Tomas [ARCHIVE] on Nostr: 📅 Original date posted:2017-11-10 📝 Original message: HI, I have some questions ...
📅 Original date posted:2017-11-10
📝 Original message:
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?
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?
Thanks,
Tomas van der Wansem
bitcrust
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html
📝 Original message:
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?
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?
Thanks,
Tomas van der Wansem
bitcrust
[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html