1 2015-12-17 00:00:13 <BlueMatt> rusty: ya'll have thick skin, right? :P
  2 2015-12-17 00:00:57 <rusty> BlueMatt: there are some species of australian trees which require fire to germinate.  I expect to get two more kids out of this...
  3 2015-12-17 00:41:09 <ghtdak> whois evoskuil
  4 2015-12-17 01:33:25 <wangchun> Luke-Jr: I think that's a good idea
  5 2015-12-17 01:34:22 <Luke-Jr> wangchun: would email list work for this? http://list.pfoe.be/mailman/listinfo/gbt2
  6 2015-12-17 02:13:06 <Luke-Jr> cfields: https://savannah.gnu.org/forum/forum.php?forum_id=8407 FYI
  7 2015-12-17 02:13:42 <cfields> neat
  8 2015-12-17 02:13:57 <cfields> guix seems a bit.. meh, but maybe some good upstream patches will come out of it :)
  9 2015-12-17 02:22:15 <zookolaptop> cfields: what's meh about it?
 10 2015-12-17 02:25:05 <cfields> zookolaptop: nothing in particular, it just seemed to be a solution to a problem that didn't exist. determinism makes it more interesting, though.
 11 2015-12-17 02:34:52 <Luke-Jr> I wonder if it's anywhere near as capable/mature as Gentoo's Portage
 12 2015-12-17 02:35:22 <Luke-Jr> it would be nice if we didn't need to have a dedicated build system just for Core
 13 2015-12-17 02:41:42 <zookolaptop> cfields: *nod*
 14 2015-12-17 03:00:33 <morcos> jgarzik: Haven't we already had "Fee Events" already?  Seems like we've gone 7 days in a row without mempools clearing out.  As you pointed out in your defnition, the effect is the same if miners choose to not mine hard limit size blocks.
 15 2015-12-17 03:01:06 <Diablo-D3> morcos, jgarzik: well, if bitcoin is "healthy" (in the economic sense), then wouldn't a constant fee storm be the usual thing?
 16 2015-12-17 03:01:31 <Diablo-D3> the trend of fee per kb should generally be creeping up
 17 2015-12-17 03:01:36 <jgarzik> morcos, a Fee Event that leads to TFM to FFM shift.
 18 2015-12-17 03:02:19 <jgarzik> morcos, the oft-mentioned "transition to a healthy fee market" is a major economic change to bitcoin
 19 2015-12-17 03:02:23 <morcos> jgarzik: yes, and that happened once already
 20 2015-12-17 03:03:02 <morcos> it used to be the case that you could get any tx mined in a reasonable amount of time if you at least paid the hard coded min relay rate, and often even if you didn't.
 21 2015-12-17 03:03:15 <morcos> that is very different from how txs work now
 22 2015-12-17 03:03:24 <morcos> good luck getting a min relay rate tx confirmed.
 23 2015-12-17 03:03:26 <Diablo-D3> a maelstrom of fees swirling around a calm zone where blocks are formed
 24 2015-12-17 03:03:42 <Diablo-D3> morcos: yeah, but you're saying it happened once already, thats the wrong way of looking at it
 25 2015-12-17 03:03:46 <Diablo-D3> it didn't stay at "critical mass"
 26 2015-12-17 03:03:59 <morcos> It's not critical mass right now?
 27 2015-12-17 03:04:23 <Diablo-D3> Well, is it? I think the argument you're making is it has slid back from that at some point in the past
 28 2015-12-17 03:04:49 <morcos> My point is that it used to be you didn't have to worry about fee.  Any tx would get mined quickly
 29 2015-12-17 03:05:05 <morcos> Now regarldes of whether that might sometimes accidentally be the case, you have to always worry about fee.
 30 2015-12-17 03:05:06 <Diablo-D3> we cross the line when it _never_ goes back to having to never worry about the fee
 31 2015-12-17 03:05:13 <morcos> That's the major economic shift, and I think its already happened
 32 2015-12-17 03:05:19 <Diablo-D3> morcos: well
 33 2015-12-17 03:05:21 <Diablo-D3> the other side of this is
 34 2015-12-17 03:05:26 <Diablo-D3> are blocks always full?
 35 2015-12-17 03:06:32 <Diablo-D3> If blocks are always full, then yes, we've finally taken off and we're zooming through the cosmos
 36 2015-12-17 03:07:35 <Diablo-D3> morcos: I view it as like, a two stage thing
 37 2015-12-17 03:08:03 <Diablo-D3> (blocks aren't full, fee storms aren't happening), (blocks aren't full, fee storms are happening), (ITS HAPPENING.gif)
 38 2015-12-17 03:08:08 <morcos> i think primarily my point is todays situation is closer to the future, than it is to the past
 39 2015-12-17 03:08:41 <Diablo-D3> jgarzik: is there a website keeping track of how many full blocks we've produced? its not a large number right?
 40 2015-12-17 03:10:00 <jgarzik> morcos, On fees, that's today because fees are nothing.   They provide very little miner signaling.  They provide very little user signaling.  They exist mainly for DoS prevention (email #1).   Fees are range bound on the low end due to blocks-not-full-on-avg (email #1).   As long as fees are range bound at the low end, fee behavior can change and have very little impact on bitcoin economic actors of any note.
 41 2015-12-17 03:11:00 <jgarzik> morcos, we have never had blocks-full-on-avg-for-extended-period before.  That is uncharted waters.   People hope that the system will continue to work, but that is pure theory.
 42 2015-12-17 03:11:00 <zookolaptop> Excuse the naive clarifying question:
 43 2015-12-17 03:11:25 <zookolaptop> How is "blocks-not-full-on-avg" consistent with "mempools not clearing out for 7 days in a row" ?
 44 2015-12-17 03:11:42 <jgarzik> mempools never fully clear out
 45 2015-12-17 03:11:49 <zookolaptop> With regard to the TFM/FFM.
 46 2015-12-17 03:12:04 <zookolaptop> So, it's unclear to naive me if we're currently in day 7 of a TFM→FFM, or not.
 47 2015-12-17 03:12:08 <morcos> jgarzik: thats wrong though.  before july 2015, mempools completely cleared out frequently
 48 2015-12-17 03:12:53 <morcos> since july 2015, there have been extended periods of time where the backlog does not clear out
 49 2015-12-17 03:13:11 <jgarzik> morcos, if you turn off anti-spam limits that's the raw network...
 50 2015-12-17 03:13:41 <morcos> the low end of usable tx fees is no longer determined by the hard cutoff , its determined by the mkt
 51 2015-12-17 03:13:42 <jgarzik> morcos, but yes, I was referring to today, not for-all-time
 52 2015-12-17 03:14:01 <jgarzik> morcos, yes that is covered in email #1
 53 2015-12-17 03:15:49 <morcos> you seem to be saying the opposite in email 1
 54 2015-12-17 03:17:48 <morcos> My point is only this.  Yes there is an economic change between the fee market of 2014 and the future "healthy" fee market.
 55 2015-12-17 03:18:04 <morcos> I don't think it's likely that this is a clear dividing line
 56 2015-12-17 03:18:28 <morcos> And I think we're already quite a bit closer to the FFM than the 2014 market than you are giving us credit
 57 2015-12-17 03:20:18 <jgarzik> morcos, the major economic policy change & market chaos happens at blocks-full-on-avg near 1M, not small bursts from which the Users recover.
 58 2015-12-17 03:21:33 <morcos> jgarzik: Yeah I disagree with the premise.  I think users at this point have to be assuming full bursts since they might happen at any time, so they are behaving the same way as they would if blocks were full on average near 1M
 59 2015-12-17 03:21:35 <jgarzik> morcos, it is just not good policy to let bitcoin drift into that, especially contra to the desires of so many of the userbase.   1M was never meant to be the limit, and it was always the idea to increase it via hard fork when needed.
 60 2015-12-17 03:22:16 <morcos> I do agree that as the ratio of tx demand to supply goes up and up, and then fees get higher this will be continuing economic change
 61 2015-12-17 03:22:19 <morcos> but its not an "event"
 62 2015-12-17 03:22:28 <jgarzik> morcos, Getting stuck here at 1M has severe consequences for the entire bitcoin ecosystem IME.  If you cannot hard fork now, it gets much worse later - possibly in a crisis when people are even more under pressure.
 63 2015-12-17 03:25:05 <morcos> IMHO, the problem now is not technical or economic, but political/philosophical.
 64 2015-12-17 03:26:01 <aj> morcos: but if we wait, the problem will become technical and economic eventually; yes?
 65 2015-12-17 03:26:22 <morcos> A subject on which I have no great expertise, and I do wish more people were willing to compromise on what they personally want for the good of staying together as a community.
 66 2015-12-17 03:27:21 <morcos> I personally don't want to increase block size at all, but am willing to agree to something along the lines of what jgarzik suggests if thats what keeps the community together.
 67 2015-12-17 03:29:06 <morcos> aj: sure, i think i just mean that technically and economically there isn't much difference right now between nothing, segwit, small bump, small bump + segwit
 68 2015-12-17 03:30:01 <aj> morcos: ack; wasn't clear if you meant that or "technical/economic issues are clear, it's just philosophy that's left"
 69 2015-12-17 03:37:30 <kanzure> jgarzik: desires of the userbase are completely irrelevant. they could desire purple unicorns and it still wouldn't matter. desires of the developers also don't matter. i think you would experience far more productive results if you focus on how knowledge works (the total mass of all the people that think a certain opinion, does not actually change whether the idea can be successfully verified).... to say otherwise will mislead people ...
 70 2015-12-17 03:37:36 <kanzure> ... about how knowledge works...
 71 2015-12-17 03:39:10 <jgarzik> That goes against a core principle of mine in open source software - if you don't listen to the users you shouldn't be impacting users...
 72 2015-12-17 03:39:32 <kanzure> listening to users is unrelated to understanding why user-mass doesn't make things right/wrong
 73 2015-12-17 03:39:35 <morcos> kanzure: that's not entirely true though.  there is no one clear technical answer to what is safe enough for decentralizaiton / security
 74 2015-12-17 03:39:58 <kanzure> morcos: whether your statement is correct does *not* modulate whether user-mass increases idea correctness. that's absurd.
 75 2015-12-17 03:40:10 <jgarzik> The typical open source method is forking the project to fire the developers.  That is key to the health of typical open source projects.  Bitcoin is not a typical open source project or obvious consensus reasons.
 76 2015-12-17 03:40:20 <jgarzik> *for
 77 2015-12-17 03:40:24 <kanzure> are you talking about bitcoin-core?
 78 2015-12-17 03:40:34 <Luke-Jr> jgarzik: open source development doesn't impact users; what does is the users' decision to adopt said software
 79 2015-12-17 03:40:50 <kanzure> rules of knowledge seem to have been thrown out the window,
 80 2015-12-17 03:40:55 <jgarzik> Luke-Jr,  it does indirectly
 81 2015-12-17 03:41:01 <kanzure> it's important to specify which rules you consider reasonable (for knowledge) otherwise this is pointless
 82 2015-12-17 03:41:13 <Luke-Jr> jgarzik: in this case, we have a unique situation that does not exist in other software
 83 2015-12-17 03:41:22 <jgarzik> kanzure, Kinda pointless for most of us to work on software that drives away users or has no users :)
 84 2015-12-17 03:41:29 <jgarzik> Luke-Jr, nod, that's what I just said
 85 2015-12-17 03:41:44 <kanzure> jgarzik: that's completely unrelated to what i just wrote.
 86 2015-12-17 03:41:56 <Luke-Jr> jgarzik: you seemed to me, to be trying to make an analogy of established practices; my point is there are no established practices for this situation
 87 2015-12-17 03:42:44 <jgarzik> I do wonder if Meni's right that permanent forks are inevitable and wallets should just be updated for that
 88 2015-12-17 03:42:45 <kanzure> jgarzik: it is morally wrong for you to characterize "correctness as not necessarily calculated by user-mass" as "driving away users or having no users".
 89 2015-12-17 03:42:48 <morcos> Luke-Jr: I completely agree with that
 90 2015-12-17 03:42:55 <zookolaptop> jgarzik: +1
 91 2015-12-17 03:43:13 <jgarzik> Luke-Jr, again, that's what I was saying
 92 2015-12-17 03:43:22 <zookolaptop> jgarzik: anything like Bitcoin which is successful enough will experience permanent schisms.
 93 2015-12-17 03:43:28 <jgarzik> "Bitcoin is not a typical open source project"
 94 2015-12-17 03:44:22 <morcos> Yeah the schisms thing is interesting
 95 2015-12-17 03:44:30 <Luke-Jr> ok, maybe I misunderstood your position completely then
 96 2015-12-17 03:46:03 <kanzure> now that i have established why jgarzik is wrong, what's the next step
 97 2015-12-17 03:46:55 <zookolaptop> lol
 98 2015-12-17 03:47:18 <kanzure> sorry, i mean, jgarzik's idea is wrong
 99 2015-12-17 03:47:24 <kanzure> nasty short hand habit.....
