From: Gregory Maxwell <greg@xiph•org>
To: jl2012 <jl2012@xbt•hk>,
Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Cc: shiva sitamraju <shiva@blockonomics•co>
Subject: Re: [bitcoin-dev] Testnet3 Reest
Date: Fri, 31 Aug 2018 00:06:06 +0000 [thread overview]
Message-ID: <CAAS2fgSF=hx581aGUBVv6zardKG4gex43B-jZbAu0a9Rupg1WQ@mail.gmail.com> (raw)
In-Reply-To: <7E247E56-38A5-4B99-941A-A2CC837D2567@xbt.hk>
On Thu, Aug 30, 2018 at 11:21 PM Johnson Lau via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> A public testnet is still useful so in articles people could make references to these transactions.
> Maybe we could have 2 testnets at the same time, with one having a smaller block size?
I would much rather have a signed blocks testnet, with a predictable
structured reorg pattern* (and a config flag so you can make your node
ignore all blocks that are going to get reorged out in a reorg of nth
or larger). There are many applications where the mined testnet just
doesn't give you anything useful... it's too stable when you want it
to be a bit unstable and too wildly unstable when you want a bit of
stability-- e.g. there are very few test cases where a 20,000 block
reorg does anything useful for you; yet they happen on testnet.
We looked at doing this previously in Bitcoin core and jtimon had some
patches, but the existing approach increased the size of the
blockindex objects in memory while not in signed testnet mode. This
could probably have been fixed by turning one of the fields like the
merkel root into a union of it's normal value and a pointer a
look-aside block index that is used only in signed block testnet mode.
Obviously such a mode wouldn't be a replacement for an ordinary
testnet, but it would be a useful middle ground between regtest (that
never sees anything remotely surprising and can't easily be used for
collaborative testing) and full on testnet where your attempts to test
against ordinary noise require you cope your entirely universe being
removed from existence and replaced by something almost but not quite
entirely different at the whim of some cthulhuian blind idiot god.
next prev parent reply other threads:[~2018-08-31 0:06 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-30 7:28 shiva sitamraju
2018-08-30 20:02 ` Peter Todd
2018-08-30 20:36 ` Jimmy Song
2018-08-30 20:44 ` Johnson Lau
2018-08-31 0:06 ` Gregory Maxwell [this message]
2018-09-01 14:47 ` rhavar
2018-09-05 3:00 ` Karl-Johan Alm
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='CAAS2fgSF=hx581aGUBVv6zardKG4gex43B-jZbAu0a9Rupg1WQ@mail.gmail.com' \
--to=greg@xiph$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jl2012@xbt$(echo .)hk \
--cc=shiva@blockonomics$(echo .)co \
/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