Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.161.47 as permitted sender)
	client-ip=209.85.161.47; envelope-from=gavinandresen@gmail.com;
	helo=mail-fx0-f47.google.com; 
MIME-Version: 1.0
In-Reply-To: <BD206D96-C458-4DD7-92F6-32AE476C259A@ceptacle.com>
References: <BD206D96-C458-4DD7-92F6-32AE476C259A@ceptacle.com>
Date: Wed, 9 Nov 2011 14:13:54 -0500
Message-ID: <CABsx9T3T7UZ-G9wsb_NDMBYpnnp9XBnjULmVVDgVXzEaUKn=5w@mail.gmail.com>
From: Gavin Andresen <gavinandresen@gmail.com>
To: =?ISO-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] multisig,
	op_eval and lock_time/sequence...
Precedence: list

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

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.

> Alternatively, the transactions would need to be sent between clients using another protocol...

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.

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.

-- 
--
Gavin Andresen