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

<> on behalf of Rusty Russell via 
bitcoin-dev <>
Sent: 13 July 2018 00:04:14
To: DING FENG; Luke Dashjr
Cc: Bitcoin Protocol Discussion;
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.


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

bitcoin-dev mailing list
bitcoin-dev mailing list

Reply via email to