Re: [bitcoin-dev] BIP sighash_noinput

[Jonas Nick via bitcoin-dev]

Oh, I missed that that's still the case with NOINPUT - thanks for pointing it
out. In that case there's no reason to sign the other inputs' sequence and
that's even better because the current NOINPUT proposal already enables
taprootifiability of eltoo unilateral closings.

On 9/26/18 7:45 PM, Johnson Lau wrote:
> In BIP143, the nSequence of the same input is always signed, with any 
> hashtype. Why do you need to sign the sequence of other inputs?
> 
>> On 26 Sep 2018, at 5:36 PM, Jonas Nick via bitcoin-dev 
>>  wrote:
>>
>>> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
>>> hashSequence so that its behaviour is consistent with ANYONECANPAY?
>>
>> There is a good reason for not doing that. If NOINPUT would sign the
>> hashSequence then it would be possible to get rid of OP_CSV in eltoo update
>> scripts. As a result update scripts could be taprootified because the more
>> common branch (settlement) would be just a 2-of-2 multisig. Applying taproot
>> would then make unilateral settlement look like a single pubkey spend and 
>> avoid
>> having to reveal the unexecuted (update) branch.
>>
>> Eltoo update transaction outputs consist of two branches, update and
>> settlement, where the update branch can be spend by a more recent update
>> transaction if an obsolete update transaction ends up spending the funding
>> output. The settlement branch is a 2-of-2 multisig with a relative timelock
>> using OP_CSV. Removing OP_CSV is possible because both parties signature is
>> required to spend the update transaction. They will only sign if the input 
>> has
>> the right sequence numbers which is sufficient to enforce the timeout 
>> (BIP68) -
>> assuming they are covered by the signature.
>>
>> There's a catch: hashSequence includes the sequence numbers of all 
>> transaction
>> inputs. That's not a problem for eltoo because settlement transactions only
>> have one input. The update mechanism with update transactions relies on being
>> able to bump the fee by unilaterally adding inputs and and change outputs to
>> the transaction. That's also not a problem because update spends do not use
>> relative timelocks and they are signed with SINGLE. So whenever NOINPUT is
>> combined SINGLE the hashSequence should be zeroed. This is in fact what a
>> minimal change to the current NOINPUT implementation would naturally do (see
>> below). However, that's error-prone when using NOINPUT in other contexts so 
>> in
>> general it would be better if NOINPUT would only sign the sequence number of
>> the corresponding input.
>>
>> Another downside of this approach is that you can never rebind to an output
>> with an OP_CSV that requires a larger sequence number, unless you also sign
>> with SIGHASH_SINGLE. It's difficult to imagine application where this would 
>> be
>> an issue.
>>
>> This is the modification to the NOINPUT implementation
>> (https://github.com/cdecker/bitcoin/commits/noinput) which makes eltoo
>> unilateral closes taprootifiable:
>> +++ b/src/script/interpreter.cpp
>> @@ -1223,7 +1223,7 @@ uint256 SignatureHash(const CScript& scriptCode, const 
>> CTransaction& txTo, unsig
>> hashPrevouts = cacheready ? cache->hashPrevouts : 
>> GetPrevoutHash(txTo);
>> }
>>
>> -if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != 
>> SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE && !noinput) {
>> +if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != 
>> SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
>> hashSequence = cacheready ? cache->hashSequence : 
>> GetSequenceHash(txTo);
>> }
>>
>> On 5/1/18 4:58 PM, Russell O'Connor via bitcoin-dev wrote:
>>> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
>>> hashSequence so that its behaviour is consistent with ANYONECANPAY?
>>>
>>
> 
> 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP sighash_noinput

[Johnson Lau via bitcoin-dev]

In BIP143, the nSequence of the same input is always signed, with any hashtype. 
Why do you need to sign the sequence of other inputs?

> On 26 Sep 2018, at 5:36 PM, Jonas Nick via bitcoin-dev 
>  wrote:
> 
>> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
>> hashSequence so that its behaviour is consistent with ANYONECANPAY?
> 
> There is a good reason for not doing that. If NOINPUT would sign the
> hashSequence then it would be possible to get rid of OP_CSV in eltoo update
> scripts. As a result update scripts could be taprootified because the more
> common branch (settlement) would be just a 2-of-2 multisig. Applying taproot
> would then make unilateral settlement look like a single pubkey spend and 
> avoid
> having to reveal the unexecuted (update) branch.
> 
> Eltoo update transaction outputs consist of two branches, update and
> settlement, where the update branch can be spend by a more recent update
> transaction if an obsolete update transaction ends up spending the funding
> output. The settlement branch is a 2-of-2 multisig with a relative timelock
> using OP_CSV. Removing OP_CSV is possible because both parties signature is
> required to spend the update transaction. They will only sign if the input has
> the right sequence numbers which is sufficient to enforce the timeout (BIP68) 
> -
> assuming they are covered by the signature.
> 
> There's a catch: hashSequence includes the sequence numbers of all transaction
> inputs. That's not a problem for eltoo because settlement transactions only
> have one input. The update mechanism with update transactions relies on being
> able to bump the fee by unilaterally adding inputs and and change outputs to
> the transaction. That's also not a problem because update spends do not use
> relative timelocks and they are signed with SINGLE. So whenever NOINPUT is
> combined SINGLE the hashSequence should be zeroed. This is in fact what a
> minimal change to the current NOINPUT implementation would naturally do (see
> below). However, that's error-prone when using NOINPUT in other contexts so in
> general it would be better if NOINPUT would only sign the sequence number of
> the corresponding input.
> 
> Another downside of this approach is that you can never rebind to an output
> with an OP_CSV that requires a larger sequence number, unless you also sign
> with SIGHASH_SINGLE. It's difficult to imagine application where this would be
> an issue.
> 
> This is the modification to the NOINPUT implementation
> (https://github.com/cdecker/bitcoin/commits/noinput) which makes eltoo
> unilateral closes taprootifiable:
> +++ b/src/script/interpreter.cpp
> @@ -1223,7 +1223,7 @@ uint256 SignatureHash(const CScript& scriptCode, const 
> CTransaction& txTo, unsig
> hashPrevouts = cacheready ? cache->hashPrevouts : 
> GetPrevoutHash(txTo);
> }
> 
> -if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != 
> SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE && !noinput) {
> +if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != 
> SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
> hashSequence = cacheready ? cache->hashSequence : 
> GetSequenceHash(txTo);
> }
> 
> On 5/1/18 4:58 PM, Russell O'Connor via bitcoin-dev wrote:
>> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
>> hashSequence so that its behaviour is consistent with ANYONECANPAY?
>> 
> 


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

