* [bitcoin-dev] Safer NOINPUT with output tagging
@ 2018-12-13 12:32 Johnson Lau
2018-12-17 15:48 ` Ruben Somsen
` (3 more replies)
0 siblings, 4 replies; 29+ messages in thread
From: Johnson Lau @ 2018-12-13 12:32 UTC (permalink / raw)
To: bitcoin-dev
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?
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2018-12-13 12:32 [bitcoin-dev] Safer NOINPUT with output tagging Johnson Lau
@ 2018-12-17 15:48 ` Ruben Somsen
2018-12-17 20:08 ` Johnson Lau
2018-12-19 22:09 ` Christian Decker
2018-12-21 11:40 ` ZmnSCPxj
` (2 subsequent siblings)
3 siblings, 2 replies; 29+ messages in thread
From: Ruben Somsen @ 2018-12-17 15:48 UTC (permalink / raw)
To: Johnson Lau, Bitcoin Protocol Discussion
Hi Johnson,
The design considerations here seem similar to the ML discussion of
whether Graftroot should be optional [1].
>While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
As far as I can tell it should be compatible with Statechains [2],
since it pretty much mirrors Eltoo in setup.
My understanding is somewhat lacking, so perhaps I am missing the
mark, but it is not completely clear to me how this affects
fungibility if taproot gets added and the setup and trigger tx for
Eltoo get combined into a single transaction. Would the NOINPUT
spending condition be hidden inside the taproot commitment?
Cheers,
Ruben Somsen
[1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016006.html
[2] https://www.reddit.com/r/Bitcoin/comments/9nhjea/eli51525faq_for_statechains_offchain_transfer_of/
On Mon, Dec 17, 2018 at 8:20 PM Johnson Lau via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> 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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2018-12-17 15:48 ` Ruben Somsen
@ 2018-12-17 20:08 ` Johnson Lau
2018-12-18 10:48 ` Johnson Lau
2018-12-19 22:09 ` Christian Decker
1 sibling, 1 reply; 29+ messages in thread
From: Johnson Lau @ 2018-12-17 20:08 UTC (permalink / raw)
To: Ruben Somsen; +Cc: bitcoin-dev
> On 17 Dec 2018, at 11:48 PM, Ruben Somsen <rsomsen@gmail•com> wrote:
>
> Hi Johnson,
>
> The design considerations here seem similar to the ML discussion of
> whether Graftroot should be optional [1].
Yes, but the “tagging” emphasises more on the payer’s side: if the payer cannot guarantee that the payee would never reuse the key, the payer could avoid any NOINPUT-related trouble by tagging properly.
>
>> While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
>
> As far as I can tell it should be compatible with Statechains [2],
> since it pretty much mirrors Eltoo in setup.
>
> My understanding is somewhat lacking, so perhaps I am missing the
> mark, but it is not completely clear to me how this affects
> fungibility if taproot gets added and the setup and trigger tx for
> Eltoo get combined into a single transaction. Would the NOINPUT
> spending condition be hidden inside the taproot commitment?
For the design considerations I mentioned above, the tags must be explicit and configurable by the payer. So it couldn’t be hidden in taproot.
If you don’t care about fungibility, you can always tag your setup output, and makes it ready for NOINPUT spending. Every update will need 2 signatures: a NOINPUT to spend the setup output or an earlier update output, and a NOINPUT to settle the latest update output.
If you care about fungibility, you can’t tag your setup output. Every update will need 3 signatures: a SINGLEINPUT (aka ANYONECANPAY) to spend the setup output, a NOINPUT to spend an earlier update output, and a NOINPUT to settle the latest update output.
(Actually, as soon as you made the first update tx with SINGLEINPUT, you don’t strictly need to make any SINGLEINPUT signatures in the later updates again, as the first update tx (or any update with a SINGLEINPUT signature) could be effectively the trigger tx. While it makes the settlement more expensive, it also means accidentally missing a SINGLEINPUT signature will not lead to any fund loss. So security-wise it’s same as the always-tagging scenario.)
The most interesting observation is: you never have the need to use NOINPUT on an already confirmed UTXO, since nothing about a confirmed UTXO is mutable. And every smart contract must anchor to a confirmed UTXO, or the whole contract is double-spendable. So the ability to NOINPUT-spend a setup output should not be strictly needed. In some (but not all) case it might make the protocol simpler, though.
So the philosophy behind output tagging is “avoid NOINPUT at all cost, until it is truly unavoidable"
>
> Cheers,
> Ruben Somsen
>
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/016006.html
> [2] https://www.reddit.com/r/Bitcoin/comments/9nhjea/eli51525faq_for_statechains_offchain_transfer_of/
>
> On Mon, Dec 17, 2018 at 8:20 PM Johnson Lau via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> 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@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2018-12-17 20:08 ` Johnson Lau
@ 2018-12-18 10:48 ` Johnson Lau
0 siblings, 0 replies; 29+ messages in thread
From: Johnson Lau @ 2018-12-18 10:48 UTC (permalink / raw)
To: Johnson Lau, bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 5235 bytes --]
> On 18 Dec 2018, at 4:08 AM, Johnson Lau via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>
>
>> On 17 Dec 2018, at 11:48 PM, Ruben Somsen <rsomsen@gmail•com <mailto:rsomsen@gmail•com>> wrote:
>>
>> Hi Johnson,
>>
>> The design considerations here seem similar to the ML discussion of
>> whether Graftroot should be optional [1].
>
> Yes, but the “tagging” emphasises more on the payer’s side: if the payer cannot guarantee that the payee would never reuse the key, the payer could avoid any NOINPUT-related trouble by tagging properly.
>
>>
>>> While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
>>
>> As far as I can tell it should be compatible with Statechains [2],
>> since it pretty much mirrors Eltoo in setup.
>>
>> My understanding is somewhat lacking, so perhaps I am missing the
>> mark, but it is not completely clear to me how this affects
>> fungibility if taproot gets added and the setup and trigger tx for
>> Eltoo get combined into a single transaction. Would the NOINPUT
>> spending condition be hidden inside the taproot commitment?
>
> For the design considerations I mentioned above, the tags must be explicit and configurable by the payer. So it couldn’t be hidden in taproot.
>
> If you don’t care about fungibility, you can always tag your setup output, and makes it ready for NOINPUT spending. Every update will need 2 signatures: a NOINPUT to spend the setup output or an earlier update output, and a NOINPUT to settle the latest update output.
>
> If you care about fungibility, you can’t tag your setup output. Every update will need 3 signatures: a SINGLEINPUT (aka ANYONECANPAY) to spend the setup output, a NOINPUT to spend an earlier update output, and a NOINPUT to settle the latest update output.
>
> (Actually, as soon as you made the first update tx with SINGLEINPUT, you don’t strictly need to make any SINGLEINPUT signatures in the later updates again, as the first update tx (or any update with a SINGLEINPUT signature) could be effectively the trigger tx. While it makes the settlement more expensive, it also means accidentally missing a SINGLEINPUT signature will not lead to any fund loss. So security-wise it’s same as the always-tagging scenario.)
>
> The most interesting observation is: you never have the need to use NOINPUT on an already confirmed UTXO, since nothing about a confirmed UTXO is mutable. And every smart contract must anchor to a confirmed UTXO, or the whole contract is double-spendable. So the ability to NOINPUT-spend a setup output should not be strictly needed. In some (but not all) case it might make the protocol simpler, though.
>
> So the philosophy behind output tagging is “avoid NOINPUT at all cost, until it is truly unavoidable"
>
After thinking more carefully, I believe output tagging could have no adverse effect on eltoo.
Consider a system without tagging, where you could always spend an output with NOINPUT. Under taproot, state update could be made in 2 ways:
a) Making 2 sigs for each update. One sig is a “script path” locktime NOINPUT spending of the setup output or an earlier update output. One sig is a “key path” relative-locktime NOINPUT spending of the new update output. In taproot terminology, “key path” means direct spending with the scriptPubKey, and “script path” means revealing the script hidden in taproot. Key path spending is always cheaper.
b) Making 3 sigs for each update. One sig is a key path SINGLEINPUT (aka ANYONECANPAY) or NOINPUT spending of the setup output, without any locktime. One sig is a script path locktime NOINPUT spending of an earlier update output (if this is not the first update). One sig is a key path relative-locktime NOINPUT spending of the new update output
Note that in b), the first signature could be either SINGLEINPUT or NOINPUT, and they just work as fine. So SINGLEINPUT should be used to avoid unnecessary replayability.
In the case of uncooperative channel closing, b) is always cheaper than a), since this first broadcast signature will be a key path signature. Also, b) has better privacy if no one is cheating (only the last update is broadcast). The only information leaked in b) is the use of SINGLEINPUT and the subsequent relative-locktime NOINPUT. However, the script path signature in a) will leak the state number, which is the maximum number of updates made in this channel.
In conclusion, b) is cheaper and more private, but it is more complex by requiring 3 sigs per update rather than 2. I think it is an acceptable tradeoff. (And as I mentioned in my last mail, missing some SINGLEINPUT sigs is not the end of the world. As long as you find one SINGLEINPUT sig in your backup, it safely falls back to the trigger tx model)
What if we require output tagging? For privacy reason you shouldn’t tag your setup tx, so the setup output could not be spent with NOINPUT. Option a) doesn’t work, but b) only requires SINGLEINPUT and has no problem. So in a fee-minimising and privacy-maximising eltoo design, output tagging should have no adverse effect.
[-- Attachment #2: Type: text/html, Size: 15700 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2018-12-17 15:48 ` Ruben Somsen
2018-12-17 20:08 ` Johnson Lau
@ 2018-12-19 22:09 ` Christian Decker
2018-12-20 11:00 ` Johnson Lau
1 sibling, 1 reply; 29+ messages in thread
From: Christian Decker @ 2018-12-19 22:09 UTC (permalink / raw)
To: Ruben Somsen, Bitcoin Protocol Discussion, Johnson Lau,
Bitcoin Protocol Discussion
Ruben Somsen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
writes:
> Hi Johnson,
>
> The design considerations here seem similar to the ML discussion of
> whether Graftroot should be optional [1].
>
>>While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
>
> As far as I can tell it should be compatible with Statechains [2],
> since it pretty much mirrors Eltoo in setup.
>
> My understanding is somewhat lacking, so perhaps I am missing the
> mark, but it is not completely clear to me how this affects
> fungibility if taproot gets added and the setup and trigger tx for
> Eltoo get combined into a single transaction. Would the NOINPUT
> spending condition be hidden inside the taproot commitment?
I'm not aware of a way to combine the setup and trigger transaction. The
trigger transaction was introduced in order to delay the start of the
timeouts until a later time, to avoid having an absolute lifetime limit
and having really huge timeout. If we were to combine the trigger
transaction with the setup transaction (which is broadcast during
channel creation), all of those timeouts would start counting down
immediately, and we could just skip the trigger transaction
altogether. It'd be more interesting to combine update and trigger
transactions in a sort of cut-through combination, but that doesn't seem
possible outside of Mimblewimble.
Cheers,
Christian
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2018-12-19 22:09 ` Christian Decker
@ 2018-12-20 11:00 ` Johnson Lau
2018-12-20 17:20 ` Christian Decker
0 siblings, 1 reply; 29+ messages in thread
From: Johnson Lau @ 2018-12-20 11:00 UTC (permalink / raw)
To: Christian Decker; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2938 bytes --]
> On 20 Dec 2018, at 6:09 AM, Christian Decker <decker.christian@gmail•com> wrote:
>
> Ruben Somsen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org <mailto:bitcoin-dev@lists•linuxfoundation.org>>
> writes:
>
>> Hi Johnson,
>>
>> The design considerations here seem similar to the ML discussion of
>> whether Graftroot should be optional [1].
>>
>>> While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
>>
>> As far as I can tell it should be compatible with Statechains [2],
>> since it pretty much mirrors Eltoo in setup.
>>
>> My understanding is somewhat lacking, so perhaps I am missing the
>> mark, but it is not completely clear to me how this affects
>> fungibility if taproot gets added and the setup and trigger tx for
>> Eltoo get combined into a single transaction. Would the NOINPUT
>> spending condition be hidden inside the taproot commitment?
>
> I'm not aware of a way to combine the setup and trigger transaction. The
> trigger transaction was introduced in order to delay the start of the
> timeouts until a later time, to avoid having an absolute lifetime limit
> and having really huge timeout. If we were to combine the trigger
> transaction with the setup transaction (which is broadcast during
> channel creation), all of those timeouts would start counting down
> immediately, and we could just skip the trigger transaction
> altogether. It'd be more interesting to combine update and trigger
> transactions in a sort of cut-through combination, but that doesn't seem
> possible outside of Mimblewimble.
>
> Cheers,
> Christian
Correct me if I’m wrong.
For the sake of simplicity, in the following I assume BIP118, 143, and 141-P2WSH are used (i.e. no taproot). Also, I skipped all the possible optimisations.
1. A and B are going to setup a channel.
2. They create one setup tx, with a setup output of the following script: <s> CLTV DROP 2 Au Bu 2 CHECKMULTISIG. Do not sign
3. They create the update tx 0, spending the setup output with NOINPUT and locktime = s+1, to the update-0 output with the script:
IF 2 As0 Bs0 2 CHECKMULTISIG ELSE <s+1> CLTV DROP 2 Au Bu 2 CHECKMULTISIG ENDIF
4. They create the settlement tx 0, spending the update-0 output with As0 and Bs0 using BIP68 relative-locktime, with 2 settlement outputs
5. They sign the setup tx and let it confirm
6. To update, they create the update tx 1, spending the setup output with NOINPUT and locktime = s+2, to the update-1 output with the script:
IF 2 As1 Bs1 2 CHECKMULTISIG ELSE <s+2> CLTV DROP 2 Au Bu 2 CHECKMULTISIG ENDIF
and create the settlement tx 1, spending the update-1 output with As1 and Bs1 using relative-locktime, with 2 settlement outputs
7. To close the channel, broadcast update tx 1. Wait for several confirmations. And broadcast settlement-tx-1
[-- Attachment #2: Type: text/html, Size: 15958 bytes --]
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2018-12-20 11:00 ` Johnson Lau
@ 2018-12-20 17:20 ` Christian Decker
2018-12-20 18:04 ` Johnson Lau
0 siblings, 1 reply; 29+ messages in thread
From: Christian Decker @ 2018-12-20 17:20 UTC (permalink / raw)
To: Johnson Lau; +Cc: bitcoin-dev
Johnson Lau <jl2012@xbt•hk> writes:
> Correct me if I’m wrong.
>
> For the sake of simplicity, in the following I assume BIP118, 143, and
> 141-P2WSH are used (i.e. no taproot). Also, I skipped all the possible
> optimisations.
>
> 1. A and B are going to setup a channel.
>
> 2. They create one setup tx, with a setup output of the following
> script: <s> CLTV DROP 2 Au Bu 2 CHECKMULTISIG. Do not sign
If we are using a trigger transaction the output of the setup
transaction would simply be `2 Au Bu 2 OP_CMS`. If we were to use a CLTV
in there we would not have an option to later attach a collaborative
close transaction that is valid immediately. Furthermore the timeout of
the CLTV would start ticking down the exact moment the setup transaction
is confirmed, hence whatever effect we are trying to achieve with that
timelock is limited, and we have a limit to the total lifetime of the
channel.
> 3. They create the update tx 0, spending the setup output with NOINPUT
> and locktime = s+1, to the update-0 output with the script: IF 2 As0
> Bs0 2 CHECKMULTISIG ELSE <s+1> CLTV DROP 2 Au Bu 2 CHECKMULTISIG ENDIF
Update 0 is usually what I call the trigger transaction. It takes the
2-of-2 multisig from the setup transaction and translates it into the
two-branch output that further updates or settlements can be attached
to. The settlement transaction attached to the trigger / update 0
reflects the initial state of the channel, i.e., if A added 2 BTC and B
added 1 BTC then settlement 0 will have 2 outputs with value 2 and 1
respectively, with the user's keys (this can also be considered the
refund in case of one party disappearing right away).
The second branch in the script you posted is the update branch, which is
not encumbered by a CSV, while the first branch is the one encumbered
with the CSV and is called the settlement branch since we'll be
attaching settlement txs to it.
The CLTV looks correct to me and ensures that we can only attach any
state >= s+1.
So just to show the output script for state `i` how I think they are
correct:
```
OP_IF
<timeout> OP_CSV 2 <As_i> <Bs_i> 2 OP_CHECKMULTISIG
OP_ELSE
<s+1> OP_CLTV OP_DROP 2 <Au> <Bu> 2 OP_CHECKMULTISIG
```
And the input scripts for the update tx and the settlement tx
respectively would be:
```
OP_FALSE <Sig_Bu> <Sig_Au>
```
and
```
OP_TRUE <Sig_Bs_i> <Sig_As_i>
```
> 4. They create the settlement tx 0, spending the update-0 output with
> As0 and Bs0 using BIP68 relative-locktime, with 2 settlement outputs
If I'm not mistaken the CSV needs to be in the scriptPubkey (or P2WSH
equivalent) since segwit witnesses only allow pushes. Hence the script
in point 3 needs to add that :-)
> 5. They sign the setup tx and let it confirm
They also need to sign (but not broadcast) update_0, in order to allow
either party to initiate the closure if the counterparty become
unresponsive. The order in which settlement_0 and update_0 are signed is
not important by the way, so we can just batch these. The important part
is that signing the setup acts as a commitment.
> 6. To update, they create the update tx 1, spending the setup output
> with NOINPUT and locktime = s+2, to the update-1 output with the
> script: IF 2 As1 Bs1 2 CHECKMULTISIG ELSE <s+2> CLTV DROP 2 Au Bu 2
> CHECKMULTISIG ENDIF and create the settlement tx 1, spending the
> update-1 output with As1 and Bs1 using relative-locktime, with 2
> settlement outputs
The output script of the updates are identical to the ones in the
trigger or update_0 transaction, so they'd also need a CSV (this is why
committing to the script structure with masking still works).
> 7. To close the channel, broadcast update tx 1. Wait for several
> confirmations. And broadcast settlement-tx-1
We have to differentiate 2 cases: collaborative close and unilateral
close. In the collaborative close we come to a mutual agreement that
we'd like to take this latest state and settle. So we create a new
transaction that spends the setup output, and add outputs according to
the state we agreed upon, and we sign it. This transaction is
immediately valid, and does not need to be signed with NOINPUT. So all
the chain sees is a setup transaction with some inputs and one multisig
output (singlesig with Schnorr) and a collaborative close transaction
that spends the setup (also not signed with NOINPUT). About as normal as
transactions in Bitcoin can get.
In the unilateral case, one party isn't there anymore, or refuses to
sign. So we take the trigger transaction (not signed with NOINPUT) and
the latest update_n transaction (signed with NOINPUT) and broadcast
them. Then we wait for the CSV timeout to expire, and then send the
settlement transaction, which gives us the enforcement of the latest
state that we agreed on. The chain sees a setup transaction and a
trigger transaction (normal transactions for all intents and purposes,
except for the output script of the trigger, but we can hide that with
taproot), followed by two more transactions which are signed with
NOINPUT. So 4 transactions in the worst case, of which 2 are special,
and 2 transactions in the good case.
So all in all I think it's a tradeoff between having a larger on-chain
footprint (4 txs vs 3 txs in the worst case) and putting a fixed
lifetime on the channel for the refund case if one party disappears
right away. We'll probably find out what acceptable parameters are for
these and where the cutoff points are :-)
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2018-12-20 17:20 ` Christian Decker
@ 2018-12-20 18:04 ` Johnson Lau
2018-12-21 11:15 ` Christian Decker
0 siblings, 1 reply; 29+ messages in thread
From: Johnson Lau @ 2018-12-20 18:04 UTC (permalink / raw)
To: Christian Decker; +Cc: bitcoin-dev
> On 21 Dec 2018, at 1:20 AM, Christian Decker <decker.christian@gmail•com> wrote:
>
> Johnson Lau <jl2012@xbt•hk> writes:
>> Correct me if I’m wrong.
>>
>> For the sake of simplicity, in the following I assume BIP118, 143, and
>> 141-P2WSH are used (i.e. no taproot). Also, I skipped all the possible
>> optimisations.
>>
>> 1. A and B are going to setup a channel.
>>
>> 2. They create one setup tx, with a setup output of the following
>> script: <s> CLTV DROP 2 Au Bu 2 CHECKMULTISIG. Do not sign
>
> If we are using a trigger transaction the output of the setup
> transaction would simply be `2 Au Bu 2 OP_CMS`. If we were to use a CLTV
> in there we would not have an option to later attach a collaborative
> close transaction that is valid immediately. Furthermore the timeout of
> the CLTV would start ticking down the exact moment the setup transaction
> is confirmed, hence whatever effect we are trying to achieve with that
> timelock is limited, and we have a limit to the total lifetime of the
> channel.
CLTV is absolute locktime. Only CSV will have the “time ticking” issue, but that’s not used here. The required locktime <s> is many years in the past. To collaboratively close, you just need to sign with SIGHASH_ALL, with a locktime s+1.
>
>> 3. They create the update tx 0, spending the setup output with NOINPUT
>> and locktime = s+1, to the update-0 output with the script: IF 2 As0
>> Bs0 2 CHECKMULTISIG ELSE <s+1> CLTV DROP 2 Au Bu 2 CHECKMULTISIG ENDIF
>
> Update 0 is usually what I call the trigger transaction. It takes the
> 2-of-2 multisig from the setup transaction and translates it into the
> two-branch output that further updates or settlements can be attached
> to. The settlement transaction attached to the trigger / update 0
> reflects the initial state of the channel, i.e., if A added 2 BTC and B
> added 1 BTC then settlement 0 will have 2 outputs with value 2 and 1
> respectively, with the user's keys (this can also be considered the
> refund in case of one party disappearing right away).
>
> The second branch in the script you posted is the update branch, which is
> not encumbered by a CSV, while the first branch is the one encumbered
> with the CSV and is called the settlement branch since we'll be
> attaching settlement txs to it.
>
> The CLTV looks correct to me and ensures that we can only attach any
> state >= s+1.
>
> So just to show the output script for state `i` how I think they are
> correct:
>
> ```
> OP_IF
> <timeout> OP_CSV 2 <As_i> <Bs_i> 2 OP_CHECKMULTISIG
> OP_ELSE
> <s+1> OP_CLTV OP_DROP 2 <Au> <Bu> 2 OP_CHECKMULTISIG
> ```
>
> And the input scripts for the update tx and the settlement tx
> respectively would be:
>
> ```
> OP_FALSE <Sig_Bu> <Sig_Au>
> ```
>
> and
>
> ```
> OP_TRUE <Sig_Bs_i> <Sig_As_i>
> ```
I think the use of OP_CSV (BIP112) is not needed here (although it doesn’t really harm except taking a few more bytes). All you need is to sign the settlement tx with a BIP68 relative locktime. Since this is a 2-of-2 branch, both parties need to agree with the relative locktime, so it is not necessary to restrict it through OP_CSV
>
>> 4. They create the settlement tx 0, spending the update-0 output with
>> As0 and Bs0 using BIP68 relative-locktime, with 2 settlement outputs
>
> If I'm not mistaken the CSV needs to be in the scriptPubkey (or P2WSH
> equivalent) since segwit witnesses only allow pushes. Hence the script
> in point 3 needs to add that :-)
I believe you confused OP_CSV (BIP112) with BIP68. Relative locktime is enforced by BIP68 (i.e. setting the nSequence). OP_CSV indirectly enforces relative-locktime by checking the value of nSequence. BIP68 could work standalone without OP_CSV, while OP_CSV is dependant on BIP68. In the case of n-of-n eltoo state update, OP_CSV is not needed because all n parties need to agree with the same nSequence value of the settlement tx. This is enough to make sure the settlement tx has delayed settlement.
>
>> 5. They sign the setup tx and let it confirm
>
> They also need to sign (but not broadcast) update_0, in order to allow
> either party to initiate the closure if the counterparty become
> unresponsive. The order in which settlement_0 and update_0 are signed is
> not important by the way, so we can just batch these. The important part
> is that signing the setup acts as a commitment.
Sure. This is obvious.
>
>> 6. To update, they create the update tx 1, spending the setup output
>> with NOINPUT and locktime = s+2, to the update-1 output with the
>> script: IF 2 As1 Bs1 2 CHECKMULTISIG ELSE <s+2> CLTV DROP 2 Au Bu 2
>> CHECKMULTISIG ENDIF and create the settlement tx 1, spending the
>> update-1 output with As1 and Bs1 using relative-locktime, with 2
>> settlement outputs
>
> The output script of the updates are identical to the ones in the
> trigger or update_0 transaction, so they'd also need a CSV (this is why
> committing to the script structure with masking still works).
>
>> 7. To close the channel, broadcast update tx 1. Wait for several
>> confirmations. And broadcast settlement-tx-1
>
> We have to differentiate 2 cases: collaborative close and unilateral
> close. In the collaborative close we come to a mutual agreement that
> we'd like to take this latest state and settle. So we create a new
> transaction that spends the setup output, and add outputs according to
> the state we agreed upon, and we sign it. This transaction is
> immediately valid, and does not need to be signed with NOINPUT. So all
> the chain sees is a setup transaction with some inputs and one multisig
> output (singlesig with Schnorr) and a collaborative close transaction
> that spends the setup (also not signed with NOINPUT). About as normal as
> transactions in Bitcoin can get.
Collaborative close is always simple as I explained in the beginning
>
> In the unilateral case, one party isn't there anymore, or refuses to
> sign. So we take the trigger transaction (not signed with NOINPUT) and
> the latest update_n transaction (signed with NOINPUT) and broadcast
> them. Then we wait for the CSV timeout to expire, and then send the
> settlement transaction, which gives us the enforcement of the latest
> state that we agreed on. The chain sees a setup transaction and a
> trigger transaction (normal transactions for all intents and purposes,
> except for the output script of the trigger, but we can hide that with
> taproot), followed by two more transactions which are signed with
> NOINPUT. So 4 transactions in the worst case, of which 2 are special,
> and 2 transactions in the good case.
>
>
> So all in all I think it's a tradeoff between having a larger on-chain
> footprint (4 txs vs 3 txs in the worst case) and putting a fixed
> lifetime on the channel for the refund case if one party disappears
> right away. We'll probably find out what acceptable parameters are for
> these and where the cutoff points are :-)
If no one is cheating (i.e. only the last update is broadcast), you always need only 3 txs. Think about this: every update tx could be a trigger tx, and you can settle directly on a trigger tx, so effectively you eliminate trigger tx.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2018-12-20 18:04 ` Johnson Lau
@ 2018-12-21 11:15 ` Christian Decker
2018-12-21 16:21 ` Johnson Lau
0 siblings, 1 reply; 29+ messages in thread
From: Christian Decker @ 2018-12-21 11:15 UTC (permalink / raw)
To: Johnson Lau; +Cc: bitcoin-dev
Johnson Lau <jl2012@xbt•hk> writes:
>> If we are using a trigger transaction the output of the setup
>> transaction would simply be `2 Au Bu 2 OP_CMS`. If we were to use a CLTV
>> in there we would not have an option to later attach a collaborative
>> close transaction that is valid immediately. Furthermore the timeout of
>> the CLTV would start ticking down the exact moment the setup transaction
>> is confirmed, hence whatever effect we are trying to achieve with that
>> timelock is limited, and we have a limit to the total lifetime of the
>> channel.
>
> CLTV is absolute locktime. Only CSV will have the “time ticking”
> issue, but that’s not used here. The required locktime <s> is many
> years in the past. To collaboratively close, you just need to sign
> with SIGHASH_ALL, with a locktime s+1.
Correct, we're using the CLTV here as a weird "compare two numbers that
are committed to in the signatures" operation, by using locktimes in the
past as you correctly point out.
> I think the use of OP_CSV (BIP112) is not needed here (although it
> doesn’t really harm except taking a few more bytes). All you need is
> to sign the settlement tx with a BIP68 relative locktime. Since this
> is a 2-of-2 branch, both parties need to agree with the relative
> locktime, so it is not necessary to restrict it through OP_CSV
I keep forgetting about BIP68, but you're right, that should be
sufficient for our use-case and would safe us a few bytes.
>> In the unilateral case, one party isn't there anymore, or refuses to
>> sign. So we take the trigger transaction (not signed with NOINPUT) and
>> the latest update_n transaction (signed with NOINPUT) and broadcast
>> them. Then we wait for the CSV timeout to expire, and then send the
>> settlement transaction, which gives us the enforcement of the latest
>> state that we agreed on. The chain sees a setup transaction and a
>> trigger transaction (normal transactions for all intents and purposes,
>> except for the output script of the trigger, but we can hide that with
>> taproot), followed by two more transactions which are signed with
>> NOINPUT. So 4 transactions in the worst case, of which 2 are special,
>> and 2 transactions in the good case.
>>
>>
>> So all in all I think it's a tradeoff between having a larger on-chain
>> footprint (4 txs vs 3 txs in the worst case) and putting a fixed
>> lifetime on the channel for the refund case if one party disappears
>> right away. We'll probably find out what acceptable parameters are for
>> these and where the cutoff points are :-)
>
> If no one is cheating (i.e. only the last update is broadcast), you
> always need only 3 txs. Think about this: every update tx could be a
> trigger tx, and you can settle directly on a trigger tx, so
> effectively you eliminate trigger tx.
I seem to keep mentally mixing different variants of the protocol in my
head. You are of course correct that the trigger and the update can be
considered the same, hence the 3 txs limit is right. Sorry for the
confusion :-(
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2018-12-13 12:32 [bitcoin-dev] Safer NOINPUT with output tagging Johnson Lau
2018-12-17 15:48 ` Ruben Somsen
@ 2018-12-21 11:40 ` ZmnSCPxj
2018-12-21 15:37 ` Johnson Lau
2019-02-08 19:01 ` Jonas Nick
2019-02-19 19:04 ` Luke Dashjr
3 siblings, 1 reply; 29+ messages in thread
From: ZmnSCPxj @ 2018-12-21 11:40 UTC (permalink / raw)
To: Johnson Lau, Bitcoin Protocol Discussion
Good morning Johnson,
> 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:
First off, this is a very good idea I think.
> While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
It prevents use of SIGHASH_NOINPUT to support walletless offchain protocols.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015925.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015926.html
In brief, this idea of "walletless offchain software" is motivated by the fact, that various onchain wallets exist with many features.
For instance, privacy-enhancement as in Samourai/Wasabi/etc.
And so on.
There are requests to include such features in e.g. Lightning software, for example: https://github.com/ElementsProject/lightning/issues/2105
But it is enough of a challenge to implement Lightning, without the additional burden of implementing nice onchain features like coin control and change labelling.
It would be best if we can retain features from an onchain wallet, while using our coin on an offchain system.
Further, it would allow onchain wallet developers to focus and gain expertise on onchain wallet features, and, vice versa, for offchain walletless software developers to focus on offchain software features.
The core idea comes from the way that offchain systems need to be set up:
1. First we agree on a (currently unconfirmed) txid and output number on which to anchor our offchain system (the funding transaction).
2. Then we sign a backout transaction (the initial commitment transactions under Poon-Dryja, or the timelock branches for CoinSwapCS, or the initial kickoff-settlement transactions for Decker-Russell-Osuntokun) spending the agreed TXO, to return the money back to the owner(s) in case some participant aborts the setting up of the offchain system.
3. Then we sign and broadcast the funding transaction.
Unfortunately, the typical onchain wallet has a very simple and atomic (uncuttable) process for making transactions:
1. Make, sign, and broadcast transaction with an output paying to the desired address.
Thus a typical onchain wallet cannot be used to set up a funding transaction for an offchain system.
Now suppose we take advantage of `SIGHASH_NOINPUT`, and modify our offchain system setup as below:
1. First we agree on a N-of-N pubkey on which to anchor our offchain system (the funding address).
2. Then we sign (with SIGHASH_NOINPUT) a backout transaction (the initial commitment transactions under Poon-Dryja, or the timelock branches for CoinSwapCS, or the initial kickoff-settlement transactions for Decker-Russell-Osuntokun), spending the agreed funding address, to return the money back to the owner(s) in case some participant aborts the setting up of the offchain system.
3. Make, sign, and broadcast transaction with an output paying to the funding address. This step can be done by any typical onchain wallet.
Note that only the starting backout transaction is *required* to sign with `SIGHASH_NOINPUT`.
For instance, a Poon-Dryja channel may sign succeeding commitment transactions with `SIGHASH_ALL`.
Finally, only in case of disaster (some participant aborts before the offchain system is set up) is the `SIGHASH_NOINPUT` backoff transaction broadcasted.
A "normal close" of the offchain system can be signed with typical `SIGHASH_ALL` for no fungibility problems.
With this, an offchain system need not require its implementing software to implement its own wallet.
Further, onchain wallets can directly put its funds into an offchain system, without requiring an onchain transfer to an offchain software wallet.
This can be helpful when building overall software.
We might take any commodity onchain wallet and any commodity offchain software, and we can integrate them easily to create a seamless wallet experience that allows spending and receiving onchain and offchain.
Further, improvements in one software component do not require re-building of the other software component.
--
That said:
1. For Lightning and similar systems, the fact that the Lightning node will give you an address that, when paid using any commodity onchain wallet, opens a channel, means that people will make wrong assumptions.
In particular, they are likely to assume that address reuse is safe and will attempt to "refill" their channel by paying to the same address again in the future.
From this alone, we can immediately see that this idea is pointless.
2. Dual-funding, which for some reason is asked for as a feature, cannot be done with this anyway.
3. It may be better to provide some standard way of signing transactions without broadcasting them.
This would still allow similar separation of concerns between onchain and offchain software components.
So output tagging still seems fine to me, even if this particular use cannot be supported.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2018-12-21 11:40 ` ZmnSCPxj
@ 2018-12-21 15:37 ` Johnson Lau
2018-12-22 14:25 ` ZmnSCPxj
0 siblings, 1 reply; 29+ messages in thread
From: Johnson Lau @ 2018-12-21 15:37 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: bitcoin-dev
> On 21 Dec 2018, at 7:40 PM, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
>
> Good morning Johnson,
>
>> 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:
>
> First off, this is a very good idea I think.
>
>
>> While this seems fully compatible with eltoo, is there any other proposals require NOINPUT, and is adversely affected by either way of tagging?
>
>
> It prevents use of SIGHASH_NOINPUT to support walletless offchain protocols.
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015925.html
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-May/015926.html
>
> In brief, this idea of "walletless offchain software" is motivated by the fact, that various onchain wallets exist with many features.
> For instance, privacy-enhancement as in Samourai/Wasabi/etc.
> And so on.
> There are requests to include such features in e.g. Lightning software, for example: https://github.com/ElementsProject/lightning/issues/2105
> But it is enough of a challenge to implement Lightning, without the additional burden of implementing nice onchain features like coin control and change labelling.
>
> It would be best if we can retain features from an onchain wallet, while using our coin on an offchain system.
> Further, it would allow onchain wallet developers to focus and gain expertise on onchain wallet features, and, vice versa, for offchain walletless software developers to focus on offchain software features.
>
> The core idea comes from the way that offchain systems need to be set up:
>
> 1. First we agree on a (currently unconfirmed) txid and output number on which to anchor our offchain system (the funding transaction).
> 2. Then we sign a backout transaction (the initial commitment transactions under Poon-Dryja, or the timelock branches for CoinSwapCS, or the initial kickoff-settlement transactions for Decker-Russell-Osuntokun) spending the agreed TXO, to return the money back to the owner(s) in case some participant aborts the setting up of the offchain system.
> 3. Then we sign and broadcast the funding transaction.
>
> Unfortunately, the typical onchain wallet has a very simple and atomic (uncuttable) process for making transactions:
>
> 1. Make, sign, and broadcast transaction with an output paying to the desired address.
>
> Thus a typical onchain wallet cannot be used to set up a funding transaction for an offchain system.
>
> Now suppose we take advantage of `SIGHASH_NOINPUT`, and modify our offchain system setup as below:
>
> 1. First we agree on a N-of-N pubkey on which to anchor our offchain system (the funding address).
> 2. Then we sign (with SIGHASH_NOINPUT) a backout transaction (the initial commitment transactions under Poon-Dryja, or the timelock branches for CoinSwapCS, or the initial kickoff-settlement transactions for Decker-Russell-Osuntokun), spending the agreed funding address, to return the money back to the owner(s) in case some participant aborts the setting up of the offchain system.
> 3. Make, sign, and broadcast transaction with an output paying to the funding address. This step can be done by any typical onchain wallet.
>
> Note that only the starting backout transaction is *required* to sign with `SIGHASH_NOINPUT`.
> For instance, a Poon-Dryja channel may sign succeeding commitment transactions with `SIGHASH_ALL`.
> Finally, only in case of disaster (some participant aborts before the offchain system is set up) is the `SIGHASH_NOINPUT` backoff transaction broadcasted.
> A "normal close" of the offchain system can be signed with typical `SIGHASH_ALL` for no fungibility problems.
>
> With this, an offchain system need not require its implementing software to implement its own wallet.
> Further, onchain wallets can directly put its funds into an offchain system, without requiring an onchain transfer to an offchain software wallet.
>
> This can be helpful when building overall software.
> We might take any commodity onchain wallet and any commodity offchain software, and we can integrate them easily to create a seamless wallet experience that allows spending and receiving onchain and offchain.
> Further, improvements in one software component do not require re-building of the other software component.
>
> --
>
> That said:
>
> 1. For Lightning and similar systems, the fact that the Lightning node will give you an address that, when paid using any commodity onchain wallet, opens a channel, means that people will make wrong assumptions.
> In particular, they are likely to assume that address reuse is safe and will attempt to "refill" their channel by paying to the same address again in the future.
> From this alone, we can immediately see that this idea is pointless.
> 2. Dual-funding, which for some reason is asked for as a feature, cannot be done with this anyway.
> 3. It may be better to provide some standard way of signing transactions without broadcasting them.
> This would still allow similar separation of concerns between onchain and offchain software components.
>
> So output tagging still seems fine to me, even if this particular use cannot be supported.
>
> Regards,
> ZmnSCPxj
>
>
Generally speaking, I think walletless protocol is needed only when you want to rely a third party to open a offchain smart contract. It could be coinswap, eltoo, or anything similar.
However, since NOINPUT still commits to the input value, if the third party paid an unexpected value, even off by 1 satoshi, the smart contract is toast. It is not uncommon as some exchanges would deduct fees from withdrawal amount. Since we don’t have a social norm to require the payer to always pay the exact requested amount, the exchange might not be liable for the loss.
It is of course possible to have a NOINPUT_NOAMOUNT, but I can’t see any chance for this being accepted.
So, unless the payer is liable for paying a wrong amount, walletless contract opening is unreliable.
Johnson
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2018-12-21 11:15 ` Christian Decker
@ 2018-12-21 16:21 ` Johnson Lau
0 siblings, 0 replies; 29+ messages in thread
From: Johnson Lau @ 2018-12-21 16:21 UTC (permalink / raw)
To: Christian Decker; +Cc: bitcoin-dev
> On 21 Dec 2018, at 7:15 PM, Christian Decker <decker.christian@gmail•com> wrote:
>
> Johnson Lau <jl2012@xbt•hk> writes:
>
>> I think the use of OP_CSV (BIP112) is not needed here (although it
>> doesn’t really harm except taking a few more bytes). All you need is
>> to sign the settlement tx with a BIP68 relative locktime. Since this
>> is a 2-of-2 branch, both parties need to agree with the relative
>> locktime, so it is not necessary to restrict it through OP_CSV
>
> I keep forgetting about BIP68, but you're right, that should be
> sufficient for our use-case and would safe us a few bytes.
>
With taproot, this actually saves a lot more than a few bytes. For each update, you will make 3 signatures. One is a SIGHASH_ALL spending the setup TXO with no locktime. One is a NOINPUT spending a previous update TXO with absolute locktime. One is a NOINPUT spending the latest update TXO with relative locktime. For the first and third signatures, you will just sign directly with the scriptPubKey, without revealing the hidden taproot script. The second signature will reveal the taproot script, but it is needed only when someone published an outdated update tx.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2018-12-21 15:37 ` Johnson Lau
@ 2018-12-22 14:25 ` ZmnSCPxj
2018-12-22 16:56 ` Johnson Lau
0 siblings, 1 reply; 29+ messages in thread
From: ZmnSCPxj @ 2018-12-22 14:25 UTC (permalink / raw)
To: Johnson Lau; +Cc: bitcoin-dev
Good morning Johnson,
> Generally speaking, I think walletless protocol is needed only when you want to rely a third party to open a offchain smart contract. It could be coinswap, eltoo, or anything similar.
I think a third party would be pointless in general, but then I am strongly against custodiality.
The idea is that you have some kind of hardware wallet or similar "somewhat cold" storage *that you control yourself*, and crate channels for your hot offchain Lightning wallet, without adding more transactions from your somewhat-cold storage to your hot offchain Lightning wallet on the blockchain.
Then you could feed a set of addresses to the hot offchain wallet (addresses your somewhat-cold storage controls) so that when channels are closed, the funds go to your somwhat-cold storage.
I also doubt that any custodial service would want to mess around with deducting funds from what the user input as the desired payment. I have not seen a custodial service that does so (this is not a scientific study; I rarely use custodial services); custodial services will deduct more from your balance than what you send, but will not modify what you send, and will prevent you from sending more than your balance minus the fees they charge for sending onchain.
Even today, custodial services deducting from your sent value (rather than the balance remaining after you send) would be problematic when interacting with merchants (or their payment processors) accepting onchain payments; the merchant would refuse to service a lower value than what it charges and it may be very technically difficult to recover such funds from the merchant.
I expect such a custodial service would quickly lose users, but the world surprises me often.
Regards,
ZmnSCPxj
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2018-12-22 14:25 ` ZmnSCPxj
@ 2018-12-22 16:56 ` Johnson Lau
2018-12-24 11:47 ` ZmnSCPxj
0 siblings, 1 reply; 29+ messages in thread
From: Johnson Lau @ 2018-12-22 16:56 UTC (permalink / raw)
To: ZmnSCPxj; +Cc: bitcoin-dev
> On 22 Dec 2018, at 10:25 PM, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
>
> Good morning Johnson,
>
>> Generally speaking, I think walletless protocol is needed only when you want to rely a third party to open a offchain smart contract. It could be coinswap, eltoo, or anything similar.
>
> I think a third party would be pointless in general, but then I am strongly against custodiality.
>
> The idea is that you have some kind of hardware wallet or similar "somewhat cold" storage *that you control yourself*, and crate channels for your hot offchain Lightning wallet, without adding more transactions from your somewhat-cold storage to your hot offchain Lightning wallet on the blockchain.
>
> Then you could feed a set of addresses to the hot offchain wallet (addresses your somewhat-cold storage controls) so that when channels are closed, the funds go to your somwhat-cold storage.
>
> I also doubt that any custodial service would want to mess around with deducting funds from what the user input as the desired payment. I have not seen a custodial service that does so (this is not a scientific study; I rarely use custodial services); custodial services will deduct more from your balance than what you send, but will not modify what you send, and will prevent you from sending more than your balance minus the fees they charge for sending onchain.
>
> Even today, custodial services deducting from your sent value (rather than the balance remaining after you send) would be problematic when interacting with merchants (or their payment processors) accepting onchain payments; the merchant would refuse to service a lower value than what it charges and it may be very technically difficult to recover such funds from the merchant.
> I expect such a custodial service would quickly lose users, but the world surprises me often.
>
> Regards,
> ZmnSCPxj
If the users are expected to manually operate a hardware wallet to fund the channel, they might do stupid things like using 2 wallets to make 2 txs, thinking that they could combine the values this way; or “refilling” the offchain wallet with the address, as you suggested. While I appreciate the goal to separate the coin-selecting wallet with the offchain wallet, I am not sure if we should rely on users to do critical steps like entering the right value or not reusing the address. Especially, the setup address should be hidden from user’s view, so only a very few “intelligent advanced users" could try to refill the channel.
If we don’t rely on the user as the bridge between the hardware wallet and the offchain wallet, we need a communication protocol between them. With such protocol, there is no need to spend the setup TXO with NOINPUT.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2018-12-22 16:56 ` Johnson Lau
@ 2018-12-24 11:47 ` ZmnSCPxj
2019-01-31 6:04 ` Anthony Towns
0 siblings, 1 reply; 29+ messages in thread
From: ZmnSCPxj @ 2018-12-24 11:47 UTC (permalink / raw)
To: Johnson Lau; +Cc: bitcoin-dev
Good morning Johnson,
Indeed, manual operation is risky.
However the intent is to reduce the requirements on commodity wallets in order to integrate them into a combined onchain and offchain UI.
A boutique protocol would reduce the number of existing onchain wallets that could be integrated in such UI.
If we could make walletless offchain software in such method, *any* existing wallet with an API to programmatically send arbitrary amount to arbitrary address can be integrated into such UI.
This could include hardware wallets.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, December 23, 2018 12:56 AM, Johnson Lau <jl2012@xbt•hk> wrote:
> > On 22 Dec 2018, at 10:25 PM, ZmnSCPxj ZmnSCPxj@protonmail•com wrote:
> > Good morning Johnson,
> >
> > > Generally speaking, I think walletless protocol is needed only when you want to rely a third party to open a offchain smart contract. It could be coinswap, eltoo, or anything similar.
> >
> > I think a third party would be pointless in general, but then I am strongly against custodiality.
> > The idea is that you have some kind of hardware wallet or similar "somewhat cold" storage that you control yourself, and crate channels for your hot offchain Lightning wallet, without adding more transactions from your somewhat-cold storage to your hot offchain Lightning wallet on the blockchain.
> > Then you could feed a set of addresses to the hot offchain wallet (addresses your somewhat-cold storage controls) so that when channels are closed, the funds go to your somwhat-cold storage.
> > I also doubt that any custodial service would want to mess around with deducting funds from what the user input as the desired payment. I have not seen a custodial service that does so (this is not a scientific study; I rarely use custodial services); custodial services will deduct more from your balance than what you send, but will not modify what you send, and will prevent you from sending more than your balance minus the fees they charge for sending onchain.
> > Even today, custodial services deducting from your sent value (rather than the balance remaining after you send) would be problematic when interacting with merchants (or their payment processors) accepting onchain payments; the merchant would refuse to service a lower value than what it charges and it may be very technically difficult to recover such funds from the merchant.
> > I expect such a custodial service would quickly lose users, but the world surprises me often.
> > Regards,
> > ZmnSCPxj
>
> If the users are expected to manually operate a hardware wallet to fund the channel, they might do stupid things like using 2 wallets to make 2 txs, thinking that they could combine the values this way; or “refilling” the offchain wallet with the address, as you suggested. While I appreciate the goal to separate the coin-selecting wallet with the offchain wallet, I am not sure if we should rely on users to do critical steps like entering the right value or not reusing the address. Especially, the setup address should be hidden from user’s view, so only a very few “intelligent advanced users" could try to refill the channel.
>
> If we don’t rely on the user as the bridge between the hardware wallet and the offchain wallet, we need a communication protocol between them. With such protocol, there is no need to spend the setup TXO with NOINPUT.
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2018-12-24 11:47 ` ZmnSCPxj
@ 2019-01-31 6:04 ` Anthony Towns
2019-02-01 9:36 ` ZmnSCPxj
0 siblings, 1 reply; 29+ messages in thread
From: Anthony Towns @ 2019-01-31 6:04 UTC (permalink / raw)
To: ZmnSCPxj, Bitcoin Protocol Discussion
On Mon, Dec 24, 2018 at 11:47:38AM +0000, ZmnSCPxj via bitcoin-dev wrote:
> A boutique protocol would reduce the number of existing onchain wallets that could be integrated in such UI.
Seems like PSBT would be a sufficient protocol:
0) lightning node generates a PSBT for a new channel,
with no inputs and a single output of the 2-of-2 address
1) wallet funds the PSBT but doesn't sign it, adding a change address
if necessary, and could combine with other tx's bustapay style
2) lightning determines txid from PSBT, and creates update/settlement
tx's for funding tx so funds can be recovered
3) wallet signs and publishes the PSBT
4) lightning sees tx on chain and channel is open
That's a bit more convoluted than "(0) lightning generates an address and
value, and creates NOINPUT update/settlement tx's for that address/value;
(1) wallet funds address to exactly that value; (2) lightning monitors
blockchain for payment to that address" of course.
But it avoids letting users get into the habit of passing NOINPUT
addresses around, or the risk of a user typo'ing the value and losing
money immediately, and it has the benefit that the wallet can tweak the
value if (eg) that avoids a change address or enhances privacy (iirc,
c-lightning tweaks payment values for that reason). If the channel's
closed cooperatively, it also avoids ever needing to publish a NOINPUT
sig (or NOINPUT tagged output).
Does that seem a fair trade off?
Cheers,
aj
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2019-01-31 6:04 ` Anthony Towns
@ 2019-02-01 9:36 ` ZmnSCPxj
0 siblings, 0 replies; 29+ messages in thread
From: ZmnSCPxj @ 2019-02-01 9:36 UTC (permalink / raw)
To: Anthony Towns; +Cc: Bitcoin Protocol Discussion
Good morning aj,
I certainly agree.
I hope that PSBT support becomes much, much, much more widespread.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Thursday, January 31, 2019 2:04 PM, Anthony Towns <aj@erisian•com.au> wrote:
> On Mon, Dec 24, 2018 at 11:47:38AM +0000, ZmnSCPxj via bitcoin-dev wrote:
>
> > A boutique protocol would reduce the number of existing onchain wallets that could be integrated in such UI.
>
> Seems like PSBT would be a sufficient protocol:
>
> 0) lightning node generates a PSBT for a new channel,
> with no inputs and a single output of the 2-of-2 address
>
> 1. wallet funds the PSBT but doesn't sign it, adding a change address
> if necessary, and could combine with other tx's bustapay style
>
> 2. lightning determines txid from PSBT, and creates update/settlement
> tx's for funding tx so funds can be recovered
>
> 3. wallet signs and publishes the PSBT
> 4. lightning sees tx on chain and channel is open
>
> That's a bit more convoluted than "(0) lightning generates an address and
> value, and creates NOINPUT update/settlement tx's for that address/value;
> (1) wallet funds address to exactly that value; (2) lightning monitors
> blockchain for payment to that address" of course.
>
> But it avoids letting users get into the habit of passing NOINPUT
> addresses around, or the risk of a user typo'ing the value and losing
> money immediately, and it has the benefit that the wallet can tweak the
> value if (eg) that avoids a change address or enhances privacy (iirc,
> c-lightning tweaks payment values for that reason). If the channel's
> closed cooperatively, it also avoids ever needing to publish a NOINPUT
> sig (or NOINPUT tagged output).
>
> Does that seem a fair trade off?
>
> Cheers,
> aj
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2018-12-13 12:32 [bitcoin-dev] Safer NOINPUT with output tagging Johnson Lau
2018-12-17 15:48 ` Ruben Somsen
2018-12-21 11:40 ` ZmnSCPxj
@ 2019-02-08 19:01 ` Jonas Nick
2019-02-09 10:01 ` Alejandro Ranchal Pedrosa
2019-02-09 10:15 ` Johnson Lau
2019-02-19 19:04 ` Luke Dashjr
3 siblings, 2 replies; 29+ messages in thread
From: Jonas Nick @ 2019-02-08 19:01 UTC (permalink / raw)
To: Johnson Lau, Bitcoin Protocol Discussion
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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2019-02-08 19:01 ` Jonas Nick
@ 2019-02-09 10:01 ` Alejandro Ranchal Pedrosa
2019-02-09 16:48 ` Johnson Lau
2019-02-09 16:54 ` Jonas Nick
2019-02-09 10:15 ` Johnson Lau
1 sibling, 2 replies; 29+ messages in thread
From: Alejandro Ranchal Pedrosa @ 2019-02-09 10:01 UTC (permalink / raw)
To: bitcoin-dev
Hi all,
>
> 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.
>
An eltoo-like protocol that works (without going on-chain) if you can't
predict in advance who will become absent would be a childchain. If the
off-chain protocol can continue updating in the abscence of other
parties, it means that other parties' signatures must not be required
when they are not involved in the off-chain state update. If other
parties' signatures must not be required, there must be a way of having
a common verifiable 'last state' to prevent a party to simultaneously
'fork' the state with two different parties, and double-spend. A
solution for this is a childchain for Bitcoin. An example of this is
what is known as a 'Broken Factory' attack [1]
(https://bitcoin.stackexchange.com/questions/77434/how-does-channel-factory-act/81005#81005)
> 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.
I believe that in many cases other parties won't be able to continue
until the unresponsive parties go back online. That might be true in
particular scenarios, but generally speaking, the party might have gone
unresponsive during a factory-level update (i.e. off-chain closing and
opening of channels), while some parties might have given out their
signature for the update without receiving a fully signed transaction.
In this case they do not even know which channel they have open (the one
of the old state that they have fully signed, or the one for the new
state that they have given out their signature for). This is known as a
'Stale Factory', and can be exploited by an adversary in a 'Stale
Factory' attack [1]. Even if they knew which state they are in (i.e. the
party went unresponsive but not during a factory-level update), some of
them might have run out of funds in some of their channels of the
factory, and might want to update, while they will not be willing to
wait for a party to go back online (something for which they also have
zero guarantees of).
An eltoo-like protocol that works (allowing going on-chain) if you can't
in advance who will become absent, then this is precisely why
'Transaction Fragments' have been suggested. They allow an eltoo-like
protocol even when one cannot predict in advance who will become absent,
or malicious (by publishing invalid states), cause the non-absent
parties can unite their fragments and create a valid spendable
factory-level transaction that effectively kicks out the malicious
parties, while leaving the rest of the factory as it was. To the best of
my understanding, the eltoo original proposal also allows this though.
Best,
Alejandro.
[1]: Scalable Lightning Factories for Bitcoin,
https://eprint.iacr.org/2018/918.pdf
On 08/02/2019 20:01, Jonas Nick via bitcoin-dev 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@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2019-02-08 19:01 ` Jonas Nick
2019-02-09 10:01 ` Alejandro Ranchal Pedrosa
@ 2019-02-09 10:15 ` Johnson Lau
2019-02-09 16:52 ` Jonas Nick
1 sibling, 1 reply; 29+ messages in thread
From: Johnson Lau @ 2019-02-09 10:15 UTC (permalink / raw)
To: Jonas Nick; +Cc: bitcoin-dev
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@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@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2019-02-09 10:01 ` Alejandro Ranchal Pedrosa
@ 2019-02-09 16:48 ` Johnson Lau
2019-02-10 4:46 ` Anthony Towns
2019-02-09 16:54 ` Jonas Nick
1 sibling, 1 reply; 29+ messages in thread
From: Johnson Lau @ 2019-02-09 16:48 UTC (permalink / raw)
To: Alejandro Ranchal Pedrosa, bitcoin-dev
In a 3 parties channel, let’s say the balance for A, B, C is 2, 3, 6BTC respectively, there are few ways they could make the settlement tx.
The first type we may call it “simple settlement”, which has 3 outputs with A=2, B=3, C=6.
The second type we may call it “fully combinatorial settlement”, which has 3 outputs with (A & B), (B & C), and (A & C). The value distribution is flexible, but never exceed the total balance of the involved parties. For example, (A & B) may have any value between 0 and 5BTC. For the following example, I will use (A & B) = 3; (B & C) = 6; (A & C) = 2, but there are infinitely many valid combinations.
The third type we may call it “partially combinatorial settlement”. It may have 2 multi-sig outputs, for example, (A & B) = 4 and (B & C) = 7; or 1 multi-sig output and 1 single-sig output, for example, (A & B) = 5 and C=6 (known as "semi-cooperative channel closing” SCCC in my last post)
I’ll just focus on the fully combinatorial settlement. The partial type works in the same way, with benefits and limitations.
In a combinatorial settlement, the multi-sig outputs are actually eltoo-style scripts. Therefore, A and B will further distribute the value of (A & B) by a 2-party eltoo channel (“branch channels"). Again, there are infinitely many valid ways to distribute the values. If the AB branch channel is distributed as A=1 and B=2, then the BC channel must be B=1 and C=5, and the AC channel must be A=1 and C=1.
A clear benefit of this model is that any 2 parties could trade with each other, in the absence of any other party(s), as long as there is enough liquidity in their branch channel. There is also no way to “fork” the state, because liquidity is restricted to each branch channel. In some way, this is like the existing lightning network where the 3 parties have direct channel with each other. However, this is superior to lightning network, because when the 3 parties are online simultaneously, they could re-distribute the channel capacities without closing any channels. They could even change it to a partially combinatorial settlement. If they find that A and C rarely trade with each other, they could remove the (A & C) output, and improve the capacities of the remaining channels. If C is going offline for a week, they could make it (A & B), C, (aka. SCCC) which will maximise the capacity of the AB branch channel, and minimise the cost in case C is not coming back.
A problem with combinatorial settlement is the increased costs of uncooperative settlement. It is more expensive, as more parties are missing. Simple settlement has the same settlement cost for any number of missing party. However, even if one party is missing, a simple settled channel will cease to function and force an immediate on-chain settlement. In combinatorial settlement, the surviving parties may keep trading, may or may not with reduced capacity depending on the exact settlement model, and in the meantime hope that the missing parties may return.
It requires 6 outputs for 4 parties doing fully combinatorial settlement, 10 outputs for 5 parties, 15 outputs for 6 parties, etc. However, in a many parties situation, not every parties might want to trade with all the other parties, and those branch channels might be omitted to improve the capacities of the other channels. If some pairs want to trade without a direct branch channel, they might try to find a third (internal) party to forward the tx. When the next time all parties are online, they could rearrange the branch channel capacities at no cost.
The combinatorial settlement model could be generalised to a hierarchical settlement model, where we might have 4 settlement outputs (A&B&C), (A&B&D), (A&C&D), (B&C&D) for a 4-party channel, and each settlement output will have 3 branch channels. If A is missing, for example, we will still have one BC branch channel, one BD branch channel, one CD branch channel, and one BCD 3-party branch channel. The benefit of having a BCD 3-party branch channel is the 3 parties could rearrange the channel capacities without involving A. Let’s say D is going for vacation, he could do a SCCC in the BCD branch channel to maximise the capacity of its BC channel. Without the involvement of A, however, the capacities of the other BC, BD, and CD branch channels are not modifiable, and B and C’s balance in the BD/CD channels are frozen during the absence of D.
As the number of parties increase, the number of settlement txs will grow factorially in a fully hierarchical settlement model, and will soon be out-of-control. The result could be catastrophic if many parties are gone. So the group needs to continuously evaluate the risks of each party being missing, and modify the settlement model accordingly.
> On 9 Feb 2019, at 6:01 PM, Alejandro Ranchal Pedrosa via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Hi all,
>>
>> 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.
>>
> An eltoo-like protocol that works (without going on-chain) if you can't predict in advance who will become absent would be a childchain. If the off-chain protocol can continue updating in the abscence of other parties, it means that other parties' signatures must not be required when they are not involved in the off-chain state update. If other parties' signatures must not be required, there must be a way of having a common verifiable 'last state' to prevent a party to simultaneously 'fork' the state with two different parties, and double-spend. A solution for this is a childchain for Bitcoin. An example of this is what is known as a 'Broken Factory' attack [1] (https://bitcoin.stackexchange.com/questions/77434/how-does-channel-factory-act/81005#81005)
>
>> 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.
>
> I believe that in many cases other parties won't be able to continue until the unresponsive parties go back online. That might be true in particular scenarios, but generally speaking, the party might have gone unresponsive during a factory-level update (i.e. off-chain closing and opening of channels), while some parties might have given out their signature for the update without receiving a fully signed transaction. In this case they do not even know which channel they have open (the one of the old state that they have fully signed, or the one for the new state that they have given out their signature for). This is known as a 'Stale Factory', and can be exploited by an adversary in a 'Stale Factory' attack [1]. Even if they knew which state they are in (i.e. the party went unresponsive but not during a factory-level update), some of them might have run out of funds in some of their channels of the factory, and might want to update, while they will not be willing to wait for a party to go back online (something for which they also have zero guarantees of).
>
> An eltoo-like protocol that works (allowing going on-chain) if you can't in advance who will become absent, then this is precisely why 'Transaction Fragments' have been suggested. They allow an eltoo-like protocol even when one cannot predict in advance who will become absent, or malicious (by publishing invalid states), cause the non-absent parties can unite their fragments and create a valid spendable factory-level transaction that effectively kicks out the malicious parties, while leaving the rest of the factory as it was. To the best of my understanding, the eltoo original proposal also allows this though.
>
> Best,
>
> Alejandro.
>
> [1]: Scalable Lightning Factories for Bitcoin, https://eprint.iacr.org/2018/918.pdf
>
>
> On 08/02/2019 20:01, Jonas Nick via bitcoin-dev 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@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2019-02-09 10:15 ` Johnson Lau
@ 2019-02-09 16:52 ` Jonas Nick
2019-02-09 17:43 ` Johnson Lau
0 siblings, 1 reply; 29+ messages in thread
From: Jonas Nick @ 2019-02-09 16:52 UTC (permalink / raw)
To: Johnson Lau; +Cc: bitcoin-dev
Johnson's modification solves the issue I pointed out.
Moreover, as Johnson and I discussed in private, using different locktimes for
X and Y is not necessary. They can have the same relative locktime. If A and B
would only sign Y as soon as the update tx is confirmed, there is no risk of Y
changing its txid and therefore invalidating updates built on it.
On 2/9/19 10:15 AM, Johnson Lau wrote:
> 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@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@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2019-02-09 10:01 ` Alejandro Ranchal Pedrosa
2019-02-09 16:48 ` Johnson Lau
@ 2019-02-09 16:54 ` Jonas Nick
1 sibling, 0 replies; 29+ messages in thread
From: Jonas Nick @ 2019-02-09 16:54 UTC (permalink / raw)
To: Alejandro Ranchal Pedrosa via bitcoin-dev
<--- not replying to list as this is off-topic ---->
Hey Alejandro,
thanks for the pointer. Is there a summary of how the opcode you're proposing would look like?
Is pairing crypto strictly necessary or would interactive key aggregation schemes like Bellare-Neven
work as well?
Best,
Jonas
On 2/9/19 10:01 AM, Alejandro Ranchal Pedrosa via bitcoin-dev wrote:
> Hi all,
>>
>> 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.
>>
> An eltoo-like protocol that works (without going on-chain) if you can't predict in advance who will become absent would be a childchain. If the off-chain protocol can continue updating in the abscence
> of other parties, it means that other parties' signatures must not be required when they are not involved in the off-chain state update. If other parties' signatures must not be required, there must
> be a way of having a common verifiable 'last state' to prevent a party to simultaneously 'fork' the state with two different parties, and double-spend. A solution for this is a childchain for Bitcoin.
> An example of this is what is known as a 'Broken Factory' attack [1] (https://bitcoin.stackexchange.com/questions/77434/how-does-channel-factory-act/81005#81005)
>
>> 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.
>
> I believe that in many cases other parties won't be able to continue until the unresponsive parties go back online. That might be true in particular scenarios, but generally speaking, the party might
> have gone unresponsive during a factory-level update (i.e. off-chain closing and opening of channels), while some parties might have given out their signature for the update without receiving a fully
> signed transaction. In this case they do not even know which channel they have open (the one of the old state that they have fully signed, or the one for the new state that they have given out their
> signature for). This is known as a 'Stale Factory', and can be exploited by an adversary in a 'Stale Factory' attack [1]. Even if they knew which state they are in (i.e. the party went unresponsive
> but not during a factory-level update), some of them might have run out of funds in some of their channels of the factory, and might want to update, while they will not be willing to wait for a party
> to go back online (something for which they also have zero guarantees of).
>
> An eltoo-like protocol that works (allowing going on-chain) if you can't in advance who will become absent, then this is precisely why 'Transaction Fragments' have been suggested. They allow an
> eltoo-like protocol even when one cannot predict in advance who will become absent, or malicious (by publishing invalid states), cause the non-absent parties can unite their fragments and create a
> valid spendable factory-level transaction that effectively kicks out the malicious parties, while leaving the rest of the factory as it was. To the best of my understanding, the eltoo original
> proposal also allows this though.
>
> Best,
>
> Alejandro.
>
> [1]: Scalable Lightning Factories for Bitcoin, https://eprint.iacr.org/2018/918.pdf
>
>
> On 08/02/2019 20:01, Jonas Nick via bitcoin-dev 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@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2019-02-09 16:52 ` Jonas Nick
@ 2019-02-09 17:43 ` Johnson Lau
0 siblings, 0 replies; 29+ messages in thread
From: Johnson Lau @ 2019-02-09 17:43 UTC (permalink / raw)
To: Jonas Nick; +Cc: bitcoin-dev
And this scheme could be generalised to the combinatorial settlement model in my earlier post.
Let’s say the settlement tx has 3 outputs: (A&B),(B&C),(A&C). There will be 4 versions of this tx:
tx-X: all 3 outputs are tagged, signed by all 3 parties
tx-Y-AB: output (A&B) is untagged, the other 2 outputs are tagged. Signed only by C
tx-Y-AC: output (A&C) is untagged, the other 2 outputs are tagged. Signed only by B
tx-Y-BC: ………
All 4 txs will have the same relative-lock-time
If C is missing at the time of settlement, A and B will settle upon tx-Y-AB with a simple signature
If B and C are missing, A will settle upon tx-X
However, I think this is just an overkill, and hardly improves fungibility. It is very clear that this is an uncooperative eltoo closing (due to the update tx of the main channel), and this is a multi-party channel (due to multiple settlement outputs). There is little doubt that the remaining parties would like to continue trading. So there is actually no secret to hide, and it might be easier to just tag all outputs
Nonetheless, this example shows that the fungibility impact of output tagging is quite manageable. Most likely you just need to prepare more versions of intermediate txs, and only use the tagged one when things go against you.
> On 10 Feb 2019, at 12:52 AM, Jonas Nick <jonasdnick@gmail•com> wrote:
>
> Johnson's modification solves the issue I pointed out.
>
> Moreover, as Johnson and I discussed in private, using different locktimes for
> X and Y is not necessary. They can have the same relative locktime. If A and B
> would only sign Y as soon as the update tx is confirmed, there is no risk of Y
> changing its txid and therefore invalidating updates built on it.
>
>
> On 2/9/19 10:15 AM, Johnson Lau wrote:
>> 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@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@lists•linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>
>>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2019-02-09 16:48 ` Johnson Lau
@ 2019-02-10 4:46 ` Anthony Towns
0 siblings, 0 replies; 29+ messages in thread
From: Anthony Towns @ 2019-02-10 4:46 UTC (permalink / raw)
To: Johnson Lau; +Cc: bitcoin-dev
On Sun, Feb 10, 2019 at 12:48:40AM +0800, Johnson Lau wrote:
> In a 3 parties channel, let’s say the balance for A, B, C is 2, 3, 6BTC respectively, there are few ways they could make the settlement tx.
The way I look at this is:
* you can have a "channel factory" of 3 or more members (A,B,C,...)
* it's protected by an n-of-n multisig output
* it contains some combination of:
- spends directly to members
- lightning channels between pairs of members
- channel factories between subgroups of members
* when initially setup, the factory just has direct spends to each
member matching the amount they contributed to the factory
* whether you create a lightning channel or a sub-factory is the same
decision as whether you create a lightning channel or a factory
on-chain, so there's no combinatorial explosion.
You can close any channel factory by publishing it (and any higher level
channel factories it was a subgroup of) to the blockchain (at which point
the lower level channel factories and lightning channels remain open),
or you can update a channel factory off-chain by having everyone agree
to a new state -- which is only possible if everyone is online, of course.
Updates to transactions in a lightning channel in a factory, or updates
to a subfactory, don't generally involve updating the containing factory
at all, I think.
I don't think there's much use to having sub-factories -- maybe if you
have a subgroup that's much more active and wants to change channel
balances between each other more frequently than the least active member
of the main factory is online?
As far as NOINPUT goes; this impacts channel factories because cheating
could be by any member of the group, so you can't easily penalise the
cheater. So an eltoo-esque setup where you publish a commitment to the
state that's spendable only by any later state, and is then redeemed
after a timelock seems workable. In that case closing a factory when
you can't get all group members to cooperatively close looks like:
funding tx: n-of-n multisig
state commitment: n-of-n multisig
spends funding tx or earlier state commitment
spendable by later state commitment or settlement
settlement: n-of-n multisig
relative timelock
spends state commitment
spends to members, channels or sub-factories
The settlement tx has to spend with a NOINPUT sig, because the state
commitment could have had to spend different things. If it's a
sub-factory, the funding tx will have been in a factory, so the state
commitment would also have had to be a NOINPUT spend. So tagging
NOINPUT-spendable outputs would mean:
- tagging state commitment outputs (which will be spent shortly with
NOINPUT by the settlement tx, so no real loss here)
- tagging settlement tx outputs if they're lightning channels or
sub-factories (which is something of a privacy loss, I think, since
they could continue off-chain for an indefinite period before being
spent)
I think Johnson's suggested elsewhere that if you spend an input with a
NOINPUT signature, you should make all the outputs be tagged NOINPUT (as
a "best practice rule", rather than consensus-enforced or standardness).
That would avoid the privacy loss here, I think, but might be confusing.
If you wanted to close your factory and send your funds to an external
third-party (a cold-wallet, custodial wallet, or just paying someone
for something), you'd presumably do that via a cooperative close of the
factory, which doesn't require the state/settlement pair or NOINPUT
spends, so the NOINPUT-in means NOINPUT-tagged-outputs doesn't cause
a problem for that use case.
FWIW, I think an interesting way to improve this model might be to *add*
centralisation and trust; so that instead of having the factory have
an n-of-n multisig, have it be protected by k-of-n plus a trusted third
party. If you have the trusted third party check that the only balances
that change in the factory are from the "k" signers, that allows (n-k)
members to be offline at any time, but the remaining members to rebalance
their channels happily. (Theoretically you could do this trustlessly
with covenants, but the spending proofs on chain would be much larger)
Of course, this allows k-signers plus the trusted party to steal funds.
It might be possible for the trusted party to store audit logs of the
partial signatures from each of the k-signers for each transaction to
provide accountability -- where the lack of such logs implies the
trusted third party was cheating.
Cheers,
aj
>
>
>
> > On 9 Feb 2019, at 6:01 PM, Alejandro Ranchal Pedrosa via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> >
> > Hi all,
> >>
> >> 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.
> >>
> > An eltoo-like protocol that works (without going on-chain) if you can't predict in advance who will become absent would be a childchain. If the off-chain protocol can continue updating in the abscence of other parties, it means that other parties' signatures must not be required when they are not involved in the off-chain state update. If other parties' signatures must not be required, there must be a way of having a common verifiable 'last state' to prevent a party to simultaneously 'fork' the state with two different parties, and double-spend. A solution for this is a childchain for Bitcoin. An example of this is what is known as a 'Broken Factory' attack [1] (https://bitcoin.stackexchange.com/questions/77434/how-does-channel-factory-act/81005#81005)
> >
> >> 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.
> >
> > I believe that in many cases other parties won't be able to continue until the unresponsive parties go back online. That might be true in particular scenarios, but generally speaking, the party might have gone unresponsive during a factory-level update (i.e. off-chain closing and opening of channels), while some parties might have given out their signature for the update without receiving a fully signed transaction. In this case they do not even know which channel they have open (the one of the old state that they have fully signed, or the one for the new state that they have given out their signature for). This is known as a 'Stale Factory', and can be exploited by an adversary in a 'Stale Factory' attack [1]. Even if they knew which state they are in (i.e. the party went unresponsive but not during a factory-level update), some of them might have run out of funds in some of their channels of the factory, and might want to update, while they will not be willing to wait for a party to go back online (something for which they also have zero guarantees of).
> >
> > An eltoo-like protocol that works (allowing going on-chain) if you can't in advance who will become absent, then this is precisely why 'Transaction Fragments' have been suggested. They allow an eltoo-like protocol even when one cannot predict in advance who will become absent, or malicious (by publishing invalid states), cause the non-absent parties can unite their fragments and create a valid spendable factory-level transaction that effectively kicks out the malicious parties, while leaving the rest of the factory as it was. To the best of my understanding, the eltoo original proposal also allows this though.
> >
> > Best,
> >
> > Alejandro.
> >
> > [1]: Scalable Lightning Factories for Bitcoin, https://eprint.iacr.org/2018/918.pdf
> >
> >
> > On 08/02/2019 20:01, Jonas Nick via bitcoin-dev 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@lists•linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists•linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2018-12-13 12:32 [bitcoin-dev] Safer NOINPUT with output tagging Johnson Lau
` (2 preceding siblings ...)
2019-02-08 19:01 ` Jonas Nick
@ 2019-02-19 19:04 ` Luke Dashjr
2019-02-19 19:22 ` Johnson Lau
3 siblings, 1 reply; 29+ messages in thread
From: Luke Dashjr @ 2019-02-19 19:04 UTC (permalink / raw)
To: bitcoin-dev, Johnson Lau
On Thursday 13 December 2018 12:32:44 Johnson Lau via bitcoin-dev wrote:
> While this seems fully compatible with eltoo, is there any other proposals
> require NOINPUT, and is adversely affected by either way of tagging?
Yes, this seems to break the situation where a wallet wants to use NOINPUT for
everything, including normal L1 payments. For example, in the scenario where
address reuse will be rejected/ignored by the recipient unconditionally, and
the payee is considered to have burned their bitcoins by attempting it.
Luke
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2019-02-19 19:04 ` Luke Dashjr
@ 2019-02-19 19:22 ` Johnson Lau
2019-02-19 20:24 ` Luke Dashjr
0 siblings, 1 reply; 29+ messages in thread
From: Johnson Lau @ 2019-02-19 19:22 UTC (permalink / raw)
To: Luke Dashjr; +Cc: bitcoin-dev
This only depends on the contract between the payer and payee. If the contract says address reuse is unacceptable, it’s unacceptable. It has nothing to do with how the payee spends the coin. We can’t ban address reuse at protocol level (unless we never prune the chain), so address reuse could only be prevented at social level.
Using NOINPUT is also a very weak excuse: NOINPUT always commit to the value. If the payer reused an address but for different amount, the payee can’t claim the coin is lost due to previous NOINPUT use. A much stronger way is to publish the key after a coin is well confirmed.
> On 20 Feb 2019, at 3:04 AM, Luke Dashjr <luke@dashjr•org> wrote:
>
> On Thursday 13 December 2018 12:32:44 Johnson Lau via bitcoin-dev wrote:
>> While this seems fully compatible with eltoo, is there any other proposals
>> require NOINPUT, and is adversely affected by either way of tagging?
>
> Yes, this seems to break the situation where a wallet wants to use NOINPUT for
> everything, including normal L1 payments. For example, in the scenario where
> address reuse will be rejected/ignored by the recipient unconditionally, and
> the payee is considered to have burned their bitcoins by attempting it.
>
> Luke
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2019-02-19 19:22 ` Johnson Lau
@ 2019-02-19 20:24 ` Luke Dashjr
2019-02-19 20:36 ` Johnson Lau
0 siblings, 1 reply; 29+ messages in thread
From: Luke Dashjr @ 2019-02-19 20:24 UTC (permalink / raw)
To: Johnson Lau; +Cc: bitcoin-dev
Even besides NOINPUT, such a wallet would simply never show a second payment
to the same address (or at least never show it as confirmed, until
successfully spent).
At least if tx versions are used, it isn't possible to indicate this
requirement in current Bitcoin L1 addresses. scriptPubKey might not be
impossible to encode, but it isn't really clear what the purpose of doing so
is.
If people don't want to use NOINPUT, they should just not use it. Trying to
implement a nanny in the protocol is inappropriate and limits what developers
can do who actually want the features.
Luke
On Tuesday 19 February 2019 19:22:07 Johnson Lau wrote:
> This only depends on the contract between the payer and payee. If the
> contract says address reuse is unacceptable, it’s unacceptable. It has
> nothing to do with how the payee spends the coin. We can’t ban address
> reuse at protocol level (unless we never prune the chain), so address reuse
> could only be prevented at social level.
>
> Using NOINPUT is also a very weak excuse: NOINPUT always commit to the
> value. If the payer reused an address but for different amount, the payee
> can’t claim the coin is lost due to previous NOINPUT use. A much stronger
> way is to publish the key after a coin is well confirmed.
>
> > On 20 Feb 2019, at 3:04 AM, Luke Dashjr <luke@dashjr•org> wrote:
> >
> > On Thursday 13 December 2018 12:32:44 Johnson Lau via bitcoin-dev wrote:
> >> While this seems fully compatible with eltoo, is there any other
> >> proposals require NOINPUT, and is adversely affected by either way of
> >> tagging?
> >
> > Yes, this seems to break the situation where a wallet wants to use
> > NOINPUT for everything, including normal L1 payments. For example, in the
> > scenario where address reuse will be rejected/ignored by the recipient
> > unconditionally, and the payee is considered to have burned their
> > bitcoins by attempting it.
> >
> > Luke
^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: [bitcoin-dev] Safer NOINPUT with output tagging
2019-02-19 20:24 ` Luke Dashjr
@ 2019-02-19 20:36 ` Johnson Lau
0 siblings, 0 replies; 29+ messages in thread
From: Johnson Lau @ 2019-02-19 20:36 UTC (permalink / raw)
To: Luke Dashjr; +Cc: bitcoin-dev
> On 20 Feb 2019, at 4:24 AM, Luke Dashjr <luke@dashjr•org> wrote:
>
> Even besides NOINPUT, such a wallet would simply never show a second payment
> to the same address (or at least never show it as confirmed, until
> successfully spent).
This is totally unrelated to NOINPUT. You can make a wallet like this today already, and tell your payer not to reuse address.
>
> At least if tx versions are used, it isn't possible to indicate this
> requirement in current Bitcoin L1 addresses. scriptPubKey might not be
> impossible to encode, but it isn't really clear what the purpose of doing so
> is.
It sounds like you actually want to tag such outputs as scriptPubKey, so you could encode this requirement in the address?
If we allow NOINPUT unconditionally (i.e. all v1 addresses are spendable with NOINPUT), you may only create a different proposal to indicate such special requirements
>
> If people don't want to use NOINPUT, they should just not use it. Trying to
> implement a nanny in the protocol is inappropriate and limits what developers
> can do who actually want the features.
>
> Luke
>
>
> On Tuesday 19 February 2019 19:22:07 Johnson Lau wrote:
>> This only depends on the contract between the payer and payee. If the
>> contract says address reuse is unacceptable, it’s unacceptable. It has
>> nothing to do with how the payee spends the coin. We can’t ban address
>> reuse at protocol level (unless we never prune the chain), so address reuse
>> could only be prevented at social level.
>>
>> Using NOINPUT is also a very weak excuse: NOINPUT always commit to the
>> value. If the payer reused an address but for different amount, the payee
>> can’t claim the coin is lost due to previous NOINPUT use. A much stronger
>> way is to publish the key after a coin is well confirmed.
>>
>>> On 20 Feb 2019, at 3:04 AM, Luke Dashjr <luke@dashjr•org> wrote:
>>>
>>> On Thursday 13 December 2018 12:32:44 Johnson Lau via bitcoin-dev wrote:
>>>> While this seems fully compatible with eltoo, is there any other
>>>> proposals require NOINPUT, and is adversely affected by either way of
>>>> tagging?
>>>
>>> Yes, this seems to break the situation where a wallet wants to use
>>> NOINPUT for everything, including normal L1 payments. For example, in the
>>> scenario where address reuse will be rejected/ignored by the recipient
>>> unconditionally, and the payee is considered to have burned their
>>> bitcoins by attempting it.
>>>
>>> Luke
>
^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2019-02-19 20:37 UTC | newest]
Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-12-13 12:32 [bitcoin-dev] Safer NOINPUT with output tagging Johnson Lau
2018-12-17 15:48 ` Ruben Somsen
2018-12-17 20:08 ` Johnson Lau
2018-12-18 10:48 ` Johnson Lau
2018-12-19 22:09 ` Christian Decker
2018-12-20 11:00 ` Johnson Lau
2018-12-20 17:20 ` Christian Decker
2018-12-20 18:04 ` Johnson Lau
2018-12-21 11:15 ` Christian Decker
2018-12-21 16:21 ` Johnson Lau
2018-12-21 11:40 ` ZmnSCPxj
2018-12-21 15:37 ` Johnson Lau
2018-12-22 14:25 ` ZmnSCPxj
2018-12-22 16:56 ` Johnson Lau
2018-12-24 11:47 ` ZmnSCPxj
2019-01-31 6:04 ` Anthony Towns
2019-02-01 9:36 ` ZmnSCPxj
2019-02-08 19:01 ` Jonas Nick
2019-02-09 10:01 ` Alejandro Ranchal Pedrosa
2019-02-09 16:48 ` Johnson Lau
2019-02-10 4:46 ` Anthony Towns
2019-02-09 16:54 ` Jonas Nick
2019-02-09 10:15 ` Johnson Lau
2019-02-09 16:52 ` Jonas Nick
2019-02-09 17:43 ` Johnson Lau
2019-02-19 19:04 ` Luke Dashjr
2019-02-19 19:22 ` Johnson Lau
2019-02-19 20:24 ` Luke Dashjr
2019-02-19 20:36 ` Johnson Lau
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox