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!)
Shrinking offchain data requirements for Groth16 verification on Bitcoin
Taking Groth16 garbling from gigabytes to megabytes
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 😆
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 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 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).
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 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.
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.
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?)