From: Peter Todd <pete@petertodd•org>
To: Jeff Garzik <jgarzik@bitpay•com>
Cc: bitcoin-development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Build your own nHashType
Date: Thu, 9 Apr 2015 13:28:09 -0400 [thread overview]
Message-ID: <20150409172808.GB27775@muck> (raw)
In-Reply-To: <CAJHLa0NgV=6D=TAy4sm_EAfYiZULK-d9GMcddW1-DZRHCE8Sew@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]
On Thu, Apr 09, 2015 at 07:22:52AM -0700, Jeff Garzik wrote:
> On Thu, Apr 9, 2015 at 7:10 AM, Stephen Morse <stephencalebmorse@gmail•com>
> wrote:
>
> > Is hashing transaction data once for each input really a huge bottleneck,
> > though? Do mobile devices have an issue with this?
> >
>
>
> Think about what slow transaction verification speed means. Slower
> propagation across the network. More work per node. Greater opportunity
> for algorithmic attacks, races and other shenanigans by attackers.
Keep in mind though we can always make part of the soft-fork be to make
the hash operations in the new CHECKSIG mechanism consume sigops.
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
This can be a much more general mechanism with easy to test modular
opcodes; for the consensus-critical codebase this can result in a much
easier and simpler to test CHECKSIG facility than a dozen new flags.
--
'peter'[:-1]@petertodd.org
000000000000000006975f442f50caa4fcc18e165746b3c77b641b75635afecb
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
next prev parent reply other threads:[~2015-04-09 17:28 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 [this message]
2015-04-10 2:56 ` Stephen Morse
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=20150409172808.GB27775@muck \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=jgarzik@bitpay$(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