From: yurisvb@pm•me
To: Nagaev Boris <bnagaev@gmail•com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Lamport scheme (not signature) to economize on L1
Date: Tue, 19 Dec 2023 14:07:23 +0000 [thread overview]
Message-ID: <ue8nChOuMtyW_JM-WxikLpWUSn9I99UHI5ukFVfLOEmQtCo4noetzyVKercbrwjr_EqNotDsR1QZ0oijMu11TO2jpEjlJF71OjLlNoZ-00Y=@pm.me> (raw)
In-Reply-To: <CAFC_Vt644Wqn7EcvoZwFscPMov8T5kO9ss_QRgNgVNir-bBA0Q@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3907 bytes --]
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
Sent with Proton Mail secure email.
On Tuesday, December 19th, 2023 at 1:45 AM, Nagaev Boris <bnagaev@gmail•com> wrote:
> On Mon, Dec 18, 2023 at 7:44 PM yurisvb@pm•me wrote:
>
> > I beg to disagree: key owner broadcasts first bundle (let's call it this way) so that it is on any miner's best interest to include said bundle on their's attempted coinbase because they know if they don't any other competing miner will in the next block.
>
>
> What if an attacker broadcasts the first bundle? He spent a lot of
> time cracking the hash which is the part of the address in the
> proposed scheme. Then he cracked the second layer of hashing to have
> both hashes ready. If the utxo has enough sats, the attack is
> economically viable.
>
>
> --
> Best regards,
> Boris Nagaev
[-- Attachment #1.2: publickey - yurisvb@pm.me - 0x535F445D.asc --]
[-- Type: application/pgp-keys, Size: 1678 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 509 bytes --]
next prev parent reply other threads:[~2023-12-19 14:07 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-18 1:37 yurisvb
2023-12-18 12:29 ` Sergio Demian Lerner
2023-12-18 16:45 ` Nagaev Boris
[not found] ` <-lH1AcjRwuxfuqLPFOh_oga10Qm12fb7Se9imDeS5ft6CU3y8KTQa3tBP0twJJBFSHgj7FC8EIxvEser3oZdWvkeitRwERQl_cCdgAWtbTU=@pm.me>
[not found] ` <CAFC_Vt7B1oV0_uAwKe3NQLWE2jdQ_MF1W4fnVqkf8s=YHyfVyQ@mail.gmail.com>
2023-12-18 22:43 ` yurisvb
2023-12-19 0:45 ` Nagaev Boris
2023-12-19 14:07 ` yurisvb [this message]
2023-12-19 17:08 ` Nagaev Boris
2023-12-19 21:22 ` yurisvb
2023-12-20 21:33 ` Nagaev Boris
2023-12-21 16:07 ` yurisvb
2023-12-22 4:52 ` G. Andrew Stone
2023-12-22 15:32 ` yurisvb
2023-12-23 0:26 ` yurisvb
2023-12-29 0:30 ` yurisvb
2023-12-31 17:42 ` yurisvb
2023-12-31 19:33 ` David A. Harding
2024-01-01 10:17 ` yurisvb
2024-01-01 18:57 ` David A. Harding
2024-01-05 18:02 ` yurisvb
2024-01-05 18:22 ` yurisvb
[not found] <nvbG12=5FSi7DVx9JbnnAvZbNdWk7hDQA23W1TXMkfYoU2iBA95Z1HzRnXgyiwFhDBmdi=5FrWL0dPllX1M9N9YZPDV47VgYADNd7CQA9CkAuX0=3D@pm.me>
[not found] ` <ue8nChOuMtyW=5FJM-WxikLpWUSn9I99UHI5ukFVfLOEmQtCo4noetzyVKercbrwjr=5FEqNotDsR1QZ0oijMu11TO2jpEjlJF71OjLlNoZ-00Y=3D@pm.me>
[not found] ` <CAFC=5FVt5PcqqcREJ67Jzcg=3DK+Agd02a9f5uSit8LwkYHshbvF7A@mail.gmail.com>
[not found] ` <HG9-9VDKRd3-0v0x9QP05=5FCjyk9Y3UW-94A1RHsT3xMQYmb7Y6sk9-wTUlqVZzm6ACigM7aM-B6NB-z6jVCCXhQIGEYkEcBKryzP587FlIo=3D@pm.me>
[not found] ` <CAFC=5FVt6vqZkeenfrsqSj4T3+4+L2KMam0o0FeWJ4VzBEWE=3DHfA@mail.gmail.com>
[not found] ` <I11FZ=5FZpfwpnQBh5hbBZMHsQt=5FcKwF9My49X4-MMRIYvaJEoIwta-GEaDNN1EtQxST4gQFAvqfOZElDvIpPrlAVknyN52IMnJKNy5kT8sUE=3D@pm.me>
[not found] ` <CAHUwRvuyhQDN5RF0ysMAJgWS2V7vv-3yHzKcLspk=5FHzQY=3Dtt2Q@mail.gmail.com>
[not found] ` <jGJvlLv4UL13U6aklzwkyRE4XRQtQSK-JZzpevPzyWQhQ4rU84I5fPDSdbtW7ehFzxkLtaOEenMMQAbHslH766qj9DGfb7QlwwXqjGsNRvU=3D@pm.me>
[not found] ` <nMFSEupHxGqdH2Z4kSNj-kufM4X=5F=5FUexnJOqC99-KlfT84adaDfPLm66vS6V8Ogphiogz1dvzFEVjM7QO=5Ft9PVR3VqNxZCIvD4C=5FSEtkDfc=3D@pm.me>
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='ue8nChOuMtyW_JM-WxikLpWUSn9I99UHI5ukFVfLOEmQtCo4noetzyVKercbrwjr_EqNotDsR1QZ0oijMu11TO2jpEjlJF71OjLlNoZ-00Y=@pm.me' \
--to=yurisvb@pm$(echo .)me \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=bnagaev@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox