What is BU's stance on SegWit?

[freetrader]

Is there already an official BU stance on SegWit, or someone planning to create a BUIP for it?

Reason I'm asking is I am thinking about compatibility in the case that the SegWit soft-fork on Core happens while Core is still dominant...

My guess is once this happens, BU would implement SW since

a) it has received widespread recognition as being a useful idea (incl. from Gavin) and no fatal security flaws in the concept discovered YET
b) it would probably be in BU's interest to provide full validation going into the future, which means it would need to understand the SegWit data
c) once SegWit has appeared, it is probably not going away again due to tidal wave of adoption

Interested to hear your thoughts on this!

 

[theZerg]

Right now we plan to periodically rebase off of core so if no BUIP is issued we'll track core.

Emotionally I have a big issue creating ANYONECANPAY txns and hoping miners don't collude to steal them. But intellectually I think the likelihood is very low. So if there is any modification to be made it could be to not generate txns in the new format... even tho we understand them.

 

[Wary]

IMO, SegWit is a bad idea.
Why?

1. Because it is a change.
Money is about stability. Any change in money, by default, decreases their projected value ("If they can change this one thing, what would stop them from changing any other thing? What would protect me from slippery slope? No, I'd better sell them until it's too late").

What's more, it is big change and it is sudden change. Which means your store of value may not deteriorate slowly, giving you chance to liquidate it, but may crash in one minute, taking all your savings with it. Who would store their hard-earned money in such value store?

2. Because it adds complexity.
Any extra complexity, by default, is bad. It must bring some serious benefits to compensate the damage it may cause, and 50% effective block increase, in some distant future, is not a serious benefit.

To be more specific, what this extra complexity brings:
a) More chances of bugs (not just in current code, but in any future code that will be based on it).
b) Bigger attack surface.
c) Bigger monopolization. The more complex is a protocol, the less people could implement it properly and efficiently. If only one team is capable of creating and maintaining bitcoin client, your bitcoins are not yours anymore, they are theirs (or government's).

 

[solex]

Nice to see you here Wary.

SegWit can theoretically bring enough benefits to outweigh the big complexity drawbacks that it also has. However, you are absolutely right that there are many considerations. It is not a substitute for a simple block limit increase which can have subchains and IBLT bolted on leaving capacity space for many years.
What Core are doing, trying to rush it, is irresponsible, and makes it more likely that they overlook a crucial factor in the a,b,c you describe.

 

[TrevinHofmann]

SegWit seems to have a lot of potential benefits. It solves transaction malleability. It creates a new class of nodes somewhere between SPV and full, which might be desirable.

However, it's a complicating overhaul to the structure of the block chain. I would like to see significant testing before it is merged into Bitcoin. It is not something that should be pushed out "ASAP".

Emotionally I have a big issue creating ANYONECANPAY txns and hoping miners don't collude to steal them. But intellectually I think the likelihood is very low.

This was a bit concerning for me, also. I'm not at all convinced that a soft fork is the best way to implement SegWit.