waxwing

Bitcoin, cryptography, Joinmarket etc.

Public Key

npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7

Profile Code

nprofile1qqsxwkuyle67y94tj378gw8w2xw2wa6nwmwlqhddlwnz0z7sztsaw2qpzpmhxue69uhkummnw3ezuamfdejsz9nhwden5te0v96xcctn9ehx7um5wghxcctwvsq32amnwvaz7tm9v3jkutnwdaehgu3wd3skueq6e6vpk

Publishing to

nostr.wine

atlas.nostr.land

eden.nostr.land

Author Public Key

npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7

Show more details

Last Notes

2026-03-01 11:58:29 UTC

- reply

Is it better than claude, chatgpt, kimi for this kind of thing? I'm talking about cryptography, let's say.

2026-02-03 23:26:38 UTC

- reply

Sorry on reflection that was a bit dumb; a ring sig wouldn't allow apportioning blame either. I found the old coinshuffle paper to be quite insightful on this difficulty.

2026-02-03 18:25:37 UTC

- reply

Ah, i see. By using all|acp you have the 'crowdfunding' workflow, so the output set can be ... set ... in advance of the input set, so people can send their signed inputs independently of the other ones.
There's one complicated detail I see: in your example you have Carol fail-to-deliver on the inputs, and then the re-start with the other two, and the ring sigs allow them to demonstrate they were part of the original set, right. But in the case where the coordination fails, not because of failure-to-deliver but because of inputs not matching with outputs, you have the problem of not knowing who is at fault, right. Not saying you *have* to solve that problem, not sure, maybe.

2026-02-02 22:28:12 UTC

- reply

Interesting. Definitely people have talked about this kind of approach before. A couple Qs: phase1 and phase 2 are disconnected at the network layer, right? so phase 2 A and B send a psbt with their inputs signed, is that right? Yes I think this all makes sense. At phase 3 (network disconnected again right) you're, by ring-signing, asserting you were one of the phase2 participants and that you authorize the use of one of the addresses (it says A' in phase 3 but address is A?) for output. Are you using linkable ring sigs? (to avoid ability to make 2 valid ring sigs on same pubkey). Hmm now I look more carefully I'm not sure I understood the A' vs A distinction, because is Phase 4 for normal operation or fallback? If it's normal operation, what does Phase 1 do?

2026-02-01 16:07:58 UTC

- reply

Sure, let me know, always up to chat :)

2026-01-30 01:52:57 UTC

Oh, and in case you were wondering, isn't something like witness discount similar? The answer is a resounding no! Think about it - what the witness discount controls is *how much stuff can go into a block* and is therefore a *global* consensus rule. If miners break it they fork off. Here what the ZIP is discussing is having everyone sing kumbaya and agree what kinds of fees are fair, reasonable and keep good privacy and ddos resistance for everyone. It'll work fine, until it doesn't.
#nevent1q…4gl3

2026-01-30 01:51:48 UTC

