Scenario between "custodial" and "non-custodial"? \ stacker news ~bitcoin

Scenario between "custodial" and "non-custodial"?

518 sats \ 8 comments \ @thebitcoinhole 25 Apr bitcoin

I would like to hear the opinion of the Bitcoin community.

While I was researching different assisted wallets for The Bitcoin Hole, I came across a case that I'm not sure how to categorize. Here's the scenario:

An assisted wallet, where the owner and the service provider need both to sign a transaction to move the funds. You can think this a 2-of-2 multi-sig, where the service provider has one key and the owner the other. However you can also implement this with MPC (Multi-Party Computation). The implementation is not the issue.

I define something as "non-custodial" or "self-custodial" when these two conditions are met: 1- The provider can't move the funds without owner's permission. 2- The owner can access its funds without the provider's permission.

In the previous case, condition 1 is satisfied, but condition 2 is not. So, my conclusion is that this assisted wallet can't be categorized as "non-custodial" or "self-custodial".

Some questions I have in my mind:

Is my conclusion correct?
Is there any difference between "non-custodial" or "self-custodial"?
Since the assisted wallet in this case cannot be considered "custodial" (as the provider cannot move the funds without the owner's permission), how should it be categorized?

I also opened this discussion in other networks:

view all related items

100 sats \ 3 replies \ @DarthCoin 25 Apr

You have also another scenarios:

Greenlight - user have the keys on his device, but the LN node and funds are on a remote custodial server. The service provider cannot touch the funds, but still the user, if the service provider close the access to the server, will not be able to recover the funds.
Breez - user have the keys to the funds, and run the node in the device, but if the central node of Breez shuts down, is not so easy to recover the funds.
Mutiny - user have the keys on his device, but many users still use the default domain app (mutinywallet.com). Service provider manage the node infrastructure, but user still have full control of the keys. but if that domain get busted user can't recover his funds.
LNBits - service provider offer lndhub accounts and have full control of the funds. The user have only a simple key to access that account, no option to recover them in any way.
Hosted channels - user have the keys to his funds but service provider still can close the access to the funds.

I will name "self-custodial" a wallet that the user:

have full control over the keys
have full control of the app hosting (his own server or mobile device)
have option to recover his funds easily into another wallet
can control all the access to his funds and manage it by himself

All the rest that do not comply these aspects will be in the custody of somebody else. You, the user are just their slave.

See more here: https://darth-coin.github.io/wallets/lightning-wallets-comparison-en.html

0 sats \ 2 replies \ @thebitcoinhole OP 25 Apr

Yes, I know that if you include Lightning you have multiple possible scenarios. I am particularly talking about onchain, I forgot to clarify that.

0 sats \ 1 reply \ @DarthCoin 25 Apr

LOL but who in the right mind will use nowadays a custodial only onchain wallet? That is stupid.

Onchain should be always only self-custodial. PERIOD. Because onchain are ONLY for holding, long term, cold wallets. PERIOD.

0 sats \ 0 replies \ @thebitcoinhole OP 25 Apr

You would categorize as "custodial" the scenario I presented? Where condition 1 is satisfied, but condition 2 is not.

10 sats \ 0 replies \ @Coinsreporter 25 Apr

Self custodial necessarily mean that you are the only one who holds your private keys bit non custodial may sometime mean that you don't hold your keys.

They are defined in this way.

0 sats \ 2 replies \ @Radentor 25 Apr

So, my conclusion is that this assisted wallet can't be categorized as "non-custodial" or "self-custodial".

I agree with this

Is there any difference between "non-custodial" or "self-custodial"?

Non-custodial : only 1 signature is needed to spend Custodial : someone else can spend at will but hopefully they don't

Since the assisted wallet in this case cannot be considered "custodial" (as the provider cannot move the funds without the owner's permission), how should it be categorized?

My suggestion would be to actually call a wallet as specific as possible based on it's spending requirement. For Onchain :

Cosign n-of-n
Cosign m-of-n
Multisig
Singlesig

LN :

Custodial
Cloud
Singlesig

Liquid :

Cosign n-of-n
Singlesig

Fedimint : Federated Cashu : Custodial I made a complete (hopefully also correct) list of wallets with varying degree of custodianship here

0 sats \ 1 reply \ @thebitcoinhole OP 25 Apr

I am particularly talking about onchain, I forgot to clarify that.

Your onchain classification sounds more the implementation, I am looking for the concept.

10 sats \ 0 replies \ @Radentor 25 Apr

Degree	Type	Possible Spender	Authorizer
⛓️🖇️	Cosign n-of-n	User + Server	All
⛓️📎	Cosign m-of-n	User or User + Server	User or Both
⛓️🗝️	Multi Sig	User	User
⛓️🔑	Single Sig	User	User
⚡🔓	Custodial	Custodian & User	Custodian
⚡☁️	Cloud	Server Host & User	Cloud Server
⚡🔑	Single Sig	User	User
💧🖇️	Cosign n-of-n	User + Server	All
💧🔑	Single Sig	User	User
🌿🔒	Federated	LGP & User	LGP
🥜🔓	Custodial	Mint & User	Mint

Variant	Who Can Spend the Underlying Collateral ?
⚡	User + Channel Counterparty 2-of-2 🗝️ (Splicing)
⚡	User or Channel Counterparty 🔑 (Channel close)
💧	11-of-15 Liquid Federation Member
🥜	The Mint
🌿	The Lightning Gateway Provider
🪐	User, After The Timelock Expired
🚢	A : User (after 24h) or User + ASP or ASP (after 4w)
🚢	B : User (after 365d) or User + ASP

What you're looking for is what i referred as "cosign n-of-n" (or just call it collaborative assisted wallet)