New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Do not download transactions during initial blockchain sync #7164

Merged
merged 1 commit into from Jan 19, 2016

Conversation

Projects
None yet
9 participants
@ptschip
Contributor

ptschip commented Dec 3, 2015

What I've noticed now that transaction rates are getting much higher is that every time a block is downloaded during the initial sync, sometimes 5, 10 or more new transactions are being downloaded as well and is slowing down the initial sync process. There is no reason to do a "getdata" and download these transactions since they are not getting accepted into the mempool anyway.

@laanwj

View changes

Show outdated Hide outdated src/main.cpp

@laanwj laanwj added the P2P label Dec 3, 2015

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Dec 3, 2015

Member

Despite not liking how more and more depends on IsInitialBlockDownload(), I think this makes sense. Downloading transactions during initial sync just gets a long list of "Rejected: Non-final" and wastes bandwidth and verification overhead.

Member

laanwj commented Dec 3, 2015

Despite not liking how more and more depends on IsInitialBlockDownload(), I think this makes sense. Downloading transactions during initial sync just gets a long list of "Rejected: Non-final" and wastes bandwidth and verification overhead.

@jtimon

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Dec 3, 2015

Member

utACK

Member

jtimon commented Dec 3, 2015

utACK

@petertodd

This comment has been minimized.

Show comment
Hide comment
@petertodd

petertodd Dec 3, 2015

Contributor

Concept ACK

Contributor

petertodd commented Dec 3, 2015

Concept ACK

@dcousens

This comment has been minimized.

Show comment
Hide comment
@dcousens

dcousens Dec 3, 2015

Contributor

conceptACK/utACK

Contributor

dcousens commented Dec 3, 2015

conceptACK/utACK

@ptschip

This comment has been minimized.

Show comment
Hide comment
@ptschip

ptschip Dec 3, 2015

Contributor

acutally please don't merge this yet, there is a problem with the
regression tests, i think something to do with mocktime...it appears
that the tests always think that we are syncing the blockchain...i'm
investigating

On 03/12/2015 12:14 PM, Daniel Cousens wrote:

ACK


Reply to this email directly or view it on GitHub
#7164 (comment).

Contributor

ptschip commented Dec 3, 2015

acutally please don't merge this yet, there is a problem with the
regression tests, i think something to do with mocktime...it appears
that the tests always think that we are syncing the blockchain...i'm
investigating

On 03/12/2015 12:14 PM, Daniel Cousens wrote:

ACK


Reply to this email directly or view it on GitHub
#7164 (comment).

@ptschip

This comment has been minimized.

Show comment
Hide comment
@ptschip

ptschip Dec 3, 2015

Contributor

Travis is happy now...during running the regression tests, the block
timestamps in the cache were too old and so the memory pools would not
sync thinking that an initial block download was happening. The last
block needs to be within the last 24 hours. But, I think I need to add
one more thing, if the cache folder is more than 1 day old it needs to
automatically be rebuilt otherwise the regression tests will fail again.

in util.py:

   -block_time = 1388534400
   +block_time = int(round(time.time() - (200 * 10 * 60) ))

On 03/12/2015 12:14 PM, Daniel Cousens wrote:

ACK


Reply to this email directly or view it on GitHub
#7164 (comment).

Contributor

ptschip commented Dec 3, 2015

Travis is happy now...during running the regression tests, the block
timestamps in the cache were too old and so the memory pools would not
sync thinking that an initial block download was happening. The last
block needs to be within the last 24 hours. But, I think I need to add
one more thing, if the cache folder is more than 1 day old it needs to
automatically be rebuilt otherwise the regression tests will fail again.

in util.py:

   -block_time = 1388534400
   +block_time = int(round(time.time() - (200 * 10 * 60) ))

On 03/12/2015 12:14 PM, Daniel Cousens wrote:

ACK


Reply to this email directly or view it on GitHub
#7164 (comment).

@MarcoFalke

View changes

Show outdated Hide outdated qa/rpc-tests/test_framework/util.py
@ptschip

This comment has been minimized.

Show comment
Hide comment
@ptschip

ptschip Dec 4, 2015

Contributor

@MarcoFalke Fixed that nit. Also added refreshing the cache every twelve hours which will prevent any very very long running regression tests from going over the 24hr limit for the age of the cache and subsequently preventing the mempools from syncing.

