From: "Michael Grønager" <gronager@ceptacle•com>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you
Date: Thu, 27 Oct 2011 09:32:16 +0200 [thread overview]
Message-ID: <1089B122-1274-454C-9097-700D392BF0FA@ceptacle.com> (raw)
In-Reply-To: <CABsx9T3YnK9ogc3J39nO=Q+29daMTDhP2J_FGvpozTGAxD1z6Q@mail.gmail.com>
OK, let me try to explain what I see is the problem:
So far we the bitcoin addresses are (for all practical purposes) a one-to-one mapping between a pubkey and uint160. This mean that your wallet is defined solely by your privatekeys (from which you can extract pubkeys and then uint160 btc-addresses).
This also enables you to make a uint160 to tx mapping on a server (like on blockexplorer) and use a thin client to query for transactions just from a list of uint160 (whether it holds the private keys behind them or not).
In the case of a multisig transaction, lets say the 2of3 example, you could e.g. have all 3 corresponding uint160s but only one privkey, but still query the server and know the value of an asset of uint160s.
This, I find a nice and clean setup, where cryptographic keys can be mapped to assets.
If we now consider the OP_EVAL proposal. Here, a new use of the uint160, namely as a mapping of ripemd160(something extra and hash256(pubkey)) is introduced. This means that this clean mapping is broken. Your will have an extra "public key" being the "something extra", and there is no easy way to do the mapping from a list of private keys to public keys to uint160s that will result in the new condensed uint160, except if you also have the knowledge of the script that was used.
I agree that it will work and I (and bitcoin-js and blockexplorer) can of change the concept of a wallet to also include scripts, but it breaks an intrinsic logic of uint160s and transactions that has so far been quite nice and clean.
So I also support checkmultisig to be the standard transaction type, but I do not appreciate the support of OP_EVAL.
Cheers,
Michael
On 26/10/2011, at 17:00, Gavin Andresen wrote:
> On Wed, Oct 26, 2011 at 4:58 AM, Michael Grønager <gronager@ceptacle•com> wrote:
>> I think it is a very important feature to be able to extract transaction to/from you only from your private keys.
>
> Why? If somebody is sending me bitcoins, then they'll have to get
> either an address or one or more public keys from me. OP_EVAL just
> lets me give them a short address that represents an arbitrary number
> of keys combined in an arbitrary way.
>
> I agree with Gregory: it shouldn't matter if that address is
> HASH(public key) or HASH(op_eval_script), the issues are the same (if
> you lose or cannot re-create the key/script then you're in trouble).
>
> Maybe I'm missing something; are you worried that blockexplorer won't
> know that coins sent to HASH(op_eval_script) are actually a
> complicated transaction until the coins are spent again? I'd consider
> that a feature, not a bug, because only the people involved in the
> transaction need to know the details until after the transaction is
> complete.
>
> Feel free to contact me about your 'tiered implementation for thin
> clients' -- I don't think OP_EVAL will make that significantly harder.
>
> I also agree with Alan: using OP_EVAL is not mandatory, I'm proposing
> that CHECKMULTISIG becomes a standard transaction type.
>
> --
> --
> Gavin Andresen
Michael Gronager, PhD
Owner Ceptacle / NDGF Director, NORDUnet A/S
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 62 14 01
E-mail: gronager@ceptacle•com
next prev parent reply other threads:[~2011-10-27 7:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-10-25 10:49 Mike Hearn
2011-10-25 13:21 ` Gavin Andresen
2011-10-25 14:49 ` Gregory Maxwell
2011-10-25 16:47 ` Alan Reiner
2011-10-26 8:58 ` Michael Grønager
2011-10-26 14:03 ` Gregory Maxwell
2011-10-26 15:00 ` Gavin Andresen
2011-10-27 7:32 ` Michael Grønager [this message]
2011-10-27 9:08 ` Gregory Maxwell
2011-10-28 10:24 ` Michael Grønager
2011-10-29 17:01 ` Gavin Andresen
2011-10-31 8:50 ` Michael Grønager
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=1089B122-1274-454C-9097-700D392BF0FA@ceptacle.com \
--to=gronager@ceptacle$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@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