pull down to refresh

I'm interested to know if there are known solutions, even if just theoretical, to enable people to have highly secure self-custodial Bitcoin, without main chain transactions for each person. If so, are there any technologies implemented or in the works that will achieve this? If they are not implemented yet, what needs to happen to get something to that state. Will there always be security reduction for off-chain technologies?
People tout Liquid. It is a very useful tool, but it is a massive security tradeoff.
Far as I can tell, Lightning can't easily be self-custodial yet. Can it be in the future? / what does it need to get there?
Fedimints will help provide trust-minimized custodial system, a massive security trade off.
I've seen other tools mentioned, but I'm not sure of their relation to this particular question: Ark, Ecash, Mercury, etc.
Maybe actually trustless sidechains that piggy back on Bitcoin's security are possible?
Obviously, there's probably lots of controversy related to this, but I would love to read people's thoughts
The only way I know of that will let you do this is with virtual utxos, which means locking up an on-chain utxo and promising parts of this utxo to many people.
Ark has a solution that accomplishes this, but the ugly path is too ugly without covenants.
Covenants in general would sort of accomplish this, if you could enforce a user to spend with a particular change output. Then you could have users swap vtxos around on a layer 2, and if things get ugly, the covenant restricts everyone to exit with only their share of the utxo.
Any side chain solution is an implicit block size increase, as the total network must store more data in order to validate your holdings.
Also, lightning is not limited to HTLC payments. There may be other channel configurations worth exploring.
reply
deleted by author
reply
Lightning can't easily be self-custodial yet.
Wrong. Totally wrong. Please read my guides.
reply
10 sats \ 0 replies \ @hynek 16 Feb
Lightning doesn’t scale in terms of user count. It’s necessary for regular payments, but as of now there can’t be more than 20mil self-custody users. (Assuming 1 transaction per month)
reply
I'll check it out. But I'm curious, with Bitcoin, you can securely save your seed, then forget about it. Can you do that with lightning?
reply
onchain = only for long term holding and opening/closing channels Lightning = only for spending, short term, small amounts.
I will repeat this over and over: use the 3 levels stash - hold (onchain vaults), cache (coin control), spending (LN)
Please read all these guides:
reply
Your guides are very good
reply
I appreciate that. For me, you are preaching to the choir. But, I can't sell this idea to easily normies.
Maybe tech can be developed to make this easier, but for now I don't think it's there.
Maybe someone could then say that maybe Bitcoin is not for such a person who can't embrace these ideas. I'm open to that, but then it's a reality to accept about Bitcoin.
But, even with that, say that I'm in Africa and I want to help someone very poor hodl Bitcoin and BTC fees go to the moon. Can I really be helpful advising them to get a very small utxo that may never be able to be spent in the future?
Is there no solution possible for that person?
One of the most interesting topics to learn. Thank you
reply
665 sats \ 5 replies \ @hynek 16 Feb
I'm trying to research this as well. These concepts are hard to understand.. but here is my current list:
reply
147 sats \ 2 replies \ @Murch 16 Feb
I don't think Utreexo fits into this list. It's an approach to enable a new type of light clients, but the transactions are still on-chain
reply
Is there a good source to get understanding of these solutions? Mainly Ark vs RGB-Prime vs Mercury vs e-cash (fedimint...) vs liquid vs lightning
I think starter for @hynek would be to get a table
  • date proposed
  • activity (number of participants, changes per month)
  • state of current project/UX (idea, definition doc, prototype, alpha, beta, smooth user mobile experience)
  • needs a soft fork? (And which one - covenants?)
  • who is sponsoring it? How much?
  • how many transactions does it require onchain (1 per 3 transactions, unlimited...)
  • what is used for extra data store (op_return...)
  • how many actors are needed to make transaction (e.g. N/2 or just 3...)
  • how many actors can block you from transacting
  • how many actors are needed to steal funds (e.g. 15)
  • how heavy is the client (e.g. 2GB per year)
  • requires being online?
  • requires interactivity from multiple actors?
  • key concept/architecture ("P2P with clients storing state", "low n of validators"...)
deleted by author
reply
UTXO... I thought it is UFO 🛸 😂
reply
Far as I can tell, Lightning can't easily be self-custodial yet.
Phoenix Wallet is easy.
reply
Phoenix is almost there. You don't have access to your channel states though, so they could technically one day kick you off and broadcast an old state to steal funds
They wouldn't, but it is something that's technically possible
reply
Use an opendime/satscard or similar device. You can have true self custody and transactions (passing the device physically from one person to another) happens completely off chain. There’s no telling how many times a utxo has changed hands once you factor in transfers of this nature.
reply
If there were ~100M people in the world instead of ~10B, on chain + lightning would be enough for a global savings and payment system.
On the plus side, we have decades to scale only another 100x, since the population is not going anywhere fast.
reply
Fedimints will help provide trust-minimized custodial system, a massive security trade off.
To be fair to Fedimint technology, the creators are very explicit. The goal is not to match Bitcoin's security, but to utilize the unit values of Bitcoin and provide a custodial layer for those who cannot / choose not to use the main chain HODL methods.
reply
Self-custodial means inside the main chain. Lightning uses actual Bitcoin UTXOs and is currently the ONLY layer that does this in a way where the user can enforce the rules and doesnt need to trust if they do. Everything else is mostly bullshit, trusted stuff.
reply
reply
Bit Risky but not self-custody
  1. LIGHTNING SATs (LAYER 2)
  2. MSTR Shares
  3. BITCOIN ETFs
