Delivery-date: Fri, 02 Aug 2024 05:31:49 -0700
Sender: bitcoindev@googlegroups.com
Date: Fri, 2 Aug 2024 01:45:18 -0700 (PDT)
From: Garlo Nicon <garlonicon@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <cab2d0fd-e5f0-40e1-b648-3741e69822f5n@googlegroups.com>
In-Reply-To: <6512db18-bd15-462e-92fd-7549b5e885e7n@googlegroups.com>
References: <6512db18-bd15-462e-92fd-7549b5e885e7n@googlegroups.com>
Subject: [bitcoindev] Re: HODL Tax Proposal
MIME-Version: 1.0
Content-Type: multipart/mixed; 
	boundary="----=_Part_191046_1478998838.1722588318288"
Precedence: list
Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com

------=_Part_191046_1478998838.1722588318288
Content-Type: multipart/alternative; 
	boundary="----=_Part_191047_1023545908.1722588318288"

------=_Part_191047_1023545908.1722588318288
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Good luck implementing it in test networks first, for example testnet3.=20
Some people were complaining, that they cannot get enough coins, and there=
=20
is no other test chain, which is close to the mainnet, and has a lot of=20
history, and a lot of halvings. So, if you think seriously about it, then=
=20
you should start from testnet3. Other networks, including mainnet, have not=
=20
enough blocks, and have too big rewards for that.

> addresses that do not engage in any outgoing transactions for over 60 day=
s

Miners can easily attack your network by mining empty blocks. It is=20
profitable to block regular payments today, to get high demurrage fees=20
tomorrow. Also, it is possible to easily censor any transaction, just by=20
refusing to include it. Then, required demurrage fees will be higher, than=
=20
what was originally sent as fees, and all nodes will just throw it away,=20
while respecting your consensus. Which also means, that this proposal=20
enables "transaction expiration" in some implicit way: if a transaction is=
=20
not confirmed in N blocks, then everything is eaten by demurrage fees, so=
=20
the old transaction simply expires.

> action needs to be taken before Peter Todd's suggestion of tail emissions=
=20
get any serious momentum

Assuming that "tail supply" will ever be implemented, then guess what:=20
people will count each and every overprinted satoshi. Creating coins is=20
hard, burning them is easy. If people will inflate Bitcoin, then other=20
people will bring it back to the equilibrium, just by burning all=20
overprinted coins, and refusing to accept any overprinted satoshi. You will=
=20
see charts, and statistics, how many "tail supply coins" were mined in a=20
given block, and people will burn the same amount, if not more.

> A proposed rate is 0.1% of the address balance per inactivity period.

Ouch. This is way more than the current fees. Some people stopped using LN,=
=20
because of fees like that. If you have 1 BTC, and you have to pay 100k=20
satoshis, then you can compare it with on-chain fees, where you can get it=
=20
confirmed for 1k sats. Which means, that this "0.1% fees" will remove all=
=20
whales from your network, where "a whale" is "anyone with >=3D 0.01 BTC".=
=20
Good luck maintaining the chain without any whales, it will be just an=20
altcoin, similar to CPU-mined altcoins, where "miners=3Dusers" is the only=
=20
use-case.

Also note, that miners can simply send those demurrage fees back to the=20
users, just to get something. Then, they will have the choice: reject=20
user's transaction entirely (because of missing demurrage fees), or confirm=
=20
two transactions: one paying demurrage fees, and one sending them back to=
=20
the user. Congratulations, your rule just doubled the number of=20
transactions for no reason. Because only miners getting proper fees will=20
survive, everyone else will reject too many transactions, and end up with=
=20
nothing.

> The inactivity threshold and fee rate can be adjusted based on community=
=20
feedback and network conditions.

So, is it a local node policy, instead of being a consensus rule? Good,=20
then I can just edit my config file, put "demurragefee=3D0.00000000" and=20
"inactivity=3D999999999". Good to know, that a proposal like that, can be=
=20
turned off that simply.

czwartek, 1 sierpnia 2024 o 23:13:42 UTC+2 Richard Greaser napisa=C5=82(a):

> Hi everyone,=20
>
> It has become apparent to me that there is an issue where users of the=20
> network holding their coins, are not adding value to the network.=20
>
> As miners continue to get squeezed post halving, they would benefit=20
> tremendously from fees being taken from individuals refusing to move thei=
r=20
> coins, providing increased security to the network.=20
>
> I have written out a proposal more in depth and is attached below.=20
>

