1 2017-12-02 00:39:33 0|luke-jr|jimpo: likely they're never linked together.. test_bitcoin_main would be linked into test_bitcoin, and init.cpp into bitcoind/bitcoin-qt
2 2017-12-02 00:50:27 0|Cooper_|Hey y'all.
3 2017-12-02 00:57:45 0|jimpo|luke-jr: That makes sense conceptually, but I don't understand make tools well enough to understand why. From what is looks like here, https://github.com/bitcoin/bitcoin/blob/master/src/Makefile.test.include#L105, the test is linked against the LIBBITCOIN_SERVER sources, which includes init.cpp.
4 2017-12-02 01:56:01 0|jimpo|I figured it out. I added a definition of a new global to init.cpp and didn't add to test/test_bitcoin_main.cpp, which forced init.cpp to get linked and caused the conflict. Feels a little brittle to me, but it's easy to work around.
5 2017-12-02 07:43:53 0|wumpus|right, to be clear I certainly think the current testnet should stay, to test miners and as a 'wildtestnet'. If anything more reliable is introduced it should not replace it but be a choice.
6 2017-12-02 07:44:27 0|Randolf|That seems reasonable.
7 2017-12-02 08:56:04 0|sipa|wildnet!
8 2017-12-02 09:06:28 0|wumpus|sipa: Provoostenator came with that I think it' great
9 2017-12-02 09:07:14 0|sipa|ha
10 2017-12-02 09:08:39 0|wumpus|a reliable testnet would be more like a simnet
11 2017-12-02 09:08:54 0|wumpus|simulate circumstances on the real chain
12 2017-12-02 11:07:39 0|gmaxwell|the more stable thing I think would be interesting to do is a singned block testnet where it accepts two keys and there is a regular standard parttern of reorgs that it does, and if you don't want to see the reorgs, you change your settings to ignore one of the keys, which is the one used for blocks which are going to get reorged out. Unfortunately, the signed block approach used in elements at
13 2017-12-02 11:07:45 0|gmaxwell|least makes the blockindex datastructures in memory larger... so they'd be ugly to have for us because the same binary is testnet and mainnet. :(
14 2017-12-02 11:08:04 0|gmaxwell|We could, of course, have a seperate build for this signed block testnet, but I think that would make it less accessible and useful.
15 2017-12-02 11:35:28 0|wumpus|indeed, doing a predictable cycle of reorgs makes sense, otherwise it's not much of a test
16 2017-12-02 11:36:19 0|wumpus|within the limits of what is realistically encountered on mainnet
17 2017-12-02 11:36:53 0|wumpus|yes, that's what I don't like, the same code is used on mainnet and testnet and this would add extra overhead, as well as more potentially buggy code inthe consensus path
18 2017-12-02 11:37:33 0|wumpus|the only way around that would be to template all the code which is not a simple change either :/
19 2017-12-02 11:38:43 0|wumpus|this really needs to be zero overhead for the mainnet case
20 2017-12-02 11:44:01 0|gmaxwell|I suspect it probably could be done with no runtime overhead, but some lack of cleanness (like having to turn one of the fields in the block index into a union).
21 2017-12-02 16:21:01 0|webuser323|Just wondering if this is relevant bitcoin-core: https://github.com/google/oss-fuzz/
22 2017-12-02 16:27:14 0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #11817: [tests] Change bip68-112-113-p2p to use BitcoinTestFramework (06master...06refactor_bip68-112-113-p2p) 02 https://github.com/bitcoin/bitcoin/pull/11817
23 2017-12-02 16:35:41 0|webuser323|pinging wumpus, maybe worth adding the project there, the trophy list is very impressive!
24 2017-12-02 19:08:20 0|meshcollider|webuser323: OSS-fuzz was discussed in #11045, you might want to check that out :)
25 2017-12-02 19:08:22 0|gribble|https://github.com/bitcoin/bitcoin/issues/11045 | Offering my Bitcoin fuzzers ÷ Issue #11045 ÷ bitcoin/bitcoin ÷ GitHub