1 2016-01-28 00:48:39 <stevenroose> github down, wtf
  2 2016-01-28 00:48:58 <mrkent> stevenroose: been for a while. super annyoing
  3 2016-01-28 00:49:14 <bsm1175321> #decentralizegithub
  4 2016-01-28 00:49:22 <bsm1175321> Come on, you don't have your git repos on ipfs yet?
  5 2016-01-28 00:49:23 <stevenroose> A decentralized github would be so awesome
  6 2016-01-28 00:49:26 <stevenroose> And is so possible
  7 2016-01-28 00:49:30 <gmaxwell> you could take the hub part out.
  8 2016-01-28 00:49:33 <stevenroose> Bitcoin should be the first to adopt it
  9 2016-01-28 00:49:35 <gmaxwell> you might call it 'git'
 10 2016-01-28 00:49:43 <mrkent> hahahha
 11 2016-01-28 00:49:45 <mrkent> word
 12 2016-01-28 00:49:48 <bsm1175321> ;-)
 13 2016-01-28 00:50:39 <stevenroose> gmaxwell, it should have a repo for issues and the ability to have an official branch with multisig support f.e.
 14 2016-01-28 00:50:48 <stevenroose> Would even be better than what GH provides today
 15 2016-01-28 00:51:10 <stevenroose> git is quite decentralized, sadly it is not used like that (anymore)
 16 2016-01-28 00:51:17 <bsm1175321> In case anyone really wants to debate forking yourself further and you're in NYC: http://www.meetup.com/BitDevsNYC/events/228376890/
 17 2016-01-28 00:51:52 <gmaxwell> stevenroose: it's used 'like that' by lots of parties.
 18 2016-01-28 00:53:23 <stevenroose> gmaxwell, yes?
 19 2016-01-28 00:54:45 <mrkent> @bsm1175321: I have a question for the "Classic crowd": What do we do when 2MB blocks start filling up?
 20 2016-01-28 00:55:36 <gmaxwell> stevenroose: in any case, AFAIK most people working on bitcoin have their git set to locally fetch all pull requests; so with it down we only lose issues and comments. (really annoying that these things themselves aren't locally pullable)
 21 2016-01-28 00:55:42 <bsm1175321> More forks.  All forks, all the time.  Fork everyone else.
 22 2016-01-28 00:56:30 <bsm1175321> mrkent: There is no answer.  Bumping the block size is not a solution to the problem, only a stop-gap measure to a more carefully considered solution.  I don't think you'll hear that from the classic camp though.
 23 2016-01-28 00:57:58 <mrkent> Right... Why isn't a list of questions for Classic to consider on reddit everyday?
 24 2016-01-28 00:58:55 <bsm1175321> mrkent: I am very tired of this debate.  I'm working on a better long-term solution.  If you really want to know what I think, it's here. http://blog.sldx.com/go-fork-yourself-more-bitcoin-transactions/
 25 2016-01-28 00:59:07 <bsm1175321> I don't read reddit because it's a forking cesspool.
 26 2016-01-28 00:59:43 <bsm1175321> We're hosting this "discussion" but I'm not leading or moderating it, I'm leaving it to some of my very level-headed co-organizers.  We hope to keep it civil and on point.
 27 2016-01-28 01:14:20 <mrkent> @bsm1175321: good read
 28 2016-01-28 01:14:37 <bsm1175321> thanks!
 29 2016-01-28 01:18:02 <mrkent> if i understand correctly, weak or extension blocks can use similar mechanism as segwit?
 30 2016-01-28 01:18:12 <bsm1175321> Yes they can
 31 2016-01-28 01:18:58 <bsm1175321> The segwit address mechanism is kind of like saying "the data to validate this is over --->> here" Which could be an extension block, a witness, or something more elaborate like a braid.
 32 2016-01-28 01:19:13 <gmaxwell> ...
 33 2016-01-28 01:19:18 <gmaxwell> That isn't correct.
 34 2016-01-28 01:19:21 <bsm1175321> Ok
 35 2016-01-28 01:19:50 <gmaxwell> mrkent: you're asking about rather orthorgonal things.
 36 2016-01-28 01:20:44 <gmaxwell> Weak blocks are a family of techniques where miners come to some kind of (loose) agreement on what the next blocks will contain, in advance of finding them, in order to make block propagation fast.  It's something miners can do that is more or less invisible to non miners.
 37 2016-01-28 01:21:53 <gmaxwell> mrkent: extension blocks are effectively a two-way-peg but into the same blockchain, rather than a side chain.  They're almost precisely equal to a blocksize increase except with better backwards compatiblity.
 38 2016-01-28 01:22:30 <gmaxwell> segwitness is only optimizing witness data (signatures, fraudproofs, etc.) -- so the tracking of the set of spendable coins is unchanged.
 39 2016-01-28 01:24:41 <kanzure> i do not believe the default git configuration fetches all of the github-posted pull requests, which are sourced from other remote branches on remote repositories. if there's a way to switch this, i would appreciate hearing.
 40 2016-01-28 01:24:45 <mrkent> I see. Weak block and extension blocks can be effectively be implemented together right?
 41 2016-01-28 01:25:21 <gmaxwell> mrkent: in the sense that most unrelated things could be implemented togeather. Yes.
 42 2016-01-28 01:25:34 <gmaxwell> I don't believe anyone working on the bitcoin software finds extension blocks interesting.
 43 2016-01-28 01:25:44 <gmaxwell> at least not currently.
 44 2016-01-28 01:26:57 <mrkent> gmaxwell: why not?
 45 2016-01-28 01:27:01 <bsm1175321> gmaxwell: Given core's lack of a serious proposal for capacity increases, I proposed extension blocks for that purpose in my above blog post.
 46 2016-01-28 01:27:30 <bsm1175321> I think a strict extension block would be a bad idea, it's better to evaluate some of the more advanced proposals like subchains/braids/NG.
 47 2016-01-28 01:28:36 <gmaxwell> mrkent: because they carry virtually every negative consequence of a blocksize increase.
 48 2016-01-28 01:29:03 <kanzure> bsm1175321: the origin of extension blocks is mostly from heavily-involved-core-related contributors or peoples... i'm not sure it's safe to say that core never thought about extension blocks.
 49 2016-01-28 01:29:37 <mrkent> minus a hardfork, which arguably is the worst consequence of blocksize increase
 50 2016-01-28 01:29:37 <TD-Linux> kanzure, pull requests are metadata outside of git, so there is no way for git itself to see them
 51 2016-01-28 01:29:38 <gmaxwell> bsm1175321: Core has a published capacity roadmap. I find your "lack of a serious proposal" to be highly disrespectful.
 52 2016-01-28 01:30:09 <bsm1175321> gmaxwell: That proposal does not contain an actual proposal.
 53 2016-01-28 01:30:15 <kanzure> TD-Linux: actually i believe github silently copies over all pull-request-related branches into the current repository into a specific namespace, like "_____{xyz}", but yea by default github does not serve up those branches when you run "git fetch".
 54 2016-01-28 01:31:33 <bsm1175321> kanzure: I'm not saying that.  But I think there is a perception that core is opposed to capacity increases.  I just wanted to point out that there exists a soft-fork capacity extension mechanism, to smooth some ruffled feathers by those joining the classic camp...
 55 2016-01-28 01:31:46 <gmaxwell> bsm1175321: I'm disappointed that you think it's appropriate to effectively call me a liar to my face.
 56 2016-01-28 01:32:13 <kanzure> this conversation just got really confusing. is bsm1175321 unaware of the capacity increases plans?
 57 2016-01-28 01:32:19 <brg444> "opposed to a capacity increase"?
 58 2016-01-28 01:32:22 <kanzure> but why does he know about segwit?
 59 2016-01-28 01:32:55 <bsm1175321> Those are: segwit (which as a capacity increase is poor), plus Lightning.
 60 2016-01-28 01:33:07 <bsm1175321> What have I missed?
 61 2016-01-28 01:33:09 <moli> lol he's been advertising his "braids" or something that seems very confusing
 62 2016-01-28 01:33:14 <kanzure> bsm1175321: you have missed almost everything :)
 63 2016-01-28 01:33:24 <bsm1175321> gmaxwell: By no means do I intend to call you a liar.
 64 2016-01-28 01:33:31 <gmaxwell> bsm1175321: It appears you haven't read the document; but moreover; the "classic" advocates are calling for something which capacity awful close to segwitness.
 65 2016-01-28 01:34:11 <gmaxwell> And their complaint about segwit is that it's 'complex'-- an argument that you've not addressed with calling for extension blocks.
 66 2016-01-28 01:34:18 <mrkent> I think the capacity increase bsm1175321 is talking about a blocksize increase. The roadmap offers many things that can make a blocksize increase easier to do.
 67 2016-01-28 01:34:46 <kanzure> mrkent: that's not true; he wouldn't be talking about extension blocks. but he is.
 68 2016-01-28 01:34:51 <bsm1175321> mrkent: exactly.  I'd say "safer".
 69 2016-01-28 01:36:39 <bsm1175321> I really don't think I missed anything.  But please correct me if I'm wrong.
 70 2016-01-28 01:36:54 <MrHodl> Non consensus hardfork is safer?
 71 2016-01-28 01:37:09 <brg444> The part where hardforks are not safer under current conditions.
 72 2016-01-28 01:37:58 <gmaxwell> he's arguing that an extension block is safer; and it is against safty considerations that basically no one is currently rasing. (except luke perhaps)
 73 2016-01-28 01:38:02 <maaku> kanzure TD-Linux : you can configure your own git repo such that 'git fetch' retrieves pull requests too
 74 2016-01-28 01:38:07 <kanzure> bsm1175321: how about the part about everything that wasn't segwit or lightning?
 75 2016-01-28 01:38:21 <kanzure> bsm1175321: weak blocks, iblt, etc. this is silly. go read the document.
 76 2016-01-28 01:38:27 <kanzure> flexcap?
 77 2016-01-28 01:38:29 <bsm1175321> kanzure: weak blocks are not a capacity nicrease.
 78 2016-01-28 01:38:37 <bsm1175321> They are orphan mitigation
 79 2016-01-28 01:38:39 <kanzure> aren't you a physicist?
 80 2016-01-28 01:38:51 <kanzure> capacity is a dimensionless unit, you know...
 81 2016-01-28 01:39:15 <TD-Linux> maaku, this is amazing, I've been wasting all my time until now adding remotes
 82 2016-01-28 01:39:34 <mrkent> kanzure: the capacity (i think) we're talking about here is measured in bytes dude
 83 2016-01-28 01:39:35 <kanzure> maaku: oh it's a github option?
 84 2016-01-28 01:39:40 <maaku> kanzure: http://blogs.atlassian.com/2014/08/how-to-fetch-pull-requests/
 85 2016-01-28 01:40:05 <maaku> kanzure: github exposes pulls on a particular remote/pr/xxx refspec
 86 2016-01-28 01:40:24 <maaku> the default git configuration doesn't fetch this, but it's a one-line change to your .git/config file
 87 2016-01-28 01:40:41 <kanzure> aha, "fetch = +refs/pull/*/head:refs/remotes/upstream/pr/*"
 88 2016-01-28 01:40:53 <kanzure> maaku: gah i didn't know that prefix. i thought it was "_____{something}". geeze. interesting.
 89 2016-01-28 01:42:19 <kanzure> i wonder if "fetch github -a" grabs those.
 90 2016-01-28 01:43:01 <gmaxwell> I learned this trick from sipa.
 91 2016-01-28 01:44:15 <kanzure> i think github was originally doing this so that people could delete their repos after they submit a pull request but before the pull request was merged into the target repo
 92 2016-01-28 01:47:18 <bsm1175321> (obviously)  I still don't think I'm missing anything.
 93 2016-01-28 01:47:49 <mrkent> "The actual effect of these technologies is unknown, but scaling now with a soft fork that has wide consensus allows us to obtain the immediate gains, test and measure the mid-term possibilities, and use that data to formulate long-term plans."
 94 2016-01-28 01:48:20 <bsm1175321> What did I do to piss him off? I seriously have nothing but respect for the guy and appreciate his post...
 95 2016-01-28 01:48:47 <TD-Linux> bsm117532, you could have said "I don't think the plan scales fast enough"
 96 2016-01-28 01:49:19 <bsm1175321> I don't think that.  Others do.  I only wanted to point out that there is a faster scaling soft-fork mechanism.
 97 2016-01-28 01:49:34 <TD-Linux> bsm117532, right, but that's what you said
 98 2016-01-28 01:49:37 <bsm1175321> I agree 100% with his post and I don't think we need a larger block size now.
 99 2016-01-28 01:49:38 <mrkent> greg is probably just on the edge from >6 months of drama
