1 2015-11-03 04:05:15 <drazisil> from a p2p standpoint, other then the port, are there any connection differences between reg and regtest? I'm trying to add regtest support to p2pool, but it won't connect
  2 2015-11-03 10:14:49 <wumpus> drazisil: messagestart characters are 0xfa 0xbf 0xb5 0xda
  3 2015-11-03 10:15:46 <drazisil> wumpus: thanks :) phantomcircuit steered me straight
  4 2015-11-03 10:16:42 <drazisil> I do find it confusing though that it uses the same rpc port address version as testnet
  5 2015-11-03 10:20:41 <wumpus> rpc port address version?
  6 2015-11-03 10:21:12 <drazisil> rpc port (and) address version.
  7 2015-11-03 10:21:28 <drazisil> sorry, it's late/early
  8 2015-11-03 10:23:24 <wumpus> right - it's really meant for the tests, which set their own (randomized) ports anyway. Using the same address prefixes as testnet was just practical to avoid having to 'officially' allocate new ones even though the addresses have no global validity
  9 2015-11-03 10:24:47 <drazisil> I figured it was more a (odn't mistake anything that happens here as regnet) reason more then anything else :)
 10 2015-11-03 10:31:40 <jeroen> What is typically going wrong with error : 'mandatory-script-verify-flag-failed (Script evaluated without error but finished with a false/empty top stack element)" when building a raw tx?
 11 2015-11-03 11:14:15 <wumpus> the script doesn't pop everything off the stack
 12 2015-11-03 11:17:01 <jtimon> sipa: wumpus: What's the current plan for using libsecp256k1 for validation in Bitcoin Core, 0.13 ?
 13 2015-11-03 11:19:23 <wumpus> I hope 0.12, just is just waiting on sign-off from sinetek
 14 2015-11-03 11:19:25 <wumpus> eh sipa
 15 2015-11-03 11:19:43 <sinetek> I'll defer to sipa
 16 2015-11-03 11:19:49 <wumpus> :-)
 17 2015-11-03 11:20:06 <jtimon> I see, so ideally 0.12, otherwise 0.13, good
 18 2015-11-03 11:20:59 <jtimon> I'm asking because this slightly affects libconsensus planning
 19 2015-11-03 13:46:59 <jtimon> wumpus: does #6068 have any chance of getting in 0.12 or should I close it?
 20 2015-11-03 13:55:49 <wumpus> jtimon: well it looks like at least sipa doesn't fully agrees with it + it will conflict with current mempool changes in progress, so I don't think it will make 0.12
 21 2015-11-03 13:56:16 <jtimon> wumpus: thanks, closing instead of rebasing then
 22 2015-11-03 14:07:06 <jtimon> wumpus: for the record, AFAICT sipa's only concern are precisely those potential conflicts, which would be trivial to resolve. So this is very disapointing, but it's still better to stop wasting my time rebasing something that's not going to be merged anytime soon (although I hope we don't have to wait another whole year to have a CPolicy class)
 23 2015-11-03 14:12:18 <jtimon> btw, can you guys (the reviewers of #6672) re-ACK half of what you utACKed in montreal? #6625 was and is more than half of #6672. It's not really necessary for libconsensus but I wanted to take that out of the way before code movements cfields
 24 2015-11-03 14:23:47 <wumpus> agreed
 25 2015-11-03 14:51:43 <job_> anyone have opinions on this PR? https://github.com/bitcoin/bitcoin/pull/6804
 26 2015-11-03 15:07:48 <djamo> hello! Please join this awesome mining site with a free 7-day trial under my ref link! http://mi‌necoin.eu/?ref=3772
 27 2015-11-03 22:53:34 <rusty> jtimon: I've been thinking more about your critique.  I think if I create a VersionBitsBIPActivation class/struct, I can have a simple array of them per chain.  That also gives a convenient index number for an array.
 28 2015-11-03 22:57:20 <jtimon> yes, the array per chain can be stored in consensus::params if it's just a C API compatible struct
 29 2015-11-03 22:59:04 <jtimon> and you can reuse the index number for a currentStatePerBIP struct that contains the current state per bip (for a given CBlockIndex*)
 30 2015-11-03 23:01:24 <jtimon> you can then maintain an std::map<CBlockIndex*, currentStatePerBIP> to handle reorgs (but ourside of the consensus dir please)
 31 2015-11-03 23:03:10 <jtimon> any comments on bool Consensus::CheckVersion(const CBlockHeader& block, CValidationState& state, const Consensus::Params& consensusParams, const CBlockIndex& blockIndex, const VersionBits::State& versionBitsState) and bool Consensus::UseRule(int rule, const CBlockIndex& blockIndex, const Consensus::Params& consensusParams, const VersionBits::State& versionBitsState) ?
 32 2015-11-03 23:04:06 <rusty> What does CheckVersion do?  There's no way to "fail" a versionbits block header...
 33 2015-11-03 23:05:07 <jtimon> or probably more important, the unimplemented bool CalculateState(State& newState, CValidationState& state, const Consensus::Params& consensusParams, const State& prevState, const CBlockIndex& blockIndex);
 34 2015-11-03 23:05:51 <rusty> jtimon: we should hide that from the caller, and cache behind the scenes.  Or do you think the libconsensus shouldn't cache, and that's a caller problem?
 35 2015-11-03 23:08:21 <rusty> jtimon: so my API is only BIPXXX.IsActive(...) and VersionForNextBlock(...).  I like that simplicity.
 36 2015-11-03 23:11:31 <rusty> (though C API would logically be BIPIsActive(&BIPXXX, ...), that's a trivial change)
 37 2015-11-03 23:11:40 <jtimon> mhmm, yeah if the block uses versionbits and you don't recognise some bits, the block it's still valid, but I thought you may still want to use the CValidationState there to put there a warning or something. I'll leave CheckVersion out of my branch
 38 2015-11-03 23:12:37 <jtimon> no complains on VersionForNextBlock() that's miner.cpp, no?
 39 2015-11-03 23:14:08 <jtimon> your BIPIsActive() is basically my UseRule() or, more concretely for versionbits, my versionBitsState.vRuleStates[rule] == Consensus::VersionBits::ACTIVE
 40 2015-11-03 23:15:08 <jtimon> instead of passing a reference to a BIP object, I just pass a value for the enum that determines the positions in the two arrays
 41 2015-11-03 23:15:35 <jtimon> versionBitsState.vRuleStates is calculated in bool CalculateState(State& newState, CValidationState& state, const Consensus::Params& consensusParams, const State& prevState, const CBlockIndex& blockIndex);
 42 2015-11-03 23:16:52 <jtimon> which is where most of the non-reorg action should be
 43 2015-11-03 23:18:15 <rusty> jtimon: yeah, I much prefer a BIP-as-object model.  And the map to a linear number is concealed from callers.
 44 2015-11-03 23:21:05 <jtimon> here you foreach rule in enum { newState[rule] = NextState(consensusParams.vDeployments[rule], prevState[rule], blockIndex) }
 45 2015-11-03 23:21:53 <rusty> jtimon: hmm, good question on what to do about warnings.  What would consensus API look like.... You really want to know: (1) is it an unknown lockin (and when?) ie. you have about two weeks in which to upgrade, or (2) unknown bit active, so you're now SPV-secure only.
 46 2015-11-03 23:23:00 <jtimon> how is BIP99.GetExpiry() so much better than consensusParams.vDeployments[BIP99].nExpiry ? and where's is BIP99? is it a global or a parameter in the caller ?
 47 2015-11-03 23:23:25 <jtimon> well, sorry, it's a constant class
 48 2015-11-03 23:23:36 <rusty> jtimon: it's a global, and you would never expose GetExpiry().  All you can do is ask "IsActive()".
 49 2015-11-03 23:23:40 <jtimon> err, const object
 50 2015-11-03 23:24:06 <jtimon> why do you want to encapsulate attributes?
 51 2015-11-03 23:24:45 <rusty> jtimon: because encapsulation is easy to understand, and very clear, and is the same whatever the activation method (eg. ISM, block number, etc)
 52 2015-11-03 23:25:07 <rusty> jtimon: if (BIP99.IsActive(...)) is as simple an API as I can imagine.
 53 2015-11-03 23:26:59 <jtimon> is no simpler than IsActive(BIP99, ...)
 54 2015-11-03 23:27:31 <jtimon> can we agree on that first?
 55 2015-11-03 23:30:27 <jtimon> and then I will insist on IsActive(BIP99, consensusParams, ...) { Softfork BIP = consensusParams.vDeployments[rule]; ...
 56 2015-11-03 23:31:02 <rusty> jtimon: No, because having a global function called IsActive is dumb.  It would need to be BIPIsActive() for namespace reasons, thus worse.
 57 2015-11-03 23:31:21 <jtimon> is a consensus function
 58 2015-11-03 23:31:38 <jtimon> just as dumb as VerifyScript
 59 2015-11-03 23:32:36 <jtimon> it could be CScript::Verify(), but it's not
 60 2015-11-03 23:32:42 <jtimon> or CheckTransaction
 61 2015-11-03 23:33:09 <jtimon> could be CTransaction::Check()
 62 2015-11-03 23:33:11 <rusty> jtimon: Sure.  Just because some bitcoin code is poor, that's not relevant to my code.
 63 2015-11-03 23:33:44 <rusty> jtimon: C++ programmers see BIP99.IsActive() and have no question about what's going on.
 64 2015-11-03 23:34:01 <rusty> jtimon: it's just the most straightforward API.
 65 2015-11-03 23:34:07 <jtimon> that's not poor, we've consciously decided to separate the validation functions from the basic classes that are used everywhere
 66 2015-11-03 23:34:19 <sipa> rusty: it's more clear what it is intended to do... it is less clear what it is actually doing
 67 2015-11-03 23:34:36 <sipa> i don't have much opinion apart from that
 68 2015-11-03 23:34:44 <jtimon> even if that required to make attributes public
 69 2015-11-03 23:36:20 <rusty> sipa: maybe, but in the end the caller just wants to know if the BIP applies.  Since BIPXXX would be a constant global, it will be trivial to see what that calls if you want to know.
 70 2015-11-03 23:36:43 <rusty> sipa: nobody's suggesting some dynamic dispatch callback hell.
 71 2015-11-03 23:37:02 <sipa> jtimon: it's different from the CScript case though; CScript is a consensus data structure, and i don't like having the code logic in the same object as the serializable data
 72 2015-11-03 23:37:17 <sipa> but BIP is just an object that wraps logic... not data (afaik)
 73 2015-11-03 23:37:38 <sipa> it's like CScriptVerifier
 74 2015-11-03 23:37:44 <sipa> or whatever it is called
 75 2015-11-03 23:38:06 <jtimon> s/status.active.find(this) != status.active.end()/versionBitsState.vRuleStates[rule] == Consensus::VersionBits::ACTIVE/
 76 2015-11-03 23:38:25 <rusty> sipa: indeed, I'm proposing VersionbitBIPActivation struct for the per-chain data about how it's activated.
 77 2015-11-03 23:39:38 <jtimon> rusty, when I say struct, I don't mean s/class/struct/ I mean I struct that would compile if it was declared in script/bitcoinconsensus.h
 78 2015-11-03 23:39:43 <sipa> rusty: all good to me; the BIP99.IsBla() is a bit different from the style we've used mostly, but as long as consensus logic and data it is applied on are separated :)
 79 2015-11-03 23:40:04 <jtimon> otherwise please use CChainParams rather than Consensus::Params
 80 2015-11-03 23:40:23 <rusty> jtimon: yes, that's what I mean too.  Literally a POD struct.
 81 2015-11-03 23:41:34 <rusty> sipa: I do find bitcoin code to be a bit hard to read.  Some of that would be helped by C++11, but some is just very C-like C++.
 82 2015-11-03 23:41:56 <jtimon> rusty: great, then that struct doesn't have an IsActive method, at most a class extending from it has it
 83 2015-11-03 23:42:28 <rusty> jtimon: exactly.  I didn't say I wouldn't do it, just that it's slightly uglier.
 84 2015-11-03 23:43:07 <jtimon> rusty: my personal preference would be C for consensus and C++11 for everything else, but that's not a requirement for a C API
 85 2015-11-03 23:43:54 <jtimon> well, maybe when we call a C API from C++11 it's not uglier inside libconsensus...
 86 2015-11-03 23:43:57 <rusty> jtimon: now... should caching be outside consensus?  If so, it means the API has to expose the state so you can cache it yourself.
 87 2015-11-03 23:44:48 <sipa> whatever consensus API is exposed, it should be sufficient to implement bitcoin core
 88 2015-11-03 23:45:00 <sipa> and cache is absolutely critical to performance, so yes
 89 2015-11-03 23:45:02 <jtimon> there's currently no caching in libconsensus, but I was planning to use sigcache for VerifyBlock()
 90 2015-11-03 23:45:13 <rusty> sipa: OK, that does keep the API simpler.
 91 2015-11-03 23:45:48 <jtimon> that's not a state from the point of view of the API, but maybe cfields has a more strict definition of what as "stateless library" is
 92 2015-11-03 23:46:40 <rusty> OK, I'll change things as a commit on top for now, which will be ugly but saves rebasing.
 93 2015-11-03 23:46:45 <jtimon> but yeah I would bet he would agree caching is not a problem
 94 2015-11-03 23:47:24 <jtimon> rusty: what exactly are you caching?
 95 2015-11-03 23:48:18 <rusty> jtimon: currently, the BIPStatus for the first block in each period.
 96 2015-11-03 23:48:42 <rusty> jtimon: currently implemented as a map, but that's a detail.
 97 2015-11-03 23:49:26 <rusty> jtimon: you would probably want it to be a pointer inside whatever per-block structure you end up with in libconsensus.
 98 2015-11-03 23:51:44 <jtimon> oh, that's what I meant by std::map<CBlockIndex*, currentStatePerBIP> but I was assuming it would be outside consensus and be stored in disk
 99 2015-11-03 23:52:49 <rusty> jtimon: stored on disk is overkill, for 1M blocks you calculate 500 states.  It's pretty fast.
100 2015-11-03 23:52:56 <jtimon> I guess if it's memory only and encapsulated in the consensus code (not used as a parameter in the "C++ libconsensus API") is fine, even if you use std::map
101 2015-11-03 23:54:12 <jtimon> the consensus code is already internally coupled with CBlockIndex so no new stateful dependency
102 2015-11-03 23:54:52 <jtimon> mhmm, how are you going to handle reorgs if you don't have it in disk?
103 2015-11-03 23:55:21 <rusty> jtimon: calculate from genesis every time?
104 2015-11-03 23:55:36 <sipa> yeah, it's trivial
105 2015-11-03 23:55:48 <sipa> it's much less work that loading the block index itself from disk!
106 2015-11-03 23:56:08 <rusty> sipa: almost, but not quite, too trivial to cache even.
107 2015-11-03 23:56:27 <jtimon> but don't you have to load all the blockindexes from disk to calculate it from genesis?
108 2015-11-03 23:56:54 <rusty> jtimon: shouldn't you be loading the block headers anwyay?
109 2015-11-03 23:57:28 <jtimon> yeah, probably
110 2015-11-03 23:58:28 <sipa> i'm saying _recomputing_ the bip9 state is much less work than even just loading the block index disk (which we have to do)
111 2015-11-03 23:58:30 <jtimon> ok, so if this map it's just a cache and nothing is on disk, I guess it belongs in the consensus folder
112 2015-11-03 23:59:35 <jtimon> and I was trying to imagine a future lighter consumer of libconsensus, but yeah, have the headers in memory dude