Re: [bitcoin-dev] BIP sighash_noinput

[Jonas Nick via bitcoin-dev]

> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
> hashSequence so that its behaviour is consistent with ANYONECANPAY?

There is a good reason for not doing that. If NOINPUT would sign the
hashSequence then it would be possible to get rid of OP_CSV in eltoo update
scripts. As a result update scripts could be taprootified because the more
common branch (settlement) would be just a 2-of-2 multisig. Applying taproot
would then make unilateral settlement look like a single pubkey spend and avoid
having to reveal the unexecuted (update) branch.

Eltoo update transaction outputs consist of two branches, update and
settlement, where the update branch can be spend by a more recent update
transaction if an obsolete update transaction ends up spending the funding
output. The settlement branch is a 2-of-2 multisig with a relative timelock
using OP_CSV. Removing OP_CSV is possible because both parties signature is
required to spend the update transaction. They will only sign if the input has
the right sequence numbers which is sufficient to enforce the timeout (BIP68) -
assuming they are covered by the signature.

There's a catch: hashSequence includes the sequence numbers of all transaction
inputs. That's not a problem for eltoo because settlement transactions only
have one input. The update mechanism with update transactions relies on being
able to bump the fee by unilaterally adding inputs and and change outputs to
the transaction. That's also not a problem because update spends do not use
relative timelocks and they are signed with SINGLE. So whenever NOINPUT is
combined SINGLE the hashSequence should be zeroed. This is in fact what a
minimal change to the current NOINPUT implementation would naturally do (see
below). However, that's error-prone when using NOINPUT in other contexts so in
general it would be better if NOINPUT would only sign the sequence number of
the corresponding input.

Another downside of this approach is that you can never rebind to an output
with an OP_CSV that requires a larger sequence number, unless you also sign
with SIGHASH_SINGLE. It's difficult to imagine application where this would be
an issue.

This is the modification to the NOINPUT implementation
(https://github.com/cdecker/bitcoin/commits/noinput) which makes eltoo
unilateral closes taprootifiable:
+++ b/src/script/interpreter.cpp
@@ -1223,7 +1223,7 @@ uint256 SignatureHash(const CScript& scriptCode, const 
CTransaction& txTo, unsig
 hashPrevouts = cacheready ? cache->hashPrevouts : 
GetPrevoutHash(txTo);
 }

-if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != 
SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE && !noinput) {
+if (!(nHashType & SIGHASH_ANYONECANPAY) && (nHashType & 0x1f) != 
SIGHASH_SINGLE && (nHashType & 0x1f) != SIGHASH_NONE) {
 hashSequence = cacheready ? cache->hashSequence : 
GetSequenceHash(txTo);
 }

On 5/1/18 4:58 PM, Russell O'Connor via bitcoin-dev wrote:
> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
> hashSequence so that its behaviour is consistent with ANYONECANPAY?
> 
> On Mon, Apr 30, 2018 at 12:29 PM, Christian Decker via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
>> Hi all,
>>
>> I'd like to pick up the discussion from a few months ago, and propose a new
>> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the
>> previous
>> output. This was previously mentioned on the list by Joseph Poon [1], but
>> was
>> never formally proposed, so I wrote a proposal [2].
>>
>> We have long known that `SIGHASH_NOINPUT` would be a great fit for
>> Lightning.
>> They enable simple watch-towers, i.e., outsource the need to watch the
>> blockchain for channel closures, and react appropriately if our
>> counterparty
>> misbehaves. In addition to this we just released the eltoo [3,4] paper
>> which
>> describes a simplified update mechanism that can be used in Lightning, and
>> other
>> off-chain contracts, with any number of participants.
>>
>> By not committing to the previous output being spent by the transaction,
>> we can
>> rebind an input to point to any outpoint with a matching output script and
>> value. The binding therefore is no longer explicit through a reference, but
>> through script compatibility, and the transaction ID reference in the
>> input is a
>> hint to validators. The sighash flag is meant to enable some off-chain
>> use-cases
>> and should not be used unless the tradeoffs are well-known. In particular
>> we
>> suggest using contract specific key-pairs, in order to avoid having any
>> unwanted
>> rebinding opportunities.
>>
>> The proposal is very minimalistic, and simple. However, there are a few
>> things
>> where we'd like to hear the input of the wider community with regards to
>> the
>> implementation details though. We had some discussions internally on
>> whether to
>> use a separate opcode or a sighash flag, some feeling that the sighash 

Re: [bitcoin-dev] BIP sighash_noinput

[Peter Todd via bitcoin-dev]

On Tue, Jul 03, 2018 at 11:45:22PM +, Gregory Maxwell wrote:
> On Tue, Jul 3, 2018 at 5:21 AM, Peter Todd  wrote:
> > The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing
> > about what the flag actually does.
> 
> I believe that making the signature replayable is 1:1 with omitting
> the identification of the specific coin being spent from it.

I think you have a good point there. But that's not the only way that reuse
could be a vulnerability: consider hash-based signatures.

I'm happy with adding a suffix or prefix to the term SIGHASH_NOINPUT, e.g.
SIGHASH_NOINPUT_UNSAFE to re-use Rust terminology.

-- 
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] BIP sighash_noinput

[Gregory Maxwell via bitcoin-dev]

On Tue, Jul 3, 2018 at 5:21 AM, Peter Todd  wrote:
> The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing
> about what the flag actually does.

I believe that making the signature replayable is 1:1 with omitting
the identification of the specific coin being spent from it.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP sighash_noinput

[Christian Decker via bitcoin-dev]

Gregory Maxwell  writes:
> I know it seems kind of silly, but I think it's somewhat important
> that the formal name of this flag is something like
> "SIGHASH_REPLAY_VULNERABLE" or likewise or at least
> "SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially
> insecure for traditional applications where a third party might pay to
> an address a second time, and should only be used in special protocols
> which make that kind of mistake unlikely.   Otherwise, I'm worried
> that wallets might start using this sighash because it simplifies
> handling malleability without realizing that when a third party reuses
> a script pubkey, completely outside of control of the wallet that uses
> the flag, funds will be lost as soon as a troublemaker shows up (but
> not, sadly, in testing).  This sort of risk is magnified because the
> third party address reuser has no way to know that this sighash flag
> has (or will) be used with a particular scriptpubkey.

Absolutely agree that we should be signaling the danger of using noinput
as clearly as possible to developers, and I'm more than happy to adopt
the _unsafe suffix suggested by jb55. I think using non-sighash_all
sighashes is always a huge danger, as you have correctly pointed out, so
maybe we should be marking all of them as being unsafe, or make sure to
communicate that danger on a higher level (docs).
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP sighash_noinput

[Peter Todd via bitcoin-dev]

On Tue, Jul 03, 2018 at 02:26:53PM +0930, Rusty Russell via bitcoin-dev wrote:
> Gregory Maxwell via bitcoin-dev  
> writes:
> > On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev
> >  wrote:
> >> Hi all,
> >>
> >> I'd like to pick up the discussion from a few months ago, and propose a new
> >> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the 
> >> previous
> >
> > I know it seems kind of silly, but I think it's somewhat important
> > that the formal name of this flag is something like
> > "SIGHASH_REPLAY_VULNERABLE" or likewise or at least
> > "SIGHASH_WEAK_REPLAYABLE".
> 
> I agree with the DO_NOT_WANT-style naming.  REUSE_VULNERABLE seems to
> capture it: the word VULNERABLE should scare people away (or at least
> cause them to google further).

The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing
about what the flag actually does.

What name are we going to give a future flag that does something different, but
is also replay vulnerable?

-- 
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] BIP sighash_noinput

[Rusty Russell via bitcoin-dev]

Gregory Maxwell via bitcoin-dev  writes:
> On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev
>  wrote:
>> Hi all,
>>
>> I'd like to pick up the discussion from a few months ago, and propose a new
>> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous
>
> I know it seems kind of silly, but I think it's somewhat important
> that the formal name of this flag is something like
> "SIGHASH_REPLAY_VULNERABLE" or likewise or at least
> "SIGHASH_WEAK_REPLAYABLE".

I agree with the DO_NOT_WANT-style naming.  REUSE_VULNERABLE seems to
capture it: the word VULNERABLE should scare people away (or at least
cause them to google further).

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

Re: [bitcoin-dev] BIP sighash_noinput

[Gregory Maxwell via bitcoin-dev]

On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev
 wrote:
> Hi all,
>
> I'd like to pick up the discussion from a few months ago, and propose a new
> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous

I know it seems kind of silly, but I think it's somewhat important
that the formal name of this flag is something like
"SIGHASH_REPLAY_VULNERABLE" or likewise or at least
"SIGHASH_WEAK_REPLAYABLE". This is because noinput is materially
insecure for traditional applications where a third party might pay to
an address a second time, and should only be used in special protocols
which make that kind of mistake unlikely.   Otherwise, I'm worried
that wallets might start using this sighash because it simplifies
handling malleability without realizing that when a third party reuses
a script pubkey, completely outside of control of the wallet that uses
the flag, funds will be lost as soon as a troublemaker shows up (but
not, sadly, in testing).  This sort of risk is magnified because the
third party address reuser has no way to know that this sighash flag
has (or will) be used with a particular scriptpubkey.

So, one could even argue that the possibility that someone might use
this flag means that it's generally unsafe to reuse a scriptpubkey.  I
don't think the same argument applies for NONE or the single-bug
because they render even a single use insecure...  The best mitigation
I can think of is defence in depth to ensure that anyone who uses this
sighash flag understands the consequences.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP sighash_noinput

[Christian Decker via bitcoin-dev]

Olaoluwa Osuntokun  writes:
> Super stoked to see that no_input has been resurrected!!! I actually
> implemented a variant back in 2015 when Tadge first described the
> approach to me for both btcd [1], and bitcoind [2]. The version being
> proposed is _slightly_ differ though, as the initial version I
> implemented still committed to the script being sent, while this new
> version just relies on witness validity instead. This approach is even
> more flexible as the script attached to the output being spent can
> change, without rendering the spending transaction invalid as long as
> the witness still ratifies a branch in the output's predicate.

Yeah, we removed the script commitment out of necessity for eltoo, but
it seems to add a lot of flexibility that might be useful. One
additional use-case that came to mind is having a recovery transaction
for vault-like scenarios, i.e., a transaction that can short-circuit a
thawing process of frozen funds. You'd keep that transaction in a vault,
pre-signed and bind it to whatever action you'd like to interrupt.

> Given that this would introduce a _new_ sighash flag, perhaps we
> should also attempt to bundle additional more flexible sighash flags
> concurrently as well?  This would require a larger overhaul w.r.t to
> how sighash flags are interpreted, so in this case, we may need to
> introduce a new CHECKSIG operator (lets call it CHECKSIG_X for now),
> which would consume an available noop opcode. As a template for more
> fine grained sighashing control, I'll refer to jl2012's BIP-0YYY [3]
> (particularly the "New nHashType definitions" section).  This was
> originally proposed in the context of his merklized script work as it
> more or less opened up a new opportunity to further modify script
> within the context of merklized script executions.  The approach reads
> in the sighash flags as a bit vector, and allows developers to express
> things like: "don't sign the input value, nor the sequence, but sign
> the output of this input, and ONLY the script of this output". This
> approach is _extremely_ powerful, and one would be able to express the
> equivalent of no_input by setting the appropriate bits in the sighash.

