search

rgb-archive / spec

[OLD!] RGB Protocol specifications for Bitcoin-based digital assets
https://rgb-org.github.io/
147 stars 26 forks source link

Multisig wallets for RGB assets: design questions #85

Closed dr-orlovsky closed 5 years ago

dr-orlovsky commented 5 years ago

Including P2C commitment scheme. Related issues are: #92 and #93

dr-orlovsky commented 5 years ago

Comment by Alekos:

Pay to contract is not a consensus mechanism, it's just a way to put stuff on the blockchain. In the case of multisig I don't think you would need to tweak all of them (just the first one is fine), but you would also need to reveal the entire scriptPubKey in the proof, so that on the other end it can be checked

dr-orlovsky commented 5 years ago

Well, in case of asymmetric multisigs, like 1-of-3, we need to ensure that any of the participants can’t spend UTXO without proper care of RGB assets, and this will require all three public keys to be tweaked

True, we need it as a field within the proof

inaltoasinistra commented 5 years ago

you would also need to reveal the entire scriptPubKey in the proof, so that on the other end it can be checked

A multisig wallet is able to generate its scriptPubKeys yet. After the assets are moved scriptPubKeys are stored into the blockchain and everyone could see them. So I think it is not needed to include scripts inside proofs.

inaltoasinistra commented 5 years ago

Well, in case of asymmetric multisigs, like 1-of-3, we need to ensure that any of the participants can’t spend UTXO without proper care of RGB assets, and this will require all three public keys to be tweaked

I think that there is no need to tweak pubkeys in order to avoid errors like these. It is simpler to use a different BIP 43 purpose code for RGB aware wallets. Moreover, the RGB awareness should be encoded also into extended pubkeys

dr-orlovsky commented 5 years ago

I think we need to leave the question to the market and let it define the best practice. This means that users should be given an option to choose (either via wallet configuration - or by using some wallets with embedded security policies) whether they tweak all public keys as a matter of funds security - or just some of them. The protocol should not force some particular behaviour and be flexible and simple as much as possible. In this case it seems that the fee-defined vout looks like the best option, and if the tweaked key is kept in a multisig-wallet address, all keys should be tweaked. Otherwise, those who prefer simplicity may tweak only one public key in some of change outputs.

dr-orlovsky commented 5 years ago

Due to the recent updates in #93 and #92 it seems that we have no other option for v1 other than to skip any commitments inside multisigs – and any P2(W)SH and commit to the other output.