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

[Christian Decker via bitcoin-dev]

fred savage via bitcoin-dev  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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[fred savage via bitcoin-dev]

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

DING FENG  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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Rusty Russell via bitcoin-dev]

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

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

[ZmnSCPxj via bitcoin-dev]

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  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 :
>
>> 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-...@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> --
>
> Mob: +86-18667916176
>
> Email:dingfeng12...@gmail.com___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[vv01f via bitcoin-dev]

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 
:
>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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[fred savage via bitcoin-dev]

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-boun...@lists.linuxfoundation.org 
 on behalf of Luke Dashjr via 
bitcoin-dev 
Sent: 03 July 2018 12:13:44
To: lightning-...@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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[William Casarin via bitcoin-dev]

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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[ZmnSCPxj via bitcoin-dev]

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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Luke Dashjr via bitcoin-dev]

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

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

[Christian Decker via bitcoin-dev]

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

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

[Anthony Towns via bitcoin-dev]

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

___
bitcoin-dev mailing list