Sat parity will be reached by all fiats sooner or later. 😁
If you include turning to shitcoining as becoming a fiat person, and I think you should, there's quite a few counterexamples I can think of. 😬
This update marks a major milestone for the project. I know, with certainty, that MLS messaging over Nostr is going to work. That might sound a little crazy after so many months working on the project, and I was pretty confident, but until you’ve got running code, it’s all conjecture.
Late last week, I released a video of a working prototype of [White Noise](https://github.com/erskingardner/whitenoise) that shows the full flow; creating groups, inviting other users to join those groups, accepting invites, and sending messages back-and-forth. I’m thrilled that I’ve gotten this far but also appalled that it’s taken so long and disgusted at the state of the code in the app (I’ve been told I have unrelenting standards 😅).
If you missed the video last week...
nostr:note125cuk0zetc7sshw52v5zaq9apq3rq7e2x587tr2c96t7z7sjs59svwv0fj
## What's Next?
In this update, I want to cover a few things about how I'm planning to proceed and how I’m splitting code out of the app into libraries that will help other developers implement MLS messaging in their own Nostr clients.
First off, many of you know that I've been building White Noise as a Rust app using the [Tauri](https://tauri.app) framework. The [OpenMLS](https://github.com/openmls/openmls) implementation is also written in Rust (with bindings for many other languages). So, when you hear me talking about library code, think Rust crates for now.
The first library, called [openmls-nostr](https://github.com/erskingardner/openmls-nostr), is an extension/abstraction on top of the openmls implementation of the MLS spec that helps Nostr clients interact more easily with that implementation in a way that feels native to Nostr. Mostly this will be helping developers interact with MLS primitives and ensure that they’re creating, validating, and serializing these objects in the right way at the right times.
The second isn’t a new library as a big contribution to the already excellent [rust-nostr](https://github.com/rust-nostr) library from nostr:npub1drvpzev3syqt0kjrls50050uzf25gehpz9vgdw08hvex7e0vgfeq0eseet. The methods that will go in rust-nostr are highly abstracted and based specifically on the requirements of NIP-104. Mostly this will be helping developers to take those MLS primitives and publish or query them as Nostr events at the right times and to/from the right relays.
Most of this code was originally written directly in the White Noise library so this week I've started to pull code for both of those libraries out and move it to its new home. While I’ve been at it, I've been writing some tests and trying to document things.
An unfortunate offshoot of this is that the usable builds of White Noise are going to take a touch longer. I promise it’s still a very high priority but at this point I need to clean a few things up based on what I've learned thus far.
Another thing that is slowing down release is that; behind the scenes of the dev work, I’ve been battling with Apple for nearly 2 months now to get a proper developer team set up so that we can publish the app via TestFlight for MacOS and iOS. I’ve also been recently learning the intricacies of Android publishing (oh my dear god there are so many devices, OS versions, etc.).
With that in mind, if you know anyone who can help get me up to speed on CI/CD, release pipelines, and multi-platform distribution please hit me up. I would love to learn more and hopefully shortcut some of the pain.
Thanks again so much for all the support over the last few months! It means a lot to me and is a huge part of what is keeping me going on this. 🙏
Thank you for putting in the work, I feel like the payoff could be huge. 🙏
I had a levelDB issue myself a couple of weeks ago. FYI there's a couple of CLI options to bitcoind called -reindex and -reindex-chainstate that are probably faster than starting over.
https://bitcoin.stackexchange.com/questions/65680/how-to-recover-corrupted-bitcoin-core-blockchain
Welp, haven't heard that one before!
My response would be - Moving the money is a service, and it has a service overhead. The person doing the service for you deserves to be able to profit for doing so. Why should someone else bear the cost of sending your transaction for you? You pay others for many other types of goods and services, why not financial services?
In Bitcoin specifically you're paying a miner to include your data in a block - There's only a up to 4 MB block about every 10 min, so this bandwidth is very limited. Limited means expensive, go figure.
I found this article about the tax. In good news the NFP who are proposing this change are short of a majority, and need agreement from Macronist in parliament to get it passed. Which probably makes it unlikely to be realized. But yes, more exit taxes are to be expected broadly.
Hop over the border to Italian Switzerland, and enjoy a nice round 0% capital gains tax, on Bitcoin or otherwise. 😉 🇨🇭
For me the nostalgia zone is the X-Men '97 intro theme - Unironically hype AF even as an adult! 🔥😤
Both are soft fork proposals but that's the only point of similarity.
CTV is a way to do covenants (lock up coins in more interesting ways). This can be useful for some layer two ideas, and vaults among other things.
CISA is basically a optimization on use of block space. It'd mean batch payments and coinjoins become smaller and thus cheaper on chain.
https://bitcoinops.org is a good resource to learn more but it's also very technical.
Amber exists: https://github.com/greenart7c3/amber
It'd be cool if you added more discovery to the app - There's already lots of good apps on there, I'd like to be able to find stuff more easily. Even more so if you add more apps.
Right, you basically give them an address, and deposit fiat, and as soon as they get the money they send you Bitcoin.
Ah so just an exchange that instantly pays out your Bitcoin to self custody? Yeah there's a couple of them that do that. Relai and Pocket Bitcoin for example.
I'm not sure I understand what you mean by locking sats for orders, but I don't think it matters. The problem is you can prove that your list of deposits / orders is complete and you didn't delete a entry.
Let's use a simplified example: Let's say you and I both have 1 BTC deposited on Kraken. Kraken in turn publishes a list of deposits stating they owe account A and account B 1 BTC each, and they have a list of addresses that have 3 BTC. Then it looks like they are 130% reserved, because they need to provide up to 2 BTC on request but have 3.
However Kraken actually has one more account C that is owed 2 BTC - Meaning they're actually 3 / 5 = 60% reserved, not 130%. Now if everyone takes out their BTC at once the last person will be rugged.
The problem is basically you can prove how much Bitcoin you have, but not how much Bitcoin you owe. Because you'd have to prove a negative, I.E "prove you don't have more deposits than you published".
Runes are still like 90% of the Mempool tho. Plenty of 🤡s around.
In order to for the custodian to be solvent liabilities have to be less
than reserves, so for every Bitcoin "claim" I have there must be one
real Bitcoin on chain able to be redeemed.
It's not too difficult to prove how much Bitcoin you have on chain actually - You can just publish your addresses somewhere. Several exchanges and ETF:s already do this. For example Bitwise, Fidelity, Kraken.
The sticky part is proving liabilities, I.E how much Bitcoin is owed to your customers. This info is not on the chain itself so it's harder to prove. The best way at the moment to do this is a 3rd party audit, but then you have to trust the auditor is not colluding with the custodian to hide some liabilities.
I've burned 75 k sats on being an eCash early adopter - Most of it I lost in Mutiny, I was trying to sweep out to my cold storage wallet and the transaction bugged out. I still have a GitHub issue open about it, not sure if I'll be able to get any help with it now since Mutiny is shutting down...