# Ark vs Bitcoin: musig comparison

### Musig registration workflow
#### Ark
* User creates the musig transaction. For this the pubkeys of the other cosigners is required. Simple value, they need to provide only one hex value.
* Tx is sent to musig server. All the cosigners need to sign it.
* Once all have signed, the originator makes final signature and broadcast tx.
* The blockchain registers the musig wallet. Registration is finished.

#### Bitcoin
There's no such thing as a musig registration. The "identity" of the musig wallet can be fully created offline and funds sent to the wallet's address (any of them) without the blockchain knowing anything about the wallet composition.

When received funds (utxos) need to be moved, the same "identity" creation process needs to be recreated by all signers so they can produce the signature that matches the unlocks the funds.

A couple interesting points:
1. Someone can add a cosigner without him approving, or even knowing about it.
2. Although creator will need to have access to co-signer's account (identity) extended public key.
3. As always with Bitcoin, there's no single one of anything: public keys, address. There's always an HD account node, and then pubkeys and address derived from there.

---
### Transfer transaction workflow
#### Ark
* Tx is created. I think (not sure) it's also signed by the creator at the same time.
* Other signers sign until it's has enough signatures.
* Original creator has to make a final signature, and then broadcast the tx.

#### Bitcoin
* Tx is created by anyone. He may sign it right then or not. It's not necessary.
> Need decision here. We could do same as ark to have the same experience.
* Other signers sign until tx has enough signatures.
* No need for final signature. Once the last one is there, anyone (most likely
the one that gets it to a ready state) can broadcast it.

---
### Public keys to send to musig server
#### Ark
Cosigners have their own, single pubkey / address pair. That pubkey is the one that is part of the musig wallet. That's it.

If the same account is part of many musig wallets, the pubkey is always the same. This means the user can query for tx pending his signature by using exactly his only public key.

#### Bitcoin
The account key for musig is derived from different path (`m/45'/x` for `legacy`, `m/48/0'/0'/1'` for `p2sh-p2wsh` or `m/48/0'/0'/2'` for `native segwit`) than the ones for regular wallets (`m/44'/0'/x'` for `legacy`, `m/49/0'/x'` for `segwit` or `m/84/0'/x'` for `native segwit`).

Those path are the common practice. Each wallet is free to choose what to use as there's no a definite standard. And of course, some wallets let the user choose what to use or default to the just mentioned ones. So technically, it doesn't matter, anything could be used for account key.

The huge implication of this is that the account key for a user's individual wallet and the one for him being part of a musig wallet will never be the same. So when sending transaction to musig server the DW needs to have the musig wallet imported so he can check for the right keys. The user's individual wallet keys don't allow for checking for transactions pending signature by him.

# After discussions
Long conversation over [Slack channel](https://cryptoarkproject.slack.com/archives/C01375X48CS/p1633695776453900).

Conclusions:
* We'll go for a BitPay-like approach where we provide a workflow for the registration process until we gather all details to create the musig wallet (basically gathering all participant's extended public keys). For that,
* We create a fake registration tx and send to musig server.
* Outside of the system, creator shares the wallet identifier (QR, copy / paste code or URI, whatever...). It all happens offline.
* Users use Join Musig Wallet in their DW using the code in QR, by signing the transaction.
* DW will keep monitoring for that tx until signed by everyone. Once signed by all, the wallet gets created for all participants in DW.

Further questions / comments:
* The fake registration needs to be kept somewhere. Because if some participant re-installs DW or recreates profile they need to be able to join again. Or there should be a mechanism that allows any of the participants to export all the extended public keys that make up the wallet.