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

On Wed, 19 Dec 2018 at 18:06, Rusty Russell via bitcoin-dev wrote: > > 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 >

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

I find another proposed use of CODESEPARATOR here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2016-March/000455.html OP_CHECKSIG OP_IF OP_ELSE OP_CSV OP_DROP OP_CODESEPARATOR OP_ENDIF

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

Good morning, > Could anyone propose a better use case of CODESEPARATOR? Long ago, aj sent an email on Lightning-dev about use of CODESEPARATOR to impose Scriptless Script even without Schnorr. It involved 3 signatures with different CODESEPARATOR places, and forced R reuse so that the

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

> On 23 Dec 2018, at 12:26 PM, Anthony Towns wrote: > > On Sat, Dec 22, 2018 at 02:54:42AM +0800, Johnson Lau wrote: >> The question I would like to ask is: is OP_CODESEPARATOR useful under >> taproot? Generally speaking, CODESEPARATOR is useful only with conditional >> opcodes (OP_IF etc),

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

On Sat, Dec 22, 2018 at 02:54:42AM +0800, Johnson Lau wrote: > The question I would like to ask is: is OP_CODESEPARATOR useful under > taproot? Generally speaking, CODESEPARATOR is useful only with conditional > opcodes (OP_IF etc), and conditional opcodes are mostly replaced by merklized >

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

> On 21 Dec 2018, at 7:17 AM, Rusty Russell wrote: > > Johnson Lau writes: > >>> 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

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

> On 17 Dec 2018, at 11:10 AM, Rusty Russell wrote: > > 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

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

Johnson Lau writes: >> On 17 Dec 2018, at 11:10 AM, Rusty Russell wrote: >> 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. > > Because it could make scripts more compact in some cases? >

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

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

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

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

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

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.

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

> 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

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

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,

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

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

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

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,

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

On Thu, Dec 13, 2018 at 11:21:10AM -0500, Russell O'Connor wrote: > On Wed, Dec 12, 2018 at 7:06 PM Anthony Towns wrote: > On Tue, Dec 11, 2018 at 05:50:24PM -0500, Russell O'Connor via bitcoin-dev > wrote: > > On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau wrote: > >     The current

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

On Wed, Dec 12, 2018 at 2:53 PM Johnson Lau wrote: > > I think the root cause of witness weight malleability is some opcodes > accept variable size input (without affecting the output), and that input > is provided by the puzzle solver. Going through the opcode list, I think > such opcodes

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

On Wed, Dec 12, 2018 at 12:26 PM Gregory Maxwell wrote: > On Wed, Dec 12, 2018 at 5:15 PM Russell O'Connor via bitcoin-dev > wrote: > > I tend to think in opposite terms. Is there a proof that any script can > be transformed into an equivalent one that avoids witness weight > malleability?

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

On Wed, Dec 12, 2018 at 7:06 PM Anthony Towns wrote: > On Tue, Dec 11, 2018 at 05:50:24PM -0500, Russell O'Connor via bitcoin-dev > wrote: > > On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau wrote: > > The current proposal is that a 64-byte signature will be used for the > > default “signing

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

Rusty Russell writes: >> However, I’m not sure if there is any useful NOINPUT case with unmasked >> script. > > This is *not* true of Eltoo; the script itself need not change for the > rebinding (Christian, did something change?). This is wrong, sorry. I re-checked the paper, and the constant

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

On Wed, Dec 12, 2018 at 08:12:10PM +1030, Rusty Russell via bitcoin-dev wrote: > Pieter Wuille via bitcoin-dev writes: > > Here is a combined proposal: > > * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE, > > and SIGHASH_SCRIPTMASK. > > * A new opcode OP_MASK is added, which

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

On Tue, Dec 11, 2018 at 05:50:24PM -0500, Russell O'Connor via bitcoin-dev wrote: > On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau wrote: > The current proposal is that a 64-byte signature will be used for the > default “signing all” sighash, and 65-byte for other sighash types. The >

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

