Date: Tue, 19 Dec 2023 14:07:23 +0000
To: Nagaev Boris <bnagaev@gmail.com>
From: yurisvb@pm.me
Message-ID: <ue8nChOuMtyW_JM-WxikLpWUSn9I99UHI5ukFVfLOEmQtCo4noetzyVKercbrwjr_EqNotDsR1QZ0oijMu11TO2jpEjlJF71OjLlNoZ-00Y=@pm.me>
In-Reply-To: <CAFC_Vt644Wqn7EcvoZwFscPMov8T5kO9ss_QRgNgVNir-bBA0Q@mail.gmail.com>
References: <nvbG12_Si7DVx9JbnnAvZbNdWk7hDQA23W1TXMkfYoU2iBA95Z1HzRnXgyiwFhDBmdi_rWL0dPllX1M9N9YZPDV47VgYADNd7CQA9CkAuX0=@pm.me>
 <CAFC_Vt5xqhuXjNVeSGE2Pn=0N0MuB6pOnREzGhSQSpk+hTUUSg@mail.gmail.com>
 <-lH1AcjRwuxfuqLPFOh_oga10Qm12fb7Se9imDeS5ft6CU3y8KTQa3tBP0twJJBFSHgj7FC8EIxvEser3oZdWvkeitRwERQl_cCdgAWtbTU=@pm.me>
 <CAFC_Vt7B1oV0_uAwKe3NQLWE2jdQ_MF1W4fnVqkf8s=YHyfVyQ@mail.gmail.com>
 <1aHuuO-k0Qo7Bt2-Hu5qPFHXi4RgRASpf9hWshaypHtdN-N9jkubcvmf-aUcFEA6-7L9FNXoilIyydCs41eK4v67GVflEd9WIuEF9t5rE8w=@pm.me>
 <CAFC_Vt644Wqn7EcvoZwFscPMov8T5kO9ss_QRgNgVNir-bBA0Q@mail.gmail.com>
Feedback-ID: 15605746:user:proton
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg=pgp-sha256;
 boundary="------8f83ec5b0c973380aa347970be5392721e7cb5e81d2e0afeffc6547f0ea2fcee";
 charset=utf-8
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Lamport scheme (not signature) to economize on L1
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------8f83ec5b0c973380aa347970be5392721e7cb5e81d2e0afeffc6547f0ea2fcee
Content-Type: multipart/mixed;boundary=---------------------246520715a22a95f02f6bba9f68828c4

-----------------------246520715a22a95f02f6bba9f68828c4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

Thank you for the question, Boris. That was an easy one:

Short answer is Lamport hashes are protected by long hash of key fingerpri=
nt an ECC (Schnorr or otherwise conventional) public-key, which is not pub=
lished until first transaction. For clarity:

HL(.) =3D serial-work- and memory-*hard* hash with *short* digest (ex.: Ar=
gon2 with ~ 12 bytes output. "L" for "Lamport");
HC(.) =3D nonspecific representation of conventional, serial-work- and mem=
ory-*easy* hashes with *long* (brute-force-resistant) digest length. "C" f=
or "Conventional";
KDF(.) =3D conventional key deriving function
ECCPUB =3D public key correspondent to ECCPRI
ECCPRI =3D KDF(seed, tag) //conventional BTC signing key (could be Schnorr=
 instead)
LAMPPUB =3D HL(LAMPPRIi)
LAMPPRI =3D 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) =3D ECCPUB, so ultimately, cracking=
 seed is still as hard as cracking a conventional seed.
ADDR =3D H(ECCPUB, LAMPPUB) //Conventional BTC key fingerprinting with con=
ventionally used hashes and their respective brute-force-resistant digest =
lengths
TX =3D plaintext transaction
LSIG =3D HL(TX, LAMPPRI)
COMMITMENT =3D Smart contract stating "This UTXO is frozen until one of th=
e following happens: A) publishing of a L such that HL(TX,L) =3D LSIG befo=
re 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 =3D "Bundle of Lamport scheme" =3D (TX, LSIG)
BC =3D "Bundle of Commitment and Conventional Signing" =3D (COMMITMENT, EC=
CPRI(COMMITMENT), ECCPUB, LAMPPUB)	//LAMPPUB is added here to allow easy v=
erification that ECCPUB corresponds to ADDR
BT =3D "Total Bundle" =3D (BL, BC)
F1 =3D fee offered to mine BL
FF1 =3D fine offered to miner of BL to compensate for delay
FC =3D fee offered to mine BC in case of default
T0 =3D Block height of broadcasting of BT
T1 =3D Block height owner should aim at broadcasting LAMPPRI  block ~ T0+1=
 to T0+6 blocks. This is to protect owner from dissensus (revealing LAMPPR=
I in a block and have it utilized to forge transaction in a competing bloc=
k of same height).
T2 =3D Block height of expiration of commitment ~ T0+24 hours to T0+ a few=
 days to protect user from execution of commitment being triggered by inno=
