BUIP082: Opt-in Malleability Fix

[torusJKL]

BUIP082: opt-in malleability fix
Submitted on 25th December 2017 by torusJKL

Background
Malleability is not an issue when working only with confirmed tx.
But if an application wants to reference an unconfirmed tx based on its tx id it could fail if said id is changed (malleate).

Motivation
Allow applications to use unconfirmed tx based on a non-malleable id.
This could open up Bitcoin Cash to new technology we do not know of today.


Goal
The solution will make tx non-malleable by the 1st party.
It should be opt-in and mustn't require existing inputs to be moved first (e.g. with SegWit where the tx has to originate from a SegWit address).


Task
1) The Bitcoin Unlimited lead developer shall engage in the discussion with other consensus implementations and propose a solution.
The solution can be already proposed by others or be a new one.

2) Writing of a specification and a pull request to the BitcoinCash repo such that other develops can implement the solution in their software.

3) Development of the malleability fix for BUCash.

Timetable
The malleability fix should be developed and to be implemented for BUCash with the aim of being ready for inclusion in the scheduled November 2018 protocol upgrade.

Caveats
The lead developer will have discretion and flexibility to modify details specified in this BUIP, while keeping within the spirit of the BUIP with the goal of advancing an opt-in malleability fix for Bitcoin Cash.


References
Malleability fix proposal
Malleability Fix SIGHASH_ANYOUTPUT
Start differenciating txid and txhash

 

[torusJKL]

@solex please assign a BUIP number and add it to the BUIP list.
Thanks.

 

[solex]

@torusJKL
Certainly. Updated with 082.

 

[torusJKL]

@solex please include this BUIP in the 15.01.2018 voting round.

Thanks

 

[solex]

@torusJKL,
Sorry, but unfortunately, it can't be voted on yet as it needs input and approval from @theZerg, as the lead developer. Especially so, where this is a development BUIP which proposes an important functional change. So, we should use the next month or so for some rigorous debate and feedback, as you indicate also with other dev teams. This will refine the requirements. Then, the BU membership will be able to make an informed voting decision.

I note you mention the HF of November, which is a while off. The next vote will be in 6-8 weeks.

 

[torusJKL]

Thanks for the explanation. I will patently await the next voting round.

 

[torusJKL]

@theZerg please have a look at this BUIP.

Thanks!

 

[Mengerian]

I support the spirit of this BUIP, but I would change the wording of this part (or just remove this section):

Timetable
The malleability fix shall be developed and to be implemented to BUCash no later than in the scheduled HF of November 2018.

It would be nice to have it in the Nov Upgrade, but I think the wording is too restrictive, since the scheduling will depend on many factors beyond the control of BU devs, such as what other implementations are doing.

The BUIP should basically just specify the goal, and give the implementors maximum latitude to decide the best way to achieve it, based on the circumstances at the time.

 

[torusJKL]

The idea behind the fixed date is to be proactive and not ask for permission but to provide a solution and go forward with it.

 

[Mengerian]

OK, it's fine to specify a date as a goal. I agree on being proactive, and not asking permission.

But I still think it would be better to word it in a way that allows flexibility if circumstances change.

Maybe add a disclaimer at the end to give discretion for change if needed.

We should also keep in mind that we can't order the devs to do something, just because we vote on it. So it's good to word it in a way that doesn't sound like it assumes we can order something to happen.

How about this?

Timetable
The malleability fix should be developed and to be implemented for BUCash with the aim of being ready for inclusion in the scheduled November 2018 protocol upgrade.

Caveats
The Developer will have discretion and flexibility to modify details specified in this BUIP, while keeping within the spirit of the BUIP with the goal of advancing an opt-in malleability fix for Bitcoin Cash.

 

[torusJKL]

I have changed the wording according to your comment.
Let's see how this will play out.

although it gives the lead developer more space to react it also takes away our support for a deadline which could make the lead developers position in negotiations with other implementations weaker.
[doublepost=1523461297][/doublepost]

We should also keep in mind that we can't order the devs to do something, just because we vote on it. So it's good to word it in a way that doesn't sound like it assumes we can order something to happen.

I'm not sure if I understand what you wrote here.
Does this mean a full time developers that is paid by BU doesn't have to work on a BUIP if he/she doesn't to like it?

 

[Mengerian]

I don't know, I wasn't aware that BU was paying any developers.

 

[torusJKL]

Hmm. As we have paid work from the devpool I was under the impression that the lead and key developers also get paid for their work.

If they don't maybe this is something that should be looked at in the future.

 

[torusJKL]

@solex this BUIP is ready.
Please include it for voting on 07.05.2018.

P.S. I made some changes to the wording of the BUIP and defined the tasks more in detail.

 

[theZerg]

I am "for" malleability fixes, but IDK if BU needs to be the team to go after them -- it seems a pretty low priority with lightning struggling along. Perhaps we leverage whatever the lightning team comes up with perhaps SIGHASH_NOINPUTs?

Regardless, I wish was more on top of reading and responding to these BUIPs. In general, you cannot mandate that the developer or anybody go off and implement something in a BUIP. Its a volunteer organization. What you can do is state that "if solution X appears, BU will merge it" OR even "X BU dollars will be spent for a merged implementation of malleability, with the developer to shepard the process"

 

[SanchoPanza]

@theZerg: Can you state whether BUIP057 will be merged if I rebase it once more (for free)?
I have asked whether there is still intention to merge this feature, but have not received decisive feedback.

Is the default in BU to merge BUIPs that have been accepted, implemented and reviewed, and what should developers expect regarding this process in terms of timeframes or communication?

 

[torusJKL]

@theZerg I value your input very much and we have pinged you already back in January and again at the beginning of March.
If you think there is a better way to reach you than on this forum please let us know and I will try to reach you there next time.

I'm not a developer and thus I see my role here more as someone who brings in ideas and creates a platform for discussions. Unfortunately almost nobody engages and the BUIPs get to be voted on like I wrote them which is a pity. (this goes also to other members of the community who do not engage)

I have already been schooled that your and the other developers work is voluntary and while it is very much appreciated I wonder how we can make the voting process more meaningful than just to give a promise that should someone come along with the code it would be merged.

Because this moves all the power back to developers who know how to code and leaves the rest of the community at their mercy.
Nothing against developers (I actually want to become one at some time in the future) but I was under the impression that BU wants to give other players also a say in the future development of Bitcoin.

 

[Bagatell]

@torusJKL

I'm not a developer, made no promise on how I would vote and have voted against several BUIPs.