Johnson Lau writes: >> On 12 Dec 2018, at 5:42 PM, Rusty Russell via bitcoin-dev >> wrote: >> >> Pieter Wuille via bitcoin-dev writes: >>> Here is a combined proposal: >>> * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE, >>> and SIGHASH_SCRIPTMASK. >>> * A new opcode

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

> On 12 Dec 2018, at 6:50 AM, Russell O'Connor wrote: > > On Sun, Dec 9, 2018 at 2:13 PM Johnson Lau > wrote: > The current proposal is that a 64-byte signature will be used for the default > “signing all” sighash, and 65-byte for other sighash types. The space saved >

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

Pieter Wuille via bitcoin-dev writes: > Here is a combined proposal: > * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE, > and SIGHASH_SCRIPTMASK. > * A new opcode OP_MASK is added, which acts as a NOP during execution. > * The sighash is computed like in BIP143, but: > * If

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

I don't believe that the default RBF policy works that way. My understanding is that current policy requires an absolute fee increase (by an amount related to incrementalrelayfee). There have been proposals to change default RBF policy, however even my proposal <

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

On Thu, Dec 06, 2018 at 11:57:09AM -0500, Russell O'Connor via bitcoin-dev wrote: > One more item to consider is "signature covers witness weight". > > While signing the witness weight doesn't completely eliminate witness > malleability (of the kind that can cause grief for compact blocks), it

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

The current proposal is that a 64-byte signature will be used for the default “signing all” sighash, and 65-byte for other sighash types. The space saved will allow a few more txs in a block, so I think it worths doing. However, this also makes witness weight estimation more difficult in

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

One more item to consider is "signature covers witness weight". While signing the witness weight doesn't completely eliminate witness malleability (of the kind that can cause grief for compact blocks), it does eliminate the worst kind of witness malleability from the user's perspective, the kind

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

I'd like to retract my comments regarding SINGLE. I was contacted in private and it was pointed out to me that I was confusing `sighash_single` with `sighash_single|sighash_anyonecanpay`. I appreciate the correction and would like to avoid creating confusion with my previous comments, hence the

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

Pieter Wuille via bitcoin-dev writes: > On Mon, 19 Nov 2018 at 14:37, Pieter Wuille wrote: > * It's probably better to sign the amounts of all inputs, as suggested > by Johnson Lau. As that would cause default sighashes to sign all > input and output amounts, is there still a need to sign the

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

We are also prototyping the OP_CHECKSIGFROMSTACK mechanism using Liquid/Elements. Given uncertainty about which features will actually be deployed on mainnet, we're exploring all possibilities so as to provide feedback about the "best" way to implement a covenant/vault, also including the

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

This is incompatible with bip-schnorr, which intentionally disallow such use by always committing to the public key: https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki With the recent fake Satoshi signature drama, and other potential ways to misuse and abuse, I think this is a

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

> On 28 Nov 2018, at 11:41 AM, Pieter Wuille via bitcoin-dev > wrote: > > So a combined proposal: > * All existing sighash flags, plus NOINPUT and MASK > (ANYONECANPAY/NOINPUT/MASK are encoded in 2 bits). > * A new opcode called OP_MASKEDPUSH, whose only runtime behaviour is > failing if not

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

On Mon, 19 Nov 2018 at 14:37, Pieter Wuille wrote: > Here is a combined proposal: > * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE, and > SIGHASH_SCRIPTMASK. > * A new opcode OP_MASK is added, which acts as a NOP during execution. > * The sighash is computed like in BIP143,

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

I have been working on an experimental wallet that implements Bitcoin Covenants/Vaults following a blog post I wrote about 2 years ago, using "Pay-to-Timelock Signed Transaction" (P2TST). (Also mentioned recently by kanzure in a talk somewheres...) The idea is that you deposit to an address for

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

> On 23 Nov 2018, at 5:40 PM, Christian Decker via bitcoin-dev > wrote: > > Anthony Towns writes: >> Commiting to just the sequence numbers seems really weird to me; it >> only really prevents you from adding inputs, since you could still >> replace any input that was meant to be there by

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

