Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1ROEoO-0002Gq-4k for bitcoin-development@lists.sourceforge.net; Wed, 09 Nov 2011 20:31:56 +0000 X-ACL-Warn: Received: from backup-server.nordu.net ([193.10.252.66]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1ROEoL-0002AQ-No for bitcoin-development@lists.sourceforge.net; Wed, 09 Nov 2011 20:31:56 +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 pA9KVirf013443 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 9 Nov 2011 21:31:46 +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:31:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: 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: 1ROEoL-0002AQ-No 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:31:56 -0000 Crossing posts ;) I like your idea! - It adds a pricetag to distributing a signature - and = - as you mention it will be part of the standard. It is only up to the = clients if they want to support it or not, but it does give you 0-conf = world wide instantaneous anonymously distribution of half-baked = transactions... However, the parties will anyway need to know at least about each others = public keys up front and hence the 0-conf might not be that important... = Left is, as you said, some anonymity (not much extra though)... /M On 09/11/2011, at 21:02, Gavin Andresen wrote: >> 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 > ... of course I write that and then start thinking about ways you > COULD use the P2P network to distribute signatures, maybe by > broadcasting (and paying fees for) complete transactions that contain > extra signatures for the transaction that you want to sign. >=20 > Here's a half-baked idea that might be brilliant or stupid: >=20 > + Start with an escrow transaction, with 3 public keys. I own one of = the keys. > + I broadcast a 'fee-only' transaction that pays 0 bitcoins to the key > I own. But I add extra data to the scriptSig; something like: >=20 > scriptSig: = > scriptPubKey: ...standard DUP HASH160 ...etc > nValue: 0 >=20 > The other parties to the escrow transaction could monitor the > block-chain for transactions to my , and get the signature > and proposed "spend the funds in escrow" transaction from the > scriptSig. >=20 > ....... >=20 > "But won't that gunk up the block chain with more data?" >=20 > Yup. But the parties to the transaction will have to pay for the > extra data they're including. >=20 > And everything in the scriptSigs can, theoretically, be forgotten (or > never sent) to most nodes on the network once the transaction is spent > and is buried deep enough in the block chain. (a nValue=3D0 = transaction > can be considered 'immediately spent'). >=20 > "Can you really put arbitrary stuff in the scriptSig?" >=20 > Yup. The IsStandard() check today allows up to 200 bytes, which > wouldn't be enough for an extra signature and transaction>. >=20 > The standard is about 150 bytes; part of the > multi-signature proposal will be increasing that to 500 bytes to > accomodate 3-signatures transactions. A simple 1-input-1-output > would be around 50 bytes or so. >=20 > "Wouldn't it be cheaper/better to NOT use the block chain to > distribute signatures?" >=20 > Yup. The only advantage I see is it might be more anonymous to use the > blockchain instead of directly connecting to, and finding out the IP > address of, the parties involved in the transaction. >=20 >=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