100 2015-12-17 03:48:07 <Luke-Jr> kanzure: can I quote you on that anyway? :P
101 2015-12-17 03:48:38 <zookolaptop> A really interesting thing happened at SB/HK, and I wish I had the presence of mind to finish unraveling it on the spot.
102 2015-12-17 03:49:07 <zookolaptop> The thing was: the miners, allegedly representing collectively 90% of the hash power, were each asked in turn for their opinions, preferences about changing the block size.
103 2015-12-17 03:49:27 <zookolaptop> They agreed that they wanted larger blocks. IIRC 8 out of 9 of them said they wanted larger blocks,
104 2015-12-17 03:49:29 <zookolaptop> and 1 abstained.
105 2015-12-17 03:49:49 <Luke-Jr> who abstained btw?
106 2015-12-17 03:49:58 <kanzure> no names rule
107 2015-12-17 03:50:04 <zookolaptop> When pressed for more details by the questions, they all repeatedly insisted that they didn't want to decide how, when, which BIPs, etc.,
108 2015-12-17 03:50:07 <zookolaptop> kanzure: no, they were onstage.
109 2015-12-17 03:50:16 <zookolaptop> Luke-Jr: you can probably find it in a video of the event? I forget.
110 2015-12-17 03:50:23 <zookolaptop> Luke-Jr: I didn't know them by name.
111 2015-12-17 03:50:42 <zookolaptop> Anyway, the miners (at least some/most of them), kept saying: we don't want to decide, we want the core devs to decide.
112 2015-12-17 03:50:59 <zookolaptop> The missed opportunity was that I should have gotten the mic and asked: "Who are the core devs?"
113 2015-12-17 03:51:02 <Luke-Jr> ugh
114 2015-12-17 03:51:09 <zookolaptop> What authority or process do you anticipate following?
115 2015-12-17 03:51:11 <Luke-Jr> it's not up to us either
116 2015-12-17 03:51:27 <kanzure> assuming authority is problematic, you should instead talk about least authority
117 2015-12-17 03:51:34 <zookolaptop> lol
118 2015-12-17 03:51:36 <kanzure> sorta surprised that you would even bother to pose the problem like that
119 2015-12-17 03:51:42 <kanzure> who has replaced zooko
120 2015-12-17 03:51:45 <zookolaptop> kanzure: dude
121 2015-12-17 03:51:48 <kanzure> heh
122 2015-12-17 03:52:46 <zookolaptop> In case anyone else in addition to kanzure is confused about this, what I'm asking is: what did the miners mean when they said they wanted the core devs to decide.
123 2015-12-17 03:53:00 <zookolaptop> Or to put it another way, if X happens, will the miners believe that this means the core devs decided? For various X's.
124 2015-12-17 03:53:28 <kanzure> perhaps they would accept whoever shouts the loudest....
125 2015-12-17 03:54:10 <kanzure> actually i was really hoping you would rant about the positive aspects of the principle of least authority
126 2015-12-17 03:54:35 <zookolaptop> lol
127 2015-12-17 03:55:06 <zookolaptop> Okay, enough lol'ing. From now on you can just *assume* that I'm laughing even if I don't say so.
128 2015-12-17 03:57:30 <midnightmagic> humans are bad at dealing with high-pressure situations where they know almost any answer will subject them to attack and/or criminal harassment
129 2015-12-17 03:58:00 <midnightmagic> there is no answer which will be more honest than when they are feeling safe and comfortable again.
130 2015-12-17 03:58:16 <zookolaptop> midnightmagic: you think the miners were feeling threatened when they gave those answers?
131 2015-12-17 03:59:26 <jgarzik> zookolaptop, I got the impression it was along the lines of "we're not devs, give us a menu of options and explain them well"
132 2015-12-17 03:59:35 <zookolaptop> My sense from having watched it in person and taken notes (i.e. live-tweeting it) is that they were uncomfortable with people asking them to form an opinion about protocol changes.
133 2015-12-17 03:59:43 <jgarzik> nod
134 2015-12-17 03:59:52 <midnightmagic> they are feeling threatened at all times, I am confident. Perhaps they would disagree they *feel* threatened, but most answers they would give *except* delegating to someone else, were probably the only thing they could think would prevent extremists from attacking them.
135 2015-12-17 03:59:59 <zookolaptop> At one point one of them mentioned that they wouldn't be willing to deploy their own source code or their own patches -- devs had to give them the code.
136 2015-12-17 04:00:14 <zookolaptop> Which I was mildly surprised to hear.
137 2015-12-17 04:00:29 <midnightmagic> miners are not devs. not any more.
138 2015-12-17 04:00:36 <kanzure> yes they also felt threatened because of the security-related talks. e.g. they were not used to think adversarially and didn't understand why that was topical.
139 2015-12-17 04:01:03 <kanzure> or, didn't want to display an understanding of why that was topical
140 2015-12-17 04:01:16 <jgarzik> That is natural for miners anyway -- they are incentivized to be followers of the herd.  They want to be where bitcoin users are.   Cannot expect miners to charge ahead on any issue, because that might risk divergence away from bitcoin's network effect.   e.g. KNC and Bitfury would never fork away from the mass of bitcoin users.
141 2015-12-17 04:01:20 <kanzure> well, i mean it wasn't the talks themselves that caused that.
142 2015-12-17 04:01:20 <zookolaptop> midnightmagic: that's consistent with what James Vasile said.
143 2015-12-17 04:01:41 <zookolaptop> He said that they he heard a lot of people unconvincingly claiming that they had no power.
144 2015-12-17 04:02:06 <zookolaptop> And he said that when you hear that, it's because there's a culture in which there is not a socially acceptable way to exercise power.
145 2015-12-17 04:02:07 <kanzure> zookolaptop: probably unconvincing if there are others claiming that other people have power.
146 2015-12-17 04:02:12 <zookolaptop> I thought that was a very interesting talk he gave.
147 2015-12-17 04:02:14 <zookolaptop> Didn't live-tweet that one.
148 2015-12-17 04:05:00 <midnightmagic> zookolaptop: considering a significant number of miners active today formed their seed capital through fraudulent means in the first place, it wouldn't strike me as odd that they would also perceive the threat of retaliation as real too. On top of that, relatively ethically clean people (ignoring short burn-min mainnet mining) have *already* been physicall threatened, followed, attacked, and dis
149 2015-12-17 04:05:06 <midnightmagic> rupted in terms of business ops.. I'm quite surprised as many showed up as did.
150 2015-12-17 04:06:00 <zookolaptop> midnightmagic: that is interesting.
151 2015-12-17 04:23:21 <rusty> jgarzik: I think coining "events" is misleading.  It's all statistics: at this stage it's how long did my payment get delayed?  That's not a single point, but natural variance means any threshold you choose will get crossed and uncrossed multiple times.
152 2015-12-17 04:25:10 <rusty> jgarzik: I'm comfortable with how that's playing out, but there's another statistic, which is "network is unusable because fees are too high".  We have even less experience with that.
153 2015-12-17 04:26:22 <morcos> Isn't that like "Nobody goes there anymore, it's too crowded"
154 2015-12-17 04:26:43 <jgarzik> rusty, In that context I would call "event" a tipping point with much higher than average actor turnover and over velocities, over a timescale long enough to not be considered "temporary" by the economic actors.
155 2015-12-17 04:27:10 <jgarzik> *other stat velocities
156 2015-12-17 04:27:25 <jgarzik> rusty, agree
157 2015-12-17 04:29:15 <zookolaptop> rusty: relatedly, the other phenomenon that jgarzik briefly mentioned in his talk: new projects not-started, or based on something other than Bitcoin.
158 2015-12-17 04:30:29 <rusty> zookolaptop: The margins we're realistically talking about for scaling are tiny; if you need orders of magnitude you're going elsewhere anyway.  I don't really buy this one (plus it's really hard to count things that didn't happen for a single reason).
159 2015-12-17 04:30:48 <zookolaptop> I agree it's really hard to measure.
160 2015-12-17 04:31:19 <zookolaptop> I don't think I agree with the other thing you just said
161 2015-12-17 04:32:40 <rusty> zookolaptop: provide a concrete counter-example, then.  I've heard too many "we'd have <cool thing here> if only you'd <something>" in political lobbying to trust it at all, I'm afraif.
162 2015-12-17 04:33:29 <zookolaptop> You mean a thing that didn't get started because Bitcoin was too slow or something/
163 2015-12-17 04:34:14 <rusty> zookolaptop: no, specifically because they needed <current-bitcoin-scale> * N, where N was > 1 but < 100, say.
164 2015-12-17 04:34:42 <zookolaptop> I can think of plenty of examples of things pivoting away from Bitcoin because Bitcoin doesn't have enough users/usage.
165 2015-12-17 04:35:12 <rusty> zookolaptop: sure, more users good, but that's a slightly different argument.
166 2015-12-17 04:35:27 <zookolaptop> Yeah, I didn't exactly mean that other argument.
167 2015-12-17 04:35:44 <zookolaptop> In my experience most people's decision procedure completely leaves out any inputs about the scalability or security of the system,
168 2015-12-17 04:35:57 <zookolaptop> and instead operates by *trying it*, and if it works then building a project on top of that.
169 2015-12-17 04:36:18 <rusty> zookolaptop: I agree.
170 2015-12-17 04:37:35 <rusty> jgarzik: your post referred to 95% full blocks for a week, or something.  Despite that that has happened already.  I think you were trying to get at some point where "my txs are processed unusably slowly".  But that seems like a problem we have to eventually solve, and it seems we're (slowly!) solving it (RBF, fee guestiimation).  Which accelerates us towards the second problem point: txs too damn expensive.  The latter can't be solved (much)
171 2015-12-17 04:37:40 <zookolaptop> I think a big source of disagreement on this topic may be implicit differing premises about Bitcoin as Store-of-Value vs. as Medium-of-Exchange.
172 2015-12-17 04:38:53 <jgarzik> rusty, higher average price point to Users of the Service, which results in a notable permanent turnover of economic actors from set A^1 to set A^2.
173 2015-12-17 04:38:57 <zookolaptop> If you look at Bitcoin today from the perspective of: are people's Bitcoins safe, could they (given enough time and fees) sell them, is the price high, things like that, it looks like a great success.
174 2015-12-17 04:39:30 <zookolaptop> I look at it from the perspective of "Does it have traction in one or more markets, are competitors outstripping it" things like that, and with those lenses I perceive it as teetering on the verge of failure.
175 2015-12-17 04:39:31 <rusty> jgarzik: yeah, the satoshidice transition.
176 2015-12-17 04:39:45 <jgarzik> rusty, there is a patience limit beyond which actors decide the Service disruption (economic, technical, failure, ...) is no longer temporary.
177 2015-12-17 04:39:58 <jgarzik> rusty, can that limit be defined precisely?  14 days?
178 2015-12-17 04:40:21 <rusty> jgarzik: there's no such limit with RBF and CPFP though.
179 2015-12-17 04:40:38 <rusty> jgarzik: (and less of a limit with fee estimation)
180 2015-12-17 04:41:01 <rusty> jgarzik: instead it collapses to a "too damn expensive" problem.
181 2015-12-17 04:41:22 <jgarzik> rusty, yep, which is self correcting in very painful ways
182 2015-12-17 04:41:52 <Luke-Jr> jgarzik: btw, how is removing the priority area not an "ECE"?
183 2015-12-17 04:42:53 <rusty> jgarzik: ... so, if we're playing Bitcoin God for a moment, I'd want to keep encouraging RBF & CPFP adoption (since we need it at our endpoint), but avoid the "insane fees" problem.  That points to a gradual, rather than sudden ramp up of blocksize.
184 2015-12-17 04:44:49 <aj> rusty, jgarzik: what's a value at which fees are "insane"?
185 2015-12-17 04:46:07 <rusty> aj: if we want lightning to bootstrap, it needs to be under a few dollars.  If we want lightning decentralized, it needs to be well under a dollar.
186 2015-12-17 04:46:59 <aj> rusty: so >$2 is insane, >50c is undersirable?
187 2015-12-17 04:47:13 <jgarzik> e (hours/days/weeks at most).
188 2015-12-17 04:47:13 <jgarzik> Luke-Jr, I'm trying to hone in on a good definition of ECE.  "Economic Change Event is a period of market chaos, where large changes to prices and sets of economic actors occurs over a short time period."   By that definition, removing priority area fits def ECE if events occur such that (a) prices are above-average volatile, (b) set of economic actors changes on a non-short-term basis, (c) over a short term timescal
189 2015-12-17 04:47:18 <rusty> aj: with my Lightning cap on, sure.
190 2015-12-17 04:47:25 <jgarzik> Luke-Jr, in laymans terms, you put a bunch of businesses out of business.
191 2015-12-17 04:47:42 <jgarzik> rusty, <grin>  Like... say.... 40,000 byte supply increase per diff period.
192 2015-12-17 04:47:46 <aj> rusty: (a lightning cap sounds hair-raising...)
193 2015-12-17 04:49:05 <Luke-Jr> jgarzik: did you just say "it's an ECE, if we find out after the fact it meets the criteria of an ECE"? -.-
194 2015-12-17 04:49:13 <zookolaptop> rusty: an example of someone pivoting away from Bitcoin due to insufficient users is ChangeTip. I understand, as you said, that it's hard to reason from these scalability and cost factors to "number of users".
195 2015-12-17 04:50:26 <jgarzik> Luke-Jr, It is an attempt to describe and specify the phenomena where prices and makeup of Users changes significant over the short term.
196 2015-12-17 04:50:54 <jgarzik> Luke-Jr, the disappearance of SD might qualify as a minor ECE... I would need to know the timescale
197 2015-12-17 04:51:22 <Luke-Jr> jgarzik: if you can only discern it after the fact, you can't argue for pre-announcements..
198 2015-12-17 04:51:50 <jgarzik> Luke-Jr, the concept of adding more safety margin and gathering data is straightforward
199 2015-12-17 04:52:24 <jgarzik> We are 100% certain the system works at blocks-not-full-on-avg, as paradoxical as that may seem.
200 2015-12-17 04:52:24 <rusty> jgarzik: yeah, or 19 bytes per block: https://github.com/rustyrussell/bitcoin/tree/bip-back-blocksize248
201 2015-12-17 04:53:02 <Luke-Jr> jgarzik: not at >1 MB block sizes..
202 2015-12-17 04:53:16 <jgarzik> rusty, After simulating BIP 100 then 101, economics 101 came back to haunt me.  small steps spread out over time = less supply shock.
203 2015-12-17 04:54:08 <rusty> jgarzik: absolutely.  Even more fundamentall, when you not sure about what the effects are, *change slowly*.
204 2015-12-17 04:55:04 <zookolaptop> I also really liked jgarzik's point that confidence about things that will/won't happen the future is an input to current economic decisions.
205 2015-12-17 04:56:44 <jgarzik> vis "halving day" - definitely painful supply shock btw, but that's too fundamental to touch.  it's much -less- worse than people make it out to be (it was mentioned at the SB:HK miner roundtable) because the market prices it in to an extent
206 2015-12-17 04:57:16 <rusty> jgarzik: it's also getting less painful over time (assuming fee market)...
207 2015-12-17 04:57:46 <rusty> zookolaptop: ... and since change is coming eventually, experts should try to disseminate information about their expectation re: timing.
208 2015-12-17 04:58:15 <aj> rusty: 50c transactions at 500B/tx and $400/BTC is just 2.5BTC per MB though
209 2015-12-17 04:58:42 <zookolaptop> rusty: I agree! That was one of jgarzik's points that I liked most, from his email post, that experts should be communicating now to people about likely imminent changes, including the changes that result from BIP000.
210 2015-12-17 04:59:25 <zookolaptop> aj: so fees would be 10% of reward instead of (as currently) 1% of reward?
211 2015-12-17 04:59:33 <jgarzik> I really do feel like there is a pattern of "Bitcoin must be leader-less, so we cannot appear to be leaders, so we cannot message stuff in advance to users as if we are leaders."
212 2015-12-17 04:59:48 <aj> zookolaptop: (multiplying fees from 5c to 50c per tx would do that, yes :)
213 2015-12-17 04:59:48 <jgarzik> which creates a shitty User experience, for projecting into the future.
214 2015-12-17 04:59:56 <zookolaptop> jgarzik: ☹ I'm afraid that sounds plausible to me.
215 2015-12-17 05:00:08 <zookolaptop> aj: ok. :-)
216 2015-12-17 05:00:44 <jgarzik> ...which creates a poor User experience of the Service, who wishes to plan for the future.
217 2015-12-17 05:01:37 <zookolaptop> *nod*
218 2015-12-17 05:09:23 <jgarzik> and...   I'm in it for the users, man.  </California dude>    If I thought the mass of users was on board with a SW+no hard fork, you would not hear a peep from me.  The inability to move max_block_size - something that was always intended to happen - seems likely to cause a big yucky rift in the community.
219 2015-12-17 05:09:42 <jgarzik> I am all for avoiding that by kicking the can.
220 2015-12-17 05:17:59 <jgarzik> But hey, maybe I'm completely wrong about that and all is well and I'm just crazy :)
221 2015-12-17 05:22:52 <rusty> jgarzik: If there's rough consensus that the endgame is (some burst capacity) + (some miner voting on blocksize cap), then it's hard to get upset with a simple can-kick with the explicit signalling that it's only to give time for R&D on that.
222 2015-12-17 05:23:52 <rusty> jgarzik: without some such signalling, it risks moral hazard.
223 2015-12-17 05:23:58 <jgarzik> rusty, agree
224 2015-12-17 05:24:52 <Luke-Jr> jgarzik: how about SW bundled with a hardfork scheduled for late 2016 or 2017?
225 2015-12-17 05:25:31 <Luke-Jr> that way, there is signalling to indicate the softfork, and plenty of time for the fallout to settle before the hardfork
226 2015-12-17 05:25:54 <jgarzik> Luke-Jr, late 2016 seems late.  I'm happy with SW HF - 100% validation, 100% trustless operation.
227 2015-12-17 05:26:31 <jgarzik> Luke-Jr, oh I misunderstood
228 2015-12-17 05:27:31 <jgarzik> Luke-Jr, SW - parallel issue to hard fork IMO.   SW:  hard fork preferred, soft fork meh (weak, over-rideable nak)
229 2015-12-17 05:27:42 <jgarzik> Luke-Jr, hard fork mid 2016
230 2015-12-17 05:28:16 <jgarzik> SW via hard fork would be super duper
231 2015-12-17 05:28:16 <Luke-Jr> jgarzik: it's not a parallel issue.. SW can get 4 MB block size effectively without a hardfork
232 2015-12-17 05:28:36 <Luke-Jr> that should be more than reasonable until 2020
233 2015-12-17 05:28:48 <aj> Luke-Jr: it's only a 1.6MB-2MB block size for normal transactions
234 2015-12-17 05:28:51 <jgarzik> Luke-Jr, I disagree with that, for reasons of rollout pace.   SW rollout will be slower than people think - when including layers beyond Bitcoin Core.
235 2015-12-17 05:29:14 <jgarzik> Luke-Jr, SW will not provide any short term scalability of note for a long time
236 2015-12-17 05:29:21 <Luke-Jr> aj: well, then the hardfork late 2016 would still be early ;)
237 2015-12-17 05:29:29 <jgarzik> presuming successful SW soft fork
238 2015-12-17 05:29:56 <rusty> aj: but it addresses one of my concerns about lightning taking off, so I like it :)
239 2015-12-17 05:32:03 <aj> jgarzik: saying SW won't immediately bump the usable block size by whatever factor is pretty similar to saying that the kick-the-can hard fork block size increases shouldn't be sudden anyway, no?
240 2015-12-17 05:32:32 <aj> jgarzik: (ie, increments of x kB per block, rather than x MB per year)
241 2015-12-17 05:33:08 <jgarzik> aj, No not at all - it is speaking strictly towards there will be less extension block use even after rollout
242 2015-12-17 05:33:27 <jgarzik> lots of pressure on the core block still
243 2015-12-17 05:33:42 <aj> (fwiw, 2/4/8 starting in 2016 sometime + SW-soft-fork + fees stuck at 20c or less is my preference)
244 2015-12-17 05:33:42 <jl2012> rusty or other mailing list mod: I have just sent a new post to the mailing list and is still get modded. Would you please whitelist me? Thank you
245 2015-12-17 05:35:10 <Luke-Jr> aj: I like SW with new combined cap of 2/4/8 (doubling each subsidy halving), and a hardfork to remove the old pre-witness limit some year or two off.
246 2015-12-17 05:35:20 <aj> jgarzik: are you proposing "kick-the-can" should immediately bump from 1MB to 2MB when activated, or should increase gradually? if the former, that's a supply shock; if the latter, it doesn't relieve pressure very suddenly
247 2015-12-17 05:35:44 <rusty> jl2012: approved... FWIW we're moderating everyone on these threads, since it's likely to go south fast :(
248 2015-12-17 05:36:27 <jgarzik> This is a taste thing, but at initial SW start the network trusts miners overly much (familiar soft fork security downgrade).  Just leaves a bad taste in the mouth.  Hard fork is just so much stronger a security guarantee.  SW soft fork = continue trust-the-miner trend.   SW hard fork = full trustless validation at each "full node"
249 2015-12-17 05:37:41 <Luke-Jr> jgarzik: hard fork *destroys* security completely
250 2015-12-17 05:37:46 <rusty> jgarzik: pretty sure an ISM soft fork gets loud warning in current bitcoind.  Sure, versionbits makes it slightly better.
251 2015-12-17 05:37:49 <jgarzik> Luke-Jr, like rusty and I were just talking about, it is nice to avoid big steps - supply shocks.   I was poking around with a patch that added +40,000 bytes per 2016 blocks.  It sounds like rusty is poking around with something even more gradual (19 bytes/block?)
252 2015-12-17 05:37:59 <Luke-Jr> jgarzik: all old nodes are vulnerable to bogus shorter-chain blocks
253 2015-12-17 05:38:29 <jgarzik> Luke-Jr, hard fork is a flag day network-must-be-upgraded, with all that entails.
254 2015-12-17 05:38:43 <rusty> jgarzik: yeah, linear 2 - 4 - 8, with 1 year from 1-2 MB, 2 years from 2-4, 2 from 4-8.  Where "year" = #halvingblocks / 4.
255 2015-12-17 05:39:04 <Luke-Jr> jgarzik: you can flag day softforks too (but in practice it's not really necessary since everyone sees it coming)
256 2015-12-17 05:39:09 <rusty> damn, gtg.
257 2015-12-17 05:39:20 <Luke-Jr> rusty: doesn't that outpace bandwidth?
258 2015-12-17 05:39:25 <jgarzik> Luke-Jr, sure
259 2015-12-17 05:39:38 <jl2012> rusty, ok if it's thread based. Thanks
260 2015-12-17 05:39:48 <Luke-Jr> softfork = old nodes get SPV security
261 2015-12-17 05:39:52 <Luke-Jr> hardfork = old nodes get no security at all
262 2015-12-17 05:40:12 <Luke-Jr> that's basically the only significant difference in this regard..
263 2015-12-17 05:41:18 <jgarzik> Luke-Jr, yes - you rotate out ancient and leech cells (nodes) off the network.  produces a healthier decentralized organism.
264 2015-12-17 05:41:44 <Luke-Jr> you leave them vulnerable; that has no real upsides.
265 2015-12-17 05:41:46 <jgarzik> Luke-Jr, they are by definition less secure and inattentive
266 2015-12-17 05:42:13 <Luke-Jr> they don't leave the network just because they're vulnerable
267 2015-12-17 05:42:25 <Luke-Jr> and SPV nodes are normative on the network anyway
268 2015-12-17 05:42:59 <jgarzik> which is more important, an individual node or the organism as a whole?
269 2015-12-17 05:43:37 <Luke-Jr> it's not a choice between the two
270 2015-12-17 05:48:13 <jl2012> Luke-Jr, with a clean hardfork (with very few or no miner in the original fork), old nodes will just cease to function
271 2015-12-17 05:48:26 <jl2012> like BIP50
272 2015-12-17 05:48:37 <Luke-Jr> jl2012: that's not correct; they will cease to function, *and* be left insecure
273 2015-12-17 05:49:13 <Luke-Jr> an attacker can mine the old chain up with no competition
274 2015-12-17 05:49:43 <jl2012> Luke-Jr, did it happen after BIP50 fork?
275 2015-12-17 05:50:26 <Luke-Jr> jl2012: presumably
276 2015-12-17 05:50:31 <Luke-Jr> I don't know that anyone tracked it
277 2015-12-17 05:50:40 <midnightmagic> even honest "leech nodes" contribute to the complexity of the edge nodes in the connection graph and make it harder to map/sybil/non-hashrate attack the network's privacy; and depending on the hardfork are also potentially remaining less-validating archival nodes
278 2015-12-17 05:51:10 <midnightmagic> *soft
279 2015-12-17 05:52:03 <jl2012> Luke-Jr, and no one complained, either
280 2015-12-17 05:52:43 <Luke-Jr> jl2012: well, it would take a non-updated node getting exploited..
281 2015-12-17 05:52:52 <Luke-Jr> *and* someone who didn't update it noticing
282 2015-12-17 05:54:03 <jl2012> Luke-Jr, so you suggest that some may got exploited in the BIP50 fork, and not even realized that they got exploited
283 2015-12-17 05:54:32 <Luke-Jr> jl2012: whether they did or didn't isn't relevant; the vulnerability is there
284 2015-12-17 05:55:09 <Luke-Jr> why open a vulnerability with a hardfork, if it can be avoided with a softfork?
285 2015-12-17 05:55:56 <midnightmagic> because once a single hardfork is completed, future hardforks presumably would also be easier
286 2015-12-17 05:56:36 <jl2012> midnightmagic: we already had a safe hardfork before
287 2015-12-17 05:57:19 <Luke-Jr> ^
288 2015-12-17 05:58:22 <jl2012> Luke-Jr, I agree with you, but only if SW is scheduled by 1 June
289 2015-12-17 05:59:10 <jl2012> so the softfork will complete before halving
290 2015-12-17 05:59:58 <zookolaptop> Luke-Jr: FWIW, I think hardforks have some advantages over softforks.
291 2015-12-17 06:00:09 <Luke-Jr> jl2012: probably possible; but what's the rush?
292 2015-12-17 06:00:17 <Luke-Jr> zookolaptop: such as?
293 2015-12-17 06:00:46 <zookolaptop> Luke-Jr: the resulting design and implementation is simpler and its rationale clearer, for example with the hardfork SW vs. softfork SW.
294 2015-12-17 06:01:33 <jl2012> Luke-Jr, I have explained in my post: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011975.html
295 2015-12-17 06:03:09 <jl2012> Basically, I agree with jgarzik that this is not yet the suitable time for a radical change in fee
296 2015-12-17 06:04:02 <jl2012> And coupling "full blocks" with "halving" is the worst scenario I could imagine
297 2015-12-17 06:04:24 <Luke-Jr> well, we have no control over fee stuff in this regard period
298 2015-12-17 06:04:27 <zookolaptop> Goodnight, folks.
299 2015-12-17 06:04:35 <Luke-Jr> spammers spam. they will always spam.
300 2015-12-17 06:04:57 <Luke-Jr> making the block size limit bigger won't change that
301 2015-12-17 06:05:19 <Luke-Jr> and they could have filled the blocks just as well earlier
302 2015-12-17 06:06:34 <jl2012> Spammers will still spam. But I'm talking about legitimate use
303 2015-12-17 06:07:03 <Luke-Jr> legitimate use isn't even half filling blocks yet
304 2015-12-17 06:07:11 <Luke-Jr> no reason to expect it to before 2017
305 2015-12-17 06:07:22 <Luke-Jr> no reason to expect it to fill 1 MB* before 2017
306 2015-12-17 06:07:26 <jl2012> halving will not lead to more spam, but will lead to more legitimate use
307 2015-12-17 06:08:04 <Luke-Jr> jl2012: that sound awfully speculative; we're going to see triple the legitimate use at the next halving, when it took 6 years to get to ~300k?
308 2015-12-17 06:12:54 <jgarzik> Luke-Jr, re "no control" - that's not true - you can buy some additional insurance by adding some buffer
309 2015-12-17 06:12:56 <jl2012> this one is better, by removing satoshidice tx
310 2015-12-17 06:13:53 <jl2012> it increased by 5x in one year since halving
311 2015-12-17 06:15:28 <jl2012> and the volume now is 2.67x of the 2013 bubble, even the price is only at 40%
312 2015-12-17 06:16:26 <jl2012> triple volume around halving is an educated guess
313 2015-12-17 06:18:28 <jl2012> as bitcoin is a young technology, exponential growth is usually a better model
314 2015-12-17 06:20:40 <jl2012> It seems my earlier link was not sent properly: https://blockchain.info/charts/n-transactions-excluding-popular?showDataPoints=false&timespan=all&show_header=true&daysAverageString=7&scale=0&address=
315 2015-12-17 06:21:10 <Luke-Jr> realistically, most everyone who is willing to adopt Bitcoin with its current state of software is likely to have already done so
316 2015-12-17 06:21:41 <jgarzik> That's self-reducing - I don't agree at all
317 2015-12-17 06:21:54 <jl2012> Luke-Jr, the chart I showed disagree with you
318 2015-12-17 06:22:04 <Luke-Jr> jl2012: as a rule, if it's on blockchain.info, it's bogus
319 2015-12-17 06:22:30 <Luke-Jr> jl2012: in particular, 2015 spam hasn't been reusing addresses as much
320 2015-12-17 06:24:33 <jl2012> I agree with the part of less address reuse, but your comment re bc.info is not very constructive on this topic
321 2015-12-17 06:25:35 <jl2012> anyway, legitimate tx increased by 5x in one year since last halving. It's more likely to have an increase in 2016 halving
322 2015-12-17 06:26:17 <jl2012> even that's only 2x, we will be very close to the limit
323 2015-12-17 06:26:54 <jl2012> and don't forget mining is a random process, the actual limit is lower than 1MB
324 2015-12-17 06:27:10 <jl2012> and miners mine empty blocks too
325 2015-12-17 07:00:32 <midnightmagic> his comment about bc.i is true; bc.i has proven themselves incompetent in *a multitude* of technical ways in the past. without triangulating evidence, there *is no reason* to believe bc.i is canonically accurate
326 2015-12-17 07:17:43 <jl2012> Let's not be distracted by bc.i
327 2015-12-17 07:27:56 <Luke-Jr> you're the one throwing that distraction in my face ;)
328 2015-12-17 07:52:36 <jl2012> Luke-Jr, midnightmagic: crossed checked with http://www.coindesk.com/data/bitcoin-daily-transactions/ and they match
329 2015-12-17 08:13:35 <jl2012> Luke-Jr, "most everyone who is willing to adopt Bitcoin with its current state of software is likely to have already done so" is just like saying "$100 is insane" in 2012
330 2015-12-17 08:13:57 <Luke-Jr> no
331 2015-12-17 08:14:05 <jl2012> Any data?
332 2015-12-17 08:14:27 <Luke-Jr> bitcoin history since 2012
333 2015-12-17 08:14:43 <jl2012> would you mind elaborate?
334 2015-12-17 08:15:02 <Luke-Jr> busy actually working on things
335 2015-12-17 08:15:12 <jl2012> ok forget it then
336 2015-12-17 08:18:29 <jl2012> Anyway, if SW softfork could be done (including miner upgrade) about 2 months before halving, I prefer it as the solution
337 2015-12-17 08:19:38 <jl2012> the question is how realistic this is and if anyone would make such a promise to the community
338 2015-12-17 08:51:18 <btcdrak> jl2012: gotta lop off those peaks though or apply ema smoothing. It looks a lot more impressive than it really is.
339 2015-12-17 09:43:59 <jl2012> btcdrak: this is 30-day moving average which should smooth out the outliers: https://blockchain.info/charts/n-transactions-excluding-popular?showDataPoints=false&timespan=all&show_header=true&daysAverageString=30&scale=0&address=
340 2015-12-17 09:44:48 <jl2012> I don't like to quote bc.i too but I can't yet find a similar graph elsewhere
341 2015-12-17 10:52:24 <midnightmagic> jl2012: which event are you defining as a safe hardfork
342 2015-12-17 10:58:43 <jl2012> midnightmagic: the BIP50
343 2015-12-17 11:05:15 <midnightmagic> that wasn't much of a successful, safe hardfork. that was an emergency bugfix to return bitcoin to expected operational status thanks to two badly-handled patches.
344 2015-12-17 11:09:13 <Luke-Jr> midnightmagic: the May part was a successful hardfork
345 2015-12-17 11:09:18 <Luke-Jr> midnightmagic: removal of the BDB lock limits
346 2015-12-17 11:13:17 <midnightmagic> they were unknown as consensus-critical limits; people expected the software to work as though the limits weren't there. it required no planning, and was a result of a side-effect of a badly-tested patch. if BIP0050 is an example of a hardfork example equivalent to context of actual, planned hardfork activity then bitcoin has experienced multiple implicit hardforks, and multiple explicit hardfor
347 2015-12-17 11:13:23 <midnightmagic> ks, and none of these facts contradict my comment: "some" people think that experiencing a hardfork now will make future hardforks easier both politically and technically.
348 2015-12-17 11:14:55 <midnightmagic> and I would be happy to quote them, but then some douche will just make a reddit post and take my comments out of context again, and the "story" will be used to build a false consciousness echo chamber as an excuse to attack me personally. again.
349 2015-12-17 11:27:31 <jl2012> midnightmagic, if an emergency simple hardfork like BIP50 could be successful, a planned simple hardfork like BIP102 supported by supermajority of miners could also be successful
350 2015-12-17 11:29:25 <midnightmagic> That does not follow. There were literally no objections to BIP0050. The objections were of the release engineering that created the problem and complaints about security as people realized they might be able to take advantage of double-spend opportunities.
351 2015-12-17 11:29:55 <jl2012> would you please tell me what are those implicit and explicit hardforks? I'm collecting these info for my wiki
352 2015-12-17 11:31:21 <jl2012> midnightmagic: so the whole discussion goes back to the threshold of hardfork
353 2015-12-17 11:32:15 <jl2012> 100.000000000%? or 99%? or some other figure?
354 2015-12-17 11:33:14 <midnightmagic> jl2012: people correct me when I mention them as hardforks due to a disagreement about what it means to call something a hardfork.
355 2015-12-17 11:34:05 <midnightmagic> I mean especially if bugfixes count as hardforks, there were many.
356 2015-12-17 13:51:53 <jl2012> midnightmagic: I'm not aware of any other bug fix that would lead to a consensus hardfork
357 2015-12-17 13:59:55 <instagibbs> average blocksize smoothed over 7 days looks like a bunch of spam spikes. Unsure of how much baseline growth there really is: https://blockchain.info/charts/avg-block-size?showDataPoints=false&timespan=&show_header=true&daysAverageString=7&scale=0&address=
358 2015-12-17 14:04:37 <aj> instagibbs: base seems to have risen from 0.3 or 0.4 to 0.5 though?
359 2015-12-17 14:06:19 <aj> instagibbs: https://blockchain.info/charts/avg-block-size?timespan=2year&showDataPoints=false&daysAverageString=7&show_header=true&scale=0&address=    looks like a massive increase in spam in the past six months though, whatever else is going on...
360 2015-12-17 16:11:53 <benjyz1> ok. my post to bitcoin-dev got censored
361 2015-12-17 16:12:15 <tripleslash> this is #bitcoin-dev and I see your post.
362 2015-12-17 16:12:24 <benjyz1> apparently this is the correct channel
363 2015-12-17 16:12:38 <benjyz1> to discuss censorship in this supposed open-source project
364 2015-12-17 16:12:50 <aj> benjyz1: https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/attachments/20151217/b9957282/attachment.mht presumably?
365 2015-12-17 16:12:56 <jgarzik> benjyz1, Here's the kickoff post for moderation: http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011591.html
366 2015-12-17 16:13:25 <jgarzik> benjyz1, in general a lot of noise was turning off contributors, so it was a moderation-or-not-have-useful-people sort of situation
367 2015-12-17 16:13:38 <tripleslash> benjyz1, if you don't believe this project to be opensource, please point me to some closed source that is included in the project.
368 2015-12-17 16:13:53 <benjyz1> there is a contributors policy
369 2015-12-17 16:13:53 <tripleslash> I think you need an adjustment to what you define as 'opensource'.
370 2015-12-17 16:14:17 <benjyz1> I received an email
371 2015-12-17 16:14:19 <benjyz1> "Request to mailing list bitcoin-dev rejected"
372 2015-12-17 16:14:23 <aj> benjyz1: (post moderation concerns to -discuss; -dev is for coding)
373 2015-12-17 16:14:33 <benjyz1> I'm not leaving the channel again
374 2015-12-17 16:14:44 <benjyz1> I've been referred to this channel
375 2015-12-17 16:14:45 <wumpus> he's talking about another mailing list not another channel
376 2015-12-17 16:14:47 <aj> benjyz1: (-discuss the mailing list, not a different irc channel)
377 2015-12-17 16:14:47 <tripleslash> benjyz1, he was referring to the mailing list, not hte hcannels.
378 2015-12-17 16:14:50 <jgarzik> benjyz1, He's referring to the bitcoin-discuss mailing list.
379 2015-12-17 16:14:56 <benjyz1> discuss is empty
380 2015-12-17 16:15:01 <benjyz1> no one is reading it
381 2015-12-17 16:15:05 <aj> benjyz1: (just in case you wanted the answer in triplicate)
382 2015-12-17 16:15:05 <benjyz1> go to /dev/null
383 2015-12-17 16:15:05 <tripleslash> prove it
384 2015-12-17 16:15:27 <tripleslash> aj: triplicate just shows a consensus ;-)
385 2015-12-17 16:15:29 <aj> i read -discuss, though tbf i'm kind of no one...
386 2015-12-17 16:15:57 <tripleslash> There's a difference between nobody reading a mailing list and nobody sending to a mailing list.
387 2015-12-17 16:16:02 <tripleslash> Its hard to prove the first.
388 2015-12-17 16:16:29 <benjyz1> whatever. its irrelevant, so this doesn't count
389 2015-12-17 16:16:36 <benjyz1> there is one mailing list
390 2015-12-17 16:16:45 <benjyz1> mentioned in github.com/bitcoin/bitcoin
391 2015-12-17 16:17:31 <tripleslash> There are several mailing lists.
392 2015-12-17 16:18:44 <benjyz1> ok, so what is the policy exactly?
393 2015-12-17 16:19:10 <benjyz1> https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md
394 2015-12-17 16:19:20 <tripleslash> "The developer mailing list should be used to discuss complicated or controversial changes before working on a patch set."  There's no claim that anyone/everyone would have access to discuss anything/everything.
395 2015-12-17 16:19:37 <benjyz1> yes
396 2015-12-17 16:19:42 <tripleslash> So what you consider to be topical for the developer mailing list may not necessarily be so.
397 2015-12-17 16:19:52 <benjyz1> yes, that is actually the case
398 2015-12-17 16:19:58 <tripleslash> No, it isn't.
399 2015-12-17 16:20:22 <tripleslash> Show me anywhere where it says you may post anything you want to the mailing list.
400 2015-12-17 16:20:25 <benjyz1> well, surely economics is off-topic e.g.
401 2015-12-17 16:20:31 <benjyz1> because bitcoin has nothing to do with it...
402 2015-12-17 16:20:40 <tripleslash> bitcoin has much to do with economics.
403 2015-12-17 16:20:54 <benjyz1> oh really?
404 2015-12-17 16:21:07 <benjyz1> and how does that affect the moderation policy?
405 2015-12-17 16:21:43 <wumpus> what did you try to post that was rejected and you feel should not have been?
406 2015-12-17 16:21:57 <benjyz1> economics is considered off-topic
407 2015-12-17 16:22:05 <tripleslash> Its a developer list with a high bar right now.  For those things not meeting that bar, as defined by the moderator, there is the discuss mailing list.
408 2015-12-17 16:22:07 <benjyz1> PeterR made some posts about fee market
409 2015-12-17 16:22:11 <tripleslash> Its really that simple.
410 2015-12-17 16:22:17 <benjyz1> one of the very things that actually made sense in this area
411 2015-12-17 16:22:17 <wumpus> yes, economics is considered off topic for -dev
412 2015-12-17 16:22:23 <benjyz1> good
413 2015-12-17 16:22:33 <benjyz1> and bitcoin.. is what exactly by your definition?
414 2015-12-17 16:22:39 <instagibbs> benjyz1, open source means you are free to fork, not that you're free to make everyone listen to you. Please keep that in mind and be respectful.
415 2015-12-17 16:23:01 <instagibbs> That said I have no dog in moderation to fight with. :)
416 2015-12-17 16:23:07 <benjyz1> I got censored - that is the opposite of respec
417 2015-12-17 16:23:07 <tripleslash> instagibbs: its even simpler than that.. open source means the source is open.
418 2015-12-17 16:23:22 <jgarzik> tripleslash, yup
419 2015-12-17 16:23:25 <instagibbs> That has nothing to do with this channel
420 2015-12-17 16:23:41 <jgarzik> Some open source is very tightly controlled - one company one copyright, but it's GPL'd and open.
421 2015-12-17 16:24:10 <wumpus> the dev mailing list is meant for serious/novel development proposals (such as BIPs), and factual discussion about them, but it had a lot of ancillary talk, this made the actual developers leave so moderation was necessary
422 2015-12-17 16:24:17 <tripleslash> Expecting anything more from the name 'open source' is just setting yourself up for hurt.
423 2015-12-17 16:24:53 <jl2012> starting from the minutes for the last week's IRC meeting, I'll translate to Chinese and put it on https://8333.info/
424 2015-12-17 16:25:00 <aj> benjyz1: you got moderated, not censored; your mail was still published. it'd have been on-topic for -discuss, imho, if you'd posted it there
425 2015-12-17 16:25:26 <tripleslash> anything moderated off dev goes to discuss anyway, does it now?
426 2015-12-17 16:25:29 <benjyz1> discuss = trash-bin
427 2015-12-17 16:25:32 <tripleslash> not*
428 2015-12-17 16:25:50 <benjyz1> brilliant rhetorical trick
429 2015-12-17 16:26:40 <aj> tripleslash: moderated stuff goes to https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/ which is pretty .. primitive
430 2015-12-17 16:27:01 <tripleslash> thanks aj
431 2015-12-17 16:27:54 <benjyz1> ok. and who decided that economics is off-topic for bitcoin development?
432 2015-12-17 16:28:03 <benjyz1> I'd be curious to know the evolution of that idea
433 2015-12-17 16:28:33 <aj> benjyz1: moderation is fairly new, and there's been little evolution of it. the place to evolve it is by discussion on -discuss, but no-one's done that yet
434 2015-12-17 16:28:57 <benjyz1> my reading is different
435 2015-12-17 16:30:59 <benjyz1> okay, say I want to discuss mining and incentives
436 2015-12-17 16:31:17 <benjyz1> and have concrete proposals around it
437 2015-12-17 16:31:27 <benjyz1> in code.. its still off-topic for bitcoin-dev?
438 2015-12-17 16:32:45 <aj> benjyz1: "say i want to discuss ..." -- then post to -discuss
439 2015-12-17 16:33:01 <aj> benjyz1: concrete proposals with code, -dev
440 2015-12-17 16:33:20 <benjyz1> assumes there is a fine line between the two
441 2015-12-17 16:33:24 <wumpus> if you have concrete proposals and code, espeically if you plan to make a BIP, it's on topic
442 2015-12-17 16:33:25 <benjyz1> turns out.. there isn't
443 2015-12-17 16:34:16 <benjyz1> BIP is not really clear concept. should be protocols, but almost all BIPS are implementation specific
444 2015-12-17 16:34:19 <aj> jl2012: going to post the translations to -discuss/reddit as well? (or just to chinese forums/wechat/whatever?)
445 2015-12-17 16:34:37 <wumpus> but there has been a lot of empty talk about mining and incentives, and things that are completely unrealistic, so it's a difficult area
446 2015-12-17 16:34:51 <jgarzik> The BIPS link to implementations but are not implementation specific.
447 2015-12-17 16:35:33 <wumpus> yes it can be any implementation, as long as people can test / get a feel for it, that generally helps acceptance
448 2015-12-17 16:36:43 <jl2012> aj: I don't know if -discuss accepts language other than English (and if anyone is really subscribing it --- I'm not)
449 2015-12-17 16:37:14 <jl2012> same for reddit.
450 2015-12-17 16:38:49 <jl2012> I've disseminated through the wechat. I expect some Chinese news portal will publish it
451 2015-12-17 16:40:02 <benjyz1> interestingly there is no BIP around OP_RETURN
452 2015-12-17 16:40:41 <jgarzik> benjyz1, That's because support has always been in bitcoin for OP_RETURN
453 2015-12-17 16:41:06 <benjyz1> why no protocol for it?
454 2015-12-17 16:41:16 <benjyz1> if BIP's are protocols. that's simply not the case
455 2015-12-17 16:41:45 <aj> jl2012: could post a link in english, though i'm not sure if that'd actually be useful. translations are cool though, +1 :)
456 2015-12-17 16:42:12 <benjyz1> so a lot of these policies around delineating development don't make much sense
457 2015-12-17 16:42:16 <jgarzik> benjyz1, Not sure the question is understood.  The bitcoin protocol has always supported OP_RETURN.  BIPS started well after bitcoin protocol creation, and only cover recent changes.
458 2015-12-17 16:43:13 <wumpus> BIPs are required for a) P2P network protocol changes b) consensus changes, for the other changes it's allowed to write an informative BIP but not required
459 2015-12-17 16:46:30 <benjyz1> OP_RETURN was introduced without BIP. for external applications its one of the more important changes
460 2015-12-17 16:47:21 <wumpus> OP_RETURN was never introduced, it has been supported since the beginning
461 2015-12-17 16:47:44 <wumpus> satoshi never wrote BIPs
462 2015-12-17 16:48:03 <benjyz1> yes, 0.01 version has OP_RETURN
463 2015-12-17 16:48:09 <benjyz1> but different semantics
464 2015-12-17 16:48:30 <jgarzik> benjyz1, no, the semantics have not changed.  The evaluation remains the same.
465 2015-12-17 16:48:41 <benjyz1> OP_RETURN as metadata
466 2015-12-17 16:48:47 <wumpus> I don't think so? would have been a hard/softfork if so, and I certainly don't remember that
467 2015-12-17 16:48:58 <wumpus> if anything it's a long time ago
468 2015-12-17 16:49:00 <jgarzik> benjyz1, That is unchanged.   OP_DROP works the same way for per-output.
469 2015-12-17 16:50:30 <pigeons> nkuttler: nkuttIer 058674cd@gateway/web/cgi-irc/kiwiirc.com/ip.5.134.116.205 is impersonating you
470 2015-12-17 16:50:36 <pigeons> oops very sorry wrong window
471 2015-12-17 17:00:56 <benjyz1> ok, and if Tier Nolan posts
472 2015-12-17 17:01:02 <benjyz1> Bitcoin is kind of like a republic where there is separation of powers between various groups.
473 2015-12-17 17:01:02 <benjyz1> - Core Devs
474 2015-12-17 17:01:02 <benjyz1> The power blocs in the process include
475 2015-12-17 17:01:04 <benjyz1> - Miners
476 2015-12-17 17:01:06 <benjyz1> - Exchanges
477 2015-12-17 17:01:08 <benjyz1> - Merchants
478 2015-12-17 17:01:10 <benjyz1> - Customers
479 2015-12-17 17:01:16 <benjyz1> that obviously is on-topic..funny
480 2015-12-17 18:57:53 <kanzure> huh, bitcoin-dev mailing list moderators cannot set modbits on users that have had modbits unset.
481 2015-12-17 18:57:53 <petertodd> jgarzik: previously OP_RETURN caused the script to succeed, rather than fail
482 2015-12-17 18:59:32 <sipa> oops, i forgot about the meeting
483 2015-12-17 18:59:46 <sipa> and my battery will die in a minute
484 2015-12-17 18:59:52 <petertodd> sipa: I'm at a ski hill right now and I remembered :P
485 2015-12-17 19:00:05 <petertodd> though I'm two weeks late...
486 2015-12-17 19:00:19 <sipa> petertodd: time zones are evil
487 2015-12-17 19:00:32 <sipa> i'm not used to having meetings during daylight
488 2015-12-17 19:00:36 <petertodd> sipa: ha
489 2015-12-17 19:01:48 <jonasschnelli> meeting?
490 2015-12-17 19:01:55 <wumpus> #meetingstart
491 2015-12-17 19:01:58 <wumpus> #startmeeting
492 2015-12-17 19:01:59 <lightningbot> Meeting started Thu Dec 17 19:01:58 2015 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
493 2015-12-17 19:01:59 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
494 2015-12-17 19:02:19 <raa> hey guys
495 2015-12-17 19:02:30 <raa> alot of people have been complaining about the block size
496 2015-12-17 19:02:34 <wumpus> anyone have topics to propose?
497 2015-12-17 19:02:46 <raa> does anyone know why this is such a big deal?
498 2015-12-17 19:02:48 <jonasschnelli> RBF handling in wallets? Is that a valid topic?
499 2015-12-17 19:02:52 <raa> like an eli5?
500 2015-12-17 19:02:53 <petertodd> jonasschnelli: sure
501 2015-12-17 19:03:06 <jonasschnelli> raa: not here. Please #bitcoin
502 2015-12-17 19:03:19 <wumpus> #topic RBF handling in wallets
503 2015-12-17 19:03:24 <raa> jonasschnelli: ah okay, i asked there also. thanks
504 2015-12-17 19:03:38 <raa> have a nice day everyone
505 2015-12-17 19:03:51 <petertodd> wumpus: is the RBFhandling in the v0.12 branch what's going to be released? IE, have we feature frozen?
506 2015-12-17 19:04:12 <wumpus> yes, we have feature frozen at dec 1
507 2015-12-17 19:04:20 <petertodd> cool
508 2015-12-17 19:04:31 <petertodd> or I should sau, frozen
509 2015-12-17 19:04:34 <wumpus> but if there is anything simple and pretty important we can make an exception....
510 2015-12-17 19:04:36 <sdaftuar> i hope 7062 still gets included in 0.12, which fixes prioritisetransaction for RBF and mempool limiting
511 2015-12-17 19:04:51 <wumpus> just nothing that will add new bugs
512 2015-12-17 19:04:56 <wumpus> sdaftuar: fixes are always welcome
513 2015-12-17 19:05:18 <wumpus> it's a feature freeze not a bugfix freeze :-)
514 2015-12-17 19:05:23 <petertodd> wumpus: lukejr's #7219 almost certainely won't
515 2015-12-17 19:05:52 <jonasschnelli> How should we allow to RBF a wtx... is best pratice delete/archive the transaction and release the input or something like "altertransaction"?
516 2015-12-17 19:06:03 <jonasschnelli> *inputs
517 2015-12-17 19:06:30 <petertodd> jonasschnelli: seems that this should have similar handling to mutability, in principle
518 2015-12-17 19:06:32 <wumpus> #action look at #7062 (fixes prioritisetransaction for RBF and mempool limiting) for 0.12
519 2015-12-17 19:06:55 <wumpus> what is #7219 Luke-Jr?
520 2015-12-17 19:07:05 <Luke-Jr> wumpus: -replacebyfee option
521 2015-12-17 19:07:11 <jonasschnelli> 7219 i think has no consensus.
522 2015-12-17 19:07:43 <wumpus> ah, right, that one
523 2015-12-17 19:07:54 <Luke-Jr> jonasschnelli: it's a policy option, not a consensus rule; it doesn't need consensus, just users
524 2015-12-17 19:08:08 <petertodd> jonasschnelli: well, devils advocate, I'll still be doing a full-RBF fork with code to make the policy option find similarly policy peers
525 2015-12-17 19:08:08 <wumpus> I think RBF certainly needs to be supported in the wallet at some point, but it's too late for 0.12 probably
526 2015-12-17 19:08:40 <petertodd> jonasschnelli: just setting RBF to something locally isn't as useful without like-minded peers
527 2015-12-17 19:08:53 <jonasschnelli> sure... RBF wallet is something for 0.13. But still,... I'd like to get the grip how this should be handled by wallets.
528 2015-12-17 19:09:03 <wumpus> sure
529 2015-12-17 19:09:36 <harding> I'm also interested in good ideas for wallet policy for writing documentation about it.
530 2015-12-17 19:09:36 <jonasschnelli> IMO a easy way to alter/increase fees is something that users would like to see.
531 2015-12-17 19:10:05 <petertodd> jonasschnelli: are you thinking just for fee bumping or more than that?
532 2015-12-17 19:10:16 <jonasschnelli> What if someone alters a wtx, and, in the very same moment, the actual/unaltered one gets mined?
533 2015-12-17 19:10:35 <petertodd> jonasschnelli: conceptually that seems similar to mutability
534 2015-12-17 19:10:57 <petertodd> jonasschnelli: as a user, what I care about is who my wallet paid, not how
535 2015-12-17 19:11:09 <jonasschnelli> petertodd: Somehow people have stuck tx (even in bitcoin-core, but mostly in SPV wallets), how could we indicate a low fee wtx and how would the UI path look like to increase fees.
536 2015-12-17 19:12:12 <petertodd> jonasschnelli: android wallet does it via a click-to-bump UI (though via CPFP)
537 2015-12-17 19:12:57 <Luke-Jr> Schildbachs wallet is nothing to imitate, last I checked.
538 2015-12-17 19:13:34 <petertodd> Luke-Jr: what don't you like about it?
539 2015-12-17 19:14:44 <Luke-Jr> petertodd: last I checked, it was very buggy; displayed nonsense like "from address", heavily encouraged addr reuse, etc
540 2015-12-17 19:14:54 <petertodd> Luke-Jr: ah, sure, I agree there
541 2015-12-17 19:14:57 <jonasschnelli> What if a wtx gets confirmed during the UI process of altering (maybe not just a fee bump, +1in/1ou). What's could be practice in a such case?
542 2015-12-17 19:15:13 <petertodd> Luke-Jr: but just for the UX of bumping a fee, it's a reasonable first attempt, and very simple
543 2015-12-17 19:15:22 <jonasschnelli> *best practice
544 2015-12-17 19:15:56 <Luke-Jr> jonasschnelli: to support more than fee bumping probably hugely complicates the current wallet
545 2015-12-17 19:16:15 <petertodd> jonasschnelli: well, do we have the info necessary to determine what the intent of the orig tx was, and if confirmed, simply do nothing?
546 2015-12-17 19:16:39 <petertodd> jonasschnelli: IE, if orig tx desired payment txout exists, we're done and do nothing
547 2015-12-17 19:17:14 <jonasschnelli> Hm... do nothing could be a way,.. but might confuse the user. Okay for a fee bump, probably problematic when adding a output/input.
548 2015-12-17 19:17:44 <petertodd> jonasschnelli: yeah, for adding an output you'd have to handle that by tracking intent - probably a fairly big restructuring of how the wallte works
549 2015-12-17 19:18:16 <jonasschnelli> The chance is relatively height that during altering the tx gets confirmed (if altering takes 15s, its a 2.5% chance)
550 2015-12-17 19:18:36 <petertodd> jonasschnelli: indeed
551 2015-12-17 19:19:03 <Luke-Jr> if you're adding an output B to transaction A, and A gets confirmed without B, you'd want to re-issue B as its own transaction
552 2015-12-17 19:19:14 <petertodd> yup
553 2015-12-17 19:19:18 <Luke-Jr> probably without re-prompting for passphrase
554 2015-12-17 19:19:26 <jonasschnelli> I guess this is a conceptual problem with RBF (you can't say for sure that you can alter a transaction, it could get confirmed during altering).
555 2015-12-17 19:19:39 <Luke-Jr> so up front, you'd want to prepare a signed tx with A+B, and another signed tx with just B spending from a change output created in A
556 2015-12-17 19:19:55 <petertodd> jonasschnelli: like I say, we need to track user intent and do what needs to be done by the scenes to insure that the txouts the user wants to exist, exist
557 2015-12-17 19:20:08 <petertodd> jonasschnelli: that's a very different model than transaction based
558 2015-12-17 19:20:53 <jonasschnelli> Okay. Fair enought. So a fee bump is the type of RBF action that makes sense for a GUI/users wallet.
559 2015-12-17 19:21:22 <petertodd> jonasschnelli: yeah, lets do that first
560 2015-12-17 19:21:55 <jonasschnelli> I think for 0.13 we like to see a fee bump option and some rawtx commands to alter a wtx.
561 2015-12-17 19:22:08 <btcdrak> agreed
562 2015-12-17 19:22:24 <Luke-Jr> jonasschnelli: well, adding outputs also makes sense; it's just very complicated to get there from where we are now
563 2015-12-17 19:22:39 <jonasschnelli> What about showing incoming RBF opted in txs?
564 2015-12-17 19:22:42 <Luke-Jr> fee bumping is the easy and more important use
565 2015-12-17 19:23:01 <petertodd> jonasschnelli: I strongly advise that we don't do that, because that gives users a false sense of confidence
566 2015-12-17 19:23:07 <Luke-Jr> jonasschnelli: for the average end user, either all or none would be RBF-optin
567 2015-12-17 19:23:24 <petertodd> jonasschnelli: we don't attempt to warn users about numerous other cases where they're very likely to be double-spent
568 2015-12-17 19:23:33 <petertodd> jonasschnelli: nor can we
569 2015-12-17 19:24:22 <jonasschnelli> But, if people start using/opting in RBF, people won't see incoming transactions immediately. Non experience users will think: "something is wrong with my tx".
570 2015-12-17 19:24:44 <petertodd> jonasschnelli: why wouldn't they see them immediately? rbf txs are propagated normally
571 2015-12-17 19:25:09 <Luke-Jr> ^
572 2015-12-17 19:25:20 <jonasschnelli> It would not be visible because we hide RBF (non final) 0confs?
573 2015-12-17 19:25:32 <petertodd> jonasschnelli: but we don't do that; RBF are final
574 2015-12-17 19:25:35 <Luke-Jr> that would be a stupid thing to do
575 2015-12-17 19:25:57 <petertodd> jonasschnelli: I specifically designed the opt-in mechanism to show up on most wallets
576 2015-12-17 19:25:59 <sdaftuar> jonasschnelli: nSequence is below int_max()-1, but nLocktime will still be met.
577 2015-12-17 19:26:08 <sdaftuar> so it will still be final
578 2015-12-17 19:26:24 <petertodd> jonasschnelli: having the ability to create opt-in txs easily would help remove some of this confusion I think...
579 2015-12-17 19:26:53 <jonasschnelli> yeah... need to create some examples and test it in detail...
580 2015-12-17 19:26:56 <petertodd> so action item, merge https://github.com/bitcoin/bitcoin/pull/7132
581 2015-12-17 19:27:42 <wumpus> what is #7132?
582 2015-12-17 19:27:44 <petertodd> jonasschnelli: see https://github.com/petertodd/replace-by-fee-tools/blob/master/sendmany.py
583 2015-12-17 19:27:54 <petertodd> wumpus: command line flag to opt into rbf on all outgoing txs
584 2015-12-17 19:27:59 <jonasschnelli> 7132 is very general. Do users want to opt in all wtx or should they decide when they create a new wtx?
585 2015-12-17 19:28:20 <jonasschnelli> petertodd: thanks. Will check it out.
586 2015-12-17 19:28:21 <wumpus> #action look at #7132 (command line flag to opt into rbf on all outgoing txs)
587 2015-12-17 19:28:23 <petertodd> jonasschnelli: I'm sure they'll want to do both, but there is no harm in having a global command line flag
588 2015-12-17 19:28:32 <sipa> jonasschnelli: rbf 0-conf transactions are just treated as 0-conf
589 2015-12-17 19:28:34 <jonasschnelli> petertodd: agree
590 2015-12-17 19:28:52 <sipa> jonasschnelli: bitcoin core always treats incoming 0-conf as unspendable anyway, so it doesn't matter whether they're rbf or not
591 2015-12-17 19:29:12 <cfields> suggested next topic: c++11 plans for 0.13
592 2015-12-17 19:29:21 <sipa> ack on topic
593 2015-12-17 19:29:24 <jonasschnelli> ack
594 2015-12-17 19:29:36 <wumpus> #topic c++11 plans for 0.13
595 2015-12-17 19:29:40 <wumpus> (yes please)
596 2015-12-17 19:30:01 <cfields> other than grumbles and api/abi snags, what are the current hold-ups ?
597 2015-12-17 19:30:01 <sipa> so i've been looking into the alleged ABI/stl problems when linking between c++11 and c++ libs
598 2015-12-17 19:30:16 <sipa> 1) for releases, we control the entire stack, so not an issue
599 2015-12-17 19:30:29 <wumpus> indeed, for releases it's not an issue
600 2015-12-17 19:30:31 <Luke-Jr> for binaries*
601 2015-12-17 19:30:38 <wumpus> yeah
602 2015-12-17 19:30:43 <sipa> 2) i expect any of those problems to either cause link problems, or immediate crashes
603 2015-12-17 19:30:59 <wumpus> from what I've noticed they cause link problems immediately
604 2015-12-17 19:31:06 <jonasschnelli> I think the advantages of c++11 overweighs the potential risk of leaving "strange" distros in the dark.
605 2015-12-17 19:31:06 <sipa> i don't think these are concerns
606 2015-12-17 19:31:14 <Luke-Jr> if 2 is correct, that would help significantly
607 2015-12-17 19:31:31 <sipa> cfields: do you know more about the potential failure scenarios?
608 2015-12-17 19:31:34 <wumpus> the only risk that would be enough reason to postpone would be if anything used in consensus (that eg uses boost) could become unreliable
609 2015-12-17 19:31:36 <cfields> sipa: for deps, i would think it would boil down to just boost, in practice?
610 2015-12-17 19:31:46 <sipa> cfields: Qt?
611 2015-12-17 19:31:51 <wumpus> eg the unordered_set or multiset
612 2015-12-17 19:32:02 <wumpus> just boost I think - qt seems wellbehaved in that respect
613 2015-12-17 19:32:03 <jonasschnelli> Qt works fine with c++11 (just creates a project with Qt and c++11)
614 2015-12-17 19:32:12 <cfields> sipa: from what i remember, qt isolates itself pretty well
615 2015-12-17 19:32:13 <sipa> jonasschnelli: not the point
616 2015-12-17 19:32:24 <wumpus> it turns up with templating etc, qt hardly does that
617 2015-12-17 19:32:25 <Luke-Jr> jonasschnelli: but the distro is likely compiled in C++98 mode
618 2015-12-17 19:32:59 <wumpus> and qt isn't consensus critical, boost unfortunately is
619 2015-12-17 19:33:22 <jonasschnelli> Luke-Jr: yes. This might be a problem. But from what i can tell, c++11 with distro Qt5 worked for me on OSX (brew) Ubuntu 14.04+ and debian7+ (out of the box).
620 2015-12-17 19:33:24 <cfields> it'd be worth spending some time to try to purposely hit a qt incompatibility
621 2015-12-17 19:33:38 <cfields> jonasschnelli: that's libc++ though
622 2015-12-17 19:33:42 <Luke-Jr> jonasschnelli: C++98 and C++11 mix fine with LLVM, just not GCC
623 2015-12-17 19:33:52 <sipa> wumpus: after c++11 we can reduce the consensus logic on boost significantly, though :)
624 2015-12-17 19:33:57 <wumpus> I'm much more worried about boost
625 2015-12-17 19:34:00 <wumpus> sipa: absolutely :)
626 2015-12-17 19:34:18 <cfields> wumpus: for sure. i was just hoping we could narrow it down to _only_ boost, then think in those terms
627 2015-12-17 19:34:18 <wumpus> yes that's a good point actually
628 2015-12-17 19:34:44 <cfields> for ex for boost only, we could probably do some runtime sanity detection
629 2015-12-17 19:34:50 <cfields> in the case that an incompat build actually linked
630 2015-12-17 19:34:51 <sipa> from what i read, this always results in link errors
631 2015-12-17 19:34:55 <wumpus> if we can replace boost usage (at least in consensus before) 0.13 that removes that conern
632 2015-12-17 19:35:02 <wumpus> sipa: that's also my experience
633 2015-12-17 19:35:03 <sipa> and only when types are returned across library boundaries
634 2015-12-17 19:35:13 <cfields> wumpus: +1 to that
635 2015-12-17 19:35:31 <Luke-Jr> maybe for 0.13, we should at the very least build in C++11 mode by default even if we don't use any of its features? plus one tiny C++11 most-advanced-we-want feature use that can be disabled by configure; and then just watch if anyone complains or gets stuck?
636 2015-12-17 19:35:42 <wumpus> cfields: the multi indexed set is the only hard thing in that regard IIRC
637 2015-12-17 19:36:08 <jonasschnelli> atomics!
638 2015-12-17 19:36:20 <sipa> i would like to preliminarily decide that we'll switch to c++11 for 0.13, and switch the compiler suite in master asap
639 2015-12-17 19:36:21 <cfields> jonasschnelli: bad starting case :)
640 2015-12-17 19:36:26 <jonasschnelli> haha
641 2015-12-17 19:36:27 <sipa> if we encounter no problems with that, we proceed
642 2015-12-17 19:36:33 <wumpus> me too sipa
643 2015-12-17 19:36:34 <cfields> jonasschnelli: iirc that's one of the minefields with libstdc++
644 2015-12-17 19:36:55 <cfields> sipa: sounds fine to me to
645 2015-12-17 19:37:01 <cfields> wumpus: what are the outstanding build issues?
646 2015-12-17 19:37:06 <sipa> we wait a few months before actually switching to c++11isms
647 2015-12-17 19:37:07 <cfields> just depends compat?
648 2015-12-17 19:37:12 <Luke-Jr> sipa: the risk is that we get entrenched in C++11 irreversibly, and find out when 0.13 is released that a large part of the userbase can't handle it yet
649 2015-12-17 19:37:14 <sipa> but switch the build env immediately
650 2015-12-17 19:37:22 <wumpus> cfields: just depends compat, and travis' compiler
651 2015-12-17 19:37:30 <cfields> ok
652 2015-12-17 19:37:48 <sipa> how about we only enable c++11 in one of the travis configurations, and for now require compatibility with both c++11 and c++02
653 2015-12-17 19:37:50 <cfields> there's also the matter of backports, if code starts to diverge too much
654 2015-12-17 19:37:50 <wumpus> and switching boost in depends to c++11 is pretty easy
655 2015-12-17 19:37:58 <Luke-Jr> sipa: sgtm
656 2015-12-17 19:38:06 <sipa> that will teach us about problems
657 2015-12-17 19:38:08 <wumpus> I've done that. Not tried for qt yet as that didn't seem to be necessary, but probably better to do so just in case
658 2015-12-17 19:38:34 <cfields> wumpus: may as well for a better representative case.
659 2015-12-17 19:39:06 <sipa> cfields: what is needed for depends/gitian/travis wrt c++11?
660 2015-12-17 19:39:28 <wumpus> I think we can start using basic c++11isms immediately, it doesn't matter, release is in half a year no matter what there's enough time
661 2015-12-17 19:39:42 <cfields> sipa: wumpus has looked into it more recently, but sounds trivial-ish
662 2015-12-17 19:39:51 <wumpus> as for depends it's easy
663 2015-12-17 19:39:56 <zookolaptop> FYI, the Zcash team has been building a fork of bitcoind with C++11 for a few months now, and maybe our experiences could be useful.
664 2015-12-17 19:40:04 <cfields> iirc for travis we can just specify a different compiler version
665 2015-12-17 19:40:05 <wumpus> I just didn't get it to pass travis
666 2015-12-17 19:40:08 <sipa> zookolaptop: i read about that; very interesting
667 2015-12-17 19:40:11 <Luke-Jr> wumpus: "enough time" for what?
668 2015-12-17 19:40:20 <wumpus> Luke-Jr: to get it working
669 2015-12-17 19:40:32 <sipa> i don't expect many problems
670 2015-12-17 19:40:36 <wumpus> if problems turn up we want to see them early as possible in the release cycle
671 2015-12-17 19:40:49 <sipa> in fact, it may actually improve performance immediately by just switching to it
672 2015-12-17 19:41:05 <Luke-Jr> that implies it's possible in 6 months time, which sadly doesn't seem conclusive yet
673 2015-12-17 19:41:09 <sipa> by avoiding some copy constructions where a move is implicitly okay
674 2015-12-17 19:41:17 <wumpus> what would not be possible in 6 month time?
675 2015-12-17 19:41:38 <cfields> zookolaptop: any major snags to report?
676 2015-12-17 19:41:40 <wumpus> I think we can get rid of most of boost in 6 months time
677 2015-12-17 19:42:08 <nwilcox> cfields: We've been unable to link to boost 1.57.0 w/ c++11 mode as described in https://github.com/bitcoin/bitcoin/pull/7165#issuecomment-165498586
678 2015-12-17 19:42:09 <cfields> wumpus: what's the plan for container replacement? hand-roll our own?
679 2015-12-17 19:42:22 <sipa> container?
680 2015-12-17 19:42:25 <sipa> you mean gitian?
681 2015-12-17 19:42:30 <wumpus> cfields: probably, or find some other implementation
682 2015-12-17 19:42:34 <wumpus> sipa: the multi index monster
683 2015-12-17 19:42:52 <sipa> it's not used in consensus code afaik
684 2015-12-17 19:42:54 <wumpus> it's used for the mempool though not consensus
685 2015-12-17 19:42:56 <wumpus> right
686 2015-12-17 19:43:03 <sipa> and it's a massive benefit imho
687 2015-12-17 19:43:05 <wumpus> thought of that one second later
688 2015-12-17 19:43:13 <sipa> exactly the right tool for the job
689 2015-12-17 19:43:26 <sipa> writing something hand-rolled is highly nontrivial
690 2015-12-17 19:43:31 <nwilcox> cfields: See also my notes here: https://github.com/bitcoin/bitcoin/pull/7165#issuecomment-165498136
691 2015-12-17 19:43:48 <wumpus> there may be some other implementation that is easier to include in the source than boost's though, dunno
692 2015-12-17 19:43:54 <Luke-Jr> wumpus: getting rid of boost doesn't avoid stdlib issues, does it?
693 2015-12-17 19:44:20 <cfields> nwilcox: thanks
694 2015-12-17 19:44:23 <wumpus> Luke-Jr: boost is the worst in that regard, with its heavy use of templating
695 2015-12-17 19:44:29 <sipa> Luke-Jr: what other libraries-we-use-that-potentially-are-compiled-without-c++11 are you worried about?
696 2015-12-17 19:44:32 <cfields> wumpus: actually, any chance that's header-only ?
697 2015-12-17 19:44:33 <wumpus> Luke-Jr: as said I haven't seen issues with qt nor berkeleydb
698 2015-12-17 19:44:41 <wumpus> cfields: it probably is
699 2015-12-17 19:45:03 <cfields> wumpus: in that case, other than the large dep, it would be c++11 safe
700 2015-12-17 19:45:24 <wumpus> cfields: indeed
701 2015-12-17 19:45:33 <cfields> er retrying that: it would be c++11 safe, only issue with it is that it's a large dep
702 2015-12-17 19:45:45 <Luke-Jr> sipa: if Qt pulls in the old stdlib to the linker, how does that interact with using the new stdlib?
703 2015-12-17 19:45:49 <jonasschnelli> "get rid of boost": i guess there is no c++11 alternative for boost::filesystem?
704 2015-12-17 19:45:53 <nwilcox> BTW- enabling c++11 mode "but not using its features" is not always possible w/out code changes.
705 2015-12-17 19:46:01 <wumpus> jonasschnelli: yeah boost::filesystem is another annoying one
706 2015-12-17 19:46:07 <sipa> Luke-Jr: the problem only occurs when you're passing stl structures as arguments across lib boundaries afaik
707 2015-12-17 19:46:29 <nwilcox> eg: throwing exceptions in dtors switches from possible to abort() unless you modify the dtor to add attributes.
708 2015-12-17 19:47:06 <nwilcox> wumpus: boost::filesystem "appears to work" or at least link (and make check) passes with boost 1.59.0 atop v0.11.2.
709 2015-12-17 19:47:23 <wumpus> nwilcox: cool
710 2015-12-17 19:47:50 <cfields> another kinda invasive change would need to be made to drop the boost::interruption stuff too
711 2015-12-17 19:48:07 <wumpus> that's easy to emulate
712 2015-12-17 19:48:17 <wumpus> the only thing that the interruption stuff does is throw an exception
713 2015-12-17 19:48:34 <nwilcox> I noiced on ticket #7165 requirements for ensuring C++11 support works on a list of distributions.  Are there automated build/make check CI for all of those distros/configs?
714 2015-12-17 19:48:51 <nwilcox> s/noiced/noticed/
715 2015-12-17 19:48:52 <Luke-Jr> is there a way to easily test building with C++11 today? --enable-c++11 or something?
716 2015-12-17 19:49:03 <Luke-Jr> is just throwing -std=c++11 in CXXFLAGS good enough?
717 2015-12-17 19:49:13 <wumpus> nwilcox: there's no problem as long as your gcc compiler is >=4.8
718 2015-12-17 19:49:18 <Luke-Jr> nwilcox: there's no realistic way to automate that in Travis :<
719 2015-12-17 19:49:51 <wumpus> "c++11 support" really isn't anything magical or new anymore at this point
720 2015-12-17 19:50:01 <nwilcox> Luke-Jr: Hm... we have a fledgling builtbot set up, and it would be worth it to us to have build/test coverage for many different configurations... (but probably not <6 mo time frame).
721 2015-12-17 19:50:03 <wumpus> many software uses it
722 2015-12-17 19:50:03 <zookolaptop> Luke-Jr: that's one of the main reasons that Zcash switched from Travis to Buildbot.
723 2015-12-17 19:50:04 <cfields> we can always add checks to configure as well
724 2015-12-17 19:50:07 <Luke-Jr> wumpus: I'm not sure 4.8 is sufficient? https://gcc.gnu.org/wiki/Cxx11AbiCompatibility
725 2015-12-17 19:50:33 <wumpus> Luke-Jr: well my 4.8 support c++11, depends on what features you use obviously
726 2015-12-17 19:50:52 <Luke-Jr> wumpus: "maps, sets, and trees" apparently has ABI issues until 4.8.2
727 2015-12-17 19:50:53 <sipa> afaik no compiler on earth implements all of c++11 :)
728 2015-12-17 19:50:54 <nwilcox> -so if we start adding build configurations for those platforms, we might be able to setup bitcoin-core build/tests for them.
729 2015-12-17 19:51:35 <wumpus> I don't think we should add more travis configurations
730 2015-12-17 19:51:55 <wumpus> the pull tester is already sloow
731 2015-12-17 19:52:03 <sipa> can we give it more juice?
732 2015-12-17 19:52:13 <sipa> in the form of money
733 2015-12-17 19:52:20 <jonasschnelli> add a 2nd free travis alternative to build more confs parallel?
734 2015-12-17 19:52:24 <cfields> Luke-Jr: those are libstdc++ compatibility issues. eg. linking with a newer version than what's found at runtime
735 2015-12-17 19:52:38 <wumpus> it used to be bitcoin foundation paying for that but... eh nm
736 2015-12-17 19:52:38 <zookolaptop> wumpus: I think nwilcox is offering that the Zcash company will set up automated testing for you.
737 2015-12-17 19:52:46 <jonasschnelli> ;)
738 2015-12-17 19:52:48 <wumpus> zookolaptop: oh that'd be cool
739 2015-12-17 19:52:49 <cfields> i pinged them a while back but never heard back. i'll try again.
740 2015-12-17 19:52:56 <nwilcox> jonasschnelli: That's what I was proposing is *possible* with buildbot. I can't commit to effort at the moment, but we have overlapping needs and could reuse infrastructure.
741 2015-12-17 19:53:21 <zookolaptop> I concur that bitcoin core and zcash both want automated testing of this stuff on many platforms.
742 2015-12-17 19:53:23 <wumpus> zookolaptop: I thought he meant adding all those to travis, sure another parallel solution would be great @nwilcox
743 2015-12-17 19:53:28 <nwilcox> zookolaptop: I'm not offering that yet.  Can't commit to it, but it's on my wishlist.
744 2015-12-17 19:54:21 <cfields> we can also reach out to distros for help. nightly ppa's, ~git versions, etc
745 2015-12-17 19:54:41 <nwilcox> cfields: +1
746 2015-12-17 19:54:52 <nwilcox> So do gitian builds use ./depends?  What uses ./depends?
747 2015-12-17 19:55:01 <cfields> wumpus: so summing up, you're ready to flip the switch on the requirement as soon as travis is building/passing?
748 2015-12-17 19:55:07 <sipa> nwilcox: travis and gitian use depends
749 2015-12-17 19:55:08 <cfields> wumpus: or start with one config and don't require it?
750 2015-12-17 19:55:09 <nwilcox> We've been using it exclusively because we like having more control over transitive dependencies.
751 2015-12-17 19:55:14 <wumpus> I use depends for cross-compiling to ARM
752 2015-12-17 19:55:20 <jonasschnelli> cfields: would switching over to travises non-sudo environment speed up building?
753 2015-12-17 19:55:38 <wumpus> cfields: yep
754 2015-12-17 19:55:51 <cfields> wumpus: which? :)
755 2015-12-17 19:56:01 <jonasschnelli> And we should also include codeship.com to build more confs in less time (in parallel with travis)
756 2015-12-17 19:56:23 <wumpus> cfields: the first one, switch builds to std=c++11 as soon as travis can do it
757 2015-12-17 19:56:24 <cfields> jonasschnelli: yes, but we can't atm due to caching requirements
758 2015-12-17 19:56:44 <sipa> #action switch some builds to c++11?
759 2015-12-17 19:56:50 <wumpus> I think it's clear that everyone wants c++11, we should just push ahead with it
760 2015-12-17 19:57:07 <cfields> jonasschnelli: though it's worth re-evaluating the status there. I hacked on that a while back, but shelved it to work on some other stuff
761 2015-12-17 19:57:14 <jgarzik> +1
762 2015-12-17 19:57:22 <nwilcox> Does this require upgrading boost requirements?  (That was our solution to two issues.)
763 2015-12-17 19:57:23 <wumpus> and if zookolaptopand nwilcoxcan help with testing that'd be doubly cool
764 2015-12-17 19:57:27 <petertodd> I'm off, going skiing
765 2015-12-17 19:57:37 <cfields> wumpus: roger. I'll start working on the PRs
766 2015-12-17 19:57:43 <sipa> petertodd: i hope you're on a slippery slope there
767 2015-12-17 19:57:48 <jonasschnelli> ;)
768 2015-12-17 19:57:48 <nwilcox> wumpus: I can help by testing builds and reviewing changes to the build system.
769 2015-12-17 19:57:51 <cfields> nwilcox: boost should already be sufficiently bumped
770 2015-12-17 19:58:17 <nwilcox> Actually doing the latter will probably help me a lot, since I'm new to autoconf/automake and feel like I'm hacking through a jungle.
771 2015-12-17 19:58:18 <wumpus> I think our boost is very recent?
772 2015-12-17 19:58:29 <nwilcox> cfields: Ah...  I haven't looked at master.
773 2015-12-17 19:58:46 <Luke-Jr> we need to support building with stable distro boosts, not just the one in depends…
774 2015-12-17 19:59:10 <wumpus> Luke-Jr: if we can reduce boost usage to just header-only, that's solved
775 2015-12-17 19:59:18 <Luke-Jr> wumpus: not really.
776 2015-12-17 19:59:25 <cfields> Luke-Jr: hmm?
777 2015-12-17 20:00:01 <sipa> #DING DONG
778 2015-12-17 20:00:15 <cfields> heh
779 2015-12-17 20:00:21 <jonasschnelli> hah
780 2015-12-17 20:00:36 <wumpus> nwilcox: cfields: https://github.com/bitcoin/bitcoin/pull/6980  "[Depends] Bump Boost, miniupnpc, ccache & zeromq #6980"
781 2015-12-17 20:00:39 <wumpus> oh
782 2015-12-17 20:00:41 <wumpus> #endmeeting
783 2015-12-17 20:00:42 <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-12-17-19.01.log.html
784 2015-12-17 20:00:42 <lightningbot> Meeting ended Thu Dec 17 20:00:41 2015 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
785 2015-12-17 20:00:42 <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-12-17-19.01.html
786 2015-12-17 20:00:42 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-dev/2015/bitcoin-dev.2015-12-17-19.01.txt
787 2015-12-17 20:01:12 <nwilcox> wumpus: thanks!
788 2015-12-17 20:01:14 <cfields> sipa: btw, some miracle? isn't your laptop battery oil burning longer than expected?
789 2015-12-17 20:01:32 <sipa> cfields: no, arrived at the office, and found a power plug
790 2015-12-17 20:01:58 <cfields> sipa: ah, the other equally likely possibility.
791 2015-12-17 20:02:03 <jonasschnelli> hahaha
792 2015-12-17 20:02:27 <zookolaptop> Wasn't clear to me: was this push to start building with c++11 for 0.12?
793 2015-12-17 20:02:34 <sipa> zookolaptop: no, 0.13
794 2015-12-17 20:02:38 <zookolaptop> Thanks.
795 2015-12-17 20:02:43 <sipa> not going to make such a drastic change in 0.12 anymore
796 2015-12-17 20:03:04 <jgarzik> 0.12 is frozen
797 2015-12-17 20:03:10 <zookolaptop> Good.
798 2015-12-17 20:03:29 <zookolaptop> FYI, zcash has no choice but to use c++11 for at least some of our libs,
799 2015-12-17 20:03:42 <zookolaptop> and our current approach is to compile the bitcoind-fork code with c++11 as well,
800 2015-12-17 20:03:51 <zookolaptop> and we hope to rebase on top of bitcoind 0.12 soon,
801 2015-12-17 20:04:20 <zookolaptop> so all of that means we should have some data for you about how well compiling 0.12 with c++11 works, when this 0.13-era push to adopt c++11 happens.
802 2015-12-17 20:05:36 <wumpus> compiling 0.12 with c++11 works fine, the only wonder is dependencies
803 2015-12-17 20:05:57 <wumpus> if your boost is compiled with c++11 - no problem
804 2015-12-17 20:06:17 <zookolaptop> nwilcox: is what wumpus just said consistent with your experience?
805 2015-12-17 20:06:57 <wumpus> there have been some changes pre-0.12 to make it build with -std=c++11
806 2015-12-17 20:07:00 <nwilcox> I don't have experience with 0.12 yet.
807 2015-12-17 20:07:06 <nwilcox> So yes, it is consistent. ;-)
808 2015-12-17 20:07:18 <zookolaptop> :-)
809 2015-12-17 20:07:35 <zookolaptop> wumpus: glad to hear it! That removes one concern I have about zcash rebasing onto 0.12.
810 2015-12-17 20:08:13 <Luke-Jr> indeed, just tried to build Core master with -std=c++11 and it fails :<
811 2015-12-17 20:08:22 <zookolaptop> *sigh*
812 2015-12-17 20:08:35 <cfields> Luke-Jr: fails how?
813 2015-12-17 20:08:36 <wumpus> Luke-Jr: build or link?
814 2015-12-17 20:08:42 <Luke-Jr> /usr/include/boost/filesystem/operations.hpp:492: undefined reference to `boost::filesystem::detail::copy_file(boost::filesystem::path const&, boost::filesystem::path const&, boost::filesystem::copy_option, boost::system::error_code*)'
815 2015-12-17 20:08:48 <zookolaptop> Which IRC channel is for discussing rewriting all the things in Rust? :-(
816 2015-12-17 20:09:08 <wumpus> yes, the boost filesystem issue is known, you can get around it by upgrading boost
817 2015-12-17 20:09:32 <wumpus> I think I actaully mention it in my pull
818 2015-12-17 20:09:39 <Luke-Jr> IMO that is a blocker, since users should not need to hand-manage their libs
819 2015-12-17 20:09:43 <wumpus> but it's not a bitcoin core incompatibility
820 2015-12-17 20:09:48 <wumpus> just a dependency, as I said above
821 2015-12-17 20:09:51 <Luke-Jr> …
822 2015-12-17 20:10:07 <wumpus> it's probably realistic to remove boost filesystem usage for 0.13
823 2015-12-17 20:10:17 <Luke-Jr> ok
824 2015-12-17 20:10:32 <cfields> wumpus: really? again, roll our own?
825 2015-12-17 20:10:47 <cfields> (i'm not against, just surprised that you'd be supportive of that :)
826 2015-12-17 20:10:50 <Luke-Jr> IMO step 1: successful build on all mainstream distros (without depends/) with -std=c++11 :P
827 2015-12-17 20:10:57 <jonasschnelli> What do we really use from boost filesystem? Recursive mkdir?
828 2015-12-17 20:11:04 <wumpus> cfields: I don't thinkk it is a big deal, we don't use much from it
829 2015-12-17 20:11:27 <wumpus> cfields: and it'd be nice to get rid of the locale voodoo
830 2015-12-17 20:11:56 <cfields> indeed. I'd support the drop for sure.
831 2015-12-17 20:12:28 <jonasschnelli> leveldb also uses boost::filesystem... is guess we need to get rid of that as well?
832 2015-12-17 20:12:34 <cfields> we can always revert to abstracted behavior when we bump to require c++17 :p
833 2015-12-17 20:12:39 <jonasschnelli> no.. wait. wrong.
834 2015-12-17 20:12:42 <cfields> jonasschnelli: eh?
835 2015-12-17 20:12:42 <wumpus> jonasschnelli: NOOO
836 2015-12-17 20:13:01 <jonasschnelli> *shocker* ,.. sorry
837 2015-12-17 20:13:06 <wumpus> hehe you got me
838 2015-12-17 20:14:03 <jgarzik> removing boost::filesystem is straightforward.  the main loss is the code will look less pretty :)    You lose the "string" / "string" composition of paths.
839 2015-12-17 20:14:11 <wumpus> why? just roll your own
840 2015-12-17 20:14:36 <jonasschnelli> "string" + "/" + "string" looks okay?
841 2015-12-17 20:14:39 <wumpus> that's easy to implement :) concatenate-with-OS-dependent-path-char
842 2015-12-17 20:14:47 <wumpus> for windows you want "\\"
843 2015-12-17 20:15:01 <cfields> :)
844 2015-12-17 20:15:01 <cfields> operator/(string rhs) { return path + rhs; }
845 2015-12-17 20:15:03 <jonasschnelli> wumpus: IIRC, mingw/windows can handle "/" just fine?
846 2015-12-17 20:15:07 <wumpus> cfields: yeah that
847 2015-12-17 20:15:31 <wumpus> jonasschnelli: from what I heard I don't think that's true in all cases, and people expect \ in GUIs etc
848 2015-12-17 20:15:57 <wumpus> anyhow it's not a big deal
849 2015-12-17 20:16:01 <jonasschnelli> indeed-
850 2015-12-17 20:16:20 <wumpus> jonasschnelli: I think the problem is if you *mix* / and \ in a path
851 2015-12-17 20:16:53 <jonasschnelli> replace(<string>, "/", "\")
852 2015-12-17 20:16:59 <jonasschnelli> *duck*
853 2015-12-17 20:17:06 <wumpus> hah
854 2015-12-17 20:17:32 <jonasschnelli> need to leave... nite everyone.
855 2015-12-17 20:17:39 <zookolaptop> Me too. Bye y'all!
856 2015-12-17 20:17:50 <wumpus> night