Nostr notes by waxwing

You're thinking of MuSig(2), which is indeed a cool watly to ...

2026-10-14T07:43:03Z

In reply to nevent1q…pde3
_________________________

You're thinking of MuSig(2), which is indeed a cool watly to do multisig. I'm talking here specifically about using CHECKSIGADD in taproot *leaves*. Different thing.

The taproot change included *both* Schnorr sigs in BIP340, which enables MuSig2, but also script trees, which enables the selective revelation I mentioned above.

Oh, right, got it. There's the argument that you can test the ...

2026-10-14T01:02:56Z

In reply to nevent1q…uxua
_________________________

Oh, right, got it. There's the argument that you can test the procedure with different keys. But your point is still very valid.

You absolutely do need to do test txs! Maybe i missed the context ...

2026-10-14T00:12:03Z

In reply to nevent1q…9wmu
_________________________

You absolutely do need to do test txs! Maybe i missed the context of your comment though.

But I was saying it strengthens it? One leaf exposes A,B. One ...

2026-10-13T20:06:11Z

In reply to nevent1q…vm06
_________________________

But I was saying it strengthens it? One leaf exposes A,B. One exposes A,C. And one exposes B,C. So onchain you only see the 2 that signed, not the 3rd. Pretaproot you see all 3, in every signing event.

But now I've written that out, it only helps in terms of blockchain publishing I think. If you literally own 2 of 3 devices, you clearly will be able to see all 3 pubkeys.

IIRC taproot affects this. Pre taproot it was impossible to sign ...

2026-10-13T19:47:28Z

In reply to nevent1q…z54l
_________________________

IIRC taproot affects this. Pre taproot it was impossible to sign m of n multisig without exposing all n pubkeys. In taproot, it is, with leaves. It's complicated but in old school multisig with 2 of 3 devices, each one has to know the others' pubkeys, so owning 2 devices is definitely enough.

If you have all 3 pubkeys, you only need 2 of 3 signatures (or ...

2026-10-13T19:39:22Z

In reply to nevent1q…0urt
_________________________

If you have all 3 pubkeys, you only need 2 of 3 signatures (or private keys ofc) to get the money. You may or may not have access to the pubkeys, it depends. But clue is in the name: they're *public* keys, called that for a reason.

There may, however, be 2 known remote attacks :)

2026-10-13T19:28:50Z

In reply to nevent1q…xejf
_________________________

There may, however, be *2* known remote attacks :)

It's certainly a good idea to make sure it doesn't ...

2026-10-13T18:30:15Z

In reply to nevent1q…ru03
_________________________

It's certainly a good idea to make sure it doesn't accidentally connect to an unsecured network. Or maybe like live in a farmhouse or something 😄

The thing is, what's your actual threat model? Anything is *possible*, but what's plausible.

It's sort of the wrong question? I mean this isn't ...

2026-10-13T15:50:32Z

In reply to nevent1q…cutz
_________________________

It's sort of the wrong question? I mean this isn't exactly true but it's a fun thought: suppose I gave the "obviously correct" hardware and software choice. Then, everyone would use that, and attackers would have at least a specific target (that is FAR from a watertight argument, but it's a fun/interesting one).

Fwiw i think it's easier to be network-disconnected on laptops and desktops, than on phones. I think that should count for something.

Maybe people will finally realise (a) it's easier to audit ...

2026-10-13T14:05:16Z

Maybe people will finally realise (a) it's easier to audit software than hardware (b) the threat model on hardware isn't realistically backdooring general purpose computers when they don't even know what software you'll run (c) you don't have to rip out network cards, if there is no accessible internet.

Maybe, maybe not ;)

I wonder if I was influenced by getting into bitcoin before hardware wallets existed. Back then the discussion was "don't be a dumbass and run your wallet on windows" and "keep it on a separate machine". People were running wallets on phones and getting into arguments about how much is safe to keep on it - I guess that just hasn't changed at all. BIP32 was just starting to become commonplace and people realized the 'watch only' concept could work (a massive step forward imo), people were just starting to tinker with the idea of special purpose devices, I remember Trezor starting up. I played with one a few times, small amounts, it's kind of cool technology, but I could never bring myself to put much money on it. It's sitting in a drawer, empty, now. I bought a couple Coldcards, gave one to a guy in El Salvador who used it for teaching, the other one sat in my drawer until the hack, shortly after which I took it out of its bag and used it as a teaching demonstration, myself. Thanks for coming to my ted talk.

Tbh it never really worked in 2016. I tried very hard but no one ...

2026-10-13T13:47:18Z

In reply to nevent1q…69xe
_________________________

Tbh it never really worked in 2016. I tried very hard but no one was interested in helping me, not even to test, so I just gave up.

I remember I found a bug in Electrum while I was doing that, that made it impossible to cosign transactions. Thomas fixed it when I showed him, but man did it take time to debug it! Pretty slow back then 😄

Here's what withdrawal looks like when the hub has gone ...

2026-10-13T13:25:55Z

Here's what withdrawal looks like when the hub has gone offline. There are 2 such transactions. Each about 10kvb, a mere 40kB of witness/script 😄 (seriously though: big, but not a problem at all).

https://mutinynet.com/tx/5193b49e0c3bc62a5a72636b0a28ef83a279effb6f5ed79dcaaa632912a72ff8?showDetails=true

quoting
nevent1q…crcg
Doesn't look like much (because it isn't! lol), but here is the first ever withdrawal from a lichen on a public network :

https://mutinynet.com/tx/0a1efc47e251e32dab3d57d1ef0052f9f55b5ef6527ecc0b65957d5f69652338

Alice deposited 30k sats into the L2 for a 2 week timeframe, paid Bob 5k, then withdrew 20k. Now Bob has 5k sats more and Alice has 5k sats left. Alice's leftover 5k sats in this case are in "credit" mode: she can't exit them any more independently, she'd have to sell them to someone else. In general, she won't do this; she'll withdraw everything when she withdraws, that's the simplest, or just "novate" : when she wants to withdraw she'll negotiate a new contract to replace the first one.

Also it won't be very practical to use 10k sat type deposits in a real deployment. Like 400k and up is my guess. Of course L2 txs can be v. small.

nevent1q…7r22

Doesn't look like much (because it isn't! lol), but here ...

2026-10-12T21:52:24Z

Doesn't look like much (because it isn't! lol), but here is the first ever withdrawal from a lichen on a public network :

https://mutinynet.com/tx/0a1efc47e251e32dab3d57d1ef0052f9f55b5ef6527ecc0b65957d5f69652338

Alice deposited 30k sats into the L2 for a 2 week timeframe, paid Bob 5k, then withdrew 20k. Now Bob has 5k sats more and Alice has 5k sats left. Alice's leftover 5k sats in this case are in "credit" mode: she can't exit them any more independently, she'd have to sell them to someone else. In general, she won't do this; she'll withdraw everything when she withdraws, that's the simplest, or just "novate" : when she wants to withdraw she'll negotiate a new contract to replace the first one.

Also it won't be very practical to use 10k sat type deposits in a real deployment. Like 400k and up is my guess. Of course L2 txs can be v. small.

quoting
nevent1q…7r22
A follow up from recent ideas : Lichen[1]. You can have trustless withdrawal from an L2 based on liquidity in channels.

https://groups.google.com/g/bitcoindev/c/yZEZ5P1lj5E

I'll be interested to see opinions. I believe this can be built today. No consensus changes needed (op codes). The application I'd like to see it for is shielded transfers for good privacy, without some of the current impracticalities in proposed bridge designs.

https://github.com/AdamISZ/lichen has a prrof of concept with a demo on regtest.

[1] another backronym 😄 .. L2 In CHannels ENforced by bitcoin.

The general replay potential of APO style sighashing was ...

2026-10-12T17:31:02Z

In reply to nevent1q…685w
_________________________

The general replay potential of APO style sighashing was discussed quite a bit in 2018 when eltoo came out. For example here's GMax suggesting to call it "SIGHASH_WEAK_REPLAYABLE" :) [1] . It's not hard to deduce that of all the various and sundry op_code proposals we've had over the years, this is one that has the least solid foundation of "users cannot footgun themselves". By any measure, they can.

To be clear, I haven't bothered to read these new proposals, but I get that your point is: because they offer more powerful templating, the risk is no longer just 'replay the payment' but 'replay the coin-spending into an actually different payment'. Very clearly a bigger risk, agreed.

Presumably the obvious counter-arguments apply: the contract outputs are 'special', they'll never be presented as addresses you can spend into and etc etc. The counter-counter argument is operational fallbility etc. I guess. I don't really have strong opinions, but I think I agree that this at least a point of controversy in terms of what should be added to consensus rules. That style of argument has been made before.

[1] https://gnusha.org/pi/bitcoindev/CAAS2fgS-_D7aBcDf_nAbuREBxv65zYMr60-1YqCnx-esvRVfEg@mail.gmail.com/

From the table of contents this looks like a fantastic ZKP ...

2026-10-12T16:35:59Z

From the table of contents this looks like a fantastic ZKP reference. All the way from the absolute math basics to modern systems:

https://github.com/BlockstreamResearch/zk-book/releases/tag/latest

A follow up from recent ideas : Lichen[1]. You can have trustless ...

2026-10-11T17:58:39Z

A follow up from recent ideas : Lichen[1]. You can have trustless withdrawal from an L2 based on liquidity in channels.

https://groups.google.com/g/bitcoindev/c/yZEZ5P1lj5E

I'll be interested to see opinions. I believe this can be built today. No consensus changes needed (op codes). The application I'd like to see it for is shielded transfers for good privacy, without some of the current impracticalities in proposed bridge designs.

https://github.com/AdamISZ/lichen has a prrof of concept with a demo on regtest.

[1] another backronym 😄 .. L2 In CHannels ENforced by bitcoin.

OK!

2026-10-11T17:51:26Z

In reply to nevent1q…7qya
_________________________

OK!

What about tamper evident seals.

2026-10-10T11:55:29Z

In reply to nevent1q…vjds
_________________________

What about tamper evident seals.

Is anyone else getting paranoid that their own writing is ...

2026-10-10T11:35:43Z

Is anyone else getting paranoid that their own writing is starting to sound like AI cliches, because so much of what they read nowadays comes out of an AI.

To be clear, I don't look down on AI writing just because it's AI. I still read it if it's a useful set of ideas, but I see it very differently if you aren't writing it yourself because, *sometimes* (depending on context) it means you just didn't make much of an effort.

Also it's gradually getting less cliched with more recent models. But, gradually.

I think it's much more likely people find surprising edge ...

2026-10-09T21:48:16Z

In reply to nevent1q…jkyc
_________________________

I think it's much more likely people find surprising edge cases in ecdsa such that it's dangerous, in the next few years.

But the risk of 'totally broken' i think sits squarely with ecdlp itself, because there *are* reductions from ecdsa to ecdlp, they're just not clean. So I guess different kinds of risk, but, again, I obviously am 99% just guessing.

Yes. The quantum attack, any attack breaking ECDLP, it's ...

2026-10-09T19:33:07Z

In reply to nevent1q…2dpq
_________________________

Yes. The quantum attack, any attack breaking ECDLP, it's worse.

An ECDSA specific algorithmic attack, it's better.

Example: with ECDSA you can create a signature that validates against two different pubkeys. With Schnorr you can't do that.

if you want to know why i always talked down people's belief ...

2026-10-09T19:31:04Z

if you want to know why i always talked down people's belief in hardware wallets, it was not because of what happened with Coldcard, it's because of what just happened (apparently? seeing it rumored via Karpeles on twitter; not sure if it's true) with Ledger: supply chain. They didn't need to tamper the wallet directly, they just created a way to watch it. You buy via the authorized resale agent, but he goes rogue and sells versions with 'implants' that read your seed as you enter it.

*Not advising any particular approach to all this, not even 'don't use hardware wallets!'. just saying - central points of failure matter, you need to think about that *actively* because it's human nature to stay in the herd, even in subtle ways.

Interesting detail that I bet no one else mentions ;) If ...

