Re: [bitcoin-dev] Testnet3 Reest

[rhavar@protonmail.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