Date: Mon, 01 Jan 2024 10:17:07 +0000
To: "David A. Harding" <dave@dtrt.org>
From: yurisvb@pm.me
Message-ID: <KyIvuW29IWRUV3nTo9qnb0H2x3a_3fViM9rC9MD0pBQg7Vrnb5-fdkMDIBZrvgRbRQeYIFrnSJjF-qWsaultktE83BYp9qAia27HSRw54kQ=@pm.me>
In-Reply-To: <6068d3536339704f3621894b2ba0daa8@dtrt.org>
References: <nvbG12_Si7DVx9JbnnAvZbNdWk7hDQA23W1TXMkfYoU2iBA95Z1HzRnXgyiwFhDBmdi_rWL0dPllX1M9N9YZPDV47VgYADNd7CQA9CkAuX0=@pm.me>
 <6068d3536339704f3621894b2ba0daa8@dtrt.org>
Feedback-ID: 15605746:user:proton
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg=pgp-sha256;
 boundary="------f3d30ed6af78a8a9a0fe9944d76a8fcd9027746ae17873501dbdb18e30731fae";
 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)
--------f3d30ed6af78a8a9a0fe9944d76a8fcd9027746ae17873501dbdb18e30731fae
Content-Type: multipart/mixed;boundary=---------------------c270617593235257f1b8965cbffd9c49

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

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 implem=
ented with available, existing Bitcoin infrastructure. As far as my limite=
d knowledge goes, the trickiest part would be to have miners agree that pr=
e-image of hash of a transaction, in a subsequent block is acceptable auth=
entication. As for the commitment, it could be implemented as ordinary sma=
rt contracts are, and its size doesn't matter because in the normal use ca=
se, 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. From t=
he No-Free-Lunch Principle, the cost for it is that transaction takes a fe=
w 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 used
> in a transaction by the serialization of the signature itself (16 vbytes
> 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 peer
> reviewed implementation of the new signature scheme and then convincing
> a very large number of Bitcoin users to accept it. A soft fork proposal
> that introduces new-to-Bitcoin cryptography (such as a different hash
> function) will likely need to be studied for a prolonged period by many
> 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 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 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 review
> and user consensus building.
> =


> That said, I love innovative ideas about Bitcoin and this is one I will
> 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
-----------------------c270617593235257f1b8965cbffd9c49
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==
-----------------------c270617593235257f1b8965cbffd9c49--

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

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

wsBzBAEBCAAnBYJlkpEUCZAv3zV8S8NMVRYhBFNfRF3t6Z4/pmFJQy/fNXxL
w0xVAAB3bQgAsaeCFukuJnEos77Y9y/tysCnZe5Lzreqhu/cQJySpzGJ/LGL
qM5t03nUTfWCcSKa9D9s7hnAlBxK3IIK8nSia5Dhxy0fe6xOFxvl4D+VANyO
JmsxSmEFePWkkfUqEZ70mL+Yq7M/+M2r1ZmDUAk+/irlQNAfJaQOf+Y2q1gr
vqU18wbvbUjWGdIi9e8ZZEc0e0M+2jdPBb/QJGozonPQr0RoCvKNHYpQmhjH
vARbjGlRYXJflN1c8zAvnrXktXq5yuaFhL/CAuaLVzPVjKLyRPcgfCpnlAbp
snvwhrSHROeYapPMqVe4Usry+W5uvNsGsPcNV4C7ijivNxZ39HOVdw==
=+wV6
-----END PGP SIGNATURE-----


--------f3d30ed6af78a8a9a0fe9944d76a8fcd9027746ae17873501dbdb18e30731fae--