<unnamed>

Public Key

npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7

Profile Code

nprofile1qqsxwkuyle67y94tj378gw8w2xw2wa6nwmwlqhddlwnz0z7sztsaw2qpp4mhxue69uhkummn9ekx7mqpzpmhxue69uhkummnw3ezuamfdejs6sj894

Publishing to

nos.lol

nostr.wine

search.nos.today

Last Notes

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-25 18:04:17 UTC

- reply

Interesting for sure! But why is it described as AI powered? Is that an essential component?

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 13:07:46 UTC

- reply

I hardly ever use gpg any more, but i remember the subkey thing being a major pain point in having a correct mental model of wtf is going on.

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-18 12:27:13 UTC

- reply

Right. But it wasn't practically feasible. I think that's a fair statement.

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:39:28 UTC

- reply

Waiting for the Kratter video to educate me on where you went wrong here.

2026-01-11 13:21:01 UTC

- reply

See #nevent1q…hzfw
... seems relevant!

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-08 14:42:17 UTC

- reply

It's a mix of everything. There are a lot of pre-european naming, but then you have not only spanish influence but also italian (in the south) and even african. A good example might be aguacate for avocado, which is old Nahuatl, but it's palta in Argentina. Chocolate is another famous one that's from Nahuatl i think. Meanwhile 'green beans' have literally 4 completely different names, no joke.

2026-01-08 14:35:58 UTC

English nouns are basically the x-only pubkeys of European languages.

2026-01-08 13:46:12 UTC

- reply

That's cool. It reminds me of something interesting: even though the same language, across Latin America there are a huge variety of words for certain common fruits and vegetables. And some everyday items too like a straw. But i noticed it especially with vegetables.

2026-01-06 20:40:26 UTC

- reply

I'll write something on the issue shortly.

2026-01-06 01:33:24 UTC

- reply

I was a Linux user for years before I found out 😆

2026-01-05 01:36:52 UTC

- reply

It will have mysteriously gone missing, so it'll be a moot point.

2026-01-04 13:39:22 UTC

There's something hilarious about this: I went to kalshi.com out of curiosity to see how bets are set up. In their "Crypto" section they have a bet on whether Satoshi will move his coins. Never mind the ludicrous way in which everyone assumes they know which coins belong to Satoshi (I mean, apart from the origin of the Hal payment, that's pretty much the only one we know "for sure"), just look at the terms of the contract https://kalshi-public-docs.s3.amazonaws.com/contract_terms/SATOSHI.pdf (both the "Source Agent" - Coinbase and Kraken, wow! - and especially the "Contingency" at the bottom!). And here's the supposed source: https://intel.arkm.com/explorer/entity/satoshi-nakamoto . I guess people just like gambling on, well, anything.

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-03 18:08:03 UTC

- reply

Ha! I was just thinking this morning that I would expect this to have happened.
Insider trading is not a crime (I mean that in every sense except the literal one).

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 20:51:23 UTC

- reply

No, at least, they never did. Just email.

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:45:22 UTC

- reply

Good question! After. I see what you mean, new regs right?

2026-01-02 18:24:26 UTC

- reply

Onchain, indeed.

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.

2026-01-01 12:39:04 UTC

Question for @nprofile…hw44 : why is the mnemonic stored unencrypted on the hard 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 15:38:00 UTC

- reply

On the first part:
Bitcoin itself isn't a product .. but I'll guess you agree with me there and say "but a lightning wallet is, kind of, a product". I can agree at least in general that you have to or want to think like that. But then it's a matter of what's reasonable. There's that old saying "if you're not paying you're the product". I believe it applies here. What is wrong with paying $2 to get access to something that you can permanently use for sovereign, private, immediate payments? In reality that $1-2 is part of the series of fees you're going to pay over time. It's trivial. I honestly can't understand this point of view, at all.
On 'more than visa or square', lots to unpack, but, merchant pays and overall way more is paid. It's not sovereign, it's not private, and it doesn't settle for days. Completely censored. Only cheap because regulators corrupted to literally rob poor people without cards and give it to their customers. Not even available in some places.
If a person prefers 10c instead of 30c fee (or w/e) despite *all* of those things, then why are you 'pitching' to them?

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-28 11:45:10 UTC

