Re: [Bitcoin-development] Addressing rapid changes in mining power
2011/11/23, Andy Parkins andypark...@gmail.com: Let's abandon the idea of a target difficulty. Instead, every node just generates the most difficulty block it can. Simultaneously, every node is listening for the most difficult block generated before time T; with T being picked to be the block generation rate (10 minutes). A miner could try to obtain more difficulty out of time and cheat its reported datetime (T). Jorge Timón -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
On 2011 November 23 Wednesday, Jorge Timón wrote: 2011/11/23, Andy Parkins andypark...@gmail.com: Let's abandon the idea of a target difficulty. Instead, every node just generates the most difficulty block it can. Simultaneously, every node is listening for the most difficult block generated before time T; with T being picked to be the block generation rate (10 minutes). A miner could try to obtain more difficulty out of time and cheat its reported datetime (T). Just as with the current system. The defence is that on receipt of a block, its timestamp is checked against the node's own clock and averaged network clock. Blocks out of that band are rejected. Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
With the current system, the timestamp can also be cheated, but miners have no direct incentive to do it. With your system, they increase their probability of mining a block by putting a false timestamp. Also, where's the network clock you're talking about? Isn't it the timestamps in the blockchain? 2011/11/23, Andy Parkins andypark...@gmail.com: On 2011 November 23 Wednesday, Jorge Timón wrote: 2011/11/23, Andy Parkins andypark...@gmail.com: Let's abandon the idea of a target difficulty. Instead, every node just generates the most difficulty block it can. Simultaneously, every node is listening for the most difficult block generated before time T; with T being picked to be the block generation rate (10 minutes). A miner could try to obtain more difficulty out of time and cheat its reported datetime (T). Just as with the current system. The defence is that on receipt of a block, its timestamp is checked against the node's own clock and averaged network clock. Blocks out of that band are rejected. Andy -- Dr Andy Parkins andypark...@gmail.com -- Jorge Timón -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
First of all I do agree that a method for adjusting the difficulty in a huge power drop is needed (I don't see it so much in power rises). The current block generation with a fixed difficulty was chosen because it it clear when to adjust and to what target difficulty it has to be adjusted. If we were to use synchronized time windows and select the hardest block it gets incredibly complicated as synchronization is not possible in distributed systems. Even the smallest drift would allow for forks in the chain all over the place. Furthermore the delay in propagation will also cause forks. If 1/2 of the network see one block as the hardest, and for the rest of the network it came too late then we'll have a fork that stays with us quite a while. The block chain is described as a timestamp server in the paper, but it is more of a proof-of-existence before, as the contained timestamp cannot be trusted anyway. Regards, Chris 2011/11/23 Jorge Timón timon.elvi...@gmail.com With the current system, the timestamp can also be cheated, but miners have no direct incentive to do it. With your system, they increase their probability of mining a block by putting a false timestamp. Also, where's the network clock you're talking about? Isn't it the timestamps in the blockchain? 2011/11/23, Andy Parkins andypark...@gmail.com: On 2011 November 23 Wednesday, Jorge Timón wrote: 2011/11/23, Andy Parkins andypark...@gmail.com: Let's abandon the idea of a target difficulty. Instead, every node just generates the most difficulty block it can. Simultaneously, every node is listening for the most difficult block generated before time T; with T being picked to be the block generation rate (10 minutes). A miner could try to obtain more difficulty out of time and cheat its reported datetime (T). Just as with the current system. The defence is that on receipt of a block, its timestamp is checked against the node's own clock and averaged network clock. Blocks out of that band are rejected. Andy -- Dr Andy Parkins andypark...@gmail.com -- Jorge Timón -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
On 2011 November 23 Wednesday, Jorge Timón wrote: With the current system, the timestamp can also be cheated, but miners have no direct incentive to do it. With your system, they increase their probability of mining a block by putting a false timestamp. Also, where's the network clock you're talking about? Isn't it the timestamps in the blockchain? (1) The probability of mining a block is old-think. The probability of mining a block is 100% in my system. Instead, it becomes the probability of your block being the hardest and that requires actual hashing power regardless of the timestamp you write on the block. I could write that my block was generated next year; but I can't fake the hashing power it needs to generate one year's worth of hashes. If chain difficulty were summed correctly (sum(log(difficulty)), I guess), then time makes not the slightest difference anyway. You can issue blocks at any time with any difficulty, and the hardest chain always wins. The block period can be anything, and it is only the block reward that makes it necessary to pick a particular period for block issuing (even that could be worked around I guess with a variable reward, but why bother?). (2) For the network clock; see util.cpp:GetAdjustedTime(). (3) Current clients do have an incentive: more time. The more time they get, the more hashes they can try. The current client already checks the timestamp: main.cpp:CBlock::CheckBlock() // Check timestamp if (GetBlockTime() GetAdjustedTime() + 2 * 60 * 60) return error(CheckBlock() : block timestamp too far in the future); My suggestion only requires that the two hour window be reduced; and a lower limit to be added. Also: while the miners have an incentive to lie about the time, the nodes they broadcast to have an incentive to reject mistimed blocks, so you won't gain much by lying to your peers since your block won't be accepted -- the incentive is therefore removed. Note: my system also prevents an attack that is possible with current bitcoin: recalculating the entire chain. Let's say Visa want to take over bitcoin. They buy enough computing power to significantly beat the current bitcoin network; then they start recalculating the entire block chain; since early blocks were low difficulty, it's not that hard to do. Once they overtake the real chain, they have effectively undone all previous transactions. (I'm not suggesting this is likely; and it's actually mitigated by the hard-coded block hashes). The point is that blocks are only generatable for the time when the rest of the network is willing to add them to the chain. Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
On 2011 November 23 Wednesday, Christian Decker wrote: The current block generation with a fixed difficulty was chosen because it it clear when to adjust and to what target difficulty it has to be adjusted. If we were to use synchronized time windows and select the hardest block it gets incredibly complicated as synchronization is not possible in distributed systems. Even the smallest drift would allow for forks in the chain all over the place. Furthermore the delay in propagation will also cause forks. If 1/2 of the network see one block as the hardest, and for the rest of the network it came too late then we'll have a fork that stays with us quite a while. The block chain is described as a timestamp server in the paper, but it is more of a proof-of-existence before, as the contained timestamp cannot be trusted anyway. These are reasonable objections. My counter is this: Let's view block difficulty as a measure of time, not time itself. The timestamp is merely a convenience for the block. You cannot fake the computing power needed for a particular difficulty; so the hardest chain always wins (note: hardest chain). If I am a miner, I have two choices: (a) try to replace the top block on the current hardest chain (b) try to append to the current hardest chain Either of these is acceptable; but in case (a) I have to generate a more difficult block to replace it; in case (b), at the start of the window, any difficulty is acceptable (however, I'm competing with other miners, so _any_ difficulty won't beat them). The rule then is that you're trying to win the one block reward that is available every 10 minutes; and your peers will be rejecting blocks with timestamps that are lies. Perhaps an example... - I (a node), download the blockchain - The blockchain has N potential heads. Each of those heads has a time, t and a sum_of_difficulty. - The next block reward is going to go to the highest difficulty with t timestamp (t + T) _and_ verified timestamp (i.e. not received more than, say 5 minutes, from its claimed timestamp). - I can choose any head to start generating from, but given that it's the highest difficulty chain that's going to win the next reward (not the highest difficulty block), I will surely pick the most difficult? - A rogue miner then issues a block with a fake timestamp; it actually generated at (t + T + 5) but claims (t + 5). Should I start using that block as my new head? Obviously not, because my peers might decide that it is a lie and reject it because it was received too late, making my work useless. It is in my interest to pick a head that is honest. Resolving forks is easy: - 50 coins every ten minutes only - most difficult chain wins I'm certainly not saying it's a simple change. There are certainly areas I haven't thought about, and could be game-overs; but I do like the idea of there being no target difficulty, and instead the blocks are issued at a fixed ten minute rate (or rather the rewards are). Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
Just brainstorming here, no idea if this would work: - Pick any old block - Create a chain fork by creating simpler blocks on top of your chosen one - The chain will not be accepted by others - At some point you might find an incredibly hard block that makes your forked chain the hardest one in the network - Suddenly all your blocks are valid and you force people to switch to your forked chain If this is possible it would allow you to revoke all transactions and claim all the mined coins since you forked. My point is that the notion of hardest chain is not so simple. The difficulty of invalidating a chain is dramatically reduced with your time window approach, by not requiring a given difficulty, and relying on synchronized time windows. Regards, Chris On Wed, Nov 23, 2011 at 2:13 PM, Andy Parkins andypark...@gmail.com wrote: On 2011 November 23 Wednesday, Christian Decker wrote: The current block generation with a fixed difficulty was chosen because it it clear when to adjust and to what target difficulty it has to be adjusted. If we were to use synchronized time windows and select the hardest block it gets incredibly complicated as synchronization is not possible in distributed systems. Even the smallest drift would allow for forks in the chain all over the place. Furthermore the delay in propagation will also cause forks. If 1/2 of the network see one block as the hardest, and for the rest of the network it came too late then we'll have a fork that stays with us quite a while. The block chain is described as a timestamp server in the paper, but it is more of a proof-of-existence before, as the contained timestamp cannot be trusted anyway. These are reasonable objections. My counter is this: Let's view block difficulty as a measure of time, not time itself. The timestamp is merely a convenience for the block. You cannot fake the computing power needed for a particular difficulty; so the hardest chain always wins (note: hardest chain). If I am a miner, I have two choices: (a) try to replace the top block on the current hardest chain (b) try to append to the current hardest chain Either of these is acceptable; but in case (a) I have to generate a more difficult block to replace it; in case (b), at the start of the window, any difficulty is acceptable (however, I'm competing with other miners, so _any_ difficulty won't beat them). The rule then is that you're trying to win the one block reward that is available every 10 minutes; and your peers will be rejecting blocks with timestamps that are lies. Perhaps an example... - I (a node), download the blockchain - The blockchain has N potential heads. Each of those heads has a time, t and a sum_of_difficulty. - The next block reward is going to go to the highest difficulty with t timestamp (t + T) _and_ verified timestamp (i.e. not received more than, say 5 minutes, from its claimed timestamp). - I can choose any head to start generating from, but given that it's the highest difficulty chain that's going to win the next reward (not the highest difficulty block), I will surely pick the most difficult? - A rogue miner then issues a block with a fake timestamp; it actually generated at (t + T + 5) but claims (t + 5). Should I start using that block as my new head? Obviously not, because my peers might decide that it is a lie and reject it because it was received too late, making my work useless. It is in my interest to pick a head that is honest. Resolving forks is easy: - 50 coins every ten minutes only - most difficult chain wins I'm certainly not saying it's a simple change. There are certainly areas I haven't thought about, and could be game-overs; but I do like the idea of there being no target difficulty, and instead the blocks are issued at a fixed ten minute rate (or rather the rewards are). Andy -- Dr Andy Parkins andypark...@gmail.com -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense.
Re: [Bitcoin-development] Addressing rapid changes in mining power
On Wed, Nov 23, 2011 at 9:38 AM, Christian Decker decker.christ...@gmail.com wrote: At some point you might find an incredibly hard block that makes your forked chain the hardest one in the network Seems to me that's the real problem with any hardest block found in X minutes scheme. If I get lucky and find a really extremely hard block then I have an incentive to keep it secret and build a couple more blocks on top of it, then announce them all at the same time. If the rest of the network rejects my longer chain because I didn't announce the extremely hard block in a timely fashion... then how could the network ever recover from a real network split? A network split/rejoin will look exactly the same. Bitcoin as-is doesn't have the I got lucky and found an extremely hard block problem because the difficulty TARGET is used to compute chain difficulty, not the actual hashes found. --- PS: I proposed a different method for dealing with large hash power drops for the testnet on the Forums yesterday, and am testing it today. -- -- Gavin Andresen -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
2011/11/23, Andy Parkins andypark...@gmail.com: On 2011 November 23 Wednesday, Jorge Timón wrote: With the current system, the timestamp can also be cheated, but miners have no direct incentive to do it. With your system, they increase their probability of mining a block by putting a false timestamp. Also, where's the network clock you're talking about? Isn't it the timestamps in the blockchain? (1) The probability of mining a block is old-think. The probability of mining a block is 100% in my system. Instead, it becomes the probability of your block being the hardest and that requires actual hashing power regardless of the timestamp you write on the block. I could write that my block was generated next year; but I can't fake the hashing power it needs to generate one year's worth of hashes. Well, I meant the probability of your block being the hardest. What a miner can do is hash the block (cheating the timestamp) for 2 more minutes than the rest of the people and then send it to the other nodes. Nodes cannot possibly know when did you hashed the block only by looking at their clock when they receive it, because there's also network latency. (2) For the network clock; see util.cpp:GetAdjustedTime(). 1) This is part of the satoshi client but not the protocol. A miner can rewrite this part of the code and there won't be anything in the chain that contradicts the protocol. 2) I haven't read the code but I'm pretty sure that's not a perfect decentralized clock. I will be more specific. Where's the network clock in the chain (in the protocol)? -- Jorge Timón -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
On 2011 November 23 Wednesday, Christian Decker wrote: Just brainstorming here, no idea if this would work: - Pick any old block - Create a chain fork by creating simpler blocks on top of your chosen one - The chain will not be accepted by others - At some point you might find an incredibly hard block that makes your forked chain the hardest one in the network - Suddenly all your blocks are valid and you force people to switch to your forked chain If this is possible it would allow you to revoke all transactions and claim all the mined coins since you forked. My point is that the notion of hardest chain is not so simple. The above is a problem in either system (mine or current). If I can make a hardest chain, then I have indeed reverted all the existing transactions. Look at CBlock::AddToBlockIndex(), if (pindexNew-bnChainWork bnBestChainWork) if (!SetBestChain(txdb, pindexNew)) return false; If the received block has higher total chain work than the current best chain work; then the new block becomes the head of the best chain. The chain work being calculated like this (I've abbreviated for the email): pindexNew-bnChainWork = pprev-bnChainWork + pindexNew-GetBlockWork() I'm not entirely convinced that this method of totalling chain work is the best (it's a sum of exponentials I think); but that's a different issue. The difficulty of invalidating a chain is dramatically reduced with your time window approach, by not requiring a given difficulty, and relying on synchronized time windows. I don't see that it is reduced; it is the same. Hashes are hashes. A given difficulty isn't required, but a higher difficulty beats a lower difficulty. So whatever the hashing power of the network at that moment, it's used. That makes the chain more secure, not less. Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
On 2011 November 23 Wednesday, Jorge Timón wrote: Well, I meant the probability of your block being the hardest. What a miner can do is hash the block (cheating the timestamp) for 2 more minutes than the rest of the people and then send it to the other nodes. Nodes cannot possibly know when did you hashed the block only by looking at their clock when they receive it, because there's also network latency. True enough; but then the same is true for everyone else. If the window is 2 minutes after the stated time, then everyone _can_ wait until the end of that window. However, they risk their block being rejected by their peers, and their efforts are wasted. In fact, it can be guaranteed by making the accept window zero. There is then no reason to carry on computing after the reward window closes, since you know your peers will reject it. (2) For the network clock; see util.cpp:GetAdjustedTime(). 1) This is part of the satoshi client but not the protocol. A miner can rewrite this part of the code and there won't be anything in the chain that contradicts the protocol. Well yes. What does that matter? It's only a way of calculating an average time. The node can use any clock it wants, as long as the block time is verified by the peers. 2) I haven't read the code but I'm pretty sure that's not a perfect decentralized clock. It definitely isn't. NTP is mentioned in the source as an alternative. I will be more specific. Where's the network clock in the chain (in the protocol)? It's nothing to do with the protocol; it's an individual miner choosing whether to accept or reject a block based on the timestamp it claims, and the current time as the miner sees it. For the sake of compatibility, the clients currently choose to use a community clock as current, as established from the time they receive from peers in the version message (it actually holds offsets between them, which is pretty bad, as a long-connected client will drift). They don't have to, but if miners aren't using time that approximates what their peers are using, under my system, their blocks would be rejected: so an incentive to use that community clock exists. Andy -- Dr Andy Parkins andypark...@gmail.com signature.asc Description: This is a digitally signed message part. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
I can substantiate Gavin's point quite powerfully: a couple months ago I did a search for the hardest block in the network and found a *very **impressive* one: https://bitcointalk.org/index.php?topic=29675.0 That block has a difficulty of **36 billion** when the network had a difficulty of **1.5 million**, which is 24,000 times harder than the target. If we were going by the /actual /hardest chain instead target-based-hardest chain, /then this block produced in July would might still represent the longest chain!/ Yes, that means that whichever miner produced this block, could've held onto it for 2-4 months without doing anything else, and then broadcast it to fork the blockchain from a block produced months ago. That's not theoretical, that's real data in the blockchain and it would be a disaster. -Alan On 11/23/2011 10:09 AM, Gavin Andresen wrote: On Wed, Nov 23, 2011 at 9:38 AM, Christian Decker decker.christ...@gmail.com wrote: At some point you might find an incredibly hard block that makes your forked chain the hardest one in the network Seems to me that's the real problem with any hardest block found in X minutes scheme. If I get lucky and find a really extremely hard block then I have an incentive to keep it secret and build a couple more blocks on top of it, then announce them all at the same time. If the rest of the network rejects my longer chain because I didn't announce the extremely hard block in a timely fashion... then how could the network ever recover from a real network split? A network split/rejoin will look exactly the same. Bitcoin as-is doesn't have the I got lucky and found an extremely hard block problem because the difficulty TARGET is used to compute chain difficulty, not the actual hashes found. --- PS: I proposed a different method for dealing with large hash power drops for the testnet on the Forums yesterday, and am testing it today. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Addressing rapid changes in mining power
But the protocol must have a deterministic way to determine if a block must be accepted or rejected. I don't know what NTP is, but if you can have a perfect distributed clock your proposal may work. 2011/11/23, Andy Parkins andypark...@gmail.com: On 2011 November 23 Wednesday, Jorge Timón wrote: Well, I meant the probability of your block being the hardest. What a miner can do is hash the block (cheating the timestamp) for 2 more minutes than the rest of the people and then send it to the other nodes. Nodes cannot possibly know when did you hashed the block only by looking at their clock when they receive it, because there's also network latency. True enough; but then the same is true for everyone else. If the window is 2 minutes after the stated time, then everyone _can_ wait until the end of that window. However, they risk their block being rejected by their peers, and their efforts are wasted. In fact, it can be guaranteed by making the accept window zero. There is then no reason to carry on computing after the reward window closes, since you know your peers will reject it. (2) For the network clock; see util.cpp:GetAdjustedTime(). 1) This is part of the satoshi client but not the protocol. A miner can rewrite this part of the code and there won't be anything in the chain that contradicts the protocol. Well yes. What does that matter? It's only a way of calculating an average time. The node can use any clock it wants, as long as the block time is verified by the peers. 2) I haven't read the code but I'm pretty sure that's not a perfect decentralized clock. It definitely isn't. NTP is mentioned in the source as an alternative. I will be more specific. Where's the network clock in the chain (in the protocol)? It's nothing to do with the protocol; it's an individual miner choosing whether to accept or reject a block based on the timestamp it claims, and the current time as the miner sees it. For the sake of compatibility, the clients currently choose to use a community clock as current, as established from the time they receive from peers in the version message (it actually holds offsets between them, which is pretty bad, as a long-connected client will drift). They don't have to, but if miners aren't using time that approximates what their peers are using, under my system, their blocks would be rejected: so an incentive to use that community clock exists. Andy -- Dr Andy Parkins andypark...@gmail.com -- Jorge Timón -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-novd2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
