Nostr notes by waxwing

Little update on Lichen: switching the onchain verification to ...

2026-10-28T01:49:31Z

Little update on Lichen: switching the onchain verification to BABE results in only a few onchain txs instead of 20-25 (so, a much smaller exit delay) and reduces onchain costs by about 7x in terms of bytes. Worst case attacks in terms of a mass exit can then allow scale of about 10k to 50k users with a single operator/hub. And fees kept in reserve are also far lower.

Already got a long way through building this out using LLMs and there are further optimizations possible afaik such as duty free bits.

Afaict the bottleneck in lichen is all with the hub(s): how much liquidity can they provide, at what price, and they need to stay fully online and available. Very easy for the user: they don't have to watch the bitcoin chain at all. It's like an LSP model, but way better imo.

The synergy between BABE and lichen appears to be very strong, enough that I would claim that switching from BitVMX changes this from 'possible' to 'practical'. Still got to do a lot of security analysis, but, optimistic.

Email was hacked.

2026-10-26T06:36:43Z

In reply to nevent1q…rdkf
_________________________

Email was hacked.

For anyone interested: these proofs are actually STARKs ; they ...

2026-10-21T13:37:23Z

In reply to nevent1q…x6a0
_________________________

For anyone interested: these proofs are actually STARKs ; they are proved recursively by the sequencer. any final withdrawal proof by the user does what Risc-0 calls 'shrink-wrap', in which you make a groth16 (so, SNARK) proof that the STARK proof validates. That's why the on-bitcoin verification is O(1). The STARK proof is also O(1) because it's a recursive proof: it says "this proof is valid, plus this other one new chunk is valid'.

Yes it's succinct. Recursive proof.

2026-10-21T11:56:32Z

In reply to nevent1q…5kg8
_________________________

Yes it's succinct. Recursive proof.

on branch `anchor` there's now a fairly complete setup: the ...

2026-10-21T02:06:27Z

on branch `anchor` there's now a fairly complete setup: the sequencer posts anchors to bitcoin each L2 block. when you withdraw, you prove that an anchor is embedded with enough PoW and at least 10 blocks deep. You prove that your withdrawal represents a valid set of state transitions from genesis. These things together mean that even if the sequencer is colluding against you, you can't be cheated out of your money. And the transfers on L2 are all shielded (like zcash). The remaining risk is censorship: the sequencer censors your withdrawal transaction.

The demo now shows the anchoring so you know how final your transaction is.

https://github.com/AdamISZ/lichen/tree/anchor

