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

[Rusty Russell]

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

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

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

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

[DING FENG]

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-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>



-- 


Mob: +86-18667916176
Email:dingfeng12...@gmail.com
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Peter Todd]

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

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

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

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

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

[Christian Decker]

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

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

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

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

[Peter Todd]

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

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

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

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


signature.asc
Description: PGP signature
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

[Christian Decker]

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: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput

[Rusty Russell]

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

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

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

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

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

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

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

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

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

[Dario Sneidermanis]

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