waxwing

Bitcoin, cryptography, Joinmarket etc.

Public Key

npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7

Profile Code

nprofile1qqsxwkuyle67y94tj378gw8w2xw2wa6nwmwlqhddlwnz0z7sztsaw2qpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0dstxtsm3

Publishing to

relay.damus.io

nos.lol

Author Public Key

npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7

Show more details

Last Notes

2026-11-12 00:40:58 UTC

Some interesting feedback on my article at stacker news: https://stacker.news/items/1612629
#nevent1q…68se

2026-11-11 01:54:53 UTC

- reply

It uses a fairly standard 2PC approach- Garbled circuits with cut and choose for the malicious setting.
I think that part's ok at least at high level.

2026-11-11 01:42:20 UTC

several interesting things! one is @m0wer 's repo: https://github.com/m0wer/coinjoinctf - this came out of a long chat we had about 'can you pay someone a bounty if they successfully deanonymised a coinjoin (graph)?" and have it actually be a fair bet? using cryptography, we think yes! take a look. a second thing is i wrote an article that bitcoin++ are apparently about to publish, i will post it here when they do. a third thing is, again in collaboration with @m0wer , he was enthused by lichen to actually try to make an ecash server work with it, so my earlier quip "an ecash mint that can't rug you" could be becoming a reality! (watch this space).

2026-11-06 23:41:22 UTC

- reply

i have been frantically trying to find a justification as to why we should build lichen on top of Bark, for this very reason :)

2026-11-06 22:32:52 UTC

- reply

He's written a lot in his fungi protocol project. I think this might be part of that overall thinking.
https://fungi-protocol.github.io/docs/
I may or may not have read part of what you linked but not sure.

2026-11-06 22:05:23 UTC

I gave a talk on lichen at bitcoin++ in Seoul. Here's the slides:
https://btcpp.nyc3.digitaloceanspaces.com/seoul/presentations/lichen-l2sinchannelsenforcedinbitcoin-1793924417028220841-873d1893b609.pptx

2026-11-05 07:53:23 UTC

Forst person to person lichen payment successful!
#nevent1q…r4aq

2026-11-04 23:16:14 UTC

Here's my address if you want to test sending somewhere:
8a8a116a8987ccd2e584b16c60a71df087c2eea4cafbcb98673d1e060ecc8b7d
#nevent1q…w035

2026-11-04 01:08:30 UTC

Thanks to Daniela Brozzoni (and bitcoin red team) for a scan that picked up several bugs in the old joinmarket-clientserver repo, one in particular that was an especially big deal - a direct funds loss of a sender in the old payjoin implementation (bip78). Thank god very few if any people really used that but we did include it directly in the client software, so I'm sure at least a few tried it here and there (with btcpayserver e.g.). I've now changed the repo from "archived; don't recommend you use this" to "archived and DO NOT USE THIS and BIG SCARY WARNING about funds loss" and repeated the warning on every release page just in case.
Worth mentioning that both I and, to a larger extent, @m0wer , did a fair bit of scanning of the joinmarket repos looking for bugs a few months back; we found quite a few but nothing with direct funds loss like that one ^ . So this was extremely valuable extra scanning.
https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/master/README.md
I recommend joinmarket-ng if you want to do joinmarket coinjoins, but bear in mind, I do not work on Joinmarket any more. The general meta comment is of course that "don't use unmaintained software in 2026" is good advice, because most things with any complexity are broken unless actively audited.

2026-11-01 23:19:09 UTC

