Avatar
Hampus
65594f279a789982b55c02a38c92a99b986f891d2814c5f553d1bbfe3e23853d
Maker of Blixt Wallet, a non-custodial Lightning Wallet https://blixtwallet.github.io Funded by HRF and OpenSats. ⚡️ hampus@blixtwallet.com

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.

https://t.me/BlixtWallet

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

Long text good. Short text bad

Lmao no it’s the complete opposite.

Character limitation prevents meaningful thought and expression, and people instead just resort to primal insults and nasty gotchas.

Nostr is 1000000x better than Twitter, because you can actually discuss things here.

Fair. I actually prefer the old SIGHASH_NOINPUT over SIGHASH_ANYPREVOUT, because it’s simpler.

Anyway let’s just do both APO and CTV and call it a day. They’re both trivial.

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.

https://github.com/nostr-protocol/nips/pull/512#issuecomment-1542851434

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

nostr:note1vzaw25nelxm7cmgfde5d2xaedkv73kvhvz4jegfyvrtxhhqn8laqlwszr4

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

nostr:note1vzaw25nelxm7cmgfde5d2xaedkv73kvhvz4jegfyvrtxhhqn8laqlwszr4

Those things don’t take us that far.

But yes, I agree that we should do things like CISA, as that would make it possible to have more transactions within the current weight unit limit.

Really, it’s a shame that Taproot didn’t include CISA already.

Replying to Avatar Hampus

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?

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?

Blixt Wallet is the tinkerer's wallet.

Check out how many things you can do in the settings.

https://i.imgur.com/yl65eg2.mp4