1 2016-08-25T00:00:16  *** harrymm has joined #bitcoin-core-dev
   2 2016-08-25T00:00:49  *** justanotheruser has joined #bitcoin-core-dev
   3 2016-08-25T00:04:14  *** pedrobranco has quit IRC
   4 2016-08-25T00:04:46  *** pedrobranco has joined #bitcoin-core-dev
   5 2016-08-25T00:08:56  *** pedrobranco has quit IRC
   6 2016-08-25T00:26:46  *** achow101 has quit IRC
   7 2016-08-25T00:40:22  *** btcdrak has quit IRC
   8 2016-08-25T00:44:58  *** harrymm has quit IRC
   9 2016-08-25T00:45:15  *** harrymm has joined #bitcoin-core-dev
  10 2016-08-25T00:53:45  *** PRab has quit IRC
  11 2016-08-25T01:00:06  *** fengling has quit IRC
  12 2016-08-25T01:12:35  *** PRab has joined #bitcoin-core-dev
  13 2016-08-25T01:19:16  *** fengling has joined #bitcoin-core-dev
  14 2016-08-25T01:44:24  *** Giszmo has quit IRC
  15 2016-08-25T01:44:40  *** justanotheruser has quit IRC
  16 2016-08-25T01:45:10  *** justanotheruser has joined #bitcoin-core-dev
  17 2016-08-25T01:57:06  *** fengling has quit IRC
  18 2016-08-25T02:05:53  *** Ylbam has quit IRC
  19 2016-08-25T02:13:06  *** slackircbridge has quit IRC
  20 2016-08-25T02:13:23  *** slackircbridge has joined #bitcoin-core-dev
  21 2016-08-25T02:23:12  *** Chris_Stewart_5 has quit IRC
  22 2016-08-25T02:24:41  <GitHub109> [bitcoin] rebroad opened pull request #8583: Show XTHIN in GUI (master...ShowXTHINinGUI) https://github.com/bitcoin/bitcoin/pull/8583
  23 2016-08-25T02:34:24  *** tom3 has joined #bitcoin-core-dev
  24 2016-08-25T02:36:11  *** Alopex has quit IRC
  25 2016-08-25T02:36:13  *** achow101 has joined #bitcoin-core-dev
  26 2016-08-25T02:37:16  *** Alopex has joined #bitcoin-core-dev
  27 2016-08-25T02:37:46  <achow101> There appears to be a problem with verifying the email that wladimir sent for announcing the release key. See https://bitcointalk.org/index.php?topic=1596294.msg16030908#msg16030908
  28 2016-08-25T02:39:50  <phantomcircuit> indeed the signature is bad when you copy/paste from the website thing
  29 2016-08-25T02:40:20  <phantomcircuit> the actual email is correct though
  30 2016-08-25T02:40:26  *** Samdney has left #bitcoin-core-dev
  31 2016-08-25T03:08:22  *** Alopex has quit IRC
  32 2016-08-25T03:09:27  *** Alopex has joined #bitcoin-core-dev
  33 2016-08-25T03:27:47  *** fengling has joined #bitcoin-core-dev
  34 2016-08-25T03:30:13  *** btcdrak has joined #bitcoin-core-dev
  35 2016-08-25T03:30:51  *** harrymm has quit IRC
  36 2016-08-25T03:46:43  *** harrymm has joined #bitcoin-core-dev
  37 2016-08-25T03:59:27  *** achow101 has quit IRC
  38 2016-08-25T04:08:02  <GitHub124> [bitcoin] pstratem opened pull request #8585: Remove last caller of IncOrderPosNext (master...2016-08-24-cwallet-incorderposnext) https://github.com/bitcoin/bitcoin/pull/8585
  39 2016-08-25T04:08:31  *** tom3 has quit IRC
  40 2016-08-25T04:09:48  *** LeMiner has quit IRC
  41 2016-08-25T04:10:34  *** LeMiner has joined #bitcoin-core-dev
  42 2016-08-25T04:14:16  <phantomcircuit> can someone cancel all those travis jobs
  43 2016-08-25T04:14:18  <phantomcircuit> sipa: ^
  44 2016-08-25T04:33:06  *** Alopex has quit IRC
  45 2016-08-25T04:34:12  *** Alopex has joined #bitcoin-core-dev
  46 2016-08-25T04:39:09  <jl2012> wumpus: please do not include any email address within a PGP signed message. The signature is invalid because the "@" is replaced by "at": https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/009045.html
  47 2016-08-25T04:40:16  <jl2012> achow101, phantomcircuit: s/ at /@/  and you will have a good signature
  48 2016-08-25T04:45:40  *** kadoban has quit IRC
  49 2016-08-25T05:10:01  *** Alopex has quit IRC
  50 2016-08-25T05:11:06  *** Alopex has joined #bitcoin-core-dev
  51 2016-08-25T05:15:46  *** fengling has quit IRC
  52 2016-08-25T05:48:58  *** fengling has joined #bitcoin-core-dev
  53 2016-08-25T05:50:32  <luke-jr> sigh, can't we just flip a switch so the ML sw doesn't edit it? :/
  54 2016-08-25T05:55:22  <kanzure> perhaps that's a "feature" enforced by linuxfoundation (which also doesn't make sense-- are they not signing email?)
  55 2016-08-25T05:59:01  <wumpus> I don't think I'm gonig to send asignedmessage with release announcement again, too many snags
  56 2016-08-25T05:59:43  <wumpus> the annouunce mailing list mutillated initial spaces converted to non-breaking spaces, \# converted to #
  57 2016-08-25T05:59:58  <wumpus> the -dev mailing list malformed the message in digest mode (which can't be disabled)
  58 2016-08-25T06:00:10  <wumpus> and now @'s are verboten too?
  59 2016-08-25T06:00:13  <wumpus> meh :-)
  60 2016-08-25T06:02:32  <wumpus> as if using GPG itsels isn't enough of a monster to get right (what, your key is only 2048 bits!)
  61 2016-08-25T06:03:42  <wumpus> sending a link to a .asc on a server may work
  62 2016-08-25T06:05:14  * wumpus first creates a gpg  release mail signing key of 65537 bits
  63 2016-08-25T06:05:26  <wumpus> or maybe a bunch of sed scripts with transformations before validation
  64 2016-08-25T06:06:39  <paveljanik> I think we should abandon GPG and Bitcoin sign everything...
  65 2016-08-25T06:06:55  <wumpus> if only it was all GPG's fault
  66 2016-08-25T06:07:06  <paveljanik> and mailing lists ;-) Of course :-)
  67 2016-08-25T06:07:10  <wumpus> hehe
  68 2016-08-25T06:07:18  <paveljanik> sending announcements via OP_RETURN 8)
  69 2016-08-25T06:07:35  <paveljanik> think a bit of it...
  70 2016-08-25T06:08:05  * luke-jr glares.
  71 2016-08-25T06:08:50  <Lightsword> we could just upload the release itself using OP_RETURN’s :P
  72 2016-08-25T06:09:03  * Lightsword hides
  73 2016-08-25T06:09:28  <wumpus> in any case the release announcement doesn't need to be signed, people should verify the SHA256SUMS.asc tha tcomes *wth* the rekease
  74 2016-08-25T06:09:50  <wumpus> I tend to sign important mails to the mailing list, but this just created a diversion
  75 2016-08-25T06:10:36  <wumpus> verifying the release email itself does nothing, it provides no security, the binaries *at* the link may still be tampered with
  76 2016-08-25T06:11:25  <luke-jr> hm, that's a good point. this doesn't just screw up release mail, it screws up even when we want to sign discussion messages
  77 2016-08-25T06:15:40  <wumpus> would be nice if the archive had a 'RAW' button like github
  78 2016-08-25T06:15:55  <wumpus> that gives you the original text of the message, to paste into gpg
  79 2016-08-25T06:16:39  <wumpus> then again, the anti-@ 'feature' mentioned by jl2012 is probably against spam, so I doubht they'll disable that transformation. They may disable all others though.
  80 2016-08-25T06:18:17  <jl2012> or you may just use an attachment
  81 2016-08-25T06:21:11  <wumpus> put the text in an attachment? fullsigning the mail and putting the signature in the attachment would work worse because any footers added will invalidate it too
  82 2016-08-25T06:26:45  <gmaxwell> wumpus: just send the whole thing ascii armored.
  83 2016-08-25T06:27:05  <wumpus> gmaxwell: that'd work!
  84 2016-08-25T06:27:34  <wumpus> can't find any problems with that, it's what ASCII armoring is supposed to protect against. I guess it will generate no @, no # and doesn't depend on spaces
  85 2016-08-25T06:28:15  <wumpus> people without GPG can't read it anymore, but who cares, they don't take security seriously so shouldn't be using bitcoin in the first place right :)
  86 2016-08-25T06:31:46  * wumpus still remembers uuencode
  87 2016-08-25T06:34:46  <wumpus> GPG base64 characters are A-Za-z0-9+/=
  88 2016-08-25T06:42:59  *** BashCo has quit IRC
  89 2016-08-25T06:44:54  *** Squidicc has joined #bitcoin-core-dev
  90 2016-08-25T06:48:31  *** Squidicuz has quit IRC
  91 2016-08-25T06:57:39  *** jannes has joined #bitcoin-core-dev
  92 2016-08-25T07:11:06  *** Alopex has quit IRC
  93 2016-08-25T07:12:11  *** Alopex has joined #bitcoin-core-dev
  94 2016-08-25T07:14:24  *** BashCo has joined #bitcoin-core-dev
  95 2016-08-25T07:21:21  *** Ylbam has joined #bitcoin-core-dev
  96 2016-08-25T07:23:15  *** BashCo_ has joined #bitcoin-core-dev
  97 2016-08-25T07:25:52  *** rubensayshi has joined #bitcoin-core-dev
  98 2016-08-25T07:26:58  *** BashCo has quit IRC
  99 2016-08-25T07:34:01  *** Alopex has quit IRC
 100 2016-08-25T07:35:07  *** Alopex has joined #bitcoin-core-dev
 101 2016-08-25T07:42:32  <wumpus> does anyone happen to have the digest mail from bitcoin-dev or core-dev containing the 0.13.0 announcement?
 102 2016-08-25T07:42:52  <wumpus> I'd like to see how the text is mangled there
 103 2016-08-25T07:48:16  <gmaxwell> "okay, so, if we write our release notes in pig latin and make sure any numbers we use are prime..."
 104 2016-08-25T07:49:40  <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
 105 2016-08-25T07:50:05  <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. :)
 106 2016-08-25T07:50:34  <wumpus> cfields_: sorry for needing another non-trivial rebase for #8085, after the next one you should harry me until it is merged
 107 2016-08-25T07:50:53  <sipa> "Your password needs to contain at least an uppercase character, a digit, punctuation, a hieroglyph, and an extinct mammal"
 108 2016-08-25T07:51:03  <wumpus> yes, that
 109 2016-08-25T07:51:15  <gmaxwell> sipa: is there a configuration for gentropy for that?
 110 2016-08-25T07:51:35  <sipa> gmaxwell: not yet :)
 111 2016-08-25T07:51:57  <sipa> yes, the network refactors should be priority now
 112 2016-08-25T07:52:03  <gmaxwell> where is the gentropy webpage again?
 113 2016-08-25T07:52:13  <sipa> can we also merge feeler connections?
 114 2016-08-25T07:52:21  <gmaxwell> feeler++
 115 2016-08-25T07:52:39  <sipa> gmaxwell: https://github.com/sipa/gentropy/tree/master/gramtropy
 116 2016-08-25T07:52:42  <gmaxwell> feelers should be considered for backport
 117 2016-08-25T07:52:57  <gmaxwell> sipa: I mean the enscriptem version
 118 2016-08-25T07:53:16  <sipa> ah, http://wps.sipa.be/gramtropy/gramtropy.html
 119 2016-08-25T07:53:24  <gmaxwell> (the backport comment, because of the problems we see in testnet with it taking a while to find many witness peers.)
 120 2016-08-25T07:54:05  <wumpus> jl2012: huh, there isn't even a @ in the release notes
 121 2016-08-25T07:54:06  <sipa> feeler is #8282
 122 2016-08-25T07:54:25  <gmaxwell> his shale kales fail thus nails fail yet ailments bewail but derailing bales assail
 123 2016-08-25T07:55:10  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8282
 124 2016-08-25T07:56:55  <GitHub188> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/f2306fbe01426ce11c4df6a5c1b837106bc2c702
 125 2016-08-25T07:56:55  <GitHub188> bitcoin/0.13 f2306fb Wladimir J. van der Laan: doc: Clean out release notes after 0.13.0 release
 126 2016-08-25T07:59:38  <paveljanik> and Wshadow changes please...
 127 2016-08-25T08:00:12  <GitHub120> [bitcoin] rebroad opened pull request #8587: Provide bloom services to whitelisted nodes. (master...WhitelistedBloom) https://github.com/bitcoin/bitcoin/pull/8587
 128 2016-08-25T08:01:38  <wumpus> yes looking at #8282 now
 129 2016-08-25T08:05:52  <gmaxwell> :-/ more overloading of whitelisted.
 130 2016-08-25T08:06:46  <sipa> soon we'll need a separate confog file describing various peer's services
 131 2016-08-25T08:06:50  <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
 132 2016-08-25T08:07:11  <sipa> with its own turing-complete configuration language, of course
 133 2016-08-25T08:07:32  <wumpus> subnet 1.2.3.x { flags allow-bloom allow-hyperspace-travel ...  }
 134 2016-08-25T08:07:35  <wumpus> yes, exactly
 135 2016-08-25T08:07:55  <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)
 136 2016-08-25T08:08:39  <wumpus> yeah..
 137 2016-08-25T08:08:56  <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
 138 2016-08-25T08:09:26  <wumpus> and proper documentation too
 139 2016-08-25T08:09:36  <gmaxwell> well, also the authentication bip thing is perhaps a better way to hand out access to varrious things.
 140 2016-08-25T08:10:32  <wumpus> I suppose there's use cases for allowing based on IP ranges as well as authentication
 141 2016-08-25T08:11:06  <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.
 142 2016-08-25T08:11:19  <wumpus> yes, completely agreed, that was my point
 143 2016-08-25T08:12:06  <wumpus> rebroad is always like 'I need this, so I'll push this change, I don't care about others'
 144 2016-08-25T08:12:19  <wumpus> ego-commits
 145 2016-08-25T08:13:01  <gmaxwell> (Also, AFAIK there isn't even a reason to turn off bloom filter support generally...)
 146 2016-08-25T08:13:27  <sipa> i don't think he needs whitefiltering or bloom filters at all
 147 2016-08-25T08:14:05  <wumpus> disabling bloom filters reduces CPU and I/O load of a running node
 148 2016-08-25T08:14:20  <gmaxwell> I just mean at the moment there are no active attacks going on.
 149 2016-08-25T08:14:25  <gmaxwell> at least none that I'm seeing.
 150 2016-08-25T08:14:41  <wumpus> sure, but its true even without attacks, though in a lesser amount ofc
 151 2016-08-25T08:14:58  <gmaxwell> Yes. It's true.
 152 2016-08-25T08:15:55  <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.
 153 2016-08-25T08:16:51  <sipa> the original idea behind whitelisting was to use it on an edge router, which your internal network nkdes connect to
 154 2016-08-25T08:16:55  <wumpus> yes, it makes sense to allow bloom filtering support selectively, no argument there
 155 2016-08-25T08:17:08  <wumpus> just overloading whitelisting for everything, bleh
 156 2016-08-25T08:17:13  <sipa> and it needed special configuration so that rebroadcasts would propagate
 157 2016-08-25T08:17:35  <wumpus> but it'd make sense to document what whitelisting is actually for
 158 2016-08-25T08:17:44  <wumpus> to prevent people extending it for what they think it is for
 159 2016-08-25T08:18:25  <wumpus> yes, that was the original idea
 160 2016-08-25T08:18:34  <sipa> agree
 161 2016-08-25T08:18:43  <sipa> it is unclear what the goal os at this point
 162 2016-08-25T08:19:22  <sipa> maybe peer authentication + mempool reconciliation are a good replacement in the future
 163 2016-08-25T08:21:40  <wumpus> yes
 164 2016-08-25T08:22:00  <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)
 165 2016-08-25T08:22:11  <gmaxwell> and it got addressed with a more general tool.
 166 2016-08-25T08:23:00  <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.
 167 2016-08-25T08:23:48  <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
 168 2016-08-25T08:24:03  <wumpus> it should be more granular
 169 2016-08-25T08:24:25  <wumpus> I wouldn't like rebroad to implement that though...
 170 2016-08-25T08:25:22  <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.
 171 2016-08-25T08:25:57  <wumpus> er between versions, not between functions
 172 2016-08-25T08:26:22  <wumpus> yes, it's always a challenge, it's clear where we don't want to go, not where we do want to go
 173 2016-08-25T08:27:36  <wumpus> trying to make general tools is a useful goal but only works with a clear view of what the use cases are
 174 2016-08-25T08:28:27  <wumpus> and that should be the beginning of the design not follow from it
 175 2016-08-25T08:28:47  <wumpus> the edge-router case is a clear one, for example
 176 2016-08-25T08:29:52  <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
 177 2016-08-25T08:30:14  <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. :)
 178 2016-08-25T08:30:25  <wumpus> but these are completely different things and shouldn't be moved under one option
 179 2016-08-25T08:31:43  <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
 180 2016-08-25T08:31:43  <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.
 181 2016-08-25T08:31:46  <wumpus> the thing is, 'whitebind'/'whitelist' *look* like something that would cover both cases. You allow internal connections with more privileges
 182 2016-08-25T08:31:48  <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.
 183 2016-08-25T08:32:19  <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
 184 2016-08-25T08:32:42  <wumpus> (e.g., instead of specific options with slightly different syntax)
 185 2016-08-25T08:33:29  <wumpus> btcdrak: yes
 186 2016-08-25T08:34:48  <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
 187 2016-08-25T08:35:45  <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
 188 2016-08-25T08:38:18  <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
 189 2016-08-25T08:38:49  <wumpus> 'bitcoind is not a firewall tool!'
 190 2016-08-25T08:39:21  <gmaxwell> I think the authentication will make it more justifyable in fact... just because there will be more cases to use it.
 191 2016-08-25T08:39:25  <wumpus> maybe we could allow specifying a BPF filter *ducks*
 192 2016-08-25T08:39:57  <gmaxwell> wumpus: bitcoin script
 193 2016-08-25T08:39:58  <wumpus> right, with authentication you virtually *need* a system like that
 194 2016-08-25T08:49:11  <GitHub189> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/62a5a8a01866...026c6edac947
 195 2016-08-25T08:49:11  <GitHub189> bitcoin/master dbb1f64 Ethan Heilman: Added feeler connections increasing good addrs in the tried table....
 196 2016-08-25T08:49:12  <GitHub189> bitcoin/master 026c6ed Wladimir J. van der Laan: Merge #8282: net: Feeler connections to increase online addrs in the tried table....
 197 2016-08-25T08:49:16  <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
 198 2016-08-25T08:49:46  <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
 199 2016-08-25T08:50:20  *** mn3monic_ is now known as mn3monic
 200 2016-08-25T08:50:35  *** mn3monic has joined #bitcoin-core-dev
 201 2016-08-25T08:54:05  <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.
 202 2016-08-25T08:55:32  <sipa> right
 203 2016-08-25T09:01:00  <GitHub185> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/026c6edac947...95a983d56dbd
 204 2016-08-25T09:01:00  <GitHub185> bitcoin/master fa1cf9e MarcoFalke: [test] Remove unused code
 205 2016-08-25T09:01:01  <GitHub185> bitcoin/master 95a983d MarcoFalke: Merge #8578: [test] Remove unused code...
 206 2016-08-25T09:01:10  <GitHub76> [bitcoin] MarcoFalke closed pull request #8578: [test] Remove unused code (master...Mf1608-qaUnused) https://github.com/bitcoin/bitcoin/pull/8578
 207 2016-08-25T09:15:28  <luke-jr> https://github.com/bitcoin/bitcoin/issues/8586 should probably be reopened.
 208 2016-08-25T09:16:00  *** hybridsole has quit IRC
 209 2016-08-25T09:16:33  *** hybridsole has joined #bitcoin-core-dev
 210 2016-08-25T09:20:48  <wumpus> luke-jr: are you going to troubleshoot/fix it?
 211 2016-08-25T09:20:55  <wumpus> if so, I don't mind reopening it
 212 2016-08-25T09:21:58  <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
 213 2016-08-25T09:22:26  <wumpus> I wonder how long this has been broken and gone unnoticed, not being able to switch tabs is quite serious
 214 2016-08-25T09:22:39  <btcdrak> is there any point in continuing with Qt4?
 215 2016-08-25T09:22:45  * luke-jr takes a look at the problem before deciding.
 216 2016-08-25T09:22:48  <sipa> arguabl, #8586 is still an issue, as we advertize support for Qt4.
 217 2016-08-25T09:22:50  <wumpus> btcdrak: see https://github.com/bitcoin/bitcoin/issues/8263
 218 2016-08-25T09:23:02  <luke-jr> btcdrak: it's currently the only way to get native look/feel on KDE 4
 219 2016-08-25T09:23:04  <sipa> the solution may be discontinuing qt4, but that's still a cjangr
 220 2016-08-25T09:23:15  <sipa> *changr
 221 2016-08-25T09:23:18  <wumpus> I personally don't want to spend one minute of my time hndling qt4 issues, at least
 222 2016-08-25T09:23:18  <sipa> *change
 223 2016-08-25T09:23:55  <jonasschnelli> Yes. Neither do I.
 224 2016-08-25T09:24:08  <wumpus> #8263 was *assuming* things were working on qt4
 225 2016-08-25T09:24:22  <MarcoFalke> What is the advantage of having a native look/feel if you know that the application is untested and potentially buggy?
 226 2016-08-25T09:24:22  <wumpus> if they aren't, and people didn't even notice, well that's clear enough
 227 2016-08-25T09:25:12  <luke-jr> wumpus: well, it's only day 2(?) and people are reporting bugs
 228 2016-08-25T09:25:26  <jonasschnelli> I think we should not keep Qt4 compatibility only because of KDE 4
 229 2016-08-25T09:25:28  * luke-jr is happy there's been no problems with C++11 though
 230 2016-08-25T09:25:30  <wumpus> MarcoFalke: tend to agree
 231 2016-08-25T09:26:36  <MarcoFalke> luke-jr: The person reporting the bug apparently compiled against qt4 by accident
 232 2016-08-25T09:26:50  <wumpus> luke-jr: any update on when KDE is going to fix this situation?
 233 2016-08-25T09:27:21  <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 :/
 234 2016-08-25T09:27:27  <da2ce7> sipa: creative/good work on #8580, I don't feel qualified to ACK, however enjoyed reading the PR.
 235 2016-08-25T09:27:29  <wumpus> MarcoFalke: I don't understand how that can happen
 236 2016-08-25T09:27:33  * luke-jr checks KDE release dates
 237 2016-08-25T09:27:39  <MarcoFalke> wumpus: Forget to install qt5?
 238 2016-08-25T09:27:47  <wumpus> we choose qt5 by default now
 239 2016-08-25T09:27:49  <wumpus> oh, maybe that
 240 2016-08-25T09:28:04  <wumpus> luke-jr: well okay that is as close to an admission that this will never happen
 241 2016-08-25T09:28:14  <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
 242 2016-08-25T09:28:14  <luke-jr> looks like it took 2 years for KDE 4 to stabilise
 243 2016-08-25T09:29:05  <sipa> s/receiver/callee/
 244 2016-08-25T09:29:09  <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.
 245 2016-08-25T09:29:34  <luke-jr> if it's trivial, I'll just fix it; otherwise, fine with removing it
 246 2016-08-25T09:30:16  <sipa> luke-jr: well, one question is why haven't we noticed yet?
 247 2016-08-25T09:30:23  <jonasschnelli> If we support Qt4, someone needs to test and fix at least the RCs.
 248 2016-08-25T09:30:27  <sipa> seems you are using Qt4, but didn't notice this issue either?
 249 2016-08-25T09:30:32  <luke-jr> sipa: no devs use Qt4? :P
 250 2016-08-25T09:30:48  <luke-jr> I've been building against Qt5 for a while
 251 2016-08-25T09:30:52  <wumpus> jonasschnelli: yes, we need someone to step up to support it then, if no one is willing, then advertising qt4 support is wrong
 252 2016-08-25T09:31:01  <jonasschnelli> Agree
 253 2016-08-25T09:31:06  <luke-jr> I can probably switch back, it's no big difference to me
 254 2016-08-25T09:32:04  <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.
 255 2016-08-25T09:32:10  <wumpus> sipa: interesting
 256 2016-08-25T09:32:29  <wumpus> sipa: yes I haven't really formed a conception around them either yet, more than 'maagic!'
 257 2016-08-25T09:32:31  <jonasschnelli> Qt4 != Qt4
 258 2016-08-25T09:32:43  <luke-jr> I can't reproduce the problem. :/
 259 2016-08-25T09:33:09  <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.
 260 2016-08-25T09:33:24  <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)
 261 2016-08-25T09:33:52  <luke-jr> everything seems to work with Qt4 for me
 262 2016-08-25T09:34:03  <wumpus> da2ce7: yes that could work (although the mailing list was already complaining about me sending a 40kb mail...)
 263 2016-08-25T09:34:29  <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
 264 2016-08-25T09:34:54  <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
 265 2016-08-25T09:34:55  <sipa> and if you want to pass x along to something else without copying, you need to use std::move
 266 2016-08-25T09:35:53  <sipa> wumpus: rvalue references are huge complication to the language, but they really feel like addressing a very deep problem
 267 2016-08-25T09:36:50  <luke-jr> wumpus: I wonder if a non-clean build dir (old bitcoin-config.h?) might also cause this
 268 2016-08-25T09:36:53  <wumpus> sipa: it does add a lot of complication to an already extremely complicated language, but yes I think overall it's worth it
 269 2016-08-25T09:37:11  <wumpus> sipa: it does allow for doing some things much more efficient in a cleaner way
 270 2016-08-25T09:37:34  <sipa> yes, it always felt non-C++-ish to me that there were many cases in which you couldn't cleanly avoiding copying
 271 2016-08-25T09:37:57  <sipa> C++-ish here meaning that you should always have the option to avoid unnecessary code execution
 272 2016-08-25T09:37:58  <wumpus> yes you had to use some really ugly hacks to avoid copying, if possible at all
 273 2016-08-25T09:38:22  <wumpus> (like adding a dummy element and swapping, etc)
 274 2016-08-25T09:39:05  <luke-jr> wumpus: I bet he had to `make clean` for Qt5, but didn't the first time around..
 275 2016-08-25T09:39:06  <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
 276 2016-08-25T09:39:07  <btcdrak> It's pretty clear supporting Qt4 and doing QA for releases is going to be like pulling teeth.
 277 2016-08-25T09:39:55  <jonasschnelli> A Qt4-semi-disabling-step would be to disable the auto-detection
 278 2016-08-25T09:40:02  <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?
 279 2016-08-25T09:40:04  <luke-jr> btcdrak: it seems to just work for now
 280 2016-08-25T09:40:16  <jonasschnelli> If someone really wants to compile against qt4, we could keep --with-gui=qt4 but disable the autodetect
 281 2016-08-25T09:40:27  <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
 282 2016-08-25T09:40:29  <sipa> wumpus: it simply casts a reference to an rvalue reference
 283 2016-08-25T09:40:37  <sipa> nope, you can implement it yourself
 284 2016-08-25T09:40:44  <wumpus> sipa: oh, that's all
 285 2016-08-25T09:40:50  <luke-jr> jonasschnelli: that sounds reasonable; maybe a message to make noises if they want Qt4 support to stay?
 286 2016-08-25T09:40:59  <sipa> std::forward is more magic, but still does not require any internals
 287 2016-08-25T09:41:06  <jonasschnelli> luke-jr: Yes. Okay... lets try that.
 288 2016-08-25T09:41:59  <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
 289 2016-08-25T09:42:32  <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
 290 2016-08-25T09:43:16  <wumpus> ah the 'perfect forwarding' thing
 291 2016-08-25T09:43:19  <GitHub187> [bitcoin] jonasschnelli pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/95a983d56dbd...d26234a9e2fa
 292 2016-08-25T09:43:20  <GitHub187> bitcoin/master 15df3c1 Andrew Chow: Persist the datadir after option reset...
 293 2016-08-25T09:43:20  <GitHub187> bitcoin/master 57acb82 Andrew Chow: Load choose datadir dialog after options reset
 294 2016-08-25T09:43:20  <GitHub187> bitcoin/master d26234a Jonas Schnelli: Merge #8487: Persist the datadir after option reset...
 295 2016-08-25T09:43:29  <GitHub68> [bitcoin] jonasschnelli closed pull request #8487: Persist the datadir after option reset (master...persist-datadir) https://github.com/bitcoin/bitcoin/pull/8487
 296 2016-08-25T09:44:06  <wumpus> it's kind of clever
 297 2016-08-25T09:44:57  <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
 298 2016-08-25T09:45:14  <wumpus> yes, makes sense
 299 2016-08-25T09:45:21  <sipa> so in that case you wouldn't want to auto destruct it on first use
 300 2016-08-25T09:45:35  <sipa> combining with substructural typing would have been nice :)
 301 2016-08-25T09:48:26  *** fengling has quit IRC
 302 2016-08-25T09:54:13  *** Ginnarr has joined #bitcoin-core-dev
 303 2016-08-25T09:55:53  *** fengling has joined #bitcoin-core-dev
 304 2016-08-25T09:57:11  *** Ginnarr has quit IRC
 305 2016-08-25T09:58:01  *** Ginnarr has joined #bitcoin-core-dev
 306 2016-08-25T09:59:32  <btcdrak> that gitian script by achow101 makes me happy
 307 2016-08-25T10:03:54  <sipa> ffs can we send rebroad to a programming class
 308 2016-08-25T10:05:24  <luke-jr> Matt's doing one in NY, right? :p
 309 2016-08-25T10:27:10  <paveljanik> rebroad looking for a ban 8)
 310 2016-08-25T10:49:52  *** moli has quit IRC
 311 2016-08-25T11:04:32  *** pedrobranco has joined #bitcoin-core-dev
 312 2016-08-25T11:05:00  *** pedrobranco has joined #bitcoin-core-dev
 313 2016-08-25T11:05:53  *** Ylbam has quit IRC
 314 2016-08-25T11:07:38  *** pedrobranco has quit IRC
 315 2016-08-25T11:08:12  *** pedrobranco has joined #bitcoin-core-dev
 316 2016-08-25T11:13:04  *** pedrobranco has quit IRC
 317 2016-08-25T11:20:11  *** Samdney has joined #bitcoin-core-dev
 318 2016-08-25T11:22:00  *** pedrobranco has joined #bitcoin-core-dev
 319 2016-08-25T11:22:44  *** pedrobranco has quit IRC
 320 2016-08-25T11:22:50  *** pedrobra_ has joined #bitcoin-core-dev
 321 2016-08-25T11:31:17  *** cryptapus has joined #bitcoin-core-dev
 322 2016-08-25T11:31:56  <GitHub152> [bitcoin] sipa opened pull request #8589: Inline CTxInWitness inside CTxIn (on top of #8580) (master...segwitinlinepain) https://github.com/bitcoin/bitcoin/pull/8589
 323 2016-08-25T11:35:50  *** Ginnarr has quit IRC
 324 2016-08-25T11:36:11  <btcdrak> sipa: does #8589 replace both #8452 and #8580?
 325 2016-08-25T11:36:53  <sipa> yes
 326 2016-08-25T11:37:18  <btcdrak> may be better to close those two?
 327 2016-08-25T11:37:52  <sipa> well i don't know whether #8451 or #8580 will be accepted
 328 2016-08-25T11:38:12  <sipa> i guess i could wait with #8589 and #8452 until that choice is made
 329 2016-08-25T11:39:15  <GitHub70> [bitcoin] sipa closed pull request #8452: Code simplification: inline CTxInWitness inside CTxIn (master...segwitinline) https://github.com/bitcoin/bitcoin/pull/8452
 330 2016-08-25T12:00:38  *** moli has joined #bitcoin-core-dev
 331 2016-08-25T12:04:49  <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
 332 2016-08-25T12:09:28  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 333 2016-08-25T12:14:42  *** Chris_Stewart_5 has quit IRC
 334 2016-08-25T12:15:01  <GitHub54> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d26234a9e2fa...9d0f43b7ca72
 335 2016-08-25T12:15:02  <GitHub54> bitcoin/master be1d451 Will Binns: contributing.md: Fix formatting...
 336 2016-08-25T12:15:03  <GitHub54> bitcoin/master 9d0f43b Pieter Wuille: Merge #8226: contributing.md: Fix formatting (line lengths and smart quotes)...
 337 2016-08-25T12:15:09  <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
 338 2016-08-25T12:17:46  *** Squidicuz has joined #bitcoin-core-dev
 339 2016-08-25T12:18:43  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 340 2016-08-25T12:19:29  *** cryptapus_ has joined #bitcoin-core-dev
 341 2016-08-25T12:19:52  *** Squidicc has quit IRC
 342 2016-08-25T12:20:17  *** cryptapus_afk has quit IRC
 343 2016-08-25T12:20:47  *** MarcoFalke has quit IRC
 344 2016-08-25T12:21:04  *** MarcoFalke has joined #bitcoin-core-dev
 345 2016-08-25T12:23:58  *** Alopex has quit IRC
 346 2016-08-25T12:24:12  *** murch has joined #bitcoin-core-dev
 347 2016-08-25T12:29:06  *** Alopex has joined #bitcoin-core-dev
 348 2016-08-25T12:36:12  *** YOU-JI has joined #bitcoin-core-dev
 349 2016-08-25T12:36:54  *** aalex_ has joined #bitcoin-core-dev
 350 2016-08-25T12:37:22  *** aalex has quit IRC
 351 2016-08-25T12:49:04  *** laurentmt has joined #bitcoin-core-dev
 352 2016-08-25T12:51:12  *** laurentmt has quit IRC
 353 2016-08-25T12:54:07  *** laurentmt has joined #bitcoin-core-dev
 354 2016-08-25T12:55:29  *** laurentmt has quit IRC
 355 2016-08-25T12:55:44  <GitHub179> [bitcoin] jonasschnelli pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/9d0f43b7ca72...0606f95b1ea8
 356 2016-08-25T12:55:44  <GitHub179> bitcoin/master 2f32c82 Jonas Schnelli: [Qt] show network/chain errors in the GUI
 357 2016-08-25T12:55:45  <GitHub179> bitcoin/master 0606f95 Jonas Schnelli: Merge #7579: [Qt] show network/chain errors in the GUI...
 358 2016-08-25T12:55:49  <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
 359 2016-08-25T13:06:09  <GitHub83> [bitcoin] MarcoFalke opened pull request #8590: Remove unused variables (master...Mf1608-unusedCode) https://github.com/bitcoin/bitcoin/pull/8590
 360 2016-08-25T13:11:31  <jonasschnelli> Travis failed on master: https://travis-ci.org/bitcoin/bitcoin/jobs/155043866#L2347
 361 2016-08-25T13:11:34  <jonasschnelli> compactblock test
 362 2016-08-25T13:15:36  <GitHub69> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/0606f95b1ea8...53f8f226bd1d
 363 2016-08-25T13:15:36  <GitHub69> bitcoin/master f13c1ba Michael Rotarius: Move AdvertiseLocal debug output to net category
 364 2016-08-25T13:15:37  <GitHub69> bitcoin/master 53f8f22 Pieter Wuille: Merge #8462: Move AdvertiseLocal debug output to net category...
 365 2016-08-25T13:15:49  <GitHub172> [bitcoin] sipa closed pull request #8462: Move AdvertiseLocal debug output to net category (master...advertiselocal) https://github.com/bitcoin/bitcoin/pull/8462
 366 2016-08-25T13:16:30  <sipa> jonasschnelli: ugh
 367 2016-08-25T13:16:50  <jonasschnelli> probably a random error...
 368 2016-08-25T13:16:54  <jonasschnelli> (one of these)
 369 2016-08-25T13:17:03  <sipa> i'm restarting
 370 2016-08-25T13:17:17  <jonasschnelli> ok
 371 2016-08-25T13:29:29  *** tom3 has joined #bitcoin-core-dev
 372 2016-08-25T13:35:51  *** Giszmo has joined #bitcoin-core-dev
 373 2016-08-25T13:49:19  *** kadoban has joined #bitcoin-core-dev
 374 2016-08-25T13:49:20  <GitHub181> [bitcoin] rebroad opened pull request #8591: Do not relay or mine excessive sighash transactions (master...NoExcessiveSighashTxs) https://github.com/bitcoin/bitcoin/pull/8591
 375 2016-08-25T13:50:03  *** isis has quit IRC
 376 2016-08-25T13:59:28  *** BashCo has joined #bitcoin-core-dev
 377 2016-08-25T14:01:50  *** BashCo_ has quit IRC
 378 2016-08-25T14:07:20  *** dirtynewshoes has quit IRC
 379 2016-08-25T14:08:12  *** Chris_Stewart_5 has quit IRC
 380 2016-08-25T14:09:20  <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
 381 2016-08-25T14:11:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 382 2016-08-25T14:14:52  *** tom3 has quit IRC
 383 2016-08-25T14:25:26  *** tom3 has joined #bitcoin-core-dev
 384 2016-08-25T14:27:00  *** pedrobra_ has quit IRC
 385 2016-08-25T14:27:14  *** pedrobranco has joined #bitcoin-core-dev
 386 2016-08-25T14:30:28  *** Chris_Stewart_5 has quit IRC
 387 2016-08-25T14:31:13  *** Samdney has quit IRC
 388 2016-08-25T14:34:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 389 2016-08-25T14:38:29  *** pedrobranco has quit IRC
 390 2016-08-25T14:44:46  *** YOU-JI has quit IRC
 391 2016-08-25T14:48:05  <GitHub76> [bitcoin] sipa closed pull request #8591: Do not relay or mine excessive sighash transactions (master...NoExcessiveSighashTxs) https://github.com/bitcoin/bitcoin/pull/8591
 392 2016-08-25T14:52:27  *** Ylbam has joined #bitcoin-core-dev
 393 2016-08-25T14:56:33  <GitHub80> [bitcoin] hejunbok opened pull request #8592: 0.13 (master...0.13) https://github.com/bitcoin/bitcoin/pull/8592
 394 2016-08-25T14:57:25  <GitHub7> [bitcoin] hejunbok closed pull request #8592: 0.13 (master...0.13) https://github.com/bitcoin/bitcoin/pull/8592
 395 2016-08-25T15:00:28  *** Megaf has joined #bitcoin-core-dev
 396 2016-08-25T15:00:43  *** arubi has quit IRC
 397 2016-08-25T15:03:52  *** rubensayshi has quit IRC
 398 2016-08-25T15:26:41  *** Chris_Stewart_5 has quit IRC
 399 2016-08-25T15:38:02  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 400 2016-08-25T15:43:54  *** Megaf has quit IRC
 401 2016-08-25T15:44:31  *** Samdney has joined #bitcoin-core-dev
 402 2016-08-25T15:47:16  *** Chris_Stewart_5 has quit IRC
 403 2016-08-25T15:48:01  <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
 404 2016-08-25T16:03:04  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 405 2016-08-25T16:50:33  *** BashCo has quit IRC
 406 2016-08-25T16:59:48  *** BashCo has joined #bitcoin-core-dev
 407 2016-08-25T17:24:34  <luke-jr> MarcoFalke: https://github.com/bitcoin/bitcoin/pull/6996 my rebase already has the tests taken care of too..
 408 2016-08-25T17:24:48  *** Chris_Stewart_5 has quit IRC
 409 2016-08-25T17:25:07  <MarcoFalke> Nice, then ask sipa to force push :)
 410 2016-08-25T17:25:37  <luke-jr> implicitly did 16 days ago :p
 411 2016-08-25T17:26:37  <sipa> luke-jr: how does it deal with invalidateblock?
 412 2016-08-25T17:26:58  <sipa> you could return later to something with a lower chainwork
 413 2016-08-25T17:27:38  <luke-jr> sipa: dunno, I would assume like any other invalid block declared precious? O.o
 414 2016-08-25T17:27:59  <sipa> i guess it's such an edge case it doesn't matter
 415 2016-08-25T17:28:34  <luke-jr> doesn't preciousblock just give a small bias toward the block in question, in best-chainwork selection?
 416 2016-08-25T17:30:33  <sipa> yes
 417 2016-08-25T17:30:48  <sipa> right, i guess it doesn't matter even
 418 2016-08-25T17:31:06  <sipa> thanks, i'll update the branch
 419 2016-08-25T17:32:29  <Lauda> Is the credit list @release of a version updated frequently/automatically/manually?
 420 2016-08-25T17:34:46  <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
 421 2016-08-25T17:34:52  *** BashCo has quit IRC
 422 2016-08-25T17:35:16  *** BashCo has joined #bitcoin-core-dev
 423 2016-08-25T17:35:36  <Lauda> Yes, that list. Thanks for the information.
 424 2016-08-25T17:38:01  <sipa> well it's not automatically updated at all... it is compiled by wumpus at release time
 425 2016-08-25T17:38:13  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 426 2016-08-25T17:39: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.
 427 2016-08-25T17:40:06  <sipa> commits
 428 2016-08-25T17:41:38  <Lauda> One has to have a merged commit to be on that list?
 429 2016-08-25T17:41:45  <luke-jr> Lauda: git shortlog v0.12.1..v0.13.0 | perl -nle 'm/^(\S.*)\s\(.*$/ && print $1' | sort
 430 2016-08-25T17:42:06  <MarcoFalke> Is the script wumpus uses public?
 431 2016-08-25T17:42:37  <sipa> Lauda: yes
 432 2016-08-25T17:42:51  <sipa> that's the necessary and sufficient condition
 433 2016-08-25T17:43:01  <MarcoFalke> In some corner cases it does misattribution.
 434 2016-08-25T17:43:10  <MarcoFalke> E.g. I open a pull but I am not author of the commits
 435 2016-08-25T17:43:17  <Lauda> I think it did, sec.
 436 2016-08-25T17:43:38  <MarcoFalke> I reported this once so it might be fixed by now
 437 2016-08-25T17:43:52  <wumpus> for the credits list I prefer erring on the safe side, e.g. including more than necessary instead of less
 438 2016-08-25T17:44:02  <wumpus> MarcoFalke: any specific ones?
 439 2016-08-25T17:44:15  <MarcoFalke> This was in 0.12.x
 440 2016-08-25T17:44:18  <MarcoFalke> already fixed
 441 2016-08-25T17:44:22  * luke-jr ponders what wumpus's LC_COLLATE is
 442 2016-08-25T17:44:49  <wumpus> that script simply looks who submitted the pull, so if you submitted someone elses' pulls then that needs to be manually corrected
 443 2016-08-25T17:45:01  <wumpus> it's pretty dumb and I end up doing a lot of work myself
 444 2016-08-25T17:45:05  <MarcoFalke> I wonder if the script could be included in the repo.
 445 2016-08-25T17:45:15  <MarcoFalke> Maybe people will help you maintain it
 446 2016-08-25T17:45:17  <wumpus> you should look over the list and correct things that aren't correct
 447 2016-08-25T17:45:19  <wumpus> oh no way, it's crap
 448 2016-08-25T17:45:28  <MarcoFalke> ha, I guessed it
 449 2016-08-25T17:45:33  <MarcoFalke> :)
 450 2016-08-25T17:45:52  <MarcoFalke> I wouldn't want to share my scripts ...
 451 2016-08-25T17:46:02  <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
 452 2016-08-25T17:46:15  <Lauda> Just.. :p
 453 2016-08-25T17:46:35  <wumpus> maybe at some point I get to cleaning it up for release, but I only tend to touch it for releases
 454 2016-08-25T17:46:51  <luke-jr> Lauda: you should see my scripts for merging translation files.. :P
 455 2016-08-25T17:47:13  *** MarcoFalke has quit IRC
 456 2016-08-25T17:48:11  *** MarcoFalke has joined #bitcoin-core-dev
 457 2016-08-25T17:48:13  <Lauda> It must be 'nice' looking :)
 458 2016-08-25T17:48:32  *** kadoban has quit IRC
 459 2016-08-25T17:49:02  <wumpus> luke-jr: I don't even know what LC_COLLATE does
 460 2016-08-25T17:49:10  <wumpus> let alone having changed it manually :)
 461 2016-08-25T17:49:31  *** kadoban has joined #bitcoin-core-dev
 462 2016-08-25T17:49:40  <wumpus> it's not even defined in my env
 463 2016-08-25T17:49:53  <Lauda> https://www.postgresql.org/docs/8.4/static/sql-createdatabase.html
 464 2016-08-25T17:50:15  <wumpus> postgresql?
 465 2016-08-25T17:50:18  <sipa> sort order
 466 2016-08-25T17:50:24  <Lauda> It has the flag explanation
 467 2016-08-25T17:50:29  <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.
 468 2016-08-25T17:50:33  <luke-jr> wumpus: your sort program does a different order than mine :p
 469 2016-08-25T17:50:42  <wumpus> my sort program probably sucks...
 470 2016-08-25T17:50:54  <luke-jr> wumpus: run `locale` and check the output
 471 2016-08-25T17:51:28  <wumpus> LC_COLLATE="en_US.UTF-8"
 472 2016-08-25T17:51:39  <luke-jr> hmm
 473 2016-08-25T17:51:49  <wumpus> maybe I should set it to Chinese
 474 2016-08-25T17:51:57  <wumpus> or Russian
 475 2016-08-25T17:51:59  <sipa> wumpus: do you use sleepsort?
 476 2016-08-25T17:52:26  <luke-jr> wumpus: German was a closer approximation in my trial-and-error experience
 477 2016-08-25T17:52:38  <wumpus> sipa: yes, the parallelism, it's awesome!
 478 2016-08-25T17:52:51  <luke-jr> de_DE.utf8 got me the same order for the linguas files.. until 0.13.0
 479 2016-08-25T17:53:14  <wumpus> I don't know what I should feel about people trying to reverse my environment variable settings :)
 480 2016-08-25T17:53:19  <luke-jr> lol
 481 2016-08-25T17:53:41  <Lauda> haha
 482 2016-08-25T17:54:32  *** kadoban has quit IRC
 483 2016-08-25T17:54:45  <luke-jr> it's what happens when doc/translation_process.md results in a resorting ;p
 484 2016-08-25T17:55:35  *** kadoban has joined #bitcoin-core-dev
 485 2016-08-25T17:55:36  <wumpus> python has locale independent sorting AFAIK, but yes, the list-authors script is a shell script
 486 2016-08-25T17:55:46  <wumpus> and itindeed calls the sort utility
 487 2016-08-25T17:56:05  <wumpus> so, so far you're right
 488 2016-08-25T17:56:59  <wumpus> it's curious how all those utilities leak information
 489 2016-08-25T18:05:24  <wumpus> luke-jr: good idea on using --use-mailmap, I was doing a manual processing step for that
 490 2016-08-25T18:06:57  <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
 491 2016-08-25T18:07:23  <btcdrak> afk11: which step?
 492 2016-08-25T18:07:41  <afk11> wget anything..
 493 2016-08-25T18:08:23  <Lightsword> is it hitting a captcha page?
 494 2016-08-25T18:08:27  <afk11> osslsigncode-Backports-to-1.7.1.patch loaded from cfields directory on bitcoincore.org in this case.
 495 2016-08-25T18:08:33  <afk11> Lightsword, yep
 496 2016-08-25T18:08:42  <wumpus> I don't think that's correct
 497 2016-08-25T18:08:50  <luke-jr> hm, I thought there was a different subdomain for downloads
 498 2016-08-25T18:09:01  <Lightsword> yeah…that’s their ddos detection getting triggered, btcdrak maybe you can lower the sensitivity
 499 2016-08-25T18:09:15  <wumpus> you can download from https://dev.bitcoincore.org/cfields/osslsigncode-Backports-to-1.7.1.patch
 500 2016-08-25T18:09:30  <wumpus> that's where it redirects, and that one's not behind cloudflare
 501 2016-08-25T18:10:28  <Lightsword> wumpus, dev.bitcoincore.org is showing behind cloudflare for me
 502 2016-08-25T18:10:46  <afk11> I'll PR that link instead
 503 2016-08-25T18:10:48  <afk11> oh
 504 2016-08-25T18:10:51  <wumpus> ok, i didn't use to be, I give up
 505 2016-08-25T18:11:34  <wumpus> maybe someone else can host the file somewhere else and give a fallback url...
 506 2016-08-25T18:11:49  *** kadoban has quit IRC
 507 2016-08-25T18:12:08  <Lightsword> there should be a way to whitelist urls in cloudflare to turn off the ddos protection
 508 2016-08-25T18:12:20  <Lightsword> although not sure if that’s available in the free plan
 509 2016-08-25T18:12:26  <wumpus> dev. shouldn't be behind cloudflare in the first place
 510 2016-08-25T18:12:46  *** kadoban has joined #bitcoin-core-dev
 511 2016-08-25T18:13:01  <luke-jr> http://luke.dashjr.org/tmp/code/osslsigncode-Backports-to-1.7.1.patch
 512 2016-08-25T18:13:04  <wumpus> it's really eating the internet, isn't it cloudflare
 513 2016-08-25T18:13:12  <wumpus> thanks luke-jr
 514 2016-08-25T18:14:17  <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?
 515 2016-08-25T18:14:45  <wumpus> btcdrak: any idea what is happening there?
 516 2016-08-25T18:15:07  <sipa> gmaxwell: ethan explained that in a comment
 517 2016-08-25T18:16:46  <gmaxwell> ah, I see it. that should have ended up as a comment in the code.
 518 2016-08-25T18:17:37  <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.
 519 2016-08-25T18:18:01  <afk11> thanks luke-jr!
 520 2016-08-25T18:18:34  <btcdrak> wumpus: this is why I wanted to change fallback URL remember.
 521 2016-08-25T18:18:49  <btcdrak> afk11: are you running behind Tor?
 522 2016-08-25T18:18:53  <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.
 523 2016-08-25T18:19:15  <gmaxwell> rather than having the eviction directly trigger a connection.
 524 2016-08-25T18:19:38  <btcdrak> afk11: it tends to happen on tor exits. settings are on minimal which basically flags Tor exit nodes.
 525 2016-08-25T18:21:13  <sipa> gmaxwell: i don't think i ever reviewed test before evict
 526 2016-08-25T18:21:23  <wumpus> btcdrak: but how did dev.bitcoincore.org end up behind cloudflare?
 527 2016-08-25T18:21:52  <gmaxwell> sipa: ha, I was asking you because you had a bunch of outdated comments on the PR.
 528 2016-08-25T18:22:38  <wumpus> I'm surprised that doesn't interacts wth the OSX SDK download which checks based on source IP
 529 2016-08-25T18:23:38  <sipa> gmaxwell: test-before-evict or feeler?
 530 2016-08-25T18:24:47  <gmaxwell> oh oh sorry. I was commenting on the comments in feeler about test before evict.
 531 2016-08-25T18:25:25  <afk11> btcdrak, yeah, it's using tor. might be better to host it elsewhere, people do this on servers after all
 532 2016-08-25T18:27:39  <wumpus> I'd hope that patch gets merged in upstream at some point so we don't need it anymore at all
 533 2016-08-25T18:27:41  <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
 534 2016-08-25T18:27:42  <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).
 535 2016-08-25T18:28:12  <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
 536 2016-08-25T18:28:16  <wumpus> btcdrak: I know bitcoincore.org is on cloudflare and that we've set up the redirects on bitcoincore.org
 537 2016-08-25T18:28:29  <wumpus> btcdrak: what I don't understand is why dev.bitcoincore.org is behind cloudflare
 538 2016-08-25T18:28:57  <btcdrak> it has to be to get the SSL.
 539 2016-08-25T18:29:12  <wumpus> dev.bitconcore.org has no SSL of itself? okay
 540 2016-08-25T18:29:21  <wumpus> yes, I probably forgot
 541 2016-08-25T18:29:22  <btcdrak> unless you want to buy a certificate. but it doesnt matter, the gitian thing would fail for afk11 anyway because of the redirect
 542 2016-08-25T18:29:34  <wumpus> well we could easily change that link
 543 2016-08-25T18:29:35  <Lightsword> btcdrak, just use letsencrypt for SSL on dev
 544 2016-08-25T18:29:39  <afk11> btcdrak, in this case, it's a qube over tor!
 545 2016-08-25T18:29:39  <luke-jr> …
 546 2016-08-25T18:30:00  <luke-jr> so you're saying people connect to CloudFlare over SSL, and then it connects to the real server unencrypted?
 547 2016-08-25T18:30:03  <luke-jr> wtf is the point
 548 2016-08-25T18:30:11  <btcdrak> letencrypt only issues certs for 3 months.
 549 2016-08-25T18:30:21  <Lightsword> btcdrak, letsencrypt has autorenew...
 550 2016-08-25T18:30:22  <btcdrak> luke-jr: no, the server is SSL
 551 2016-08-25T18:30:28  <afk11> you can set a crontab (certauto is a tool for it I think) to auto-renew
 552 2016-08-25T18:30:28  <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
 553 2016-08-25T18:30:31  <btcdrak> it's just expired
 554 2016-08-25T18:30:38  <luke-jr> aha, ok
 555 2016-08-25T18:31:11  <luke-jr> how about StartCom?
 556 2016-08-25T18:31:15  <Lightsword> btcdrak, expiring for letsencrypt certificates shouldn’t ben an issue
 557 2016-08-25T18:31:15  <wumpus> hosting files is one of our bigger problems
 558 2016-08-25T18:31:20  <btcdrak> if we were to change the gitian fallback URL we could just point it to github tbf
 559 2016-08-25T18:31:43  <wumpus> but that's what you get with an almost zero project budget :)
 560 2016-08-25T18:31:47  <Lightsword> since you normally run an autoupdater on the server that will periodically renew the letsencrypt cert before it expires
 561 2016-08-25T18:32:09  <btcdrak> Lightsword: no, all those moving parts fail and it's a lot of maintenance in practice.
 562 2016-08-25T18:32:34  <Lightsword> hmm, I thought they had made it fairly reliable by now
 563 2016-08-25T18:32:38  <btcdrak> the gitian fallback should be hosted on github releases page and that would solve the issue.
 564 2016-08-25T18:32:48  <wumpus> is there some cheap https-supporting hosting that is not behind cloudflare?
 565 2016-08-25T18:32:51  <luke-jr> what happened to bitcoin.org's maintainers (not bitcoin.org itself) offering to host bitcoincore.org also?
 566 2016-08-25T18:33:05  <btcdrak> luke-jr: their hosting is due to run out soon.
 567 2016-08-25T18:33:08  <luke-jr> ah
 568 2016-08-25T18:33:14  <wumpus> they have the same proble
 569 2016-08-25T18:33:25  <sipa> who is bitcoin.org's maintainers, and who is bitcoin.org itself?
 570 2016-08-25T18:33:30  <btcdrak> actually, Pindar is getting us a budget for about 5 years infrastructure hosting.
 571 2016-08-25T18:33:47  <luke-jr> sipa: saivann/harding vs theymos/Cobra/someoneelse
 572 2016-08-25T18:33:54  <sipa> ah, ok
 573 2016-08-25T18:33:57  <btcdrak> should have the funding by October/November.
 574 2016-08-25T18:34:06  <gmaxwell> letsencrypt even sends email if you're going to expire.
 575 2016-08-25T18:34:54  <Lightsword> https://github.com/GUI/lua-resty-auto-ssl
 576 2016-08-25T18:34:56  <btcdrak> when wumpus and I spoke, he was quite clear about having a long term solution. also infrastructure hosting is a pita
 577 2016-08-25T18:34:56  <gmaxwell> Please never again setup pretextual security like that, it's an embarassment.
 578 2016-08-25T18:34:58  <Lightsword> for nginx should work
 579 2016-08-25T18:35:21  <btcdrak> gmaxwell: pretextural what?
 580 2016-08-25T18:35:27  <Lightsword> or certbot
 581 2016-08-25T18:35:29  <btcdrak> sorry, I mean what is pretextural
 582 2016-08-25T18:35:47  <wumpus> huh gmaxwell?
 583 2016-08-25T18:36:26  <gmaxwell> proxying through a third party to 'add SSL' when the connection just leaves cloudflare unencrypted and unauthenticated.
 584 2016-08-25T18:36:42  <gmaxwell> It appears secure to the user, but it's secure to a third party, and not even secure to the backend.
 585 2016-08-25T18:36:46  <afk11> certbot works quite well
 586 2016-08-25T18:36:49  <btcdrak> gmaxwell it's _not_
 587 2016-08-25T18:36:52  * luke-jr assumed btcdrak meant CloudFlare pinned the expired cert or something
 588 2016-08-25T18:36:54  <btcdrak> it's SSL to SSL
 589 2016-08-25T18:36:56  <wumpus> that's not even the case
 590 2016-08-25T18:37:13  <btcdrak> btw, this is the PR https://github.com/bitcoin/bitcoin/pull/7351
 591 2016-08-25T18:37:16  <afk11> btcdrak, it's not. it can be (gets you over CN mismatches), but they will proxy to a HTTP server
 592 2016-08-25T18:37:34  *** arubi has joined #bitcoin-core-dev
 593 2016-08-25T18:37:40  <btcdrak> afk11: no they wont, because it's set to Full SSL
 594 2016-08-25T18:37:46  <wumpus> gmaxwell: also dev.bitcoincore.org is *not* used for anything security critical, there are just some fallback files and gitian checks the hash
 595 2016-08-25T18:38:07  <wumpus> the only reason ssl was necessary there is that browsers frown on redirecting https to http
 596 2016-08-25T18:38:17  <sipa> i'm confused
 597 2016-08-25T18:38:29  <btcdrak> afk11: you can also configure the webserver to only accept connections from a certificate signed by CF
 598 2016-08-25T18:38:30  <gmaxwell> okay I was responding to "why is ... behind cloudflare" "it has to be to get the ssl".
 599 2016-08-25T18:38:53  <Lightsword> wumpus, bitcoincore.org is HSTS preloaded so http through browser won’t work at all for chrome and firefox
 600 2016-08-25T18:38:54  <wumpus> no, it's because of a cert issue with dev.bitcoincore.org, which is hopefully temporary
 601 2016-08-25T18:39:10  <gmaxwell> Okay.
 602 2016-08-25T18:39:37  <wumpus> Lightsword: right, that too
 603 2016-08-25T18:39:51  <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.
 604 2016-08-25T18:40:06  <Lightsword> doesn’t github force https?
 605 2016-08-25T18:40:10  <btcdrak> remember also, bitcoincore.org has HSTS preloading so we cannot use http:// on that domain.
 606 2016-08-25T18:40:26  <luke-jr> HSTS affects subdomains? :x
 607 2016-08-25T18:40:32  <wumpus> I'm not sure why we're even having an argument about this, is there an actual problem?
 608 2016-08-25T18:40:36  <wumpus> luke-jr: you can configure it to
 609 2016-08-25T18:40:39  <Lightsword> luke-jr, yeah it’s required to be on for HSTS preloading
 610 2016-08-25T18:40:47  <btcdrak> ^
 611 2016-08-25T18:40:48  <wumpus> please keep this channel restricted to bitcoin core development
 612 2016-08-25T18:41:01  <sipa> we need #bitcoin-core-org-dev :)
 613 2016-08-25T18:41:04  <btcdrak> LOL
 614 2016-08-25T18:41:13  <luke-jr> almost time for meeting btw
 615 2016-08-25T18:41:21  <wumpus> all the http and gpg etc talk is getting heavily off topic, yes I know I have been participating too
 616 2016-08-25T18:41:55  <sipa> wumpus: it looks like you've spent an awful lot of time on administrative stuff with 0.13
 617 2016-08-25T18:42:02  <gmaxwell> It's helpful to collaborate on things, even if they're offtopic. But not polite to people trying to read the logs. :)
 618 2016-08-25T18:42:03  <wumpus> sipa: yes :(
 619 2016-08-25T18:43:17  <btcdrak> more channels!
 620 2016-08-25T18:43:33  * btcdrak dashes for a tea break before the meeting
 621 2016-08-25T18:48:20  *** kadoban has quit IRC
 622 2016-08-25T18:49:26  *** kadoban has joined #bitcoin-core-dev
 623 2016-08-25T18:58:00  *** laurentmt has joined #bitcoin-core-dev
 624 2016-08-25T18:59:16  *** achow101 has joined #bitcoin-core-dev
 625 2016-08-25T18:59:31  *** jcorgan has joined #bitcoin-core-dev
 626 2016-08-25T18:59:42  *** Chris_Stewart_5 has quit IRC
 627 2016-08-25T19:00:01  <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
 628 2016-08-25T19:00:06  <instagibbs> here
 629 2016-08-25T19:00:09  <CodeShark> morning
 630 2016-08-25T19:00:13  <cfields_> hi, here
 631 2016-08-25T19:00:15  <kanzure> greetz
 632 2016-08-25T19:00:19  <murch> evening
 633 2016-08-25T19:00:32  <jonasschnelli> Meeting?
 634 2016-08-25T19:00:41  <sipa> pŗėșểñť
 635 2016-08-25T19:01:00  * luke-jr gives sipa some frogs as a present.
 636 2016-08-25T19:01:21  <gmaxwell> yum.
 637 2016-08-25T19:01:43  <paveljanik> topics?
 638 2016-08-25T19:01:47  <MarcoFalke> no chair?
 639 2016-08-25T19:02:00  <paveljanik> I'd like to ask for more ACKs on Wshadow PRs
 640 2016-08-25T19:02:13  <gmaxwell> too bad, we haven't started so you can't ask for that yet.
 641 2016-08-25T19:02:27  <gmaxwell> :P
 642 2016-08-25T19:02:29  <kanzure> hehe
 643 2016-08-25T19:02:37  <wumpus> #startmeeting
 644 2016-08-25T19:02:37  <lightningbot> Meeting started Thu Aug 25 19:02:37 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 645 2016-08-25T19:02:37  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 646 2016-08-25T19:02:51  <btcdrak> here
 647 2016-08-25T19:02:57  <paveljanik> I'd like to ask for more ACKs on Wshadow PRs
 648 2016-08-25T19:02:59  <paveljanik> ;-)
 649 2016-08-25T19:03:12  <cfields_> seconded. Will ACK/re-ACK.
 650 2016-08-25T19:03:18  <gmaxwell> paveljanik: as you wish.
 651 2016-08-25T19:03:18  *** laurentmt has quit IRC
 652 2016-08-25T19:03:32  <instagibbs> paveljanik, pr #?
 653 2016-08-25T19:03:34  <cfields_> (i caught a bug of my own with -Wshadow yesterday)
 654 2016-08-25T19:03:36  <instagibbs> for those not initiated
 655 2016-08-25T19:03:37  <MarcoFalke> paveljanik: I ACKed all. Anything I missed?
 656 2016-08-25T19:03:40  <gmaxwell> Give the PP@.
 657 2016-08-25T19:03:55  <gmaxwell> gr. PR#
 658 2016-08-25T19:03:59  <MarcoFalke> https://github.com/bitcoin/bitcoin/pulls/paveljanik
 659 2016-08-25T19:04:20  <paveljanik> 8449, 8472, 8191, 8163, 8109
 660 2016-08-25T19:04:43  <paveljanik> but yes, Marco's link is even better
 661 2016-08-25T19:05:00  <wumpus> anything that really needs to be discussed at the meetng?
 662 2016-08-25T19:05:26  <CodeShark> no, we've already accomplished everything - there's nothing more to do ever
 663 2016-08-25T19:05:32  <gmaxwell> woot.
 664 2016-08-25T19:05:33  <sipa> i'd like to bring up the various proposals for segwit DoS protection
 665 2016-08-25T19:05:38  <gmaxwell> ^
 666 2016-08-25T19:05:39  <instagibbs> ack
 667 2016-08-25T19:05:41  <petertodd> ack
 668 2016-08-25T19:05:41  <btcdrak> ack
 669 2016-08-25T19:05:47  <wumpus> well I'm very happy we finally managed to release 0.13.0, congrats everyone!
 670 2016-08-25T19:05:51  <paveljanik> Do we have any numbers of 0.13.0 nodes?
 671 2016-08-25T19:05:56  <cfields_> topic suggestion: codesigning update
 672 2016-08-25T19:05:58  <paveljanik> congrats to wumpus!
 673 2016-08-25T19:06:05  * jonasschnelli is checking the 0.13 nodes on his seeder
 674 2016-08-25T19:06:07  <instagibbs> paveljanik, few hundred ones bitnodes has reached
 675 2016-08-25T19:06:09  <btcdrak> beer for wumpus
 676 2016-08-25T19:06:12  <sipa> wumpus: congrats to all, and thanks a lot wumpus
 677 2016-08-25T19:06:13  <wumpus> #topic proposals for segwit DoS protection
 678 2016-08-25T19:06:21  <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.
 679 2016-08-25T19:06:35  <luke-jr> paveljanik: http://luke.dashjr.org/programs/bitcoin/files/charts/branches.html
 680 2016-08-25T19:06:51  <murch> paveljanik: 322 (according to bitnodes)
 681 2016-08-25T19:06:56  <gmaxwell> Congrats on 0.13. It looks like a great release.
 682 2016-08-25T19:06:57  <jonasschnelli> cat dnsseed.dump | grep "0.13.0" | grep "    1   " | wc -l               ---> 62
 683 2016-08-25T19:07:01  <sipa> so the main issue is #8279
 684 2016-08-25T19:07:37  <jonasschnelli> 213 seeds in non-good state (probably just set up)
 685 2016-08-25T19:07:43  <jonasschnelli> s/seeds/nodes
 686 2016-08-25T19:08:09  <gmaxwell> there are a lot more parties running it than accepting inbound, as typical.
 687 2016-08-25T19:08:11  <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, ...
 688 2016-08-25T19:08:30  <jonasschnelli> https://github.com/bitcoin/bitcoin/issues/8279
 689 2016-08-25T19:08:51  <gmaxwell> sipa: I think all of these changes are beneficial.
 690 2016-08-25T19:08:52  <kanzure> this is separate from the malleability confusion someone posted about the other day, ya?
 691 2016-08-25T19:09:07  <luke-jr> sipa: making feefilter mandatory, or merely always using it?
 692 2016-08-25T19:09:14  <instagibbs> kanzure, the linked github issue explains it
 693 2016-08-25T19:09:31  <sipa> luke-jr: you need to be able to rely on it, and be able to ban peers who disregard it
 694 2016-08-25T19:09:33  <gmaxwell> luke-jr: me means giving it an ack message and punting peers that violate it.
 695 2016-08-25T19:10:00  <sipa> luke-jr: as you're moving the responsibility for filtering things you won't accept to the sender
 696 2016-08-25T19:10:22  <luke-jr> ok, so <0.12 nodes wouldn't be kicked
 697 2016-08-25T19:10:28  <gmaxwell> right.
 698 2016-08-25T19:10:31  <petertodd> segwit is a good opportunity to make feefilter mandatory, given we're completely changing what nodes we connect too
 699 2016-08-25T19:10:34  <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.
 700 2016-08-25T19:11:05  <btcdrak> petertodd: i think that is the plan
 701 2016-08-25T19:11:20  <sipa> yes, but it seems hasty to do that along with 0.13.1
 702 2016-08-25T19:11:47  *** kadoban has quit IRC
 703 2016-08-25T19:11:58  <gmaxwell> in any case, "verify all inputs" was a proposal from before segwit was even imagined.
 704 2016-08-25T19:12:00  <petertodd> sipa: sure, but 0.13.1 also "hastily" has to stop fetching stuff from non-segwit nodes
 705 2016-08-25T19:12:12  *** kadoban has joined #bitcoin-core-dev
 706 2016-08-25T19:12:19  <sipa> petertodd: by hasty i mean we haven't implemented/tested/... a mandatory feefilter yet
 707 2016-08-25T19:12:29  <sipa> we have tested the relay behaviour of segwit vs non-segwit peers
 708 2016-08-25T19:13:21  <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.
 709 2016-08-25T19:13:23  <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)
 710 2016-08-25T19:13:59  <sipa> petertodd: we still need a new network message etc
 711 2016-08-25T19:14:13  <sipa> otherwise peers can just ignore your feefilter
 712 2016-08-25T19:14:29  <petertodd> sipa: maybe I'm missing something, but why do we need a new network message?
 713 2016-08-25T19:14:31  <luke-jr> sipa: I think petertodd is saying "segwit peers MUST NOT ignore feefilter"
 714 2016-08-25T19:14:48  <gmaxwell> petertodd: because the protocol is async, we don't know if the far end has recieved our feefilter request yet.
 715 2016-08-25T19:14:50  <sipa> petertodd: you don't know what the last feefilter message you sent is that your peer received
 716 2016-08-25T19:15:15  <petertodd> sipa: ah right, duh...
 717 2016-08-25T19:15:26  <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?
 718 2016-08-25T19:15:56  <gmaxwell> so the suggestion there is to add a feefilterack, and punt peers that should send it but don't send it 'fast enough'
 719 2016-08-25T19:15:59  <petertodd> sipa: I had it in my head that feefilter worked the other way around, and already had a new inv with fee info...
 720 2016-08-25T19:15:59  <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?
 721 2016-08-25T19:16:31  <gmaxwell> luke-jr: yes, thats part of the consideration.
 722 2016-08-25T19:16:54  <sipa> i expect that most of the problems are solved with just having feefilter
 723 2016-08-25T19:17:27  <sipa> and we can just do #8525 now
 724 2016-08-25T19:17:34  <luke-jr> hm, what if we change feerate's definition and want to get rid of the current algo some day?
 725 2016-08-25T19:17:36  <sipa> (don't store witness txn in the reject cache)
 726 2016-08-25T19:17:54  <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.
 727 2016-08-25T19:17:59  <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/8525
 728 2016-08-25T19:18:16  <petertodd> sipa: that could be a problem in the future if we have peers with different non-fee-related acceptance criteria than us
 729 2016-08-25T19:18:25  <CodeShark> I kinda like the idea of an inv with fee data - slightly larger messages but no need for state
 730 2016-08-25T19:18:30  <gmaxwell> reject cache was 90% implemented for lack of a fee filter.
 731 2016-08-25T19:18:43  <sipa> gmaxwell: that would open up many attacks... i don't think those are impossible to fix, but it needs a lot of analysis
 732 2016-08-25T19:18:54  <gmaxwell> I disagree.
 733 2016-08-25T19:19:21  <sipa> i like the idea of always validating (as #8593 does), but it feels risky
 734 2016-08-25T19:19:27  <gmaxwell> An uncached UTXO lookup eclipses the validation costs on most systems by orders of magnitude.
 735 2016-08-25T19:19:51  <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
 736 2016-08-25T19:20:12  <CodeShark> can't we consider extreme cases?
 737 2016-08-25T19:20:31  <CodeShark> what's the maximum possible validation cost for a single transaction?
 738 2016-08-25T19:21:01  <sipa> huge... remember we can't have any feerate or size based rejection criteria beforehand
 739 2016-08-25T19:21:33  <gmaxwell> well you can have a stripped size limit.
 740 2016-08-25T19:21:54  <sipa> yes, #8593 does that
 741 2016-08-25T19:21:59  <sipa> but you can't use fee
 742 2016-08-25T19:22:14  *** skyraider has joined #bitcoin-core-dev
 743 2016-08-25T19:22:19  <sipa> or at least not actual feerate, only stripped-size-feerate
 744 2016-08-25T19:22:53  <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
 745 2016-08-25T19:23:11  <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
 746 2016-08-25T19:23:31  <petertodd> sipa: so I don't see the value of feerate in preventing DoS attack there anyway
 747 2016-08-25T19:23:41  <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
 748 2016-08-25T19:23:50  <sipa> and you'll validate it, but not relay
 749 2016-08-25T19:24:43  <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.
 750 2016-08-25T19:24:47  <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
 751 2016-08-25T19:25:03  <sipa> petertodd: well in no case will any of this relay
 752 2016-08-25T19:25:16  <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.
 753 2016-08-25T19:26:11  <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
 754 2016-08-25T19:26:41  <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
 755 2016-08-25T19:27:04  <sipa> CodeShark: i think mandatory feefilter is a better solution than adding 10 kB of data to each inv
 756 2016-08-25T19:27:10  <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.
 757 2016-08-25T19:28:05  <CodeShark> 10kB of data?
 758 2016-08-25T19:28:26  <CodeShark> the fee is uint64 and the tx size is varint
 759 2016-08-25T19:28:35  <sipa> CodeShark: txid, wtxid, fee, feerate, stripped feerate, size, sigops, bytes hashed, ... anything else that may affect your policy
 760 2016-08-25T19:28:48  <CodeShark> ok, fair enough
 761 2016-08-25T19:28:56  <sipa> inv bandwidth is larger than tx bandwidth by a factor of 5 on my node
 762 2016-08-25T19:29:05  <luke-jr> sipa: let's make it configurable! /s
 763 2016-08-25T19:29:25  <sipa> and that's between feefilter nodes
 764 2016-08-25T19:30:22  <sipa> so... do we think jl2012's approach of validating everything (or a fraction thereof) is the way to go for 0.13.1
 765 2016-08-25T19:30:25  <sipa> ?
 766 2016-08-25T19:30:36  <CodeShark> I haven't done the math
 767 2016-08-25T19:30:36  <sipa> the code is simple at least
 768 2016-08-25T19:30:48  <sipa> CodeShark: getpeerinfo
 769 2016-08-25T19:30:54  <sipa> shows bytes per message
 770 2016-08-25T19:30:56  <gmaxwell> This is why I think we need reconciliation for any inv improvement long term.
 771 2016-08-25T19:31:04  <sipa> yes
 772 2016-08-25T19:31:13  <sipa> but the meeting time is half, let's not stray too far
 773 2016-08-25T19:31:21  <sipa> i'd like to know what we're going to do for 0.13.1
 774 2016-08-25T19:31:26  <instagibbs> sipa, your guess is as ~~good as~~ better than mine
 775 2016-08-25T19:31:28  <CodeShark> sipa: I mean, I haven't done the math for validation cost edge cases
 776 2016-08-25T19:31:35  <gmaxwell> sipa: I jl2012's sampling suggestion is a pretty good idea, coupled with not reject filtering them.
 777 2016-08-25T19:32:22  <sipa> gmaxwell: right... either fully validate, or don't store in reject
 778 2016-08-25T19:32:41  <sipa> i like
 779 2016-08-25T19:32:53  <sipa> ok, other topics?
 780 2016-08-25T19:32:55  <petertodd> I suspect we'd be better off kicking peers who send us >100KB txs
 781 2016-08-25T19:33:09  <petertodd> (rather than any kind of probabalistic thing)
 782 2016-08-25T19:33:28  <afk11> hardware signing BIP?
 783 2016-08-25T19:33:50  <sipa> there were a few other topic ideas before
 784 2016-08-25T19:34:18  <wumpus> #topic code signing
 785 2016-08-25T19:34:19  <petertodd> afk11: that's off-topic to Bitcoin Core development right now
 786 2016-08-25T19:34:20  <gmaxwell> petertodd: yes, we can do that-- and I think we should--, but I think it's not sufficient.
 787 2016-08-25T19:34:21  <wumpus> @cfields_
 788 2016-08-25T19:34:37  <wumpus> petertodd: it's on topic for the future though
 789 2016-08-25T19:34:39  <petertodd> gmaxwell: well, I mean in combination with fully validating
 790 2016-08-25T19:34:40  *** cryptapus_ has quit IRC
 791 2016-08-25T19:34:49  <petertodd> wumpus: sure, why I said "right now" :)
 792 2016-08-25T19:34:52  <gmaxwell> petertodd: okay. lets talk after meeting.
 793 2016-08-25T19:35:02  <cfields_> so, i just wanted to bring this up before i finish the work, in case anyone has any suggestions for improvements
 794 2016-08-25T19:35:04  <cfields_> https://github.com/theuni/osx-codesign
 795 2016-08-25T19:35:21  <cfields_> I have a working codesigner for osx from linux, so an osx machine is no longer needed for the release process
 796 2016-08-25T19:35:38  <gmaxwell> \O/
 797 2016-08-25T19:35:47  <sipa> great
 798 2016-08-25T19:35:48  <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
 799 2016-08-25T19:35:55  <CodeShark> cfields_: nice
 800 2016-08-25T19:35:57  <btcdrak> cfields_ except for extracting the MacOS SDK...
 801 2016-08-25T19:35:58  <jonasschnelli> cfields_: very nice. Lots of devs are looking for something!
 802 2016-08-25T19:36:01  <jonasschnelli> like that
 803 2016-08-25T19:36:05  <wumpus> cfields_: nice work!
 804 2016-08-25T19:36:26  <sipa> cfields_: what cryptography does it use?
 805 2016-08-25T19:36:28  <cfields_> (as of now it produces valid signed binaries given very specific constraints, it just needs to be tidied up and plugged into gitian)
 806 2016-08-25T19:36:48  <luke-jr> cfields_: plugged into gitian?
 807 2016-08-25T19:36:53  <petertodd> cfields_: nice license!
 808 2016-08-25T19:37:10  <jonasschnelli> GNU AFFERO GENERAL PUBLIC LICENSE,... hell!
 809 2016-08-25T19:37:25  <gmaxwell> :)
 810 2016-08-25T19:37:41  * luke-jr agrees it's a good choice of license. ☺
 811 2016-08-25T19:37:41  <cfields_> sipa: there's no choice in that, i haven't even looked into the signature type
 812 2016-08-25T19:37:54  <gmaxwell> If it is RSA or schnorr we can secret share the key.
 813 2016-08-25T19:38:14  <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
 814 2016-08-25T19:38:21  <petertodd> jonasschnelli: I like AGPL because I'm not stinkin' commie
 815 2016-08-25T19:38:39  <cfields_> along with a mostly redundant detached xml with the same hashes
 816 2016-08-25T19:38:45  <gmaxwell> cfields_: how are you signing if you don't know how it's signing? :)
 817 2016-08-25T19:39:01  <cfields_> sorry, not my license choice. 99% of the code is borrowed from an ios tool
 818 2016-08-25T19:39:31  <jonasschnelli> I guess you need to update "sudo xcode-select --switch /Applications/Xcode-4.6.3.app"
 819 2016-08-25T19:39:35  <cfields_> gmaxwell: PKCS7_sign(), openssl does the hard work :)
 820 2016-08-25T19:39:37  <gmaxwell> nothing wrong with AGPL for a tool like this, licensing is a tool.
 821 2016-08-25T19:39:38  <jonasschnelli> Hard to download older version of Xcode
 822 2016-08-25T19:39:47  <gmaxwell> cfields_: how big is the signature? :P
 823 2016-08-25T19:40:23  <cfields_> gmaxwell: i can dump you some samples after the meeting
 824 2016-08-25T19:40:44  <gmaxwell> great, in any case, I'd like to talk about integrating multiparty signing into it. it might be easy to accomplish.
 825 2016-08-25T19:40:47  <cfields_> but back to the point: is anyone interested in coming up with a signing scheme that deviates from what we have now?
 826 2016-08-25T19:41:11  <cfields_> oh, i suppose that's why you want to know about sig type :)
 827 2016-08-25T19:41:18  <gmaxwell> Yes.
 828 2016-08-25T19:41:23  <sipa> yes.
 829 2016-08-25T19:41:28  <jonasschnelli> gmaxwell: my OSX code signing certs are RSA 2048 Bit
 830 2016-08-25T19:41:45  <michagogo> cfields_: your signer is missing a README
 831 2016-08-25T19:41:50  <petertodd> cfields_: I'm already working on codesigning as my first application for dex
 832 2016-08-25T19:42:01  <sipa> oh, let's just switch bitcoin to use prime factoring as PoW
 833 2016-08-25T19:42:11  <cfields_> same here, what i'm not sure about is how much you're allowed to change around the sig format
 834 2016-08-25T19:42:44  <cfields_> (for osx, the signing cert must be signed by apple)
 835 2016-08-25T19:42:49  <wumpus> yes, IIRC PKCS7 is simply RSA wrapped in ASN.1 mess
 836 2016-08-25T19:43:12  <cfields_> yes
 837 2016-08-25T19:43:25  <cfields_> and apple adds a weird little scripting language around 'designated requirements'
 838 2016-08-25T19:43:35  <wumpus> congrats on cracking that :)
 839 2016-08-25T19:43:37  <sipa> cfields_: well there could be several signers, and we get a cert for the combined key?
 840 2016-08-25T19:43:50  <jonasschnelli> The question is, does code-signing really increases the security of bitcoin-core...
 841 2016-08-25T19:44:05  <cfields_> so you can add other restrictions, but again, i'm not sure how much apple lets you deviate from the default
 842 2016-08-25T19:44:11  <luke-jr> jonasschnelli: imagine where common gitian builders all sign themselves and combine the sig
 843 2016-08-25T19:44:12  <gmaxwell> the straightforward way of doing threshold RSA needs a trusted dealer. but at least its multiparty after setup.
 844 2016-08-25T19:44:19  <petertodd> jonasschnelli: I suspect the code-signature-verification is what increases the security of bitcoin-core :)
 845 2016-08-25T19:44:34  <jonasschnelli> petertodd: i rather say verifing of gitian signatures...
 846 2016-08-25T19:44:44  <luke-jr> jonasschnelli: essentially we'd get the OS to verify the gitian builds in this case
 847 2016-08-25T19:44:45  <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
 848 2016-08-25T19:44:49  <jonasschnelli> OSX code signatures are from "Bitcoin Foundation"... anyone could hold the key
 849 2016-08-25T19:45:03  <sipa> i'm sure we can get a new cert
 850 2016-08-25T19:45:08  <petertodd> jonasschnelli: the gitian signatures aren't ever going to be much more secure than the code signatures
 851 2016-08-25T19:45:11  <jonasschnelli> cfields_: Yes. But thats just a restrriction from apple...
 852 2016-08-25T19:45:13  <cfields_> jonasschnelli:  (we haven't messed with the sandboxing yet, afaik)
 853 2016-08-25T19:45:18  <jonasschnelli> and sandboxing is impossible for bitcoin core right now
 854 2016-08-25T19:45:23  <petertodd> jonasschnelli: also, lots of people don't use the gitian builds (I've never personally run one)
 855 2016-08-25T19:45:26  <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.
 856 2016-08-25T19:45:45  <kanzure> someone should make sure to watch petertodd do a gitian build in milan :)
 857 2016-08-25T19:45:48  <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
 858 2016-08-25T19:45:53  *** Ylbam has quit IRC
 859 2016-08-25T19:46:28  <jonasschnelli> cfields_: sure. But nice work! Linux based OSX/iOS code signing is highly appriciated by lots of devs.
 860 2016-08-25T19:46:33  <cfields_> just to reiterate though: osx-codesign is 99% ripped from a tool from Saurek. I just ported to osx and updated.
 861 2016-08-25T19:46:39  <kanzure> saurik
 862 2016-08-25T19:46:46  <cfields_> *Saurik. Thanks.
 863 2016-08-25T19:47:04  <sipa> saurik?
 864 2016-08-25T19:47:09  <cfields_> jonasschnelli: right, mostly I got tired of having to have my macbook for signing.
 865 2016-08-25T19:47:16  <kanzure> /whois saurik
 866 2016-08-25T19:47:23  <cfields_> and it limits the amount of people who can do the signing
 867 2016-08-25T19:47:36  <jonasschnelli> Indeed
 868 2016-08-25T19:47:46  <jonasschnelli> though you can run a OSX VM on a Linux machine. :)
 869 2016-08-25T19:47:57  <cfields_> heh
 870 2016-08-25T19:47:58  <jonasschnelli> (and violate apples TOC)
 871 2016-08-25T19:48:02  * luke-jr peers at his common channels with saurik
 872 2016-08-25T19:48:06  <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.
 873 2016-08-25T19:48:18  <kanzure> sipa: he is known for various ios reverse engineering things
 874 2016-08-25T19:48:22  <CodeShark> is 4096 overkill?
 875 2016-08-25T19:48:23  <sipa> ah, cool
 876 2016-08-25T19:48:25  <cfields_> gmaxwell: perfect, thanks.
 877 2016-08-25T19:48:31  <gmaxwell> (as an aside, this could also be done with wumpus' release key)
 878 2016-08-25T19:48:37  <jeremyrubin> 4096 not overkill
 879 2016-08-25T19:48:38  <kanzure> sipa: (pm)
 880 2016-08-25T19:48:41  *** cryptapus_ has joined #bitcoin-core-dev
 881 2016-08-25T19:48:42  *** cryptapus_ is now known as cryptapus_afk
 882 2016-08-25T19:49:03  <sipa> CodeShark: 3000 bits RSA is approximately equivalent with 256 bit EC
 883 2016-08-25T19:49:05  <jonasschnelli> CodeShark: 2048 gives use 118bit of security.. ECDSA 128 I guess... enought?
 884 2016-08-25T19:49:09  <gmaxwell> CodeShark: I believe we don't get to choose the parameters of this key.
 885 2016-08-25T19:49:18  <jonasschnelli> Yes. Apples does it.
 886 2016-08-25T19:49:22  <CodeShark> oh, right
 887 2016-08-25T19:49:29  <gmaxwell> Otherwise it would be 4096 bit. because duh.
 888 2016-08-25T19:49:37  <cfields_> gmaxwell: i'll try to find out if other signature types are possible.
 889 2016-08-25T19:49:45  * jonasschnelli is trying a 4096 key
 890 2016-08-25T19:49:48  <gmaxwell> (the size and performance are basically irrelevant)
 891 2016-08-25T19:51:00  <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.
 892 2016-08-25T19:51:21  <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
 893 2016-08-25T19:51:25  <kanzure> jeremyrubin: got the core dumps yet?
 894 2016-08-25T19:51:34  <jonasschnelli> Which would allow decoupling the keys from the wallet(system)
 895 2016-08-25T19:51:50  <jeremyrubin> kanzure: nope; i tried changing the travis script to dump them but couldn't see anything.
 896 2016-08-25T19:52:19  <kanzure> you can probably call gdb bt from inside the after_failure segment
 897 2016-08-25T19:52:21  <jonasschnelli> to end the wild-west APIs/interfaces that are currently been implemented by wallets and hardware-wallet vendors
 898 2016-08-25T19:52:26  <wumpus> I very much like the idea of standardizing detached signing
 899 2016-08-25T19:52:32  <wumpus> yes, exactly
 900 2016-08-25T19:52:54  <jonasschnelli> One of the main problems users have and will have with wallets is to keep private keys private.
 901 2016-08-25T19:53:29  <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
 902 2016-08-25T19:53:42  <btcdrak> jonasschnelli: well you'd hope hardware signing devices will become more commonplace
 903 2016-08-25T19:53:53  <CodeShark> they will
 904 2016-08-25T19:54:04  <instagibbs> 7 minutes, any more topics?
 905 2016-08-25T19:54:08  <CodeShark> it's not something we should hope for - it's something we should make happen
 906 2016-08-25T19:54:08  <wumpus> no doubt about that, though it's two-sided, software also needs to support them
 907 2016-08-25T19:54:09  <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.
 908 2016-08-25T19:54:21  <wumpus> CodeShark: jonasschnelli is helping make it happen
 909 2016-08-25T19:54:28  <sipa> the topic is still codesigning :)
 910 2016-08-25T19:54:45  <petertodd> btcdrak: also note that in systems like Qubes, detached signing in another VM is a significant security improvement even w/o special hardware
 911 2016-08-25T19:54:47  <btcdrak> yes. detached signing is more for the bitcoin-dev ML
 912 2016-08-25T19:54:58  <petertodd> btcdrak: Qubes does this for GPG already
 913 2016-08-25T19:55:04  <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.
 914 2016-08-25T19:55:04  <wumpus> do we still have anything to say about codesigning?
 915 2016-08-25T19:55:07  <btcdrak> petertodd: interesting
 916 2016-08-25T19:55:24  <jonasschnelli> gmaxwell: Yes. I'm working on a PoC with static data between Core and iOS.
 917 2016-08-25T19:55:40  <sipa> wumpus: i believe not, i was only casually complaining about the random switch of topic :)
 918 2016-08-25T19:55:58  <jonasschnelli> my fault. sry.
 919 2016-08-25T19:56:10  <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.
 920 2016-08-25T19:56:22  <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
 921 2016-08-25T19:56:31  <wumpus> sipa: agreed, it's a bit of a sudden switch
 922 2016-08-25T19:56:54  <wumpus> time to end the meeting maybe
 923 2016-08-25T19:57:10  <wumpus> #endmeeting
 924 2016-08-25T19:57:10  <lightningbot> Meeting ended Thu Aug 25 19:57:10 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
 925 2016-08-25T19:57:10  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-25-19.02.html
 926 2016-08-25T19:57:10  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-25-19.02.txt
 927 2016-08-25T19:57:10  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2016/bitcoin-core-dev.2016-08-25-19.02.log.html
 928 2016-08-25T19:57:13  <murch> sipa: average UTXO set size did turn out to be a very valuable evaluation criteria by the way.
 929 2016-08-25T19:57:25  <jonasschnelli> gmaxwell: I think it should be split into two applications
 930 2016-08-25T19:57:28  <sipa> murch: cool
 931 2016-08-25T19:57:46  <gmaxwell> jonasschnelli: How so?
 932 2016-08-25T19:58:12  <jonasschnelli> wallet does only hold pubkeys,... it can retrieve new keys or signatures over the sign:// URL scheme
 933 2016-08-25T19:58:12  *** cryptapus has quit IRC
 934 2016-08-25T19:58:20  <jonasschnelli> sign://getkeys?amount=10
 935 2016-08-25T19:58:31  <jonasschnelli> sign://sign?type=bitcointx&somedata=xyz
 936 2016-08-25T19:58:37  <CodeShark> wallet stuff really needs to be a separate project - bitcoin-core-dev should focus on consensus and p2p stuff :p
 937 2016-08-25T19:58:45  <gmaxwell> CodeShark: I disagree.
 938 2016-08-25T19:58:48  *** achow101 has quit IRC
 939 2016-08-25T19:59:32  <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
 940 2016-08-25T19:59:37  <jonasschnelli> *users
 941 2016-08-25T19:59:42  <gmaxwell> jonasschnelli: now thats batching things into having 'multiple wallet' data stores.
 942 2016-08-25T20:00:09  <jonasschnelli> No really. Just separating private-key from the wallet
 943 2016-08-25T20:00:17  <jonasschnelli> *keys
 944 2016-08-25T20:00:18  <gmaxwell> you mean seperating the wallet from the wallet.
 945 2016-08-25T20:00:30  <CodeShark> the thing that needs to be separated is the signer
 946 2016-08-25T20:00:37  <jonasschnelli> No.. the wallet is much more then the private-keys...
 947 2016-08-25T20:00:39  <CodeShark> along with all private key data
 948 2016-08-25T20:00:55  <jonasschnelli> private-keys do only sign data... 90% is wallet logic.
 949 2016-08-25T20:00:57  <CodeShark> and the signing request protocol can be defined abstractly
 950 2016-08-25T20:01:03  <gmaxwell> jonasschnelli: Yes it is, but the thing 99% of the care goes into is the keying material.
 951 2016-08-25T20:01:32  <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.
 952 2016-08-25T20:01:37  <CodeShark> the signing device doesn't need to store history and perhaps only very little state
 953 2016-08-25T20:01:57  <sipa> CodeShark: i think jonasschnelli is well aware of that
 954 2016-08-25T20:02:19  <CodeShark> I was replying to gmaxwell's "separate the wallet from the wallet" comment
 955 2016-08-25T20:02:24  <jonasschnelli> CodeShark: yes. It just needs the data that needed to verify the data-to-sign
 956 2016-08-25T20:02:36  <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.
 957 2016-08-25T20:02:37  <jonasschnelli> If you sign a PDF, you need the PDF along with the sha256(PDF)
 958 2016-08-25T20:02:54  <gmaxwell> (for that case)
 959 2016-08-25T20:03:30  <jonasschnelli> gmaxwell: what would be in the blob stored on behalf of the signer?
 960 2016-08-25T20:03:46  <jonasschnelli> Some king of authentication?
 961 2016-08-25T20:03:50  <sipa> jonasschnelli: encrypted keys in gmaxwell's examplr
 962 2016-08-25T20:03:50  <jonasschnelli> kind
 963 2016-08-25T20:04:00  <sipa> jonasschnelli: but you shouldn't care about what it is
 964 2016-08-25T20:04:15  <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.
 965 2016-08-25T20:04:15  <michagogo> If anyone here has an iOS device and hasn't heard yet: update to iOS 9.3.5 ASAP.
 966 2016-08-25T20:04:17  <da2ce7> gmaxwell: I agree making the Hardware wallet storage-less other than securely holding a decryption key is a very attractive route.
 967 2016-08-25T20:04:42  <michagogo> A trio of critical security holes was just patched. And in the meantime stay away from untrusted links.
 968 2016-08-25T20:05:02  <CodeShark> the requestor sends a blob + metadata, signer displays metadata to user and asks for authorization, user authorizes, signer returns signed blob
 969 2016-08-25T20:05:11  <sipa> da2ce7: i think you misunderstand
 970 2016-08-25T20:05:29  <sipa> da2ce7: an actual hardware wallet would have its own state, of course
 971 2016-08-25T20:05:45  <gmaxwell> or maybe it wouldn't that would be up to its design.
 972 2016-08-25T20:05:46  <CodeShark> the interface could even provide for abstract sighash type
 973 2016-08-25T20:06:01  <jonasschnelli> sipa, gmaxwell: thanks... need to think about it. need to go afk.
 974 2016-08-25T20:06:35  <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
 975 2016-08-25T20:11:08  <kanzure> is the hardware wallet BIP thread the right place to pimp "libconsensus in HSM" stuff?
 976 2016-08-25T20:11:13  <gmaxwell> NO
 977 2016-08-25T20:11:25  <gmaxwell> actually I think that thread should be dropped for now.
 978 2016-08-25T20:12:25  <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.
 979 2016-08-25T20:12:59  <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"
 980 2016-08-25T20:13:24  <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"
 981 2016-08-25T20:14:37  *** BashCo has quit IRC
 982 2016-08-25T20:15:48  <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.
 983 2016-08-25T20:16:28  <MarcoFalke> jeremyrubin: You need to solve the merge conflict for travis to pick it up
 984 2016-08-25T20:16:39  <MarcoFalke> I will try to reproduce locally
 985 2016-08-25T20:17:36  <jeremyrubin> MarcoFalke: ah; will do. It's picked up on my fork
 986 2016-08-25T20:17:46  <jeremyrubin> https://travis-ci.org/JeremyRubin/bitcoin/builds/154016406
 987 2016-08-25T20:17:54  <MarcoFalke> ok
 988 2016-08-25T20:18:05  <jeremyrubin> I just added something to print out the test-suite.log after_failure
 989 2016-08-25T20:18:12  <jeremyrubin> so that's the newer build
 990 2016-08-25T20:22:58  *** cryptapus_afk has quit IRC
 991 2016-08-25T20:35:28  <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...
 992 2016-08-25T20:36:06  <jonasschnelli> But I think a BIP would be the right think for a hardware wallet interface standard..
 993 2016-08-25T20:36:24  <jonasschnelli> *Thing
 994 2016-08-25T20:37:28  <sipa> sure, eventually
 995 2016-08-25T20:41:59  * jonasschnelli sometimes thinks that a wallet with privet-keys is like a home door with the key under the doormat
 996 2016-08-25T20:44:08  <instagibbs> jonasschnelli, you can start a SIP ;)
 997 2016-08-25T20:44:12  * instagibbs ducks
 998 2016-08-25T20:45:54  <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.
 999 2016-08-25T20:46:11  <gmaxwell> because your compromised computer will substitute any addresses you attempt to pay to.
