From: Gregory Maxwell <gmaxwell@gmail•com>
To: Stephen Morse <stephencalebmorse@gmail•com>
Cc: bitcoin-development <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Build your own nHashType
Date: Wed, 15 Apr 2015 03:34:50 +0000 [thread overview]
Message-ID: <CAAS2fgTndnSoSx8==EVvP_mMHX=TEMV0whN7s3RBoMYyYDmzJw@mail.gmail.com> (raw)
In-Reply-To: <CABHVRKTNFoLm9LEO=ctT_UP9zW7QOMQzVXitKC=PAzj=HG9OHg@mail.gmail.com>
On Wed, Apr 8, 2015 at 7:50 PM, Stephen Morse
<stephencalebmorse@gmail•com> wrote:
> Seeking feedback on a proposal that will allow a transaction signer to
> explicitly specify what is to be serialized for the signature hash. The
> basic idea is to make the nHashType general enough that we won't need a new
> sighash flag every time a new use case comes up.
>
> If implemented into bitcoin (via a soft fork), this would make malleability
> almost a non-issue (the TXID referenced by inputs just need to be updated
> previous TX changes) and would enable hardware wallets to securely sign
> without needing to download/process each transaction it spends from.
I'm not sure if I'm super fond of that particular non-programmatic but
many options approach; It sort of has the problem that there are
relatively few useful options that don't rapidly extend into a choose
your own adventure with too many options to count; so you take a
complexity penalty perhaps without a matching functionality payoff.
but thats not why I'm commenting...
I wonder if anyone noticed that any sighash masking that eliminates
the txin txid enables covenants?
Covenants are payments which constrain their future payments (like
deed covenants), I've written about them in the past
https://bitcointalk.org/index.php?topic=278122.0 ... they can
sometimes be pretty useful but are also potentially a irritating hit
to fungibility, at least if used stupidly.
the approach here is that you make the scriptpubkey contain "[push:
0x30, 0x06, 0x02, 0x01, 0x04, 0x02, 0x01, 0x04, flags] [push pubkey
resulting from pubkey recovery] OP_CHECKSIG" and set the flags to
match only the things you want to enforce in the spending transaction
hash them up and recover the EC public point. You can think of that
construct as giving a you a OP_MASKED_TRANSACTION_HASH_EQUALS ... the
recovered pubkey is just a kind of message hash, though a weird and
expensive to compute one.
I don't currently see how to get a perpetual covenant out of it-- e.g.
a coin that anyone can spend, but only to its same scriptpubkey, (the
obvious way requires the ability to be able to checksig stuff on the
stack) though I wouldn't be shocked if it were possible with a
sufficiently complex sighash flag and nothing else.
prev parent reply other threads:[~2015-04-15 3:34 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
2015-04-15 3:34 ` Gregory Maxwell [this message]
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='CAAS2fgTndnSoSx8==EVvP_mMHX=TEMV0whN7s3RBoMYyYDmzJw@mail.gmail.com' \
--to=gmaxwell@gmail$(echo .)com \
--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