pull down to refresh
10 sats \ 0 replies \ @_arshbot OP 10h \ parent \ on: DM ME if you're potentially affected by covenants bitcoin
We're talking about a potential upgrade for Bitcoin that works by fundamentally narrowing the functionality of a utxo.
Here's a great explainer site: https://covenants.info/
10 sats \ 0 replies \ @_arshbot OP 24 May \ parent \ on: How to Build the Ultimate Bandaid Wallet bitcoin
hey thanks for the reply. largely agree with all your points, however the trust assumptions on the infra provider mean that while you may hold keys, it doesn't mean you have unilateral control, which is something we value.
electrum spv, i think isn't the best example though there are others because there are many you can rely on, and you can rely on many at once (reducing the likelihood of being successfully sybil'd).
but pretty much safe enough in most circumstances even when dealing with big transfers worth millions of dollars.
I disagree, the main intention of these systems has always been to be a form of "free, ungovernable money". The introduction of all these centralized points allow for coercion by nation-states.
If that million dollar transfer is one that a nation-state, or even the centralized entity dislikes for whatever reason (say it represents a sizable gambling win from a subsidiary owned by the same parent), they have unilateral control on the transfer.
Such is the weakness of the compromise of these wallets designs.
Yep, so this is actually a well understood concern across all of crypto - we just haven't been exposed to it because bitcoin doesn't allow for these usecases.
Other crypto projects attempt to solve this problem by incentivizing many nodes to care for data over time with direct payments from tx fees. There are many other solutions, but this is just one.
Taproot Assets don't have an explicit solution baked in. The above could be a solution, enforceable by the Universe rules (all universe asset spends spend a bit into a treasury address).
But to be honest, if you want functionality in bitcoin beyond the simple send/receiving of bitcoin, you will be reliant on out-of-band data that isn't stored explicitly in the blockchain.
Even explicitly stored data like ordinals, runes, etc require specialized wallets to decode the info.
Taproot also works like this, with bitcoind implementing descriptor wallets backups that are far more complex than just the seed.
With USDT, it seems like Tether will run its own universe that will back up this data, but what's to prevent them from losing it?
Just to be clear, nothing. There are more decentralized stablecoins out there but none more utilized than tether.
Personally, I'm not sure if I'd be comfortable holding a significant quantity of Taproot Assets under this arrangement
To be clear, Tether is only utilizing the taproot assets technology. They are wholly separated. Tether also holds this functionality across all implementations of USDT
You would not be considered a money transmitter by running your own node. However, if you were to acquire investment in the millions to build a crypto business (which is the foundation of our bitcoin economy), you'd need to make sure you're good with the local law.
Or else your investors might be quite upset.
You're reading the room correctly. Folks who think the Biden/Harris administration is unfriendly to crypto are frankly incorrect. They've signaled nothing but acceptance - so long as crypto lives in an institutional landscape with high barriers to entry.
There are pros and cons to that, but the signals they've put out are "we welcome the old players to the crypto game."
However, it's pretty clear these regulatory tools are being utilized as favors. BNY Melon being granted an explicit approval by Biden is interesting in context when you realize the same admin recently veto'd a resolution to overturn SAB-121.
Basically, the White House quite literally said keep the moat but let this guy through.
I didn't really talk about what the status quo is (though I heavily implied it multiple times). It's just a really complicated subject, and I didn't want this article to detract from BitGo while maintaining it's simplicity.
Is that a topic y'all would find useful?
Posting here for more exposure. Really thinking through consensus in bitcoin and trying to understand miner incentives. If you're affiliate with a miner operation, please dm me, I'd love to chat.
I don't live on nostr at all, and am pretty out of the loop, but I found this article helpful in understanding the problem remote signers are trying to solve
Generally the idea of broadcasting events containing secret material through multiple relays is an antipattern. You want to minimize metadata around secret events, since metadata is by definition a degradation of privacy. This is also one of the problems with NIP-04 (encrypted DMs).
I have a few problems with this paragraph
- privacy and censorship resistance (decentralization) do not go hand in hand. It's hard to solve for both and hardly ever equally, and never while insuring future flexibility.
- This (above paragraph) sounds like a win for decentralization needs, but at a marginal cost to privacy because of the interaction footprint. The alternative is for direct peer to peer sending, which would require an entirely new architecture or pathway in the current nostr-server design. Not impossible, just not easily feasible.
putting encrypted nsecs on 3rd party servers? There has to be a less risky, more sovereign design here right?
Idea seems to be sovereign designs to me, the few options I found were self-hosted first and "here demo my software" second. The only solution to the problem of ensuring nsec sensitivity for privacy absolutists is run your own code on your own device. These open source projects seem to offer that.
I did not end my LN node with the same coins I started the node...
You seem a bit confused. This is not how the lightning network works. Please assume all onchain utxo history you have are tracked or trackable.
If there isn't someone (like Chainanlysis) actively tracking your utxo history, there is nothing stopping them from viewing those footprints years from now.
however it stores all funds on-chain and not on-lightning for a user. So every incoming payment is a splice-out
This doesn't make the most sense. Splice-out/ins (and I think you're referring to splice-in for incoming payment?) only apply to funds held in a lightning channel. All funds in lightning channels are anchored onchain, which is how splice works.
Do you mean to say all onchain movements in Muun are performed with splice in/out's?
464 sats \ 1 reply \ @_arshbot OP 9 Jan 2024 \ parent \ on: How to Build the Ultimate Bandaid Wallet bitcoin
I really despise this made up term "bandaid" wallet to describe Mutiny and others. I really don't know in what way you define this.
I'm sorry I've offended you, but I'm comparing between bitcoin wallets and lightning wallets. In order to get a similar experience to bitcoin, our lightning wallets have to make a lot of concessions. Concessions in privacy, concessions in fees to service providers (block explorers don't charge this).
Describing Mutiny, Phoenix, Muun as bandaid experiences isn't a dig at y'all. You guys have made very useful, very clever solutions to the challenges in front of you. But those solutions are fundament bandaids of the limitations of the baselayer.
I'm in the middle of building what I describe as a bandaid wallet myself. We, implementors are bridging gaps that shouldn't exist in my opinion. All of lightning exists as a way to bridge the gap of restricting blocksize as usage increases while still allowing for day-to-day transactions. It's a dig at a lack of supporting features at the base layer, not a dig at your (or my) work.
People want Bitcoin to grow, without scaling Bitcoin in any way. Now, the onus of support is left to us to make and make use of bandaids.
You're also defining it as infrastructure you can't host, however the entire mutiny stack is self hostable and we have multiple users that go that route on their start9
Sure, in those cases it's not what I'd call a bandaid wallet, but what I'd call a self-hosted wallet. Which does not have ease of use or easy onboarding as an attribute.
Splicing is not a "bandaid" only feature
I concede
having onchain vs LN accounting is not self hosted only
I address this above. "There isn’t an explicit reason why self hosted wallets lack unified accounting, though without the help of LSPs, the fees are higher. So let’s talk about the real elephant in the room with bandaid wallets." If I had to guess, if you're going to go to the trouble of going self-hosted, you might as well optimize on fees. Bandaid wallets don't aim to optimize on fees, they aim to profit off them (nothing wrong with this!)
(not sure why you think receiving on chain to a "bandaid" wallet takes a fee as well, unless you're talking about one specific wallet which I think Phoenix might).
If the bandaid wallet supports unified accounting (yours does not), then they likely use swap-ins which have a mining fee + provider, with one notable exception.
This is false.
Please elaborate!
Async payments don't exist anywhere yet..? Are you describing something else that's specific to a single wallet implemention (Zeus)? Because that's not async payments, that's hodl invoices.
I'm describing async payments to be implemented by LDK