--- Day changed Tue Oct 04 2016 00:00 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev 00:10 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer] 00:11 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev 00:19 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:22 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] 00:22 -!- DigiByteDev [~JT2@185.29.164.146] has joined #bitcoin-core-dev 00:23 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 00:24 -!- juscamarena [~jus@47.148.186.144] has quit [Ping timeout: 272 seconds] 00:27 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 248 seconds] 00:31 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer] 00:32 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev 00:43 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer] 00:43 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev 01:04 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer] 01:04 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev 01:10 -!- laurentmt [~Thunderbi@80.215.138.74] has joined #bitcoin-core-dev 01:15 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer] 01:15 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev 01:21 -!- MarcoFalke [~marco@5.199.182.203] has joined #bitcoin-core-dev 01:21 -!- laurentmt [~Thunderbi@80.215.138.74] has quit [Quit: laurentmt] 01:26 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer] 01:26 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev 01:26 -!- laurentmt [~Thunderbi@80.215.138.74] has joined #bitcoin-core-dev 01:29 -!- chris2000 [~chris2000@p5DCB52C9.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 01:34 < wumpus> aureianimus: if you don't fix your IRC client I'll have to ban you to reduce join/part noise in this channel 01:37 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer] 01:37 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has joined #bitcoin-core-dev 01:37 -!- mode/#bitcoin-core-dev [+o wumpus] by ChanServ 01:39 -!- mode/#bitcoin-core-dev [+b #bitcoin-core-de!*@*] by wumpus 01:39 -!- mode/#bitcoin-core-dev [-b #bitcoin-core-de!*@*] by wumpus 01:40 -!- mode/#bitcoin-core-dev [+b *!*@s55963df3.adsl.online.nl] by wumpus 01:41 -!- mode/#bitcoin-core-dev [-o wumpus] by ChanServ 01:42 < wumpus> PM me if fixed 01:50 -!- aureianimus [~quassel@s55963df3.adsl.online.nl] has quit [Read error: Connection reset by peer] 01:52 -!- laurentmt [~Thunderbi@80.215.138.74] has quit [Quit: laurentmt] 02:08 < GitHub132> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/a7e5cbb209d4...7dce175f5d89 02:08 < GitHub132> bitcoin/master 47314e6 Wladimir J. van der Laan: prevector: add C++11-like data() method... 02:08 < GitHub132> bitcoin/master f00705a Wladimir J. van der Laan: serialize: Deprecate `begin_ptr` / `end_ptr`... 02:08 < GitHub132> bitcoin/master 7dce175 Wladimir J. van der Laan: Merge #8850: Implement (begin|end)_ptr in C++11 and add deprecation comment... 02:08 < GitHub115> [bitcoin] laanwj closed pull request #8850: Implement (begin|end)_ptr in C++11 and add deprecation comment (master...2016_09_beginptr_deprecation) https://github.com/bitcoin/bitcoin/pull/8850 02:21 < MarcoFalke> luke-jr: "Rewinding blocks" is always displayed when you run a recent version. 02:21 < MarcoFalke> (It does not actually do any rewinding) 02:22 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev 02:29 < wumpus> let's correct the message 02:31 < sipa> yeah, just produce no message wgen there is nothing to rewind 02:31 < wumpus> it must be doing something if it is visible at all, though 02:32 < wumpus> well okay not true in the log, but is in the GUI, you won't notice the first message if it updates two times in a row 02:32 < sipa> probably the next thing it does after it takes a non-negilgable amount of time 02:33 < wumpus> so *that* needs its own message 02:33 < wumpus> better fix 02:33 < sipa> right 02:33 < randy-waterhouse> unwinding ... get a drink 02:33 < wumpus> :-) 02:41 -!- rubensayshi [~ruben@82.201.92.138] has quit [Remote host closed the connection] 02:57 -!- kyletorpey [~kyle@pool-71-176-227-116.rcmdva.fios.verizon.net] has quit [Ping timeout: 265 seconds] 03:12 -!- murch [~murch@p4FE389DF.dip0.t-ipconnect.de] has joined #bitcoin-core-dev 03:12 -!- cdecker [~quassel@2a02:aa16:1105:4a80:4b0:a9a7:975:76eb] has joined #bitcoin-core-dev 03:14 -!- DigiByteDev [~JT2@185.29.164.146] has quit [Quit: DigiByteDev] 03:14 < GitHub70> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/7dce175f5d89...d93f0c61843f 03:14 < GitHub70> bitcoin/master 905bc68 Cory Fields: net: fix a few cases where messages were sent rather than dropped upon disconnection... 03:14 < GitHub70> bitcoin/master d93f0c6 Wladimir J. van der Laan: Merge #8862: Fix a few cases where messages were sent after requested disconnect... 03:14 < GitHub157> [bitcoin] laanwj closed pull request #8862: Fix a few cases where messages were sent after requested disconnect (master...fix-disconnect-send) https://github.com/bitcoin/bitcoin/pull/8862 03:18 < GitHub79> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d93f0c61843f...d7615af34e8e 03:18 < GitHub79> bitcoin/master 2fa0063 Johnson Lau: Add NULLDUMMY verify flag in bitcoinconsensus.h 03:18 < GitHub79> bitcoin/master d7615af Wladimir J. van der Laan: Merge #8848: Add NULLDUMMY verify flag in bitcoinconsensus.h... 03:18 < GitHub150> [bitcoin] laanwj closed pull request #8848: Add NULLDUMMY verify flag in bitcoinconsensus.h (master...consensusnulldummy) https://github.com/bitcoin/bitcoin/pull/8848 03:22 -!- jtimon [~quassel@150.110.132.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 03:28 -!- murch [~murch@p4FE389DF.dip0.t-ipconnect.de] has quit [Remote host closed the connection] 03:29 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-core-dev 03:33 -!- wasi_ [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-core-dev 03:33 -!- wasi_ [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Client Quit] 03:41 < GitHub49> [bitcoin] MarcoFalke opened pull request #8879: [doc] Rework docs (master...Mf1610-docCleanup) https://github.com/bitcoin/bitcoin/pull/8879 03:46 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds] 03:58 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 04:03 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.] 04:18 < GitHub185> [bitcoin] laanwj opened pull request #8880: protocol.h: Move MESSAGE_START_SIZE into CMessageHeader (master...2016_10_cosmetic) https://github.com/bitcoin/bitcoin/pull/8880 04:21 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 265 seconds] 04:40 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 04:41 -!- cryptapus_ is now known as cryptapus 04:47 -!- DigiByteDev [~JT2@185.29.164.97] has joined #bitcoin-core-dev 04:53 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev 04:53 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host] 04:53 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 05:03 -!- DigiByteDev [~JT2@185.29.164.97] has quit [Quit: DigiByteDev] 05:05 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving] 05:19 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:22 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Quit: Leaving] 05:23 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-core-dev 05:40 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [Ping timeout: 272 seconds] 05:41 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev 05:41 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 05:42 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:43 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has quit [Quit: Leaving] 05:44 -!- wasi [~wasi@25.22.3.213.static.wline.lns.sme.cust.swisscom.ch] has joined #bitcoin-core-dev 05:55 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: Konversation terminated!] 05:55 -!- cryptapus [~cryptapus@87.254.202.138] has joined #bitcoin-core-dev 05:55 -!- cryptapus [~cryptapus@87.254.202.138] has quit [Changing host] 05:55 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 06:19 < BlueMatt> cfields_: whats your opinion on switching g_connman to a std::shared_ptr and then using that in the map of logica validators? 06:21 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 248 seconds] 06:32 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev 06:34 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has left #bitcoin-core-dev [] 06:37 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:41 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has quit [Quit: DigiByteDev] 06:48 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 06:48 -!- laurentmt [~Thunderbi@80.215.138.74] has joined #bitcoin-core-dev 06:52 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 252 seconds] 06:53 -!- laurentmt [~Thunderbi@80.215.138.74] has quit [Client Quit] 06:59 -!- cryptapus [~cryptapus@66.119.84.15] has joined #bitcoin-core-dev 06:59 -!- cryptapus [~cryptapus@66.119.84.15] has quit [Changing host] 06:59 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 07:08 -!- Guest95984 is now known as bsm117532 07:27 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev 07:30 < BlueMatt> cfields_: nvm, i pushed a change to switch to a shared_ptr there, makes everything safe without adding a GetId() to CConnman, which I like 07:36 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 272 seconds] 07:41 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 07:59 < cfields_> BlueMatt: please please no :) 07:59 < BlueMatt> ehh, its better than another global GetId() thing 08:00 < cfields_> BlueMatt: it breaks down ownership models, and will almost certainly lead to teardown issues/races eventually 08:01 < BlueMatt> i mean i dunno how to resolve that without having an ownership model for who owns the CConnman and who owns the logic 08:01 < BlueMatt> unless you want the CConnman to own the logic 08:02 < cfields_> BlueMatt: right, we need to think about that carefully. But punting to a shared_ptr effectively just masks the problem, imo 08:03 < GitHub59> [bitcoin] laanwj closed pull request #8843: rpc: Handle `getinfo` client-side in bitcoin-cli w/ `-getinfo` (master...2016_09_getinfo_clientside) https://github.com/bitcoin/bitcoin/pull/8843 08:04 < BlueMatt> i mean if a failure to teardown in the right order does anything more than cause memory to keep growing as you push events that arent handled, then you have other issues 08:05 < cfields_> wumpus: thoughts on the above? IIRC we've discussed briefly before. The question is: what model do we use to glue networking and message handling together? 08:06 < cfields_> BlueMatt: i don't see the problem with the approach before the shared_ptr? As long as a signal is broadcast to the processors that the connman is no longer valid, that seems fine to me? 08:06 < BlueMatt> before the shared ptr? you could delete and dereference null, no? 08:06 < BlueMatt> i mean if you failed to teardown, that is 08:07 < wumpus> well if it is CConnMan that manages the lifecycle of connections there's not need for shared_ptr 08:07 < cfields_> BlueMatt: right, with the caveat that the handler would have to appropriately act on the signal in time 08:07 < wumpus> you may need 'weak-pointer' like callbacks in that case, to prevent anyone still holding keeping handle when a connection goes away 08:08 < BlueMatt> wumpus: not about connections, about the CConnman itself 08:08 < wumpus> Init() and Shutdown() 'own' CConnman 08:08 < cfields_> BlueMatt: then CConnman will have advertised that all connections have been torn down before it itself is deleted 08:09 < wumpus> we have a well defined lifecycle there 08:09 < wumpus> after Shutdown there should be no networking anymore, and no connman 08:09 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has quit [Quit: ZNC 1.6.3+deb1 - http://znc.in] 08:10 < wumpus> and everything that uses connman should be deinitialized before ConnMan gets deinitialized 08:10 < wumpus> better to have deterministic lifecycles for objects then rely on shared pointers to happen to get things right 08:10 < wumpus> or even worse, relying on global constructors/destructors order 08:15 < cfields_> +1. Though I think also it's important to design such that net users essentially have no chance of trying to send messages by the time CConnman has shut down, so that the fact that it's "owned" by Init really doesn't matter. 08:15 < cfields_> eg. queued messages should be deleted when the nodes are advertised as disconnected, and processors should be shutdown when their connman advertises that it's stopping 08:16 < wumpus> that depends on what preconditions you try to enforce, if net users remain by the time CConMan shuts down you'd say that's a bug 08:16 < wumpus> oh right, it may be a multi-phase process 08:18 < luke-jr> wumpus: I wasn't objecting to -getinfo <.< 08:19 < cfields_> right, the processor will get an interrupt which should break its loops, then a blocking stop, after which it should assume that its connman is null'd 08:20 < wumpus> luke-jr: I know, but I just don't think it's worth pushing too much for, it's something I'd use myself but I don't think anyone else cares and maybe I should just get used to using the respective commands, or simply make a python script 08:22 -!- shesek [~shesek@bzq-84-110-234-6.cablep.bezeqint.net] has quit [Ping timeout: 252 seconds] 08:23 < wumpus> heck or just a bash alias. bitcoin-cli getwalletinfo && bitcoin-cli getnetworkinfo | head -20 or such. I'd been overthinking it a bit because I thought it was neat to do RPC batch from bitcoin-cli 08:25 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 08:27 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-core-dev 08:27 -!- shesek [~shesek@bzq-84-110-234-6.red.bezeqint.net] has joined #bitcoin-core-dev 08:27 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 248 seconds] 08:29 -!- Lightsword [~Lightswor@2604:a880:1:20::1d3:9001] has joined #bitcoin-core-dev 08:31 < cfields_> wumpus: you mentioned in #8856 that you'd like to see an api for options eventually. I have a few generic base classes that I've been working on in order to break some global dependencies out of utils. for threading, logging, options, etc. Wasn't sure if you'd want those or not. I could PR an RFC if you think it's worth discussing 08:32 < cfields_> (it was done as an exercise for CConnman, seeing what it would take to drop all global state deps by passing in a base logger, base options parser, etc) 08:35 < wumpus> cfields_: yes I think that would be a good thing, options handling has always been somewhat of a mess. And when boost has to be dropped as a dependency we need a replacement for boost::options. 08:36 < cfields_> wumpus: right 08:36 < cfields_> wumpus: seems the only thing we actually use it for is parsing the config file? 08:36 < wumpus> cfields_: there's a lot unclear though, e.g. do we want to be able to change (some) options on the fly (which would require callbacks), how to handle types, how to handle defaults, etc 08:36 < wumpus> yes, just replacing it would be trivial, doesn't need a whole options overhaul :) 08:37 < cfields_> wumpus: as a stopgap, I just kept it all pretty much as-is 08:38 < wumpus> e.g. how we handle defaults is kind of ugly. In stead of declaring the option and its type and default e.g. at the top of the module where it gets used, we have to declare a constant DEFAULT_BLABLA then pass it in in every place where the option gets used 08:38 < cfields_> wumpus: stores a const map of strings, a const multimap, then a non-const map for the soft-sets. The getters treat that as an overlay, and fallback to const 08:38 < wumpus> also there's a lot of overhead as arguments get parsed to their type time after time, in some places 08:38 < wumpus> and it's possible to call GetBOol on an argument in one place and GetString on it in another place 08:38 < cfields_> wumpus: heh, yes. There's certainly the argument that the options shouldn't even be visibile outside of init 08:39 < wumpus> and my favorite pet issue https://github.com/bitcoin/bitcoin/issues/1044 08:40 < cfields_> mmm, yuck 08:40 < wumpus> cfields_: that would be one way, though it means all the argument propagation logic is centralized. Right now we are moving towards having the wallet handle its own arguments, for example, which makes sense to break the circular dependency and get rid of ENABLE_WALLET defines. 08:40 < wumpus> it's in no way a trivial thing to get right 08:41 < wumpus> many constraints, and low priority, and the current state well... kind of works 08:41 < wumpus> cfields_: yes, validation would be good :) 08:42 < cfields_> wumpus: low priority, hint taken :) 08:43 < wumpus> well the net refactor is much more important 08:43 < wumpus> as well as build system/gitian security 08:44 < wumpus> speaking of which how's your mac code-signer project doing? 08:45 < sipa> wumpus: i once started on an options system (inspired a bit by google's, where you just declare a global IntOption nMaxConnections("-maxconnections", minval, maxval, description); or so, and then can query nMaxConnections as if it were an integer 08:46 < cfields_> wumpus: got distracted when some net stuff got merged. It's fully working and stable though, the only work left is to figure out the detach/attach scheme 08:46 < sipa> i also think luke started on an options thing where they could be changed over time 08:47 < wumpus> sipa: sounds good to me 08:48 < wumpus> and yes luke-jr has some pulls open that accomplish some of these things 08:49 < wumpus> haven't looked very much yet at those, sorry 08:55 -!- cdecker [~quassel@2a02:aa16:1105:4a80:4b0:a9a7:975:76eb] has quit [Quit: No Ping reply in 180 seconds.] 08:58 -!- cdecker [~quassel@2a02:aa16:1105:4a80:b16e:e2a4:ecd2:4483] has joined #bitcoin-core-dev 08:59 < GitHub163> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/5f3e4a8a2ae2dd0e0fa316c6caa50e97280be773 08:59 < GitHub163> bitcoin/master 5f3e4a8 Wladimir J. van der Laan: protocol.h: Make enums in GetDataMsg concrete values... 08:59 < wumpus> gah oh fuck 09:01 < GitHub108> [bitcoin] laanwj force-pushed master from 5f3e4a8 to d7615af: https://github.com/bitcoin/bitcoin/commits/master 09:01 -!- instagibbs [~instagibb@pool-100-15-114-3.washdc.fios.verizon.net] has joined #bitcoin-core-dev 09:01 < wumpus> emergency force-push back to d7615af34e8e19920ed12bfdafb09e0e4b57c7c5 09:02 * cfields_ goes to verify, i just pulled 5min ago 09:04 < wumpus> thanks 09:05 < cfields_> hmm, wonder if there's a quick way to ask git for a repo contents hash (ignoring that the commit hash kinda represents that) 09:07 < sipa> the tree hash? 09:07 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer] 09:07 < wumpus> that's the 'tree hash' I suppose? 09:08 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev 09:08 < wumpus> it's unfortunate that github's bot only logs the short commit hash, otherwise you could just browse back and compare ids 09:09 < cfields_> cory@cory-i7:~/dev/bitcoin2(connman-send)$ git ls-tree origin/master | sha256sum 09:09 < cfields_> 5f470267d0fc7161ac6193c223f7e76fe135ba33fac35ec39d1adde9324f021f - 09:10 < cfields_> cory@Macbook:~/dev/bitcoin(fix-gui-ban)$ git ls-tree origin/master | sha256sum 09:10 < cfields_> 5f470267d0fc7161ac6193c223f7e76fe135ba33fac35ec39d1adde9324f021f - 09:10 < cfields_> 1 pre force-push, 1 post. No surprise, they match :) 09:11 < wumpus> good 09:16 < BlueMatt> cfields_: sorry, had to step out...do you prefer, then, that we stick with the map? 09:16 < BlueMatt> I mean I'm open to that, you just objected that it was fragile, and shared_ptr is an explicit fix for fragility of using a ptr there 09:16 < cfields_> BlueMatt: for the sake of not holding it up, sure. 09:18 < BlueMatt> I mean, ok, I'll revert the shared_ptr change, then, but what would be the long-term target there? a logic class which owns the CConnman? 09:18 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds] 09:20 < GitHub196> [bitcoin] laanwj closed pull request #8746: [Qt][RPC] Hide passphrases in debug console history (master...hide-walletpassphrase) https://github.com/bitcoin/bitcoin/pull/8746 09:21 < cfields_> BlueMatt: it doesn't own it, it just holds a reference to one. It should receive signals that the connman is being torn down, and assume that it's invalid from that point forward 09:23 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] 09:29 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 09:33 < BlueMatt> cfields_: hmm, ok...I find that harder to reason about (and it generates more code), but, ehh, whatever 09:33 < BlueMatt> cfields_: in any case, thats not something that is less than a lot of work to make happen 09:36 < cfields_> BlueMatt: well, lots of things are going to want to own the CConnman. They can't all have it :) 09:36 -!- mkarrer_ [~mkarrer@159.red-83-47-122.dynamicip.rima-tde.net] has quit [] 09:36 < sipa> well either it's owned by one thing and one thing only, or it's refcounted 09:37 < BlueMatt> cfields_: oh? what else wants to own CConnman? I think not much else cares about anything at a lower level than what peers are doing 09:37 < BlueMatt> cfields_: aside from the need to provide the setup argument sin init 09:38 < cfields_> BlueMatt: rpc/wallet/gui could all make the argument 09:40 < sipa> i'd say init creates&owns CConnman, and passes it as argument to rpc/wallet/gui 09:40 < sipa> who hold a reference to CConnman, but don't own it 09:40 < sipa> and it's init's responsibility to not shut down CConnman before all its users are destroyed 09:41 < BlueMatt> cfields_: why does rpc/wallet/or gui care about anything more than the list of nodes connected to, outside of the context of configuration options 09:41 < sipa> (please tell me to shut up if there are large issues i'm not aware of, i haven't actively followed the code) 09:41 < cfields_> sipa: agree, that's what I'm suggesting as well 09:41 < BlueMatt> sipa: ok, well thats what it is now 09:41 < BlueMatt> cfields_: was taking objection to that 09:41 -!- shesek [~shesek@bzq-84-110-234-6.red.bezeqint.net] has quit [Ping timeout: 265 seconds] 09:41 < sipa> BlueMatt: how so? 09:42 < cfields_> BlueMatt: eh? I'm aligned with that. I'm taking objection to a processor taking ownership 09:42 < BlueMatt> "a processor"? 09:42 < BlueMatt> you mean the PeerValidationLogic 09:42 < BlueMatt> it doesnt take ownership, it keeps a pointer to the object 09:42 < cfields_> message handler, validator, etc 09:43 < BlueMatt> and " it's init's responsibility to not shut down CConnman before all its users are destroyed" :p 09:43 < cfields_> BlueMatt: yes, and I'm fine with that :) 09:43 < BlueMatt> wait, now I'm confuseg 09:43 < BlueMatt> ugh, ok, I'll leave it how it is 09:43 < cfields_> just not a shared_ptr 09:43 < sipa> well ideally, the PeerValidationLogic is a class, and there is a seaprate instance of it for each CConnman 09:43 < sipa> so it can hold a pointer, and does not need a map 09:43 < BlueMatt> cfields_: yea, I'll remove that 09:43 < BlueMatt> sipa: it does, the map is only as a place to put the storage, mostly 09:44 < sipa> BlueMatt: i'll shut up before looking at the 09:44 < sipa> code 09:44 < BlueMatt> its just there so you can do Register(CConnman*) and Deregister(CConnman*) and it knows which PeerValidationLogic object is associated with that connman so it can destroy the right one 09:45 < sipa> hmm, shouldn't init create the PeerValidationLogic object, and just pass it the CConnman pointer? 09:45 < sipa> there should never be a need to look something up 09:46 < BlueMatt> How else do you know which PeerValidationLogic to destroy when someone hands you a CConnman* to Deregister()? 09:46 < BlueMatt> i mean aside from iterating 09:46 < BlueMatt> anyway, whatever, could also iterate, doesnt matter much 09:46 < sipa> init would create the PeerValidationLogic 09:46 < sipa> and destroy it 09:46 -!- shesek [~shesek@bzq-84-110-234-6.red.bezeqint.net] has joined #bitcoin-core-dev 09:47 < BlueMatt> ahh, yea, i mean thats maybe a more forward-looking thing...once the code is well-separated and designed, maybe, but for now it lets main store it 09:47 < sipa> ok 09:47 < cfields_> BlueMatt: ^^ seems simpler than stashing it in main? 09:47 < sipa> all good; "it requires too much refactoring" is a good reason 09:47 -!- laurentmt [~Thunderbi@80.215.138.74] has joined #bitcoin-core-dev 09:48 < BlueMatt> cfields_: I didnt really want to expose the PeerValidationLogic in main.h yet 09:48 < sipa> gah stupid github and its author date based ordering of commits 09:48 < BlueMatt> i had originally started doing what sipa said, and then decided i wanted less exposing of shit 09:48 < sipa> it took me 10 minutes to figure out why #8871's commits didn't show up in #8393 09:49 < sipa> turns out they are there... at the end 09:49 < cfields_> BlueMatt: mm, ok. Giving you a pass since the intention is to break stuff out anyway 09:49 < cfields_> :) 09:50 < BlueMatt> cfields_: heh, ok, will need like 2 more prs for that :p 09:51 < cfields_> BlueMatt: wait, isn't it a child of CValidationInterface ? 09:51 < BlueMatt> is what? 09:53 < cfields_> yea, PeerLogicValidation 09:53 < cfields_> why not just keep a base pointer in init? 09:53 < BlueMatt> oh, you mean ptr to CValidationInterface 09:54 < BlueMatt> hmm, dont we need like a virtual destructor or something crazy like that? 09:54 < cfields_> er, setup a base ptr to a dummy interface in init, then actually create it later in the process 09:54 < BlueMatt> wait, what? 09:56 < cfields_> oh, it's already non-virtual anyway. no need for the dummy 09:56 < cfields_> BlueMatt: nm, it can wait 'til later 09:56 * BlueMatt is so confused 09:58 < cfields_> BlueMatt: i can write it up real quick 09:59 < BlueMatt> ugh, y'all and your C++ magic 09:59 -!- laurentmt [~Thunderbi@80.215.138.74] has quit [Quit: laurentmt] 10:03 < sipa> BlueMatt: for my grammar-based password generator, i wrote an stl-like list where the iterators are refcounted, and elements automatically get destructed when no iterators remain... epic fun with rvalue references everywhere :) 10:03 < BlueMatt> fuck you people 10:04 < sipa> though i don't think cfields_ is talking about anything as extreme as that :) 10:04 < cfields_> sipa: haha 10:05 < cfields_> no, I just mean using a base class as a base class :) 10:07 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 10:08 < BlueMatt> heh, one of these days sipa is gonna learn my name (https://github.com/bitcoin/bitcoin/pull/8393/commits/e15a0584911f142d5819cc7fb967028c76682792)... 10:08 < BlueMatt> right after he finishes learning english, mabye :p 10:09 < cfields_> BlueMatt: still hacking it up, just a few min 10:09 -!- juscamarena [~jus@47.148.186.144] has joined #bitcoin-core-dev 10:10 < sipa> BlueMatt: crap 10:11 < sipa> BlueMatt: fixed 10:17 < luke-jr> BlueMatt: "We went looking everywhere, but couldn’t find those commits." 10:18 < luke-jr> oh, prob cuz sipa deleted it 10:18 * luke-jr peers at MarcoFalke deleting branches quickly after merge 10:20 -!- juscamarena [~jus@47.148.186.144] has quit [Ping timeout: 272 seconds] 10:20 < MarcoFalke> luke-jr: You need to modify the url to get the commit: e.g. https://github.com/bitcoin/bitcoin/commit/e15a0584911f142d5819cc7fb967028c76682792 10:21 < MarcoFalke> for the above one 10:21 < cfields_> BlueMatt: untested POC: https://github.com/theuni/bitcoin/commit/31438dd973a95934ab847fb5ba7d6fa604ee506c 10:22 < BlueMatt> testing? who does that??? 10:22 < BlueMatt> cfields_: omgno 10:22 < cfields_> BlueMatt: the unique_ptr is awkward because it has to be passed to main for creation. Once the header can be exposed, nearly all of that ugliness goes away 10:22 < BlueMatt> the second I see std::move my eyes glaze over 10:22 < cfields_> eh? 10:23 < BlueMatt> you're like passing around something without knowledge of the type and using std::move and things 10:23 < BlueMatt> i really dont like that 10:23 < cfields_> huh? Yes, I'm using virtuals and rvalues... 10:23 < cfields_> Everything there is type-safe and defined 10:24 < cfields_> but as mentioned above, that's only there to work around the fact that the header isn't exposed. The moves go away once you can create the inteface directly in init 10:26 < BlueMatt> i mean you had to add a virtual destructor...... 10:26 < BlueMatt> was mostly what i was referring to 10:26 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev 10:26 < BlueMatt> can we just push this off until its in net_processing.h and we can expose the class there? 10:27 < BlueMatt> like, ehh, you're bending over backwards to make this work without exposing the PeerLogicValidation, whereas I'd kinda prefer to expose it in main.h 10:27 < BlueMatt> though, mostly, Id rather put it off into peer_validator.h 10:27 < BlueMatt> ehh, net_processing.h is what i was calling it 10:27 < cfields_> BlueMatt: I'm just coding it up with the constraints I've been given. Obviously it's much nicer to just split out the header and use it directly 10:27 < luke-jr> BlueMatt virtually self-destructs. 10:28 * luke-jr hides 10:28 < cfields_> so if that's the plan, sure, no need to do it now 10:28 < BlueMatt> yea, sorry, i mean my "dont want to expose this" is a weak preference just because main.h is Too Damn Big (tm) 10:28 < BlueMatt> after the split i see no reason why it shouldnt be exposed (net_processing.h right now is like 4 functions and some forward-declarations) 10:29 < cfields_> BlueMatt: ok, how about this then... 10:29 < cfields_> stuff it in main.h for now, hold it cleanly in init, then split it out of main.h as the next step? 10:30 < cfields_> that way the plan is clear all along. Or is there a reason that doesn't work? 10:30 < BlueMatt> sure, can do that, too, then I'll just move all the to-be-moved stuff together - RegisterNodeSignals, UnregisterNodeSignals, ProcessMessages, SendMessages, GetNodeStateStats, and Misbehaving 10:31 < cfields_> BlueMatt: that sounds much better :) 10:32 < BlueMatt> since main.h moves are easy 10:33 < BlueMatt> ok, I'ma overwrite the shit out of history on that pr, then 10:33 < luke-jr> lol 10:34 * cfields_ salivates at the thought of PeerLogicValidation::mapNodeState 10:35 < BlueMatt> heh, yup 10:36 < sipa> at some point i thought about a generic NetmessageProcessor class you could inherit from (with your own state type filled in), which you could register to net 10:36 < cfields_> maybe this can be the final home for CChainParams as well. 10:37 < sipa> and you'd have separate instances for dealing with tx relay, block relay, ping, addr management, ... 10:37 < cfields_> sipa: state types being? 10:37 < cfields_> ah 10:37 < sipa> cfields_: well for the ping handler, the state would be a struct that remembers the last sent ping 10:37 < sipa> for addr management it would be the addrKnown and tosend vectors 10:37 < sipa> etc 10:38 < sipa> and you'd have the ability to do parallel processing across different nodes as long as it was about different handlers 10:38 < cfields_> hmm, interesting 10:38 < cfields_> how to order dependent messages? 10:38 < sipa> you don't 10:38 < cfields_> (for ex the ping ordering that ruins everything) 10:39 < sipa> you only ever process the oldest unprocessed message for each peer 10:39 < BlueMatt> we need to discuss ping ordering at some point 10:39 < BlueMatt> sdaftuar: pointed out that its pretty much violated everywhere wrt block processing 10:39 < cfields_> oh, gotcha. I missed the "different nodes" part. My brain turned that into "across different messages" 10:39 < BlueMatt> essentially, i think we need to grep bitcoinj and other spv clients, find all the places where they actually use ping sync, define those, than then say that that is the protocol 10:40 < sipa> BlueMatt: heh, i thought we'd just stick to synchronous processing all messages 10:40 -!- paveljanik [~paveljani@79.98.72.176] has joined #bitcoin-core-dev 10:40 -!- paveljanik [~paveljani@79.98.72.176] has quit [Changing host] 10:40 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 10:40 < sipa> that's such a huge change to deviate from 10:40 < sipa> i'd rather redo the p2p protocol from scratch if you're going to change that 10:41 < BlueMatt> sipa: we already violate it a) with block processing sometimes (sdaftuar thinks this is the cause for some of the compact block test failures, last I heard) and definitely on reject messages 10:41 < BlueMatt> sipa: so we kinda already deviate from it :/ 10:41 < sipa> we don't 10:41 < sipa> when receiving a block, we *process* the block fully 10:41 < sipa> and send all messages in response to that 10:41 < BlueMatt> sipa: there are several things we send in SendMessages instead of ProcessMessages 10:41 < BlueMatt> which will violate it 10:41 < sipa> that doesn't mean we fully validate 10:42 < sdaftuar> sipa: block announcements are delivered asynchronously (as are block reject messages) 10:42 < sipa> sdaftuar: sure 10:42 -!- shesek [~shesek@bzq-84-110-234-6.red.bezeqint.net] has quit [Ping timeout: 265 seconds] 10:43 < BlueMatt> cfields_: hope you like your main.h with some #include "validationinterface.h" :p 10:44 < cfields_> oh wow, i didn't realize we'd slimmed the main.h includes down so much 10:44 < BlueMatt> yea, they're pretty minimal now 10:44 < BlueMatt> I dont really mind adding validationinterface, though...we'll kill it soon :) 10:44 < cfields_> BlueMatt: i think that's fine as long as it's temporary 10:45 < BlueMatt> yup 10:55 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 10:55 < BlueMatt> ok, cfields_ see current branch 10:57 < BlueMatt> gotta love https://github.com/bitcoin/bitcoin/pull/8865/files#diff-e8db9b851adc2422aadfffca88f14c91R523 10:58 < cfields_> BlueMatt: much better 11:00 -!- microbe [~microbe@109.143.133.35] has joined #bitcoin-core-dev 11:00 < luke-jr> lol 11:02 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 11:02 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 11:05 < cfields_> BlueMatt: any reason not to simply register/unregister in PeerLogicValidation's ctor/dtor? 11:05 < BlueMatt> layer violation? 11:05 < BlueMatt> feel yucky to me 11:06 < BlueMatt> yea, it feels yucky because "hidden magic" 11:07 < BlueMatt> the zmq one doesnt do that 11:07 < cfields_> hmm, as long as the registration is global, it all seems like the same hidden magic to me. 11:07 < cfields_> but np, was just a thought 11:07 < BlueMatt> true, but the registration will eventually not be global :p 11:08 < BlueMatt> i guess I'm kinda thinking about chunks of code as if they were classes even though they are currently not 11:08 < BlueMatt> since they should be eventually, or even if not they'll be well-isolated so even if not a class, a single common interface feels similar 11:09 < cfields_> ok, then future request: when you're registering to a signagls instance, and you pass that instance into PeerLogicValidation, make it RAII please :) 11:10 < BlueMatt> maybe we should just use weak_ptrs for signal instances :p 11:10 < cfields_> and I think i see what you mean, and sounds good 11:11 < cfields_> I really wish there was some unique_ptr with a weak_ptr, it would be really useful sometimes. Though some of the semantics kinda make no sense 11:12 < BlueMatt> yea, would be cool to not have to use shared_ptrs, i guess...would just be somewhat oxymoronic to use it with a unique_ptr 11:12 -!- shesek [~shesek@bzq-84-110-234-6.red.bezeqint.net] has joined #bitcoin-core-dev 11:13 < cfields_> Well the interesting use-case would be: I'm using a unique_ptr, grab it and hold it if it's non-null. 11:13 < cfields_> so basically a shared_ptr with a max refcount of 2 11:13 < BlueMatt> yea 11:19 -!- mkarrer [~mkarrer@159.red-83-47-122.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 11:25 < GitHub126> [bitcoin] jnewbery opened pull request #8881: Add some verbose logging to bitcoin-util-test.py (master...verbose-bitcoin-util-output) https://github.com/bitcoin/bitcoin/pull/8881 11:26 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 11:45 -!- kyletorpey [~kyle@pool-71-176-227-116.rcmdva.fios.verizon.net] has joined #bitcoin-core-dev 11:45 < ill> abovetghelaw 11:58 -!- ill [~ill@32.210.24.120] has quit [Ping timeout: 252 seconds] 12:10 -!- microbe [~microbe@109.143.133.35] has quit [Quit: leaving] 12:26 -!- ill [~ill@32.210.24.120] has joined #bitcoin-core-dev 12:39 -!- waxwing [~waxwing@62.205.214.125] has quit [Quit: Leaving] 12:40 -!- kyletorpey [~kyle@pool-71-176-227-116.rcmdva.fios.verizon.net] has quit [Quit: Leaving.] 12:45 -!- juscamarena [~jus@2607:f380:a61:650:9dc7:32fa:ca57:2923] has joined #bitcoin-core-dev 12:52 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 265 seconds] 12:56 < GitHub126> [bitcoin] sdaftuar opened pull request #8882: [qa] Another attempt to fix race condition in p2p-compactblocks.py (master...fix-race-again) https://github.com/bitcoin/bitcoin/pull/8882 13:11 -!- chris2000 [~chris2000@p5DCB52C9.dip0.t-ipconnect.de] has left #bitcoin-core-dev [] 13:11 -!- shesek [~shesek@bzq-84-110-234-6.red.bezeqint.net] has quit [Ping timeout: 252 seconds] 13:14 -!- cdecker_ [~quassel@2a02:aa16:1105:4a80:b16e:e2a4:ecd2:4483] has joined #bitcoin-core-dev 13:14 -!- cdecker [~quassel@2a02:aa16:1105:4a80:b16e:e2a4:ecd2:4483] has quit [Quit: No Ping reply in 180 seconds.] 13:21 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [Remote host closed the connection] 13:25 -!- shesek [~shesek@bzq-84-110-179-95.red.bezeqint.net] has joined #bitcoin-core-dev 13:28 -!- MarcoFalke [~marco@5.199.182.203] has left #bitcoin-core-dev [] 13:33 -!- Cory [~C@unaffiliated/cory] has quit [Ping timeout: 244 seconds] 13:35 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has joined #bitcoin-core-dev 13:36 -!- Cory [~C@unaffiliated/cory] has joined #bitcoin-core-dev 13:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 13:58 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 14:00 -!- juscamarena [~jus@2607:f380:a61:650:9dc7:32fa:ca57:2923] has quit [Ping timeout: 248 seconds] 14:29 < GitHub177> [bitcoin] jnewbery opened pull request #8883: Add all standard TXO types to bitcoin-tx (master...add-p2sh-segwit-options-to-bitcoin-tx) https://github.com/bitcoin/bitcoin/pull/8883 14:31 < luke-jr> sipa: would it help if I rebase and address comments on https://github.com/bitcoin/bitcoin/pull/8448 ? 14:57 < sipa> luke-jr: i'll do it after 0.13.1 14:58 < luke-jr> ok 14:58 < sipa> you can of course, but i wanted to change a few things 15:00 < luke-jr> sipa: if you'd rather I take it off your load, just let me know what things you'd like changed ;) 15:02 < sipa> luke-jr: thanks 15:14 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 15:21 < GitHub119> [bitcoin] luke-jr opened pull request #8884: Bugfix: Trivial: RPC: getblockchaininfo help: pruneheight is the lowest, not highest, block (master...trivial_pruneheight_help) https://github.com/bitcoin/bitcoin/pull/8884 15:35 -!- jnewbery [~jnewbery@rrcs-67-251-193-154.nyc.biz.rr.com] has quit [] 15:45 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 15:58 -!- owowo [ovovo@gateway/vpn/mullvad/x-pohdfhremqcjppyq] has quit [Ping timeout: 264 seconds] 16:04 -!- owowo [ovovo@gateway/vpn/mullvad/x-pmfaaoioqwhfbhpr] has joined #bitcoin-core-dev 16:26 -!- cdecker_ [~quassel@2a02:aa16:1105:4a80:b16e:e2a4:ecd2:4483] has quit [Ping timeout: 252 seconds] 16:42 < GitHub135> [bitcoin] theuni opened pull request #8885: gui: fix ban from qt console (master...fix-gui-ban) https://github.com/bitcoin/bitcoin/pull/8885 16:57 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving] 17:35 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds] 17:47 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-iooaxrmelxrhmubl] has quit [Quit: Connection closed for inactivity] 17:53 -!- owowo [ovovo@gateway/vpn/mullvad/x-pmfaaoioqwhfbhpr] has quit [Read error: Connection reset by peer] 17:54 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 244 seconds] 17:57 -!- owowo [ovovo@gateway/vpn/mullvad/x-ktjvqcxgnsddtsbm] has joined #bitcoin-core-dev 18:01 -!- Expanse [sid146237@gateway/web/irccloud.com/x-giulybnndffvqfmk] has quit [Ping timeout: 265 seconds] 18:05 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 18:07 -!- juscamarena [~jus@2607:f380:a61:650:1d67:429c:3c05:e073] has joined #bitcoin-core-dev 18:13 -!- Expanse [sid146237@gateway/web/irccloud.com/x-vbsdfajcehaxlsqf] has joined #bitcoin-core-dev 18:20 -!- juscamarena [~jus@2607:f380:a61:650:1d67:429c:3c05:e073] has quit [Ping timeout: 248 seconds] 18:28 -!- owowo [ovovo@gateway/vpn/mullvad/x-ktjvqcxgnsddtsbm] has quit [Ping timeout: 264 seconds] 18:34 -!- owowo [ovovo@gateway/vpn/mullvad/x-nleltvvuqblvsuvh] has joined #bitcoin-core-dev 18:42 -!- linuxfan2718 [~dennis@pool-173-56-0-101.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 19:03 < wumpus> MSG_FILTERED_WITNESS_BLOCK defined in protocol.h is neither used in our source code nor defined in any BIP, should be in BIP144 I guess? 19:10 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Ping timeout: 248 seconds] 19:18 < wumpus> (looking up these numbers for documentation in protocol.h for #8880) 19:19 < luke-jr> if it's not used in code, why define it at all? 19:20 -!- jtimon [~quassel@150.110.132.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds] 19:20 < wumpus> I'd say to reserve the bit pattern, though this should happen in the BIP too 19:21 < luke-jr> ah, so we use the value, just via setting a bit instead of the enum key 19:21 < wumpus> that's my assumption. I haven't checked 19:36 < GitHub60> [bitcoin] EvertonMelo opened pull request #8886: Update build-unix.md (master...patch-1) https://github.com/bitcoin/bitcoin/pull/8886 19:49 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 19:49 < xinxi> sipa: are you there? 19:50 < xinxi> I am wondering why Bitcoin Core does not store the blockchain in a distributed way to save space? 19:50 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 19:52 < wumpus> there are some ideas for adding range negotiation to the protocol, so that nodes can store different ranges of blocks 19:52 < wumpus> see e.g. last meeting notes 19:52 < wumpus> the answer to 'why' is always: because no one has designed/implemented this yet 19:53 < xinxi> So theoretically, it is possible. 19:53 < wumpus> in any case if you are short in space you can use pruning 19:53 < xinxi> And blocksize won't be a problem seriously. 19:53 < wumpus> you're confounding issues 19:54 < xinxi> Sure blocksize increase will cause other issues like network latency. 19:54 < wumpus> increasing block size is a problem for utxo set growth, for the time it takes to initially sync, for bandwidth requirements of nodes and miners, for CPU validation overhead. Storing the block chain is the least of worries really 19:55 < wumpus> anyhow move this to #bitcoin, this is off topic here 19:55 < xinxi> OK 19:56 < xinxi> Thank you. 19:59 < xinxi> Another question directly about Bitcoin's current protocol. 20:00 < xinxi> Is it possible to increase OP_RETURN's data size with a softfork? 20:00 < wumpus> this topic is about development, discussion about changing the source code, use #bitcoin for general questions 20:00 < wumpus> see topic ^^ 20:03 -!- bsm117532 is now known as Guest26311 20:07 < GitHub168> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d7615af34e8e...f92805025d5b 20:07 < GitHub168> bitcoin/master eeeebdd MarcoFalke: [doc] Rework docs... 20:07 < GitHub168> bitcoin/master f928050 Wladimir J. van der Laan: Merge #8879: [doc] Rework docs... 20:08 < GitHub181> [bitcoin] laanwj closed pull request #8879: [doc] Rework docs (master...Mf1610-docCleanup) https://github.com/bitcoin/bitcoin/pull/8879 20:12 < wumpus> sigh... https://github.com/bitcoin/bitcoin/pull/8886#discussion_r81892323 20:15 < GitHub173> [bitcoin] fanquake opened pull request #8887: [Doc] Improve GitHub issue template (master...link-stackexchange) https://github.com/bitcoin/bitcoin/pull/8887 20:17 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-wceohqpesdjbewkt] has quit [Quit: Connection closed for inactivity] 20:17 -!- xinxi [~xinxi@116.86.38.246] has quit [Remote host closed the connection] 20:18 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 20:18 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds] 20:19 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.] 20:23 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 264 seconds] 20:26 < GitHub91> [bitcoin] theuni opened pull request #8888: CConnman: Remove global usage in wallet and some gui (master...no-global-connman) https://github.com/bitcoin/bitcoin/pull/8888 20:26 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 20:33 < achow101> the values for MSG_WITNESS_BLOCK and MSG_WITNESS_TX should probably be defined in BIP144... 20:34 < wumpus> good point achow101 20:51 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 21:00 < luke-jr> wumpus: wtf @ 8886 21:10 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 252 seconds] 21:17 -!- xinxi_ [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 21:20 -!- xinxi [~xinxi@116.86.38.246] has quit [Ping timeout: 265 seconds] 21:40 -!- linuxfan2718 [~dennis@pool-173-56-0-101.nycmny.fios.verizon.net] has quit [Ping timeout: 265 seconds] 21:47 < GitHub22> [bitcoin] luke-jr opened pull request #8889: Qt/ModalOverlay: Use theme tooltip colours (master...overlay_theme) https://github.com/bitcoin/bitcoin/pull/8889 21:55 < NicolasDorier> sipa: about PrecomputedTransactionData, I noticed you calculate it even if the Transaction has no witness https://github.com/bitcoin/bitcoin/blob/d93f0c61843f9da2a662f54ea1794ae0d263b196/src/main.cpp#L2458 I don't know if it has big impact on performance during IBT. Just dropping it here in case you overlooked it 21:55 < NicolasDorier> IBD 21:59 -!- DigiByteDev [~JT2@185.29.164.86] has joined #bitcoin-core-dev 22:07 < GitHub117> [bitcoin] fanquake opened pull request #8890: [Doc] Update Doxygen configuration file (master...update-doxyfile-1-8-12) https://github.com/bitcoin/bitcoin/pull/8890 22:17 -!- xinxi_ [~xinxi@116.86.38.246] has quit [Remote host closed the connection] 22:17 < sipa> wumpus: i guess MSG_FILTERED_WITNESS_BLOCK is what we'd need for a bip37 extension with segwit data 22:18 < sipa> NicolasDorier: yes, i'm aware 22:34 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 22:34 -!- xinxi [~xinxi@116.86.38.246] has joined #bitcoin-core-dev 22:35 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 22:42 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-lrcsbdemgpzyxfen] has quit [Ping timeout: 252 seconds] 22:45 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection] 22:46 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-otbzlqixlgiejnut] has joined #bitcoin-core-dev 22:46 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev 22:47 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 22:52 -!- molz [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 22:56 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 272 seconds] 22:58 -!- molz [~molly@unaffiliated/molly] has quit [Ping timeout: 272 seconds] 22:58 -!- juscamarena [~jus@47.148.186.144] has joined #bitcoin-core-dev 23:01 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 23:13 -!- DigiByteDev [~JT2@185.29.164.86] has quit [Quit: DigiByteDev] 23:20 -!- DigiByteDev [~JT2@n218250011174.netvigator.com] has joined #bitcoin-core-dev 23:35 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-txrugnyvhxxivncp] has joined #bitcoin-core-dev 23:37 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection] 23:40 -!- xinxi [~xinxi@116.86.38.246] has quit [Quit: Leaving...] 23:44 -!- juscamarena [~jus@47.148.186.144] has quit [Quit: Leaving] 23:58 < wumpus> sipa: makes sense