70 sats \ 1 reply \ @rblb 16 May \ on: Cashu: This will allow integrating Ecash into existing KYC/AML infrastructure bitcoin
They seem a bit too eager to integrate with KYC, this is becoming suspicious.
Github Copilot is very useful as a "mind-reading" autocompletion if you are writing correct code and you know what you are doing.
Or if you have the general idea on how the code should be, but you don't know how to use the api for a specific library, you can write a comment explaining what you want the next line to do and copilot will write the code to do that.
It works best if you have well structured commented code and source code available for the main dependencies, also it doesn't work the same with all languages and programming styles.
Regarding debugging, it catches oversights that you would catch too if you were to read carefully the code, it is not very good with complex issues.
Overall i think as a developer you should aim to integrate with ai tools and not to use them as a replacement for yourself.
So, besides the usual quarrels that are very common in FOSS development, you raise an important point, my understanding is that you do believe that these PRs introduced vulnerabilities to certain attacks.
The fact that the PR is merged doesn't prevent you from proving your point, so, if you can simulate these attacks in a real world scenario, as you proposed originally, I suggest you do that and show the results to the public, you will get much more people on your side then.
This is the same as spoofing the download page for native apps. True, app stores solve it to an extent, however malicious homonym apps sometimes end up on app stores too.
If we consider this model to be good enought, then it is just a matter of building a link directory for Web Apps and tell the users to open the link from there and bookmark/install the web app.
I didn't miss the drawbacks section of the BIP, i just think you are wrong
a) This is true, i think you are correct as i've already said in my previous reply
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. No it doesn't, the application making the query can choose how they make requests for themselves.
b) 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...
Let me cite your BIP:
While public recursive DNS resolvers are very common (e.g. 1.1.1.1, 8.8.8.8, and 9.9.9.9), using such resolvers directly (even after validating DNSSEC signatures) introduces drawback (b), at least in regard to a centralized intermediary. Resolving payment instructions recursively locally would instead introduce drawback (b) directly to the recipient, which may well be worse. For payers not using VPN or other proxying technologies, they generally trust their ISP for protection against denial of service anyway, so using ISP-provided recursive DNS resolvers is sufficient.
So let me get this straight, if i ask you how to protect against dns resolvers logging my ip your answer is "use a vpn bro" but the same answer is not valid to protect you against the http server logging your ip?
More so, your solution has a clear fingerprint that stands out for the resolver, since it asks for a record that is unique, contrary to a common domain resolution request.
Huh? You can pick a TTL and requesters will cache for exactly as long as you say. This simply isn't true.
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.
There is a moving goalpost here
- sometimes it is about privacy : but you've admitted in your BIP that there are drawbacks
- sometimes it is for size or complexity of the sw stack : and i think you have a valid point here
- 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.
Because i like SN... also i don't think lightning needs to be usable in a self sovereign manner by the average user to succeed, it already works with custodial solutions and with fedimint, cashu, LoL etc.. we can get the same usability with less trust involved.
I was just pointing out an inaccuracy in your argument
Since you don't welcome contrarian opinions on the bip proposal, I'd like to address your points here...
a) It is just a json file that can be extended to support everything, it is actually already used for nostr zaps
b) true
c) Arguably better than revealing it to a centralized dns provider
d) Subjective
e) Yes, they can. This is mapped to alby: zap@rblb.it
Drawbacks to the DNS proposal
a) It needs dns resolution that is not available on webapps unless using a proxy server or DoH provider, increasing centralization
b) Very limited control over cache invalidation by the domain owner
c) Relies on the user or the user's os to set encrypted dns for privacy
Now, i understand that you do not care about arguments in favor of HTTP vs DNS, totally fair, but you are putting out subjective and technically inaccurate facts as if they were unchallenged truths.
- We need to educate individuals with unit biases, as this flawed thinking could negatively impact other aspects.
- Correct, it's the Bitcoin logo, not the sats logo.
- So, I stand corrected. You keep saying the proposal is to use ₿ as the symbol but sats as name. In reality, it's more of a covert redenomination. Also i disagree with gmax.
- Unit bias is FIAT mentality (also common scammy rhetoric used by tokens eg. safemoon)
- ₿ is already assigned to Bitcoin
- Why is there a small faction of allegedly Bitcoiners attempting to erase Satoshi from bitcoin? He did a lot for us, so it's only fair that we honor his legacy every time we spend bitcoin.
I suggest staying focused on scaling and building on Bitcoin, rather than politics.
I think ⚡ is fine, we could pretend it stands for proof of work, energy or electricity, bitcoin is closely related to all of them. Also, nothing is stopping future scaling solutions to choose names that hint back to this meaning.
Ok thanks for the answer.
Does the mint have a database of the ecash somewhat connected to a seed phrase? My understanding of the cashu protocol is that every ecash is a self contained proof and for this reason it is very hard for a mint to track offline exchanges, but if every issued ecash and every claimed ecash can be traced back to a seed phrase the situation is different as it is like having a virtual account.
Nice! Anyone knows how the "off device backup" works?
I get that the seed is probably the encryption key for the wallet backup, but where is the backup stored?
When i asked binance support why lightning wasn't enabled in my account, they said lightning is illegal in italy 🤷 (still have to find the law btw) , they don't even deserve to be in that 6%
I've noticed this during development as well, i think it is a bug in Green, not Anser, since Green can't even scan its own QRs (if they have assetid or amount), while they all work fine with Aqua and other wallets.
As a workaround you can send everything (including the non L-BTC assets) to the L-BTC qr that works fine with Green, since all the other QRs are just the L-BTC address with some hints to get the wallet client to automatically select the right asset and amount.
Yes, the Alby extension holds one master key that provides the identities for several things (lnurl-auth, nostr, btc and liquid at the moment) and it exposes some apis to use them without ever accessing the private keys directly.
Eg. for liquid you have one api to retrieve the address, and one api to request the user to sign a transaction.