waxwing's avatar
waxwing
npub1vadc...nuu7
Bitcoin, cryptography, Joinmarket etc.
waxwing's avatar
waxwing 15 hours ago
several interesting things! one is @m0wer 's repo: - 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).
waxwing's avatar
waxwing 6 days ago
Here's my address if you want to test sending somewhere: 8a8a116a8987ccd2e584b16c60a71df087c2eea4cafbcb98673d1e060ecc8b7d View quoted note →
waxwing's avatar
waxwing 1 week ago
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. 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.
waxwing's avatar
waxwing 1 week ago
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 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 there's a paper there.
waxwing's avatar
waxwing 1 week ago
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.
waxwing's avatar
waxwing 1 week ago
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.
waxwing's avatar
waxwing 1 week ago
How have I only today learned that the plural of lemma is lemmata.
waxwing's avatar
waxwing 2 weeks ago
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.
waxwing's avatar
waxwing 3 weeks ago
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. View quoted note →
waxwing's avatar
waxwing 3 weeks ago
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.
waxwing's avatar
waxwing 3 weeks ago
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 image
waxwing's avatar
waxwing 3 weeks ago
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!).
waxwing's avatar
waxwing 3 weeks ago
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! View quoted note →
waxwing's avatar
waxwing 3 weeks ago
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. View quoted note →
↑