Contributor

ptschip commented Dec 4, 2015

@MarcoFalke Fixed that nit. Also added refreshing the cache every twelve hours which will prevent any very very long running regression tests from going over the 24hr limit for the age of the cache and subsequently preventing the mempools from syncing.

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Dec 4, 2015

Member

Ugh that "maximum 24 hours" check has tripped us up multiple times.

Another option to avoid the cache invalid issue would be to change nMaxTipAge to 0x7fffffff, as it is also for regtest, as it is for testnet (see #5987)

https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L172

I'd prefer that myself to having to expire the cache every 12 hours just to avoid this check. Although there's something to be said for testing IsInitialBlockDownload itself as well... so not sure

Yet another option would be to set a mock time, but this isn't easy to do consistently.

Member

laanwj commented Dec 4, 2015

Ugh that "maximum 24 hours" check has tripped us up multiple times.

Another option to avoid the cache invalid issue would be to change nMaxTipAge to 0x7fffffff, as it is also for regtest, as it is for testnet (see #5987)

https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L172

I'd prefer that myself to having to expire the cache every 12 hours just to avoid this check. Although there's something to be said for testing IsInitialBlockDownload itself as well... so not sure

Yet another option would be to set a mock time, but this isn't easy to do consistently.

@ptschip

This comment has been minimized.

Show comment
Hide comment
@ptschip

ptschip Dec 4, 2015

Contributor

@laanwj Changing nmaxtipage certainly is an easy fix but I never like the idea of changing the behaviour of an app before regression testing, it sometimes bites down the road. I used mocktime instead but then had issues with nodehandling because GetTime() doesn't increment properly once you set mocktime. Made some edits there to make GetTime() increment correctly if mocktime is set.

Also needed a small edit to p2pfullblocktest to set the time base to MOCKTIME.

Pushed and travis is happy...

Contributor

ptschip commented Dec 4, 2015

@laanwj Changing nmaxtipage certainly is an easy fix but I never like the idea of changing the behaviour of an app before regression testing, it sometimes bites down the road. I used mocktime instead but then had issues with nodehandling because GetTime() doesn't increment properly once you set mocktime. Made some edits there to make GetTime() increment correctly if mocktime is set.

Also needed a small edit to p2pfullblocktest to set the time base to MOCKTIME.

Pushed and travis is happy...

@jtimon

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Dec 4, 2015

Member

re-utACK

Member

jtimon commented Dec 4, 2015

re-utACK

@ptschip

This comment has been minimized.

Show comment
Hide comment
@ptschip

ptschip Dec 5, 2015

Contributor

Oops there is one last thing, there are a few of extended tests that might need the mocktime. I can't execute them because of ndbm which doesn't run on windows so I'll have to try things out on Travis. I think about 4 scripts that might need fixing up. Shouldn't take too long...I'll let you know when it's done.

Contributor

ptschip commented Dec 5, 2015

Oops there is one last thing, there are a few of extended tests that might need the mocktime. I can't execute them because of ndbm which doesn't run on windows so I'll have to try things out on Travis. I think about 4 scripts that might need fixing up. Shouldn't take too long...I'll let you know when it's done.

@paveljanik

This comment has been minimized.

Show comment
Hide comment
@paveljanik

paveljanik Dec 5, 2015

Contributor

Rebase needed.

Contributor

paveljanik commented Dec 5, 2015

Rebase needed.

@sdaftuar

This comment has been minimized.

Show comment
Hide comment
@sdaftuar

sdaftuar Dec 5, 2015

Member

I like the overall goal here, but I'm not sure I follow the reasoning for changing the behavior of SetMockTime. One advantage of the way mocktime works now is that for the places in the code that call GetTime(), the behavior is deterministic -- the time will always be whatever the last mocktime call set it to. I think this determinism can be a useful feature for testing, and making it an offset of the current system time will eliminate the determinism.

Can we work around this problem differently in the tests? I don't actually understand why the time would need to advance but I haven't yet poked into the problems you ran into. But for instance, one workaround I've used in tests I've previously written is to just mine a single block at the beginning of the test to ensure that the nodes are out of IBD (I recognize this workaround may not easily apply to all testing scenarios though).

Member

sdaftuar commented Dec 5, 2015

I like the overall goal here, but I'm not sure I follow the reasoning for changing the behavior of SetMockTime. One advantage of the way mocktime works now is that for the places in the code that call GetTime(), the behavior is deterministic -- the time will always be whatever the last mocktime call set it to. I think this determinism can be a useful feature for testing, and making it an offset of the current system time will eliminate the determinism.

Can we work around this problem differently in the tests? I don't actually understand why the time would need to advance but I haven't yet poked into the problems you ran into. But for instance, one workaround I've used in tests I've previously written is to just mine a single block at the beginning of the test to ensure that the nodes are out of IBD (I recognize this workaround may not easily apply to all testing scenarios though).

@ptschip

This comment has been minimized.

Show comment
Hide comment
@ptschip

ptschip Dec 5, 2015

Contributor

Mocktime needs to advance otherwise banning and unbanning doesn't work
so scripts such as nodehandling end up failing. I think having mocktime
advance, gives us a more realisitic functionality for testing as it
behaves in the same way as the application does in the real world.

On 05/12/2015 6:40 AM, Suhas Daftuar wrote:

I like the overall goal here, but I'm not sure I follow the reasoning
for changing the behavior of |SetMockTime|. One advantage of the way
mocktime works now is that for the places in the code that call
|GetTime()|, the behavior is deterministic -- the time will always be
whatever the last mocktime call set it to. I think this determinism
can be a useful feature for testing, and making it an offset of the
current system time will eliminate the determinism.

Can we work around this problem differently in the tests? I don't
actually understand why the time would need to advance but I haven't
yet poked into the problems you ran into. But for instance, one
workaround I've used in tests I've previously written is to just mine
a single block at the beginning of the test to ensure that the nodes
are out of IBD (I recognize this workaround may not easily apply to
all testing scenarios though).


Reply to this email directly or view it on GitHub
#7164 (comment).

Contributor

ptschip commented Dec 5, 2015

Mocktime needs to advance otherwise banning and unbanning doesn't work
so scripts such as nodehandling end up failing. I think having mocktime
advance, gives us a more realisitic functionality for testing as it
behaves in the same way as the application does in the real world.

On 05/12/2015 6:40 AM, Suhas Daftuar wrote:

I like the overall goal here, but I'm not sure I follow the reasoning
for changing the behavior of |SetMockTime|. One advantage of the way
mocktime works now is that for the places in the code that call
|GetTime()|, the behavior is deterministic -- the time will always be
whatever the last mocktime call set it to. I think this determinism
can be a useful feature for testing, and making it an offset of the
current system time will eliminate the determinism.

Can we work around this problem differently in the tests? I don't
actually understand why the time would need to advance but I haven't
yet poked into the problems you ran into. But for instance, one
workaround I've used in tests I've previously written is to just mine
a single block at the beginning of the test to ensure that the nodes
are out of IBD (I recognize this workaround may not easily apply to
all testing scenarios though).


Reply to this email directly or view it on GitHub
#7164 (comment).

@ptschip

This comment has been minimized.

Show comment
Hide comment
@ptschip

ptschip Dec 5, 2015

Contributor

@sdaftuar Thinking about this some more perhaps you are right, but maybe we can have both. We can have the mocktime we have now and also have a mocktime that will advance for those that need it. It would certainly be easier than having to fix up these python scripts.

Contributor

ptschip commented Dec 5, 2015

@sdaftuar Thinking about this some more perhaps you are right, but maybe we can have both. We can have the mocktime we have now and also have a mocktime that will advance for those that need it. It would certainly be easier than having to fix up these python scripts.

@ptschip

This comment has been minimized.

Show comment
Hide comment
@ptschip

ptschip Dec 5, 2015

Contributor

@sdaftuar And then if we go with a more complex mocktime it probably needs to be in a separate PR. I think I'm going to go back to the way the original mocktime was and see if I can get that nodehandling script to work. That would be much simpler and more within the scope of this PR.

Contributor

ptschip commented Dec 5, 2015

@sdaftuar And then if we go with a more complex mocktime it probably needs to be in a separate PR. I think I'm going to go back to the way the original mocktime was and see if I can get that nodehandling script to work. That would be much simpler and more within the scope of this PR.

@ptschip

This comment has been minimized.

Show comment
Hide comment
@ptschip

ptschip Dec 6, 2015

Contributor

@laanwj @sdaftuar I reverted back to the original mocktime which doesn't increment GetTime(). Instead, I made edits to a few of the python scripts to get them to work with mocktime and checked both the regular and extended scripts to make sure they all work. Pushed and Travis is happy.

Perhaps in the future we should have a mocktime that is both deterministic as well as one that allows GetTime() to increment. I think having a more realistic test scenario is always best but I agree with @sdaftuar that we need to keep the current deterministic behavior of mocktime as well.

Contributor

ptschip commented Dec 6, 2015

@laanwj @sdaftuar I reverted back to the original mocktime which doesn't increment GetTime(). Instead, I made edits to a few of the python scripts to get them to work with mocktime and checked both the regular and extended scripts to make sure they all work. Pushed and Travis is happy.

Perhaps in the future we should have a mocktime that is both deterministic as well as one that allows GetTime() to increment. I think having a more realistic test scenario is always best but I agree with @sdaftuar that we need to keep the current deterministic behavior of mocktime as well.

@jtimon

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Dec 6, 2015

Member

It seems reasonable to have 2 different setmocktime functions if they're both useful for testing.

Member

jtimon commented Dec 6, 2015

It seems reasonable to have 2 different setmocktime functions if they're both useful for testing.

@MarcoFalke

This comment has been minimized.

Show comment
Hide comment
@MarcoFalke

MarcoFalke Dec 6, 2015

Member

utACK 233fe56

Member

MarcoFalke commented Dec 6, 2015

utACK 233fe56

@sdaftuar

This comment has been minimized.

Show comment
Hide comment
@sdaftuar

sdaftuar Dec 6, 2015

Member

@ptschip I agree that an advancing mocktime can be useful too, and yeah probably makes sense to add that support in a separate PR.

I'm not sure it's a good idea for the default test-framework behavior to be to enable mocktime for all tests (which changes the behavior of the code being tested). I guess the issue is that if you're using initialize_chain which can give you an old cached datadir, then you probably want a mocktime that goes with it? Many of the tests now use initialize_chain_clean to avoid the issue of an old blockchain, and I think for tests that don't need to use a mocktime (because of the way they are written) it'd be best to not change the behavior they're testing by introducing use of mocktime.

It looks like running bitcoind with a mocktime of 0 is a no-op, so could we do something where the default mocktime used by start_node is only set to a non-zero value if the code that tries to generate a cached datadir is invoked?

Member

sdaftuar commented Dec 6, 2015

@ptschip I agree that an advancing mocktime can be useful too, and yeah probably makes sense to add that support in a separate PR.

I'm not sure it's a good idea for the default test-framework behavior to be to enable mocktime for all tests (which changes the behavior of the code being tested). I guess the issue is that if you're using initialize_chain which can give you an old cached datadir, then you probably want a mocktime that goes with it? Many of the tests now use initialize_chain_clean to avoid the issue of an old blockchain, and I think for tests that don't need to use a mocktime (because of the way they are written) it'd be best to not change the behavior they're testing by introducing use of mocktime.

It looks like running bitcoind with a mocktime of 0 is a no-op, so could we do something where the default mocktime used by start_node is only set to a non-zero value if the code that tries to generate a cached datadir is invoked?

@sdaftuar

This comment has been minimized.

Show comment
Hide comment
@sdaftuar

sdaftuar Dec 6, 2015

Member

I think another option would be to just have the tests that don't need to use mocktime change their invocations of start_node to include -mocktime=0 as one of the arguments to bitcoind. That should override the argument that's being added to util.py, and the test writer is likely aware if they're not using the cached directory.

If others are fine with an extra argument being needed to avoid invoking mocktime that is fine with me, but I do think we should go back and make sure that we're only using non-zero mocktimes on the tests that need them.

Member

sdaftuar commented Dec 6, 2015

I think another option would be to just have the tests that don't need to use mocktime change their invocations of start_node to include -mocktime=0 as one of the arguments to bitcoind. That should override the argument that's being added to util.py, and the test writer is likely aware if they're not using the cached directory.

If others are fine with an extra argument being needed to avoid invoking mocktime that is fine with me, but I do think we should go back and make sure that we're only using non-zero mocktimes on the tests that need them.

@jtimon

This comment has been minimized.

Show comment
Hide comment
@jtimon

jtimon Dec 6, 2015

Member

As said, having 2 mocktime functions may be useful, but I completely agree with not using it in the tests that don't need it. I think being explicit in the tests you need it may be more verbose than having it set implicitly for all tests, but is also clearer and more easily modifiable (if "explicit is better than implicit" is not enough).

Member

jtimon commented Dec 6, 2015

As said, having 2 mocktime functions may be useful, but I completely agree with not using it in the tests that don't need it. I think being explicit in the tests you need it may be more verbose than having it set implicitly for all tests, but is also clearer and more easily modifiable (if "explicit is better than implicit" is not enough).

@ptschip

This comment has been minimized.

Show comment
Hide comment
@ptschip

ptschip Dec 6, 2015

Contributor

On 06/12/2015 3:02 AM, Suhas Daftuar wrote:

I think another option would be to just have the tests that don't need
to use mocktime change their invocations of start_node to include
|-mocktime=0| as one of the arguments to bitcoind. That should
override the argument that's being added to |util.py|,

Yes, you can override mocktime in that way. In fact I had to do that in
the maxuploadtarget.py to get it to work, although in that case I had to
start_node with mocktime set to the current time, but it does work if
one wants to use it that way. So for now I would think that would be
sufficient for those that don't want to use mocktime in their scripting?

Contributor

ptschip commented Dec 6, 2015

On 06/12/2015 3:02 AM, Suhas Daftuar wrote:

I think another option would be to just have the tests that don't need
to use mocktime change their invocations of start_node to include
|-mocktime=0| as one of the arguments to bitcoind. That should
override the argument that's being added to |util.py|,

Yes, you can override mocktime in that way. In fact I had to do that in
the maxuploadtarget.py to get it to work, although in that case I had to
start_node with mocktime set to the current time, but it does work if
one wants to use it that way. So for now I would think that would be
sufficient for those that don't want to use mocktime in their scripting?

@ptschip

This comment has been minimized.

Show comment
Hide comment
@ptschip

ptschip Dec 6, 2015

Contributor

Another simple solution for those that don't want to use or need to use
mocktime in their scripts is simply to set MOCKTIME=0 at the very
beginning.

On 06/12/2015 3:02 AM, Suhas Daftuar wrote:

I think another option would be to just have the tests that don't need
to use mocktime change their invocations of start_node to include
|-mocktime=0| as one of the arguments to bitcoind. That should
override the argument that's being added to |util.py|, and the test
writer is likely aware if they're not using the cached directory.

If others are fine with an extra argument being needed to avoid
invoking mocktime that is fine with me, but I do think we should go
back and make sure that we're only using non-zero mocktimes on the
tests that need them.


Reply to this email directly or view it on GitHub
#7164 (comment).

Contributor

ptschip commented Dec 6, 2015

Another simple solution for those that don't want to use or need to use
mocktime in their scripts is simply to set MOCKTIME=0 at the very
beginning.

On 06/12/2015 3:02 AM, Suhas Daftuar wrote:

I think another option would be to just have the tests that don't need
to use mocktime change their invocations of start_node to include
|-mocktime=0| as one of the arguments to bitcoind. That should
override the argument that's being added to |util.py|, and the test
writer is likely aware if they're not using the cached directory.

If others are fine with an extra argument being needed to avoid
invoking mocktime that is fine with me, but I do think we should go
back and make sure that we're only using non-zero mocktimes on the
tests that need them.


Reply to this email directly or view it on GitHub
#7164 (comment).

@laanwj

This comment has been minimized.

Show comment
Hide comment
@laanwj

laanwj Dec 7, 2015

Member

Changing nmaxtipage certainly is an easy fix but I never like the idea of changing the behaviour of an app before regression testing

I tend to agree. I also think the max tip age should never have been a chain parameter in the first place, but an option separately specified.

I like the new approach.

Edit: simulated time in tests is great, if it avoids sleep()s it speeds up the tests!

Member

laanwj commented Dec 7, 2015

Changing nmaxtipage certainly is an easy fix but I never like the idea of changing the behaviour of an app before regression testing

I tend to agree. I also think the max tip age should never have been a chain parameter in the first place, but an option separately specified.

I like the new approach.

Edit: simulated time in tests is great, if it avoids sleep()s it speeds up the tests!

@pstratem

This comment has been minimized.

Show comment
Hide comment
@pstratem

pstratem Dec 8, 2015

Contributor

@ptschip please do the mocktime fix as a separate commit possibly even a separate pr? (someone argue with me on that))

Contributor

pstratem commented Dec 8, 2015

@ptschip please do the mocktime fix as a separate commit possibly even a separate pr? (someone argue with me on that))

