From: Mike Hearn <mike@plan99•net>
To: Stephen Morse <stephencalebmorse@gmail•com>
Cc: bitcoin-development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Build your own nHashType
Date: Thu, 9 Apr 2015 16:45:35 +0200 [thread overview]
Message-ID: <CANEZrP3mBibjUK99L=E9jHFAvQ0QLpx0ke112=yQjw-RhjWnyg@mail.gmail.com> (raw)
In-Reply-To: <CABHVRKSET18D13+yi4MTPs6+4xwUD5vuJszCOJG9CaTi0+CAvA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1460 bytes --]
>
> I don't think it's quite a blank check, but it would enable replay attacks
> in the form of sending the money to the same place it was sent before if an
> address ever receives coins again.
>
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.
> It's hard, though, because there is different data needs to be signed for
> each input.
>
Yes but is that fundamental or is there a way to avoid it? That's what I'm
getting at.
> Another possibility would be to put the previous scriptPubKey and previous
> output value at the END of the serialized transaction, so that you could
> make use of some sort of a signature hash midstate.
>
Interesting idea! I don't agree it's messy. If anything it should be
simpler than what we have today - the need to edit a transaction *in the
middle* means that sighash computation involves constantly reserializing a
transaction before it even gets to be hashed.
> Is hashing transaction data once for each input really a huge bottleneck,
> though? Do mobile devices have an issue with this?
>
Consider what happens with very large transactions, like a big assurance
contract that might have thousands of inputs and be multiple megabytes in
size. Obviously such large transactions cannot happen today, but there is
user demand for giant contracts (or at least, users tell me there is,
whether they'd actually do it for real is a bit unclear).
[-- Attachment #2: Type: text/html, Size: 2521 bytes --]
next prev parent reply other threads:[~2015-04-09 14:45 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
2015-04-18 23:33 ` Peter Todd
2015-04-09 14:45 ` Mike Hearn [this message]
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='CANEZrP3mBibjUK99L=E9jHFAvQ0QLpx0ke112=yQjw-RhjWnyg@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=stephencalebmorse@gmail$(echo .)com \
/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