Good morning Erik and Jeremy, > The "for" arithmetic here is largely to mean that this cleverness allows an > implementation of `OP_CHECKSIGFROMSTACK`, using arithmetic operation `OP_ADD`. > > To my mind this cleverness is more of an argument against ever enabling > `OP_ADD` and friends, LOL. > This is more of a "bad but ridiculously clever thing" post than a "Bitcoin > should totally use this thing" post.
Turns out `OP_ADD` is actually still enabled in Bitcoin, LOL, I thought it was hit in the same banhammer that hit `OP_CAT` and `OP_MUL`. Limited to 32 bits, but that simply means that you just validate longer bitvectors (e.g. the `s` in the "lamport-sign the EC signature") in sections of 32 bits. In any case, the point still mostly stands, I think this is more of a "overall bad but still ridiculously clever" idea; the script and witness sizes are fairly awful. Mostly just worth discussing just in case it triggers somebody else to think of a related idea that takes some of the cleverness but is overall better. On the other hand if we can actually implement the "Lamport-sign the EC sig" idea (I imagine the 32-bit limit requires some kind of `OP_CAT` or similar, or other bit or vector slicing operetion), that does mean Bitcoin is already quantum-safe (but has a fairly lousy quantum-safe signing scheme, I really do not know the characteristics of better ones though). Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
