12016-10-23T00:19:25  *** aalex has quit IRC
  22016-10-23T00:25:04  *** kadoban has quit IRC
  32016-10-23T00:33:35  *** aalex has joined #bitcoin-core-dev
  42016-10-23T00:37:51  *** alpalp has quit IRC
  52016-10-23T00:39:36  *** aalex has quit IRC
  62016-10-23T00:43:26  *** aalex has joined #bitcoin-core-dev
  72016-10-23T00:50:17  *** jl2012 has quit IRC
  82016-10-23T00:55:54  *** jl2012 has joined #bitcoin-core-dev
  92016-10-23T00:57:58  <gmaxwell> 2016-10-23 00:57:16 - Disconnect block: 1651.55ms
 102016-10-23T00:59:23  *** Ylbam has quit IRC
 112016-10-23T01:02:19  *** Ylbam has joined #bitcoin-core-dev
 122016-10-23T01:02:59  *** alpalp has joined #bitcoin-core-dev
 132016-10-23T01:04:24  *** jl2012 has quit IRC
 142016-10-23T01:10:07  <gmaxwell> :( actually the disconnectblock message undersates it, seeing on a fast machine 97 seconds between update tips while disconnecting blocks.
 152016-10-23T01:10:15  *** jl2012 has joined #bitcoin-core-dev
 162016-10-23T01:14:51  *** alpalp has quit IRC
 172016-10-23T01:15:09  *** alpalp has joined #bitcoin-core-dev
 182016-10-23T01:15:16  <morcos> gmaxwell: yeah disconnects are slow..  but those are on my list once i'm done banging my head against a wall with connects...   i tried to look up that on my nodes and i didn't see one
 192016-10-23T01:16:07  <gmaxwell> I'm trying to roll back to a couple months ago for some tests.
 202016-10-23T01:16:47  <gmaxwell> and it's going to take hours. I'm not sure if we regressed or it's just increased load. It was always slow but when invalidate block was first written I tested it by reorging back all the way to the start... and I know it didn't take me months. :)
 212016-10-23T01:21:21  <sipa> 18:20:59 <sipa> for every undo that creates a UTXO that doesn't exist yet (because it's an undo of the last spend from one txid), it's trying to 'modify' that entry, looking for it on disk
 222016-10-23T01:21:25  <sipa> 18:21:14 <sipa> not realizing that it needs to create a new one, and thus can avoid the lookup
 232016-10-23T01:21:58  <sipa> so it causes on average 1 disk lookup for each txid being rolled back
 242016-10-23T01:22:04  <sipa> over long periods of time
 252016-10-23T01:24:24  <sipa> it would be an easy fix except for the fact that we want to use the more thorough current behaviour in the start-up consistency check (ah! that explains why that check is so slow as well...)
 262016-10-23T01:30:26  *** Giszmo has joined #bitcoin-core-dev
 272016-10-23T01:31:48  <gmaxwell> in addition to that it looks like it's spending most of its time twiddling with the mempool. setting the relay fee to 1btc/kb and the mempool size to minimum has it going fast.
 282016-10-23T01:32:12  <gmaxwell> not blindingly fast but fast enough that I wouldn't have commented (maybe 4 blocks per second or so)
 292016-10-23T01:32:39  <gmaxwell> sampling the backtrace seems to show a lot of it under UpdateForDescendants
 302016-10-23T01:40:23  *** laurentmt has joined #bitcoin-core-dev
 312016-10-23T01:40:45  <gmaxwell> so I have a node configured with connect=0 (what I've historically done when wanting no connections) and I see that it's managing to connect to itself over and over again...
 322016-10-23T01:40:49  <gmaxwell> 2016-10-23 01:40:11 trying connection 0 lastseen=0.0hrs
 332016-10-23T01:40:51  <gmaxwell> 2016-10-23 01:40:11 Added connection peer=721
 342016-10-23T01:40:54  <gmaxwell> 2016-10-23 01:40:11 Added connection peer=722
 352016-10-23T01:40:57  <gmaxwell> 2016-10-23 01:40:11 send version message: version 70014, blocks=435494, us=[::]:0, peer=721
 362016-10-23T01:41:00  <gmaxwell> 2016-10-23 01:40:11 connection from 127.0.0.1:53402 accepted
 372016-10-23T01:41:02  <gmaxwell> 2016-10-23 01:40:11 sending: version (103 bytes) peer=721
 382016-10-23T01:41:05  <gmaxwell> 2016-10-23 01:40:11 received: version (103 bytes) peer=722
 392016-10-23T01:41:07  <gmaxwell> 2016-10-23 01:40:11 connected to self at 127.0.0.1:53402, disconnecting
 402016-10-23T01:44:32  *** aalex has quit IRC
 412016-10-23T01:47:05  *** Ylbam has quit IRC
 422016-10-23T02:03:35  *** aalex has joined #bitcoin-core-dev
 432016-10-23T02:03:39  *** laurentmt has quit IRC
 442016-10-23T02:19:13  *** aalex has quit IRC
 452016-10-23T02:23:22  *** aalex has joined #bitcoin-core-dev
 462016-10-23T02:26:20  *** d_t has quit IRC
 472016-10-23T02:37:32  *** wasi has quit IRC
 482016-10-23T02:39:03  *** fengling has quit IRC
 492016-10-23T02:58:13  *** AtashiCon has joined #bitcoin-core-dev
 502016-10-23T03:09:11  *** wasi has joined #bitcoin-core-dev
 512016-10-23T03:09:21  *** cryptapus_afk has quit IRC
 522016-10-23T03:12:00  *** cryptapus has joined #bitcoin-core-dev
 532016-10-23T03:12:00  *** cryptapus has joined #bitcoin-core-dev
 542016-10-23T03:13:07  *** Alopex has quit IRC
 552016-10-23T03:14:12  *** Alopex has joined #bitcoin-core-dev
 562016-10-23T03:27:02  *** Alopex has quit IRC
 572016-10-23T03:28:07  *** Alopex has joined #bitcoin-core-dev
 582016-10-23T03:29:08  *** cryptapus is now known as cryptapus_afk
 592016-10-23T03:40:02  *** Alopex has quit IRC
 602016-10-23T03:41:07  *** Alopex has joined #bitcoin-core-dev
 612016-10-23T03:49:50  *** aalex has quit IRC
 622016-10-23T03:49:56  *** jacurn has joined #bitcoin-core-dev
 632016-10-23T03:50:53  *** alpalp has quit IRC
 642016-10-23T03:53:34  *** aalex has joined #bitcoin-core-dev
 652016-10-23T03:56:54  *** jacurn has quit IRC
 662016-10-23T03:59:06  *** jacurn has joined #bitcoin-core-dev
 672016-10-23T03:59:40  *** aalex has quit IRC
 682016-10-23T04:03:25  *** aalex has joined #bitcoin-core-dev
 692016-10-23T04:10:06  *** Alopex has quit IRC
 702016-10-23T04:10:24  *** davec has quit IRC
 712016-10-23T04:10:56  *** davec has joined #bitcoin-core-dev
 722016-10-23T04:11:11  *** Alopex has joined #bitcoin-core-dev
 732016-10-23T04:35:33  *** Giszmo has quit IRC
 742016-10-23T04:44:42  *** fengling has joined #bitcoin-core-dev
 752016-10-23T04:54:46  *** aalex has quit IRC
 762016-10-23T04:58:30  *** aalex has joined #bitcoin-core-dev
 772016-10-23T05:05:09  *** To7 has quit IRC
 782016-10-23T05:10:15  <luke-jr> is there some reason we're not using SVG images in the GUI?
 792016-10-23T05:40:21  *** fengling has quit IRC
 802016-10-23T05:43:06  *** fengling has joined #bitcoin-core-dev
 812016-10-23T05:57:37  *** fengling has quit IRC
 822016-10-23T06:00:02  *** dermoth has quit IRC
 832016-10-23T06:00:39  *** dermoth has joined #bitcoin-core-dev
 842016-10-23T06:03:05  *** fengling has joined #bitcoin-core-dev
 852016-10-23T06:30:21  <GitHub8> [bitcoin] luke-jr opened pull request #8996: Network activity toggle (master...networkactive) https://github.com/bitcoin/bitcoin/pull/8996
 862016-10-23T07:20:35  *** whphhg has quit IRC
 872016-10-23T07:23:25  *** whphhg has joined #bitcoin-core-dev
 882016-10-23T07:28:06  *** cdecker has joined #bitcoin-core-dev
 892016-10-23T07:29:20  *** aalex has quit IRC
 902016-10-23T07:33:28  *** aalex has joined #bitcoin-core-dev
 912016-10-23T07:42:59  *** Ylbam has joined #bitcoin-core-dev
 922016-10-23T07:48:22  *** Alopex has quit IRC
 932016-10-23T07:49:27  *** Alopex has joined #bitcoin-core-dev
 942016-10-23T07:56:13  *** baldur has quit IRC
 952016-10-23T08:04:01  *** Alopex has quit IRC
 962016-10-23T08:05:07  *** Alopex has joined #bitcoin-core-dev
 972016-10-23T09:14:20  *** aalex has quit IRC
 982016-10-23T09:16:52  *** justanotheruser has quit IRC
 992016-10-23T09:18:50  *** aalex has joined #bitcoin-core-dev
1002016-10-23T09:27:40  *** justanotheruser has joined #bitcoin-core-dev
1012016-10-23T09:56:04  <gmaxwell> why is getblocktemplate returning txn results for me on a 0.13.1rc1 node?
1022016-10-23T09:56:39  <gmaxwell> I thought as soon as segwit was defined it needed the capability?
1032016-10-23T09:57:07  <gmaxwell> ... if thats only triggered on activation, then uh we would expect some portion of hashpower who hasn't correctly prepared to simply drop off at that point.
1042016-10-23T09:57:27  <gmaxwell> Where did I desync?
1052016-10-23T09:59:41  *** aalex has quit IRC
1062016-10-23T10:04:21  *** aalex has joined #bitcoin-core-dev
1072016-10-23T10:07:39  *** murch has joined #bitcoin-core-dev
1082016-10-23T10:17:59  *** d_t has joined #bitcoin-core-dev
1092016-10-23T10:27:01  *** sdaftuar_ has joined #bitcoin-core-dev
1102016-10-23T10:28:04  <sdaftuar_> gmaxwell: possible I'm misremembering but I think gbt just won't signal for segwit until the capability is specified, but it will still return successfully
1112016-10-23T10:28:52  <sdaftuar_> There should be tests for the intended behavior in segwit.py or p2p-segwit.py
1122016-10-23T10:30:34  <gmaxwell> oh thats okay too then!
1132016-10-23T10:33:09  *** Alina-malina has quit IRC
1142016-10-23T10:33:40  *** Alina-malina has joined #bitcoin-core-dev
1152016-10-23T10:35:52  *** Alina-malina has quit IRC
1162016-10-23T10:35:52  *** Alina-malina has joined #bitcoin-core-dev
1172016-10-23T10:37:31  *** BCBot has quit IRC
1182016-10-23T10:37:49  *** BCBot has joined #bitcoin-core-dev
1192016-10-23T10:40:28  *** sdaftuar__ has joined #bitcoin-core-dev
1202016-10-23T10:40:44  *** sdaftuar_ has quit IRC
1212016-10-23T10:41:09  *** sdaftuar__ is now known as sdaftuar_
1222016-10-23T10:41:59  *** n1ce has joined #bitcoin-core-dev
1232016-10-23T10:44:52  *** ratoder has joined #bitcoin-core-dev
1242016-10-23T10:49:14  *** n1ce has quit IRC
1252016-10-23T10:51:01  *** sdaftuar_ has quit IRC
1262016-10-23T10:52:20  *** sdaftuar_ has joined #bitcoin-core-dev
1272016-10-23T11:01:05  <wumpus> luke-jr: because including the svg rendering engine would introduce an extra dependency, and also qt4/qt5 differences IIRC
1282016-10-23T11:01:59  <wumpus> also drawing SVG is generally slower than just drawing pixmaps, unless you have some smart caching layer, I have no clue where Qt is in that regard
1292016-10-23T11:02:24  <wumpus> tldr it's just a big risky change and things work pretty well as they do
1302016-10-23T11:03:41  <wumpus> maybe it makes sense when, if ever, moving from qt widgets to qml quick or such based gui. I have no relevant experience with any of the qt newness in the last few years though.
1312016-10-23T11:03:41  *** n1ce has joined #bitcoin-core-dev
1322016-10-23T11:06:24  <wumpus> in any case I doubt we'll accept a patch that just changes image rendering to svg and has zero visual changes for the user, even though it would be 'neater' way of doing things in some sense, it's just not worth the review and testing overhead
1332016-10-23T11:07:13  <wumpus> on the other hand a snappy GUI-redo that blows everyone away and happens to need SVG rendering, well, sure
1342016-10-23T11:13:34  *** laurentmt has joined #bitcoin-core-dev
1352016-10-23T11:13:49  *** laurentmt has quit IRC
1362016-10-23T11:15:59  *** Guyver2 has joined #bitcoin-core-dev
1372016-10-23T11:17:39  *** d_t has quit IRC
1382016-10-23T11:18:11  *** achow101 has quit IRC
1392016-10-23T11:18:44  *** n1ce has quit IRC
1402016-10-23T11:21:40  *** n1ce has joined #bitcoin-core-dev
1412016-10-23T11:28:19  *** laurentmt has joined #bitcoin-core-dev
1422016-10-23T11:34:38  *** aalex has quit IRC
1432016-10-23T11:35:07  *** testnet has joined #bitcoin-core-dev
1442016-10-23T11:35:58  *** testnet has left #bitcoin-core-dev
1452016-10-23T11:38:36  *** sdaftuar_ has quit IRC
1462016-10-23T11:40:07  *** sdaftuar_ has joined #bitcoin-core-dev
1472016-10-23T11:43:32  *** aalex has joined #bitcoin-core-dev
1482016-10-23T11:56:30  *** aalex has quit IRC
1492016-10-23T11:58:23  *** aalex has joined #bitcoin-core-dev
1502016-10-23T12:00:04  *** sdaftuar_ has quit IRC
1512016-10-23T12:00:05  *** sdaftuar__ has joined #bitcoin-core-dev
1522016-10-23T12:03:28  *** belcher has quit IRC
1532016-10-23T12:04:16  *** aalex has quit IRC
1542016-10-23T12:05:37  *** belcher has joined #bitcoin-core-dev
1552016-10-23T12:06:29  <nsh> there were a couple issues identified in NCC audit by NCC group which might be relevant to bitcoin-core. not sure if they made it upstream.
1562016-10-23T12:06:41  <nsh>  NCC-2016-015 - Out-of-bounds Read in Boost date Class #1459 - https://github.com/zcash/zcash/issues/1459
1572016-10-23T12:06:50  <nsh>  NCC-2016-008 - Potential uninitialized reads #1464  - https://github.com/zcash/zcash/issues/1464
1582016-10-23T12:08:23  *** aalex has joined #bitcoin-core-dev
1592016-10-23T12:08:43  *** jtimon has joined #bitcoin-core-dev
1602016-10-23T12:09:19  <wumpus> I've seen the report, but thanks for the update
1612016-10-23T12:09:43  <wumpus> the respective fixes haven't made it upstream yet
1622016-10-23T12:10:36  * nsh nods
1632016-10-23T12:19:24  *** d_t has joined #bitcoin-core-dev
1642016-10-23T12:19:36  *** aalex has quit IRC
1652016-10-23T12:21:52  <jtimon> gmaxwell: wumpus btcdrak sorry I missed the rest conversation in https://botbot.me/freenode/bitcoin-core-dev/2016-10-22/?msg=75272893&page=1
1662016-10-23T12:22:55  <jtimon> I know btcdrak hates "cascading PRs", but I think it makes sense here
1672016-10-23T12:23:22  *** aalex has joined #bitcoin-core-dev
1682016-10-23T12:23:39  <jtimon> I plan to finish https://github.com/jtimon/bitcoin/compare/0.13-new-testchain...jtimon:0.13-blocksign hopefully on monday
1692016-10-23T12:23:49  <btcdrak> nice!
1702016-10-23T12:24:32  <jtimon> but I think they could really just use this temporarily and I'm afraid the block signing part will require a lot more review and testing and will take longer to merge
1712016-10-23T12:24:58  <jtimon> they can -chain=custom -chainpetname=lightning, new chain
1722016-10-23T12:25:46  <btcdrak> I'm ok with two PRs. blocksign will be rebased on the first PR anyway right?
1732016-10-23T12:26:12  <jtimon> if an idiot spends a lot of energy mining that testchain, you can just -chain=custom -chainpetname=lightning2 and show him your middle finger, you can always -listen=0 -connect=... etc
1742016-10-23T12:27:20  <jtimon> btcdrak: yeah blocksigning will be on top of this one since to create a new blocksigning chain you need to first create a new chain
1752016-10-23T12:28:00  <jtimon> reading from a file was a later addition, but it was like 4 lines extra
1762016-10-23T12:29:52  *** mol is now known as moli
1772016-10-23T12:30:06  <jtimon> at least reusing ReadConfigFile, if we really prefer a json file over a conf file that may be more extra work, not sure how strongly wumpus wants json, I personally don't see the gain
1782016-10-23T12:31:44  <btcdrak> I think json makes sense, there are potentially a lot of chain params to configure.
1792016-10-23T12:33:04  <jtimon> regarding "what they asked for" rusty asked for providing the genesishash manually instead of it being calculated dynamically  from the genesis block (you can force a new genesis just changing -chainpetname) like this PR does, so I wanted his feedback on that (it's true I didn't need to open the PR already for that)
1802016-10-23T12:34:03  <jtimon> btcdrak: the same number as with a conf file, but you're just not able to reuse util to handle them
1812016-10-23T12:35:06  <jtimon> I don't think CChainParams::UpdateFromArgs() will get smaller by using json
1822016-10-23T12:36:18  *** n1ce has quit IRC
1832016-10-23T12:36:38  <btcdrak> It's also easier to share chain details with a json file.
1842016-10-23T12:37:27  *** n1ce has joined #bitcoin-core-dev
1852016-10-23T12:37:53  <jtimon> regarding "a pointless feature that we've already lowered the quality of the codebase to enable" I strongly disagree but I'm not entirely sure what gmaxwell is refering to
1862016-10-23T12:38:42  <jtimon> he mentions Params().GetConsensus().getdarnaninterger() inside a loop
1872016-10-23T12:39:09  <wumpus> let's bury that part of the discussion please
1882016-10-23T12:39:16  <wumpus> both gmaxwell and me went out of line there
1892016-10-23T12:39:30  <wumpus> blame it on stress, or whatever
1902016-10-23T12:42:00  <jtimon> as opposed to chainparams.GetConsensus().getdarnaninterger() so I assume he is not complaining about changes related to #7829 . If he is complaining about the GetConsensus part, that was only for libconsensus to avoid the chainparams dependency which contains globals. Of course I agree that shouldn't be in a loop, it should be called once and made a local variable outside the loop, if it is the only chainparams that the function
1912016-10-23T12:42:00  <jtimon>  needs, it should take darninteger directly as parameter instead of the whole CChainParams
1922016-10-23T12:42:25  <jtimon> ok, not trying to revive any fire, just trying to make sure we're on the same page
1932016-10-23T12:42:59  <wumpus> I explained the reasoning behind it afterward, and what will be the future direction, no need to rake up anything
1942016-10-23T12:43:02  <wumpus> right
1952016-10-23T12:43:21  <jtimon> btcdrak: how is sharing mychain.json any easier than sharing mychain.conf ?
1962016-10-23T12:43:43  <wumpus> if there's a bla().bla().bla() in a loop we can just factor it out of the loop, this is not rocketscience :)
1972016-10-23T12:44:31  <gmaxwell> putting things in a file does not make them configurable.
1982016-10-23T12:44:41  <gmaxwell> please keep that in mind.
1992016-10-23T12:44:42  <wumpus> jtimon: json may be a more convenient format for automatic generation from the tests / handling nested structures, but I don't care deeply
2002016-10-23T12:44:46  <jtimon> wumpus: what are your thoughts on json vs conf since you brought that up?
2012016-10-23T12:44:48  *** n1ce has quit IRC
2022016-10-23T12:44:56  <gmaxwell> many of our constants tie deeply into algorithims and protocol assumptions.
2032016-10-23T12:44:57  <jtimon> I see
2042016-10-23T12:44:59  <btcdrak> what wumpus said
2052016-10-23T12:45:27  <wumpus> yes, there is compromise somewhere on what constants whould be configurable, I think the ones curently in ChainParams make sense though
2062016-10-23T12:45:44  <wumpus> this doesn't mean the entire algorithm should be micro-manageable though the configuration file
2072016-10-23T12:45:58  <wumpus> unless you want to replace it with JITed LUA or so, but that's clearly not a goal here
2082016-10-23T12:46:36  <gmaxwell> yep.
2092016-10-23T12:46:57  <gmaxwell> (as I said, just something to keep in mind.)
2102016-10-23T12:47:03  <wumpus> it may be possible to switch between discretely defined algorithms in the config file though, e.g. between a PoW or "centrally signed blocks"
2112016-10-23T12:47:15  <gmaxwell>         fRequireStandard = false;
2122016-10-23T12:47:21  <gmaxwell> sure
2132016-10-23T12:47:47  <jtimon> once they're in ChainParams they are not constants, but we may have abused ChainParams and maybe we want to try to turn some back into constants (if testnet and regtest have the same values at least)
2142016-10-23T12:48:20  <wumpus> well they are constants after reading them from the configuration file
2152016-10-23T12:48:30  <wumpus> they don't change at runtime, that would be madness
2162016-10-23T12:48:42  <jtimon> the way I was planning to expose the blocksigning was through a variable like -blocksignscript, maybe a boolean too
2172016-10-23T12:48:55  <wumpus> sure, at the language leven they're not constants, but they already are not because they're fetched from a structure...
2182016-10-23T12:49:01  <wumpus> leveL
2192016-10-23T12:49:29  <jtimon> wumpus: right, they init once and then ChainParams should be always passed as const
2202016-10-23T12:49:35  <gmaxwell> there are a at least some things that the values in chain params for testnet/regtest are at odds with the code. don't assume the paramters for testnet or regtest were especially well thought out. :) there may be places where we want to reduce their divergence with mainnet in the future... as their differences are a continued source of time-waste.
2212016-10-23T12:50:35  <wumpus> gmaxwell: that's our whole point, though, there may be use for testnets that are more close to mainnet, or further away from it, dependeing on the specific testing
2222016-10-23T12:50:36  <jtimon> I fear a cleanup may require testnet4 and regtest2
2232016-10-23T12:50:55  <gmaxwell> I am wtfing at regtest2.
2242016-10-23T12:51:14  <wumpus> regtest2 makes no sense
2252016-10-23T12:51:33  <gmaxwell> but duh sure, improving things may mean some incompatiblities. thats fine.
2262016-10-23T12:51:34  <wumpus> there is no shared 'regtest' network
2272016-10-23T12:52:07  <wumpus> although compatibility between versions may be useful for comparison testing
2282016-10-23T12:52:10  <wumpus> (!)
2292016-10-23T12:52:46  <jtimon> well, maybe if you want to make some values more similar to the mainnet to make them constants again, but I really don't know, I've thought more about testnet4, particularly in the context of bip70 which maybe gets replaced or something
2302016-10-23T12:53:14  <gmaxwell> E.g. I don't think when we created testnet or regtest anyone tought of the idea of inserting an optional bit mask in the target comparison function, so that high value blocks could be seen as meeting much lower targets.  I think if we'd thought of that we could have avoided some of the special difficulty rules there.
2312016-10-23T12:53:53  <jtimon> I particularly hate the fact that in bip70 testnet3 is called "test" instead of "testnet3" but that's a tiny detail
2322016-10-23T12:54:44  <wumpus> well a new testnet would need a new bip70 identifier I guess so that can be fixed then... but it's a minor inconsequential thing
2332016-10-23T12:55:19  <jtimon> and I dislike testnet's special case for pow too, but matt said it was quite useful (I don't really know)
2342016-10-23T12:55:45  <wumpus> well it will always need a special case for PoW, the question is can we do better than testnet3
2352016-10-23T12:56:17  <jtimon> not sure I understand gmaxwell's point about the bit mask
2362016-10-23T12:57:07  <wumpus> without special case for PoW a miner entering it and exiting it will just kill it, this happened before and was the reason for adding it to testnet3 in the first place. That doesn't mean it's the perfect solution that shoudl be used forever, but just reverting to plain PoW would be stupid.
2372016-10-23T12:57:20  <gmaxwell> regtest's 'special casing' requires difficulty go below one, which causes a large amount of divergence in the code.
2382016-10-23T12:57:57  <jtimon> wumpus: maybe a different difficulty filter would help more, but that's strong special-casing too
2392016-10-23T12:58:02  <wumpus> I sometimes wonder why doesn't just ignore PoW completely
2402016-10-23T12:58:06  <wumpus> regtest*
2412016-10-23T12:58:21  <wumpus> that would mean the PoW checking is regression tested less, ofcourse
2422016-10-23T12:58:51  <wumpus> jtimon: my point is just that testnet requires special casing there, the type of special casing is open for proposals though
2432016-10-23T12:58:52  <jtimon> gmaxwell: I see, what about making regtest just always pass the pow check?
2442016-10-23T12:59:10  <gmaxwell> that could have been better accomplished with a if (params->weakpow) memset(blockhash,0,4);  in the pow comparison.
2452016-10-23T12:59:28  <jtimon> I see
2462016-10-23T12:59:34  <gmaxwell> jtimon: there are tests that need pow to not be bypassed. Or at least there have been in the past, e.g. feeding lower difficulty blocks.
2472016-10-23T13:00:06  <wumpus> yes, that would make sense
2482016-10-23T13:00:35  <jtimon> gmaxwell: yeah just passing pow would need those tests to move to mainnet or testnet, but your solution seems less disruptive
2492016-10-23T13:00:44  <gmaxwell> the testnet getting stuckthing, even the current setup has problems with that, part of the call for the availability of signed block testnets.
2502016-10-23T13:00:53  <wumpus> regtest as it is now was a compromise back in the day and it works pretty well for regression testing, most trivial alternatives are probably worse
2512016-10-23T13:01:33  <gmaxwell> it also existed as a patch at first, it wasn't quite so designed out. Did it's roll fine, but with expirence better could be done now.
2522016-10-23T13:01:42  *** n1ce has joined #bitcoin-core-dev
2532016-10-23T13:01:48  <jtimon> gmaxwell: right, so maybe after adding signed blocks it makes more sense to remove testnet3's mindif special case
2542016-10-23T13:02:02  <gmaxwell> It might also be possible to set the rest of the paramters like normal (2016 blocks, yadda yadda, just make it cheaper to mine if its not fast enough)
2552016-10-23T13:02:07  <gmaxwell> jtimon: potentially.
2562016-10-23T13:03:05  <gmaxwell> Basically we should either have divergences that _really_ aid testing (signed blocks) or otherwise minimize them, we really have lost of a lot of troubleshooting time due to testnet having issues that mainnet would never have, not all due to paramter differences, but many.
2572016-10-23T13:03:55  *** n1ce2 has joined #bitcoin-core-dev
2582016-10-23T13:04:25  <jtimon> right
2592016-10-23T13:05:09  *** instagibbs has joined #bitcoin-core-dev
2602016-10-23T13:06:16  *** n1ce has quit IRC
2612016-10-23T13:06:23  <jtimon> regarding block signing, I was thinking making it optional at compile time and just have blocks having both nBits-nNonce and scriptChallenge-scriptSolution in blocks (that's a hit on memory requirements that shouldn't be imposed on production nodes)
2622016-10-23T13:06:26  *** d_t has quit IRC
2632016-10-23T13:07:00  <jtimon> previously thought of union, but even that would be a hit if you cannot disable it at compile time
2642016-10-23T13:07:22  <jtimon> how does that sound?
2652016-10-23T13:08:18  <jtimon> I mean, even an extra pointer and polymorphism would be 4 or 8 extra bytes per header (apart from polymorphism performance concerns)
2662016-10-23T13:08:20  <wumpus> where would be the hit in memory requirements? header stoage?
2672016-10-23T13:08:29  <jtimon> yep, header storage
2682016-10-23T13:09:12  <wumpus> ok yes bleh, that structure is already too fat
2692016-10-23T13:09:12  <jtimon> in elements we just remove nBits and nNonce, but obviously we cannot do that here
2702016-10-23T13:09:16  *** n1ce2 has quit IRC
2712016-10-23T13:09:19  *** n1ce has joined #bitcoin-core-dev
2722016-10-23T13:09:42  <jtimon> so ack on compile time option for signed blocks?
2732016-10-23T13:09:44  <wumpus> using an union sounds better then
2742016-10-23T13:10:02  <wumpus> well compile time option does mean it cannot be used for the normal tests
2752016-10-23T13:10:16  <wumpus> and probably won't be enabled by default in releases
2762016-10-23T13:10:45  <wumpus> I'd prefer not to do that, unless this is a rarely used, memory hogging option, but then who would enable it in practice?
2772016-10-23T13:10:48  <jtimon> mhmm, if you allow the option you compile the tests that need it too?
2782016-10-23T13:11:02  <sipa> i don't think you can use a union with non-trivial C++ types in it
2792016-10-23T13:11:08  <jtimon> only devs I was assuming
2802016-10-23T13:11:22  <wumpus> this is about trivial C++ types such as ints right? nBits, nNonce etc
2812016-10-23T13:11:25  <sipa> c+11 relaxed the requirements a bit, though
2822016-10-23T13:11:44  <wumpus> if not that's a dangerous minefile
2832016-10-23T13:11:46  <wumpus> minefield*
2842016-10-23T13:11:49  <sipa> for block signing the signature is a CScript
2852016-10-23T13:11:55  <gmaxwell> compile time is pretty sad, how about an auxiliray datastructure that only gets created if using signed blocks, e.g. a second index?
2862016-10-23T13:11:56  <sipa> in CBlockHeader
2872016-10-23T13:12:09  <wumpus> that needs to be stored for every block, permanently?
2882016-10-23T13:12:22  <sipa> yes, instead of a nonce you have a signature
2892016-10-23T13:12:44  <jtimon> I was thinking ethier a union of structs PowProof and ScriptProof or an IntOrScript union for both nBits and nNonce
2902016-10-23T13:12:45  <wumpus> gmaxwell: yes
2912016-10-23T13:12:56  <gmaxwell> well technically it's a block witness...
2922016-10-23T13:13:16  <gmaxwell> segregate all the witnesses. :P
2932016-10-23T13:13:18  <wumpus> that makes sense; with using an union you could even take the additional memory requirement to 0
2942016-10-23T13:13:28  <wumpus> union a pointer with nBits,nNonce
2952016-10-23T13:14:03  <jtimon> I mean, the challenge field could be just constant per chain instead of being included in every block, I was just thinking that maybe someone could get creative with CalculateNextScriptChallenge or something
2962016-10-23T13:14:24  <wumpus> (i mean the additonal memory requirement when not using the feature, which is what we care about here)
2972016-10-23T13:14:58  <jtimon> this is it's actually in both CBlockHeader and CBlockIndex
2982016-10-23T13:15:58  <jtimon> wumpus: yeah, at a minimum union a pointer would be an extra pointer per block, that's my worry
2992016-10-23T13:16:18  <sipa> ah, it seems you can have non-trivial classes in a union now
3002016-10-23T13:16:36  <sipa> but it requires placement new and explicit destructor invocations
3012016-10-23T13:16:48  <jtimon> yep IntOrScript seemed to compile
3022016-10-23T13:17:30  <wumpus> jtimon: I don't understand that. You'd only need the pointer when using block signing, youd' only need nBits+nNonce when using PoW, those could be in the same memory space right?
3032016-10-23T13:18:08  <jtimon> so it would be a pointer to a struct that is either nBits+nNonce or a script (or a couple of them)
3042016-10-23T13:18:20  <sipa> wumpus: nBits is the "challenge" which can in theory also be replaced with a "block scriptPubKey"
3052016-10-23T13:18:38  <wumpus> jtimon: in the first case it'd just be nBits+nNonce in-place, in the second case it'd be a pointer to a script
3062016-10-23T13:18:41  <sipa> wumpus: so you can allow rules about how the signer(s) can change over time
3072016-10-23T13:18:50  <wumpus> sipa: okay
3082016-10-23T13:18:55  <sipa> however, that seems overkill here
3092016-10-23T13:18:59  <gmaxwell> a bit out of scope here but not incompatable.
3102016-10-23T13:19:01  <jtimon> sipa: right, but we can also remove that if the challenge script is going to be always constant
3112016-10-23T13:19:14  <sipa> as the block challenge can just be a chain wide constant as jtimon says
3122016-10-23T13:19:18  <gmaxwell> the union is the 64 bits of nbits+nonce or a pointer to an extension datastructure.
3132016-10-23T13:20:04  <jtimon> wumpus: I see, yeah, that's better and removes the need for the compile time option, thanks!
3142016-10-23T13:20:37  <sipa> perhaps we want the union to be between {nBits,nNonce} on the onenhand, and CScript *scriptSig on the other
3152016-10-23T13:20:54  <wumpus> sipa: that's what both gmaxwell and me are saying , yes :)
3162016-10-23T13:21:09  <sipa> note the *
3172016-10-23T13:21:21  <wumpus> I had assumed the *
3182016-10-23T13:21:22  <jtimon> or we could put the script in the coinbase with the other witnesses, but I'm not really sure I like that
3192016-10-23T13:21:38  <wumpus> I have no clue what the size of CScript is, but I'd guess it's larger than 8
3202016-10-23T13:21:53  <wumpus> so yes that should be a pointer
3212016-10-23T13:21:54  <sipa> 24
3222016-10-23T13:22:01  <sipa> on 64-bit
3232016-10-23T13:22:15  <sipa> actually, it's a prevector, so much larger
3242016-10-23T13:22:17  <jtimon> yep, now I'm embarrased I didn't thought of the union being like that myself, but thanks guys, good call
3252016-10-23T13:22:53  <sipa> for some reason i am very scared of using unions
3262016-10-23T13:23:12  <wumpus> in this case the way it is used depends on a global setting, so I'm okay with it
3272016-10-23T13:23:21  <wumpus> I'm scared of tagged/per-case unions though
3282016-10-23T13:23:25  <jtimon> sipa: yeah that motivated my run to the compile option too
3292016-10-23T13:23:43  <sipa> but the CBlockHeader destructor will need to know which of the two cases is being used
3302016-10-23T13:23:48  <sipa> that's very ugly
3312016-10-23T13:23:59  <sipa> how will it know? a global?
3322016-10-23T13:24:08  <wumpus> maybe have two different CBlockHeader types?
3332016-10-23T13:24:12  <jtimon> oh, right, that's ugly
3342016-10-23T13:24:25  <jtimon> a static field in CBlockHeader maybe
3352016-10-23T13:24:34  <sipa> jtimon: that's just a global
3362016-10-23T13:24:43  <wumpus> CPoWBlockHeader CSignedBlockHeader .. but yeah that moves the problem up :)
3372016-10-23T13:24:44  <jtimon> sipa: yep
3382016-10-23T13:24:56  <sipa> wumpus: then you need to templatize all the block logoc
3392016-10-23T13:25:07  <jtimon> wumpus: CPoWBlockHeader CSignedBlockHeader is way too disruptive
3402016-10-23T13:25:13  <wumpus> yes...
3412016-10-23T13:25:32  <wumpus> no, never mind, that would be stupid in c++ :)
3422016-10-23T13:26:00  <jtimon> I mean, it's CBlockHeader<proofType> or whatever, but still, not an option I think
3432016-10-23T13:26:08  <wumpus> this is pretty much the place where the inflexibilty of C languages starts to show
3442016-10-23T13:27:00  <gmaxwell> only if the header itself owns the data, and it isn't just an index into a seperate data structure.
3452016-10-23T13:27:14  <wumpus> either you have to template everything, or do some crazy union hack, both seem like bad choices...
3462016-10-23T13:27:38  <sipa> it is in fact much easier (in terms of code changes) to make it tagged
3472016-10-23T13:27:52  <jtimon> well, I guess the less disruptive option would be to make CBlockHeader the base and use polymorphism, but I think we want to avoid that too
3482016-10-23T13:27:57  <gmaxwell> e.g. you could have a header-extradata structure, and the header just gets indexes into it. iirc we don't ever delete headers one accepted.
3492016-10-23T13:28:06  <wumpus> sipa: yes, but the tag takes up extra space, which was what we wre trying to avoid in the first place :)
3502016-10-23T13:28:23  <sipa> wumpus: i know, but far less than just always having both cases
3512016-10-23T13:28:34  <gmaxwell> so the extradata structure would own its own memory and be responsable for freeing it on shutdown.
3522016-10-23T13:28:47  <sipa> gmaxwell: the extra data is not just in CBlockIndex
3532016-10-23T13:28:48  <wumpus> gmaxwell: yes, indeed
3542016-10-23T13:29:06  <sipa> it's part of every CBlockHeader we send and receive
3552016-10-23T13:29:25  <jtimon> I think the best candidates are union and a compile time option
3562016-10-23T13:29:28  <sipa> it sounds very hard to avoid a memory leak if you do not deal with deletion
3572016-10-23T13:29:39  <jtimon> right, plus CBlock extends from CBlockHeader
3582016-10-23T13:30:13  <wumpus> what I like least about this is that it changes consensus data structures
3592016-10-23T13:30:34  <wumpus> for something that is just for testing
3602016-10-23T13:31:58  <jtimon> yep, that may be another argument in favor of the compile time option (which I realise is independent from using the union or not)
3612016-10-23T13:32:43  <gmaxwell> Compile time option would greatly diminish the utility of this. (especially considering the size of our static binaries)
3622016-10-23T13:32:56  <wumpus> with compile time option you could *guarantee* that the normal case remains unchanged
3632016-10-23T13:33:13  <gmaxwell> Yes.
3642016-10-23T13:33:16  <gmaxwell> at that point, might as well just make it a seperate repo and resync to core periodically, I think.
3652016-10-23T13:33:23  <wumpus> which is, imo, the only acceptable way to do this
3662016-10-23T13:33:45  <wumpus> yes, probably. It's effectively an altcoin at that point :)
3672016-10-23T13:34:18  <gmaxwell> Right, so why take noise in the codebase for it if we can't even make it as integrated as testnet? it's at least a pretty clean patch.
3682016-10-23T13:35:00  * wumpus wants pluggable consensus libraries
3692016-10-23T13:35:37  <wumpus> yes, it seems it's not practically doable at this time
3702016-10-23T13:35:53  <wumpus> in our current codebase and structure
3712016-10-23T13:38:09  <jtimon> well, I will try with the union and without compile time option and see how it looks like
3722016-10-23T13:39:14  *** n1ce has quit IRC
3732016-10-23T13:39:17  <jtimon> if we do it as a constanly rebased branch, at least merging the custom chain patch would make the blocksigning one more maintainable
3742016-10-23T13:40:18  <sipa> jtimon: agree
3752016-10-23T13:40:46  <sipa> i was surprised there was not a resurgence of coingen like sites after chainparams was merged :)
3762016-10-23T13:42:20  *** kadoban has joined #bitcoin-core-dev
3772016-10-23T13:44:24  <jtimon> sipa: you where also surprised there wasn't an elements_alpha_with_pow_back altcoin I asume, I guess you forget that the most important part of an altcoin is the logo not the features :p
3782016-10-23T13:44:25  <wumpus> proabably coingen didn't work too well as a business model
3792016-10-23T13:45:12  <wumpus> making it even easier to make altcoins by just changing one source file undermines that further, who would pay for it anymore :)
3802016-10-23T13:45:27  <sipa> wumpus, jtimon: we can of course trying the separate-branch approach first, merging only the unlikely-to-affect-consensus patches in mainline, to see how much interest there is in it
3812016-10-23T13:45:46  <wumpus> yes
3822016-10-23T13:45:53  <sipa> sure, not having it integrated inline may hurt adoption of such a chain
3832016-10-23T13:46:19  <sipa> but on the other hand, it would be a pity tongo throigh all the work of plugging this in if it doesn't get used
3842016-10-23T13:46:28  <sipa> *to go through
3852016-10-23T13:48:16  <jtimon> in any case, I think chainparams is older than coingen , isn't it? I don't remember not being a chainparams
3862016-10-23T13:51:29  <gmaxwell> not at all.
3872016-10-23T13:53:22  *** paveljanik has joined #bitcoin-core-dev
3882016-10-23T13:54:18  *** aalex has quit IRC
3892016-10-23T13:55:11  <sipa> chainparams was only in june 2013
3902016-10-23T13:56:10  <sipa> before that, we just had "if (fTestnet)" all over the place
3912016-10-23T13:57:29  <sipa> and testnet itself was october 2010, 2 months before i ever looked at the code
3922016-10-23T14:00:06  <wumpus> also altcoins, inherently driven by speculation, have always tended to fork from what is the speculation hotness of the day, at one point this was litecoin, after that the "PoS" coins, now it's probably ethereum-ism things. A profitable coingen would have to follow all that :p
3932016-10-23T14:00:53  *** sdaftuar__ has quit IRC
3942016-10-23T14:01:37  <tulip> for a long time most alt coins were, and still are 0.6 based branches. the original proof of stake patches were never rebased onto modern Bitcoin Core until quite late in the crazy. the original lfnet IRC channels still have hundreds of alt coin nodes (but only 2-3 wxBitcoin).
3952016-10-23T14:02:14  <wumpus> yes :)
3962016-10-23T14:02:52  <sipa> many earlier ones forked off namecoin, was was based on 0.3.24 afaik
3972016-10-23T14:02:57  <tulip> up until recently there was a 0.3 and a 0.4 node still connected to #bitcoin00 on lfnet, one of the two still had 8333 routed. I'd love to know where that was running to be still up, but obviously well behind the chain this number of years on.
3982016-10-23T14:03:21  <wumpus> it's a lemons market, flooded with even more lemons every day, quite interesting from a psychology point of view not so much from a technological :)
3992016-10-23T14:08:30  *** aalex has joined #bitcoin-core-dev
4002016-10-23T14:08:56  <tulip> wumpus: given there's >200 name coin clients on lfnet I assume they never rebased past 0.5? surprised it even functions, they must be missing some serious patches by this point.
4012016-10-23T14:12:06  *** alpalp has joined #bitcoin-core-dev
4022016-10-23T14:13:02  *** d9b4bef9 has quit IRC
4032016-10-23T14:14:07  *** d9b4bef9 has joined #bitcoin-core-dev
4042016-10-23T14:15:40  <wumpus> namecoin did fairly recently rebase on top of newer bitcoin core (not sure what version). But yes most coins do not, it's not like they're a big target for attacks, nor actively maintained. The only way we notice is that sometimes people file bugs/build system issues against bitcoincore that have been fixed years ago, not realizing we've moved on since
4052016-10-23T14:17:16  <wumpus> I'm going to try to get this gcbpay person banned from our github, this can no longer be accidental: https://github.com/bitcoin/bitcoin/issues?utf8=%E2%9C%93&q=is%3Aissue%20author%3Agcbpay%20
4062016-10-23T14:17:47  <luke-jr> wumpus: go the organization settings
4072016-10-23T14:17:55  <luke-jr> there's a "tab" for banning users
4082016-10-23T14:25:23  <sipa> wumpus: he has a bunch of repositories, but none contain code, and all issues are self created and look like nonsense as well
4092016-10-23T14:25:39  <sipa> it may be just someone who has no clue
4102016-10-23T14:25:57  *** MarcoFalke has joined #bitcoin-core-dev
4112016-10-23T14:28:52  <sipa> but if they're a nuisance and not responsive to comments, yes ban
4122016-10-23T14:29:13  *** aalex has quit IRC
4132016-10-23T14:31:51  <wumpus> Blocking a user prevents the following on all your repositories: opening or commenting on issues or pull requests, starring, forking, or watching,  adding or editing wiki pages
4142016-10-23T14:32:05  <wumpus> they can still download the source, or check it out
4152016-10-23T14:32:10  <wumpus> which is great
4162016-10-23T14:32:32  <wumpus> I don't expect any useful contributions from them, but they won't lose access completely, so this is the right thing to do
4172016-10-23T14:33:23  *** aalex has joined #bitcoin-core-dev
4182016-10-23T14:40:21  *** MarcoFalke has quit IRC
4192016-10-23T14:40:52  *** MarcoFalke has joined #bitcoin-core-dev
4202016-10-23T14:41:55  *** alpalp has quit IRC
4212016-10-23T14:42:12  *** alpalp has joined #bitcoin-core-dev
4222016-10-23T14:42:13  *** alpalp has joined #bitcoin-core-dev
4232016-10-23T14:44:16  *** aalex has quit IRC
4242016-10-23T14:44:35  *** achow101 has joined #bitcoin-core-dev
4252016-10-23T14:46:46  *** MarcoFalke has quit IRC
4262016-10-23T14:47:00  *** MarcoFalke has joined #bitcoin-core-dev
4272016-10-23T14:48:25  *** aalex has joined #bitcoin-core-dev
4282016-10-23T14:54:25  *** aalex has quit IRC
4292016-10-23T14:57:24  *** MarcoFalke has quit IRC
4302016-10-23T14:57:38  *** MarcoFalke has joined #bitcoin-core-dev
4312016-10-23T14:58:26  *** aalex has joined #bitcoin-core-dev
4322016-10-23T15:00:25  *** alpalp has quit IRC
4332016-10-23T15:09:02  *** MarcoFalke has quit IRC
4342016-10-23T15:09:30  *** MarcoFalke has joined #bitcoin-core-dev
4352016-10-23T15:14:55  *** MarcoFalke has quit IRC
4362016-10-23T15:15:42  *** alpalp has joined #bitcoin-core-dev
4372016-10-23T15:15:43  *** alpalp has joined #bitcoin-core-dev
4382016-10-23T15:15:59  *** MarcoFalke has joined #bitcoin-core-dev
4392016-10-23T15:16:10  *** Giszmo has joined #bitcoin-core-dev
4402016-10-23T15:26:09  *** alpalp has quit IRC
4412016-10-23T15:40:11  *** To7 has joined #bitcoin-core-dev
4422016-10-23T15:40:19  *** aalex has quit IRC
4432016-10-23T15:43:38  *** aalex has joined #bitcoin-core-dev
4442016-10-23T16:21:00  *** AaronvanW has quit IRC
4452016-10-23T16:21:08  *** alpalp has joined #bitcoin-core-dev
4462016-10-23T16:33:57  *** aalex has quit IRC
4472016-10-23T16:38:45  *** aalex has joined #bitcoin-core-dev
4482016-10-23T16:39:07  *** Alina-malina has quit IRC
4492016-10-23T16:45:20  *** Alina-malina has joined #bitcoin-core-dev
4502016-10-23T16:47:25  *** Alina-malina has quit IRC
4512016-10-23T16:47:25  *** Alina-malina has joined #bitcoin-core-dev
4522016-10-23T17:00:59  *** d_t has joined #bitcoin-core-dev
4532016-10-23T17:06:11  *** MarcoFalke has quit IRC
4542016-10-23T17:06:17  *** MarcoFalke has joined #bitcoin-core-dev
4552016-10-23T17:06:35  <arubi> something weird on regtest (did not try testnet), I have two nodes addnode'd to eachother (A and B).  A first mines 750 blocks, sends the sum in one output to B, and mines block 751.  then B creates a 1 input to 607 p2wsh(15-of-15 multisig) outputs (to itself) tx and relays it to A which then mines a block.  B now has 607 15-of-15 p2wsh utxos, it combines them all a 607 p2wsh(15-of-15) -> 1 p2wpkh output tx, and relays to A which now has it
4562016-10-23T17:06:35  <arubi> in mempool too.  now, I can not get either A or B to mine this tx, no matter if hours pass or if I mine a thousand blocks at a time.  it just stays in both mempools.
4572016-10-23T17:06:59  <arubi> the same process with a 606 15-of-15 outputs works fine.  still trying other types of scripts.  I couldn't get this to happen with p2pkh or p2sh(15-of-15).  it either aborts because the tx is too large, or too many sigops.
4582016-10-23T17:07:14  <arubi> 606 and below*
4592016-10-23T17:08:12  <achow101> arubi: is it related to https://github.com/bitcoin/bitcoin/pull/8499#issuecomment-252420342
4602016-10-23T17:08:25  <achow101> the new policy limits for p2wsh?
4612016-10-23T17:09:08  <arubi> is 15 of 15 multisig affected?  looking
4622016-10-23T17:12:28  <sipa> how large is the 607 p2wsh output?
4632016-10-23T17:12:56  <arubi> well the script is 513 bytes
4642016-10-23T17:13:35  <arubi> signatures + pushes.. 1110 bytes?  I think
4652016-10-23T17:13:46  <arubi> can check, moment
4662016-10-23T17:14:02  <sipa> eh, i mean the size and weight of the transaction that does not get mined
4672016-10-23T17:14:47  <arubi> oh heh, sec.
4682016-10-23T17:15:14  <arubi> size": 999515, vsize": 268602,
4692016-10-23T17:16:04  <jl2012> vsize over 100000 is nonstandard?
4702016-10-23T17:16:45  <arubi> hm, so it's relayed around because regtest?  then not mined because it's too exotic?
4712016-10-23T17:17:25  <jl2012> not tested. but if it is accepted to mempool, it should also be mined?
4722016-10-23T17:17:47  <sipa> yes, being relayd/accepted but not mined sounds like a bug
4732016-10-23T17:18:24  <jl2012> arubi: are you sure your blocks are synced between the 2 nodes?
4742016-10-23T17:18:31  <arubi> yep
4752016-10-23T17:18:45  <jl2012> have you tried to do everything with only 1 node?
4762016-10-23T17:19:09  <arubi> I can try, though neither will mine it
4772016-10-23T17:19:12  <arubi> (trying)
4782016-10-23T17:19:36  <jl2012> are you doing it by hand or automated?
4792016-10-23T17:20:02  <jl2012> if automated, would you please share the script?
4802016-10-23T17:20:19  <arubi> a lot is automated, the script is a monstrosity
4812016-10-23T17:20:39  <arubi> I'm rewriting it, making it useful for more complex stuff.  mast in mind
4822016-10-23T17:21:20  <arubi> maybe it's time..  I'll get a gitlab account tomorrow and put it there
4832016-10-23T17:22:35  <jl2012> size: 999515 is for 606 or 607 inputs?
4842016-10-23T17:23:11  <arubi> 607
4852016-10-23T17:23:17  <jl2012> i think there is a setting about the block size/weight, forgot the name
4862016-10-23T17:23:26  <jl2012> maybe you hit the limit
4872016-10-23T17:23:39  <arubi> maxblocksize=1m , maxblockweight=4m with my nodes
4882016-10-23T17:23:56  <jl2012> try with only maxblockweight=4m ?
4892016-10-23T17:23:57  <arubi> unless weight can go higher, I didn't assume it could
4902016-10-23T17:24:07  <arubi> hm.  alright
4912016-10-23T17:24:17  <sipa> do you literally set '1m' as value?
4922016-10-23T17:24:20  <arubi> oh no no
4932016-10-23T17:24:25  <jl2012> i think the problem is maxblocksize=1m
4942016-10-23T17:24:26  <sipa> ok, just making sure
4952016-10-23T17:24:41  <sipa> yes, maxblocksize=1000000 may be too much
4962016-10-23T17:24:53  <arubi> yea no worries.  so just not set it?
4972016-10-23T17:24:54  <sipa> i think we always stay 1000 bytes below the limit
4982016-10-23T17:24:54  <jl2012> too small, you mean?
4992016-10-23T17:25:09  <sipa> you can set both weight and size to 4000000
5002016-10-23T17:25:43  <arubi> re-running with 1 node now, waiting for it to finish.  sipa, oh really?  I really didn't think that's the case
5012016-10-23T17:26:21  <sipa> maxblocksize is about the total serialized size, including witness
5022016-10-23T17:27:36  <arubi> and weight?  seems like the default value for maxsize is 750000, so maybe that's why I assumed
5032016-10-23T17:28:22  <arubi> and default weight is 3m so really seemed like the x4 factor at the time, now I remember
5042016-10-23T17:28:34  <sipa> weight is (total_size + 3*size_without_witness)
5052016-10-23T17:30:40  <arubi> I see, thanks.  jl2012, single node same behavior.  trying w/ setting maxsize to 4m as well
5062016-10-23T17:31:06  <jl2012> quite sure it's because of the max size
5072016-10-23T17:31:13  <jl2012> i tried before
5082016-10-23T17:32:12  <arubi> you mean without setting it at all, or setting it to 4m?
5092016-10-23T17:32:49  <sipa> if you only specify maxblockweight, the maxblocksize is implicitly 4M
5102016-10-23T17:32:53  <jl2012> i think i just set max weight
5112016-10-23T17:32:54  <GitHub114> [bitcoin] theuni opened pull request #9000: miner debugging: faux-mining (master...faux-mining) https://github.com/bitcoin/bitcoin/pull/9000
5122016-10-23T17:33:18  <jl2012> #9000
5132016-10-23T17:33:53  <arubi> ah, so is it correct to say maxblockweight supersedes maxblocksize?  congrats! :)
5142016-10-23T17:34:04  <arubi> bitcoin is officially over 9000
5152016-10-23T17:34:16  <sipa> not _over_ 9000.
5162016-10-23T17:34:58  <jl2012> arubi: if you set both, i guess it always take the effective lower one
5172016-10-23T17:35:11  <sipa> jl2012: if you set both, it respects both
5182016-10-23T17:35:25  <jl2012> make sense
5192016-10-23T17:36:49  <arubi> sipa, programmers of all people don't start counting at 1 :P
5202016-10-23T17:37:43  <sipa> arubi: ok, so we're at 8999 even.
5212016-10-23T17:39:08  <arubi> sipa, thanks :(
5222016-10-23T17:54:43  <arubi> \o/ jl2012 , sipa , thank you!  setting only weight=4m cleared a 607 inputs tx.  I'll play around with both size and weight, got a better idea what they mean now
5232016-10-23T17:54:44  *** achow101 has quit IRC
5242016-10-23T17:55:30  *** murch has quit IRC
5252016-10-23T18:00:14  *** laurentmt has quit IRC
5262016-10-23T18:03:24  <luke-jr> we are well over 9000 byte blocks, and even 9000 MB blockchain
5272016-10-23T18:03:26  * luke-jr ducks
5282016-10-23T18:11:33  *** Victorsueca has quit IRC
5292016-10-23T18:14:02  *** achow101 has joined #bitcoin-core-dev
5302016-10-23T18:18:22  *** justan0theruser has joined #bitcoin-core-dev
5312016-10-23T18:19:32  *** justanotheruser has quit IRC
5322016-10-23T18:20:23  *** aalex has quit IRC
5332016-10-23T18:28:25  *** aalex has joined #bitcoin-core-dev
5342016-10-23T18:36:39  *** MarcoFalke has quit IRC
5352016-10-23T18:38:35  *** n1ce has joined #bitcoin-core-dev
5362016-10-23T18:48:54  *** aalex has quit IRC
5372016-10-23T18:50:51  *** n1ce has quit IRC
5382016-10-23T18:53:24  *** aalex has joined #bitcoin-core-dev
5392016-10-23T18:59:06  *** achow101 has quit IRC
5402016-10-23T19:04:07  *** MarcoFalke has joined #bitcoin-core-dev
5412016-10-23T19:04:37  *** n1ce has joined #bitcoin-core-dev
5422016-10-23T19:11:08  *** n1ce has quit IRC
5432016-10-23T19:13:08  *** achow101 has joined #bitcoin-core-dev
5442016-10-23T19:29:14  *** aalex has quit IRC
5452016-10-23T19:33:25  *** aalex has joined #bitcoin-core-dev
5462016-10-23T19:40:06  *** jujumax has joined #bitcoin-core-dev
5472016-10-23T19:44:33  *** aalex has quit IRC
5482016-10-23T19:46:09  *** whphhg has quit IRC
5492016-10-23T19:48:24  *** aalex has joined #bitcoin-core-dev
5502016-10-23T19:48:59  *** whphhg has joined #bitcoin-core-dev
5512016-10-23T19:56:41  *** AaronvanW has joined #bitcoin-core-dev
5522016-10-23T19:56:41  *** AaronvanW has quit IRC
5532016-10-23T19:56:41  *** AaronvanW has joined #bitcoin-core-dev
5542016-10-23T20:05:33  *** e4xit has quit IRC
5552016-10-23T20:09:24  *** aalex has quit IRC
5562016-10-23T20:09:26  *** e4xit has joined #bitcoin-core-dev
5572016-10-23T20:16:08  *** MarcoFalke has left #bitcoin-core-dev
5582016-10-23T20:16:10  *** e4xit has quit IRC
5592016-10-23T20:17:18  *** e4xit has joined #bitcoin-core-dev
5602016-10-23T20:18:14  *** grindeltoshi is now known as andytoshi
5612016-10-23T20:18:22  *** aalex has joined #bitcoin-core-dev
5622016-10-23T20:24:10  *** aalex has quit IRC
5632016-10-23T20:24:34  *** aalex has joined #bitcoin-core-dev
5642016-10-23T20:29:57  *** jujumax has quit IRC
5652016-10-23T20:38:29  *** Guyver2 has quit IRC
5662016-10-23T20:49:38  *** AtashiCon has quit IRC
5672016-10-23T20:50:08  *** baldur has joined #bitcoin-core-dev
5682016-10-23T20:52:08  *** jujumax has joined #bitcoin-core-dev
5692016-10-23T21:17:51  *** AtashiCon has joined #bitcoin-core-dev
5702016-10-23T21:42:01  <GitHub52> [bitcoin] TheBlueMatt closed pull request #7903: Fix help text around importaddress and rename it to importscript (master...16-04-importaddress-helptext) https://github.com/bitcoin/bitcoin/pull/7903
5712016-10-23T22:24:50  *** n1ce has joined #bitcoin-core-dev
5722016-10-23T22:29:16  *** aalex has quit IRC
5732016-10-23T22:38:24  *** aalex has joined #bitcoin-core-dev
5742016-10-23T22:50:31  *** Cheeseo has joined #bitcoin-core-dev
5752016-10-23T22:50:35  *** Cheeseo has joined #bitcoin-core-dev
5762016-10-23T22:56:01  *** cdecker has quit IRC
5772016-10-23T22:58:14  *** Cheeseo has quit IRC
5782016-10-23T23:14:20  *** aalex has quit IRC
5792016-10-23T23:17:08  *** alpalp has quit IRC
5802016-10-23T23:18:26  *** aalex has joined #bitcoin-core-dev
5812016-10-23T23:35:30  *** d_t has quit IRC
5822016-10-23T23:40:44  *** Cheeseo has joined #bitcoin-core-dev
5832016-10-23T23:43:15  *** alpalp has joined #bitcoin-core-dev
5842016-10-23T23:46:10  *** alpalp has quit IRC
5852016-10-23T23:46:28  *** alpalp has joined #bitcoin-core-dev
5862016-10-23T23:46:29  *** alpalp has joined #bitcoin-core-dev
5872016-10-23T23:51:23  *** PRab has quit IRC
5882016-10-23T23:52:57  *** Cheeseo has quit IRC