--- Day changed Fri Apr 21 2017 00:08 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev 00:12 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Ping timeout: 260 seconds] 00:17 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:34 -!- chatter29 [bc2adf28@gateway/web/cgi-irc/kiwiirc.com/ip.188.42.223.40] has joined #bitcoin-core-dev 00:34 < chatter29> hey guys 00:34 < chatter29> allah is doing 00:34 < chatter29> sun is not doing allah is doing 00:35 < chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger 00:35 -!- chatter29 [bc2adf28@gateway/web/cgi-irc/kiwiirc.com/ip.188.42.223.40] has quit [Client Quit] 01:02 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev 01:04 -!- CubicEarth [~cubiceart@c-67-168-4-85.hsd1.wa.comcast.net] has joined #bitcoin-core-dev 01:07 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Ping timeout: 260 seconds] 01:13 < CubicEarth> Should the default keypool size be increased to 1000? 01:13 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev 01:14 < CubicEarth> Or is HD the new default? 01:27 -!- tw2006 [~tw2006@2601:187:8480:2770:a4bd:c997:5421:8220] has joined #bitcoin-core-dev 01:32 -!- tw2006 [~tw2006@2601:187:8480:2770:a4bd:c997:5421:8220] has quit [Ping timeout: 240 seconds] 01:34 -!- CubicEarth [~cubiceart@c-67-168-4-85.hsd1.wa.comcast.net] has quit [] 01:40 -!- gm2052 [~gm2051@2a02:c7d:12e:100:7d68:5847:3bfe:8327] has joined #bitcoin-core-dev 01:42 -!- molz_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 01:44 -!- gm2051 [~gm2051@2a02:c7d:12e:100:7d6e:9411:9766:c3eb] has quit [Ping timeout: 240 seconds] 01:45 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 01:47 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/86ea3c2ff247...694062eafec5 01:47 < bitcoin-git> bitcoin/master 0611bc3 Shigeya Suzuki: Minor fix in build documentation for FreeBSD 11... 01:47 < bitcoin-git> bitcoin/master 694062e Wladimir J. van der Laan: Merge #10245: Minor fix in build documentation for FreeBSD 11... 01:48 < bitcoin-git> [bitcoin] laanwj closed pull request #10245: Minor fix in build documentation for FreeBSD 11 (master...freebsd-11-build-doc-fix) https://github.com/bitcoin/bitcoin/pull/10245 01:54 -!- gm2053 [~gm2051@2a02:c7d:12e:100:19b5:51d1:eca2:7739] has joined #bitcoin-core-dev 01:56 -!- goksinen [~goksinen@2604:2000:c591:8400:ec56:fe7a:ed70:280c] has joined #bitcoin-core-dev 01:57 -!- gm2051 [~gm2051@2a02:c7d:12e:100:9cdc:4e89:c7ed:da2d] has joined #bitcoin-core-dev 01:57 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/694062eafec5...0416ea9f743f 01:57 < bitcoin-git> bitcoin/master 394ccf7 Pieter Wuille: Make Boost use std::atomic internally 01:57 < bitcoin-git> bitcoin/master 0416ea9 Wladimir J. van der Laan: Merge #10239: Make Boost use std::atomic internally... 01:57 -!- gm2052 [~gm2051@2a02:c7d:12e:100:7d68:5847:3bfe:8327] has quit [Ping timeout: 252 seconds] 01:57 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0416ea9f743f...f6f3b58a7250 01:57 < bitcoin-git> bitcoin/master fb463d1 Russell Yanofsky: [qt] Don't call method on null WalletModel object... 01:57 < bitcoin-git> bitcoin/master f6f3b58 Wladimir J. van der Laan: Merge #10242: [qt] Don't call method on null WalletModel object... 01:57 < bitcoin-git> [bitcoin] laanwj closed pull request #10242: [qt] Don't call method on null WalletModel object (master...pr/rbfnull) https://github.com/bitcoin/bitcoin/pull/10242 01:59 -!- gm2053 [~gm2051@2a02:c7d:12e:100:19b5:51d1:eca2:7739] has quit [Ping timeout: 255 seconds] 02:01 -!- goksinen [~goksinen@2604:2000:c591:8400:ec56:fe7a:ed70:280c] has quit [Ping timeout: 260 seconds] 02:12 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/f6f3b58a7250...27faa6cccd8d 02:12 < bitcoin-git> bitcoin/master 3577603 Cory Fields: build: remove wonky auto top-level convenience targets... 02:12 < bitcoin-git> bitcoin/master 91ab8f5 Cory Fields: build: fix bitcoin-config.h regeneration after touching build files... 02:12 < bitcoin-git> bitcoin/master 27faa6c Wladimir J. van der Laan: Merge #10228: build: regenerate bitcoin-config.h as necessary... 02:13 < bitcoin-git> [bitcoin] laanwj closed pull request #10228: build: regenerate bitcoin-config.h as necessary (master...fix-config-h) https://github.com/bitcoin/bitcoin/pull/10228 02:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:15 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 02:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 02:19 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 02:38 * wumpus still deleting "qa" directories everywhere :-) 02:43 -!- jtimon [~quassel@9.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 02:50 -!- goksinen [~goksinen@2604:2000:c591:8400:ec56:fe7a:ed70:280c] has joined #bitcoin-core-dev 02:55 -!- goksinen [~goksinen@2604:2000:c591:8400:ec56:fe7a:ed70:280c] has quit [Ping timeout: 260 seconds] 03:04 -!- AaronvanW [~AaronvanW@66.red-88-11-249.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 03:04 -!- AaronvanW [~AaronvanW@66.red-88-11-249.dynamicip.rima-tde.net] has quit [Changing host] 03:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:09 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 03:14 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 03:16 -!- tw2006 [~tw2006@2601:187:8480:2770:5d1b:3942:c991:2ba4] has joined #bitcoin-core-dev 03:21 -!- tw2006 [~tw2006@2601:187:8480:2770:5d1b:3942:c991:2ba4] has quit [Ping timeout: 258 seconds] 03:44 -!- goksinen [~goksinen@2604:2000:c591:8400:ec56:fe7a:ed70:280c] has joined #bitcoin-core-dev 03:49 -!- goksinen [~goksinen@2604:2000:c591:8400:ec56:fe7a:ed70:280c] has quit [Ping timeout: 260 seconds] 03:54 -!- elkalamar [~pepe@84.126.69.179.dyn.user.ono.com] has quit [Quit: Leaving] 04:00 < jonasschnelli> #10244 and the IPC approach is in general good. Is there a broad agreement that we want to do this? I vaguely remember gmaxwell had some concerns. Just to give more clear feedback to ryanofsky 04:00 < gribble> https://github.com/bitcoin/bitcoin/issues/10244 | [qt] Add abstraction layer for accessing node and wallet functionality from gui by ryanofsky · Pull Request #10244 · bitcoin/bitcoin · GitHub 04:01 < jonasschnelli> I like it 04:02 < jonasschnelli> But I remember when I also tried to write such *larger* PRs... they just have a hard time getting reviewed. Constant rebase and often great risks when merging. 04:15 -!- nu11p7r [~nu11p7r@dfaefce4-1ec2-41ac-b8f9-6bd816c36ded.node.sporestack.com] has quit [Ping timeout: 240 seconds] 04:17 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds] 04:18 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 04:19 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 04:20 <@wumpus> yes it's difficult to do a big change like thta 04:21 <@wumpus> I agree broadly, on the approach, the thing I didn't like about it is that he seemed to add more abstraction layers. What I don't like about that is that it reduces flexibility, hardcoding maybe stupid choices that were made years ago and made sense at the time, buried beneath layers of calls. 04:22 <@wumpus> my original plan was to make ClientModel and WalletModel the abstractions for the core, they are currently thin wrappers around it, and could be extended/changed to support a remote core instance instead 04:23 <@wumpus> along with using async notifications for replies from the core instead of synchronous calls and busy-waiting on locks 04:23 <@wumpus> so I'm happy he's doing it, but it's not in the way that I would, maybe I should just let it go though 04:26 <@wumpus> though I have a hard time reviewing code changes that aren't in line with my own thoughts 04:26 <@wumpus> especially big ones 04:26 < sipa> wumpus: is your concern that the result makes the client/walletmodel less independent? 04:26 < sipa> in that it now requires the IPC abstraction below it 04:27 <@wumpus> sipa: mostly that the code becomes even harder to work on 04:27 <@wumpus> it seems like a double abstraction; walletmodel is already an abstraction for core's CWallet 04:27 <@wumpus> now there's a class in between 04:29 < sipa> seems like a reasonable concern to me... WalletModel and ClientModel don't really have much responsibility anymore 04:29 <@wumpus> the best way to implement remote-anything is not necessarily changing every direct call into a IPC call 04:30 <@wumpus> it's the easiest way to do it, but it's not how modern GUIs are written, ther shouldn't be anything waiting on replies from a remote process inside the GUI thread/loop 04:31 <@wumpus> even for local implementation this is wrong, and it means that while e.g. sending a transaction while cs_main is busy, the GUI hangs instead of being able to show a moving progress indicator 04:31 <@wumpus> I'm much more concerned with that than IPCing everything 04:31 < sipa> seems reasonable, i don't know much about that 04:31 <@wumpus> so this is kind of calcifying the state of the code that I'm already not happy with 04:35 < jonasschnelli> wumpus: I completely agree with you. 04:35 < jonasschnelli> I think it will be very hard to change the GUI towards that goal with the current review strategy 04:35 <@wumpus> jonasschnelli: I tried to talk to him about this, but he seemed convinced that my concern had nothing to do with his changes, and that this can be done first. 04:36 < jonasschnelli> Also the split between Wallet and Node (walletmodal / clientmodel) makes really sense. 04:36 < jonasschnelli> *model 04:37 <@wumpus> and he's not entirely incorrect but I in my opinoin it makes sense to combine those two things; if the core and GUI communicate with asynchronous messages, goign from there to an IPC protocol is much easier 04:37 < jonasschnelli> I often though maybe rewrite the GUI from the ground up,... 04:38 <@wumpus> and will likely be less complex 04:38 <@wumpus> I'm not sure that is a good idea 04:38 < jonasschnelli> Yeah.. me neither... :) 04:38 <@wumpus> a rewrite is a lot of work to get feature parity, all bugs are born new, etc 04:39 <@wumpus> usually I prefer incremental improvements unless something is total junk, which I think the code is not 04:39 < sipa> wumpus: that was my concern as well... it seems crazy to me that introducing an IPC layer somehow helps making things more asynchronous 04:39 <@wumpus> sipa: not the way he's doing it, at least 04:39 <@wumpus> in the way I always imagined doing it, it would 04:39 < jonasschnelli> What design would make sense for asynchronous messages? 04:40 <@wumpus> jonasschnelli: qt signals/slots? same way that RPCConsole and RPCThread communicate for example 04:41 < jonasschnelli> So each node call would run in its own thread? Or would that be a single node-/wallet-interaction thread with queue? 04:41 <@wumpus> signals could be generated by something that listens to a network pipe or local implemantion, most of the GUI code could be oblivous to that 04:41 <@wumpus> one thread should be OK usually 04:42 -!- gm2052 [~gm2051@2a02:c7d:12e:100:b571:c37e:1f05:a513] has joined #bitcoin-core-dev 04:42 <@wumpus> long running operations could be their own thread 04:42 < jonasschnelli> Yes. I think this would be much better... would also require context sensitive activity-inidcators instead of a GUI freeze when communication is in progress 04:42 <@wumpus> right 04:43 < jonasschnelli> reminds me that the RPCConcole/RPCThread missed a activity indicator... 04:43 <@wumpus> heck, even changing the cursor to a bee as on the Atari ST is better than hanging the GUI 04:43 < jonasschnelli> (things like topupkeypool 1000) 04:43 < jonasschnelli> wumpus: haha 04:43 <@wumpus> yes, indeed, it doesn't provide feedback that something is in progress 04:43 < jonasschnelli> Yes. We could start with a general activity indicator ("node communication happening") in the status bar 04:44 < jonasschnelli> I hope we can convince ryanofsky 04:44 <@wumpus> in any case showing a modal dialog is still possible 04:44 <@wumpus> if you don't want the user to do other things 04:44 <@wumpus> that's not hanging the GUI; the dialog could e.g. show an animation, or have an abort butotn, or react to the user in other ways 04:45 < jonasschnelli> Yes. The modal non blocking concept is much better 04:45 < jonasschnelli> Blocking the GUI must be avoided any time 04:45 -!- gm2051 [~gm2051@2a02:c7d:12e:100:9cdc:4e89:c7ed:da2d] has quit [Ping timeout: 255 seconds] 04:45 < jonasschnelli> Otherwise users will force quite 04:46 < jonasschnelli> force kill 04:46 <@wumpus> right. And some OSes will blank out the window 04:52 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 04:53 -!- BCBot [~BCBot@46.101.246.115] has quit [Remote host closed the connection] 04:54 -!- BCBot [~BCBot@46.101.246.115] has joined #bitcoin-core-dev 04:54 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 260 seconds] 05:00 < bitcoin-git> [bitcoin] sipa opened pull request #10248: Introduce CHashVerifier to hash while deserializing (master...chashverifier) https://github.com/bitcoin/bitcoin/pull/10248 05:02 <@wumpus> so on the other hand I like that people actively work on the code and dno't want to discourage it, just because I have some different ideas 05:05 -!- tw2006 [~tw2006@2601:187:8480:2770:94c:21f4:8453:8a0e] has joined #bitcoin-core-dev 05:07 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 05:10 -!- tw2006 [~tw2006@2601:187:8480:2770:94c:21f4:8453:8a0e] has quit [Ping timeout: 260 seconds] 05:11 <@wumpus> I know I myself have way too many ideas and too little time to work on them 05:12 -!- str4d [~str4d@27.110.123.91] has quit [Ping timeout: 260 seconds] 05:13 < sipa> i think the ultimate goal of having the GUI being independent from the core, and being able to start/stop it separate is very nice 05:13 -!- nu11p7r [~nu11p7r@dfaefce4-1ec2-41ac-b8f9-6bd816c36ded.node.sporestack.com] has joined #bitcoin-core-dev 05:13 < sipa> if that requires an extra abstraction layer somewhere, fine 05:13 < sipa> but i'm not convinced why that abstraction layer can't be clientmodel/walletmodel 05:24 < jonasschnelli> I think one of ryanofsky arguments is that the client-/walletmodal also contains "business" logic and not only communication handling. 05:24 < jonasschnelli> Which I partially can follow 05:25 < sipa> well that business logic should move to the core 05:25 < sipa> some of it can likely be merged with some code in rpcwallet 05:27 < luke-jr> Random reddit user suggests that txindex should default to on when pruning is disabled. 05:28 < sipa> ...? 05:28 < luke-jr> he was annoyed he had to reindex to setup an Electrum server because txindex defaulted to off, and argues that the txindex is small compared to the full blockchain 05:29 < sipa> it's huge compared to the utxo set 05:29 < luke-jr> https://www.reddit.com/r/Bitcoin/comments/66k36g/why_does_electrum_need_special_servers/dgjtg54/?context=3 05:29 < sipa> and people shouldn't rely on having a txindex available 05:29 < luke-jr> I don't think it's avoidable for Electrum 05:29 < sipa> i think electrum server should have a specialized node for that, not rely on bitcoind 05:30 < sipa> but ok 05:30 < sipa> still doesn't mean everyone needs that 05:30 < jonasschnelli> You suggesting making it default in order to be able to run an electrum server? 05:30 < luke-jr> jonasschnelli: relatively low cost, and high benefit to users who want to use Electrum 05:30 < luke-jr> sipa: not everyone needs BLOOM, but we have it enabled by default 05:30 < jonasschnelli> Well,... a reindex with txindex takes a day or so? 05:31 < luke-jr> true 05:31 < jonasschnelli> bloom is network, txindex is loca 05:31 < jonasschnelli> +l 05:31 < luke-jr> jonasschnelli: txindex is used for Electrum network protocol 05:31 < sipa> luke-jr: the way i see it, i'd have removed txindex support entirely with ultraprune 05:31 < jonasschnelli> Yes. Just saying offering bloom is something you do for the public, txindex is local 05:31 < sipa> luke-jr: but that would have caused too much problems for people relying on the software, so made it optional instead 05:32 < sipa> i don't think bitcoind's goal should be indexing the blockchain... for some purposes it's useful to have that feature availab;e 05:32 < sipa> but it's not optimized for it at all 05:33 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev 05:33 < luke-jr> perhaps not, but users care less about that than how easy it is to get things going 05:33 < sipa> maybe we should create a separate tool that indexes the chain in a decent way 05:33 < sipa> without doing validation etc 05:35 < bitcoin-git> [bitcoin] sipa opened pull request #10249: Switch CCoinsMap from boost to std unordered_map (master...stdcoinmap) https://github.com/bitcoin/bitcoin/pull/10249 05:37 <@wumpus> no, txindex should not be default-enabled at any time. By far most people don't use it, while it forces an overhead on everyone. 05:37 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Ping timeout: 240 seconds] 05:38 <@wumpus> if it's an annoyance to have to enable it once, well yes maybe, but there's a cost to everything 05:39 <@wumpus> can be kind of annoying if people have some far-out usage of a program and then expect everyone to accomodate to them 05:39 < luke-jr> I suspect there are more Electrum users than Core-wallet users, sadly 05:40 <@wumpus> of course there are more electrum users, that doesn't invalidate anything I said, most people running bitcoin core do not run an electrum server 05:40 < luke-jr> everyone using Electrum should be running their own Electrum server 05:41 <@wumpus> in any case people shoudl be encouraged to use an index on the utxo set intead of on the whole block chain 05:41 < luke-jr> need an index on the whole blockchain to get tx history 05:42 <@wumpus> there should be no need to index the whole block chain ,ever, unless you're doing chain analysis stuff, in which case you're working with such big data thatdoing an extra reindex should be peanuts 05:44 < sipa> there is something crazy in this reasoning: bitcoin core is too annoying to use due to resource usage, thus people switch to electrum, but then complain they can't easily run their own server... which is even more expensive than just running a full node wallet in the first place 05:44 < sipa> also, doesn't electrum full history require addrindex even? 05:44 < sipa> not just txindex? 05:45 < luke-jr> sipa: many people use Electrum because it supports hardware wallets 05:45 < luke-jr> and yes, Electrum's server generates that itself from the txindex 05:45 < sipa> then why can't it create the txindex too? 05:45 < luke-jr> not sure. 05:46 < sipa> luke-jr: well electrum uses a model that makes it inherently more expensive to run a server 05:46 < luke-jr> sipa: depends whether storage/indexing costs more than doing the filtering on-the-fly for bloom nodes 05:46 < sipa> stupid "the blockchain is my wallet model" 05:46 <@wumpus> it could, but remember that it is python code, so doing it there would be slower than having core handle it 05:46 < luke-jr> indexes are far less expensive than filtering for each user 05:46 < sipa> luke-jr: my view is that end users shouldn't need the full blockchain 05:47 < sipa> much less so a fully indexed one 05:47 < sipa> i understand electrum has advantages, but there must be ways to get them without burdening full nodes further 05:47 < luke-jr> sipa: not sure that's avoidable 05:47 < sipa> finding your old transactions should be a rare occurence 05:48 <@wumpus> if everyone ran their own trusted full node to connect to, they could run some remote wallet UI instead of electrum on the light device side 05:48 < luke-jr> bloom allows you to get the data from other nodes, and use your own only for consensus, but those other nodes could omit info 05:48 < luke-jr> wumpus: yes, in theory 05:48 <@wumpus> luke-jr: everyoen running their own electrum server is theory just as well 05:48 <@wumpus> luke-jr: and a much more overhead one at that 05:48 < sipa> without the 'blockchain is my wallet' model, you could easily outsource the recovery of old transactions to a third party 05:49 <@wumpus> why would everyone need to index everyone's transactions? 05:49 <@wumpus> that's just crazy 05:51 < sipa> to be clear: my concern is indirect... txindex is indeed that not much of a resource problem, but the fact that something 'requires' you to have txindex, implies it requires you to have the full blockchain readily available 05:52 < sipa> an ecosystem that relies on everyone having the full blockchain available is disaster for scalability 05:52 <@wumpus> in any case txindex is already supported, people can use it if they want 05:52 <@wumpus> what I find deplorable is that people want to burden everyone with it just to avoid a one-time overhead for them 05:53 < sipa> maybe instead we should make pruning default :) 05:53 < instagibbs> ^ was about tot say that 05:54 <@wumpus> but I guess it fits well in the weird idea that many people have about the block chain, that it's some infinite externality that one can just keep dumping into, without relevant cost to anyone 05:54 < luke-jr> sipa: IMO wait until we can IBD from pruned nodes 05:54 < sdaftuar> sipa: lets merge that default to motivate block download improvements for 0.15 :) 05:54 < sipa> luke-jr: fair point 05:54 < luke-jr> I did make a pruning GUI for Knots, but it uses rwconf :x 05:57 <@wumpus> I think offering a choice in the initial GUI dialog would already be nice 05:57 < sipa> agree 05:58 <@wumpus> (the one that lets you choose the data directory and shows an estimate of disk usage) 05:58 <@wumpus> I wouldn't like pruning to be the default because it means throwing away downloaded data by default. Prefer to err on the safe side. 05:59 <@wumpus> it's trivially possible to go from non-pruned to pruned, the other way around can be expensive 06:00 <@wumpus> sure if e.g. the machine has little disk space it can be encouraged strongly to prune 06:00 <@wumpus> just think it should not be enabled silently 06:00 -!- tw2006 [~tw2006@2601:187:8480:2770:9c9e:1d5b:f230:5aba] has joined #bitcoin-core-dev 06:01 < bitcoin-git> [bitcoin] sipa opened pull request #10250: Fix some empty vector references (master...nonnullref) https://github.com/bitcoin/bitcoin/pull/10250 06:02 < luke-jr> wumpus: Knots firstrun: http://i.imgur.com/mKTQrVb.png http://i.imgur.com/jopLsLQ.png 06:02 < sipa> in the GUI, a wizard setup dialog the first time that asks you seems nice 06:02 <@wumpus> luke-jr: exactly 06:02 < luke-jr> perhaps I should re-PR rwconf without the GUI stuff? 06:02 < sipa> what is rwconf? 06:02 < luke-jr> although I guess that doesn't help get it to Intro 06:02 < luke-jr> sipa: bitcoin_rw.conf file that the software modifies 06:03 < sipa> which is also used by bitcoind? 06:03 < luke-jr> Knots bitcoind, yes 06:03 <@wumpus> luke-jr: is that file at least in the per-network directory? 06:03 < luke-jr> wumpus: yes 06:03 < jonasschnelli> I once started a new GUI wizard with pruning: https://github.com/jonasschnelli/bitcoin/commit/7d8798d4942b7d7980a4c4f90cdd714432696ea7 06:03 <@wumpus> luke-jr: great 06:04 < luke-jr> IIRC the hold-back from Core was that you wanted the GUI to use an enum for each setting 06:04 < luke-jr> but maybe just a minimal approach that only uses it for pruning would be okay before that's done 06:05 < jonasschnelli> The idea of the branch above was to ask about pruning / dbcache / folder (what we have right now) 06:05 <@wumpus> from a sandboxing point of view I don't really like the idea of daemons writing their own configuration files 06:05 <@wumpus> but if it doesn't write bitcoin.conf, well, it's not too bad 06:06 < luke-jr> right, that's why it was an independent file 06:06 < sipa> maybe we should go back to serializing settings into wallet.dat 06:06 <@wumpus> right 06:06 * sipa ducks 06:06 <@wumpus> also having it in per-network directory cleverly avoids the problem of a testnet and mainnet instance trying to write the file at the same time 06:09 < luke-jr> ok, so plan: 1) split the rwconf low-level from the GUI Options changes, and PR the former only; 2) in a second PR (?), do just the pruning Intro stuff? 06:10 < luke-jr> * [new tag] v0.14.1.knots20170420 -> v0.14.1.knots20170420 <-- gitian builds please ☺ 06:11 <@wumpus> yes, I hope adding yet another settings source doesn't introduce a mess, it makes it harder to reason what takes precedence 06:12 <@wumpus> ok, will build 06:39 < luke-jr> thx 06:50 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 06:50 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Max SendQ exceeded] 06:59 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 07:02 -!- molz_ [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds] 07:09 < jonasschnelli> Using lambdas in Qt is a no go? Right? It would break Qt4 compile compat? 07:10 < sipa> you cant use c++11 lambdas? 07:11 < jonasschnelli> You can... but I think if you are using Qt "connect" mechanism and directly embed a lambda it will no longer be compilable with Qt4... 07:11 < jonasschnelli> not sure though 07:19 < sipa> a lambda is just a function object 07:19 < jonasschnelli> I'm always surprised what kind of hack from the CoinControl implementation I find: https://github.com/bitcoin/bitcoin/blame/master/src/qt/walletmodel.cpp#L64 07:20 < jonasschnelli> sipa: Yeah. But I think Qt4 can't handle something like connect( inProject, &myProject::signal, [=] () {}); because it's a marco or a MOC function (or whatever Qt uses to decompose) 07:21 < sipa> oh 07:22 < Chris_Stewart_5> sipa: Since we are talking about lambdas, if i use '[&]' on lambdas that will force the arg to be passed by reference, instead of being copied correct? 07:22 < Chris_Stewart_5> for things like this: https://github.com/Christewart/bitcoin/blob/6c929c05c51c266b6d991ff6e370425dee0f391a/src/test/gen/crypto_gen.h#L28 07:23 < jonasschnelli> Chris_Stewart_5: correct 07:24 < jonasschnelli> The L28 above makes a copy of the Key, right? 07:25 < Chris_Stewart_5> From my understanding of it, yes. However it seems like i could scope it with '&' 07:26 -!- fao1 [~fao@106.120.101.38] has quit [Ping timeout: 240 seconds] 07:26 -!- fao1 [~fao@106.120.101.38] has joined #bitcoin-core-dev 07:26 -!- molz_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 07:27 < Chris_Stewart_5> The way I have it written now is just the simplest way I could achieve what I was trying to do -- create a generator for a CPrivKey 07:28 < sipa> Chris_Stewart_5: that lambda does not capture anything... 07:28 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 260 seconds] 07:29 < sipa> [&] will have no effect 07:29 -!- mol [~molly@unaffiliated/molly] has quit [Ping timeout: 258 seconds] 07:29 < sipa> if you want the parameter key to be by reference, you just make it Key& key 07:31 < sipa> [=] and [&] control the capture list, not the parameter list 07:31 < Chris_Stewart_5> by 'capture' you just mean a variable that is a scope larger than that lambda, correct? For instance some global variable? 07:32 < Chris_Stewart_5> by default it copies that global variable if you just provide '[]'? 07:32 < sipa> if you provide [], it does not capture anything 07:32 < sipa> if you provide [=] it captures everything, by value 07:33 -!- gm2053 [~gm2051@2a02:c7d:12e:100:e407:340d:9c40:469d] has joined #bitcoin-core-dev 07:33 < sipa> if you provide [&] it captures everything, by reference 07:34 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has quit [Ping timeout: 252 seconds] 07:34 < Chris_Stewart_5> Thanks for the explanation. That clears up a lot wrt to lambdas for me. 07:35 -!- gm2051 [~gm2051@2a02:c7d:12e:100:84d0:5615:5e47:1a2f] has joined #bitcoin-core-dev 07:36 < sipa> Chris_Stewart_5: http://en.cppreference.com/w/cpp/language/lambda 07:36 -!- gm2052 [~gm2051@2a02:c7d:12e:100:b571:c37e:1f05:a513] has quit [Ping timeout: 252 seconds] 07:38 -!- gm2053 [~gm2051@2a02:c7d:12e:100:e407:340d:9c40:469d] has quit [Ping timeout: 240 seconds] 07:42 < ryanofsky> i kind of like the coding convention where you use unnamed [&] capture for any lambda called synchronously, and named capture [&var1, var2] or [] for any lambda called asynchronously 07:42 < ryanofsky> asynchronously meaning the closure is copied and called after the lambda expression goes out of scope 07:43 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 07:43 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #10251: Add balances cache / GUI: use a signal instead of a poll thread (master...2017/04/gui_rm_locks) https://github.com/bitcoin/bitcoin/pull/10251 07:44 < sipa> ryanofsky: that's a nice convention 07:44 < sipa> ryanofsky: is there a way to construct a non-copyable lambda? 07:45 < ryanofsky> in c++14 there definitely is because you can capture by move 07:45 < ryanofsky> so the resulting closure is move-only 07:46 < ryanofsky> otherwise i don't think you can do it directly without std::bind or something 07:46 < sipa> which incurs a performance penalty? 07:47 < ryanofsky> yeah, probably minor unless lambda is capturing a lot of variables or a very big struct by copy 07:48 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 07:49 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has joined #bitcoin-core-dev 07:57 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 08:00 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 260 seconds] 08:09 -!- fao1 [~fao@106.120.101.38] has quit [Ping timeout: 252 seconds] 08:13 -!- fao1 [~fao@106.120.101.38] has joined #bitcoin-core-dev 08:14 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/27faa6cccd8d...f3db4c601385 08:14 < bitcoin-git> bitcoin/master 821dd5e Jimmy Song: Tests: Add test for getdifficulty... 08:14 < bitcoin-git> bitcoin/master f3db4c6 Wladimir J. van der Laan: Merge #10229: Tests: Add test for getdifficulty... 08:14 < bitcoin-git> [bitcoin] laanwj closed pull request #10229: Tests: Add test for getdifficulty (master...test_getdifficulty) https://github.com/bitcoin/bitcoin/pull/10229 08:17 -!- fao1 [~fao@106.120.101.38] has quit [Ping timeout: 240 seconds] 08:21 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 08:30 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f3db4c601385...5352e5e75da9 08:30 < bitcoin-git> bitcoin/master c39a6b9 Jimmy Song: Tests: Refactor to create witness script creation function... 08:30 < bitcoin-git> bitcoin/master 5352e5e Wladimir J. van der Laan: Merge #10223: Tests: Refactor to create witness script creation function... 08:30 < bitcoin-git> [bitcoin] laanwj closed pull request #10223: Tests: Refactor to create witness script creation function (master...refactor_blocktools_for_segwit) https://github.com/bitcoin/bitcoin/pull/10223 08:32 -!- stoner19 [~stoner19@unaffiliated/stoner19] has joined #bitcoin-core-dev 08:32 < stoner19> can anyone link me to the actual code for segwit in bitcoin core? 08:33 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has quit [Remote host closed the connection] 08:33 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 08:33 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has joined #bitcoin-core-dev 08:34 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/5352e5e75da9...1428f3030d99 08:34 < bitcoin-git> bitcoin/master f478d98 Pieter Wuille: Fix some empty vector references... 08:34 < bitcoin-git> bitcoin/master 1428f30 Wladimir J. van der Laan: Merge #10250: Fix some empty vector references... 08:34 < sipa> stoner19: what part? consensus logic? p2p protocol changes? signing code for transactions? 08:34 < bitcoin-git> [bitcoin] laanwj closed pull request #10250: Fix some empty vector references (master...nonnullref) https://github.com/bitcoin/bitcoin/pull/10250 08:34 < stoner19> sipa, guess I'm just curious about it all. What needed to be changed in order to implement/signal segwit? 08:35 < sipa> stoner19: signalling is 1 line of code, just changing the block nversion 08:36 < sipa> stoner19: https://github.com/bitcoin/bitcoin/pull/8149/commits 08:36 < stoner19> oh that helps significantly thank you 08:38 -!- RubenSomsen [~RubenSoms@5ED2CA1D.cm-7-3d.dynamic.ziggo.nl] has quit [Ping timeout: 240 seconds] 08:49 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 08:51 < morcos> gmaxwell: sipa: wumpus: i update https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41 to contain proposed fee estimation changes for 0.15 08:51 < morcos> It's a bit more thorough description than is included in #10199 08:51 < gribble> https://github.com/bitcoin/bitcoin/issues/10199 | Better fee estimates by morcos · Pull Request #10199 · bitcoin/bitcoin · GitHub 08:52 < morcos> It may have actually started to go into too much detail, but I'm happy to discuss further online if there are more questions 09:26 -!- molz_ [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer] 09:42 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1428f3030d99...a6548a47a554 09:42 < bitcoin-git> bitcoin/master 25660e9 Mario Dian: pass Consensus::Params& to ReceivedBlockTransactions() 09:42 < bitcoin-git> bitcoin/master a6548a4 Wladimir J. van der Laan: Merge #10201: pass Consensus::Params& to ReceivedBlockTransactions()... 09:44 < achow101> has 0.14.1 been officially released yet? or still waiting on gitian sigs? 09:45 < bitcoin-git> [bitcoin] luke-jr opened pull request #10252: RPC/Mining: Restore API compatibility for prioritisetransaction (master...rpc_prioritise_api) https://github.com/bitcoin/bitcoin/pull/10252 09:46 < luke-jr> achow101: thanks for the reminder to build signed bins :D 09:51 < gmaxwell> morcos: 60% threshold at target/2 09:51 < gmaxwell> 85% threshold at target 09:52 < gmaxwell> so do we have any reason to expect that the 60% at target/2 won't dominate the estimate? 09:55 -!- Guest12838 [~justin@47.148.176.74] has quit [Remote host closed the connection] 09:59 -!- Guest12838 [~justin@47.148.176.74] has joined #bitcoin-core-dev 10:00 < bitcoin-git> [bitcoin] jimmysong opened pull request #10253: Tests: Add test for getnetworkhashps (master...test_getnetworkhashps) https://github.com/bitcoin/bitcoin/pull/10253 10:05 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 260 seconds] 10:19 -!- fao1 [~fao@106.120.101.38] has joined #bitcoin-core-dev 10:20 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds] 10:31 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 10:33 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 10:37 -!- gielbier [~michiel@unaffiliated/gielbier] has quit [Ping timeout: 258 seconds] 10:49 -!- jtimon_ [~quassel@9.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 10:49 -!- gielbier [~michiel@2001:981:9573:1:1914:346b:4882:4614] has joined #bitcoin-core-dev 10:50 < jtimon_> wumpus: it seems you added a commit to https://github.com/bitcoin/bitcoin/pull/10201 by mistake? 10:54 < bitcoin-git> [bitcoin] jtimon closed pull request #10227: Make functions in validation.cpp static: (master...b14-chainparams-validation-static) https://github.com/bitcoin/bitcoin/pull/10227 10:57 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 11:02 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 268 seconds] 11:05 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 260 seconds] 11:24 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Ping timeout: 252 seconds] 11:28 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 11:28 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 12:06 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 12:06 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 12:27 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 12:41 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 255 seconds] 12:44 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 255 seconds] 12:44 -!- moli_ [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 13:00 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #10254: [Qt] Remove shutdown poll timer and replace it with a signal (master...2017/04/qt_shutdown) https://github.com/bitcoin/bitcoin/pull/10254 13:05 < bitcoin-git> [bitcoin] jimmysong opened pull request #10255: [test] Add test for listaddressgroupings (master...test_listaddressgroupings) https://github.com/bitcoin/bitcoin/pull/10255 13:11 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 13:16 -!- owowo [~ovovo@185.183.104.83] has joined #bitcoin-core-dev 13:16 -!- owowo [~ovovo@185.183.104.83] has quit [Changing host] 13:16 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 13:46 < morcos> gmaxwell: i think in practice, the 3 calculations are often quite close. 13:47 < morcos> but i wouldn't be concerned if it turned out the target/2 one dominated 13:53 -!- stoner19 [~stoner19@unaffiliated/stoner19] has left #bitcoin-core-dev ["Keep on keepin' on..."] 13:53 < morcos> you can look at each data point (tx and how long it took to get confirmed) as an independent event in which case you would expect the 60% n/2 and 85% n estimates to be roughly the same 13:55 < morcos> but also you know they aren't really independent and at the extreme end of that , all you care about is the current tx congestion and what fee rate is being cleared down to 13:56 < morcos> the way i looked at it is i could kind of have the best of couple differnet worlds by combining (taking the max) of different estimates 13:57 < morcos> the n/2 estimate allows you to react more quickly b/c lets you look at the more recent history for more of the estimates so you'll react more quickly to changing conditions 13:59 < morcos> but its important to also have an estimate with a 95% threshold so that you do know that your tx is going to be confirmed within a reasonable time frame.. you don't know if some of the data points were accelerated via special arrangement or CPFP'ed or had other special characteristics 13:59 < morcos> also, if you have a long history of 100% of things being concerned, it can take quite some time for estimates to drop 13:59 < morcos> man this is hard to walk through on IRC, it kind of sounds so handwavy 14:00 -!- tw2006 [~tw2006@2601:187:8480:2770:9c9e:1d5b:f230:5aba] has quit [Remote host closed the connection] 14:02 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 14:03 < sipa> haha 14:03 -!- NewLiberty [~NewLibert@206.15.84.254] has joined #bitcoin-core-dev 14:10 -!- pepe__ [~pepe@84.126.69.179.dyn.user.ono.com] has joined #bitcoin-core-dev 14:11 -!- pepe__ [~pepe@84.126.69.179.dyn.user.ono.com] has quit [Client Quit] 14:12 -!- elkalamar [~elkalamar@84.126.69.179.dyn.user.ono.com] has joined #bitcoin-core-dev 14:13 -!- tw2006 [~tw2006@2601:187:8480:2770:b568:2126:cd19:530b] has joined #bitcoin-core-dev 14:15 -!- tw2006 [~tw2006@2601:187:8480:2770:b568:2126:cd19:530b] has quit [Read error: Connection reset by peer] 14:15 -!- tw2006 [~tw2006@2601:187:8480:2770:b568:2126:cd19:530b] has joined #bitcoin-core-dev 14:53 -!- NewLiberty [~NewLibert@206.15.84.254] has quit [Ping timeout: 260 seconds] 14:56 -!- NewLiberty [~NewLibert@206.15.84.254] has joined #bitcoin-core-dev 15:10 -!- str4d [~str4d@27.110.123.91] has joined #bitcoin-core-dev 15:10 -!- NewLiberty [~NewLibert@206.15.84.254] has quit [Ping timeout: 240 seconds] 15:17 -!- NewLiberty [~NewLibert@206.15.84.254] has joined #bitcoin-core-dev 15:20 -!- tw2006 [~tw2006@2601:187:8480:2770:b568:2126:cd19:530b] has quit [Remote host closed the connection] 15:40 < gmaxwell> sipa: is there a reason that the CBlock doesn't cache its hash and redblockfromdisk couldn't use something like CHashverifier to populate it on construction? 15:50 -!- gm2052 [~gm2051@2.124.85.23] has joined #bitcoin-core-dev 15:52 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 15:54 -!- gm2051 [~gm2051@2a02:c7d:12e:100:84d0:5615:5e47:1a2f] has quit [Ping timeout: 255 seconds] 16:01 < BlueMatt> gmaxwell: not so useful given hash is only 80 bytes... 16:01 < BlueMatt> but, it should cache in some way, indeed 16:17 < gmaxwell> yea, I guess the hashverifier doesn't really matter for performance due to the size. I keep thinking it hashes the whole block I dunno why readblock from disk is so slow since it doesn't. 16:21 < luke-jr> does it hash every transaction? 16:22 < BlueMatt> gmaxwell: we have a benchmark for that because its so damned slow 16:25 < instagibbs> why is it so damned slow 16:26 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 16:27 < BlueMatt> instagibbs: you're allocating a metric shitload of objects on the heap 16:30 < gmaxwell> oh because of that. right. why do I keep forgetting the allocations. 16:35 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 16:37 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 16:38 < gmaxwell> Luke's revised text for the 0.14.2 changes is confusing. :( 16:38 < gmaxwell> er 0.14.1 16:39 -!- NewLiberty_ [~NewLibert@206.15.84.254] has joined #bitcoin-core-dev 16:39 < gmaxwell> I wish text weren't so hard. 16:40 < gmaxwell> Apparently it has people thinking that 0.14.1 change to relay blocks to non-segwit nodes. :( I can see how it's easy to read that way, but didn't notice it before. 16:40 < luke-jr> huh? O.o 16:41 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 16:42 -!- NewLiberty [~NewLibert@206.15.84.254] has quit [Ping timeout: 240 seconds] 16:59 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 17:09 -!- tw2006 [~tw2006@2601:187:8480:2770:c84f:d04:968c:6c49] has joined #bitcoin-core-dev 17:13 -!- tw2006 [~tw2006@2601:187:8480:2770:c84f:d04:968c:6c49] has quit [Ping timeout: 258 seconds] 17:15 -!- NewLiberty_ [~NewLibert@206.15.84.254] has quit [Ping timeout: 258 seconds] 17:27 -!- NewLiberty_ [~NewLibert@206.15.84.254] has joined #bitcoin-core-dev 17:40 < sipa> gmaxwell: i'm sure that no matter how it is formulated, some people will misread it 17:42 -!- NewLiberty_ [~NewLibert@206.15.84.254] has quit [Ping timeout: 240 seconds] 17:55 -!- To7 [~theo@cpe-158-222-192-214.nyc.res.rr.com] has quit [Ping timeout: 258 seconds] 17:57 -!- NewLiberty_ [~NewLibert@206.15.84.254] has joined #bitcoin-core-dev 18:00 -!- tw2006 [~tw2006@2601:187:8480:2770:75a2:147f:ef83:e417] has joined #bitcoin-core-dev 18:00 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds] 18:01 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Remote host closed the connection] 18:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 18:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 18:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 18:09 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 18:11 < bitcoin-git> [bitcoin] jimmysong opened pull request #10256: [test] Add gettxout call to wallet.py (master...test_gettxout) https://github.com/bitcoin/bitcoin/pull/10256 18:11 -!- NewLiberty_ [~NewLibert@206.15.84.254] has quit [Ping timeout: 260 seconds] 18:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 18:14 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 18:17 -!- vicenteH [~user@135.234.15.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds] 18:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 18:26 < achow101> I made dummy github user non-github-bitcoin (https://github.com/non-github-bitcoin) to account for the commits made by the people who committed but don't have github accounts. right now it has sirius-m (github removed it from saracen to allow me to add that account) and lasloh. I'll be asking github to also let me add s_nakamoto which is currently under invalid-email-address. I think it would be prudent to give the repo maintainers 18:26 < achow101> control of the account, so how should I go about doing that? 18:32 < gmaxwell> achow101: sounds great. 18:33 < gmaxwell> achow101: maybe the best way would be to get wumpus to forward you his prior communication with github on it? 18:38 < achow101> gmaxwell: I think github will let me assign satoshi's email to that account as they allowed me to do that for sirius's. 18:39 < achow101> the question now is how I should securely hand over the account to wumpus and other maintainers. 18:39 < gmaxwell> achow101: ask wumpus if he's willing to take it (he will be) then send him the password in gpg email. 18:40 < achow101> yeah, I figured that's how it would work. just waiting for a response to my pm 18:41 < gmaxwell> Sat Apr 22 01:41:19 UTC 2017 18:41 < gmaxwell> expect one in 6 hours or so. 18:50 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wretphkizwdpbdhl] has quit [Quit: Connection closed for inactivity] 18:54 -!- NewLiberty_ [~NewLibert@206.15.84.254] has joined #bitcoin-core-dev 19:08 < bitcoin-git> [bitcoin] jimmysong opened pull request #10257: [test] Add test for getmemoryinfo (master...test_getmemoryinfo) https://github.com/bitcoin/bitcoin/pull/10257 19:10 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 19:12 -!- nu11p7r [~nu11p7r@dfaefce4-1ec2-41ac-b8f9-6bd816c36ded.node.sporestack.com] has quit [Ping timeout: 268 seconds] 19:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 19:48 -!- dermoth [~thomas@dsl-216-221-55-119.mtl.contact.net] has quit [Ping timeout: 268 seconds] 19:50 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 20:03 -!- gm2052 [~gm2051@2.124.85.23] has quit [Ping timeout: 240 seconds] 20:17 -!- NewLiberty_ [~NewLibert@206.15.84.254] has quit [Ping timeout: 260 seconds] 20:22 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 20:23 < midnightmagic> sigh. Or maybe Github could just fix the bug instead of making us work around their crappy design. 20:27 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 20:34 -!- tw2006 [~tw2006@2601:187:8480:2770:75a2:147f:ef83:e417] has quit [Remote host closed the connection] 20:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 21:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 21:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds] 21:16 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 21:30 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds] 21:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 21:35 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 21:35 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Max SendQ exceeded] 21:35 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 21:36 -!- tw2006 [~tw2006@2601:187:8480:2770:34de:e3bf:8dd6:2c0] has joined #bitcoin-core-dev 21:40 -!- tw2006 [~tw2006@2601:187:8480:2770:34de:e3bf:8dd6:2c0] has quit [Ping timeout: 255 seconds] 21:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds] 21:48 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye] 22:24 <@wumpus> midnightmagic: yes - what happened to 'confirm your email' kind of setup 22:24 <@wumpus> achow101: sure, thanks for doing that 22:24 < gmaxwell> well you can't confirm those emails, they contain no dot. 22:25 <@wumpus> gmaxwell: that's my point, if you used an invalid mail you probably shouldn't be able to claim credit for it 22:25 <@wumpus> e.g. being able to add arbitrary mail addresses to your account so they show up as you is a broken system 22:27 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev 22:29 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Read error: Connection reset by peer] 22:29 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev 22:30 < gmaxwell> I'm sure the issue is that anything imported from SVN is like that... so you've got lots of repos where people complain they can't get credit... 22:31 <@wumpus> the burden on proof should be on them 22:31 < gmaxwell> thats why we can't trust them to retain the fix... any time it's fixed more people complain they can't take credit for their own commits. 22:31 < gmaxwell> and then the 'fix' that, because github isn't about security or integrity in any form, it's a freeking web repository. :P 22:32 < gmaxwell> (I agree with you it's dumb, but we're expecting too much from github... or another way of looking at it: we're getting pretty much exactly what we pay for. :) ) 22:32 <@wumpus> there's other ways, they could also have added a form for the person doing the SVN import to fill in a name to user/real_email mapping 22:33 <@wumpus> or at least the owner of the repo 22:33 < gmaxwell> yea, or at least require the parties be repo members, so you could just kick out anyone who misused it. 22:33 < gmaxwell> but that would be like.. good. worse is better, or something. 22:33 <@wumpus> I have a paid github account 22:34 < gmaxwell> wumpus: still, it's not like it's expensive. :) 22:34 < gmaxwell> we probably use more in bandwidth alone than the cost of a couple paid accounts. 22:34 <@wumpus> that's true. I doubt I pay fairly for the share of bandwidth and CPU load I cause to them :) 22:42 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 22:51 -!- Guest12838 is now known as juscamarena 22:55 -!- annanay25 [~csbtech@geekon.tech] has quit [Remote host closed the connection] 22:56 -!- annanay25 [~csbtech@geekon.tech] has joined #bitcoin-core-dev 23:02 -!- jtimon [~quassel@9.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] 23:02 -!- jtimon_ [~quassel@9.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] 23:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 23:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds] 23:12 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has quit [Read error: Connection reset by peer] 23:12 -!- goksinen [~goksinen@2604:2000:c591:8400:fd17:6fc3:e19b:a0bb] has joined #bitcoin-core-dev 23:21 -!- goksinen [~goksinen@2604:2000:c591:8400:fd17:6fc3:e19b:a0bb] has quit [Ping timeout: 258 seconds] 23:24 -!- tw2006 [~tw2006@2601:187:8480:2770:8812:3a2c:6ed0:c893] has joined #bitcoin-core-dev 23:29 -!- goksinen [~goksinen@cpe-74-71-4-175.nyc.res.rr.com] has joined #bitcoin-core-dev 23:29 -!- QBcrusher [~QBcrusher@cpe-173-88-70-206.columbus.res.rr.com] has quit [Read error: Connection reset by peer] 23:29 -!- tw2006 [~tw2006@2601:187:8480:2770:8812:3a2c:6ed0:c893] has quit [Ping timeout: 260 seconds]