summaryrefslogtreecommitdiff
path: root/e1/e835f2c302a6c4d9bfa26bc6826c0e662decaf
blob: d69e008f76ba3388a2810d789786b02fd8e41d1d (plain)
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
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 3BFEFC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  6 Jul 2022 11:10:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 07D0B833C6
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  6 Jul 2022 11:10:38 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 07D0B833C6
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl
 header.a=rsa-sha256 header.s=2013 header.b=JtZa3t+y
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.699
X-Spam-Level: 
X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5
 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 2aJUj_p-0MwM
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  6 Jul 2022 11:10:36 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 378E4831F8
Received: from smtpo92.poczta.onet.pl (smtpo92.poczta.onet.pl
 [213.180.149.145])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 378E4831F8
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Wed,  6 Jul 2022 11:10:35 +0000 (UTC)
Received: from pmq8v.m5r2.onet (pmq8v.m5r2.onet [10.174.35.145])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4LdGzm22V1zlg9hF;
 Wed,  6 Jul 2022 13:10:28 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1657105828; bh=OAjukh4IObVJ7OMnZMNugb93yFjNLLSbZk1k/G+mV7I=;
 h=From:To:In-Reply-To:Date:Subject:From;
 b=JtZa3t+yyhremz0xIsqKGN27JNiZfdp4jpjdweV8DEdQ3jC2oCrlTHxYqPF11P5h6
 NzrsnlUwvZB40Vs2LY8Xaipdg8qjWITJpw+HDhvQOjrGR+qzCAAcB0phZ9kUWlF2ZU
 OSj3jRIUqlHstqJPUjlpglJ0X77W2pvyjpv6T4U4=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [82.177.167.2] by pmq8v.m5r2.onet via HTTP id ;
 Wed, 06 Jul 2022 13:10:28 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
To: "Corey Haddad <corey3@gmail.com>,
 Bitcoin Protocol Discussion" <bitcoin-dev@lists.linuxfoundation.org>,
 Giuseppe B <beppeben2030@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAK_HAC97sfvtkfs=yTt8Z0pi5ZF91n7OcZbu7k4XhdnMJ_PYnA@mail.gmail.com>
Date: Wed, 06 Jul 2022 13:10:27 +0200
Message-Id: <139633828-26b5fcbad80d1ca7046479237716ace3@pmq8v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;82.177.167.2;PL;2
X-Mailman-Approved-At: Wed, 06 Jul 2022 11:12:56 +0000
Subject: Re: [bitcoin-dev] Bitcoin covenants are inevitable
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: Wed, 06 Jul 2022 11:10:38 -0000

> If the only realistic (fair, efficient & proportionate) way to pay for Bi=
tcoin's security was by having some inflation scheme that violated the 21 m=
illion cap, then agreeing to break the limit would probably be what makes s=
ense, and in the economic interest of its users and holders.

So, Paul Sztorc was right again, there are three options: Enormous Block Si=
ze Increases, Violate 21M Coin Limit, or >50% Miner Fee-Revenues Come From =
Merged Mining: https://www.truthcoin.info/images/sb-trilemma.png. And I thi=
nk using Merged Mining is the best option. More about that: https://www.tru=
thcoin.info/blog/security-budget-ii-mm/

> Another option, if we were to decide we are over-secured in the short ter=
m, would be to soft-fork in a reduction in the current and near-future mini=
ng rewards, by somehow locking the coins in a contract that deprived the mi=
ner of the full reward, and then using that contract to pay the rewards out=
 far in the future, should at some point we feel the security budget was in=
sufficient.

Yes, that's also possible, RSK uses that. And making some kind of soft-fork=
 for that is also possible, but I don't know if miners will agree to send s=
ome coinbase reward to "<futureBlockNumber> OP_CHECKLOCKTIMEVERIFY OP_DROP =
OP_TRUE".

On 2022-07-06 06:29:18 user Corey Haddad via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
>Bitcoin's finite supply is the main argument for people investing in it, t=
he whole narrative around bitcoin is based on its finite supply. While it h=
as its flaws and basically condemns bitcoin to be only used as a store >of =
value (and not as a currency), I don't think it's worth questioning it at t=
his point.=C2=A0
>
>Just my 2 sats.=C2=A0
>
>Giuseppe.=C2=A0


A finite=C2=A0supply alone is not enough to give something value, as it mus=
t also be useful in some way. In the case of Bitcoin, various=C2=A0forms of=
 cryptographic=C2=A0security=C2=A0must all work - and work together - to ma=
ke Bitcoin useful. If the only realistic (fair, efficient & proportionate) =
way to pay for Bitcoin's security=C2=A0was by having some inflation scheme=
=C2=A0that violated the 21 million cap, then agreeing to break the limit wo=
uld probably be what makes sense, and in the economic interest of its users=
 and holders.

There will always be competitive=C2=A0pressures with respect to efficiency,=
 and both being over-secured and under-secured would be economically ineffi=
cient for a crypto currency, and thereby laving room for a more optimally-s=
ecured competitor to gain ground. Currently there is zero feedback in the B=
itcoin system between what we might think is the optimum amount of security=
 and what actually exists. There is also zero agreement on how much securit=
y would constitute such an optimum. Figuring out how much security is neede=
d, or even better, figuring out a way to have a market mechanism to answer =
that question, will be an important project.

Another option, if we were to decide we are over-secured in the short term,=
 would be to soft-fork in a reduction in the current and near-future mining=
 rewards, by somehow locking the coins in a contract that deprived the mine=
r of the full reward, and then using that contract to pay the rewards out f=
ar in the future, should at some point we feel the security budget was insu=
fficient. Anthony Towns presented a form of this concept in greater detail =
at a Scaling Bitcoin conference some years ago. While this solution, if emp=
loyed, would only work for some finite amount of time, it is possible that =
could give additional decades before the accumulated security budget was ex=
hausted.=C2=A0


Corey