I discovered something quite remarkable today after seeing podcasts with Sean Bowe [1] describing the new tachyon system and then one today with Ying Tong [2] mentioning the fabled 'sandblasting attack' . It turns out that zcash put out a ZIP zips.z.cash/zip-0317 with what seems to me extraordinary content: it says not that there is some resource limit for blocks, but that individual transactions *should* be treated thusly: fee should be linear in number of ins/outs, but 2 outs should be treated like one (for a privacy reason), that certain types of transactions (their different shielded pools) should not be discriminated, and they disrecommend relay of transactions with other fees, and then give a long RECOMMENDED section to miners on how to construct blocks. This is totally nuts - the miner incentive is always to maximize fee revenue, and while it can be hard to work under that scenario sometimes, it's crazy to try to say things like randomize your candidate transactions and only take high paying txs in this ratio, or similar, as they do. Bear in mind that the sandblasting attack, which genuinely crippled the network afaik because they couldn't verify, in a normal node, as fast as the attacker could create transactions, happened because they had the insane idea of a flat fee for every individual transaction, no matter how big it was! (to be sure, they must have done that for better privacy, but it's an utterly broken concept).
These are some of the very smartest cryptographers in the world, and I am not exaggerating for effect, there. How did they get such batshit insane ideas (or lack of ideas?) about how a permissionless p2p network works?
[1] its on the recent Zero Knowledge podcast, look it up, [2] the recent BTCKVR podcast 'BitVM optimizations', around 35 minutes
#cryptography #bitcoin #zcash

2026-01-20 19:54:49 UTC

https://eprint.iacr.org/2022/1178 "We propose a new, unifying framework that yields an array of cryptographic primitives with certified deletion. These primitives enable a party in possession of a quantum ciphertext to generate a classical certificate that the encrypted plaintext has been information-theoretically deleted, and cannot be recovered even given unbounded computational resources." 🤯
#cryptography

2026-01-19 12:47:52 UTC

https://files.catbox.moe/qgy1ni.pdf
Perhaps it's a bit silly but I show here the full conversation I had yesterday with Claude, in which I asked it to teach me Groth16 (the most famous ZKP system). It's a little cheat-y in that I had already "overview" studied it, more than once, but I always found the existing explanatory materials difficult to work though and lost track at some point. This time, with Claude actively teaching me, I can confidently say I have a solid understanding of the whole system, after one single day.
In my opinion LLMs are great for these things: Search, learning and language (incl. code). They can seem ludicrously brilliant at all of these, but in each case you have to be wary of different variants of the same flaw: their inability to notice their weakspots. In learning Spanish I get 97% perfect explanations/answers/translations, but with certain obscure slang it might resolutely refuse to accept the existence of the phrase I'm referring to. In this Groth16 conversation it slips up with a specific equation/algebraic notation (it says it was 'sloppy'; I'd say it was wrong) halfway through, in a way a human professor wouldn't. In search I'm not as sure as I don't use it as much, you could argue semantics and say it's not really the one doing the search, but I bet it slips up in a similar way there too.
I don't think this kind of flaw is the real story, though. The real story is that if you frame your request properly, and you engage seriously and reflectively, you have access to a teacher that a decent simulation of a high-level expert, in a one-on-one session. If you actually want to learn something, I do think you should do as I did here and ask it to "teach me X based on the fact that my background is roughly Y (so it can pitch at the right level), and ask concept-checking questions along the way".
(btw this is not a commentary about claude vs others .. i think this kind of job can be done ~ equally by all the latest models).
I have to emphasize how natural this felt. I really felt like I was talking to a teacher that was listening carefully to my responses and engaging with them. Among a number of notable moments in the conversation, this one in particular, after the aforementioned algebra screwup, stood out to me: I asked "yes. back to Q13. rewrite it if necessary, otherwise I'll just keep thinking." and it responded after a few seconds: "{Claude:} The question stands as is. Take your time."
A reasonable push-back on this example is that I chose something that has been described and discussed on the 'net a lot over the last 8+ years - certainly no other ZKP system has as much material. So it's showing the best it can be. If you discuss cutting-edge research with it, you're in *much* more dangerous territory.

2026-01-18 23:37:30 UTC

- reply

I think it depends how far it goes.
At the extreme a perfectly trustless sidechain or rollup of some flavor will be the best way to transact with bitcoin. Actual scalability and privacy.
What they're aiming at right now is, I agree, just a high tech implementation of a bridge with maybe better security properties than those that already exist.

2026-01-18 18:51:00 UTC

- reply

Oh you said improve not remove. OK. Seems like a performance difference not a trust difference.

2026-01-18 18:49:58 UTC

- reply

Right. But does it actually remove the DV part? It's still describing a protocol between a prover and verifier, and it's still describing use of a 2PC between them, just the circuit they're garbling is a much different and simpler one (in fact so simple it's just a single multiplication). So the verifier's secret needs to be there at setup, so it's a DV.
Correct me if I'm wrong. Paper is huge 😁

2026-01-18 12:43:26 UTC

- reply

About extreme scenarios like 80% of btc stolen (- I'm going to ignore the "how do you measure it" part, though I suspect that'll come back to bite us at some point!): i mean there is presumably a failure mode where trust breaks down, but it's not really about a specific number or ratio. It's about whether there's any credibility that going forward, the system will be trustworthy. Anything above 30-40% is presumably disaster-level and the project *might* just kind of fall apart. But I really don't know. I just know that if you violate the core principle of private property you've mostly already lost. Maybe I'm wrong and everyone would love it, but what's the point in bitcoin in that case, I don't see it.

2026-01-18 12:38:14 UTC

- reply

On the DAO,ETC,ETH and my "bet": excellent point to raise, there. There is no doubt that the opposite side to my argument won. At the time as you'll remember it was just as obvious that it wouldn't have happened in BTC because of the "DNA" of what bitcoin even is, being so tied to uncensorability (let's not forget that it's a bit murky whether anything like "consensus" was actually reached in the ETH community; it might even be possible to characterise it as the equivalent to the new york agreement winning in btc's case; but I'd be willing to cede the opposite is possible, that the DAO coin "reassignment" was a community consensus). The DAO disaster just showed that there was a profound divergence between the communities at a not just technical but philosophical level. So yeah, another project which has a different less pure concept of decentralization might reasonably define cutoff dates, but I don't think BTC should. It's against its nature and purpose. Concretely, the tradeoffs bitcoin's design makes (e.g. no onchain obfuscation; no onchain global state and complex contracting; slow block times; etc) are all in service of that. I know that this is a retelling of history - SN didn't seem to see it quite like that, but somehow designed it like that despite himself, lol.

2026-01-18 12:28:18 UTC

