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