From: slush <slush@centrum•cz>
Cc: "bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE
Date: Fri, 23 Jan 2015 16:40:39 +0100 [thread overview]
Message-ID: <CAJna-Hj1UrMx5bHmN2DXm2U-9uEmw2GN3z=SeF0oevibCV6zvw@mail.gmail.com> (raw)
In-Reply-To: <54C267A1.8090208@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4456 bytes --]
> 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
[-- Attachment #2: Type: text/html, Size: 6819 bytes --]
next prev parent reply other threads:[~2015-01-23 15:41 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
2015-01-23 15:40 ` slush [this message]
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='CAJna-Hj1UrMx5bHmN2DXm2U-9uEmw2GN3z=SeF0oevibCV6zvw@mail.gmail.com' \
--to=slush@centrum$(echo .)cz \
--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