12016-04-06T00:05:34  *** aureianimus has quit IRC
  22016-04-06T00:09:31  <Luke-Jr> now git just needs to allow signatures after-the-commit
  32016-04-06T00:19:30  *** aureianimus has joined #bitcoin-core-dev
  42016-04-06T00:42:47  *** laurentmt has joined #bitcoin-core-dev
  52016-04-06T00:43:04  *** frankenmint has quit IRC
  62016-04-06T00:48:04  *** laurentmt has quit IRC
  72016-04-06T01:01:03  *** Ylbam has quit IRC
  82016-04-06T01:34:35  *** xiangfu has joined #bitcoin-core-dev
  92016-04-06T01:38:31  *** jtimon has quit IRC
 102016-04-06T01:53:02  *** xabbix has quit IRC
 112016-04-06T01:54:17  *** xabbix has joined #bitcoin-core-dev
 122016-04-06T01:54:17  *** xabbix has joined #bitcoin-core-dev
 132016-04-06T02:00:06  *** dermoth has quit IRC
 142016-04-06T02:01:00  *** dermoth has joined #bitcoin-core-dev
 152016-04-06T02:09:21  *** wallet42 has quit IRC
 162016-04-06T02:22:33  *** fengling has joined #bitcoin-core-dev
 172016-04-06T02:35:39  *** hsmiths has quit IRC
 182016-04-06T02:37:26  *** hsmiths has joined #bitcoin-core-dev
 192016-04-06T02:46:17  *** fengling has quit IRC
 202016-04-06T02:46:39  *** xiangfu has quit IRC
 212016-04-06T02:48:13  *** xiangfu has joined #bitcoin-core-dev
 222016-04-06T02:54:48  *** fengling has joined #bitcoin-core-dev
 232016-04-06T03:05:24  *** frankenmint has joined #bitcoin-core-dev
 242016-04-06T03:24:46  *** supasonic has quit IRC
 252016-04-06T03:25:16  *** supasonic has joined #bitcoin-core-dev
 262016-04-06T03:39:01  *** wallet42 has joined #bitcoin-core-dev
 272016-04-06T03:50:19  *** gevs has quit IRC
 282016-04-06T03:56:34  *** go1111111 has quit IRC
 292016-04-06T04:00:05  *** go1111111 has joined #bitcoin-core-dev
 302016-04-06T04:21:29  *** p15x has joined #bitcoin-core-dev
 312016-04-06T04:56:01  *** Alopex has quit IRC
 322016-04-06T04:57:07  *** Alopex has joined #bitcoin-core-dev
 332016-04-06T05:18:06  *** OGF-US has joined #bitcoin-core-dev
 342016-04-06T05:21:13  *** river__ has joined #bitcoin-core-dev
 352016-04-06T05:21:22  *** StringerBell has quit IRC
 362016-04-06T05:22:56  *** fengling has quit IRC
 372016-04-06T05:23:50  *** frankenmint has quit IRC
 382016-04-06T05:27:27  *** arubi is now known as ^arubi
 392016-04-06T05:50:45  *** jannes has quit IRC
 402016-04-06T05:59:07  *** fengling has joined #bitcoin-core-dev
 412016-04-06T05:59:21  *** wallet42 has quit IRC
 422016-04-06T06:00:07  *** dermoth has quit IRC
 432016-04-06T06:00:50  *** dermoth has joined #bitcoin-core-dev
 442016-04-06T06:19:21  *** go1111111 has quit IRC
 452016-04-06T06:27:33  *** assder has joined #bitcoin-core-dev
 462016-04-06T06:38:08  *** supasonic has quit IRC
 472016-04-06T07:18:36  *** frankenmint has joined #bitcoin-core-dev
 482016-04-06T07:42:57  *** randy-waterhouse has joined #bitcoin-core-dev
 492016-04-06T07:47:06  *** PRab has quit IRC
 502016-04-06T07:55:42  *** PRab has joined #bitcoin-core-dev
 512016-04-06T08:08:01  *** jannes has joined #bitcoin-core-dev
 522016-04-06T08:08:30  *** Guyver2 has joined #bitcoin-core-dev
 532016-04-06T08:10:46  *** AaronvanW has joined #bitcoin-core-dev
 542016-04-06T08:17:07  *** Arnavion has quit IRC
 552016-04-06T08:18:44  *** Arnavion has joined #bitcoin-core-dev
 562016-04-06T08:28:35  *** Thireus has quit IRC
 572016-04-06T08:28:52  *** Thireus has joined #bitcoin-core-dev
 582016-04-06T08:31:06  *** rubensayshi has quit IRC
 592016-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
 602016-04-06T08:42:39  *** mesmer_ has quit IRC
 612016-04-06T08:43:05  *** mesmer_ has joined #bitcoin-core-dev
 622016-04-06T08:54:42  *** Cory has quit IRC
 632016-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?
 642016-04-06T08:58:59  *** Cory has joined #bitcoin-core-dev
 652016-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
 662016-04-06T09:00:35  <wumpus> I'm seeing awful latency on arm64 with leveldb
 672016-04-06T09:01:32  <btcdrak> no testing was done with lmdb, only sqlite (which was ghastly).
 682016-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
 692016-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.
 702016-04-06T09:05:08  <sipa> wumpus: lmdb uses mmap for everything afaik, so it's hard to use on 32-bit platforms
 712016-04-06T09:05:21  <wumpus> I don't care about 32 bit platforms for this experiment
 722016-04-06T09:05:40  <wumpus> just want to compare x86_64 versus arm64
 732016-04-06T09:06:39  <wumpus> mmapping everything sounds perfect
 742016-04-06T09:09:44  <jonasschnelli> wumpus: what device are you targeting? Odroid? PINE A64?
 752016-04-06T09:09:50  <wumpus> odroid C2
 762016-04-06T09:10:13  <jonasschnelli> I have ordered a PINE A64. ~same sepcs..
 772016-04-06T09:10:20  <wumpus> how much memroy?
 782016-04-06T09:10:22  <jonasschnelli> 2GB
 792016-04-06T09:10:29  <jonasschnelli> (which is essential)
 802016-04-06T09:10:58  <jonasschnelli> I think we might finally have tiny devices that can run a fullnode and cost <40USD.
 812016-04-06T09:11:02  <wumpus> yes I'd preferred one with 8GB but at least it's not abysmal :)
 822016-04-06T09:11:08  <jonasschnelli> A fullnode next to your router...
 832016-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
 842016-04-06T09:12:09  <jonasschnelli> imdb sounds promissing...
 852016-04-06T09:12:42  <jonasschnelli> wumpus: what this needs a very fast, close-to-hw, key/value store    <--- I agree!
 862016-04-06T09:12:51  <jonasschnelli> C based
 872016-04-06T09:13:54  <jonasschnelli> wumpus: How fast is the "disk" (flash) access on the Odroid C2? You think its enough for UTXO queries?
 882016-04-06T09:13:55  <wumpus> exactly!
 892016-04-06T09:14:48  *** jtimon has joined #bitcoin-core-dev
 902016-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
 912016-04-06T09:16:23  <jonasschnelli> wumpus USB2.0 should probably fast enought... though, in theory (IIRC) gbit ethernet should be faster.
 922016-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
 932016-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
 942016-04-06T09:17:25  <wumpus> of course, that's kind of cheating :)
 952016-04-06T09:17:33  <jonasschnelli> hah. true!
 962016-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
 972016-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
 982016-04-06T09:18:17  <btcdrak> yeah that thing is going to rock
 992016-04-06T09:18:31  <jonasschnelli> 1,2GHZ Cortext A53
1002016-04-06T09:18:49  <wumpus> nice! yes specs look very much like the odroid C2
1012016-04-06T09:18:56  <jonasschnelli> Wel.. the Odroid runs on 2Ghz
1022016-04-06T09:19:20  <jonasschnelli> I mean, 29USD. Holly!
1032016-04-06T09:19:53  <sipa> i have a rpi3 now
1042016-04-06T09:20:04  <jonasschnelli> 512MB ram?!
1052016-04-06T09:20:14  <sipa> which also has an arm64 cpu, though their kernel is still 32-bit :(
1062016-04-06T09:20:35  <jonasschnelli> Ordoid C2: * Infrared(IR) Receiver? :|
1072016-04-06T09:21:07  <sipa> We need a bitcoin-over-ir protocol...
1082016-04-06T09:25:16  <jonasschnelli> haha...
1092016-04-06T09:48:55  *** MarcoFalke has joined #bitcoin-core-dev
1102016-04-06T09:51:14  *** xiangfu has quit IRC
1112016-04-06T09:51:40  <wumpus> I've heard about bitcoin over nfc, but no never over IRyet :-)
1122016-04-06T09:53:43  <Luke-Jr> turn gameboy colour into a hw wallet?
1132016-04-06T09:58:06  <wumpus> almost all those ARM boards have an IR receiver, but never a transmitter
1142016-04-06T10:07:21  <wumpus> yes you could use it for communication with a gameboy color probably :-)
1152016-04-06T10:09:28  <wumpus> not sure about wavelengths, frequencies etc
1162016-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
1172016-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
1182016-04-06T10:33:10  *** p15x has quit IRC
1192016-04-06T10:38:27  *** broofa has joined #bitcoin-core-dev
1202016-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
1212016-04-06T10:40:36  *** broofa has quit IRC
1222016-04-06T10:44:35  *** laurentmt has joined #bitcoin-core-dev
1232016-04-06T10:49:53  *** laurentmt has quit IRC
1242016-04-06T10:50:10  *** laurentmt has joined #bitcoin-core-dev
1252016-04-06T10:50:13  *** laurentmt has quit IRC
1262016-04-06T10:58:05  *** fengling has quit IRC
1272016-04-06T11:08:29  *** laurentmt has joined #bitcoin-core-dev
1282016-04-06T11:08:38  *** laurentmt has quit IRC
1292016-04-06T11:16:56  *** randy-waterhouse has left #bitcoin-core-dev
1302016-04-06T11:34:53  *** cryptapus has joined #bitcoin-core-dev
1312016-04-06T11:34:53  *** cryptapus has joined #bitcoin-core-dev
1322016-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
1332016-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
1342016-04-06T12:08:47  <jtimon> MarcoFalke: told me that some people told him they kind of like #7779
1352016-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?
1362016-04-06T12:10:55  <wumpus> heh we have kind of a PR storm at the moment
1372016-04-06T12:13:13  <GitHub168> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1b2460bd5824...70ac71b877f3
1382016-04-06T12:13:14  <GitHub168> bitcoin/master ffff866 MarcoFalke: [qa] Remove misleading "errorString syntax"
1392016-04-06T12:13:14  <GitHub168> bitcoin/master 70ac71b Wladimir J. van der Laan: Merge #7801: [qa] Remove misleading "errorString syntax"...
1402016-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
1412016-04-06T12:13:59  <GitHub191> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/70ac71b877f3...401c65c6b3e2
1422016-04-06T12:13:59  <GitHub191> bitcoin/master fac724c MarcoFalke: [qa] maxblocksinflight: Actually enable test
1432016-04-06T12:14:00  <GitHub191> bitcoin/master 401c65c Wladimir J. van der Laan: Merge #7803: [qa] maxblocksinflight: Actually enable test...
1442016-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
1452016-04-06T12:14:34  <GitHub54> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/401c65c6b3e2...3bc71e1572cb
1462016-04-06T12:14:34  <GitHub54> bitcoin/master fa24456 MarcoFalke: [qa] httpbasics: Actually test second connection
1472016-04-06T12:14:35  <GitHub54> bitcoin/master 3bc71e1 Wladimir J. van der Laan: Merge #7802: [qa] httpbasics: Actually test second connection...
1482016-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
1492016-04-06T12:14:54  <wumpus> jtimon: maybe ask people to look at it during the meeting
1502016-04-06T12:18:38  <jtimon> quote from MarcoFalke "Actually we were discussing on IRC with wumpus morcos and sduftar.
1512016-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
1522016-04-06T12:19:24  <jtimon> sdaftuar:
1532016-04-06T12:19:35  <jtimon> I'll just leave it here
1542016-04-06T12:24:39  <wumpus> we should also inform about the c++11 transition in the upcoming meeting, I want to use nullptr  @sipa :)
1552016-04-06T12:26:07  <paveljanik> jtimon, I guess it is because it slipped to the second page of the PRs.
1562016-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)
1572016-04-06T12:29:35  <wumpus> agreed on that
1582016-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
1592016-04-06T12:30:40  <btcdrak> and again here https://bitcoincore.org/en/meetings/2016/01/21/#c11-update
1602016-04-06T12:30:45  <wumpus> thanks :)
1612016-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
1622016-04-06T12:31:09  <wumpus> It might be still blocked on travis caching support, not sure though
1632016-04-06T12:36:14  *** laurentmt has joined #bitcoin-core-dev
1642016-04-06T12:47:11  *** cryptapus__ has joined #bitcoin-core-dev
1652016-04-06T12:47:11  *** cryptapus__ has joined #bitcoin-core-dev
1662016-04-06T12:48:38  *** cryptapus__ is now known as cryptapus_
1672016-04-06T12:50:08  *** cryptapus has quit IRC
1682016-04-06T12:53:09  *** Ylbam has joined #bitcoin-core-dev
1692016-04-06T12:59:35  *** supasonic has joined #bitcoin-core-dev
1702016-04-06T13:02:46  <jonasschnelli> hmm... the GUI does not show wallet conflicts. Right? IIRC, there where PRs from dgenr8?
1712016-04-06T13:03:50  <jonasschnelli> With RBF this will be required somehow
1722016-04-06T13:04:23  <btcdrak> jonasschnelli: https://github.com/bitcoin/bitcoin/pulls?utf8=%E2%9C%93&q=is%3Apr+author%3Adgenr8+
1732016-04-06T13:05:45  <jonasschnelli> btcdrak: Thanks...
1742016-04-06T13:05:52  <jtimon> mhmm, 1b2460b doesn't pass python ./qa/pull-tester/rpc-tests.py (mempool_limit.py fails), git fetch origin...
1752016-04-06T13:09:31  *** gevs has joined #bitcoin-core-dev
1762016-04-06T13:13:34  *** Cory has quit IRC
1772016-04-06T13:17:02  <jtimon> mhmm, 3bc71e1 *   origin/master seems to fail too...
1782016-04-06T13:17:24  *** laurentmt has quit IRC
1792016-04-06T13:17:41  *** Cory has joined #bitcoin-core-dev
1802016-04-06T13:17:43  <jtimon> do I need to do anything else besides rm -rf cache or the current master wouldn't pass travis?
1812016-04-06T13:18:18  <jtimon> wumpus: ?
1822016-04-06T13:18:47  <wumpus> is that the extended or the base tests?
1832016-04-06T13:18:55  <wumpus> only the base tests are run by travis
1842016-04-06T13:19:07  <jtimon> the base ones mempool_limit.py
1852016-04-06T13:19:31  <wumpus> those should indeed pass, haven't heard travis complain
1862016-04-06T13:19:32  <jtimon> python ./qa/pull-tester/rpc-tests.py mempool_limit
1872016-04-06T13:19:51  <wumpus> what error do you get?
1882016-04-06T13:20:44  <jtimon> https://0bin.net/paste/qSAK6dUwqKg8rAQL#b8PsedY3uoBOHP3J-bsCQ73XyGXgr6XhSEDcQXctC/J
1892016-04-06T13:21:13  <wumpus> hm weird, never saw that one
1902016-04-06T13:21:32  <jtimon> you don't reproduce it on current master?
1912016-04-06T13:22:14  *** frankenmint has quit IRC
1922016-04-06T13:22:47  <wumpus> can't try rght now
1932016-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
1942016-04-06T13:24:44  <paveljanik> jtimon, mmnt
1952016-04-06T13:24:54  <jtimon> paveljanik: awesome thanks
1962016-04-06T13:24:57  <sipa> wumpus: ack on nullptr :)
1972016-04-06T13:25:17  *** cryptapus_ is now known as cryptapus
1982016-04-06T13:26:37  <jtimon> wumpus: sipa: suggestions for more C++11-ish "extern boost::scoped_ptr<CPolicy> globalPolicy;" ?
1992016-04-06T13:26:44  <paveljanik> jtimon, OK, 3s
2002016-04-06T13:26:55  <jtimon> paveljanik: no hurry
2012016-04-06T13:27:03  <paveljanik> no, it is finished -
2022016-04-06T13:27:07  <paveljanik> Tests successful
2032016-04-06T13:27:08  <paveljanik> Duration: 3 s
2042016-04-06T13:27:08  <wumpus> a global scoped ptr? no, I don't like that
2052016-04-06T13:27:29  <wumpus> if you need them at all, please explicitly create/initialize and teardown global objects
2062016-04-06T13:27:31  <paveljanik> jtimon, what does it print for you?
2072016-04-06T13:27:42  <paveljanik> ah mempool full
2082016-04-06T13:27:43  <wumpus> we've had enough (de)initialization order problems to last a lifetime
2092016-04-06T13:27:45  <paveljanik> not here...
2102016-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
2112016-04-06T13:29:23  <jtimon> it seems "rm -rf cache" is not enough
2122016-04-06T13:29:59  <jtimon> wumpus: where's the right place for deleting global pointers ?
2132016-04-06T13:31:24  <jtimon> people seemed to like boost::scoped_ptr<CChainParams> for #6907
2142016-04-06T13:31:34  <wumpus> jtimon: shutdown()
2152016-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
2162016-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
2172016-04-06T13:34:13  <wumpus> and ideally the global pointer would be restricted within one module, not shared via external, but passed where necessary
2182016-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, ...
2192016-04-06T13:35:07  <sipa> and there are no globals at all
2202016-04-06T13:35:10  * sipa dreams
2212016-04-06T13:35:14  <wumpus> yes, no globals would be best
2222016-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
2232016-04-06T13:35:33  <jtimon> ?
2242016-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
2252016-04-06T13:36:03  <wumpus> doesn't sound good to me
2262016-04-06T13:36:09  <wumpus> keep the globals with the code that uses them
2272016-04-06T13:36:18  <wumpus> keep them as local as possible
2282016-04-06T13:36:35  <wumpus> this makes it easier to make it into a class, too
2292016-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
2302016-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)
2312016-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
2322016-04-06T13:44:24  <jtimon> I changed the topic, sorry. I guess the answer to my original question is http://stackoverflow.com/a/5294005
2332016-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)
2342016-04-06T13:53:46  <jtimon> where should Params() be called from? ideally, nowhere
2352016-04-06T13:55:04  <jtimon> but only from init and one other place would be almost as ideal
2362016-04-06T13:56:54  *** Chris_Stewart_5 has quit IRC
2372016-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
2382016-04-06T13:57:35  <wumpus> similar to private: or protected: in classes
2392016-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
2402016-04-06T13:59:48  <wumpus> and stored in appropriate places within classes, so they can pass it on
2412016-04-06T14:00:49  *** nanotube has quit IRC
2422016-04-06T14:02:11  <jonasschnelli> sipa: ping
2432016-04-06T14:02:16  <sipa> jonasschnelli: pang
2442016-04-06T14:02:22  <jonasschnelli> You remember the SetMerkleBranch PR for the wallet:
2452016-04-06T14:02:23  <jonasschnelli> https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.cpp#L3299
2462016-04-06T14:02:45  <jonasschnelli> The GUI does not detect RBF conflicts...
2472016-04-06T14:03:01  <sipa> ?
2482016-04-06T14:03:07  <jonasschnelli> You return 0 (=in mempool) if the hash is unset... is that correct
2492016-04-06T14:03:14  <jonasschnelli> (hash of the block)
2502016-04-06T14:03:27  <sipa> yes, it means the transaction is not known to be in a block
2512016-04-06T14:03:47  <jonasschnelli> https://github.com/bitcoin/bitcoin/blob/master/src/wallet/wallet.h#L204
2522016-04-06T14:04:12  <sipa> that's outdated; it's not necessarily in the mempool
2532016-04-06T14:04:16  <jonasschnelli> I think the GUI needs an aditional mempool check then
2542016-04-06T14:05:17  <jonasschnelli> Somehow the wallet does not detect conflict with a transaction that is not in the mempool
2552016-04-06T14:05:21  <jonasschnelli> *conflicts
2562016-04-06T14:05:22  <sipa> for detecting what case?
2572016-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.
2582016-04-06T14:06:05  <gmaxwell> $ ./bitcoin-cli stop
2592016-04-06T14:06:06  <gmaxwell> error: couldn't parse reply from server
2602016-04-06T14:06:08  <gmaxwell> 0_o
2612016-04-06T14:06:20  <jonasschnelli> (the first transaction is removed from the mempool)
2622016-04-06T14:06:57  <sipa> jonasschnelli: known to conflict is only for conflicting with confirmed transactions
2632016-04-06T14:07:15  <sipa> jonasschnelli: you can use IsTrusted ?
2642016-04-06T14:07:21  *** aj has quit IRC
2652016-04-06T14:07:34  <jonasschnelli> sipa: okay. Let me see..
2662016-04-06T14:07:54  *** aj has joined #bitcoin-core-dev
2672016-04-06T14:07:57  <sipa> jonasschnelli: i don't know the gui, and i don't really know what you're talking about
2682016-04-06T14:08:45  <gmaxwell> hm. seems to be deadlocked
2692016-04-06T14:08:50  <jonasschnelli> hah. Yes. Forget about it. I'll work on it and show you some code... thats better understandable.
2702016-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
2712016-04-06T14:13:26  <sipa> gmaxwell: https://github.com/sipa/bitcoin/commit/115157b45caa374719fa6ad2a3d46281c9109349
2722016-04-06T14:13:36  <sipa> gmaxwell: going to run with that to monitor
2732016-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
2742016-04-06T14:15:42  *** nanotube has joined #bitcoin-core-dev
2752016-04-06T14:15:53  <gmaxwell> Yes, it does.
2762016-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
2772016-04-06T14:16:14  <sipa> gmaxwell: but i doubt it matters at all now
2782016-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)
2792016-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
2802016-04-06T14:19:29  * sipa ducks
2812016-04-06T14:19:57  <gmaxwell> cached createnew block and intersect with the inventory. :P
2822016-04-06T14:20:48  <sipa> do you have any statistics for how this affects orphan tx?
2832016-04-06T14:21:04  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2842016-04-06T14:21:08  <sipa> i guess you'd need a test setup with multiple nodes
2852016-04-06T14:21:13  <gmaxwell> not yet, though with only two nodes running it, I couldn't measure.
2862016-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.
2872016-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?
2882016-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
2892016-04-06T14:30:17  <sipa> Chris_Stewart_5: strictenc also disallows hybrid public key encoding
2902016-04-06T14:31:28  *** Luke-Jr has quit IRC
2912016-04-06T14:33:58  <Chris_Stewart_5> why isn't the hash type being defined in the bip66 specification?
2922016-04-06T14:34:32  <sipa> because it's not necessary
2932016-04-06T14:34:41  *** cryptapus has quit IRC
2942016-04-06T14:34:42  <sipa> the hashtype is included in the sighash, so you can't modify it
2952016-04-06T14:34:50  <sipa> or it would invalidate the signature
2962016-04-06T14:34:56  *** d_t has joined #bitcoin-core-dev
2972016-04-06T14:34:57  *** cryptapus has joined #bitcoin-core-dev
2982016-04-06T14:34:57  *** cryptapus has joined #bitcoin-core-dev
2992016-04-06T14:45:07  *** laurentmt has joined #bitcoin-core-dev
3002016-04-06T14:49:35  *** laurentmt has quit IRC
3012016-04-06T15:08:18  *** gevs has quit IRC
3022016-04-06T15:08:21  *** Chris_Stewart_5 has quit IRC
3032016-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
3042016-04-06T15:18:01  *** laurentmt has joined #bitcoin-core-dev
3052016-04-06T15:20:16  *** laurentmt has quit IRC
3062016-04-06T15:20:45  *** gevs has joined #bitcoin-core-dev
3072016-04-06T15:20:45  *** gevs has joined #bitcoin-core-dev
3082016-04-06T15:22:27  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3092016-04-06T15:25:32  *** hsmiths has quit IRC
3102016-04-06T15:26:26  *** MarcoFalke has quit IRC
3112016-04-06T15:27:27  *** hsmiths has joined #bitcoin-core-dev
3122016-04-06T15:29:09  *** MarcoFalke has joined #bitcoin-core-dev
3132016-04-06T15:50:39  *** Luke-Jr has joined #bitcoin-core-dev
3142016-04-06T16:04:32  *** hsmiths has quit IRC
3152016-04-06T16:05:52  *** hsmiths has joined #bitcoin-core-dev
3162016-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
3172016-04-06T16:31:22  <sipa> wumpus: not necessarily, i think
3182016-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
3192016-04-06T16:32:14  <sipa> to mimick the batch update model
3202016-04-06T16:32:48  <wumpus> http://symas.com/mdb/doc/group__mdb.html#ga8bf10cd91d3f3a83a34d04ce6b07992d
3212016-04-06T16:33:40  <wumpus> yes, that could work
3222016-04-06T17:15:12  *** AaronvanW has quit IRC
3232016-04-06T17:17:21  *** jannes has quit IRC
3242016-04-06T17:41:02  *** ^arubi is now known as arubi
3252016-04-06T18:12:03  *** hybridsole has quit IRC
3262016-04-06T18:29:57  *** bsm117532 has quit IRC
3272016-04-06T18:33:15  *** Chris_Stewart_5 has quit IRC
3282016-04-06T18:34:58  *** hybridsole has joined #bitcoin-core-dev
3292016-04-06T18:41:05  *** SteveTaylor has quit IRC
3302016-04-06T18:56:03  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3312016-04-06T18:57:44  *** molz has joined #bitcoin-core-dev
3322016-04-06T18:59:46  *** moli has quit IRC
3332016-04-06T19:11:03  <wumpus> cool, I have bitcoind working with lmdb
3342016-04-06T19:11:57  <btcdrak> wumpus: that was fast
3352016-04-06T19:12:12  <btcdrak> the question is, is it faster? =)
3362016-04-06T19:12:16  <wumpus> well it's one big hack
3372016-04-06T19:12:20  <wumpus> I don't know yet
3382016-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 ;)
3392016-04-06T19:13:39  <wumpus> but it feels quite fast
3402016-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.
3412016-04-06T19:16:14  <wumpus> yes
3422016-04-06T19:21:58  <jonasschnelli> wumpus: well done... looking forward to see some benachmarks / footprint comparison!
3432016-04-06T19:28:01  *** Chris_Stewart_5 has quit IRC
3442016-04-06T19:36:36  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3452016-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
3462016-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?
3472016-04-06T20:05:03  <Chris_Stewart_5> i.e. it indicates the ending of the scriptSig & beginning of the scriptPubKey?
3482016-04-06T20:06:57  <sipa> Chris_Stewart_5: it is assumed that it waas intended to allow delegation
3492016-04-06T20:07:33  <sipa> someone signing over the right to sign to someone else, under other conditions
3502016-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 :-/
3512016-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
3522016-04-06T20:24:02  *** zooko has joined #bitcoin-core-dev
3532016-04-06T20:26:40  *** Chris_Stewart_5 has quit IRC
3542016-04-06T20:28:27  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3552016-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
3562016-04-06T20:38:14  *** cryptapus has quit IRC
3572016-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)
3582016-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
3592016-04-06T21:06:09  *** zooko has quit IRC
3602016-04-06T21:17:42  *** d_t has quit IRC
3612016-04-06T21:20:34  *** supasonic has quit IRC
3622016-04-06T21:21:15  *** supasonic has joined #bitcoin-core-dev
3632016-04-06T21:26:51  *** supasonic has quit IRC
3642016-04-06T21:27:17  *** supasonic has joined #bitcoin-core-dev
3652016-04-06T21:35:00  *** d_t has joined #bitcoin-core-dev
3662016-04-06T21:35:34  *** d_t has joined #bitcoin-core-dev
3672016-04-06T21:36:05  *** d_t has joined #bitcoin-core-dev
3682016-04-06T21:46:19  *** Arnavion has quit IRC
3692016-04-06T21:47:30  *** Arnavion has joined #bitcoin-core-dev
3702016-04-06T21:59:46  *** d_t has quit IRC
3712016-04-06T22:23:33  <kanzure> jtimon: why do you want pull request 7829 "never merged"?
3722016-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
3732016-04-06T22:42:19  <jtimon> kanzure: does that make any sense?
3742016-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 ...
3752016-04-06T22:43:39  <kanzure> ... master branch to keep everything updated."
3762016-04-06T22:43:42  <kanzure> (however, it's unclear to me if that is an accurate summary)
3772016-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
3782016-04-06T22:45:54  <kanzure> if your intention was tutorship then that was not clear to me reading the PR text :)
3792016-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
3802016-04-06T22:46:36  <jtimon> kanzure: that is good feedback
3812016-04-06T22:46:55  *** Guyver2 has quit IRC
3822016-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 :)
3832016-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
3842016-04-06T22:48:49  *** randy-waterhouse has joined #bitcoin-core-dev
3852016-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.
3862016-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)
3872016-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
3882016-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 ...
3892016-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)."
3902016-04-06T22:54:40  <jtimon> ok, I pasted your comment on the PR
3912016-04-06T22:54:50  <jtimon> very grateful, but...
3922016-04-06T22:55:04  <jtimon> "I have marked a number of TODO comments in the source code of this pull request"
3932016-04-06T22:55:37  <jtimon> I haven't merged anything anywhere, at most #7828  as an example
3942016-04-06T22:56:47  *** Giszmo has quit IRC
3952016-04-06T23:04:27  <jtimon> kanzure: never mind, "of this pull request", re-read, all fine, thank you very much
3962016-04-06T23:05:14  <kanzure> yep
3972016-04-06T23:05:28  <jtimon> you captured the spirit and improved the description
3982016-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
3992016-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
4002016-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)
4012016-04-06T23:10:24  <jtimon> but I have to admit that moving from subversion to git was kind of a shock for me
4022016-04-06T23:10:45  <kanzure> bitcoin was your first introduction to git?
4032016-04-06T23:11:12  <jtimon> well, I fetch pybrain before that, but basically yes
4042016-04-06T23:11:17  *** laurentmt has joined #bitcoin-core-dev
4052016-04-06T23:11:31  <jtimon> never pushed anything to git that wasn't mine before git
4062016-04-06T23:11:35  *** laurentmt has quit IRC
4072016-04-06T23:11:44  <jtimon> before bitcoin
4082016-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)
4092016-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
4102016-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
4112016-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
4122016-04-06T23:35:51  *** p15 has joined #bitcoin-core-dev
4132016-04-06T23:59:54  <jtimon> where is the longest branch for 0.12.1?