I mean bitcoin's proof of work can act as a timestamp mechanism for more than just bitcoin.
With Bitcoin blocks coming out every ten minutes, an altcoin that quoted a recent bitcoin block's hash would contain a reference to that ten-minute period. You couldn't generate the altcoin block before that period arrived.
Topic: what could prevent the sender from preparing a chain of blocks ahead of time? (Read 1544 times)
May 21, 2014, 01:41:06 PM
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
May 21, 2014, 01:32:51 PM
If you want to prevent someone from preparing a chain of blocks ahead of time, it's worthwhile to require each block to contain some kind of observed event that can't easily be known in advance.
A Bitcoin block ID/Hash would be a pretty good example of that, I'm thinking.
If you require a bitcoin hash from, say, 2 hours ago in each block of your block chain, you're immune to reorgs on the bitcoin blockchain unless they're over 2 hours long, and the time of appearance of each bitcoin block is publicly known. The result is that nobody can make a block of your altcoin chain more than 2 hours in advance.
A Bitcoin block ID/Hash would be a pretty good example of that, I'm thinking.
If you require a bitcoin hash from, say, 2 hours ago in each block of your block chain, you're immune to reorgs on the bitcoin blockchain unless they're over 2 hours long, and the time of appearance of each bitcoin block is publicly known. The result is that nobody can make a block of your altcoin chain more than 2 hours in advance.
not sure what you mean exactly. Bitcoin's proof of work already acts as a timestamp mechanism.
May 21, 2014, 11:54:25 AM
If you want to prevent someone from preparing a chain of blocks ahead of time, it's worthwhile to require each block to contain some kind of observed event that can't easily be known in advance.
A Bitcoin block ID/Hash would be a pretty good example of that, I'm thinking.
If you require a bitcoin hash from, say, 2 hours ago in each block of your block chain, you're immune to reorgs on the bitcoin blockchain unless they're over 2 hours long, and the time of appearance of each bitcoin block is publicly known. The result is that nobody can make a block of your altcoin chain more than 2 hours in advance.
A Bitcoin block ID/Hash would be a pretty good example of that, I'm thinking.
If you require a bitcoin hash from, say, 2 hours ago in each block of your block chain, you're immune to reorgs on the bitcoin blockchain unless they're over 2 hours long, and the time of appearance of each bitcoin block is publicly known. The result is that nobody can make a block of your altcoin chain more than 2 hours in advance.
May 21, 2014, 06:19:37 AM
It's... difficult.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
May 19, 2014, 12:24:42 PM
it is possible, but it is very difficult/unlikely unless you have
a huge amount of hashing power, which is probably going to be
much more expensive than the double-spend you are trying to do.
a huge amount of hashing power, which is probably going to be
much more expensive than the double-spend you are trying to do.
May 19, 2014, 11:57:54 AM
What video?
What you described is a double spend. It becomes progressively more difficulty for Alice to build the longer chain unless she hash a majority of the computing power. It doesn't matter if Alice starts building the attack chain first or makes the legitimate deposit and then starts building the attack chain the probability she will outrace the network starting from a block behind is unlikely. The more confirmations the less likely it becomes.
For a deposit of 1,000 BTC the exchange should probably require more than three confirmations. Meni wrote a very good paper on the economics of double spending. If Alice has 10% of the network computing power her chance of being successful is 1.712% for 3 confirmations, 0.546% for 4 confirmations, 0.178% for 5 confirmations, and 0.059% for 6 confirmations. The exchange can also protect itself by validating KYC information for users involved in large transactions. https://bitcoil.co.il/Doublespend.pdf
As for your quote. I don't know what Satoshi was talking about in the quoted section as it doesn't make any sense to me either. You are right, the attacker doesn't need the victims PubKey in order to build the chain because the "attack chain" will contain the double spend not the spend to the victim. I can only conclude that Satoshi was either mistaken or he is talking about something else and is unclear in the wording. The paper was written at a theoretical level about a year before the first version of the client was completed.
What you described is a double spend. It becomes progressively more difficulty for Alice to build the longer chain unless she hash a majority of the computing power. It doesn't matter if Alice starts building the attack chain first or makes the legitimate deposit and then starts building the attack chain the probability she will outrace the network starting from a block behind is unlikely. The more confirmations the less likely it becomes.
For a deposit of 1,000 BTC the exchange should probably require more than three confirmations. Meni wrote a very good paper on the economics of double spending. If Alice has 10% of the network computing power her chance of being successful is 1.712% for 3 confirmations, 0.546% for 4 confirmations, 0.178% for 5 confirmations, and 0.059% for 6 confirmations. The exchange can also protect itself by validating KYC information for users involved in large transactions. https://bitcoil.co.il/Doublespend.pdf
As for your quote. I don't know what Satoshi was talking about in the quoted section as it doesn't make any sense to me either. You are right, the attacker doesn't need the victims PubKey in order to build the chain because the "attack chain" will contain the double spend not the spend to the victim. I can only conclude that Satoshi was either mistaken or he is talking about something else and is unclear in the wording. The paper was written at a theoretical level about a year before the first version of the client was completed.
This video: http://www.youtube.com/watch?v=Lx9zgZCMqXE . At around 14:00 minutes, it explains why one can't preparing blocks ahead of time. I think what it says is incorrect.
Meni assumes one block was pre-mined by the attacker. All his calculation is base on this assumption.
My case is that the attacker pre-mines all the blocks he needs, Which makes him sure he can double spend the coins. The calculation should be different between my case and Meni's case.
I think if someone really want to double spend coins, he should pre-mine all the blocks he needs.
The reasons are:
1. When he is successfully pre-mine the blocks he needs, he is 100% sure he can double spend the coins.
2. When he pre-mine the blocks, he can abandon his hidden chain when his chain becomes shorter than the honest chain, and works on another hidden chain after the honest chain. This is more efficient. In Meni's case, unless the attacker gives up his attack, after the he spent the coins in the honest chain, he can't abandon his hidden chain even if the honest chain becomes longer than his chain.
The video is not incorrect.
Are you sure you understand the part where they said the previous blocks output is used as input to the next block?
you would need a tremendous amount of hashing power to outmine the network for even a few blocks.
I sure I understand.
Preparing a chain of blocks ahead of time is possible, that why I said the video was incorrect.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
May 19, 2014, 01:25:03 AM
What video?
What you described is a double spend. It becomes progressively more difficulty for Alice to build the longer chain unless she hash a majority of the computing power. It doesn't matter if Alice starts building the attack chain first or makes the legitimate deposit and then starts building the attack chain the probability she will outrace the network starting from a block behind is unlikely. The more confirmations the less likely it becomes.
For a deposit of 1,000 BTC the exchange should probably require more than three confirmations. Meni wrote a very good paper on the economics of double spending. If Alice has 10% of the network computing power her chance of being successful is 1.712% for 3 confirmations, 0.546% for 4 confirmations, 0.178% for 5 confirmations, and 0.059% for 6 confirmations. The exchange can also protect itself by validating KYC information for users involved in large transactions. https://bitcoil.co.il/Doublespend.pdf
As for your quote. I don't know what Satoshi was talking about in the quoted section as it doesn't make any sense to me either. You are right, the attacker doesn't need the victims PubKey in order to build the chain because the "attack chain" will contain the double spend not the spend to the victim. I can only conclude that Satoshi was either mistaken or he is talking about something else and is unclear in the wording. The paper was written at a theoretical level about a year before the first version of the client was completed.
What you described is a double spend. It becomes progressively more difficulty for Alice to build the longer chain unless she hash a majority of the computing power. It doesn't matter if Alice starts building the attack chain first or makes the legitimate deposit and then starts building the attack chain the probability she will outrace the network starting from a block behind is unlikely. The more confirmations the less likely it becomes.
For a deposit of 1,000 BTC the exchange should probably require more than three confirmations. Meni wrote a very good paper on the economics of double spending. If Alice has 10% of the network computing power her chance of being successful is 1.712% for 3 confirmations, 0.546% for 4 confirmations, 0.178% for 5 confirmations, and 0.059% for 6 confirmations. The exchange can also protect itself by validating KYC information for users involved in large transactions. https://bitcoil.co.il/Doublespend.pdf
As for your quote. I don't know what Satoshi was talking about in the quoted section as it doesn't make any sense to me either. You are right, the attacker doesn't need the victims PubKey in order to build the chain because the "attack chain" will contain the double spend not the spend to the victim. I can only conclude that Satoshi was either mistaken or he is talking about something else and is unclear in the wording. The paper was written at a theoretical level about a year before the first version of the client was completed.
This video: http://www.youtube.com/watch?v=Lx9zgZCMqXE . At around 14:00 minutes, it explains why one can't preparing blocks ahead of time. I think what it says is incorrect.
Meni assumes one block was pre-mined by the attacker. All his calculation is base on this assumption.
My case is that the attacker pre-mines all the blocks he needs, Which makes him sure he can double spend the coins. The calculation should be different between my case and Meni's case.
I think if someone really want to double spend coins, he should pre-mine all the blocks he needs.
The reasons are:
1. When he is successfully pre-mine the blocks he needs, he is 100% sure he can double spend the coins.
2. When he pre-mine the blocks, he can abandon his hidden chain when his chain becomes shorter than the honest chain, and works on another hidden chain after the honest chain. This is more efficient. In Meni's case, unless the attacker gives up his attack, after the he spent the coins in the honest chain, he can't abandon his hidden chain even if the honest chain becomes longer than his chain.
The video is not incorrect.
Are you sure you understand the part where they said the previous blocks output is used as input to the next block?
you would need a tremendous amount of hashing power to outmine the network for even a few blocks.
May 19, 2014, 01:07:59 AM
What video?
What you described is a double spend. It becomes progressively more difficulty for Alice to build the longer chain unless she hash a majority of the computing power. It doesn't matter if Alice starts building the attack chain first or makes the legitimate deposit and then starts building the attack chain the probability she will outrace the network starting from a block behind is unlikely. The more confirmations the less likely it becomes.
For a deposit of 1,000 BTC the exchange should probably require more than three confirmations. Meni wrote a very good paper on the economics of double spending. If Alice has 10% of the network computing power her chance of being successful is 1.712% for 3 confirmations, 0.546% for 4 confirmations, 0.178% for 5 confirmations, and 0.059% for 6 confirmations. The exchange can also protect itself by validating KYC information for users involved in large transactions. https://bitcoil.co.il/Doublespend.pdf
As for your quote. I don't know what Satoshi was talking about in the quoted section as it doesn't make any sense to me either. You are right, the attacker doesn't need the victims PubKey in order to build the chain because the "attack chain" will contain the double spend not the spend to the victim. I can only conclude that Satoshi was either mistaken or he is talking about something else and is unclear in the wording. The paper was written at a theoretical level about a year before the first version of the client was completed.
What you described is a double spend. It becomes progressively more difficulty for Alice to build the longer chain unless she hash a majority of the computing power. It doesn't matter if Alice starts building the attack chain first or makes the legitimate deposit and then starts building the attack chain the probability she will outrace the network starting from a block behind is unlikely. The more confirmations the less likely it becomes.
For a deposit of 1,000 BTC the exchange should probably require more than three confirmations. Meni wrote a very good paper on the economics of double spending. If Alice has 10% of the network computing power her chance of being successful is 1.712% for 3 confirmations, 0.546% for 4 confirmations, 0.178% for 5 confirmations, and 0.059% for 6 confirmations. The exchange can also protect itself by validating KYC information for users involved in large transactions. https://bitcoil.co.il/Doublespend.pdf
As for your quote. I don't know what Satoshi was talking about in the quoted section as it doesn't make any sense to me either. You are right, the attacker doesn't need the victims PubKey in order to build the chain because the "attack chain" will contain the double spend not the spend to the victim. I can only conclude that Satoshi was either mistaken or he is talking about something else and is unclear in the wording. The paper was written at a theoretical level about a year before the first version of the client was completed.
This video: http://www.youtube.com/watch?v=Lx9zgZCMqXE . At around 14:00 minutes, it explains why one can't preparing blocks ahead of time. I think what it says is incorrect.
Meni assumes one block was pre-mined by the attacker. All his calculation is base on this assumption.
My case is that the attacker pre-mines all the blocks he needs, Which makes him sure he can double spend the coins. The calculation should be different between my case and Meni's case.
I think if someone really want to double spend coins, he should pre-mine all the blocks he needs.
The reasons are:
1. When he is successfully pre-mine the blocks he needs, he is 100% sure he can double spend the coins.
2. When he pre-mine the blocks, he can abandon his hidden chain when his chain becomes shorter than the honest chain, and works on another hidden chain after the honest chain. This is more efficient. In Meni's case, unless the attacker gives up his attack, after the he spent the coins in the honest chain, he can't abandon his hidden chain even if the honest chain becomes longer than his chain.
May 18, 2014, 03:14:48 PM
The attack that satoshi I believe is hinting at is hidden mining. If I know Supercar Ltd's private key and know they are selling a supercar for 10,000BTC I start mining at the current block including a transaction for 10,000BTC to Supercar Ltd. If I am very lucky and manage to generate 6 blocks in a row on my own which are higher than the main chain and also another block on the main chain which is longer than my hidden chain then I send my hidden chain to the network. Supercar Ltd. see the transaction has 6 confirmations and so hands over the supercar. Once this has happened, I drive off in the car, and I send the block on the main chain to the network to overwrite my chain.
This is a silly attack because it costs more work on average to perform than a normal double spend via lucky generation of 6 blocks in a row and only works on things which are given to the customer immediately. The advantage of the attack is that given enough waiting time to get lucky it will guarantee a double spend (assuming all the rest of the network is honest and follows the protocol rules exactly)
I may be wrong but this is my interpretation of Satoshi's words.
This is a silly attack because it costs more work on average to perform than a normal double spend via lucky generation of 6 blocks in a row and only works on things which are given to the customer immediately. The advantage of the attack is that given enough waiting time to get lucky it will guarantee a double spend (assuming all the rest of the network is honest and follows the protocol rules exactly)
I may be wrong but this is my interpretation of Satoshi's words.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
May 18, 2014, 02:49:34 PM
would it maybe have to do with the situation where its a single
transaction in a block?
Or would that not matter, because you still need the previous block's
information to solve the next block?
transaction in a block?
Or would that not matter, because you still need the previous block's
information to solve the next block?
May 18, 2014, 02:41:48 PM
maybe originally there was no such thing as blocks and every transaction was simply linked to the next?
No there always was a chain of blocks from the very begining. It was the new concept which solved the double spend problem in a decentralized network. If someone has a good explanation for what Satoshi means in this quote I am all ears.
Larger context quoted.
Quote
11. Calculations
We consider the scenario of an attacker trying to generate an alternate chain faster than the honest
chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such
as creating value out of thin air or taking money that never belonged to the attacker. Nodes are
not going to accept an invalid transaction as payment, and honest nodes will never accept a block
containing them. An attacker can only try to change one of his own transactions to take back
money he recently spent.
The race between the honest chain and an attacker chain can be characterized as a Binomial
Random Walk. The success event is the honest chain being extended by one block, increasing its
lead by +1, and the failure event is the attacker's chain being extended by one block, reducing the
gap by -1.
The probability of an attacker catching up from a given deficit is analogous to a Gambler's
Ruin problem. Suppose a gambler with unlimited credit starts at a deficit and plays potentially an
infinite number of trials to try to reach breakeven. We can calculate the probability he ever
reaches breakeven, or that an attacker ever catches up with the honest chain, as follows [8]:
p = probability an honest node finds the next block
q = probability the attacker finds the next block
qz = probability the attacker will ever catch up from z blocks behind
qz= 1 if p≤q
qz = (q/ p)^z if p
Given our assumption that p > q, the probability drops exponentially as the number of blocks the
attacker has to catch up with increases. With the odds against him, if he doesn't make a lucky
lunge forward early on, his chances become vanishingly small as he falls further behind.
We now consider how long the recipient of a new transaction needs to wait before being
sufficiently certain the sender can't change the transaction. We assume the sender is an attacker
who wants to make the recipient believe he paid him for a while, then switch it to pay back to
himself after some time has passed. The receiver will be alerted when that happens, but the
sender hopes it will be too late.
The receiver generates a new key pair and gives the public key to the sender shortly before
signing. This prevents the sender from preparing a chain of blocks ahead of time by working on
it continuously until he is lucky enough to get far enough ahead, then executing the transaction at
that moment. Once the transaction is sent, the dishonest sender starts working in secret on a
parallel chain containing an alternate version of his transaction.
The recipient waits until the transaction has been added to a block and z blocks have been
linked after it. He doesn't know the exact amount of progress the attacker has made, but
assuming the honest blocks took the average expected time per block, the attacker's potential
progress will be a Poisson distribution with expected value.
We consider the scenario of an attacker trying to generate an alternate chain faster than the honest
chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such
as creating value out of thin air or taking money that never belonged to the attacker. Nodes are
not going to accept an invalid transaction as payment, and honest nodes will never accept a block
containing them. An attacker can only try to change one of his own transactions to take back
money he recently spent.
The race between the honest chain and an attacker chain can be characterized as a Binomial
Random Walk. The success event is the honest chain being extended by one block, increasing its
lead by +1, and the failure event is the attacker's chain being extended by one block, reducing the
gap by -1.
The probability of an attacker catching up from a given deficit is analogous to a Gambler's
Ruin problem. Suppose a gambler with unlimited credit starts at a deficit and plays potentially an
infinite number of trials to try to reach breakeven. We can calculate the probability he ever
reaches breakeven, or that an attacker ever catches up with the honest chain, as follows [8]:
p = probability an honest node finds the next block
q = probability the attacker finds the next block
qz = probability the attacker will ever catch up from z blocks behind
qz= 1 if p≤q
qz = (q/ p)^z if p
Given our assumption that p > q, the probability drops exponentially as the number of blocks the
attacker has to catch up with increases. With the odds against him, if he doesn't make a lucky
lunge forward early on, his chances become vanishingly small as he falls further behind.
We now consider how long the recipient of a new transaction needs to wait before being
sufficiently certain the sender can't change the transaction. We assume the sender is an attacker
who wants to make the recipient believe he paid him for a while, then switch it to pay back to
himself after some time has passed. The receiver will be alerted when that happens, but the
sender hopes it will be too late.
The receiver generates a new key pair and gives the public key to the sender shortly before
signing. This prevents the sender from preparing a chain of blocks ahead of time by working on
it continuously until he is lucky enough to get far enough ahead, then executing the transaction at
that moment. Once the transaction is sent, the dishonest sender starts working in secret on a
parallel chain containing an alternate version of his transaction.
The recipient waits until the transaction has been added to a block and z blocks have been
linked after it. He doesn't know the exact amount of progress the attacker has made, but
assuming the honest blocks took the average expected time per block, the attacker's potential
progress will be a Poisson distribution with expected value.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
May 18, 2014, 01:31:09 PM
I don't know what Satoshi was talking about in the quoted section as it doesn't make any sense to me either. You are right, the attacker doesn't need the victims PubKey in order to build the chain because the "attack chain" will contain the double spend not the spend to the victim. I can only conclude that Satoshi was either mistaken or he is talking about something else and is unclear in the wording. The paper was written at a theoretical level about a year before the first version of the client was completed.
....iiiiiiinteresting....
maybe originally there was no such thing as blocks and every transaction was simply linked to the next?
May 18, 2014, 10:53:04 AM
What video?
What you described is a double spend. It becomes progressively more difficulty for Alice to build the longer chain unless she hash a majority of the computing power. It doesn't matter if Alice starts building the attack chain first or makes the legitimate deposit and then starts building the attack chain the probability she will outrace the network starting from a block behind is unlikely. The more confirmations the less likely it becomes.
For a deposit of 1,000 BTC the exchange should probably require more than three confirmations. Meni wrote a very good paper on the economics of double spending. If Alice has 10% of the network computing power her chance of being successful is 1.712% for 3 confirmations, 0.546% for 4 confirmations, 0.178% for 5 confirmations, and 0.059% for 6 confirmations. The exchange can also protect itself by validating KYC information for users involved in large transactions. https://bitcoil.co.il/Doublespend.pdf
As for your quote. I don't know what Satoshi was talking about in the quoted section as it doesn't make any sense to me either. You are right, the attacker doesn't need the victims PubKey in order to build the chain because the "attack chain" will contain the double spend not the spend to the victim. I can only conclude that Satoshi was either mistaken or he is talking about something else and is unclear in the wording. The paper was written at a theoretical level about a year before the first version of the client was completed.
What you described is a double spend. It becomes progressively more difficulty for Alice to build the longer chain unless she hash a majority of the computing power. It doesn't matter if Alice starts building the attack chain first or makes the legitimate deposit and then starts building the attack chain the probability she will outrace the network starting from a block behind is unlikely. The more confirmations the less likely it becomes.
For a deposit of 1,000 BTC the exchange should probably require more than three confirmations. Meni wrote a very good paper on the economics of double spending. If Alice has 10% of the network computing power her chance of being successful is 1.712% for 3 confirmations, 0.546% for 4 confirmations, 0.178% for 5 confirmations, and 0.059% for 6 confirmations. The exchange can also protect itself by validating KYC information for users involved in large transactions. https://bitcoil.co.il/Doublespend.pdf
As for your quote. I don't know what Satoshi was talking about in the quoted section as it doesn't make any sense to me either. You are right, the attacker doesn't need the victims PubKey in order to build the chain because the "attack chain" will contain the double spend not the spend to the victim. I can only conclude that Satoshi was either mistaken or he is talking about something else and is unclear in the wording. The paper was written at a theoretical level about a year before the first version of the client was completed.
May 18, 2014, 10:44:44 AM
You can't prepare any chain ahead of time because you always have to build on the blocks that came before it. So by the time you solve the next block, someone else will likely also solve it, and the network will use their block if you try to keep yours hidden.
What about this case?
If Alice keeps working on a chain of blocks secretly. When she is lucky enough to get a secret block chain longer than the honest chain of 3 blocks. Let's assume the length of honest chain is 1000, and hers is 1003. In her No.1003 block, Alice redeem a output of 1000BTC to herself. And then Alice makes a transaction which sends this 1000BTC to a exchange. This transaction is accepted in the No.1001 block of the honest chain . Then Alice sells the coins in the exchange, and withdraws the money. Let's assume this withdrawal is successful when the length of the honest chain increases to 1003, and the length of Alice's secret chain increases to 1004. Then Alice send her secret chain to public. Her chain is the longest chain and will be accepted by others. She will get back the 1000BTC.
In this case, I think nothing could prevent Alice from preparing her secret chain. This case is different from the video's case. In the video's case, it is assumed that Alice has to build her secret chain after the block 1. But in fact, Alice doesn't have to do this. She can keep trying until she gets a chain longer than the honest chain of enough blocks. When she get such a chain, she can surely double spend her coins.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
May 17, 2014, 09:53:28 AM
You can't prepare any chain ahead of time because you always have to build on the blocks that came before it. So by the time you solve the next block, someone else will likely also solve it, and the network will use their block if you try to keep yours hidden.
May 16, 2014, 10:12:37 AM
Basically, I want to double spend the coins i want to send to you.
I prepare two chains.
a 6 long chain with your TX in the first block
a 7 long chain with your TX doublespent in the first block.
Then I submit the first chain,
you send me the stuff and immediately I release the 7 long chain charging back the money.
When releasing the Pubkey shortly before payment, this is not possible.
I prepare two chains.
a 6 long chain with your TX in the first block
a 7 long chain with your TX doublespent in the first block.
Then I submit the first chain,
you send me the stuff and immediately I release the 7 long chain charging back the money.
When releasing the Pubkey shortly before payment, this is not possible.
Why this is not possible? The 7 long chain doesn't contain the my Pubkey. You can prepare the 7 long chain without knowing my Pubkey. Because you send the coins to your own pubkey in the 7 long chain, not my Pubkey.
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
May 15, 2014, 04:07:35 PM
You mean including only that one single transaction in a block?
May 15, 2014, 02:43:19 PM
This message was too old and has been purged
May 15, 2014, 02:39:13 PM
This message was too old and has been purged
legendary
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
May 15, 2014, 01:10:46 PM
It's a good question. I don't know what Satoshi is talking about in this paragraph either.
I do know that generally, proof of work prevents long chains from being pre built, because
the network always accepts the longest chain, so you would have to mine faster than
the rest of the network.
I thought the proof of work and chain is based on finding an acceptable hash for the
Merkle root of the block, which is based on the transaction IDs.
So I don't get how the public keys relate to this.
I do know that generally, proof of work prevents long chains from being pre built, because
the network always accepts the longest chain, so you would have to mine faster than
the rest of the network.
I thought the proof of work and chain is based on finding an acceptable hash for the
Merkle root of the block, which is based on the transaction IDs.
So I don't get how the public keys relate to this.
May 15, 2014, 12:34:35 PM
In Satoshi's paper, it says:
"The receiver generates a new key pair and gives the public key to the sender shortly before
signing. This prevents the sender from preparing a chain of blocks ahead of time by working on
it continuously until he is lucky enough to get far enough ahead, then executing the transaction at
that moment."
But the sender doesn't need the receiver's public key to prepare the blocks. So why this could prevent the sender from preparing a chain of blocks ahead of time?
Is I miss something? Please explain it to me, thanks~
If this can't work, what could prevent the sender from preparing a chain of blocks ahead of time?
"The receiver generates a new key pair and gives the public key to the sender shortly before
signing. This prevents the sender from preparing a chain of blocks ahead of time by working on
it continuously until he is lucky enough to get far enough ahead, then executing the transaction at
that moment."
But the sender doesn't need the receiver's public key to prepare the blocks. So why this could prevent the sender from preparing a chain of blocks ahead of time?
Is I miss something? Please explain it to me, thanks~
If this can't work, what could prevent the sender from preparing a chain of blocks ahead of time?
Jump to: