BUIP037: Hardfork SegWit

[adamstgbit]

@deadalnix

It doesn't do anything about block size. If it did, that'd be specified. SegWit never was about block size until luke-jr figured out it could make it as a soft fork by using a block extension - which they then decided to sell as a block size increase. And everybody at core cheered, but everybody else was left wondering who the fuck their dealer was.

yes I found myself wondering who there dealer was when I understood how the "effective block size incress" was achieved.
I'm glad this proposal does not do this "block weight" + hard coded sig discount bullshit.

It is a hard fork, so I don't think this questions makes any sense.

i was referring to the core-segwit, a soft fork which requires 95% backing... if they require everyone to upgrade what's the point of creating code detb for backward compatibility, right.

That wouldn't be the right tradeof IMO. Some parts of the SF SegWit are just soft fork kludge, such as the fact that you require an input script, but it's empty because data are in the witness fields,
...
In addition, SegWit format is not very extensible

I understand. thanks.

I don't want to be harsh, but you seem to have an opinion while you clearly lack the background to understand the problem

I understand enough to vote for or against this BUIP as a member.
I trust you have put in the work to come up with the best proposal you can, but for me to feel comfortable voting, i need to ask a few really bad questions and try to gain a bit more understanding, before i cast my vote.

 

[deadalnix]

Hey, there is no problem asking questions !

This comment was more of a response to @Christoph Bergmann who seems to expect the BUIP to be a tutorial on SegWit. This wouldn't be appropriate for the BUIP to be such a thing.

I think it is very important to understand a problem before making a decision, or simply chose to do something else. For instance, I'm no crptygraphy expert. I certainly know more than average Joe, but if you ask me about the math behind elliptic curve, you'll quickly find my limitations. That's why you'll see me mostly asking questions on these subjects. I would very much appreciate if we could avoid falling into the "I don't get it, but I do/don't like it" trap.

 

[Mengerian]

I really like this BUIP, I think of it as "segwit done right"

Although I still don't like the name "hard fork segwit", I don't think it really makes sense. It is a different proposal from segwit, so I think the name leads to confusion. And it is not descriptive, the witness is not really "segregated".

In terms of hard fork/soft fork, the way it is done makes sense. We want to make a better transaction format, not shoehorn something in with a soft fork.

If it is implemented in BU, I think it would make sense to give users the choice of whether they want to activate the new transaction format, we shouldn't pressure them into it like Core is doing with segwit.

Also, we would want to wait until after a block size increase before releasing this new transaction format.

In terms of actually implementing it, do you have a plan for that @deadalnix? How much coding effort do you think it would take? Should there be funding allocated to get it implemented?

 

[HostFat]

Is it possible to release a Litecoin version of this? (I'm not invested in Litecoin currently)

 

[Christoph Bergmann]

This comment was more of a response to @Christoph Bergmann who seems to expect the BUIP to be a tutorial on SegWit. This wouldn't be appropriate for the BUIP to be such a thing.

I think it is very important to understand a problem before making a decision, or simply chose to do something else

but you seem to have an opinion while you clearly lack the background to understand the problem, as your question reveals. I suggest you proceed in order, document yourself, learn about the problem, evaluate the solution and then form an opinion, rather than starting with your opinion and working back from there.

I will not take this discussion to this trollish level. You made a BUIP. Accept that it is discussed. I askes several question, explicitly not technical, but rather conceptual and political, and the only helpful answer is that I should read the Medium-article and / or STFU.

So, let me get it again. As a member of BU I see it as my duty to vote about BUIPS in regards to my vision for BU. I don't want to concern troll or something like this, but I don't think this proposal is conceptionally / politically wise.

Why? The most serious reason is that it makes BU a "we do the hardfork" team[*]. Which has several downsides:
- using a hardfork as a prefered mechanism of upgrading threatens Bitcoin's immutability and it's digital gold status. (we had this discussion on slack and most people here agreed) This is not only unwise for Bitcoin itself, it i a thread for the public image of BU and its acceptance.
- you need an immense amount of work to enforce such a hardfork in the market and all actors. Who should do this work? BU for sure has not the ressources to coordinate.
- chances are high that it will never get the love in the ecosystem its needs to be successfull and thus wasted your time
[**]

So. The essence is: This proposal could be politically unwise and the chance it ever get activated is low. Thus my question is: What is so important in doing it SegWit as a hardfork to outweight this disadvantages? In my oppinion you should need to deliver a very strong reason to get the support of BU members.

And no, a link to medium and the claim that I don't know what I'm talking about are no answer on my question!

Also, if you know good reasons, and this reasons are acceptable to justify the work, you still need to answer another question: How do you plan to enforce the upgrade? Do you want to combine it with the first BU-fork? Unfortunately the activation and the acceptance of this proposal is way more important than the technical details.

[*]
Somehow BU is his, by creating a way to soft-hardfork to bigger blocks in line with the preferences of the ecosystem. But preparing the next hardfork while the first is not activated is not wise and can threaden the acceptance of the first, which is what is needed. So conceptually I'm all for fighting for this hardfork but be vey carefull with further changes; at best making them non-fork, but effectful like xthin.

[**]
There are some more reasons, e. G.: SegWit is a fundamental change of Bitcoin. It might be acceptable as an add-on. Doing it as a hardfork is like building a new bitcoin.

 

[Christoph Bergmann]

To clearify why I'm against hardforking SegWit:

As some of you might know, I'm in good contact with one exchange; and as you might have noticed, no exchange has by now openly supported Unlimited. The major reason for this is imo that hardforks means work for exchanges and the risk to loose customer's funds. Period. Hardforks are a disruption of business with several hard to predict scenarios and risks. No business likes this and don't wants this if it is not really needed. You can close your eyes, say, that core manipulated exchanges, that they need to learn, that this is not true, that a hardfork is no risk, and so on. Fact is that exchange don't like hardforks.

From all the resistance against raising the limit the risk of a hardfork is the only thing I accept and the exchanges support.

It might be acceptable for exchanges and so on if a Hardfork does something we need to enrich the bitcoin markets, a softfork can't achieve, like onchain scaling, but it is likely not acceptable for them if it is a feature not obviously needed which can be done with a Softfork (like SegWit).

Bitcoin Unlimited has a lot of work to do to make exchanges and so on to accept Unlimited. This proposal risks to seriously hinder the success of this work, as it, in general, risks to untergo the acceptance of Bitcoin Unlimited as a serious alternative to Core by large parts of the bitcoin economy.

So, as I said, you need to deliver very good reasons why we need this.

I really don't want to offend you, and I'm extremely sorry to start a fight with you about this, as I have a deep and high respect for your knowledge and consider you as the best asset Bitcoin Unlimited has got in the last 12 month. But for me this hardfork is not the way to go. At least for now. Maybe the time will come after Unlimited suceeded in persuading the ecosystem for its modell and after we learned how Hardforks play out.

 

[deadalnix]

@Christoph Bergmann Once again you let me nothing to respond to. You claim the benefit aren't stated, which is not true. If you don't understand some of these benefit, I suggest you ask questions. If you disagree with some of these benefits, please explain why.

In absence of this, you aren't providing value. Really, everythign is there:

Thus my question is: What is so important in doing it SegWit as a hardfork to outweight this disadvantages? In my oppinion you should need to deliver a very strong reason to get the support of BU members.

These are stated, please discuss them.

How do you plan to enforce the upgrade? Do you want to combine it with the first BU-fork?

I'm quoting this because this is typical trolling. I'm not sure you are doing it on purpose, but definitively you are doing it. See question 1, this is school case example of concern trolling. You aren't discussing the topic but rather something else, in this case activation. If this is deemed a good idea, we can work on activation, if not, that's just wasting time.

The second question is a form of "what if you did that very stupid thing, that'd be a problem wouldn't it ?" aka poisoning the well. Nowhere in the proposal was activating this with the block size hard fork was proposed, and, therefore, what the hell are you talking about ?

Unfortunately the activation and the acceptance of this proposal is way more important than the technical details.

This is disprove by the fact that the BU block size increase is the one getting the most traction, and also the one that did not specify this. This runs contrary to any real world facts out these, and, therefore, can be dismissed.

But preparing the next hardfork while the first is not activated is not wise and can threaden the acceptance of the first, which is what is needed.

This is maybe one of the only interesting piece in all this. I understand your concern here, but, on the other hand, SegWit solves real problems, such as quadratic hashing and malleability - even if it does so partially. The ecosystem is wondering what are BU's plan regarding this.

There are some more reasons, e. G.: SegWit is a fundamental change of Bitcoin. It might be acceptable as an add-on. Doing it as a hardfork is like building a new bitcoin.

This is not an argument, it is just asserted. And it is false. Doing SegWit as a hard fork doesn't create 2 classes of transaction, 2 types of UTXO and alike. SegWit as a hard fork is much less creating a new bitcoin than SegWit as a soft fork. In addition, the fact that Satoshi added version fields in transaction is a pretty good indicator that he planned for new transaction format to be created.

Now the second post.

It might be acceptable for exchanges and so on if a Hardfork does something we need to enrich the bitcoin markets, a softfork can't achieve, like onchain scaling, but it is likely not acceptable for them if it is a feature not obviously needed which can be done with a Softfork (like SegWit).

Well this is completely factually incorrect. First block size can be increased as a soft fork, by committing a bock extension in the coinbase, and second, malleability and quadratic hashing cannot be solved completely via a soft fork - as you'd know if you'd read the article I provided you earlier about SegWit.

There is no shame in not knowing. There is in stating your incorrect understanding of the situation as fact. I told you you were doing this earlier, I don't think this is acceptable, and you are doing it again. What can I say. Please inform yourself before making your mind on something or asserting you opinion of it. An uninformed opinion is not valuable and you shouldn't expect me to value it.
[doublepost=1484569844][/doublepost]

How much coding effort do you think it would take? Should there be funding allocated to get it implemented?

The biggest coding effort would be the BUIP039 part. The serialization/deserialization isn't that hard, no more than a few day should be sufficient. Semantic is pretty much the same as before, so same thing, a few days.

On the other hand, the BUIP039 is very much consensus related and will need some serious testing going on - unit tests clearly aren't sufficient here. This is probably 2 weeks to a month of work (I'd say 2 weeks, but you know how devs are, and I'm the same, so table on a month), maybe more for people to be confident it works as expected.

 

[Christoph Bergmann]

plz, take out the hostility.

Your post is again to most parts an insult to me and you again say that I don't understand the technical aspects. While I explicitly don't talk about technology.

Also you completely misunderstand / ignore the points I made in my second post about the acceptance by exchanges and other economical entities. As I don't have the impression that anything I wrote reached you, this discussion makes no sense and I will stop my contribution to this thread with my conclusion:

I don't think this proposal has a chance to get accepted by the ecosystem in the midterm future. It is not only a waste of time to build someting that will never be used; it can be do serious harm to the public acceptance of Bitcoin Unlimited as a whole.

Maybe it will be a good ideal later, but not now.

 

[deadalnix]

I did not insult you. If you want to reach me, not lying would be a good start.

 

[adamstgbit]

its interesting to read you too discuss this vigorously.

@Christoph Bergmann makes some good points :

exchanges dont like HF.

having BU try to push all kinds of changes will make it more controversial and will undermine its original goal.

@deadalnix tries to mitigate the first problem with

keeps things close to [SF] SegWit to minimize sunk cost for actor supporting [HF segwit].

I see BU not as Bitcoin Unlimited "blocksize" but rather Bitcoin Unlimited "Choice/Control"
Might help if this BU clients can turn on/off signaling for this HF.

HF activation is a non-issue if everyone is signaling support... and the concern of BU trying to change too many things at once is a non-issue if users have to not only use the lastest BU code but also explicitly turn on signaling support.

IMO it would definitely be a mistake to say from this point on if you use BU your supporting HFsegwit, I agree with @Christoph Bergmann this would hinder acceptance of BU.

 

[deadalnix]

Yes I understand exchange don't like HF. This is why I made sure this could be extended in pretty much any way we want using BUIP039. I'd be happy to do away with the hard fork/soft fork thing as none of them are a good way to upgrade - hard fork are potentially very disruptive, soft fork are not opposable by most actors. to do away with HF and SF, you need to introduce an alternative.

 

[Troubadour]

Although I still don't like the name "hard fork segwit", I don't think it really makes sense. It is a different proposal from segwit, so I think the name leads to confusion. And it is not descriptive, the witness is not really "segregated".

Desegregated Witness? (Or perhaps just Unsegregated Witness - as it hasn't really been segregated yet.)

 

[Mengerian]

Does BUIP037 bring the same benefit to hardware wallets that were touted with Segwit?

 

[deadalnix]

Yes, and, for completeness, FT does as well.

 

[HostFat]

I think that it would be good to have this already on the BU code.
I will be enabled with another "different" vote from miners.
This vote will be available only after the fork to a block bigger then 1MB, and it should enable itself like after 6 months. (6 is just an example)
It will be more that just words. Many devs of LN or other scaling solutions will appreciate this.
And users/companies that are demanding this kind of things will see this a big break on all the propaganda.
I still read in many occasions that users thinks that BU and hard forks means not LN or things like it.

 

[Mengerian]

Yeah, I agree it would be great to get this implemented and tested. Activation can come later (or never if the market prefers Flexible Transactions).

I would be in favor of BU allocating resources, maybe to hire coders or whatever is needed, to help make this happen.

 

[freetrader]

> This vote will be available only after the fork to a block bigger then 1MB

If it's BIP9 voted, then it needs a start date. I don't think it's easy to determine which is 'the fork block' until a safe time after the fact, although one could say enable such a vote if a >1MB block is buried by e.g. one retargeting period (2016 blocks).

Still, whichever way one wants to enable this vote, most of the code can be put in place & tested, and a client update released when it's sure we are on a healthy big block chain.

And starting to work on a PR for this would already be a huge signal to those who worry about a TM fix not happening.

 

[SamG]

Frankly, given that many wallets and exchanges are already supporting SegWit, it doesn't make sense to implement it differently, otherwise you have just made more work for everyone and the time they spent is wasted.

Whatever you decide, it should be compatible with address format and commands already implemented by existing wallets and exchanges.

Malleability is an obvious problem for smart contracts or any applications with bitcoin that require chaining transactions. The benefit of the backwards compatibility that Core implemented in the SegWit soft-fork is that existing services with standard tx can continue to be used, and new services can be developed to take advantage of the witness block.

Furthermore, it doesn't have to be perfect the first time around. If BU really does intend to continue development, it can be cleaned up and optimized with additional updates.

 

[deadalnix]

Current SegWit proposal is not good for reasons discussed again and again. I suggest you get familiar these shortcoming before coming and repeating the party line.

 

[Christoph Bergmann]

I really like the idea of hostfat. Let SegWit as a hardfork be the next option, after blocks are bigger than 1 MB, with something like fixed activation points every 48,000 blocks, activated by miners.