Mike Hearn [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-12 📝 Original message:Good to see so much ...
📅 Original date posted:2014-03-12
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/257756f4/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5971 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/257756f4/attachment.p7s>;
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/257756f4/attachment.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5971 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140312/257756f4/attachment.p7s>;