Last Notes
No no, for offers. Imagine Nostr app wants to zap using BOLT 12. It does a system open for bitcoin:?lno=lnoffer&pop=proofcallback, but it ultimately needs the proof to include “Bob zapped with emoji🫠”. So either the proofcallback has to include the private key or that original URI has to include the string to sign.
That is not the only instance they’re talking about. That’s just the new one from today. Here’s three specific instances the UN is objecting to, all from the Guardian article from yesterday. https://image.nostr.build/59b14a3f73dd32ecb9be35a9f3890c5431ac781fe929f277b40dec4c99bb1bf3.jpg https://image.nostr.build/e1352d1c5a75f8cd05feb8922ae13cb8b61461b67b565cbcad36ea1563ba4843.jpg https://image.nostr.build/83cb8200c759a80ec4a7872674de1e14074d3596f69e309c4034256ef4b63074.jpg
Today you can see the lightning nodes that ship fixes for novel attacks quickly (eclair and LDK, which did some force closures as a result of the fix) and those that don’t respond to security issues after months.
Any method of cooperatively building a nonce (eg stuff things do for FROST, it’s the same problem).
Maybe with some fixed prefix though.
(And, to be clear, if we want to avoid onion messages you could still do BOLT 12 over nostr, though I’d generally recommend against for privacy reasons)
Yep, that’s why I didn’t say 1000 sats :). Even 100k sats is a lot for a channel, tho, tbh.
I understand the data to be signed and tied to an Apple ID. It may well also be tied to some per-device factory-sealed key. I mean you can always buy 256 real AirTags but hardware modifications are much more likely to be detected than software ones.
You can even make bets on leverage 🎰🎰🎰
Sadly no implementation exists for Taproot AFAIK, but the BitBox folks have a PR to secp256k1-zkp at least.
Not “intentionally”, just some miners got excited when it was still a PR.
I mean that’s literally Unfil’s mandate - to watch what happens so they can encourage both sides to reduce tensions and tell the UN who’s job is to do the same?
Hmm? The IDF comments on lots of specific cases. Not everything, certainly, but when things make big news headlines, I’ve generally seen comments.
Anyway, not sure arguing relative percentages is worth it - I’m still really confused why you are talking a *default* stance of “the IDF is right not the UN” rather than a default stance of “I dunno, could go either way, both stances have reasonable motivation”. I fear you are falling into the “all conflicts must have a good guy and because the other side are obviously not it, Israel must be it, and can do no wrong” fallacy that is all too common in conflicts.
Not to mention it follows a week or more of Israel explicitly telling Unfil that they should leave, the idea that commanders may wish to ramp up pressure isn’t unreasonable.
Look like @npub1az9…m8y8 is avoiding opinions he disagrees with on his podcast, so which one should I go on instead to talk about hardware wallet issues? https://image.nostr.build/e73fac49e7e40f67b1d0f2842f63ed3dd96e23649cf60a85575481177c88a847.jpg
That doesn’t allow a payer’s lightning wallet to access the internet, though?
Yea, you can do multisig channels (indeed nested musig) for lightning (well, 66%+1, not 50%+1, sadly), but you’re still doing the “I communicate with some third party over your internet before I pay you for it”.
But, yeah just giving people a tiny bit of internet works fine mostly. Even airplane WiFi with credit cards lets you access DNS before you buy…
It’s just a head-of-line-blocking question, though…I imagine mostly you’re not downloading lots of CSS/JS/images, which is the big head-of-line issue HTTP clients have - they can render the page partially in response to each new item they get off the wire.
I assume you don’t, really, though? You presumably get events back from the server in time-order and populate the page down in time-order, so mostly one event stalling the next won’t make all that much difference in UX?
Filtering the Internet such that you can connect to your LSP but nothing else is…hard?
My point was I’m not sure you can pretend you’re *any* devices without being an Apple device. In any case #nevent1q…8fpa
Better late than never. See the Proof of Payment section at https://github.com/bitcoin/bips/pull/1555/files
Yea, someone probably should. Probably one of the hardware wallet vendors who are complaining that there’s no standard and that’s why they never bothered to implement it (nevermind that it’s implemented in secp256k1-zkp and can be done at the HWI driver layer, but indeed it’s be better as a PSBT field).
LNURL-P indeed should be replaced…. But to replace it with a version of BOLT 12 reimplemented on nostr that misses out on ~all BOLT 12’s features (like, you know, recipient privacy, among many orders) just because NIH would be a massive disservice to Nostr users. #note1740…y88h
Satoshi’s doing well, thanks.
Note that QUIC is useful on the web for helping to and the multi-connection/head-of-line blocking problem. But if you aren’t fetching a bunch of resources from the same server across different streams where you can use each resource individually on its own this doesn’t apply (and it requires integration work to make it apply).
The issue with exfil is that the computer can’t detect whether the nonce is malicious or not, so it can’t block the attack. What you really want is for the nonce used to sign to be provably random, by simply having the computer add some of its own randomness to nonce, plus some deterministic message+pk hash from the hardware wallet (ala 6979). That way the HWW cannot exfil.
While you’re at it you should also include randomness from the computer in the seed generation process so that the private keys themselves don’t rely on only the HWW.
Neither of these are complicated, FROST is built around the same kind of nonce agreement protocol and including the randomness from the computer in key gen is just a matter of adding a second private key.
Please don’t buy testnet coins. If they get a price, we get testnet5.
I think the difference is that with ecash the buyer choose who to trust and only trusts them. With your setup the buyer needs to trust the seller to some extent to use their infra to log into a custodial wallet. I’m not sure that’s a great idea.
I’m incredibly, incredibly skeptical that with the amount of data we’re talking about you can even measure the difference in performance on a LAN, let alone the internet.
TLS’ only issues aren’t just CAs being a mess, it’s also an anachronistic protocol that just isn’t how you’d design something today. 1.3 is better, sure, but it carries tons of legacy garbage and most clients still have fallbacks and logic for it.
I also dislike QUIC for being a lazy, poor version of TCP. Middleboxes suck sometimes but sometimes do useful things (eg on a plane TCP is terminated before it goes to the sat, improving latency and throughput compared to UDP things with retransmissions, middleboxes can use MSS clamping to avoid fragmentation, etc). QUIC largely failed to consider these things and just said “screw all middleboxes” (compare to eg tcpinc which got similar encryption properties without being lazy). QUIC exists to rebuild TCP in user-space cause kernels sometimes suck, but for those of us with an operating system newer than five years old that’s not a problem we have. Worse, sometimes your OS has specific useful features (eg MP-TCP) that you don’t want twenty apps to have to rewrite. FFS this is literally the point of having an OS! The only promise QUIC made that isn’t as trivial in TCP is FEC, but they gave up on it cause…I dunno why.
AFAIR QUIC has the same number of round trips as normal TLS if you set the TCP options right. Basically it shaves off RTs because it begins the TLS handshake in the SYN. You can do that with TCP, too, doubly so if you aren’t using a TLS library that sets socket options for you. The claim in your diagram that you need 0 full RTs to do QUIC setup is nonsense, that’s just if you’ve spoken to the server before and it has cached keys, but the 0 RTT TLS stuff isn’t being implemented in generic HTTP stacks because of replay issues.
Errr avoid the multi-connection (and associated initial small window sizes)/head-of-line-blocking tradeoff.
It’s also implemented in secp256k1-zkp.
I think it’s required. If we’re flipping it to have the nostr zapper broadcast the zap (which we should) you need to cryptographically tie the nostr zapper to the payment proof somehow.
I can see the argument for returning the key explicitly (it’s simple, the initiating app is the payer, kinda), but it feels pretty gross (two copies of a key always bad if you can only have one). Seems cleaner to just pass the message in the original URI?
If you’re running a bunch of testing infra and mostly working with partners, I’d absolutely recommend your own signet!
I still use a 5 year old Apple Watch because there have been no new features worth spending a dollar for.
I mean as a simple v1 we could just replace it with BOLT 12 as-is? It’s pretty simple to swap in, and BOLT 12’s reusability + proof of payment means you could still announce the zap on nostr.
Modern btrfs is fine (more likely to catch a hardware error than lose your data). It was bad like a decade ago but…
Yea, I don’t think I buy that we’ll be able to get our act together enough to start cryptographically signing things for reasonable authenticity. My hot take is this actually drives people back to mainstream media as arbiters of truth.
Cool! I’m admittedly pretty surprised by that, but…cool! Most of the joint-testing I’ve seen done is on various signets (mutinynet is pretty common, signet og too, etc), and having multiple testnets that different groups use seems fine? The whole point of testnets is that they don’t have value, though…
The whole point of testnets is that any amount is equivalent. There’s no reason to ever want a whole or event 1/10th a coin.
I mean it won’t work in a browser anyway? Noise definitely the way to go if you’re building something without compat, and this won’t get compat anyway
Given the only other observers to the incident are confident it was no accident (and it follows several related incidents), I would not carry a default judgement here. There are absolutely strategic reasons Israel would have to fire on a UN position, even if they’re a bit more tenuous than the reason of “bad intelligence”.
And, yea, I’m sure we’ll never know much more. https://image.nostr.build/c78e3554a1f5bd46ca946ed13dd0a5bad70242fb602154dc01d48daf647c4172.jpg
Texas appears to finally submitting to DOE oversight by interconnecting ERCOT with the rest of the country.
https://electrek.co/2024/10/03/hell-froze-over-in-texas-us-grid-first-time/
I wonder if the initiating app in BIP 21-replacement should be able to specify that string? Probably…
Fair, Wasabi built something good too, and certainly succeeded in user adoption in a way JoinMarket never did (sadly, though for many reasons), but if we jump to a theoretical world where they both have an equal user base, I know which one I’m picking.
The web client shouldn’t be fetching the invoice, it just passes the whole offer on to the wallet and asks it to pay. When the wallet completes it does a callback to the initiating app.
TLS is a really bad protocol if your doing something greenfield. Please don’t ever use it unless you’re stuck in the web browser world.
Everyone with any tech chops always wrote off Samorai as a joke. The only reason people weren’t vocal about it is cause of how toxic all the asshats who loved it were. None of this means they should go to prison, but getting charged doesn’t mean you were the best, just the loudest and stupidest.
It’s literally front page news. It’s a big deal, but it’s definitely getting reported lol.