public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Michael Grønager" <gronager@ceptacle.com>
To: Gavin Andresen <gavinandresen@gmail.com>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...
Date: Wed, 9 Nov 2011 21:31:44 +0100	[thread overview]
Message-ID: <E390E6EB-BE00-4F96-A4FB-05C39E2036BB@ceptacle.com> (raw)
In-Reply-To: <CABsx9T3ESoZ21h_V0a8PZAN4MS+KRZ8eVjKc47p9wgJmH0jt-g@mail.gmail.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





  reply	other threads:[~2011-11-09 20:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-09 10:22 [Bitcoin-development] multisig, op_eval and lock_time/sequence Michael Grønager
2011-11-09 14:43 ` Alan Reiner
2011-11-09 15:22   ` Alan Reiner
2011-11-09 19:13 ` Gavin Andresen
2011-11-09 20:02   ` Gavin Andresen
2011-11-09 20:31     ` Michael Grønager [this message]
2011-11-09 21:18       ` Gavin Andresen
2011-11-09 21:32         ` Joel Joonatan Kaartinen
2011-11-09 22:13     ` theymos
2011-11-09 20:03   ` Michael Grønager
2011-11-10  3:00     ` Alan Reiner
2011-11-10  9:55       ` Michael Grønager
2011-11-10 12:56         ` Alan Reiner
2011-11-12 16:58           ` Mike Hearn
2011-11-12 17:10             ` Alan Reiner
2011-11-12 17:16               ` Mike Hearn
2011-11-12 17:25                 ` Alan Reiner
2011-11-12 17:38                   ` Mike Hearn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E390E6EB-BE00-4F96-A4FB-05C39E2036BB@ceptacle.com \
    --to=gronager@ceptacle.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=gavinandresen@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox