Claude is really good at code, agree. I'm talking about some cryptography problems that have really chunky mathematical reasoning steps. Also, I don't really keep up with the models so 'Kimi' - I just mean whatever Maple is giving me. K2.5 apparently.

Yeah perhaps, I doubt it but it's a valid point (about fission).

Super intelligent AI possibility is definitely a wild card; very new thing, hard to judge.

Oh yeah, I forgot about that. It was all the rage back when I was more into physics.

Yes.

Got to disagree here, it's one of the more profound questions in the space that @Milos is raising: "but how does ZKP usage affect auditability". See, there's a trite response: addition holding under a homomorphism still means addition holding (think like "well, the ZKP proves that new coins weren't minted, so just because you can't read the balance directly doesn't mean it isn't guaranteed to be fixed supply!"). But in a profound way this is not a good analysis: we don't only consider correctness, we consider recovery modes under incorrectness: *whatever* reason for random new bitcoin getting minted, we will see it in the utxo count (gettxoutsetinfo rpc); obviously it would be a bug, but we'd see it. in zcash it was warned in advance (by people like Peter Todd especially, but also I and others raised this alarm) that you don't have that counting function, so if *any part of the stack* fails, you will not know. That problem cross applies to *any* property you want a public blockchain to have, that if you cover it with ZK you need to be 100% sure there is no error, and you cannot be. None of this is some kind of checkmate atheists, never use ZKP, but it should be food for very serious thought. My way of putting this years ago is that "it's in the DNA of blockchains to be public". This is why I've always been focused on ZK for second layers.

Access to communication channels could be crucial to saving your life.

Yes. But Israel and the UAE have not totally shut down the internet.

Meh, that's mostly a mischaracterization I think. Bulletproofs as originally conceived was a valuable addition to the mix; it didn't have succinct verification so it couldn't *directly* compete with Groth16 and other pairing based schemes but it did have: no trusted setup and no assumptions outside of ECDLP. The other option was STARKs but the proof sizes were large. The verification scaling being bad was addressed in HALO and HALO2 with some rather clever tweaks, keeping the no-trusted-setup property while getting succinct verification. So nowadays it's a general class of algorithms see "folding schemes", "inner product arguments" and those can be flavours of zkSNARK; bulletproofs literally purely as originally written, yes, is rarely used, although perhaps occasionally still finds a use - an example is Curve Trees, which you mention. But it's also a paradigm which continues to be used in more sophisticated forms. Perhaps a confusion here is you were thinking about 'bulletproofs for confidential transactions via range proofs' (still used in Monero) as opposed to 'bulletproofs as a general ZKP system' (which was in the original paper).

Not misleading. It's been known as ICE for decades in the finance world.

While I totally understand your point: namely that the prefix for the type is not the same thing as the variable name - and your point about Satoshi's own documentation is correct, still, saying that "scriptSig" and "scriptPubkey" are wrong names coming from misunderstanding, I would claim itself is a misunderstanding :) The best way to think of these two things are as *generalizations* of the concepts of signature, public key in a public key digital signature scheme. For the obvious reason that Bitcoin Script itself is designed to allow that generalization: you're not limited to validating a signature against a single public key, but are instead evaluating the predicate script-verify(script-pubkey, script-signature, message) instead of just verify(pubkey, signature, message). From what I know that's why scriptPubkey and scriptSig stuck.