2026-10-08T22:14:38Z

Interesting detail that I bet no one else mentions ;)

If you're worried that AI might break the cryptography protecting your coins, it might make sense to switch to taproot. ECDSA is *far* less trustworthy than Schnorr and ECDLP, imho.

Of course no one really has a clue, but that take is not unreasonable.

The part that got my attention so far is chapter 3: using ...

2026-10-08T20:17:09Z

In reply to nevent1q…nv7a
_________________________

The part that got my attention so far is chapter 3: using fedimint ecash servers!

https://bounty.blink.sv/ Very interesting read! H/T ...

2026-10-08T20:10:45Z

https://bounty.blink.sv/

Very interesting read!

H/T Super Testnet (nprofile…jtmp)

Yeah you were right, it is dns level block at ISP.

2026-10-08T20:09:51Z

In reply to nevent1q…zc4k
_________________________

Yeah you were right, it is dns level block at ISP.

Ironically that boss is famously not only very easy to kill, but ...

2026-10-05T19:34:20Z

In reply to nevent1q…eycm
_________________________

Ironically that boss is famously not only very easy to kill, but also much smaller in the game than in the cover art/intro cinematic.

My guess is it's a classification error, not a ban; that ...

2026-10-05T12:52:24Z

In reply to nevent1q…k9h5
_________________________

My guess is it's a classification error, not a ban; that would have been news.

I honestly think that's orthogonal to what I'm talking ...

2026-10-05T12:50:18Z

In reply to nevent1q…uel9
_________________________

I honestly think that's orthogonal to what I'm talking about. What you're talking about is a very serious problem of vastly expanding automation of real world interaction. I have experienced similar.

I'm talking about pure software. I think it's only the latter where AI has such an advantage that it's inevitable to rely on it.

It's strange but afaict bitrefill.com is permanently blocked ...

2026-10-05T12:47:24Z

It's strange but afaict bitrefill.com is permanently blocked in my ISP in Buenos Aires, last 2 months at least. I saw other similar reports from people in Argentina.

Zero problems via VPN. Definitely *some* kind of local block. Weird.

As both users and developers, we're rapidly approaching the ...

2026-10-05T12:18:50Z

As both users and developers, we're rapidly approaching the point where we have to decide 'is it OK for the software I use for serious things (health, money, privacy etc.) was not fully vetted or fully understood, line-by-line, by expert humans.'

Tests were always a vital part of development. We're going to have to decide if we can rely on them even way more than we do now.

Sorry for being Captain Obvious today...

That's interesting. So it's a 'virtual' account ...

2026-10-04T18:56:56Z

In reply to nevent1q…kd58
_________________________

That's interesting. So it's a 'virtual' account that Bull holds but is named by the customer? I don't entirely get it.

Project I've been working on: "LN-GAP": ...

2026-10-03T00:36:25Z

Project I've been working on: "LN-GAP":

https://github.com/AdamISZ/ln-gap

Play multi-move games or arbitrarily complex contracts in Lightning channels.

Read the linked short paper as per the README, to get an idea of how it works.

Trust model: trustless settlement w.r.t. the counterparty, but needing a 'venue' that is only trusted to publish the 'moves' on time. The venue never controls any funds, doesn't need to process (or understand) the contract, can be drawn randomly from an arbitrarily large set, only 1 of n trust for liveness and majority+counterparty required to collude. Collusion burns reputation and/or bonds.

You can pretty easily run the chess or blackjack examples in the browser.

I think it's a pretty interesting idea, slightly different angle of attack on offchain bitcoin denominated contracts. Draws a lot on many older ideas/constructions, with a few new ideas/details.

This is extremely typical of my interactions with Opus 5.5. I try ...

2026-10-01T17:39:22Z

This is extremely typical of my interactions with Opus 5.5. I try to make a lighthearted quip about some nerdy thing and it immediately shoots back with a totally dry/deadpan insightful and content-packed answer with the intellect of a thousand suns, or something (*):

"a long time ago when analyzing a similar construction, i somehow convinced myself that the optimum is at e, and that's why 3 or 4 as the base often appears optimal. but knowing me i probably just guessed e by intuition, and it's probably not correct :)

Your intuition was right, and it's a real result. It's called radix economy. If representing a number costs (number of digits) × (cost per digit, proportional to the base), the cost is b · log_b N = (b / ln b) · ln N, which is minimized at b = e. The best integer is 3, slightly better than 2 or 4. That's the classic argument for ternary computers (the Soviet Setun was one)."

(*) OK on reflection, this isn't particularly amazing. But the reference to the Soviet ternary computer is cool. And this output comes in like, milliseconds.

a trick I hadn't seen before to get a random number onto the ...

2026-09-28T13:15:31Z

a trick I hadn't seen before to get a random number onto the stack in bitcoin: say Alice and bob post a hash (so a commitment) of a random number, then you want to force them to reveal it in a Script. Using 32 byte values is not useful if you want to do arithmetic; as we all know you can only do arithmetic on "little script": 4 byte values, not 32 byte. Even worse, just hashing '12' is no good; there needs to be a salt so that the commitment is hiding, so more random bytes. Script can't parse the preimage and split it into parts to get the number from '12f3fwrffrsf' to '12'. So here's what you do:

OP_SIZE on the preimage gives a 'little script' number directly. If you want to commit '12' you make a random string *of 12 bytes*, hash it and that's your commitment. It has hiding because the 12 character string is random, and when the preimage is consumed with OP_SIZE you get the number 12 on the stack.

Obviously this is only going to get a smallish number out: I used '12' but i think you could get into the 100s, but not 1000s due to Script limitations. You could do it multiple times though and encode digits that way.