cent unavailability.

From ADDR alone, Miners, cannot forge a valid LSIG, nor try to ascertain L=
AMPPUB 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 schem=
ed-based economic transaction, which has to be the first transaction of AD=
DR (because of publishing of ECCPUB). After this first transaction, ADDR i=
s stil valid, just no longer able to issue transactions.

The proposed scheme, therefore, favors the good practice of non-address re=
use.

YSVB

Sent with Proton Mail secure email.

On Tuesday, December 19th, 2023 at 1:45 AM, Nagaev Boris <bnagaev@gmail.co=
m> wrote:


> On Mon, Dec 18, 2023 at 7:44=E2=80=AFPM yurisvb@pm.me wrote:
> =


> > I beg to disagree: key owner broadcasts first bundle (let's call it th=
is 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 co=
mpeting 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
-----------------------246520715a22a95f02f6bba9f68828c4
Content-Type: application/pgp-keys; filename="publickey - yurisvb@pm.me - 0x535F445D.asc"; name="publickey - yurisvb@pm.me - 0x535F445D.asc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="publickey - yurisvb@pm.me - 0x535F445D.asc"; name="publickey - yurisvb@pm.me - 0x535F445D.asc"

LS0tLS1CRUdJTiBQR1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCgp4c0JOQkYySmpSWUJDQUM1MXlo
K0s0MmF0c0V5MGdCTmgvaklXR1hzQnRFLzdJOGFuUmZkZTcvcWdHeXkKbEx4TXFZRE1OelUwN3c5
Z3VINllKRDdWdzNaUmxTVGVqNU9Hc2laOFJ2OUp4YXBYc0MxeDMrdHhOQkFQClYyVml1MVpsMnhK
Y29sTDkrem9SUmhmU25lVDVaZm1IQlpBSklKbmhOdU80ajhrRi9iNDRFaEZ3NkwvTgpGbE9rK1VC
SkVvS0FFQWttd09aWWpVTDd6MStRdzJBZkJIVGVwNFMzYmY4SmZMNDFOUVJsRnBSa3MrSkMKTjNa
c0ozZmZhNURjWjVqTGgyK2k5Mlg2eE8yVW5nM0hLYXhJYTVtbzB3cGVvQ1JQdUxNRjE2cjVQelJ4
CjJmNldzZVlUbWVmZWVYUGUzZEhyTTR4ai9ndHpBRGNxaFd6VVZLM21ZNTdPTXhVYjJ4MWdqZ1Z6
QUJFQgpBQUhOSFhsMWNtbHpkbUpBY0cwdWJXVWdQSGwxY21semRtSkFjRzB1YldVK3dzQjFCQkFC
Q0FBZkJRSmQKaVkwV0Jnc0pCd2dEQWdRVkNBb0NBeFlDQVFJWkFRSWJBd0llQVFBS0NSQXYzelY4
UzhOTVZkTkRCLzlRCnZRRlpZNkRzR3FMOTlkKzI2QjdHYmRCb0VjenUxL2NqTVpNdE9QeW9nSElF
eXllalR3R1RVN3ZYNEpWZQozRHZnbnd4U2xIYjQ2dDU2VGV3OU5rZ2V4MmFIb0hGRnJBd3MraTVa
ajdZN2lhL2l2RVozZE1KR3dNSUoKeVlQS08rdG1ockxNYWlSSFdnUnhtSG5mRnhUY1dFQ1dSZEk3
dDRJWFp3Rm9QN2Z3TVVVVXQrV3NTbzJSCnJhUVZEL3NTL2F2TlF5T2h6YTlLcVBQNjBZY3B2RUtj
UXArL2hyTjRRcFhVSkxiaDFZMVlqeUhlbDhnQgpRa3p2QzUwUjVxTzRlY2xxSy9FMEhESnlDWmZN
TThkV2o0REJrTWN2SzlsYjB5b3ZRMDFFTXp1NkU1NEcKYjZ0VFp1bktQTVpVd1J1SW5FY0hHMjV0
azdWUEM4clJTU0hqeDhTT3pzQk5CRjJKalJZQkNBQ3RiUWdNCldRSnMvTVdZbDR2THRLSlhYbFlS
T2h1YkVWbjRjTFdZSmVFWHpzSllCQWRlNWh0QlEzc212UjJ2NnVJegptejJpaXFsSkVVdmYwY2xM
WS9QVExoSGVTbWE5VTRodzRaRDNZKzV6WWxINURza2l1N3lLZTdIVmpEVmkKd1FJN25acWRvanJs
dDhCZENiOVNMaXRNaFRvR1crS2E1VCtUOWNmbWthMk1qa3pRSFBNTEJtdVJ6a2V2ClBkZFF6M0xB
MjMzZDNHREVTZklCYy91OC9YelBUNkZTZ3MzSEh4OEFJbFdQbEJaYmh6WmpQNlRLclRNRQpOSEtK
cmxTRlZKclErL25QU28ya0VSL0VDczF0aUJEY0JkamVPYWx6LzdRVWN0Rnp3NGdjS0RtMGpUeEkK
cVhWVlV3a2tuRkM4NDZMTjNBT2p0UWRyOVV3czVsTzhkeXBGQUJFQkFBSEN3RjhFR0FFSUFBa0ZB
bDJKCmpSWUNHd3dBQ2drUUw5ODFmRXZEVEZXS2VBZ0FxRXN1QXJMZFprYXBvZDI3K2hpcHZZNUcr
eVRLQW1NMApIVlhmQzJiMVdtNXQwQXhOVXVkMlJ1OTE1MHA3V09CRXpXYkxnNXdzOTc1M296dlZi
cFpIQU9uVGZOeXoKUUR5QWhmZ1hNQjIvdzRERXEwT2tlQVBRNXhsQWtISDZpUW1hSkZiYy9FRjRX
ZWZWeE92MnNRNDlRNks5Ci9Bb1FROG54RVh1RzRidXVrclEwTGVlTVAzNEdMWUhYK2JvWENHQmxI
MGhiZm5kc3VQbEdqYnBnWVErdQplclJGTlB4N1JtSWtnQjJ0WmhwZkZ3VGtid1c2TVFmWDM5Z3F1
SitwVEVKUnA5UmpJVjFZU2txSjZJUkgKQkc4eFBocGgzT3huaWJyWkdlbGdtakpNM2QwM1k5OSs3
OXBvdTRlY09BeWYyTHMrMVVTY2NDTzA2YnI4CldlcjJ3cmI0WXc9PQo9aHJheAotLS0tLUVORCBQ
R1AgUFVCTElDIEtFWSBCTE9DSy0tLS0tCg==
-----------------------246520715a22a95f02f6bba9f68828c4--

--------8f83ec5b0c973380aa347970be5392721e7cb5e81d2e0afeffc6547f0ea2fcee
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wsBzBAEBCAAnBYJlgaN5CZAv3zV8S8NMVRYhBFNfRF3t6Z4/pmFJQy/fNXxL
w0xVAAB5JQgAhuxOItVigEDOJM9aWJrVtsjK9/eOOuQF8RQJ4YrDGluutaBG
Gqat4WSU+J2+SLF9qtIkbvd3sAedx2/4cplreGtCz8sAeVaix5GIiNH2nJ8L
V4G8JUNn1bhAxDy7xmCjICbkc5rI/RsKMty4HBLgOmOoO26XrhI9uIwvrmDn
ur0zwXGDMHRSy4/6hHHvtNdHFkZmmUSRv05GN7c9cG893r9hkgoIaryPDVne
y15wxte10hMUsw3hnTJ1S5yh/3qY/X+l6EoLXTKkL8IyndBrMZ9hJyrvAzEJ
fBgOhcyKMXczIlIor5jVFGVlfHHrU2VOYS8KvxkYktR2H7v1N/T7Wg==
=RqpP
-----END PGP SIGNATURE-----


--------8f83ec5b0c973380aa347970be5392721e7cb5e81d2e0afeffc6547f0ea2fcee--