đź“… Original date posted:2019-02-09
đź“ť Original message:This is really interesting. If I get it correctly, I think the fungibility hit could be avoided, just by making one more signature, and not affecting the blockchain space usage.
Just some terminology first. In a 3-party channel, “main channel” means the one requires all parties to update, and “branch channel” requires only 2 parties to update.
By what you describe, I think the most realistic scenario is “C is going to offline soon, and may or may not return. So the group wants to keep the main channel open, and create a branch channel for A and B, during the absence of C”. I guess this is what you mean by being able to "predict in advance who will become absent”
I call this process as “semi-cooperative channel closing” (SCCC). During a SCCC, the settlement tx will have 2 outputs: one as (A & B), one as (C). Therefore, a branch channel could be opened with the (A & B) output. The channel opening must use NOINPUT signature, since we don’t know the txid of the settlement tx. With the output tagging requirement, (A & B) must be tagged, and lead to the fungibility loss you described.
However, it is possible to make 2 settlement txs during SCCC. Outputs of the settlement tx X are tagged(A&B) and C. Outputs of the settlement tx Y are untagged(A&B) and C. Both X and Y are BIP68 relative-time-locked, but Y has a longer time lock.
The branch channel is opened on top of the tagged output of tx X. If A and B want to close the channel without C, they need to publish the last update tx of the main channel. Once the update tx is confirmed, its txid becomes permanent, so are the txids of X and Y. If A and B decide to close the channel cooperatively, they could do it on top of the untagged output of tx Y, without using NOINPUT. There won’t be any fungibility loss. Other people will only see the uncooperative closing of the main channel, and couldn’t even tell the number of parties in the main channel. Unfortunately, the unusual long lock time of Y might still tell something.
If anything goes wrong, A or B could publish X before the lock time of Y, and settle it through the usual eltoo style. Since this is an uncooperative closing anyway, the extra fungibility loss due to tagging is next to nothing. However, it may suggest that the main channel was a multi-party one.
For C, the last update tx of the main channel and the settlement tx Y are the only things he needs to get the money back. C has to sign tx X, but he shouldn’t get the complete tx X. Otherwise, C might have an incentive to publish X in order to get the money back earlier, at the cost of fungibility loss of the branch channel.
To minimise the fungibility loss, we’d better make it a social norm: if you sign your tx with NOINPUT, always try to make all outputs tagged to be NOINPUT-spendable. (NOTE: you can still spend tagged outputs with normal signatures, so this won’t permanently taint your coins as NOINPUT-spendable) It makes sense because the use of NOINPUT signature strongly suggests that you don’t know the txid of the parent tx, so you may most likely want your outputs to be NOINPUT-spendable as well. I thought of making this a policy or consensus rule, but may be it’s just overkill.
> On 9 Feb 2019, at 3:01 AM, Jonas Nick <jonasdnick at gmail.com> wrote:
>
> Output tagging may result in reduced fungibility in multiparty eltoo channels.
> If one party is unresponsive, the remaining participants want to remove
> the party from the channel without downtime. This is possible by creating
> settlement transactions which pay off the unresponsive party and fund a new
> channel with the remaining participants.
>
> When the party becomes unresponsive, the channel is closed by broadcasting the
> update transaction as usual. As soon as that happens the remaining
> participants can start to update their new channel. Their update signatures
> must use SIGHASH_NOINPUT. This is because in eltoo the settlement txid is not
> final (because update tx is not confirmed and may have to rebind to another
> output). Therefore, the funding output of the new channel must be NOINPUT
> tagged. Assuming the remaining parties later settle cooperatively, this loss
> of fungibility would not have happened without output tagging.
>
> funding output update output settlement outputs update output
> [ A & B & C ] -> ... -> [ (A & B & C & state CLTV) | (As & Bs & Cs) ] -> [ NOINPUT tagged: (A' & B'), -> ...
> C' ]
> If the expectation is that the unresponsive party returns, fungibility is
> not reduced due to output tagging because the above scheme can be used
> off-chain until the original channel can be continued.
>
> Side note: I was not able to come up with an similar, eltoo-like protocol that works
> if you can't predict in advance who will become absent.
>
> On 12/13/18 12:32 PM, Johnson Lau via bitcoin-dev wrote:
>> NOINPUT is very powerful, but the tradeoff is the risks of signature replay. While the key holders are expected not to reuse key pair, little could be done to stop payers to reuse an address. Unfortunately, key-pair reuse has been a social and technical norm since the creation of Bitcoin (the first tx made in block 170 reused the previous public key). I don’t see any hope to change this norm any time soon, if possible at all.
>>
>> As the people who are designing the layer-1 protocol, we could always blame the payer and/or payee for their stupidity, just like those people laughed at victims of Ethereum dumb contracts (DAO, Parity multisig, etc). The existing bitcoin script language is so restrictive. It disallows many useful smart contracts, but at the same time prevented many dumb contracts. After all, “smart” and “dumb” are non-technical judgement. The DAO contract has always been faithfully executed. It’s dumb only for those invested in the project. For me, it was just a comedy show.
>>
>> So NOINPUT brings us more smart contract capacity, and at the same time we are one step closer to dumb contracts. The target is to find a design that exactly enables the smart contracts we want, while minimising the risks of misuse.
>>
>> The risk I am trying to mitigate is a payer mistakenly pay to a previous address with the exactly same amount, and the previous UTXO has been spent using NOINPUT. Accidental double payment is not uncommon. Even if the payee was honest and willing to refund, the money might have been spent with a replayed NOINPUT signature. Once people lost a significant amount of money this way, payers (mostly exchanges) may refuse to send money to anything other than P2PKH, native-P2WPKH and native-P2WSH (as the only 3 types without possibility of NOINPUT)
>>
>> The proposed solution is that an output must be “tagged” for it to be spendable with NOINPUT, and the “tag” must be made explicitly by the payer. There are 2 possible ways to do the tagging:
>>
>> 1. A certain bit in the tx version must be set
>> 2. A certain bit in the scriptPubKey must be set
>>
>> I will analyse the pros and cons later.
>>
>> Using eltoo as example. The setup utxo is a simple 2-of-2 multisig, and should not be tagged. This makes it indistinguishable from normal 1-of-1 utxo. The trigger tx, which spends the setup utxo, should be tagged, so the update txs could spend the trigger utxo with NOINPUT. Similarly, all update txs should be tagged, so they could be spent by other update txs and settlement tx with NOINPUT. As the final destination, there is no need to tag in the settlement tx.
>>
>> In payer’s perspective, tagging means “I believe this address is for one-time-use only” Since we can’t control how other people manage their addresses, we should never do tagging when paying to other people.
>>
>> I mentioned 2 ways of tagging, and they have pros and cons. First of all, tagging in either way should not complicate the eltoo protocol in anyway, nor bring extra block space overhead.
>>
>> A clear advantage of tagging with scriptPubKey is we could tag on a per-output basis. However, scriptPubKey tagging is only possible with native-segwit, not P2SH. That means we have to disallow NOINPUT in P2SH-segwit (Otherwise, *all* P2SH addresses would become “risky” for payers) This should be ok for eltoo, since it has no reason to use P2SH-segwit in intermediate txs, which is more expensive.
>>
>> Another problem with scriptPubKey tagging is all the existing bech32 implementations will not understand the special tag, and will pay to a tagged address as usual. An upgrade would be needed for them to refuse sending to tagged addresses by default.
>>
>> On the other hand, tagging with tx version will also protect P2SH-segwit, and all existing wallets are protected by default. However, it is somewhat a layer violation and you could only tag all or none output in the same tx. Also, as Bitcoin Core has just removed the tx version from the UTXO database, adding it back could be a little bit annoying, but doable.
>>
>> There is an extension to the version tagging, which could make NOINPUT even safer. In addition to tagging requirement, NOINPUT will also sign the version of the previous tx. If the wallet always uses a randomised tx version, it makes accidental replay very unlikely. However, that will burn a few more bits in the tx version field.
>>
>> While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
Johnson Lau [ARCHIVE] /
npub1fy…p2mv9
2023-06-07 18:16:13
in reply to nevent1q…scpx
Author Public Key
npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9Seen on
wss://relay.noswhere.comPublished at
2023-06-07 18:16:13Event JSON
{
"id": "f1dc336427404307883c89bc30dbeb0ed5f7c026a8a3554dba8b29c15a72c456",
"pubkey": "492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7",
"created_at": 1686161773,
"kind": 1,
"tags": [
[
"e",
"d115c2cf2fc1879f7295a540eec6df49284da7ea0208c40bff09a5bb6df1c817",
"",
"root"
],
[
"e",
"3c129130ea365a6acd828470ff89ef98ace9f3f2de164dd7375601116a48d061",
"",
"reply"
],
[
"p",
"eae21eb28545b20116d940817b2995954758d0d5511695442681f035faabe60f"
]
],
"content": "📅 Original date posted:2019-02-09\n📝 Original message:This is really interesting. If I get it correctly, I think the fungibility hit could be avoided, just by making one more signature, and not affecting the blockchain space usage.\n\nJust some terminology first. In a 3-party channel, “main channel” means the one requires all parties to update, and “branch channel” requires only 2 parties to update.\n\nBy what you describe, I think the most realistic scenario is “C is going to offline soon, and may or may not return. So the group wants to keep the main channel open, and create a branch channel for A and B, during the absence of C”. I guess this is what you mean by being able to \"predict in advance who will become absent”\n\nI call this process as “semi-cooperative channel closing” (SCCC). During a SCCC, the settlement tx will have 2 outputs: one as (A \u0026 B), one as (C). Therefore, a branch channel could be opened with the (A \u0026 B) output. The channel opening must use NOINPUT signature, since we don’t know the txid of the settlement tx. With the output tagging requirement, (A \u0026 B) must be tagged, and lead to the fungibility loss you described.\n\nHowever, it is possible to make 2 settlement txs during SCCC. Outputs of the settlement tx X are tagged(A\u0026B) and C. Outputs of the settlement tx Y are untagged(A\u0026B) and C. Both X and Y are BIP68 relative-time-locked, but Y has a longer time lock.\n\nThe branch channel is opened on top of the tagged output of tx X. If A and B want to close the channel without C, they need to publish the last update tx of the main channel. Once the update tx is confirmed, its txid becomes permanent, so are the txids of X and Y. If A and B decide to close the channel cooperatively, they could do it on top of the untagged output of tx Y, without using NOINPUT. There won’t be any fungibility loss. Other people will only see the uncooperative closing of the main channel, and couldn’t even tell the number of parties in the main channel. Unfortunately, the unusual long lock time of Y might still tell something.\n\nIf anything goes wrong, A or B could publish X before the lock time of Y, and settle it through the usual eltoo style. Since this is an uncooperative closing anyway, the extra fungibility loss due to tagging is next to nothing. However, it may suggest that the main channel was a multi-party one.\n\nFor C, the last update tx of the main channel and the settlement tx Y are the only things he needs to get the money back. C has to sign tx X, but he shouldn’t get the complete tx X. Otherwise, C might have an incentive to publish X in order to get the money back earlier, at the cost of fungibility loss of the branch channel.\n\nTo minimise the fungibility loss, we’d better make it a social norm: if you sign your tx with NOINPUT, always try to make all outputs tagged to be NOINPUT-spendable. (NOTE: you can still spend tagged outputs with normal signatures, so this won’t permanently taint your coins as NOINPUT-spendable) It makes sense because the use of NOINPUT signature strongly suggests that you don’t know the txid of the parent tx, so you may most likely want your outputs to be NOINPUT-spendable as well. I thought of making this a policy or consensus rule, but may be it’s just overkill.\n\n\n\n\u003e On 9 Feb 2019, at 3:01 AM, Jonas Nick \u003cjonasdnick at gmail.com\u003e wrote:\n\u003e \n\u003e Output tagging may result in reduced fungibility in multiparty eltoo channels.\n\u003e If one party is unresponsive, the remaining participants want to remove\n\u003e the party from the channel without downtime. This is possible by creating\n\u003e settlement transactions which pay off the unresponsive party and fund a new\n\u003e channel with the remaining participants.\n\u003e \n\u003e When the party becomes unresponsive, the channel is closed by broadcasting the\n\u003e update transaction as usual. As soon as that happens the remaining\n\u003e participants can start to update their new channel. Their update signatures\n\u003e must use SIGHASH_NOINPUT. This is because in eltoo the settlement txid is not\n\u003e final (because update tx is not confirmed and may have to rebind to another\n\u003e output). Therefore, the funding output of the new channel must be NOINPUT\n\u003e tagged. Assuming the remaining parties later settle cooperatively, this loss\n\u003e of fungibility would not have happened without output tagging.\n\u003e \n\u003e funding output update output settlement outputs update output\n\u003e [ A \u0026 B \u0026 C ] -\u003e ... -\u003e [ (A \u0026 B \u0026 C \u0026 state CLTV) | (As \u0026 Bs \u0026 Cs) ] -\u003e [ NOINPUT tagged: (A' \u0026 B'), -\u003e ...\n\u003e C' ]\n\u003e If the expectation is that the unresponsive party returns, fungibility is\n\u003e not reduced due to output tagging because the above scheme can be used\n\u003e off-chain until the original channel can be continued.\n\u003e \n\u003e Side note: I was not able to come up with an similar, eltoo-like protocol that works\n\u003e if you can't predict in advance who will become absent.\n\u003e \n\u003e On 12/13/18 12:32 PM, Johnson Lau via bitcoin-dev wrote:\n\u003e\u003e NOINPUT is very powerful, but the tradeoff is the risks of signature replay. While the key holders are expected not to reuse key pair, little could be done to stop payers to reuse an address. Unfortunately, key-pair reuse has been a social and technical norm since the creation of Bitcoin (the first tx made in block 170 reused the previous public key). I don’t see any hope to change this norm any time soon, if possible at all.\n\u003e\u003e \n\u003e\u003e As the people who are designing the layer-1 protocol, we could always blame the payer and/or payee for their stupidity, just like those people laughed at victims of Ethereum dumb contracts (DAO, Parity multisig, etc). The existing bitcoin script language is so restrictive. It disallows many useful smart contracts, but at the same time prevented many dumb contracts. After all, “smart” and “dumb” are non-technical judgement. The DAO contract has always been faithfully executed. It’s dumb only for those invested in the project. For me, it was just a comedy show.\n\u003e\u003e \n\u003e\u003e So NOINPUT brings us more smart contract capacity, and at the same time we are one step closer to dumb contracts. The target is to find a design that exactly enables the smart contracts we want, while minimising the risks of misuse.\n\u003e\u003e \n\u003e\u003e The risk I am trying to mitigate is a payer mistakenly pay to a previous address with the exactly same amount, and the previous UTXO has been spent using NOINPUT. Accidental double payment is not uncommon. Even if the payee was honest and willing to refund, the money might have been spent with a replayed NOINPUT signature. Once people lost a significant amount of money this way, payers (mostly exchanges) may refuse to send money to anything other than P2PKH, native-P2WPKH and native-P2WSH (as the only 3 types without possibility of NOINPUT)\n\u003e\u003e \n\u003e\u003e The proposed solution is that an output must be “tagged” for it to be spendable with NOINPUT, and the “tag” must be made explicitly by the payer. There are 2 possible ways to do the tagging:\n\u003e\u003e \n\u003e\u003e 1. A certain bit in the tx version must be set\n\u003e\u003e 2. A certain bit in the scriptPubKey must be set\n\u003e\u003e \n\u003e\u003e I will analyse the pros and cons later.\n\u003e\u003e \n\u003e\u003e Using eltoo as example. The setup utxo is a simple 2-of-2 multisig, and should not be tagged. This makes it indistinguishable from normal 1-of-1 utxo. The trigger tx, which spends the setup utxo, should be tagged, so the update txs could spend the trigger utxo with NOINPUT. Similarly, all update txs should be tagged, so they could be spent by other update txs and settlement tx with NOINPUT. As the final destination, there is no need to tag in the settlement tx.\n\u003e\u003e \n\u003e\u003e In payer’s perspective, tagging means “I believe this address is for one-time-use only” Since we can’t control how other people manage their addresses, we should never do tagging when paying to other people.\n\u003e\u003e \n\u003e\u003e I mentioned 2 ways of tagging, and they have pros and cons. First of all, tagging in either way should not complicate the eltoo protocol in anyway, nor bring extra block space overhead.\n\u003e\u003e \n\u003e\u003e A clear advantage of tagging with scriptPubKey is we could tag on a per-output basis. However, scriptPubKey tagging is only possible with native-segwit, not P2SH. That means we have to disallow NOINPUT in P2SH-segwit (Otherwise, *all* P2SH addresses would become “risky” for payers) This should be ok for eltoo, since it has no reason to use P2SH-segwit in intermediate txs, which is more expensive.\n\u003e\u003e \n\u003e\u003e Another problem with scriptPubKey tagging is all the existing bech32 implementations will not understand the special tag, and will pay to a tagged address as usual. An upgrade would be needed for them to refuse sending to tagged addresses by default.\n\u003e\u003e \n\u003e\u003e On the other hand, tagging with tx version will also protect P2SH-segwit, and all existing wallets are protected by default. However, it is somewhat a layer violation and you could only tag all or none output in the same tx. Also, as Bitcoin Core has just removed the tx version from the UTXO database, adding it back could be a little bit annoying, but doable.\n\u003e\u003e \n\u003e\u003e There is an extension to the version tagging, which could make NOINPUT even safer. In addition to tagging requirement, NOINPUT will also sign the version of the previous tx. If the wallet always uses a randomised tx version, it makes accidental replay very unlikely. However, that will burn a few more bits in the tx version field.\n\u003e\u003e \n\u003e\u003e While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?\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",
"sig": "e57923905d0ee164e03b77cea56762cc850ef6670d12345d6f049115ba85a2b7b90b9c6dd93433d8aba34141adbd86ef45298605156f9f0ab7eb30e29669cdb4"
}