Apparently this trick was already there in a 2013(!) paper: https://eprint.iacr.org/2013/784.pdf that talks about doing MPC on bitcoin. I wonder if it was unfairly ignored because no one was gonna do MPC on bitcoin back then!

The whole Glock program is as expected, slowly but surely coming ...

2026-09-24T11:50:24Z

The whole Glock program is as expected, slowly but surely coming together. Basically algebraic garbling is the thing: with that you change a garbled circuit from a 100GB behemoth into some normal sized object. You might still have to throw cut and choose at it, but that's never more than a 100x multiplier. (I admit I haven't read the paper yet, lol, but that's the story that's been brewing all year. I think the Linus/Eagen/Ying Tong thing is somehow closed source so I guess none of us know what the frontier is exactly, unless we pay up!)

https://www.alpen.org/blog/shrinking-offchain-data-requirements-for-groth16-verification-on-bitcoin

Look at this absolute shite your tokens get wasted on: "The ...

2026-09-23T12:27:27Z

Look at this absolute shite your tokens get wasted on:

"The user is asking whether browser fingerprinting is a good example of the kind of high-dimensional, sparse datasets that make deanonymization feasible per Narayanan–Shmatikov. This is a conceptual question, not a current-events question. I know this domain well. I could optionally cite sources — the system prompt says embedding links in markdown with sources is available via tools, and there's an instruction "Use router_search first to discover sources, then router_fetch specific URLs only when you need deeper detail." Also "You may use the router_search and router_fetch tools when current web information would improve the answer."

Hmm, there's also a general instruction: "NEVER write URLs or links." Wait — that conflicts with the citation instructions. The earlier instructions say to cite with clickable markdown links when using tools. The later "General Instructions" say NEVER write URLs or links. In my previous turns I included a link to the GitHub doc. If I don't use tools, I shouldn't fabricate links. I could answer from knowledge without links, which complies with "NEVER write URLs or links." But if I use search, I'd need to cite. The tension: the general instruction says never write URLs or links. In my prior turn, I did write one link to the doc the user themselves gave. That link came from the user, so it's not really "writing a link" discovered via search...." and so on. Like 10 tokens defining my question and then 500 arguing with itself over whether its own rules are self-contradictory 😆

Nostr event nevent1qqsxmke89dwppkk7k59mccqldfdc7mfeqktv6fr0q8gygexpaflnncczypn4hp87wh3pd2u5036r3mj3njnhw5mkmhc9mt0m5cnch5qju8tjsk0nt45

2026-09-20T18:56:42Z

In reply to nevent1q…r2k3
_________________________

https://delvingbitcoin.org/t/ec-ots-onchain-has-anyone-considered-it/2901

Oh. So, two things are in my head that made me write that 1/ ...

2026-09-20T18:14:35Z

In reply to nevent1q…exuk
_________________________

Oh. So, two things are in my head that made me write that 1/ inversion (that is division) is one of the most expensive and ugly operations you have to do (remember we're dividing mod p where p is an outlandishly huge prime number). They did a ton of work on it. But 2/ is what actually matters here: they're careful to only expose in the API what a user of the library actually needs, because that lets them have the ability to change underlying algos without breaking software that uses the library. Some libraries have different strategies for that, like naming parts of their API "unstable" or "experimental". Actually come to think of it libsecp did have that kind of thing too. But anyway I guess it's just too low level and they don't want to be responsible for maintaining a stable API for that operation.

Does libsecp256k1 not expose scalar inversion? I mean it fits the ...

2026-09-20T12:58:05Z

Does libsecp256k1 not expose scalar inversion?

I mean it fits the longstanding philosophy but it's still slightly irritating 😄

Has anyone considered doing Lamport or Winternitz style ...

2026-09-19T19:47:23Z

Has anyone considered doing Lamport or Winternitz style signatures using dlogs instead of hashes?

First thing I'm noticing: Lamport maps simply, but WOTS uses hash *chains* ; how much additional cleverness might be required for that?

A reasonable question might be 'why on earth would you want to do that?'. I do have an idea for using it, but it takes some explaining...

i can only sympathize with anyone trying to run a bitcoin ...

2026-09-19T13:23:59Z

i can only sympathize with anyone trying to run a bitcoin business (say, a technical one, supporting wallets and similar). if you stick with open source, it seems, you will continue to be attacked directly with the new tooling. if you try to use closed source, your more sensible customers will treat it as it really is - custodial. all combinations are bad: like, custodial, but also open source: guess what you still get attacked. one of the biggest defenses is the simple one: don't be in a big crowd with a big pot of bitcoin under one type of control. the coldcard customers fell victim to that one (though tbh I think the coldcard case was the most extremely unfortunate scenario of everything we 've seen; the Liquid one was also super-unfortunate but not absolutely insanely so).

My bugfix PR was closed after 8 years. With a pretty good reason! ...

2026-09-15T17:52:21Z

My bugfix PR was closed after 8 years. With a pretty good reason! 😆

https://github.com/btcsuite/btcd/pull/1108#pullrequestreview-5213530739

I read that the customer data leak was a while ago. But honestly ...

2026-09-15T02:03:33Z

In reply to nevent1q…v5sr
_________________________

I read that the customer data leak was a while ago. But honestly I've forgotten 😄

Also I think I am not in the affected group anyway.

Fair point that there are other dangers (e.g. surveillance) that ...

2026-09-14T19:59:25Z

In reply to nevent1q…f85w
_________________________

Fair point that there are other dangers (e.g. surveillance) that we have much shorter and more concrete paths to, here, which might require very different responses.

There was a customer data leak. It's been in the news last 2 ...

2026-09-14T18:53:54Z

In reply to nevent1q…er32
_________________________

There was a customer data leak. It's been in the news last 2 days.

Closed my Revolut account earlier this year, seems like I was a ...

2026-09-14T01:26:31Z

Closed my Revolut account earlier this year, seems like I was a bit too late.

