<div dir="ltr">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&#39; inputs, which is much more costly, as the link Gavin posted shows. <div><br></div><div>On Thu, Apr 9, 2015 at 10:45 AM, Mike Hearn <span dir="ltr">&lt;<a href="mailto:mike@plan99.net" target="_blank">mike@plan99.net</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Right, good point. I wonder if this sort of auto forwarding could even be a useful feature. I can&#39;t think of one right now.</div></div></div></blockquote><div><br></div><div>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 <a href="http://bitcoin.stackexchange.com/questions/1495/is-there-a-way-to-automatically-send-bitcoins-from-one-wallet-to-another">this Bitcoin SE post</a>. I think there are better ways to handle key management than auto-forwarding, though. Anyone looking for this feature probably just wasn&#39;t aware that there are better solutions.</div><div><br></div><div>On Thu, Apr 9, 2015 at 10:45 AM, Mike Hearn <span dir="ltr">&lt;<a href="mailto:mike@plan99.net" target="_blank">mike@plan99.net</a>&gt;</span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">Yes but is that fundamental or is there a way to avoid it? That&#39;s what I&#39;m getting at.</div></div></div></blockquote><div><br></div><div>In the bitcointalk article referenced, Sergio actually gave us the answer:</div><div><br></div>&gt; Hash(Tx,previn-index) = Hash ( Hash(outputs) || Hash (Inputs-with-script-cleared) || &lt;previn-index&gt; )<br>&gt;   (for SIGHASH_ALL)<br>&gt;   This way the values &quot;Hash(outputs)&quot; and &quot;Hash(Inputs-with-script-cleared)&quot; can be cached and reused.<div><br></div><div>Basically, just re-order the way stuff is serialized. Put the stuff that is nearly always signed at the beginning, and vice versa. I&#39;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&#39;t think that&#39;s a big limitation, though, the attack is already somewhat possible, and would be very hard to do, and doesn&#39;t really gain the attacker anything (other than infamy). <br><div><br></div><div>On Thu, Apr 9, 2015 at 1:28 PM, Peter Todd <span dir="ltr">&lt;<a href="mailto:pete@petertodd.org" target="_blank">pete@petertodd.org</a>&gt;</span> wrote:<br></div></div></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
For the OP: Have you looked at how CODESEPARATOR allows the signature to<br>
sign code to run as part of verifying the signature? E.g. my signature<br>
can say &quot;valid if you run these additional opcodes and they return true&quot;<br>
where those additional opcodes take the transaction, hash it in the<br>
defined way, and verify that the ECC signature correctly signs that<br>
hash and the hash of the additional opcodes. For instance in this case<br>
making a signature that&#39;s only valid if the tx fee is less than the<br>
defined amount would be a matter of GET_FEE &lt;max fee + 1&gt; LESSTHAN VERIFY<br></blockquote><div><br></div><div>I&#39;ve never been able to really see a good use case for OP_CODESEPARATOR, and I&#39;m not sure I completely have my head wrapped around what you&#39;re proposing. From <a href="http://bitcoin.stackexchange.com/questions/34013/what-is-op-codeseparator-used-for">this</a> and <a href="https://bitcointalk.org/index.php?topic=52949.msg631255#msg631255">this</a>, 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. </div><div><br></div><div>Best,<br>Stephen</div></div></div></div>