 Show Posts
|
|
Pages: [1]
|
...
Wow, fantastic explanation. Now it's clear. Thank you very much! |
|
|
|
I have a question. I know that a transaction consists of an input and an output, whereas an unspent transaction output (UTXO) is equivalent to an amount someone holds. Clearly, every output contains a locking script, whereas each input contains a corresponding unlocking script. My question is the following: We consider the following picture (unfortuatley, [img]http://doesn't work... https://freedomnode.com/uploads/images/ad1f3d1790b9f1f7764fbc72f2337b6c44cd5adfba10324a9a8a65e5b6b09125.pngThe picture shows that Bob spends 0.5 BTC to Alice. This is quite clear. He signs the transaction. But now this is what I don't understand: When do the 0.5 BTC appear in Alices wallet? Does she now posses the Output of transaction A? Because this is an unspent output. Only when she wants to pay her employee, she unlocks this output, such that the input of transaction B consumes the output of transaction A. Then, her empoyee "holds" the output of transaction B. Is this the correct way? In my understanding, an input only consumes a previous output, when someone wants to make a subsequent transaction. This is why this picture irritates me a little, because it says "Alice receives"... But isn't she already the owner of the output, before the input of transaction B consumes the output of transaction A? So, in my optionen: Alice won't unlock the 0.5 BTC in order to possess them, but in order to spend them. I hope someone can explain me...... |
|
|
|
Wow, thank you very much! |
|
|
|
I have got a question: Bitcoin uses Elliptic Curves maths for several reasons. But my question is: How does it work in reality? This is nice to see, but is is "standard theory", these computations are very expensive; there are much more efficient algorithms. Especially, Renes, Costello and Batina showed "complete addition formulas" (see https://eprint.iacr.org/2015/1060.pdf), where one calculates in the projective plane. I also read that Bitcoin chose Secp256k1 because of efficiency reasons, so I cannot believe that they use "standard" formulas for calculating. Bitcoin uses ECC in making the public key from your private key. Private key is just a big number that is kept secret. Your private key is multiplied with the base point B using ECC math to get the public key. Privkey*B=Pubkey This operation is "one way" meaning that it is easy to do, but almost impossible to reverse. Thanks for your answer. Of course, I know the "sense" about kryptography. These is not new for me. My question is why we got these 20-30% faster computations. You wrote: For some curves like secp256k1 there are some more efficient ways to do the addition and multiplication operations. But basically they do the exact same thing as the "standard formulas" only ~20-30% faster. For example the field size is 2^256 - 2^32 - 2^9 - 2^8 - 2^7 - 2^6 - 2^4 - 1 which makes it faster to take the mod operation. So my question is: Why is it ~20-30% faster? What are the more efficient ways to do the addition and multiplication operations? Of course the result is the same as if I would calculate it with the "standard formulas". The specific curve was chosen because you can do more efficient operations on it. But why is this the case? |
|
|
|
Hi all. I have got a question: Bitcoin uses Elliptic Curves maths for several reasons. But my question is: How does it work in reality? Of course in every book you find the "normal" addition and point doubling formulas in every book, such as:  This is nice to see, but is is "standard theory", these computations are very expensive; there are much more efficient algorithms. Especially, Renes, Costello and Batina showed "complete addition formulas" (see https://eprint.iacr.org/2015/1060.pdf), where one calculates in the projective plane. So, does anyone know how ECC is used in Bitcoin? Is there a possibility where I can find the code in the Bitcoin protocol? I also read that Bitcoin chose Secp256k1 because of efficiency reasons, so I cannot believe that they use "standard" formulas for calculating. |
|
|
|
According to Mani Rosenfeld:
If the average time to find a block is T, and the typical time for a found block to propagate in the network is t, then the proportion of orphans among all blocks will be roughly 1/(1+T/t).
I also found this formula in one of his posts now. I hope I find a mathematical proof for this estimation. I will read his papers now. |
|
|
|
I understand that they would be seen as never existed. But my question is: When a new block is mined, when gets the miner the new coins into his wallet? Immediately? Or must he wait for this 100 confirmations which DannyHamilton mentioned?
I mean: Assumed that two miners make a block at the same time and the wallet would get the new coins immediately, one would lose them after resolving the fork. I hope you know what I mean, but i wasn't able to find an answer to this.
Ah ok, the rule is like DannyHamilton said: For each input, if the referenced output transaction is coinbase (i.e. only 1 input, with hash=0, n=-1), it must have at least COINBASE_MATURITY (100) confirmations; else reject this transaction. Now I understand. I wasn't clear to me. I thought they are just not spendable for 100 confirmations long.......... I'm idiot  |
|
|
|
Most of the transactions in one side of the split will also ALREADY be confirmed in the other side of the split as well. However, this is the reason that many services require 3 or 6 confirmations before accepting a transaction as completed. It is extremely unlikely for a split to last than many blocks without being resolved.
So the 6 confirmations is an experience value? or is there a boundary value of probability one could show mathematically? According to Mani Rosenfeld: If the average time to find a block is T, and the typical time for a found block to propagate in the network is t, then the proportion of orphans among all blocks will be roughly 1/(1+T/t). In the case of Bitcoin, the average time to find a block tends to be somewhere around 10 minutes. A conservative estimate for the typical time to propagate in the network would be less than 5 seconds. Converting 10 minutes to 600 seconds and plugging those values in to the equation... 1/(1+600/5) is approximately 0.00826 = 0.826% So: - The chances that the next block solved will be orphaned is probably less than 0.826%.
- The chances that the next two blocks in a row will be orphaned is probably less than 0.008262 = 0.0000682 = 0.00682%
- The chances that the next three blocks in a row will be orphaned is probably less than 0.008263 = 0.000000564 = 0.0000564%
- The chances that the next four blocks in a row will be orphaned is probably less than 0.008264 = 0.00000000466 = 0.000000466%
- The chances that the next five blocks in a row will be orphaned is probably less than 0.008265 = 0.0000000000385 = 0.00000000385%
- The chances that the next six blocks in a row will be orphaned is probably less than 0.008266 = 0.000000000000318 - 0.0000000000318%
If you don't like my estimates of 600 seconds and 5 seconds, then plug in your own estimate and see how it works out. Thank you! |
|
|
|
Most of the transactions in one side of the split will also ALREADY be confirmed in the other side of the split as well. However, this is the reason that many services require 3 or 6 confirmations before accepting a transaction as completed. It is extremely unlikely for a split to last than many blocks without being resolved.
So the 6 confirmations is an experience value? or is there a boundary value of probability one could show mathematically? |
|
|
|
Ok, I understand this. I understand this point of view what users see. But what sees the miner? I realize that the shorter chain will become orphaned. But what happenes to the "new" coins of these succesful miners who are in the shorter chain? I hope you know what I mean.
I mean: After the shorter chain will become orphaned, EVERY user will see the longer chain. Then there is a real consensus. And this means that only the ones in the longer chain should have new coins.
The coinbase transaction on that orphaned chain would be as if it has never existed. It's usually just for a block or two so it isn't a huge loss to them; unless they somehow create a longer fork due to differing rules. In these case, are there is still one common pool of transactions?
Strictly speaking, the mempool differs for every single node across the network. Given that the mempool of every node of the network is consistent before the split, they would have the same pool of transaction at the point of split (confirmed+unconfirmed). Let's assume I make a transfer and I am following chain 1. But the transfer is confirmed in a block of chain 2 first. What do I see then? I guess it is not possible that my transfer is in chain one confirmed and about 20 minutes later also in chain two, since it is already confirmed once.....
Which chain are you on? Lets say there's two blockchain, chain A and chain B. If you are on chain A and it has one confirmation, you would see one confirmation in your client. If you are on the chain B where your transaction has never been included in a block, you wouldn't see a confirmation. When the chain B gets longer than the chain A, chain A would get orphaned and your transaction would have zero confirmation again. This is one of the reason why people require more than one confirmation for the maximum security that they can have. Ah, fantastic, now I understand this parts. Thanks. I didn't find a description of these cases in any book... Thanks! But der is still one question: Ok, I understand this. I understand this point of view what users see. But what sees the miner? I realize that the shorter chain will become orphaned. But what happenes to the "new" coins of these succesful miners who are in the shorter chain? I hope you know what I mean.
I mean: After the shorter chain will become orphaned, EVERY user will see the longer chain. Then there is a real consensus. And this means that only the ones in the longer chain should have new coins.
The coinbase transaction on that orphaned chain would be as if it has never existed. It's usually just for a block or two so it isn't a huge loss to them; unless they somehow create a longer fork due to differing rules. I understand that they would be seen as never existed. But my question is: When a new block is mined, when gets the miner the new coins into his wallet? Immediately? Or must he wait for this 100 confirmations which DannyHamilton mentioned? I mean: Assumed that two miners make a block at the same time and the wallet would get the new coins immediately, one would lose them after resolving the fork. I hope you know what I mean, but i wasn't able to find an answer to this. |
|
|
|
Oh, just another question. You wrote: The entire network will be split. Nodes, merchants, and users that accept one of the blocks will see that the miner of THAT block got new bitcoins and that the miner of the other block did not. Nodes, merchants, and users that accept the other blocks will see the opposite. The network will remain in this split state until one of the chains establishes "longer chain", and at that time the "shorter chain" will become orphaned.
In these case, are there is still one common pool of transactions? Let's assume I make a transfer and I am following chain 1. But the transfer is confirmed in a block of chain 2 first. What do I see then? I guess it is not possible that my transfer is in chain one confirmed and about 20 minutes later also in chain two, since it is already confirmed once..... |
|
|
|
Wow, thank you very much, now anything makes sense to me! It wasn't clear to me that in both chains the transactions could be confirm - even it is clear. Your explanation makes more sense that the ones in EVERY book I read so far. Theres only one question left. You wrote: The entire network will be split. Nodes, merchants, and users that accept one of the blocks will see that the miner of THAT block got new bitcoins and that the miner of the other block did not. Nodes, merchants, and users that accept the other blocks will see the opposite. The network will remain in this split state until one of the chains establishes "longer chain", and at that time the "shorter chain" will become orphaned. Ok, I understand this. I understand this point of view what users see. But what sees the miner? I realize that the shorter chain will become orphaned. But what happenes to the "new" coins of these succesful miners who are in the shorter chain? I hope you know what I mean. I mean: After the shorter chain will become orphaned, EVERY user will see the longer chain. Then there is a real consensus. And this means that only the ones in the longer chain should have new coins. |
|
|
|
|
Hi. I am "new" in bitcoin, I read several books about it and I try to understand how it works.
Well, I understand the sense of mining: building new blocks with transactions to be confirmed. And the one who mines it gets new bitcoins via the coinbase transfer. I also understand that it can happen that 2 or more new blocks are mined simultaneously - so at the end, the longest chain will "win" and the other blocks will end in a fork.
Well, I am still confused about the following thing: I read that the transactions in the outpaced blocks go back in the mempool, waiting to come to another block (and this opens the possibility for a double-spending attack). But my questions are:
- Let's assume there were to blocks mined simultaneously. Did both get new bitcoins? What happenes with the one who will "lose the race" for the longest chain? Are his new bitcoins cancelled? And if, what if he already spent it?
- And: If there is a fork: Everyone who has a transaction in it would be able to do a double spending attack?
- Assumed that one makes a double-spend attack (waiting for more than several blocks, theoretically). I always read that the vendor then will "lose" his bitcoins (clear), since the transaction will get invalid. But: Theoretically, the vendor who gets attacked may already spent the amount he got from the fauld transaction. What then? Isn't he the one who lose, but the one he payed with this bitcoins?
I hope someone can answer these questions.......
|
|
|
|
|
