📅 Original date posted:2018-09-26
📝 Original message:> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
> hashSequence so that its behaviour is consistent with ANYONECANPAY?
There is a good reason for not doing that. If NOINPUT would sign the
hashSequence then it would be possible to get rid of OP_CSV in eltoo update
scripts. As a result update scripts could be taprootified because the more
common branch (settlement) would be just a 2-of-2 multisig. Applying taproot
would then make unilateral settlement look like a single pubkey spend and avoid
having to reveal the unexecuted (update) branch.
Eltoo update transaction outputs consist of two branches, update and
settlement, where the update branch can be spend by a more recent update
transaction if an obsolete update transaction ends up spending the funding
output. The settlement branch is a 2-of-2 multisig with a relative timelock
using OP_CSV. Removing OP_CSV is possible because both parties signature is
required to spend the update transaction. They will only sign if the input has
the right sequence numbers which is sufficient to enforce the timeout (BIP68) -
assuming they are covered by the signature.
There's a catch: hashSequence includes the sequence numbers of all transaction
inputs. That's not a problem for eltoo because settlement transactions only
have one input. The update mechanism with update transactions relies on being
able to bump the fee by unilaterally adding inputs and and change outputs to
the transaction. That's also not a problem because update spends do not use
relative timelocks and they are signed with SINGLE. So whenever NOINPUT is
combined SINGLE the hashSequence should be zeroed. This is in fact what a
minimal change to the current NOINPUT implementation would naturally do (see
below). However, that's error-prone when using NOINPUT in other contexts so in
general it would be better if NOINPUT would only sign the sequence number of
the corresponding input.
Another downside of this approach is that you can never rebind to an output
with an OP_CSV that requires a larger sequence number, unless you also sign
with SIGHASH_SINGLE. It's difficult to imagine application where this would be
an issue.
This is the modification to the NOINPUT implementation
(https://github.com/cdecker/bitcoin/commits/noinput) which makes eltoo
unilateral closes taprootifiable:
+++ b/src/script/interpreter.cpp
@@ -1223,7 +1223,7 @@ uint256 SignatureHash(const CScript& scriptCode, const CTransaction& txTo, unsig
hashPrevouts = cacheready ? cache->hashPrevouts : GetPrevoutHash(txTo);
}
- if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE && !noinput) {
+ if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
hashSequence = cacheready ? cache->hashSequence : GetSequenceHash(txTo);
}
On 5/1/18 4:58 PM, Russell O'Connor via bitcoin-dev wrote:
> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
> hashSequence so that its behaviour is consistent with ANYONECANPAY?
>
> On Mon, Apr 30, 2018 at 12:29 PM, Christian Decker via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> I'd like to pick up the discussion from a few months ago, and propose a new
>> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the
>> previous
>> output. This was previously mentioned on the list by Joseph Poon [1], but
>> was
>> never formally proposed, so I wrote a proposal [2].
>>
>> We have long known that `SIGHASH_NOINPUT` would be a great fit for
>> Lightning.
>> They enable simple watch-towers, i.e., outsource the need to watch the
>> blockchain for channel closures, and react appropriately if our
>> counterparty
>> misbehaves. In addition to this we just released the eltoo [3,4] paper
>> which
>> describes a simplified update mechanism that can be used in Lightning, and
>> other
>> off-chain contracts, with any number of participants.
>>
>> By not committing to the previous output being spent by the transaction,
>> we can
>> rebind an input to point to any outpoint with a matching output script and
>> value. The binding therefore is no longer explicit through a reference, but
>> through script compatibility, and the transaction ID reference in the
>> input is a
>> hint to validators. The sighash flag is meant to enable some off-chain
>> use-cases
>> and should not be used unless the tradeoffs are well-known. In particular
>> we
>> suggest using contract specific key-pairs, in order to avoid having any
>> unwanted
>> rebinding opportunities.
>>
>> The proposal is very minimalistic, and simple. However, there are a few
>> things
>> where we'd like to hear the input of the wider community with regards to
>> the
>> implementation details though. We had some discussions internally on
>> whether to
>> use a separate opcode or a sighash flag, some feeling that the sighash flag
>> could lead to some confusion with existing wallets, but given that we have
>> `SIGHASH_NONE`, and that existing wallets will not sign things with unknown
>> flags, we decided to go the sighash way. Another thing is that we still
>> commit
>> to the amount of the outpoint being spent. The rationale behind this is
>> that,
>> while rebinding to outpoints with the same value maintains the value
>> relationship between input and output, we will probably not want to bind to
>> something with a different value and suddenly pay a gigantic fee.
>>
>> The deployment part of the proposal is left vague on purpose in order not
>> to
>> collide with any other proposals. It should be possible to introduce it by
>> bumping the segwit script version and adding the new behavior.
>>
>> I hope the proposal is well received, and I'm looking forward to discussing
>> variants and tradeoffs here. I think the applications we proposed so far
>> are
>> quite interesting, and I'm sure there are many more we can enable with this
>> change.
>>
>> Cheers,
>> Christian
>>
>> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
>> 2016-February/012460.html
>> [2] https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki
>> [3] https://blockstream.com/2018/04/30/eltoo-next-lightning.html
>> [4] https://blockstream.com/eltoo.pdf
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
Jonas Nick [ARCHIVE] /
npub1at…y3z5a
2023-06-07 18:14:53
in reply to nevent1q…0yn5
Author Public Key
npub1at3pav59gkeqz9kegzqhk2v4j4r435x42ytf23pxs8crt74tuc8s2y3z5aPublished at
2023-06-07 18:14:53Event JSON
{
"id": "b6e3cad92b20c33d37e90b5074acbd7cd6248e27f9e7cc1d9260c10c1ae96f97",
"pubkey": "eae21eb28545b20116d940817b2995954758d0d5511695442681f035faabe60f",
"created_at": 1686161693,
"kind": 1,
"tags": [
[
"e",
"caf3c36f225fa36403be57a594ee2f51f7c55c02be7ef466c9181610f6cda7d5",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2018-09-26\n📝 Original message:\u003e At the risk of bikeshedding, shouldn't NOINPUT also zero out the\n\u003e hashSequence so that its behaviour is consistent with ANYONECANPAY?\n\nThere is a good reason for not doing that. If NOINPUT would sign the\nhashSequence then it would be possible to get rid of OP_CSV in eltoo update\nscripts. As a result update scripts could be taprootified because the more\ncommon branch (settlement) would be just a 2-of-2 multisig. Applying taproot\nwould then make unilateral settlement look like a single pubkey spend and avoid\nhaving to reveal the unexecuted (update) branch.\n\nEltoo update transaction outputs consist of two branches, update and\nsettlement, where the update branch can be spend by a more recent update\ntransaction if an obsolete update transaction ends up spending the funding\noutput. The settlement branch is a 2-of-2 multisig with a relative timelock\nusing OP_CSV. Removing OP_CSV is possible because both parties signature is\nrequired to spend the update transaction. They will only sign if the input has\nthe right sequence numbers which is sufficient to enforce the timeout (BIP68) -\nassuming they are covered by the signature.\n\nThere's a catch: hashSequence includes the sequence numbers of all transaction\ninputs. That's not a problem for eltoo because settlement transactions only\nhave one input. The update mechanism with update transactions relies on being\nable to bump the fee by unilaterally adding inputs and and change outputs to\nthe transaction. That's also not a problem because update spends do not use\nrelative timelocks and they are signed with SINGLE. So whenever NOINPUT is\ncombined SINGLE the hashSequence should be zeroed. This is in fact what a\nminimal change to the current NOINPUT implementation would naturally do (see\nbelow). However, that's error-prone when using NOINPUT in other contexts so in\ngeneral it would be better if NOINPUT would only sign the sequence number of\nthe corresponding input.\n\nAnother downside of this approach is that you can never rebind to an output\nwith an OP_CSV that requires a larger sequence number, unless you also sign\nwith SIGHASH_SINGLE. It's difficult to imagine application where this would be\nan issue.\n\nThis is the modification to the NOINPUT implementation\n(https://github.com/cdecker/bitcoin/commits/noinput) which makes eltoo\nunilateral closes taprootifiable:\n+++ b/src/script/interpreter.cpp\n@@ -1223,7 +1223,7 @@ uint256 SignatureHash(const CScript\u0026 scriptCode, const CTransaction\u0026 txTo, unsig\n hashPrevouts = cacheready ? cache-\u003ehashPrevouts : GetPrevoutHash(txTo);\n }\n\n- if (!(nHashType \u0026 SIGHASH_ANYONECANPAY) \u0026\u0026 (nHashType \u0026 0x1f) != SIGHASH_SINGLE \u0026\u0026 (nHashType \u0026 0x1f) != SIGHASH_NONE \u0026\u0026 !noinput) {\n+ if (!(nHashType \u0026 SIGHASH_ANYONECANPAY) \u0026\u0026 (nHashType \u0026 0x1f) != SIGHASH_SINGLE \u0026\u0026 (nHashType \u0026 0x1f) != SIGHASH_NONE) {\n hashSequence = cacheready ? cache-\u003ehashSequence : GetSequenceHash(txTo);\n }\n\nOn 5/1/18 4:58 PM, Russell O'Connor via bitcoin-dev wrote:\n\u003e At the risk of bikeshedding, shouldn't NOINPUT also zero out the\n\u003e hashSequence so that its behaviour is consistent with ANYONECANPAY?\n\u003e \n\u003e On Mon, Apr 30, 2018 at 12:29 PM, Christian Decker via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e\u003e Hi all,\n\u003e\u003e\n\u003e\u003e I'd like to pick up the discussion from a few months ago, and propose a new\n\u003e\u003e sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the\n\u003e\u003e previous\n\u003e\u003e output. This was previously mentioned on the list by Joseph Poon [1], but\n\u003e\u003e was\n\u003e\u003e never formally proposed, so I wrote a proposal [2].\n\u003e\u003e\n\u003e\u003e We have long known that `SIGHASH_NOINPUT` would be a great fit for\n\u003e\u003e Lightning.\n\u003e\u003e They enable simple watch-towers, i.e., outsource the need to watch the\n\u003e\u003e blockchain for channel closures, and react appropriately if our\n\u003e\u003e counterparty\n\u003e\u003e misbehaves. In addition to this we just released the eltoo [3,4] paper\n\u003e\u003e which\n\u003e\u003e describes a simplified update mechanism that can be used in Lightning, and\n\u003e\u003e other\n\u003e\u003e off-chain contracts, with any number of participants.\n\u003e\u003e\n\u003e\u003e By not committing to the previous output being spent by the transaction,\n\u003e\u003e we can\n\u003e\u003e rebind an input to point to any outpoint with a matching output script and\n\u003e\u003e value. The binding therefore is no longer explicit through a reference, but\n\u003e\u003e through script compatibility, and the transaction ID reference in the\n\u003e\u003e input is a\n\u003e\u003e hint to validators. The sighash flag is meant to enable some off-chain\n\u003e\u003e use-cases\n\u003e\u003e and should not be used unless the tradeoffs are well-known. In particular\n\u003e\u003e we\n\u003e\u003e suggest using contract specific key-pairs, in order to avoid having any\n\u003e\u003e unwanted\n\u003e\u003e rebinding opportunities.\n\u003e\u003e\n\u003e\u003e The proposal is very minimalistic, and simple. However, there are a few\n\u003e\u003e things\n\u003e\u003e where we'd like to hear the input of the wider community with regards to\n\u003e\u003e the\n\u003e\u003e implementation details though. We had some discussions internally on\n\u003e\u003e whether to\n\u003e\u003e use a separate opcode or a sighash flag, some feeling that the sighash flag\n\u003e\u003e could lead to some confusion with existing wallets, but given that we have\n\u003e\u003e `SIGHASH_NONE`, and that existing wallets will not sign things with unknown\n\u003e\u003e flags, we decided to go the sighash way. Another thing is that we still\n\u003e\u003e commit\n\u003e\u003e to the amount of the outpoint being spent. The rationale behind this is\n\u003e\u003e that,\n\u003e\u003e while rebinding to outpoints with the same value maintains the value\n\u003e\u003e relationship between input and output, we will probably not want to bind to\n\u003e\u003e something with a different value and suddenly pay a gigantic fee.\n\u003e\u003e\n\u003e\u003e The deployment part of the proposal is left vague on purpose in order not\n\u003e\u003e to\n\u003e\u003e collide with any other proposals. It should be possible to introduce it by\n\u003e\u003e bumping the segwit script version and adding the new behavior.\n\u003e\u003e\n\u003e\u003e I hope the proposal is well received, and I'm looking forward to discussing\n\u003e\u003e variants and tradeoffs here. I think the applications we proposed so far\n\u003e\u003e are\n\u003e\u003e quite interesting, and I'm sure there are many more we can enable with this\n\u003e\u003e change.\n\u003e\u003e\n\u003e\u003e Cheers,\n\u003e\u003e Christian\n\u003e\u003e\n\u003e\u003e [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/\n\u003e\u003e 2016-February/012460.html\n\u003e\u003e [2] https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki\n\u003e\u003e [3] https://blockstream.com/2018/04/30/eltoo-next-lightning.html\n\u003e\u003e [4] https://blockstream.com/eltoo.pdf\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e \n\u003e \n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e",
"sig": "8b4a9f7775b769d06a77752a5d1062bdf30b5bad5c15687ed368ec64c8c9191af26fbc741af5d792431815e69eb2c7477a2e46208e554e214487f5541cc30930"
}