--=20
You received this message because you are subscribed to the Google Groups "=
Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/=
bitcoindev/cab2d0fd-e5f0-40e1-b648-3741e69822f5n%40googlegroups.com.

------=_Part_191047_1023545908.1722588318288
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Good luck implementing it in test networks first, for example testnet3. Som=
e people were complaining, that they cannot get enough coins, and there is =
no other test chain, which is close to the mainnet, and has a lot of histor=
y, and a lot of halvings. So, if you think seriously about it, then you sho=
uld start from testnet3. Other networks, including mainnet, have not enough=
 blocks, and have too big rewards for that.<br /><br />&gt; addresses that =
do not engage in any outgoing transactions for over 60 days<br /><br />Mine=
rs can easily attack your network by mining empty blocks. It is profitable =
to block regular payments today, to get high demurrage fees tomorrow. Also,=
 it is possible to easily censor any transaction, just by refusing to inclu=
de it. Then, required demurrage fees will be higher, than what was original=
ly sent as fees, and all nodes will just throw it away, while respecting yo=
ur consensus. Which also means, that this proposal enables "transaction exp=
iration" in some implicit way: if a transaction is not confirmed in N block=
s, then everything is eaten by demurrage fees, so the old transaction simpl=
y expires.<br /><br />&gt; action needs to be taken before Peter Todd's sug=
gestion of tail emissions get any serious momentum<br /><br />Assuming that=
 "tail supply" will ever be implemented, then guess what: people will count=
 each and every overprinted satoshi. Creating coins is hard, burning them i=
s easy. If people will inflate Bitcoin, then other people will bring it bac=
k to the equilibrium, just by burning all overprinted coins, and refusing t=
o accept any overprinted satoshi. You will see charts, and statistics, how =
many "tail supply coins" were mined in a given block, and people will burn =
the same amount, if not more.<br /><br />&gt; A proposed rate is 0.1% of th=
e address balance per inactivity period.<br /><br />Ouch. This is way more =
than the current fees. Some people stopped using LN, because of fees like t=
hat. If you have 1 BTC, and you have to pay 100k satoshis, then you can com=
pare it with on-chain fees, where you can get it confirmed for 1k sats. Whi=
ch means, that this "0.1% fees" will remove all whales from your network, w=
here "a whale" is "anyone with &gt;=3D 0.01 BTC". Good luck maintaining the=
 chain without any whales, it will be just an altcoin, similar to CPU-mined=
 altcoins, where "miners=3Dusers" is the only use-case.<br /><br />Also not=
e, that miners can simply send those demurrage fees back to the users, just=
 to get something. Then, they will have the choice: reject user's transacti=
on entirely (because of missing demurrage fees), or confirm two transaction=
s: one paying demurrage fees, and one sending them back to the user. Congra=
tulations, your rule just doubled the number of transactions for no reason.=
 Because only miners getting proper fees will survive, everyone else will r=
eject too many transactions, and end up with nothing.<br /><br />&gt; The i=
nactivity threshold and fee rate can be adjusted based on community feedbac=
k and network conditions.<br /><br />So, is it a local node policy, instead=
 of being a consensus rule? Good, then I can just edit my config file, put =
"demurragefee=3D0.00000000" and "inactivity=3D999999999". Good to know, tha=
t a proposal like that, can be turned off that simply.<br /><br /><div clas=
s=3D"gmail_quote"><div dir=3D"auto" class=3D"gmail_attr">czwartek, 1 sierpn=
ia 2024 o=C2=A023:13:42 UTC+2 Richard Greaser napisa=C5=82(a):<br/></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0 0 0 0.8ex; border-left: =
1px solid rgb(204, 204, 204); padding-left: 1ex;">Hi everyone,=C2=A0<div><b=
r></div><div>It has become apparent to me that there is an issue where user=
s of the network holding their coins, are not adding value to the network. =
<br><br></div><div>As miners continue to get squeezed post halving, they wo=
uld benefit tremendously from fees being taken from individuals refusing to=
 move their coins, providing increased security to the network.=C2=A0<br><b=
r>I have written out a proposal more in depth and is attached below.=C2=A0<=
/div></blockquote></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/cab2d0fd-e5f0-40e1-b648-3741e69822f5n%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/cab2d0fd-e5f0-40e1-b648-3741e69822f5n%40googlegroups.com</a>.=
<br />

------=_Part_191047_1023545908.1722588318288--

------=_Part_191046_1478998838.1722588318288--