Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Vanilla multisig is no panacea, as Appendix C claims #25

Open
bitcoinhodler opened this issue Mar 9, 2018 · 1 comment
Open

Vanilla multisig is no panacea, as Appendix C claims #25

bitcoinhodler opened this issue Mar 9, 2018 · 1 comment

Comments

@bitcoinhodler
Copy link
Collaborator

Appendix C claims "This allows all signatories storing private keys to view the user’s balance, because a copy of the redeem script must be kept with each private key. Vanilla multisig transactions would address this[...]"

Vanilla multisig, aka native multisig, puts the multisig script into the output scriptPubKey field at the time of funding, instead of in the scriptSig at redemption time.

Any signatory with a private key can find the matching public key using bitcoin-cli (using a sequence of importprivkey, getaddressesbyaccount, validateaddress). Since this pubkey is already in the blockchain, it can be located by a blockchain search. In the end, a knowledgeable signatory can still see the user's balance. (Granted, it's much more difficult than simply typing the P2SH address into a block explorer.)

Making it worse, the protocol needs a way for the user with M-of-N keys in his possession to find the unspent outputs for this wallet. The process would be exactly the same. A single key is enough to find all the UTXOs, and the protocol would need to walk the user through the process. A signatory with a single key could easily follow the same documented process to find the balance.

And finally, vanilla multisig is not widely supported among Bitcoin wallets, making the funding of such a wallet rather cumbersome.

Therefore, I recommend all the bits about vanilla multisig be removed. Shamir's algorithm is the only way I see to hide the balance from a signatory.

(Thanks to Eric Wall for pointing this out.)

@bitcoinhodler
Copy link
Collaborator Author

I just realized that even using Shamir to hide the redemption script is insufficient if the owner has performed a test withdrawal as the protocol recommends. The test withdrawal will put the redemption script into the blockchain, and as explained above, anybody with a single private key can find it from there. Once they find the test withdrawal they will know the address, and hence the balance.

For complete privacy from nosy signatories, Glacier would need to be redone to shard the privkey itself using Shamir's algorithm. (At this point, multisig is no longer beneficial; it could be a single privkey using standard P2PKH.) This would be a huge change to Glacier and would require more crypto to be done on the quarantined laptops, something the protocol strives to avoid for security and trust reasons.

I'm not suggesting that anybody should implement this; I'm suggesting that Appendix C be updated to explain what would be required for proper privacy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant