Re: [bitcoin-dev] Testnet3 Reest
On Fri, Aug 31, 2018 at 9:43 PM Gregory Maxwell via bitcoin-dev 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. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Testnet3 Reest
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 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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Testnet3 Reest
On Thu, Aug 30, 2018 at 11:21 PM Johnson Lau via bitcoin-dev 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
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 > 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 > > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Testnet3 Reest
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 > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Testnet3 Reest
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 signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
