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: <4EBB3E68.6060402@gmail.com>
Date: Thu, 10 Nov 2011 10:55:55 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <CBFE8E7C-7A30-4450-A111-4EB413E068DF@ceptacle.com>
References: <BD206D96-C458-4DD7-92F6-32AE476C259A@ceptacle.com>
	<CABsx9T3T7UZ-G9wsb_NDMBYpnnp9XBnjULmVVDgVXzEaUKn=5w@mail.gmail.com>
	<200034A7-15F9-438F-A6B1-923A69348F55@ceptacle.com>
	<4EBB3E68.6060402@gmail.com>
To: Alan Reiner <etotheipi@gmail.com>
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] multisig,
	op_eval and lock_time/sequence...
Precedence: list

Hi Alan,

I have now read BIP0010 - one first idea is: add a link to it on the =
wiki (or remove all bip links from the wiki... - we don't want two =
places for BIPs...)

I am not sure where you prefer the discussion on the content of the BIP =
- but now you get it here, but feel free to redirect...

Likes:
* inclusion of prevout txout scripts - could prove handy
* that it is a proposal to do this similarly on all clients

Dislikes:
* the format - I guess I would prefer a normal JSON format - where the =
scripts gets populated step by step. As for the scriptPubKey (now an =
awful name...) it would be easy to just add it to the JSON, or have the =
prevouts simply be the actual txouts instead of {hash,n}.

Comments:
* it is good to have this proposal, but I think that once we see ways to =
communicate it they could very well radically steer how a format should =
look. Take e.g. the discussion we had with Gavin yesterday, if we had =
chosen to move in that direction BIP0010 would had been useless. So =
perhaps a bit premature?

Cheers,

Michael


On 10/11/2011, at 04:00, Alan Reiner wrote:

> The purpose of creating BIP 0010 now, is to encourage a standard that =
developers want to adopt, from the outset.  Every developer who is =
planning to touch multi-signature transactions, is going to have to =
solve the problem of multi-sig tx exchanges, eventually.  By offering an =
excellent solution before they've started asking the question, there's a =
good chance people will use it.   Hear me out...
>=20
> Protocols get fragmented when there's multiple competing ways to do =
something, each having some advantages the others don't have.  This =
leads to developers with differing priorities picking different ones, or =
creating their own.   However, I believe that the problem BIP 0010 seeks =
to solve is a fairly straightforward problem.  There's not a lot of =
variety in the solutions that could compete against it.  People just =
need a way to pass this data around, and they want it to be as =
convenient to use, and as easy to implement as possible.  In that sense, =
I think BIP 0010 (or some future variant) is fairly optimal as a =
building block for higher-level protocols. =20
>=20
> If anyone has ideas for why someone would want to create a competing =
idea to BIP 0010 (besides not being aware of it when they start), I'd =
like to discuss it.  I'm fairly confident that any such ideas could just =
be added to BIP 0010 and thus reset the question of why anyone would =
need a competing idea.
>=20
>=20
>=20
> On 11/09/2011 03:03 PM, Michael Gr=F8nager wrote:
>> My main concern when it comes to introducing other protocols is that =
they might never be standard (I think a great number of clients will =
emerge - and this would be a thing to compete on). If it is part of the =
p2p network it will be a seamless standard and easy for everyone to use, =
even across different clients. But I share your concern on the=20
>>=20
>> /M
>>=20
>=20
> =
--------------------------------------------------------------------------=
----
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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


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