From: Saint Wenhao <saintwenhao@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] Unbreaking testnet4
Date: Sun, 27 Apr 2025 04:44:16 -0700 (PDT) [thread overview]
Message-ID: <672cb527-9005-46fc-be2c-4508d39cfd7dn@googlegroups.com> (raw)
In-Reply-To: <vgcVopNpWCowIGaIpVgjsCWyTMjxVKoWtRdDVnTNrM8tYPjKtC6MJ6S-2KxIYdJYgAhG8iNPig-xijwd7DtAm6tHN3T3xgIMUNUSTBYvT_A=@protonmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4546 bytes --]
What about introducing demurrage in testnet5 consensus rules?
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+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/672cb527-9005-46fc-be2c-4508d39cfd7dn%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 5671 bytes --]
next prev parent reply other threads:[~2025-04-27 16:47 UTC|newest]
Thread overview: 18+ 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 [this message]
2025-04-27 22:49 ` Jameson Lopp
[not found] ` <CACgYNOKDFjxTuk8Szq305oNvS_tAwoCosrcR3ij4ihCuHjw78A@mail.gmail.com>
2025-04-28 10:45 ` Jameson Lopp
2025-04-28 12:47 ` Sjors Provoost
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=672cb527-9005-46fc-be2c-4508d39cfd7dn@googlegroups.com \
--to=saintwenhao@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