Who am I kidding, they're all exactly the same.

I've been vacillating on this one. On the one hand, the push ...

2026-09-14T00:00:05Z

In reply to nevent1q…s33c
_________________________

I've been vacillating on this one. On the one hand, the push towards fear seems like it's being manufactured. On the other hand, I can easily imagine, even if a way out in the future, some very negative scenarios could play out. If agents become as much smarter than us as we are compared to, say, rodents, then it becomes nearly impossible to predict the outcome. I'm just not sure. But I don't think some global 'disarmament agreement' will work the same way it ~ did for nuclear material, since the ability to deploy this tech is so much easier and so strongly economically motivated.

Yep you trade privacy off for reliability. Only partly of course, ...

2026-09-12T21:30:28Z

In reply to nevent1q…002f
_________________________

Yep you trade privacy off for reliability. Only partly of course, but you do. Not a panacea but way better than custodial. That's how I see it. Re: complicated to get funds back, I don't think so, but I'm not sure, haven't tried it recently. There is a close channel option that presumably force closes as you'd expect.

Phoenix because it's reliable while self custodial. In the ...

2026-09-12T19:58:18Z

In reply to nevent1q…nvu5
_________________________

Phoenix because it's reliable while self custodial.

In the last year or two I haven't even bothered to run my own LN node at home (or elsewhere). I used to, but I don't have the motivation or the organization to do it properly. Which is a shame, but shrug.

Also my case is not normal, I spent the last few years in El Salvador mostly.

i did this a few years ago, but i should update it: "What ...

2026-09-12T17:51:25Z

i did this a few years ago, but i should update it: "What have you used Lightning to buy?". My answer is now: "drinks at bars/events, food (dinner) including sharing the bill with other people, hotel rooms, flights, cellphone bills (both the normal type and esims), electricity bills, water bills, internet bills, taxis, takeaways, groceries (last 3 via gift cards) VPS, VPN, charity donations, trades with friends (usually for USD cash), topping up a debit card, payment for nostr relays, zaps on nostr and LLM model tokens." Probably missed a good few miscellaneous 'buy a thing', but that covers a lot. I have to go via bitrefill for a couple of these, especially internet and electricity bills (in El Salvador; which is also where I got the debit card I can top up with Lightning).

I should also say that 'flights and hotels' being higher cost items, are almost always with btc mainchain or via some other method, but I think I used lightning once or twice here (and will always choose it if I can!). And lastly I should say that having done this for years, with a *self custodial wallet* (I used Electrum a bit but I mostly used Phoenix), I basically *never* have payment routing failures, that used to happen all the time pre-2023.

But apparently I'm all alone because nobody uses Lightning.

From what I heard that's pretty typical. As in the general ...

2026-09-09T13:34:24Z

In reply to nevent1q…9nw9
_________________________

From what I heard that's pretty typical. As in the general market for mid to upper end flats in (central?) London has turned down heavily. Though I don't live there any more.

Reflections on the Liquid hack. Take it at different layers: 1/ A ...

2026-09-09T13:17:02Z

Reflections on the Liquid hack.

Take it at different layers:
1/ A central point of failure, even if distributed, holding everyone's funds makes it a brittle design. True. Obviously no nuance there, but it's the first guiding point. It's the reason it's always been way less interesting than a decentralized sidechain would be.

2/ Let's not forget that they *had a whitelist system for exits*. As in, you could not independently peg out, you had to go through a trusted intermediary. This is somehow a failure in 2 opposite directions: it removes reasonable claims of censorship resistance, but, when it came down to it, they also *completely failed to censor* a transaction that no reasonable human-in-the-loop would allow. It's practically a terrible failure, but the whole shape of this problem follows from 1/ so it can never be fully eradicated/corrected.

3/ The software bug was not actually about the cryptography/privacy feature (but wait for 4/ !). It was a logic error in the way that rangeproofs (you can think of them how you think of signatures in normal bitcoin: a little blob of data that proves the transaction is valid) were stored and accessed. it's normal to cache things in software like this that has a significant performance requirement: even simple things like hash functions that are fast. Normal, but of course, it has to be done super carefully (e.g. they have a signature cache in Bitcoin Core) to avoid accepting signatures, rangeproofs and similar, that aren't actually valid. It *was* "just" a software bug, a subtle and tricky one that was easy to miss.

4/ ... Whether 3/ is fair or not as a characterization, here's a surprising feature that *is* absolutely dependent on the cryptography/privacy feature: the *effect* of the bug. Now, it's true that there are non-crypto ways to have catastrophic balance errors, like the 2010 bug in bitcoin that allowed someone to print billions of btc. but not only are they easier if you put the balance arithmetic behind a cryptographic blinding, but they're also easier to be invisible (in Liquid's case, only until you peg out, of course). But it was the crypto structure that allowed this cache hit error to turn into a complete wipeout; if you had some egregious error in signature caching in vanilla bitcoin, I think the worst that can happen is you can steal someone else's money, *not* create bitcoin out of thin air, **because balance checking is not dependent on cryptography, only arithmetic**.

5/ This last one is more in the weeds: as per 3/ caching makes sense because the verifier's computation of the validity of a rangeproof is not free. In fact, this is something specific to bulletproofs as a ZKP: the efficiency of its 'bandwidth' (what has to be sent over the wire; which is also, for a blockchain application, what has to go onchain) comes from essentially folding up the proof's multiple layers into one. the downside is that the verifier has to 'unroll the loop': they have a computational cost linear in the size of the statement. All that's to say, rangeproof verifications are not too efficient. In a different type of ZKP, such as a Groth16 SNARK, the cost of verification is O(1), that is, constant. But that is just not possible on Bitcoin or on bitcoin's EC curve.

I did. I have a vague impression that it's overblown. Very ...

2026-09-08T19:42:07Z

In reply to nevent1q…q8k4
_________________________

I did. I have a vague impression that it's overblown. Very vague though. The thing is, how much difference does it really make, long term?

