Re: [bitcoin-dev] BIP sighash_noinput
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
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
> 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 f
Re: [bitcoin-dev] BIP sighash_noinput
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
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
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
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
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
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
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
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
> 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
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
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
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] https://github.com/cdecker/bips/blob/noinput
Re: [bitcoin-dev] BIP sighash_noinput
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
Re: [bitcoin-dev] BIP sighash_noinput
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&broadcast 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 fut
Re: [bitcoin-dev] BIP sighash_noinput
Good morning Christian and list, It seems to me, that `SIGHASH_NOINPUT` may help make some protocol integrate better with existing wallets. 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. 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). Now, without `SIGHASH_NOINPUT`, we would first require that the initial funding transaction be written (but not signed and broadcast), and then the txid to the other side. The other side then generates the backout transaction (which requires the txid and outnum of the funding outpoint) and returns the signature for the backout transaction to the first side. Because of this, an implementation of CoinSwap needs to have control of its own coins. This means that coin selection, blockchain tracking, and mempool tracking (i.e. to handle RBFs, which would invalidate any further transactions if you used coins received by RBF-able transactions while unconfirmed) needs to be implemented. But it would be much nicer if instead the CoinSwap implementation could simply say "okay, I started our CoinSwap, now send X coins to address A", and then the user uses their ordinary wallet software to send to that address (obviously before the CoinSwap can start, the user must first provide an address to which the backoff transaction should pay; but in fact that could simply be the same as the other address in the swap). 1. The user will not have to make a separate transfer from their wallet, then initiate a swap, then transfer from the CoinSwap implementation to their usual wallet: instead the user gets an address from their wallet, initiates the swap, then pays to the address the CoinSwap implementation said to pay and wait to receive the swapped funds to their normal wallet. 2. Implementing the CoinSwap program is now somewhat easier since we do not need to manage our own funds: the software only needs to manage the single particular coin that was paid to the single address being used in the swap. 3. The smaller number of required features for use means easier implementation and testing. It also makes it more likely to be implemented in the first place, since the effort to make it is smaller. 4. The lack of a wallet means users can use a trusted wallet implementation (cold storage, hardware wallet, etc) in conjunction with the software, and only risk the amount that passes through the CoinSwap software (which is smaller, since it does not have to include any extra funds to pay for fees). 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. 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.
Re: [bitcoin-dev] BIP sighash_noinput
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
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
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
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
