nostr:npub1spralxq6jlw5rdy0249vqr5sh43rfrlx2wzv3rhjjqedw559w9psrs8s72 nostr:npub185h9z5yxn8uc7retm0n6gkm88358lejzparxms5kmy9epr236k2qcswrdp Thank you for entrusting me to foster Grumpy at rust-bitcoin Summit. He found his forever home at MIT DCI 
nostr:npub1s0vtkgej33n7ec4d7ycxmwt78up8hpfa30d0yfksrshq7t82mchqynpq6j keeps hinting at a blurry target that looks like this
has generative ai given rise to a new type of software worker who is neither a developer nor applies engineering principles yet produces results as a product mainly of extracting results from software?
How did you find Erik?
📝 New BDK Blog Post … What we were up to in Q2 https://bitcoindevkit.org/blog/_2024-q2-update/%E2%80%A8%E2%80%A8%F0%9F%9A%80 1.0 alphas! New grant projects! btc++! Bitkey!
https://bitcoindevkit.org/blog/_2024-q2-update/ percent-encoding gone rogue
I think they do with a bit of additional kyc and manual in-app bitcoin purchase https://help.venmo.com/hc/en-us/articles/16145303480595-Crypto-Transfers
I’m glad twitter broke away from the mainstream and at the same time recognize the incentives are broken
I’ve seen no kyc regulated financial services are viable for small amounts (i.e. less than $1k). Could an institution offer a mint and somehow cap amounts with range proofs?
📢 BDK 1.0.0-beta.1 has landed 🚀. This release includes the first beta version of bdk_wallet with a stable 1.0.0 API. The changes in this version include reworked wallet persistence, changeset, and construction, optional user provided RNG, custom tx sorting, and use of merkle proofs in bdk_electrum. See the release notes for all the details.
https://github.com/bitcoindevkit/bdk/releases/tag/v1.0.0-beta.1
Humongous congrats to all of the contributors and to everyone downstream who’ll be able to update without taking painkillers after.
What a W.
Ok – so Signal is great. Good encryption, etc. Obviously, the main thing that we want to improve there is the centralized coordinator in the middle.
My original proposal was an adaptation of the Signal protocol for Nostr. https://github.com/nostr-protocol/nips/blob/2169fab971591d0b4a450ef08aeb6301c5d2a0da/104.md
But I got lots of feedback on that one that 1) group messaging needs to be first class and 2) multiple device support needs to be first class. Both of these are actually the same thing - supporting groups.
With the signal protocol, the way that the symmetric encryption works, when you're in a group, you're effectively creating a DM to every member of the group, encrypting it separately, and sending it out. Signal makes this feel like less of a big deal because they do some tricks on the server side to make it less heavy for the client.
In the nostr version of the signal protocol, you have no server to do work for you, so your device has to do all that work itself.
With MLS, because it's using a different data structure (binary trees) for managing encryption keys and users in a group, you go from a situation where group scaling is a linear problem (each new user in a group adds the same amount of work for all clients) to a log problem (where each new user in a group adds wayyyy less work for all clients).
There are also other benefits of MLS.
1) it's about to be an internet standard (like TLS, etc) so we conceivably get interoperability with other networks/clients
2) it's built to allow for the use of multiple ciphersuites and the graceful change/upgrade of the ciphersuites over time.
The only drawback is that it's very complex and very new. My work so far on getting MLS to Nostr has been focused on updating dependency libraries to allow for support of schnorr signatures over the secp256k1 curve (what nostr - and bitcoin - uses). I'm very convinced this is the right long-term solution for private messaging on Nostr but it's going to take a bit longer to get it probably ready for implementation.
If you haven't see it already, you can follow along with what I'm doing in my weekly posts. Also, if you're interested in working with me on all this, that'd be awesome.
nostr:naddr1qvzqqqr4gupzq9eemymaerqvwdc25f6ctyuvzx0zt3qld3zp5hf5cmfc2qlrzdh0qqxnzdejxy6rzwf5xvmnwveh25uk9n
Must we assume the server does no work on behalf of the user? Is it it possible to have a server do more and explicitly advertise NIP-X support or is that not Nostrly?
Using Payjoin for better batching of all sorts of activity is the goal. Sounds like you just get it 🔥
Any major snags or changes to propose?
Putting the reps in with Payjoin Dev Kit I see 🫡 nostr:note1x74psc7wu2garkr3qzzu5z3jhsaev4lnpelalmnzw9nmhsmkaygss3pr6a
Curious about this new BIP 353/Human Readable Names thing but don’t have a wallet that supports it yet? Want to see if you set it up right?
Head over to https://satsto.me/ to resolve them to legacy addresses!
It’s not just BOLT12, either, any reusable bitcoin addresses can go in there (but preferably ones that don’t cause on-chain address reuse)!
The BIP recommends Tor or VPN for private DNS querying. Was ODoH considered? I assume it was avoided because it tries to avoid HTTP, but in web clients of course HTTP is available