[bitcoin-dev] Pre-BIP Growth Soft-hardfork

[bitcoin-dev] Pre-BIP Growth Soft-hardfork

[Luke Dashjr]

Here's a draft BIP I wrote almost a year ago. I'm going to look into revising 
and completing it soon, and would welcome any suggestions for doing so.

This hardfork BIP aims to accomplish a few important things:
- Finally deploying proper merge-mining as Satoshi suggested before he left.
- Expanding the nonce space miners can scan in-chip, avoiding expensive
  calculations on the host controller as blocks get larger.
- Provide a way to safely deploy hardforks without risking leaving old nodes
  vulnerable to attack.

https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki

Luke

Re: [bitcoin-dev] Pre-BIP Growth Soft-hardfork

[Tier Nolan]

[-- Attachment #1: Type: text/plain, Size: 2988 bytes --]

This is a specific implementation of the "nuclear option" soft fork (or
"firm-fork").

The problem with any hard-fork (like) change is that there is an incentive
to add as much as possible and then the process gets bogged down.

Since the POW is based on the header 1, you could make header 3
expandable.  This would allow adding new fields later.

This could be used for other block commitments.  This would save having to
make the merkle tree a sum tree immediately.  At a later time, the sum-tree
root could be added. (I think you also need to commit the path to the first
entry in the sum-tree, in order to get compact proofs).  There could be
separate sum-trees for each counter (sigops, block size, tx count, sighash?)

Having a dedicated hard fork and soft fork counter is a good idea.  There
should also be a field for parallel soft forks.  Incrementing the soft fork
counter could set the bitfield soft forks back to zero.  Ideally, each soft
fork would have a yes and no bit.  If > 50% vote No, then it fails adoption.

The effect of this change is that nodes react to hard forks by stalling the
chain.  The hard fork counter means that the new rules could be that nodes
should do that going forward for all new hard forks.

- soft fork (bitfield or count) => warn user that a soft fork has happened
- hard fork count increase => warn user that update is required and don't
process any more blocks

This means that header3 should be kept as simple as possible.

   - 2 bytes: hardfork block version
   - 2 bytes: softfork block version
   - 4 bytes: softfork bitfields
   - 32 byte: hash(header4)

Header4 and everything else in the block could be changed when a hard fork
happens.  The merged mining rules and header3 would be fixed.

I think confirmation counts should be based on even numbers, i.e. 3800 of
4000, but that is an aesthetic issue and doesn't really matter.

A section on recommendations for the different client types would be useful.

If 1000 of the last 2000 blocks are votes for a hard fork, then warn the
user that a hard fork is being considered

If 4000 of the last 4463 blocks are votes for a hard fork, then warn the
user that a hard fork is likely to occur within the next few days

If a hard fork happens:

- shut down transaction processing
- inform the user that a hard fork has happened

Non-upgraded miners could blacklist the hard forking block and keep mining
on their own chain.  Their chain would never reach the threshold to trigger
the hard fork.  It would max out at 4323 blocks of the last 4463.

Ironically, if users did this, it would defeat some of the benefit of using
the hard fork field.

Users should definitely be given the option of accepting or rejecting the
hard fork.  Otherwise, miners can hard-fork at will, which isn't desirable.
<https://www.avast.com/sig-email> This email has been sent from a
virus-free computer protected by Avast.
www.avast.com <https://www.avast.com/sig-email>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

[-- Attachment #2: Type: text/html, Size: 3968 bytes --]

Re: [bitcoin-dev] Pre-BIP Growth Soft-hardfork

[jl2012]

This looks very interesting. The first time implementing it might be more
painful but that will make subsequent hardforks a lot easier.

Do you think it's good to include the median timestamp of the past 11 blocks
after the block height in coinbase? That would make it easier to use it as
activation threshold of consensus rule changes.

For the witness commitment, it will also be treated as a merge mined
commitment?

It is also good to emphasize that it is the responsibility of miners, not
devs, to ensure that the hardfork is accepted by the supermajority of the
economy.


-----Original Message-----
From: bitcoin-dev-bounces@lists.linuxfoundation.org
[mailto:bitcoin-dev-bounces@lists.linuxfoundation.org] On Behalf Of Luke
Dashjr via bitcoin-dev
Sent: Sunday, 7 February, 2016 17:53
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Pre-BIP Growth Soft-hardfork

Here's a draft BIP I wrote almost a year ago. I'm going to look into
revising and completing it soon, and would welcome any suggestions for doing
so.

This hardfork BIP aims to accomplish a few important things:
- Finally deploying proper merge-mining as Satoshi suggested before he left.
- Expanding the nonce space miners can scan in-chip, avoiding expensive
  calculations on the host controller as blocks get larger.
- Provide a way to safely deploy hardforks without risking leaving old nodes
  vulnerable to attack.

https://github.com/luke-jr/bips/blob/bip-mmhf/bip-mmhf.mediawiki

Luke
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev