public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  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 [Bitcoin-development] SIGHASH_WITHINPUTVALUE 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.cz \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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