Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gavinandresen@gmail.com>) id 1ROELo-0003Xy-W7
	for bitcoin-development@lists.sourceforge.net;
	Wed, 09 Nov 2011 20:02:24 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.47 as permitted sender)
	client-ip=209.85.214.47; envelope-from=gavinandresen@gmail.com;
	helo=mail-bw0-f47.google.com; 
Received: from mail-bw0-f47.google.com ([209.85.214.47])
	by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1ROELo-0007Az-6g
	for bitcoin-development@lists.sourceforge.net;
	Wed, 09 Nov 2011 20:02:24 +0000
Received: by mail-bw0-f47.google.com with SMTP id zs2so2582365bkb.34
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 09 Nov 2011 12:02:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.152.113.167 with SMTP id iz7mr2480137lab.15.1320868943687;
	Wed, 09 Nov 2011 12:02:23 -0800 (PST)
Received: by 10.152.2.231 with HTTP; Wed, 9 Nov 2011 12:02:23 -0800 (PST)
In-Reply-To: <CABsx9T3T7UZ-G9wsb_NDMBYpnnp9XBnjULmVVDgVXzEaUKn=5w@mail.gmail.com>
References: <BD206D96-C458-4DD7-92F6-32AE476C259A@ceptacle.com>
	<CABsx9T3T7UZ-G9wsb_NDMBYpnnp9XBnjULmVVDgVXzEaUKn=5w@mail.gmail.com>
Date: Wed, 9 Nov 2011 15:02:23 -0500
Message-ID: <CABsx9T3ESoZ21h_V0a8PZAN4MS+KRZ8eVjKc47p9wgJmH0jt-g@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
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(gavinandresen[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
	0.0 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1ROELo-0007Az-6g
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
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: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 09 Nov 2011 20:02:25 -0000

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

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

Here's a half-baked idea that might be brilliant or stupid:

+ 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:

scriptSig:  <escrow_signature> <serialized_escrow_transaction> <sig> <pubkey>
scriptPubKey: ...standard DUP HASH160 <pubkeyhash> ...etc
nValue: 0

The other parties to the escrow transaction could monitor the
block-chain for transactions to my <pubkeyhash>, and get the signature
and proposed "spend the funds in escrow" transaction from the
scriptSig.

.......

"But won't that gunk up the block chain with more data?"

Yup.  But the parties to the transaction will have to pay for the
extra data they're including.

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=0 transaction
can be considered 'immediately spent').

"Can you really put arbitrary stuff in the scriptSig?"

Yup.  The IsStandard() check today allows up to 200 bytes, which
wouldn't be enough for an extra signature and <serialized
transaction>.

The standard <sig> <pubkey> 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
<serialized transaction> would be around 50 bytes or so.

"Wouldn't it be cheaper/better to NOT use the block chain to
distribute signatures?"

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.


-- 
--
Gavin Andresen