reply
Aren't WBTCs (Wrapped Bitcoin) off chain solution for self custodial Bitcoin?
reply
WBTC is worse than L-BTC on Liquid Network.
reply
Except that they're an IOU issued by BitGo who takes the role of custodying the BTC to issue WBTC in return
reply
0 sats \ 0 replies \ @ama 16 Feb
WBTC could be wrapped on many different chains, right? Isn't that probably the absolute worse way to own Bitcoin if, for example, you get them wrapped on the horrendous ETH network or SOL, or any other similar PoS (Piece of Shit)?
reply
When you say self-custodial bitcoin outside of the main chain, I think of Zeus, Mutiny, Blixt, etc. Would love to hear others’ opinions on these.
reply
Do note that a force close on Mutiny might lead to your UTXO being swept to the LSP if you're not online enough. Or at least that could have been the case in the past. Not sure if this also applies to Zeus, but be careful describing their embedded nodes as self-custodial LN channels.
reply
RGB Protocol and Taro Protocol are ways to enhance self-custody within the Bitcoin ecosystem. RGB takes a unique approach, building a smart contract system on top of the Lightning Network. This enables you to create and transfer various assets via Lightning channels without sacrificing full ownership control. Your wallet software enforces ownership rules locally, preventing fraud even though Lightning nodes facilitate the actual movement of assets. Taro, on the other hand, leverages the Taproot upgrade to "commit" assets onto the Bitcoin blockchain. Through advanced scripting techniques, assets become governed by rules you define, ensuring no one but you can authorize movements. Both protocols promote self-custody by minimizing reliance on trusted third parties.
reply
This has nothing to do with self custodial bitcoin.
reply
This is a really important topic. When the world hyperbitcoinizes the onchain fees will raise a lot. The onchain fee for opening a lightning channel would be crushing for poor people. We need a solution for them to self custody anyways.
reply
In my opinion Ark like solutions are the most promising for scaling self custodial bitcoin. This video gives a good technical explanation of ark.
I see ark as promising for self-custody but less promising for use in payments.
reply
25 sats \ 5 replies \ @Murch 16 Feb
A mechanism that requires you to bump your VTXO every few weeks lest you lose them to the ASP feels a bit awkward for the most promising approach for self-custody
reply
Yes, the default parameters that have been announced wouldn't work well for self custody. When I say Ark, I really mean the concept of what Ark does. I imagine that the block height lock for the ASP to reclaim could be changed to a much longer time for a transaction tree that wants long term self custody. This could be offset by the ASP by requiring higher fees if a participant in the tree wants to leave earlier. (Disclaimer, I am not an expert)
reply
25 sats \ 3 replies \ @Murch 17 Feb
Isn't the lock time though synonymous with the amount of time that the ASP has to lock up their own funds in parallel for the unilateral exit from the Ark? I.e. longer locking would mean that the ASP has to have way more capital
reply
The ASP needs extra funds starting from the redemption of a VTXO till when the ASP is able to sweep the UTXO. The ASP could charge a VTXO redemption fee equal to VTXO amount * some ASP decided interest rate * time till ASP has ability to sweep UTXO.
Basically users of the ASP would have to pay interest on the capital that the ASP has to lock up because of the user.
reply
25 sats \ 1 reply \ @Murch 17 Feb
So holding in an ASP would incur a fee relative to the amount held there, slowly bleeding away your holdings. That seems at adds with wanting to hold a lot of funds for a long period.
reply
Though the fee is also relative to how long the ASP has to provide captial for your VTXO.
For example, if the ASP provided an ARK with a 1 year sweep time, a user planning to self custody their funds for at least a year would join the tree, wait till maybe two weeks till ASP can sweep, then redeem to a new tree. This way they would only pay interest for 2 weeks of time.
Its important to note that all the users participating in these ARKs would be doing so because they believe the net fees they would have to pay to be in the ARK would still be cheaper than standard self-custody through an onchain transaction fee. This would likely only be true for small-medium amounts so its unlikely any very large amounts would ever participate in these ARKs.
reply
You are asking if you can have highly secure self custody of off-chain Bitcoin. The answer is no. NYKNYC.
reply
Can you own gold without owning gold? Not sarcasm; think about all the ways people "own" things.
There are some unique properties to Bitcoin which allows for clever things like Lightning, but every scaling layer will either introduce trust or complexity or both, and reduce security (more code, more attack vectors and more potential bugs).
For everyone to own, really own, Bitcoin would require a different consensus mechanism, which would degrade the security or increase the trust required. Scaling the base layer. It's a trade-off most other cryptocurrencies make.
Follow-up If I had been clearer to my point, I would express that I mean with Bitcoin if you securely store your seed or private address, you can never look at it again and provided all goes well with the network, your funds will always be there, without having to trust anyone except the Bitcoin network itself.
Can this be done with Bitcoin on another 'layer' or any kind of known mechanism, real or theoretically?
In other words, can a HODL solution exist using Bitcoin, that does not directly use the main chain?
Far as I can tell, all current solutions seem to involve a security trade-off / additional trust and continuous maintenance.
0 sats \ 0 replies \ @sdf 16 Feb
deleted by author
reply