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

From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: DING FENG <dingfeng12345@gmail•com>
Cc: Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>,
	"lightning-dev@lists•linuxfoundation.org"
	<lightning-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev]  BIP sighash_noinput
Date: Wed, 11 Jul 2018 03:43:49 -0400	[thread overview]
Message-ID: <xF57z5lmJtHRanRFykpwT4mFSGhTYFPYEOurYulBDMpb7SNeqVliqfDHPjYl5LEFs2hP_zuOKbbh0yU8li5GTcbJfrDhR3Ez734-2qLwL2Y=@protonmail.com> (raw)
In-Reply-To: <CAK_c0Xo0G9-YiOGZK_8WsYNkzjQRaH+u7XOUAozKosggXeXTNg@mail.gmail.com>

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