To sponsor (support) someone on github, even just to tip them $25, you have to hand over name and address (and use a credit card or something equally crappy). That's so shit.

Cost for a SWIFT transaction between 2 LatAm countries: $45 on sending side plus $20 on receiving side [1]. No matter how small the transaction. You also have to fill out forms on both sides and submit supporting documentation, on both sides. But remember guys, bitcoin has no use case and is slow and expensive! [1] (Before you say it, yeah i know that a more normal cost is like $30 or less for SWIFT and ~$0 for some other types of bank transfer. But plenty of the world is not 'normal' in the way you're accustomed to, and plenty of governments and bureaucracy is tied to these abysmally inefficient banking rails).

I just came up with a slightly casual thesis about Bitcoin privacy and for fun threw it at Kimi 2.6 (2.6 mind you! not even a latest model!) and said "develop this thesis however you see fit". It came back to me with a full essay that honestly is a pleasure to read (at least for me...), *at least in* how beautifully it was written combined with a set of metaphors and comparisons that were really quite original. Sure, I know, AI writing is "slop": you can recognize it and it's pretty annoying when people resort to it to achieve a goal (it feels both fake and lazy, often), but I hadn't recently just asked it to write free form: it's *probably* recognizably AI (just about), but who cares if it's *actually better than almost all writing I've seen recently about <bitcoin, or whatever you care about>!*

Did you know that Dryja's discreet log contracts are fundamentally unsound? OK now the click has been well and truly baited, I'll try to contextualize: DLCs are unsound in a theoretical sense that I'll explain; it's enough that it matters, but probably not enough that any real-world implementation would actually get attacked. To explain the cryptographic-unsoundness without going into mathematics, I think it probably helps to explain a concept "UF-CMA": unforgeability against chosen message attack. The idea is this: you want your signing algorithm to be strong enough that this, specifically, holds: if someone asks me to sign a message and (this is after all, quite common), I'm willing to oblige and sign their message, then there's no way they can craft their message-to-be-signed such that my signature on *that* message allows them to *forge* my signature on a different message. Obviously we imagine this scenario repeated, e.g. they get me to sign 16 different messages, all of which they carefully choose, before using all of that as input to create a forgery. We clearly do not want this to be true in a general purpose signing algorithm. You can prove EUF-CMA for plain vanilla Schnorr signatures: here the "E" is about the idea of them creating a signature on *any* new message, at all. EUF-CMA is generally treated as a requirement. DLCs don't use vanilla-Schnorr[1]. What they use is a variant: R is set *in advance*. A refresher on R: there is a one-time used secret value k, called a nonce, in a Schnorr-type signature, and R is the "pubkey" of k: R = kG. DLC doesn't violate the "one-time" and "secret" nature of k. It changes the protocol in a more subtle way, by publishing and therefore fixing R, before the message to be signed arrives. It turns out that this loses UF-CMA due to something called the Wagner attack (or ROS attack). I will spare you the details, but imagine just that it means: because an attacker can know in advance the inputs to the hash function, he can create a forgery by summing signatures he's given, **as long as he can control what gets signed**. (that's why knowing R matters; if he couldn't predict R, he would be unable to execute the attack because the hash output wouldn't be predictable from the message). If your DLC oracle will sign literally anything (so it has published a huge number of Rs for a huge number of outcomes), then in N (large) signatures on messages *you control*, he'll actually allow a forgery of his signature on *any message at all* (even a bitcoin transaction, should you store money at the same key as the signing oracle, unlikely I guess). Sounds pretty bad, right? Cryptographically, it is. But in practice, in the nature of what oracles are is that they control what they sign carefully. If they only sign "true" or "false" then that's not enough information to squeeze in random values that the attacker needs to squeeze in, *even if* the attacker can fully control whether the output is true or false. Even in the more plausible scenarios like, an oracle signs a price measured to 6 decimal places, there's more information for the attacker to "squeeze in" but it's all the more impractical for an attacker to control the outcome that exactly. The oracle has to be prepared to attest to some huge number of outcomes, *and* the attacker has to be able to fully force the output he wants. And to repeat this process. So this leaves us in a funny situation: it is reasonable to assume security of the construct from the point of view of "the oracle can be trusted not to sign just anything, or some large number of weird message that don't correspond to reality (real price, real temperature), and that's why we trust it's not going to get hacked", that is, your trust is not in the cryptography, but in the identity behind it. But that's the "oracle problem" anyway; even if the cryptography didn't have this weakness, you'd still have that same trust. I *do* think it's dubious, though; such a theoretical hole is very undesirable. Attacks *tend* to improve over time. The rest is more techincal, feel free to skip: Postscript: you might be thinking, damn, this Wagner attack is scary, if you can just make a forgery from a bunch of pre-existing signatures .. maybe you can do that with normal Schnorr like in BIP340? The answer is: using *deterministic nonces* elegantly avoids this attack, even if making fresh and unpredictable nonces didn't (it does). If the nonce is generated from a hash of the message and the private key it cannot be derived in advance in any way by the attacker without knowledge of the private key, which makes the attack moot. The only other "nonces are pre-prepared and handed out" case is that of MuSig2 (and iirc FROST); in those cases the defence is specifically connected with a clever "contextualized nonce" : R1 + bR2 where b hashes the *context* of the signing event, including the message, which prevents grinding. This extra defence was created *specifically* to address the Wagner threat, which otherwise would be even worse for the collaborative protocols than the single signer one. What you should take away is: default Schnorr is tremendously nonce-fragile: it's not even enough for it to be random; it has to be secret before the signing event! [1] You can say that it does, but I beg to differ. Vanilla Schnorr is the canonical sigma protocol and follows the pattern: commit, challenge, response, with R being the "commit" step and "P" being the public context of the protocol execution. In DLC R is part of the public context, and what is the commit step? (there isn't one, I guess). Obviously this is very abstract but it's probably the right way to understand why the security hole exists.

I love these new AI tools. It seems like most of us do. But let's be real, so many of us are going to get disastrously owned. It's a security nightmare.

The European Commission is turning Google Search into a privacy and national-security risk

The European Commission is preparing to compel Google to stream search data to third-party companies through an automated API.

The oh so virtuous European elite care so much about privacy and reducing the power of US tech companies that they are ... giving random other foreign spies, sorry, companies, access to private information of all their citizens, wait what? (Story's actually a little more nuanced but the author explains how the protections can be worked around trivially. Worth reading.)

I've said this before but given "current topic", time to say it again: pattern-matching to the 90s winning of the crypto wars is just wrong. The political forces leading to full ID and monitoring of every digital event is inevitable, and **the advent of ZK technology is going to make it happen**, not prevent it. Why? Because the academics' argument of "golden key"/"key escrow" being fundamentally flawed won't matter: the political will is there. Example: right now, a large majority of the UK public support social media controls for kids, and don't focus on the freedom violation this implies for themselves (ID verification). They will grumble, because they don't want ID cards, but online they'll accept it, because they've already accepted that ID verification is good, not bad, for online discourse, they are all using Apple, Google ID systems ... they've already accepted it should be used as a gate for even financial transactions; hardly a big stretch since they've accepted full slavery w.r.t. their bank accounts. This might be affected by how few people in the UK have any wealth at all except in their house (if they're lucky enough to have a house). ZK and FHE will accelerate this from crude ID verification into full on filtering: you can do secure communication, that will be allowed with sanctioned providers, but it will be proved "safe" using various techniques (I mention ZK, FHE to show the advanced version: your e2e chats will be filtered for child porn/terrorism/criticizing the govt, while still fully encrypted). I see no version of the future where this doesn't happen; it's just a matter of time, and admittedly it could be a very slow process. If we still care about freedom we should look into full disconnection: p2p, mesh networks, steganography where it can work. Am I hopeful? No, I don't see a good reason to be. Perhaps only a very dark future involving a lot of war can stop this inevitable flow towards digital tyranny.

Testing!

Btw does @npub16g4u...kv4h still not allow the models to web search (seems so)? Is that limitation coming from API access?

Had a fun time in Oslo for the Olso Freedom Forum conference last week. Thanks to @gladstein et al for inviting me. Really well organized event. There were a *lot* of Bitcoiners there (and nostr-ers of course).. I spent most of my time nerding out with people about Bitcoin stuff so didn't pay as much attention (though, a little) to the political talks/reports. Obviously AI is "the new hotness" and it feels like, to develop a theme I occasionally opine about, the real story for me is access to compute: it's defining what power is, more and more, in the new world. I'm probably one of many many people that are spending a lot of time worrying in the background about how communication channels are getting more and more corrupted by the new vector of power which is access to datacenters. I stated here, years ago, that I thought open source software is going to win in this field, but to this day I am doubtful about whether the power asymmetry of data center access is resolvable. Perhaps the answer is in compute power distribution, as it was/is for Bitcoin mining.

Btw, there's something delightful about seeing people earnestly and genuinely asking, on twitter, "maybe the zcash devs can figure out a way to *prove* in zk that the coin supply is correct?". 😂 Reminds me of that old book about string theory - some ideas are "not even wrong"!

Who are you gonna believe, me or your lying APIs? - Groucho Marx, probably

Doomer thought for the day. Satoshi said "You will not find a solution to political problems in cryptography. Yes, but we can win a major battle in the arms race and gain a new territory of freedom for several years.". It has been a lot more than "several years" now.

I am often drawn to remembering an article by Izabella Kaminska from late 2013, with the striking title "Is this how fiat currency dies, with thunderous CPUs?". Kaminska's 2013 vintage articles were equal parts hilarious (in her technical incompetence) and thought provoking (a genuinely reflective person a million miles from the cypherpunk ethos honestly grappling with bitcoin in a way that no other mainstream commentator did). And in this article she clued in to the real heart of it (sorry I can't find the original text, but anyway it was the title that already captured it). To this day, the trend towards a world dominated by compute power gets ever stronger. When I think about ways to help humanity ("tools for the people" as Amir used to say) in this approaching cyber/cypher-dystopia, I keep coming up against walls made of "thunderous CPUs". If we don't find ways to get distributed compute working in the presence of the censor, I'm not sure anything else will really matter that much. Note that Bitcoin already does that, but (a) mining's centralization tendencies are causing non-trivial fragility and (b) Bitcoin is not general compute, so we can't somehow leverage mining infrastructure. Btw you might be assuming I'm talking about AI. I am, but not only. I think even any form of free communication may require compute power in future.

Steemit actually still exists.

Steemit

Steemit

Communities without borders. A social network owned and operated by its users, powered by Steem.

(Still, more surprising that Ripple still exists tbh.)

What if the next Satoshi Nakamoto and rhe next Ross Ullbricht are not human?