Author

Topic: Hacking the fork (Read 1186 times)

member
Activity: 63
Merit: 10
Vires in Numeris
May 16, 2013, 03:13:32 PM
#10
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
Oh.
I see. You were referring to the hard fork rule and not to the linked page.
I misunderstood, sorry.
staff
Activity: 4284
Merit: 8808
May 16, 2013, 11:30:48 AM
#9
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
member
Activity: 63
Merit: 10
Vires in Numeris
May 15, 2013, 07:33:51 PM
#8
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. Huh. Hax!" and perhaps you'll see why?
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. 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. Then you said that the moon wasn't made of cheese...
staff
Activity: 4284
Merit: 8808
May 15, 2013, 10:08:34 AM
#7
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. Huh. Hax!" and perhaps you'll see why?
member
Activity: 63
Merit: 10
Vires in Numeris
May 15, 2013, 09:35:14 AM
#6
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.
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.
staff
Activity: 4284
Merit: 8808
May 14, 2013, 10:38:52 PM
#5
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.
member
Activity: 63
Merit: 10
Vires in Numeris
May 14, 2013, 09:54:50 PM
#4
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.
staff
Activity: 4284
Merit: 8808
May 14, 2013, 04:31:30 PM
#3
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.
sr. member
Activity: 287
Merit: 250
May 14, 2013, 03:17:56 PM
#2
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.
hero member
Activity: 700
Merit: 500
May 14, 2013, 03:11:57 PM
#1
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.
Jump to: