Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YEgMQ-0005aQ-6g for bitcoin-development@lists.sourceforge.net; Fri, 23 Jan 2015 15:41:26 +0000 X-ACL-Warn: Received: from mail-ig0-f176.google.com ([209.85.213.176]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YEgMM-0001zw-Kj for bitcoin-development@lists.sourceforge.net; Fri, 23 Jan 2015 15:41:26 +0000 Received: by mail-ig0-f176.google.com with SMTP id hl2so2513465igb.3 for ; Fri, 23 Jan 2015 07:41:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:cc:content-type; bh=w4wa1HrLWWqQQOIQjj8wdfu9HqJD1I5+XNnDWUar0qk=; b=CCIbpSmKUuLquMLn2JI9U4Y+t6PS9z/HsN5+3ClISXCwmd0DRpW6iM1BxoH3jO4ogJ 4PXGU/jbV7D97DQDBvXbCIgLsyoVXJGg12dLV6PTi1bDg8NjTDlYBZmPRC4gft066e2J qtf5PkPLHh7XwN2G3SqBaAKoeCYUDzSp7M2axdwxr+J7pTs2bumipTa8mhd3U0Gmifwz 7TPHmI07O/qToOeOEALf8mRH1QjWLDo2Koc8hLgL3IAiKehPH2G97ADeIxb6Qn3m7paF V2wVg24fcwNm0fUPX0A0sctwz7a9iwG5QkXbYUh6hlcYBqNVULX8qkhCLyzyO0NbUbpO OBCA== X-Gm-Message-State: ALoCoQlSxeB1WsDZe9pGutyvVbpiCZwcddsP0w+IMo89iI9kDQEtmLQNpsOrQIqAzWenXVU8Oa+J X-Received: by 10.50.108.83 with SMTP id hi19mr2540738igb.8.1422027669772; Fri, 23 Jan 2015 07:41:09 -0800 (PST) MIME-Version: 1.0 Sender: marek@palatinus.cz Received: by 10.64.31.138 with HTTP; Fri, 23 Jan 2015 07:40:39 -0800 (PST) In-Reply-To: <54C267A1.8090208@gmail.com> References: <54C267A1.8090208@gmail.com> From: slush Date: Fri, 23 Jan 2015 16:40:39 +0100 X-Google-Sender-Auth: RAY-L56umuFGS0LJDI8QlQ24rdU Message-ID: Cc: "bitcoin-development@lists.sourceforge.net" Content-Type: multipart/alternative; boundary=089e01494c2a1e3896050d539e1d X-Spam-Score: 3.0 (+++) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (slush[at]centrum.cz) 1.2 MISSING_HEADERS Missing To: header 1.0 HTML_MESSAGE BODY: HTML included in message 2.8 MALFORMED_FREEMAIL Bad headers on message from free email service -2.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1YEgMM-0001zw-Kj 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:41:26 -0000 --089e01494c2a1e3896050d539e1d Content-Type: text/plain; charset=ISO-8859-1 > I *strongly* encourage this to be considered for inclusion at some point. Thanks Alan for a nice summary. I also agree that such stuff should be implemented at some point. Anyway, I would probably not vote for doing hard fork *just* for this change, but if I remember well, there're other ideas flying around in the air and waiting for hardfork... Marek On Fri, Jan 23, 2015 at 4:24 PM, Alan Reiner wrote: > 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? > > https://bitcointalk.org/index.php?topic=181734.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 (=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 listBitcoin-development@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > ------------------------------------------------------------------------------ > 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 > T --089e01494c2a1e3896050d539e1d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
> I=A0strongly=A0encourage this to be consi= dered for inclusion at some point.

Thanks Alan for= a nice summary. I also agree that such stuff should be implemented at some= point. Anyway, I would probably not vote for doing hard fork *just* for th= is change, but if I remember well, there're other ideas flying around i= n the air and waiting for hardfork...

Marek
<= div>
On Fri,= Jan 23, 2015 at 4:24 PM, Alan Reiner <etotheipi@gmail.com> wrote:
=20 =20 =20
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. =A0 The proposal simpl= y provides a way to optionally sign the input values with the TxOut scripts.=A0 In other words a signature right now says "I sign this transaction using these inputs, whatever value they are."=A0 With = this SIGHASH type, the signature says "I sign this transaction assuming that input 0 is X BTC, input 1 is Y BTC,....".=A0 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.=A0 Most of the soft-fork variations of it required the coins being spent to have been originated in a special way.=A0 In other words, it would only work if the coins had entered the wallet with some special, modified TxOut script.=A0 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.=A0 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.=A0 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.=A0 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?=A0


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 4= 0 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. O= n 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/s=
fu/gigenet


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


-----------------------------------------------------------------------= -------
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/s= fu/gigenet
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment
T

--089e01494c2a1e3896050d539e1d--