- reply

Look up 'median time past'/MTP. Clocks can be unsynchronized ... but not too much!

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-27 12:23:52 UTC

In 10-20 years, will we have people who are on the street and talk to each other like this: "Here's the key insight: that's not an X, it's a Y" - because that's the only kind of text they've ever read?

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-13 12:42:25 UTC

- reply

I wonder if we could help the general public by explaining why there is such a thing as a "private" member variable in computer programming ... i.e. that it's not a morality question, it's a principal used for architecting systems well, for both safety and efficiency.
I mean obviously not 😁 ... but, in theory, maybe.

2025-12-12 11:58:18 UTC

- reply

But wait you said member. Why not any user?

2025-12-12 11:19:02 UTC

- reply

Yeah. An interesting detail, crossed my mind too!
Unless they switched to El Gamal but I very much doubt it.

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 18:13:28 UTC

- reply

Yeah, I think I saw that text on another page, but definitely good find; because that text is the most explicit about their baffling decision: "no longer considered a good choice" for opening files, only for "Save As". Crazy.

2025-12-08 13:59:03 UTC

My favorite part of researching this was finding this in an old 2012 thread:
"I will second the default of $HOME.
I, like many people, like to watch pornography on my computer. Lots of pornography. Pornography that pushes the boundaries of what is physically, morally, and socially acceptable. Contemptuous, despicable, regrettable pornography.
I think it would be great if the GtkFileChooser did not try to announce this fact to everyone who uses my computer to save a spreadsheet.
Thanks!" https://bugzilla.gnome.org/show_bug.cgi?id=658280#c15
😆
#nevent1q…ym97

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 22:22:04 UTC

- reply

To generate, no. To restore, technically maybe no, in that *if* your wallet allows a direct connection to your own bitcoin node running on the same computer, it can perform the restoration function by just talking to that running node. However this won't be a full restoration as if there is no live internet connection, your node will not have the most recent blocks. So realistically, restoring needs an internet connection. Generating a wallet 100% does not, which is important for high security setups. Also check the concept of a "watch-only wallet" for an interesting and useful finesse.
Of course a lot of convenient lower security wallets will not be careful about these details. If you are not using your own node, certain tradeoffs are inevitable.

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-04 20:07:54 UTC

- reply

I think algebraic merkle trees (curve trees) are a natural fit because you get fast verification (10-50ms without batching) and fast proof (relatively fast; a second or two), because of not having to put a cryptographic hash function through arithmetization. And you still get the same ability to embed logical conditions on what is in the leaves of the tree, using standard ZK proving systems like bulletproofs (e.g. I did "proof of reserves" in aut-ct). Maybe worth looking at Luke Parker's work on FCMP for how much this can scale. I described aut-ct more wordily here if it's interesting: https://delvingbitcoin.org/t/anonymous-usage-tokens-from-curve-trees-or-autct/862 .
I also think reputation is a false trail but, meh, that's just a vague opinion.

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:24:24 UTC

- reply

Filtering is inevitable. I fear having a fixed rule about how to filter (such as an AI filtering tool) may not be helpful. It's certainly no that clear-cut, though.

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-24 17:33:14 UTC

uncomfortable truth? : i feel like the debate on the mailing list about AI authorship for BIPs is reminiscent of the filtering debate for Bitcoin. In both cases, people arguing for prevention (not just dissuasion) are essentially pissing in the wind. Using "automated tools to detect AI usage in documents" is doomed to fail over time, with terrible false +ve rates; just think about it. In both cases, the technological reality just does not support the prevention argument.
As for dissuasion, even that's problematic. It's hard to argue these tools are not useful, and the nuance of "don't misuse it" is too difficult to capture imo. In short, just like spam on-chain, I'm not saying there isn't a problem, but it's hard to define and the cure is worse than the disease.