On Fri, Nov 23, 2018 at 12:03 AM Anthony Towns wrote: > On Wed, Nov 21, 2018 at 12:07:30PM -0500, Russell O'Connor via bitcoin-dev > wrote: > > Given that we want to move away from OP_CODESEPARATOR, because each call > to > > this operation effectively takes O(script-size) time, we need a >

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

>Even still, each call to OP_CODESEPARATOR / OP_CHECKSIG pair requires >recomputing a new #5. scriptCode from BIP 143, and hence computes a new >transaction digest. In the existing sighash (i.e. legacy and BIP143), there are 6 canonical SIGHASH types: 1, 2, 3, 0x81, 0x82, 0x83. In consensus,

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

Anthony Towns writes: > Commiting to just the sequence numbers seems really weird to me; it > only really prevents you from adding inputs, since you could still > replace any input that was meant to be there by almost any arbitrary > other transaction... It's a really roundabout way of

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

On Wed, Nov 21, 2018 at 12:15:44PM +0100, Christian Decker via bitcoin-dev wrote: > One minor thing that I noticed a while ago and that I meant > to fix on BIP118 is that `hashSequence` does not need to be blanked for > eltoo to work (since where it is needed we also use `sighash_single`), > so

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

On Wed, Nov 21, 2018 at 12:07:30PM -0500, Russell O'Connor via bitcoin-dev wrote: > Given that we want to move away from OP_CODESEPARATOR, because each call to > this operation effectively takes O(script-size) time, we need a replacement > for > the functionality it currently provides.  While

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

On Thu, Nov 22, 2018 at 3:53 PM Johnson Lau wrote: > Assuming a script size of 128 bytes (including SHA256 padding), 2^20 > scripts is 134MB. Double it to 268MB for the merkle branch hashes. With > roughly 100MB/s, this should take 2.5s (or 42min for 30 levels). However, > memory use is not

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

Assuming a script size of 128 bytes (including SHA256 padding), 2^20 scripts is 134MB. Double it to 268MB for the merkle branch hashes. With roughly 100MB/s, this should take 2.5s (or 42min for 30 levels). However, memory use is not considered. >each call to this operation effectively takes

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

I see, so your suggestion is that a sequence of OP_IF ... OP_ENDIF can be replaced by a Merklized Script tree of that depth in practice. I'm concerned that at script creation time it takes exponential time to complete a Merkle root of depth 'n'. Can anyone provide benchmarks or estimates of how

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

With MAST in taproot, OP_IF etc become mostly redundant, with worse privacy. To maximise fungibility, we should encourage people to use MAST, instead of improve the functionality of OP_IF and further complicate the protocol. > On 22 Nov 2018, at 1:07 AM, Russell O'Connor via bitcoin-dev >

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

If we sign the txids of all inputs, we should also explicitly commit to their values. Only this could fully eliminate any possible way to lie about input value to hardware wallets > Does it make sense to keep SIGHASH_NONE? SIGHASH_NONE should be kept. ANYONECANPAY|NONE allows donation of dust

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

On Mon, Nov 19, 2018 at 10:22 PM Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > So my question is whether anyone can see ways in which this introduces > redundant flexibility, or misses obvious use cases? > Hopefully my comment is on-topic for this thread: Given

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

Anthony Towns via bitcoin-dev writes: > Given this implementation, NOINPUT effectively implies ANYONECANPAY, > I think. (I think that is also true of BIP 118's NOINPUT spec) I mentioned this in my reply to Pieter, but this may not be true if we remove the blanking of the `hashSequence` field.

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

Hi Pieter, great proposal, I think this may address some of the (perceived) downsides of BIP118, by committing to the script when possible (always?). One minor thing that I noticed a while ago and that I meant to fix on BIP118 is that `hashSequence` does not need to be blanked for eltoo to work

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

On Mon, Nov 19, 2018 at 02:37:57PM -0800, Pieter Wuille via bitcoin-dev wrote: > Here is a combined proposal: > * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE, > and SIGHASH_SCRIPTMASK. > * A new opcode OP_MASK is added, which acts as a NOP during execution. > * The sighash is