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

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

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

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 I've forgotten 😄 Also I think I am not in the affected group anyway.