marijn 2017-01-18 03:03:08
interesting
bitcoin840 2017-01-18 03:22:16
Hello everyone! While I was learning how bitcoin works, I got stuck in a concept. Can anyone of you help me understand it?
Lauda 2017-01-18 03:24:02
What's the problem
bitcoin840 2017-01-18 03:28:09
I was watching this https://app.pluralsight.com/player?course=bitcoin-decentralized-technology&author=scott-driscoll&name=bitcoin-decentralized-technology-m2&clip=7&mode=live (requires account to watch it) and I don't understand 1. how the system ensures that the majority of bookeepers decide about the transaction order (in order to prevent a double-spend attack);
piqure 2017-01-18 03:28:10
^^^ WARNING: any URL may lead directly or indirectly to COIN-STEALING MALWARE! ^^^
bitcoin840 2017-01-18 03:28:16
b. why is that "transactions towards the end of the chain shouldn't be trusted as much as ones further back"?
Lauda 2017-01-18 03:29:21
1) For a block to be valid, all TXs have to be validated. This means that every input signature has to be validated. If it's already been spent, it won't be accepted. To know how this exactly works, you need to look @code.
Lauda 2017-01-18 03:30:00
2) That's because security is based on a probabilistic system. This means that no amount of confirmations will guarantee 100% security. The more confirmations a TX has, the more security is has. Generally, it is not advised to accept a zero-conf TX.
Lauda 2017-01-18 03:32:01
Here's more information about 1. https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages
piqure 2017-01-18 03:32:02
^^^ WARNING: any URL may lead directly or indirectly to COIN-STEALING MALWARE! ^^^
bitcoin840 2017-01-18 03:35:20
I know that to understand it very well, I have to look at the code directly. I just wanted to get an overall concept.
bitcoin840 2017-01-18 03:35:56
If Bob has to send money to the seller and he issues 2 transactions to try to "fool" the ledger. 1st transaction: Bob -> Seller ;2nd transaction: Bob -> Bob Some bookeepers may receive 1-2, some other 2-1. They "vote" to decide by solving the math problem. Now, if a bookeeper who has the block that contains 2-1 solves it first, the block to be inserted in the chain would be that with the transactions in the order 2-1 and thus Bo
bitcoin840 2017-01-18 03:36:42
Is that right? What prevents this scenario from happening?
Lauda 2017-01-18 03:36:45
Yes, it all comes down what the miner has in the mempool and who solves the block first (and whether it propagates to most in time).
Lauda 2017-01-18 03:37:06
I don't see something that requires prevention.
Lauda 2017-01-18 03:37:26
You are supposed to wait for confirmations, as I've mentioned above.
haakonn 2017-01-18 03:37:34
key observation: to replace a confirmation that is already confirmed, you need to replace the block it's in. mining one block is very resource-intensive. but you also need to replace all blocks *after* it, since the longest chain is the valid one. so the more blocks you have to replace, the harder it is
bitcoin840 2017-01-18 03:38:10
But, in the way I described it, it's vulnerable to double-spend attacks.They see the block has been solved with the order 2-1. They verify it with the hash function and everything seems okay.
Lauda 2017-01-18 03:38:36
Zero confirmation TXs are vulnerable to double-spend attacks. That's known
Lauda 2017-01-18 03:38:45
This is why you wait for confirmations.
haakonn 2017-01-18 03:39:21
you describe the "one confirmation" scenario. it happens that one of them gets "orphaned", as you describe. not often, but it happens. better to wait for 2 confirmations in this case
bitcoin840 2017-01-18 03:39:21
how do the others confirm it? Don't they check with hash function if the hash generated suffice the math problem?
haakonn 2017-01-18 03:39:47
each miner constructs blocks that contains the hash of the previous block
Lauda 2017-01-18 03:40:52
I think this is moving away from double spend problem to orphans and stale blocks.
bitcoin840 2017-01-18 03:40:53
Yes! And the first one who solves it, sends the solution to the others who, in turn, verify it. Valid -> Transaction order OK.
Lauda 2017-01-18 03:41:07
So what's the question again?
haakonn 2017-01-18 03:41:08
they verify it, and starts building "on top of" it
bitcoin840 2017-01-18 03:41:32
What do you mean with "starts building "on top of" it" ?
haakonn 2017-01-18 03:41:46
they include the hash of the block in their new block
haakonn 2017-01-18 03:42:04
thus forming a chain of blocks, or a blockchain
Lauda 2017-01-18 03:42:20
You should look up what a block consists of, as knowing what that means is really trivial.
bitcoin840 2017-01-18 03:43:19
yes, but the new block will have subsequent transactions. The previous transaction has already been put in the now-validated block.
haakonn 2017-01-18 03:43:36
yes, it's not allowed to put the same transaction in two different blocks
bitcoin840 2017-01-18 03:43:39
A block is a group of transactions, right?
haakonn 2017-01-18 03:43:53
correct
Lauda 2017-01-18 03:44:21
bitcoin840 a signature spending an already spent input will not work
Lauda 2017-01-18 03:44:31
It will be considered invalid. Including this into your block = invalid block
bitcoin840 2017-01-18 03:44:41
I understand that. Maybe I'm not explaining myself well.
bitcoin840 2017-01-18 03:44:59
I know an already-spent input will be considered invalid.
