1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
|
Return-Path: <dave@dtrt.org>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 59382C0037
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Jan 2024 18:57:18 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 3AAE540192
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Jan 2024 18:57:18 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 3AAE540192
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id D72dEoUtGtvj
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Jan 2024 18:57:17 +0000 (UTC)
Received: from smtpauth.rollernet.us (smtpauth.rollernet.us
[IPv6:2607:fe70:0:3::d])
by smtp2.osuosl.org (Postfix) with ESMTPS id 20E514011B
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 1 Jan 2024 18:57:16 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 20E514011B
Received: from smtpauth.rollernet.us (localhost [127.0.0.1])
by smtpauth.rollernet.us (Postfix) with ESMTP id 766C82800862;
Mon, 1 Jan 2024 10:57:14 -0800 (PST)
Received: from webmail.rollernet.us (webmail.rollernet.us
[IPv6:2607:fe70:0:14::a])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
(Client did not present a certificate)
by smtpauth.rollernet.us (Postfix) with ESMTPSA;
Mon, 1 Jan 2024 10:57:13 -0800 (PST)
MIME-Version: 1.0
Date: Mon, 01 Jan 2024 08:57:13 -1000
From: "David A. Harding" <dave@dtrt.org>
To: yurisvb@pm.me
In-Reply-To: <KyIvuW29IWRUV3nTo9qnb0H2x3a_3fViM9rC9MD0pBQg7Vrnb5-fdkMDIBZrvgRbRQeYIFrnSJjF-qWsaultktE83BYp9qAia27HSRw54kQ=@pm.me>
References: <nvbG12_Si7DVx9JbnnAvZbNdWk7hDQA23W1TXMkfYoU2iBA95Z1HzRnXgyiwFhDBmdi_rWL0dPllX1M9N9YZPDV47VgYADNd7CQA9CkAuX0=@pm.me>
<6068d3536339704f3621894b2ba0daa8@dtrt.org>
<KyIvuW29IWRUV3nTo9qnb0H2x3a_3fViM9rC9MD0pBQg7Vrnb5-fdkMDIBZrvgRbRQeYIFrnSJjF-qWsaultktE83BYp9qAia27HSRw54kQ=@pm.me>
User-Agent: Roundcube Webmail/1.4.15
Message-ID: <7d364adaed1457855a40522f73f3adfe@dtrt.org>
X-Sender: dave@dtrt.org
Content-Type: text/plain; charset=US-ASCII;
format=flowed
Content-Transfer-Encoding: 7bit
X-Rollernet-Abuse: Contact abuse@rollernet.us to report. Abuse policy:
http://www.rollernet.us/policy
X-Rollernet-Submit: Submit ID 3e6a.65930b09.3ad99.0
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Lamport scheme (not signature) to economize on L1
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jan 2024 18:57:18 -0000
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/
|
