From: Garlo Nicon <garlonicon@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: [bitcoindev] Re: HODL Tax Proposal
Date: Fri, 2 Aug 2024 01:45:18 -0700 (PDT) [thread overview]
Message-ID: <cab2d0fd-e5f0-40e1-b648-3741e69822f5n@googlegroups.com> (raw)
In-Reply-To: <6512db18-bd15-462e-92fd-7549b5e885e7n@googlegroups.com>
[-- Attachment #1.1: Type: text/plain, Size: 4185 bytes --]
Good luck implementing it in test networks first, for example testnet3.
Some 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
history, and a lot of halvings. So, if you think seriously about it, then
you should start from testnet3. Other networks, including mainnet, have not
enough blocks, and have too big rewards for that.
> addresses that do not engage in any outgoing transactions for over 60 days
Miners 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 include it. Then, required demurrage fees will be higher, than
what was originally sent as fees, and all nodes will just throw it away,
while respecting your consensus. Which also means, that this proposal
enables "transaction expiration" in some implicit way: if a transaction is
not confirmed in N blocks, then everything is eaten by demurrage fees, so
the old transaction simply expires.
> action needs to be taken before Peter Todd's suggestion of tail emissions
get any serious momentum
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 is easy. If people will inflate Bitcoin, then other
people will bring it back to the equilibrium, just by burning all
overprinted coins, and refusing to 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.
> 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,
because of fees like that. If you have 1 BTC, and you have to pay 100k
satoshis, then you can compare it with on-chain fees, where you can get it
confirmed for 1k sats. Which means, that this "0.1% fees" will remove all
whales from your network, where "a whale" is "anyone with >= 0.01 BTC".
Good luck maintaining the chain without any whales, it will be just an
altcoin, similar to CPU-mined altcoins, where "miners=users" is the only
use-case.
Also note, 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 transaction entirely (because of missing demurrage fees), or confirm
two transactions: one paying demurrage fees, and one sending them back to
the user. Congratulations, your rule just doubled the number of
transactions for no reason. Because only miners getting proper fees will
survive, everyone else will reject too many transactions, and end up with
nothing.
> The inactivity threshold and fee rate can be adjusted based on community
feedback and network conditions.
So, is it a local node policy, instead of being a consensus rule? Good,
then I can just edit my config file, put "demurragefee=0.00000000" and
"inactivity=999999999". Good to know, that a proposal like that, can be
turned off that simply.
czwartek, 1 sierpnia 2024 o 23:13:42 UTC+2 Richard Greaser napisał(a):
> Hi everyone,
>
> It has become apparent to me that there is an issue where users of the
> network holding their coins, are not adding value to the network.
>
> As miners continue to get squeezed post halving, they would benefit
> tremendously from fees being taken from individuals refusing to move their
> coins, providing increased security to the network.
>
> I have written out a proposal more in depth and is attached below.
>
--
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 email 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.
[-- Attachment #1.2: Type: text/html, Size: 4689 bytes --]
prev parent reply other threads:[~2024-08-02 12:31 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-01 21:03 [bitcoindev] " Richard Greaser
2024-08-01 21:59 ` José Edil Guimarães de Medeiros
2024-08-02 0:28 ` Keagan McClelland
2024-08-02 1:19 ` Jimmy Song
2024-08-02 2:03 ` George Burke
2024-08-02 5:08 ` 'hashnoncemessage' via Bitcoin Development Mailing List
2024-08-01 23:38 ` George Burke
2024-08-02 0:12 ` Keagan McClelland
2024-08-02 8:45 ` Garlo Nicon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cab2d0fd-e5f0-40e1-b648-3741e69822f5n@googlegroups.com \
--to=garlonicon@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox