Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2017-11-12 📝 Original message: Tomas <tomas at ...
📅 Original date posted:2017-11-12
📝 Original message:
Tomas <tomas at bitcrust.org> writes:
> HI,
>
> I have some questions regarding the proposal to use SIGHASH_NOINPUT on
> the bitcoin-dev mailing list. [1]
>
> 1. If I understand correctly, the problem of malleated transactions for
> LN is limited to the punishment transaction which is the only one that
> spends an unconfirmed transaction. Does that mean that with
> SIGHASH_NOINPUT, no other malleability fix would have been needed for LN
> to work? Am I correct that LN could function with (roughly) the same
> design without SegWit if SIGHASH_NOINPUT would be in place?
Malleation is a problem for every commitment transaction: we use HTLC
transactions which depend on it. Now, in theory SIGHASH_NOINPUT could
be used to work around malleation here too, by allowing you to update
the dependent transaction, but you need separate keys on every output to
ensure that transactions can't be connected to the wrong outputs.
> 2. On the mailing list, it was argued that SIGHASH_NOINPUT is important
> to prevent excessive recreation and routing of punishment transaction to
> 3rd party monitoring services. Is this still important or have other
> solutions presented itself? Is work in this area still being done?
IIRC it cuts the number of updates down by about a factor of 2 under
typical use, more under weird conditions. Basically you can re-attach
the HTLC transaction instead of needing a new one.
IMHO SIGHASH_NOINPUT is a generally nice thing to have, though it's
extremely dangerous if you reuse keys at all. So, don't do that :)
Cheers,
Rusty.
📝 Original message:
Tomas <tomas at bitcrust.org> writes:
> HI,
>
> I have some questions regarding the proposal to use SIGHASH_NOINPUT on
> the bitcoin-dev mailing list. [1]
>
> 1. If I understand correctly, the problem of malleated transactions for
> LN is limited to the punishment transaction which is the only one that
> spends an unconfirmed transaction. Does that mean that with
> SIGHASH_NOINPUT, no other malleability fix would have been needed for LN
> to work? Am I correct that LN could function with (roughly) the same
> design without SegWit if SIGHASH_NOINPUT would be in place?
Malleation is a problem for every commitment transaction: we use HTLC
transactions which depend on it. Now, in theory SIGHASH_NOINPUT could
be used to work around malleation here too, by allowing you to update
the dependent transaction, but you need separate keys on every output to
ensure that transactions can't be connected to the wrong outputs.
> 2. On the mailing list, it was argued that SIGHASH_NOINPUT is important
> to prevent excessive recreation and routing of punishment transaction to
> 3rd party monitoring services. Is this still important or have other
> solutions presented itself? Is work in this area still being done?
IIRC it cuts the number of updates down by about a factor of 2 under
typical use, more under weird conditions. Basically you can re-attach
the HTLC transaction instead of needing a new one.
IMHO SIGHASH_NOINPUT is a generally nice thing to have, though it's
extremely dangerous if you reuse keys at all. So, don't do that :)
Cheers,
Rusty.