1000 2016-08-25T20:46:29  <gmaxwell> and it will tell you that you've been paid, when you haven't been.
1001 2016-08-25T20:46:34  <jeremyrubin> MarcoFalke: I rebased onto master fyi so you'll want to -D your local if you pulled it
1002 2016-08-25T20:46:38  <jonasschnelli> Yeah. Agree. But...
1003 2016-08-25T20:47:12  <jonasschnelli> A hardware wallet or let say, a detached signer (assume a smartphone) can verify the data(tx) independently.
1004 2016-08-25T20:47:52  <jonasschnelli> Even if you computer is totally compromised, your signer would reveal that.
1005 2016-08-25T20:47:56  <sipa> jonasschnelli: how does the hw device verify it's sending to the right address
1006 2016-08-25T20:48:15  <sipa> it can show you, sure
1007 2016-08-25T20:48:24  <jonasschnelli> It would show it on a display?
1008 2016-08-25T20:48:34  <sipa> but how do you know the right address if your computer is hacked?
1009 2016-08-25T20:48:39  <jonasschnelli> Fees are a bit tricky
1010 2016-08-25T20:49:12  <jonasschnelli> That right... Your browser window where the address listed could be already compromised.
1011 2016-08-25T20:49:45  <jonasschnelli> In the world of "addresses", we have to assume it has been transmitted untempered
1012 2016-08-25T20:50:40  <gmaxwell> jonasschnelli: thats what I mean, if your computer is compromised it doesn't really matter what it displays, at least right now.
1013 2016-08-25T20:50:41  <jonasschnelli> At least the signer can identify if a receiving address is owned by the signer and also if a change address is
1014 2016-08-25T20:51:15  <jonasschnelli> But you might scan in a QRcode address...
1015 2016-08-25T20:53:27  <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.
1016 2016-08-25T20:54:19  <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.
1017 2016-08-25T20:54:25  <jonasschnelli> Malware targeting only you wallet software would be identified. A clever forged multi-app attack not.
1018 2016-08-25T20:55:12  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1019 2016-08-25T20:55:32  *** aalex_ is now known as aalex
1020 2016-08-25T20:55:37  <MarcoFalke> jeremyrubin: This also fails locally on my 14.04vm
1021 2016-08-25T20:55:43  <MarcoFalke> Might be easier to debug
1022 2016-08-25T20:56:07  <jonasschnelli> gmaxwell: how can the later be exploited? You mean by displaying an attackers address instead of the owner ones?
1023 2016-08-25T20:56:59  <jeremyrubin> MarcoFalke: Awesome; maybe it's a virtualization thing
1024 2016-08-25T20:57:32  <jeremyrubin> Are you just using a vanilla 14.04?
1025 2016-08-25T20:58:00  <gmaxwell> the latter is that the attacker 'pays you' but never authors a transaction and your compromised host displays the transaction as confirmed.
1026 2016-08-25T20:58:41  <MarcoFalke> jup, I don't recall any specifics I changed
1027 2016-08-25T21:00: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 :-)
1028 2016-08-25T21:01:54  <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.
1029 2016-08-25T21:02:09  <gmaxwell> so at least that could be done.
1030 2016-08-25T21:02:41  <jeremyrubin> cool -- do you see anything interesting in the dump? (spinning one up now)
1031 2016-08-25T21:03:14  <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. ;(
1032 2016-08-25T21:15:01  <luke-jr> instagibbs: SIPs are for altcoin stuffs ;)
1033 2016-08-25T21:39:52  *** MarcoFalke has left #bitcoin-core-dev
1034 2016-08-25T21:44:51  *** BashCo has joined #bitcoin-core-dev
1035 2016-08-25T21:54:08  *** belcher has joined #bitcoin-core-dev
1036 2016-08-25T21:55:53  *** Megaf has joined #bitcoin-core-dev
1037 2016-08-25T22:13:24  *** Megaf has quit IRC
1038 2016-08-25T22:28:50  *** cryptapus has joined #bitcoin-core-dev
1039 2016-08-25T22:28:50  *** cryptapus has joined #bitcoin-core-dev
1040 2016-08-25T22:29:12  *** cryptapus is now known as cryptapus_afk
1041 2016-08-25T22:32:15  *** Ylbam has joined #bitcoin-core-dev
1042 2016-08-25T22:34:33  *** spudowiar has joined #bitcoin-core-dev
1043 2016-08-25T22:36:05  *** murch has quit IRC
1044 2016-08-25T22:42:01  *** paracyst has joined #bitcoin-core-dev
1045 2016-08-25T22:51:44  *** JackH has quit IRC
1046 2016-08-25T23:03:02  <btcdrak> cfields_: I have successfully extracted the MacOS SDK from Xcode DMG directly linux :)
1047 2016-08-25T23:06:09  <luke-jr> btcdrak: how?
1048 2016-08-25T23:06:19  <btcdrak> black magic :)
1049 2016-08-25T23:07:26  <btcdrak> luke-jr: cfields: https://gist.github.com/btcdrak/6e67c84ed8375c9a9d506c2038622fc4
1050 2016-08-25T23:12:32  *** skyraider has quit IRC
1051 2016-08-25T23:13:39  <GreenIsMyPepper> ooo that's awesome ^_^
1052 2016-08-25T23:18:17  <btcdrak> GreenIsMyPepper: I think I have been cheated! the archive size doesnt match sigh
1053 2016-08-25T23:18:25  <luke-jr> ☺
1054 2016-08-25T23:18:41  <luke-jr> btcdrak: the files are all empty
1055 2016-08-25T23:19:26  <btcdrak> =) oh well
1056 2016-08-25T23:23:12  *** achow101 has joined #bitcoin-core-dev
1057 2016-08-25T23:23:32  *** spudowiar has quit IRC
1058 2016-08-25T23:23:33  <cfields_> btcdrak: woohoo!
1059 2016-08-25T23:23:48  <cfields_> oh, heh
1060 2016-08-25T23:23:55  <btcdrak> cfields: :/
1061 2016-08-25T23:24:04  <cfields_> yes, hfsmount hasn't been touched in ages afaik
1062 2016-08-25T23:24:09  <cfields_> iirc there are files missing too
1063 2016-08-25T23:25:04  <btcdrak> I assume the extraction of the partition by 7z is fine, just the hfsmount is incompatible?
1064 2016-08-25T23:26:03  <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.
1065 2016-08-25T23:26:14  <gmaxwell> We can have side information as part of the process.
1066 2016-08-25T23:29:45  *** spudowiar has joined #bitcoin-core-dev
1067 2016-08-25T23:50:16  *** Cheeseo has quit IRC
1068 2016-08-25T23:53:15  <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
1069 2016-08-25T23:54:23  *** Cheeseo has joined #bitcoin-core-dev
1070 2016-08-25T23:54:24  *** Cheeseo has joined #bitcoin-core-dev