Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...

["Michael Grønager" <gronager@ceptacle.com>]

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

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