[bitcoin-dev] Testnet3 Reest

[bitcoin-dev] Testnet3 Reest

[shiva sitamraju]

[-- Attachment #1: Type: text/plain, Size: 502 bytes --]

Hi,

Testnet is now 1411795 blocks and a full sync is taking atleast 48 hours.

Is a testnet reset scheduled in the next release or any reason not to do a
reset ?

Fast onboarding/lower disk overheads would be  very much appreicated for
testing purposes

Regards


-- 
Shiva S
CEO @ Blockonomics <https://www.blockonomics.co>
Decentralized and Permissionless Payments
Join us on Telegram <https://t.me/BlockonomicsCo>
View our Welcome Guide
<https://www.blockonomics.co/docs/blockonomics-brochure.pdf>

[-- Attachment #2: Type: text/html, Size: 991 bytes --]

Re: [bitcoin-dev] Testnet3 Reest

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 747 bytes --]

On Thu, Aug 30, 2018 at 12:58:42PM +0530, shiva sitamraju via bitcoin-dev wrote:
> Hi,
> 
> Testnet is now 1411795 blocks and a full sync is taking atleast 48 hours.
> 
> Is a testnet reset scheduled in the next release or any reason not to do a
> reset ?
> 
> Fast onboarding/lower disk overheads would be  very much appreicated for
> testing purposes

Actually I'd advocate the opposite: I'd want testnet to be a *larger*
blockchain than mainnet to find size-related issues first.

Note that for testing regtest is often a better alternative, and you can setup
private regtest blockchains fairly easily and with good control over exactly
when and how blocks are created.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Testnet3 Reest

[Jimmy Song]

[-- Attachment #1: Type: text/plain, Size: 1121 bytes --]

Stupid question time:

Why don't we have multiple testnets?

On Thu, Aug 30, 2018 at 3:31 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Aug 30, 2018 at 12:58:42PM +0530, shiva sitamraju via bitcoin-dev
> wrote:
> > Hi,
> >
> > Testnet is now 1411795 blocks and a full sync is taking atleast 48 hours.
> >
> > Is a testnet reset scheduled in the next release or any reason not to do
> a
> > reset ?
> >
> > Fast onboarding/lower disk overheads would be  very much appreicated for
> > testing purposes
>
> Actually I'd advocate the opposite: I'd want testnet to be a *larger*
> blockchain than mainnet to find size-related issues first.
>
> Note that for testing regtest is often a better alternative, and you can
> setup
> private regtest blockchains fairly easily and with good control over
> exactly
> when and how blocks are created.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 1842 bytes --]

Re: [bitcoin-dev] Testnet3 Reest

[Johnson Lau]

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?

> On 31 Aug 2018, at 4:02 AM, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> Signed PGP part
> On Thu, Aug 30, 2018 at 12:58:42PM +0530, shiva sitamraju via bitcoin-dev wrote:
>> Hi,
>> 
>> Testnet is now 1411795 blocks and a full sync is taking atleast 48 hours.
>> 
>> Is a testnet reset scheduled in the next release or any reason not to do a
>> reset ?
>> 
>> Fast onboarding/lower disk overheads would be  very much appreicated for
>> testing purposes
> 
> Actually I'd advocate the opposite: I'd want testnet to be a *larger*
> blockchain than mainnet to find size-related issues first.
> 
> Note that for testing regtest is often a better alternative, and you can setup
> private regtest blockchains fairly easily and with good control over exactly
> when and how blocks are created.
> 
> -- 
> https://petertodd.org 'peter'[:-1]@petertodd.org
> 
> 

Re: [bitcoin-dev] Testnet3 Reest

[Gregory Maxwell]

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.

Re: [bitcoin-dev] Testnet3 Reest

[rhavar]

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

Re: [bitcoin-dev] Testnet3 Reest

[Karl-Johan Alm]

On Fri, Aug 31, 2018 at 9:43 PM Gregory Maxwell via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.

I am currently working on an implementation that simply puts a global
mapping of block hash to signature that is transparently
(de)serialized in the block header.

We were looking into various ways to stuff the signature into the
actual header itself without changing its size, but this looked like
it required truncating the prevblock/merkleroots and such, which
seemed a bit too invasive.

I don't think my approach with a global mapping to sig differs in any
meaningful way from your suggested union, but corrections welcome.

The code is here: https://github.com/kallewoof/bitcoin/tree/signet

I believe jtimon is interested in helping out, and Jeremy Rubin has
also said he wants to help.