From: Mike Hearn <mike@plan99•net>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Multisign payment protocol?
Date: Wed, 12 Mar 2014 10:48:01 +0100 [thread overview]
Message-ID: <53202D51.8010008@plan99.net> (raw)
In-Reply-To: <9A6499BC-E546-45CC-A7EF-5182FC86052D@gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1451 bytes --]
Good to see so much activity! But please do remember, there's more to
"multisig" than just keys - you need the whole user experience to be
planned out and specced for fully interoperable implementations.
For the "group account for an organisation" feature, you don't really
want to expose end users to the notion of a key. Historically this has
just led to confusion (and an ugly visual explosion of padlocks and
small metal objects :) It'd be much better for the UI to be designed in
terms of people, perhaps with a bit of social network integration to
avoid having to set up profiles, and then a "group spend" feature would
behind the scenes rendezvous with the others and swap signatures around,
etc. So for interop, you'd need to define all the rendezvous protocols
as well.
> CoinVault is also using a partially signed transaction format whereby
> 0-length placeholders are used for missing signatures in the
> transaction scripts.
I don't know how you are implementing this/what framework you're using,
but I suggest using placeholders that are the length of an actual
expected signature, at least when forming the transaction. This is what
bitcoinj will do because otherwise you could end up miscalculating the
fee, which is based on the final size. See TransactionSignature.dummy()
<http://plan99.net/%7Emike/bitcoinj/0.11/com/google/bitcoin/crypto/TransactionSignature.html#dummy%28%29>
in the API.
[-- Attachment #1.2: Type: text/html, Size: 1885 bytes --]
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 5971 bytes --]
next prev parent reply other threads:[~2014-03-12 9:48 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-10 17:39 Drak
2014-03-10 17:49 ` Gavin Andresen
2014-03-10 18:01 ` Alan Reiner
2014-03-11 0:04 ` kjj
2014-03-11 0:09 ` Alan Reiner
2014-03-11 0:14 ` Jeff Garzik
2014-03-11 1:15 ` Gavin Andresen
2014-03-11 11:43 ` Drak
2014-03-11 12:38 ` Jeff Garzik
2014-03-11 13:51 ` Gavin Andresen
2014-03-11 14:13 ` Jeff Garzik
2014-03-11 14:23 ` Gavin Andresen
2014-03-11 14:34 ` Jeff Garzik
2014-03-11 14:44 ` Jeff Garzik
2014-03-11 14:53 ` Gary Rowe
2014-03-11 15:18 ` Mike Hearn
2014-03-11 17:11 ` Miron
2014-03-11 15:37 ` Thomas Voegtlin
2014-03-11 21:12 ` Peter Todd
2014-03-11 17:41 ` Odinn Cyberguerrilla
2014-03-12 0:29 ` Jean-Pierre Rupp
2014-03-12 2:35 ` Alan Reiner
2014-03-12 2:48 ` Eric Lombrozo
2014-03-12 9:48 ` Mike Hearn [this message]
2014-03-12 15:35 ` Jeff Garzik
2014-03-12 16:02 ` Mike Hearn
2014-03-12 16:09 ` Drak
2014-03-12 16:14 ` Mike Hearn
2014-03-12 16:24 ` Peter Todd
2014-03-12 16:33 ` Jeff Garzik
2014-03-12 16:41 ` Mike Hearn
2014-03-12 16:47 ` Peter Todd
2014-03-12 16:57 ` Jeff Garzik
2014-03-10 17:50 ` Mike Hearn
2014-03-10 18:12 ` Jeff Garzik
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=53202D51.8010008@plan99.net \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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