Anyone else starting to think they judged Kurzweil too harshly? ...

2026-09-08T19:31:08Z

Anyone else starting to think they judged Kurzweil too harshly? Just had an AI call me about my home security, which modulated its speech when it realized my cellphone signal was bad. It got the info it needed and politely ended the call.

Then I opened twitter and saw that they had solved Navier Stokes. It's all a bit much.

Yeah i qualified in reply. But this is nostr, so, understandable ...

2026-09-08T13:26:29Z

In reply to nevent1q…kyyv
_________________________

Yeah i qualified in reply. But this is nostr, so, understandable 😄

I wrote that before the 15%. The other two points are good. ...

2026-09-08T02:48:39Z

In reply to nevent1q…eg4c
_________________________

I wrote that before the 15%.

The other two points are good. Especially the first one; since they could take anything, it's a particularly good point.

The third one is not as clear cut, but definitely to be considered.

Good qualifications but I don't see how it equates to ...

2026-09-07T18:25:33Z

In reply to nevent1q…lkcw
_________________________

Good qualifications but I don't see how it equates to "No". I trust myself to keep a private key safe for a short period. And giving it back wasn't hard either, as has been demonstrated now.

'Wrong' was oversimplified on my part, though I stand by ...

2026-09-07T16:35:39Z

In reply to nevent1q…nzvj
_________________________

'Wrong' was oversimplified on my part, though I stand by it.

What I was thinking about more was the risk. Taking a big chunk (as apparently they now have done) unilaterally puts them firmly in the criminal category from a legal perspective. IANAL but I think they could have very reasonably and ethically argued that they did not steal, if they hadn't done that.. Now, they cannot. Of course if their opsec is tight, they may avoid the consequence, but that's another Q.

Yes, that's what's happening. They're finding a way ...

2026-09-07T15:38:55Z

In reply to nevent1q…rh5n
_________________________

Yes, that's what's happening. They're finding a way to return that bitcoin safely to control of the 11/15 federation multisig (if they're honest). Which they could do immediately *if* the signatories didn't have infrastructure that automatically sends it out on any "valid" Liquid transaction that has a peg-out.

So yeah if Liquid is currently 100% shutdown then it'd be safe to send, even without a bugfix. Maybe that's your point.

I don't know if the blockchain is totally or partly shutdown right now.

Yes, people should definitely be spooked! Not saying ...

2026-09-07T14:37:02Z

In reply to nevent1q…yhm3
_________________________

Yes, people should definitely be spooked! Not saying "definitely the guy has good intentions ".

...But them saying 'I'll send most of it back' ...

2026-09-07T14:14:18Z

In reply to nevent1q…5wcm
_________________________

...But them saying 'I'll send *most* of it back' instead of negotiating a bounty separately, is wrong.

I mean technically you're 100% right. But you can still argue ...

2026-09-07T14:13:10Z

In reply to nevent1q…4x9j
_________________________

I mean technically you're 100% right. But you can still argue that swiping it the second you realize you can, is the more correct choice.

The "Whitehat? Bullshit, that's stealing" natural ...

2026-09-07T13:35:29Z

The "Whitehat? Bullshit, that's stealing" natural response isn't really justified.

If you see this bug and you don't want every user to lose their money, you are somewhat ethically bound to confiscate it until the devs release a fix.

