public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Garlo Nicon <garlonicon@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] The Future of Bitcoin Testnet
Date: Wed, 1 May 2024 08:30:41 -0700 (PDT)	[thread overview]
Message-ID: <47e4f1a0-709a-438b-a3ba-9e397c373ea9n@googlegroups.com> (raw)
In-Reply-To: <3b1a26a9-acef-496a-8465-c32879d2a833n@googlegroups.com>


[-- Attachment #1.1: Type: text/plain, Size: 4294 bytes --]

> Doubling every 210,000 blocks.

This can potentially increase spam. Why? Because the minimal fee is one 
satoshi per virtual byte. So, if you increase coin amounts, without 
changing anything else, then you also increase the amount of bytes, which 
you can push to the network. Because if you have 50 tBTC, then it means you 
can push 5 GB of data, so if you suddenly would get 100 tBTC per block, 
then it would increase your spamming ability to 10 GB, and then 20 GB, and 
then 40 GB, and so on.

Also, going one bit to the left in every doubling means, that after a few 
doublings, the values in 64-bit numbers will overflow, so that approach 
will recreate the Value Overflow Incident. In general, the value of 50 tBTC 
can be written as 0x12a05f200. That means, after 31 doublings, you will get 
0x9502f90000000000, corresponding to 107,374,182,400 tBTC, and the next 
value will overflow.

> impossible to try to ascribe value to that.

Even if some monetary system has some inflation, some value can always be 
assigned. For example, a lot of fiat coins like dollars, can have unlimited 
inflation. And they still have value, even if there is no max supply. There 
is even a word for what happens in systems with hyperinflation, it is 
called redenomination: https://en.wikipedia.org/wiki/Redenomination

The same with many altcoins, which don't have any upper limit. Also note, 
that in many altcoins, there is a trend of burning coins, to increase their 
value. So, the same could happen in a new testnet: claiming less coins in 
the coinbase transaction, is a perfectly valid no-fork, that would be 
compatible, so even if you type in code "you can get 100 tBTC", then miners 
could still claim only 50 tBTC or 25 tBTC, and their blocks will be valid.

Also, assuming no blockstorms, if you touch any rules, related to halvings, 
then they don't have to hit us immediately. It is possible, that for the 
next four years, everything will be fine, but after that, there will be a 
lot of drama, related to what should be the correct value of the coinbase 
transaction after that period. Note that even in the official signet, we 
are still before the first halving.

Tuesday, 30 April 2024 at 21:00:32 UTC+2 Matthew Bagazinski wrote:

Unfortunately, the current form of Testnet is doomed to have value, just 
like BTC. Its scarcity makes it a valuable asset. And no reset will change 
that. It will only result in repeated resets, multiple versions of testnet, 
and people never learning.

I have to agree with emsit here. Never underestimate the ability for people 
to ascribe value to something with provable scarcity.  I like Peter Todd's 
suggestion of removing the halving completely, so that plenty new coins are 
always coming into circulation, but it received pushback for removing the 
regular 210,000-block events. Here are a few dumb ideas to chew on to see 
if we can come up with something better:

   - Doubling every 210,000 blocks. This leads to the supply growing 
   exponentially; impossible to try to ascribe value to that.
   - Adding 1 to the subsidy every 210,000 blocks. Still an infinite 
   supply, closer to a standard subsidy, but there is still a change happening 
   every 210,000 blocks.
   - Subtracting 1 every 210,000 blocks. This is technically still scarce, 
   but a much gentler decline in admissions. Yes, it eventually drops to 0, 
   but after 50 events instead of the current 33 halvings.
   - Change "half" to some other fraction like "nine-tenths". Still 
   technically scarce, gentler decline in rewards, but still retains the 
   property of having a geometric sequence to the subsidies.

Like I said, dumb ideas, but I think there is a decision to be made between 
avoiding a future reset by mitigating reasons people add value to tBTC 
(such as scarcity) and expecting/planning for more regular resets when 
people start inevitably valuing tBTC.

-- 
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/47e4f1a0-709a-438b-a3ba-9e397c373ea9n%40googlegroups.com.

[-- Attachment #1.2: Type: text/html, Size: 5363 bytes --]

  reply	other threads:[~2024-05-04  0:04 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-31 13:19 Jameson Lopp
2024-03-31 14:33 ` Luke Dashjr
2024-03-31 14:57   ` Jameson Lopp
2024-03-31 17:21     ` Eric Voskuil
2024-04-09 18:28   ` Garlo Nicon
2024-03-31 16:02 ` Peter Todd
2024-03-31 21:01   ` Nagaev Boris
2024-03-31 21:29     ` Peter Todd
2024-04-01 12:54       ` Jameson Lopp
2024-04-01 13:37         ` Pieter Wuille
2024-04-01 14:20           ` Andrew Poelstra
2024-04-01 22:01             ` 'Fabian' via Bitcoin Development Mailing List
2024-04-02 11:53               ` Jameson Lopp
2024-04-02 18:36                 ` Lukáš Kráľ
2024-04-02 19:46                   ` Jameson Lopp
2024-04-03  4:19           ` Anthony Towns
2024-04-03 18:18             ` emsit
2024-04-03 19:35               ` Andrew Poelstra
2024-04-30 18:46               ` Matthew Bagazinski
2024-05-01 15:30                 ` Garlo Nicon [this message]
2024-05-04 17:13                 ` Peter Todd
2024-04-10  6:57       ` Garlo Nicon
2024-04-22  4:33         ` Ali Sherief
2024-04-01 13:25 ` Andrew Poelstra
2024-04-01 13:32   ` 'Fabian' via Bitcoin Development Mailing List
2024-04-01 14:28 ` Warren Togami
2024-04-01 19:22 ` [bitcoindev] " emsit
2024-04-04  8:14 ` Calvin Kim
2024-04-04 12:47   ` Jameson Lopp
2024-04-05  4:30     ` Calvin Kim
2024-04-06 23:04       ` David A. Harding
2024-04-09 16:48         ` Peter Todd
2024-04-16 17:30           ` [bitcoindev] " 'Sjors Provoost' via Bitcoin Development Mailing List
2024-04-07  7:20   ` [bitcoindev] " Christian Decker
2024-04-07  8:09     ` K Calvin
2024-04-08 19:11 ` Garlo Nicon
2024-04-09  4:29   ` coinableS
2024-04-28 13:45 ` [bitcoindev] " Matt Corallo
2024-05-02  7:10   ` Ali Sherief
2024-05-04 17:08     ` Peter Todd

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=47e4f1a0-709a-438b-a3ba-9e397c373ea9n@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