pull down to refresh
5 sats \ 0 replies \ @bluematt OP 2 Jul \ parent \ on: No, the new Wallet of Satoshi is not "self-custodial" bitcoin
I wouldn't call Spark "shared custody", but the Spark operator is well-known - its Lightspark, they're not trying to hide that. Also, Lightspark's regulated money transmission business is separate from the Spark product, even though its from the same company.
They just announced a new change to the wallet that they're calling "self-custodial" (upgrading from the existing, fully custodial, wallet). The new one is really not "self-custodial", though its also better than a classic, fully custodial, wallet.
I woulnd't say it "becomes custodial" at some threshold (somewhat the opposite, it becomes less custodial after you have enough money to afford the fees), but I would say that every wallet under something like 5k sats is custodial - if you can't afford the fees to punish a counterparty for cheating in an L2, its not custodial.
Spark/the new WoS integration, is not really self-custodial at any threshold, but its also not custodial in the traditional sense (at least if you have enough money to exit).
Its much better than other custodial systems in terms of trust model, but, yea, don't put all that much more in it than you would any other custodial wallet. Of course if you put too little in it its very much not non-custodial cause you can't unilaterally exit/force close without a fairly high fee.
Yep, super simple and straightforward! Its mostly in response to the Samurai and Tornadocash cases, which charged exactly this (and drove Phoenix out of the US in response), fixing exactly the law they were charged with.
There's the Blanche Memo and favorable case law in the hopper.
The Blanche Memo can and will be reversed by the next administration. There is no case law here.
I'm not gonna bother engaging on the Block nonsense, if you think Block is evil, great, go read Coincenter's view on this, Bitcoin Policy Institute's view, CCI, or literally any other lawyer's take on this stuff.
Self-custodial wallets with decent UX require other tech - on-chain Bitcoin for regular transactions is unusably horrible. If you want Ark, Spark, Lightning, Rollups, or literally any of the things that make Bitcoin usable, you need someone (or many someones) to run nodes, sequencers, or many other things. Ensuring those things aren't made illegal in the US is important, no matter how much we pretend it isn't. If only so that developers can build them in the US, and people can run them outside the US later.
The new California bill, that can seize your bitcoin after it has been idle for 3 years and with no login, etc., gives enough alarm bells for me. Those rules will only be loosened in favor of the state, I assume.
This is inaccurate. The California bill actually ensures that the state wont sell your coins if you haven't logged into your custodial account in three years.
Except that (a) it works, and (b) if you want any devs building actual Bitcoin tech over the next few years, the law's gotta allow for that. No one is gonna risk going to jail to bring you free, open-source Bitcoin software, no matter how much you scream that they should.
What? So you think that we should remove regulations on Cash App and Coinbase (custodial wallets) and this is so important that we shouldn't try to get the (actually maybe achievable) outcome of making non-custodial wallets less regulated, and that somehow this is good for Block (the company behind Cash App, that generally drowns in regulations)? Enabling people to better build non-custodial wallets that outcompete Block's products is...good for Block? Okay man.
I hope we never expose users to the idea of options for LSPs and plans in the onboarding flow (maybe somewhere in the settings in an advanced panel or something) - onboarding has to look like "write down your seedword -> here's your invoice, you're ready to go!", anything more and we've lost the vast majority of users already (and even just writing your seedword loses lots of folks).
Most likely, wallets will simply partner with an LSP (or a few) and split some of the fees with the LSP. Users can pick a different wallet if they don't like the fee structure.
IMO If we ever expose a UI with that much detail to the user we've lost. That's wayyyyy too complicated for the vast majority of folks when they're just getting started (sure, in an advanced panel in settings, no problem).
The entire concept of a "channel" (let alone the duration of it or the size of it) should never be exposed to 99% of lightning users, and IMO the quicker people accept that the quicker LN will actually see some real users.
It looks like this has no concept of sybil resistance (ie Chainanalysis can just join and spam things and trivially de-anonymize everyone), it just picks a (few?) peers and CJs with them. Instead, you might want to take a look at JoinMarket, which has existed for quite some time and has reasonably good liquidity and sybil resistance in the form of fidelity bonds.
I would definitely agree with your point here, if it weren't for the wildcard option. While I think its a sad state of affairs that most devs don't know anything about how the DNS works (which is sad cause its wayyyy more simple than HTTP(s)), I agree that its often the case. That's the reason for the wildcard option! With it, large custodial services don't need to know much about DNS, they can add one wildcard record and handle the rest at the app layer. Anyone running a solo name resolver can similarly just add one record, so its all pretty easy.
I assume you saw what a, b, and c referred to :) They're pretty important properties.
100 sats \ 2 replies \ @bluematt 24 Feb 2024 \ parent \ on: Using DNS To Coordinate Bitcoin Payments bitcoin
You may be interested in reading the BIP draft at https://github.com/bitcoin/bips/pull/1551 specifically the section which lists the drawbacks for HTTP-based solutions. Further, note that a large custodial provider wishing to accept payments for many users only needs a single (wildcard) entry in the lightning case, so it shouldn’t be too hard to handle :)
With your system you reveal your ip and payment intentions to the dns resolver that is a centralized entity that can absolutely filter out records, requests and log your ip. That is even more true if you force the dns resolver from the app to use DoH as suggested. You even said that yourself, in the BIP and you suggested to use isp provided dns...
Indeed, there are several different options and they provide different tradeoffs. Some users may wish to use a few public resolvers (which are at least far less likely to geoblock than payment recipients, which are legally mandated to geoblock in most places in the world), and risk they log. Others may choose to use their ISP's resolver, with similar tradeoffs. Still others may choose to run their own resolver and reveal their IP to the payer. At least the sender gets to pick here, whereas with HTTP they do not, they're stuck not only depending on the same DNS infrastructure you're talking about with the same resolution censorship risks plus always revealing your IP to the recipient, modulo using a real proxy.
In the lightning context, where this idea originated, we can actually do much better - https://github.com/lightning/blips/pull/32 defines a protocol to make DNS queries using lightning onion messages, ie a built-in privacy layer to do these lookups completely privately!
Its worth pointing out that this is only possible with DNS, not with HTTP - that protocol lets you query 20 untrusted lightning nodes and as long as one is honest you get your payment instructions. With TLS you cannot build a succinct proof that the data is correct, so you have to actually have a full TCP stream proxy like Tor.
As i've said... TTL is not guaranteed to be respected, DNS is not intented to be realtime. TTL it is just an expiration, with http headers you can control much more than that.
Sure, if you set your TTL to 1 second DNS resolvers are going to ignore you and use a minute or two, but in general DNS TTLs are respected. More specifically, however, DNSSEC adds an expiry time which is absolutely always respected - the whole point of this protocol is that senders validate the DNSSEC signatures and will check the time in those signatures for an expiration.
There is a moving goalpost here
No, its about all of those!
sometimes it is about privacy : but you've admitted in your BIP that there are drawbacks
Yep, this is Bitcoin, its definitely about that. Re: drawbacks, not really, please see above for the lightning built-in OM-based solution. It makes very few tradeoffs on the privacy front!
sometimes it is for size or complexity of the sw stack
Yep
sometimes it is for censorship resistance: but if that's the goal we should probably avoid dns entirely, since there is history that proves that dns is very easy to use for censorship, see for example thepiratebay that is dns blocked by many resolvers. Why do you think they would never block or track a very specific dns query? You just need one law that mandates that, actually, very easy.
You're suggesting we use HTTP instead? Which is wholly dependent on the entire DNS infrastructure, in addition to CAs and other infrastructure on top. Indeed, there are blockchain-based alternatives to DNS which we could use, and someone arguing we should instead rely on the Ethereum Name Service arguably has a point, as I note in the BIP. I think the lack of succinct proofs there kinda suck, but that's definitely the tradeoff for much better censorship resistance.
Still, I think you make a great point about thepiratebay - in spite of one of the most powerful governments in the world wanting to take it off the internet, it not only still has a domain name, it still has a .org domain name, operated in the US! In practice, the DNS is incredibly censorship resistant, just sometimes you have to do the resolution yourself (or rely on someone other than your ISP).
I believe you missed the drawbacks section in the BIP text. Specifically, of the 4 listed there, HTTP fails (a) lacking succinct proofs of namespace to public key mappings, (b) revealing sender IP addresses to recipients or other intermediaries as a side-effect of payment, (c) relying on the bloated TLS Certificate Authority infrastructure.
(a) is important as it allows a wallet to provide a small (< 1KB) proof to a hardware wallet, which can then display "you're paying a@b.c" rather than "you're paying 1Abcasdfqreysfda". This is not possible with TLS-based solutions as a general matter.
(b) is critical for censorship resistance. We already see LNURL-pay recipients filter who can send based on source IP address, and its absolutely a legal requirement for companies to do so. I fully do not understand how any bitcoiner thinks an HTTP-based protocol is okay for this reason alone - if we don't have censorship resistance what's the point of Bitcoin at all?
(c) is a bit nicer to have, admittedly, but TLS + all the certificate authorities out there is a huge pile of crap that you're trusting for your payments, and I'd very much rather not trust all 100 certificate authorities, including the a number of governments all over the world to "secure" my payments.
As for your specific points:
a) It needs dns resolution that is not available on webapps unless using a proxy server or DoH provider, increasing centralization
Sure, but you can query 4 or 5 DoH providers and not need to worry too much about it. Even better, that extra hop gives the sender privacy and nets substantially more censorship resistance, so it seems like a great tradeoff!
b) Very limited control over cache invalidation by the domain owner
Huh? You can pick a TTL and requesters will cache for exactly as long as you say. This simply isn't true.
c) Relies on the user or the user's os to set encrypted dns for privacy
No it doesn't, the application making the query can choose how they make requests for themselves.
Yes, not only does this allow for multiple protocols, its reliance on BIP 21 URIs means it can reuse wallets’ existing multiple protocol logic!
I don't understand why a wallet should fail the Lightning address if it finds multiple TXT records. Couldn't multiple TXT records be used to achieve the above, e.g. one record for a stealth onchain address, another for LNURLp, Bolt12, AMP or keysend?
BIP 21 today is usually implemented by providing a single URI with multiple payment protocols embedded in different query parameters. This takes advantage of that standard and uses a single record to express as many protocols as a recipient wants. It could be relaxed to allow multiple TXT records, but given there’s no need for it and it may cause ambiguity or indicate misconfiguration, it seems best to disallow.
So apparently I was more calorie-defecient when I read this than I was thinking...I somehow read it as "this solution is over dude, imho", which made kinda no sense to me.