Bitcointalk username: NotATether
(This review has been prepared a few days ago. It covers the Android app in landscape and portrait mode, funding the multisig wallet from Electrum.)
Review of Mixin Safe Wallet Messenger
TL;DR What is this program? It doubles as a messaging program and a cryptocurrency wallet that is supposed to make it easier for you to send crypto to contacts in your phonebook, assuming they also have Mixin Safe installed. This leads me to believe that this app wants to achieve mass adoption.
I am going to specifically cover the Android app. (Read below about PC and iOS apps.) This is going to be more comprehensive than most of my other reviews due to the sheer size of the program, nevertheless, let's get this under way.
Initialization
First of all, I could not install this on my iPhone as it was (barely!) too old. I heard stories of people getting their phones bricked after upgrading to a really later iOS so that's a no-thanks from me. So I borrowed an Android phone for this demonstration. I'm assuming the interface would be like-for-like with the Android build anyway.
This is the homepage which you can get to after you type in your phone number and stuff. Well, you might ask: "Why must I need a phone number to use a crypto wallet?" I can think of two possible reasons:
- It could be a semi-custodial wallet so it needs some way to identify users (they did say they are using a 2-of-3 multisig and hold one of the keys)
- It could be for the benefit of identifying to your contacts who is using the app so that they can send cryptocurrency to you
(Apparently, in retrospect, it could also be used for authentication too.)
All in all though, mandatory phone verification was actually something I expected to see only in exchange apps, so that was pretty weird.
Yes, images are blurry - it's not like I was taking these photos from an action camera, but you can just about see enough of the user interface and text to figure out that this is a) the homepage, and b) I have been immediately sent 4 messages by "Team Mixin" after creating the account. Side note though: Why send four messages, when you could include most of that information in one message, with a WWW link (that is not the homepage) where I can read more information? That would be a better design.
Interface
As you can see in this image, there are three main buttons at the bottom. The one on the left is where you access your wallet - when you first open the app, there is no wallet created, so it nags you to create a wallet.
Here is a screenshot of the create wallet process since I forgot to take a photo of it on the camera:
As you can see, your wallet is not secured by a password or a seed phrase. Instead, it is using a PIN that is sent through
Throttled Identity Protocol. (What the hell is Throttled Identity Protocol you ask? Read Appendix A.)
Anyway, the important part is to get an internet connection while you do this because it's going to connect with some servers during the process (using TLS and key hashing I hope).
Then you are asked to enter a PIN which will be your wallet password (where the phone number is your username I guess). But before you enter a dummy PIN, the app will actually stop you from using insecure PINs:
private fun validatePin(): Boolean {
val pin = binding.pin.code()
if (pin == "123456") {
toast(R.string.wallet_password_unsafe)
return false
}
val numKind = arrayListOf()
pin.forEach {
if (!numKind.contains(it)) {
numKind.add(it)
}
}
if (numKind.size <= 2) {
toast(R.string.wallet_password_unsafe)
return false
}
return true
}
(Ah yes, how I love having my Java skills in a time like this.)
So basically, you can't use the passwords:
"123456"
Any password that has only one or two digits, such as "111111" or "010101".
However according to
this, I advise the developer to blacklist
- consecutive sequences of numbers (not just 123456, but also something like 234567)
- reversed number sequences (i.e. 654321)
In general, PINs are much less secure than passwords because the creative PINs of a particular length are much less than the creative ASCII passwords of an equivalent length. Developer should also add password support.
You must enter the PIN
four times because Mixin really doesn't want you to forget the PIN. But I don't really find that effective, because all those entries are happening at one point in time. It is better to copy Telegram in this regard which displays a "Do you still remember your password?" notification where you can enter the password while logged in to see if you still remember it - and if not, change it immediately.
Here is a very uneventful screen while we wait for the TIP keys to be created from the passcode:
Periodically, you will be asked to enter this PIN at seemingly random times. Must be a protocol thing (See Appendix A).
Wallet
Now that we have created a Mixin wallet, we can access our assets and see the almost 40 OG coins and shitcoins listed in your portfolio!
Making the list:
- Bitcoin
- Ethereum
- Litecoin
- BOTH BNB tokens
- Bitcoin Cash
- Monero
- Craig Wrong's coin (who shall not be named)
- Dash
- ZCash
- Solana
- Kusama (whatever that is)
- ETH Classic
- Decred
- Avalanche
- Cosmos
- Horizen
- Aptos (what?)
- Arweave (what?)
- Polkadot
- Filecoin
- Namecoin
- NEAR protocol
- Toncoin (read carefully: Toncoin not Tron)
- Tezos
- EOS
- Polygon (aka MATIC)
- XRP
- Mobilecoin (whatever that is)
- Akash Network (god these coins have weird names)
- Stellar Lumens
- Algorand
- Tron
- Dogecoin (says something about DOGE's usefulness being placed so down the list)
- Ravencoin
- Handshake (never heard of it)
- Siacoin (see above)
- Nervos CKByte (see above)
In addition, it supports most token chains such as ERC20, BEP20, BEP-2 (Binance is so messed up for having two different yet similarly sounding chains), TRC-20, TRC-10. Layer 2 networks such as Liquid, Lightning, etc. are
not supported.
Coin receive addresses are generated when you click on the coin for the first time.
(Honestly I think half of these coins would be called securities by Gary Gensler and the other half his SEC agency would have no clue what to call them
)
You can send or receive coins from each address, but you have to add the address into the app in order to use it, so it may not be ideal if your addresses mainly consist of those from Coinpayments, Coinbase Commerce, BitPay, and exchange deposit addresses.
(Memo is a blockchain thing and is only required for such obscure coins like EOS and Stellar and can be safely turned off for almost everything else).
You can also send coins to other Mixin contacts, and hide coins that you will never use. For most people reading this, that's usually the bottom 90% of this list.
Transactions
Originally, I did not have this section included, but sending and receiving a transaction is required so here it goes.
Receiving transactions in particular is straightforward. There's a giant modal with address and QR code for each coin which you can just copy or send to another device to make a transaction. I have made a $30 transaction in BTC inside debbe87a68398075a2be41eb109f49bfc741c4e355f7bbbe42836d7f96dee05a to address bc1qdltcmdt7xlpm4c0p2gku9rdl74vthf5cjm8q24 (I don't know if you can verify addresses as being from Mixin, but here we go:)
I have two transactions listed here, because one is the RBF of another, and both are displayed here for some reason. Nevertheless, you can see that the more recent transaction has already been included in a block, while the older one should fall off over time as the blockchain nodes become full.
Sending coins is a bit of a hassle though, and actually has me a bit pissed (after all, you don't always deposit $30 to test a service). You are required to enter your PIN to
add an address - not just when you are sending money. Why? Also, I got (supposedly) locked out for 24 hours trying to add an address with a label "Mr. X", despite remembering my PIN and entering it correctly. Or at least that's what the app claims happened, because after removing all the special characters and numbers/uppercase letters from the label, I was able to successfully add an address just a few minutes later. Anyways, its very inconsistent.
The actual error message says something like: "You will be locked out for 24 hours. 5 tries remaining" which I interpreted as being locked out now and after 5 more tries you get permanently locked out like a phone. Anyway, quite inaccurate message.
So now finally I can send the coins back to my address. But there is a massive, fixed 0.0004
BTC "withdrawal fee" for bitcoin that feels more like tax (the 0.004
BTC was
not part of the measly 21 sats/vbyte transaction fee) and makes Ethereum look cheap by comparison (again, why? BRC20 congestion isn't as bad anymore). How come fees cannot be customized if this is a semi-custodial wallet?
Full documentation of the circus that is the current receiving process:
QR Scanner
Going back to the main menu, the button in the middle is for scanning QR codes. These could be addresses, transaction invoices, or things like logging in to the desktop client.
(Unfortunately, I forgot to link up the app with a desktop wallet, so that is why I could not review the desktop wallet. Sorry!)
Speaking of which, the desktop app, before you scan its code, is just a blank page with a QR code on it. I think, if its practical, there should be a second box below the QR code, displaying the contents of the QR code for you to type into the mobile app. That way, it can function on phones that have the camera disabled for security reasons (Edward Snowden), and possibly in the future, even hardware wallets that pick up on the protocol. (perhaps place a checksum at the end just like with bitcoin addresses). More on this below.
It seems that there is no support for linking hardware wallets with this app, which I think is a shame, because if would've been fantastic for hardware wallet holders to be able to use their devices along side an open-source multi-currency wallet.
"Bots"
For some reason, this is the name of the rightmost button on the main menu. It looks like this:
So this looks like we got ourselves the first two buttons (why?), a camera, and what is presumably a circle for each contact (for me, not wanting to add any contacts, I just see the circle for "Team Mixin").
I'm going to assume that the camera is for taking pictures to send to contacts? Because it really doesn't have a use for the wallet when the QR scanner exists.
Anyway, this is what you get when you open a contact:
And here is me adding random contacts and group chats (just to show that these features work as intended):
By the way, if you uninstall the app, it saves the wallet and stuff so that's nice. It also gives you the option to restore chat history from the local device or another device.
Full contents messages from "Team Mixin":
Welcome to Mixin Messenger,
This is the support bot, and ready to help whenever you need it. Some quick features list:
1. Everything, including text, audio, photo, and so on, is end-to-end encrypted with Signal protocol.
2. Mixin Messenger allows you to make end-to-end encrypted group audio call with up to 16 people.
3. The built-in wallet makes it easier to transfer many popular cryptocurrencies with your contacts.
Best,
Team Mixin
Mixin Messenger's Guidelines
Welcome to use Mixin Messenger and enjoy end-to-end encrypted chat featuring a full-cryptocurrency wallet.
Secure: decentralized wallet
Instant: Confirm finality less than 1 second
Free: No transfer fees
Easy to use: manage assets with a 6-digit pin, making transfers by contacts
Diverse: Support 36 public chains such as BTC, EOS, ETH, XMR, and more than 100,000 tokens.
Help documents
How to use Bots?
Please read How to use Bots on Mixin Messenger?
How to deposit?
Please read How to deposit?
How to use credit cards to buy USDT, USDC, and DAI?
You could add Mixin Wallet
How to trade cryptos?
Several third-party bots provide trading services, such as MixSwap (similer to 1inch), 4swap (similar to Uniswap), or ExinOne (connects with Binance and Huobi exchange, working as an intermediary agent).
Find people to talk with?
Welcome to join supergroups such as Mixin English, FOX.ONE English.
Mixin Network's public data
Please add Mixin Data and tap the bot icon to check.
More useful bots
Please add Mixin Bots that collects the frequently used app on Mixin Messenger.
Need help?
Please leave a message to Team Mixin, and the support team will help you.
It turns out the other two messages are duplicates of the first two messages quoted here, so they will not be reposted again.
Speaking of which, with all these services, I wonder how Mixin makes money?
Profile and Settings
One more time, lets go back to the main menu, and this time click on the top-right avatar. There, you can see your profile, with options to add a contact or start a new group chat (as well as to receive money by sharing a Mixin QR code).
Now when you click on the gear, you get taken to the settings page. Here are a bunch of settings which I think you will find self-explanatory:
Multisig
Let's be honest, I expected the 2-of-3 multisignature to be: 2 keys held by the user and 1 by Mixin - trustedcoin does something like that for Electrum. (After all, you can't view private keys or seeds yourself). Nowhere in the app did I see any information about creating a multisig or using it in any capacity, which left me kind of disappointed as multisig was one of the things that was advertised on the website. Although later I did get a message from the developer which read that the multisig is actually used internally by Mixin servers when you send a transaction - so that's something, but it doesn't
feel like a multisig in the sense that I have multiple devices and signatures hooked up to the wallet. An attacker can still wipe you out if they have your PIN.
Certainly, in a single-user wallet, I am not going to be adding people as co-signers for any kind of multisig wallet anyway. But the emergency recover feature looks cool - it's worth noting that
I myself don't have a use case for it - though I have fears this might be abused like a password reset.
Some other people here are downloading multisig / auth apps for this purpose, but I decided not to go down that route. After all, if you want to distribute some of the keys to other wallets, it would be more economical to support the hardware and software wallet integrations instead. Maybe the desktop app supports it (I don't know), but Android doesn't seem to support it.
Edit: It seems that multisig is only available on desktop / web.Verdict, and Thoughts
I cannot see myself using this wallet for BTC. But maybe the other coins have lower fees so I don't know. It certainly looks more reputable than some of the other wallets out there (Atomic FTW!). The procedure for adding addresses is cumbersome and downright annoying at times,
there is no fee customizer (I have no idea why they are taking 0.004
BTC if it's not for a transaction fee - If they are trying to do the TrustedCoin business model then that is way too much)
And above all there's no reason to have a mobile-only app when you can make the desktop app support mobile phone login with phone numbers of any SIM card in a telephone. It's not like the app is using the secure device storage for storing private keys anyway. And even if it is, AES-256-CBC is more than a match for storing the local private key.
I never store cryptocurrency on mobile phones for any reason, so I'd regard this as an important issue. But when we ignore the chatting features, camera, messaging, the whole bot ecosystem, etc., this is a solid wallet (again, with the exception of the "withdrawal fee") being used and protected by the decentralized TIP protocol. We just need assurances & proof that the node software being used for TIP cannot be compromised - something more than one crypto hacker would like to do.
And in the end, I think this is exactly what's needed - a wallet. Support for hardware wallets and Layer 2 networks would definitely help.
That is why I don't think it's a good idea to leave the Windows/Mac/Linux desktop application as a dud, it should be useful out of the box without the need for a mobile app. (Just TIP phone number log-in plus PIN and you should be all set.) Mass adoption can only happen when you facilitate it.
Appendix A: Throttled Identity Protocol (TIP)
I checked out the website and found that this solution is developed by none other than our resident Mixin boss, so I'll let the page do most of the talking.
TL;DR - using custom authentication servers, users can give a service provider something like an email address or some other unique identification for themselves, set a password, which is used with the username in a bunch of HMAC hashing to generate one of the parts of a multisignature key (m-of-n). Only after m of these are generated (which could be exact duplicates I guess??) can you create a signature that doubles as an "authentication success token" which is just a bunch of bytes you can use to derive a private key, a seed phrase, etc. from.
Throttled Identity ProtocolThrottled Identity Protocol (TIP) is a decentralized key derivation protocol, which allows people to obtain a strong secret key through a very simple passphrase, e.g. a six-digit PIN.
Mission and OverviewAlong with the rising of Bitcoin and other cryptocurrencies, the saying "not your keys, not your coins" has become well-known. That's true, very true and definitely true, that's the right and freedom Bitcoin has given people. Whoever can access the key can move the money, and nobody without the key is able to do that.
That said it's better to manage your own Bitcoin private key than let your coins lie in some centralized exchanges. However, it's admitted that key management requires superior skills, which most people lack. And the result is people who own their keys lose the coins permanently due to various accidents, and those who opened a Coinbase account years ago can still get back their assets easily.
The embarrassing result doesn't prove the security of centralized exchanges, yet exposes the drawbacks of key management. The key grants people the right to truly own their properties, but people lose money due to poor key management skills. People should not be blamed for that, it's the problem of the key itself.
Bitcoin gives people the right and freedom to own their properties, and people deserve the convenience to manage their keys. Current private key or mnemonic phrase designs are over-complicated for people to keep properly. Instead of fearing the corruption of centralized financial institutions, people become slaves of the private key.
It's what TIP strives to do. Let people truly own their coins with a six-digit PIN. This decentralized PIN is easy to remember for any person, doesn't require any special skills or hardware, and people can manage their coins with more confidence than ever.
Protocol DesignTIP involves three independent parties to make the protocol work. A decentralized signer network authenticates signing requests from the user, and throttles malicious attempts; A trusted account manager serves the user an identity seed, which typically authenticates the user by email or phone verification code; The user remembers a PIN and combines the identity seed from the account manager, then makes independent requests to enough signer network nodes, and finally derives their secret key.
Decentralized Network SetupThe decentralized signer network is launched cooperatively by many different entities. Specifically, those entities gather and reach a consensus to run some node software, those nodes interactively run a distributed key generation protocol. For TIP, the DKG is
threshold Boneh-Lynn-Shacham (BLS) signatures.
Assuming
n entities agree to launch the network, they generate an asymmetric key pair respectively and configure their node software to include all the entities' public keys in a deterministic order. Then they boot the nodes to run a
t-of-
n (where
t=n * 2 / 3 + 1) DKG protocol to set up a collective public key
P and private key shares si respectively.
After the DKG protocol finishes, all entities should share the public key
P to ensure they hold the same one, keep their private key shares si cautiously, and should make professional backups.
Finally, all entities should boot their node software to accept throttled signing requests from users. And again, they should safeguard the node servers and defend against all malicious attacks.
This repository includes an implementation of the signer node software, for instructions please see the
signer directory.
Throttled Secret DerivationThe network announces the configuration and signers list to the public or potential users and waits for signing requests. Each signer should throttle the requests based on the same restrictions.
- Identity. This is the base factor for all restrictions, the identity should be a valid BLS public key, and a user should use the same identity for all signers. The signer checks the request and verifies the request signature against the public key, and the signer must reduce the request quota of this identity for any invalid signature.
- Ephemeral. This parameter is a different random value for each signer but should remain unchanged for the same signer during the ephemeral grace period. If the ephemeral changes during the grace period, the signer must reduce the ephemeral requests quota of this identity.
- Nonce. For each signing request, the user should increase the nonce during the ephemeral grace period. If the nonce is invalid during the grace period, the signer must reduce the ephemeral requests quota of this identity.
After the signing request passes all throttle checks, the signer responds back a part of the
t-of-
n threshold BLS signature by signing the identity. Whenever the user collects
t valid partials, they can recover the final collective signature and verify it with the collective public key.
The final collective signature is the seed to the secret key of the user. Then it's up to the user to use different algorithms to generate their private key for Bitcoin or other usages. It doesn't need any further requests to use this secret key, and in case of a loss, the user can recover it by making the same requests.
For details of the throttle restrictions, please see the
keeper directory.
Threshold Identity GenerationThe mission of TIP network is to let people truly own their coins by only remembering a 6-digit PIN, so they should not have the duty to store
identity,
ephemeral or
nonce. They are capable of achieving this goal through the threshold identity generation process with the help from the trusted account manager.
- User authenticates themself with a trusted account manager through email or phone verification code, and the manager responds with the identity seed Si.
- User chooses a very slow hash function Hs, e.g. argon2id, and generates the identity I=Hs(PIN || Si).
- User generates a random ephemeral seed Se, and stores the seed on its device securely.
- For each signer i in the network with public key Pi, user generates the ephemeral ei=Hs(I || Se || Pi).
- User sends signing requests (I, ei, nonce, grace) to each signer i and gathers enough partial signatures, then recover the final collective signature.
- User must repeat the process every a while to refresh the ephemeral grace period.
The identity seed should prohibit all impersonation, the on-device random ephemeral seed should prevent the account manager collude with some signer, and the ephemeral grace period allows the user to recover its secret key when the device is lost.
Furthermore, the user can make their threshold identity generation more secure by cooperating with another user to combine their identity to increase the entropy especially when the account manager manages lots of identities.
And finally, the user can just back up his seeds like any traditional key management process, and this backup is considered more secure against loss or theft.
Network EvolutionOnce the decentralized signer network is launched, its signers should remain constant, no new entity is permitted to join the signers or replace an old signer because the DKG protocol remains valid only when all shares remain unchanged. But people need the network to become stronger, and that requires more entities to join the network. So TIP allows network evolution.
Whenever a new entity is accepted to the network, either replacing an old signer or joining as a new one, an evolution happens. Indeed, an evolution starts a fresh DKG protocol in the same process as the previous evolution, but with different signers, thus resulting in absolutely different shares for each signer. It's noted that an entity leaving the network doesn't result in any evolution, because the remaining shares can still serve requests.
In a new evolution, all signers should reference the number and the hash of the signer list from the previous evolution. After a new evolution starts, the previous evolution still works. For each signer in the new evolution, if it is a signer of the previous evolution, it must maintain its availability to serve signing requests to the previous evolution, otherwise it should be punished.
Any user requests for the throttled secret derivation should include the evolution number to get the correct signature. And in any case of network changes, the user is assured of their key security due to various backups discussed in previous sections.
Incentive and PunishmentThe code doesn't include any incentive or punishment for the entities running the signer node software. It's up to their consensus on their mission, either to serve their customers a better user experience, or charge a small key signing request fee, or they could make some tokens to do community development.
SecurityAll the cryptography libraries used in this repository are being developed and used by industry-leading institutions, notably the
drand project and its league of entropy that includes Cloudflare, EPFL, Kudelski Security, Protocol Labs, Celo, UCL, and UIUC.
The code has been audited by Certik, and the audit report can be found at
https://github.com/MixinNetwork/audits.
ContributionThe project doesn't accept feature requests and welcomes all security improvement contributions. Shall you find any security issues, please email
[email protected] before any public disclosures or pull requests.
The core team highly values the contributions and provides at most a $100K bounty for any vulnerability report according to the severity.
Code and LicenseThe TIP implementation
https://github.com/MixinNetwork/tip is released under Apache 2.0 license.
Appendix B: Mixin Safe Web Wallet
Today on 2023-07-25, I decided to link my mobile wallet with the web wallet.
Things went predictably well enough at first:
OK, so as you can see, the integration had succeeded, and I was able to access the web interface, which looks like this:
Not bad, actually. Good user interface.
So I went to create a multisig Safe that everyone was talking about. Now the only options so far are Mornin Key, Ledger, and Bitcoin Core. As I do not own a Ledger and was unwilling to fiddle around with more apps on the phone, I just chose Bitcoin Core as I happen to have a node running. So after following the instructions in the Bitcoin Core guide:
I was baffled with the last screen, which asked me to pay money in order to create my first Safe. Maybe this was because I already had a wallet on the mobile app or something equivalent. But either way, I had already burned money in order to test the transaction deposit and withdraw feature, so I wasn't willing to send more money to Mixin to create the Safe.
My recommendation is to eliminate the Standard plan and merge it with the Free plan (or "No plan" as it is called on the website), because as it stands, if you don't buy a plan, you cannot create a safe, and network fees of Mixin presumably already go to the Mixin organization (right?) so the $2/
month (apparently it's $2/year according to the quote in the OP - that's even worse from a financial perspective, and I strongly suggest making the prices on a monthly count in order to become profitable) will only generate a tiny amount of revenue for Mixin, and won't pay for much even if 1000 users signed up for the plan. It reminds me of those $0.99 and $1.99/month subscription plans for App Store apps that similarly struggle to pay the developer due to lack of users.
I also recommend Mixin team reads this:
https://www.entrepreneur.com/money-finance/an-entrepreneurs-guide-to-startup-pricing-strategies/428342 and add more features to the higher two paid plans in order to incite users into buying those instead. Locking certain features to the paid plans works tremendously well in this case, as well as extending the premium features to include stuff in the mobile app. Some examples from other companies e.g. Twitter:
- Imposing a message size limit, multimedia size limit, or recent messages limit
- Limiting the number of group chats and contacts you can add
- Restricting the use of certain assets in wallets to paid plans
- Restricting the use of certain multisig software e.g. hardware wallets for creating the Safe to the paid plans
- Allow certain kinds of assets e.g. NFTs to be transferred to the Safe only in paid plans
- Remodel the highest plan to make it suitable for businesses - businesses have huge amounts of money and if you give them phone support, and a suite of features needed by businesses, it can generate you a ton of revenue, as in 5, 6, or even 7 digits monthly if the service gains traction. Also, advertise to businesses directly, as companies are notoriously bad at keeping people's crypto safe from hacks. This will give you some immediate revenue to start with.
- Or even (at the risk of making an unpopular suggestion) making the free plan ad-supported but vet the ads that you display just like Bitcointalk used to do.
A person who genuinely depends on your service - as opposed to the casual user who just wants a look around - will definitely subscribe to one of the paid plans.
So if you develop more products and solutions that utilize Multisig and offer them to this paying class, they will be more likely to buy them.There are probably more ways to make the premium plans more attractive and viable, which I encourage you to explore. But ultimately, being around people who make startups and all that, I just don't find the $2 pricing plan financially viable for you.
(But in the unlikely event that you decide to keep the current pricing [which I do not recommend for the reasons above], you should display the pricing modal in place of the dashboard when the user signs in, not when the user has almost finished creating a Safe.)
Appendix C: Using the safe with Bitcoin Core
(Or, how to shoot yourself in the foot with a BB gun)
2023-07-27, I decided to see what happens when you pay for the plan. As expected, the payment was processed, and there were actually some further instructions involving signing/verifying the safe from Bitcoin Core. Presumably to make sure the whole thing works.
Here I'd like to point out something wrong with the documentation - it assumes that Bitcoin Core
decodescript RPC will return the multisig timelock script as the Segwit descriptor. However, this is not the case for some versions of Core, which return an address descriptor instead.
In the case where there is only one user added to the Safe, there's going to be the 2-of-3 multisig which looks like this:
wsh(thresh(2,pk(AAAA),s:pk(BBBB),sj:and_v(v:pk(CCCC),n:older(DDDD))))
The ASM output is always correct though. In my case, it's:
"asm": "02ec372c4b6d6a6fc0964e07dd48448bc84921469fbfdc4c522da90f3a6b954fe9 OP_CHECKSIG OP_SWAP 03d64177a393989c5ff9c8603df421e2890d03913f1e1e5e7948b63f7e136a57d1 OP_CHECKSIG OP_ADD OP_SWAP OP_SIZE OP_0NOTEQUAL OP_IF 02d84f36931c6138f1825a49c29f5c4d9af9524ca795e133b8cfc65a01acd77c9a OP_CHECKSIGVERIFY 432 OP_CHECKSEQUENCEVERIFY OP_0NOTEQUAL OP_ENDIF OP_ADD 2 OP_EQUAL"
The placeholders are:
AAAA is the first key (in my case, 02ec372c4b6d6a6fc0964e07dd48448bc84921469fbfdc4c522da90f3a6b954fe9)
BBBB is the second key (03d64177a393989c5ff9c8603df421e2890d03913f1e1e5e7948b63f7e136a57d1)
CCCC is the third key (02d84f36931c6138f1825a49c29f5c4d9af9524ca795e133b8cfc65a01acd77c9a)
DDDD is where you put the timelock value (432)
Once you've done that, you should pass the descriptor as input to
bitcoin-cli getdescriptorinfo to get the full descriptor with checksum.
Hopefully this will help someone make the safe even if Bitcoin Core changes the output format. Then you can follow the rest of the steps as according to the guide.
When the Safe is created, you can make a deposit or a transaction. Depositing the transaction is very simple, but you have to deposit at least 0.0001
BTC. Making a transaction is, as expected, much more involved, and any of the Safe members or the Owner (the person who owns the other wallet, be it Bitcoin Core, Ledger or something else) can approve or reject the transcaction. The owner must always approve the transaction.
When I had my only member account of the safe approve the transaction, it asked me to scan a QR code because these things must be approved via the mobile app by typing a PIN. The Owner, on the other hand, must make a partially signed order to make the final approval
If only.
For some reason, I have my private key, and the script wallet, and the PSBT decoded shows the correct set of keys, but the PSBT is not signing at all!
So,
do not create safes with Bitcoin Core until the devs make the instructions fool-proof, or you could lose your coins.