path: root/6a/a61be55d5caf80a54d4c400c5055590d89d89c

Return-Path: <vjudeu@gazeta.pl>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id DD88BC002D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 Jul 2022 06:04:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id B7A0B60812
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 Jul 2022 06:04:10 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org B7A0B60812
Authentication-Results: smtp3.osuosl.org;
 dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl
 header.a=rsa-sha256 header.s=2013 header.b=hX2YDjeN
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, FREEMAIL_FROM=0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Fb1q-YCXdz1V
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 Jul 2022 06:04:09 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org A9FE960AC4
Received: from smtpo95.poczta.onet.pl (smtpo95.poczta.onet.pl
 [213.180.149.148])
 by smtp3.osuosl.org (Postfix) with ESMTPS id A9FE960AC4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 15 Jul 2022 06:04:08 +0000 (UTC)
Received: from pmq6v.m5r2.onet (pmq6v.m5r2.onet [10.174.33.77])
 by smtp.poczta.onet.pl (Onet) with ESMTP id 4Lkgm01Rbgzlg8r4;
 Fri, 15 Jul 2022 08:04:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
 t=1657865040; bh=j7Q7Waq9qEB6G/54kMOu8UnEmvkMLWDY4HIcD1lgmHw=;
 h=From:To:In-Reply-To:Date:Subject:From;
 b=hX2YDjeNSgfPNIos1vZQK6JHrF/NBoMAaHmD79d/gnbAGuRNXXZmi2Nrlkc3PT6cJ
 SV3cjJmg5hUfNyKTe6WsRL7Atj/aSDlu85wEmPcayf+g+kOFMJrzDAazO4o5SN/FlZ
 yT9+ChqFYhBMnoVgIDmq98cjo5qIb2AAnal28d94=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [82.177.167.2] by pmq6v.m5r2.onet via HTTP id ;
 Fri, 15 Jul 2022 08:04:00 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
To: "Manuel Costa <manecosta@gmail.com>,
 Bitcoin Protocol Discussion" <bitcoin-dev@lists.linuxfoundation.org>,
 Gino Pinuto <gino.pinuto@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <CAAxiurZ6qEtQv5q7uXJnZQvh1mDF_sfOVVsR-FXEctbmfkV9LQ@mail.gmail.com>
Date: Fri, 15 Jul 2022 08:03:57 +0200
Message-Id: <72259160-59237a0217670fbbafa7229697cbd60f@pmq6v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;82.177.167.2;PL;2
X-Mailman-Approved-At: Fri, 15 Jul 2022 08:23:23 +0000
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: Fri, 15 Jul 2022 06:04:11 -0000

> Unsure how this solves or relates to the smoothing of block rewards. Let =
me know if I misunderstood.

