Testing to post to a cool new relay

Is red meat, white rice and broccoli a good diet for bodybuilding?

3D graphics peaked with Warcraft III in 2002. It went downhill from there.

I’m very happy to announce Blixt Wallet 0.6.8! It contains a new feature called speedloader by @kubernetes, which syncs LN channel db on app startup, leading to robust payment pathfinding. We want to thank Breez, which this work is derived from ⚡️

GitHub

Release 0.6.8 · hsjoberg/blixt-wallet

Blixt Wallet v0.6.8 is here and we have an important new feature called Speedloader! Speedloader syncs the wallet's channel database ("channel grap...

Speedloader loads the channel database file on app startup. On Android, the channel database file that speedloader uses is automatically cached by a background sync job every 24h. On iOS & macOS, the file is also downloaded on startup, leading to slightly longer startup times. https://twitter.com/i/status/1674029478115266560 - Blixt Wallet 0.6.8 has better support for hodl invoices. On-going payments now show up as "pending" in the transaction log before they are eventually settled or cancelled. This should result in a better experience when using services like RoboSats. - Blixt Wallet 0.6.8 introduces 0-conf channel support! Add pubkeys for nodes you would like to accept 0-conf channels from. https://twitter.com/i/status/1674029483525849091 - Speedloader is open-source and can be used with a normal lnd instance.

GitHub

GitHub - djkazic/speedloader: speedloader is a gossip syncer for LND on mobile

speedloader is a gossip syncer for LND on mobile. Contribute to djkazic/speedloader development by creating an account on GitHub.

Primer is used for generating the channel db file.

GitHub

GitHub - djkazic/primer

Contribute to djkazic/primer development by creating an account on GitHub.

In a future Blixt Wallet version, we'll add the ability to choose endpoint for downloading the channel db file. - Blixt Wallet 0.6.8 includes a crash fix for certain iPhone devices. Known affected devices are: iPhone 5/5s/6/6s/7/X/XR. If you have experienced issues in the past, please give a fresh installation of Blixt Wallet a try. 🪄 - Happy Blixting everyone! 🟡

People still look at the Bitcoin price?

Yet another centralized service (Lightspark) being a menace to the network by doing evil probing is not fixing Lightning. In order to promote self-custody, we need tools to improve reliability for self-custodial wallets: - Native probing (BOLT14) - Blinded paths - Stuckless payments - Async payments

Blixt Wallet and Blixt Wallet Testnet have been reinstated to the Goople Play Store. Link to Blixt Wallet: https://play.google.com/store/apps/details?id=com.blixtwallet Link to Blixt Wallet Testnet: https://play.google.com/store/apps/details?id=com.blixtwallet.testnet Happy Blixting! 🟡

Our appeal for the suspension of Blixt Wallet and Blixt Wallet Testnet on Google Play has been accepted. The apps are currently under review. We expect them to be back soon! The suspension was due to app similarities, but we've clarified that Blixt Testnet is for testing only. As always, you can download the APK directly from our releases page on GitHub:

GitHub

Releases · hsjoberg/blixt-wallet

Bitcoin Lightning Wallet with focus on usability and user experience - hsjoberg/blixt-wallet

In order to stay up-to-date with releases, we recommend you to use the tool Obtainium:

GitHub

GitHub - ImranR98/Obtainium: Get Android app updates straight from the source.

Get Android app updates straight from the source. Contribute to ImranR98/Obtainium development by creating an account on GitHub.

Read more about this in DarthCoin's article:

What mobile device should use bitcoiners?

A quick guide how to build your own clean mobile device, ready to be used safely with all kind of Bitcoin applications.

View quoted note →

Blixt Wallet and Blixt Wallet Testnet have been suspended from the Google Play Store. We are working with Google on figuring out why. In the meantime, you can download the wallet APK on GitHub.

GitHub

Releases · hsjoberg/blixt-wallet

Bitcoin Lightning Wallet with focus on usability and user experience - hsjoberg/blixt-wallet

My email is getting too many support inquiries for Blixt Wallet. I cannot keep up. If you need immediate help, please join our Telegram chat group. We are a strong and helpful community.

Telegram

Blixt Wallet

Android: https://play.google.com/store/apps/details?id=com.blixtwallet iOS: https://testflight.apple.com/join/EXvGhRzS GitHub repository: https://g...

Real wizards use https://ide.scriptwiz.app, not robes.

At this point, it's clear that many prominent scaling technologies being proposed for Bitcoin are reliant on either OP_CTV or SIGHASH_ANYPREVOUT. Seeing how SIGHASH_ANYPREVOUT is such a simple softfork, I suggest that we start moving towards an activation for it in Bitcoin.

There is a proposal out there to change the internal encoding format of nostr from text-based (JSON) to binary. This is a huge mistake. One of the primary reasons why we have such vibrant ecosystem today is because of the simplicity of the nostr protocol, which means it’s easy for developers to create applications and tools. Furthermore adding another encoding format puts a lot of burden of the whole ecosystem of services, clients, relays and tools. Let’s don’t lose what we have. Don’t adopt NIP-88.

GitHub

NIP-88: binary event encoding by dr-orlovsky · Pull Request #512 · nostr-protocol/nips

At the present moment nostr (NIP-1) uses text serialization of the event data, represented in a form of a JSON object. While being simple-to-implem...

The Blixt community thanks the Human Rights Foundation for the open-source grant awarded to Hampus. ⚡️🟡 View quoted note →

The Blixt community thanks the Human Rights Foundation for the open-source grant awarded to Hampus. ⚡️🟡 View quoted note →

Is it Lightning's time to shine now when the onchain transaction fee is so high? Well yes, partly. But please understand that Lightning ceases to work if the fees are too high! To understand why, let’s go back to the saying that “Lightning is just Bitcoin transactions”. Yes, this is true. Lightning in the end relies on normal Bitcoin transactions. So by knowing this, you should have already realized why Lightning under a high onchain fee market is fragile, but let me explain: The primary problem I’m referring to is the economical viability to sweep HTLCs. An HTLC is the thing that gets added as an output to your lightning commitment transaction when you are doing Lightning payment. It gets cleared out by making a new commitment transaction once the payment has goes through. But the problem here is that if the onchain transaction fee is $100 and the cost of the sweeping an HTLC output is $100, then that means it’s not actually economically possible to redeem these funds. Under normal circumstances you would never have to force-close and redeem this onchain, but it _can_ happen. How LN circumvents this problem is by giving the payment amount to miners instead as a substitute for a real HTLC output. Giving the sats to miners means no more bytes are added to the commitment transaction, but it also means that if a force-close happens, these sats will just be given to miners instead. This was already the case for all smaller payments (21 sats and so on) including virtually _all_ zaps here on nostr. But for smaller micro-transactions it’s not a big deal if a payments gets lost, because no one would cry over 21 sats. But if it’s about 210 000 sats, then we’re in a BIG problem if this isn’t secure and trustless. We need to find a sweet spot for onchain transaction fees and we need more scaling solutions that work together with LN in order to fix this. My favorite solution is a Lightning Network deployed over multiple Drivechains, fully interoperable, but I’m open for more suggestions. What do you think?