> 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 <etotheipi@gmail.com> 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