pull down to refresh
328 sats \ 11 replies \ @bluematt 5 May \ on: Coinjoin Workshop aka Emessbee đ: Unstoppable Coinjoins with No Coordinator bitcoin
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.
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 :)
102 sats \ 0 replies \ @bluematt OP 11 Feb \ parent \ on: Human Readable Bitcoin Payment Instructions bitcoin
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.
This spec is generic across any bitcoin payment method. It works for on-chain as much as it does BOLT12, fedimint, or cashu. All it needs is a static invoice (so not BOLT11) that can go in a bitcoin: URI.
You can run the server yourself, then it is self custodial
That's fair, and, indeed, I should have chosen my words more carefully. Maybe I should have said "lnurl, by definition, if you are not running the server yourself (which ~no one does) cannot be non-custodial".
Senders can also validate the signature in the intended recipient's invoice to ensure it hasn't been swapped (I implemented something pretty similar to this for zaplocker, though I didn't go all the way) -- that also makes it self custodial
Except, not only does no one do this, but it requires a spec extension for senders to (a) have any idea what the intended public key is and (b) requires some signaling to know whether the sender should be validating (possible using TOFU). In both cases, you need some kind of external signaling (because you can't simply trust the lnurl server, that would defeat the point), which defeats the point of lnaddress - a simple human-readable name to pay to.
Not only is that true, but even if you fully trust the federation its still a useless distinction - lnurl, by definition, cannot be non-custodial. Its a single (HTTPS) server that can steal any and all payments to you. They can't take money after you have it, but its not a very interesting distinction IMO.
One easy thing you can do to contribute to OSS, ignoring the maintainer issue, is report issues in a clear, concise, understandable, and friendly manner. One of the issues the freerider problem has created is that users using open source software often fight to work around issues, without ever reporting them. While this isn't super helpful for projects short on maintainer time, at least filing issues helps them understand what is going wrong and potentially fix it. Of course filing an issue and being pompous or rude isn't acceptable, but filing issues that are clear and well-documented is a great contribution!
All the benefits of LN-Address, (most of) the privacy of BOLT12, plus you can choose use it without trusting a provider as long as you have your own domain and can add one DNS record!
It'd be pretty easy for lightning nodes/wallets to just stop showing/highlighting the message. That would probably deter spam pretty quickly.
If you're using either LDK option, please join our discord! We try very hard to help developers using LDK or ldk-node as much as possible, and appreciate hearing from developers what is going wrong or what they're struggling with. This allows us to improve the interfaces going forward, as well as help developers resolve issues quickly rather than struggling.
Okay, I'm done arguing this, you can take it up with bitkit, but it sounds like you have and they told you to chill out and wait until they finish building before you complain about specific bugs. Maybe worth listening to them.
Sadly there are only really three (and a half) options for integrating lightning into an existing application - (full) LDK, ldk-node, greenlight/breez, and (kinda) LND. Integrating LND into an existing application is a ton of work, and lots to maintain, so generally hasn't been something people do, or have stuck with long-term.
The full LDK interface is a lot of work, but very flexible in terms of how it gets integrated into an existing application, with customization for how/where you store your data, how you generate all key material, how/where you get blockchain data from, how/where you do signing operations, several different models of potential watchtower integration, etc, etc. This is great if you need some of that customization, but if not its a lot of work just to build the same thing everyone else has.
ldk-node is a standard node that does all the usual things to build a lightning node, packaged up with a super simple API (start node, open channel, pay money, list transactions) that handles storage and keys and blockchain sync for you. It works great on mobile, and has some flexibility, but is generally targeted at devs who just want something that just works.
greenlight/breez SDK are fairly similar to ldk-node in their API design, but unlike ldk-node they rely on hosting from greenlight/blockstream and integration with the breez LSP, rather than being able to choose your own.