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