Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

[Rusty Russell via bitcoin-dev]

Johnson Lau  writes:
>> On 16 Dec 2018, at 2:55 PM, Rusty Russell via bitcoin-dev 
>>  wrote:
>> 
>> Anthony Towns via bitcoin-dev  writes:
>>> On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via bitcoin-dev 
>>> wrote:
 And is it worthwhile doing the mask complexity, rather than just
 removing the commitment to script with NOINPUT?  It *feels* safer to
 restrict what scripts we can sign, but is it?
>>> 
>>> If it's not safer in practice, we've spent a little extra complexity
>>> committing to a subset of the script in each signature to no gain. If
>>> it is safer in practice, we've prevented people from losing funds. I'm
>>> all for less complexity, but not for that tradeoff.
>> 
>> There are many complexities we could add, each of which would prevent
>> loss of funds in some theoretical case.
>
> Every security measures are overkill, until someone get burnt. If these 
> security measures are really effective, no one will get burnt. The inevitable 
> conclusion is: every effective security measures are overkill.
>
>> 
>> From practical experience; reuse of private keys between lightning and
>> other things is not how people will lose funds[1].
>
> So you argument seems just begging the question. Without NOINPUT, it is just 
> impossible to lose money by key reuse, and this is exactly the topic we are 
> debating.

I think we're getting confused here.  I'm contributing my thoughts from
the lightning implementer's point of view; there are other important
considerations, but this is my contribution.

In *lightning* there are more ways to lose funds via secret reuse.

Meanwhile, both SIGHASH_NOINPUT and OP_MASK have the reuse-is-dangerous
property; with OP_MASK the danger is limited to reuse-on-the-same-script
(ie. if you use the same key for a non-lightning output and a lightning
output, you're safe with OP_MASK.  However, this is far less likely in
practice).

I state again: OP_MASK doesn't seem to gain *lightning* any significant
security benefit.

> It does not need to be something like 
> GetMaskedScript(GetScriptCodeForMultiSig()). After all, only a very small 
> number of script templates really need NOINPUT. A GetMaskedScript() in a 
> wallet is just an overkill (and a vulnerability if mis-implemented) 

Our current transaction signing code is quite generic (and, if I may say
so, readable and elegant).  We could, of course, special case
GetMaskedScript() for the case we need (the Eltoo examples I've seen
have a single OP_MASK at the front, which makes it trivial).

> It’s also about functionality here: as I mentioned in another reply, 
> OP_CODESEPARATOR couldn’t function properly with NOINPUT but without 
> OP_MASKEDPUSH

The mailing list seems a bit backed up or something; I replied to that
in the hope you can clear my confusion on that one.

> This debate happens because NOINPUT introduces the third way to lose fund 
> with key reuse. And once it is deployed, we have to support it forever, and 
> is not something that we could softfork it away.

A would use the same words to encourage you to create the simplest
possible implementation?

I don't think we disagree on philosophy, just trade-offs.  And that's
OK.

Cheers,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

[Rusty Russell via bitcoin-dev]

Johnson Lau  writes:
> I don’t think this has been mentioned: without signing the script or masked 
> script, OP_CODESEPARATOR becomes unusable or insecure with NOINPUT.
>
> In the new sighash proposal, we will sign the hash of the full script (or 
> masked script), without any truncation. To make OP_CODESEPARATOR works like 
> before, we will commit to the position of the last executed OP_CODESEPARATOR. 
> If NOINPUT doesn’t commit to the masked script, it will just blindly 
> committing to a random OP_CODESEPARATOR position, which a wallet couldn’t 
> know what codes are actually being executed.

My anti-complexity argument leads me to ask why we'd support
OP_CODESEPARATOR at all?  Though my argument is weaker here: no wallet
need support it.

But I don't see how OP_CODESEPARATOR changes anything here, wrt NOINPUT?
Remember, anyone can create an output which can be spent by any NOINPUT,
whether we go for OP_MASK or simply not commiting to the input script.