100 2016-01-28 01:49:52 <maaku> bsm1175321: there is a complicated assortment of factors that cause bitcoin's capacity to be limited. each of them has to be addressed in order to safely raise a cap
101 2016-01-28 01:50:04 <maaku> bsm1175321: please read the faq and statements for more detail
102 2016-01-28 01:50:08 <bsm1175321> I know.  I've seen some of his reddit posts. The poor guy needs a vacation.
103 2016-01-28 01:50:08 <kanzure> mrkent: perhaps he has deeper epistemic complaints about bsm1175321 and other behavior other than just "drama".
104 2016-01-28 01:50:21 <moa> git goes down ... flame warm erupts on dev IRC within minutes
105 2016-01-28 01:50:34 <TD-Linux> git still works perfectly fine :)
106 2016-01-28 01:50:35 <kanzure> oh you guys were noticing github unicorns too?
107 2016-01-28 01:50:35 <moa> idle hands are the devil's tools
108 2016-01-28 01:51:15 <bsm1175321> Apparently I pissed off gmaxwell at some point, dunno how or why.  something to do with epistemology or something.
109 2016-01-28 01:51:37 <TD-Linux> bsm117532, for future reference I will tell you why: <bsm1175321> gmaxwell: That proposal does not contain an actual proposal.
110 2016-01-28 01:52:03 <kanzure> TD-Linux: that doesn't sound like "because drama" to me, heh
111 2016-01-28 01:52:16 <bsm1175321> TD-Linux: Thanks.  I should have worded that: "that proposal doesn't contain a proposal for *bandwith*based*increases* in capacity".
112 2016-01-28 01:52:47 <bsm1175321> word suck.
113 2016-01-28 01:52:49 <kanzure> i'm not sure that one is true either; smoothing out the bandwidth spikiness is an increase in capacity in at least some sort of dimension.
114 2016-01-28 01:52:51 <bsm1175321> *words
115 2016-01-28 01:52:51 <TD-Linux> bsm117532, but that would also be wrong because it has a nearly 2x bandwidth increase. but yes even that wording would be more respectful
116 2016-01-28 01:53:55 <TD-Linux> at least then you can discuss whether segwit would count as a bandwidth increase. but having a discussion around "is your proposal a proposal" is impossible.
117 2016-01-28 01:53:59 <maaku> bsm1175321: you are also confusing capacity (what the system is theoretically capable of supporting) with permitted scaling (what the system is artificially limited to support)
118 2016-01-28 01:55:00 <bsm1175321> maaku: I think everyone is making that confusion.  And you're referring to payment channels...which happen with or without a blocksize increase and are not enough.
119 2016-01-28 01:55:50 <brg444> It's a process, nothing on its own is enough. There's no magic solution.
120 2016-01-28 01:56:20 <brg444> All things that are addressed in the capacity roadmap.
121 2016-01-28 01:59:23 <maaku> bsm1175321: no I am not referring to payment channels only
122 2016-01-28 01:59:53 <maaku> e.g. weak blocks could potentially spread out transaction transmission so as to allow more transactions per block
123 2016-01-28 01:59:59 <maaku> please read the faq and such
124 2016-01-28 02:01:47 <bsm1175321> I have read the damn FAQ.  Weak blocks are not a capacity increase.  I don't understand why you're claiming they do.
125 2016-01-28 02:02:51 <bsm1175321> Maybe a <10% increase by reducing the orphan rate.  Is that what you mean?
126 2016-01-28 02:39:19 <Luke-Jr> bsm1175321: weak blocks + IBLT reduce the size of the time-critical block data.
127 2016-01-28 02:52:10 <bsm1175321> Luke-Jr: So they reduce the orphan rate, and through that is the only way they have any affect on transaction volume, no?
128 2016-01-28 02:53:07 <Luke-Jr> bsm1175321: stale rate*, which is a primary factor in what size blocks the network can handle
129 2016-01-28 02:53:30 <bsm1175321> terminology.  Yes stale rate.
130 2016-01-28 02:59:01 <phantomcircuit> Luke-Jr, block switching time is the short term critical piece
131 2016-01-28 02:59:19 <phantomcircuit> long term the critical piece is initial block synchronization time
132 2016-01-28 03:00:43 <Luke-Jr> phantomcircuit: yes, but segwit probably helps that a lot
133 2016-01-28 03:04:13 <phantomcircuit> Luke-Jr, it's a constant factor reduction in the rate of growth
134 2016-01-28 03:04:24 <Luke-Jr> phantomcircuit: ?
135 2016-01-28 03:04:26 <phantomcircuit> so medium term yes, long term no
136 2016-01-28 03:04:38 <Luke-Jr> phantomcircuit: it means everything more than ~a month ago, you only need to download half of it
137 2016-01-28 03:05:45 <phantomcircuit> Luke-Jr, uh
138 2016-01-28 03:05:49 <phantomcircuit> Luke-Jr, no it doesn't
139 2016-01-28 03:06:06 <phantomcircuit> going forward that's true
140 2016-01-28 03:06:19 <Luke-Jr> going forward is the non-constant..
141 2016-01-28 03:06:37 <bsm1175321> You guys get weak blocks implemented and the orphan rate will be <~ 1%.  My braids will be a solution in need of a problem at that point.  :-(
142 2016-01-28 03:07:19 <phantomcircuit> bsm1175321, i do not believe it's possible to improve relay in the face of an adversary
143 2016-01-28 03:07:33 <phantomcircuit> since by definition the adversary has the data and can simply not send you pieces
144 2016-01-28 03:07:57 <bsm1175321> True.
145 2016-01-28 03:08:11 <bsm1175321> So you're saying all miners will be willing to receive weak blocks from others, but unwilling to publish them?
146 2016-01-28 03:08:46 <phantomcircuit> bsm1175321, only if they are executing some form of attack
147 2016-01-28 03:09:02 <phantomcircuit> what makes all of this dangerous is that the system will appear to be far more secure than it is
148 2016-01-28 03:09:59 <bsm1175321> How so?
149 2016-01-28 03:12:00 <phantomcircuit> bsm1175321, "stale block rate is only 0.1%, wow amazing! blocks can be 20MB now!" except actually the moment a miner runs a selfish mining attack the stale rate would explode to >20% for other pools
150 2016-01-28 03:12:30 <bsm1175321> Interesting argument.
151 2016-01-28 03:19:02 <phantomcircuit> bsm1175321, i have so far not had anybody make an even half reasonable argument that the position is wrong
152 2016-01-28 03:19:17 <bsm1175321> I would say you're right.
153 2016-01-28 03:20:43 <bsm1175321> Well as part of braids, it's necessary to move the coinbase reward to be past-looking.  It's really the fact that blocks contain a payout, and can be relative orphans, that enables selfish mining to work.  So I kill two birds with one stone there.
154 2016-01-28 03:21:54 <bsm1175321> It's the coinbase that forces the blocks to be relative double-spends.  All other transactions could be identical.  (And would be, with weak blocks)
155 2016-01-28 03:25:30 <Luke-Jr> phantomcircuit: well, if nobody *tries* to break it, we're still ok
156 2016-01-28 03:25:33 <Luke-Jr> /s
157 2016-01-28 09:34:59 <thermoman> wumpus: thanks
158 2016-01-28 11:33:31 <blur3d> like losing a founder, if you were to move on, bitcoin would literally lose part of it’s soul. So thank you all :)
159 2016-01-28 11:33:31 <blur3d> To the Core Devs, I’d just like to let you know that you guys are amazing. Keep on doing what you are doing. Ignore all the side channel trash, and just do what you do best. Great work on the improved communication, I think it’s a great start, and definately positive for the community. You guys are really working on some cutting edge stuff, and considering no one knows exactly where it’s going, you guys are on top of it.
160 2016-01-28 11:34:16 <wumpus> thanks blur3d :)
161 2016-01-28 13:44:37 <priidu> what datatype does Bitcoin Core use to return the current network hashrate?
162 2016-01-28 13:44:46 <priidu> e.g. the "getnetworkhashps" command
163 2016-01-28 13:45:50 <priidu> if its an unsigned 64-bit integer, we're probably about 1/20 way there to it wrapping :P
164 2016-01-28 13:51:11 <priidu> (more on this in #bitcoin, if it's a valid concern)
165 2016-01-28 13:52:17 <priidu> mostly a concern for interfacing software, though
166 2016-01-28 13:52:39 <priidu> for example, all the Java wrappers I've seen use "long" instead of "BigInteger" to hold the network hash rate
167 2016-01-28 13:55:39 <priidu> in which case:
168 2016-01-28 13:55:42 <priidu> 9 223 372 036 854 775 807 (Long.MAX_VALUE)
169 2016-01-28 13:55:50 <priidu> 1 073 000 000 000 000 000 (Network hashrate a few days ago)
170 2016-01-28 14:14:14 <nibbler> priidu: hasrate is not reported by core
171 2016-01-28 14:16:15 <nibbler> or is it?
172 2016-01-28 14:17:40 <priidu> nibbler: iirc, both the "getnetworkhashps" and "getmininginfo" commands return it
173 2016-01-28 14:17:50 <priidu> maybe there are more
174 2016-01-28 14:17:55 <priidu> but those pop to mind first
175 2016-01-28 15:23:53 <priidu> either way, it won't be a critical problem for a while still
176 2016-01-28 15:24:07 <priidu> but still food for thought
177 2016-01-28 16:44:49 <qsipp> anyone active?
178 2016-01-28 16:49:54 <btcdrak> what's up?
179 2016-01-28 17:18:47 <priidu> any takers on my question from before? :P
180 2016-01-28 17:19:58 <priidu> http://bitcoinstats.com/irc/bitcoin-dev/logs/2016/01/28#l1453988677.0
181 2016-01-28 17:42:21 <kanzure> https://mta.openssl.org/pipermail/openssl-announce/2016-January/000061.html
182 2016-01-28 18:50:37 <Luke-Jr> possible topic-- priority: what do I need to fix and/or expand my maintaining-scope to include, to keep it?
183 2016-01-28 18:54:05 <Luke-Jr> but I may be driving for part of the meeting..
184 2016-01-28 18:56:29 <jtimon> possible topic: "refactoring window" when is that?
185 2016-01-28 18:57:35 <Tasoshi> possible topic: "the blocksize question" Are we to prioritise scaling onchain or are we to prioritise ripple like settlement systems?
186 2016-01-28 19:00:17 <cfields> Tasoshi: this is a technical discussion
187 2016-01-28 19:01:09 <wumpus> #startmeeting
188 2016-01-28 19:01:10 <lightningbot`> Meeting started Thu Jan 28 19:01:09 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
189 2016-01-28 19:01:10 <lightningbot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
190 2016-01-28 19:01:25 <petertodd> hi
191 2016-01-28 19:01:43 <wumpus> #topic refactoring window
192 2016-01-28 19:02:06 <jtimon> I just want to have a clearer idea of when those are
193 2016-01-28 19:02:27 <wumpus> I'm fine with starting moveonly stuff at least - I've already merged #7348
194 2016-01-28 19:02:32 <jtimon> and what it means when we're on a "refactoring window"
195 2016-01-28 19:02:54 <wumpus> we're nearing the 0.12 release, and there's not that much urgent to be merged otherwise
196 2016-01-28 19:03:10 <petertodd> note that there is significant segwit work that is affected by this, OTOH, it may not be affected in a way that matters
197 2016-01-28 19:03:29 <what_now> Hello, sometimes I get a time out on rpc calls to bitcoind. I am using 0.11.2. I have a big wallet file(big keypool). The slowdown occurrs upon all commands(example wallet decryption too) not just sending out funds.
198 2016-01-28 19:03:44 <wumpus> not sure about that petertodd, but they're based on 0.12 AFAIK
199 2016-01-28 19:03:46 <petertodd> what_now: we're in the middle of a dev meeting; best if you ask again in an hour
200 2016-01-28 19:03:48 <jonasschnelli> what_now: please use #bitcoin-core-dev (meeting in this channel)
201 2016-01-28 19:03:57 <Luke-Jr> jtimon: can you prioritise refactors gthat dont conflict segwit?
202 2016-01-28 19:04:21 <petertodd> wumpus: yeah, being based on v0.12 is part of what helps here
203 2016-01-28 19:04:23 <wumpus> so it doesn't affect segwit immedaitely, although at some point it needs to be forward-ported over the moves
204 2016-01-28 19:04:34 <what_now> Ok thanks
205 2016-01-28 19:04:47 <wumpus> (which for pure move-only isn't too much effort, at least)
206 2016-01-28 19:04:54 <petertodd> wumpus: I'm assuming we're most likely to release segwit first as a 0.12.x?
207 2016-01-28 19:05:09 <wumpus> petertodd: I suppose so
208 2016-01-28 19:05:21 <wumpus> 0.13 will be june-july
209 2016-01-28 19:05:22 <btcdrak> petertodd: ofc, 0.13 isnt scheduled for months yet
210 2016-01-28 19:05:24 <gmaxwell> It previously occured to me that having refactor windows at the beginning of a version cycle may interfear with the constant backporting we do then.
211 2016-01-28 19:05:39 <Luke-Jr> but it should be merged to master first
212 2016-01-28 19:05:40 <jtimon> petertodd: my longest consensus refactoring branch is based on last-0.11.99 3cd836c
213 2016-01-28 19:06:02 <wumpus> gmaxwell: it does, but 0.12.0 final is near, I don't expect much more backporting to be needed now
214 2016-01-28 19:07:17 <wumpus> we'll do a rc3 next week and if really necessary a rc4 the week after that and then that's that
215 2016-01-28 19:07:44 <jtimon> Luke-Jr: if we don't want to backport refactors with segwit and we want to wait for segwit, then the 0.13 refactor window may be missed again for really simple things like #7310, which I assume you consider conflicting with segwit
216 2016-01-28 19:08:52 <jtimon> gmaxwell: yeah, that's what I've been saying since the first time we talked about this windows, I think they are far best at the end of the release cycle, before forking the next version to release from master
217 2016-01-28 19:09:08 <Luke-Jr> jtimon: I was thinking more like closing refactors a week after segwsit
218 2016-01-28 19:09:17 <gmaxwell> I guess the thing to admit is that there is no good time for refactors, and that we'll just have to deal with their costs.
219 2016-01-28 19:09:40 <gmaxwell> jtimon: thats a point.
220 2016-01-28 19:09:43 <wumpus> yes, otherwise you keep postponing
221 2016-01-28 19:09:58 <jtimon> if we had done it before forking 0.12...I really think that's the best time (doesn't mean that it won't have costs)
222 2016-01-28 19:10:05 <wumpus> as said above, I'd say now is a pretty good time, but if people prefer postponing I won't complain, it's always a bad time
223 2016-01-28 19:10:24 <wumpus> no, before forking 0.12 it was *really* busy
224 2016-01-28 19:10:35 <wumpus> all kinds of stuff that needs to b e merged as soon as possible
225 2016-01-28 19:10:55 <wumpus> at least it came to rest a bit now
226 2016-01-28 19:12:25 <btcdrak> yeah, a lot of PRs are mergeable now without needing rebased.
227 2016-01-28 19:12:38 <Luke-Jr> imo do non-SW-conlicts first and if we end up conflicting anyway so be it
228 2016-01-28 19:12:40 <wumpus> but there's nothing that needs to be merged urgently
229 2016-01-28 19:13:25 <jtimon> Luke-Jr: better yet, what about not bip68-112-conflicting, not versionbits conflicting and non-segwit conflicting ?
230 2016-01-28 19:13:33 <btcdrak> I do think it's time to start thinking about merging #7184 and #6564 after they get a few more ACKs
231 2016-01-28 19:13:42 <wumpus> in contrast to before a release deadline, when there's pressure to get things in
232 2016-01-28 19:13:45 <jtimon> </sarcasm>
233 2016-01-28 19:13:47 <petertodd> I'd vote for getting it over with now, as jtimon's been rather patient :)
234 2016-01-28 19:14:00 <petertodd> (for dev branch)
235 2016-01-28 19:15:17 <wumpus> ok, next topic?
236 2016-01-28 19:15:23 <Tasoshi> Everyone complains that the blocksize is not discussed in these meetings. So maybe it can be discussed for once?
237 2016-01-28 19:15:32 <wumpus> Tasoshi: no
238 2016-01-28 19:15:37 <Tasoshi> why not?
239 2016-01-28 19:15:47 <Tasoshi> has a decision been made on it?
240 2016-01-28 19:16:03 <maaku> Tasoshi: this is not the place
241 2016-01-28 19:16:14 <petertodd> Tasoshi: this is a technical meeting to discuss relatively short-term dev work
242 2016-01-28 19:16:23 <cfields> Tasoshi: these meetings are for our day-to-day work. We need a place for that, even if it's not sexy topics. Please respect that.
243 2016-01-28 19:16:28 <Tasoshi> maaku of course it is, it is a technical meeting, so lets discuss a technical topic, the blocksize question
244 2016-01-28 19:16:31 <wumpus> yes, we'll not do a blocksize hardfork for now
245 2016-01-28 19:16:52 <Tasoshi> so the decision is to not maxbloklimit_increase?
246 2016-01-28 19:16:53 <jonasschnelli> wumpus: +1. Next topic?
247 2016-01-28 19:17:07 <Tasoshi> until when?
248 2016-01-28 19:17:13 <gmaxwell> Tasoshi: Core has a published capacity roadmap, feel free to comment about that on the list.
249 2016-01-28 19:17:21 <Tasoshi> this isn't the core chan
250 2016-01-28 19:17:27 <Tasoshi> this is general bitcoin development
251 2016-01-28 19:17:35 <wumpus> Tasoshi: this is a bitcoin core meeting
252 2016-01-28 19:17:47 <Tasoshi> maybe core should have it's meetings in the core chan?
253 2016-01-28 19:17:50 <wumpus> Tasoshi: stop interfering
254 2016-01-28 19:17:56 <Tasoshi> I thought this was a general bitcoin dev meeting
255 2016-01-28 19:18:00 <Luke-Jr> wumpus: it is genereal bitcoin meeting..
256 2016-01-28 19:18:11 <gmaxwell> Tasoshi: please you're disrupting the meeting.
257 2016-01-28 19:18:11 <jtimon> actually he has a point, maybe these meetings should happen in #bitcoin-core-dev
258 2016-01-28 19:18:21 <jtimon> but yeah, not the time
259 2016-01-28 19:18:24 <Luke-Jr> Tasoshi: still nlo decisions are made in meetings
260 2016-01-28 19:18:30 <petertodd> jtimon: seems reasonable if this keeps coming up, but that's for next meeting
261 2016-01-28 19:18:33 <Luke-Jr> no*
262 2016-01-28 19:19:10 <wallet42> getrawtransaction works as long as a pruning is not enabled and at least 1 spendable output is still available right?
263 2016-01-28 19:19:28 <Luke-Jr> Tasoshi: email the ML to schedule a new meeting another day, maybe?
264 2016-01-28 19:19:43 <wumpus> we can move the meeting to #bitcoin-core-dev, sure
265 2016-01-28 19:19:46 <Tasoshi> or maybe you guys can actually discuss it
266 2016-01-28 19:19:48 <Tasoshi> but whatever
267 2016-01-28 19:19:54 <Tasoshi> the users are about to vote
268 2016-01-28 19:19:56 <jtimon> anyway, so the refactor window is from now to when? and what does it mean that there's a refactor window?
269 2016-01-28 19:19:57 <maaku> NEXT TOPIC
270 2016-01-28 19:20:00 <Tasoshi> you can bury your heads all you want
271 2016-01-28 19:20:02 <gmaxwell> Topic suggestion: Any outstanding issues for 0.12RC?
272 2016-01-28 19:20:34 <wumpus> #topic outstanding issues for 0.12.0
273 2016-01-28 19:20:55 <Luke-Jr> not declaring removal of priority
274 2016-01-28 19:20:56 <cfields> uhmm, it was brought to my attention that we may need to sign the win32 release with a new key for win7+
275 2016-01-28 19:21:15 <jonasschnelli> expired?
276 2016-01-28 19:21:23 <cfields> so, ignoring the fact that we need a new key in general, we can upgrade ours to work for this release
277 2016-01-28 19:21:33 <wumpus> it needs to use sha256
278 2016-01-28 19:21:36 <cfields> i believe it doesn't take long. I'll be starting that process today
279 2016-01-28 19:21:41 <cfields> right, current is sha1
280 2016-01-28 19:21:44 <jonasschnelli> ^^
281 2016-01-28 19:21:49 <btcdrak> ouch
282 2016-01-28 19:22:10 <cfields> i'll get an eta on that asap so we'll know if it's worth holding up rc3
283 2016-01-28 19:22:18 <wumpus> #action cfields: new key for win release signing
284 2016-01-28 19:22:24 <what_now> Topic suggestion: creating a roadmap for aspiring devs to catch up with code?
285 2016-01-28 19:22:33 <petertodd> cfields: do we have an idea of how many windows users test rc's btw?
286 2016-01-28 19:22:36 <btcdrak> otherwise jonasschnelli could sign, he has a key iirc
287 2016-01-28 19:22:52 <jonasschnelli> btcdrak: only OSX
288 2016-01-28 19:23:18 <petertodd> what_now: I'd suggest posting that to the dev list; also, first look at bitcoin.org's documentation efforts
289 2016-01-28 19:23:20 <jonasschnelli> petertodd: I test them.. have serval win VMs here. Although only "smoke" tests.
290 2016-01-28 19:23:24 <cfields> btcdrak: not nice to change keys during the release cycle. I believe this keeps the current chain intact
291 2016-01-28 19:23:37 <btcdrak> cfields: agree
292 2016-01-28 19:23:39 <wumpus> what_now: not really a meeting topic, better to ask that outside the meeting
293 2016-01-28 19:23:45 <what_now> Thank you petter see you in 2 years :(
294 2016-01-28 19:23:56 <cfields> petertodd: same as jonasschnelli above. I verify that they start up and are infact the correct tagged release
295 2016-01-28 19:23:59 <what_now> Roger, gonna shut up now
296 2016-01-28 19:24:08 <petertodd> jonasschnelli: cool - I was thinking that if we're not getting many windows testers, that suggests we shouldn't hold back the rc releases because of a windows-specific issue.
297 2016-01-28 19:24:27 <wumpus> well we need some key for signing, it doesn't matter too much which one
298 2016-01-28 19:24:47 <jonasschnelli> I can offer to sign the OSX binaries in future (maybe from 0.13)
299 2016-01-28 19:25:38 <cfields> makes sense to me, since you're the most active on osx these days
300 2016-01-28 19:25:38 <wumpus> cool jonasschnelli
301 2016-01-28 19:26:30 <wumpus> ok, that concludes the topic I think, we don't know how long it will take to get a new key, if it takes too long someone else can sign this time
302 2016-01-28 19:27:34 <wumpus> I mean concludes the signing topic, not the "outstanding issues" topic
303 2016-01-28 19:28:27 <wumpus> it seems there is still some controversy re: priority, or at least how the changes should be noted in the release notes
304 2016-01-28 19:28:42 <wumpus> e.g. https://github.com/bitcoin/bitcoin/pull/7346
305 2016-01-28 19:28:50 <jonasschnelli> +1 for keep it as it is
306 2016-01-28 19:29:02 <gmaxwell> I realized tht we never did anything about the issue I raised with localhost being banning whitelisted + autoonion support; do we care?
307 2016-01-28 19:29:31 <petertodd> Luke-Jr: is there anything we can do to make it easier for LJR to support priority if Core doesn't?
308 2016-01-28 19:29:39 <wumpus> jonasschnelli: I'd say so too - though it makes sense to mention the plans to remove priority in the release notes
309 2016-01-28 19:30:04 <petertodd> Luke-Jr: or i should say, Bitcoin <insert-snappy-name-here> :)
310 2016-01-28 19:30:08 <jonasschnelli> Okay. I follow the majority.
311 2016-01-28 19:30:23 <petertodd> gmaxwell: link?
312 2016-01-28 19:30:41 <wumpus> gmaxwell: of course we do
313 2016-01-28 19:30:56 <wumpus> petertodd: I think that's a good question
314 2016-01-28 19:31:25 <jonasschnelli> I guess there is no reported issue.
315 2016-01-28 19:31:29 <paveljanik> The plan should have been announced even earlier. Even the change in the default priority settings.
316 2016-01-28 19:31:35 <gmaxwell> there is a blinking _pr_
317 2016-01-28 19:31:36 <wumpus> I mean some people are bound to want to keep some semblance of priority support, but supporting it in the current mempool framework is hard/inefficient
318 2016-01-28 19:31:50 <gmaxwell> I'll go rebase it and cut it down.
319 2016-01-28 19:31:58 <paveljanik> What we can do now is to announce the removal of prio code - special section in release notes, probably?
320 2016-01-28 19:32:18 <wumpus> paveljanik: yes , we should certainly announce it somewher
321 2016-01-28 19:32:22 <jonasschnelli> Okay. I'm happy to work on the banning whitelisted + autoonion support issue (start end of feb.).
322 2016-01-28 19:32:34 <wumpus> if only to get an idea what people outside direct dev circles think about it
323 2016-01-28 19:32:50 <gmaxwell> the original PR got hung up because of the locking mess around nodestats.
324 2016-01-28 19:32:59 <wumpus> I'm happing to work on it too, but after 0.12.0 release
325 2016-01-28 19:33:02 <wumpus> happy*
326 2016-01-28 19:33:09 <gmaxwell> (it's PR 7082) but I can make the change more minimal.
327 2016-01-28 19:33:16 <jonasschnelli> Yes. I guess after some changes there i'm familiar with the locking concept in CNode CNodeStat
328 2016-01-28 19:33:47 <wumpus> it's not something I have enough confidence in to get correct for a last minute fixup
329 2016-01-28 19:34:08 <jonasschnelli> Wasn't aware of that PR (7082). Will test / rebase and or extend.
330 2016-01-28 19:34:09 <gmaxwell> wumpus: yes, I can just change the patch to remove the privledging of localhost only.
331 2016-01-28 19:34:26 <wumpus> gmaxwell: yep, if we can slip in some simpler fix that'd be better
332 2016-01-28 19:34:30 <jonasschnelli> No. I guess its for 0.13 or 0.12.1?
333 2016-01-28 19:34:35 <wumpus> then leave the rest for 0.13/0.12.1
334 2016-01-28 19:34:46 <gmaxwell> jonasschnelli: please lt me. I just wanted confirmation that it wasn't intentionally dropped.
335 2016-01-28 19:34:59 <jonasschnelli> Sure.
336 2016-01-28 19:35:03 <gmaxwell> yea, just the one line change should at least avoid the simple attack, I'll do that.
337 2016-01-28 19:35:08 <wumpus> no, certainly not intentionally, it's just easy to forget about things
338 2016-01-28 19:35:14 <jonasschnelli> Do we need a solution for this in 0.12.0?
339 2016-01-28 19:35:27 <gmaxwell> Thats why I brought it up.
340 2016-01-28 19:35:40 <jtimon> jonasschnelli: the one line change ?
341 2016-01-28 19:35:53 <gmaxwell> Please see the PR, without doing something the autoonion support makes connection exhaustion attacks much easier.
342 2016-01-28 19:35:56 <wumpus> #action gmaxwell: "one line change" to fix #7082 in 0.12.0
343 2016-01-28 19:36:02 <gmaxwell> Thanks.
344 2016-01-28 19:36:04 <jonasschnelli> +75 −37 in main/net seems to late for a after-rc2-change
345 2016-01-28 19:36:17 <jonasschnelli> ok. Agree.
346 2016-01-28 19:36:58 <petertodd> gmaxwell: so, specifically you're worried about exhausting all incoming connections right?
347 2016-01-28 19:37:37 <wumpus> yes, it's about incoming connections
348 2016-01-28 19:38:29 <gmaxwell> petertodd: yes we have eviction to protect from that but localhost is excempted.
349 2016-01-28 19:38:29 <paveljanik> I think we should also announce somewhere that current openssl bugs do not affect Bitcoin Core...
350 2016-01-28 19:38:49 <wumpus> good idea paveljanik
351 2016-01-28 19:39:07 <jonasschnelli> +1
352 2016-01-28 19:39:14 <wumpus> #topic how does this new "critical" OpenSSL release affect us
353 2016-01-28 19:39:17 <jonasschnelli> btcdrak: a website blog post?
354 2016-01-28 19:39:37 <wumpus> <kanzure> https://mta.openssl.org/pipermail/openssl-announce/2016-January/000061.html
355 2016-01-28 19:39:42 <btcdrak> jonasschnelli: sure.
356 2016-01-28 19:39:43 <wumpus> #link https://mta.openssl.org/pipermail/openssl-announce/2016-January/000061.html
357 2016-01-28 19:40:00 <wumpus> nothing that affect us in any way?
358 2016-01-28 19:40:15 <jonasschnelli> Does it not affect bip70 / GUI? (haven't checked)
359 2016-01-28 19:40:16 <wumpus> also not for qt payment protocol TLS stuff?
360 2016-01-28 19:41:13 <gmaxwell> I wish we had some way of measureing if that stuff was ever used, it seems barely usable (send only, gui only) to me and has been a source of multiple problems.
361 2016-01-28 19:41:18 <jtimon> did the replacement for the wallet encription PR get merged? what other parts of core still depend on openssl apart from bip70?
362 2016-01-28 19:41:30 <wumpus> yes, it is being used
363 2016-01-28 19:42:00 <jonasschnelli> jtimon: entropy, AES (wallet), bip70
364 2016-01-28 19:42:19 <wumpus> jtimon: no, I think those all need rebase
365 2016-01-28 19:42:22 <jonasschnelli> jtimon: and the wallet encryption PR from cfields is not yet merged.
366 2016-01-28 19:42:40 <wumpus> I think they're all labeled 0.13
367 2016-01-28 19:42:43 <jtimon> thanks
368 2016-01-28 19:42:44 <jonasschnelli> and sipa/gmaxwells fortuna change needs also rebase.
369 2016-01-28 19:43:01 <jonasschnelli> (although we should pack it into a sep. library)
370 2016-01-28 19:43:04 <cfields> wumpus: according to that mail, 1.0.1 isn't affected
371 2016-01-28 19:43:17 <gmaxwell> vetting if any particular openssl release impacts the BIP70 implementation is too much work; I'd generally be unwilling to sign off on a claim that it didn't.  The amount of involved code is huge, including a bunch of code in QT.
372 2016-01-28 19:43:19 <cfields> (not discounting self-builders of course, just pointing that out)
373 2016-01-28 19:43:36 <wumpus> yes, fortuna needs to be a separate lib
374 2016-01-28 19:43:49 <jtimon> are there any plans to replace openssl for entropy?
375 2016-01-28 19:44:01 <jonasschnelli> I would say static builds are nice,.. but the once we need to care about are the once that self-compile.
376 2016-01-28 19:44:02 <wumpus> jtimon: yes
377 2016-01-28 19:44:29 <jtimon> wumpus: oh, I see, that's the fortuna thing
378 2016-01-28 19:44:32 <petertodd> jtimon: that's what the fortuna thing would be basically
379 2016-01-28 19:44:41 <wumpus> jtimon: https://github.com/bitcoin/bitcoin/pull/5885
380 2016-01-28 19:44:44 <wumpus> gmaxwell: agree on that
381 2016-01-28 19:45:25 <wumpus> gmaxwell: I don't expect that from you either - my question was more "does it affect TLS usage"
382 2016-01-28 19:45:28 <jonasschnelli> I would also see it as a plain C(89 or 99) library
383 2016-01-28 19:46:00 <petertodd> jonasschnelli: fortuna? why isn't C++ ok here?
384 2016-01-28 19:46:07 <wumpus> as openssl is basically one huge TLS library I expect the answer to that is "yes"
385 2016-01-28 19:46:08 <jonasschnelli> petertodd: MCU
386 2016-01-28 19:46:26 <petertodd> jonasschnelli: oh, you mean for microprocessors?
387 2016-01-28 19:46:27 <gmaxwell> jonasschnelli: there are many difficult complications in making a safe, generic RNG, first among them is fork detection; which is more or less impossible to do completely safely on linux. :(
388 2016-01-28 19:46:55 <wumpus> gmaxwell: we only have to be better than openssl
389 2016-01-28 19:47:13 <gmaxwell> (even if you do the slow thing of testing the PID on every call, a sequence of multiple forks could leave you with the same PID as a now-gone grandparent process)
390 2016-01-28 19:47:13 <jonasschnelli> I would say libsecp256k1 together with a C based fort. implementation would be a very good team.
391 2016-01-28 19:47:14 <petertodd> wumpus: we still have to be better than /dev/urandom :)
392 2016-01-28 19:47:21 <wumpus> if it's impossible to do safely on linux, then openssl doesn't do that either
393 2016-01-28 19:47:41 <wumpus> note also that bitcoin never forks
394 2016-01-28 19:47:46 <jonasschnelli> Long term, i don't think entropy really matters for bitcoin core
395 2016-01-28 19:47:55 <wumpus> (well, it does, but only to launch ancillary processes)
396 2016-01-28 19:47:56 <gmaxwell> wumpus: yes but when we must be a library we need to be safe for more than bitcoin.
397 2016-01-28 19:48:02 <jonasschnelli> Mainly for the const time hack in libsecp
398 2016-01-28 19:48:14 <jonasschnelli> I don't expect people generating keys on the same machine then core runs.
399 2016-01-28 19:48:14 <wumpus> gmaxwell: just add a disclaimer 'not fork safe'
400 2016-01-28 19:48:35 <wumpus> I don't think it needs to satisfy any possible use case everyone can have
401 2016-01-28 19:48:39 <jonasschnelli> 'not fork safe'? HW or SF....
402 2016-01-28 19:48:42 <btcdrak> "<@wumpus> note also that bitcoin never forks"
403 2016-01-28 19:48:44 <jonasschnelli> </funmode>
404 2016-01-28 19:48:47 <cfields> lol
405 2016-01-28 19:48:54 <wumpus> LOL btcdrak
406 2016-01-28 19:48:56 <petertodd> wumpus: see, that's one of the reasons I'd lean towards C++ - I'm not sure we want to be in the business of making these libraries if others' will use them
407 2016-01-28 19:48:58 <wumpus> hadn't even thought of that
408 2016-01-28 19:49:03 <gmaxwell> thata going to get misunderstood by the public...
409 2016-01-28 19:49:08 <jonasschnelli> hehe
410 2016-01-28 19:49:35 <cfields> petertodd: c++11 even has fancy prngs built-in...
411 2016-01-28 19:49:41 <cfields> though i doubt that would go over well
412 2016-01-28 19:50:31 <wumpus> in any case, I thin kfor seperation of concerns it needs to be a seperate lib, if it ever turns out useful for anyone else is not our problem ;)
413 2016-01-28 19:50:59 <gmaxwell> in any case, these also need locking; ... regardless, I spent a fair amount of time talking to nick from tor about this, and I'm also on a mailing list of people trying to replace the RNG in openssl.  I'm now pretty confident that we wouldn't be able to satisify that many people; lots of people care greatly about really high performance, which we more or less don't care about. (OpenSSL's is exception
414 2016-01-28 19:51:05 <gmaxwell> ally slow, and we've seldom noticed)
415 2016-01-28 19:51:16 <gmaxwell> wumpus: Sorry, I don't beleive in that "not our problem" approach. :)
416 2016-01-28 19:51:17 <wumpus> though if jonasschnelli has applications in mind himself then it makes sense to keep those in mind
417 2016-01-28 19:51:29 <wumpus> gmaxwell: we can't do everything for everyone
418 2016-01-28 19:51:44 <wumpus> gmaxwell: well you are welcome to try, of course :)
419 2016-01-28 19:52:16 <gmaxwell> We're going off on a tangent here in any case.
420 2016-01-28 19:52:28 <btcdrak> -wizards
421 2016-01-28 19:52:36 <wumpus> but sure, we can stay with openssl's RNG if that's what is preferred
422 2016-01-28 19:52:44 <gmaxwell> I'm not saying that.
423 2016-01-28 19:52:44 <wumpus> no decision needs to be made today
424 2016-01-28 19:52:46 <wumpus> next topic?
425 2016-01-28 19:53:21 <wumpus> only ~7 minutes left
426 2016-01-28 19:53:23 <petertodd> wumpus: I just posted some important stuff re: segwit upgrades, but I don't think it needs to be discussed here yet
427 2016-01-28 19:53:32 <jtimon> wumpus let's leave openssl only for bip70, even if it's not today
428 2016-01-28 19:53:32 <petertodd> wumpus: (posted to the -dev list)
429 2016-01-28 19:53:53 <wumpus> jtimon: I agree with that in theory, but if making our own RNG is really so dangerous I don't want to risk it
430 2016-01-28 19:54:46 <petertodd> wumpus: I'd feel happier if this was part of an effort including non-bitcoin users (e.g mailing list & tor that gmaxwell mentioned above)
431 2016-01-28 19:54:51 <wumpus> it is a really risky endavour to implement this kind of stuff ourselves and get it completely right, many people are messed up before with hand rolled RNGs in the bitcoin space
432 2016-01-28 19:54:53 <jtimon> wumpus: maybe not for 0.13, but I trust that we will have done it already be 0.20 :p
433 2016-01-28 19:55:02 <jtimon> s/be/by
434 2016-01-28 19:55:07 <wumpus> petertodd: agree
435 2016-01-28 19:55:25 <gmaxwell> wumpus: please don't punish me for speaking frankly. The prior efforts to upgrade ours were derailed by a desire to make something generic. I've determined that making something generic is quite hard to do right.
436 2016-01-28 19:55:34 <wumpus> so I'm just trying to be pragmatic, yes we'd like to get rid of openssl dependency but not at all cost
437 2016-01-28 19:55:49 <gmaxwell> I think it would be a worthwhile thing to do, but I don't think the resources can be spared to do something generic right now.
438 2016-01-28 19:55:52 <wumpus> gmaxwell: how am I punuishing you?
439 2016-01-28 19:55:59 <jonasschnelli> gmaxwell: Agree. It takes much more time..
440 2016-01-28 19:56:07 <jonasschnelli> But maybe other are ready to contribute.
441 2016-01-28 19:56:19 <gmaxwell> wumpus: by jumping to not doing it at all when I raised a single complaints.
442 2016-01-28 19:56:22 <jonasschnelli> (and I have use cases)
443 2016-01-28 19:56:33 <wumpus> gmaxwell: I'm not saying we should do it, just that we should be careful
444 2016-01-28 19:56:40 <gmaxwell> Sure.
445 2016-01-28 19:56:45 <wumpus> gmaxwell: I've been saying that from the beginning and you convinced me to be even more
446 2016-01-28 19:56:49 <petertodd> jonasschnelli: if your usecases are solidly separated from Bitcoin Core, that'd help re: review
447 2016-01-28 19:56:57 <wumpus> that's *agreeing* with you, not punishment.
448 2016-01-28 19:57:09 <jonasschnelli> petertodd: nice!
449 2016-01-28 19:57:28 <jtimon> wumpus: ok, I misinterpreted your "let's be careful when doint it" as well
450 2016-01-28 19:58:06 <btcdrak> On another note: aj has written some functional test scripts for OP_CSV (requires #7184 + #6564) https://github.com/ajtowns/op_csv-test - so anyone who wants to test those PRs has another tool at their disposal. We do need to think about wrapping those PRs up next month to keep on the roadmap schedule.
451 2016-01-28 19:58:10 <wumpus> jtimon: I haven't said "let's never do this", but I'd be fine postponing it a year or so so there can be a serious generic effort
452 2016-01-28 19:58:18 <wumpus> (as petertodd says)
453 2016-01-28 19:58:36 <petertodd> RNG's are weird after all - they're not really the same skillset as normal cryptographic code
454 2016-01-28 19:58:42 <wumpus> right.
455 2016-01-28 19:59:21 <gmaxwell> wumpus: lets disuss later in the 0.13 cycle. I think getting off of OpenSSL's is important.
456 2016-01-28 19:59:55 <wumpus> I mean for the wallet the RNG is pretty much what it all hinges on, I don't even want to think about the consequences of a bug there
457 2016-01-28 19:59:59 <wumpus> gmaxwell: sure
458 2016-01-28 20:00:14 <jtimon> wumpus:  I don't think I can contribute so I can't say much dates, just nacking the "never" I thought I heard but you didn't say
459 2016-01-28 20:00:42 <paveljanik> Getting rid of openssl sounds like a plan. Lets announce it somewhere...
460 2016-01-28 20:00:46 <wumpus> #endmeeting
461 2016-01-28 20:00:47 <lightningbot`> Log:            http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-28-19.01.log.html
462 2016-01-28 20:00:47 <lightningbot`> Meeting ended Thu Jan 28 20:00:47 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
463 2016-01-28 20:00:47 <lightningbot`> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-28-19.01.html
464 2016-01-28 20:00:47 <lightningbot`> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-28-19.01.txt
465 2016-01-28 20:01:14 <petertodd> btcdrak: "rings the bell" <- by that, you mean Bitcoin trading is closed for the day, right?
466 2016-01-28 20:01:33 <wumpus> paveljanik: as said, getting rid of openssl would be nice, but not at all cost, and there's no real urgency. THe alternatives need to be acceptable, and in the case of the RNG be need to be very sure that the replacement is up to it.
467 2016-01-28 20:01:35 <btcdrak> petertodd: bitcoin neber sleeps...
468 2016-01-28 20:01:47 <jonasschnelli> lol petertodd
469 2016-01-28 20:03:09 <gmaxwell> wumpus: basically several other people have been trying to do the 'good generic rng' thing for some time, I hoped we could combine efforts, but all I've found are critically interested in high performance, perhaps at the expense of some security; which is a fairly different use case than for us... and there are a number of nasty problems, especially when you care about high performance.
470 2016-01-28 20:03:11 <wumpus> (we can of course move forward with the less risky changes to reduce dependency on openssl)
471 2016-01-28 20:03:26 <paveljanik> wumpus, understood. But we should probably first describe where it is used and then limit reduce the dependency.
472 2016-01-28 20:03:43 <paveljanik> yes
473 2016-01-28 20:04:38 <wumpus> gmaxwell: yes, "high performance at the expense of security" that's quite the opposite case from us
474 2016-01-28 20:05:06 <wumpus> gmaxwell: at least for the key generation we need security at the expense of pretty much everything else, we have some other uses for randomness that are less critical
475 2016-01-28 20:05:14 <jonasschnelli> Yes. Bitcoin usecase does not seek HP.
476 2016-01-28 20:05:53 <gmaxwell> In particular the pid checking on every call is really bad for performance, and isn't even enough to guarentee fork safty -- though it gets pretty close.  BSD has a facility to zero a madvised page on fork which can be used for completely safe and fast fork detection, but linux doesn't have it yet.  I suspect any such library is going to be a mess of non-portable subroutines.  Which would be unfortun
477 2016-01-28 20:05:59 <gmaxwell> ate, -- I fear us having to maintain stuff thats safe/tested on many platforms (esp ones we don't care about for Core); and yet at the same time I've seen how our code gets reused and I don't really want to be the proximal cause of the next android RNG bug. :)
478 2016-01-28 20:06:01 <wumpus> some of them require quite high performance; eg. where InsecureRandom is used right now, but we don't necessarily need to replace that
479 2016-01-28 20:06:13 <gmaxwell> wumpus: yes, though except in the coin selection knapsack we really don't care about performance.
480 2016-01-28 20:06:44 <jonasschnelli> gmaxwell: but we don't need fortuna for knapsack.
481 2016-01-28 20:07:04 <wumpus> fortuna is *fast* right?
482 2016-01-28 20:07:15 <jonasschnelli> define *fast*. :)
483 2016-01-28 20:08:00 <gmaxwell> There are degrees. Nothing that does PID checking on each call is fast enough for someone using it for call per packet for encryption IVs for (say) a dns server.
484 2016-01-28 20:08:07 <wumpus> yes, I don't know, but in any case the important part is key generation for the wallet
485 2016-01-28 20:08:34 <wumpus> e.g. an extra getpid() call per key won't make much of a difference there
486 2016-01-28 20:08:40 <gmaxwell> (we have an existance proof that we don't need fast, openssl's is super slow)
487 2016-01-28 20:09:28 <gmaxwell> or rather, we did need fast-- in the coin selection, and ... that doesn't use openssl, as it didn't need to be cryptographic.
488 2016-01-28 20:09:48 <jonasschnelli> But long term: do we expect people generating keys on a "bitcoin-core machine"?
489 2016-01-28 20:09:48 <wumpus> gmaxwell: exactly, where we need fast, we don't need much security
490 2016-01-28 20:09:54 <petertodd> so, if we went with a faster, but not quite as secure generic library, and then used it with XOR read('/dev/urandom', 32) for the really critical wallet stuff, would that be ok?
491 2016-01-28 20:10:07 <wumpus> where we need security, we don't need fast
492 2016-01-28 20:10:40 <gmaxwell> petertodd: thats what I proposed on the PR. xoring with dev/urandom for key generation.
493 2016-01-28 20:11:01 <wumpus> petertodd: makes sense
494 2016-01-28 20:11:31 <gmaxwell> petertodd: my goal was to basically reduce the part that must be reviewed very carefully to only a couple lines.
495 2016-01-28 20:11:33 <petertodd> gmaxwell: I know - I mean, would that be acceptable if we also used a somewhat less secure - but faster - generic library with it? basically, I'm saying, is that level of security acceptable for all the other things we need random numbers for?
496 2016-01-28 20:12:13 <petertodd> gmaxwell: that approach might be the way to get back to something that's at least used by multiple parties outside of Bitcoin
497 2016-01-28 20:12:43 <jonasschnelli> how do we handle Win32 /dev/urandom (CryptGenRandom?)
498 2016-01-28 20:13:03 <petertodd> jonasschnelli: exactly - I guess we'd end up implementing about two or three separate OS-specific routines?
499 2016-01-28 20:13:33 <jtimon> propose (but I really hope I can make things easy enough for other to propose their own variants) is more or less final [but the branch needs much cleaning up in the implementation] and can be seen in https://github.com/jtimon/bitcoin/commits/libconsensus-f3
500 2016-01-28 20:13:33 <jtimon> quick update on libconsensus for those interested: most stable branch (should only change for backports from master and nits) is in https://github.com/jtimon/bitcoin/commits/libconsensus-p2-A and contains the open PRs #7091 #7287 #7310 #7311 . libconsensus-p2-A contains the simplest refactorings and should be enough to do libconsensus-p3-A (expose verifyHeader). The longest branch is still WIP but I believe the C API *I* am going to
501 2016-01-28 20:13:33 <wumpus> jonasschnelli: yes - that's similar to /dev/random/urandom
502 2016-01-28 20:13:48 <jonasschnelli> I think, longterm, we should prepare that entropy will be generated in tiny offline devices or additional chips in smartphone.
503 2016-01-28 20:14:01 <gmaxwell> petertodd: perhaps. There is also a schism over AES CTR based RNG (clearly fastest and most power efficient anywhere you have hardware AES) and chacha (fastest anywhere where there is no hardware AES).
504 2016-01-28 20:14:28 <wumpus> jonasschnelli: in the long term, key storage as well as generation should move to some (either by means of software or hardware) isolated device, yes
505 2016-01-28 20:14:50 <jtimon> by reviewing #7091 #7287 #7310 #7311 asap you help make https://github.com/jtimon/bitcoin/commits/libconsensus-f3 a more stable branch for people to propose their own final C APIs for libconsensus on top of
506 2016-01-28 20:14:59 <gmaxwell> petertodd: but I don't think fork safty is really negoiable in a library.
507 2016-01-28 20:15:00 <petertodd> gmaxwell: is that a pluggable option? IE, is everything but the AES vs. chacha the same?
508 2016-01-28 20:15:29 <gmaxwell> petertodd: it could be, of course that kind of complexity is despised for good reason. :)
509 2016-01-28 20:15:44 <petertodd> gmaxwell: right, so some of these users would be happy to give that up, perhaps in exchange for it being a <foo>-specific codebase?
510 2016-01-28 20:16:00 <petertodd> gmaxwell: yup
511 2016-01-28 20:16:23 <jtimon> </review begging>
512 2016-01-28 20:16:50 <petertodd> gmaxwell: have we considered making the RNG someone elses problem and using a cloud API for it? we could use micropayments to incentivise people to run the API
513 2016-01-28 20:17:30 <wumpus> jtimon: cool, I'll take a look at your proposed conseneus API soon
514 2016-01-28 20:17:49 <gmaxwell> lol
515 2016-01-28 20:18:04 <gmaxwell> petertodd: "microservice" is the trendy name, I think.
516 2016-01-28 20:18:16 <wumpus> hahahah
517 2016-01-28 20:18:42 <petertodd> the tricky part, is ensuring the RNG microservice doesn't charge macro-level fees...
518 2016-01-28 20:21:28 <jtimon> wumpus: great, as said is more unstable than p2 (just encapsulating stuff without exposing anything else), but you told me you were more interested on a candidate "final" C API to start reviewing that