1 2016-04-06T00:05:34  *** aureianimus has quit IRC
  2 2016-04-06T00:09:31  <Luke-Jr> now git just needs to allow signatures after-the-commit
  3 2016-04-06T00:19:30  *** aureianimus has joined #bitcoin-core-dev
  4 2016-04-06T00:42:47  *** laurentmt has joined #bitcoin-core-dev
  5 2016-04-06T00:43:04  *** frankenmint has quit IRC
  6 2016-04-06T00:48:04  *** laurentmt has quit IRC
  7 2016-04-06T01:01:03  *** Ylbam has quit IRC
  8 2016-04-06T01:34:35  *** xiangfu has joined #bitcoin-core-dev
  9 2016-04-06T01:38:31  *** jtimon has quit IRC
 10 2016-04-06T01:53:02  *** xabbix has quit IRC
 11 2016-04-06T01:54:17  *** xabbix has joined #bitcoin-core-dev
 12 2016-04-06T01:54:17  *** xabbix has joined #bitcoin-core-dev
 13 2016-04-06T02:00:06  *** dermoth has quit IRC
 14 2016-04-06T02:01:00  *** dermoth has joined #bitcoin-core-dev
 15 2016-04-06T02:09:21  *** wallet42 has quit IRC
 16 2016-04-06T02:22:33  *** fengling has joined #bitcoin-core-dev
 17 2016-04-06T02:35:39  *** hsmiths has quit IRC
 18 2016-04-06T02:37:26  *** hsmiths has joined #bitcoin-core-dev
 19 2016-04-06T02:46:17  *** fengling has quit IRC
 20 2016-04-06T02:46:39  *** xiangfu has quit IRC
 21 2016-04-06T02:48:13  *** xiangfu has joined #bitcoin-core-dev
 22 2016-04-06T02:54:48  *** fengling has joined #bitcoin-core-dev
 23 2016-04-06T03:05:24  *** frankenmint has joined #bitcoin-core-dev
 24 2016-04-06T03:24:46  *** supasonic has quit IRC
 25 2016-04-06T03:25:16  *** supasonic has joined #bitcoin-core-dev
 26 2016-04-06T03:39:01  *** wallet42 has joined #bitcoin-core-dev
 27 2016-04-06T03:50:19  *** gevs has quit IRC
 28 2016-04-06T03:56:34  *** go1111111 has quit IRC
 29 2016-04-06T04:00:05  *** go1111111 has joined #bitcoin-core-dev
 30 2016-04-06T04:21:29  *** p15x has joined #bitcoin-core-dev
 31 2016-04-06T04:56:01  *** Alopex has quit IRC
 32 2016-04-06T04:57:07  *** Alopex has joined #bitcoin-core-dev
 33 2016-04-06T05:18:06  *** OGF-US has joined #bitcoin-core-dev
 34 2016-04-06T05:21:13  *** river__ has joined #bitcoin-core-dev
 35 2016-04-06T05:21:22  *** StringerBell has quit IRC
 36 2016-04-06T05:22:56  *** fengling has quit IRC
 37 2016-04-06T05:23:50  *** frankenmint has quit IRC
 38 2016-04-06T05:27:27  *** arubi is now known as ^arubi
 39 2016-04-06T05:50:45  *** jannes has quit IRC
 40 2016-04-06T05:59:07  *** fengling has joined #bitcoin-core-dev
 41 2016-04-06T05:59:21  *** wallet42 has quit IRC
 42 2016-04-06T06:00:07  *** dermoth has quit IRC
 43 2016-04-06T06:00:50  *** dermoth has joined #bitcoin-core-dev
 44 2016-04-06T06:19:21  *** go1111111 has quit IRC
 45 2016-04-06T06:27:33  *** assder has joined #bitcoin-core-dev
 46 2016-04-06T06:38:08  *** supasonic has quit IRC
 47 2016-04-06T07:18:36  *** frankenmint has joined #bitcoin-core-dev
 48 2016-04-06T07:42:57  *** randy-waterhouse has joined #bitcoin-core-dev
 49 2016-04-06T07:47:06  *** PRab has quit IRC
 50 2016-04-06T07:55:42  *** PRab has joined #bitcoin-core-dev
 51 2016-04-06T08:08:01  *** jannes has joined #bitcoin-core-dev
 52 2016-04-06T08:08:30  *** Guyver2 has joined #bitcoin-core-dev
 53 2016-04-06T08:10:46  *** AaronvanW has joined #bitcoin-core-dev
 54 2016-04-06T08:17:07  *** Arnavion has quit IRC
 55 2016-04-06T08:18:44  *** Arnavion has joined #bitcoin-core-dev
 56 2016-04-06T08:28:35  *** Thireus has quit IRC
 57 2016-04-06T08:28:52  *** Thireus has joined #bitcoin-core-dev
 58 2016-04-06T08:31:06  *** rubensayshi has quit IRC
 59 2016-04-06T08:34:32  <GitHub9> [bitcoin] laanwj opened pull request #7821: init: allow shutdown during 'Activating best chain...' (master...2016_04_shutdown_during_activate_best_chain) https://github.com/bitcoin/bitcoin/pull/7821
 60 2016-04-06T08:42:39  *** mesmer_ has quit IRC
 61 2016-04-06T08:43:05  *** mesmer_ has joined #bitcoin-core-dev
 62 2016-04-06T08:54:42  *** Cory has quit IRC
 63 2016-04-06T08:58:49  <wumpus> just curious, did anyone (or know of anyone that tried) to replace leveldb with lmdb and do benchmarks with regard to chainstate sync yet?
 64 2016-04-06T08:58:59  *** Cory has joined #bitcoin-core-dev
 65 2016-04-06T08:59:52  <wumpus> I'd really like to know this but I don't get around to it, I know there are lmdb versus leveldb comparison sites but should be under our specific workload
 66 2016-04-06T09:00:35  <wumpus> I'm seeing awful latency on arm64 with leveldb
 67 2016-04-06T09:01:32  <btcdrak> no testing was done with lmdb, only sqlite (which was ghastly).
 68 2016-04-06T09:02:17  <wumpus> yes I know about sqlite, sqlite would be an ok format for the wallet but it's too high level/high overhead for chainstate use
 69 2016-04-06T09:04:08  <wumpus> what this needs a very fast, close-to-hw, key/value store, Ideally for this experient I'd just map the entire thing into memory but the device has only 2GB.
 70 2016-04-06T09:05:08  <sipa> wumpus: lmdb uses mmap for everything afaik, so it's hard to use on 32-bit platforms
 71 2016-04-06T09:05:21  <wumpus> I don't care about 32 bit platforms for this experiment
 72 2016-04-06T09:05:40  <wumpus> just want to compare x86_64 versus arm64
 73 2016-04-06T09:06:39  <wumpus> mmapping everything sounds perfect
 74 2016-04-06T09:09:44  <jonasschnelli> wumpus: what device are you targeting? Odroid? PINE A64?
 75 2016-04-06T09:09:50  <wumpus> odroid C2
 76 2016-04-06T09:10:13  <jonasschnelli> I have ordered a PINE A64. ~same sepcs..
 77 2016-04-06T09:10:20  <wumpus> how much memroy?
 78 2016-04-06T09:10:22  <jonasschnelli> 2GB
 79 2016-04-06T09:10:29  <jonasschnelli> (which is essential)
 80 2016-04-06T09:10:58  <jonasschnelli> I think we might finally have tiny devices that can run a fullnode and cost <40USD.
 81 2016-04-06T09:11:02  <wumpus> yes I'd preferred one with 8GB but at least it's not abysmal :)
 82 2016-04-06T09:11:08  <jonasschnelli> A fullnode next to your router...
 83 2016-04-06T09:11:45  <wumpus> right, it's promising, too bad leveldb is letting me down on this, I'm not sure why, most profiling tools are broken with this experimental kernel
 84 2016-04-06T09:12:09  <jonasschnelli> imdb sounds promissing...
 85 2016-04-06T09:12:42  <jonasschnelli> wumpus: what this needs a very fast, close-to-hw, key/value store    <--- I agree!
 86 2016-04-06T09:12:51  <jonasschnelli> C based
 87 2016-04-06T09:13:54  <jonasschnelli> wumpus: How fast is the "disk" (flash) access on the Odroid C2? You think its enough for UTXO queries?
 88 2016-04-06T09:13:55  <wumpus> exactly!
 89 2016-04-06T09:14:48  *** jtimon has joined #bitcoin-core-dev
 90 2016-04-06T09:14:50  <wumpus> well I have a microsd in it of 32gb, but it's not very fast, I only use it for the OS, have attached an external USB harddisk for storing the block chain and utxo set
 91 2016-04-06T09:16:23  <jonasschnelli> wumpus USB2.0 should probably fast enought... though, in theory (IIRC) gbit ethernet should be faster.
 92 2016-04-06T09:16:33  <wumpus> so it could be a problem with slow storage, it looks like a latency problem, block validation fires a lot of queries and some of those end up taking ~1.2ms per input
 93 2016-04-06T09:17:12  <wumpus> well the fastest setup I've been able to use up until now is to put the blocks on the USB harddisk, and the utxo set on a network block device mounted over 1gbit ethernet
 94 2016-04-06T09:17:25  <wumpus> of course, that's kind of cheating :)
 95 2016-04-06T09:17:33  <jonasschnelli> hah. true!
 96 2016-04-06T09:17:46  <wumpus> and it still doesn't manage to max out the CPU on most blocks, so something curious is happening with leveldb
 97 2016-04-06T09:17:52  <jonasschnelli> wumpus: also, have a look at the PINE: https://www.kickstarter.com/projects/pine64/pine-a64-first-15-64-bit-single-board-super-comput/description
 98 2016-04-06T09:18:17  <btcdrak> yeah that thing is going to rock
 99 2016-04-06T09:18:31  <jonasschnelli> 1,2GHZ Cortext A53
