From: Alan Reiner <etotheipi@gmail•com>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE
Date: Fri, 23 Jan 2015 10:24:17 -0500 [thread overview]
Message-ID: <54C267A1.8090208@gmail.com> (raw)
In-Reply-To: <CAJna-HjwMRff_+7BvcR2YME9f2yUQPvfKOGZ1qq9d0nOGqORkg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3417 bytes --]
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 list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 5254 bytes --]
next prev parent reply other threads:[~2015-01-23 15:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-23 14:51 slush
2015-01-23 15:24 ` Alan Reiner [this message]
2015-01-23 15:40 ` slush
2015-01-23 16:05 ` Gregory Maxwell
2015-01-23 16:18 ` slush
2015-01-23 16:52 ` Gregory Maxwell
2015-01-23 17:40 ` slush
2015-01-23 18:51 ` Gregory Maxwell
2015-01-23 19:19 ` slush
2015-01-23 16:23 ` Alan Reiner
2015-01-23 16:27 ` Alan Reiner
2015-01-23 16:33 ` Alan Reiner
2015-01-23 16:35 ` slush
2015-01-23 17:49 ` Peter Todd
2015-01-23 15:31 ` Tamas Blummer
2015-01-23 15:42 ` Alan Reiner
2015-01-23 15:47 ` slush
2015-01-23 16:08 ` Tamas Blummer
2015-01-23 16:12 ` Adam Back
2015-01-23 16:17 ` Adam Back
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54C267A1.8090208@gmail.com \
--to=etotheipi@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox