Will BU support segwit?

[Chronos]

As you may have seen, Wuille just submitted a PR for segwit. https://github.com/bitcoin/bitcoin/pull/7910

Has BU taken an official stance on whether or not it will support this feature?

 

[theZerg]

this is certainly something that must be voted on...

 

[Inca]

I think it should to retain network relevance. BU should strive to be the best client out there even if we don't agree with all changes suggested by Core ATM. Once there is more client / node diversity then Core will not be able to keep steamrolling soft forks onto the network. True decentralised development and consensus will then be upon us, but we are not there yet.

 

[Chronos]

I don't think I'm a "voting member" (if such a thing exists) but I do think segwit should be supported so that BU nodes can properly validate segwit transactions.

 

[bitcartel]

There are a bunch of BIPs involved - are they all or nothing? Can some BIPs stand on their own merit? Can the proposed solution to transaction malleability be implemented independently of economic decisions such as offering a fee discount for witness (i.e. signature) data? Or script versioning?

 

[solex]

If we stick to a 3-monthly vote then a BUIP to handle SegWit could be voted on or about 29th July.

If SegWit is to be supported there is scope for change such as eliminating the discount so that per byte cost of tx remains consistent between base and witness data.

We will have a good idea about the rate of take-up of this change by July. Whatever happens, we can't allow BU nodes to become lobotomized by soft-forking stealth.

 

[adamstgbit]

i think the vote should happen now and BU should aim to try and sort out exactly how it will handle segwit before or shortly after segwits release.
July might be a little late, i suspect segwit will be ready mid may.

 

[solex]

@adamstgbit
Someone needs to write up a BUIP for Segwit ideally laying out a few options e.g. take it as is or specify some changes. The final deadline is its activation date which is unknown. In the PR Wuille writes:

There are certainly some items left to do:

• Incorporate changes to BIP145/BIP9 when finalized (see bitcoin/bips#365)
• Define a deployment time for testnet
• Seed nodes that provide segwit-capable peers
• Do tests in a mixed network of upgraded and non-upgraded nodes
• Remove segnet from mainline merge
• Define a deployment time for mainnet
• Per-transaction caching of sighashes to fix the O(n^2) sighash problem (see sipa#70)

(my bold emphasis)

So he is not even specifying deployment details yet. BS are probably still mulling over the conundrum that the usual 95% enforcement may not be reached when a hold-out rump of miners can stall it. The battle for deployment may continue into next year.

As long as BU has a release which is SegWit compatible by the time SegWit hits say 50% of miner take-up, then we should be OK to protect our BU users such that their full nodes can upgrade and remain fully functional.

 

[adamstgbit]

@solex
right, i had not considered the time it would take to achieve that 95%
so it would appear there is no rush.

 

[TrevinHofmann]

I would have BU allow the user to choose whether to vote for or against SFSW (soft-forked segregated witnesses), with voting against it as the default. To me, maximizing a user's control over their node is a core principle of BU.

If the SFSW support threshold is reached, users should be able to configure their node as either a fully-validating node (supporting SFSW) or a partially-validating node (ignoring SFSW). However, the node should not be usable for mining unless SFSW support is enabled. A network-supported soft fork is not optional for miners. They would risk creating blocks that are rejected by the network.