Confused,
Rusty.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Safer NOINPUT with output tagging

[Johnson Lau via bitcoin-dev]

> On 18 Dec 2018, at 4:08 AM, Johnson Lau via bitcoin-dev 
>  wrote:
> 
> 
> 
>> On 17 Dec 2018, at 11:48 PM, Ruben Somsen > > 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. 

Re: [bitcoin-dev] Schnorr and taproot (etc) upgrade

[Johnson Lau via bitcoin-dev]

> On 18 Dec 2018, at 12:58 PM, Anthony Towns  wrote:
> 
> On Mon, Dec 17, 2018 at 10:18:40PM -0500, Russell O'Connor wrote:
>> On Mon, Dec 17, 2018 at 3:16 PM Johnson Lau  wrote:
>>But I’m not sure if that would do more harm than good. For example, people
>>might lose money by copying an existing script template. But they might
>>also lose money in the same way as CHECKMULTISIG is disabled. So I’m not
>>sure.
> 
> Well, if CHECKSIG* and CHECKMULTISIG* are all disabled in favour of
> CHECKDLS, CHECKDLSVERIFY and CHECKDLSADD with both different names and
> different opcodes, copying a script template opcode-for-opcode from v0
> to v1 will always fail. (With taproot, this doesn't necessarily mean you
> lose money, even if the script is impossible to ever satisfy, since you
> may be able to recover via the direct signature path)
> 
>>Another related thing I’d like to bikeshed is to pop the stack after
>>OP_CLTV and OP_CSV. The same pros and cons apply.
>> This one is almost a no-brainer I think.  Nearly every instance of OP_CSV is
>> followed by an OP_DROP and we'd save 1 WU per OP_CSV if we pop the stack
>> afterwards.
> 
> It's definitely bikeshedding so whatever; but to me, it seems like it'd
> be easier for everyone to have it so that if you've got the same opcode
> in v0 script and v1.0 script; they have precisely the same semantics.
> 
> (That said, constructions like " CLTV  CHECKSIGVERIFY" that avoid
> the DROP and work when you're expected to leave a true value on the
> stack won't work if you have to end up with an empty stack)
> 
> Cheers,
> aj
> 

I think you mean   CHECKSIGVERIFY  CLTV, but this works only for simple 
script. Most likely you need a DROP if you use IF or CODESEPARATOR.

However, if we change the rule from “one true stack item” to “empty stack”, 
CLTV/CSV popping stack will make more sense. So I think either we change all, 
or change nothing.

The “true stack item” and CLTV/CSV as NOP are tech debt. Fixing them in new 
script version makes script creation easier and sometimes cheaper, but the fix 
itself creates further tech debts in the code. So I don’t have strong opinion 
on this topic.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

[Peter Todd via bitcoin-dev]

On Tue, Dec 18, 2018 at 03:08:26AM +0800, Johnson Lau via bitcoin-dev wrote:
> >> If it's not safer in practice, we've spent a little extra complexity
> >> committing to a subset of the script in each signature to no gain. If
> >> it is safer in practice, we've prevented people from losing funds. I'm
> >> all for less complexity, but not for that tradeoff.
> > 
> > There are many complexities we could add, each of which would prevent
> > loss of funds in some theoretical case.
> 
> Every security measures are overkill, until someone get burnt. If these 
> security measures are really effective, no one will get burnt. The inevitable 
> conclusion is: every effective security measures are overkill.

This isn't really a security issue, it's a software reliability issue. And
you're making a trade-off between complexity of the core protocol and
complexity of wallet software.

A core protocol failure has high costs for every single Bitcoin user; a wallet
software failure affects a much smaller number of people. So I'd be inclined to
prioritise core protocol simplicity rather than stamping out one of many, many,
ways that wallet software can screw up and lose money.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Schnorr and taproot (etc) upgrade

[Anthony Towns via bitcoin-dev]

On Mon, Dec 17, 2018 at 10:18:40PM -0500, Russell O'Connor wrote:
> On Mon, Dec 17, 2018 at 3:16 PM Johnson Lau  wrote:
> But I’m not sure if that would do more harm than good. For example, people
> might lose money by copying an existing script template. But they might
> also lose money in the same way as CHECKMULTISIG is disabled. So I’m not
> sure.

Well, if CHECKSIG* and CHECKMULTISIG* are all disabled in favour of
CHECKDLS, CHECKDLSVERIFY and CHECKDLSADD with both different names and
different opcodes, copying a script template opcode-for-opcode from v0
to v1 will always fail. (With taproot, this doesn't necessarily mean you
lose money, even if the script is impossible to ever satisfy, since you
may be able to recover via the direct signature path)

> Another related thing I’d like to bikeshed is to pop the stack after
> OP_CLTV and OP_CSV. The same pros and cons apply.
> This one is almost a no-brainer I think.  Nearly every instance of OP_CSV is
> followed by an OP_DROP and we'd save 1 WU per OP_CSV if we pop the stack
> afterwards.

It's definitely bikeshedding so whatever; but to me, it seems like it'd
be easier for everyone to have it so that if you've got the same opcode
in v0 script and v1.0 script; they have precisely the same semantics.

(That said, constructions like " CLTV  CHECKSIGVERIFY" that avoid
the DROP and work when you're expected to leave a true value on the
stack won't work if you have to end up with an empty stack)

Cheers,
aj

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Schnorr and taproot (etc) upgrade

[Russell O'Connor via bitcoin-dev]

On Mon, Dec 17, 2018 at 3:16 PM Johnson Lau  wrote:

>
> I proposed the same in BIP114. I wish Satoshi had designed that way.
>

Thanks.  I probably read that and internalized it and forgot you wrote it.


> But I’m not sure if that would do more harm than good. For example, people
> might lose money by copying an existing script template. But they might
> also lose money in the same way as CHECKMULTISIG is disabled. So I’m not
> sure.
>
> Another related thing I’d like to bikeshed is to pop the stack after
> OP_CLTV and OP_CSV. The same pros and cons apply.
>

This one is almost a no-brainer I think.  Nearly every instance of OP_CSV
is followed by an OP_DROP and we'd save 1 WU per OP_CSV if we pop the stack
afterwards.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Schnorr and taproot (etc) upgrade

[Johnson Lau via bitcoin-dev]

> On 16 Dec 2018, at 7:38 AM, Russell O'Connor via bitcoin-dev 
>  wrote:
> 
> On Fri, Dec 14, 2018 at 8:39 AM Anthony Towns via bitcoin-dev 
>  > wrote:
>   5. if there's exactly one, non-zero item on the stack; succeed
> 
> Unless it is too much bikeshedding, I'd like to propose that to succeed the 
> stack must be exactly empty.  Script is more composable that way, removing 
> the need for special logic to handle top-level CHECKSIG, vs mid-level 
> CHECKSIGVERIFY.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

I proposed the same in BIP114. I wish Satoshi had designed that way. But I’m 
not sure if that would do more harm than good. For example, people might lose 
money by copying an existing script template. But they might also lose money in 
the same way as CHECKMULTISIG is disabled. So I’m not sure.

Another related thing I’d like to bikeshed is to pop the stack after OP_CLTV 
and OP_CSV. The same pros and cons apply.___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Safer NOINPUT with output tagging

[Johnson Lau via bitcoin-dev]

> On 17 Dec 2018, at 11:48 PM, Ruben Somsen  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
>  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 

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

[Johnson Lau via bitcoin-dev]

> On 16 Dec 2018, at 2:55 PM, Rusty Russell via bitcoin-dev 
>  wrote:
> 
> Anthony Towns via bitcoin-dev  writes:
>> On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via bitcoin-dev 
>> wrote:
>>> And is it worthwhile doing the mask complexity, rather than just
>>> removing the commitment to script with NOINPUT?  It *feels* safer to
>>> restrict what scripts we can sign, but is it?
>> 
>> If it's not safer in practice, we've spent a little extra complexity
>> committing to a subset of the script in each signature to no gain. If
>> it is safer in practice, we've prevented people from losing funds. I'm
>> all for less complexity, but not for that tradeoff.
> 
> There are many complexities we could add, each of which would prevent
> loss of funds in some theoretical case.

Every security measures are overkill, until someone get burnt. If these 
security measures are really effective, no one will get burnt. The inevitable 
conclusion is: every effective security measures are overkill.

> 
> From practical experience; reuse of private keys between lightning and
> other things is not how people will lose funds[1].

Assuming an user holds a private key exclusively and securely, currently there 
are only 2 ways to lose funds by private key reuse: 1. reusing the same 
signature nonce; 2. signing the hash “one”, for the SIGHASH_SINGLE consensus 
bug.

People lost money for the first reason. Since this is a feature of the 
signature schemes we use, unavoidably that will happen again from time to time. 
The second one has been fixed in segwit (though incompletely), and could be 
completely fixed with a simple softfork.

Overall speaking, while private key reuse hurts fungibility and privacy, it is 
not terribly insecure, as long as you use rfc6979 and are not foolish enough to 
sign hash “one”. This actually thanks to the fact that signatures always 
committed to the previous txid. It makes sure that a signature is never valid 
for more than one UTXO. Unfortunately, the guarantee of non-replayability 
incentified the practice of key-reuse, since the day-one of bitcoin. While 
NOINPUT fundamentally changes this security assumption, it won’t change this 
long-established culture of key reuse.

So you argument seems just begging the question. Without NOINPUT, it is just 
impossible to lose money by key reuse, and this is exactly the topic we are 
debating.


> 
> It *is* however non-trivially more complicated for wallets; they
> currently have a set of script templates which they will sign (ie. no
> OP_CODESEPARATOR) and I implemented BIP 143 with only the simplest of
> naive code[2].  In particular, there is no code to parse scripts.

Sorry that I’m not familiar with the implementation details of your wallet. But 
as you don’t have code to parse scripts, I assume your wallet can’t handle 
OP_CODESEPARATOR? However, this is exactly what you should do: only implement 
what you actually need, and ignore those unrelated details.

Also, trying to faithfully and completely reproduce the consensus code in a 
wallet (even if you don’t need that at all) could be extremely dangerous. Such 
wallet might be tricked, for example, to sign the hash “one” and get all money 
stolen (I was told someone really did that, but I don’t know the details)

If you didn’t implement OP_CODESEPARATOR because you didn’t use it, there is no 
reason for you to fully implement OP_MASKEDPUSH nor script parsing. In existing 
signature schemes (e.g. BIP143), signatures always commit to the script being 
executed (the “scriptCode”). I assume that all wallets would re-construct the 
scriptCode at signing time, based on the limited set of script templates they 
support. If a wallet had a function called GetScriptCodeForMultiSig() for this 
purpose, all they need now is a GetMaskedScriptCodeForMultiSig() that returns 
the masked template, or a new option in the existing 
GetScriptCodeForMultiSig(). It does not need to be something like 
GetMaskedScript(GetScriptCodeForMultiSig()). After all, only a very small 
number of script templates really need NOINPUT. A GetMaskedScript() in a wallet 
is just an overkill (and a vulnerability if mis-implemented) 

> 
> Bitcoind developers are not in a good position to assess complexity
> here.  They have to implement *everything*, so each increment seems
> minor.  In addition, none of these new script versions will ever make
> bitcoind simpler, since they have to support all prior ones.  Wallets,
> however, do not have to.
> 
> I also think that minimal complexity for (future) wallets is an
> underappreciated feature: the state of wallets in bitcoin is poor[3]
> so simplicity should be a key goal.

It is a 3-way tradeoff of security, complexity, and functionality. While not 
everyone might appreciate this, security seems to always be the dominent factor 
in bitcoin protocol development. It was the reason why most core contributors 
were hesitant towards BIP148, despite they all love the functionality of segwit.

Re: [bitcoin-dev] Safer NOINPUT with output tagging

[Ruben Somsen via bitcoin-dev]

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
 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 

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

[Rusty Russell via bitcoin-dev]

Anthony Towns via bitcoin-dev  writes:
> On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via bitcoin-dev wrote:
>> And is it worthwhile doing the mask complexity, rather than just
>> removing the commitment to script with NOINPUT?  It *feels* safer to
>> restrict what scripts we can sign, but is it?
>
> If it's not safer in practice, we've spent a little extra complexity
> committing to a subset of the script in each signature to no gain. If
> it is safer in practice, we've prevented people from losing funds. I'm
> all for less complexity, but not for that tradeoff.

There are many complexities we could add, each of which would prevent
loss of funds in some theoretical case.

>From practical experience; reuse of private keys between lightning and
other things is not how people will lose funds[1].

It *is* however non-trivially more complicated for wallets; they
currently have a set of script templates which they will sign (ie. no
OP_CODESEPARATOR) and I implemented BIP 143 with only the simplest of
naive code[2].  In particular, there is no code to parse scripts.

Bitcoind developers are not in a good position to assess complexity
here.  They have to implement *everything*, so each increment seems
minor.  In addition, none of these new script versions will ever make
bitcoind simpler, since they have to support all prior ones.  Wallets,
however, do not have to.

I also think that minimal complexity for (future) wallets is an
underappreciated feature: the state of wallets in bitcoin is poor[3]
so simplicity should be a key goal.

Respectfully,
Rusty.

[1] Reusing your revocation base point across two channels will lose
funds in a much more trivial way, as will reusing payment hashes
across invoices.
[2] In fact, I added SIGHASH_ANYONECANPAY and SIGHASH_SINGLE recently
for Segwit and it worked first time!  Kudos to BIP143's authors for
such a clear guide.
[3] Bitcoind's wallet can't restore from seed; this neatly demonstrates
how hard the wallet problem is, but there are many others.












code, as modern wallets currently don't have to parse the scripts they
sign.







I'm telling you that this is not how people are losing funds.



>
> Also, saying "I can't see how to break this, so it's probably good
> enough, even if other people have a bad feeling about it" is a crypto
> anti-pattern, isn't it?
>
> I don't see how you could feasibly commit to more information than script
> masking does for use cases where you want to be able to spend different
> scripts with the same signature [0]. If that's possible, I'd probably
> be for it.
>
> At the same time, script masking does seem feasible, both for
> lightning/eltoo, and even for possibly complex variations of scripts. So
> committing to less doesn't seem wise.
>
>> You already need both key-reuse and amount-reuse to be exploited.
>> SIGHASH_MASK only prevents you from reusing this input for a "normal"
>> output; if you used this key for multiple scripts of the same form,
>> you're vulnerable[1].
>
> For example, script masking seems general enough to prevent footguns
> even if (for some reason) key and value reuse across eltoo channels
> were a requirement, rather than prohibited: you'd make the script be
> " MASK  CLTV 2DROP  CHECKSIG", and your
> signature will only apply to that channel, even if another channel has
> the same capacity and uses the same keys, a and b.
>
>> So I don't think it's worth it.  SIGHASH_NOINPUT is simply dangerous
>> with key-reuse, and Don't Do That.
>
> For my money, "NOINPUT" commits to dangerously little context, and
> doesn't really feel safe to include as a primitive -- as evidenced by
> the suggestion to add "_UNSAFE" or similar to its name. Personally, I'm
> willing to accept a bit of risk, so that feeling doesn't make me strongly
> against the idea; but it also makes it hard for me to want to support
> adding it. To me, committing to a masked script is a huge improvement.
>
> Heck, if it also makes it easier to do something safer, that's also
> probably a win...
>
> Cheers,
> aj
>
> [0] You could, perhaps, commit to knowing the private keys for all the
> *outputs* you're spending to, as well as the inputs, which comes
> close to saying "I know this is a scary NOINPUT transaction, but
> we're paying to ourselves, so it will all be okay".
> ___
> 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

Re: [bitcoin-dev] Schnorr and taproot (etc) upgrade

[Russell O'Connor via bitcoin-dev]

On Fri, Dec 14, 2018 at 8:39 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>   5. if there's exactly one, non-zero item on the stack; succeed
>

Unless it is too much bikeshedding, I'd like to propose that to succeed the
stack must be exactly empty.  Script is more composable that way, removing
the need for special logic to handle top-level CHECKSIG, vs mid-level
CHECKSIGVERIFY.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

[Johnson Lau via bitcoin-dev]

I don’t think this has been mentioned: without signing the script or masked 
script, OP_CODESEPARATOR becomes unusable or insecure with NOINPUT.

In the new sighash proposal, we will sign the hash of the full script (or 
masked script), without any truncation. To make OP_CODESEPARATOR works like 
before, we will commit to the position of the last executed OP_CODESEPARATOR. 
If NOINPUT doesn’t commit to the masked script, it will just blindly committing 
to a random OP_CODESEPARATOR position, which a wallet couldn’t know what codes 
are actually being executed.

> On 14 Dec 2018, at 5:30 PM, Anthony Towns via bitcoin-dev 
>  wrote:
> 
> On Thu, Dec 13, 2018 at 11:07:28AM +1030, Rusty Russell via bitcoin-dev wrote:
>> And is it worthwhile doing the mask complexity, rather than just
>> removing the commitment to script with NOINPUT?  It *feels* safer to
>> restrict what scripts we can sign, but is it?
> 
> If it's not safer in practice, we've spent a little extra complexity
> committing to a subset of the script in each signature to no gain. If
> it is safer in practice, we've prevented people from losing funds. I'm
> all for less complexity, but not for that tradeoff.
> 
> Also, saying "I can't see how to break this, so it's probably good
> enough, even if other people have a bad feeling about it" is a crypto
> anti-pattern, isn't it?
> 
> I don't see how you could feasibly commit to more information than script
> masking does for use cases where you want to be able to spend different
> scripts with the same signature [0]. If that's possible, I'd probably
> be for it.
> 
> At the same time, script masking does seem feasible, both for
> lightning/eltoo, and even for possibly complex variations of scripts. So
> committing to less doesn't seem wise.
> 
>> You already need both key-reuse and amount-reuse to be exploited.
>> SIGHASH_MASK only prevents you from reusing this input for a "normal"
>> output; if you used this key for multiple scripts of the same form,
>> you're vulnerable[1].
> 
> For example, script masking seems general enough to prevent footguns
> even if (for some reason) key and value reuse across eltoo channels
> were a requirement, rather than prohibited: you'd make the script be
> " MASK  CLTV 2DROP  CHECKSIG", and your
> signature will only apply to that channel, even if another channel has
> the same capacity and uses the same keys, a and b.
> 
>> So I don't think it's worth it.  SIGHASH_NOINPUT is simply dangerous
>> with key-reuse, and Don't Do That.
> 
> For my money, "NOINPUT" commits to dangerously little context, and
> doesn't really feel safe to include as a primitive -- as evidenced by
> the suggestion to add "_UNSAFE" or similar to its name. Personally, I'm
> willing to accept a bit of risk, so that feeling doesn't make me strongly
> against the idea; but it also makes it hard for me to want to support
> adding it. To me, committing to a masked script is a huge improvement.
> 
> Heck, if it also makes it easier to do something safer, that's also
> probably a win...
> 
> Cheers,
> aj
> 
> [0] You could, perhaps, commit to knowing the private keys for all the
>*outputs* you're spending to, as well as the inputs, which comes
>close to saying "I know this is a scary NOINPUT transaction, but
>we're paying to ourselves, so it will all be okay".
> ___
> 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