I purposefully made the proposal as small and as well defined as
possible, with a number of possible applications to back it, since I
think this might be the best way to introduce a new feature and make it
as uncontroversial as possible. I'm not opposed to additional flags
being deployed in parallel, but they'll need their own justification and
analysis, and shouldn't be rushed just "because we're doing noinput".

Going for a separate op-code is definitely an option we considered, but
just for noinput it'd be duplicating quite a lot of existing
functionality. With additional sighash flags it might become necessary,
but I don't think it is necessary just for noinput.

> Looking forward in hearing y'alls thoughts on this approach, thanks.
>
> [1]: https://github.com/Roasbeef/btcd/commits/SIGHASH_NOINPUT
> [2]: https://github.com/Roasbeef/bitcoin/commits/SIGHASH_NOINPUT
> [3]: 
> https://github.com/jl2012/bips/blob/vault/bip-0YYY.mediawiki#new-nhashtype-definitions
>
> -- Laolu
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP sighash_noinput

[Rusty Russell via bitcoin-dev]

Anthony Towns via bitcoin-dev  writes:
> On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev 
> wrote:
>> Given the general enthusiasm, and lack of major criticism, for the
>> `SIGHASH_NOINPUT` proposal, [...]
>
> So first, I'm not sure if I'm actually criticising or playing devil's
> advocate here, but either way I think criticism always helps produce
> the best proposal, so
>
> The big concern I have with _NOINPUT is that it has a huge failure
> case: if you use the same key for multiple inputs and sign one of them
> with _NOINPUT, you've spent all of them. The current proposal kind-of
> limits the potential damage by still committing to the prevout amount,
> but it still seems a big risk for all the people that reuse addresses,
> which seems to be just about everyone.

If I can convince you to sign with SIGHASH_NONE, it's already a problem
today.

> I wonder if it wouldn't be ... I'm not sure better is the right word,
> but perhaps "more realistic" to have _NOINPUT be a flag to a signature
> for a hypothetical "OP_CHECK_SIG_FOR_SINGLE_USE_KEY" opcode instead,
> so that it's fundamentally not possible to trick someone who regularly
> reuses keys to sign something for one input that accidently authorises
> spends of other inputs as well.

That was also suggested by Mark Friedenbach, but I think we'll end up
with more "magic key" a-la Schnorr/taproot/graftroot and less script in
future.

That means we'd actually want a different Segwit version for
"NOINPUT-can-be-used", which seems super ugly.

> Maybe a different opcode maybe makes sense at a "philosophical" level:
> normal signatures are signing a spend of a particular "coin" (in the
> UTXO sense), while _NOINPUT signatures are in some sense signing a spend
> of an entire "wallet" (all the coins spendable by a particular key, or
> more accurately for the current proposal, all the coins of a particular
> value spendable by a particular key). Those are different intentions,
> so maybe it's reasonable to encode them in different addresses, which
> in turn could be done by having a new opcode for _NOINPUT.

In a world where SIGHASH_NONE didn't exist, this might be an argument :)

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

Re: [bitcoin-dev] BIP sighash_noinput

[Olaoluwa Osuntokun via bitcoin-dev]

> The current proposal kind-of limits the potential damage by still
committing
> to the prevout amount, but it still seems a big risk for all the people
that
> reuse addresses, which seems to be just about everyone.

The typical address re-use doesn't apply here as this is a sighash flag that
would only really be used for doing various contracts on Bitcoin. I don't
see any reason why "regular" wallets would update to use this sighash flag.
We've also seen first hand with segwit that wallet authors are slow to pull
in the latest and greatest features available, even if they solve nuisance
issues like malleability and can result in lower fees.

IMO, sighash_none is an even bigger footgun that already exists in the
protocol today.

-- Laolu


On Tue, May 8, 2018 at 7:41 AM Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev
> wrote:
> > Given the general enthusiasm, and lack of major criticism, for the
> > `SIGHASH_NOINPUT` proposal, [...]
>
> So first, I'm not sure if I'm actually criticising or playing devil's
> advocate here, but either way I think criticism always helps produce
> the best proposal, so
>
> The big concern I have with _NOINPUT is that it has a huge failure
> case: if you use the same key for multiple inputs and sign one of them
> with _NOINPUT, you've spent all of them. The current proposal kind-of
> limits the potential damage by still committing to the prevout amount,
> but it still seems a big risk for all the people that reuse addresses,
> which seems to be just about everyone.
>
> I wonder if it wouldn't be ... I'm not sure better is the right word,
> but perhaps "more realistic" to have _NOINPUT be a flag to a signature
> for a hypothetical "OP_CHECK_SIG_FOR_SINGLE_USE_KEY" opcode instead,
> so that it's fundamentally not possible to trick someone who regularly
> reuses keys to sign something for one input that accidently authorises
> spends of other inputs as well.
>
> Is there any reason why an OP_CHECKSIG_1USE (or OP_CHECKMULTISIG_1USE)
> wouldn't be equally effective for the forseeable usecases? That would
> ensure that a _NOINPUT signature is only ever valid for keys deliberately
> intended to be single use, rather than potentially valid for every key.
>
> It would be ~34 witness bytes worse than being able to spend a Schnorr
> aggregate key directly, I guess; but that's not worse than the normal
> taproot tradeoff: you spend the aggregate key directly in the normal,
> cooperative case; and reserve the more expensive/NOINPUT case for the
> unusual, uncooperative cases. I believe that works fine for eltoo: in
> the cooperative case you just do a SIGHASH_ALL spend of the original
> transaction, and _NOINPUT isn't needed.
>
> Maybe a different opcode maybe makes sense at a "philosophical" level:
> normal signatures are signing a spend of a particular "coin" (in the
> UTXO sense), while _NOINPUT signatures are in some sense signing a spend
> of an entire "wallet" (all the coins spendable by a particular key, or
> more accurately for the current proposal, all the coins of a particular
> value spendable by a particular key). Those are different intentions,
> so maybe it's reasonable to encode them in different addresses, which
> in turn could be done by having a new opcode for _NOINPUT.
>
> A new opcode has the theoretical advantage that it could be deployed
> into the existing segwit v0 address space, rather than waiting for segwit
> v1. Not sure that's really meaningful, though.
>
> Cheers,
> aj
>
> ___
> 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] BIP sighash_noinput

[Bram Cohen via bitcoin-dev]

A technical point about SIGHASH_NOINPUT: It seems like a more general and
technically simpler to implement idea would be to have a boolean specifying
whether the inputs listed must be all of them (the way it works normally)
or a subset of everything. It feels like a similar boolean should be made
for outputs as well. Or maybe a single boolean should apply to both. In any
case, one could always use SIGHASH_SUBSET and not specify any inputs and
that would have the same effect as SIGHASH_NOINPUT.

On Mon, May 7, 2018 at 12:40 PM, Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Given the general enthusiasm, and lack of major criticism, for the
> `SIGHASH_NOINPUT` proposal, I'd like to formally ask the BBEs (benevolent
> BIP editors) to be assigned a BIP number. I have hacked together a
> simple implementation of the hashing implementation in Bitcoin Core [1]
> though I think it's unlikely to sail through review, and given the lack
> of ground-work on witness V1 scripts, I can't really test it now, and
> only the second commit is part of the implementation itself.
>
> One issue that was raised off list was that some fork coins have used
> sighash 0x40 as FORKID. This does not conflict with this proposal since
> the proposal only applies to segwit transactions, which the fork coins
> have explicitly disabled :-)
>
> I'm looking forward to discussing how to we can move forward to
> implementing this proposal, and how we can combine multiple proposals
> into the next soft-fork.
>
> Cheers,
> Christian
>
> [1] https://github.com/cdecker/bitcoin/tree/noinput
> ___
> 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] BIP sighash_noinput

[Anthony Towns via bitcoin-dev]

On Mon, May 07, 2018 at 09:40:46PM +0200, Christian Decker via bitcoin-dev 
wrote:
> Given the general enthusiasm, and lack of major criticism, for the
> `SIGHASH_NOINPUT` proposal, [...]

So first, I'm not sure if I'm actually criticising or playing devil's
advocate here, but either way I think criticism always helps produce
the best proposal, so

The big concern I have with _NOINPUT is that it has a huge failure
case: if you use the same key for multiple inputs and sign one of them
with _NOINPUT, you've spent all of them. The current proposal kind-of
limits the potential damage by still committing to the prevout amount,
but it still seems a big risk for all the people that reuse addresses,
which seems to be just about everyone.

I wonder if it wouldn't be ... I'm not sure better is the right word,
but perhaps "more realistic" to have _NOINPUT be a flag to a signature
for a hypothetical "OP_CHECK_SIG_FOR_SINGLE_USE_KEY" opcode instead,
so that it's fundamentally not possible to trick someone who regularly
reuses keys to sign something for one input that accidently authorises
spends of other inputs as well.

Is there any reason why an OP_CHECKSIG_1USE (or OP_CHECKMULTISIG_1USE)
wouldn't be equally effective for the forseeable usecases? That would
ensure that a _NOINPUT signature is only ever valid for keys deliberately
intended to be single use, rather than potentially valid for every key.

It would be ~34 witness bytes worse than being able to spend a Schnorr
aggregate key directly, I guess; but that's not worse than the normal
taproot tradeoff: you spend the aggregate key directly in the normal,
cooperative case; and reserve the more expensive/NOINPUT case for the
unusual, uncooperative cases. I believe that works fine for eltoo: in
the cooperative case you just do a SIGHASH_ALL spend of the original
transaction, and _NOINPUT isn't needed.

Maybe a different opcode maybe makes sense at a "philosophical" level:
normal signatures are signing a spend of a particular "coin" (in the
UTXO sense), while _NOINPUT signatures are in some sense signing a spend
of an entire "wallet" (all the coins spendable by a particular key, or
more accurately for the current proposal, all the coins of a particular
value spendable by a particular key). Those are different intentions,
so maybe it's reasonable to encode them in different addresses, which
in turn could be done by having a new opcode for _NOINPUT.

A new opcode has the theoretical advantage that it could be deployed
into the existing segwit v0 address space, rather than waiting for segwit
v1. Not sure that's really meaningful, though.

Cheers,
aj

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

Re: [bitcoin-dev] BIP sighash_noinput

[Olaoluwa Osuntokun via bitcoin-dev]

Super stoked to see that no_input has been resurrected!!! I actually
implemented a variant back in 2015 when Tadge first described the approach
to
me for both btcd [1], and bitcoind [2]. The version being proposed is
_slightly_ differ though, as the initial version I implemented still
committed
to the script being sent, while this new version just relies on
witness validity instead. This approach is even more flexible as the script
attached to the output being spent can change, without rendering the
spending
transaction invalid as long as the witness still ratifies a branch in the
output's predicate.

Given that this would introduce a _new_ sighash flag, perhaps we should also
attempt to bundle additional more flexible sighash flags concurrently as
well?
This would require a larger overhaul w.r.t to how sighash flags are
interpreted, so in this case, we may need to introduce a new CHECKSIG
operator
(lets call it CHECKSIG_X for now), which would consume an available noop
opcode. As a template for more fine grained sighashing control, I'll refer
to
jl2012's BIP-0YYY [3] (particularly the "New nHashType definitions"
section).
This was originally proposed in the context of his merklized script work as
it
more or less opened up a new opportunity to further modify script within the
context of merklized script executions.  The approach reads in the
sighash flags as a bit vector, and allows developers to express things like:
"don't sign the input value, nor the sequence, but sign the output of this
input, and ONLY the script of this output". This approach is _extremely_
powerful, and one would be able to express the equivalent of no_input by
setting the appropriate bits in the sighash.

Looking forward in hearing y'alls thoughts on this approach, thanks.