quoting
nevent1q…u6rk
Shielded transfers on L2. All state transitions are proved valid. Spending costs the sender a 5-10s proof (it's not very optimized).

A question for anyone following along: is Bob safe?

#lichen

Unlimited Liquid withdrawals?

2026-10-20T20:31:17Z

In reply to nevent1q…xevw
_________________________

Unlimited Liquid withdrawals?

The private keys shall be randomly chosen between 1 and the curve ...

2026-10-20T20:30:30Z

The private keys shall be randomly chosen between 1 and the curve order.

Well, they're between 1 and 256. Good enough right? 🤦‍♂️

This is an internet Certificate Authority?

https://bugzilla.mozilla.org/show_bug.cgi?id=2083449#c5

In all the frantic discussions about how thoroughly fucked all ...

2026-10-19T21:19:08Z

In all the frantic discussions about how thoroughly fucked all blockchains are in the case of an ECDLP break EITHER from AI OR from Quantum, no one seems to have noticed something important: a halt to a proof of work chain is a fundamentally more meaningful concept than a halt to a proof of stake chain that maintains consensus on a threshold signature scheme that uses discrete logs - which includes BLS as well as Schnorr, of course, so it covers Ethereum and I guess most all (?) PoS chains. there is no objective halt height if the thing that determines our current height becomes forgeable. In a quantum scenario (ECDLP broken by CRQC) that most envisage, the proof of work headers chain is untouched. assuming there was some "flag day". But with consensus over a forgeable signature scheme .. sheesh.

Shielded transfers on L2. All state transitions are proved valid. ...

2026-10-19T20:31:29Z

Shielded transfers on L2. All state transitions are proved valid. Spending costs the sender a 5-10s proof (it's not very optimized).

A question for anyone following along: is Bob safe?

#lichen

The problem with BABE and how Lichen solves it: In BABE, you set ...

2026-10-18T15:36:41Z

The problem with BABE and how Lichen solves it: In BABE, you set up a puzzle to be solved later, like "if you can at any time find a valid proof for the statement that this 1BTC belongs to you, you can claim it". The problem is that the amount, 1BTC is fixed right there, at setup, before anything happened. So the only system you can use that for are things like claiming collateral or whatnot. Very limiting. If you made the statement say "I have a valid claim on an amount x" with x being a variable, then they can claim the prize with x=0.01 while the prize is 1BTC; useless.

In Lichen we can exploit the fact that the hub is *required* to answer requests (hub's have to stay live; users don't, until timeout), as follows: first, the statement that BABE's WE works over becomes: "I have an amount x **which the hub signed** and a valid proof that my balance on L2 is > x" where the proof ensures both 'x's are the same. It's bizarre at first until you realize, the hub doesn't sign 'x' to say 'x is a valid withdrawal'; he signs 'x' to commit the user to that choice. So the process goes: user claims 'i want to withdraw x', hub (forced by liveness; loses after timeout) must winternitz-sign x. Then user can use the setup-at-contract-start BABE setup to extract the spending secret which then fires off into the bit decomposition, that actually pays out that same x.

Currently I'm about 80% sure this works in practice, not just theory. And if it does, dispute goes from worst-case 23 transactions onchain to worst-case 4 or 5 and *maybe* 20kb. In either case, it's zero normally. ( Lichen: if you don't know what it is, see the paper in https://github.com/AdamISZ/lichen, also the explainers under docs/ ).

Right now setting up a shielded transfers L2 using a basic design, just to create a prototype. Already done a fair few mutinynet tests of the existing BitVMX dispute (with its 20+ transactions, a lot more bearable on that chain of course!).

Damn i spoke to soon. NIST P256's generator's seed was ...

2026-10-17T00:55:27Z

Damn i spoke to soon.

NIST P256's generator's seed was found.

That's not Bitcoin's (secp256k1 is not a NIST curve).

Again it theoretically doesn't matter. But we'd still love to know!

quoting
nevent1q…un03
Wow!

https://www.anthropic.com/research/ecdsa-curve-origins

This is not a bad thing, don't worry 😄

The opposite: we now where G comes from in secp256k1. It was theoretically not a problem anyway. But now we know for ~sure it was not some weird backdoor.

This is quite an eye opener considering Greg was one of the ...

2026-10-17T00:51:58Z

In reply to nevent1q…unl9
_________________________

This is quite an eye opener considering Greg was one of the people who really investigated this back in 2013-14

https://news.ycombinator.com/item?id=50125089
I mean, even *he* isn't claiming they literally stole something, and the attribution barely matters. But still.

Wow! https://www.anthropic.com/research/ecdsa-curve-origins This ...

2026-10-16T19:15:47Z

Wow!

https://www.anthropic.com/research/ecdsa-curve-origins

This is not a bad thing, don't worry 😄

The opposite: we now where G comes from in secp256k1. It was theoretically not a problem anyway. But now we know for ~sure it was not some weird backdoor.

And re: your last paragraph, yes, totally, you buy inbound ...

2026-10-16T14:43:53Z

In reply to nevent1q…q75y
_________________________

And re: your last paragraph, yes, totally, you buy inbound liquidity, probably, just like you do now with an lsp.

The scenario is not so much "I want to move from hub A to hub ...

2026-10-16T14:42:37Z

In reply to nevent1q…0tfk
_________________________

The scenario is not so much "I want to move from hub A to hub B". Not saying that isn't interesting, but, to give you the flavor of motivation behind "we need to move money across hubs":

When I talk about different hubs I'm mostly trying to address this scalability problem: if there was just one mega-hub, everyone would have to join it and it would have to have huge liquidity and if it ever went down everyone would be trying to broadcast their withdrawal transactions at once. Bad. So, Alice wants to be with hub1 and Bob wants to be with hub2. As the paper notes you can't do that on one ledger and have them minting the same btc-flavor as one could cheat the other. So, you could have them on different ledgers minting their own btc-flavor. Then the question is if only 1000 people are on hub1 and 1000 on hub2 the ability to pay people is way too limited (10k or even 100k could work, instead, but same principle). So you want to *pay* from one hub to the other, and you could do that easily *using atomic swaps cross-ledger*: hub2 has a balance with hub1. Anyone like Alice on hub1 who wants to pay Bob on hub2, pays him with a two-transaction chain: they pay hub2-on-hub1 but only after hashlocks are set up to ensure that Bob gets paid on hub2 at the same time. (A two-hop route, if you prefer).

Remember the risk with cashu servers/hubs isn't honoring ...

2026-10-16T14:32:00Z

In reply to nevent1q…7yuq
_________________________

Remember the risk with cashu servers/hubs isn't honoring withdrawals as much as, they just spend the bitcoin, since they can. OK I guess the distinction isn't important, in both cases as a user this only matters when you want to get money out.

But in trying to understand why lichen is different, remember that before the timeout of your contract with the hub (3 months, 6 months, whatever you choose), the money is locked in a 2 of 2: it can only go out by *you* producing a ZKP saying you're owed X, or to either you or the hub if either side can prove the other cheated, or all to the hub after the timeout if you go silent after 6 months. Things like "payment from Alice on hub1 to Bob on hub2" would work as classic swaps, with an intermediary (think hub2 having a balance on hub1 and your money flows through it. But that's another thing, the "unruggable" is about that 2 of 2 that you have with your hub.

Small community discourse is always higher quality, as we see ...

2026-10-15T23:00:28Z

In reply to nevent1q…0cxx
_________________________

Small community discourse is always higher quality, as we see here.

Yeah claude helped me partly understand the subtle differences. ...

2026-10-15T18:51:12Z

In reply to nevent1q…aqre
_________________________

Yeah claude helped me partly understand the subtle differences. Bit sleep deprived from travel rn, I'm sure I'll get a better handle on it later 😄

This reminds me a lot of the tlsnotary work we did back in 2013. ...

2026-10-15T16:06:30Z

In reply to nevent1q…6sk6
_________________________

This reminds me a lot of the tlsnotary work we did back in 2013. At a glance it's solving a slightly different problem. Cool idea either way.

It's more zcash or monero style transfers inside, than ecash ...

2026-10-15T13:40:43Z

In reply to nevent1q…ueds
_________________________

It's more zcash or monero style transfers inside, than ecash style, because it's transfers on an independent ledger. Ecash mints delink payment events; independent ledgers, you can just broadcast your tx p2p, from tor. Just a ledger/blockchain, with the exception you withdraw by interacting with the same guy you deposited at. Receiver doesn't have to be online.

Damn it's hard to describe this succinctly because it's a really a hybrid between an ecash server for btc, with its backing, but now trustless modulo an L2 consensus, and a sidechain for btc. All I can say is, read the paper.

I feel rather the same. Especially because paying between hubs, ...

2026-10-15T04:15:13Z

I feel rather the same. Especially because paying between hubs, I've just realized, should be just as simple as it is between ecash servers now.

quoting
nevent1q…xz2z
An ecash mint which can't rug its users?

Yes, please sign me up!!

#privacy

nevent1q…ueda

It's not fully developed yet, but the idea is: once ...

2026-10-14T21:41:28Z

In reply to nevent1q…v5df
_________________________

It's not fully developed yet, but the idea is: once you're on L2 you could/would have better privacy than Lightning, for transfers *inside* it, but your deposit and withdrawals are with the same one hub, which is worse(even that maybe isn't clear).

A more interesting comparison, in some ways, is ecash servers like cashu. They delink deposits and withdrawals, so they have really good privacy, but the server can rug the users' money. Here you're guaranteed to get your money out.

Nostr event nevent1qqsv7tlsz84f9j4nvvrelsdm86499vjcpgp77vl79melpg6fwrufq8gzypn4hp87wh3pd2u5036r3mj3njnhw5mkmhc9mt0m5cnch5qju8tjslz5eye

2026-10-14T12:18:46Z

https://www.coinbase.com/blog/working-together-on-btc-post-quantum-readiness

This is an interesting perspective from the biggest custodian on the planet.

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.