|
Title: Hacking the fork Post by: yokosan on May 14, 2013, 08:11:57 PM First, read this http://culubas.blogspot.co.uk/2011/05/timejacking-bitcoin_802.html
What are your thoughts on executing a variation of this attack while the fork is in progress? Screw up the time, screw up the fork. Title: Re: Hacking the fork Post by: mustyoshi on May 14, 2013, 08:17:56 PM It would be interesting if somebody did this to all non BTCGuild mining pools just to push their effective hashing power to over 51% to cause trouble. But this could be very easily fixed by forcing the miners to use system time.
Title: Re: Hacking the fork Post by: gmaxwell on May 14, 2013, 09:31:30 PM Sorry, this is confused. The rule enforcement behavior is a pure function of the chain and only governs the acceptability of blocks in the self-same chain. A nodes time is utterly irrelevant beyond determining what it will put in its own blocks.
Title: Re: Hacking the fork Post by: leijurv on May 15, 2013, 02:54:50 AM A nodes time is utterly irrelevant beyond determining what it will put in its own blocks. But what if the node isn't a miner? The node's time is used to make sure that blocks aren't more than 2 hours in the future, right? The node doesn't check the difference between the current block that it's verifying's timestamp and the immediately previous block's timestamp.Title: Re: Hacking the fork Post by: gmaxwell on May 15, 2013, 03:38:52 AM But what if the node isn't a miner? The node's time is used to make sure that blocks aren't more than 2 hours in the future, right? The node doesn't check the difference between the current block that it's verifying's timestamp and the immediately previous block's timestamp. And? The moon is not made of cheese.Title: Re: Hacking the fork Post by: leijurv on May 15, 2013, 02:35:14 PM But what if the node isn't a miner? The node's time is used to make sure that blocks aren't more than 2 hours in the future, right? The node doesn't check the difference between the current block that it's verifying's timestamp and the immediately previous block's timestamp. And? The moon is not made of cheese.Title: Re: Hacking the fork Post by: gmaxwell on May 15, 2013, 03:08:34 PM Er... I wasn't saying that the moon was made of cheese. You said that the node's time is only used for mining blocks; it's also used in verifying blocks. Yes, sure, thats true and not at all relevant here for the subject of the thread.Why don't you try writing out the particulars of what you're thinking in greater detail than "Collect timestamps. ???. Hax!" and perhaps you'll see why? Title: Re: Hacking the fork Post by: leijurv on May 16, 2013, 12:33:51 AM Er... I wasn't saying that the moon was made of cheese. You said that the node's time is only used for mining blocks; it's also used in verifying blocks. Yes, sure, thats true and not at all relevant here for the subject of the thread.Why don't you try writing out the particulars of what you're thinking in greater detail than "Collect timestamps. ???. Hax!" and perhaps you'll see why? Title: Re: Hacking the fork Post by: gmaxwell on May 16, 2013, 04:30:48 PM Okay. The OP linked to a page which was all about timing attacks and how nodes used their time to verify blocks, and how to skew that. Then he suggested doing it while a fork was in progress. Which would accomplish absolutely nothing. It's a bag of facts with no purpose, this was why I said the moon wasn't made of cheese. You are not a llama, so where is my million dollars? One thing does not follow from the others. A bunch of truthful preconditions doesn't make the following text sensible.Quote Then you said that this was confused, and said that node times were only used in "what it puts in it's own blocks", which wasn't correct (as you just agreed), which I then pointed out. No, my response was in context. For the purpose of the hard fork rule a node's time is irrelevant except for what it puts in its own blocks. The hard fork rule is evaluated only based on the data in the chain ("blocks with timestamps <X are only allowed to be <Y in size") not based on the receiving node's time.Title: Re: Hacking the fork Post by: leijurv on May 16, 2013, 08:13:32 PM Okay. The OP linked to a page which was all about timing attacks and how nodes used their time to verify blocks, and how to skew that. Then he suggested doing it while a fork was in progress. Which would accomplish absolutely nothing. It's a bag of facts with no purpose, this was why I said the moon wasn't made of cheese. You are not a llama, so where is my million dollars? One thing does not follow from the others. A bunch of truthful preconditions doesn't make the following text sensible.Quote Then you said that this was confused, and said that node times were only used in "what it puts in it's own blocks", which wasn't correct (as you just agreed), which I then pointed out. No, my response was in context. For the purpose of the hard fork rule a node's time is irrelevant except for what it puts in its own blocks. The hard fork rule is evaluated only based on the data in the chain ("blocks with timestamps <X are only allowed to be <Y in size") not based on the receiving node's time.I see. You were referring to the hard fork rule and not to the linked page. I misunderstood, sorry. |