You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here is an idea for a project for anyone(s) motivated by it. I'm not aware of any published guidelines for entities ranging from governments to companies to non-profit entities to handle self custody procedures. How many people should hold keys, who should hold them, how should they hold them, and how should key transfer happen when people leave or there is a transition of power? For example, let's say a country like El Salvador has a bitcoin reserve, and instead of relying on a US-based company to custody their bitcoin (which is much like a country storing their gold in NYC), instead they want to be self-sovereign and custody themselves. Not only do they care about being safe and secure, but they also need to answer the questions above, who holds the keys. And when a new person is elected president, how does that key transfer occur, handling both peaceful and non-peaceful transfer of power?
Or, even a simpler case, such as a small non-profit like Bitcoin Development Kit Foundation or ₿trust, how should they handle this?
Right now, I believe every organization has to roll their own solution. This is intimidating and a barrier to doing self custody. I suspect many opt for custodial due to this. And for those that self custody, most probably have an inferior solution than if they adopted a well-thought-out Bitcoin Design Guide guidelines.
There is already some discussion happening. I'm creating this issue so the idea does not get lost.
I still think it's a good project for the next designathon (but it does not have to be, anyone interested can just hop on this if they are excited about the topic).
The text was updated successfully, but these errors were encountered:
This request by @moneyball came up in Discord here.
There is already some discussion happening. I'm creating this issue so the idea does not get lost.
I still think it's a good project for the next designathon (but it does not have to be, anyone interested can just hop on this if they are excited about the topic).
The text was updated successfully, but these errors were encountered: