On Tue, Dec 19, 2023 at 11:07 AM <yuri...@pm.me> wrote: > > Thank you for the question, Boris. That was an easy one: > > Short answer is Lamport hashes are protected by long hash of key fingerprint > an ECC (Schnorr or otherwise conventional) public-key, which is not published > until first transaction. For clarity: > > HL(.) = serial-work- and memory-*hard* hash with *short* digest (ex.: Argon2 > with ~ 12 bytes output. "L" for "Lamport"); > HC(.) = nonspecific representation of conventional, serial-work- and > memory-*easy* hashes with *long* (brute-force-resistant) digest length. "C" > for "Conventional"; > KDF(.) = conventional key deriving function > ECCPUB = public key correspondent to ECCPRI > ECCPRI = KDF(seed, tag) //conventional BTC signing key (could be Schnorr > instead) > LAMPPUB = HL(LAMPPRIi) > LAMPPRI = HL(seed, tag) //Though it is (more) feasible to crack a seed S that > works as pre-image to LAMPRI, such seed can only be deemed valid if the > public key correspondent to KDF(s) = ECCPUB, so ultimately, cracking seed is > still as hard as cracking a conventional seed. > ADDR = H(ECCPUB, LAMPPUB) //Conventional BTC key fingerprinting with > conventionally used hashes and their respective brute-force-resistant digest > lengths > TX = plaintext transaction > LSIG = HL(TX, LAMPPRI) > COMMITMENT = Smart contract stating "This UTXO is frozen until one of the > following happens: A) publishing of a L such that HL(TX,L) = LSIG before T2 > in which case TX is deemed valid and executed, or B) T2 blocks from now, when > miner of LSIG has gets F1+FF1, and the miner of COMMITMENT gets FC, both from > UTXO" > BL = "Bundle of Lamport scheme" = (TX, LSIG) > BC = "Bundle of Commitment and Conventional Signing" = (COMMITMENT, > ECCPRI(COMMITMENT), ECCPUB, LAMPPUB) //LAMPPUB is added here to allow > easy verification that ECCPUB corresponds to ADDR > BT = "Total Bundle" = (BL, BC) > F1 = fee offered to mine BL > FF1 = fine offered to miner of BL to compensate for delay > FC = fee offered to mine BC in case of default > T0 = Block height of broadcasting of BT > T1 = Block height owner should aim at broadcasting LAMPPRI block ~ T0+1 to > T0+6 blocks. This is to protect owner from dissensus (revealing LAMPPRI in a > block and have it utilized to forge transaction in a competing block of same > height). > T2 = Block height of expiration of commitment ~ T0+24 hours to T0+ a few days > to protect user from execution of commitment being triggered by innocent > unavailability. > > From ADDR alone, Miners, cannot forge a valid LSIG, nor try to ascertain > LAMPPUB or LAMPPRI, because of pre-image-resistance of H(.) and brute-force > resistance of ECCPUB before being published. The saving happens because, safe > from T2 passing without LAMPRI being broadcasted, only BL and LAMPPR, and not > BC, end up in Blockchain. > > The proposed scheme, therefore allows for only 1 instance of Lamport > schemed-based economic transaction, which has to be the first transaction of > ADDR (because of publishing of ECCPUB). After this first transaction, ADDR is > stil valid, just no longer able to issue transactions. > > The proposed scheme, therefore, favors the good practice of non-address reuse. > > YSVB >
Thank you for the great explanation, Yuri! Let's make sure we are on the same page. I calculated the on-chain footprint of signatures of the proposed scheme and compared it with schnorr keys as are used in taproot. Lamport scheme, the case no ECC signature is published: - output: 20 bytes. ADDR = H(ECCPUB, LAMPPUB) - input 1: LSIG (14 bytes) - input 2: ECCPUB, LAMPPRI (32+14=46). (ECCPUB is needed to verify hashing to ADDR; LAMPPUB is not needed onchain, because it is a hash of LAMPPRI.) Total onchain footprint: 20+14+46=80 (bytes) Is this correct? Taproot: - output: 32 bytes (schnorr public key) - input: 64 bytes (schnorr signature) Total: 32+64 = 96 (bytes) Some additional space is needed in the lamport scheme case to address T0 from T1 and to have T1 in the first place. Tx overhead is around 10 bytes and say 6 bytes for the reference. It looks, the footprint will be the same. -- Best regards, Boris Nagaev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
