Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YEg64-0004Mr-QU for bitcoin-development@lists.sourceforge.net; Fri, 23 Jan 2015 15:24:32 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.45 as permitted sender) client-ip=209.85.216.45; envelope-from=etotheipi@gmail.com; helo=mail-qa0-f45.google.com; Received: from mail-qa0-f45.google.com ([209.85.216.45]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YEg60-0007jf-GM for bitcoin-development@lists.sourceforge.net; Fri, 23 Jan 2015 15:24:32 +0000 Received: by mail-qa0-f45.google.com with SMTP id n8so6219442qaq.4 for ; Fri, 23 Jan 2015 07:24:23 -0800 (PST) X-Received: by 10.140.28.54 with SMTP id 51mr14406267qgy.6.1422026658351; Fri, 23 Jan 2015 07:24:18 -0800 (PST) Received: from [192.168.1.28] (c-69-143-204-74.hsd1.md.comcast.net. [69.143.204.74]) by mx.google.com with ESMTPSA id r16sm1727340qay.10.2015.01.23.07.24.17 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Jan 2015 07:24:17 -0800 (PST) Message-ID: <54C267A1.8090208@gmail.com> Date: Fri, 23 Jan 2015 10:24:17 -0500 From: Alan Reiner User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: bitcoin-development@lists.sourceforge.net References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010609060202080009000300" X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (etotheipi[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YEg60-0007jf-GM Subject: Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jan 2015 15:24:32 -0000 This is a multi-part message in MIME format. --------------010609060202080009000300 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable The SIGHASH_WITHINPUTVALUE proposal is a hardfork, but otherwise non-intrusive, doesn't change any TxOut scripts, doesn't change any tx/block parsing (besides verification), it works with all existing coins in the network, and existing software doesn't have to use it if they don't want to upgrade their signers. The proposal simply provides a way to optionally sign the input values with the TxOut scripts. In other words a signature right now says "I sign this transaction using these inputs, whatever value they are." With this SIGHASH type, the signature says "I sign this transaction assuming that input 0 is X BTC, input 1 is Y BTC,....". If the online computer providing the data to be signed lies about the value of any input, the resulting signature will be invalid. Unfortunately, it seems that there was no soft-fork way to achieve this benefit, at least not one that had favorable properties. Most of the soft-fork variations of it required the coins being spent to have been originated in a special way. In other words, it would only work if the coins had entered the wallet with some special, modified TxOut script.=20 So it wouldn't work with existing coins, and would require senders to update their software to reshape the way they send transactions to be compatible with our goals. I *strongly* encourage this to be considered for inclusion at some point. Not only does it simplify HW as Marek suggested, it increases the options for online-offline communication channels, which is also a win for security. Right now, QR codes don't work because of the possibility of having to transfer megabytes over the channel, and no way to for the signer to control that size. With this change, it's possible for the signer to control the size of each chunk of data to guarantee it fits in, say, a QR code (even if it means breaking it up into a couple smaller transactions). -Alan On 01/23/2015 09:51 AM, slush wrote: > Hi, > > is any progress or even discussion in this area?=20 > > https://bitcointalk.org/index.php?topic=3D181734.0 > > I don't insist on any specific solution, but this is becoming a real > issue as hardware wallets are more widespread. I'm sitting next to > TREZOR for 40 minutes already, because it streams and validate some > complex transaction. By using proposed solution, such signature would > be a matter of few seconds. > > That's also not just about time/resource/hw cost optimization. I'm > talking about possibility of huge simplification of the firmware > (=3Dsecurity FTW), because 50% of actual codebase is solving this > particular downside of Bitcoin protocol. > > So, there's real world problem. On which solution can we as a > community find a wide agreement? > > Best, > Marek > > > -----------------------------------------------------------------------= ------- > New Year. New Location. New Benefits. New Data Center in Ashburn, VA. > GigeNET is offering a free month of service with a new server in Ashbur= n. > Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely compliant= =2E > http://p.sf.net/sfu/gigenet > > > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --------------010609060202080009000300 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit The SIGHASH_WITHINPUTVALUE proposal is a hardfork, but otherwise non-intrusive, doesn't change any TxOut scripts, doesn't change any tx/block parsing (besides verification), it works with all existing coins in the network, and existing software doesn't have to use it if they don't want to upgrade their signers.   The proposal simply provides a way to optionally sign the input values with the TxOut scripts.  In other words a signature right now says "I sign this transaction using these inputs, whatever value they are."  With this SIGHASH type, the signature says "I sign this transaction assuming that input 0 is X BTC, input 1 is Y BTC,....".  If the online computer providing the data to be signed lies about the value of any input, the resulting signature will be invalid.

Unfortunately, it seems that there was no soft-fork way to achieve this benefit, at least not one that had favorable properties.  Most of the soft-fork variations of it required the coins being spent to have been originated in a special way.  In other words, it would only work if the coins had entered the wallet with some special, modified TxOut script.  So it wouldn't work with existing coins, and would require senders to update their software to reshape the way they send transactions to be compatible with our goals.

I strongly encourage this to be considered for inclusion at some point.  Not only does it simplify HW as Marek suggested, it increases the options for online-offline communication channels, which is also a win for security.  Right now, QR codes don't work because of the possibility of having to transfer megabytes over the channel, and no way to for the signer to control that size.  With this change, it's possible for the signer to control the size of each chunk of data to guarantee it fits in, say, a QR code (even if it means breaking it up into a couple smaller transactions).

-Alan



On 01/23/2015 09:51 AM, slush wrote:
Hi,

is any progress or even discussion in this area? 


I don't insist on any specific solution, but this is becoming a real issue as hardware wallets are more widespread. I'm sitting next to TREZOR for 40 minutes already, because it streams and validate some complex transaction. By using proposed solution, such signature would be a matter of few seconds.

That's also not just about time/resource/hw cost optimization. I'm talking about possibility of huge simplification of the firmware (=security FTW), because 50% of actual codebase is solving this particular downside of Bitcoin protocol.

So, there's real world problem. On which solution can we as a community find a wide agreement?

Best,
Marek


------------------------------------------------------------------------------
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet


_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--------------010609060202080009000300--