[bitcoin-dev] BIP sighash_noinput

[bitcoin-dev] BIP sighash_noinput

[Christian Decker]

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

Re: [bitcoin-dev] BIP sighash_noinput

[Dario Sneidermanis]

[-- Attachment #1: Type: text/plain, Size: 3920 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 5896 bytes --]

Re: [bitcoin-dev] BIP sighash_noinput

[Russell O'Connor]

[-- Attachment #1: Type: text/plain, Size: 3437 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 4556 bytes --]

Re: [bitcoin-dev] BIP sighash_noinput

[Christian Decker]

Russell O'Connor <roconnor@blockstream.io> 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.

Re: [bitcoin-dev] BIP sighash_noinput

[ZmnSCPxj]

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

Regards,
ZmnSCPxj

Re: [bitcoin-dev] BIP sighash_noinput

[Christian Decker]

ZmnSCPxj <ZmnSCPxj@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.

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

Re: [bitcoin-dev] BIP sighash_noinput

[ZmnSCPxj]

Good morning Christian,


> ZmnSCPxj ZmnSCPxj@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 future protocol arises that uses the funding transaction pattern again, then again existing wallets can integrate with those protocols via P2WSH address.
3.  Special protocol software need not implement even basic wallet functionality: they can just focus on the specific protocol they implement.  Consider how until late last year c-lightning needed a separate RPC command to inform it that it received funds, and a few months ago we had many issues with UTXOs in our database getting out of sync with the blockchain (why we implemented `dev-rescan-outputs`).

Regards.
ZmnSCPxj

Re: [bitcoin-dev] BIP sighash_noinput

[Jonas Nick]

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

[Johnson Lau]

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 <bitcoin-dev@lists.linuxfoundation.org> 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?
>> 
> 

Re: [bitcoin-dev] BIP sighash_noinput

[Jonas Nick]

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 <bitcoin-dev@lists.linuxfoundation.org> 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?
>>>
>>
> 
> 

Re: [bitcoin-dev] BIP sighash_noinput

[Christian Decker]

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

Re: [bitcoin-dev] BIP sighash_noinput

[Bram Cohen]

[-- Attachment #1: Type: text/plain, Size: 1795 bytes --]

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
>

[-- Attachment #2: Type: text/html, Size: 2536 bytes --]

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

[ZmnSCPxj]

[-- Attachment #1: Type: text/plain, Size: 209 bytes --]

Good morning,

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

SIGHASH_NOINPUT_REUSE_VULNERABLE?

SIGHASH_NOINPUT_VULNERABLE?

Regards,
ZmnSCPxj

[-- Attachment #2: Type: text/html, Size: 385 bytes --]

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

[William Casarin]

A convention in Haskell libraries is to use an "unsafe" prefix to any function that may have side effects (here be dragons, etc)

I'm happy with a _VULNERABLE or _UNSAFE postfix as a standard way to signal this.

Re: [bitcoin-dev] BIP sighash_noinput

[Anthony Towns]

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

Re: [bitcoin-dev] BIP sighash_noinput

[Olaoluwa Osuntokun]

[-- Attachment #1: Type: text/plain, Size: 3776 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4701 bytes --]

Re: [bitcoin-dev] BIP sighash_noinput

[Rusty Russell]

Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> 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.

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

[Anthony Towns]

On Thu, May 10, 2018 at 08:34:58AM +0930, Rusty Russell wrote:
> > 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.

So, I don't find that very compelling: "there's already a way to lose
your money, so it's fine to add other ways to lose your money". And
again, I think NOINPUT is worse here, because a SIGHASH_NONE signature
only lets others take the coin you're trying to spend, messing up when
using NOINPUT can cause you to lose other coins as well (with caveats).

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

I could see either dropping support for SIGHASH_NONE for segwit
v1 addresses, or possibly limiting SIGHASH_NONE in a similar way to
limiting SIGHASH_NOINPUT. Has anyone dug through the blockchain to see
if SIGHASH_NONE is actually used/useful?

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

Taproot and graftroot aren't "less script" at all -- if anything they're
the opposite in that suddenly every address can have a script path.
I think NOINPUT has pretty much the same tradeoffs as taproot/graftroot
scripts: in the normal case for both you just use a SIGHASH_ALL
signature to spend your funds; in the abnormal case for NOINPUT, you use
a SIGHASH_NOINPUT (multi)sig for unilateral eltoo closes or watchtower
penalties, in the abnormal case for taproot/graftroot you use a script.

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

That's backwards. If you introduce a new opcode, you can use the existing
segwit version, rather than needing segwit v1. You certainly don't need
v1 segwit for regular coins and v2 segwit for NOINPUT coins, if that's
where you were going?

For segwit v0, that would mean your addresses for a key "X", might be:

   [pubkey]  X    
    - not usable with NOINPUT
   [script]  2 X Y 2 CHECKMULTISIG
    - not usable with NOINPUT
   [script]  2 X Y 2 CHECKMULTISIG_1USE_VERIFY
    - usable with NOINPUT (or SIGHASH_ALL)

CHECKMULTISIG_1USE_VERIFY being soft-forked in by replacing an OP_NOP,
of course. Any output spendable via a NOINPUT signature would then have
had to have been deliberately created as being spendable by NOINPUT.

For a new segwit version with taproot that likewise includes an opcode,
that might be:

   [taproot]  X
    - not usable with NOINPUT
   [taproot]  X or: X CHECKSIG_1USE
    - usable with NOINPUT

If you had two UTXOs (with the same value), then if you construct
a taproot witness script for the latter address it will look like:

    X [X CHECKSIG_1USE] [sig_X_NOINPUT]

and that signature can't be used for addresses that were just intending
to pay to X, because the NOINPUT sig/sighash simply isn't supported
without a taproot path that includes the CHECKSIG_1USE opcode.

In essence, with the above construction there's two sorts of addresses
you generate from a public key X: addresses where you spend each coin
individually, and different addresses where you spend the wallet of
coins with that public key (and value) at once; and that remains the
same even if you use a single key for both.

I think it's slightly more reasonable to worry about signing with NOINPUT
compared to signing with SIGHASH_NONE: you could pretty reasonably setup
your (light) bitcoin wallet to not be able to sign (or verify) with
SIGHASH_NONE ever; but if you want to use lightning v2, it seems pretty
likely your wallet will be signing things with SIGHASH_NOINPUT. From
there, it's a matter of having a bug or a mistake cause you to
cross-contaminate keys into your lightning subsystem, and not be
sufficiently protected by other measures (eg, muSig versus checkmultisig).

(For me the Debian ssh key generation bug from a decade ago is sufficient
evidence that people you'd think are smart and competent do make really
stupid mistakes in real life; so defense in depth here makes sense even
though you'd have to do really stupid things to get a benefit from it)

The other benefit of a separate opcode is support can be soft-forked in
independently of a new segwit version (either earlier or later).

I don't think the code has to be much more complicated with a separate
opcode; passing an extra flag to TransactionSignatureChecker::CheckSig()
is probably close to enough. Some sort of flag remains needed anyway
since v0 and pre-segwit signatures won't support NOINPUT.

Cheers,
aj

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

[Christian Decker]

Anthony Towns <aj@erisian.com.au> writes:

> On Thu, May 10, 2018 at 08:34:58AM +0930, Rusty Russell wrote:
>> > 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.
>
> So, I don't find that very compelling: "there's already a way to lose
> your money, so it's fine to add other ways to lose your money". And
> again, I think NOINPUT is worse here, because a SIGHASH_NONE signature
> only lets others take the coin you're trying to spend, messing up when
> using NOINPUT can cause you to lose other coins as well (with caveats).

`SIGHASH_NOINPUT` is a rather powerful tool, but has to be used
responsibly, which is why we always mention that it shouldn't be used
lightly. Then again all sighash flags can be dangerous if not well
understood. Think for example `SIGHASH_SINGLE` with it's pitfall when
the input has no matching output, or the already mentioned SIGHASH_NONE.

From a technical, and risk, point of view I don't think there is much
difference between a new opcode or a new sighash flag, with the
activation being the one exception. I personally believe that a segwit
script bump has cleaner semantics than soft-forking in a new opcode
(which has 90% overlap with the existing checksig and checkmultisig
opcodes).

>> [...]
>> In a world where SIGHASH_NONE didn't exist, this might be an argument :)
>
> I could see either dropping support for SIGHASH_NONE for segwit
> v1 addresses, or possibly limiting SIGHASH_NONE in a similar way to
> limiting SIGHASH_NOINPUT. Has anyone dug through the blockchain to see
> if SIGHASH_NONE is actually used/useful?

That's a good point, I'll try looking for it once I get back to my full
node :-) And yes, `SIGHASH_NONE` should also come with all the warning
signs about not using it without a very good reason.

>> 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.
>
> Taproot and graftroot aren't "less script" at all -- if anything they're
> the opposite in that suddenly every address can have a script path.
> I think NOINPUT has pretty much the same tradeoffs as taproot/graftroot
> scripts: in the normal case for both you just use a SIGHASH_ALL
> signature to spend your funds; in the abnormal case for NOINPUT, you use
> a SIGHASH_NOINPUT (multi)sig for unilateral eltoo closes or watchtower
> penalties, in the abnormal case for taproot/graftroot you use a script.

That's true for today's uses of `SIGHASH_NOINPUT` and others, but there
might be other uses that we don't know about in which noinput isn't just
used for the contingency, handwavy I know. That's probably not the case
for graftroot/taproot, but I'm happy to be corrected on that one.

Still, these opcodes and hash flags being mainly used for contingencies,
doesn't remove the need for these contingency options to be enforced
on-chain.

>> That means we'd actually want a different Segwit version for
>> "NOINPUT-can-be-used", which seems super ugly.
>
> That's backwards. If you introduce a new opcode, you can use the existing
> segwit version, rather than needing segwit v1. You certainly don't need
> v1 segwit for regular coins and v2 segwit for NOINPUT coins, if that's
> where you were going?
>
> For segwit v0, that would mean your addresses for a key "X", might be:
>
>    [pubkey]  X    
>     - not usable with NOINPUT
>    [script]  2 X Y 2 CHECKMULTISIG
>     - not usable with NOINPUT
>    [script]  2 X Y 2 CHECKMULTISIG_1USE_VERIFY
>     - usable with NOINPUT (or SIGHASH_ALL)
>
> CHECKMULTISIG_1USE_VERIFY being soft-forked in by replacing an OP_NOP,
> of course. Any output spendable via a NOINPUT signature would then have
> had to have been deliberately created as being spendable by NOINPUT.

The main reason I went for the sighash flag instead of an opcode is that
it has clean semantics, allows for it to be bundled with a number of
other upgrades, and doesn't use up NOP-codes, which I was lectured
for my normalized tx BIP (BIP140) is a rare resource that should be used
sparingly. The `SIGHASH_NOINPUT` proposal is minimal, since it enhances
4 existing opcodes. If we were to do that with new opcodes we'd either
want a multisig and a singlesig variant, potentially with a verify
variant each. That's a lot of opcodes.

The proposal being minimal should also help against everybody trying to
get their favorite feature added, and hopefully streamline the
discussion.

> For a new segwit version with taproot that likewise includes an opcode,
> that might be:
>
>    [taproot]  X
>     - not usable with NOINPUT
>    [taproot]  X or: X CHECKSIG_1USE
>     - usable with NOINPUT
>
> If you had two UTXOs (with the same value), then if you construct
> a taproot witness script for the latter address it will look like:
>
>     X [X CHECKSIG_1USE] [sig_X_NOINPUT]
>
> and that signature can't be used for addresses that were just intending
> to pay to X, because the NOINPUT sig/sighash simply isn't supported
> without a taproot path that includes the CHECKSIG_1USE opcode.
>
> In essence, with the above construction there's two sorts of addresses
> you generate from a public key X: addresses where you spend each coin
> individually, and different addresses where you spend the wallet of
> coins with that public key (and value) at once; and that remains the
> same even if you use a single key for both.
>
> I think it's slightly more reasonable to worry about signing with NOINPUT
> compared to signing with SIGHASH_NONE: you could pretty reasonably setup
> your (light) bitcoin wallet to not be able to sign (or verify) with
> SIGHASH_NONE ever; but if you want to use lightning v2, it seems pretty
> likely your wallet will be signing things with SIGHASH_NOINPUT. From
> there, it's a matter of having a bug or a mistake cause you to
> cross-contaminate keys into your lightning subsystem, and not be
> sufficiently protected by other measures (eg, muSig versus checkmultisig).

I think the same can be addressed by simply having the wallet use a
different derivation path for keys that it is willing to sign with
NOINPUT. I sort of dislike having a direct dependency on taproot, i.e.,
allowing noinput only in taproot scripts, since that isn't a done deal
either. Without that direct dependency, having the noinput path and the
sighash_all path be differentiated in the script leaks the details
on-chain, bloating the UTXO set, and leaking details about our contract.

Also isn't the same issue true for a separate opcode?

> (For me the Debian ssh key generation bug from a decade ago is sufficient
> evidence that people you'd think are smart and competent do make really
> stupid mistakes in real life; so defense in depth here makes sense even
> though you'd have to do really stupid things to get a benefit from it)

Totally agree, however one could argue that increased code complexity
is a major contributor to security issues, and I'm still convinced that
the hashflag is the simplest and cleanest approach to getting this
feature implemented.

That being said, I think the soft-forked opcode is also a good option,
if we can get agreement on the details in a reasonable amount of time.

> The other benefit of a separate opcode is support can be soft-forked in
> independently of a new segwit version (either earlier or later).

That can both be a positive as well as a negative, since a bundle of
complementing features likely is easier to get reviewed and activated.

> I don't think the code has to be much more complicated with a separate
> opcode; passing an extra flag to TransactionSignatureChecker::CheckSig()
> is probably close to enough. Some sort of flag remains needed anyway
> since v0 and pre-segwit signatures won't support NOINPUT.

That's moving the fanout for sighash_all vs sighash_none from the opcode
up to the interpreter, right.

Cheers,
Christian

Re: [bitcoin-dev] BIP sighash_noinput

[Olaoluwa Osuntokun]

[-- Attachment #1: Type: text/plain, Size: 5309 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 6985 bytes --]

Re: [bitcoin-dev] BIP sighash_noinput

[Christian Decker]

Olaoluwa Osuntokun <laolu32@gmail.com> 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

Re: [bitcoin-dev] BIP sighash_noinput

[Gregory Maxwell]

On Mon, Apr 30, 2018 at 4: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

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.

Re: [bitcoin-dev] BIP sighash_noinput

[Rusty Russell]

Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
> On Mon, Apr 30, 2018 at 4: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
>
> 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.

Re: [bitcoin-dev] BIP sighash_noinput

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1160 bytes --]

On Tue, Jul 03, 2018 at 02:26:53PM +0930, Rusty Russell via bitcoin-dev wrote:
> Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
> > On Mon, Apr 30, 2018 at 4: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
> >
> > 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] BIP sighash_noinput

[Gregory Maxwell]

On Tue, Jul 3, 2018 at 5:21 AM, Peter Todd <pete@petertodd.org> 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.

Re: [bitcoin-dev] BIP sighash_noinput

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 724 bytes --]

On Tue, Jul 03, 2018 at 11:45:22PM +0000, Gregory Maxwell wrote:
> On Tue, Jul 3, 2018 at 5:21 AM, Peter Todd <pete@petertodd.org> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] BIP sighash_noinput

[Christian Decker]

Gregory Maxwell <greg@xiph.org> 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).

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

[Luke Dashjr]

On Monday 02 July 2018 18:11:54 Gregory Maxwell wrote:
> 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. 

I don't agree. Address reuse is undefined behaviour. Nobody should assume it 
is safe or works.

I intend to possibly use SIGHASH_NOINPUT for ordinary Bitcoin transactions in 
a wallet I am writing, which explicitly does not support address reuse.

Luke

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

[fred savage]

[-- Attachment #1: Type: text/plain, Size: 1533 bytes --]

you cannot specifically NOT support addrss reuse. on a blockchain where people can send you funds without your permission required to send you funds. so ALWAYS expect multiple payments to the same address

________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Luke Dashjr via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Sent: 03 July 2018 12:13:44
To: lightning-dev@lists.linuxfoundation.org
Cc: Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

On Monday 02 July 2018 18:11:54 Gregory Maxwell wrote:
> 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.

I don't agree. Address reuse is undefined behaviour. Nobody should assume it
is safe or works.

I intend to possibly use SIGHASH_NOINPUT for ordinary Bitcoin transactions in
a wallet I am writing, which explicitly does not support address reuse.

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

[-- Attachment #2: Type: text/html, Size: 2494 bytes --]

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

[vv01f]

You can provide a reusable payment code (BIP-47) instead of an actual address. Unfortunately that not yet supported by the clients/apps most people use. Just that would be less a hurdle than providing a service that e.g. generates addresses from xpub.

Am July 4, 2018 6:08:43 PM UTC schrieb fred savage via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>:
>you cannot specifically NOT support addrss reuse. on a blockchain where
>people can send you funds without your permission required to send you
>funds. so ALWAYS expect multiple payments to the same address

-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

[ZmnSCPxj]

[-- Attachment #1: Type: text/plain, Size: 3424 bytes --]

Good morning DING FENG,

While your concern is valid, the general intent is the below:

1.  We will use a scary name like SIGHASH_NOINPUT_UNSAFE to explicitly inform to wallet and Bitcoin software developers that the flag is potentially unsafe.
2.  SIGHASH_NOINPUT_UNSAFE is intended to be used for specialty protocols like LN, CoinSwap, etc. and not for general-purpose user wallets (except for Luke Dash Jr wallet which explicitly rejects address reuse).  By default, this flag is not set and address reuse is still slightly safe for common usage, modulo other bugs in the implementation such as weak generation of random R (which are already existing concerns for SIGHASH_ALL).
2.1.  Even for LN/CoinSwap/etc., SIGHASH_NOINPUT_UNSAFE will be used only in the exact specialty protocol, and not e.g. for general wallet usage.

Regards,
ZmnSCPxj

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On July 11, 2018 12:37 PM, DING FENG <dingfeng12345@gmail.com> wrote:

> Hi,
>
> I'm a junior developer and a bitcoin user.
> And I have read this thread carefully.
>
> I'm very worried about "SIGHASH_NOINPUT".
>
> Because "SIGHASH_NOINPUT" looks will be widely used, and it makes reuse address more dangerous.
> Now, most donate addresses (even bitcointalk.org and bitcoin.org) used as reuse addresss, and fans continually send bitcoins to these addresses.
> So, if user import his address (keys, seeds) to one of the "SIGHASH_NOINPUT" enabled Bitcoin/LN wallet and sign a Tx, this will make his donate address disabled immediately and will continue loss coins future(although the input amount is included by the SIGHASH_NOINPUT signature).
>
> "SIGHASH_NONE" only influence the current coin in the single Tx, and may be no wallet implement it.
> "SIGHASH_NOINPUT" influence the whole wallet and future coins, and "SIGHASH_NOINPUT" intent to be widely used in Bitcoin/LN wallet.
>
> "SIGHASH_NOINPUT" look more like give away my signature right (as release my private key, I know that there is an exchange of private keys operation in LN).
> Other SIGHASH flag just giveaway my designated coins.
>
> Although address reuse is not perfect safe, but it can be used and widely used in fact,
> So, I think "SIGHASH_NOINPUT" may let a lot of users at risk.
>
> 2018-07-03 20:13 GMT+08:00 Luke Dashjr <luke@dashjr.org>:
>
>> On Monday 02 July 2018 18:11:54 Gregory Maxwell wrote:
>>> 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.
>>
>> I don't agree. Address reuse is undefined behaviour. Nobody should assume it
>> is safe or works.
>>
>> I intend to possibly use SIGHASH_NOINPUT for ordinary Bitcoin transactions in
>> a wallet I am writing, which explicitly does not support address reuse.
>>
>> Luke
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> --
>
> Mob: +86-18667916176
>
> Email:dingfeng12345@gmail.com

[-- Attachment #2: Type: text/html, Size: 5769 bytes --]

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

[Rusty Russell]

DING FENG <dingfeng12345@gmail.com> writes:
> Hi,
>
> I'm a junior developer and a bitcoin user.
> And I have read this thread carefully.
>
> I'm very worried about "SIGHASH_NOINPUT".
>
> Because "SIGHASH_NOINPUT" looks will be widely used, and it makes reuse
> address more dangerous.

No.

A wallet should *never* create a SIGHASH_NOINPUT to spend its own UTXOs.
SIGHASH_NOINPUT is useful for smart contracts which have unique
conditions, such as a pair of peers rotating keys according to an agreed
schedule (eg. lightning).

Cheers,
Rusty.

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

[fred savage]

[-- Attachment #1: Type: text/plain, Size: 2543 bytes --]

the issues with sighash_noinput is this

  1.  you cannot prevent address-reuse. because bitcoin is a PUSH payment. meaning other people can send funds to one address without the owner of the key approval/refusal. thus luke cannot control address reuse if many people start spamming him donations.
  2.  for average users who would just 'autopilot' LN and only see the GUI. they will have no clue what transaction types and technicals are happening under the hood. also with LN being not validated by the community. a user creating a channel could tweak their own LN node to make their counterparty sign a sighash-noinput as a term/condition of the channel
this is also a risk for the under the hood raw tx risks where a tx can be signed but then allow the out's to alter value(using a different opcode). .. you know the premiss of allowing a counterpart to alter the outs value to vary so that they can control the broadcast fee at the time of broadcast to cover being acceptd onchain.. which can be abused by a counter party just editing it so A gets nothing and B gets it all..
  3.  by allowing certain things to change after signing. is infact bringing back malleability for those that use a TXID to identify a tx has been confirmed. as a TXID would change if values change.. just like how malleation abused old transactions by editing a tx without needing to re-sign a tx

________________________________
From: bitcoin-dev-bounces@lists.linuxfoundation.org <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf of Rusty Russell via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Sent: 13 July 2018 00:04:14
To: DING FENG; Luke Dashjr
Cc: Bitcoin Protocol Discussion; lightning-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

DING FENG <dingfeng12345@gmail.com> writes:
> Hi,
>
> I'm a junior developer and a bitcoin user.
> And I have read this thread carefully.
>
> I'm very worried about "SIGHASH_NOINPUT".
>
> Because "SIGHASH_NOINPUT" looks will be widely used, and it makes reuse
> address more dangerous.

No.

A wallet should *never* create a SIGHASH_NOINPUT to spend its own UTXOs.
SIGHASH_NOINPUT is useful for smart contracts which have unique
conditions, such as a pair of peers rotating keys according to an agreed
schedule (eg. lightning).

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

[-- Attachment #2: Type: text/html, Size: 3650 bytes --]

Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput

[Christian Decker]

fred savage via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> writes:
> the issues with sighash_noinput is this
>
>   1.  you cannot prevent address-reuse. because bitcoin is a PUSH
>   payment. meaning other people can send funds to one address without
>   the owner of the key approval/refusal. thus luke cannot control
>   address reuse if many people start spamming him donations.

This point is pretty much moot since these are scripts, that are used in
very specialized contexts, and should not be shown to any
end-user. Sure, if you go through the blockchain looking for these
addresses, and send the exact same value to it, and create a matching
script then you could end up exposing those funds to this, however
that'd be very silly of you, and you'd have jumped through a lot of
hoops to lose money :-)

>   2.  for average users who would just 'autopilot' LN and only see the
> GUI. they will have no clue what transaction types and technicals are
> happening under the hood. also with LN being not validated by the
> community. a user creating a channel could tweak their own LN node to
> make their counterparty sign a sighash-noinput as a term/condition of
> the channel this is also a risk for the under the hood raw tx risks
> where a tx can be signed but then allow the out's to alter value(using
> a different opcode). .. you know the premiss of allowing a counterpart
> to alter the outs value to vary so that they can control the broadcast
> fee at the time of broadcast to cover being acceptd onchain.. which
> can be abused by a counter party just editing it so A gets nothing and
> B gets it all..

You cannot force the counterparty to sign with a sighash-flag that they
don't chose themselves. We are very clear in the BIP that you should
only use sighash_noinput_unsafe in the context of protocols, that need
to be designed in such a way that these issues are excluded. In
particular, eltoo uses a public key, provided by the signing party,
which they can ensure is not reused (ensuring script
uniqueness). Finally, wallets that are not part of LN or eltoo, won't
even know how to sign with sighash-noinput (try signing anything but
sighash-all on a hardware wallet for example).

The kind of editing you describe also doesn't work, since sighash-single
is used for the late fee binding, not sighash-noinput. sighash-single
makes sure that the input is only valid if the matching output is still
intact, so redirecting funds away from the desired output doesn't work.

>   3.  by allowing certain things to change after signing. is infact
>   bringing back malleability for those that use a TXID to identify a
>   tx has been confirmed. as a TXID would change if values
>   change.. just like how malleation abused old transactions by editing
>   a tx without needing to re-sign a tx

Again, this is only to be used in the context of applications that
require it, which also means that they know how to deal with this
malleability (in fact this malleability is wanted here). If you squint
at it you can probably see that sighash-noinput is also a poor-man's
malleability fix, allowing you to take a transaction that is based on a
malleated output, and rebind it to re-establish the connection.

It seems people believe that we are advocating the use of
sighash-noinput-unsafe in general purpose wallets and in everyday
transactions, this couldn't be further from the truth: sighash-noinput
is a sharp tool, that should only be used in very specific situations,
to enable a bit more flexibility, and it can improve the safety of
off-chain protocols a lot, however general purpose wallets should not
even allow signing with it.

Cheers,
Christian