Delivery-date: Fri, 03 May 2024 17:04:34 -0700 Received: from mail-yb1-f187.google.com ([209.85.219.187]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s32tF-0007zx-UJ for bitcoindev@gnusha.org; Fri, 03 May 2024 17:04:34 -0700 Received: by mail-yb1-f187.google.com with SMTP id 3f1490d57ef6-de468af2b73sf515155276.0 for ; Fri, 03 May 2024 17:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1714781068; x=1715385868; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:sender:from :to:cc:subject:date:message-id:reply-to; bh=yhckZmBxdTu6JOZmiYgPk+4fK8vry4AQoH04HglhZCY=; b=K5ZYwCk7u+X4muvMwoz0Kf87DAL2jovLfwNNWA8KgdDeDxBcGVThahQZPOpnCNpMRb BJxPZ0u7ruN87KW8DTg6RhhOcAIhRu3NbdyN+eu0elq5J+onfyeSH35OWuJLR1mimbj0 fAymYMHUFu/sInS4oameZIHzNeqJ1Owrjp3NsOzY4YskpwwlEgEpDSvdHwSB3Fsrefvo 1cVGISWURmjNBT+fKYt4pISqjR66DdUKoqfIvsepyNt7kkl6fEw6xBV2zhUfyI0arBJx cVDfA3NTX8FJ2mGaz+jE+cIa8yiIx8GIPJfXZB/mIVdnlr3qFLX1gX3SWKibdUZuJNOE TT6g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1714781068; x=1715385868; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:from:to:cc :subject:date:message-id:reply-to; bh=yhckZmBxdTu6JOZmiYgPk+4fK8vry4AQoH04HglhZCY=; b=TyA24MyIh0Od2eSy34SxChDDwoIF+9bs9AslM0u53WH5Fj+UdVXJ8KyRf9lvOQrzv3 yGmnQeFXIXhAeW+EHxNSuJNWPMoCx6aCRzuro7Ov8BU01/5uaqbHyScbfciQGQI6i0wg t8aug3QHVbA48f7YV8BBI/GvtoCcsLx4v4fGMIgfzptKYZsA5cc/O6vnVMGGTBMTmDUt FBM0eiz8pG93dKgO5qneySR4Uw9gYQ2TpQlpl0WvF5sp17wcgTCyEb2fe6D+tTS5Hiam ACtCf2/dmR7F4U4jAlfykjbpDmuOgrHr6vjvoFfaFXxKJzVC9BWbSkbhshRyMn+ofQ+7 CoMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1714781068; x=1715385868; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:references:in-reply-to:message-id:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=yhckZmBxdTu6JOZmiYgPk+4fK8vry4AQoH04HglhZCY=; b=rt06wPKe4FGDFI5ddi5p72Y8mZ210a2E4apPrzan/xFJTzYYYHsrXJIEUwQeUlZ0cz /p/DIZN2LVoXVlRmrDQ1T3tHsTGHUnXEyoTKMaYhaMIFCyAno63fuWjzaUPA7Dcx51eX YjM9ne1ucF4btufQ6MMnVvFo0Ba0DzG7Kv29z1vtUsk51btORTKzKcducTj7lpeZw3Pe y6Di0Ogi9vwPgIcNZMCzM2FmKjC3A8iG8C2YTFKjyYakYV9gUHuYLKDu9p0esagD6SYE /6aAkF3Er5jZHbKoJUwxo99FjNO491TkGlYt7QYFvBhKo9M6I2G9LCLGZvpcgYAEf/42 4QOw== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCULk5CSBhuW34fkOUQyHlHTBhd8M+AElCdGwfqcGqpDxYLUHbAngqp3ABXLPKC9zFGGLJarMYDDGar9OOPvw6FZ/NBrxi0= X-Gm-Message-State: AOJu0Yy2JKsEwAYu2ZSfYNuUTCvdMJ4T+pGQX5H2GH+I1kp1PpBpCi1n CAnBX+IGt0qSjKwpfQG9hn86tUVjZKXhtMs7fICYr3/2BksUFs1X X-Google-Smtp-Source: AGHT+IFi+uLd1SPE4nuFmIjX4kfDWYfFmEjo9tjyqipbjpJXKoUKKQ/9e9LkJu3x7rFBmcZOJu6gog== X-Received: by 2002:a05:6902:218c:b0:dd0:3a7a:fb70 with SMTP id dl12-20020a056902218c00b00dd03a7afb70mr5561766ybb.52.1714781067952; Fri, 03 May 2024 17:04:27 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a25:c7c3:0:b0:dcd:202d:6bd6 with SMTP id 3f1490d57ef6-de8b54b9441ls717423276.1.-pod-prod-03-us; Fri, 03 May 2024 17:04:26 -0700 (PDT) X-Received: by 2002:a0d:dbcd:0:b0:61a:d016:60ff with SMTP id d196-20020a0ddbcd000000b0061ad01660ffmr832272ywe.2.1714781066291; Fri, 03 May 2024 17:04:26 -0700 (PDT) Received: by 2002:a05:690c:39c:b0:61b:e8f5:76d6 with SMTP id 00721157ae682-61dfb025199ms7b3; Wed, 1 May 2024 08:30:42 -0700 (PDT) X-Received: by 2002:a0d:e6d5:0:b0:61b:e8a2:6f4a with SMTP id p204-20020a0de6d5000000b0061be8a26f4amr791900ywe.0.1714577441667; Wed, 01 May 2024 08:30:41 -0700 (PDT) Date: Wed, 1 May 2024 08:30:41 -0700 (PDT) From: Garlo Nicon To: Bitcoin Development Mailing List Message-Id: <47e4f1a0-709a-438b-a3ba-9e397c373ea9n@googlegroups.com> In-Reply-To: <3b1a26a9-acef-496a-8465-c32879d2a833n@googlegroups.com> References: <7a67edd1-0182-4170-90f4-998d12431024n@googlegroups.com> <3b1a26a9-acef-496a-8465-c32879d2a833n@googlegroups.com> Subject: Re: [bitcoindev] The Future of Bitcoin Testnet MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_66206_578549279.1714577441299" X-Original-Sender: garlonicon@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_66206_578549279.1714577441299 Content-Type: multipart/alternative; boundary="----=_Part_66207_1244780516.1714577441299" ------=_Part_66207_1244780516.1714577441299 Content-Type: text/plain; charset="UTF-8" > 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. ------=_Part_66207_1244780516.1714577441299 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Doubling every 210,000 blocks.

This can potentially increas= e spam. Why? Because the minimal fee is one satoshi per virtual byte. So, i= f 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 sudde= nly would get 100 tBTC per block, then it would increase your spamming abil= ity to 10 GB, and then 20 GB, and then 40 GB, and so on.

Also, g= oing one bit to the left in every doubling means, that after a few doubling= s, the values in 64-bit numbers will overflow, so that approach will recrea= te the Value Overflow Incident. In general, the value of 50 tBTC can be wri= tten as 0x12a05f200. That means, after 31 doublings, you will get 0x9502f90= 000000000, corresponding to 107,374,182,400 tBTC, and the next value will o= verflow.

> impossible to try to ascribe value to that.
<= br />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 unlim= ited 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
<= br />The same with many altcoins, which don't have any upper limit. Also no= te, that in many altcoins, there is a trend of burning coins, to increase t= heir 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 c= ompatible, 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.<= br />
Also, assuming no blockstorms, if you touch any rules, related t= o halvings, then they don't have to hit us immediately. It is possible, tha= t for the next four years, everything will be fine, but after that, there w= ill be a lot of drama, related to what should be the correct value of the c= oinbase transaction after that period. Note that even in the official signe= t, we are still before the first halving.

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

U= nfortunately, the current form of Testnet is doomed to have value, just lik= e BTC. Its scarcity makes it a valuable asset. And no reset will change tha= t. It will only result in repeated resets, multiple versions of testnet, an= d people never learning.

I have to agree wi= th emsit here. Never underestimate the ability for people to ascribe value = to something with provable scarcity.=C2=A0 I like Peter Todd's suggestion o= f removing the halving completely, so that plenty new coins are always comi= ng 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 com= e up with something better:
  • Doubling every 210,000 blocks= . This leads to the supply growing exponentially; impossible to try to ascr= ibe value to that.
  • Adding 1 to the subsidy every 210,000 blocks. St= ill 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 adm= issions. Yes, it eventually drops to 0, but after 50 events instead of the = current 33 halvings.
  • Change "half" to some other fraction like "nin= e-tenths". Still technically scarce, gentler decline in rewards, but still = retains the property of having a geometric sequence to the subsidies.
  • <= /ul>
    Like I said, dumb ideas, but I think there is a decision to be mad= e between avoiding a future reset by mitigating reasons people add value to= tBTC (such as scarcity) and expecting/planning for more regular resets whe= n people start inevitably valuing tBTC.

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/47e4f1a0-709a-438b-a3ba-9e397c373ea9n%40googlegroups.com.=
------=_Part_66207_1244780516.1714577441299-- ------=_Part_66206_578549279.1714577441299--