pull down to refresh
1571 sats \ 0 replies \ @lightcoin 6 Dec 2024 \ on: A Bitcoin Family Trust; Self-Custody Multisig bitcoin
I recommend reading some of Pamela Morgan's posts about bitcoin inheritance:
https://medium.com/@pamelawjd
What you are describing sounds to me a bit like a "family office" fund that happens to be invested in BTC, and you are looking for a relatively decentralized way for the family to manage custody of the BTC held in the fund. This might be an easily understandable way to introduce the idea to a lawyer if you seek council about this (and I recommend that you do -- I am not a lawyer).
Regarding wallet options, you could check out Nunchuk which is one of the easier-to-use multisig wallets and it is open-source which is nice from an auditability perspective. Electrum, Sparrow, and Specter are all good options as well but a bit more advanced usability-wise. Check them out and you can decide for yourself what is best for your situation. See also https://btcguide.github.io/ for general multisig tips.
HRF was founded to specifically focus on dictatorships and other autocratic regimes, to speak out for the people under those regimes who are often heavily penalized for dissent. There are many other organizations in "democratic" countries who hold their governments accountable.
I assume its overall throughput is comparable to that of Liquid.
While it really depends on the hardware that the fedimint is running on, all else being equal I would consider the throughput of a fedimint to be higher than Liquid. There are no blocks in the fedimint context, transactions can confirm ~ instantly, and they can be confirmed as fast as the mint's hardware is able to swap notes with transaction recipients, which I imagine can be very fast. So fedimints are faster to sync your wallet balance (because no blocks to download) and they can do transactions at the speed of bare metal computing (extremely fast) overall should result in a theoretically higher throughput than Liquid.
So in total it seems to me like Fedimint is currently the superior of the two technologies due to its superior privacy and comparable characteristics in other areas. Do you agree with this conclusion? Or are there any other important things, that I am missing?
Liquid uses the strong federations model, claiming to use tamper-proof HSMs to protect the private keys that secure the federated multisig bridge. It is unlikely that your average mint operator will implement such high security measures, if only due to the high technical and cost barrier to doing so. So that is something to consider. I also agree with k00b that auditability is an important consideration.
I think it is a negative, if only because it suggests that "the market" has decided bitcoin isn't private enough for mission-critical transactions. If we want bitcoin to be the best electronic cash, it should have sufficiently strong privacy that the market does not near-universally consider an alternative as superior on that dimension.
I doubt ecash is a solution, because if any mint were to attract DNMs as users the mint operator would most likely be shut down.
Lightning is also far from being private enough to serve as an effective replacement for Monero. It might be too strong to say LN will "never" be as private but it does seem to me like there are fundamental technical challenges that would prevent LN from being as private.
I think the best solution would be to improve base layer privacy of bitcoin, leap-frog Monero's (now outdated) privacy tech and go straight for zk-SNARK-based private transactions a la Zerocash. Or we could enable validity proof verification on bitcoin, then developers can experiment with privacy protocols on L2 and the market will pick the one that works the best.
However, privacy shouldn't be a bolt on addition for a settlement layer.
What meaningful differences do you think there are between having a privacy app like Railgun vs making privacy a "native" feature at the consensus layer of the chain?
a UTXO model also counters most practical quantum attacks too
This weakness of the account model can be mitigated by using a PQ signature algorithm in the L2. PQ signatures tend to be relatively large in size but with a ZKP L2 we can aggregate these signatures into a single PQ ZKP (e.g. STARK) so that the L1 footprint is no larger than it otherwise would be.
I am curious, are you an author from Alpen?
I work for Alpen but was not an author on this paper.
Good comments, thanks for the feedback!
I imagine we'd weight it accordingly using something similar to the witness discount (but more like a "witness premium"), or using GSR-style varops budgeting.
enough to continue scaling self-custodial BTC hodling and spending to as many people as possible, with as much freedom for spending conditions as possible, while preserving decentralization.
account-based blockchain is a primitive design and is inferior to a UTXO-based blockchain.
there are tradeoffs involved with account based chains vs utxo chains. one isn't necessarily better than the other. which is better depends on the use case at hand (and for some use cases, either would work just fine)
it encourages bad practices like address reuse
there are privacy solutions like firn, railgun, and umbra that mitigate or negate the harms of address reuse.
and creates unbalanced transaction loads, making scaling either harder or impossible
there are already account based chains with parallel transaction processing. though even with sequential processing, chains are getting to pretty large scale already. anyways, at a certain point, it makes more sense to shard execution rather than keep scaling the same execution environment if the goal is preserving decentralization. all that said, since a bitcoin rollup would be limited in scale by bitcoin's data availability capacity, scaling isn't even the main concern here.
what happens when we go past 2^40 accounts? will collisions occur?
no, past the limit you just can't create any more accounts.
shitcoiners
who are you referring to here?
should have at least the decency to build on top of existing opcodes
it's not possible with existing opcodes
Introduction blog post: https://www.alpenlabs.io/blog/proof-of-work
Bridges/sidechains may not be the only applications to benefit from a permissionless challenger protocol. Since this change can be utilized by any BitVM application I think it is worth the version bump.
The thread does say that if the payment is to a CASP then the sender will need to KYC, which suggests to me that if the merchant is using a custodial point of sale system hosted by a third party (like BitPay) then all customers will need to KYC.
https://twitter.com/paddi_hansen/status/1771929875894399367