CJP [ARCHIVE] on Nostr: 📅 Original date posted:2015-11-19 📝 Original message: Wow, that was unexpected. ...
📅 Original date posted:2015-11-19
📝 Original message:
Wow, that was unexpected.
Is there a place where I can see the discussion that concluded in
withdrawing BIP62? The only thing I found with a quick search was this:
https://github.com/bitcoin/bips/commit/916142e742b4256686c26b15a0bf943aea3f5ef9
All of BIP62's (including the only-new-transactions) are currently
enforced
as standardness rules, but it seems hard to push it further. Every new
type
of complex transaction may require new extra rules, and some important
types
of malleability cannot be addressed by it (for example, a single
participant
in a multisig spend creating a new signature with a different nonce).
It seems wiser to pursue normalized txid or segregated witness-based
solutions, which do solve this problem more fundamentally.
The reasoning seems to assume that "normalized txid or segregated
witness-based solutions" will become available in the future. Aren't
these features harder to introduce (hard fork)? Is there a backup plan
for when these somehow don't get implemented? That could be e.g.
un-withdrawing BIP62. If miners / pool operators see value in reducing
tx malleability, I don't see how the core developers could stop such a
movement.
BIP62 may not solve all cases (and is, in that sense, inferior to more
fundamental solutions), but from what I can see, it was already good
enough for certain types of smart contract constructions. I think the
Amiko Pay "HTLC emulation" design would be secure against malleability
under the conditions that
* BIP62 is in effect
* Every channel is only funded by one of the two sides (so e.g. the "New
signatures by the sender" case can't be abused)
CJP
Rusty Russell schreef op do 19-11-2015 om 13:23 [+1030]:
> Hi all!
>
> As you know, I designed a lightning variant which used only
> non-experimental, in-planning BIPs[1]. One assumption was BIP62: in
> particular, that anchor malleability wouldn't be an issue. This was
> flawed; BIP62 will never be deployed.
>
> There are several options from here:
>
> 1) Ignore it. Malleated txs are non-standard.
> 2) Add a timeout to the anchor. Limits the lifetime of the channel, and
> still means if it does happen you have to wait for the timeout.
> 3) Propose a reduced BIP62 which (say) only protects P2PKH, for a
> specific transaction version.
> 4) Take a leap of faith and assume Segregated Witness fixes all
> malleability.
>
> I was debating between #1 and #3 for a while, but eventually settled on
> #4. Here's why:
>
> 1) While still pre-BIP, Pieter Wuille is working on a prototype now
> (Luke Jr came up with a sanish way of softforking it in).
> 2) Other parts of the lightning code (in particular, watching bitcoin
> transactions) become significantly simpler if malleability is
> ignored.
> 3) It's the right thing for Bitcoin; all smart contract systems want
> this.
>
> This result is NOP for lightning in the short term; assuming SW is the
> same as pretending malleability doesn't exist. But if we need to add
> malleability support later, it's going to be painful, since handling it
> correctly in all the places it's missing will be hard.
>
> Cheers,
> Rusty.
> PS. Remember, every project has 3 major disasters. Just wait until you
> see the next two!
>
> [1] https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
📝 Original message:
Wow, that was unexpected.
Is there a place where I can see the discussion that concluded in
withdrawing BIP62? The only thing I found with a quick search was this:
https://github.com/bitcoin/bips/commit/916142e742b4256686c26b15a0bf943aea3f5ef9
All of BIP62's (including the only-new-transactions) are currently
enforced
as standardness rules, but it seems hard to push it further. Every new
type
of complex transaction may require new extra rules, and some important
types
of malleability cannot be addressed by it (for example, a single
participant
in a multisig spend creating a new signature with a different nonce).
It seems wiser to pursue normalized txid or segregated witness-based
solutions, which do solve this problem more fundamentally.
The reasoning seems to assume that "normalized txid or segregated
witness-based solutions" will become available in the future. Aren't
these features harder to introduce (hard fork)? Is there a backup plan
for when these somehow don't get implemented? That could be e.g.
un-withdrawing BIP62. If miners / pool operators see value in reducing
tx malleability, I don't see how the core developers could stop such a
movement.
BIP62 may not solve all cases (and is, in that sense, inferior to more
fundamental solutions), but from what I can see, it was already good
enough for certain types of smart contract constructions. I think the
Amiko Pay "HTLC emulation" design would be secure against malleability
under the conditions that
* BIP62 is in effect
* Every channel is only funded by one of the two sides (so e.g. the "New
signatures by the sender" case can't be abused)
CJP
Rusty Russell schreef op do 19-11-2015 om 13:23 [+1030]:
> Hi all!
>
> As you know, I designed a lightning variant which used only
> non-experimental, in-planning BIPs[1]. One assumption was BIP62: in
> particular, that anchor malleability wouldn't be an issue. This was
> flawed; BIP62 will never be deployed.
>
> There are several options from here:
>
> 1) Ignore it. Malleated txs are non-standard.
> 2) Add a timeout to the anchor. Limits the lifetime of the channel, and
> still means if it does happen you have to wait for the timeout.
> 3) Propose a reduced BIP62 which (say) only protects P2PKH, for a
> specific transaction version.
> 4) Take a leap of faith and assume Segregated Witness fixes all
> malleability.
>
> I was debating between #1 and #3 for a while, but eventually settled on
> #4. Here's why:
>
> 1) While still pre-BIP, Pieter Wuille is working on a prototype now
> (Luke Jr came up with a sanish way of softforking it in).
> 2) Other parts of the lightning code (in particular, watching bitcoin
> transactions) become significantly simpler if malleability is
> ignored.
> 3) It's the right thing for Bitcoin; all smart contract systems want
> this.
>
> This result is NOP for lightning in the short term; assuming SW is the
> same as pretending malleability doesn't exist. But if we need to add
> malleability support later, it's going to be painful, since handling it
> correctly in all the places it's missing will be hard.
>
> Cheers,
> Rusty.
> PS. Remember, every project has 3 major disasters. Just wait until you
> see the next two!
>
> [1] https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev