Stephen Morse [ARCHIVE] on Nostr: 📅 Original date posted:2015-04-09 📝 Original message:Regarding the re-hashing ...

📅 Original date posted:2015-04-09
📝 Original message: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 <mike at plan99.net> 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
<http://bitcoin.stackexchange.com/questions/1495/is-there-a-way-to-automatically-send-bitcoins-from-one-wallet-to-another>;.
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 <mike at plan99.net> 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) || <previn-index> )
> (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 <pete at petertodd.org> 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 <max fee + 1> 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
<http://bitcoin.stackexchange.com/questions/34013/what-is-op-codeseparator-used-for>;
and this
<https://bitcointalk.org/index.php?topic=52949.msg631255#msg631255>;,
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150409/f55fb600/attachment.html>;