From: Garlo Nicon <garlonicon@gmail•com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Subject: Re: [bitcoindev] The Future of Bitcoin Testnet
Date: Tue, 9 Apr 2024 11:28:02 -0700 (PDT) [thread overview]
Message-ID: <7c2a3be7-ebea-4ea3-abea-93ff8ebe0d42n@googlegroups.com> (raw)
In-Reply-To: <8c6e98ff-bdec-4955-8132-bd93af2d40dd@dashjr.org>
[-- Attachment #1.1: Type: text/plain, Size: 7425 bytes --]
> Is the difficulty reset bug actually a bug, or a feature?
Both. It is a bug, because it makes things unstable. However, it is also a
feature, because it allows us to quickly reach a lot of halvings, and test
a situation, where basic block reward is small, and where getting new coins
is very difficult, because you have to get them from the current owners.
> If it's a bug, couldn't we just fix it and let the blockchain reorg on
its own?
But there is no need to "reorg" things. If you have 1,5 M blocks, then it
is not a problem, that in 2015, there was a blockstorm somewhere. The only
problem is if you create some transaction, and see that kind of blockstorm
here and now, when you put some timelock on your transaction, or when 100
confirmations are not enough, because it is covered with a very little
Proof of Work, and was mined in a minute.
Which also means, that fixing previous blockstorms is not that important.
Fixing the current ones is more urgent, because if you would see, that
since for example block 1,8 M, there will be no blockstorms, then that
network will become stable.
The only "fix" into previous blockstorms, could be related to the amounts,
which were mined during those blockstorms. But then, it is all about
"demurrage", or any other penalty, and it does not require erasing past
blocks from the history. Those blocks could still be present in the chain
of previous block hashes inside block headers. The only question is about
throwing away coins from the UTXO set, or turning them into fees for the
future blocks. But there is no need to overwrite the history to fix things.
> Signet is definitely not a replacement for testnet.
I wonder, what people think about merging signet and testnet into a single
chain? For example: imagine if signet would be entirely stored on testnet3,
but just some blocks would be signed with that "signet challenge", some
would be signed with another, and some would be not signed at all. Then,
you could scan the whole testnet3, pick some "signet challenge", and your
UTXO set would contain only coins from the test network, which you want to
observe. And then, everyone could do some "network reset", just by
switching the signet challenge, and rebuilding the database.
Another interesting model, is making a network, where mainnet and testnet
blocks are visible in the same timeline. Then, to make some new test coins,
you would just sign some mainnet coins. And to destroy them, you just burn
them, or move them in the main network in any way, so they are no longer
pegged, and are skipped during Initial Blockchain Download in the test
network.
> If we fix the difficulty reset bug, we might as well also fix the coin
supply issue: get rid of the halving for testnet and just make every block
create new coins.
To solve the problem of getting the new test coins, people would need to
realize the truth: testnet coins are supposed to be worthless. Which means,
that performing all tests with zero satoshis should be fine, right? So, why
those non-zero amounts are needed? Of course as a protection from spam.
Which also means, that if someone has no coins, then we could allow
including a transaction, if it provides some Proof of Work instead, right?
Because if you have 0.01 tBTC, then what does it mean? It is not something,
which should be converted into BTC. It is worthless. However, it is used to
express "data pushing ability". It simply means, that if your transaction
fee is 1 sat/vB, then you can push 1 MB publicly, and reveal your test
cases, so other users can see them. But if instead of including transaction
fee, users would share some Proof of Work, then the protocol could allow
them to include their tests for free (or just cheaper than usual), because
they did some work, so we could reward them accordingly to the hashes they
found.
By the way, even if we run out of coins, then there are still cases, where
producing new blocks with zero reward makes sense, because it affects
locktimes, the difficulty, and the whole Script is still followed to the
letter, so all kinds of contracts are still executed (and for example
timestamping a document in some Proof of Work chain may be worthy, even if
the miner didn't earn any new coins by doing so). Another use case is
unlocking some previously mined coinbase transaction, because even a new
block with no reward, still counts as an additional confirmation.
sunday, 31 march 2024 at 18:24:37 UTC+2 Luke Dashjr wrote:
Is the difficulty reset bug actually a bug, or a feature?
If it's a bug, couldn't we just fix it and let the blockchain reorg on its
own?
Signet is definitely not a replacement for testnet.
Luke
On 3/31/24 09:19, Jameson Lopp wrote:
Hi all,
I'd like to open a discussion about testnet3 to put out some feelers on
potential changes to it. First, a few facts:
1. Testnet3 has been running for 13 years. It's on block 2.5 million
something and the block reward is down to ~0.014 TBTC, so mining is not
doing a great job at distributing testnet coins any more.
2. The reason the block height is insanely high is due to a rather amusing
edge case bug that causes the difficulty to regularly get reset to 1, which
causes a bit of havoc. If you want a deep dive into the quirk:
https://blog.lopp.net/the-block-storms-of-bitcoins-testnet/
3. Testnet3 is being actively used for scammy airdrops; those of us who
tend to be generous with our testnet coins are getting hounded by
non-developers chasing cheap gains.
4. As a result, TBTC is being actively bought and sold; one could argue
that the fundamental principle of testnet coins having no value has been
broken.
This leads me to ponder the following questions, for which I'm soliciting
feedback.
1. Should we plan for a reset of testnet? If so, given how long it has been
since the last reset and how many production systems will need to be
updated, would a reset need to be done with a great deal of notice?
2. Is there interest in fixing the difficulty reset bug? It should be a one
liner fix, and I'd argue it could be done sooner rather than later, and
orthogonal to the network reset question. Would such a change, which would
technically be a hard fork (but also arguably a self resolving fork due to
the difficulty dynamics) necessitate a BIP or could we just YOLO it?
3. Is all of the above a waste of time and we should instead deprecate
testnet in favor of signet?
- Jameson
--
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 on the web visit
https://groups.google.com/d/msgid/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw%40mail.gmail.com
<https://groups.google.com/d/msgid/bitcoindev/CADL_X_eXjbRFROuJU0b336vPVy5Q2RJvhcx64NSNPH-3fDCUfw%40mail.gmail.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 on the web visit https://groups.google.com/d/msgid/bitcoindev/7c2a3be7-ebea-4ea3-abea-93ff8ebe0d42n%40googlegroups.com.
[-- Attachment #1.2: Type: text/html, Size: 9267 bytes --]
next prev parent reply other threads:[~2024-04-09 21:53 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 [this message]
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
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=7c2a3be7-ebea-4ea3-abea-93ff8ebe0d42n@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