Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1ROENJ-0001D8-E6 for bitcoin-development@lists.sourceforge.net; Wed, 09 Nov 2011 20:03:57 +0000 X-ACL-Warn: Received: from backup-server.nordu.net ([193.10.252.66]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1ROENH-0007Eq-PI for bitcoin-development@lists.sourceforge.net; Wed, 09 Nov 2011 20:03:57 +0000 Received: from [192.168.0.15] (2508ds5-oebr.0.fullrate.dk [95.166.54.87]) (authenticated bits=0) by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pA9K3iBh016337 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Nov 2011 21:03:47 +0100 (CET) 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?= In-Reply-To: Date: Wed, 9 Nov 2011 21:03:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <200034A7-15F9-438F-A6B1-923A69348F55@ceptacle.com> References: To: Gavin Andresen X-Mailer: Apple Mail (2.1251.1) X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1ROENH-0007Eq-PI Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence... X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Nov 2011 20:03:57 -0000 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