Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
In-Reply-To: <CABsx9T3YnK9ogc3J39nO=Q+29daMTDhP2J_FGvpozTGAxD1z6Q@mail.gmail.com>
Date: Thu, 27 Oct 2011 09:32:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1089B122-1274-454C-9097-700D392BF0FA@ceptacle.com>
References: <CANEZrP1ic4RXFzoqf66MGv=rJe3MgWxVi5nnk2VKkMc4VMCDyw@mail.gmail.com>
	<CABsx9T3WKv3RLWT+Q6s7cCLzDL3sVRCWfmPiKcSp=_Re05m+zQ@mail.gmail.com>
	<CAAS2fgSYwUdiyY2XfHhWn+aN_6a72XRKs-8W7ibZM5t0tZ28rg@mail.gmail.com>
	<CALf2ePy=3N1JQodP3s9PzH=Af1z-7qGdy_4=QW9-CJmaxYGz5Q@mail.gmail.com>
	<7A50EE90-0FFC-45FB-A27F-786AEB23A8CA@ceptacle.com>
	<CAAS2fgTx8gEztUt-UrDObMCQtfdzZc52fzS6c1q8mm+a-TjwjQ@mail.gmail.com>
	<CABsx9T3YnK9ogc3J39nO=Q+29daMTDhP2J_FGvpozTGAxD1z6Q@mail.gmail.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
Precedence: list

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.=20

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=F8nager =
<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.
>=20
> 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.
>=20
> 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).
>=20
> 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.
>=20
> Feel free to contact me about your 'tiered implementation for thin
> clients' -- I don't think OP_EVAL will make that significantly harder.
>=20
> I also agree with Alan: using OP_EVAL is not mandatory, I'm proposing
> that CHECKMULTISIG becomes a standard transaction type.
>=20
> --=20
> --
> 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