From: Stephen Morse <stephencalebmorse@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoin-development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Build your own nHashType
Date: Thu, 9 Apr 2015 22:56:20 -0400 [thread overview]
Message-ID: <CABHVRKQOSHBzkWGoKROcXJd-mKcb3FvLLdSYMgOZJ3gC1zjNnw@mail.gmail.com> (raw)
In-Reply-To: <20150409172808.GB27775@muck>
[-- Attachment #1: Type: text/plain, Size: 3302 bytes --]
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@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@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@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
[-- Attachment #2: Type: text/html, Size: 4707 bytes --]
next prev parent reply other threads:[~2015-04-10 2:56 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-08 19:50 Stephen Morse
2015-04-09 11:29 ` Mike Hearn
2015-04-09 14:10 ` Stephen Morse
2015-04-09 14:22 ` Jeff Garzik
2015-04-09 17:28 ` Peter Todd
2015-04-10 2:56 ` Stephen Morse [this message]
2015-04-18 23:33 ` Peter Todd
2015-04-09 14:45 ` Mike Hearn
2015-04-15 3:34 ` Gregory Maxwell
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=CABHVRKQOSHBzkWGoKROcXJd-mKcb3FvLLdSYMgOZJ3gC1zjNnw@mail.gmail.com \
--to=stephencalebmorse@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=pete@petertodd$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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