This example shows clearly that even if tail supply supporters will win, th=
en no matter how they will introduce new coins to the system, we can still =
resist that attack by burning those coins, or by locking them in some endle=
ss loop, to make it compatible with their malicious soft-fork (because I do=
n't think the community will agree on some hard-fork, when none is needed).

And when it comes to smoothing rewards, then if you decide, that for exampl=
e any miner can take only 0.01 BTC, and the rest should be timelocked to th=
e future blocks, then it will make block rewards more smooth. So, when it c=
omes to making fees more smooth, it is only a matter of choosing the right =
amount, that miners can agree to introduce (because reducing 6.25 BTC plus =
fees into 0.01 BTC now, and getting a promise that the block reward will ne=
ver go below 0.01 BTC, is not something they are likely to support, so diff=
erent amounts should be chosen).


On 2022-07-14 18:34:24 user Manuel Costa via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
> There is a smarter way. Just send 0.01 BTC per block to the timelocked ou=
tputs. Now, we have 6.25 BTC, so it means less than 0.2%. But that percenta=
ge will grow over time, as basic block reward will shrink, and we will have=
 mandatory 0.01 BTC endlessly moved, until it will wrap. And guess what: if=
 it will be 0.01 BTC per block, wrapped every 210,000 blocks, it simply mea=
ns you can lock 2,100 BTC in an endless circulation loop, and avoid this "t=
ail supply attack".

My understanding of this is that it would basically remove 0.01 BTC rewards=
 from the next 210k blocks, and then do nothing.
After 210k blocks have passed, you're just rolling it forward, taking from =
the anyone can spend output and locking it in a new one for 210k blocks fro=
m now.
You're basically just using the next 210k block's reward to create a stash =
of forever locked coins in a loop.
Unsure how this solves or relates to the smoothing of block rewards. Let me=
 know if I misunderstood.


Gino Pinuto via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> escreve=
u no dia quinta, 14/07/2022 =C3=A0(s) 13:18:
This is not an argument in line with bitcoin values, on that scenario only =
rich people will be able to mine and participate to the consensus process.
Like George Soros today, he use its financial reserves to monopolize ONG in=
 order to manipulate nation states. I would not define this a "tax", moreov=
er a cost to maintain control over the network.


Those rich holders could crate a cartel and without market dynamics all gam=
e theory stop to work and the bitcoin network value drop.


We should think about how to maximise the network value instead of trying t=
o preserve it with corruptible practices outside of market dynamics princip=
les.


On Thu, 14 Jul 2022, 12:53 Erik Aronesty via bitcoin-dev, <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
Fees and miner rewards are not needed at all for security at all since long=
 term holders can simply invest in mining to secure the value of their stak=
e.


Isn't it enough that the protocol has a mechanism to secure value?


Sure fees *might* be enough.=C2=A0=C2=A0


But in the event that they are not, large holders can burn a bit to make su=
re the hashrate stays high.


I know, I know it's a tax on the rich and it's not fair because smaller hol=
ders are less likely to do it, but it's a miniscule tax even in the worst c=
ase


















On Thu, Jul 14, 2022, 5:35 AM vjudeu via bitcoin-dev <bitcoin-dev@lists.lin=
uxfoundation.org> wrote:
> This specific approach would obviously not work as most of those outputs =
would be dust and the miner would need to waste an absurd amount of block s=
pace just to grab them, but maybe there's a smarter way to do it.

There is a smarter way. Just send 0.01 BTC per block to the timelocked outp=
uts. Now, we have 6.25 BTC, so it means less than 0.2%. But that percentage=
 will grow over time, as basic block reward will shrink, and we will have m=
andatory 0.01 BTC endlessly moved, until it will wrap. And guess what: if i=
t will be 0.01 BTC per block, wrapped every 210,000 blocks, it simply means=
 you can lock 2,100 BTC in an endless circulation loop, and avoid this "tai=
l supply attack".

So, fortunately, even if "tail supply attackers" will win, we will still ha=
ve a chance to counter-attack by burning those coins, or (even better) by l=
ocking them in an endless circulation loop, just to satisfy their malicious=
 soft-fork, whatever amount it will require. Because even if it will be man=
datory to timelock 0.01 BTC to the current block number plus 210,000, then =
it is still perfectly valid to move that amount endlessly, without taking i=
t, just to resist this "tail supply attack".


On 2022-07-13 20:01:39 user Manuel Costa via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org> wrote:
> What about burning all fees and keep a block reward that will smooth out =
while keeping the ~21M coins limit ?

This would be a hard fork afaict as it would go against the rules of the co=
inbase transaction following the usual halving schedule.

However, if instead we added a rule that fees have to be sent to an anyone =
can spend output with a timelock we might be able to achieve a similar thin=
g.

Highly inefficient example:

- Split blocks into 144 (about a day)
- A mined block takes all the fees and distributes them equally into 144 ne=
w outputs (anyone can spend) time locked=C2=A0to each of the 144 blocks of =
the next day.
- Next day, for each block, we'd have available an amount equivalent to the=
 previous day total fees / 144. So we deliver previous day's fees smoothed =
out.

Notes:
144 is arbitrary in the example.
This specific approach would obviously not work as=C2=A0most of those outpu=
ts would be dust and the miner would need to waste an absurd=C2=A0amount of=
 block space just to grab them, but maybe there's a smarter way to do it.




Gino Pinuto via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> escreve=
u no dia quarta, 13/07/2022 =C3=A0(s) 13:19:
What about burning all fees and keep a block reward that will smooth out wh=
ile keeping the ~21M coins limit ?


Benefits :
- Miners would still be incentivized to collect higher fees transaction wit=
h the indirect perspective to generate more reward in future.
- Revenues are equally distributed over time to all participants and we sol=
ve the overnight discrepancy.
- Increased velocity of money will reduce the immediate supply of bitcoin c=
ooling down the economy.
- Reduction of velocity will have an impact on miners only if it persevere =
in the long term but short term they will still perceive the buffered rewar=
d.


I don't have ideas yet on how to elegantly implement this.



On Wed, 13 Jul 2022, 12:08 John Tromp via bitcoin-dev, <bitcoin-dev@lists.l=
inuxfoundation.org> wrote:
> The emission curve lasts over 100 years because Bitcoin success state req=
uires it to be entrenched globally.

It effectively doesn't. The last 100 years from 2040-2140 only emits a
pittance of about 0.4 of all bitcoin.

What matters for proper distribution is the shape of the emission
curve. If you emit 99% in the first year and 1% in the next 100 years,
your emission "lasts" over 100 years, and you achieve a super low
supply inflation rate immediately after 1 year, but it's obviously a
terrible form of distribution.

This is easy to quantify as the expected time of emission which would
be 0.99 * 0.5yr + 0.01* 51yr =3D 2 years.
Bitcoin is not much better in that the expected time of emission of an
bitcoin satisfies x =3D 0.5*2yr + 0.5*(4+x) and thus equals 6 years.

Monero appears much better since its tail emission yields an infinite
expected time of emission, but if we avoid infinities by looking at
just the soft total emission [1], which is all that is emitted before
a 1% yearly inflation, then Monero is seen to actually be a lot worse
than Bitcoin, due to emitting over 40% in its first year and halving
the reward much faster. Ethereum is much worse still with its huge
premine and PoS coins like Algorand are scraping the bottom with their
expected emission time of 0.

There's only one coin whose expected (soft) emission time is larger
than bitcoin's, and it's about an order of magnitude larger, at 50
years.

[1] https://john-tromp.medium.com/a-case-for-using-soft-total-supply-1169a1=
88d153
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev