bitcoin-dev

Combined summary - Lamport scheme (not signature) to economize on L1

Combined summary - Lamport scheme (not signature) to economize on L1

Recent updates to Bitcoin protocols have resulted in transaction authentication requiring only 36 bytes and dropping to 16 bytes for address reuse due to the Lamport scheme.

A discussion on Twitter Spaces is scheduled to deliberate these changes.

Dave expresses skepticism about the benefits of reducing transaction sizes through new cryptographic elements, questioning whether such incremental savings warrant the potential risks and challenges in gaining community acceptance.

Another email suggests that while integrating a new scheme could fit within Bitcoin's existing framework, convincing miners and balancing the slowed validation process present significant hurdles, invoking the No-Free-Lunch Principle.

Research indicates signature serialization makes up 14-16% of a Bitcoin transaction size; thus, new signature schemes could reduce block space usage by a similar margin. However, practicality and costs of implementation via soft or hard fork are concerns.

A cryptographic protocol offering up to a 66% reduction in blockchain footprint has been developed, based on the difficulty of factorizing polynomials. This is documented on GitHub and is being prepared as a Bitcoin Improvement Proposal.

A correction was issued concerning the description of a function related to pre-image problems, now correctly mapping 'a valid LAMPPRI' to an address and signature format. Further details on entropy calculations are forthcoming.

The vulnerabilities of cryptographic schemes are under examination, with a focus on cryptanalysis and minimizing collision rates in hash functions. The possibility of a multi-use version of the scheme is considered to further decrease blockchain bloat.

Security concerns for a proposed change include implications for chain reorganizations and double-spending attacks, with fears it may increase the attack surface. Measures against rainbow-table attacks and nonces as salts are recommended, and reassessment of the adversarial model is promised.

Consensus emerges that hash functions should have digest sizes double their symmetric key size to prevent collision attacks. A 26% reduction in block space utilization is possible, but security may be compromised.

Further discussions involve optimizing 12-byte hashes instead of 14-byte ones for efficiency, broadcasting ECCPUB to mitigate LSIG miner risks, standardizing fingerprint to 128 bits, and considering Schnorr keys for maintaining security standards.

Comparing cryptographic schemes, Lamport leads to an 80-byte footprint versus Taproot's 96 bytes, with possible equal space requirements after additional Lamport space needs. Transaction timing simplification proposes fixing T2 at 48 hours after T0.

Lamport hashes use a lengthy hash of key fingerprints, with KDFs generating ECCPRI and ECCPUB derived from them, leading to Bitcoin addresses resistant to brute force. Transaction signing processes and mining fee structures are explained, focusing on the single-use economic model for Lamport transactions.

Security concerns include attackers broadcasting first bundles after cracking hashes and the need to break a second hashing layer. The weakest link principle illustrates system robustness, emphasizing the difficulty of breaking Lamport chains compared to double-spending attacks.

Schnorr signatures' compactness raises questions about their security effectiveness. Cryptographic protocol developments like MAVE signature scheme, MAVEPAY cryptocurrency, and FawkesCoin based on the Guy Fawkes Protocol are mentioned by R. M. Needham.

An enhancement for Layer 1 blockchain byte-efficiency combines the Lamport Scheme with a dual-key system, including a penalty payment system for unfulfilled commitments and suggesting Argon2 for potential 12-byte hashes, significantly reducing space from ECC signatures.

Discussion History

0
yurisvb at pm.meOriginal Post
December 18, 2023 01:37 UTC
1
December 18, 2023 12:29 UTC
2
December 18, 2023 16:45 UTC
3
December 18, 2023 22:43 UTC
4
December 19, 2023 00:45 UTC
5
December 19, 2023 14:07 UTC
6
December 19, 2023 17:08 UTC
7
December 19, 2023 21:22 UTC
8
December 20, 2023 21:33 UTC
9
December 21, 2023 16:07 UTC
10
December 22, 2023 04:52 UTC
11
December 22, 2023 15:32 UTC
12
December 23, 2023 00:26 UTC
13
December 29, 2023 00:30 UTC
14
December 31, 2023 17:42 UTC
15
December 31, 2023 19:33 UTC
16
January 1, 2024 10:17 UTC
17
January 1, 2024 18:57 UTC
18
January 5, 2024 18:02 UTC
19
January 5, 2024 18:22 UTC