100 2016-04-06T09:18:49  <wumpus> nice! yes specs look very much like the odroid C2
101 2016-04-06T09:18:56  <jonasschnelli> Wel.. the Odroid runs on 2Ghz
102 2016-04-06T09:19:20  <jonasschnelli> I mean, 29USD. Holly!
103 2016-04-06T09:19:53  <sipa> i have a rpi3 now
104 2016-04-06T09:20:04  <jonasschnelli> 512MB ram?!
105 2016-04-06T09:20:14  <sipa> which also has an arm64 cpu, though their kernel is still 32-bit :(
106 2016-04-06T09:20:35  <jonasschnelli> Ordoid C2: * Infrared(IR) Receiver? :|
107 2016-04-06T09:21:07  <sipa> We need a bitcoin-over-ir protocol...
108 2016-04-06T09:25:16  <jonasschnelli> haha...
109 2016-04-06T09:48:55  *** MarcoFalke has joined #bitcoin-core-dev
110 2016-04-06T09:51:14  *** xiangfu has quit IRC
111 2016-04-06T09:51:40  <wumpus> I've heard about bitcoin over nfc, but no never over IRyet :-)
112 2016-04-06T09:53:43  <Luke-Jr> turn gameboy colour into a hw wallet?
113 2016-04-06T09:58:06  <wumpus> almost all those ARM boards have an IR receiver, but never a transmitter
114 2016-04-06T10:07:21  <wumpus> yes you could use it for communication with a gameboy color probably :-)
115 2016-04-06T10:09:28  <wumpus> not sure about wavelengths, frequencies etc
116 2016-04-06T10:16:00  <wumpus> I have an FPGA board (ICEstick) with a IR led that could probably be taught to speak the right protocol, but I'm too lazy :p
117 2016-04-06T10:31:06  <GitHub118> [bitcoin] jpdffonseca opened pull request #7822: [qa] Add test to RPC listunspent (master...support/add-test-listunspent) https://github.com/bitcoin/bitcoin/pull/7822
118 2016-04-06T10:33:10  *** p15x has quit IRC
119 2016-04-06T10:38:27  *** broofa has joined #bitcoin-core-dev
120 2016-04-06T10:38:29  <GitHub154> [bitcoin] jpdffonseca opened pull request #7823: [Wallet] Add index of unspent transaction outputs (UTXOs) (master...enhancement/cache-unspent-outputs) https://github.com/bitcoin/bitcoin/pull/7823
121 2016-04-06T10:40:36  *** broofa has quit IRC
122 2016-04-06T10:44:35  *** laurentmt has joined #bitcoin-core-dev
123 2016-04-06T10:49:53  *** laurentmt has quit IRC
124 2016-04-06T10:50:10  *** laurentmt has joined #bitcoin-core-dev
125 2016-04-06T10:50:13  *** laurentmt has quit IRC
126 2016-04-06T10:58:05  *** fengling has quit IRC
127 2016-04-06T11:08:29  *** laurentmt has joined #bitcoin-core-dev
128 2016-04-06T11:08:38  *** laurentmt has quit IRC
129 2016-04-06T11:16:56  *** randy-waterhouse has left #bitcoin-core-dev
130 2016-04-06T11:34:53  *** cryptapus has joined #bitcoin-core-dev
131 2016-04-06T11:34:53  *** cryptapus has joined #bitcoin-core-dev
132 2016-04-06T11:51:17  <GitHub62> [bitcoin] jonasschnelli opened pull request #7824: Add uncontroversial RBF base features (master...2016/04/rbf_uncontroversial) https://github.com/bitcoin/bitcoin/pull/7824
133 2016-04-06T11:59:24  <GitHub56> [bitcoin] pedrobranco opened pull request #7825: Prevent multiple calls to ExtractDestination (master...enhancement/prevent-multiple-calls-extractdestination) https://github.com/bitcoin/bitcoin/pull/7825
134 2016-04-06T12:08:47  <jtimon> MarcoFalke: told me that some people told him they kind of like #7779
135 2016-04-06T12:10:38  <jtimon> wumpus: but nobody commented on the PR...I'm not sure what should I do. Comment the example commit and remove the "Discussion: " label? just close it and keep waiting for someone to hopefuly comment?
136 2016-04-06T12:10:55  <wumpus> heh we have kind of a PR storm at the moment
137 2016-04-06T12:13:13  <GitHub168> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1b2460bd5824...70ac71b877f3
138 2016-04-06T12:13:14  <GitHub168> bitcoin/master ffff866 MarcoFalke: [qa] Remove misleading "errorString syntax"
139 2016-04-06T12:13:14  <GitHub168> bitcoin/master 70ac71b Wladimir J. van der Laan: Merge #7801: [qa] Remove misleading "errorString syntax"...
140 2016-04-06T12:13:18  <GitHub158> [bitcoin] laanwj closed pull request #7801: [qa] Remove misleading "errorString syntax" (master...Mf1604-qaTestErrorString) https://github.com/bitcoin/bitcoin/pull/7801
141 2016-04-06T12:13:59  <GitHub191> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/70ac71b877f3...401c65c6b3e2
142 2016-04-06T12:13:59  <GitHub191> bitcoin/master fac724c MarcoFalke: [qa] maxblocksinflight: Actually enable test
143 2016-04-06T12:14:00  <GitHub191> bitcoin/master 401c65c Wladimir J. van der Laan: Merge #7803: [qa] maxblocksinflight: Actually enable test...
144 2016-04-06T12:14:03  <GitHub183> [bitcoin] laanwj closed pull request #7803: [qa] maxblocksinflight: Actually enable test (master...Mf1604-qaTestMaxBlocks) https://github.com/bitcoin/bitcoin/pull/7803
145 2016-04-06T12:14:34  <GitHub54> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/401c65c6b3e2...3bc71e1572cb
146 2016-04-06T12:14:34  <GitHub54> bitcoin/master fa24456 MarcoFalke: [qa] httpbasics: Actually test second connection
147 2016-04-06T12:14:35  <GitHub54> bitcoin/master 3bc71e1 Wladimir J. van der Laan: Merge #7802: [qa] httpbasics: Actually test second connection...
148 2016-04-06T12:14:43  <GitHub144> [bitcoin] laanwj closed pull request #7802: [qa] httpbasics: Actually test second connection (master...Mf1604-qaTestHttp) https://github.com/bitcoin/bitcoin/pull/7802
149 2016-04-06T12:14:54  <wumpus> jtimon: maybe ask people to look at it during the meeting
150 2016-04-06T12:18:38  <jtimon> quote from MarcoFalke "Actually we were discussing on IRC with wumpus morcos and sduftar.
151 2016-04-06T12:18:38  <jtimon> They seemed unanimous about using one flag and not removing it from the method because it might be needed later." when talking about #7779 and #7574
152 2016-04-06T12:19:24  <jtimon> sdaftuar:
153 2016-04-06T12:19:35  <jtimon> I'll just leave it here
154 2016-04-06T12:24:39  <wumpus> we should also inform about the c++11 transition in the upcoming meeting, I want to use nullptr  @sipa :)
155 2016-04-06T12:26:07  <paveljanik> jtimon, I guess it is because it slipped to the second page of the PRs.
156 2016-04-06T12:27:42  <jtimon> paveljanik: not in a hurry, but it seems a bit useless as a discussion PR if the discussion happens elsewhere (and without me, I opened it to know what people think)
157 2016-04-06T12:29:35  <wumpus> agreed on that
158 2016-04-06T12:30:27  <btcdrak> wumpus: recent meeting notes on c++11 transition here: https://bitcoincore.org/en/meetings/2015/12/17/#c11-for-013
159 2016-04-06T12:30:40  <btcdrak> and again here https://bitcoincore.org/en/meetings/2016/01/21/#c11-update
160 2016-04-06T12:30:45  <wumpus> thanks :)
161 2016-04-06T12:31:04  <jtimon> wumpus: thanks, so just pinged the people involved and mentioned here, I don't think it's necessary to talk about #7779 in the meeting
162 2016-04-06T12:31:09  <wumpus> It might be still blocked on travis caching support, not sure though
163 2016-04-06T12:36:14  *** laurentmt has joined #bitcoin-core-dev
164 2016-04-06T12:47:11  *** cryptapus__ has joined #bitcoin-core-dev
165 2016-04-06T12:47:11  *** cryptapus__ has joined #bitcoin-core-dev
166 2016-04-06T12:48:38  *** cryptapus__ is now known as cryptapus_
167 2016-04-06T12:50:08  *** cryptapus has quit IRC
168 2016-04-06T12:53:09  *** Ylbam has joined #bitcoin-core-dev
169 2016-04-06T12:59:35  *** supasonic has joined #bitcoin-core-dev
170 2016-04-06T13:02:46  <jonasschnelli> hmm... the GUI does not show wallet conflicts. Right? IIRC, there where PRs from dgenr8?
171 2016-04-06T13:03:50  <jonasschnelli> With RBF this will be required somehow
172 2016-04-06T13:04:23  <btcdrak> jonasschnelli: https://github.com/bitcoin/bitcoin/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Adgenr8+
173 2016-04-06T13:05:45  <jonasschnelli> btcdrak: Thanks...
174 2016-04-06T13:05:52  <jtimon> mhmm, 1b2460b doesn't pass python ./qa/pull-tester/rpc-tests.py (mempool_limit.py fails), git fetch origin...
175 2016-04-06T13:09:31  *** gevs has joined #bitcoin-core-dev
176 2016-04-06T13:13:34  *** Cory has quit IRC
177 2016-04-06T13:17:02  <jtimon> mhmm, 3bc71e1 *   origin/master seems to fail too...
178 2016-04-06T13:17:24  *** laurentmt has quit IRC
179 2016-04-06T13:17:41  *** Cory has joined #bitcoin-core-dev
180 2016-04-06T13:17:43  <jtimon> do I need to do anything else besides rm -rf cache or the current master wouldn't pass travis?
181 2016-04-06T13:18:18  <jtimon> wumpus: ?
182 2016-04-06T13:18:47  <wumpus> is that the extended or the base tests?
183 2016-04-06T13:18:55  <wumpus> only the base tests are run by travis
184 2016-04-06T13:19:07  <jtimon> the base ones mempool_limit.py
185 2016-04-06T13:19:31  <wumpus> those should indeed pass, haven't heard travis complain
186 2016-04-06T13:19:32  <jtimon> python ./qa/pull-tester/rpc-tests.py mempool_limit
187 2016-04-06T13:19:51  <wumpus> what error do you get?
188 2016-04-06T13:20:44  <jtimon> https://0bin.net/paste/qSAK6dUwqKg8rAQL#b8PsedY3uoBOHP3J-bsCQ73XyGXgr6XhSEDcQXctC/J
189 2016-04-06T13:21:13  <wumpus> hm weird, never saw that one
190 2016-04-06T13:21:32  <jtimon> you don't reproduce it on current master?
191 2016-04-06T13:22:14  *** frankenmint has quit IRC
192 2016-04-06T13:22:47  <wumpus> can't try rght now
193 2016-04-06T13:23:44  <jtimon> ok, if anybody else can try "python ./qa/pull-tester/rpc-tests.py mempool_limit" on the current master to confirm is not a local/cache thing, I would appreciate it
194 2016-04-06T13:24:44  <paveljanik> jtimon, mmnt
195 2016-04-06T13:24:54  <jtimon> paveljanik: awesome thanks
196 2016-04-06T13:24:57  <sipa> wumpus: ack on nullptr :)
197 2016-04-06T13:25:17  *** cryptapus_ is now known as cryptapus
198 2016-04-06T13:26:37  <jtimon> wumpus: sipa: suggestions for more C++11-ish "extern boost::scoped_ptr<CPolicy> globalPolicy;" ?
199 2016-04-06T13:26:44  <paveljanik> jtimon, OK, 3s
200 2016-04-06T13:26:55  <jtimon> paveljanik: no hurry
201 2016-04-06T13:27:03  <paveljanik> no, it is finished -
202 2016-04-06T13:27:07  <paveljanik> Tests successful
203 2016-04-06T13:27:08  <paveljanik> Duration: 3 s
204 2016-04-06T13:27:08  <wumpus> a global scoped ptr? no, I don't like that
205 2016-04-06T13:27:29  <wumpus> if you need them at all, please explicitly create/initialize and teardown global objects
206 2016-04-06T13:27:31  <paveljanik> jtimon, what does it print for you?
207 2016-04-06T13:27:42  <paveljanik> ah mempool full
208 2016-04-06T13:27:43  <wumpus> we've had enough (de)initialization order problems to last a lifetime
209 2016-04-06T13:27:45  <paveljanik> not here...
210 2016-04-06T13:29:04  <jtimon> paveljanik: thank you, see the 0bin link above. Now it is something in https://github.com/bitcoin/bitcoin/pull/7820/commits and I'm not cleaning up properly between tests
211 2016-04-06T13:29:23  <jtimon> it seems "rm -rf cache" is not enough
212 2016-04-06T13:29:59  <jtimon> wumpus: where's the right place for deleting global pointers ?
213 2016-04-06T13:31:24  <jtimon> people seemed to like boost::scoped_ptr<CChainParams> for #6907
214 2016-04-06T13:31:34  <wumpus> jtimon: shutdown()
215 2016-04-06T13:33:11  <jtimon> ok, then I can use a simple pointer that initializes in AppInit2() and gets deleted in shutdown(), fine with me. maybe we should do that with the chainparams globals too
216 2016-04-06T13:33:54  <wumpus> sure, if you really need something that lasts the entire program you could use global scoped_ptr, but make sure there areno dependencies on anything
217 2016-04-06T13:34:13  <wumpus> and ideally the global pointer would be restricted within one module, not shared via external, but passed where necessary
218 2016-04-06T13:34:59  <sipa> ideally all of the node operation in main is encapsulated in a class, which has a pointer to the utxo cache, the policy, the mempool, ...
219 2016-04-06T13:35:07  <sipa> and there are no globals at all
220 2016-04-06T13:35:10  * sipa dreams
221 2016-04-06T13:35:14  <wumpus> yes, no globals would be best
222 2016-04-06T13:35:28  <jtimon> what do you think about eventually moving all globals to globals/server (most of them currently in main.o), globals/util, globals/common, etc
223 2016-04-06T13:35:33  <jtimon> ?
224 2016-04-06T13:35:50  <wumpus> but if you really need them at least be as careful as possible with them, restrict their scope/accessibility as much as possible, etc
225 2016-04-06T13:36:03  <wumpus> doesn't sound good to me
226 2016-04-06T13:36:09  <wumpus> keep the globals with the code that uses them
227 2016-04-06T13:36:18  <wumpus> keep them as local as possible
228 2016-04-06T13:36:35  <wumpus> this makes it easier to make it into a class, too
229 2016-04-06T13:36:56  <jtimon> well, I was thinking that maybe not including all the globals in everything that needs to include main.h for other reason would be a step forward, but thanks for the feedback
230 2016-04-06T13:38:16  <jtimon> you could just grep #include "globals/ and find functions that could take parameters explicitly (the only true and slow path to removing globals)
231 2016-04-06T13:40:23  <jtimon> I mean, I've mostly thought about this only for the globals in util.o, chainparams.o and globalPolicy, probably would move globals from main.o to globals/server.o the last thing, since it will be clearly the most disruptive
232 2016-04-06T13:44:24  <jtimon> I changed the topic, sorry. I guess the answer to my original question is http://stackoverflow.com/a/5294005
233 2016-04-06T13:52:27  <jtimon> on "keep the globals with the code that uses them" well, in my opinion I will use a new global in init.cpp, and everywhere else basically shouldn't be using it (it should be passed down explicitly, but you cannot do that at once)
234 2016-04-06T13:53:46  <jtimon> where should Params() be called from? ideally, nowhere
235 2016-04-06T13:55:04  <jtimon> but only from init and one other place would be almost as ideal
236 2016-04-06T13:56:54  *** Chris_Stewart_5 has quit IRC
237 2016-04-06T13:57:17  <wumpus> I don't like the globals/ idea. If you need globals from another implementation unit there could be a function that returns (a pointer or reference to) it
238 2016-04-06T13:57:35  <wumpus> similar to private: or protected: in classes
239 2016-04-06T13:58:06  <wumpus> where should Params() be called from? <- yes, ideally just once to create the object, after that it just gets passed on
240 2016-04-06T13:59:48  <wumpus> and stored in appropriate places within classes, so they can pass it on
241 2016-04-06T14:00:49  *** nanotube has quit IRC
242 2016-04-06T14:02:11  <jonasschnelli> sipa: ping
243 2016-04-06T14:02:16  <sipa> jonasschnelli: pang
244 2016-04-06T14:02:22  <jonasschnelli> You remember the SetMerkleBranch PR for the wallet:
245 2016-04-06T14:02:23  <jonasschnelli> https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L3299
246 2016-04-06T14:02:45  <jonasschnelli> The GUI does not detect RBF conflicts...
247 2016-04-06T14:03:01  <sipa> ?
248 2016-04-06T14:03:07  <jonasschnelli> You return 0 (=in mempool) if the hash is unset... is that correct
249 2016-04-06T14:03:14  <jonasschnelli> (hash of the block)
250 2016-04-06T14:03:27  <sipa> yes, it means the transaction is not known to be in a block
251 2016-04-06T14:03:47  <jonasschnelli> https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.h#L204
252 2016-04-06T14:04:12  <sipa> that's outdated; it's not necessarily in the mempool
253 2016-04-06T14:04:16  <jonasschnelli> I think the GUI needs an aditional mempool check then
254 2016-04-06T14:05:17  <jonasschnelli> Somehow the wallet does not detect conflict with a transaction that is not in the mempool
255 2016-04-06T14:05:21  <jonasschnelli> *conflicts
256 2016-04-06T14:05:22  <sipa> for detecting what case?
257 2016-04-06T14:05:52  <jonasschnelli> If a replace a transaction (RBF), I have two transaction in the transaction list, neither of them is marked conflicted.
258 2016-04-06T14:06:05  <gmaxwell> $ ./bitcoin-cli stop
259 2016-04-06T14:06:06  <gmaxwell> error: couldn't parse reply from server
260 2016-04-06T14:06:08  <gmaxwell> 0_o
261 2016-04-06T14:06:20  <jonasschnelli> (the first transaction is removed from the mempool)
262 2016-04-06T14:06:57  <sipa> jonasschnelli: known to conflict is only for conflicting with confirmed transactions
263 2016-04-06T14:07:15  <sipa> jonasschnelli: you can use IsTrusted ?
264 2016-04-06T14:07:21  *** aj has quit IRC
265 2016-04-06T14:07:34  <jonasschnelli> sipa: okay. Let me see..
266 2016-04-06T14:07:54  *** aj has joined #bitcoin-core-dev
267 2016-04-06T14:07:57  <sipa> jonasschnelli: i don't know the gui, and i don't really know what you're talking about
268 2016-04-06T14:08:45  <gmaxwell> hm. seems to be deadlocked
269 2016-04-06T14:08:50  <jonasschnelli> hah. Yes. Forget about it. I'll work on it and show you some code... thats better understandable.
270 2016-04-06T14:09:31  <GitHub105> [bitcoin] laanwj closed pull request #6774: IsSuperMajority() moved to separate soft forks unit (master...ISM_to_softforks_unit) https://github.com/bitcoin/bitcoin/pull/6774
271 2016-04-06T14:13:26  <sipa> gmaxwell: https://github.com/sipa/bitcoin/commit/115157b45caa374719fa6ad2a3d46281c9109349
272 2016-04-06T14:13:36  <sipa> gmaxwell: going to run with that to monitor
273 2016-04-06T14:15:34  <sipa> gmaxwell: i think the inv sorting is suboptimal, in that it always puts transactions without unconfirmed dependencies first, even if they have lower individual feerate than dependent ones
274 2016-04-06T14:15:42  *** nanotube has joined #bitcoin-core-dev
275 2016-04-06T14:15:53  <gmaxwell> Yes, it does.
276 2016-04-06T14:16:07  <sipa> gmaxwell: after CPFP i guess we'll want to change it to sort by ancestor-combined-feerate, and build a set to submit based on it
277 2016-04-06T14:16:14  <sipa> gmaxwell: but i doubt it matters at all now
278 2016-04-06T14:18:07  <gmaxwell> I was aware of it, but didn't think it was worth the more core/computationally expensive handling. (issue being that the parent tx may already have been sent, so you can't just sort by feerate then move down all without parents-- or you'd just get ~what I have)
279 2016-04-06T14:19:20  <sipa> i guess you'd just want to run CreateNewBlock on the subset of the mempool that overlaps with vInventoryToSend, with the reduces max size, and then send that :p
280 2016-04-06T14:19:29  * sipa ducks
281 2016-04-06T14:19:57  <gmaxwell> cached createnew block and intersect with the inventory. :P
282 2016-04-06T14:20:48  <sipa> do you have any statistics for how this affects orphan tx?
283 2016-04-06T14:21:04  *** Chris_Stewart_5 has joined #bitcoin-core-dev
284 2016-04-06T14:21:08  <sipa> i guess you'd need a test setup with multiple nodes
285 2016-04-06T14:21:13  <gmaxwell> not yet, though with only two nodes running it, I couldn't measure.
286 2016-04-06T14:21:46  <gmaxwell> I believe it will completely eliminate them; except for garbage being sent by confused node, and except for the fact that we don't sync the mempool at start.
287 2016-04-06T14:28:34  <Chris_Stewart_5> is the only difference between SCRIPT_VERIFY_STRICTENC & SCRIPT_VERIFY_DERSIG the fact that the former requires the hash type to be defined?
288 2016-04-06T14:30:17  <Chris_Stewart_5> specifically looking at these lines of code https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L191-L197
289 2016-04-06T14:30:17  <sipa> Chris_Stewart_5: strictenc also disallows hybrid public key encoding
290 2016-04-06T14:31:28  *** Luke-Jr has quit IRC
291 2016-04-06T14:33:58  <Chris_Stewart_5> why isn't the hash type being defined in the bip66 specification?
292 2016-04-06T14:34:32  <sipa> because it's not necessary
293 2016-04-06T14:34:41  *** cryptapus has quit IRC
294 2016-04-06T14:34:42  <sipa> the hashtype is included in the sighash, so you can't modify it
295 2016-04-06T14:34:50  <sipa> or it would invalidate the signature
296 2016-04-06T14:34:56  *** d_t has joined #bitcoin-core-dev
297 2016-04-06T14:34:57  *** cryptapus has joined #bitcoin-core-dev
298 2016-04-06T14:34:57  *** cryptapus has joined #bitcoin-core-dev
299 2016-04-06T14:45:07  *** laurentmt has joined #bitcoin-core-dev
300 2016-04-06T14:49:35  *** laurentmt has quit IRC
301 2016-04-06T15:08:18  *** gevs has quit IRC
302 2016-04-06T15:08:21  *** Chris_Stewart_5 has quit IRC
303 2016-04-06T15:16:06  <GitHub37> [bitcoin] jonasschnelli opened pull request #7826: [Qt] show conflicts of unconfirmed transactions in the UI (master...2016/04/ui_mem_cflct) https://github.com/bitcoin/bitcoin/pull/7826
304 2016-04-06T15:18:01  *** laurentmt has joined #bitcoin-core-dev
305 2016-04-06T15:20:16  *** laurentmt has quit IRC
306 2016-04-06T15:20:45  *** gevs has joined #bitcoin-core-dev
307 2016-04-06T15:20:45  *** gevs has joined #bitcoin-core-dev
308 2016-04-06T15:22:27  *** Chris_Stewart_5 has joined #bitcoin-core-dev
309 2016-04-06T15:25:32  *** hsmiths has quit IRC
310 2016-04-06T15:26:26  *** MarcoFalke has quit IRC
311 2016-04-06T15:27:27  *** hsmiths has joined #bitcoin-core-dev
312 2016-04-06T15:29:09  *** MarcoFalke has joined #bitcoin-core-dev
313 2016-04-06T15:50:39  *** Luke-Jr has joined #bitcoin-core-dev
314 2016-04-06T16:04:32  *** hsmiths has quit IRC
315 2016-04-06T16:05:52  *** hsmiths has joined #bitcoin-core-dev
316 2016-04-06T16:21:43  <wumpus> hmm in lmdb reads happen inside a transaction as well, this makes it harder to fit into the current dbwrapper, resetting the transactino for every read is probably inefficient
317 2016-04-06T16:31:22  <sipa> wumpus: not necessarily, i think
318 2016-04-06T16:31:56  <sipa> otherwise, you could have a read transaction that persists, and is just closed whenever a write is performed, and then reopened
319 2016-04-06T16:32:14  <sipa> to mimick the batch update model
320 2016-04-06T16:32:48  <wumpus> http://symas.com/mdb/doc/group__mdb.html#ga8bf10cd91d3f3a83a34d04ce6b07992d
321 2016-04-06T16:33:40  <wumpus> yes, that could work
322 2016-04-06T17:15:12  *** AaronvanW has quit IRC
323 2016-04-06T17:17:21  *** jannes has quit IRC
324 2016-04-06T17:41:02  *** ^arubi is now known as arubi
325 2016-04-06T18:12:03  *** hybridsole has quit IRC
326 2016-04-06T18:29:57  *** bsm117532 has quit IRC
327 2016-04-06T18:33:15  *** Chris_Stewart_5 has quit IRC
328 2016-04-06T18:34:58  *** hybridsole has joined #bitcoin-core-dev
329 2016-04-06T18:41:05  *** SteveTaylor has quit IRC
330 2016-04-06T18:56:03  *** Chris_Stewart_5 has joined #bitcoin-core-dev
331 2016-04-06T18:57:44  *** molz has joined #bitcoin-core-dev
332 2016-04-06T18:59:46  *** moli has quit IRC
333 2016-04-06T19:11:03  <wumpus> cool, I have bitcoind working with lmdb
334 2016-04-06T19:11:57  <btcdrak> wumpus: that was fast
335 2016-04-06T19:12:12  <btcdrak> the question is, is it faster? =)
336 2016-04-06T19:12:16  <wumpus> well it's one big hack
337 2016-04-06T19:12:20  <wumpus> I don't know yet
338 2016-04-06T19:12:51  <wumpus> let's first see if it is correct, in my experience it's very easy to make something fast if it doesn't work properly ;)
339 2016-04-06T19:13:39  <wumpus> but it feels quite fast
340 2016-04-06T19:15:37  <gmaxwell> one thing to also benchmark agains is leveldb with the checks turned back down again too; as thats more apples to apples.
341 2016-04-06T19:16:14  <wumpus> yes
342 2016-04-06T19:21:58  <jonasschnelli> wumpus: well done... looking forward to see some benachmarks / footprint comparison!
343 2016-04-06T19:28:01  *** Chris_Stewart_5 has quit IRC
344 2016-04-06T19:36:36  *** Chris_Stewart_5 has joined #bitcoin-core-dev
345 2016-04-06T20:00:12  <GitHub93> [bitcoin] mrbandrews opened pull request #7827: Speed up getchaintips. (master...ba-fix-chaintips) https://github.com/bitcoin/bitcoin/pull/7827
346 2016-04-06T20:02:01  <Chris_Stewart_5> sipa: Wrt to our discussion yesterday about executing scriptSigs & scriptPubKeys individually, was OP_CODESEPARATOR initially trying to allow this?
347 2016-04-06T20:05:03  <Chris_Stewart_5> i.e. it indicates the ending of the scriptSig & beginning of the scriptPubKey?
348 2016-04-06T20:06:57  <sipa> Chris_Stewart_5: it is assumed that it waas intended to allow delegation
349 2016-04-06T20:07:33  <sipa> someone signing over the right to sign to someone else, under other conditions
350 2016-04-06T20:19:29  <Chris_Stewart_5> it seems that you could have some sort of separator like that to say push ops can't transcent separator boundaries... not sure what the value added is though :-/
351 2016-04-06T20:22:06  <GitHub50> [bitcoin] jtimon opened pull request #7828: Trivial: Globals: Explicitly pass const CChainParams& to ProcessMessage() (master...0.12.99-chainparams-trivial) https://github.com/bitcoin/bitcoin/pull/7828
352 2016-04-06T20:24:02  *** zooko has joined #bitcoin-core-dev
353 2016-04-06T20:26:40  *** Chris_Stewart_5 has quit IRC
354 2016-04-06T20:28:27  *** Chris_Stewart_5 has joined #bitcoin-core-dev
355 2016-04-06T20:30:08  <GitHub99> [bitcoin] jtimon opened pull request #7829: TODO: Kill "Params()" (master...0.12.99-todo-globals-chainparams) https://github.com/bitcoin/bitcoin/pull/7829
356 2016-04-06T20:38:14  *** cryptapus has quit IRC
357 2016-04-06T21:03:15  <jtimon> newbies and full grown programmers get out of your dark conrners and comment on #7829 so that I can see you. (this is not part of the funded stuff, just you doing stuff for me and me giving advice to you if you want that)
358 2016-04-06T21:05:18  <jtimon> the mission is not a priority or important, but if you want to get familiarized with github or whatever I'm happy to teach you with simple examples I care about
359 2016-04-06T21:06:09  *** zooko has quit IRC
360 2016-04-06T21:17:42  *** d_t has quit IRC
361 2016-04-06T21:20:34  *** supasonic has quit IRC
362 2016-04-06T21:21:15  *** supasonic has joined #bitcoin-core-dev
363 2016-04-06T21:26:51  *** supasonic has quit IRC
364 2016-04-06T21:27:17  *** supasonic has joined #bitcoin-core-dev
365 2016-04-06T21:35:00  *** d_t has joined #bitcoin-core-dev
366 2016-04-06T21:35:34  *** d_t has joined #bitcoin-core-dev
367 2016-04-06T21:36:05  *** d_t has joined #bitcoin-core-dev
368 2016-04-06T21:46:19  *** Arnavion has quit IRC
369 2016-04-06T21:47:30  *** Arnavion has joined #bitcoin-core-dev
370 2016-04-06T21:59:46  *** d_t has quit IRC
371 2016-04-06T22:23:33  <kanzure> jtimon: why do you want pull request 7829 "never merged"?
372 2016-04-06T22:40:45  <jtimon> kanzure: well, I'm happy merging all those TODO lines in the last commits, but it would be easier for me to keep track about what's been done and what is not if the PR is not merged. Besides that, I'm happy to merge a lot of TODO comments, no problem with me
373 2016-04-06T22:42:19  <jtimon> kanzure: does that make any sense?
374 2016-04-06T22:43:33  <kanzure> almost; the PR text could be more clear about what that PR is.... is this a good summary? "There is a set of changes that I would like to make. There's a lot of changes involved in this. To organize this work and to coordinate with others interested in helping make these changes, I have labeled TODOs in this pull request's source code. You are welcome to fork this and fix individual issues, and I will regularly rebase against the ...
375 2016-04-06T22:43:39  <kanzure> ... master branch to keep everything updated."
376 2016-04-06T22:43:42  <kanzure> (however, it's unclear to me if that is an accurate summary)
377 2016-04-06T22:45:21  <jtimon> kanzure: I'm happy to change the description of the PR, do you think you get the general intend? offering myself as a "tutor" only for small things I want done? no money involved in either direction
378 2016-04-06T22:45:54  <kanzure> if your intention was tutorship then that was not clear to me reading the PR text :)
379 2016-04-06T22:46:19  <jtimon> I don't want to promise too much, but I think I could offer some free guidance with stupid examples I know all about
380 2016-04-06T22:46:36  <jtimon> kanzure: that is good feedback
381 2016-04-06T22:46:55  *** Guyver2 has quit IRC
382 2016-04-06T22:47:39  <kanzure> one other minor point of feedback is that if you want to attract novices to your pull request, saying "Probably nobody with bitcoin development experience will think this is a priority. I don't either." will not make it clear to novices that you think these changes are good or worth doing at all :)
383 2016-04-06T22:48:39  <jtimon> but my intention is not really to start a tutorial, just to make people work for me on simple things I want done, and offer any help I can offer for them, whatever is more attractive without lying
384 2016-04-06T22:48:49  *** randy-waterhouse has joined #bitcoin-core-dev
385 2016-04-06T22:49:36  <kanzure> right, you are offering mentorship/tutorship for how to make simple contributions to the project, in exchange for feedback and advice on a newcomer's other pull requests.    but this is not clear from the PR text.
386 2016-04-06T22:50:49  <jtimon> kanzure: more good feedback, but I feel that's the truth (nobody is nervous about this not happenning soon enough), and it may actually be a relief for someone new (ie it doesn't matter if it takes you 3 weeks or 4, it will be welcome whenever you are ready because nobody is working on this urgently)
387 2016-04-06T22:52:30  <jtimon> kanzure: I'm happy that you got the basic idea, please, don't hesiate from making this kind of feedback on the PR itself
388 2016-04-06T22:52:41  <kanzure> i would start the PR text with something like: "I opened this PR so that newcomers to the Bitcoin Core project could make simple changes to get familiar with contributing to Bitcoin Core. I have marked a number of TODO comments in the source code of this pull request. The changes listed here are not critical to the project but they are good introductory material. Each TODO is relatively simple, and more experienced developers are busy ...
389 2016-04-06T22:52:47  <kanzure> ... doing other tasks, making this an excellent chance for you to get feedback from me on basic contributions to Bitcoin Core. Hopefully this will help you streamline submissions to Core, please let me know how I can help and I'm also offering some promises/commitments (see below)."
390 2016-04-06T22:54:40  <jtimon> ok, I pasted your comment on the PR
391 2016-04-06T22:54:50  <jtimon> very grateful, but...
392 2016-04-06T22:55:04  <jtimon> "I have marked a number of TODO comments in the source code of this pull request"
393 2016-04-06T22:55:37  <jtimon> I haven't merged anything anywhere, at most #7828  as an example
394 2016-04-06T22:56:47  *** Giszmo has quit IRC
395 2016-04-06T23:04:27  <jtimon> kanzure: never mind, "of this pull request", re-read, all fine, thank you very much
396 2016-04-06T23:05:14  <kanzure> yep
397 2016-04-06T23:05:28  <jtimon> you captured the spirit and improved the description
398 2016-04-06T23:06:47  <jtimon> in summary is that, free review for simple tasks I review, and I will try to push other people to review, etc
399 2016-04-06T23:06:58  <jtimon> in summary is that, free review for simple tasks I select, and I will try to push other people to review, etc
400 2016-04-06T23:09:33  <jtimon> I've met some developers that are shy because they are "C++ newbies" (to be honest, never was one because in the uni it was almast all C/C++ but some slides from older teachers still in pascal, but was never afraid of other languages and they shouldn't be either)
401 2016-04-06T23:10:24  <jtimon> but I have to admit that moving from subversion to git was kind of a shock for me
402 2016-04-06T23:10:45  <kanzure> bitcoin was your first introduction to git?
403 2016-04-06T23:11:12  <jtimon> well, I fetch pybrain before that, but basically yes
404 2016-04-06T23:11:17  *** laurentmt has joined #bitcoin-core-dev
405 2016-04-06T23:11:31  <jtimon> never pushed anything to git that wasn't mine before git
406 2016-04-06T23:11:35  *** laurentmt has quit IRC
407 2016-04-06T23:11:44  <jtimon> before bitcoin
408 2016-04-06T23:13:00  <jtimon> and never rebase -i until sipa told me that was possible ("this is what maaku means by re-writing history" I thought)
409 2016-04-06T23:14:36  <jtimon> no, I'm lying, I did used git before with maaku, but I had never done interactive rebases until I had to contribute for the first time. for some reason I really needed to rewrite history
410 2016-04-06T23:16:36  <jtimon> probably just squash 2 commits into one or something stupidly simple that just happened to be impossible for me before
411 2016-04-06T23:17:38  <jtimon> if other people intend to get stuck in the same sptupid things that I did, I won't let them
412 2016-04-06T23:35:51  *** p15 has joined #bitcoin-core-dev
413 2016-04-06T23:59:54  <jtimon> where is the longest branch for 0.12.1?