pull down to refresh
Why do you want them to stop?
They want to use Bitcoin and make an L2 on top of it.
No there is no way to make them stop with the current consensus rules and it's deeply pathological to even suggest such a thing. Bitcoin is supposed to be censorship resistant.
Another question: how many unprunable outputs are we talking about from Citrea? Hundreds? Thousands? Tens of thousands? Is this something really core to their business model
They need two taproot outputs to embed an extra 32bytes * 2 in.
So in total they're embedding 144 bytes of data.
This is also in the worst-case scenario that's never supposed to happen, where the bridge is malfunctioning.
In normal operation there won't be any data embedding here.
NIP19 nprofiles with a relay entry are not a solution -- they just resurrect the Mastadon/Matrix problem.
It doesn't resurrect the Mastodon/Matrix problem.
The fact that you can have mulitple relays embedded in the nprofile is a huge win over Mastodon, where your identity (that you don't own) is stuck on one single instance that can ban you at any time.nprofile is good enough.
Presumably yes. At the very least Lightning being used over multiple BitVM sidechains (all using BTC as the unit) should work.
Yeah we are not on the official F-Droid repo or have our own repo just yet.
Best option is to download the APKs from GitHub. You can use tools like Obtanium to keep track.
Yes indeed that could be a pretty good service.
I've been thinking about that too, and calling it OnlySats.
You can also use your Lightning Address via Lightning Box for nostr tipping. you don't need to use Wallet of Satoshi anymore.
Feel free to reach out on Telegram or nostr if you have any questions guys.
To use this feature, it's very important to run Blixt Persistent Mode and disable battery optimization for the app. We have been testing this for many months and the battery drain should be low if everything is going as expected.
Also, doing "Lnd db compaction" inside settings -> debug can improve efficiency. It's recommended to do it.
Regarding ZeroSync, what do you think about the feasibility of mobile bitcoin/lightning wallets embedding a fullnode utilizing ZeroSync?
My understanding is that mobile is one of the focus areas of the project and tech?
I don't fully grasp how the technology works regarding constructing the UTXO set. What is the bandwidth and disk space requirements etc? What would be required in order to scan and/or keep track of your own bitcoin addresses?
Cheers and good job on BitVM, I'm still in shock that it's even real.
I don't see any explicit decoding of the query param:
It was some time ago I made this server, but I think Fastify is implicitly decoding the GET params. It makes it into an object.
It will naturally not attempt to decode twice, which is why the JSON.parse() errors out.
Perhaps we're double encoding when we shouldn't be?
Yes, my understanding after reading the specification again is that it should not be encoded twice.
Perhaps we're double encoding when we shouldn't be?
Yes, as far as I can tell, it seems to be double-encoded when it shouldn't be.
A quick look.
Yours require two decodeURIComponents:
// stacker.news
decodeURIComponent(decodeURIComponent("%257B%2522identifier%2522%253A%2522SatsAllDay%2540stacker.news%2522%257D"));
'{"identifier":"SatsAllDay@stacker.news"}'
// blixt wallet
decodeURIComponent("%7B%22name%22%3A%22Hampus%22%2C%22identifier%22%3A%22hampus%40blixtwallet.com%22%7D");
'{"name":"Hampus","identifier":"hampus@blixtwallet.com"}'If I want to send to chat@blixtwallet.com (https://chat.blixtwallet.com/) 10 sats it appear the comment and name but I get an error: Unexpected error value: [400, "expectedPaymentRequestToDecode"]
expectedPaymentRequestToDecode appears to be coming the lightning npm lib, and is decoding an invoice.
Perhaps the invoice request (i.e calling the callback in LNURL-pay) didn't work properly for some reason and did not return an invoice.
Yes. This is totally the plan I have for my Lightning Box concept, which I will integrate deeply into Blixt Wallet and that other wallets can trivially support via LNURL.
Yes, however this is nothing new and is similar to wallets using an LSP like Phoenix, Blixt, Zeus etc.
To achieve good UX in Bitcoin it looks like you have to make certain tradeoffs.
Aa long as you can unilaterally exit and you're in custody of your money, I think this is workable.