📅 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.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:47:38
in reply to nevent1q…gll9
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:47:38Event JSON
{
"id": "c016f65fa1c42831c71843653af6eed1c0203654498589950d14d7b970c5253b",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686314858,
"kind": 1,
"tags": [
[
"e",
"1b5890b1f355aa9bd0c48d19b3a4f0c6e857ab0a1016ed957f0b70c4a4e4b725",
"",
"root"
],
[
"e",
"65ee6dbba17aee12dcd8f662b9583817322d42963a547f6056bfc2e408bf509a",
"",
"reply"
],
[
"p",
"1c03575343555d1132a621c49466190d680da4a306ba8b992e8b87e267609cdd"
]
],
"content": "📅 Original date posted:2017-11-12\n📝 Original message:\nTomas \u003ctomas at bitcrust.org\u003e writes:\n\u003e HI,\n\u003e\n\u003e I have some questions regarding the proposal to use SIGHASH_NOINPUT on\n\u003e the bitcoin-dev mailing list. [1]\n\u003e\n\u003e 1. If I understand correctly, the problem of malleated transactions for\n\u003e LN is limited to the punishment transaction which is the only one that\n\u003e spends an unconfirmed transaction. Does that mean that with\n\u003e SIGHASH_NOINPUT, no other malleability fix would have been needed for LN\n\u003e to work? Am I correct that LN could function with (roughly) the same\n\u003e design without SegWit if SIGHASH_NOINPUT would be in place?\n\nMalleation is a problem for every commitment transaction: we use HTLC\ntransactions which depend on it. Now, in theory SIGHASH_NOINPUT could\nbe used to work around malleation here too, by allowing you to update\nthe dependent transaction, but you need separate keys on every output to\nensure that transactions can't be connected to the wrong outputs.\n\n\u003e 2. On the mailing list, it was argued that SIGHASH_NOINPUT is important\n\u003e to prevent excessive recreation and routing of punishment transaction to\n\u003e 3rd party monitoring services. Is this still important or have other\n\u003e solutions presented itself? Is work in this area still being done?\n\nIIRC it cuts the number of updates down by about a factor of 2 under\ntypical use, more under weird conditions. Basically you can re-attach\nthe HTLC transaction instead of needing a new one.\n\nIMHO SIGHASH_NOINPUT is a generally nice thing to have, though it's\nextremely dangerous if you reuse keys at all. So, don't do that :)\n\nCheers,\nRusty.",
"sig": "d4bc7d402c43309cdcd60d0b7ce96db8cf32d51a3e9633421214531c3923ba46dfdaea9eede2ae70f3174523c8e6f39d158c93df89b8ea4a9b014b7288f18737"
}