Danny Thorpe [ARCHIVE] on Nostr: 📅 Original date posted:2015-08-19 📝 Original message:>> I would expect any ...
📅 Original date posted:2015-08-19
📝 Original message:>>
I would expect any uncontroversial hardfork to be deployed in testnet3
before it is deployed in bitcoin's main chain.
<<
Ok, glad to hear that.
>>
In any case, you can already do these tests using
https://github.com/bitcoin/bitcoin/pull/6382
<<
I saw your post about that awhile ago, thanks for doing the work! My
fiddling with that end of the food chain is gated by my needing to block
out a weekend to set up a bitcoind build environment.
How do "big-block" testnet nodes running this 6382 rev recognize each other
on the peer network? If I set up a 2MB block limit testnet node and
-addnode another 2MB block testnet node (say, JornC's node) to it, and my
node mines a block stuffed with 1.3MB of test txs, the other "big-block"
node should accept my mined block, but it will be rejected / immediately
orphaned by the rest of the testnet network because it exceeds their notion
of block size limit, correct?
Thanks,
-Danny
On Wed, Aug 19, 2015 at 2:29 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> On Tue, Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Ya, so? All that means is that the experiment might reach the hard fork
> tipping point faster than mainnet would. Verifying that the network can
> handle such transitions, and how larger blocks affect the network, is the
> point of testing.
> >
> > And when I refer to testnet, I mean the public global testnet
> blockchain, not in-house isolated networks like testnet-in-a-box.
>
> I would expect any uncontroversial hardfork to be deployed in testnet3
> before it is deployed in bitcoin's main chain.
>
> In any case, you can already do these tests using
> https://github.com/bitcoin/bitcoin/pull/6382
> Note that even if the new testchains are regtest-like (ie cheap proof
> of work) you don't need to test them "in-a-box": you can run them from
> many different places.
> Rusty's test ( http://rusty.ozlabs.org/?p=509 ) could have been
> perfectly made using #6382, it just didn't existed at the time.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/dabc7a84/attachment.html>;
📝 Original message:>>
I would expect any uncontroversial hardfork to be deployed in testnet3
before it is deployed in bitcoin's main chain.
<<
Ok, glad to hear that.
>>
In any case, you can already do these tests using
https://github.com/bitcoin/bitcoin/pull/6382
<<
I saw your post about that awhile ago, thanks for doing the work! My
fiddling with that end of the food chain is gated by my needing to block
out a weekend to set up a bitcoind build environment.
How do "big-block" testnet nodes running this 6382 rev recognize each other
on the peer network? If I set up a 2MB block limit testnet node and
-addnode another 2MB block testnet node (say, JornC's node) to it, and my
node mines a block stuffed with 1.3MB of test txs, the other "big-block"
node should accept my mined block, but it will be rejected / immediately
orphaned by the rest of the testnet network because it exceeds their notion
of block size limit, correct?
Thanks,
-Danny
On Wed, Aug 19, 2015 at 2:29 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> On Tue, Aug 18, 2015 at 11:06 PM, Danny Thorpe via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > Ya, so? All that means is that the experiment might reach the hard fork
> tipping point faster than mainnet would. Verifying that the network can
> handle such transitions, and how larger blocks affect the network, is the
> point of testing.
> >
> > And when I refer to testnet, I mean the public global testnet
> blockchain, not in-house isolated networks like testnet-in-a-box.
>
> I would expect any uncontroversial hardfork to be deployed in testnet3
> before it is deployed in bitcoin's main chain.
>
> In any case, you can already do these tests using
> https://github.com/bitcoin/bitcoin/pull/6382
> Note that even if the new testchains are regtest-like (ie cheap proof
> of work) you don't need to test them "in-a-box": you can run them from
> many different places.
> Rusty's test ( http://rusty.ozlabs.org/?p=509 ) could have been
> perfectly made using #6382, it just didn't existed at the time.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/dabc7a84/attachment.html>;