<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<style type="text/css" style="display:none;"><!-- P {margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr">
<div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr">
<p style="margin-top:0;margin-bottom:0">the issues with sighash_noinput is this<br>
</p>
<ol style="margin-bottom: 0px; margin-top: 0px;">
<li>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.</li><li>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<br>
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..</li><li>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<br>
</li></ol>
<p style="margin-top:0;margin-bottom:0"></p>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> bitcoin-dev-bounces@lists.linuxfoundation.org &lt;bitcoin-dev-bounces@lists.linuxfoundation.org&gt; on behalf of Rusty Russell via bitcoin-dev &lt;bitcoin-dev@lists.linuxfoundation.org&gt;<br>
<b>Sent:</b> 13 July 2018 00:04:14<br>
<b>To:</b> DING FENG; Luke Dashjr<br>
<b>Cc:</b> Bitcoin Protocol Discussion; lightning-dev@lists.linuxfoundation.org<br>
<b>Subject:</b> Re: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput</font>
<div>&nbsp;</div>
</div>
<div class="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="PlainText">DING FENG &lt;dingfeng12345@gmail.com&gt; writes:<br>
&gt; Hi,<br>
&gt;<br>
&gt; I'm a junior developer and a bitcoin user.<br>
&gt; And I have read this thread carefully.<br>
&gt;<br>
&gt; I'm very worried about &quot;SIGHASH_NOINPUT&quot;.<br>
&gt;<br>
&gt; Because &quot;SIGHASH_NOINPUT&quot; looks will be widely used, and it makes reuse<br>
&gt; address more dangerous.<br>
<br>
No.<br>
<br>
A wallet should *never* create a SIGHASH_NOINPUT to spend its own UTXOs.<br>
SIGHASH_NOINPUT is useful for smart contracts which have unique<br>
conditions, such as a pair of peers rotating keys according to an agreed<br>
schedule (eg. lightning).<br>
<br>
Cheers,<br>
Rusty.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
bitcoin-dev@lists.linuxfoundation.org<br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</div>
</span></font></div>
</body>
</html>