--- Day changed Thu Aug 25 2016
00:11 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
00:12 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
00:14 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:21 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-niodrkmwtscdsmhs] has joined #bitcoin-core-dev
00:23 -!- BashCo_ [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
00:25 -!- rubensayshi [~ruben@82.201.93.169] has joined #bitcoin-core-dev
00:26 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 252 seconds]
00:34 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
00:35 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
00:42 < wumpus> does anyone happen to have the digest mail from bitcoin-dev or core-dev containing the 0.13.0 announcement?
00:42 < wumpus> I'd like to see how the text is mangled there
00:48 < gmaxwell> "okay, so, if we write our release notes in pig latin and make sure any numbers we use are prime..."
00:49 < wumpus> yes it reminds me of the often crazy requirements for passwords "needs at least one $, but no #, must be longer than 666 characters but shorter than 7" etc
00:50 < gmaxwell> jonasschnelli: re, service bit comment, that was my thinking too but I didn't make that argument because I didn't want to encourage another bitcoin classic like sybil attack. :)
00:50 < wumpus> cfields_: sorry for needing another non-trivial rebase for #8085, after the next one you should harry me until it is merged
00:50 < sipa> "Your password needs to contain at least an uppercase character, a digit, punctuation, a hieroglyph, and an extinct mammal"
00:51 < wumpus> yes, that
00:51 < gmaxwell> sipa: is there a configuration for gentropy for that?
00:51 < sipa> gmaxwell: not yet :)
00:51 < sipa> yes, the network refactors should be priority now
00:52 < gmaxwell> where is the gentropy webpage again?
00:52 < sipa> can we also merge feeler connections?
00:52 < gmaxwell> feeler++
00:52 < sipa> gmaxwell: https://github.com/sipa/gentropy/tree/master/gramtropy
00:52 < gmaxwell> feelers should be considered for backport 
00:52 < gmaxwell> sipa: I mean the enscriptem version
00:53 < sipa> ah, http://wps.sipa.be/gramtropy/gramtropy.html
00:53 < gmaxwell> (the backport comment, because of the problems we see in testnet with it taking a while to find many witness peers.)
00:54 < wumpus> jl2012: huh, there isn't even a @ in the release notes
00:54 < sipa> feeler is #8282
00:54 < gmaxwell> his shale kales fail thus nails fail yet ailments bewail but derailing bales assail
00:55 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8282
00:56 < GitHub188> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/f2306fbe01426ce11c4df6a5c1b837106bc2c702
00:56 < GitHub188> bitcoin/0.13 f2306fb Wladimir J. van der Laan: doc: Clean out release notes after 0.13.0 release
00:59 < paveljanik> and Wshadow changes please...
01:00 < GitHub120> [bitcoin] rebroad opened pull request #8587: Provide bloom services to whitelisted nodes. (master...WhitelistedBloom) https://github.com/bitcoin/bitcoin/pull/8587
01:01 < wumpus> yes looking at #8282 now
01:05 < gmaxwell> :-/ more overloading of whitelisted.
01:06 < sipa> soon we'll need a separate confog file describing various peer's services
01:06 < wumpus> I think I've joked about this before, but it's starting to seriously look like whitelisting should be split up into a bitfield
01:07 < sipa> with its own turing-complete configuration language, of course
01:07 < wumpus> subnet 1.2.3.x { flags allow-bloom allow-hyperspace-travel ...  }
01:07 < wumpus> yes, exactly
01:07 < gmaxwell> virtually no one uses it. and its changes in behavior (e.g. the forced relaying) have made it less useful (though at least 0.13 lets you turn that off)
01:08 < wumpus> yeah..
01:08 < wumpus> in any case if this is going to be more complicated it's going to need a proper design, instead of bolting on things
01:09 < wumpus> and proper documentation too
01:09 < gmaxwell> well, also the authentication bip thing is perhaps a better way to hand out access to varrious things.
01:10 < wumpus> I suppose there's use cases for allowing based on IP ranges as well as authentication 
01:11 < gmaxwell> there are, though it just gets messy when we're peppering the code with permit this and permit that, and then putting them all under one banner.
01:11 < wumpus> yes, completely agreed, that was my point
01:12 < wumpus> rebroad is always like 'I need this, so I'll push this change, I don't care about others'
01:12 < wumpus> ego-commits
01:13 < gmaxwell> (Also, AFAIK there isn't even a reason to turn off bloom filter support generally...)
01:13 < sipa> i don't think he needs whitefiltering or bloom filters at all
01:14 < wumpus> disabling bloom filters reduces CPU and I/O load of a running node
01:14 < gmaxwell> I just mean at the moment there are no active attacks going on.
01:14 < gmaxwell> at least none that I'm seeing.
01:14 < wumpus> sure, but its true even without attacks, though in a lesser amount ofc
01:14 < gmaxwell> Yes. It's true.
01:15 < gmaxwell> in any case, for the use case I can think of for that: only provide bloomfiltering to your own mobile wallet,  the authentication is exactly what you want: your wallet will move around, and you want the privacy of the encrypted link.
01:16 < sipa> the original idea behind whitelisting was to use it on an edge router, which your internal network nkdes connect to
01:16 < wumpus> yes, it makes sense to allow bloom filtering support selectively, no argument there
01:17 < wumpus> just overloading whitelisting for everything, bleh
01:17 < sipa> and it needed special configuration so that rebroadcasts would propagate
01:17 < wumpus> but it'd make sense to document what whitelisting is actually for
01:17 < wumpus> to prevent people extending it for what they think it is for
01:18 < wumpus> yes, that was the original idea
01:18 < sipa> agree
01:18 < sipa> it is unclear what the goal os at this point
01:19 < sipa> maybe peer authentication + mempool reconciliation are a good replacement in the future
01:21 < wumpus> yes
01:22 < gmaxwell> well partly it was a result of someone having a specific need (armory wanting to be able to trigger a rebroadcast, when the initial broadcast happened before the nodes connections were up, and similar)
01:22 < gmaxwell> and it got addressed with a more general tool.
01:23 < gmaxwell> but the armory usage was kind of at odds with other usage, for example elewhere I use whitelist to bypass my bandwidth limits to let local nodes use as much as they want,  and to prevent my p2pool daemon from being disconnected.
01:23 < wumpus> yes, overloading the same option for a ton of different things  isn't a good idea, it makes people get into each other's way, and causes unexpected behavior changes between functions that may be exploitable
01:24 < wumpus> it should be more granular
01:24 < wumpus> I wouldn't like rebroad to implement that though...
01:25 < gmaxwell> sort of a challenge, we want to solve specific problems with general tools... but we don't want to overload multiple tools into one feature. It can be hard to tell these things apart.
01:25 < wumpus> er between versions, not between functions
01:26 < wumpus> yes, it's always a challenge, it's clear where we don't want to go, not where we do want to go
01:27 < wumpus> trying to make general tools is a useful goal but only works with a clear view of what the use cases are
01:28 < wumpus> and that should be the beginning of the design not follow from it
01:28 < wumpus> the edge-router case is a clear one, for example
01:29 < wumpus> so is the 'allow BLOOM for LAN or localhost or authenticated peers only' for people using SPV wallets locally to connect to a node, but don't want to expose it to the whole world
01:30 < gmaxwell> yes, though that means different things for different uses. e.g. the armory one wanted it to bypass all standardness rules, for example. not what you normally want when the purpose of your edge router is to conceal your screwups from the network. :)
01:30 < wumpus> but these are completely different things and shouldn't be moved under one option
01:31 < btcdrak> wumpus: the announce list converted the message to HTML that's where the issues came from which we have solved. As for the LF list, the @ conversion is to protect against spam harvesters. For the mailing list does sending attachments work? I think it is important to have the SHA256SUMS sent to several locations. Certainly GPG signing simple messages is not
01:31 < btcdrak> hazardous. Maybe it it too much to GPG sign the entire release announcement. The part that needs to be signed are the torrent link and the hashes.
01:31 < wumpus> the thing is, 'whitebind'/'whitelist' *look* like something that would cover both cases. You allow internal connections with more privileges
01:31 < gmaxwell> The idea of some fancy acl thing  (your set subnet 1234 flags space-modulator, example) makes me sad because 0.0001% of users would use it, and half of them would set it wrong. But something like that would be the only way to reasonable accomidate some things.
01:32 < wumpus> well at least a fancy ACL would be a general tool, that can be used for many different things, that doesm ake me happy
01:32 < wumpus> (e.g., instead of specific options with slightly different syntax)
01:33 < wumpus> btcdrak: yes
01:34 < wumpus> the hashes are already in SHA256SUMS.asc, I think adding them into the release announcement may have confused people to check the signature on that message instead of SHA256SUMS.asc
01:35 < wumpus> btcdrak: I usually just sign my mails to the development mailing list, doesn't haev much to do with it being a release announcement or not
01:38 < wumpus> gmaxwell: but I can still remember arguing against having any subnet/ACL matching in bitcoind because of similar reasons, so I understand your point, it's just that now we've crossed this threshold anyway we should try to do it in a consistent way
01:38 < wumpus> 'bitcoind is not a firewall tool!'
01:39 < gmaxwell> I think the authentication will make it more justifyable in fact... just because there will be more cases to use it.
01:39 < wumpus> maybe we could allow specifying a BPF filter *ducks*
01:39 < gmaxwell> wumpus: bitcoin script
01:39 < wumpus> right, with authentication you virtually *need* a system like that
01:49 < GitHub189> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/62a5a8a01866...026c6edac947
01:49 < GitHub189> bitcoin/master dbb1f64 Ethan Heilman: Added feeler connections increasing good addrs in the tried table....
01:49 < GitHub189> bitcoin/master 026c6ed Wladimir J. van der Laan: Merge #8282: net: Feeler connections to increase online addrs in the tried table....
01:49 < GitHub71> [bitcoin] laanwj closed pull request #8282: net: Feeler connections to increase online addrs in the tried table. (master...feelers3) https://github.com/bitcoin/bitcoin/pull/8282
01:49 < GitHub197> [bitcoin] laanwj closed pull request #8459: [0.13] release-notes: Do not encourage changing blockmaxsize to blockmaxweight (0.13...0.13_relnotes_remove_bad_advice) https://github.com/bitcoin/bitcoin/pull/8459
01:50 -!- mn3monic_ is now known as mn3monic
01:50 -!- mn3monic [~guido@176.9.68.68] has quit [Changing host]
01:50 -!- mn3monic [~guido@unaffiliated/mn3monic] has joined #bitcoin-core-dev
01:54 < wumpus> I'm not sure what to do with "leveldb: generate lib independent of locale sort" https://github.com/bitcoin/bitcoin/pull/8575  it's a change to leveldb,and we no longer need it since 0.13.0, and we likely won't do a leveldb subtree update anymore for 0.12.x. 
01:55 < sipa> right
02:01 < GitHub185> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/026c6edac947...95a983d56dbd
02:01 < GitHub185> bitcoin/master fa1cf9e MarcoFalke: [test] Remove unused code
02:01 < GitHub185> bitcoin/master 95a983d MarcoFalke: Merge #8578: [test] Remove unused code...
02:01 < GitHub76> [bitcoin] MarcoFalke closed pull request #8578: [test] Remove unused code (master...Mf1608-qaUnused) https://github.com/bitcoin/bitcoin/pull/8578
02:15 < luke-jr> https://github.com/bitcoin/bitcoin/issues/8586 should probably be reopened.
02:16 -!- hybridsole [~hybridsol@unaffiliated/hybridsole] has quit [Ping timeout: 276 seconds]
02:16 -!- hybridsole [~hybridsol@unaffiliated/hybridsole] has joined #bitcoin-core-dev
02:20 < wumpus> luke-jr: are you going to troubleshoot/fix it?
02:20 < wumpus> if so, I don't mind reopening it
02:21 < wumpus> I tend to agree with MarcoFalke "However, if things are know to be broken and no one maintains/tests them, it would be better to disable qt4 right now.", but if we have someone that tests/fixes/maintains qt4 support we could keep doing that
02:22 < wumpus> I wonder how long this has been broken and gone unnoticed, not being able to switch tabs is quite serious
02:22 < btcdrak> is there any point in continuing with Qt4?
02:22  * luke-jr takes a look at the problem before deciding.
02:22 < sipa> arguabl, #8586 is still an issue, as we advertize support for Qt4.
02:22 < wumpus> btcdrak: see https://github.com/bitcoin/bitcoin/issues/8263
02:23 < luke-jr> btcdrak: it's currently the only way to get native look/feel on KDE 4
02:23 < sipa> the solution may be discontinuing qt4, but that's still a cjangr
02:23 < sipa> *changr
02:23 < wumpus> I personally don't want to spend one minute of my time hndling qt4 issues, at least
02:23 < sipa> *change
02:23 < jonasschnelli> Yes. Neither do I. 
02:24 < wumpus> #8263 was *assuming* things were working on qt4
02:24 < MarcoFalke> What is the advantage of having a native look/feel if you know that the application is untested and potentially buggy?
02:24 < wumpus> if they aren't, and people didn't even notice, well that's clear enough
02:25 < luke-jr> wumpus: well, it's only day 2(?) and people are reporting bugs
02:25 < jonasschnelli> I think we should not keep Qt4 compatibility only because of KDE 4
02:25  * luke-jr is happy there's been no problems with C++11 though
02:25 < wumpus> MarcoFalke: tend to agree
02:26 < MarcoFalke> luke-jr: The person reporting the bug apparently compiled against qt4 by accident
02:26 < wumpus> luke-jr: any update on when KDE is going to fix this situation?
02:27 < luke-jr> wumpus: KDE has moved on. KDE 4 is no longer supported. but KDE 5 is not usable yet. if the past tells anything, it'll be years before it is :/
02:27 < da2ce7> sipa: creative/good work on #8580, I don't feel qualified to ACK, however enjoyed reading the PR.
02:27 < wumpus> MarcoFalke: I don't understand how that can happen
02:27  * luke-jr checks KDE release dates
02:27 < MarcoFalke> wumpus: Forget to install qt5?
02:27 < wumpus> we choose qt5 by default now
02:27 < wumpus> oh, maybe that
02:28 < wumpus> luke-jr: well okay that is as close to an admission that this will never happen
02:28 < sipa> regarding c++11, i'd like to share a misconception i've had for a long time: i first read that rvalue references where "values where the receiver was responsible for cleaning up", but that's quite confusing - the destructor is still invoked by the caller. What they really are, is references to values that the receiver is allowed (but not required) to do anything with, including reusing its storage
02:28 < luke-jr> looks like it took 2 years for KDE 4 to stabilise
02:29 < sipa> s/receiver/callee/
02:29 < wumpus> but again, if you are willing to actively support Qt4, I'm fine with keeping support for it. Otherwise the clear decision of all other devs seems to be to remove it.
02:29 < luke-jr> if it's trivial, I'll just fix it; otherwise, fine with removing it
02:30 < sipa> luke-jr: well, one question is why haven't we noticed yet?
02:30 < jonasschnelli> If we support Qt4, someone needs to test and fix at least the RCs.
02:30 < sipa> seems you are using Qt4, but didn't notice this issue either?
02:30 < luke-jr> sipa: no devs use Qt4? :P
02:30 < luke-jr> I've been building against Qt5 for a while
02:30 < wumpus> jonasschnelli: yes, we need someone to step up to support it then, if no one is willing, then advertising qt4 support is wrong
02:31 < jonasschnelli> Agree
02:31 < luke-jr> I can probably switch back, it's no big difference to me
02:32 < jonasschnelli> luke-jr: your saying that you will continue to actively support Qt4? Which means testing release candidates and fixing stuff? Than I'll stop the PR for disabling Qt4 support.
02:32 < wumpus> sipa: interesting
02:32 < wumpus> sipa: yes I haven't really formed a conception around them either yet, more than 'maagic!'
02:32 < jonasschnelli> Qt4 != Qt4
02:32 < luke-jr> I can't reproduce the problem. :/
02:33 < da2ce7> wumpus: on the gpg signing the release announcement: I would recommend including signed gpg armoured copy of the announcement at the bottom of the email;  Anyone who wishes to verify the message can do a diff between the two to see if anything important was changed.
02:33 < sipa> wumpus: it's quite clever... the only "magic" is that passed temporaries are automatically given the rvalue-reference class (which can be automatically converted into a lvalue reference, if the callee doesn't have an overloaded version that takes rvalue references)
02:33 < luke-jr> everything seems to work with Qt4 for me
02:34 < wumpus> da2ce7: yes that could work (although the mailing list was already complaining about me sending a 40kb mail...)
02:34 < sipa> wumpus: something else that was unintuitive to me is that when you have a function with a (type&& x) parameter, x is just an lvalue reference - the rvalue status is just used to determine which overloaded version to use
02:34 < wumpus> luke-jr: I had this problem with qt5 too, with the out-of-tree changes, btw https://github.com/bitcoin/bitcoin/pull/7911#issuecomment-212413442   But that was fixed. Bu tmay be a similar issue
02:34 < sipa> and if you want to pass x along to something else without copying, you need to use std::move
02:35 < sipa> wumpus: rvalue references are huge complication to the language, but they really feel like addressing a very deep problem
02:36 < luke-jr> wumpus: I wonder if a non-clean build dir (old bitcoin-config.h?) might also cause this
02:36 < wumpus> sipa: it does add a lot of complication to an already extremely complicated language, but yes I think overall it's worth it
02:37 < wumpus> sipa: it does allow for doing some things much more efficient in a cleaner way
02:37 < sipa> yes, it always felt non-C++-ish to me that there were many cases in which you couldn't cleanly avoiding copying
02:37 < sipa> C++-ish here meaning that you should always have the option to avoid unnecessary code execution
02:37 < wumpus> yes you had to use some really ugly hacks to avoid copying, if possible at all
02:38 < wumpus> (like adding a dummy element and swapping, etc)
02:39 < luke-jr> wumpus: I bet he had to `make clean` for Qt5, but didn't the first time around..
02:39 < wumpus> right, un-c++ish, it's intended to be an efficient language, if not, there are plenty of other languages to use that are more developer friendly
02:39 < btcdrak> It's pretty clear supporting Qt4 and doing QA for releases is going to be like pulling teeth.
02:39 < jonasschnelli> A Qt4-semi-disabling-step would be to disable the auto-detection
02:40 < wumpus> "and if you want to pass x along to something else without copying, you need to use std::move"  I do wonder how std::move is implemented, or is it some compiler-internal magic?
02:40 < luke-jr> btcdrak: it seems to just work for now
02:40 < jonasschnelli> If someone really wants to compile against qt4, we could keep --with-gui=qt4 but disable the autodetect
02:40 < wumpus> jonasschnelli: good idea; you can still force using it if you know what you're doing, but it wil never choose it by default
02:40 < sipa> wumpus: it simply casts a reference to an rvalue reference
02:40 < sipa> nope, you can implement it yourself
02:40 < wumpus> sipa: oh, that's all
02:40 < luke-jr> jonasschnelli: that sounds reasonable; maybe a message to make noises if they want Qt4 support to stay?
02:40 < sipa> std::forward is more magic, but still does not require any internals
02:41 < jonasschnelli> luke-jr: Yes. Okay... lets try that.
02:41 < sipa> wumpus: you can create a function that takes a template parameter <typename T> (T&& x), in which case x is a universal reference (either an lvalue or an rvalue), and std::forward turns it back into the way it was called
02:42 < sipa> so you can create a function that takes either an lvalue or an rvalue, and passes it down the stack several times without losing its rvalue status
02:43 < wumpus> ah the 'perfect forwarding' thing
02:43 < GitHub187> [bitcoin] jonasschnelli pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/95a983d56dbd...d26234a9e2fa
02:43 < GitHub187> bitcoin/master 15df3c1 Andrew Chow: Persist the datadir after option reset...
02:43 < GitHub187> bitcoin/master 57acb82 Andrew Chow: Load choose datadir dialog after options reset
02:43 < GitHub187> bitcoin/master d26234a Jonas Schnelli: Merge #8487: Persist the datadir after option reset...
02:43 < GitHub68> [bitcoin] jonasschnelli closed pull request #8487: Persist the datadir after option reset (master...persist-datadir) https://github.com/bitcoin/bitcoin/pull/8487
02:44 < wumpus> it's kind of clever
02:44 < sipa> and the reason that std::forward doesn't happen automatically is that of course you're allowed to use x multiple times in the function body, as it is a normal variable
02:45 < wumpus> yes, makes sense
02:45 < sipa> so in that case you wouldn't want to auto destruct it on first use
02:45 < sipa> combining with substructural typing would have been nice :)
02:48 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
02:54 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has joined #bitcoin-core-dev
02:55 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
02:57 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has quit [Client Quit]
02:58 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has joined #bitcoin-core-dev
02:59 < btcdrak> that gitian script by achow101 makes me happy
03:03 < sipa> ffs can we send rebroad to a programming class
03:05 < luke-jr> Matt's doing one in NY, right? :p
03:27 < paveljanik> rebroad looking for a ban 8)
03:49 -!- moli [~molly@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
04:04 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
04:04 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Remote host closed the connection]
04:05 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
04:05 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-niodrkmwtscdsmhs] has quit [Quit: Connection closed for inactivity]
04:07 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Remote host closed the connection]
04:08 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has joined #bitcoin-core-dev
04:13 -!- pedrobranco [~pedrobran@167.225.61.94.rev.vodafone.pt] has quit [Ping timeout: 264 seconds]
04:20 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has joined #bitcoin-core-dev
04:22 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
04:22 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]
04:22 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
04:31 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
04:31 < GitHub152> [bitcoin] sipa opened pull request #8589: Inline CTxInWitness inside CTxIn (on top of #8580) (master...segwitinlinepain) https://github.com/bitcoin/bitcoin/pull/8589
04:35 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has quit [Quit: Textual IRC Client: www.textualapp.com]
04:36 < btcdrak> sipa: does #8589 replace both #8452 and #8580?
04:36 < sipa> yes
04:37 < btcdrak> may be better to close those two?
04:37 < sipa> well i don't know whether #8451 or #8580 will be accepted
04:38 < sipa> i guess i could wait with #8589 and #8452 until that choice is made
04:39 < GitHub70> [bitcoin] sipa closed pull request #8452: Code simplification: inline CTxInWitness inside CTxIn (master...segwitinline) https://github.com/bitcoin/bitcoin/pull/8452
05:00 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
05:04 < GitHub60> [bitcoin] sipa closed pull request #7984: Optional parameter for rescans to start at a specified height (master...rescan-fromheight) https://github.com/bitcoin/bitcoin/pull/7984
05:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:14 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 244 seconds]
05:15 < GitHub54> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d26234a9e2fa...9d0f43b7ca72
05:15 < GitHub54> bitcoin/master be1d451 Will Binns: contributing.md: Fix formatting...
05:15 < GitHub54> bitcoin/master 9d0f43b Pieter Wuille: Merge #8226: contributing.md: Fix formatting (line lengths and smart quotes)...
05:15 < GitHub120> [bitcoin] sipa closed pull request #8226: contributing.md: Fix formatting (line lengths and smart quotes) (master...binns-contributing-formatting) https://github.com/bitcoin/bitcoin/pull/8226
05:17 -!- Squidicuz [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has joined #bitcoin-core-dev
05:18 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
05:19 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
05:19 -!- Squidicc [~squid@pool-173-48-102-116.bstnma.fios.verizon.net] has quit [Ping timeout: 258 seconds]
05:20 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 250 seconds]
05:20 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Remote host closed the connection]
05:21 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev
05:23 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Ping timeout: 252 seconds]
05:24 -!- murch [~murch@p4FE3896C.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
05:29 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
05:36 -!- YOU-JI [~youyouyou@FL1-60-237-57-24.chb.mesh.ad.jp] has joined #bitcoin-core-dev
05:36 -!- aalex_ [~aalex@64.187.177.58] has joined #bitcoin-core-dev
05:37 -!- aalex [~aalex@64.187.177.58] has quit [Read error: Connection reset by peer]
05:49 -!- laurentmt [~Thunderbi@80.215.210.165] has joined #bitcoin-core-dev
05:51 -!- laurentmt [~Thunderbi@80.215.210.165] has quit [Client Quit]
05:54 -!- laurentmt [~Thunderbi@80.215.210.165] has joined #bitcoin-core-dev
05:55 -!- laurentmt [~Thunderbi@80.215.210.165] has quit [Client Quit]
05:55 < GitHub179> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9d0f43b7ca72...0606f95b1ea8
05:55 < GitHub179> bitcoin/master 2f32c82 Jonas Schnelli: [Qt] show network/chain errors in the GUI
05:55 < GitHub179> bitcoin/master 0606f95 Jonas Schnelli: Merge #7579: [Qt] show network/chain errors in the GUI...
05:55 < GitHub28> [bitcoin] jonasschnelli closed pull request #7579: [Qt] show network/chain errors in the GUI (master...2016/02/gui_alert) https://github.com/bitcoin/bitcoin/pull/7579
06:06 < GitHub83> [bitcoin] MarcoFalke opened pull request #8590: Remove unused variables (master...Mf1608-unusedCode) https://github.com/bitcoin/bitcoin/pull/8590
06:11 < jonasschnelli> Travis failed on master: https://travis-ci.org/bitcoin/bitcoin/jobs/155043866#L2347
06:11 < jonasschnelli> compactblock test
06:15 < GitHub69> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0606f95b1ea8...53f8f226bd1d
06:15 < GitHub69> bitcoin/master f13c1ba Michael Rotarius: Move AdvertiseLocal debug output to net category
06:15 < GitHub69> bitcoin/master 53f8f22 Pieter Wuille: Merge #8462: Move AdvertiseLocal debug output to net category...
06:15 < GitHub172> [bitcoin] sipa closed pull request #8462: Move AdvertiseLocal debug output to net category (master...advertiselocal) https://github.com/bitcoin/bitcoin/pull/8462
06:16 < sipa> jonasschnelli: ugh
06:16 < jonasschnelli> probably a random error...
06:16 < jonasschnelli> (one of these)
06:17 < sipa> i'm restarting
06:17 < jonasschnelli> ok
06:29 -!- tom3 [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
06:35 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev
06:49 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
06:49 < GitHub181> [bitcoin] rebroad opened pull request #8591: Do not relay or mine excessive sighash transactions (master...NoExcessiveSighashTxs) https://github.com/bitcoin/bitcoin/pull/8591
06:50 -!- isis [~isis@abulafia.patternsinthevoid.net] has quit [Quit: Lost terminal]
06:59 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
07:01 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 258 seconds]
07:07 -!- dirtynewshoes [~dirtynews@sydnns0115w-156057003104.dhcp-dynamic.FibreOp.ns.bellaliant.net] has quit [Quit: WeeChat 0.3.8]
07:08 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]
07:09 < GitHub149> [bitcoin] MarcoFalke closed pull request #8579: Performance: Prefer prefix operator for non-primitive types (master...Mf1608-perfIter) https://github.com/bitcoin/bitcoin/pull/8579
07:11 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:14 -!- tom3 [~tom@unaffiliated/tommc] has quit [Ping timeout: 258 seconds]
07:25 -!- tom3 [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev
07:27 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection]
07:27 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev
07:30 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds]
07:31 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has quit [Quit: Verlassend]
07:34 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
07:38 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit []
07:44 -!- YOU-JI [~youyouyou@FL1-60-237-57-24.chb.mesh.ad.jp] has quit [Quit: Leaving...]
07:48 < GitHub76> [bitcoin] sipa closed pull request #8591: Do not relay or mine excessive sighash transactions (master...NoExcessiveSighashTxs) https://github.com/bitcoin/bitcoin/pull/8591
07:52 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hfxuqdjefumevcqm] has joined #bitcoin-core-dev
07:56 < GitHub80> [bitcoin] hejunbok opened pull request #8592: 0.13 (master...0.13) https://github.com/bitcoin/bitcoin/pull/8592
07:57 < GitHub7> [bitcoin] hejunbok closed pull request #8592: 0.13 (master...0.13) https://github.com/bitcoin/bitcoin/pull/8592
08:00 -!- Megaf [~quassel@unaffiliated/megaf] has joined #bitcoin-core-dev
08:00 -!- arubi [~ese168@unaffiliated/arubi] has quit [Ping timeout: 252 seconds]
08:03 -!- rubensayshi [~ruben@82.201.93.169] has quit [Remote host closed the connection]
08:26 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 265 seconds]
08:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
08:43 -!- Megaf [~quassel@unaffiliated/megaf] has quit [Ping timeout: 260 seconds]
08:44 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has joined #bitcoin-core-dev
08:47 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 264 seconds]
08:48 < GitHub39> [bitcoin] jl2012 opened pull request #8593: Verify all incoming txs unless the witness stripped size is >100kB (master...verifyalltx) https://github.com/bitcoin/bitcoin/pull/8593
09:03 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
09:50 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]
09:59 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
10:24 < luke-jr> MarcoFalke: https://github.com/bitcoin/bitcoin/pull/6996 my rebase already has the tests taken care of too..
10:24 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
10:25 < MarcoFalke> Nice, then ask sipa to force push :)
10:25 < luke-jr> implicitly did 16 days ago :p
10:26 < sipa> luke-jr: how does it deal with invalidateblock?
10:26 < sipa> you could return later to something with a lower chainwork
10:27 < luke-jr> sipa: dunno, I would assume like any other invalid block declared precious? O.o
10:27 < sipa> i guess it's such an edge case it doesn't matter
10:28 < luke-jr> doesn't preciousblock just give a small bias toward the block in question, in best-chainwork selection?
10:30 < sipa> yes
10:30 < sipa> right, i guess it doesn't matter even
10:31 < sipa> thanks, i'll update the branch
10:32 < Lauda> Is the credit list @release of a version updated frequently/automatically/manually?
10:34 < luke-jr> Lauda: you mean the list of contributors at the end of the release notes? typically comes from a git log, sometimes with manual adjustments
10:34 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Read error: Connection reset by peer]
10:35 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
10:35 < Lauda> Yes, that list. Thanks for the information.
10:38 < sipa> well it's not automatically updated at all... it is compiled by wumpus at release time
10:38 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
10:39 < Lauda> Based on what? Seems some people are on the list due to just having a pull request or two that eventually got closed.
10:40 < sipa> commits
10:41 < Lauda> One has to have a merged commit to be on that list?
10:41 < luke-jr> Lauda: git shortlog v0.12.1..v0.13.0 | perl -nle 'm/^(\S.*)\s\(.*$/ && print $1' | sort
10:42 < MarcoFalke> Is the script wumpus uses public?
10:42 < sipa> Lauda: yes
10:42 < sipa> that's the necessary and sufficient condition
10:43 < MarcoFalke> In some corner cases it does misattribution.
10:43 < MarcoFalke> E.g. I open a pull but I am not author of the commits
10:43 < Lauda> I think it did, sec.
10:43 < MarcoFalke> I reported this once so it might be fixed by now
10:43 < wumpus> for the credits list I prefer erring on the safe side, e.g. including more than necessary instead of less
10:44 < wumpus> MarcoFalke: any specific ones?
10:44 < MarcoFalke> This was in 0.12.x
10:44 < MarcoFalke> already fixed
10:44  * luke-jr ponders what wumpus's LC_COLLATE is
10:44 < wumpus> that script simply looks who submitted the pull, so if you submitted someone elses' pulls then that needs to be manually corrected
10:45 < wumpus> it's pretty dumb and I end up doing a lot of work myself
10:45 < MarcoFalke> I wonder if the script could be included in the repo.
10:45 < MarcoFalke> Maybe people will help you maintain it
10:45 < wumpus> you should look over the list and correct things that aren't correct
10:45 < wumpus> oh no way, it's crap
10:45 < MarcoFalke> ha, I guessed it
10:45 < MarcoFalke> :)
10:45 < MarcoFalke> I wouldn't want to share my scripts ...
10:46 < luke-jr> Lauda: git shortlog --use-mailmap v0.12.1..v0.13.0 | perl -nle 'm/^(\S.*)\s\(.*$/ && print $1' | sort | uniq  # just needs LC_COLLATE and a mailmap file :P
10:46 < Lauda> Just.. :p
10:46 < wumpus> maybe at some point I get to cleaning it up for release, but I only tend to touch it for releases
10:46 < luke-jr> Lauda: you should see my scripts for merging translation files.. :P
10:47 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke]
10:48 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev
10:48 < Lauda> It must be 'nice' looking :)
10:48 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Remote host closed the connection]
10:49 < wumpus> luke-jr: I don't even know what LC_COLLATE does
10:49 < wumpus> let alone having changed it manually :)
10:49 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
10:49 < wumpus> it's not even defined in my env
10:49 < Lauda> https://www.postgresql.org/docs/8.4/static/sql-createdatabase.html
10:50 < wumpus> postgresql?
10:50 < sipa> sort order
10:50 < Lauda> It has the flag explanation
10:50 < Lauda> Collation order (LC_COLLATE) to use in the new database. This affects the sort order applied to strings, e.g. in queries with ORDER BY, as well as the order used in indexes on text columns. The default is to use the collation order of the template database. See below for additional restrictions.
10:50 < luke-jr> wumpus: your sort program does a different order than mine :p
10:50 < wumpus> my sort program probably sucks...
10:50 < luke-jr> wumpus: run `locale` and check the output
10:51 < wumpus> LC_COLLATE="en_US.UTF-8"
10:51 < luke-jr> hmm
10:51 < wumpus> maybe I should set it to Chinese
10:51 < wumpus> or Russian
10:51 < sipa> wumpus: do you use sleepsort?
10:52 < luke-jr> wumpus: German was a closer approximation in my trial-and-error experience
10:52 < wumpus> sipa: yes, the parallelism, it's awesome!
10:52 < luke-jr> de_DE.utf8 got me the same order for the linguas files.. until 0.13.0
10:53 < wumpus> I don't know what I should feel about people trying to reverse my environment variable settings :)
10:53 < luke-jr> lol
10:53 < Lauda> haha
10:54 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Remote host closed the connection]
10:54 < luke-jr> it's what happens when doc/translation_process.md results in a resorting ;p
10:55 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
10:55 < wumpus> python has locale independent sorting AFAIK, but yes, the list-authors script is a shell script
10:55 < wumpus> and itindeed calls the sort utility
10:56 < wumpus> so, so far you're right
10:56 < wumpus> it's curious how all those utilities leak information
11:05 < wumpus> luke-jr: good idea on using --use-mailmap, I was doing a manual processing step for that
11:06 < afk11> bitcoincore.org is behind CloudFlare - following the gitian instructions lead to a 403 if CloudFlare decides it doesn't like you. https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#fetch-and-create-inputs-first-time-or-when-dependency-versions-change
11:07 < btcdrak> afk11: which step?
11:07 < afk11> wget anything..
11:08 < Lightsword> is it hitting a captcha page?
11:08 < afk11> osslsigncode-Backports-to-1.7.1.patch loaded from cfields directory on bitcoincore.org in this case.
11:08 < afk11> Lightsword, yep
11:08 < wumpus> I don't think that's correct
11:08 < luke-jr> hm, I thought there was a different subdomain for downloads
11:09 < Lightsword> yeah…that’s their ddos detection getting triggered, btcdrak maybe you can lower the sensitivity
11:09 < wumpus> you can download from https://dev.bitcoincore.org/cfields/osslsigncode-Backports-to-1.7.1.patch
11:09 < wumpus> that's where it redirects, and that one's not behind cloudflare 
11:10 < Lightsword> wumpus, dev.bitcoincore.org is showing behind cloudflare for me
11:10 < afk11> I'll PR that link instead
11:10 < afk11> oh
11:10 < wumpus> ok, i didn't use to be, I give up
11:11 < wumpus> maybe someone else can host the file somewhere else and give a fallback url...
11:11 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Remote host closed the connection]
11:12 < Lightsword> there should be a way to whitelist urls in cloudflare to turn off the ddos protection
11:12 < Lightsword> although not sure if that’s available in the free plan
11:12 < wumpus> dev. shouldn't be behind cloudflare in the first place
11:12 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
11:13 < luke-jr> http://luke.dashjr.org/tmp/code/osslsigncode-Backports-to-1.7.1.patch
11:13 < wumpus> it's really eating the internet, isn't it cloudflare
11:13 < wumpus> thanks luke-jr
11:14 < gmaxwell> sipa: in the feeler stuff that was just merged, what is the purpose of FEELER_SLEEP_WINDOW, when the timing of the feelers is accomplished via the possion next-send?
11:14 < wumpus> btcdrak: any idea what is happening there?
11:15 < sipa> gmaxwell: ethan explained that in a comment
11:16 < gmaxwell> ah, I see it. that should have ended up as a comment in the code.
11:17 < gmaxwell> As it stands, if I later reworked that code and didn't know they both went in at once, I might have removed the latter delay. 
11:18 < afk11> thanks luke-jr! 
11:18 < btcdrak> wumpus: this is why I wanted to change fallback URL remember.
11:18 < btcdrak> afk11: are you running behind Tor?
11:18 < gmaxwell> sipa: I wonder if their test before evict shouldn't be accomplished by having a seperate table of recently evicted entries which are prioritized for feeler probes. 
11:19 < gmaxwell> rather than having the eviction directly trigger a connection.
11:19 < btcdrak> afk11: it tends to happen on tor exits. settings are on minimal which basically flags Tor exit nodes.
11:21 < sipa> gmaxwell: i don't think i ever reviewed test before evict
11:21 < wumpus> btcdrak: but how did dev.bitcoincore.org end up behind cloudflare?
11:21 < gmaxwell> sipa: ha, I was asking you because you had a bunch of outdated comments on the PR.
11:22 < wumpus> I'm surprised that doesn't interacts wth the OSX SDK download which checks based on source IP
11:23 < sipa> gmaxwell: test-before-evict or feeler?
11:24 < gmaxwell> oh oh sorry. I was commenting on the comments in feeler about test before evict.
11:25 < afk11> btcdrak, yeah, it's using tor. might be better to host it elsewhere, people do this on servers after all
11:27 < wumpus> I'd hope that patch gets merged in upstream at some point so we don't need it anymore at all
11:27 < btcdrak> wumpus: it's in our PMs iirc with lots of details. firstly the fallback URL points to bitcoincore.org so there is a redirect to dev.bitcoincore.org. so the initial request hits CF, game over. the firewall settings are on min, but you cant disable it on the free plan and it flags some IPs very very occasionally if they are "abusive" tor exits usually. You
11:27 < btcdrak> didnt want to change the fallback URL in gitian setup, so I had to use a redirect. secondly there isnt a valid SSL cert on dev so it uses the CF one, plus there was the issue of transient hosting (and wanting the least maintenance options).
11:28 < btcdrak> afk11: you're the first person who has complained, I'm not really sure why a server would be running exclusively behind tor unless it's a dnm :-p
11:28 < wumpus> btcdrak: I know bitcoincore.org is on cloudflare and that we've set up the redirects on bitcoincore.org
11:28 < wumpus> btcdrak: what I don't understand is why dev.bitcoincore.org is behind cloudflare
11:28 < btcdrak> it has to be to get the SSL.
11:29 < wumpus> dev.bitconcore.org has no SSL of itself? okay
11:29 < wumpus> yes, I probably forgot
11:29 < btcdrak> unless you want to buy a certificate. but it doesnt matter, the gitian thing would fail for afk11 anyway because of the redirect
11:29 < wumpus> well we could easily change that link
11:29 < Lightsword> btcdrak, just use letsencrypt for SSL on dev
11:29 < afk11> btcdrak, in this case, it's a qube over tor!
11:29 < luke-jr> …
11:30 < luke-jr> so you're saying people connect to CloudFlare over SSL, and then it connects to the real server unencrypted?
11:30 < luke-jr> wtf is the point
11:30 < btcdrak> letencrypt only issues certs for 3 months.
11:30 < Lightsword> btcdrak, letsencrypt has autorenew...
11:30 < btcdrak> luke-jr: no, the server is SSL
11:30 < afk11> you can set a crontab (certauto is a tool for it I think) to auto-renew
11:30 < wumpus> this is not about gitian, but some other file mentioned in https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#fetch-and-create-inputs-first-time-or-when-dependency-versions-change
11:30 < btcdrak> it's just expired
11:30 < luke-jr> aha, ok
11:31 < luke-jr> how about StartCom?
11:31 < Lightsword> btcdrak, expiring for letsencrypt certificates shouldn’t ben an issue
11:31 < wumpus> hosting files is one of our bigger problems
11:31 < btcdrak> if we were to change the gitian fallback URL we could just point it to github tbf
11:31 < wumpus> but that's what you get with an almost zero project budget :)
11:31 < Lightsword> since you normally run an autoupdater on the server that will periodically renew the letsencrypt cert before it expires
11:32 < btcdrak> Lightsword: no, all those moving parts fail and it's a lot of maintenance in practice.
11:32 < Lightsword> hmm, I thought they had made it fairly reliable by now
11:32 < btcdrak> the gitian fallback should be hosted on github releases page and that would solve the issue.
11:32 < wumpus> is there some cheap https-supporting hosting that is not behind cloudflare?
11:32 < luke-jr> what happened to bitcoin.org's maintainers (not bitcoin.org itself) offering to host bitcoincore.org also?
11:33 < btcdrak> luke-jr: their hosting is due to run out soon.
11:33 < luke-jr> ah
11:33 < wumpus> they have the same proble
11:33 < sipa> who is bitcoin.org's maintainers, and who is bitcoin.org itself?
11:33 < btcdrak> actually, Pindar is getting us a budget for about 5 years infrastructure hosting.
11:33 < luke-jr> sipa: saivann/harding vs theymos/Cobra/someoneelse
11:33 < sipa> ah, ok
11:33 < btcdrak> should have the funding by October/November.
11:34 < gmaxwell> letsencrypt even sends email if you're going to expire.
11:34 < Lightsword> https://github.com/GUI/lua-resty-auto-ssl
11:34 < btcdrak> when wumpus and I spoke, he was quite clear about having a long term solution. also infrastructure hosting is a pita
11:34 < gmaxwell> Please never again setup pretextual security like that, it's an embarassment.
11:34 < Lightsword> for nginx should work
11:35 < btcdrak> gmaxwell: pretextural what?
11:35 < Lightsword> or certbot
11:35 < btcdrak> sorry, I mean what is pretextural
11:35 < wumpus> huh gmaxwell?
11:36 < gmaxwell> proxying through a third party to 'add SSL' when the connection just leaves cloudflare unencrypted and unauthenticated. 
11:36 < gmaxwell> It appears secure to the user, but it's secure to a third party, and not even secure to the backend.
11:36 < afk11> certbot works quite well
11:36 < btcdrak> gmaxwell it's _not_
11:36  * luke-jr assumed btcdrak meant CloudFlare pinned the expired cert or something
11:36 < btcdrak> it's SSL to SSL
11:36 < wumpus> that's not even the case
11:37 < btcdrak> btw, this is the PR https://github.com/bitcoin/bitcoin/pull/7351
11:37 < afk11> btcdrak, it's not. it can be (gets you over CN mismatches), but they will proxy to a HTTP server
11:37 -!- arubi [~ese168@unaffiliated/arubi] has joined #bitcoin-core-dev
11:37 < btcdrak> afk11: no they wont, because it's set to Full SSL
11:37 < wumpus> gmaxwell: also dev.bitcoincore.org is *not* used for anything security critical, there are just some fallback files and gitian checks the hash
11:38 < wumpus> the only reason ssl was necessary there is that browsers frown on redirecting https to http
11:38 < sipa> i'm confused
11:38 < btcdrak> afk11: you can also configure the webserver to only accept connections from a certificate signed by CF
11:38 < gmaxwell> okay I was responding to "why is ... behind cloudflare" "it has to be to get the ssl".
11:38 < Lightsword> wumpus, bitcoincore.org is HSTS preloaded so http through browser won’t work at all for chrome and firefox
11:38 < wumpus> no, it's because of a cert issue with dev.bitcoincore.org, which is hopefully temporary
11:39 < gmaxwell> Okay.
11:39 < wumpus> Lightsword: right, that too
11:39 < gmaxwell> I thought this was another instance of "something hosted on github pages, then people complained about it not having ssl because security, so someone layerd cloudflare on top".   My apologies.
11:40 < Lightsword> doesn’t github force https?
11:40 < btcdrak> remember also, bitcoincore.org has HSTS preloading so we cannot use http:// on that domain.
11:40 < luke-jr> HSTS affects subdomains? :x
11:40 < wumpus> I'm not sure why we're even having an argument about this, is there an actual problem?
11:40 < wumpus> luke-jr: you can configure it to
11:40 < Lightsword> luke-jr, yeah it’s required to be on for HSTS preloading
11:40 < btcdrak> ^
11:40 < wumpus> please keep this channel restricted to bitcoin core development
11:41 < sipa> we need #bitcoin-core-org-dev :)
11:41 < btcdrak> LOL
11:41 < luke-jr> almost time for meeting btw
11:41 < wumpus> all the http and gpg etc talk is getting heavily off topic, yes I know I have been participating too
11:41 < sipa> wumpus: it looks like you've spent an awful lot of time on administrative stuff with 0.13
11:42 < gmaxwell> It's helpful to collaborate on things, even if they're offtopic. But not polite to people trying to read the logs. :)
11:42 < wumpus> sipa: yes :(
11:43 < btcdrak> more channels!
11:43  * btcdrak dashes for a tea break before the meeting
11:48 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Remote host closed the connection]
11:49 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
11:58 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev
11:59 -!- achow101 [~achow101@206.196.187.154] has joined #bitcoin-core-dev
11:59 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev
11:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
12:00 < gmaxwell> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier
12:00 < instagibbs> here
12:00 < CodeShark> morning
12:00 < cfields_> hi, here
12:00 < kanzure> greetz
12:00 < murch> evening
12:00 < jonasschnelli> Meeting?
12:00 < sipa> pŗėșểñť
12:01  * luke-jr gives sipa some frogs as a present.
12:01 < gmaxwell> yum.
12:01 < paveljanik> topics?
12:01 < MarcoFalke> no chair?
12:02 < paveljanik> I'd like to ask for more ACKs on Wshadow PRs
12:02 < gmaxwell> too bad, we haven't started so you can't ask for that yet.
12:02 < gmaxwell> :P
12:02 < kanzure> hehe
12:02 < wumpus> #startmeeting
12:02 < lightningbot> Meeting started Thu Aug 25 19:02:37 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:02 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:02 < btcdrak> here
12:02 < paveljanik> I'd like to ask for more ACKs on Wshadow PRs
12:02 < paveljanik> ;-)
12:03 < cfields_> seconded. Will ACK/re-ACK.
12:03 < gmaxwell> paveljanik: as you wish.
12:03 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt]
12:03 < instagibbs> paveljanik, pr #?
12:03 < cfields_> (i caught a bug of my own with -Wshadow yesterday)
12:03 < instagibbs> for those not initiated
12:03 < MarcoFalke> paveljanik: I ACKed all. Anything I missed?
12:03 < gmaxwell> Give the PP@.
12:03 < gmaxwell> gr. PR#
12:03 < MarcoFalke> https://github.com/bitcoin/bitcoin/pulls/paveljanik
12:04 < paveljanik> 8449, 8472, 8191, 8163, 8109
12:04 < paveljanik> but yes, Marco's link is even better
12:05 < wumpus> anything that really needs to be discussed at the meetng?
12:05 < CodeShark> no, we've already accomplished everything - there's nothing more to do ever
12:05 < gmaxwell> woot.
12:05 < sipa> i'd like to bring up the various proposals for segwit DoS protection
12:05 < gmaxwell> ^
12:05 < instagibbs> ack 
12:05 < petertodd> ack
12:05 < btcdrak> ack
12:05 < wumpus> well I'm very happy we finally managed to release 0.13.0, congrats everyone!
12:05 < paveljanik> Do we have any numbers of 0.13.0 nodes?
12:05 < cfields_> topic suggestion: codesigning update
12:05 < paveljanik> congrats to wumpus!
12:06  * jonasschnelli is checking the 0.13 nodes on his seeder
12:06 < instagibbs> paveljanik, few hundred ones bitnodes has reached
12:06 < btcdrak> beer for wumpus
12:06 < sipa> wumpus: congrats to all, and thanks a lot wumpus 
12:06 < wumpus> #topic proposals for segwit DoS protection
12:06 < gmaxwell> Some of this is more general than segwit. There as some existing minor vulnerablities that have been ignored, which were pointed out in segwit form. Good to resolve those too.
12:06 < luke-jr> paveljanik: http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
12:06 < murch> paveljanik: 322 (according to bitnodes)
12:06 < gmaxwell> Congrats on 0.13. It looks like a great release.
12:06 < jonasschnelli> cat dnsseed.dump | grep "0.13.0" | grep "    1   " | wc -l               ---> 62
12:07 < sipa> so the main issue is #8279
12:07 < jonasschnelli> 213 seeds in non-good state (probably just set up)
12:07 < jonasschnelli> s/seeds/nodes
12:08 < gmaxwell> there are a lot more parties running it than accepting inbound, as typical.
12:08 < sipa> and there have been several proposed solutions, including: verify all inputs (even if the transaction is too big or below feerate), not entering failed witness txn into the reject table, making feefilter mandatory, ...
12:08 < jonasschnelli> https://github.com/bitcoin/bitcoin/issues/8279
12:08 < gmaxwell> sipa: I think all of these changes are beneficial. 
12:08 < kanzure> this is separate from the malleability confusion someone posted about the other day, ya?
12:09 < luke-jr> sipa: making feefilter mandatory, or merely always using it?
12:09 < instagibbs> kanzure, the linked github issue explains it
12:09 < sipa> luke-jr: you need to be able to rely on it, and be able to ban peers who disregard it
12:09 < gmaxwell> luke-jr: me means giving it an ack message and punting peers that violate it.
12:09 < sipa> luke-jr: as you're moving the responsibility for filtering things you won't accept to the sender
12:10 < luke-jr> ok, so <0.12 nodes wouldn't be kicked
12:10 < gmaxwell> right.
12:10 < petertodd> segwit is a good opportunity to make feefilter mandatory, given we're completely changing what nodes we connect too
12:10 < kanzure> instagibbs: for example; someone was unaware that adding witness data to a non-segwit script was consensus-invalid.  but er, your link seems more productive anyway, so nevermind.
12:11 < btcdrak> petertodd: i think that is the plan
12:11 < sipa> yes, but it seems hasty to do that along with 0.13.1
12:11 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Remote host closed the connection]
12:11 < gmaxwell> in any case, "verify all inputs" was a proposal from before segwit was even imagined.
12:12 < petertodd> sipa: sure, but 0.13.1 also "hastily" has to stop fetching stuff from non-segwit nodes
12:12 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev
12:12 < sipa> petertodd: by hasty i mean we haven't implemented/tested/... a mandatory feefilter yet
12:12 < sipa> we have tested the relay behaviour of segwit vs non-segwit peers
12:13 < gmaxwell> I believe the primary reason we didn't just make the verify all inputs change is that it was proposed before feefilter, during spam attacks, and there was a lot of rejected stuff coming from even cooperative peers. That should be resolving now.
12:13 < petertodd> sipa: but thats the thing, you can just make it mandatory if the peer is a segwit peer, and leave the current behavior the same otherwise - non-segwit peers can't send us segwit txs at all (other than ones stripped of their witnesses which is easy to detect)
12:13 < sipa> petertodd: we still need a new network message etc
12:14 < sipa> otherwise peers can just ignore your feefilter
12:14 < petertodd> sipa: maybe I'm missing something, but why do we need a new network message?
12:14 < luke-jr> sipa: I think petertodd is saying "segwit peers MUST NOT ignore feefilter"
12:14 < gmaxwell> petertodd: because the protocol is async, we don't know if the far end has recieved our feefilter request yet.
12:14 < sipa> petertodd: you don't know what the last feefilter message you sent is that your peer received
12:15 < petertodd> sipa: ah right, duh...
12:15 < gmaxwell> so you send a feefilter, remote sends an inv.. you get the data.. oops failed filter.. Was the far end bad or just too fast?
12:15 < gmaxwell> so the suggestion there is to add a feefilterack, and punt peers that should send it but don't send it 'fast enough'
12:15 < petertodd> sipa: I had it in my head that feefilter worked the other way around, and already had a new inv with fee info...
12:15 < luke-jr> are there any possible nodes where implementing feefilter would be a burden? I think we already need fee info to relay transactions anyway, right?
12:16 < gmaxwell> luke-jr: yes, thats part of the consideration.
12:16 < sipa> i expect that most of the problems are solved with just having feefilter
12:17 < sipa> and we can just do #8525 now
12:17 < luke-jr> hm, what if we change feerate's definition and want to get rid of the current algo some day?
12:17 < sipa> (don't store witness txn in the reject cache)
12:17 < gmaxwell> I think we should be able to always validate now that feefilter is in place. The only argument I recall against always validating is that that a significant fraction of all recieved txn failed the fee check. That should be much less true now.
12:17 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8525
12:18 < petertodd> sipa: that could be a problem in the future if we have peers with different non-fee-related acceptance criteria than us
12:18 < CodeShark> I kinda like the idea of an inv with fee data - slightly larger messages but no need for state
12:18 < gmaxwell> reject cache was 90% implemented for lack of a fee filter.
12:18 < sipa> gmaxwell: that would open up many attacks... i don't think those are impossible to fix, but it needs a lot of analysis
12:18 < gmaxwell> I disagree.
12:19 < sipa> i like the idea of always validating (as #8593 does), but it feels risky
12:19 < gmaxwell> An uncached UTXO lookup eclipses the validation costs on most systems by orders of magnitude.
12:19 < petertodd> gmaxwell: yeah, I don't see how an attacker who can DoS attack by sending specially crafted txs is ever stopped by the other validation rules, and yes, UTXO looking is expensive too
12:20 < CodeShark> can't we consider extreme cases?
12:20 < CodeShark> what's the maximum possible validation cost for a single transaction?
12:21 < sipa> huge... remember we can't have any feerate or size based rejection criteria beforehand
12:21 < gmaxwell> well you can have a stripped size limit.
12:21 < sipa> yes, #8593 does that
12:21 < sipa> but you can't use fee
12:22 -!- skyraider [uid41097@gateway/web/irccloud.com/x-gkpsvxhqtawpseon] has joined #bitcoin-core-dev
12:22 < sipa> or at least not actual feerate, only stripped-size-feerate
12:22 < CodeShark> I'm not sure if this is what petertodd was referring to above - but I was imagining an inv that sends not just transaction hash - it also sends fee amount and tx size
12:23 < petertodd> sipa: so, an attacker who was trying to DoS attack you would just pay enough fee, with a tx that triggered O(n^2) complexity
12:23 < petertodd> sipa: so I don't see the value of feerate in preventing DoS attack there anyway
12:23 < sipa> an attacker can now craft a very expensive valid transaction that has a feerate too low to be acceptable to you, but stripped-size-feerate high enough
12:23 < sipa> and you'll validate it, but not relay
12:24 < gmaxwell> CodeShark: improved invs are a fine thing, longer term (though we should be spending our time on reconcillation, IMO) -- but I think the focus of the discussion is on shorter term since we likely need some improvements for 0.13.
12:24 < petertodd> right, but relaying is worse! we're then attacking others, and there's still no guarantee the tx will get mined, allowing the attacker to doublespend and repeat
12:25 < sipa> petertodd: well in no case will any of this relay
12:25 < gmaxwell> An alternative jl2012 suggested to validating all was to randomly validate some percentage. This will allow you to punt a peer sending you garbage, but you only take a fraction of the cost.
12:26 < CodeShark> gmaxwell: it seems simpler to just create a new static inv structure than to have to manage session states and do feefilteracks and stuff like that
12:26 < petertodd> sipa: sure, so then why not kick peers that send us DoS attack txs? IsStandard() has been around long enough that we could get away with that
12:27 < sipa> CodeShark: i think mandatory feefilter is a better solution than adding 10 kB of data to each inv
12:27 < gmaxwell> CodeShark: not so, right now inv bandwidth is already _greater_ than transaction bandwidth. You can't really escape the need to have people not send you things you're totally disinterested in.
12:28 < CodeShark> 10kB of data?
12:28 < CodeShark> the fee is uint64 and the tx size is varint
12:28 < sipa> CodeShark: txid, wtxid, fee, feerate, stripped feerate, size, sigops, bytes hashed, ... anything else that may affect your policy
12:28 < CodeShark> ok, fair enough
12:28 < sipa> inv bandwidth is larger than tx bandwidth by a factor of 5 on my node
12:29 < luke-jr> sipa: let's make it configurable! /s
12:29 < sipa> and that's between feefilter nodes
12:30 < sipa> so... do we think jl2012's approach of validating everything (or a fraction thereof) is the way to go for 0.13.1
12:30 < sipa> ?
12:30 < CodeShark> I haven't done the math
12:30 < sipa> the code is simple at least
12:30 < sipa> CodeShark: getpeerinfo
12:30 < sipa> shows bytes per message
12:30 < gmaxwell> This is why I think we need reconciliation for any inv improvement long term.
12:31 < sipa> yes
12:31 < sipa> but the meeting time is half, let's not stray too far
12:31 < sipa> i'd like to know what we're going to do for 0.13.1
12:31 < instagibbs> sipa, your guess is as ~~good as~~ better than mine
12:31 < CodeShark> sipa: I mean, I haven't done the math for validation cost edge cases
12:31 < gmaxwell> sipa: I jl2012's sampling suggestion is a pretty good idea, coupled with not reject filtering them.
12:32 < sipa> gmaxwell: right... either fully validate, or don't store in reject
12:32 < sipa> i like
12:32 < sipa> ok, other topics?
12:32 < petertodd> I suspect we'd be better off kicking peers who send us >100KB txs
12:33 < petertodd> (rather than any kind of probabalistic thing)
12:33 < afk11> hardware signing BIP?
12:33 < sipa> there were a few other topic ideas before
12:34 < wumpus> #topic code signing
12:34 < petertodd> afk11: that's off-topic to Bitcoin Core development right now
12:34 < gmaxwell> petertodd: yes, we can do that-- and I think we should--, but I think it's not sufficient. 
12:34 < wumpus> @cfields_
12:34 < wumpus> petertodd: it's on topic for the future though
12:34 < petertodd> gmaxwell: well, I mean in combination with fully validating
12:34 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 264 seconds]
12:34 < petertodd> wumpus: sure, why I said "right now" :)
12:34 < gmaxwell> petertodd: okay. lets talk after meeting.
12:35 < cfields_> so, i just wanted to bring this up before i finish the work, in case anyone has any suggestions for improvements
12:35 < cfields_> https://github.com/theuni/osx-codesign
12:35 < cfields_> I have a working codesigner for osx from linux, so an osx machine is no longer needed for the release process
12:35 < gmaxwell> \O/
12:35 < sipa> great
12:35 < cfields_> but i'm curious to see if anyone has any suggstions for more complicated/distributed signing schemes, before just implementing it as it was before
12:35 < CodeShark> cfields_: nice
12:35 < btcdrak> cfields_ except for extracting the MacOS SDK...
12:35 < jonasschnelli> cfields_: very nice. Lots of devs are looking for something!
12:36 < jonasschnelli> like that
12:36 < wumpus> cfields_: nice work!
12:36 < sipa> cfields_: what cryptography does it use?
12:36 < cfields_> (as of now it produces valid signed binaries given very specific constraints, it just needs to be tidied up and plugged into gitian)
12:36 < luke-jr> cfields_: plugged into gitian?
12:36 < petertodd> cfields_: nice license!
12:37 < jonasschnelli> GNU AFFERO GENERAL PUBLIC LICENSE,... hell!
12:37 < gmaxwell> :)
12:37  * luke-jr agrees it's a good choice of license. ☺
12:37 < cfields_> sipa: there's no choice in that, i haven't even looked into the signature type
12:37 < gmaxwell> If it is RSA or schnorr we can secret share the key.
12:38 < cfields_> sipa: it basically collects all of the files to be embedded, creates a custom wonky structure out of them, signs, and embeds the final hash in the binary
12:38 < petertodd> jonasschnelli: I like AGPL because I'm not stinkin' commie
12:38 < cfields_> along with a mostly redundant detached xml with the same hashes
12:38 < gmaxwell> cfields_: how are you signing if you don't know how it's signing? :)
12:39 < cfields_> sorry, not my license choice. 99% of the code is borrowed from an ios tool
12:39 < jonasschnelli> I guess you need to update "sudo xcode-select --switch /Applications/Xcode-4.6.3.app"
12:39 < cfields_> gmaxwell: PKCS7_sign(), openssl does the hard work :)
12:39 < gmaxwell> nothing wrong with AGPL for a tool like this, licensing is a tool.
12:39 < jonasschnelli> Hard to download older version of Xcode
12:39 < gmaxwell> cfields_: how big is the signature? :P
12:40 < cfields_> gmaxwell: i can dump you some samples after the meeting
12:40 < gmaxwell> great, in any case, I'd like to talk about integrating multiparty signing into it. it might be easy to accomplish.
12:40 < cfields_> but back to the point: is anyone interested in coming up with a signing scheme that deviates from what we have now?
12:41 < cfields_> oh, i suppose that's why you want to know about sig type :)
12:41 < gmaxwell> Yes.
12:41 < sipa> yes.
12:41 < jonasschnelli> gmaxwell: my OSX code signing certs are RSA 2048 Bit
12:41 < michagogo> cfields_: your signer is missing a README
12:41 < petertodd> cfields_: I'm already working on codesigning as my first application for dex
12:42 < sipa> oh, let's just switch bitcoin to use prime factoring as PoW
12:42 < cfields_> same here, what i'm not sure about is how much you're allowed to change around the sig format
12:42 < cfields_> (for osx, the signing cert must be signed by apple)
12:42 < wumpus> yes, IIRC PKCS7 is simply RSA wrapped in ASN.1 mess
12:43 < cfields_> yes
12:43 < cfields_> and apple adds a weird little scripting language around 'designated requirements'
12:43 < wumpus> congrats on cracking that :)
12:43 < sipa> cfields_: well there could be several signers, and we get a cert for the combined key?
12:43 < jonasschnelli> The question is, does code-signing really increases the security of bitcoin-core...
12:44 < cfields_> so you can add other restrictions, but again, i'm not sure how much apple lets you deviate from the default
12:44 < luke-jr> jonasschnelli: imagine where common gitian builders all sign themselves and combine the sig
12:44 < gmaxwell> the straightforward way of doing threshold RSA needs a trusted dealer. but at least its multiparty after setup.
12:44 < petertodd> jonasschnelli: I suspect the code-signature-verification is what increases the security of bitcoin-core :)
12:44 < jonasschnelli> petertodd: i rather say verifing of gitian signatures...
12:44 < luke-jr> jonasschnelli: essentially we'd get the OS to verify the gitian builds in this case
12:44 < cfields_> jonasschnelli: yes and no. the code-signing itself, not really. but code-signing does allow you to force-on the osx sandbox, which is interesting for security
12:44 < jonasschnelli> OSX code signatures are from "Bitcoin Foundation"... anyone could hold the key
12:45 < sipa> i'm sure we can get a new cert
12:45 < petertodd> jonasschnelli: the gitian signatures aren't ever going to be much more secure than the code signatures
12:45 < jonasschnelli> cfields_: Yes. But thats just a restrriction from apple... 
12:45 < cfields_> jonasschnelli:  (we haven't messed with the sandboxing yet, afaik)
12:45 < jonasschnelli> and sandboxing is impossible for bitcoin core right now
12:45 < petertodd> jonasschnelli: also, lots of people don't use the gitian builds (I've never personally run one)
12:45 < gmaxwell> We can get a new cert and we should improve the maintaince of it so no one person needs to hold the key-- it's a good practice.
12:45 < kanzure> someone should make sure to watch petertodd do a gitian build in milan :)
12:45 < cfields_> jonasschnelli: ah ok, i've been meaning to look into it. if you already have, i'm very curious to hear your thoughts after the meeting
12:45 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-hfxuqdjefumevcqm] has quit [Quit: Connection closed for inactivity]
12:46 < jonasschnelli> cfields_: sure. But nice work! Linux based OSX/iOS code signing is highly appriciated by lots of devs.
12:46 < cfields_> just to reiterate though: osx-codesign is 99% ripped from a tool from Saurek. I just ported to osx and updated.
12:46 < kanzure> saurik
12:46 < cfields_> *Saurik. Thanks.
12:47 < sipa> saurik?
12:47 < cfields_> jonasschnelli: right, mostly I got tired of having to have my macbook for signing.
12:47 < kanzure> /whois saurik
12:47 < cfields_> and it limits the amount of people who can do the signing
12:47 < jonasschnelli> Indeed
12:47 < jonasschnelli> though you can run a OSX VM on a Linux machine. :)
12:47 < cfields_> heh
12:47 < jonasschnelli> (and violate apples TOC)
12:48  * luke-jr peers at his common channels with saurik
12:48 < gmaxwell> cfields_: so I think good job, continue on, and I (and sipa?) will look into threshold signing for 2048 bit RSA and see if we can't get it so that no single party holds that key.
12:48 < kanzure> sipa: he is known for various ios reverse engineering things
12:48 < CodeShark> is 4096 overkill?
12:48 < sipa> ah, cool
12:48 < cfields_> gmaxwell: perfect, thanks.
12:48 < gmaxwell> (as an aside, this could also be done with wumpus' release key)
12:48 < kanzure> sipa: (pm)
12:48 < jeremyrubin> 4096 not overkill
12:48 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
12:48 -!- cryptapus_ is now known as cryptapus_afk
12:49 < sipa> CodeShark: 3000 bits RSA is approximately equivalent with 256 bit EC
12:49 < jonasschnelli> CodeShark: 2048 gives use 118bit of security.. ECDSA 128 I guess... enought?
12:49 < gmaxwell> CodeShark: I believe we don't get to choose the parameters of this key.
12:49 < jonasschnelli> Yes. Apples does it.
12:49 < CodeShark> oh, right
12:49 < gmaxwell> Otherwise it would be 4096 bit. because duh.
12:49 < cfields_> gmaxwell: i'll try to find out if other signature types are possible.
12:49  * jonasschnelli is trying a 4096 key
12:49 < gmaxwell> (the size and performance are basically irrelevant)
12:51 < jeremyrubin> unrelated question while everyone is in meeting: having a lot of trouble getting my code to pass travis, but can pass locally on a few diff machines. If anyone has any ideas, ping me after meeting.
12:51 < jonasschnelli> To shortly come back to afk11 topic: there has been a proposal for detached signing: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013008.html
12:51 < kanzure> jeremyrubin: got the core dumps yet?
12:51 < jonasschnelli> Which would allow decoupling the keys from the wallet(system)
12:51 < jeremyrubin> kanzure: nope; i tried changing the travis script to dump them but couldn't see anything.
12:52 < kanzure> you can probably call gdb bt from inside the after_failure segment
12:52 < jonasschnelli> to end the wild-west APIs/interfaces that are currently been implemented by wallets and hardware-wallet vendors
12:52 < wumpus> I very much like the idea of standardizing detached signing
12:52 < wumpus> yes, exactly
12:52 < jonasschnelli> One of the main problems users have and will have with wallets is to keep private keys private.
12:53 < wumpus> it makes no sense to try to support detached signing in bitcoin core until there is some kind of standard, if every hw vendor is going to hook in their own code in their own way it isgoing to be a mess 
12:53 < btcdrak> jonasschnelli: well you'd hope hardware signing devices will become more commonplace
12:53 < CodeShark> they will
12:54 < instagibbs> 7 minutes, any more topics?
12:54 < CodeShark> it's not something we should hope for - it's something we should make happen
12:54 < wumpus> no doubt about that, though it's two-sided, software also needs to support them
12:54 < jonasschnelli> Yes. I proposed the URLScheme standard... even, I don't like it in the first place.. but its probably the only choice if we'd like to address all systems and platforms.
12:54 < wumpus> CodeShark: jonasschnelli is helping make it happen
12:54 < sipa> the topic is still codesigning :)
12:54 < petertodd> btcdrak: also note that in systems like Qubes, detached signing in another VM is a significant security improvement even w/o special hardware
12:54 < btcdrak> yes. detached signing is more for the bitcoin-dev ML 
12:54 < petertodd> btcdrak: Qubes does this for GPG already
12:55 < gmaxwell> jonasschnelli: I think at this point the discussion should stop and some prototypes should be tried. You've seen there is some support and some opposition, and thats fine.
12:55 < wumpus> do we still have anything to say about codesigning?
12:55 < btcdrak> petertodd: interesting
12:55 < jonasschnelli> gmaxwell: Yes. I'm working on a PoC with static data between Core and iOS.
12:55 < sipa> wumpus: i believe not, i was only casually complaining about the random switch of topic :)
12:55 < jonasschnelli> my fault. sry.
12:56 < gmaxwell> jonasschnelli: okay, even simpler-- I think we should change our standard operation to have walletpassphrase and decrypt and sign done by a seperate mlocked process.
12:56 < wumpus> petertodd: yes, it should be general enough to support that scenario as well, but I think that's handled if it works for hw signing, just expose a 'virtual' hw device
12:56 < wumpus> sipa: agreed, it's a bit of a sudden switch
12:56 < wumpus> time to end the meeting maybe
12:57 < wumpus> #endmeeting
12:57 < lightningbot> Meeting ended Thu Aug 25 19:57:10 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:57 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-25-19.02.html
12:57 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-25-19.02.txt
12:57 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-25-19.02.log.html
12:57 < murch> sipa: average UTXO set size did turn out to be a very valuable evaluation criteria by the way.
12:57 < jonasschnelli> gmaxwell: I think it should be split into two applications
12:57 < sipa> murch: cool
12:57 < gmaxwell> jonasschnelli: How so?
12:58 < jonasschnelli> wallet does only hold pubkeys,... it can retrieve new keys or signatures over the sign:// URL scheme
12:58 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 276 seconds]
12:58 < jonasschnelli> sign://getkeys?amount=10
12:58 < jonasschnelli> sign://sign?type=bitcointx&somedata=xyz
12:58 < CodeShark> wallet stuff really needs to be a separate project - bitcoin-core-dev should focus on consensus and p2p stuff :p
12:58 < gmaxwell> CodeShark: I disagree.
12:58 -!- achow101 [~achow101@206.196.187.154] has quit [Ping timeout: 265 seconds]
12:59 < jonasschnelli> If we scale and all uses that jump on the nicely scaled bitcoin bus and use webbased or heavy centarlized insecure walltes... we can stop focus on consensus and p2p
12:59 < jonasschnelli> *users
12:59 < gmaxwell> jonasschnelli: now thats batching things into having 'multiple wallet' data stores.
13:00 < jonasschnelli> No really. Just separating private-key from the wallet
13:00 < jonasschnelli> *keys
13:00 < gmaxwell> you mean seperating the wallet from the wallet.
13:00 < CodeShark> the thing that needs to be separated is the signer
13:00 < jonasschnelli> No.. the wallet is much more then the private-keys... 
13:00 < CodeShark> along with all private key data
13:00 < jonasschnelli> private-keys do only sign data... 90% is wallet logic.
13:00 < CodeShark> and the signing request protocol can be defined abstractly
13:01 < gmaxwell> jonasschnelli: Yes it is, but the thing 99% of the care goes into is the keying material.
13:01 < gmaxwell> jonasschnelli: in any case, all I am suggesting there is that the wallet be able to store a blob on behalf of the signer, and be able to return that blob to the signer when asking it to sign.
13:01 < CodeShark> the signing device doesn't need to store history and perhaps only very little state
13:01 < sipa> CodeShark: i think jonasschnelli is well aware of that
13:02 < CodeShark> I was replying to gmaxwell's "separate the wallet from the wallet" comment
13:02 < jonasschnelli> CodeShark: yes. It just needs the data that needed to verify the data-to-sign
13:02 < gmaxwell> jonasschnelli: and then my example of having a seperate interface to collect the passphrase and sign, works fine-- the signer would ask the wallet to store its encrypted key data.  Then the signer needs no filesystem access.
13:02 < jonasschnelli> If you sign a PDF, you need the PDF along with the sha256(PDF)
13:02 < gmaxwell> (for that case)
13:03 < jonasschnelli> gmaxwell: what would be in the blob stored on behalf of the signer?
13:03 < jonasschnelli> Some king of authentication?
13:03 < sipa> jonasschnelli: encrypted keys in gmaxwell's examplr
13:03 < jonasschnelli> kind
13:04 < sipa> jonasschnelli: but you shouldn't care about what it is
13:04 < gmaxwell> jonasschnelli: in the case of the detatched signer which I think we should use in the GUI by default, it would be the encrypted master key. But bitcoin-core wouldn't really know or care what it is.
13:04 < michagogo> If anyone here has an iOS device and hasn't heard yet: update to iOS 9.3.5 ASAP.
13:04 < da2ce7> gmaxwell: I agree making the Hardware wallet storage-less other than securely holding a decryption key is a very attractive route.
13:04 < michagogo> A trio of critical security holes was just patched. And in the meantime stay away from untrusted links.
13:05 < CodeShark> the requestor sends a blob + metadata, signer displays metadata to user and asks for authorization, user authorizes, signer returns signed blob
13:05 < sipa> da2ce7: i think you misunderstand
13:05 < sipa> da2ce7: an actual hardware wallet would have its own state, of course
13:05 < gmaxwell> or maybe it wouldn't that would be up to its design.
13:05 < CodeShark> the interface could even provide for abstract sighash type
13:06 < jonasschnelli> sipa, gmaxwell: thanks... need to think about it. need to go afk.
13:06 < sipa> da2ce7: gmaxwell is just suggesting that if thr protocol allows the signer to ask the wallet to store data, it could replace our current wallet encryption scheme as well, by moving the signing part to a separare process
13:11 < kanzure> is the hardware wallet BIP thread the right place to pimp "libconsensus in HSM" stuff?
13:11 < gmaxwell> NO
13:11 < gmaxwell> actually I think that thread should be dropped for now.
13:12 < gmaxwell> I think too many speculative things are going for "BIP" now, this isn't really what the bip process is intended for. BIPs shouldn't be for speculative ideas. They should be so that implementations are documented and can interoperate.
13:12 < gmaxwell> There are many discussions that are being phrased as "lets have a BIP about X"  when they should be "I think it would be useful for me to do X"
13:13 < gmaxwell> only after establishing that X is something that people might want to actually do, should it move onto "now we should have a standard for doing X"
13:14 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
13:15 < gmaxwell> talking about it in the context of standards first seems to be having bad effects where people oppose ideas seemingly because they don't want to implement more things.
13:16 < MarcoFalke> jeremyrubin: You need to solve the merge conflict for travis to pick it up
13:16 < MarcoFalke> I will try to reproduce locally
13:17 < jeremyrubin> MarcoFalke: ah; will do. It's picked up on my fork 
13:17 < jeremyrubin> https://travis-ci.org/JeremyRubin/bitcoin/builds/154016406
13:17 < MarcoFalke> ok
13:18 < jeremyrubin> I just added something to print out the test-suite.log after_failure
13:18 < jeremyrubin> so that's the newer build
13:22 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 244 seconds]
13:35 < jonasschnelli> gmaxwell: the hardware wallet signing thing is not really a BIP now. It's just something to think about I have sent to the ML...
13:36 < jonasschnelli> But I think a BIP would be the right think for a hardware wallet interface standard..
13:36 < jonasschnelli> *Thing
13:37 < sipa> sure, eventually
13:41  * jonasschnelli sometimes thinks that a wallet with privet-keys is like a home door with the key under the doormat
13:44 < instagibbs> jonasschnelli, you can start a SIP ;)
13:44  * instagibbs ducks
13:45 < gmaxwell> jonasschnelli: that is going a bit far, ultimately if your computere is totally compromised you probably can't use bitcoin correctly no matter having a hardware wallet or offline signing or what not.. at most you can slow the bleeding.
13:46 < gmaxwell> because your compromised computer will substitute any addresses you attempt to pay to.
13:46 < gmaxwell> and it will tell you that you've been paid, when you haven't been.
13:46 < jeremyrubin> MarcoFalke: I rebased onto master fyi so you'll want to -D your local if you pulled it
13:46 < jonasschnelli> Yeah. Agree. But...
13:47 < jonasschnelli> A hardware wallet or let say, a detached signer (assume a smartphone) can verify the data(tx) independently.
13:47 < jonasschnelli> Even if you computer is totally compromised, your signer would reveal that.
13:47 < sipa> jonasschnelli: how does the hw device verify it's sending to the right address
13:48 < sipa> it can show you, sure
13:48 < jonasschnelli> It would show it on a display?
13:48 < sipa> but how do you know the right address if your computer is hacked?
13:48 < jonasschnelli> Fees are a bit tricky
13:49 < jonasschnelli> That right... Your browser window where the address listed could be already compromised.
13:49 < jonasschnelli> In the world of "addresses", we have to assume it has been transmitted untempered
13:50 < gmaxwell> jonasschnelli: thats what I mean, if your computer is compromised it doesn't really matter what it displays, at least right now.
13:50 < jonasschnelli> At least the signer can identify if a receiving address is owned by the signer and also if a change address is
13:51 < jonasschnelli> But you might scan in a QRcode address...
13:53 < jonasschnelli> The receiving part can be made relatively secure. But I agree, the pay-to part - in case the pay-to addresses origin for you is your computer - cannot be made much more more secure through a signing device.
13:54 < gmaxwell> and similarly, there are two ways you can be robbed, by sending where you don't intend, or by thinking you were paid when you weren't. Existing hardware wallets do nothing about the latter.
13:54 < jonasschnelli> Malware targeting only you wallet software would be identified. A clever forged multi-app attack not.
13:55 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
13:55 -!- aalex_ is now known as aalex
13:55 < MarcoFalke> jeremyrubin: This also fails locally on my 14.04vm
13:55 < MarcoFalke> Might be easier to debug
13:56 < jonasschnelli> gmaxwell: how can the later be exploited? You mean by displaying an attackers address instead of the owner ones?
13:56 < jeremyrubin> MarcoFalke: Awesome; maybe it's a virtualization thing 
13:57 < jeremyrubin> Are you just using a vanilla 14.04?
13:58 < gmaxwell> the latter is that the attacker 'pays you' but never authors a transaction and your compromised host displays the transaction as confirmed.
13:58 < MarcoFalke> jup, I don't recall any specifics I changed
14:00 < jonasschnelli> Ah. I see. Yes. Hard to detect on the host even with a signing device... You would need access to a trusted offline in-sync air gapped node :-)
14:01 < gmaxwell> well it's not really that wild, you'd just need your wallet to hand all the payments to the hardware wallet with spv proofs and then it could display your balance and lists of transactions.
14:02 < gmaxwell> so at least that could be done.
14:02 < jeremyrubin> cool -- do you see anything interesting in the dump? (spinning one up now)
14:03 < gmaxwell> but the address substituion attacks don't have as easy a fix.. you need a PKI and send signed payment requests to the wallet. ;(
14:15 < luke-jr> instagibbs: SIPs are for altcoin stuffs ;)
14:39 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev []
14:44 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
14:54 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
14:55 -!- Megaf [~quassel@unaffiliated/megaf] has joined #bitcoin-core-dev
15:13 -!- Megaf [~quassel@unaffiliated/megaf] has quit [Ping timeout: 276 seconds]
15:28 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev
15:28 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host]
15:28 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev
15:29 -!- cryptapus is now known as cryptapus_afk
15:32 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-pxidrdkgwlygfpum] has joined #bitcoin-core-dev
15:34 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
15:36 -!- murch [~murch@p4FE3896C.dip0.t-ipconnect.de] has quit [Quit: Leaving.]
15:42 -!- paracyst [paracyst@unaffiliated/paracyst] has joined #bitcoin-core-dev
15:51 -!- JackH [~Jack@79-73-189-132.dynamic.dsl.as9105.com] has quit [Ping timeout: 244 seconds]
16:03 < btcdrak> cfields_: I have successfully extracted the MacOS SDK from Xcode DMG directly linux :)
16:06 < luke-jr> btcdrak: how?
16:06 < btcdrak> black magic :)
16:07 < btcdrak> luke-jr: cfields: https://gist.github.com/btcdrak/6e67c84ed8375c9a9d506c2038622fc4
16:12 -!- skyraider [uid41097@gateway/web/irccloud.com/x-gkpsvxhqtawpseon] has quit [Quit: Connection closed for inactivity]
16:13 < GreenIsMyPepper> ooo that's awesome ^_^
16:18 < btcdrak> GreenIsMyPepper: I think I have been cheated! the archive size doesnt match sigh
16:18 < luke-jr> ☺
16:18 < luke-jr> btcdrak: the files are all empty
16:19 < btcdrak> =) oh well
16:23 -!- achow101 [~achow101@206.196.187.154] has joined #bitcoin-core-dev
16:23 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: Leaving.]
16:23 < cfields_> btcdrak: woohoo!
16:23 < cfields_> oh, heh
16:23 < btcdrak> cfields: :/
16:24 < cfields_> yes, hfsmount hasn't been touched in ages afaik
16:24 < cfields_> iirc there are files missing too
16:25 < btcdrak> I assume the extraction of the partition by 7z is fine, just the hfsmount is incompatible?
16:26 < gmaxwell> so I have a suggestion. We have the data, right? uncompress the download, and the take as side information a list of offsets to extract bytes from.
16:26 < gmaxwell> We can have side information as part of the process.
16:29 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev
16:50 -!- Cheeseo [~x@unaffiliated/cheeseo] has quit [Ping timeout: 264 seconds]
16:53 < GitHub34> [bitcoin] gmaxwell opened pull request #8594: Do not add random inbound peers to addrman. (master...no_inbound_addr) https://github.com/bitcoin/bitcoin/pull/8594
16:54 -!- Cheeseo [~x@unaffiliated/cheeseo] has joined #bitcoin-core-dev
17:20 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has quit [Ping timeout: 250 seconds]
17:32 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
17:32 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Ping timeout: 276 seconds]
17:33 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has joined #bitcoin-core-dev
17:47 < phantomcircuit> luke-jr, im looking at the wallet accounting tests (which afaict you wrote)
17:47 < phantomcircuit> im confused by things like vpwtx[0]->nTimeReceived = (unsigned int)1333333335;
17:48 < phantomcircuit> it seems like the unit test is mucking around with the internals of the wallet?
17:51 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: zzzZzzzZzZZZzzzzZZZZzzzzZ]
17:52 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds]
17:53 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
17:57 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has joined #bitcoin-core-dev
18:08 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev
18:21 -!- achow101 [~achow101@206.196.187.154] has quit [Ping timeout: 240 seconds]
18:25 < GitHub143> [bitcoin] rebroad opened pull request #8595: [Wallet] Ensure <0.13 clients can't open HD wallets (master...2016/07/hd_minversion) https://github.com/bitcoin/bitcoin/pull/8595
18:28 < luke-jr> phantomcircuit: could be
18:39 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has quit [Ping timeout: 244 seconds]
18:48 -!- sanada` [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev
18:50 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-ncvmplahvpivbtoo] has quit [Quit: Connection closed for inactivity]
18:50 -!- sanada [~bitktn@36-2-119-80.chiba.ap.gmo-isp.jp] has quit [Ping timeout: 265 seconds]
18:51 -!- pmienk [~pmienk@c-71-227-177-179.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
18:54 < kanzure> 16:54 < saurik> so, I just spent a bunch of time making certain I didn't miss anything via IRC, and I've also checked e-mail. were they intending to tell me anything? I am kind of in shock that of all projects, bitcoin, another open source project, is now continuing the pattern of "we found something mysterious that we fixed that we don't bother mentioning directly to upstream"
18:54 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has left #bitcoin-core-dev ["Verlassend"]
18:54 < kanzure> 18:53 < kanzure> saurik: bitcoin core just a bunch of people hanging out on irc doing stuff. so i pinged you about it.
18:54 < kanzure> i mean.. i don't expect how else to inform upstream other than sending messages :P.
18:55 < gmaxwell> mindrays.
18:56 < kanzure> shh don't tell them about my mind rays
18:57 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds]
18:57 < midnightmagic> i thought they were my mindrays
18:57 < midnightmagic> D-:
18:58 < Squidicuz> woah.. full frontal lobotomy button, and now mindrays?!
18:59 -!- achow101 [~achow101@206.196.187.154] has joined #bitcoin-core-dev
19:02 < midnightmagic> we are.. groot?
19:05 < phantomcircuit> kanzure, what's he even talking about?
19:05 < kanzure> don't speak so ill of the lobotomy</nobel prize committee>
19:05 < kanzure> (actually i'm joking. no idea why that got the nobel prize.)
19:05 < kanzure> phantomcircuit: osx code signing O_o
19:06 < phantomcircuit> kanzure, you see you should have connected to his personal irc server
19:06 < kanzure> actually you're right, there really is an irc.saurik.com
19:07 < midnightmagic> :-o
19:12 < luke-jr> kanzure: a pull request? :P
19:13 < cfields_> kanzure: i fully intended to upstream it
19:13 < cfields_> kanzure: what channel? I'll ping him to discuss
19:16 < midnightmagic> I dunno if he really knows what it means to invite rando bitcoiners in to his IRC. :(
19:19 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
19:19 < dcousens> is there any way to turn off pretty-printing in the bitcoind RPC JSON?
19:19 -!- Giszmo [~leo@pc-40-227-45-190.cm.vtr.net] has quit [Quit: Leaving.]
19:19 < kanzure> cfields_: pm
19:20 < cfields_> thanks
19:20 < kanzure> cfields_: btw i don't think it's urgent; i just found his response funny :).
19:21 < cfields_> kanzure: sure, i'd just like him to understand that I planned to PR it, but it's just a bunch of hard-coded hacks still
19:23 < phantomcircuit> dcousens, ?
19:25 < GitHub198> [bitcoin] rebroad opened pull request #8596: Feeler code and debugging. (master...FeelerFixes) https://github.com/bitcoin/bitcoin/pull/8596
19:31 < dcousens> phantomcircuit: nevermind, its just bitcoin-cli being smart :)
19:52 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-jnkbbhdolsveerjx] has joined #bitcoin-core-dev
19:56 -!- ryan-c [~ryan@znc.rya.nc] has quit [Ping timeout: 265 seconds]
19:57 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Ping timeout: 244 seconds]
19:59 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
20:01 -!- Netsplit *.net <-> *.split quits: fengling, [Author]
20:05 -!- ryan-c [~ryan@znc.rya.nc] has joined #bitcoin-core-dev
20:06 -!- [Author] [~Author]@2401:a400:3202:2000:bad:d09:15:90d] has joined #bitcoin-core-dev
20:06 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
20:10 < phantomcircuit> dcousens, yeah i think univalue always produces a single line
20:10 < dcousens> phantomcircuit: yup, my bad, went into tcpdump and yeah its not pretty printed over the wire which is all I cared about
20:11 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer]
20:11 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
20:17 < phantomcircuit> dcousens, as someone who is very guilty of this
20:17 < phantomcircuit> i usually fine that if something looks dumb it is not
20:18 < phantomcircuit> except when it is
20:19 < dcousens> phantomcircuit: haha, yup.  I need to put the rubber duck back on my desk,  it usually gets most of my stupid questions before I branch out haha
20:35 -!- tom3 [~tom@unaffiliated/tommc] has quit [Ping timeout: 244 seconds]
20:36 < phantomcircuit> luke-jr, indeed i think the unit tests are broken
20:36 < phantomcircuit> or rather are testing the behaviour too specifically
20:37 < luke-jr> "too specifically" is often subjective. ☺
20:38 -!- moli [~molly@unaffiliated/molly] has quit [Read error: Connection reset by peer]
20:39 < gmaxwell> not really, ideally a test fails when the software is broken and only fails in those cases, passes when the software is not broken and only passes in those cases.
20:40 < gmaxwell> this is an objective standard you can judge a test against, even if its not usually achievable for most functions.
20:43 < gmaxwell> it can be useful, at times, to have test functions which define 'broken' as 'changes in any way at all'; but thats special and not usually a good requirement for tests; especially for functions which you intend to actually change.
20:53 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
20:54 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
20:55 < phantomcircuit> luke-jr, can you explain why it's testing wtx nTimeReceived ?
20:57 < luke-jr> gmaxwell: IMO there's a grey area smart times fall into. you don't care about the exact behaviour or even exact results per se, but you probably do need to test for exact results to know the results are sane.
20:58 < luke-jr> phantomcircuit: what file/module is this?
20:59 < gmaxwell> luke-jr: if you can't define "sane" better than "same as before" -- can anyone really know if the code is right or not? :P
20:59 < phantomcircuit> luke-jr, src/wallet/test/accounting_tests.cpp
20:59 < gmaxwell> (and could it ever be updated?)
21:00 < gmaxwell> I don't think it's necessarily bad to have tests that do nothing but tell you if something changed, but if thats all we have, then we don't really have tests that are useful for anything except maybe refactoring.
21:00 < luke-jr> gmaxwell: for example, some payment protocol could possibly provide better time estimate to a user that was offline at the time
21:00 < gmaxwell> Consider, you intentionally change a function.  Exact behavior tests fail, well "no shit"-- but was your change correct or not? the 'test' gives you no insight-- it just told you something you already knew.
21:02 < luke-jr> phantomcircuit: it's testing that nTimeReceived either does or doesn't influence the sorting order as it should[n't]
21:03 < luke-jr> gmaxwell: in this case, it's creating CWalletTxs, adding them to the wallet, and checking the sort comes out correct
21:04 < luke-jr> (I was wrong thinking it was doing smart fee stuff; it's sort order)
21:10 -!- moli [~molly@unaffiliated/molly] has joined #bitcoin-core-dev
21:14 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
21:17 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
21:17 < phantomcircuit> luke-jr, is there something that describes how the smart time stuff works?
21:20 < luke-jr> phantomcircuit: not besides the code, AFAIK. essentially when a new transaction is seen, it uses the earlier of the block time or received/current time, unless that's before the time of the most recent known transaction (within reason)
21:20 < luke-jr> if the most recent known transaction is newer, it won't go backward
21:20 < luke-jr> unless it's significantly earlier, IIRC 15 minutes or so
21:20 -!- achow101 [~achow101@206.196.187.154] has quit [Quit: Leaving]
21:39 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
21:48 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
21:54 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
21:55 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
21:56 < phantomcircuit> luke-jr, so you're simulating the blocktime?
22:20 -!- Alopex [~bitcoin@cyber.dealing.ninja] has quit [Remote host closed the connection]
22:21 -!- Alopex [~bitcoin@cyber.dealing.ninja] has joined #bitcoin-core-dev
22:22 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
22:29 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Quit: Lost terminal]
22:54 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
22:56 -!- harrymm [~wayne@171.5.179.111] has quit [Ping timeout: 244 seconds]
23:04 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
23:12 -!- harrymm [~wayne@223.205.78.144] has joined #bitcoin-core-dev
23:19 -!- mturquette [sid66043@gateway/web/irccloud.com/x-aiuzpvewgkfemxkg] has quit [Ping timeout: 264 seconds]
23:19 -!- mturquette [sid66043@gateway/web/irccloud.com/x-virsyitqvkndwsxt] has joined #bitcoin-core-dev
23:21 -!- crescendo [~mozart@unaffiliated/crescendo] has quit [Ping timeout: 264 seconds]
23:21 -!- crescendo [~mozart@unaffiliated/crescendo] has joined #bitcoin-core-dev
23:26 -!- harrymm [~wayne@223.205.78.144] has quit [Ping timeout: 240 seconds]
23:30 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-jnkbbhdolsveerjx] has quit [Quit: Connection closed for inactivity]
23:31 < jonasschnelli> gmaxwell: Though about the idea of the BLOB (encrypted key) stored in the wallet and passed to the signer. Do you propose that signing operations will be done in a separate process (or application) by handing over the required tx data and the encrypted private key?
23:32 < gmaxwell> Yes. And the signer program has you confirm the transaction, enter the passphrase, returns the result.
23:32 < gmaxwell> and it can have 100% mlocked memory, be highly sandboxed, etc.
23:33 < jonasschnelli> How do the encrypted private keys get there in the first place?
23:33 < gmaxwell> It generates them and gives the blob to the wallet, like you were thinking with 'getnewaddress'... but there would be an 'init' or 'initwallet' call.
23:35 < jonasschnelli> So the signing device creates the encrypted keys,... what the reason of passing them to the wallet instead of keeping track (storing) them in the signers space?
23:35 < jonasschnelli> *whats
23:35 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
23:35 < jonasschnelli> Ah. mlocked mem
23:35 < gmaxwell> because then you have two files to backup for you wallet, and now the signer needs filesystem access.
23:36 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds]
23:37 < jonasschnelli> gmaxwell: Yes. I think this would be a nice add-on. Would be nice if the transport layer would be flexible enough to also support hardware wallets.
23:37 < jonasschnelli> Hardware wallet will probably not export encrypted private keys.
23:37 < jonasschnelli> So the "blob" could be optional.
23:37 < gmaxwell> Yes. Also third party co-signers... or at least extended to that eventually.
23:38 < gmaxwell> yes, it would be optional, but-- I dunno, perhaps a reasonable way to construct a low cost hardware wallet-- why give it any flash? all rom. :)
23:38 < jonasschnelli> IMO the main problem with co-signing is the missing infrastructure for the communication layer, how to pass partial-signed transaction to the co-signer, etc.
23:38 < jonasschnelli> The problem with the blob storing encrypted keys is the backward and forward-security IMO
23:39 < jonasschnelli> A leaked encryption password will result in compromising everything
23:40 < GitHub61> [bitcoin] rebroad opened pull request #8597: [WIP] Move code from VERACK to VERSION (since VERACK is not requied) (master...NotDependentOnVerack) https://github.com/bitcoin/bitcoin/pull/8597
23:40 < jonasschnelli> I'd personally prefer only keeping pub-keys in my wallet and sign on a different system where the priv-keys are not exposed to many I/Os
23:40 -!- harrymm [~wayne@171.5.186.30] has joined #bitcoin-core-dev
23:55 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev
23:56 < luke-jr> phantomcircuit: I'm not sure - do smart fees even have tests?
23:56 < luke-jr> smart times*
23:56 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev