1 2016-10-23T00:19:25  *** aalex has quit IRC
  2 2016-10-23T00:25:04  *** kadoban has quit IRC
  3 2016-10-23T00:33:35  *** aalex has joined #bitcoin-core-dev
  4 2016-10-23T00:37:51  *** alpalp has quit IRC
  5 2016-10-23T00:39:36  *** aalex has quit IRC
  6 2016-10-23T00:43:26  *** aalex has joined #bitcoin-core-dev
  7 2016-10-23T00:50:17  *** jl2012 has quit IRC
  8 2016-10-23T00:55:54  *** jl2012 has joined #bitcoin-core-dev
  9 2016-10-23T00:57:58  <gmaxwell> 2016-10-23 00:57:16 - Disconnect block: 1651.55ms
 10 2016-10-23T00:59:23  *** Ylbam has quit IRC
 11 2016-10-23T01:02:19  *** Ylbam has joined #bitcoin-core-dev
 12 2016-10-23T01:02:59  *** alpalp has joined #bitcoin-core-dev
 13 2016-10-23T01:04:24  *** jl2012 has quit IRC
 14 2016-10-23T01:10:07  <gmaxwell> :( actually the disconnectblock message undersates it, seeing on a fast machine 97 seconds between update tips while disconnecting blocks.
 15 2016-10-23T01:10:15  *** jl2012 has joined #bitcoin-core-dev
 16 2016-10-23T01:14:51  *** alpalp has quit IRC
 17 2016-10-23T01:15:09  *** alpalp has joined #bitcoin-core-dev
 18 2016-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
 19 2016-10-23T01:16:07  <gmaxwell> I'm trying to roll back to a couple months ago for some tests.
 20 2016-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. :)
 21 2016-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
 22 2016-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
 23 2016-10-23T01:21:58  <sipa> so it causes on average 1 disk lookup for each txid being rolled back
 24 2016-10-23T01:22:04  <sipa> over long periods of time
 25 2016-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...)
 26 2016-10-23T01:30:26  *** Giszmo has joined #bitcoin-core-dev
 27 2016-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.
 28 2016-10-23T01:32:12  <gmaxwell> not blindingly fast but fast enough that I wouldn't have commented (maybe 4 blocks per second or so)
 29 2016-10-23T01:32:39  <gmaxwell> sampling the backtrace seems to show a lot of it under UpdateForDescendants
 30 2016-10-23T01:40:23  *** laurentmt has joined #bitcoin-core-dev
 31 2016-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...
 32 2016-10-23T01:40:49  <gmaxwell> 2016-10-23 01:40:11 trying connection 0 lastseen=0.0hrs
 33 2016-10-23T01:40:51  <gmaxwell> 2016-10-23 01:40:11 Added connection peer=721
 34 2016-10-23T01:40:54  <gmaxwell> 2016-10-23 01:40:11 Added connection peer=722
 35 2016-10-23T01:40:57  <gmaxwell> 2016-10-23 01:40:11 send version message: version 70014, blocks=435494, us=[::]:0, peer=721
 36 2016-10-23T01:41:00  <gmaxwell> 2016-10-23 01:40:11 connection from accepted
 37 2016-10-23T01:41:02  <gmaxwell> 2016-10-23 01:40:11 sending: version (103 bytes) peer=721
 38 2016-10-23T01:41:05  <gmaxwell> 2016-10-23 01:40:11 received: version (103 bytes) peer=722
 39 2016-10-23T01:41:07  <gmaxwell> 2016-10-23 01:40:11 connected to self at, disconnecting
 40 2016-10-23T01:44:32  *** aalex has quit IRC
 41 2016-10-23T01:47:05  *** Ylbam has quit IRC
 42 2016-10-23T02:03:35  *** aalex has joined #bitcoin-core-dev
 43 2016-10-23T02:03:39  *** laurentmt has quit IRC
 44 2016-10-23T02:19:13  *** aalex has quit IRC
 45 2016-10-23T02:23:22  *** aalex has joined #bitcoin-core-dev
 46 2016-10-23T02:26:20  *** d_t has quit IRC
 47 2016-10-23T02:37:32  *** wasi has quit IRC
 48 2016-10-23T02:39:03  *** fengling has quit IRC
 49 2016-10-23T02:58:13  *** AtashiCon has joined #bitcoin-core-dev
 50 2016-10-23T03:09:11  *** wasi has joined #bitcoin-core-dev
 51 2016-10-23T03:09:21  *** cryptapus_afk has quit IRC
 52 2016-10-23T03:12:00  *** cryptapus has joined #bitcoin-core-dev
 53 2016-10-23T03:12:00  *** cryptapus has joined #bitcoin-core-dev
 54 2016-10-23T03:13:07  *** Alopex has quit IRC
 55 2016-10-23T03:14:12  *** Alopex has joined #bitcoin-core-dev
 56 2016-10-23T03:27:02  *** Alopex has quit IRC
 57 2016-10-23T03:28:07  *** Alopex has joined #bitcoin-core-dev
 58 2016-10-23T03:29:08  *** cryptapus is now known as cryptapus_afk
 59 2016-10-23T03:40:02  *** Alopex has quit IRC
 60 2016-10-23T03:41:07  *** Alopex has joined #bitcoin-core-dev
 61 2016-10-23T03:49:50  *** aalex has quit IRC
 62 2016-10-23T03:49:56  *** jacurn has joined #bitcoin-core-dev
 63 2016-10-23T03:50:53  *** alpalp has quit IRC
 64 2016-10-23T03:53:34  *** aalex has joined #bitcoin-core-dev
 65 2016-10-23T03:56:54  *** jacurn has quit IRC
 66 2016-10-23T03:59:06  *** jacurn has joined #bitcoin-core-dev
 67 2016-10-23T03:59:40  *** aalex has quit IRC
 68 2016-10-23T04:03:25  *** aalex has joined #bitcoin-core-dev
 69 2016-10-23T04:10:06  *** Alopex has quit IRC
 70 2016-10-23T04:10:24  *** davec has quit IRC
 71 2016-10-23T04:10:56  *** davec has joined #bitcoin-core-dev
 72 2016-10-23T04:11:11  *** Alopex has joined #bitcoin-core-dev
 73 2016-10-23T04:35:33  *** Giszmo has quit IRC
 74 2016-10-23T04:44:42  *** fengling has joined #bitcoin-core-dev
 75 2016-10-23T04:54:46  *** aalex has quit IRC
 76 2016-10-23T04:58:30  *** aalex has joined #bitcoin-core-dev
 77 2016-10-23T05:05:09  *** To7 has quit IRC
 78 2016-10-23T05:10:15  <luke-jr> is there some reason we're not using SVG images in the GUI?
 79 2016-10-23T05:40:21  *** fengling has quit IRC
 80 2016-10-23T05:43:06  *** fengling has joined #bitcoin-core-dev
 81 2016-10-23T05:57:37  *** fengling has quit IRC
 82 2016-10-23T06:00:02  *** dermoth has quit IRC
 83 2016-10-23T06:00:39  *** dermoth has joined #bitcoin-core-dev
 84 2016-10-23T06:03:05  *** fengling has joined #bitcoin-core-dev
 85 2016-10-23T06:30:21  <GitHub8> [bitcoin] luke-jr opened pull request #8996: Network activity toggle (master...networkactive) https://github.com/bitcoin/bitcoin/pull/8996
 86 2016-10-23T07:20:35  *** whphhg has quit IRC
 87 2016-10-23T07:23:25  *** whphhg has joined #bitcoin-core-dev
 88 2016-10-23T07:28:06  *** cdecker has joined #bitcoin-core-dev
 89 2016-10-23T07:29:20  *** aalex has quit IRC
 90 2016-10-23T07:33:28  *** aalex has joined #bitcoin-core-dev
 91 2016-10-23T07:42:59  *** Ylbam has joined #bitcoin-core-dev
 92 2016-10-23T07:48:22  *** Alopex has quit IRC
 93 2016-10-23T07:49:27  *** Alopex has joined #bitcoin-core-dev
 94 2016-10-23T07:56:13  *** baldur has quit IRC
 95 2016-10-23T08:04:01  *** Alopex has quit IRC
 96 2016-10-23T08:05:07  *** Alopex has joined #bitcoin-core-dev
 97 2016-10-23T09:14:20  *** aalex has quit IRC
 98 2016-10-23T09:16:52  *** justanotheruser has quit IRC
 99 2016-10-23T09:18:50  *** aalex has joined #bitcoin-core-dev
100 2016-10-23T09:27:40  *** justanotheruser has joined #bitcoin-core-dev
101 2016-10-23T09:56:04  <gmaxwell> why is getblocktemplate returning txn results for me on a 0.13.1rc1 node?
102 2016-10-23T09:56:39  <gmaxwell> I thought as soon as segwit was defined it needed the capability?
103 2016-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.
104 2016-10-23T09:57:27  <gmaxwell> Where did I desync?
105 2016-10-23T09:59:41  *** aalex has quit IRC
106 2016-10-23T10:04:21  *** aalex has joined #bitcoin-core-dev
107 2016-10-23T10:07:39  *** murch has joined #bitcoin-core-dev
108 2016-10-23T10:17:59  *** d_t has joined #bitcoin-core-dev
109 2016-10-23T10:27:01  *** sdaftuar_ has joined #bitcoin-core-dev
110 2016-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
111 2016-10-23T10:28:52  <sdaftuar_> There should be tests for the intended behavior in segwit.py or p2p-segwit.py
112 2016-10-23T10:30:34  <gmaxwell> oh thats okay too then!
113 2016-10-23T10:33:09  *** Alina-malina has quit IRC
114 2016-10-23T10:33:40  *** Alina-malina has joined #bitcoin-core-dev
115 2016-10-23T10:35:52  *** Alina-malina has quit IRC
116 2016-10-23T10:35:52  *** Alina-malina has joined #bitcoin-core-dev
117 2016-10-23T10:37:31  *** BCBot has quit IRC
118 2016-10-23T10:37:49  *** BCBot has joined #bitcoin-core-dev
119 2016-10-23T10:40:28  *** sdaftuar__ has joined #bitcoin-core-dev
120 2016-10-23T10:40:44  *** sdaftuar_ has quit IRC
121 2016-10-23T10:41:09  *** sdaftuar__ is now known as sdaftuar_
122 2016-10-23T10:41:59  *** n1ce has joined #bitcoin-core-dev
123 2016-10-23T10:44:52  *** ratoder has joined #bitcoin-core-dev
124 2016-10-23T10:49:14  *** n1ce has quit IRC
125 2016-10-23T10:51:01  *** sdaftuar_ has quit IRC
126 2016-10-23T10:52:20  *** sdaftuar_ has joined #bitcoin-core-dev
127 2016-10-23T11:01:05  <wumpus> luke-jr: because including the svg rendering engine would introduce an extra dependency, and also qt4/qt5 differences IIRC
128 2016-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
129 2016-10-23T11:02:24  <wumpus> tldr it's just a big risky change and things work pretty well as they do
130 2016-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.
131 2016-10-23T11:03:41  *** n1ce has joined #bitcoin-core-dev
132 2016-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
133 2016-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
134 2016-10-23T11:13:34  *** laurentmt has joined #bitcoin-core-dev
135 2016-10-23T11:13:49  *** laurentmt has quit IRC
136 2016-10-23T11:15:59  *** Guyver2 has joined #bitcoin-core-dev
137 2016-10-23T11:17:39  *** d_t has quit IRC
138 2016-10-23T11:18:11  *** achow101 has quit IRC
139 2016-10-23T11:18:44  *** n1ce has quit IRC
140 2016-10-23T11:21:40  *** n1ce has joined #bitcoin-core-dev
141 2016-10-23T11:28:19  *** laurentmt has joined #bitcoin-core-dev
142 2016-10-23T11:34:38  *** aalex has quit IRC
143 2016-10-23T11:35:07  *** testnet has joined #bitcoin-core-dev
144 2016-10-23T11:35:58  *** testnet has left #bitcoin-core-dev
145 2016-10-23T11:38:36  *** sdaftuar_ has quit IRC
146 2016-10-23T11:40:07  *** sdaftuar_ has joined #bitcoin-core-dev
147 2016-10-23T11:43:32  *** aalex has joined #bitcoin-core-dev
148 2016-10-23T11:56:30  *** aalex has quit IRC
149 2016-10-23T11:58:23  *** aalex has joined #bitcoin-core-dev
150 2016-10-23T12:00:04  *** sdaftuar_ has quit IRC
151 2016-10-23T12:00:05  *** sdaftuar__ has joined #bitcoin-core-dev
152 2016-10-23T12:03:28  *** belcher has quit IRC
153 2016-10-23T12:04:16  *** aalex has quit IRC
154 2016-10-23T12:05:37  *** belcher has joined #bitcoin-core-dev
155 2016-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.
156 2016-10-23T12:06:41  <nsh>  NCC-2016-015 - Out-of-bounds Read in Boost date Class #1459 - https://github.com/zcash/zcash/issues/1459
157 2016-10-23T12:06:50  <nsh>  NCC-2016-008 - Potential uninitialized reads #1464  - https://github.com/zcash/zcash/issues/1464
158 2016-10-23T12:08:23  *** aalex has joined #bitcoin-core-dev
159 2016-10-23T12:08:43  *** jtimon has joined #bitcoin-core-dev
160 2016-10-23T12:09:19  <wumpus> I've seen the report, but thanks for the update
161 2016-10-23T12:09:43  <wumpus> the respective fixes haven't made it upstream yet
162 2016-10-23T12:10:36  * nsh nods
163 2016-10-23T12:19:24  *** d_t has joined #bitcoin-core-dev
164 2016-10-23T12:19:36  *** aalex has quit IRC
165 2016-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
166 2016-10-23T12:22:55  <jtimon> I know btcdrak hates "cascading PRs", but I think it makes sense here
167 2016-10-23T12:23:22  *** aalex has joined #bitcoin-core-dev
168 2016-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
169 2016-10-23T12:23:49  <btcdrak> nice!
170 2016-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
171 2016-10-23T12:24:58  <jtimon> they can -chain=custom -chainpetname=lightning, new chain
172 2016-10-23T12:25:46  <btcdrak> I'm ok with two PRs. blocksign will be rebased on the first PR anyway right?
173 2016-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
174 2016-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
175 2016-10-23T12:28:00  <jtimon> reading from a file was a later addition, but it was like 4 lines extra
176 2016-10-23T12:29:52  *** mol is now known as moli
177 2016-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
178 2016-10-23T12:31:44  <btcdrak> I think json makes sense, there are potentially a lot of chain params to configure.
179 2016-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)
180 2016-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
181 2016-10-23T12:35:06  <jtimon> I don't think CChainParams::UpdateFromArgs() will get smaller by using json
182 2016-10-23T12:36:18  *** n1ce has quit IRC
183 2016-10-23T12:36:38  <btcdrak> It's also easier to share chain details with a json file.
184 2016-10-23T12:37:27  *** n1ce has joined #bitcoin-core-dev
185 2016-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
186 2016-10-23T12:38:42  <jtimon> he mentions Params().GetConsensus().getdarnaninterger() inside a loop
187 2016-10-23T12:39:09  <wumpus> let's bury that part of the discussion please
188 2016-10-23T12:39:16  <wumpus> both gmaxwell and me went out of line there
189 2016-10-23T12:39:30  <wumpus> blame it on stress, or whatever
190 2016-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
191 2016-10-23T12:42:00  <jtimon>  needs, it should take darninteger directly as parameter instead of the whole CChainParams
192 2016-10-23T12:42:25  <jtimon> ok, not trying to revive any fire, just trying to make sure we're on the same page
193 2016-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
194 2016-10-23T12:43:02  <wumpus> right
195 2016-10-23T12:43:21  <jtimon> btcdrak: how is sharing mychain.json any easier than sharing mychain.conf ?
196 2016-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 :)
197 2016-10-23T12:44:31  <gmaxwell> putting things in a file does not make them configurable.
198 2016-10-23T12:44:41  <gmaxwell> please keep that in mind.
199 2016-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
200 2016-10-23T12:44:46  <jtimon> wumpus: what are your thoughts on json vs conf since you brought that up?
201 2016-10-23T12:44:48  *** n1ce has quit IRC
202 2016-10-23T12:44:56  <gmaxwell> many of our constants tie deeply into algorithims and protocol assumptions.
203 2016-10-23T12:44:57  <jtimon> I see
204 2016-10-23T12:44:59  <btcdrak> what wumpus said
205 2016-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
206 2016-10-23T12:45:44  <wumpus> this doesn't mean the entire algorithm should be micro-manageable though the configuration file
207 2016-10-23T12:45:58  <wumpus> unless you want to replace it with JITed LUA or so, but that's clearly not a goal here
208 2016-10-23T12:46:36  <gmaxwell> yep.
209 2016-10-23T12:46:57  <gmaxwell> (as I said, just something to keep in mind.)
210 2016-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"
211 2016-10-23T12:47:15  <gmaxwell>         fRequireStandard = false;
212 2016-10-23T12:47:21  <gmaxwell> sure
213 2016-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)
214 2016-10-23T12:48:20  <wumpus> well they are constants after reading them from the configuration file
215 2016-10-23T12:48:30  <wumpus> they don't change at runtime, that would be madness
216 2016-10-23T12:48:42  <jtimon> the way I was planning to expose the blocksigning was through a variable like -blocksignscript, maybe a boolean too
217 2016-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...
218 2016-10-23T12:49:01  <wumpus> leveL
219 2016-10-23T12:49:29  <jtimon> wumpus: right, they init once and then ChainParams should be always passed as const
220 2016-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.
221 2016-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
222 2016-10-23T12:50:36  <jtimon> I fear a cleanup may require testnet4 and regtest2
223 2016-10-23T12:50:55  <gmaxwell> I am wtfing at regtest2.
224 2016-10-23T12:51:14  <wumpus> regtest2 makes no sense
225 2016-10-23T12:51:33  <gmaxwell> but duh sure, improving things may mean some incompatiblities. thats fine.
226 2016-10-23T12:51:34  <wumpus> there is no shared 'regtest' network
227 2016-10-23T12:52:07  <wumpus> although compatibility between versions may be useful for comparison testing
228 2016-10-23T12:52:10  <wumpus> (!)
229 2016-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
230 2016-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.
231 2016-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
232 2016-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
233 2016-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)
234 2016-10-23T12:55:45  <wumpus> well it will always need a special case for PoW, the question is can we do better than testnet3
235 2016-10-23T12:56:17  <jtimon> not sure I understand gmaxwell's point about the bit mask
236 2016-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.
237 2016-10-23T12:57:20  <gmaxwell> regtest's 'special casing' requires difficulty go below one, which causes a large amount of divergence in the code.
238 2016-10-23T12:57:57  <jtimon> wumpus: maybe a different difficulty filter would help more, but that's strong special-casing too
239 2016-10-23T12:58:02  <wumpus> I sometimes wonder why doesn't just ignore PoW completely
240 2016-10-23T12:58:06  <wumpus> regtest*
241 2016-10-23T12:58:21  <wumpus> that would mean the PoW checking is regression tested less, ofcourse
242 2016-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
243 2016-10-23T12:58:52  <jtimon> gmaxwell: I see, what about making regtest just always pass the pow check?
244 2016-10-23T12:59:10  <gmaxwell> that could have been better accomplished with a if (params->weakpow) memset(blockhash,0,4);  in the pow comparison.
245 2016-10-23T12:59:28  <jtimon> I see
246 2016-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.
247 2016-10-23T13:00:06  <wumpus> yes, that would make sense
248 2016-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
249 2016-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.
250 2016-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
251 2016-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.
252 2016-10-23T13:01:42  *** n1ce has joined #bitcoin-core-dev
253 2016-10-23T13:01:48  <jtimon> gmaxwell: right, so maybe after adding signed blocks it makes more sense to remove testnet3's mindif special case
254 2016-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)
255 2016-10-23T13:02:07  <gmaxwell> jtimon: potentially.
256 2016-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.
257 2016-10-23T13:03:55  *** n1ce2 has joined #bitcoin-core-dev
258 2016-10-23T13:04:25  <jtimon> right
259 2016-10-23T13:05:09  *** instagibbs has joined #bitcoin-core-dev
260 2016-10-23T13:06:16  *** n1ce has quit IRC
261 2016-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)
262 2016-10-23T13:06:26  *** d_t has quit IRC
263 2016-10-23T13:07:00  <jtimon> previously thought of union, but even that would be a hit if you cannot disable it at compile time
264 2016-10-23T13:07:22  <jtimon> how does that sound?
265 2016-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)
266 2016-10-23T13:08:20  <wumpus> where would be the hit in memory requirements? header stoage?
267 2016-10-23T13:08:29  <jtimon> yep, header storage
268 2016-10-23T13:09:12  <wumpus> ok yes bleh, that structure is already too fat
269 2016-10-23T13:09:12  <jtimon> in elements we just remove nBits and nNonce, but obviously we cannot do that here
270 2016-10-23T13:09:16  *** n1ce2 has quit IRC
271 2016-10-23T13:09:19  *** n1ce has joined #bitcoin-core-dev
272 2016-10-23T13:09:42  <jtimon> so ack on compile time option for signed blocks?
273 2016-10-23T13:09:44  <wumpus> using an union sounds better then
274 2016-10-23T13:10:02  <wumpus> well compile time option does mean it cannot be used for the normal tests
275 2016-10-23T13:10:16  <wumpus> and probably won't be enabled by default in releases
276 2016-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?
277 2016-10-23T13:10:48  <jtimon> mhmm, if you allow the option you compile the tests that need it too?
278 2016-10-23T13:11:02  <sipa> i don't think you can use a union with non-trivial C++ types in it
279 2016-10-23T13:11:08  <jtimon> only devs I was assuming
280 2016-10-23T13:11:22  <wumpus> this is about trivial C++ types such as ints right? nBits, nNonce etc
281 2016-10-23T13:11:25  <sipa> c+11 relaxed the requirements a bit, though
282 2016-10-23T13:11:44  <wumpus> if not that's a dangerous minefile
283 2016-10-23T13:11:46  <wumpus> minefield*
284 2016-10-23T13:11:49  <sipa> for block signing the signature is a CScript
285 2016-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?
286 2016-10-23T13:11:56  <sipa> in CBlockHeader
287 2016-10-23T13:12:09  <wumpus> that needs to be stored for every block, permanently?
288 2016-10-23T13:12:22  <sipa> yes, instead of a nonce you have a signature
289 2016-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
290 2016-10-23T13:12:45  <wumpus> gmaxwell: yes
291 2016-10-23T13:12:56  <gmaxwell> well technically it's a block witness...
292 2016-10-23T13:13:16  <gmaxwell> segregate all the witnesses. :P
293 2016-10-23T13:13:18  <wumpus> that makes sense; with using an union you could even take the additional memory requirement to 0
294 2016-10-23T13:13:28  <wumpus> union a pointer with nBits,nNonce
295 2016-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
296 2016-10-23T13:14:24  <wumpus> (i mean the additonal memory requirement when not using the feature, which is what we care about here)
297 2016-10-23T13:14:58  <jtimon> this is it's actually in both CBlockHeader and CBlockIndex
298 2016-10-23T13:15:58  <jtimon> wumpus: yeah, at a minimum union a pointer would be an extra pointer per block, that's my worry
299 2016-10-23T13:16:18  <sipa> ah, it seems you can have non-trivial classes in a union now
300 2016-10-23T13:16:36  <sipa> but it requires placement new and explicit destructor invocations
301 2016-10-23T13:16:48  <jtimon> yep IntOrScript seemed to compile
302 2016-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?
303 2016-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)
304 2016-10-23T13:18:20  <sipa> wumpus: nBits is the "challenge" which can in theory also be replaced with a "block scriptPubKey"
305 2016-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
306 2016-10-23T13:18:41  <sipa> wumpus: so you can allow rules about how the signer(s) can change over time
307 2016-10-23T13:18:50  <wumpus> sipa: okay
308 2016-10-23T13:18:55  <sipa> however, that seems overkill here
309 2016-10-23T13:18:59  <gmaxwell> a bit out of scope here but not incompatable.
310 2016-10-23T13:19:01  <jtimon> sipa: right, but we can also remove that if the challenge script is going to be always constant
311 2016-10-23T13:19:14  <sipa> as the block challenge can just be a chain wide constant as jtimon says
312 2016-10-23T13:19:18  <gmaxwell> the union is the 64 bits of nbits+nonce or a pointer to an extension datastructure.
313 2016-10-23T13:20:04  <jtimon> wumpus: I see, yeah, that's better and removes the need for the compile time option, thanks!
314 2016-10-23T13:20:37  <sipa> perhaps we want the union to be between {nBits,nNonce} on the onenhand, and CScript *scriptSig on the other
315 2016-10-23T13:20:54  <wumpus> sipa: that's what both gmaxwell and me are saying , yes :)
316 2016-10-23T13:21:09  <sipa> note the *
317 2016-10-23T13:21:21  <wumpus> I had assumed the *
318 2016-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
319 2016-10-23T13:21:38  <wumpus> I have no clue what the size of CScript is, but I'd guess it's larger than 8
320 2016-10-23T13:21:53  <wumpus> so yes that should be a pointer
321 2016-10-23T13:21:54  <sipa> 24
322 2016-10-23T13:22:01  <sipa> on 64-bit
323 2016-10-23T13:22:15  <sipa> actually, it's a prevector, so much larger
324 2016-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
325 2016-10-23T13:22:53  <sipa> for some reason i am very scared of using unions
326 2016-10-23T13:23:12  <wumpus> in this case the way it is used depends on a global setting, so I'm okay with it
327 2016-10-23T13:23:21  <wumpus> I'm scared of tagged/per-case unions though
328 2016-10-23T13:23:25  <jtimon> sipa: yeah that motivated my run to the compile option too
329 2016-10-23T13:23:43  <sipa> but the CBlockHeader destructor will need to know which of the two cases is being used
330 2016-10-23T13:23:48  <sipa> that's very ugly
331 2016-10-23T13:23:59  <sipa> how will it know? a global?
332 2016-10-23T13:24:08  <wumpus> maybe have two different CBlockHeader types?
333 2016-10-23T13:24:12  <jtimon> oh, right, that's ugly
334 2016-10-23T13:24:25  <jtimon> a static field in CBlockHeader maybe
335 2016-10-23T13:24:34  <sipa> jtimon: that's just a global
336 2016-10-23T13:24:43  <wumpus> CPoWBlockHeader CSignedBlockHeader .. but yeah that moves the problem up :)
337 2016-10-23T13:24:44  <jtimon> sipa: yep
338 2016-10-23T13:24:56  <sipa> wumpus: then you need to templatize all the block logoc
339 2016-10-23T13:25:07  <jtimon> wumpus: CPoWBlockHeader CSignedBlockHeader is way too disruptive
340 2016-10-23T13:25:13  <wumpus> yes...
341 2016-10-23T13:25:32  <wumpus> no, never mind, that would be stupid in c++ :)
342 2016-10-23T13:26:00  <jtimon> I mean, it's CBlockHeader<proofType> or whatever, but still, not an option I think
343 2016-10-23T13:26:08  <wumpus> this is pretty much the place where the inflexibilty of C languages starts to show
344 2016-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.
345 2016-10-23T13:27:14  <wumpus> either you have to template everything, or do some crazy union hack, both seem like bad choices...
346 2016-10-23T13:27:38  <sipa> it is in fact much easier (in terms of code changes) to make it tagged
347 2016-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
348 2016-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.
349 2016-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 :)
350 2016-10-23T13:28:23  <sipa> wumpus: i know, but far less than just always having both cases
351 2016-10-23T13:28:34  <gmaxwell> so the extradata structure would own its own memory and be responsable for freeing it on shutdown.
352 2016-10-23T13:28:47  <sipa> gmaxwell: the extra data is not just in CBlockIndex
353 2016-10-23T13:28:48  <wumpus> gmaxwell: yes, indeed
354 2016-10-23T13:29:06  <sipa> it's part of every CBlockHeader we send and receive
355 2016-10-23T13:29:25  <jtimon> I think the best candidates are union and a compile time option
356 2016-10-23T13:29:28  <sipa> it sounds very hard to avoid a memory leak if you do not deal with deletion
357 2016-10-23T13:29:39  <jtimon> right, plus CBlock extends from CBlockHeader
358 2016-10-23T13:30:13  <wumpus> what I like least about this is that it changes consensus data structures
359 2016-10-23T13:30:34  <wumpus> for something that is just for testing
360 2016-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)
361 2016-10-23T13:32:43  <gmaxwell> Compile time option would greatly diminish the utility of this. (especially considering the size of our static binaries)
362 2016-10-23T13:32:56  <wumpus> with compile time option you could *guarantee* that the normal case remains unchanged
363 2016-10-23T13:33:13  <gmaxwell> Yes.
364 2016-10-23T13:33:16  <gmaxwell> at that point, might as well just make it a seperate repo and resync to core periodically, I think.
365 2016-10-23T13:33:23  <wumpus> which is, imo, the only acceptable way to do this
366 2016-10-23T13:33:45  <wumpus> yes, probably. It's effectively an altcoin at that point :)
367 2016-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.
368 2016-10-23T13:35:00  * wumpus wants pluggable consensus libraries
369 2016-10-23T13:35:37  <wumpus> yes, it seems it's not practically doable at this time
370 2016-10-23T13:35:53  <wumpus> in our current codebase and structure
371 2016-10-23T13:38:09  <jtimon> well, I will try with the union and without compile time option and see how it looks like
372 2016-10-23T13:39:14  *** n1ce has quit IRC
373 2016-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
374 2016-10-23T13:40:18  <sipa> jtimon: agree
375 2016-10-23T13:40:46  <sipa> i was surprised there was not a resurgence of coingen like sites after chainparams was merged :)
376 2016-10-23T13:42:20  *** kadoban has joined #bitcoin-core-dev
377 2016-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
378 2016-10-23T13:44:25  <wumpus> proabably coingen didn't work too well as a business model
379 2016-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 :)
380 2016-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
381 2016-10-23T13:45:46  <wumpus> yes
382 2016-10-23T13:45:53  <sipa> sure, not having it integrated inline may hurt adoption of such a chain
383 2016-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
384 2016-10-23T13:46:28  <sipa> *to go through
385 2016-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
386 2016-10-23T13:51:29  <gmaxwell> not at all.
387 2016-10-23T13:53:22  *** paveljanik has joined #bitcoin-core-dev
388 2016-10-23T13:54:18  *** aalex has quit IRC
389 2016-10-23T13:55:11  <sipa> chainparams was only in june 2013
390 2016-10-23T13:56:10  <sipa> before that, we just had "if (fTestnet)" all over the place
391 2016-10-23T13:57:29  <sipa> and testnet itself was october 2010, 2 months before i ever looked at the code
392 2016-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
393 2016-10-23T14:00:53  *** sdaftuar__ has quit IRC
394 2016-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).
395 2016-10-23T14:02:14  <wumpus> yes :)
396 2016-10-23T14:02:52  <sipa> many earlier ones forked off namecoin, was was based on 0.3.24 afaik
397 2016-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.
398 2016-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 :)
399 2016-10-23T14:08:30  *** aalex has joined #bitcoin-core-dev
400 2016-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.
401 2016-10-23T14:12:06  *** alpalp has joined #bitcoin-core-dev
402 2016-10-23T14:13:02  *** d9b4bef9 has quit IRC
403 2016-10-23T14:14:07  *** d9b4bef9 has joined #bitcoin-core-dev
404 2016-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
405 2016-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
406 2016-10-23T14:17:47  <luke-jr> wumpus: go the organization settings
407 2016-10-23T14:17:55  <luke-jr> there's a "tab" for banning users
408 2016-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
409 2016-10-23T14:25:39  <sipa> it may be just someone who has no clue
410 2016-10-23T14:25:57  *** MarcoFalke has joined #bitcoin-core-dev
411 2016-10-23T14:28:52  <sipa> but if they're a nuisance and not responsive to comments, yes ban
412 2016-10-23T14:29:13  *** aalex has quit IRC
413 2016-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
414 2016-10-23T14:32:05  <wumpus> they can still download the source, or check it out
415 2016-10-23T14:32:10  <wumpus> which is great
416 2016-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
417 2016-10-23T14:33:23  *** aalex has joined #bitcoin-core-dev
418 2016-10-23T14:40:21  *** MarcoFalke has quit IRC
419 2016-10-23T14:40:52  *** MarcoFalke has joined #bitcoin-core-dev
420 2016-10-23T14:41:55  *** alpalp has quit IRC
421 2016-10-23T14:42:12  *** alpalp has joined #bitcoin-core-dev
422 2016-10-23T14:42:13  *** alpalp has joined #bitcoin-core-dev
423 2016-10-23T14:44:16  *** aalex has quit IRC
424 2016-10-23T14:44:35  *** achow101 has joined #bitcoin-core-dev
425 2016-10-23T14:46:46  *** MarcoFalke has quit IRC
426 2016-10-23T14:47:00  *** MarcoFalke has joined #bitcoin-core-dev
427 2016-10-23T14:48:25  *** aalex has joined #bitcoin-core-dev
428 2016-10-23T14:54:25  *** aalex has quit IRC
429 2016-10-23T14:57:24  *** MarcoFalke has quit IRC
430 2016-10-23T14:57:38  *** MarcoFalke has joined #bitcoin-core-dev
431 2016-10-23T14:58:26  *** aalex has joined #bitcoin-core-dev
432 2016-10-23T15:00:25  *** alpalp has quit IRC
433 2016-10-23T15:09:02  *** MarcoFalke has quit IRC
434 2016-10-23T15:09:30  *** MarcoFalke has joined #bitcoin-core-dev
435 2016-10-23T15:14:55  *** MarcoFalke has quit IRC
436 2016-10-23T15:15:42  *** alpalp has joined #bitcoin-core-dev
437 2016-10-23T15:15:43  *** alpalp has joined #bitcoin-core-dev
438 2016-10-23T15:15:59  *** MarcoFalke has joined #bitcoin-core-dev
439 2016-10-23T15:16:10  *** Giszmo has joined #bitcoin-core-dev
440 2016-10-23T15:26:09  *** alpalp has quit IRC
441 2016-10-23T15:40:11  *** To7 has joined #bitcoin-core-dev
442 2016-10-23T15:40:19  *** aalex has quit IRC
443 2016-10-23T15:43:38  *** aalex has joined #bitcoin-core-dev
444 2016-10-23T16:21:00  *** AaronvanW has quit IRC
445 2016-10-23T16:21:08  *** alpalp has joined #bitcoin-core-dev
446 2016-10-23T16:33:57  *** aalex has quit IRC
447 2016-10-23T16:38:45  *** aalex has joined #bitcoin-core-dev
448 2016-10-23T16:39:07  *** Alina-malina has quit IRC
449 2016-10-23T16:45:20  *** Alina-malina has joined #bitcoin-core-dev
450 2016-10-23T16:47:25  *** Alina-malina has quit IRC
451 2016-10-23T16:47:25  *** Alina-malina has joined #bitcoin-core-dev
452 2016-10-23T17:00:59  *** d_t has joined #bitcoin-core-dev
453 2016-10-23T17:06:11  *** MarcoFalke has quit IRC
454 2016-10-23T17:06:17  *** MarcoFalke has joined #bitcoin-core-dev
455 2016-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
456 2016-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.
457 2016-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.
458 2016-10-23T17:07:14  <arubi> 606 and below*
459 2016-10-23T17:08:12  <achow101> arubi: is it related to https://github.com/bitcoin/bitcoin/pull/8499#issuecomment-252420342
460 2016-10-23T17:08:25  <achow101> the new policy limits for p2wsh?
461 2016-10-23T17:09:08  <arubi> is 15 of 15 multisig affected?  looking
462 2016-10-23T17:12:28  <sipa> how large is the 607 p2wsh output?
463 2016-10-23T17:12:56  <arubi> well the script is 513 bytes
464 2016-10-23T17:13:35  <arubi> signatures + pushes.. 1110 bytes?  I think
465 2016-10-23T17:13:46  <arubi> can check, moment
466 2016-10-23T17:14:02  <sipa> eh, i mean the size and weight of the transaction that does not get mined
467 2016-10-23T17:14:47  <arubi> oh heh, sec.
468 2016-10-23T17:15:14  <arubi> size": 999515, vsize": 268602,
469 2016-10-23T17:16:04  <jl2012> vsize over 100000 is nonstandard?
470 2016-10-23T17:16:45  <arubi> hm, so it's relayed around because regtest?  then not mined because it's too exotic?
471 2016-10-23T17:17:25  <jl2012> not tested. but if it is accepted to mempool, it should also be mined?
472 2016-10-23T17:17:47  <sipa> yes, being relayd/accepted but not mined sounds like a bug
473 2016-10-23T17:18:24  <jl2012> arubi: are you sure your blocks are synced between the 2 nodes?
474 2016-10-23T17:18:31  <arubi> yep
475 2016-10-23T17:18:45  <jl2012> have you tried to do everything with only 1 node?
476 2016-10-23T17:19:09  <arubi> I can try, though neither will mine it
477 2016-10-23T17:19:12  <arubi> (trying)
478 2016-10-23T17:19:36  <jl2012> are you doing it by hand or automated?
479 2016-10-23T17:20:02  <jl2012> if automated, would you please share the script?
480 2016-10-23T17:20:19  <arubi> a lot is automated, the script is a monstrosity
481 2016-10-23T17:20:39  <arubi> I'm rewriting it, making it useful for more complex stuff.  mast in mind
482 2016-10-23T17:21:20  <arubi> maybe it's time..  I'll get a gitlab account tomorrow and put it there
483 2016-10-23T17:22:35  <jl2012> size: 999515 is for 606 or 607 inputs?
484 2016-10-23T17:23:11  <arubi> 607
485 2016-10-23T17:23:17  <jl2012> i think there is a setting about the block size/weight, forgot the name
486 2016-10-23T17:23:26  <jl2012> maybe you hit the limit
487 2016-10-23T17:23:39  <arubi> maxblocksize=1m , maxblockweight=4m with my nodes
488 2016-10-23T17:23:56  <jl2012> try with only maxblockweight=4m ?
489 2016-10-23T17:23:57  <arubi> unless weight can go higher, I didn't assume it could
490 2016-10-23T17:24:07  <arubi> hm.  alright
491 2016-10-23T17:24:17  <sipa> do you literally set '1m' as value?
492 2016-10-23T17:24:20  <arubi> oh no no
493 2016-10-23T17:24:25  <jl2012> i think the problem is maxblocksize=1m
494 2016-10-23T17:24:26  <sipa> ok, just making sure
495 2016-10-23T17:24:41  <sipa> yes, maxblocksize=1000000 may be too much
496 2016-10-23T17:24:53  <arubi> yea no worries.  so just not set it?
497 2016-10-23T17:24:54  <sipa> i think we always stay 1000 bytes below the limit
498 2016-10-23T17:24:54  <jl2012> too small, you mean?
499 2016-10-23T17:25:09  <sipa> you can set both weight and size to 4000000
500 2016-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
501 2016-10-23T17:26:21  <sipa> maxblocksize is about the total serialized size, including witness
502 2016-10-23T17:27:36  <arubi> and weight?  seems like the default value for maxsize is 750000, so maybe that's why I assumed
503 2016-10-23T17:28:22  <arubi> and default weight is 3m so really seemed like the x4 factor at the time, now I remember
504 2016-10-23T17:28:34  <sipa> weight is (total_size + 3*size_without_witness)
505 2016-10-23T17:30:40  <arubi> I see, thanks.  jl2012, single node same behavior.  trying w/ setting maxsize to 4m as well
506 2016-10-23T17:31:06  <jl2012> quite sure it's because of the max size
507 2016-10-23T17:31:13  <jl2012> i tried before
508 2016-10-23T17:32:12  <arubi> you mean without setting it at all, or setting it to 4m?
509 2016-10-23T17:32:49  <sipa> if you only specify maxblockweight, the maxblocksize is implicitly 4M
510 2016-10-23T17:32:53  <jl2012> i think i just set max weight
511 2016-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
512 2016-10-23T17:33:18  <jl2012> #9000
513 2016-10-23T17:33:53  <arubi> ah, so is it correct to say maxblockweight supersedes maxblocksize?  congrats! :)
514 2016-10-23T17:34:04  <arubi> bitcoin is officially over 9000
515 2016-10-23T17:34:16  <sipa> not _over_ 9000.
516 2016-10-23T17:34:58  <jl2012> arubi: if you set both, i guess it always take the effective lower one
517 2016-10-23T17:35:11  <sipa> jl2012: if you set both, it respects both
518 2016-10-23T17:35:25  <jl2012> make sense
519 2016-10-23T17:36:49  <arubi> sipa, programmers of all people don't start counting at 1 :P
520 2016-10-23T17:37:43  <sipa> arubi: ok, so we're at 8999 even.
521 2016-10-23T17:39:08  <arubi> sipa, thanks :(
522 2016-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
523 2016-10-23T17:54:44  *** achow101 has quit IRC
524 2016-10-23T17:55:30  *** murch has quit IRC
525 2016-10-23T18:00:14  *** laurentmt has quit IRC
526 2016-10-23T18:03:24  <luke-jr> we are well over 9000 byte blocks, and even 9000 MB blockchain
527 2016-10-23T18:03:26  * luke-jr ducks
528 2016-10-23T18:11:33  *** Victorsueca has quit IRC
529 2016-10-23T18:14:02  *** achow101 has joined #bitcoin-core-dev
530 2016-10-23T18:18:22  *** justan0theruser has joined #bitcoin-core-dev
531 2016-10-23T18:19:32  *** justanotheruser has quit IRC
532 2016-10-23T18:20:23  *** aalex has quit IRC
533 2016-10-23T18:28:25  *** aalex has joined #bitcoin-core-dev
534 2016-10-23T18:36:39  *** MarcoFalke has quit IRC
535 2016-10-23T18:38:35  *** n1ce has joined #bitcoin-core-dev
536 2016-10-23T18:48:54  *** aalex has quit IRC
537 2016-10-23T18:50:51  *** n1ce has quit IRC
538 2016-10-23T18:53:24  *** aalex has joined #bitcoin-core-dev
539 2016-10-23T18:59:06  *** achow101 has quit IRC
540 2016-10-23T19:04:07  *** MarcoFalke has joined #bitcoin-core-dev
541 2016-10-23T19:04:37  *** n1ce has joined #bitcoin-core-dev
542 2016-10-23T19:11:08  *** n1ce has quit IRC
543 2016-10-23T19:13:08  *** achow101 has joined #bitcoin-core-dev
544 2016-10-23T19:29:14  *** aalex has quit IRC
545 2016-10-23T19:33:25  *** aalex has joined #bitcoin-core-dev
546 2016-10-23T19:40:06  *** jujumax has joined #bitcoin-core-dev
547 2016-10-23T19:44:33  *** aalex has quit IRC
548 2016-10-23T19:46:09  *** whphhg has quit IRC
549 2016-10-23T19:48:24  *** aalex has joined #bitcoin-core-dev
550 2016-10-23T19:48:59  *** whphhg has joined #bitcoin-core-dev
551 2016-10-23T19:56:41  *** AaronvanW has joined #bitcoin-core-dev
552 2016-10-23T19:56:41  *** AaronvanW has quit IRC
553 2016-10-23T19:56:41  *** AaronvanW has joined #bitcoin-core-dev
554 2016-10-23T20:05:33  *** e4xit has quit IRC
555 2016-10-23T20:09:24  *** aalex has quit IRC
556 2016-10-23T20:09:26  *** e4xit has joined #bitcoin-core-dev
557 2016-10-23T20:16:08  *** MarcoFalke has left #bitcoin-core-dev
558 2016-10-23T20:16:10  *** e4xit has quit IRC
559 2016-10-23T20:17:18  *** e4xit has joined #bitcoin-core-dev
560 2016-10-23T20:18:14  *** grindeltoshi is now known as andytoshi
561 2016-10-23T20:18:22  *** aalex has joined #bitcoin-core-dev
562 2016-10-23T20:24:10  *** aalex has quit IRC
563 2016-10-23T20:24:34  *** aalex has joined #bitcoin-core-dev
564 2016-10-23T20:29:57  *** jujumax has quit IRC
565 2016-10-23T20:38:29  *** Guyver2 has quit IRC
566 2016-10-23T20:49:38  *** AtashiCon has quit IRC
567 2016-10-23T20:50:08  *** baldur has joined #bitcoin-core-dev
568 2016-10-23T20:52:08  *** jujumax has joined #bitcoin-core-dev
569 2016-10-23T21:17:51  *** AtashiCon has joined #bitcoin-core-dev
570 2016-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
571 2016-10-23T22:24:50  *** n1ce has joined #bitcoin-core-dev
572 2016-10-23T22:29:16  *** aalex has quit IRC
573 2016-10-23T22:38:24  *** aalex has joined #bitcoin-core-dev
574 2016-10-23T22:50:31  *** Cheeseo has joined #bitcoin-core-dev
575 2016-10-23T22:50:35  *** Cheeseo has joined #bitcoin-core-dev
576 2016-10-23T22:56:01  *** cdecker has quit IRC
577 2016-10-23T22:58:14  *** Cheeseo has quit IRC
578 2016-10-23T23:14:20  *** aalex has quit IRC
579 2016-10-23T23:17:08  *** alpalp has quit IRC
580 2016-10-23T23:18:26  *** aalex has joined #bitcoin-core-dev
581 2016-10-23T23:35:30  *** d_t has quit IRC
582 2016-10-23T23:40:44  *** Cheeseo has joined #bitcoin-core-dev
583 2016-10-23T23:43:15  *** alpalp has joined #bitcoin-core-dev
584 2016-10-23T23:46:10  *** alpalp has quit IRC
585 2016-10-23T23:46:28  *** alpalp has joined #bitcoin-core-dev
586 2016-10-23T23:46:29  *** alpalp has joined #bitcoin-core-dev
587 2016-10-23T23:51:23  *** PRab has quit IRC
588 2016-10-23T23:52:57  *** Cheeseo has quit IRC