bitcoin840 2017-01-18 03:45:20
Okay. I'll try to explain what I mean step by step.
Lauda 2017-01-18 03:45:32
Just ask the question in 1 sentence
Lauda 2017-01-18 03:45:38
It seems that explaining makes it worse :D
bitcoin840 2017-01-18 03:45:56
Let me give it another try. Please! :)
Lauda 2017-01-18 03:46:12
Sure. Go ahead
bitcoin840 2017-01-18 03:46:16
- Bob has to send money to the seller to pay a service.
haakonn 2017-01-18 03:46:34
i'm confused, who's bob?
bitcoin840 2017-01-18 03:46:47
Oh, no! :)
haakonn 2017-01-18 03:46:49
:D
bitcoin840 2017-01-18 03:46:52
Bob is the buyer.
haakonn 2017-01-18 03:46:59
Bob the Buyer, got it
bitcoin840 2017-01-18 03:46:59
'right. Let me do this.
Lauda 2017-01-18 03:47:02
Okay Bob sends to service. What's next
bitcoin840 2017-01-18 03:47:40
Bob issues a transaction (from: bob; to:seller)
bitcoin840 2017-01-18 03:47:56
At the same time Bob issues another transaction (from: bob; to: bob)
bitcoin840 2017-01-18 03:48:32
Some nodes (bookeepers) may receive the former first , some others the latter
haakonn 2017-01-18 03:48:37
it is possible that both get mined, by different miners - yes
bitcoin840 2017-01-18 03:48:43
Now, what's the order?
haakonn 2017-01-18 03:48:57
generally nodes accept the block they see first
bitcoin840 2017-01-18 03:48:58
In order to establish the order (yeah, words...) they have to "vote"
Lauda 2017-01-18 03:49:02
You're talking about orphan blocks.
bitcoin840 2017-01-18 03:49:42
Yeah, they accept the block they see first but they're not in agrement.
bitcoin840 2017-01-18 03:50:18
To agree on which one is the transaction, they have to "vote" The voting system here consists of solving a math problem
haakonn 2017-01-18 03:50:18
some nodes will accept block A as the valid one, some will accept block B. some miner builds on block A, and finds block AA. now the chain consisting of A and AA is longer than the chain consisting of block B, so block A is the valid one
Lauda 2017-01-18 03:50:23
The "winner" is decided by the next mined block
bitcoin840 2017-01-18 03:51:09
What if some miner builds on block B and builds BB?
haakonn 2017-01-18 03:51:23
in that case you have to wait even one more round, for AAA or BBB
haakonn 2017-01-18 03:51:37
but as these chains get longer, they get less and less probable
Lauda 2017-01-18 03:51:50
A orphaned chain can have more blocks.
haakonn 2017-01-18 03:51:53
finally just one remains, and everybody agrees
haakonn 2017-01-18 03:52:31
yes, technically it's the one with the most work that wins, but that's a minor detail that can confuse
bitcoin840 2017-01-18 03:53:02
>"in that case you have to wait even one more round, for AAA or BBB". Why? Here I'm getting confused.
haakonn 2017-01-18 03:53:09
when you explain something to newbies, you have to simplify a little so he has a chance to build intuition. you can't just link to protocol specs like you did, Lauda :)
Lauda 2017-01-18 03:53:29
Protocol specs are nice to use your brain like an adult.
haakonn 2017-01-18 03:53:54
bitcoin840: because the consensus rules say that the longest chain wins, and if you have a tie, you need to wait for it to resolve
bitcoin840 2017-01-18 03:54:04
As I understood it, they need to "have to do other rounds" only if they solve the math problem at about the same instant.
Lauda 2017-01-18 03:54:05
bitcoin840 because if two miners mine follow up blocks, one starting with prevhash(block A) and another prevhash (block B) at the same time
Lauda 2017-01-18 03:54:09
You get the same situation again
haakonn 2017-01-18 03:54:20
bitcoin840: yes, that's true
haakonn 2017-01-18 03:54:39
if they don't release the blocks at almost the same instant, there is no conflict - the first observed block will win
bitcoin840 2017-01-18 03:55:13
and...my question is...what if the first observed block to win is the block B (bob->bob)?
Lauda 2017-01-18 03:55:28
Then bob made a double spend.
haakonn 2017-01-18 03:55:32
then bob has cheated the seller. double-spending isn't impossible in bitcoin
bitcoin840 2017-01-18 03:55:38
oooh! Here it is.
bitcoin840 2017-01-18 03:55:46
So, what keeps the overall system safe?
haakonn 2017-01-18 03:55:54
bitcoin is all about the improbable, not the impossible
Lauda 2017-01-18 03:55:59
Confirmations bitcoin840
Lauda 2017-01-18 03:56:02
I keep telling you this
haakonn 2017-01-18 03:56:05
the cost of mining
bitcoin840 2017-01-18 03:56:28
Lauda, you have to excuse me! :) Can you expand on that?
Lauda 2017-01-18 03:56:42
+ you do not want to cheat a service that can revoke your goods. e.g. cheating Steam when they can block your whole account would be a bad mistake.
haakonn 2017-01-18 03:57:08
bitcoin840: the point is that the seller can avoid getting cheated simply by waiting for more confirmations
Lauda 2017-01-18 03:57:20
bitcoin840 it's a probabilistic system. With zero configurations there is a risk of a double-spend (even by non mallicious intent, e.g. zero included fee). The more confirmations you have the risk gets expontentially lower.
haakonn 2017-01-18 03:57:31
zero confirmations*
bitcoin840 2017-01-18 03:57:54
but what are confirmations? What is there to be confirmed if the block has been "settled" and the attacker double-spended successfully?
Lauda 2017-01-18 03:58:07
1 block with included TX = 1 confirmation
Lauda 2017-01-18 03:58:38
You wait (!) for the confirmations and then finish the transaction as a seller
Lauda 2017-01-18 03:58:47
Not sell your goods and then wait for confirmations
Lauda 2017-01-18 03:59:15
Unless you can revoke access to the sold service. In that case I guess it's fine to accept zero-conf. TXs.
bitcoin840 2017-01-18 04:00:04
Please, be patient. I don't get what "configurations" and "confirmations" are.
bitcoin840 2017-01-18 04:00:10
[-.-]"
Lauda 2017-01-18 04:00:15
configurations?
Lauda 2017-01-18 04:00:22
I just told you what a confirmation is
Lauda 2017-01-18 04:00:36
X confirmations = X number of blocks since the TX was included into the blockchain.
bitcoin840 2017-01-18 04:02:11
okay, so it has to do with the subsequent blocks (the blocks after the now-validated block). Right?
bitcoin840 2017-01-18 04:02:48
How do they make it more secure as the confirmations grow?
Lauda 2017-01-18 04:02:50
1 confirmation = TX was included in previous block; 2 confirmation = was included in the second last block, etc.
Lauda 2017-01-18 04:03:17
It's hard to revert confirmations. You'd need to have extensive mining power.
mryandao 2017-01-18 04:03:29
i like to think of it as books piling up on each other.
haakonn 2017-01-18 04:03:35
Lauda: you used the word "configurations" yourself, by mistake
mryandao 2017-01-18 04:03:45
the more they are stacked, the harder it is for you to undo the "arrangement"
bitcoin840 2017-01-18 04:03:46
But aren't the transaction just put in one single block?
Lauda 2017-01-18 04:03:53
No
Lauda 2017-01-18 04:04:08
1 block is created every 10 minutes on average.
bitcoin840 2017-01-18 04:04:22
In how many blocks is it put?
Lauda 2017-01-18 04:04:39
Ah now I see what you're asking. Yes, a TX is included in 1 block
Lauda 2017-01-18 04:04:48
but this block is chained to the following block, and so on
Lauda 2017-01-18 04:04:52
hence "block" "chain"
bitcoin840 2017-01-18 04:06:14
yeah, yeah. But if the block with the transaction has been attacked (mined by an attacker sooner), the subsequent blocks will only "refer" to it not recheck it.
Lauda 2017-01-18 04:06:41
Each node should validate the mined block and build upon it.
Lauda 2017-01-18 04:06:59
Are you in the IT field?
maret 2017-01-18 04:07:51
Hi everyone, is there some plan how to lower fees if you are sending a lot of transactions locally? For example I pay my bank few euro a month and have unlimited number of transactions. With aproximate 0.17 cents per transaction it takes around 30 transaction to pay 5 dollars which is not that many transactions per month
Lauda 2017-01-18 04:08:10
^no.
maret 2017-01-18 04:08:18
and my understanding is that fees might go higher for several usecases
haakonn 2017-01-18 04:08:22
bitcoin has no notion of "locally" :)
Lauda 2017-01-18 04:08:25
^
Lauda 2017-01-18 04:08:35
All Bitcoin payments are global.
Anduck 2017-01-18 04:08:37
maret: you can make a payment channel
haakonn 2017-01-18 04:08:46
and bitcoin fees are not centrally planned, so there is no "plan"
Anduck 2017-01-18 04:08:49
inside the channel you can transfer as much as you want for zero fee
bitcoin840 2017-01-18 04:09:13
Lauda: "Each node should validate the mined block and build upon it." How?
Lauda 2017-01-18 04:09:30
Do you even know what nodes are?
haakonn 2017-01-18 04:09:34
bitcoin840: by including a hash of the block they're building on inside the block they're building
Anduck 2017-01-18 04:09:36
bitcoin840: nodes check that work has been done when the chain was extended with a new block. (=PoW)
Lauda 2017-01-18 04:09:38
Nodes are supposed to validate both TXs and blocks.
haakonn 2017-01-18 04:10:15
it's useful to ask questions to build intuition, but at some point reading documentation is more useful
maret 2017-01-18 04:15:24
Anduck: payment channel helps if you are planning to pay to same party several times right? If yes that doesn't help. Unless many merchants would use same Bitcoin wallet provider.
bitcoin840 2017-01-18 04:15:42
I understand that the next block has to refer to the previous one by its hash but yet I can't see how that assures the correct order and prevent the attack.
bitcoin840 2017-01-18 04:15:48
Maybe it's me! :|
bitcoin840 2017-01-18 04:16:23
Anyway, than k you all Anduck, haakonn and Lauda.
Lauda 2017-01-18 04:16:54
Google is your friend.
