rich1.0ZmnSCPxj [ARCHIVE] (npub1g5…3ms3l)https://yabu.me/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lnjumphttps://yabu.me📅 Original date posted:2021-04-16 📝 Original message:Good morning LL, > On Tue, 16 Mar 2021 at 11:25, David A. Harding via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote: > > > I curious about whether anyone informed about ECC and QC > > knows how to create output scripts with lower difficulty that could be > > used to measure the progress of QC-based EC key cracking.  E.g., > > NUMS-based ECDSA- or taproot-compatible scripts with a security strength > > equivalent to 80, 96, and 112 bit security. > > Hi Dave, > > This is actually relatively easy if you are willing to use a trusted setup. The trusted party takes a secp256k1 secret key and verifiably encrypt it under a NUMS public key from the weaker group. Therefore if you can crack the weaker group's public key you get the secp256k1 secret key. Camenisch-Damgard[1] cut-and-choose verifiable encryption works here. > People then pay the secp256k1 public key funds to create the bounty. As long as the trusted party deletes the secret key afterwards the scheme is secure. > > Splitting the trusted setup among several parties where only one of them needs to be honest looks doable but would take some engineering and analysis work. To simplify this, perhaps `OP_CHECKMULTISIG` is sufficient? Simply have the N parties generate individual private keys, encrypt each of them with the NUMS pubkey from the weaker group, then pay out to an N-of-N `OP_CHECKMULTISIG` address of all the participants. Then a single honest participant is enough to ensure security of the bounty. Knowing the privkey from the weaker groups would then be enough to extract all of the SECP256K1 privkeys that would unlock the funds in Bitcoin. This should reduce the need for analysis and engineering. Regards, ZmnSCPxj