A bit of an update/nuance on the below, after continuing to read more about this new field: it's a valuable correction to say "this is not just like a federated sidechain: you can get a 1 out of n trust model, not only a majority/quorum". indeed, you can, though i would caution that you have to reflect on the security limitations of having a designated set of verifiers, even if only 1 of them has to be honest (I think that model is not bad at all for setup, but for continuous operation it's not so great; think: "men with guns"). Also worth noting that a related paper was released shortly after, using a different trick (witness encryption, pretty exotic stuff) but based on the same general ideas: https://eprint.iacr.org/2026/065.pdf
#nevent1q…0dmy

2026-01-17 15:33:16 UTC

- reply

i disagree with that framing at the end, it feels illogical. it's not necessary for everyone to agree on what level of security to use, it's a lot more nuanced than that (trivial example: hashed addresses vs not, pre-QC consideration; it was never a trivial question. Remember Nicolas Courtois' scaremongering?). And there is no requirement for any specific users to move out of existing coins to be able to say "bitcoin has the functionality required to keep your coins secure". bitcoin has never yet required people to move their coins, don't forget. And to illustrate more concretely, the part you put in quotation marks: that describes me, I think that, but I don't agree with what follows: I don't prefer the fork "with fewer coins sold", I think that's a non sequitur (not that it can't follow, I mean that it doesn't logically follow), *and* I think it's the ethically wrong position, too, *and* I think long term it's a vector of failure for the project in its goals.

2026-01-17 14:21:59 UTC

- reply

I disagree about fork choice. People will choose a version of bitcoin where there is zero human governance over coin issuance and coin ownership. If my bet is wrong there is very little value left in bitcoin as a system.
It doesn't matter if Bitcoin "looks like chumps" or whatever. It matters that it has integrity as a system. "Miraculously" it has somehow maintained that for a long time.
I do agree though that it'll be a disaster if we don't have any viable migration by the time QC hits, but, meh, it seems ridiculously far off. Glad some people are working on it.

2026-01-17 13:14:52 UTC

- reply

I see several things wrong with this pov. First, stop assuming they're Satoshi's. We don't know that. Second, when/if they are spent, we won't know how the private key was known to the spender. Quantum's existence won't change that epistemic limitation. Third, there is no "we" to make such a choice. No group of people have the right to confiscate coins, no matter how rational the reason.
And to *anyone* (not Matt specifically) who is worried about the market effect of huge selling, consider the market effect of the precedent of freezing coins at the protocol layer. Everything is a one-time exception until it isn't.
Notice that that last point is not wrong because "if QC then all btc is worthless"; we are discussing the scenario of there being a migration path but old plain pubkey holders don't use it

2026-01-17 12:14:40 UTC

A second round of Glock review/reading to better .. grok? .. what the hell this stuff is. The TLDR is that, afaik, there is still no there there. I don't mean that this research isn't incredibly impressive and exciting; at least to my dumb eyes, it is. I mean that it hasn't created the dream scenario of verifying arbitrary off-chain contract execution with negligible onchain cost. It *almost* has done this: it allows you to verify a SNARK, post the proof somewhere offchain and have people be able to punish you onchain if you lie. All that happens without nasty onchain costs like in BitVM and similar. But there's a crucial detail: the SNARK we're talking about here is "designated verifier"; so it's not public verification, it's more like a sidechain where you trust an entity or a federation to enforce the rules. Obviously, that in itself is not really interesting to most people.
The new follow-up "Argo MAC" paper ( https://eprint.iacr.org/2026/049.pdf ) is really in the weeds (though if like me you find Elliptic Curve endomorphisms interesting then .. it's fun!) but it *does* change the above crudely described system from "impractical" to "probably completely practical" - because the garbled circuit stuff suddenly went from 100s of GBs to 10s of MBs. But the DV- nature of the SNARK is not changed by it .. so the open question is "can you replace the DV-SNARK with a public verifiable SNARK" and I have no idea of the answer except, the verifier circuit has to be small and that's .. hard?
if anyone out there (not *that* unlikely) can correct or refine that description, I'd be grateful.
#cryptography #bitcoin

2026-01-14 22:17:36 UTC

- reply

Agreed.

2026-01-12 14:28:16 UTC

- reply

https://old.reddit.com/r/LocalLLaMA/comments/1oqi4qp/comment/nofbwx1/

2026-01-12 12:47:41 UTC

- reply

For completeness:
In response to "we will come back to this, but first, i'm disappointed that you have the same "AI slop" writing style as other commercial models (no real problem in communication, but stereotypical). i'm curious, what is the origin of this LLM model?" it said "Fair. I'm Claude 3.5 Sonnet, built by Anthropic. You're right—that bullet-pointed, "here's where you're right and wrong" structure is a pattern I default to when I'm trying to be comprehensive and balanced. It's the LLM equivalent of a corporate presentation: clear, but soulless."
Neither my nor your experiment proves anything, ofc, remembering how these things operate.

2026-01-12 01:54:21 UTC

- reply

Not too surprising to see variation, in itself. I think I asked it which LLM it was, and it was quite specific ... Claude 3.5 from Anthropic.

2026-01-11 13:01:04 UTC

- reply

I asked K2 what model it is and it said it was claude 3.5.
Is it like an open source version or something? Hmm that doesn't make sense.

2026-01-10 16:44:05 UTC

- reply

Right. If the content is actually tied to your personal life it's gonna be super tough. There could still be value in separation between sessions though, so, tor could be something for that.

2026-01-10 12:41:45 UTC

- reply

I have run open source LLMs locally for free. The performance can't match, not even in the same ballpark (hence me mentioning $20K etc) ... or did I misunderstand you?

2026-01-10 12:16:35 UTC

Maple.ai via Tor with anon account paid for with Lightning.
I think this a decent tradeoff against the appalling reality of what most of us are doing giving personal data to OpenAI, Anthropic etc.
The at-home build isn't viable for real work except if you pay like $20K and sink time into it (and even then).
Also I'm not shilling maple here .. it probably can't give you the same level of convenience etc. But maybe close, I think?
Opinions?
#asknostr

2026-01-08 15:26:01 UTC

- reply

Lol, yes, you got it. The gender bit is dropped :)

2026-01-03 18:57:59 UTC

- reply

Right, it's certainly fair to question everything from that perspective. Trump's is acting 95%+ from the perspective of US interests, which isn't going to (necessarily) align with Venezuelans' interests.

2026-01-03 18:36:06 UTC

- reply

I live in south America and even before this event, the diaspora (which is enormous on this continent, guess why) were massively in favor of his removal by force.

2026-01-03 18:31:59 UTC

- reply

'Do they care about Venezuelans?'. Do you? Are you paying attention to the reaction of Venezuelans?

2026-01-02 23:38:33 UTC

- reply

See Peter's reply. Very plausibly new EU regs are involved, though I'm just guessing.

2026-01-02 23:33:02 UTC

- reply

Yeah sorry can't fix it rn.

2026-01-02 23:20:42 UTC

- reply

Bit too much, prefer not to say more.

2026-01-02 19:35:24 UTC

- reply

Yes, I am 90% sure this was the cause - though as you know, we are forced to guess!

2026-01-02 19:01:40 UTC

- reply

about the LN fees: it's a bit more than a nice starter I think! it would make the system an order of magnitude more useful imo (no fee fingerprint on chain) but I'm curious what you have in mind for how it could work. The way I saw it you essentially would need something equivalent to a submarine swap but with privacy, which means adaptors, which means PTLC and taproot and Schnorr (I'm thinking: payment secret is revealed by publishing signature for coinjoin). Even if that line of thinking is coherent, it's not only complex to implement, but relies on things that don't exist. Perhaps it could be done with ECDSA adaptors, which do exist, but .. well I hope it's already obvious why I always saw it as kind of "out there". Do you have something simpler (or just, better) in mind?

2026-01-02 18:16:57 UTC

- reply

Ah some nice stuff in the README, like it!
Thoughts on Lightning network integration that you mentioned alongside CJXT, there? A number of different things are possible, I'm curious what you're most interested in.

2026-01-02 18:12:38 UTC

- reply

I wish I could say no company in the past did this ... but at least you didn't use to hear about it so much with retail services like this. Sigh.

2026-01-02 18:10:45 UTC

- reply

Nice to see! Apart from the code itself, did you have ideas about changing things architecturally? Thinking especially about the communication layer.
Well anyway I will read your repo a bit :)

2026-01-02 18:02:19 UTC

Warning: do NOT use travala.com any more, if you did.
They directly stole my money.
Here is my response to the customer service agent:
(Customer service agent),
> Sorry for the delay, im ahmed from compliance department, for refund or either processing the booking, the verification is a mandatory step, we require the minimum and basic info for that, and you can pass it easily through the following link : <snipped>
Let's establish the facts: I have been a regular customer of Travala for years, have done probably a hundred or more bookings through your site - mentioning this *not* to claim some status as a customer (which I do not want, and do not have), but to point out that ZERO times on the website or through any of those transactions was it mentioned that you could simply keep my money and provide no service - i.e. STEAL my money - if I did not pass a verification process -handing over extensive and intrusive personal documents - that you never documented anywhere. And indeed for this booking, again, no such advance warning was given.
So you (that is to say Travala, not you personally!) act exactly as a kidnapper: to give me back the money which is mine, you insist that I hand over security sensitive information. Which I will not do. There are an endless stream of documented violent theft events of cryptocurrency holders, so spreading one's personal information is stupid, and any claim you make to "keep my data safe" is ridiculous, given the equally endless stream of reported hacking events. I do not trust your company with my personal information because I don't trust *any* company with it.
I have been doing Bitcoin development work for over a decade, I will make sure that a lot of people in the community know that Travala steals its customers money, directly, with no apology.
Feel free to pass this message to any management, I would appreciate that.
(me)

2026-01-02 16:43:40 UTC

- reply

Right, understood. I think it's enough to just document the choice, though personally I think desktop wallets should always have an encryption option, I do understand that Liana is principally targeting HW signing, right.

2026-01-01 14:15:59 UTC

- reply

Also, on reflection, I don't really agree with the characterization "only defends against a narrow set of attacks". To me, it's a broad and significant set of attacks that are defended against with encryption at rest: the most likely way to get your secrets stolen is for someone to get access to your physical hardware (stolen laptop; evil maid attack), or perhaps getting access to backups of your filesystem. True that someone actually taking control remotely is a big risk too, especially on Windows, but that is such a catastrophic failure mode that nothing matters .. not a good excuse to have zero defences imo - people regularly assume some level of security at least on MacOS and Linux and they should be able to, I think. A desktop is not a phone.
Anyway all arguable I guess. But not giving the option or any warning - I don't see a justification of it, really.

2026-01-01 14:06:59 UTC

- reply

I agree that an unencrypted wallet is a defensible *option* - e.g. Electrum iirc allow you to not set a password (many wallet don't allow it). But I can't see a rational reason to just not offer the option? It's not like the user is warned that their mnemonic is sitting in plaintext on disk.

2025-12-31 15:41:15 UTC

- reply

Yes, all good points, but even technical or somewhat technical people seem to think it should be essentially free. I've never quite understood why that mentality is so prevalent.

2025-12-31 13:31:52 UTC

Phoenix can't be mentioned in the same sentence as the others. It's an actual self-custodial lightning wallet that works, seamlessly. "Outrageous fees": as an experiment, I went through my last 5 transactions. Tx1: $2.22 fee: 14 sats 2: $142 fee: 643 sats 3: $141 fee: 641 sats 4: $586 fee: 2644 sats 5: (deposit on chain) $1555 fee: 210 sats. Does that seem outrageous to you? The $586 payment had a high fee of a little over $2, which is like 0.3%; Lightning is like that, it's percentage based. But "high": this is way lower than many other payment methods, and it's instant, sovereign and mainly private.
Overall it's crazy to me that for years now, every time I recommend Phoenix, saying the actual tradeoff is a slightly worse privacy model (but really not bad), I hear people dismiss it as "crazy fees". Just because immediate onboarding (which is a one-time event) to an actually self sovereign wallet costs a couple of bucks doesn't mean "crazy fees"! You don't get everything working perfectly for zero dollars, sheesh.
#nevent1q…4883

2025-12-30 21:16:17 UTC

- reply

Felicitaciones!

2025-12-28 12:07:14 UTC

- reply

I don't necessarily disagree but you *can* make an opposite, or at least different, case: subjects based on physics, math and related are a lot more exposed to the possibility of AI-made redundancy, than services jobs (so like your oil and gas example, but think of all the things like medical and educational 'care' expertise). I think maybe the most exposed to danger are in the "middle" between extremes: call it "office work" perhaps.

2025-12-27 21:31:36 UTC

- reply

But the usd value is completely canceled out in the equation.

2025-12-27 18:26:46 UTC

- reply

Where can i find this?

2025-12-26 17:13:14 UTC

- reply

I think you make a very fair point that the practical reality of privacy on LN today is a lot better than it would be under fully adversarial conditions. There are some glaring weaknesses as people like Matt Corallo will point out. But it will get better with increasing volume, and if we ever get ptlc. And being a *real* L2, warts and all, it has great properties for everyday small scale use.

2025-12-26 14:49:44 UTC

- reply

Yes the wallet fingerprinting stuff sounded kind of crap/BS. But if you asked them they'd just say "oh yes but our system is much more sophisticated than that; we can't tell you more because it's proprietary". And while *that* is BS, it's also true that the principle of multiplicative/compounding on fingerprinting is unreasonably powerful (see: browser fingerprinting etc.).
I strongly agree that LN is an exceptionally good tool for privacy despite its (imo heavily overblown) limitations. But my general comment was about the "move large amount through anon technique X" and that comment very much applies to LN too.
I guess your "Wasabi is a perfectly good wallet" was more aimed at the article than at my comment about it, but yeah, I agree that this is not evidence against Wasabi's utilty.

2025-12-26 12:22:52 UTC

- reply

No, that's not the story.

2025-12-26 12:22:29 UTC

- reply

Interesting doc. Obviously you have to get past the "proprietary techniques" blatant self-promotion that is typical of these guys, as well as the constant "Russian" "high-risk" language designed to ping high $ value government contracts, but at root the story they're telling is a familiar one: criminals trying to move high amounts of money through coinjoin find both a kind of success and a kind of failure: the success is, they can find a way to move the money before it gets found, basically it's usually through exchanges that aren't doing the whole "coinjoin flagging" thing. It's still never going to be easy for them to convert it to something in the real world, but it's at least possible this way. The bad side is that the pattern of usage "take a huge chunk of coins and put them in <insert your favorite anon technique> and then, shortly after, shove all of those coins into a specific offramp venue" has the problem that *just* timing correlation and amount correlation already provides a huge red flag, and then the investigator just needs to find more metadata clues that are inevitably lurking around. These problems even exist with e.g. zcash, monero (perhaps I should mention Liquid?). Of course it *is* worse in Bitcoin - e.g. the "gridchain case" where a bunch of money moved through joinmarket but when it was funneled, outwards, through an exchange, they sent ~ all of it to the same address!

2025-12-19 02:44:25 UTC

- reply

It's definitely worth researching but the cost of implementation might be really high.

2025-12-18 22:37:02 UTC

- reply

The problem is, does *anyone* have any clue, at all.
I keep pattern matching to nuclear fusion in the 80s, which would mean the current panic is ridiculous. But that assessment itself could be ridiculous; I don't know.
I am suspicious generally of advances in fundamental physics, that field went from breakneck speed in say the 1920s to an enormously expensive waste of time by around 2000. Arguable, of course, but still.

2025-12-12 11:16:30 UTC

- reply

Yeah not working atm sorry

2025-12-11 14:49:30 UTC

An ignored part of the current quantum computer fud^H^H debate, because it's a counterfactual: back in 2015-17 a lot of people got very excited about a proposal from Greg Maxwell to do "confidential transactions" on bitcoin. I was very much in the group of people both fascinated and excited about the prospect and went very deep down the rabbit hole on it, learning a lot about cryptography along the way.
But the energy to even suggest a fork to include it slowly dissipated; my own personal reason for rejecting it was *not* the obvious "the range proofs are too large" (see: Bulletproofs, work that was heavily inspired by that scaling problem, though it ended up being far more significant w.r.t. "folding"). It was "pedersen commitments are only computationally binding" [1], to put it another way an EC break means we get unbounded, invisible inflation. At the time it was fun to predict that Zcash had this failure mode and indeed it was borne out (look up their history if you don't know). It felt weird justifying this to people sometimes: "I don't want a bitcoin where amounts are not visible because the total might not add up" sounds Luddite ... I remember being asked on a panel by Giulia Fanti "are you scared that P=NP or something?" ... it was not felt to be a quite logical thing to worry about this, since we rely on EC in Bitcoin anyway ... and if we trust EC, the math of homomorphic commitments *guarantees* it adds up!
But a computational bound on that is not OK. i.e. i don't want *any* computer to be able to break it! not just normal computers! - and that's exactly where a quantum computer comes in. I am FAR more worried about breaking bitcoin's fixed supply than about a million old P2PK coins getting stolen. Stealing is not minting.
[1] A counterpoint is that ElGamal commitments exist, at the cost of even more space. But hey, it's still less space, by a huge margin, than current post quantum signature schemes! Something worth considering?
#cryptography #bitcoin

2025-12-08 18:14:26 UTC

- reply

Pretty sure it's deliberate. Despite quite a few people (especially users!) complaining about it.

2025-12-08 13:58:00 UTC

Linux desktop stuff is such a mystery to me. This honestly seems batshit insane, but in GTK3, it appears that if you use a FilePicker, something like (Rust here but w/e):
rfd::FileDialog::new().set_directory(&my_specific_dir).pick_folder()
... it refuses to open the file picker in your specified directory. It just flat out ignores you, and *always* opens the dialog in its "Recent Items". So not complaining about a default (though it's a terrible one honestly), but the baffling decision to just ignore the developer's setting. I would love to find any justification of this anywhere, but I can't. This "documentation" ( https://docs.gtk.org/gtk3/method.FileChooser.set_current_folder.html ) just points at a non-existent other documentation section to justify why you shouldn't use the function (Not "deprecated" but "warning, you'd better not use this function, but we won't tell you why!"). The code itself basically defaults to recent items, and that can *only* be overwritten with a GTK setting, outside of the developer's control, and here's the best bit: if you somehow get your user to override it, they can *only* change the location the FilePicker opens in, to $HOME! Your directory setting will still get ignored!
Btw this restriction did not exist in the previous GTK version; they actively added it as an improvement.
#linux

2025-12-07 12:22:25 UTC

- reply

That's exactly what Lightning excels at.

2025-12-06 20:02:58 UTC

- reply

Afaik for QR ZKP tech you have STARKs and that's about it. Because they're hash based (which ofc doesn't quite mean 'impervious to quantum algos' but more or less does mean that in practice, as currently understood).
As for the actual proposal here re:bip32 and proofs, it feels a bit wrong to me but I'd have to think it through.

2025-12-05 12:35:26 UTC

- reply

You're 100% right but there's a crucial to understand change in what banks are today vs 150 years ago: they are no longer businesses serving their customers, they are agents of state power (their actual customer is the state). It changes everything.

2025-12-02 19:02:52 UTC

- reply

Schrodinger's quantum threat.

2025-12-01 14:24:00 UTC

- reply

The last good thought Taleb had before he lost the plot 😁
(Antifragility does get horrendously misused though)

2025-11-30 16:52:59 UTC

- reply

Right. I think we're correctly identifying that the issue is: the syntax/semantics distinction as I like to describe it, or the rules/censorship distinction have the problem of a somewhat blurred dividing line. In my human laws example, the "hate speech" law in the UK is now protocol or "consensus" as per bitcoin's lingo, but that doesn't make it OK. Because it's a law about something like "what you are thinking" it's not actually viable; it has already created monstrous outcomes. So it's not that I'm saying you're wrong that "if it's in the protocol/consensus rules then it's not censorship by narrow definition", but I also wouldn't blame people for saying "come on, just use common sense! that's censorship!". It's probably not a very valuable discussion, except maybe to say "there are two different ways censorship could happen; but having censorship *in* the protocol rules is even far worse than the other (normal) type!".

2025-11-29 13:31:15 UTC

- reply

So to rewind: what you were pointing out at the beginning is that the only things that are "banned" properly, are banned by rules, which is the protocol: the protocol is the rules. When people talk about bitcoin being "censorship resistant" they're talking exactly about how hard it is to have *other* rules (call it "soft banning" if you will), ones that are *not* in the code. OFAC e.g.; we're hoping that the way mining works prevents an OFAC rule becoming de facto (though not "de jure" in code). My "semantics vs syntax" distinction may not be the only way of framing that, but it's the one that I find most resonant, we see it very clearly across modern human society. When it comes to human language/society laws, a good example is "hate speech" laws of the type seen in the UK: it's a law about semantics, not about syntax, in my framing (and it's to my mind the rubicon which a government can never cross). In a Bitcoin context one can similarly *attempt* to create syntax rules that control semantics, but they will always be ineffective ("pissing in the wind"), and most likely also very deleterious. As I've always said, trying to ban spam is imo *both* ethically *and* technically bankrupt. It's not going to work. Instead, try to make bitcoin the best money it can be.

2025-11-27 23:01:11 UTC

- reply

Yes. Syntax means only certain patterns are allowed. But the protocol (English) makes no judgement about the purpose, or meaning, of valid combinations of words (the semantics). This distinction represents the correct analogy here.
Bitcoin's protocol gives a syntax for financial state transitions, but doesn't judge whether they are acceptable state transitions. The problem is that semantics are not absolute like syntax is, and it's a fool's errand trying to control semantics. If you ban "fuck" another word will be "co opted" to somehow be equally offensive. Protocol rules control syntax, not semantics.

2025-11-27 17:08:44 UTC

- reply

I'm slotting 'English language' into your statement about protocols.

2025-11-27 16:40:09 UTC

- reply

Compare with the English language.
Is English defined by the data not permitted?
There's a reason "syntax" and "semantics" are 2 different concepts.

2025-11-25 21:22:43 UTC

- reply

I don't think any reviewer should have a responsibility to justify in detail why they're not accepting a PR, or why they're choosing to spend more time to review one and not another.
I mean, heck, it's going to happen right - a PR from sipa vs a PR from Joe Bloggs.
I think your point about the analogy isn't as clear as all that; the analogy would be more with setting policy and less with what constitutes a valid transaction (that's more, does the syntax of the document even satisfy the definition of a BIP).
If the problem with AI drafts were *only* volume we wouldn't be having the same discussion, nor using terms like slop.

2025-11-24 21:22:13 UTC

- reply

Also: I feel that existing deployments on other systems are a bit different, where the stakes are not as high.
Also: 'extra coins'? You're talking about stealing, not extra coins, right? (Academic? Maybe, but if we had done confidential transactions, would be v. different!)

2025-11-24 21:19:04 UTC

- reply

Fair. Starting is entirely sensible. But I would rather say 'planning' and researching, than starting.

2025-11-24 20:59:55 UTC

- reply

Exactly. People are clueless about how hard, and risky, this will be.

2025-11-24 17:42:06 UTC

I did this. It worked. Cool software!
#nevent1q…dpdl

2025-11-22 17:37:57 UTC

- reply

The 4 year cycle was a borderline insane concept. It is the single most predictable event (halving) in the entire economic world, and yet somehow the market reacts to it ... in real time?

2025-11-22 16:44:35 UTC

- reply

I would be impressed if I actually understood any of it 😄

2025-11-19 21:48:44 UTC

- reply

Now ask it to prove zero knowledgeness holds :)

2025-11-19 21:45:13 UTC

- reply

Beautiful.

2025-11-19 21:44:43 UTC

- reply

How long do you have?

2025-11-19 21:42:43 UTC

- reply

And indeed: amount field represents an especially big challenge to prevent embedding, but to be fair it is small and could be smaller. I considered it but keys/signatures are the crucial part.

2025-11-19 21:40:31 UTC

- reply

Re: your true or false question: i think the answer might be: technically it's surprisingly false, but it requires almost absurd total redesign of bitcoin; see our discussion here:
#nevent1q…hk7r

2025-11-19 21:32:13 UTC

- reply

I think the site is blocked in certain countries like UK.
I should have hosted it on github but tbh there's only a few slides, it only helps a little. Basic ideas already on the bitcoin mailing list "on (in)ability to embed data in Schnorr from a few weeks ago.

2025-11-19 14:45:03 UTC

- reply

That kind of delay is expected once every day or two afaik. Probably once per day if the difficulty is on the high side.

2025-11-19 14:37:05 UTC

Gave a presentation last week on "purecoin", showing basically how ~ 50% embedding rate in "pure" bitcoin transactions with no scripts is inevitable *even if* you force the outputs to prove they are not "fake". 'Fraid the audience had no idea what I was talking about, so I'll post the pdf here:
https://files.catbox.moe/tpfc4x.pdf
I must apologize for calling it a "very hard fork" because you could actually do it as a soft fork (thanks @nprofile…u090 ) but it's hardly relevant. The point is that there is no version of Bitcoin, even a 99% crippled version of it that doesn't allow L2s, that does not allow data embedding, *except* one in which we completely change the cryptography to BLS (any deterministic signature scheme could in theory do it, but nobody is going to seriously suggest hash-based signatures or RSA FDH I think) (thanks @nprofile…xj85 for thoughts on this), *and* totally cripple any programmability. And since quantum is coming (so they tell me!) I see basically no chance of this happening.
#bitcoin #cryptography

2025-11-19 12:45:42 UTC

- reply

I'm getting a dangerous site warning on brave on android.

2025-11-18 21:22:37 UTC

Wtf! (also not working here)
#nevent1q…rcsp

2025-11-18 21:10:43 UTC

- reply

Yes that's a very good point. I remember now that DJB is a strong advocate for exactly this.
Notice though how in performance critical applications, using even more space and time to do this is going to be ... ouch.

2025-11-18 20:39:02 UTC

- reply

It could also theoretically open up new attack vectors. People talk a lot about the performance problems with PQC algos, but the recent history of proposed algos is littered with cases of people finding breaks/insecurities.

2025-11-18 15:19:25 UTC

- reply

It's throwing 'internal server error' so it seems like a decent chance it's not a problem that's specific to you.

2025-11-18 14:11:42 UTC

- reply

Interestingly, you were the only person in the thread I couldn't zap (not sure if it's due to cloudflare, but maybe?)

2025-11-18 14:09:34 UTC

- reply

Stuff always loads slow for me. It doesn't feel too different rn. I'll dunk on nostr infra. another time; for now I think it's the fact that centralized payment systems aren't working that we should be trashing!

2025-11-18 13:18:18 UTC

- reply

It doesn't pay well. It's just easy. They are doing it for a laugh, and people like you are the butt of the joke.

2025-11-18 04:37:49 UTC

- reply

*implementing

2025-11-18 04:37:25 UTC

- reply

"this" is actually implenting PQC on Bitcoin.

2025-11-18 03:49:05 UTC

- reply

I think people are underestimating how hard this will be. If there's meaningful progress within 5 years I'll be surprised.

2025-11-17 22:24:49 UTC

- reply

OK cool thanks for the tip. Meanwhile I'm wondering about the model here: wouldn't it make sense to cache (as in, persist to disk) actual filters? The current codebase persists the filter headers to disk, but not the filters themselves. While it's true that for a constrained device, the filters would be a bit large, they're still like 3 orders of magnitude smaller than the full blockchain, and it seems like it'd make sense to have them stored then verified against headers or w/e, rather than a pretty slow start up (i mean clearly the idea is to have a long running daemon, but still, it seems wasteful. I know compact filters was optimizing privacy and disk space, not bandwidth, but tbh even a smartphone would probably prefer to use the disk than the bandwidth! .. perhaps).

2025-11-15 23:06:44 UTC

- reply

Yeah, it's hard to say the best design. That one was pretty good for sure.

2025-11-15 15:22:42 UTC

- reply

Hmm, an interesting perspective. First, to be clear, most of these proposals are "self-verifying" so to speak, so the question doesn't arise (i.e. proof of burn, proof of work and aut-ct). Specifically for a payment though, like ecash, I imagined it as "user has N entry point relays, relays talk to each other" and the latter is a matter of relationship between relays. I suspect that's how it works today. Relay X just blocks relay Y when it sees it sending a bunch of objectionable spam, otherwise they choose to cooperate. As for relays behaving adversarially because they might be in economic competition, that could be a good point, I'm not sure.

2025-11-15 14:58:20 UTC

- reply

I think I agree.
(Apart from 'key has a known key' 😁)

2025-11-15 12:52:05 UTC

- reply

Custodial wallet means you don't own your own keys.
It's correct to point out that this implies bad privacy too, but that's not the definition of custodial. And the implication does not apply in the other direction.