Proposal: "No-Collision" mode for Multisig BIP32 Wallets
4 messages, 23 Sep 2014. Started by Alan Reiner.
Alan Reiner (2), Justus Ranvier (2)
This topic has been touched on briefly here before, but I wanted to solidify it and propose it as a BIP if there is wider support for it. Also, the topic is difficult to discuss without lots of pictures -- so that's what I've done (mainly to describe it to my team, but also as general documentation). It's in presentation form:
https://s3.amazonaws.com/bitcoinarmory-media/MultisigWalletNoCollide.pdf
The proposal is that for an M-of-N multisig wallet based on BIP32, there should be N internal chains and N external chains. Each party is assigned a chain based on the lexicographic ordering of their wallet's root public key in the multisig. This guarantees that no parties are generating and distributing the same addresses, and also provides a certain level of built-in book-keeping. Coins being received on chain 2*x were created by participant x (receiving), and coins received on 2*x+1 are change outputs created by participant x (outgoing). Thus, it's easy from simply looking at the wallet structure who was responsible for which transactions.
Alternatively, we could change it to suggest that each "device" is assigned a pair of chains. For a 2-of-3 there may 3 participants plus a CFO with a "watch-only" version of the multisig wallet. Then you might use four pairs of chains. I'm just not sure how they would be assigned.
If this has been proposed before, then consider this my contribution to documentation. -Alan
P.S. -- "No-Collision Mode" is not a great name. Happy to take suggestions for changing it.
On 09/23/2014 04:16 PM, Alan Reiner wrote:
Quoted text (2 lines)
> P.S. -- "No-Collision Mode" is not a great name. Happy to take > suggestions for changing it.
I'd call it a "voting pool wallet", since that was the original application for this arrangement.
Would be nice if you'd at least mention our work, since we did share it with you back in January and have been publicly documenting it ever since.
Or does the fact that we're implementing it in btcwallet mean what we're working on is unmentionable here?
- -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:justus@monetas.net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
On 09/23/2014 12:37 PM, Justus Ranvier wrote:
Quoted text (7 lines)
> Would be nice if you'd at least mention our work, since we did share > it with you back in January and have been publicly documenting it ever > since. > > Or does the fact that we're implementing it in btcwallet mean what > we're working on is unmentionable here? >
Please don't assume poor intentions or sneaky motives. I get a lot of emails from a lot of people about a lot of things. Nine months ago was an eternity in this world, and it can't be ruled out that I simply forgot.
I have no problem giving credit where it is due, and I mentioned in my first email that I wasn't sure if my stuff was original. Please recap/link it here so that it can be part of this discussion.
- -Alan
On 09/23/2014 04:48 PM, Alan Reiner wrote:
Quoted text (2 lines)
> Please recap/link it here so that it can be part of this > discussion.
http://sourceforge.net/p/bitcoin/mailman/message/32736455/
http://opentransactions.org/wiki/index.php/Deposit_Address_(voting_pools)
Currently being implemented here:
https://github.com/monetas/btcwallet/commits/vp
- --
Really what's so annoying is how the BIP numbering process is handled in such a way that proposals can be silently pigeonholed.
Especially so in the case of an *informational* BIP which requires no action on anyone's part (except for not using the same BIP43 purpose code).
We resolved this by changing the naming scheme for our proposals, and their associated purpose codes, to not rely on centrally-allocated numbers.
https://github.com/Open-Transactions/rfc/tree/master/bips
- -- Justus Ranvier | Monetas <http://monetas.net/> <mailto:justus@monetas.net> | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc