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: <CABsx9T3T7UZ-G9wsb_NDMBYpnnp9XBnjULmVVDgVXzEaUKn=5w@mail.gmail.com>
Date: Wed, 9 Nov 2011 21:03:44 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <200034A7-15F9-438F-A6B1-923A69348F55@ceptacle.com>
References: <BD206D96-C458-4DD7-92F6-32AE476C259A@ceptacle.com>
	<CABsx9T3T7UZ-G9wsb_NDMBYpnnp9XBnjULmVVDgVXzEaUKn=5w@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] multisig,
	op_eval and lock_time/sequence...
Precedence: list

Hi Gavin / Alan,

Agree that we would also need to consider these "half" transaction =
valid. At least for the time being up to the lock_time, and one could =
have an extra constrain - that the lock_time should be within e.g. =
30minutes that would avoid the will-never-be-completed cases.

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

I can, however, also understand your worries, and some other constraints =
should be introduced to ensure that not even short time spamming is =
possible...=20

/M

On 09/11/2011, at 20:13, Gavin Andresen wrote:

>> 1. from client1 I issue a transaction containing one of the =
signatures, with a locktime e.g. 10 minutes from now and a sequence of =
0. This transaction is now posted to the p2p network.
>=20
> As Alan said, that won't work-- it will not be relayed across the
> network because it isn't a valid transaction until it has enough
> signatures.
>=20
>> Alternatively, the transactions would need to be sent between clients =
using another protocol...
>=20
> Formats and protocols for gathering signatures are in the TODO
> category-- Alan's BIP 10 is the next piece of the puzzle, maybe a
> standardized http/https RESTful API, or HTTP/JSON, or protocol buffers
> and raw sockets, or... something... solution (or solutions) built on
> top of that makes sense.
>=20
> I don't think partially-signed transactions belong on the main Bitcoin
> P2P network, mostly because I don't see any way of preventing somebody
> from endlessly spamming bogus, will-never-be-completed partial
> transactions just to be annoying.
>=20
> --=20
> --
> Gavin Andresen