A lichen L2 hub, running on Mutinynet, open for testing:
Mac or Linux. You need, on your machine, a C compiler (Mac: xcode-select --install; Debian/Ubuntu: build-essential) and Rust (rustup.rs). About 1 GB of disk and a few minutes to build:
git clone https://github.com/AdamISZ/lichen-gui
cd lichen-gui
./build.sh
target/release/lichen-gui
It opens a page in your browser. Then:
To connect to my hub you need the urls for the hub and sequencer, paste them into the fields to connect:
1. hub http://193.168.140.156:18310, sequencer http://193.168.140.156:18300. Check the keys it shows:
sequencer fc760de0f51debf97c3a116c19180660b21661c8ddfd5f18bcbae304a01b5ea5
hub 0d530a46a469ecaf7abe72a89cf737c88bf7dcb1ce149f86e0b8ae6186af8665
2. Open a contract (defaults: 100k deposit, 100k inbound). It shows a deposit address and amount, about 151k sats: pay it from https://faucet.mutinynet.com, in ONE payment. Opening takes a few minutes (it checks the hub's BABE setup and downloads about 240 MB).
3. Pay someone on the L2, or ask to be paid: near-instant. I'll keep an eye on replies here, if someone wants to test paying back and forth with me, send me your address here. My address is 8a8a116a8987ccd2e584b16c60a71df087c2eea4cafbcb98673d1e060ecc8b7d
4. Withdraw: about 5 minutes (it waits for an anchor on Bitcoin and its proof). Withdrawals and your reserve go to the wallet's own Bitcoin address, so you can pay your next deposit from it: the faucet is only needed once.
It's an early prototype: expect rough edges, and tell me what breaks. Disputes and shielded payments aren't in the GUI yet.
If you hadn't read anything I wrote here before about lichen, check out https://github.com/AdamISZ/lichen there's a paper there.

2026-10-30 21:26:20 UTC

the binance hack will be a huge setback for those people who want to push bitcoin and cryptocurrency as "legitimate". It hands a perfect argument to those in power who hate bitcoin and want to shut it down, much more so than say FTX which was just "a bunch of people getting scammed". Now they can say (they already did, but this hack is *huge*) that we are literally funding North Korea's entire nuclear weapons program.

2026-10-29 22:27:24 UTC

- reply

Binance got hacked?

2026-10-29 20:49:17 UTC

I could be wrong, but what I'm noticing about these headline-grabbing (deservedly) results from frontier models on long-held theories of computation limits is, that they are more showing that the long-held theories are approximations, not so much that they are wrong. The "Exponential Time Hypothesis" and the square-root bound for ECDLP are in this category: both the results that show they are wrong, show they are wrong to an absurdly infinitesimal extent. Maybe it's more like saying that things are fuzzier than you think, not clean, not so much saying that the general rule you have in mind is wrong. Just a guess, though.

2026-10-29 03:48:34 UTC

- reply

It's like a little 'observation' in mathematics. Something too small to be given the name 'Theorem', basically.
Or a step *towards* a theorem that needs a bunch of steps in place before it can all be put together.

2026-10-28 22:53:18 UTC

How have I only today learned that the plural of lemma is lemmata.

2026-10-28 18:44:37 UTC

Cool idea.
https://huggingface.co/benthecarman/Qwen3.8-27B-BTC-Script-RL

2026-10-28 01:49:31 UTC

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.

2026-10-26 06:36:43 UTC

- reply

Email was hacked.

2026-10-21 13:37:23 UTC

- reply

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'.

2026-10-21 11:56:32 UTC

- reply

Yes it's succinct. Recursive proof.

2026-10-21 02:06:27 UTC

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
#nevent1q…u6rk

2026-10-20 20:31:17 UTC

- reply

Unlimited Liquid withdrawals?

2026-10-20 20:30:30 UTC

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

2026-10-19 21:19:08 UTC

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.

2026-10-19 20:31:29 UTC

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
https://blossom.primal.net/da0ee808c671837a83f6dcf66e45ad0b5c2a550f0a9d27e623eaa0a4220ef238.jpg

2026-10-18 15:36:41 UTC

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!).

2026-10-17 00:55:27 UTC

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!
#nevent1q…un03

2026-10-17 00:51:58 UTC

- reply

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.

2026-10-16 19:15:47 UTC

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.

2026-10-16 14:43:53 UTC

- reply

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

2026-10-16 14:42:37 UTC

- reply

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).

2026-10-16 14:32:00 UTC

- reply

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.

2026-10-15 23:00:28 UTC

- reply

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

2026-10-15 18:51:12 UTC

- reply

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 😄

2026-10-15 16:06:30 UTC

- reply

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.

2026-10-15 13:40:43 UTC

- reply

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.

2026-10-15 04:15:13 UTC

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.
#nevent1q…xz2z

2026-10-14 21:41:28 UTC

- reply

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.

2026-10-14 12:18:46 UTC

https://www.coinbase.com/blog/working-together-on-btc-post-quantum-readiness
This is an interesting perspective from the biggest custodian on the planet.

2026-10-14 07:43:03 UTC

- reply

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.

2026-10-14 01:02:56 UTC

- reply

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

2026-10-14 00:12:03 UTC

- reply

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

2026-10-13 20:06:11 UTC

- reply

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.

2026-10-13 19:47:28 UTC

- reply

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.

2026-10-13 19:39:22 UTC

- reply

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.

2026-10-13 19:28:50 UTC

- reply

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

2026-10-13 18:30:15 UTC

- reply

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.

2026-10-13 15:50:32 UTC

- reply

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.

2026-10-13 14:05:16 UTC

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.

2026-10-13 13:47:18 UTC

- reply

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 😄

2026-10-13 13:25:55 UTC

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
#nevent1q…crcg

2026-10-12 21:52:24 UTC

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

2026-10-12 17:31:02 UTC

- reply

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/

2026-10-12 16:35:59 UTC

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

2026-10-11 17:58:39 UTC

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.

2026-10-11 17:51:26 UTC

- reply

OK!

2026-10-10 11:55:29 UTC

- reply

What about tamper evident seals.

2026-10-10 11:35:43 UTC

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.

2026-10-09 21:48:16 UTC

- reply

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.

2026-10-09 19:33:07 UTC

- reply

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.

2026-10-09 19:31:04 UTC

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.

2026-10-08 22:14:38 UTC

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.

2026-10-08 20:17:09 UTC

- reply

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

2026-10-08 20:10:45 UTC

https://bounty.blink.sv/
Very interesting read!
H/T @nprofile…jtmp

2026-10-08 20:09:51 UTC

- reply

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

2026-10-05 19:34:20 UTC

- reply

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.

2026-10-05 12:52:24 UTC

- reply

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

2026-10-05 12:50:18 UTC

- reply

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.

2026-10-05 12:47:24 UTC

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.

2026-10-05 12:18:50 UTC

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...

2026-10-04 18:56:56 UTC

- reply

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

2026-10-03 00:36:25 UTC

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.

2026-10-01 17:39:22 UTC

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.

2026-09-28 13:15:31 UTC

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!

2026-09-24 11:50:24 UTC

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

2026-09-23 12:27:27 UTC

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 😆

2026-09-20 18:56:42 UTC

- reply

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

2026-09-20 18:14:35 UTC

- reply

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.

2026-09-20 12:58:05 UTC

Does libsecp256k1 not expose scalar inversion?
I mean it fits the longstanding philosophy but it's still slightly irritating 😄

2026-09-19 19:47:23 UTC

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...

2026-09-19 13:23:59 UTC

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).

2026-09-15 17:52:21 UTC

My bugfix PR was closed after 8 years. With a pretty good reason! 😆
https://github.com/btcsuite/btcd/pull/1108#pullrequestreview-5213530739

2026-09-15 02:03:33 UTC

- reply

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.

2026-09-14 19:59:25 UTC

- reply

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.

2026-09-14 18:53:54 UTC

- reply

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

2026-09-14 01:26:31 UTC

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.

2026-09-14 00:00:05 UTC

- reply

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.

2026-09-12 21:30:28 UTC

- reply

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.

2026-09-12 19:58:18 UTC

- reply

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.

2026-09-12 17:51:25 UTC

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.

2026-09-09 13:34:24 UTC

- reply

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.

2026-09-09 13:17:02 UTC

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.

2026-09-08 19:42:07 UTC

- reply

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?

2026-09-08 19:31:08 UTC

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.

2026-09-08 13:26:29 UTC

- reply

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

2026-09-08 02:48:39 UTC

- reply

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.

2026-09-07 18:25:33 UTC

- reply

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.

2026-09-07 16:35:39 UTC

- reply

'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.

2026-09-07 15:38:55 UTC

- reply

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.

2026-09-07 14:37:02 UTC

- reply

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