@ptschip

This comment has been minimized.

Show comment
Hide comment
@ptschip

ptschip Dec 8, 2015

Contributor

@pstratem I already had taken the changes out of GetTime() and mocktime , reverting back to the current master branch version, and only updated the py scripts.instead so that they use mocktime correctly. The py scripts need those changes otherwise this PR will break them.

I have no additional changes to this PR, I think it's complete.

Contributor

ptschip commented Dec 8, 2015

@pstratem I already had taken the changes out of GetTime() and mocktime , reverting back to the current master branch version, and only updated the py scripts.instead so that they use mocktime correctly. The py scripts need those changes otherwise this PR will break them.

I have no additional changes to this PR, I think it's complete.

@laanwj laanwj merged commit 39a525c into bitcoin:master Jan 19, 2016

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

laanwj added a commit that referenced this pull request Jan 19, 2016

Merge pull request #7164: Do not download transactions during initial…
… blockchain sync

39a525c Do not download transactions during inital sync (ptschip)

@ptschip ptschip deleted the ptschip:tx_getdata branch Apr 5, 2016

MarcoFalke added a commit to MarcoFalke/bitcoin that referenced this pull request Apr 27, 2016

@MarcoFalke

This comment has been minimized.

Show comment
Hide comment
@MarcoFalke

