From: "'Sjors Provoost' via Bitcoin Development Mailing List" <bitcoindev@googlegroups.com>
To: bitcoindev@googlegroups.com
Cc: "David A. Harding" <dave@dtrt•org>, Peter Todd <pete@petertodd•org>
Subject: Re: [bitcoindev] The Future of Bitcoin Testnet
Date: Tue, 16 Apr 2024 19:30:37 +0200 [thread overview]
Message-ID: <B72E693A-4050-4AE8-B8FE-8986760BD9C3@sprovoost.nl> (raw)
In-Reply-To: <ZhVxZN6eLiCpdQ/F@petertodd.org>
[-- Attachment #1: Type: text/plain, Size: 2668 bytes --]
> Op 9 apr 2024, om 18:48 heeft Peter Todd <pete@petertodd•org> het volgende geschreven:
>
> On Sat, Apr 06, 2024 at 01:04:16PM -1000, David A. Harding wrote:
>>
>>
>> On April 4, 2024 6:30:19 PM HST, Calvin Kim <ccychc@gmail•com> wrote:
>>> I support reseting testnet3.
>>>
>>> However, I'm more inclined towards keeping the rules the same.
>>
>> What about fundamentally requiring BIP34 from the start of the next testnet? I haven't heard anyone say this, but I assume the current testnet4 having reverted[1] to BIP30 is bad for utreexo?
The current proposed testnet4 has all the usual soft-forks active from block 1,
see e.g. BIP34Height in src/kernel/chainparams.cpp
https://github.com/bitcoin/bitcoin/pull/29775
> NACK
>
> One of the purposes of testnet is to exercise edge cases in code, in an
> environment where mistakes don't cost money. It's a good thing that, eg, a
> utreexo testnet implementation has to deal with all the the same warts as it
> would have to eventually deal with in mainnet.
>
> In fact, ideally if we reset testnet we'd delibrately *add* non-unique txids to
> testnet to ensure that code related to that flaw is exercised; IIRC testnet
> currently does not have any.
No strong feelings here. If people want this, we could pick a height and have
a short free-for-all duplicate transaction mining period before then.
However, it would be annoying if we later propose a permanent BIP30 fix,
and it turns out it only works on mainnet and not on testnet. Though I suppose
we could just reset it again.
> At the very least, if we do a testnet reset we should
> consider re-adding all those weird edge cases to the new testnet.
For consensus valid transactions that can be done later by anyone. For things
that past soft forks made invalid, someone would have to make plan for when to
activate them, plus a script to produce some interesting test vectors before
activation.
The first Bitcoin Core release with testnet4 will probably be v28 in October,
so there's some time to do this.
Note that some soft forks are treated as always active and are not even set in
chainparams.cpp - we might want to do that again for other soft forks that are
sufficiently old. It would be annoying if testnet gets in the way of that, but see above.
- Sjors
--
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/B72E693A-4050-4AE8-B8FE-8986760BD9C3%40sprovoost.nl.
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-04-16 17:34 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
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 ` 'Sjors Provoost' via Bitcoin Development Mailing List [this message]
2024-04-07 7:20 ` 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=B72E693A-4050-4AE8-B8FE-8986760BD9C3@sprovoost.nl \
--to=bitcoindev@googlegroups.com \
--cc=dave@dtrt$(echo .)org \
--cc=pete@petertodd$(echo .)org \
--cc=sjors@sprovoost$(echo .)nl \
/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