Date: Fri, 05 Jan 2024 18:22:44 +0000
To: "David A. Harding" <dave@dtrt.org>
From: yurisvb@pm.me
Message-ID: <ek_yawNCaDmqpsW5IjJXdxR8w1UOnydBnT3XIi_WtIjPXdN7Ag_gdDV4bDQ66--rwPmdgtE_ZiU2ahS_tAaGJkDwt25Yd12o_OulAwOubDI=@pm.me>
In-Reply-To: <gj0bWcRsGuhr7TuFHzCWI8NQD0YM6VN9rcWmx6WsF7vkoLNrjDm0gZ2iQCKs2HEk3iocOpwZzyxAO9iSjJuoEKa0GDKzu1042_UpeSEyVuQ=@pm.me>
References: <nvbG12_Si7DVx9JbnnAvZbNdWk7hDQA23W1TXMkfYoU2iBA95Z1HzRnXgyiwFhDBmdi_rWL0dPllX1M9N9YZPDV47VgYADNd7CQA9CkAuX0=@pm.me>
 <6068d3536339704f3621894b2ba0daa8@dtrt.org>
 <KyIvuW29IWRUV3nTo9qnb0H2x3a_3fViM9rC9MD0pBQg7Vrnb5-fdkMDIBZrvgRbRQeYIFrnSJjF-qWsaultktE83BYp9qAia27HSRw54kQ=@pm.me>
 <gj0bWcRsGuhr7TuFHzCWI8NQD0YM6VN9rcWmx6WsF7vkoLNrjDm0gZ2iQCKs2HEk3iocOpwZzyxAO9iSjJuoEKa0GDKzu1042_UpeSEyVuQ=@pm.me>
Feedback-ID: 15605746:user:proton
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg=pgp-sha256;
 boundary="------296e4cfdec9cb403c7cd9e232e6e0a5523f13ae5fedc7595750d391a835a1464";
 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)
--------296e4cfdec9cb403c7cd9e232e6e0a5523f13ae5fedc7595750d391a835a1464
Content-Type: multipart/mixed;boundary=---------------------1855eddfd53d490a3145d166bf6b7975

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

Addendum:

Tomorrow I'll host a Twitter Spaces on this topic:
https://twitter.com/yurivillasboas/status/1743305920937963696
You are all welcome to join!

YSVB

Sent with Proton Mail secure email.

On Friday, January 5th, 2024 at 7:02 PM, yurisvb@pm.me <yurisvb@pm.me> wro=
te:


> Dear friends and colleagues,
> =


> I believe this current version of the protocol and its documentation, no=
w 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 =
needed to authenticate it. The number falls to 16 in case of address (addr=
ess chain) is reused, because change address coincides with Lamport-scheme=
 pre-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 ha=
ve 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 im=
plemented with available, existing Bitcoin infrastructure. As far as my li=
mited knowledge goes, the trickiest part would be to have miners agree tha=
t pre-image of hash of a transaction, in a subsequent block is acceptable =
authentication. As for the commitment, it could be implemented as ordinary=
 smart contracts are, and its size doesn't matter because in the normal us=
e case, it is not mined.
> > =


> > To be clear: The only component that is mined other than addresses and=
 the plaintext transactions would be one hash, between 16 and 20 bytes. Fr=
om 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.=
org wrote:
> > =


> > > Hi Yuri,
> > > =


> > > I think it's worth noting that for transactions with an equal number=
 of
> > > P2TR keypath spends (inputs) and P2TR outputs, the amount of space u=
sed
> > > in a transaction by the serialization of the signature itself (16 vb=
ytes
> > > 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 tha=
t
> > > savings needs to be compared to the challenge of creating a highly p=
eer
> > > reviewed implementation of the new signature scheme and then convinc=
ing
> > > a very large number of Bitcoin users to accept it. A soft fork propo=
sal
> > > that introduces new-to-Bitcoin cryptography (such as a different has=
h
> > > function) will likely need to be studied for a prolonged period by m=
any
> > > experts before Bitcoin users become confident enough in it to trust
> > > their bitcoins to it. A hard fork proposal has the same challenges a=
s a
> > > soft fork, plus likely a large delay before it can go into effect, a=
nd
> > > it also needs to be weighed against the much easier process it would=
 be
> > > 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 workin=
g on
> > > an improved version), but I wanted to put my gut feeling about it in=
to
> > > words to offer feedback (hopefully of the constructive kind): I thin=
k
> > > the savings in block space might not be worth the cost in expert rev=
iew
> > > and user consensus building.
> > > =


> > > That said, I love innovative ideas about Bitcoin and this is one I w=
ill
> > > 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 a=
s
> > > exciting, if not more so.
> > > =


> > > Thanks for innovating!,
> > > =


> > > -Dave
-----------------------1855eddfd53d490a3145d166bf6b7975
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==
-----------------------1855eddfd53d490a3145d166bf6b7975--

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

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

wsBzBAEBCAAnBYJlmEjUCZAv3zV8S8NMVRYhBFNfRF3t6Z4/pmFJQy/fNXxL
w0xVAACwyggAkfjLvx3zTQX4YYYTtiOvsLrll7bOkHWpNdksLChq6ZpT3jBR
pBqUUoBjv1ZkiU9qz9E9+/gx92UqpXIV1C3DCNcMaanGFdSMVdoqmuRnSsvl
KYMKr4tpIBAMqee5meyXTYxGXiDhc6JKhACIDOleG9IWuXEpsUg+PZAnX0TX
awwAlprryE3t+soK0TlIRzhd+azWRUL+EH6NwzqGf/UTPl/P5tjjtl3sFsQT
u+xZ9OIg/+C8g5nxSDlk+noJ2El9Ru1Q62QaCqnlik86bGzjj/bZ4I5oq4z7
oW+eov5pW+rWr/kypViqHs+S9zgBJ2AvVqk860C5+atL/FW0qH0qNQ==
=N1pn
-----END PGP SIGNATURE-----


--------296e4cfdec9cb403c7cd9e232e6e0a5523f13ae5fedc7595750d391a835a1464--