MarcoFalke Jun 9, 2016

Member

Backported as part of #7938. Removing label 'Needs backport'.

Member

MarcoFalke commented Jun 9, 2016

Backported as part of #7938. Removing label 'Needs backport'.

thokon00 added a commit to faircoin/faircoin that referenced this pull request Jun 28, 2016

nomnombtc added a commit to nomnombtc/bitcoin that referenced this pull request Nov 12, 2016

nomnombtc added a commit to nomnombtc/bitcoin that referenced this pull request Nov 12, 2016

nomnombtc added a commit to nomnombtc/bitcoin that referenced this pull request Nov 13, 2016

@dgenr8 dgenr8 referenced this pull request Jan 8, 2017

Merged

Cherries #184

deadalnix added a commit to deadalnix/bitcoin that referenced this pull request Jan 11, 2017

Make max tip age an option instead of chainparam
After discussion in bitcoin#7164 I think this is better.

Max tip age was introduced in bitcoin#5987 to make it possible to run
testnet-in-a-box. But associating this behavior with the testnet chain
is wrong conceptually, as it is not needed in normal usage.
Should aim to make testnet test the software as-is.

Replace it with a (debug) option `-maxtipage`, which can be
specified only in the specific case.

deadalnix added a commit to deadalnix/bitcoin that referenced this pull request Jan 11, 2017