You are thus making deployment of the fix 100x less dangerous (because the collateral is not exposed during the transition.

(Hot take? I don't think so?)

I should really show the follow up paragraph: "While I'm ...

2026-09-07T12:52:59Z

In reply to nevent1q…tvt4
_________________________

I should really show the follow up paragraph:

"While I'm not the King of Monero, I am frustrated my approval was given to a PR on a faulty premise. I'm trying to funnel this frustration into not having to worry about this anymore. Yes, serializing the entire TX is overkill. That's the point. It may be less efficient. This offers a 5x perf boost. I'd rather hear we left .1x on the table than hear we had a double spend in the next release."

I hope more developers of bitcoin security code don't feel bad about "overkill", either!

A comment by Luke Parker (guy who's the main author of FCMP ...

2026-09-07T12:48:33Z

In reply to nevent1q…9ldk
_________________________

A comment by Luke Parker (guy who's the main author of FCMP stuff) struck me on a PR to introduce such a verification cache:

"We could just serialize key images, and fix that issue. I suggested in #8707. The problem is how it's been pointed out there's yet another field with this behavior. I don't want to play cat and mouse forever. The TX's entire networked value, and the mix ring (via do_serialize and as tested by @jeffro256 ) is complete. **Considering this code disables almost every single line of meaningful TX validation code**, I'm not willing to settle for less anymore."
(emphasis mine).

It's remarkable (if not surprising) that this comment exists ...

2026-09-07T12:40:04Z

It's remarkable (if not surprising) that this comment exists in the Monero source, about caching the same kind of verification:

quoting
nevent1q…rwly

Why the heck wouldn't they belt and suspenders with the transaction hash?

(They could also just not cache, full stop. Better choice for Liquid specifically imo, but easy to say in retrospect).

Why the heck wouldn't they belt and suspenders with the ...

2026-09-07T12:26:02Z

In reply to nevent1q…2d7l
_________________________

Why the heck wouldn't they belt and suspenders with the transaction hash?

(They could also just not cache, full stop. Better choice for Liquid specifically imo, but easy to say in retrospect).

Yes, indeed. The pre-patch version didn't have length checks ...

2026-09-07T12:20:48Z

In reply to nevent1q…f3sn
_________________________

Yes, indeed. The pre-patch version didn't have length checks either, but it didn't matter with only (proof, commitment). A very well intended security patch that exposed a pre-existing flaw. Fucking hell software is hard!

I feel like the true root cause is this one: #nevent1q…0nvp The ...

2026-09-07T02:21:46Z

In reply to nevent1q…rvdm
_________________________

I feel like the true root cause is this one:

quoting nevent1q…0nvp

it seems that the bug ultimately comes down to this line: "https://github.com/ElementsProject/elements/blob/c7e856fab1b0c4d37005e25c0940184d812a26a0/src/script/sigcache.cpp#L60 " . range proofs that hit the cache that is keyed to this hash, are counted as valid without checking. the problem is that the data fed into the hash is not length checked. so you can feed different (proof, commitment, asset) tuples into it by varying the length of the proof. the proof can be totally invalid and it'll still come back as valid. and this explains why OP_RETURN is involved: you need an extra output to sort of 'consume' the invalid amount. so you make a totally valid output of 4000 btc and you shove the negative corresponding value in the OP_RETURN. Apparently the anomalous size of the proof confirms this reading (bulletproofs rangeproofs have specific sizes based on the bit range 0..2^k). The only part I don't get is why there was a consensus deviation. Did some nodes have the rangeproof caching disabled or something?

The reason I got convinced is that this theory matches the size of the "garbage proof".

it seems that the bug ultimately comes down to this line: ...

2026-09-07T02:06:04Z

it seems that the bug ultimately comes down to this line: "https://github.com/ElementsProject/elements/blob/c7e856fab1b0c4d37005e25c0940184d812a26a0/src/script/sigcache.cpp#L60 " . range proofs that hit the cache that is keyed to this hash, are counted as valid without checking. the problem is that the data fed into the hash is not length checked. so you can feed different (proof, commitment, asset) tuples into it by varying the length of the proof. the proof can be totally invalid and it'll still come back as valid. and this explains why OP_RETURN is involved: you need an extra output to sort of 'consume' the invalid amount. so you make a totally valid output of 4000 btc and you shove the negative corresponding value in the OP_RETURN. Apparently the anomalous size of the proof confirms this reading (bulletproofs rangeproofs have specific sizes based on the bit range 0..2^k). The only part I don't get is why there was a consensus deviation. Did some nodes have the rangeproof caching disabled or something?

Oh. Double wow.

2026-09-07T00:46:54Z

In reply to nevent1q…zww2
_________________________

Oh. Double wow.

So they were caching range proofs and it's a caching bug? ...

2026-09-06T22:55:31Z

In reply to nevent1q…sce4
_________________________

So they were caching range proofs and it's a caching bug? Like in that they bypass verification of the rangeproof on a cache hit? That's what I'm seeing now. If so, that's... terrible?

This patch seems to be the fix: https://github.com/ElementsProject/elements/commit/c26d719c29a40da280a825b25657e9c3d8bc7d99

Yeah I'm seeing now it's not as simple as that! Which is ...

2026-09-06T22:34:45Z

In reply to nevent1q…4sud
_________________________

Yeah I'm seeing now it's not as simple as that! Which is a relief, but then again I haven't seen the right explanation yet, so I should hold off on that relief ...

I think GLM 5.2 might have found this. See Poelstra's ...

2026-09-06T22:11:17Z

I think GLM 5.2 might have found this. See Poelstra's response in this github thread: https://github.com/ElementsProject/elements/issues/1325 . What if someone created a transaction with an OP_RETURN that has a pedersen commitment that has some big negative value? If it gets included in the balance equation, that can work *only if* the range proof is not attached to that output.

See https://blockstream.info/liquid/tx/f24a4b179b5cc7e88b25a763911f7cbdf2bf45d1d1b5ab611e94461cef0a183f?expand - this is the transaction at which people are saying there's a consensus split.

quoting
nevent1q…mlcr
https://x.com/i/status/2096696669287178696

Steven Roose (who used to work on Liquid) seems to think it's a confidential transactions bug. Seeing others tend towards that conclusion too.

Wow.

Notably they're still using original flavor CT not bulletproofs afaik.

Oh I am wrong, they do use bulletproofs now: ...

2026-09-06T21:57:59Z

In reply to nevent1q…gxd2
_________________________

Oh I am wrong, they do use bulletproofs now: https://docs.liquid.net/docs/confidential-transactions

https://x.com/i/status/2096696669287178696 Steven Roose (who used ...

2026-09-06T21:42:28Z

https://x.com/i/status/2096696669287178696

Steven Roose (who used to work on Liquid) seems to think it's a confidential transactions bug. Seeing others tend towards that conclusion too.

Wow.

Notably they're still using original flavor CT not bulletproofs afaik.

They're already exceptionally good at hardcore cryptography i ...

2026-09-06T20:50:57Z

In reply to nevent1q…aeyt
_________________________

They're already exceptionally good at hardcore cryptography i think. As of last few months, for sure. But it's less likely to be there. Just vague opinion, to be clear.

Iiuc there are some rules for automated signing by the HSMs? ...

2026-09-06T20:49:01Z

In reply to nevent1q…xadl
_________________________

Iiuc there are some rules for automated signing by the HSMs? Maybe it's there somewhere?

Yes i was joking, but jokes should be a little closer to reality ...

2026-09-06T19:54:53Z

In reply to nevent1q…rx56
_________________________

Yes i was joking, but jokes should be a little closer to reality to be funny. Also this maybe isn't a great topic to joke about: *some* people, even if not nany, presumably lost money. Unless white hat is true , which I guess to be fair is a pretty decent chance.

Disclaimer: not necessarily effective 😆 This is genuinely ...

2026-09-06T19:49:56Z

In reply to nevent1q…57rz
_________________________

Disclaimer: not necessarily effective 😆

This is genuinely crazy though. All the people telling you multisig is the right security solution, might give you pause ...

Nostr event nevent1qqsrhj4cnp5qkddnjs46qjwvvsmv7fyfeksdkht0vuq0ygp49kvvuhqzypn4hp87wh3pd2u5036r3mj3njnhw5mkmhc9mt0m5cnch5qju8tjsvm640l

2026-09-06T19:41:06Z

Liquid rolling back the chain in 3.. 2...

Only whitelisted addresses can peg out iirc.

2026-09-06T19:40:37Z

In reply to nevent1q…evud
_________________________

Only whitelisted addresses can peg out iirc.

Well sure, not only does that risk always exist but, for now, ...

2026-09-06T19:18:14Z

In reply to nevent1q…avfp
_________________________

Well sure, not only does that risk always exist but, for now, it’s actually worse with AI-powered attacks. It might actually get better, in future though, according to the above argument.

A little anti-doomer take for those of you (like me!) getting ...

2026-09-06T19:09:36Z

A little anti-doomer take for those of you (like me!) getting worried about AI. It's just a small niche but maybe the same thoughts could cross-apply to other areas of life:

I don't think it's very likely that AI will find classical breaks (as in, poly-time algos) to ECDLP. That's just an offhand intuition, but it's a very deep mathematical problem (factoring, also, though I guess that one is a bit safer). While at the same time, consider some of the big-picture problems - not hardness problems, but things we want to do, but can't - like functional encryption, indistinguishability obfuscation, fully homomorphic encryption, post-quantum analogs that don't have horrible tradeoffs, in cryptography. It's orders of magnitude more likely that AI will find *very* good solutions to those kind of problems. If they do, it will mean that things like Bitcoin become vastly more powerful, because vastly more useful. And the one thing that really underpins Bitcoin is not susceptible to some vast intelligence changing its character: energy scarcity. if you unlock a 10x on how much energy humanity has access to, obviously that changes a ton of things, but it doesn't change that energy is scarce. it's the finiteness that matters in proof of work, not the number. so short version: much *better* cryptography meaning much better bitcoin usability, is actually a pretty likely outcome.

Your 2nd Q: the ability to transact offchain in a system with ...

2026-09-06T16:23:30Z

In reply to nevent1q…uky7
_________________________

Your 2nd Q: the ability to transact offchain in a system with extra features is massive: better privacy, speed, scale and trustless contracts like options and dexes. Not saying you just get that all easily, some of it's hard and some near impossible. To get that for bitcoin without sacrificing trust is a kind of holy grail. Lightning got a small part of that, with some tradeoffs, and it already massively changed the usability of bitcoin as money.

Exactly, they 'exist' as per, anyone can write and ...

2026-09-05T15:09:26Z

In reply to nevent1q…uky7
_________________________

Exactly, they 'exist' as per, anyone can write and execute the code right now, but it isn't usable for existing LN. Just trying to counter the tendency to assume that that means you literally can't design a system using them; you can.

Why haven't people been working on arbitrarily complex ...

2026-09-05T13:20:22Z

Why haven't people been working on arbitrarily complex contracts *inside* a Lightning channel?

Think BitVM but without the ugliness of what's needed to make dispute resolution work non-interactively onchain.

(Oh and btw we *do* have PTLC; anyone can deploy it in their own channel.)

You can bet signet coins at https://thimbly.org .. implementation ...

2026-09-04T20:15:15Z

You can bet signet coins at https://thimbly.org .. implementation of babilonia . need to use a psbt supporting wallet for signing, works with Sparrow and Core and should be taproot. Though i guess you could do it non-taproot but you need the psbt co-signing feature. paper and code are linked at the top of the page. This is just for demonstration purposes, the better way of doing it is p2p via a Core node, though this is perhaps more fun :)

It'd be kind of normal to be fixed size. Just like a ...

2026-09-04T11:18:15Z

In reply to nevent1q…dm57
_________________________

It'd be kind of normal to be fixed size. Just like a signature has a fixed size, so does a zkp.

blockstream.info/signet lowest priority fee: 4277 sats/vb. ...

2026-09-04T11:16:51Z

blockstream.info/signet lowest priority fee: 4277 sats/vb.

It's been drifting up. I guess something broke their end, I'm kind of curious what, though.

There's also plenty of precedent for government level ...

2026-09-03T18:01:41Z

In reply to nevent1q…0afv
_________________________

There's also plenty of precedent for government level reserves just getting swiped, especially by the USA (France historically, Russia more recently, though that was,USD), but also the UK (Venezuela case iirc).

I tend to agree.

2026-09-03T17:08:55Z

In reply to nevent1q…tx8j
_________________________

I tend to agree.

Uh maybe it's not exactly the antipode of CSV exactly. ...

2026-09-03T12:14:25Z

In reply to nevent1q…0u2v
_________________________

Uh maybe it's not exactly the antipode of CSV exactly. There's nuance there. But setting that term aside, you get the point.

They want 100% recoverability for a wallet, from the blockchain ...

2026-09-03T12:13:04Z

In reply to nevent1q…ta98
_________________________

They want 100% recoverability for a wallet, from the blockchain itself. This is the counterargument to client side validation. Not saying I buy it myself, but the argument can be made.

So suppose that some people out there were developing a protocol ...

2026-09-02T19:58:12Z

So suppose that some people out there were developing a protocol for private payments on bitcoin that required 800 byte OP_RETURNs per transaction.

How would you feel about that?

Yeah I saw that too.

2026-09-01T20:48:19Z

In reply to nevent1q…kd4m
_________________________

Yeah I saw that too.

Is there some nasty stuff going down? Protonmail was clearly ...

2026-09-01T17:46:27Z

Is there some nasty stuff going down? Protonmail was clearly having a big problem today, then I see news on twitter/X about email leaks? Nordvpn?

https://www.inventati.org/campaign/press I love how they explain ...

2026-08-31T11:20:03Z

https://www.inventati.org/campaign/press

I love how they explain derisking here as if it's some obscure thing that they wouldn't have known in advance.

They don't mention bitcoin. Why wouldn't something like autistici.org use bitcoin? (I mean, also tor, but they probably do use that?).

I think there's a certain wilful ignorance about this stuff from a lot of 'activists'. If they're not even prepared to route around the banking system, how much of it is just LARPing.

cryptocurrency does not require human middlemen: that was the ...

2026-08-31T11:14:24Z

In reply to nevent1q…je2g
_________________________

cryptocurrency does not require human middlemen: that was the point of my post.