public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "David A. Harding" <dave@dtrt•org>
To: yurisvb@pm•me,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1
Date: Sun, 31 Dec 2023 09:33:24 -1000	[thread overview]
Message-ID: <6068d3536339704f3621894b2ba0daa8@dtrt.org> (raw)
In-Reply-To: <nvbG12_Si7DVx9JbnnAvZbNdWk7hDQA23W1TXMkfYoU2iBA95Z1HzRnXgyiwFhDBmdi_rWL0dPllX1M9N9YZPDV47VgYADNd7CQA9CkAuX0=@pm.me>

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


  parent reply	other threads:[~2023-12-31 19:33 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
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 [this message]
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=6068d3536339704f3621894b2ba0daa8@dtrt.org \
    --to=dave@dtrt$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=yurisvb@pm$(echo .)me \
    /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