Make max tip age an option instead of chainparam
After discussion in bitcoin#7164 I think this is better.

Max tip age was introduced in bitcoin#5987 to make it possible to run
testnet-in-a-box. But associating this behavior with the testnet chain
is wrong conceptually, as it is not needed in normal usage.
Should aim to make testnet test the software as-is.

Replace it with a (debug) option `-maxtipage`, which can be
specified only in the specific case.

deadalnix added a commit to deadalnix/bitcoin that referenced this pull request Jan 15, 2017

Make max tip age an option instead of chainparam
After discussion in bitcoin#7164 I think this is better.

Max tip age was introduced in bitcoin#5987 to make it possible to run
testnet-in-a-box. But associating this behavior with the testnet chain
is wrong conceptually, as it is not needed in normal usage.
Should aim to make testnet test the software as-is.

Replace it with a (debug) option `-maxtipage`, which can be
specified only in the specific case.

deadalnix added a commit to deadalnix/bitcoin that referenced this pull request Jan 16, 2017

Make max tip age an option instead of chainparam
After discussion in bitcoin#7164 I think this is better.

Max tip age was introduced in bitcoin#5987 to make it possible to run
testnet-in-a-box. But associating this behavior with the testnet chain
is wrong conceptually, as it is not needed in normal usage.
Should aim to make testnet test the software as-is.