[1]: https://github.com/Roasbeef/btcd/commits/SIGHASH_NOINPUT
[2]: https://github.com/Roasbeef/bitcoin/commits/SIGHASH_NOINPUT
[3]:
https://github.com/jl2012/bips/blob/vault/bip-0YYY.mediawiki#new-nhashtype-definitions

-- Laolu

On Mon, Apr 30, 2018 at 10:30 AM Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> I'd like to pick up the discussion from a few months ago, and propose a new
> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the
> previous
> output. This was previously mentioned on the list by Joseph Poon [1], but
> was
> never formally proposed, so I wrote a proposal [2].
>
> We have long known that `SIGHASH_NOINPUT` would be a great fit for
> Lightning.
> They enable simple watch-towers, i.e., outsource the need to watch the
> blockchain for channel closures, and react appropriately if our
> counterparty
> misbehaves. In addition to this we just released the eltoo [3,4] paper
> which
> describes a simplified update mechanism that can be used in Lightning, and
> other
> off-chain contracts, with any number of participants.
>
> By not committing to the previous output being spent by the transaction,
> we can
> rebind an input to point to any outpoint with a matching output script and
> value. The binding therefore is no longer explicit through a reference, but
> through script compatibility, and the transaction ID reference in the
> input is a
> hint to validators. The sighash flag is meant to enable some off-chain
> use-cases
> and should not be used unless the tradeoffs are well-known. In particular
> we
> suggest using contract specific key-pairs, in order to avoid having any
> unwanted
> rebinding opportunities.
>
> The proposal is very minimalistic, and simple. However, there are a few
> things
> where we'd like to hear the input of the wider community with regards to
> the
> implementation details though. We had some discussions internally on
> whether to
> use a separate opcode or a sighash flag, some feeling that the sighash flag
> could lead to some confusion with existing wallets, but given that we have
> `SIGHASH_NONE`, and that existing wallets will not sign things with unknown
> flags, we decided to go the sighash way. Another thing is that we still
> commit
> to the amount of the outpoint being spent. The rationale behind this is
> that,
> while rebinding to outpoints with the same value maintains the value
> relationship between input and output, we will probably not want to bind to
> something with a different value and suddenly pay a gigantic fee.
>
> The deployment part of the proposal is left vague on purpose in order not
> to
> collide with any other proposals. It should be possible to introduce it by
> bumping the segwit script version and adding the new behavior.
>
> I hope the proposal is well received, and I'm looking forward to discussing
> variants and tradeoffs here. I think the applications we proposed so far
> are
> quite interesting, and I'm sure there are many more we can enable with this
> change.
>
> Cheers,
> Christian
>
> [1]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012460.html
> [2] 

Re: [bitcoin-dev] BIP sighash_noinput

[ZmnSCPxj via bitcoin-dev]

Good morning Christian,


> ZmnSCPxj zmnsc...@protonmail.com writes:
> 
> > It seems to me, that `SIGHASH_NOINPUT` may help make some protocol
> > 
> > integrate better with existing wallets.
> 
> Depends on which end of a transaction the existing wallet is: existing
> 
> wallets will refuse to sign a transaction with an unknown sighash flag,
> 
> but if the wallet is creating the output that'll later be spent using a
> 
> `SIGHASH_NOINPUT` transaction it won't (and shouldn't) care.
>

Yes, the intent is that specialized utilities (like the CoinSwap I gave as an 
example) would be the ones signing with `SIGHASH_NOINPUT`, with the existing 
wallet generating the output that will be spent with a `SIGHASH_NOINPUT`.

The issue is that some trustless protocols have an offchain component, where 
some kind of backoff transaction is created, and the creation involves the 3 
steps (1) make but do not sign a funding tx (2) make and sign a 
backoff transaction that spends the funding tx (3) sign and broadcast the 
original funding tx. This holds for Poon-Dryja, your new eltoo 
Decker-Russell-Osuntokun, and CoinSwap.  Commodity user wallets and exchange 
wallets only support the most basic "make tx, sign, broadcast", and integrating 
with the generalized funding transaction pattern is not possible.  
`SIGHASH_NOINPUT` allows us to make the backoff transaction first, then make 
the funding transaction via the usual "make tx, sign, broadcast" procedure that 
commodity wallets implement.

> > A drawback of course, is that `SIGHASH_NOINPUT` is an unusual flag to
> > 
> > use; it immediately paints the user as using some special protocol.
> > 
> > So much for `SIGHASH_NOINPUT` CoinSwap.
> 
> By providing a new use-case you are contributing to the obfuscation of
> 
> this technique. The more normal the use of `SIGHASH_NOINPUT` becomes the
> 
> less an observer can learn from it being used. In combination with MAST,
> 
> Taproot or Graftroot we can further hide the details of the executed
> 
> protocol :-)

Thinking about it further, it turns out that in the cooperative completion of 
the protocol, we do not need to sign anything using `SIGHASH_NOINPUT`, but can 
use the typical `SIGHASH_ALL`. Indeed all generalized funding transaction 
patterns can be updated to use this: only the initial backout transaction needs 
to be signed with `SIGHASH_NOINPUT`, all others can be signed with 
`SIGHASH_ALL`, including the protocol conclusion transaction.

1.  In CoinSwapCS, TX-0 and TX-1 are funding transactions.  The backoff 
transaction is the TX-2 and TX-3 transactions.  Only TX-2 and TX-3 need be 
signed with `SIGHASH_NOINPUT`.  TX-4 and TX-5, which complete the protocol and 
hide the swap, can be signed with `SIGHASH_ALL`.

2.  In Poon-Dryja, the backoff transaction is the very first commitment 
transaction.  Again only that transaction needs to be signed with 
`SIGHASH_NOINPUT`: future commitment transactions as well as the mutual close 
transaction can be signed with `SIGHASH_ALL`.

3.  In Decker-Russell-Osuntokun, the backoff transaction is the trigger 
transaction and the first settlement transaction.  The trigger transaction can 
sign with `SIGHASH_NOINPUT`.  Then only the final settlement (i.e. mutual 
close) can be signed with `SIGHASH_ALL`.

Thus if the protocol completes cooperatively, the only onchain evidence is that 
a 2-of-2 multisig is spent, and signed using `SIGHASH_ALL`, and the money goes 
to some ordinary P2WPKH addresses.

The advantage, as I mentioned, is that these protocols can be implemented using 
"walletless" software: the special protocol software runs the protocol up to 
the point that they get the backoff transaction, then asks the user to pay an 
exact amount to an exact address.  This has a number of advantages:

1.  RBF can be supported if the wallet software supports RBF.  In particular 
without `SIGHASH_NOINPUT` the protocol would require renegotiation of a new 
backoff transaction in order to support RBF (and in particular the protocol 
spec would need to be designed in the first place to consider that 
possibility!), and would become more complicated since while a new backoff 
transaction is being negotiated, the previous version of the funding 
transaction may get confirmed.  With `SIGHASH_NOINPUT` all the specialized 
protocol software needs to do, is to watch for a transaction paying to the 
given address to be confirmed deeply enough to be unlikely to be reorganized: 
there is no need to renegotiate a backoff transaction, because whatever 
transaction gets confirmed, as long as it pays to the address with a given 
amount, the signature for the backoff transaction remains valid for it.
2.  Wallet software of any kind can be used in conjunction with special 
protocol software of any kind.  Hardware wallets do not need to implement LN: 
the LN software starts a channel and gives a P2WSH address that hardware 
wallets know how to pay to.  Ditto for exchange wallets.  Etc.  And if a future 

Re: [bitcoin-dev] BIP sighash_noinput

[Christian Decker via bitcoin-dev]

ZmnSCPxj  writes:
> It seems to me, that `SIGHASH_NOINPUT` may help make some protocol
> integrate better with existing wallets.

Depends on which end of a transaction the existing wallet is: existing
wallets will refuse to sign a transaction with an unknown sighash flag,
but if the wallet is creating the output that'll later be spent using a
`SIGHASH_NOINPUT` transaction it won't (and shouldn't) care.

> I remember vaguely that `SIGHASH_NOINPUT` was also mentioned before in
> LN discussions, when the issue of transaction malleation was
> considered (before SegWit, being totally uncontroversial, was
> massively adopted).  The sketch below, I believe, is somewhat
> consistent with how it could have been used in funding a channel.

I consider `SIGHASH_NOINPUT` to be a poor-man's malleability fix, since
it comes with some baggage. Without trying to undermine my own proposal,
but address reuse in combination with binding through script, can lead
to very unexpected results. You need to be very careful about where you
allow rebinding, hence the warnings in the proposal.

> Consider a CoinSwap protocol.  Each side writes a transaction that
> pays out to an ordinary 2-of-2 multisig address.  But before each side
> writes and signs that transaction, it first demands a timelocked
> backout transaction to let them recover their own funds in case it
> falls through (more generally, every offchain protocol has a similar
> setup stage where some way to back out is signed before all parties
> enter into the contract).
>
> ...
>
> With `SIGHASH_NOINPUT`, we can indeed implement such a walletless
> CoinSwap (or other protocol) software.  We only need to provide the
> public keys that will be used in the initial 2-of-2, and the other
> side can create a signature with `SIGHASH_NOINPUT` flag.

I was wondering whether we could actually skip one communication round
w.r.t. the previously described CoinSwap protocol, but it turns out we
need to at least exchange public keys before actually moving any
funds. Would have been nice to do spontaneous CoinSwaps.

> The setup of the CoinSwap then goes this way.  The swapping nodes
> exchange public keys (two for each side in this case), they agree on
> who gets to move first in the swap and who generates the preimage, and
> then they agree on what the backout transactions look like (in
> particular, they agree on the address the backout transactions spend)
> and create signatures, with `SIGHASH_NOINPUT`.  In particular, the
> signatures do not commit to the txid of the transaction that they
> authorize spending.  The CoinSwap sofwares then turn around to their
> users and say "okay, send to this address", the users initiate the
> swap using their normal wallet software, the CoinSwap software
> monitors only the address it asked the user to use, then when it
> appears onchain (the CoinSwap software does not even need to track the
> mempool) it continues with the HTLC offers and preimage exchanges
> until the protocol completes.
>
> In a world where walletless CoinSwap exists, consider this:
>
> 1.  A user buys Bitcoin from an exchange.  The exchange operates a
> wallet which they credit when the user buys Bitcoin.
> 2.  The user starts a CoinSwap, giving the destination address from
> their cold-storage wallet.
> 3.  The CoinSwap tells the user an address to send to.  The user
> withdraws money from the exchange using that address as destination (1
> transaction)
> 4.  The user waits for the CoinSwap to finish, which causes the funds
> to appear in their cold-storage wallet (1 transaction).
>
> If CoinSwap implementations all needed their own wallets, then instead:
>
> 1.  A user buys Bitcoin from an exchange.
> 2.  The user withdraws the funds from the exchange to a CoinSwap
> implementation wallet (1 transaction).
> 3.  The user performs a CoinSwap which goes back to the CoinSwap
> implementation wallet (2 transactions).
> 4.  The user sends from the CoinSwap wallet to their cold storage (1
> transaction). (granted, the CoinSwap implementation could offer a
> feature that immediately transfers the swapped funds to some other
> wallet, but we still cannot get around the transfer from the exchange
> to the CoinSwap wallet)
>
> A drawback of course, is that `SIGHASH_NOINPUT` is an unusual flag to
> use; it immediately paints the user as using some special protocol.
> So much for `SIGHASH_NOINPUT` CoinSwap.

By providing a new use-case you are contributing to the obfuscation of
this technique. The more normal the use of `SIGHASH_NOINPUT` becomes the
less an observer can learn from it being used. In combination with MAST,
Taproot or Graftroot we can further hide the details of the executed
protocol :-)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP sighash_noinput

[Christian Decker via bitcoin-dev]

Russell O'Connor  writes:
> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
> hashSequence so that its behaviour is consistent with ANYONECANPAY?

Good catch, must've missed that somehow. I'll amend the BIP accordingly.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP sighash_noinput

