From: rhavar@protonmail•com
To: Gregory Maxwell <greg@xiph•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Cc: shiva sitamraju <shiva@blockonomics•co>
Subject: Re: [bitcoin-dev] Testnet3 Reest
Date: Sat, 01 Sep 2018 14:47:53 +0000 [thread overview]
Message-ID: <nSgDJydDNqQwbRrVzhJ7PsRHnVr2eqXTA8I2X4p-Wm16M4TW4PCSPU20q9nUrO-2Hm8WODFILJqb7drIaY74wSnCQ3cAcDvqfHZ7b_mOM6w=@protonmail.com> (raw)
In-Reply-To: <CAAS2fgSF=hx581aGUBVv6zardKG4gex43B-jZbAu0a9Rupg1WQ@mail.gmail.com>
I think I mentioned it before, but seems semi-relevant to this thread so I'd like to throw my vote behind pretty tiny blocks on testnet (like max 50-100k weight) to try help simulate a fee-market like situation.
(Although lately there's been a lot of testnet spam and full blocks, which has really made testing easier. But I don't know how long this situation will last)
-Ryan
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On August 30, 2018 7:06 PM, Gregory Maxwell via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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.
>
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
next prev parent reply other threads:[~2018-09-01 14:48 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
2018-09-01 14:47 ` rhavar [this message]
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='nSgDJydDNqQwbRrVzhJ7PsRHnVr2eqXTA8I2X4p-Wm16M4TW4PCSPU20q9nUrO-2Hm8WODFILJqb7drIaY74wSnCQ3cAcDvqfHZ7b_mOM6w=@protonmail.com' \
--to=rhavar@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=greg@xiph$(echo .)org \
--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