From: fred savage <fred_savage2003@hotmail.co.uk>
To: Rusty Russell <rusty@rustcorp.com.au>, Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Thread-Topic: [bitcoin-dev] [Lightning-dev]  BIP sighash_noinput
Thread-Index: AQHUEselD0WWJh1tD0mLalZbedKWy6SMVRiEgACfV6Y=
Date: Fri, 13 Jul 2018 09:50:47 +0000
Message-ID: <VI1PR1001MB1309AFFE2838D85CBCB77C66DE580@VI1PR1001MB1309.EURPRD10.PROD.OUTLOOK.COM>
References: <871sewirni.fsf@gmail.com>
	<CAAS2fgS-_D7aBcDf_nAbuREBxv65zYMr60-1YqCnx-esvRVfEg@mail.gmail.com>
	<201807031213.51127.luke@dashjr.org>
	<CAK_c0Xo0G9-YiOGZK_8WsYNkzjQRaH+u7XOUAozKosggXeXTNg@mail.gmail.com>,
	<878t6gxapt.fsf@rustcorp.com.au>
In-Reply-To: <878t6gxapt.fsf@rustcorp.com.au>
Accept-Language: en-GB, en-US
Content-Language: en-GB
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [qnHOiYbs5t9So78s8xCQ328bdlcySGOUPfwqgOGNk7bJeS+qJQuPiqu8PrH3xOEX]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB5EUR03HT140;
	7:iIfJkORvEx4UczE3DtY9QLKo0JipoaZbesdVY+fthaxgbdDpsmIbB0RiO8CWcB9syOYiN0HyWwLFjS/KsjyLwlDGhffSY+fUQwWxSZhtOyYsx+rbul6Oz2uVF5xY8e8pQfBIN3yo8lj6bFvwQhralGj7LDyS3v2DeFo0rS0PHlTHjz2aCLFN8V229rjP14Fx0Xpoq/oMyyodXbb6Jwr3X7z2JsQiMK7Y5lj03kC8VKTlUZPfZ/2nNSCaSIHHQ7J2
x-incomingheadercount: 46
x-eopattributedmessage: 0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0;
	RULEID:(7020095)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1601125500)(1603101448)(1701031045);
	SRVR:DB5EUR03HT140; 
x-ms-traffictypediagnostic: DB5EUR03HT140:
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(82015058);
	SRVR:DB5EUR03HT140; BCL:0; PCL:0; RULEID:; SRVR:DB5EUR03HT140; 
x-forefront-prvs: 07326CFBC4
x-forefront-antispam-report: SFV:NSPM;
	SFS:(7070007)(189003)(199004)(606006)(6606003)(104016004)(8936002)(97736004)(105586002)(476003)(6506007)(551934003)(6346003)(106356001)(486006)(76176011)(73972006)(99286004)(102836004)(56003)(74316002)(93886005)(74482002)(81156014)(8676002)(256004)(14444005)(33656002)(5660300001)(86362001)(82202002)(2900100001)(46003)(6246003)(9686003)(19627405001)(5250100002)(229853002)(54896002)(55016002)(6306002)(86152003)(6436002)(236005)(110136005)(68736007)(14454004)(446003)(11346002)(7696005)(966005)(25786009)(46252003);
	DIR:OUT; SFP:1901; SCL:1; SRVR:DB5EUR03HT140;
	H:VI1PR1001MB1309.EURPRD10.PROD.OUTLOOK.COM; FPR:; SPF:None;
	PTR:InfoNoRecords; MX:1; A:1; LANG:; 
received-spf: None (protection.outlook.com: hotmail.co.uk does not designate
	permitted sender hosts)
authentication-results: spf=none (sender IP is )
	smtp.mailfrom=fred_savage2003@hotmail.co.uk; 
x-microsoft-antispam-message-info: Hc070ARbzCcaOVPd1kPAbeZz9jvGKGyOLCoLgLILpS95hzjL36wwe8fBpQ7aPX8bakP04iM5d+0UUpIZMFMElSeyBAFHYkXafu2LZhSxbyB4/IkeOTVwa42Ug/FVN47+hTT206cqwm1s2Nfi+JtAW0sCs478k+xDzglRymc+3NlRdbPaQwswGVBcgRBowSRqxf5bT6j/OLwf3W1daxux+a8Mk8H/DM77s+fS/Az5enE=
Content-Type: multipart/alternative;
	boundary="_000_VI1PR1001MB1309AFFE2838D85CBCB77C66DE580VI1PR1001MB1309_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 54485d23-c432-40fe-8436-6091d627118c
X-MS-Exchange-CrossTenant-Network-Message-Id: dadc8f9c-2f77-473e-1229-08d5e8a61c00
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 54485d23-c432-40fe-8436-6091d627118c
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2018 09:50:47.3837 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5EUR03HT140
X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,
	FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Fri, 13 Jul 2018 10:17:01 +0000
Subject: Re: [bitcoin-dev] [Lightning-dev]  BIP sighash_noinput
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jul 2018 09:50:50 -0000

--_000_VI1PR1001MB1309AFFE2838D85CBCB77C66DE580VI1PR1001MB1309_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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 peopl=
e 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 s=
igned 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 bringin=
g back malleability for those that use a TXID to identify a tx has been con=
firmed. 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 <bitcoin-dev-bounces@li=
sts.linuxfoundation.org> on behalf of Rusty Russell via bitcoin-dev <bitcoi=
n-dev@lists.linuxfoundation.org>
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 <dingfeng12345@gmail.com> 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

--_000_VI1PR1001MB1309AFFE2838D85CBCB77C66DE580VI1PR1001MB1309_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Helvetica,sans-serif;" dir=3D"ltr">
<p style=3D"margin-top:0;margin-bottom:0">the issues with sighash_noinput i=
s this<br>
</p>
<ol style=3D"margin-bottom: 0px; margin-top: 0px;">
<li>you cannot prevent address-reuse. because bitcoin is a PUSH payment. me=
aning other people can send funds to one address without the owner of the k=
ey approval/refusal. thus luke cannot control address reuse if many people =
start spamming him donations.</li><li>for average users who would just 'aut=
opilot' LN and only see the GUI. they will have no clue what transaction ty=
pes and technicals are happening under the hood. also with LN being not val=
idated 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/co=
ndition of the channel<br>
this is also a risk for the under the hood raw tx risks where a tx can be s=
igned 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.. wh=
ich 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 li=
ke how malleation abused old transactions by editing
 a tx without needing to re-sign a tx<br>
</li></ol>
<p style=3D"margin-top:0;margin-bottom:0"></p>
</div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> bitcoin-dev-bounces@l=
ists.linuxfoundation.org &lt;bitcoin-dev-bounces@lists.linuxfoundation.org&=
gt; on behalf of Rusty Russell via bitcoin-dev &lt;bitcoin-dev@lists.linuxf=
oundation.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=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;=
">
<div class=3D"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=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">=
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</div>
</span></font></div>
</body>
</html>

--_000_VI1PR1001MB1309AFFE2838D85CBCB77C66DE580VI1PR1001MB1309_--