From: "'emsit' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Unbreaking testnet4
Date: Mon, 28 Apr 2025 04:59:09 -0700 (PDT) [thread overview]
Message-ID: <47f218f0-4c7d-464c-a68c-04bcfeb5b76dn@googlegroups.com> (raw)
In-Reply-To: <CADL_X_dfaBQJDXu=urRn40J7fCkDAPi-sdnnCwAZd4RUgr68fw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 9733 bytes --]
I think that the idea of expiring testnet coins would kill faucets. So
getting some coins would become even harder.
My faucet doesn't work based on donations. What I distribute I had to mine
myself (ideally in the early days, when the difficulty was lower). And
since I’ve been running the faucet for more than 10 years, I can say that
only a very small portion of testnet BTC ever returns to the faucet, and it
was like that even before people started trading it.
It's better for people to keep their testnet coins for future use rather
than later struggling to find ways to get more. Not everyone can mine. I
myself had to rent mining power.
Back in the day, I used to give away 1-2 BTC per withdrawal — there were
enough coins, and nobody cared about them. But in recent years, demand has
skyrocketed, supplies have shrunk, and withdrawals became more frequent.
Some people started abusing faucets, and it’s still happening today, which
is why my current withdrawal limit is set to 0.001-0.002 per request.
Even though testnet4 is new and the block reward is 50 BTC, it hasn’t
solved the shortage problem because most mined coins aren't publicly
available.
And even if some faucet had plenty of them, it would still only offer a
very small withdrawal amount, because people would immediately start
abusing it to profit.
Dátum: pondelok 28. apríla 2025, čas: 13:06:38 UTC+2, odosielateľ: Jameson
Lopp
> On Mon, Apr 28, 2025 at 2:11 AM Saint Wenhao <saint...@gmail•com> wrote:
>
>> > Demurrage might be asking a bit much in terms of deviation.
>>
>> If that's the case, then why signing all blocks in signet is not "too
>> much"?
>>
>
> Because signet isn't testnet? It gives up permissionless block creation in
> return for predictability.
>
>
>> Or why unlimited supply is not "too much"?
>>
>
> It might be, but it might not be, given that the point of testnet is for
> coins to be free for developers to acquire and use without fear of
> financial loss. Thus scarcity isn't really an inviolable property of
> testnet.
>
>
>> All of these changes were put in the same basket of "Require unanimous
>> consent", so why one kind of change is better or worse than the others? All
>> of them deviates from the mainnet, and we probably wouldn't want anything
>> like that on the original chain anyway.
>>
>
>>
>> > I'd think that testnets should be reset more frequently than that.
>>
>> Then why don't we put any kind of reset logic into testnet5 consensus
>> rules? Because when nothing like that is present, then testnets can
>> potentially run forever. Testnet3 is becoming an altcoin, and new testnets
>> will also be, if no significant changes will be made. Signet is not traded
>> yet, mainly because of centralized mining, but there already are
>> centralized altcoin federations, so it may change in the future.
>>
>>
> Encoding an "end of life date" into testnets is actually an interesting
> idea worth discussing. As far as I'm aware it's never been done before on
> any network.
>
> And again, the word "reset" should be replaced by "abandon", unless you
>> really want to reorganize the whole old chain of some existing testnet, by
>> producing a stronger alternative chain in testnet5, which would replace the
>> old network in a backward-compatible way, by mining everything on top of
>> the same Genesis Block, and eventually producing a bigger chainwork.
>>
>
>> pon., 28 kwi 2025 o 00:50 Jameson Lopp <jameso...@gmail•com> napisał(a):
>>
>>>
>>>
>>> On Sun, Apr 27, 2025 at 12:47 PM Saint Wenhao <saint...@gmail•com>
>>> wrote:
>>>
>>>> What about introducing demurrage in testnet5 consensus rules?
>>>>
>>> In general it seems desirable for a testnet to be as close as possible
>>> to mainnet's rules. Demurrage might be asking a bit much in terms of
>>> deviation.
>>>
>>> I'd suggest simply disabling the halving logic and making it a perpetual
>>> 50 TBTC issuance. At that rate, it would still take ~8 years or so to
>>> surpass the 21M limit and I'd think that testnets should be reset more
>>> frequently than that.
>>>
>>>>
>>>> Testnet coins were supposed to be worthless. But it failed in both
>>>> testnet3 and testnet4. In the meanwhile, signet was introduced, to make a
>>>> more stable test network. However, signing blocks was listed on wiki page
>>>> https://en.bitcoin.it/wiki/Prohibited_changes as something, that
>>>> "Require unanimous consent". And, as the history can tell us, people still
>>>> wanted to test mining anyway, which is why testnet3 and testnet4 have much
>>>> more chainwork than signet (and when it comes to signet, sending
>>>> signed-but-unmined blocks to the miners was never implemented, so they had
>>>> no chance to provide more hashing power).
>>>>
>>>> Another kind of change on the list, that would require consent, was
>>>> increasing the total number of coins beyond 21 million. But then, testing
>>>> supply limits would be harder, and it could cause integer overflows in some
>>>> cases. But: in all test networks, including testnet3, testnet4, and signet,
>>>> there was never a problem of "not enough coins for miners", so that change
>>>> probably wouldn't solve any problems (and seeing it in action would take
>>>> years anyway; testnet4 is still far from the first halving, and it is
>>>> traded anyway, so that change won't fix it).
>>>>
>>>> Then, we have the third option, which was not yet tried in test
>>>> networks: demurrage. There are two main options: burning coins, or
>>>> re-assigning them to someone else. To make a soft-fork out of it,
>>>> re-assigning would be backward-incompatible, so it is probably easier to
>>>> just implement burning, and just treat all coins older than N blocks in the
>>>> same way, as OP_RETURN, by simply invalidating transactions spending them
>>>> on consensus level.
>>>>
>>>> Also, when it comes to maintaining testnet nodes, if it would be
>>>> possible to automatically remove things from the UTXO set, then it would
>>>> make Initial Blockchain Download easier, just because new nodes wouldn't
>>>> need to synchronize everything, if old coins would be automatically
>>>> invalidated. In practice, all nodes could be just running in pruned mode
>>>> all the time, and everything beyond the pruning point, could be simply
>>>> ignored on consensus level (which would also prevent the UTXO set from
>>>> exploding). And then, if we would keep for example the last 2,016 blocks,
>>>> then the whole chain would never take more than 2016 * 4 MB = 8.064 GB of
>>>> storage, and that's all we would need to send during Initial Blockchain
>>>> Download to other nodes.
>>>>
>>>> poniedziałek, 31 marca 2025 o 22:50:27 UTC+2 Antoine Poinsot napisał(a):
>>>>
>>>>> Good point on not having the flag day on a holiday. One or two weeks
>>>>> sounds good to me.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Monday, March 24th, 2025 at 8:25 AM, Murch <mu...@murch•one> wrote:
>>>>>
>>>>> >
>>>>> >
>>>>> > Errr, I wrote the same date as you, but I meant a week later,
>>>>> 2026-01-08
>>>>> > instead.
>>>>> >
>>>>> > -Murch
>>>>> >
>>>>> > On 2025-03-21 14:20, Murch wrote:
>>>>> >
>>>>> > > Hey Antoine and everyone,
>>>>> > >
>>>>> > > What you suggest makes sense to me. Since the 20-minute difficulty
>>>>> > > exception is now exploited perpetually, it doesn’t serve its
>>>>> intended
>>>>> > > purpose of allowing developers to mine themselves a few coins
>>>>> easily or
>>>>> > > confirm their own non-standard transactions. In that case, it
>>>>> would be
>>>>> > > better to not have it at all.
>>>>> > >
>>>>> > > On 2025-03-18 07:29, 'Antoine Poinsot' via Bitcoin Development
>>>>> Mailing
>>>>> > > List wrote:
>>>>> > >
>>>>> > > > I propose to fix this by removing the difficulty reset rule from
>>>>> > > > testnet4 through a flag day hard fork on 2026-01-01.
>>>>> > >
>>>>> > > I would suggest to pick a date that’s not a holiday in many places
>>>>> to
>>>>> > > avoid disrupting people’s holiday, how about 2026-01-01 instead?
>>>>> > >
>>>>> > > Cheers,
>>>>> > > Murch
>>>>> >
>>>>> >
>>>>> > --
>>>>> > 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+...@googlegroups•com.
>>>>> > To view this discussion visit
>>>>> https://groups.google.com/d/msgid/bitcoindev/7c6800f0-7b77-4aca-a4f9-2506a2410b29%40murch.one.
>>>>>
>>>>>
>>>> --
>>>> 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+...@googlegroups•com.
>>>> To view this discussion visit
>>>> https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%40googlegroups.com
>>>> <https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>
--
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 visit https://groups.google.com/d/msgid/bitcoindev/47f218f0-4c7d-464c-a68c-04bcfeb5b76dn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 13551 bytes --]
next prev parent reply other threads:[~2025-04-29 14:15 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-18 14:29 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-03-18 21:34 ` Melvin Carvalho
2025-03-19 7:01 ` [bitcoindev] " Garlo Nicon
2025-03-19 7:56 ` [bitcoindev] " Sjors Provoost
2025-03-19 8:43 ` Garlo Nicon
2025-03-19 8:32 ` Sjors Provoost
2025-03-19 9:11 ` Melvin Carvalho
2025-03-19 17:03 ` bitcoin-dev-ml.void867 via Bitcoin Development Mailing List
2025-03-20 18:58 ` Melvin Carvalho
2025-03-21 21:20 ` Murch
2025-03-24 7:00 ` Garlo Nicon
2025-03-31 7:32 ` Saint Wenhao
2025-03-24 12:25 ` Murch
2025-03-24 13:57 ` 'Antoine Poinsot' via Bitcoin Development Mailing List
2025-04-27 11:44 ` Saint Wenhao
2025-04-27 22:49 ` Jameson Lopp
2025-04-28 6:11 ` Saint Wenhao
2025-04-28 10:45 ` Jameson Lopp
2025-04-28 11:59 ` 'emsit' via Bitcoin Development Mailing List [this message]
2025-04-28 12:47 ` Sjors Provoost
2025-04-28 13:33 ` Saint Wenhao
2025-04-28 18:15 ` Saint Wenhao
2025-04-28 18:50 ` Sjors Provoost
[not found] ` <20250428110655.D4A1C7C0AE9@smtp.postman.i2p>
2025-04-28 11:48 ` pithosian
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=47f218f0-4c7d-464c-a68c-04bcfeb5b76dn@googlegroups.com \
--to=bitcoindev@googlegroups.com \
--cc=emsit@emsit$(echo .)sk \
/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