📅 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
CJP [ARCHIVE] /
npub13q…cuzdm
2023-06-09 14:45:07
in reply to nevent1q…jt6d
Author Public Key
npub13q863scgpsaanrjhfn7dd4h48lgnupgkcs828arzj4pckrq8hh6s4cuzdmPublished at
2023-06-09 14:45:07Event JSON
{
"id": "1150e1a41b8935fba89512ab19a683209cae75cec0114cb5a523d51e4552dead",
"pubkey": "880fa8c3080c3bd98e574cfcd6d6f53fd13e0516c40ea3f46295438b0c07bdf5",
"created_at": 1686314707,
"kind": 1,
"tags": [
[
"e",
"1af72c6403b0bf6c208cd96111979b74febacb268ea0e46444fb1495c20b46af",
"",
"root"
],
[
"e",
"33aa4d9140c02260a13cb9801eea3dacfb95d660b5a300ec8526e6b7dbfe56b4",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2015-11-19\n📝 Original message:\nWow, that was unexpected.\n\nIs there a place where I can see the discussion that concluded in\nwithdrawing BIP62? The only thing I found with a quick search was this:\n\nhttps://github.com/bitcoin/bips/commit/916142e742b4256686c26b15a0bf943aea3f5ef9\n\nAll of BIP62's (including the only-new-transactions) are currently\nenforced\nas standardness rules, but it seems hard to push it further. Every new\ntype\nof complex transaction may require new extra rules, and some important\ntypes\nof malleability cannot be addressed by it (for example, a single\nparticipant\nin a multisig spend creating a new signature with a different nonce).\nIt seems wiser to pursue normalized txid or segregated witness-based\nsolutions, which do solve this problem more fundamentally.\n\nThe reasoning seems to assume that \"normalized txid or segregated\nwitness-based solutions\" will become available in the future. Aren't\nthese features harder to introduce (hard fork)? Is there a backup plan\nfor when these somehow don't get implemented? That could be e.g.\nun-withdrawing BIP62. If miners / pool operators see value in reducing\ntx malleability, I don't see how the core developers could stop such a\nmovement.\n\nBIP62 may not solve all cases (and is, in that sense, inferior to more\nfundamental solutions), but from what I can see, it was already good\nenough for certain types of smart contract constructions. I think the\nAmiko Pay \"HTLC emulation\" design would be secure against malleability\nunder the conditions that\n* BIP62 is in effect\n* Every channel is only funded by one of the two sides (so e.g. the \"New\nsignatures by the sender\" case can't be abused)\n\nCJP\n\n\nRusty Russell schreef op do 19-11-2015 om 13:23 [+1030]:\n\u003e Hi all!\n\u003e \n\u003e As you know, I designed a lightning variant which used only\n\u003e non-experimental, in-planning BIPs[1]. One assumption was BIP62: in\n\u003e particular, that anchor malleability wouldn't be an issue. This was\n\u003e flawed; BIP62 will never be deployed.\n\u003e \n\u003e There are several options from here:\n\u003e \n\u003e 1) Ignore it. Malleated txs are non-standard.\n\u003e 2) Add a timeout to the anchor. Limits the lifetime of the channel, and\n\u003e still means if it does happen you have to wait for the timeout.\n\u003e 3) Propose a reduced BIP62 which (say) only protects P2PKH, for a\n\u003e specific transaction version.\n\u003e 4) Take a leap of faith and assume Segregated Witness fixes all\n\u003e malleability.\n\u003e \n\u003e I was debating between #1 and #3 for a while, but eventually settled on\n\u003e #4. Here's why:\n\u003e \n\u003e 1) While still pre-BIP, Pieter Wuille is working on a prototype now\n\u003e (Luke Jr came up with a sanish way of softforking it in).\n\u003e 2) Other parts of the lightning code (in particular, watching bitcoin\n\u003e transactions) become significantly simpler if malleability is\n\u003e ignored.\n\u003e 3) It's the right thing for Bitcoin; all smart contract systems want\n\u003e this.\n\u003e \n\u003e This result is NOP for lightning in the short term; assuming SW is the\n\u003e same as pretending malleability doesn't exist. But if we need to add\n\u003e malleability support later, it's going to be painful, since handling it\n\u003e correctly in all the places it's missing will be hard.\n\u003e \n\u003e Cheers,\n\u003e Rusty.\n\u003e PS. Remember, every project has 3 major disasters. Just wait until you\n\u003e see the next two!\n\u003e \n\u003e [1] https://github.com/ElementsProject/lightning/blob/master/doc/deployable-lightning.pdf\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev",
"sig": "6a0a58d161dd663239e2f9c41b3d8c992e3277962e39a19ff10fbf99355b0939f689831891654430ef029f7cf0d8a04b946762b6d3c8d5b550f47dbbcfe8e6f4"
}