Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B689EC50 for ; Fri, 13 Jul 2018 09:50:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-oln040092070019.outbound.protection.outlook.com [40.92.70.19]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C32A66D6 for ; Fri, 13 Jul 2018 09:50:49 +0000 (UTC) Received: from DB5EUR03FT033.eop-EUR03.prod.protection.outlook.com (10.152.20.55) by DB5EUR03HT140.eop-EUR03.prod.protection.outlook.com (10.152.21.173) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.930.16; Fri, 13 Jul 2018 09:50:47 +0000 Received: from VI1PR1001MB1309.EURPRD10.PROD.OUTLOOK.COM (10.152.20.56) by DB5EUR03FT033.mail.protection.outlook.com (10.152.20.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.952.17 via Frontend Transport; Fri, 13 Jul 2018 09:50:47 +0000 Received: from VI1PR1001MB1309.EURPRD10.PROD.OUTLOOK.COM ([fe80::a1c9:4137:6b7b:d60e]) by VI1PR1001MB1309.EURPRD10.PROD.OUTLOOK.COM ([fe80::a1c9:4137:6b7b:d60e%8]) with mapi id 15.20.0952.017; Fri, 13 Jul 2018 09:50:47 +0000 From: fred savage To: Rusty Russell , Bitcoin Protocol Discussion Thread-Topic: [bitcoin-dev] [Lightning-dev] BIP sighash_noinput Thread-Index: AQHUEselD0WWJh1tD0mLalZbedKWy6SMVRiEgACfV6Y= Date: Fri, 13 Jul 2018 09:50:47 +0000 Message-ID: References: <871sewirni.fsf@gmail.com> <201807031213.51127.luke@dashjr.org> , <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-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:E5BAAF79FA61BE7B98E33982F3A3ADF4A9324E8010A637A41C98070AA9A4C570; UpperCasedChecksum:5D6647B47C895E9AF947B78A060912530F3B27C833ACCAD7D9989689A137CDAF; SizeAsReceived:7454; Count:46 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 --_000_VI1PR1001MB1309AFFE2838D85CBCB77C66DE580VI1PR1001MB1309_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

the issues with sighash_noinput i= s this

  1. 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.
  2. 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
    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..
  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 li= ke how malleation abused old transactions by editing a tx without needing to re-sign a tx

From: bitcoin-dev-bounces@l= ists.linuxfoundation.org <bitcoin-dev-bounces@lists.linuxfoundation.org&= gt; on behalf of Rusty Russell via bitcoin-dev <bitcoin-dev@lists.linuxf= oundation.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:<= br> > 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_--