--- Log opened Thu Aug 23 00:00:48 2018
00:05 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev
00:06 < provoostenator> They're all different? https://github.com/bitcoin-core/gitian.sigs/pull/780/files#diff-32221b5f40db6596d8213cb93b29c705R9
00:07 < provoostenator> The SDK file isn't distributed, right?
00:08 < jonasschnelli> looks like... I though we have all shared the same tarball? But maybe not
00:13 < provoostenator> I used OSX to extract the relevant stuff from the thing I downloaded from Apple. On Linux you have to use different tools. Or maybe it's a timestamp thing?
00:15 < provoostenator> I've had the same hash since 0.16.0rc4 it seems, and I've used at least two distinct gitian machines.
00:22 -!- phwalkr [~phwalkr@2001:1284:f019:69b1:f15e:85d1:a133:857a] has quit [Ping timeout: 264 seconds]
00:35 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
00:36 -!- Krellan [~Krellan@2601:640:4000:9258:7902:1f7a:6ab3:9f71] has quit [Read error: Connection reset by peer]
00:36 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
00:36 -!- Krellan [~Krellan@2601:640:4000:9258:7902:1f7a:6ab3:9f71] has joined #bitcoin-core-dev
00:36 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
00:37 -!- csknk [~csknk@unaffiliated/csknk] has joined #bitcoin-core-dev
00:41 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Ping timeout: 272 seconds]
00:42 < luke-jr> jonasschnelli: the tarball isn't deterministically made..
00:42 < luke-jr> IMO it's a good thing that we have obviously-different SDKs ;)
00:42 < jonasschnelli> Yes. Indeed
00:50 -!- vexbuy [~vexbuy@89.39.107.196] has joined #bitcoin-core-dev
01:20 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-aycqdrvsqzqrvjcg] has joined #bitcoin-core-dev
01:32 -!- gnappuraz [5f5bf5a1@gateway/web/freenode/ip.95.91.245.161] has joined #bitcoin-core-dev
01:44 < gnappuraz> Hi there, I was wondering if there is any documentation relative to the different archives declared in the main Makefile. Cause I don't really understand the logic of how stuff is organized. i.e. what is the difference between libbitcoin_util and libbitcoin_common?
01:49 < jonasschnelli> gnappuraz: these are semi-independent modules. Those modules get linked for the different binaries we have (bitcoin-tx, bitcoin-cli, bitcoind, bitcoin-qt).
01:49 < jonasschnelli> But they do not have an ABI or are meant to be used with other applications
01:59 -!- gnappuraz [5f5bf5a1@gateway/web/freenode/ip.95.91.245.161] has quit [Ping timeout: 252 seconds]
01:59 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has quit [Ping timeout: 264 seconds]
02:06 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has joined #bitcoin-core-dev
02:08 -!- gnappuraz [5f5bf5a1@gateway/web/freenode/ip.95.91.245.161] has joined #bitcoin-core-dev
02:08 < ossifrage> g++ is really annoying sometimes, a 'make -j4' just managed to OOM this crappy box
02:11 < gnappuraz> thx for the answer. But let's assume that I have to add a new file that if meant to be use by both bitcoind and bitcoin-qt, the rationale behind putting it in COMMON vs UTIL should be: if used by bitcoin-cli then UTIL, otherwise COMMON (since bitcoin-cli links UTIL but not COMMON)?
02:23 -!- GAit [~GAit@unaffiliated/gait] has joined #bitcoin-core-dev
02:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
02:24 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
02:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
03:04 -!- e4xit [~e4xit@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #bitcoin-core-dev
03:06 < Empact> Is it possible to extend the ability to restart appveyor builds to core devs?
03:08 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
03:14 < ken2812221_> MarcoFalke: You can checkout https://ci.appveyor.com/gitHubTeams and https://ci.appveyor.com/project/Drahtbot/bitcoin/settings/permissions to help you setting up appveyor permissions.
03:16 -!- ken2812221_ is now known as ken2812221
03:31 < Empact> ken2812221: Thanks - set up the former but don't have access to the latter.
03:37 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Quit: Leaving.]
03:39 -!- vexbuy_ [~vexbuy@89.39.107.196] has joined #bitcoin-core-dev
03:43 -!- vexbuy [~vexbuy@89.39.107.196] has quit [Ping timeout: 264 seconds]
03:44 < ken2812221> Empact: I was talking to MarcoFalke, he's the owner of appveyor ci account.
03:47 -!- Empact [~empact@192-195-80-226.PUBLIC.monkeybrains.net] has quit [Ping timeout: 264 seconds]
04:10 -!- gnappuraz [5f5bf5a1@gateway/web/freenode/ip.95.91.245.161] has quit [Ping timeout: 252 seconds]
04:16 -!- vexbuy [~vexbuy@89.39.107.196] has joined #bitcoin-core-dev
04:20 -!- vexbuy_ [~vexbuy@89.39.107.196] has quit [Ping timeout: 260 seconds]
04:24 -!- vexbuy [~vexbuy@89.39.107.196] has quit [Remote host closed the connection]
04:33 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev
04:37 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]
04:39 -!- _flow_ [~none@2001:638:a000:4140::ff10:844c] has joined #bitcoin-core-dev
04:41 < _flow_> What can I do to get https://github.com/bitcoin/bitcoin/pull/13621 merged? It improves the, currently terriable, configuration mechanics of bitcoind a bit (while still not perfect) and re-enables a recently disabled test.
04:43 < wumpus> we're really careful merging changes to the order of configuration file parsing, slight changes to precedence will mess up things for current users and there are no good tests for this
04:43 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev
04:43 < jonasschnelli> _flow_: it needs more developers weighting in on the importance of that PR
04:43 < wumpus> _flow_: so I suppose my answer is "add good tests"!
04:44 < wumpus> those would also help to show what is improved, as they would fail on the old code and pass on the new one
04:45 < wumpus> also: does this affect the GUI
04:45 < wumpus> I see you did update the existing test, good
04:45 < wumpus> but I think it needs to extended, to include the failure cases that you describe
04:49 -!- Gnappuraz [5f5bf5a1@gateway/web/freenode/ip.95.91.245.161] has joined #bitcoin-core-dev
04:49 -!- vexbuy [~vexbuy@89.39.107.196] has joined #bitcoin-core-dev
04:54 -!- cyber55 [~cyber55@unaffiliated/cyber55] has quit [Remote host closed the connection]
04:55 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
05:01 < _flow_> wumpus: jonasschnelli: thanks. I'll consider adding a test for the issue the user in https://github.com/bitcoin/bitcoin/pull/12255#issuecomment-403666092 is experiencing
05:02 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
05:22 -!- rafalcpp_ [~racalcppp@84-10-11-234.static.chello.pl] has quit [Read error: Connection reset by peer]
05:34 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
05:38 -!- vexbuy [~vexbuy@89.39.107.196] has quit [Ping timeout: 268 seconds]
05:57 -!- pergaminho [~Cleber@201.47.91.172] has joined #bitcoin-core-dev
06:09 -!- belcher_ [~belcher@unaffiliated/belcher] has quit [Quit: Leaving]
06:23 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has quit [Ping timeout: 265 seconds]
06:23 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev
06:26 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
06:27 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
06:30 -!- vexbuy_ [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
06:46 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
06:54 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 272 seconds]
06:56 < jonasschnelli> how do I compile to detect pass-the-end iterator violations? I once had this setup but can no longer reproduce it.
06:56 < jonasschnelli> (ideally gcc/debian)
06:58 -!- Krellan [~Krellan@2601:640:4000:9258:7902:1f7a:6ab3:9f71] has quit [Read error: Connection reset by peer]
06:58 < jonasschnelli> Oh.. is it maybe DEBUG=1 for the depends build?
06:59 -!- Krellan [~Krellan@2601:640:4000:9258:7902:1f7a:6ab3:9f71] has joined #bitcoin-core-dev
07:08 -!- Rootsudo [~textual@180.190.116.105] has joined #bitcoin-core-dev
07:11 -!- csknk [~csknk@unaffiliated/csknk] has quit [Quit: leaving]
07:12 -!- wxss [~user@185.153.176.2] has joined #bitcoin-core-dev
07:38 -!- petertod1 is now known as petertodd
07:40 -!- d_t [~d_t@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
07:41 < achow101> gmaxwell: luke-jr: there's an additional "absurdly high fee" that is enforced as a relay policy. it's triggered by a tx with a fee higher than 0.01 BTC (or something like that)
07:42 < achow101> gmaxwell: also, insanely high fee is something that I can only find in 0.8 and earlier. I think that guy is making his own altcoin from 0.8.6 as people tend to do
07:47 < treyzania> why do people fork from that far back?
08:01 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has quit [Quit: Leaving.]
08:04 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has joined #bitcoin-core-dev
08:17 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
08:24 -!- pergaminho [~Cleber@201.47.91.172] has quit [Ping timeout: 256 seconds]
08:31 -!- pergaminho [~Cleber@201.47.91.172] has joined #bitcoin-core-dev
08:39 -!- wxss [~user@185.153.176.2] has quit [Quit: leaving]
08:41 < cfields> fanquake: I was waiting to make sure that my results matched jonasschnelli's before signing
08:41 < cfields> jonasschnelli: yes, it's DEBUG=1 for depends
08:42 < cfields> jonasschnelli: for sigs, note that this is the first detached sig in a new release series. So we'll switch to a 0.17 branch to match.
08:42 < jonasschnelli> cfields: ack. I'll PR after you pushed your commit (if you havent)
08:43 < cfields> jonasschnelli: pushed
08:47 < cfields> jonasschnelli: for future reference, I use "--orphan" when creating new git branches in the detached sigs repo, to avoid sharing any history between them.
08:48 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
08:48 -!- profmac [~ProfMac@2001:470:1f0f:226:4fa:dd19:ca84:f149] has quit [Read error: Connection reset by peer]
08:48 < jonasschnelli> cfields: noted
08:48 -!- profmac [~ProfMac@2001:470:1f0f:226:4fa:dd19:ca84:f149] has joined #bitcoin-core-dev
08:56 -!- Giszmo [~leo@pc-72-54-46-190.cm.vtr.net] has joined #bitcoin-core-dev
09:01 < gmaxwell> achow101: no there isn't. re: relay policy.
09:02 < gmaxwell> achow101: you're probably confused because the check is in ATMP, but it's always called with it disabled when handlign a transaction from the network.
09:09 -!- Gnappuraz [5f5bf5a1@gateway/web/freenode/ip.95.91.245.161] has quit [Ping timeout: 252 seconds]
09:15 -!- Rootsudo [~textual@180.190.116.105] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
09:16 -!- Rootsudo [~textual@180.190.116.105] has joined #bitcoin-core-dev
09:16 -!- Rootsudo [~textual@180.190.116.105] has quit [Client Quit]
09:17 -!- Rootsudo [~textual@180.190.116.105] has joined #bitcoin-core-dev
09:17 -!- Rootsudo [~textual@180.190.116.105] has quit [Client Quit]
09:18 -!- Rootsudo [~textual@180.190.116.105] has joined #bitcoin-core-dev
09:18 -!- Rootsudo [~textual@180.190.116.105] has quit [Client Quit]
09:19 -!- Rootsudo [~textual@180.190.116.105] has joined #bitcoin-core-dev
09:19 -!- Rootsudo [~textual@180.190.116.105] has quit [Client Quit]
09:40 -!- sipa [~pw@unaffiliated/sipa1024] has joined #bitcoin-core-dev
10:10 -!- leishman [~leishman@50.237.29.22] has joined #bitcoin-core-dev
10:36 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
10:37 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 256 seconds]
10:39 -!- profmac [~ProfMac@2001:470:1f0f:226:4fa:dd19:ca84:f149] has quit [Ping timeout: 252 seconds]
10:48 -!- rex4539 [~rex4539@2a02:587:3516:600:dc14:db78:2211:85e7] has joined #bitcoin-core-dev
10:50 -!- profmac [~ProfMac@2001:470:1f0f:226:4fa:dd19:ca84:f149] has joined #bitcoin-core-dev
10:50 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit []
11:00 -!- d_t [~d_t@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 240 seconds]
11:00 -!- Empact [~empact@192-195-80-226.PUBLIC.monkeybrains.net] has joined #bitcoin-core-dev
11:00 -!- Krellan [~Krellan@2601:640:4000:9258:7902:1f7a:6ab3:9f71] has quit [Remote host closed the connection]
11:01 -!- pergaminho [~Cleber@201.47.91.172] has quit [Quit: Saindo]
11:02 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 268 seconds]
11:06 -!- Rootsudo [~textual@180.190.116.105] has joined #bitcoin-core-dev
11:07 < wumpus> what's up with travis, btw? it looks like it's failing on all PRs
11:09 < sipa> feature_block fails?
11:09 < wumpus> there's something wrong with this new appveyor build
11:09 < sipa> oh, it's appveyor that fails, not travis
11:09 < wumpus> "Error making request with Error Code ServiceUnavailable and Http Status Code ServiceUnavailable. No further error information was returned by the service."
11:10 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
11:10 < wumpus> I've also seen feature_block fail though, but not consistently
11:11 < wumpus> on the very-last test (the reorg) 
11:26 -!- leishman [~leishman@50.237.29.22] has quit [Remote host closed the connection]
11:31 -!- nullptr| [~nullptr|@ip-94-113-103-134.net.upcbroadband.cz] has quit [Quit: ZNC - http://znc.in]
11:32 -!- nullptr| [~nullptr|@ip-94-113-103-134.net.upcbroadband.cz] has joined #bitcoin-core-dev
11:34 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev
11:39 -!- math_ [~mario@p4FCB3FA3.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
11:43 < MarcoFalke> ken2812221: Empact: I set the permissions to view and run builds for our github team
11:43 < MarcoFalke> Could someone verify that?
11:44 -!- promag [~promag@83.223.234.48] has joined #bitcoin-core-dev
11:46 < Empact> MarcoFalke: I'm still not seeing an option to restart the appveyor
11:47 < MarcoFalke> You need to be in the group that can assign labels to issues on our GitHub, I can't see who is in there
11:50 < Empact> Gotcha, yeah I'm not in the group
11:51 < wumpus> let's see if I can restart appveryot
11:53 < wumpus> I don't see it https://ci.appveyor.com/project/DrahtBot/bitcoin/build/master.127, but maybe I'm looking over it
11:53 < wumpus> (logged in through github)
11:56 < promag> wumpus: can I get #13100 in HP now that 13529 is merged?
11:56 < gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add dynamic wallets support by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
11:57 < wumpus> promag: the meeting is in four minutes, but sure...
11:57 < MarcoFalke> hmm maybe I forgot to press "save"?
11:57 < MarcoFalke> Mind to try again?
11:58 < promag> wumpus: thanks
12:00 < sipa> meeting?
12:00 < wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Aug 23 19:00:12 2018 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00 < sipa> hi
12:00 < gmaxwell> hi
12:00 < achow101> hi
12:00 < jonasschnelli> hi
12:01 < promag> hi
12:01 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark mi
12:01 < wumpus> chagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator
12:01 -!- meshcollider_ [uid246294@gateway/web/irccloud.com/x-nmtqdivaiywxuoiu] has joined #bitcoin-core-dev
12:01 < wumpus> who has a topic?
12:01 < meshcollider> Hi
12:02 < jonasschnelli> topic proposal: tor plugable transport
12:02 < wumpus> MarcoFalke: I still don't see it, though I'm not sure what kind of button I'm looking for
12:02 < wumpus> let's start with high prio as usual
12:02 < wumpus> #topic high priority for review
12:03 < jonasschnelli> I'd like to add #14032 if that is appropriate
12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/14032 | Add p2p layer encryption with ECDH/ChaCha20Poly1305 by jonasschnelli · Pull Request #14032 · bitcoin/bitcoin · GitHub
12:03 < wumpus> https://github.com/bitcoin/bitcoin/projects/8  two were merged, one was added, this leaves five open
12:04 < wumpus> jonasschnelli: sure
12:04 < cfields> jonasschnelli: thanks, I'm excited to read that.
12:05 < jonasschnelli> I'm also excited to hear your feedback. :)
12:05 < wumpus> yes, very good to see a PR about that
12:05 < promag> jonasschnelli: do you think you can extract some commits to new PR's?
12:05 < MarcoFalke> I'd like to add #13961 (it is only refactoring, but drops the memory usage at compile time by 100Mb, also compiles faster)
12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/13961 | util: Replace boost::signals2 with std::function by MarcoFalke · Pull Request #13961 · bitcoin/bitcoin · GitHubAsset 1Asset 1
12:05 < jonasschnelli> promag: I guess it's hard to make it smaller... 
12:05 < wumpus> MarcoFalke: ok
12:05 < cfields> MarcoFalke: also nice :)
12:05 < achow101> topic suggestion: hardware wallet support
12:06 < wumpus> #topic tor pluggable transport (jonasschnelli)
12:06 < jonasschnelli> Tor has this concept of pluggable transports
12:07 < promag> jonasschnelli: could create a PR only with the first 3 commits, but let's talk later
12:07 < jonasschnelli> https://www.torproject.org/docs/pluggable-transports.html.en
12:07 < jonasschnelli> https://gitweb.torproject.org/torspec.git/tree/pt-spec.txt
12:07 -!- spinza [~spin@155.93.246.187] has quit [Ping timeout: 272 seconds]
12:07 < Empact> jonasshnelli: First three commits look independent as prep work
12:07 < jonasschnelli> It a great concept to bypass DPI, censored envs...
12:07  * sipa suggests using gramtropy generated text over IRC
12:07 < jonasschnelli> Tor can start subprocesses that bootstrap a SOCK proxy to communicate with the counterparty
12:08 < gmaxwell> jonasschnelli: Why do you think we need something special for that?  We have proxy support already, which is all that is generally required for that sort of thing. 
12:08 < jonasschnelli> I think supporting PT should be not to complicated in Core
12:08 < gmaxwell> I think it's so not complicated that we already have it. :)
12:08 < wumpus> I don't understand
12:08 < jonasschnelli> I'm unsure about the reverse proxy, the env vars and the auto-exec of that subprocess...
12:08 < wumpus> pluggable transports plug into *tor*
12:08 < sipa> jonasschnelli: what specific form of transport do you suggest?
12:08 < wumpus> bitcoin core can use tor
12:08 < wumpus> what else is needed?
12:09 < jonasschnelli> sipa: its not about specific transports,.. IMO its an API for other transport layers...
12:09 < sipa> jonasschnelli: it is to make tor communicate with other tor nodes using different transport layers
12:09 < sipa> what transport layer do you suggest?
12:09 < gmaxwell> The API is socks.
12:09 < wumpus> looks like a layer violation to worry about this? or do you want to make tor tunnel over bitcoin instead of the other way around?
12:09 < luke-jr> I also don't get it
12:09 < jonasschnelli> Maybe I got it wrong,.. but it looked to me after a pure transport layer (not tor)
12:10 < sipa> yes and no
12:10 < wumpus> yes, socks (+optional control port) is good enough as API
12:10 < wumpus> it's the only way it's recommended to use tor
12:10 < sipa> jonasschnelli: i'm very confused by what you suggest
12:10 < sipa> so far you've said "we can use tor pluggable transport", which is true for any tor user
12:10 < phantomcircuit> jonasschnelli, the pluggable transport presents a socks interface which tor uses instead of directly connecting
12:10 < sipa> how is it bitcoin specific, or what do you specifically propose?
12:11 < wumpus> integrating tor's code into bitcoin core is not a good idea
12:11 < kanzure> merge tor source tree
12:11 < phantomcircuit> it's not something that should be configured by things using tor
12:11 < wumpus> indeed, it's part of the tor configuration
12:11 < jonasschnelli> The idea is to make Bitcoin work in DPI env in case it would get blocked,.. like China or Iran
12:11 < jonasschnelli> Without relying on tor
12:11 < gmaxwell> wumpus: I think jonasschnelli suggests that we have support for these obfscuated transports without putting tor in the middle.  I think we already do (in fact, I used one of the ones made for tor to bridge bitcoin nodes last year when we were worried about china blocking bitcoin... before later changing to an icecast stream so that it wouldn't be identifyable by traffic analysis)
12:11 < jonasschnelli> Core could directly use obfs4
12:11 < gmaxwell> jonasschnelli: we already can.
12:11 < jonasschnelli> or meek
12:12 < sipa> jonasschnelli: ah!
12:12 < wumpus> gmaxwell: ohh, so using *part* of tor, just the obfuscation part...
12:12 < sipa> you mean using obfuscation for our own connections, even non tor ones
12:12 < jonasschnelli> Since its a separated project and a seperate binary
12:12 < gmaxwell> wumpus: well the obfuscation parts of tor aren't parts of tor, technicaly. But yes.
12:12 < wumpus> this sounds like scope creep to me
12:12 < gmaxwell> jonasschnelli: have you trie using obfs4. I did previously, it just worked.
12:12 < gmaxwell> tried*
12:13 < sipa> i would say if we're worried about that, you should also just use tor already
12:13 < wumpus> gmaxwell: it's tor project code
12:13 < wumpus> maybe not part of the tor repository, I don't know
12:13 < phantomcircuit> i dont see any reason to do this, anybody who needs this can already configure it with the socks proxy support
12:13 < wumpus> yes
12:13 < jonasschnelli> okay... fair points. /topic
12:13 < gmaxwell> AFAIK, it just works.  It's kinda limited though because none of them resist traffic analysis and it's SUPER easy to identify bitcoin traffic with traffic analysis. :)
12:14 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
12:14 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Client Quit]
12:14 < phantomcircuit> gmaxwell, iirc they're all super easy to identify anyways
12:14 < gmaxwell> If there was some addon we needed to make more of them work, I suppose that would be cool, but I dunno what that would be. At least the original obfs proxy that I used before was just a socks proxy.
12:15 < gmaxwell> phantomcircuit: well I think the idea in tor is that there are private ones.
12:15 < jonasschnelli> I think core <-> core could use the propose p2p encryption (with NewHope), but for censoring, is was unsure if we should relay on Tor or on the underlaying independent obfuscation projects.
12:15 < wumpus> oh the obfs layer itself is also a socks proxy?
12:15 < gmaxwell> wumpus: yes
12:15 < wumpus> tor is socks proxies all the way down and nothing else isn't it :)
12:16 < sipa> pigeons at the bottom of the stack
12:16 < wumpus> anyhow, yes, then we can already use it
12:16 < wumpus> sipa: pigeons for transaction broadcasting
12:16 < phantomcircuit> gmaxwell, the only ones that work are the domain fronting ones, so presumably only the private ones actually work
12:16 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
12:18 < wumpus> well the non-private ones become known very soon
12:18 < gmaxwell> (hm the thing I used before wasn't obfs4 it was an earlier version, they all look like they implement proxies regardless)
12:18 < wumpus> no matter how good the obfuscation is, if it's public that you run one...
12:19 < gmaxwell> In any case, I think jonasschnelli's spirt is right. I just don't actually think we need to do anything more than have socks support.
12:19 < wumpus> yes
12:19 < jonasschnelli> Even better then. :)
12:19 < gmaxwell> (it's certantly better to do protocol obfscuation via external proxies than to try to bake anything in...)
12:19 < sipa> how does the proxy know which peers need to use the obfuscation?
12:19 < phantomcircuit> gmaxwell, meek is the only one that works in china, it's domain fronting with gce
12:19 < sipa> you can't just blanket obfuscate all connections
12:20 < sipa> as our normal peer discovery will find peers that don't support it
12:20 < achow101> sipa: I think this would only work for outgoing connections
12:20 < wumpus> sipa: you wouldn't want to use normal peer discovery in such cases
12:20 < sipa> achow101: yes, of course
12:20 < sipa> wumpus: right
12:21 < wumpus> something needs to de-obfuscate incoming connections too, but I suppose that works by forwarding a listening port?
12:21 < gmaxwell> I think perhaps the useful 'feature' that might come for this is being able to provide per-peer proxy configs to addnode/connect.
12:21 < wumpus> or does it really need SOCKS5 binding
12:22 < jonasschnelli> I think achow101 has a topic
12:22 < wumpus> (which we don't support, we only use the proxy for outgoing, SOCKS binding is really really obscure)
12:22 < gmaxwell> I don't think there is need for socks5 binding.
12:22 < wumpus> okay
12:22 < wumpus> per-peer proxies could be useful, yes
12:23 < cfields> gmaxwell: interesting. I believe that'd be trivial to add, other than the syntax handling
12:23 < sipa> "netmask X uses proxy Y"
12:23 < gmaxwell> wumpus: https://www.comparitech.com/blog/vpn-privacy/hide-openvpn-traffic-obfsproxy-on-windows-and-linux-ec2/  you can see how you can hide arbritary crap with obfsproxy. 
12:24 < wumpus> gmaxwell: thanks
12:24 < gmaxwell> sipa: don't want to go too far or proxychains becomes the right tool (it's a multiproxy routing daemon)
12:24 < sipa> ha
12:24 < sipa> that sounds like an improvements over sidechains or treechains
12:24 < phantomcircuit> gmaxwell, proxychains is never the right tool >.>
12:24 < gmaxwell> (it can even nest proxies)
12:25 < gmaxwell> phantomcircuit: but how else will I hax you through 7 proxies?
12:25 < wumpus> fwiw ssh has built-in support for proxy chaining in the client
12:26 < wumpus> #topic hardware wallet support (achow101)
12:26 < achow101> So with PSBT we can kind of do hardware wallet things
12:26 < gmaxwell> in any case, being able to net-scope or node scope proxies is something I would have used before, e.g. "addnode my node in the office via my ssh -D socks proxy".
12:26 < achow101> I've been working on a tool that takes a psbt and does the hardware wallet things: https://github.com/achow101/HWI
12:27 < jonasschnelli> great work achow101!
12:27 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]
12:27 < gmaxwell> achow101: cool.
12:27 < wumpus> woohoo!
12:27 < achow101> but to actually get hww support, we still need a way to get derivation paths for imported keys and such. and for those keys to be part of the keypool
12:27 < jonasschnelli> why not a xpub watch-only wallet support?
12:28 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev
12:28 < achow101> I know sipa has the output descriptors stuff that would work for this, but I think that still quite a ways off
12:28 < sipa> i can prioritize it more, but it's unclear how to keep things compatible
12:29 < sipa> do we want the old keystore based system and the new descriptor based system side by side?
12:29 < jonasschnelli> importing keys seems meh-ish for hardware-wallet. IMO the ideal use case for BIP32 pub key derivation
12:29 < sipa> that wouldn't be too hard, i think
12:29 < gmaxwell> I don't see why we shouldn't deploy the very narrow thing we need to make all the common hardware wallets work, so long as it won't prevent us from using descriptor based logic in tuhe future.
12:29 < sipa> but it would be much nicer if we also get to convert old keystores to desceiptors
12:29 < jonasschnelli> Also, xpub watch-only do not need keypools
12:29 < gmaxwell> jonasschnelli: yes it does.
12:29 < jonasschnelli> I don't see why but happy to learn... 
12:30 < sipa> it's the equivalent of their gap limit
12:30 < gmaxwell> It doesn't have private key material, but it needs _something_ to look ahead with pubkeys and watch for payments.
12:30 < achow101> I did #14021 for importing keypaths into the wallet with importmulti, but it isn't ideal
12:30 < gribble> https://github.com/bitcoin/bitcoin/issues/14021 | Import key origin data through importmulti by achow101 · Pull Request #14021 · bitcoin/bitcoin · GitHubAsset 1Asset 1
12:30 < achow101> it ... works, but kinda sucks as you have to import more keys as you use them. And they aren't in the keypool
12:30 < jonasschnelli> gmaxwell: yes. Right. Correction: no keypool written to disk, only xpub, then derive on load
12:31 < sipa> i fear for more combinations and special cases to deal with
12:31 < gmaxwell> jonasschnelli: well it doesn't really matter if we save it to disk or not. It's harmless to do so.
12:31 < jonasschnelli> Yes. Thats right.
12:32 < gmaxwell> achow101: obviously as a stopgap importing keys at least allows development and/or testing.
12:32 < gmaxwell> achow101: but I assume what you really want is a wallet whos master key reflects the third-party keychain.  I fear the mess of mixed wallets.
12:33 < jonasschnelli> achow101: do you have a plan to make hww interaction more hassle free, like including USBHID in core </joke>?
12:33 < achow101> jonasschnelli: the idea I had was to use the HWI scripts and call them from Core.
12:33 < achow101> they implement all of the usb stuff
12:34 < gmaxwell> I think that should be out of of scope. We should implement a simple fork and stdio interface (or similar) to talk to hardware specific drivers.
12:34 < jonasschnelli> could one of the "hardware-wallets" just be a hot keystore? Similar to SSH Agent?
12:34 < gmaxwell> right.
12:34 < sipa> have metadata in the wallet that says "for these outputs, attempt to sign through device driver X"
12:34 < sipa> which is just an executable that gets invoked and sent a psbt
12:34 < gmaxwell> Even one using SGX+TPM, for example.
12:35 < gmaxwell> the drivers could then also provide their own UI, if required.
12:35 < gmaxwell> E.g. to get a passphrase.
12:35 < gmaxwell> or remind you to plug in the device.
12:35 < achow101> yup. I plan on adding a UI to HWI once I get everything actually working
12:36 < jonasschnelli> Yes. Becaue of the UI, I initially though every vendor must provide its own script/binary...
12:36 < sipa> jonasschnelli: yes
12:36 < jonasschnelli> Because again, plugins then endup outside of the vendors control
12:36 < jonasschnelli> Leading to outdated software
12:36 < gmaxwell> I'm sure it would eventually be possible to have "generic" drivers that work for a family of devices, but I think the industry is too immature for that.
12:36 < jonasschnelli> Indeed
12:37 < gmaxwell> sipa: how would we handle, e.g. "this script is multisig, with device X and device Y" ?
12:37 < gmaxwell> (er driver x and driver y)
12:37 < sipa> gmaxwell: list two drivers
12:37 < gmaxwell> sounds good.
12:37 < jonasschnelli> I was hoping for a protocol/API where Core starts a process and passes all relevant data and the vendors plugin there with rich UI "drivers"
12:37 < sipa> gmaxwell: the drivers would be metadata to descriptor records
12:37 < achow101> gmaxwell: wouldn't that be "this script has two keys and key 1 uses driver X and key 2 uses driver Y"
12:37 < sipa> so they would apply to all outputs derived using the same chain(s)
12:38 < sipa> achow101: doesn't even need to say which key is which device
12:38 < sipa> just "try signing using X, try signing using ay"
12:38 < sipa> *Y
12:39 < achow101> anyways, the main point of bringing up this topic was that I wanted to ask whether we should implement xpub watch only wallets or just wait for sipa to finish output descriptor wallets
12:39 < gmaxwell> This kind of interface could easily be used for things other than HWI. For example, green address has a 2fa service, where the service will sign its part of a multisig with you, if you pass a 2fa.  This could be supported by a simple driver that sends the tx to a service and gets the sig back.
12:40 < gmaxwell> jonasschnelli: I don't think we should be providing the HWI specific UI, because if we provide the UI we would constrain innovation there.
12:41 < jonasschnelli> Not Core. But the vendor could have a driver with UI
12:41 < jonasschnelli> (and network interface and whatnot)
12:41 < gmaxwell> right. I agree.
12:42 < gmaxwell> The interface between core and the driver is basically just a PSBT plus arguments provided in the driver config.
12:42 < gmaxwell> achow101: well I think thats between you and sipa mostly
12:42 < gmaxwell> I hope we don't end up with even more combinitorial explosion in the wallet, however.
12:42 < jonasschnelli> Yes. But IMO that only one part. How to get pubkey&metdata into core (and eventually multisig stuff) is still unlcear to me
12:42 < gmaxwell> like having to handle a wallet with mixed old plain keys, hd keys, achowpubkey, and descriptors all at once.
12:42 < jonasschnelli> (in a non RPCish way)
12:42 < sipa> jonasschnelli: descriptors :)
12:43 < jonasschnelli> sipa: I mean plug-n-play. :)
12:43 < sipa> jonasschnelli: i'll try to create a writeup on how to integrate them in the wallet
12:43 < sipa> jonasschnelli: "import a descriptor"
12:43 < gmaxwell> the descriptor thing could eventually be  "create new wallet with descriptor"  "paste in descriptor" "confirm"..
12:43 < sipa> ah, you mean GUI
12:43 < sipa> i have no clue.
12:43 < jonasschnelli> You plugin a HWW, the Core detects it and tells you "do you wanna use XYZ".
12:43 < jonasschnelli> *then
12:44 < gmaxwell> doubt we're going to have any detection anytime soon...
12:44 < gmaxwell> as that would require shipping a pile of vendor specific detection and interface code.
12:44 < jonasschnelli> Yes. But if we form an API or similar, we should not only focus on the PSBT part,... also on the how do I create a watch-only wallet (eventually also multisig)
12:45 < jonasschnelli> But I guess the descriptors are the answer here
12:45 < gmaxwell> Create a new wallet from a descriptor, or import a descriptor into a wallet.  
12:46 < gmaxwell> sipa: maybe you can work with achow 101 on a descriptor-lite implementation that would be forward compatible with the full thing later, and is enough to support the common hardware wallets?
12:46 < sipa> gmaxwell: descriptors are also in the codebase
12:46 < sipa> *already
12:47 < gmaxwell> well I meant basically "enough stuff to be able to create an xpub with path autofilling watching wallet"
12:47 < sipa> the hard part is integrating them in the wallet of course
12:47 < sipa> but that isn't harder or easier depending on what the descriptors support
12:48 < achow101> gmaxwell: the problem with that is the wallet format needs to change
12:48 < sipa> i'll try to think it through
12:51 < wumpus> any other topics?
12:51 < gmaxwell> jonasschnelli: wanted to talk about encryption!
12:52 < wumpus> #topic P2P encryption (jonasschnelli)
12:52 < jonasschnelli> Not really... :) but happy to do
12:52 < gmaxwell> heh, what just going to open that big PR and go on vacation? :P
12:52 < jonasschnelli> The question for me now is, is the PR to large (2000lines) and how and when to add NewHope (quantum resistant handshake)
12:53 < jonasschnelli> If it is to large, how to split it into PR that make partially sense on its own (could add the crypto stuff beforehand, but meh)
12:53 < gmaxwell> so the PR can probably be broken into three parts:  (1) prepatory refactors, (2) inclusion of new primitives, (3) the thing itself.
12:53 < jonasschnelli> Yes. Agree.
12:54 < jonasschnelli> But would we merge 2 without 3?
12:54 < jonasschnelli> Maybe 2 with concrete chances that 3 gets merged 
12:54 < gmaxwell> Yes. Exactly.
12:54 < jonasschnelli> 1 will be very small
12:54 < gmaxwell> Well if we changed our mind we could always take it out. We've put other primitives in in advance before.
12:55 < gmaxwell> e.g. bip32 key derrivation went unused for years.
12:55 < sipa> BIP32 derivation was in the codebase for 3 years before being used :)
12:55 < sipa> jinx.
12:55 < jonasschnelli> Indeed. But its 2018 now. :)
12:55 < jonasschnelli> Okay. I'll do the split then.
12:55 < wumpus> granted, that was before people neurotically deleted dead code :-)
12:55 < gmaxwell> It's fine,  I think that chacha stuff is mostly a distraction from the review of that PR.  It needs to be reviewed but mostly for build integration, etc.
12:56 < gmaxwell> wumpus: or even not-dead-yet code!
12:56 < jonasschnelli> heh
12:56 < sipa> wumpus: it wasn't dead! it had tests!
12:56 < wumpus> gmaxwell: even preemptively
12:56 < cfields> jonasschnelli: taking a quick look at your PR, was the handshake spec modified to be sent first thing? Or am I misreading the code?
12:56 < jonasschnelli> Yes. I can also try to extend the existing ChaCha20 RNG to be used for the crypto part
12:56 < wumpus> jonasschnelli: anyhow if it simplifies review, please do split it up
12:56 < jonasschnelli> cfields: yes
12:57 < jonasschnelli> cfields: https://gist.github.com/jonasschnelli/c530ea8421b8d0e80c51486325587c52#Handshake
12:57 < jonasschnelli> Great. Will split
12:57 < promag> nice
12:57 < gmaxwell> jonasschnelli: when you split make sure all the parts are visible. E.g. I'll want to look at (3) while reviewing (1) just in case some refactor seems like it makes no sense on its own. :)
12:58 < cfields> jonasschnelli: woohoo, thanks
12:58 < jonasschnelli> gmaxwell: Yes. Good point. Will do.
12:59 < jonasschnelli> I guess keeping the "overall" PR somewhere helps to see the goal.
12:59 < gmaxwell> sipa has done that in the past, e.g. with the segwit rebase.
12:59 < jonasschnelli> The unanswered question is when and how to add the NewHope handshake part
12:59 < wumpus> yes, indeed, though we probably want to change the one in high-priority then
12:59 < jonasschnelli> Yes. Lets remove it for now
12:59 < jonasschnelli> (ill do that)
13:00 < wumpus> ok
13:00 < wumpus> #endmeeting
13:00 < lightningbot> Meeting ended Thu Aug 23 20:00:12 2018 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:00 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-08-23-19.00.html
13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-08-23-19.00.txt
13:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-08-23-19.00.log.html
13:00 < wumpus> jonasschnelli: I did already
13:00 < jonasschnelli> thanks
13:00 < gmaxwell> jonasschnelli: well my thought is that we make another PR on top of these-- likely with two commits, one that just adds the code to the build, the other which crams it into the handshake, so we see the marginal cost.
13:01 < jonasschnelli> Yes. Exactly.
13:02 < jonasschnelli> gmaxwell: Do you know if it is sane to replace using SHAKE as the output "KDF/XOF" with HKDF?
13:02 < jonasschnelli> Or would that be a custom version of NewHope?
13:03 < gmaxwell> jonasschnelli: we could just take its output as is for now. Lets change the absolute minimum for the first pass.
13:03 < jonasschnelli> okay
13:03 < cfields> jonasschnelli: I'm lagging quite far behind, so "go read the full spec" is a fine answer if you'd like. But I don't see any extensibility in the handshake spec? What's the reason for hard-coding a bare 32byte key without some sort of versioning/typing?
13:03 < sipa> cfields: versioning outside of the key is identifiable
13:03 < cfields> got it.
13:03 < cfields> thanks
13:03 < jonasschnelli> yes..
13:04 < jonasschnelli> cfields: also, the additional NewHope handshake is not in the specs right now.
13:04 < gmaxwell> cfields: we are avoiding having any fixed bytes so that it's harder for dumb DPI to block the traffic. A new protocol can distinguish itself by being incompatible. :)
13:04 < jonasschnelli> But IMO censorship resistance is not property of that proposal...
13:04 < cfields> jonasschnelli: right, I was just trying to figure out how the transition would work. I understand the issue now.
13:05 < jonasschnelli> Not having censorship resistance as a property of the new protocol, doesn't mean, we should use static, identifiable data if avoidable
13:05 < gmaxwell> in general upgrading this stuff, even with versioning is messy. 
13:05 < jonasschnelli> and that, yes.
13:06 < jonasschnelli> Does anyone knows why appveyor has build issues when travis and gitian is fine with it? https://ci.appveyor.com/project/DrahtBot/bitcoin/build/master.148
13:06 < gmaxwell> like you send key type B and then the other side doesn't support B only A.... so what, now you start over?  all doable just fine.
13:07 < jonasschnelli> I just figured out we don't keep node stats outside of the connection lifetime...
13:07 < jonasschnelli> (except addrman's service bits)
13:07 < gmaxwell> But the extra complexity makes me feel like we're not likely to do something like newhope until the next major protocol rework, if it doesn't go in the first ersion.
13:07 < jonasschnelli> Yes. It should go into the first, deployed version.
13:07 < jonasschnelli> But maybe not in the same PR
13:08 < jonasschnelli> Leading to the possibility of incompatible master<->master peers, which I think is fine
13:09 < jonasschnelli> (or merge them almost simultaneous)
13:15 < gmaxwell> yea, incompatible master/master doesn't worry me too much. If we're worried we could add a hidden option to disable the crypto and default it to off until we're ready.
13:17 < wumpus> putting it behind an option initially sounds like a good idea in any case
13:17 < jonasschnelli> Yes. Thats done already (-netencryption)
13:17 < jonasschnelli> Disabled by default
13:18 < wumpus> right
13:20 -!- profmac [~ProfMac@2001:470:1f0f:226:4fa:dd19:ca84:f149] has quit [Ping timeout: 264 seconds]
13:21 < MarcoFalke> jonasschnelli: Appveyor is a different build system
13:21 < MarcoFalke> You'd have to add new files to the cmake file
13:21 < MarcoFalke> (Assuming that that is the issue)
13:22 < jonasschnelli> So all new files need to be added to the Makefile and to a special CI file?
13:22 < wumpus> we need documentation for this appveyor stuff
13:22 < jonasschnelli> Sorry,... I missed the whole PR about that
13:22 < wumpus> it's a different build system and no one really has an idea how it works
13:22 < gmaxwell> what does it do?
13:23 < wumpus> well maybe MarcoFalke does :)
13:23 -!- profmac [~ProfMac@2001:470:1f0f:226:4fa:dd19:ca84:f149] has joined #bitcoin-core-dev
13:23 < MarcoFalke> no, lol
13:23 < achow101> gmaxwell: it's for building windows things IIRC
13:23 < achow101> building in a windows environment
13:23 < jonasschnelli> Do we really need a Visual Studio CI?
13:23 < wumpus> otherwise I'm going to ignore it
13:23 < wumpus> and merge if only travis passes 
13:24 < MarcoFalke> I think it is fine to ignore for now because it is experimental
13:25 < achow101> MarcoFalke: is there supposed to a button to restart appveyor builds? sf so, i don't see one
13:25 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
13:25 < wumpus> jonasschnelli: I think it's hardly reasonable to expect people submitting PRs to update two build systems
13:25 < MarcoFalke> achow101: hmm, yeah there should be a button
13:26 < wumpus> especially if we all have no clue how it works
13:27 < achow101> presumably ken2812221 knows since he was the one to suggest it?
13:31 -!- hebasto [~hebasto@195.60.70.234] has joined #bitcoin-core-dev
13:32 -!- profmac [~ProfMac@2001:470:1f0f:226:4fa:dd19:ca84:f149] has quit [Ping timeout: 276 seconds]
13:35 < jonasschnelli> Maybe it is possible to run the appveyor CI on PRs but not report back (with green-checkmark or red-cross)
13:35 -!- profmac [~ProfMac@2001:470:1f0f:226:4fa:dd19:ca84:f149] has joined #bitcoin-core-dev
13:38 < jonasschnelli> I'm not going to touch an .vcxproj XML...
13:39 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
13:40 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
13:41 < wumpus> ya it's a proprietary format too
13:42 -!- Empact [~empact@192-195-80-226.PUBLIC.monkeybrains.net] has quit [Ping timeout: 276 seconds]
13:44 < luke-jr> smh
13:46 -!- clarkmoody [~clarkmood@47-218-248-206.bcstcmta04.res.dyn.suddenlink.net] has quit []
13:49 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-aycqdrvsqzqrvjcg] has quit [Quit: Connection closed for inactivity]
13:55 < ryanofsky> would be nice if appveyor errors on github were only shown as warnings. it is actually pretty straightforward to edit .vcxproj files, though
14:01 < wumpus> I'm sure it's learnable, but I think we already ask enough things from contributors
14:03 -!- phwalkr [~phwalkr@2001:1284:f019:69b1:82e:a366:b0a4:dfc2] has joined #bitcoin-core-dev
14:04 < wumpus> not that it would hurt to have documentation on how to add files, even with the current build system
14:05 -!- thib [~thib@wikimedia/Thibaut120094] has joined #bitcoin-core-dev
14:11 < MarcoFalke> Hmm, anyone knows how to have one of the linux jobs in travis compile with clang?
14:11 < MarcoFalke> I installed clang and then set CC=clang and CXX=clang++, but these are simply ignored
14:12 < MarcoFalke> All those build systems are hokuspokus to me
14:13 < wumpus> $1/configure CC="${CLANGPATH}/bin/clang " CXX="${CLANGPATH}/bin/clang++" OBJCXX="${CLANGPATH}/bin/clang++"
14:13 < wumpus> is what I have
14:15 < cfields> MarcoFalke: I believe CC and CXX can't be overridden during configure
14:16 < wumpus> I've been doing it for years
14:16 < luke-jr> cfields: eh, they should be
14:16 < cfields> er sorry...
14:16 < cfields> MarcoFalke: I believe CC and CXX can't be overridden during configure for depends builds
14:16 < cfields> patch coming up
14:17 < wumpus> never tried it with depends builds
14:17 < MarcoFalke> Hmm, maybe I remember wrongly that it worked with depends builds
14:17 < wumpus> so that could well be true
14:17 < MarcoFalke> patch welcome, obviously :)
14:20 -!- meshcollider_ [uid246294@gateway/web/irccloud.com/x-nmtqdivaiywxuoiu] has quit [Quit: Connection closed for inactivity]
14:30 -!- hebasto [~hebasto@195.60.70.234] has quit [Remote host closed the connection]
14:34 -!- profmac [~ProfMac@2001:470:1f0f:226:4fa:dd19:ca84:f149] has quit [Ping timeout: 255 seconds]
14:35 -!- profmac [~ProfMac@2001:470:1f0f:226:4fa:dd19:ca84:f149] has joined #bitcoin-core-dev
14:41 < cfields> MarcoFalke: https://github.com/theuni/bitcoin/commit/0d00fd5901102d9ca2b99d6f17a3bd96c946e3b7
14:42 < cfields> after doing that, need to 'make' in depends again. It should be instant, though.
15:04 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 240 seconds]
15:06 -!- lnostdal [~lnostdal@77.70.119.51] has quit [Read error: Connection reset by peer]
15:19 -!- Varunram [sid210151@gateway/web/irccloud.com/x-eckgfsfaurkhrzdd] has quit [Read error: Connection reset by peer]
15:19 -!- Varunram [sid210151@gateway/web/irccloud.com/x-rhoxavwjqbuhlnzd] has joined #bitcoin-core-dev
15:20 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
15:36 -!- lukedashjr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
15:38 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 260 seconds]
15:41 -!- lukedashjr is now known as luke-jr
16:00 -!- michaelsdunn1 [~michaelsd@unaffiliated/michaelsdunn1] has quit [Remote host closed the connection]
16:37 -!- Zenton [~user@54.104.135.37.dynamic.jazztel.es] has quit [Ping timeout: 264 seconds]
16:59 -!- profmac [~ProfMac@2001:470:1f0f:226:4fa:dd19:ca84:f149] has quit [Ping timeout: 276 seconds]
17:05 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Quit: Leaving.]
17:06 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
17:09 -!- zivl [~zivl@2601:19a:837f:e4e1:3c9c:9c6b:fcd3:1a87] has quit [Ping timeout: 260 seconds]
17:20 -!- phwalkr [~phwalkr@2001:1284:f019:69b1:82e:a366:b0a4:dfc2] has quit [Ping timeout: 265 seconds]
17:32 -!- lnostdal [~lnostdal@77.70.119.51] has joined #bitcoin-core-dev
17:37 -!- profmac [~ProfMac@2001:470:1f0f:226:8530:7dfd:325:e852] has joined #bitcoin-core-dev
17:38 -!- promag [~promag@83.223.234.48] has quit [Remote host closed the connection]
17:38 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
17:46 -!- promag [~promag@83.223.234.48] has joined #bitcoin-core-dev
18:07 -!- Netsplit *.net <-> *.split quits: rex4539
18:07 -!- Netsplit *.net <-> *.split quits: Rootsudo
18:07 -!- Netsplit over, joins: rex4539
18:08 -!- Netsplit over, joins: Rootsudo
18:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
18:10 -!- promag [~promag@83.223.234.48] has quit [Remote host closed the connection]
18:17 -!- promag [~promag@83.223.234.48] has joined #bitcoin-core-dev
18:22 -!- promag [~promag@83.223.234.48] has quit [Ping timeout: 252 seconds]
18:46 -!- Netsplit *.net <-> *.split quits: Magma
18:47 -!- Netsplit *.net <-> *.split quits: pindarhk_, adam3us
18:47 -!- Netsplit over, joins: warren, dongcarl
18:47 -!- Netsplit *.net <-> *.split quits: nanotube
18:50 -!- adam3us [~adam3us@unaffiliated/adam3us] has joined #bitcoin-core-dev
18:52 -!- nanotube [~nanotube@unaffiliated/nanotube] has joined #bitcoin-core-dev
18:58 -!- lone3lf [~lone3lf@177.13.176.184] has quit [Ping timeout: 272 seconds]
19:28 -!- Netsplit *.net <-> *.split quits: vexbuy, rafalcpp
19:29 -!- Netsplit *.net <-> *.split quits: Lightsword, helo, niska, instagibbs
19:30 -!- Netsplit over, joins: Lightsword, helo, instagibbs, vexbuy, rafalcpp, niska
19:32 -!- Netsplit *.net <-> *.split quits: phantomcircuit, andytoshi, keymone, jamesob, Madars, thaumavorio, dqx, bitbee, BlueMatt, wumpus,  (+9 more, use /NETSPLIT to show all of them)
19:43 -!- sipa [~pw@unaffiliated/sipa1024] has quit [Quit: leaving]
19:47 -!- BGL [ninety@75-149-171-58-Washington.hfc.comcastbusiness.net] has quit [Read error: Connection reset by peer]
19:49 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev
19:50 -!- berndj [~berndj@azna.co.za] has joined #bitcoin-core-dev
19:50 -!- bitbee [~bitbee@138.197.209.248] has joined #bitcoin-core-dev
19:53 -!- rev_strangehope [~revstrang@ec2-13-115-230-7.ap-northeast-1.compute.amazonaws.com] has joined #bitcoin-core-dev
19:55 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
19:58 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
20:01 -!- justan0theruser is now known as justanotheruser
20:05 -!- Netsplit *.net <-> *.split quits: e4xit, lnostdal, Varunram, farmerwampum, Giszmo
20:06 -!- Netsplit *.net <-> *.split quits: unholymachine, jl2012, sturles, karelb, MarcoFalke, molz, ryanofsky, windsok, petertodd, games_,  (+6 more, use /NETSPLIT to show all of them)
20:06 -!- Netsplit over, joins: Varunram, Giszmo, e4xit, farmerwampum, ryanofsky, molz, lnostdal, games_, xHire
20:06 -!- grubles [~grubles@gateway/tor-sasl/grubles] has quit [Remote host closed the connection]
20:07 -!- dongcarl [~dongcarl@c-24-5-70-69.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
20:07 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
20:07 -!- unholymachine [~quassel@2601:8c:c003:9f16:a9a2:a65b:627a:51ee] has joined #bitcoin-core-dev
20:07 -!- MarcoFalke [~none@198.12.116.246] has joined #bitcoin-core-dev
20:07 -!- meshcollider [meshcollid@gateway/shell/elitebnc/x-wgvbdtbctoyeevjj] has joined #bitcoin-core-dev
20:07 -!- windsok [~windsok@unaffiliated/windsok] has joined #bitcoin-core-dev
20:07 -!- atroxes [~atroxes@unaffiliated/atroxes] has joined #bitcoin-core-dev
20:07 -!- petertodd [~pete@ec2-52-5-185-120.compute-1.amazonaws.com] has joined #bitcoin-core-dev
20:07 -!- jl2012 [sid133844@gateway/web/irccloud.com/x-mspisgraidtswzjf] has joined #bitcoin-core-dev
20:07 -!- karelb [uid316741@gateway/web/irccloud.com/x-mkfofbuiiybjpdcw] has joined #bitcoin-core-dev
20:07 -!- sturles [~sturles@unaffiliated/sturles] has joined #bitcoin-core-dev
20:07 -!- davex__ [~user@97.119.150.83] has joined #bitcoin-core-dev
20:08 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Ping timeout: 254 seconds]
20:08 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev
20:08 -!- grubles [~grubles@unaffiliated/grubles] has quit [Changing host]
20:08 -!- grubles [~grubles@gateway/tor-sasl/grubles] has joined #bitcoin-core-dev
20:12 -!- Guest46194 [~DougieBot@unaffiliated/dougiebot5000] has joined #bitcoin-core-dev
20:21 -!- Krellan [~Krellan@50-242-94-241-static.hfc.comcastbusiness.net] has quit [Remote host closed the connection]
20:22 -!- plankers [~plank@200.7.98.14] has joined #bitcoin-core-dev
20:25 -!- cornfeedhobo [~cornfeedh@unaffiliated/cornfeed] has quit [Quit: ZNC - https://znc.in]
20:28 -!- jhfrontz [~Adium@cpe-184-57-118-36.columbus.res.rr.com] has quit [Ping timeout: 265 seconds]
20:41 -!- cornfeedhobo [~cornfeedh@unaffiliated/cornfeed] has joined #bitcoin-core-dev
20:43 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Ping timeout: 268 seconds]
20:43 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-dev
20:48 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Quit: Quit]
20:50 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #bitcoin-core-dev
20:57 -!- moxuan [279bdd37@gateway/web/freenode/ip.39.155.221.55] has joined #bitcoin-core-dev
21:01 -!- plankers [~plank@200.7.98.14] has quit [Ping timeout: 252 seconds]
21:07 -!- ken2812221 [~ken281222@110.50.144.85] has quit [Ping timeout: 260 seconds]
21:07 -!- BGL [fifty@75-149-171-58-Washington.hfc.comcastbusiness.net] has joined #bitcoin-core-dev
21:08 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #bitcoin-core-dev
21:15 -!- ken2812221 [~ken281222@1-160-140-87.dynamic-ip.hinet.net] has joined #bitcoin-core-dev
21:17 < ken2812221> Is there any existing document that teach us how to add new source files?
21:20 < ken2812221> I think I can add those for MSVC.
21:26 -!- moxuan [279bdd37@gateway/web/freenode/ip.39.155.221.55] has quit [Ping timeout: 252 seconds]
21:27 -!- moxuan [279bdd37@gateway/web/freenode/ip.39.155.221.55] has joined #bitcoin-core-dev
21:28 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has joined #bitcoin-core-dev
21:29 -!- ossifrage [~ossifrage@unaffiliated/ossifrage] has joined #bitcoin-core-dev
21:40 -!- echonaut9 [~echonaut@46.101.192.134] has quit [Remote host closed the connection]
21:40 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev
21:54 -!- harrymm [~harrymm@69.161.195.103] has quit []
21:56 -!- moxuan [279bdd37@gateway/web/freenode/ip.39.155.221.55] has quit []
21:57 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
21:58 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
21:58 -!- harrymm [~harrymm@223.205.159.23] has joined #bitcoin-core-dev
22:00 -!- plankers [~plank@c-98-238-141-78.hsd1.ca.comcast.net] has quit [Ping timeout: 252 seconds]
22:00 -!- Rootsudo [~textual@180.190.116.105] has quit [Ping timeout: 268 seconds]
22:01 -!- ken2812221 [~ken281222@1-160-140-87.dynamic-ip.hinet.net] has quit [Ping timeout: 272 seconds]
22:02 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Ping timeout: 268 seconds]
22:03 -!- harrymm [~harrymm@223.205.159.23] has quit [Ping timeout: 272 seconds]
22:05 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
22:08 -!- moxuan [~moxuan@39.155.221.55] has joined #bitcoin-core-dev
22:09 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev
22:14 -!- moxuan [~moxuan@39.155.221.55] has quit [Quit: Leaving]
22:15 -!- moxuan [~ycchen@39.155.221.55] has joined #bitcoin-core-dev
22:16 -!- moxuan [~ycchen@39.155.221.55] has quit [Client Quit]
22:18 -!- moxuan [~moxuan@39.155.221.55] has joined #bitcoin-core-dev
22:40 -!- kallewoof [~quassel@240d:1a:759:6000:a7b1:451a:8874:e1ac] has quit [Ping timeout: 265 seconds]
23:08 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
23:09 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
23:10 -!- ken2812221 [~ken281222@1-160-140-87.dynamic-ip.hinet.net] has joined #bitcoin-core-dev
23:13 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Ping timeout: 252 seconds]
23:17 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has quit [Remote host closed the connection]
23:17 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
23:18 -!- sipa [~pw@gateway/tor-sasl/sipa1024] has joined #bitcoin-core-dev
23:22 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
23:24 -!- harrymm_ [~harrymm@69.161.195.103] has joined #bitcoin-core-dev
23:54 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev
23:56 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has quit [Remote host closed the connection]
23:57 -!- vexbuy [~vexbuy@147.red-83-47-212.dynamicip.rima-tde.net] has joined #bitcoin-core-dev
--- Log closed Fri Aug 24 00:00:28 2018