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