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
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
|
Return-Path: <bram@chia.net>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 9F8C4C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Jul 2022 02:47:57 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 736564184E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Jul 2022 02:47:57 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 736564184E
Authentication-Results: smtp4.osuosl.org;
dkim=pass (2048-bit key) header.d=chia.net header.i=@chia.net
header.a=rsa-sha256 header.s=google header.b=LhchIjKR
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id ljOXxmcVfbyd
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Jul 2022 02:47:56 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org DB9274181F
Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com
[IPv6:2607:f8b0:4864:20::1134])
by smtp4.osuosl.org (Postfix) with ESMTPS id DB9274181F
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 12 Jul 2022 02:47:55 +0000 (UTC)
Received: by mail-yw1-x1134.google.com with SMTP id
00721157ae682-31caffa4a45so67966617b3.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 11 Jul 2022 19:47:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chia.net; s=google;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=QkqBNjFHC5gjLBdMmqmaYCLlP92hsxqGwTQkPY0qVj0=;
b=LhchIjKRzSkwZ8MDwDPNcTfYUTvbB9juzFIEEoX6BRGloDJ0QnS4V+lJJGUpKWl9S3
fWRxUyyhBe76MqG8nKBr7BBrUL6NBcioy2l2Bki8JNlTw9py2BqtbX0FKReyCEQ5iwWV
ddbJ6dRljuewigZIkHGIg0nTFYLLKSGDGOyHGKkiK6KtWn1rMZDWYyh2lZlBW2hhLngZ
JMkoGRqCK6nxqX1i1bxWwCdOGwUFM2cxX5XRSItvEiuWGj0HYq42CoFgqnH/CJnKem8m
4iLMdVV8L7Gv8y6YtxLgmBoiwdJDeop1g2vSNtBlb5eqo53EqlQYD+1gY6m8H/DmAJK7
hrAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=QkqBNjFHC5gjLBdMmqmaYCLlP92hsxqGwTQkPY0qVj0=;
b=X3jqNbeqHykzK5Fg0I4PDI3lpeMWSWqZj1n0zEq+i5pG1Ngv/FMMwmIiRfl2rRVvga
XdGqENeR6s7yUp3J9qDmt284W95wKkyy50vgQi9awHT9piHRZD7cIIilFrADS4P1M3Ak
f6Trjx+pVqp2LbQLRTpjvKb7YCTjrCmkHTEakfsq7Pk2oSUR40+LiG6U9fi1mzBnUDdV
Tiz+UpuO8ZBTDyhALm9r+m+KlImaQxi6wC92cr2B/tAxsjNFw+M2fzjX1Wi77+OO3bxX
7AlYfA30+GM5g3S0R6VObgsLtsonChs+jl5uZeg7By2sZfe9FztP6zTeK7WCF5JSS4d3
TyQQ==
X-Gm-Message-State: AJIora95Zs4rPxeprVnjUJU6HOFTmiEkJ4K+wYmUpkazDMtfjs0cWqCx
QJYo4RVpTFZzNLjVylEOTZL/6/B32xQ7/3oGe1IXdA==
X-Google-Smtp-Source: AGRyM1tsusTFEVI2sBGbSAlNd7Kf3QENRchVpmuf+l6WS4iJMRUCuzOxDSaAQwd0+C56lCoOF90wM3mu0ajgIbn6U6w=
X-Received: by 2002:a81:9b02:0:b0:31c:9ae4:99ec with SMTP id
s2-20020a819b02000000b0031c9ae499ecmr22793786ywg.495.1657594074760; Mon, 11
Jul 2022 19:47:54 -0700 (PDT)
MIME-Version: 1.0
References: <CAHUJnBDYDbgr3C158o7c6_XXdG+kqJruFo=od_RmPFk_GS0udw@mail.gmail.com>
<Ysyb4T/36oXeAH+z@petertodd.org>
In-Reply-To: <Ysyb4T/36oXeAH+z@petertodd.org>
From: Bram Cohen <bram@chia.net>
Date: Mon, 11 Jul 2022 19:47:43 -0700
Message-ID: <CAHUJnBA+gb0AnGDRB9iA99R6=L0Y5DffB7aE2x+9dU9vyOoXmw@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="000000000000021ea305e392b212"
X-Mailman-Approved-At: Tue, 12 Jul 2022 09:49:17 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Security problems with relying on transaction
fees for security
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: Tue, 12 Jul 2022 02:47:57 -0000
--000000000000021ea305e392b212
Content-Type: text/plain; charset="UTF-8"
On Mon, Jul 11, 2022 at 2:53 PM Peter Todd <pete@petertodd.org> wrote:
>
> The only type of fee-smoothing scheme that is feasible is to smooth an
> entirely
> separate category of fees that are made mandatory. For example, you could
> achieve the economic impact of inflation by having a fixed value*time
> based fee
> that goes to timelocked anyone-can-spend outputs in the coinbase to push
> the
> fee forward to other miners.
>
I'm not sure what the implications would be of charging coins for moving
based on their value times how long since they last moved would be (I
*think* that's what you're suggesting). It isn't obviously bad, but feels
weird to me.
That said, a scheme which would work would be to have a fixed minimum fee
of satoshis/vbyte which is required to be repaid out by the miner into a
pool and they get back a fixed fraction of what was in that pool. The pool
could simply be a rolling coin which keeps the balance. That's still a bit
ugly but doesn't lessen block size significantly, is fairly coherent, and
is a soft fork. It's the best emergency measure I'm aware of.
--000000000000021ea305e392b212
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr">On Mon, Jul 11, 2022 at 2:53 PM Peter Tod=
d <<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>> wrot=
e:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex"><br>
The only type of fee-smoothing scheme that is feasible is to smooth an enti=
rely<br>
separate category of fees that are made mandatory. For example, you could<b=
r>
achieve the economic impact of inflation by having a fixed value*time based=
fee<br>
that goes to timelocked anyone-can-spend outputs in the coinbase to push th=
e<br>
fee forward to other miners.<br></blockquote><div><br></div><div>I'm no=
t sure what the implications would be of charging coins for moving based on=
their value times how long since they last moved would be (I *think* that&=
#39;s what you're suggesting). It isn't obviously bad, but feels we=
ird to me.</div><div><br></div><div>That said, a scheme which would work wo=
uld be to have a fixed minimum fee of satoshis/vbyte which is required to b=
e repaid out by the miner into a pool and they get back a fixed fraction of=
what was in that pool. The pool could simply be a rolling coin which keeps=
the balance. That's still a bit ugly but doesn't lessen block size=
significantly, is fairly coherent, and is a soft fork. It's the best e=
mergency measure I'm aware of.</div></div></div>
--000000000000021ea305e392b212--
|