[Russell O'Connor via bitcoin-dev]

At the risk of bikeshedding, shouldn't NOINPUT also zero out the
hashSequence so that its behaviour is consistent with ANYONECANPAY?

On Mon, Apr 30, 2018 at 12:29 PM, Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> I'd like to pick up the discussion from a few months ago, and propose a new
> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the
> previous
> output. This was previously mentioned on the list by Joseph Poon [1], but
> was
> never formally proposed, so I wrote a proposal [2].
>
> We have long known that `SIGHASH_NOINPUT` would be a great fit for
> Lightning.
> They enable simple watch-towers, i.e., outsource the need to watch the
> blockchain for channel closures, and react appropriately if our
> counterparty
> misbehaves. In addition to this we just released the eltoo [3,4] paper
> which
> describes a simplified update mechanism that can be used in Lightning, and
> other
> off-chain contracts, with any number of participants.
>
> By not committing to the previous output being spent by the transaction,
> we can
> rebind an input to point to any outpoint with a matching output script and
> value. The binding therefore is no longer explicit through a reference, but
> through script compatibility, and the transaction ID reference in the
> input is a
> hint to validators. The sighash flag is meant to enable some off-chain
> use-cases
> and should not be used unless the tradeoffs are well-known. In particular
> we
> suggest using contract specific key-pairs, in order to avoid having any
> unwanted
> rebinding opportunities.
>
> The proposal is very minimalistic, and simple. However, there are a few
> things
> where we'd like to hear the input of the wider community with regards to
> the
> implementation details though. We had some discussions internally on
> whether to
> use a separate opcode or a sighash flag, some feeling that the sighash flag
> could lead to some confusion with existing wallets, but given that we have
> `SIGHASH_NONE`, and that existing wallets will not sign things with unknown
> flags, we decided to go the sighash way. Another thing is that we still
> commit
> to the amount of the outpoint being spent. The rationale behind this is
> that,
> while rebinding to outpoints with the same value maintains the value
> relationship between input and output, we will probably not want to bind to
> something with a different value and suddenly pay a gigantic fee.
>
> The deployment part of the proposal is left vague on purpose in order not
> to
> collide with any other proposals. It should be possible to introduce it by
> bumping the segwit script version and adding the new behavior.
>
> I hope the proposal is well received, and I'm looking forward to discussing
> variants and tradeoffs here. I think the applications we proposed so far
> are
> quite interesting, and I'm sure there are many more we can enable with this
> change.
>
> Cheers,
> Christian
>
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2016-February/012460.html
> [2] https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki
> [3] https://blockstream.com/2018/04/30/eltoo-next-lightning.html
> [4] https://blockstream.com/eltoo.pdf
> ___
> bitcoin-dev mailing list
> bitcoin-dev@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] BIP sighash_noinput

[Dario Sneidermanis via bitcoin-dev]

Something like this might also be useful for several use cases related to
RBF. For example:

Alice sends Bob an RBF-activated transaction T1 with the intention of
bumping its fee if necessary. Bob wants to send these funds to Carol, but
cannot wait until T1 confirms, so he crafts a transaction T2 that spends T1
using SIGHASH_NOINPUT, and pays Carol. Carol can now make sure she receives
the money even if Alice fee-bumps T1, as long as the outputs of the
replaced transactions are compatible.

Extra care should be taken to avoid rebinding, maybe by including an extra
input in T2 that doesn't use SIGHASH_NOINPUT.

On Mon, Apr 30, 2018 at 1:29 PM, Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> I'd like to pick up the discussion from a few months ago, and propose a new
> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the
> previous
> output. This was previously mentioned on the list by Joseph Poon [1], but
> was
> never formally proposed, so I wrote a proposal [2].
>
> We have long known that `SIGHASH_NOINPUT` would be a great fit for
> Lightning.
> They enable simple watch-towers, i.e., outsource the need to watch the
> blockchain for channel closures, and react appropriately if our
> counterparty
> misbehaves. In addition to this we just released the eltoo [3,4] paper
> which
> describes a simplified update mechanism that can be used in Lightning, and
> other
> off-chain contracts, with any number of participants.
>
> By not committing to the previous output being spent by the transaction,
> we can
> rebind an input to point to any outpoint with a matching output script and
> value. The binding therefore is no longer explicit through a reference, but
> through script compatibility, and the transaction ID reference in the
> input is a
> hint to validators. The sighash flag is meant to enable some off-chain
> use-cases
> and should not be used unless the tradeoffs are well-known. In particular
> we
> suggest using contract specific key-pairs, in order to avoid having any
> unwanted
> rebinding opportunities.
>
> The proposal is very minimalistic, and simple. However, there are a few
> things
> where we'd like to hear the input of the wider community with regards to
> the
> implementation details though. We had some discussions internally on
> whether to
> use a separate opcode or a sighash flag, some feeling that the sighash flag
> could lead to some confusion with existing wallets, but given that we have
> `SIGHASH_NONE`, and that existing wallets will not sign things with unknown
> flags, we decided to go the sighash way. Another thing is that we still
> commit
> to the amount of the outpoint being spent. The rationale behind this is
> that,
> while rebinding to outpoints with the same value maintains the value
> relationship between input and output, we will probably not want to bind to
> something with a different value and suddenly pay a gigantic fee.
>
> The deployment part of the proposal is left vague on purpose in order not
> to
> collide with any other proposals. It should be possible to introduce it by
> bumping the segwit script version and adding the new behavior.
>
> I hope the proposal is well received, and I'm looking forward to discussing
> variants and tradeoffs here. I think the applications we proposed so far
> are
> quite interesting, and I'm sure there are many more we can enable with this
> change.
>
> Cheers,
> Christian
>
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
> 2016-February/012460.html
> [2] https://github.com/cdecker/bips/blob/noinput/bip-xyz.mediawiki
> [3] https://blockstream.com/2018/04/30/eltoo-next-lightning.html
> [4] https://blockstream.com/eltoo.pdf
> ___
> bitcoin-dev mailing list
> bitcoin-dev@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