Date: Fri, 05 Jan 2024 18:02:39 +0000
To: "David A. Harding" <dave@dtrt.org>
From: yurisvb@pm.me
Message-ID: <gj0bWcRsGuhr7TuFHzCWI8NQD0YM6VN9rcWmx6WsF7vkoLNrjDm0gZ2iQCKs2HEk3iocOpwZzyxAO9iSjJuoEKa0GDKzu1042_UpeSEyVuQ=@pm.me>
In-Reply-To: <KyIvuW29IWRUV3nTo9qnb0H2x3a_3fViM9rC9MD0pBQg7Vrnb5-fdkMDIBZrvgRbRQeYIFrnSJjF-qWsaultktE83BYp9qAia27HSRw54kQ=@pm.me>
References: <nvbG12_Si7DVx9JbnnAvZbNdWk7hDQA23W1TXMkfYoU2iBA95Z1HzRnXgyiwFhDBmdi_rWL0dPllX1M9N9YZPDV47VgYADNd7CQA9CkAuX0=@pm.me>
 <6068d3536339704f3621894b2ba0daa8@dtrt.org>
 <KyIvuW29IWRUV3nTo9qnb0H2x3a_3fViM9rC9MD0pBQg7Vrnb5-fdkMDIBZrvgRbRQeYIFrnSJjF-qWsaultktE83BYp9qAia27HSRw54kQ=@pm.me>
Feedback-ID: 15605746:user:proton
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg=pgp-sha256;
 boundary="------fa44a534e0332c30c778cadcb6aa94d40aaf4fcdd66f214cc59853f3961046a6";
 charset=utf-8
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1
Precedence: list

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------fa44a534e0332c30c778cadcb6aa94d40aaf4fcdd66f214cc59853f3961046a6
Content-Type: multipart/mixed;boundary=---------------------5366da5ba2fcc47bca2180d9a14ea798

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

Dear friends and colleagues,

I believe this current version of the protocol and its documentation, now =
including a diagram answers the questions raised so far:

https://github.com/Yuri-SVB/LVBsig/blob/main/docs/white_paper.md

All in all, in addition to the plain transaction TXi, only 36 bytes are ne=
eded to authenticate it. The number falls to 16 in case of address (addres=
s chain) is reused, because change address coincides with Lamport-scheme p=
re-image.

YSVB.

Sent with Proton Mail secure email.

On Monday, January 1st, 2024 at 11:17 AM, yurisvb@pm.me <yurisvb@pm.me> wr=
ote:


> Hello, Dave,
> =


> I'm afraid I didn't understand your objection. It would be great to have=
 a direct, real-time conversation with you, if you have the availability. =
Be my guest to DM me for that.
> =


> Though this is to be confirmed, I suspect my proposed scheme can be impl=
emented with available, existing Bitcoin infrastructure. As far as my limi=
ted knowledge goes, the trickiest part would be to have miners agree that =
pre-image of hash of a transaction, in a subsequent block is acceptable au=
thentication. As for the commitment, it could be implemented as ordinary s=
mart contracts are, and its size doesn't matter because in the normal use =
case, it is not mined.
> =


> To be clear: The only component that is mined other than addresses and t=
he plaintext transactions would be one hash, between 16 and 20 bytes. From=
 the No-Free-Lunch Principle, the cost for it is that transaction takes a =
few blocks, instead of just one to be validated.
> =


> YSVB
> =


> Sent with Proton Mail secure email.
> =


> =


> On Sunday, December 31st, 2023 at 8:33 PM, David A. Harding dave@dtrt.or=
g wrote:
> =


> =


> =


> > Hi Yuri,
> > =


> > I think it's worth noting that for transactions with an equal number o=
f
> > P2TR keypath spends (inputs) and P2TR outputs, the amount of space use=
d
> > in a transaction by the serialization of the signature itself (16 vbyt=
es
> > per input) ranges from a bit over 14% of transaction size (1-input,
> > 1-output) to a bit less than 16% (10,000-in, 10,000-out; a ~1 MvB tx).
> > I infer that to mean that the absolute best a signature replacement
> > scheme can do is free up 16% of block space.
> > =


> > An extra 16% of block space is significant, but the advantage of that
> > savings needs to be compared to the challenge of creating a highly pee=
r
> > reviewed implementation of the new signature scheme and then convincin=
g
> > a very large number of Bitcoin users to accept it. A soft fork proposa=
l
> > that introduces new-to-Bitcoin cryptography (such as a different hash
> > function) will likely need to be studied for a prolonged period by man=
y
> > experts before Bitcoin users become confident enough in it to trust
> > their bitcoins to it. A hard fork proposal has the same challenges as =
a
> > soft fork, plus likely a large delay before it can go into effect, and
> > it also needs to be weighed against the much easier process it would b=
e
> > for experts and users to review a hard fork that increased block
> > capacity by 16% directly.
> > =


> > I haven't fully studied your proposal (as I understand you're working =
on
> > an improved version), but I wanted to put my gut feeling about it into
> > words to offer feedback (hopefully of the constructive kind): I think
> > the savings in block space might not be worth the cost in expert revie=
w
> > and user consensus building.
> > =


> > That said, I love innovative ideas about Bitcoin and this is one I wil=
l
> > remember. If you continue working on it, I very much look forward to
> > seeing what you come up with. If you don't continue working on it, I
> > believe you're likely to think of something else that will be just as
> > exciting, if not more so.
> > =


> > Thanks for innovating!,
> > =


> > -Dave
-----------------------5366da5ba2fcc47bca2180d9a14ea798
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==
-----------------------5366da5ba2fcc47bca2180d9a14ea798--

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

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

wsBzBAEBCAAnBYJlmEQeCZAv3zV8S8NMVRYhBFNfRF3t6Z4/pmFJQy/fNXxL
w0xVAACaLgf+PEpFYArSZVd7Fp4s6TClZv7pCibMBw+h1+fTBH8BNrLko2XR
yWN2yq0uf3V/AFPWz183eUHHxNXzNevtS7wGlpys78nZqMte8gfRo2Pje4eC
XIz+zvVIZFoU+Vgs8sTleoF/a3w4z1qlyOHdkuJSb3fnn9aqxdebHXvmoXBJ
XRH045TQ0rlr4YVjkJN5nMbUc92ixTqTQqCnMCp8ebx6V6YSw6mEkYSIANDl
Hfzlb+MoQzSD5PIGriBlD6C9Jih/7xoFvoXi5u0vRSHsWbIziCP7UJJZlWWJ
dPMjMhF/S6f5SPxe7Z+oUj9hBrlahN/7sSifp6vJpaB43rCGSK8XZA==
=DTGv
-----END PGP SIGNATURE-----


--------fa44a534e0332c30c778cadcb6aa94d40aaf4fcdd66f214cc59853f3961046a6--