From: Gavin Andresen <gavinandresen@gmail.com>
To: "Michael Grønager" <gronager@ceptacle.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 15:02:23 -0500 [thread overview]
Message-ID: <CABsx9T3ESoZ21h_V0a8PZAN4MS+KRZ8eVjKc47p9wgJmH0jt-g@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T3T7UZ-G9wsb_NDMBYpnnp9XBnjULmVVDgVXzEaUKn=5w@mail.gmail.com>
> 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
next prev parent reply other threads:[~2011-11-09 20:02 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 [this message]
2011-11-09 20:31 ` Michael Grønager
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=CABsx9T3ESoZ21h_V0a8PZAN4MS+KRZ8eVjKc47p9wgJmH0jt-g@mail.gmail.com \
--to=gavinandresen@gmail.com \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=gronager@ceptacle.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