Developing a minimum viable fork based on BU

[freetrader]

Hi all,

I'm opening this thread to discuss requirements and design for a minimum viable hard fork client based on Bitcoin Unlimited, in order to move forward with Bitcoin on-chain scaling.

BU seems to have overwhelmingly strong support as the base client for such a fork [1].

Previously, I formulated some user requirements that I could see as being shared across MVF implementations.
I will now continue work on elaborating the corresponding system and software requirements, and then the design, for the BU branch.

This is an invitation to all interested parties to participate in that process.
Coding of an MVF-BU implementation may proceed in parallel, for the requirements/design aspects which are completed to a sufficient degree.

[1] https://www.reddit.com/r/btcfork/comments/52purc/repost_which_client_do_you_want_btcfork_to/

 

[freetrader]

One of the goals that I have in the back of my mind with the MVF specifications is that it should hopefully remain broadly possible for MVF implementations to remain "compatible" with each other, so that one could have various clients participating on a common hard fork chain.

This means things like the trigger condition and network separation should be coordinated so that MVF's could move to a common post-fork network and build on the same spun-off blockchain.

 

[freetrader]

System requirements for MVF-BU have been completely (*) drafted:

https://github.com/BTCfork/bitcoinfork-collaborative-spec/blob/unlimited/requirements.md

Some of the user requirements were also adapted slightly, based on specific characteristics of BU.
More detailed S/W requirements + start on design doc is next.

If anyone has any review comments, I'd be happy to discuss them here, on Reddit, or leave them on GitHub as issues or PRs.

(*) actually, there is one user requirement (and system requirement) that I would add, but I'd like to see if anyone else suggests it

780e767ab497e7a7c74a182dfaf7cafc8af9af854eead4c391555d9778822a0f

 

[79b79aa8]

i have a question that has perhaps already been amply discussed, but here goes anyways . . . how crucial is it to implement a HF before segwit activates? or is MVF deployment largely independent of this issue?

 

[freetrader]

Good question. The trigger-related requirement of the MVF currently states:

The fork shall trigger at a specified block height or upon
SegWit activation (95%), whichever is reached first.

So from a user perspective, I'd say the MVF would have partly failed to achieve this requirement.
However, if it does not release before SW activates, it still has a few options:

1. release without SW support based on current SW-affected blockchain (turning SW transactions into open season)
   
2. release with SW support (major changes required) based on current SW-affected blockchain, i.e. just upgrade the blocksize etc. but keep SW
   
3. release without SW support and based on a pre-SW blockchain snapshot at SW activation time or before (fork retroactively)

Right now none of these options really appeal to me. Still, you're right that it should be considered, because it's possible that SW activates before an MVF or other viable HF is deployed.

 

[79b79aa8]

thanks for the answer . . .

i'd say (3) militates against adoption of the fork (impossibly hard to convince those who have transacted to revert their activity). meanwhile, (2) seems to defeat an important purpose of forking, i.e., to avoid the omnibus.

as for (1) . . . it still leaves open some options. for example, would the client have no SW support but still provide some other fix for transaction malleability, and hence be (in principle) LN compatible? this would probably be required to compete against core.

i had to miss out on some conversations over the past few weeks, i apologize if this has been discussed already (where should i look?).

 

[freetrader]

Well, we've discussed some of the implications of (1)-(3) on the BTCfork slack and maybe other places (like /r/btcfork), but I'm finding it hard to keep up with conversations myself ;-)

What has not been discussed sufficiently is contingency plans in case of no HF client being ready to activate at SegWit activation or prior to that, so I think the question you raised is still very much current.

I agree with your assessments btw, but I don't necessarily see a TM fix as immediately needed in the first hard fork. I would very much like to see Tom Zander's flexible transactions proposal tested and possibly forked in afterwards in an upgrade release. OTOH, if someone thinks it's ready and can be verified sufficiently in time for the first HF ... then I would say go ahead and produce a HF with that included.
I do agree that TM (among other things) needs to be ensured in future in order to go head to head with Core on support for LN and similar projects. But if we can't upgrade the blocksize a fair bit (and not just the small increase planned by SW) , those projects will also find themselves in straightjackets and non-SW use of Bitcoin will dwindle / move to other currencies.

 

[satoshis_sockpuppet]

Good work.

Maybe I would express MVHF-BU-SYS-REQ-5 slightly different:
Instead of

Upon triggering, the system shall cleanly separate from
the current Bitcoin network and prevent as much
unnecessary processing as possible on both sides.

something like this:

Upon triggering, both chains shall be clearly distinguishable and separated from each other, to [...]

The current formulation makes it easier to smear it as an Altcoin imho.

But I'm just nit-picking.

 

[freetrader]

@satoshis_sockpuppet : that's a good suggestion, and it goes toward the direction of the "one user requirement (and system requirement) that I would add" (very warm)

 

[satoshis_sockpuppet]

@freetrader
"The forked blockchain shall (still) be called Bitcoin"?

 

[freetrader]

Nah, that's not something we have sufficient control over

 

[freetrader]

@satoshis_sockpuppet : Is this fomulation ok ?

Upon triggering, the system shall ensure that both chains are clearly distinguishable and their networks separated from each other, to prevent as much unnecessary processing as possible on both sides.

I changed the wording a little to include the 'networks' aspect and 'the system shall' to indicate that some action needs to be performed to get into that state.

 

[satoshis_sockpuppet]

Sounds good!

 

[freetrader]

Ok, that's done.
And I've resolved the "missing requirements" puzzle

echo "ensure that the fork client is distinguishable from the non-forked client to the user, both visually and how it identifies over the network" | sha256sum

 

[satoshis_sockpuppet]

@freetrader Just let the client play "Looking for freedom" every time it starts, people will know they started the right client.

 

[freetrader]

@satoshis_sockpuppet : it must do so over the PC speaker though, so that it can be heard in datacenters all over

 

[freetrader]

For review - added SW requirements and traceability for client identification as MVF-BU (REQ-11):

https://github.com/BTCfork/bitcoinfork-collaborative-spec/pull/19

These "identify yourself clearly everywhere" requirements were not fulfilled completely for hardfork_prototype_0 - stuff like window titles etc. was not done 100%.

For the 'design' part of this, I envisage that 'Bitcoin Unlimited' will retain the 'Bitcoin' part (that's vital IMO) and turn into 'Bitcoin MVF-BU' for now.

SW-REQ-11-x were drafted w/o looking at the code, just looking at GUI and from memory about things I changed for HFP0. I'm Interested if I missed any places where the client should ID itself accurately.