Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YgP7M-00067P-Dh for bitcoin-development@lists.sourceforge.net; Fri, 10 Apr 2015 02:56:28 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.212.169 as permitted sender) client-ip=209.85.212.169; envelope-from=stephencalebmorse@gmail.com; helo=mail-wi0-f169.google.com; Received: from mail-wi0-f169.google.com ([209.85.212.169]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YgP7K-00017D-S8 for bitcoin-development@lists.sourceforge.net; Fri, 10 Apr 2015 02:56:28 +0000 Received: by wiax7 with SMTP id x7so6887307wia.0 for ; Thu, 09 Apr 2015 19:56:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.78.231 with SMTP id e7mr63788568wjx.33.1428634580854; Thu, 09 Apr 2015 19:56:20 -0700 (PDT) Received: by 10.194.151.197 with HTTP; Thu, 9 Apr 2015 19:56:20 -0700 (PDT) In-Reply-To: <20150409172808.GB27775@muck> References: <20150409172808.GB27775@muck> Date: Thu, 9 Apr 2015 22:56:20 -0400 Message-ID: From: Stephen Morse To: Peter Todd Content-Type: multipart/alternative; boundary=047d7bfcf2fab4ad94051355e818 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (stephencalebmorse[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YgP7K-00017D-S8 Cc: bitcoin-development Subject: Re: [Bitcoin-development] Build your own nHashType X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Apr 2015 02:56:28 -0000 --047d7bfcf2fab4ad94051355e818 Content-Type: text/plain; charset=UTF-8 Regarding the re-hashing the transaction data once per input being a bottleneck, I was mistakenly only thinking about this from the point of view of the signer. Full nodes have to check all transactions' inputs, which is much more costly, as the link Gavin posted shows. On Thu, Apr 9, 2015 at 10:45 AM, Mike Hearn wrote: > > Right, good point. I wonder if this sort of auto forwarding could even be > a useful feature. I can't think of one right now. > I can think of a few convoluted use cases, but not any good ones. People have definitely looked for this feature before, though, just look at this Bitcoin SE post . I think there are better ways to handle key management than auto-forwarding, though. Anyone looking for this feature probably just wasn't aware that there are better solutions. On Thu, Apr 9, 2015 at 10:45 AM, Mike Hearn wrote: > > Yes but is that fundamental or is there a way to avoid it? That's what I'm > getting at. > In the bitcointalk article referenced, Sergio actually gave us the answer: > Hash(Tx,previn-index) = Hash ( Hash(outputs) || Hash (Inputs-with-script-cleared) || ) > (for SIGHASH_ALL) > This way the values "Hash(outputs)" and "Hash(Inputs-with-script-cleared)" can be cached and reused. Basically, just re-order the way stuff is serialized. Put the stuff that is nearly always signed at the beginning, and vice versa. I'll see if I can update the proposal to make this optimization possible. What I suspect, though, is that with all the new controls, blocks with ordinary transactions will verify faster, but an attacker could still create a very CPU intensive block by signing inputs with a wide variety of nHashTypes and then signing the last one with the equivalent of SIGHASH_ALL. I don't think that's a big limitation, though, the attack is already somewhat possible, and would be very hard to do, and doesn't really gain the attacker anything (other than infamy). On Thu, Apr 9, 2015 at 1:28 PM, Peter Todd wrote: > For the OP: Have you looked at how CODESEPARATOR allows the signature to > sign code to run as part of verifying the signature? E.g. my signature > can say "valid if you run these additional opcodes and they return true" > where those additional opcodes take the transaction, hash it in the > defined way, and verify that the ECC signature correctly signs that > hash and the hash of the additional opcodes. For instance in this case > making a signature that's only valid if the tx fee is less than the > defined amount would be a matter of GET_FEE LESSTHAN VERIFY > I've never been able to really see a good use case for OP_CODESEPARATOR, and I'm not sure I completely have my head wrapped around what you're proposing. From this and this , though, it seems like OP_CODESEPARATOR cannot really be made useful unless you already have a way to sign without hashing the TXIDs referenced by your input, in which case you need to modify the nHashType. Best, Stephen --047d7bfcf2fab4ad94051355e818 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Regarding the re-hashing the transaction data once per inp= ut being a bottleneck, I was mistakenly only thinking about this from the p= oint of view of the signer. Full nodes have to check all transactions' = inputs, which is much more costly, as the link Gavin posted shows.=C2=A0
On Thu, Apr 9, 2015 at 10:45 AM, Mike Hearn=C2=A0<mike@plan= 99.net>=C2=A0wrote:
Right, good point. I wonder i= f this sort of auto forwarding could even be a useful feature. I can't = think of one right now.

I= can think of a few convoluted use cases, but not any good ones. People hav= e definitely looked for this feature before, though, just look at this Bitcoin SE post= . I think there are better ways to handle key management than auto-forwardi= ng, though. Anyone looking for this feature probably just wasn't aware = that there are better solutions.

On Thu, Apr 9, 20= 15 at 10:45 AM, Mike Hearn=C2=A0<mike@plan99.net>=C2=A0wrote:<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa= dding-left:1ex">
Yes but is that fundamental or is there a way to avoid it? That= 's what I'm getting at.

In the bitcointalk article referenced, Sergio actually gave us the a= nswer:

> Hash(Tx,previn-index) =3D Hash ( Hash(outpu= ts) || Hash (Inputs-with-script-cleared) || <previn-index> )
> = =C2=A0 (for SIGHASH_ALL)
> =C2=A0 This way the values "Hash(outp= uts)" and "Hash(Inputs-with-script-cleared)" can be cached a= nd reused.

Basically, just re-order the way stuff is ser= ialized. Put the stuff that is nearly always signed at the beginning, and v= ice versa. I'll see if I can update the proposal to make this optimizat= ion possible. What I suspect, though, is that with all the new controls, bl= ocks with ordinary transactions will verify faster, but an attacker could s= till create a very CPU intensive block by signing inputs with a wide variet= y of nHashTypes and then signing the last one with the equivalent of SIGHAS= H_ALL. I don't think that's a big limitation, though, the attack is= already somewhat possible, and would be very hard to do, and doesn't r= eally gain the attacker anything (other than infamy).=C2=A0

On Thu, Apr 9, 2015 at 1:28 PM, Peter Todd <pete@petertodd.org> wrote:
<= div class=3D"gmail_quote">
For the OP: Have you looked at how CODESEPARATOR allows the signature to sign code to run as part of verifying the signature? E.g. my signature
can say "valid if you run these additional opcodes and they return tru= e"
where those additional opcodes take the transaction, hash it in the
defined way, and verify that the ECC signature correctly signs that
hash and the hash of the additional opcodes. For instance in this case
making a signature that's only valid if the tx fee is less than the
defined amount would be a matter of GET_FEE <max fee + 1> LESSTHAN VE= RIFY

I've never been able to really= see a good use case for OP_CODESEPARATOR, and I'm not sure I completel= y have my head wrapped around what you're proposing. From=C2=A0this=C2=A0and=C2=A0this, though, it seems like OP= _CODESEPARATOR cannot really be made useful unless you already have a way t= o sign without hashing the TXIDs referenced by your input, in which case yo= u need to modify the nHashType.=C2=A0

Best,
Ste= phen
--047d7bfcf2fab4ad94051355e818--