Replace it with a (debug) option `-maxtipage`, which can be
specified only in the specific case.

deadalnix added a commit to deadalnix/bitcoin that referenced this pull request Jan 17, 2017

Make max tip age an option instead of chainparam
After discussion in bitcoin#7164 I think this is better.

Max tip age was introduced in bitcoin#5987 to make it possible to run
testnet-in-a-box. But associating this behavior with the testnet chain
is wrong conceptually, as it is not needed in normal usage.
Should aim to make testnet test the software as-is.

Replace it with a (debug) option `-maxtipage`, which can be
specified only in the specific case.

deadalnix added a commit to deadalnix/bitcoin that referenced this pull request Jan 19, 2017

Make max tip age an option instead of chainparam
After discussion in bitcoin#7164 I think this is better.

Max tip age was introduced in bitcoin#5987 to make it possible to run
testnet-in-a-box. But associating this behavior with the testnet chain
is wrong conceptually, as it is not needed in normal usage.
Should aim to make testnet test the software as-is.

Replace it with a (debug) option `-maxtipage`, which can be
specified only in the specific case.

deadalnix added a commit to deadalnix/bitcoin that referenced this pull request Jan 19, 2017

Make max tip age an option instead of chainparam
After discussion in bitcoin#7164 I think this is better.

Max tip age was introduced in bitcoin#5987 to make it possible to run
testnet-in-a-box. But associating this behavior with the testnet chain
is wrong conceptually, as it is not needed in normal usage.
Should aim to make testnet test the software as-is.

Replace it with a (debug) option `-maxtipage`, which can be
specified only in the specific case.

deadalnix added a commit to deadalnix/bitcoin that referenced this pull request Jan 19, 2017

Make max tip age an option instead of chainparam
After discussion in bitcoin#7164 I think this is better.

Max tip age was introduced in bitcoin#5987 to make it possible to run
testnet-in-a-box. But associating this behavior with the testnet chain
is wrong conceptually, as it is not needed in normal usage.
Should aim to make testnet test the software as-is.

Replace it with a (debug) option `-maxtipage`, which can be
specified only in the specific case.

deadalnix added a commit to deadalnix/bitcoin that referenced this pull request Jan 26, 2017

Make max tip age an option instead of chainparam
After discussion in bitcoin#7164 I think this is better.

Max tip age was introduced in bitcoin#5987 to make it possible to run
testnet-in-a-box. But associating this behavior with the testnet chain
is wrong conceptually, as it is not needed in normal usage.
Should aim to make testnet test the software as-is.

Replace it with a (debug) option `-maxtipage`, which can be
specified only in the specific case.

deadalnix added a commit to deadalnix/bitcoin that referenced this pull request Feb 12, 2017

Make max tip age an option instead of chainparam
After discussion in bitcoin#7164 I think this is better.

Max tip age was introduced in bitcoin#5987 to make it possible to run
testnet-in-a-box. But associating this behavior with the testnet chain
is wrong conceptually, as it is not needed in normal usage.
Should aim to make testnet test the software as-is.

Replace it with a (debug) option `-maxtipage`, which can be
specified only in the specific case.

deadalnix added a commit to deadalnix/bitcoin that referenced this pull request Feb 27, 2017

Make max tip age an option instead of chainparam
After discussion in bitcoin#7164 I think this is better.

Max tip age was introduced in bitcoin#5987 to make it possible to run
testnet-in-a-box. But associating this behavior with the testnet chain
is wrong conceptually, as it is not needed in normal usage.
Should aim to make testnet test the software as-is.

Replace it with a (debug) option `-maxtipage`, which can be
specified only in the specific case.

deadalnix added a commit to deadalnix/bitcoin that referenced this pull request Feb 27, 2017

Make max tip age an option instead of chainparam
After discussion in bitcoin#7164 I think this is better.

Max tip age was introduced in bitcoin#5987 to make it possible to run
testnet-in-a-box. But associating this behavior with the testnet chain
is wrong conceptually, as it is not needed in normal usage.
Should aim to make testnet test the software as-is.

Replace it with a (debug) option `-maxtipage`, which can be
specified only in the specific case.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment