Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1

["David A. Harding" <dave@dtrt.org>]

On 2024-01-01 00:17, yurisvb@pm.me wrote:
> I'm afraid I didn't understand your objection. [...]
> I suspect my proposed scheme can be
> implemented with available, existing Bitcoin infrastructure.

Is a soft fork or a hard fork required?  If so, the proposal will need a 
lot of peer review and user acceptance.

What are the benefits of your proposal?  As I understand it, the benefit 
is smaller transactions.  How much smaller will they be in terms of 
vbytes?  For example, a transaction today with one input performing a 
taproot keypath spend and one taproot-paying output is 111 vbytes[1].  
What will be the total onchain size of an equivalent one-input, 
one-output transaction using your scheme?

My comment (not objection) is that modest decreases in onchain data size 
may not provide a significant enough benefit to attract reviewers and 
interested users, especially if a proposal is complicated by a 
dependencies on many things that have not previously been included in 
Bitcoin (such as new hash functions).

If I'm deeply misunderstanding your proposal and my questions don't make 
sense, I'd very much appreciate a clarification about what your proposal 
does.

Thanks,

-Dave

[1] https://bitcoinops.org/en/tools/calc-size/