public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Nagaev Boris <bnagaev@gmail•com>
To: yurisvb@pm•me
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1
Date: Wed, 20 Dec 2023 18:33:56 -0300	[thread overview]
Message-ID: <CAFC_Vt6vqZkeenfrsqSj4T3+4+L2KMam0o0FeWJ4VzBEWE=HfA@mail.gmail.com> (raw)
In-Reply-To: <HG9-9VDKRd3-0v0x9QP05_Cjyk9Y3UW-94A1RHsT3xMQYmb7Y6sk9-wTUlqVZzm6ACigM7aM-B6NB-z6jVCCXhQIGEYkEcBKryzP587FlIo=@pm.me>

On Tue, Dec 19, 2023 at 6:22 PM <yurisvb@pm•me> wrote:
>
> Thank you for putting yourself through the working of carefully analyzing my proposition, Boris!
>
> 1) My demonstration concludes 12 bytes is still a very conservative figure for the hashes. I'm not sure where did you get the 14 bytes figure. This is 2*(14-12) = 4 bytes less.

I agree. It should have been 12.

> 2) Thank you for pointing out that ECCPUB is necessary. That's exactly right and I failed to realize that. To lessen the exposure, and the risk of miner of LSIG, it can be left to be broadcast together with LAMPPRI.
>
> 3) I avail to advocate for economizing down the fingerprint to just 128 bits for the weakest-link-principle, since 128 bits is a nearly ubiquitous standard, employed even by the majority of seeds. Not an argument against plain Schnorr, because Schnorr keys could use it too, but, compared with current implementations, we have that would be 20-16=4 bytes less.

I think that the digest size for hash should be 2x key size for
symmetric encryption. To find a collision (= break) for a hash
function with digest size 128 bits one needs to calculate ~ 2^64
hashes because of the birthday paradox.

> 4) [Again, argument against plain, because it cuts for both sides:] To economize even further, there is also the entropy-derivation cost trade-off of N times costlier derivation for log2(N) less bits. If applied to the Address, we could shave away another byte.
>
> 5) T0 is just the block height of burying of LSIG doesn't need to be buried. T2 can perfectly be hard-coded to always be the block equivalent of T0 + 48 hours (a reasonable spam to prevent innocent defaulting on commitment due to network unavailability). T1 is any value such as T0 < T1 < T2, (typically T1 <= T0+6) of user's choosing, to compromise between, on one hand, the convenience of unfreezing UTXO and having TX mining completed ASAP and, on the other, avoiding the risk of blockchain forking causing LAMPPRI to be accidentally leaked in the same block height as LSIG, which allows for signatures to be forged. So this is 16 bytes less.
>
> Miners would keep record of unconfirmed BL's, because of the reward of mining either possible outcome of it (successful transaction or execution of commitment). Everything is paid for.
>
> So, unless I'm forgetting something else, all other variables kept equal, we have 20 bytes lighter than Schnorr; and up to 25 bytes less the current implementation of Schnorr, if items 3 and 4 are implemented too. Already we have a reduction of between 21% and 26%, while, so far, nobody in the mailing list has disputed how 'outrageously' conservative the 12 bytes figure is.

26% reduction of block space utilization would be great, but the price
of relying on 12 bytes hashes (only need 2^48 hashes to find a
collision) is too much for that, IMHO.

Another consideration is about 12 byte hashes. Let's try to figure out
if they are resistant to rainbow table attack by a large organization.
Let's assume that the rainbow table has a chain length of 1024^3 (billion).
What storage size is needed? 2^96 * 12 / 1024^3 = 900 exabytes.
Both chain length and storage size seems prohibitively high for today,
but tomorrow the hash function can be optimized, memory can be
optimized, storage can become cheaper etc. And this attack may be
affordable for state level attackers.

> Any other objections?
>
> YSVB
>


-- 
Best regards,
Boris Nagaev


  reply	other threads:[~2023-12-20 21:34 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 [this message]
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
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='CAFC_Vt6vqZkeenfrsqSj4T3+4+L2KMam0o0FeWJ4VzBEWE=HfA@mail.gmail.com' \
    --to=bnagaev@gmail$(echo .)com \
    --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