MIME-Version: 1.0
Sender: marek@palatinus.cz
In-Reply-To: <54C267A1.8090208@gmail.com>
References: <CAJna-HjwMRff_+7BvcR2YME9f2yUQPvfKOGZ1qq9d0nOGqORkg@mail.gmail.com>
	<54C267A1.8090208@gmail.com>
From: slush <slush@centrum.cz>
Date: Fri, 23 Jan 2015 16:40:39 +0100
Message-ID: <CAJna-Hj1UrMx5bHmN2DXm2U-9uEmw2GN3z=SeF0oevibCV6zvw@mail.gmail.com>
Cc: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e01494c2a1e3896050d539e1d
Subject: Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE
Precedence: list

--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 <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

--089e01494c2a1e3896050d539e1d
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt; I=A0<b>strongly</b>=A0encourage this to be consi=
dered for inclusion at some point.</div><div><br></div><div>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&#39;re other ideas flying around i=
n the air and waiting for hardfork...</div><div><br></div><div>Marek</div><=
div><br></div><div class=3D"gmail_extra"><div class=3D"gmail_quote">On Fri,=
 Jan 23, 2015 at 4:24 PM, Alan Reiner <span dir=3D"ltr">&lt;<a href=3D"mail=
to:etotheipi@gmail.com" target=3D"_blank">etotheipi@gmail.com</a>&gt;</span=
> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">
 =20
   =20
 =20
  <div bgcolor=3D"#FFFFFF" text=3D"#000000">
    The SIGHASH_WITHINPUTVALUE proposal is a hardfork, but otherwise
    non-intrusive, doesn&#39;t change any TxOut scripts, doesn&#39;t change=
 any
    tx/block parsing (besides verification), it works with all existing
    coins in the network, and existing software doesn&#39;t have to use it
    if they don&#39;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 &quot;I sign this
    transaction using these inputs, whatever value they are.&quot;=A0 With =
this
    SIGHASH type, the signature says &quot;I sign this transaction assuming
    that input 0 is X BTC, input 1 is Y BTC,....&quot;.=A0 If the online
    computer providing the data to be signed lies about the value of any
    input, the resulting signature will be invalid.<br>
    <br>
    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&#39;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.<br>
    <br>
    I <b>strongly</b> 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&#39;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&#39;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). <br>
    <br>
    -Alan<div><div><br>
    <br>
    <br>
    <br>
    <div>On 01/23/2015 09:51 AM, slush wrote:<br>
    </div>
    </div></div><blockquote type=3D"cite"><div><div>
      <div dir=3D"ltr"><span style=3D"font-size:13px">Hi,</span>
        <div style=3D"font-size:13px"><br>
        </div>
        <div style=3D"font-size:13px">is any progress or even discussion
          in this area?=A0</div>
        <div style=3D"font-size:13px"><br>
        </div>
        <div style=3D"font-size:13px"><a href=3D"https://bitcointalk.org/in=
dex.php?topic=3D181734.0" target=3D"_blank">https://bitcointalk.org/index.p=
hp?topic=3D181734.0</a><br>
        </div>
        <div style=3D"font-size:13px"><br>
        </div>
        <div style=3D"font-size:13px">I don&#39;t insist on any specific
          solution, but this is becoming a real issue as hardware
          wallets are more widespread. I&#39;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.</div>
        <div style=3D"font-size:13px"><br>
        </div>
        <div style=3D"font-size:13px">That&#39;s also not just about
          time/resource/hw cost optimization. I&#39;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.</div>
        <div style=3D"font-size:13px"><br>
        </div>
        <div style=3D"font-size:13px">So, there&#39;s real world problem. O=
n
          which solution can we as a community find a wide agreement?</div>
        <div style=3D"font-size:13px"><br>
        </div>
        <div style=3D"font-size:13px">Best,</div>
        <div style=3D"font-size:13px">Marek</div>
      </div>
      <br>
      <fieldset></fieldset>
      <br>
      </div></div><pre>----------------------------------------------------=
--------------------------
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.
<a href=3D"http://p.sf.net/sfu/gigenet" target=3D"_blank">http://p.sf.net/s=
fu/gigenet</a></pre>
      <br>
      <fieldset></fieldset>
      <br>
      <pre>_______________________________________________
Bitcoin-development mailing list
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a>
</pre>
    </blockquote>
    <br>
  </div>

<br>-----------------------------------------------------------------------=
-------<br>
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.<br>
GigeNET is offering a free month of service with a new server in Ashburn.<b=
r>
Choose from 2 high performing configs, both with 100TB of bandwidth.<br>
Higher redundancy.Lower latency.Increased capacity.Completely compliant.<br=
>
<a href=3D"http://p.sf.net/sfu/gigenet" target=3D"_blank">http://p.sf.net/s=
fu/gigenet</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
T</blockquote></div><br></div></div>

--089e01494c2a1e3896050d539e1d--