Bitcoin Forum
September 27, 2018, 10:59:28 PM *
News: ♦♦ New info! Bitcoin Core users absolutely must upgrade to previously-announced 0.16.3 [Torrent]. All Bitcoin users should temporarily trust confirmations slightly less. More info.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Broadcasting all headers that are at least 6 blocks deep  (Read 1007 times)
TierNolan
Legendary
*
Offline Offline

Activity: 1190
Merit: 1001


View Profile
November 11, 2014, 05:55:25 PM
 #1

When a miner finds a block, he could broadcast the block header immediately.  It could spread over the network much faster than sending the whole block, but headers aren't forwarded without the block to back them up.

This policy exists due to potential problems with incentives of broadcasting headers. 

If a miner receives the header but not the full block, then he should stop mining on the old block.  Since he doesn't have the new block and doesn't know which transactions were in the new block, he has to mine empty blocks.  This means that miners would have an incentive to wait a while before sending the full block, but they must send the headers as fast as possible.

The policy means that miners don't send off main-chain headers.  This could be useful in a fork situation.  If nodes could see that a large amount of mining power is hashing on an alternative fork, then it shows that there are problems with the system.  Merchants could shutdown their operations.

The current reference code goes into safemode if there is a fork larger than 6 blocks.

This doesn't cover the situation where there is a hard-fork (or a soft-fork with < 50% of the hashing power supporting it).  In that case, miners would simply reject the other fork and so a re-org wouldn't be triggered.

I suggest that headers should be forwarded if

  • It is less than 1008 blocks worth of POW behind the main chain
  • The header has at least 6 headers built on top of it

The first rule prevents spamming with low difficulty chains.    The second rule blocks the withholding attack.  By the time the block has 6 blocks on top of it, the block would have been forwarded anyway.

The advantage is that it allows the entire block header tree to be forwarded.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
1538089168
Hero Member
*
Offline Offline

Posts: 1538089168

View Profile Personal Message (Offline)

Ignore
1538089168
Reply with quote  #2

1538089168
Report to moderator
1538089168
Hero Member
*
Offline Offline

Posts: 1538089168

View Profile Personal Message (Offline)

Ignore
1538089168
Reply with quote  #2

1538089168
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1538089168
Hero Member
*
Offline Offline

Posts: 1538089168

View Profile Personal Message (Offline)

Ignore
1538089168
Reply with quote  #2

1538089168
Report to moderator
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2520
Merit: 1514



View Profile
November 11, 2014, 11:22:43 PM
 #2

Seems overly complicated considering that little that existing implementations due today to deal with weird cases. I'd be more interested if there were any evidence of implementations making .. well. really.. almost any effort to handle exceptional cases like this usefully.  (Bitcoin-qt does something more than nothing but only very slightly more than nothing; and I've seen no evidence so far that it does any good... including cases where services were running bitcoinds on faulty hardware that ended up forked, and still failed to respond at all to it.)

But, at the same time, I do agree that would address the goals there. Just given the environment today, it may not be worth the additional implementation complexity and risks. This may change, I'd certainly like to see better reactions to weird cases.

Bitcoin will not be compromised
TierNolan
Legendary
*
Offline Offline

Activity: 1190
Merit: 1001


View Profile
November 12, 2014, 01:02:15 AM
 #3

Seems overly complicated considering that little that existing implementations due today to deal with weird cases.

I don't think it is that complex. 

If a block or header is received that extends the tree, then you scan back 6 blocks and forward the block header to all peers that haven't that header.

It wouldn't be necessary for the main chain, since those blocks/headers should have already been forwarded.

Quote
and I've seen no evidence so far that it does any good... including cases where services were running bitcoinds on faulty hardware that ended up forked, and still failed to respond at all to it.)

Well, that is partly a separate issue.

1LxbG5cKXzTwZg9mjL3gaRE835uNQEteWF
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!