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 multisig, 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?
lunaticoin (npub1yn3…mzt0) ODELL (npub1qny…95gx) jack (npub1sg6…f63m) NVK (npub1az9…m8y8) Leo Wandersleb (npub1gm7…8rf6) multicripto (npub12aq…dvgy)
thebitcoinhole / The Bitcoin Hole
npub1mtd…qxas
2024-04-25 17:28:40
Author Public Key
npub1mtd7s63xd85ykv09p7y8wvg754jpsfpplxknh5xr0pu938zf86fqygqxasPublished at
2024-04-25 17:28:40Event JSON
{
"id": "8239abbf6d92958982a32428d1378fb67b8c5d26413ad8e97de3ddf1fc22240d",
"pubkey": "dadbe86a2669e84b31e50f8877311ea564182421f9ad3bd0c37878589c493e92",
"created_at": 1714058920,
"kind": 1,
"tags": [
[
"p",
"24e37c1e5b0c8ba8dde2754bcffc63b5b299f8064f8fb928bcf315b9c4965f3b",
"",
"mention"
],
[
"p",
"04c915daefee38317fa734444acee390a8269fe5810b2241e5e6dd343dfbecc9",
"",
"mention"
],
[
"p",
"82341f882b6eabcd2ba7f1ef90aad961cf074af15b9ef44a09f9d2a8fbfbe6a2",
"",
"mention"
],
[
"p",
"e88a691e98d9987c964521dff60025f60700378a4879180dcbbb4a5027850411",
"",
"mention"
],
[
"p",
"46fcbe3065eaf1ae7811465924e48923363ff3f526bd6f73d7c184b16bd8ce4d",
"",
"mention"
],
[
"p",
"574099a17051b0f13e75f7c8933e2138477156c0c67ea2ef964388dcf3abeb80",
"",
"mention"
]
],
"content": "I would like to hear the opinion of the Bitcoin community.\n\nWhile 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:\n\nAn 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 multisig, 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.\n\nI define something as \"non-custodial\" or \"self-custodial\" when these two conditions are met:\n1- The provider can't move the funds without owner's permission.\n2- The owner can access its funds without the provider's permission.\n\nIn 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\".\n\nSome questions I have in my mind:\n- Is my conclusion correct?\n- Is there any difference between \"non-custodial\" or \"self-custodial\"?\n- 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?\n\n nostr:npub1yn3hc8jmpj963h0zw49ullrrkkefn7qxf78mj29u7v2mn3yktuasx3mzt0 nostr:npub1qny3tkh0acurzla8x3zy4nhrjz5zd8l9sy9jys09umwng00manysew95gx nostr:npub1sg6plzptd64u62a878hep2kev88swjh3tw00gjsfl8f237lmu63q0uf63m nostr:npub1az9xj85cmxv8e9j9y80lvqp97crsqdu2fpu3srwthd99qfu9qsgstam8y8 nostr:npub1gm7tuvr9atc6u7q3gevjfeyfyvmrlul4y67k7u7hcxztz67ceexs078rf6 nostr:npub12aqfngts2xc0z0n47lyfx03p8prhz4kqcel29mukgwydeuatawqqg5dvgy",
"sig": "7b1fa3eadfbf43464a5d51bd6f151c38971d28bea68ae793a65d985d5377f75abe4f2c4771000cfc2a901247103d769eb457bb9eedb70b2cf4a1c9bd4af40cd9"
}