1 2016-01-21 00:00:13 <maaku> What do you mean blocked by bitcoin?
  2 2016-01-21 00:00:52 <joecool> maaku: I mean blocked specifically by a check in the configure code, relevant issue on the matter: https://github.com/bitcoin/bitcoin/pull/6244
  3 2016-01-21 00:01:10 <TD-Linux> joecool, literally two seconds of googling: https://github.com/bitcoin/bitcoin/pull/6732
  4 2016-01-21 00:02:09 <TD-Linux> tl;dr it's not blocked anymore
  5 2016-01-21 00:03:09 <joecool> TD-Linux: thanks
  6 2016-01-21 01:16:24 <rusty2> btcdrak, kanzure, jgarzik: I started the bitcoin-dev moderation review thread.  Publicity would be welcome.
  7 2016-01-21 01:19:11 <sydOutlier> Hi all. Complete irc noob here please be gentle :p
  8 2016-01-21 01:20:59 <sydOutlier> I am hoping to begin contributing to the bitcoin core development project but I am new to open source dev and was hoping I could get some pointers?
  9 2016-01-21 01:21:10 <sydOutlier> Don't mind doing grunt work like testing etc.
 10 2016-01-21 01:22:23 <Guest91472> Look at the issue tracker on github. Read the source and try writing test cases to understand it better
 11 2016-01-21 01:22:36 <Guest91472> Get an IRC bouncer if you don't have one.
 12 2016-01-21 01:22:43 <gijensen> sydOutlier: https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md
 13 2016-01-21 01:25:52 <sydOutlier> Thank you. I'm pretty new to Linux also. Have experience with Debian and Mint so far. Can you recommend a distro best suited to bitcoin dev?
 14 2016-01-21 01:26:29 <gijensen> Id recommend Debian
 15 2016-01-21 01:27:14 <gijensen> Whatever you're comfortable with though. Mint is similar anyways
 16 2016-01-21 01:29:22 <sydOutlier> Thanks. I really like Mint but its so feature rich I was thinking debian a more secure choice? Also I'd rather be learning proper linux commands than using an update manager app etc.
 17 2016-01-21 01:33:03 <sydOutlier> though I guess there's nothing to stop me doing that in Mint also but the spartan characteristic of debian remind me of being 16 and writing TSR programs in ms-dos (nostalgic appeal i guess)
 18 2016-01-21 01:35:53 <sydOutlier> so i guess i have a couple more questions (and again i apologise they will sound obtuse i grew up on microsoft tech):
 19 2016-01-21 01:36:13 <sydOutlier> will i need to installe web server component of debian?
 20 2016-01-21 01:37:20 <kefkius> sydOutlier: Nope, a web server is not required for development of bitcoin
 21 2016-01-21 01:38:03 <kefkius> Also regarding distros: Since you're new to Linux, the best distro for development is whatever you can work comfortably in :)
 22 2016-01-21 01:38:06 <sydOutlier> thank you. also are there any particular dev tools i should get?
 23 2016-01-21 01:38:22 <kefkius> It's all personal preference
 24 2016-01-21 01:38:35 <sydOutlier> thanks kefkius
 25 2016-01-21 01:38:50 <kefkius> For example, all of my coding happens with vim and tmux, but that won't work for everybody
 26 2016-01-21 01:38:53 <kefkius> np
 27 2016-01-21 01:38:59 <sydOutlier> i'm kinda like a nervous refugee from microsoft totalitarian state lol
 28 2016-01-21 01:41:41 <gijensen> sydOutlier, generally Debian is thought to be more secure I believe. I certainly prefer it for servers anyways
 29 2016-01-21 01:41:52 <sydOutlier> and the last but not least newbie question: i should "clone" the repository to get a local copy. i.e. don't want to affect dev branches in any way
 30 2016-01-21 01:42:19 <gijensen> You have read-only access so don't worry about messing up someone's work but yes
 31 2016-01-21 01:42:34 <sydOutlier> thanks, gijensen
 32 2016-01-21 01:42:38 <kefkius> Ahh, learning git is a great favor you can do for yourself, I do recommend that (as a random internet stranger)
 33 2016-01-21 01:43:23 <gijensen> Yes I highly recommend learning how to use branches and remotes at least. They make flow a lot smoother
 34 2016-01-21 01:45:42 <sydOutlier> this is actually my first foray into open source dev. pretty excited about it actually after decades of soul-less ms dev in financial services
 35 2016-01-21 01:46:07 <sydOutlier> unit registry migration in (ok not ms) sybase - yay what fun!
 36 2016-01-21 01:46:35 <sydOutlier> or fix the bug in this vb6 utility we have and no we don't use .net yet
 37 2016-01-21 01:47:26 <sydOutlier> and the finest example of all: somehow learn vb3 cos that's what our portfolio mamnagement system is written in * dies inside *
 38 2016-01-21 01:48:17 <sydOutlier> anyway off topic! thank you very much for the pointers. i'll be back when i have some semblence of an environment operational and have reviewed that doc link
 39 2016-01-21 04:10:33 <derbumi> kredits list
 40 2016-01-21 04:59:17 <alex_____> Is it possible to create a 2-2 multisig payout address without knowing 1 of the xpubs that comprise that address?
 41 2016-01-21 05:21:12 <kanzure> rusty: fwiw, re: +1s, i largely agree with you, with the following exception: if it was someone who was arguing the other position, and then was convinced by some further argumentation, it makes sense for the person to post a follow-up saying "Oh, yes, I agree.". and that should probably be let through the moderation queue.
 42 2016-01-21 05:21:35 <rusty> kanzure: sure, it's deprecated, not banned.
 43 2016-01-21 06:41:53 <Lauda> "Back to SW, someone recently pointed out that in an environment of 75% SW nodes, the malicious users only need over 37.5% of hash power to attack the network. This is because the rest 25% of non-SW nodes will not be able to detect the double spending since what they see is only empty blocks "
 44 2016-01-21 06:41:54 <Lauda> Anyone?
 45 2016-01-21 08:56:44 <sturles> False.  They don't see empty blocks.
 46 2016-01-21 08:59:49 <sipa> alex___: no
 47 2016-01-21 09:00:46 <da2ce7_> hello all :) Back from Vacatoin!  India is beautaful!
 48 2016-01-21 09:01:16 <da2ce7_> (oh and it seems like spelling also left me).
 49 2016-01-21 09:03:43 <sipa> Lauda: incorrect; double spending rules are not cbanged by SW, and old nodes still see all inputs and outputs, they do not see empty blocks.
 50 2016-01-21 09:05:42 <jl2012> Lauda: the number of nodes has nothing to do with the hashing power
 51 2016-01-21 09:06:16 <sipa> right, and what jl2012 says: the statement seems to confuse hash power with full nodes
 52 2016-01-21 09:07:35 <jl2012> attack like that is always possible, but the threshold is always 51%
 53 2016-01-21 09:09:36 <sipa> it's more complicated: a 51% hashrate that agrees with each other can always produce the longest chain, but that still doesn't mean it will be considered valid
 54 2016-01-21 09:10:23 <jl2012> SPV node that do not do any validation will consider it valid
 55 2016-01-21 09:10:41 <jl2012> but that's unrelated to segwit
 56 2016-01-21 09:12:44 <sipa> indeed
 57 2016-01-21 09:13:00 <sipa> also, the switchover point is intended to be 95%
 58 2016-01-21 10:06:29 <kang_> For a new developer looking to bitcoin dev, any advise on how to tackle the mailing-list mountain? How to organize, what is must & what can be left out?
 59 2016-01-21 10:09:31 <wumpus> kang_, I'd say work on what you want to work on, read posts that interest you, there's no way to follow everything
 60 2016-01-21 10:10:06 <kang_> wumpus: Thanks. If anyone joined recently, how did they organize it?
 61 2016-01-21 10:59:25 <btcdrak> kang_: yes, work on what you like. you are welcome to our weekly meetings too. 19:00UTC every Thursday
 62 2016-01-21 10:59:58 <btcdrak> kang_: also read CONTRIBUTING.md in the root of the source repository
 63 2016-01-21 11:00:22 <kang_> btcdrak: yes, ok. thanks
 64 2016-01-21 14:15:20 <Lauda> Thanks sipa, jl2012.
 65 2016-01-21 14:21:31 <Lauda> "Based on such actual data and the avg block txs compositions SegWit will give s scaling factor of ~1.75x once the soft-fork will be adopted by 100% of the network.
 66 2016-01-21 14:21:31 <Lauda> - SegWit deployed on april/may 2016
 67 2016-01-21 14:21:31 <Lauda> This is a possible scenario:
 68 2016-01-21 14:21:32 <Lauda> - 50% of adoption after one year
 69 2016-01-21 14:21:32 <Lauda> - Soft-Fork triggers in Jun/July 2016
 70 2016-01-21 14:21:33 <Lauda> if all the above are valid that means that you will have 1.35MB  vitual max block size by june/july 2017.
 71 2016-01-21 14:21:36 <Lauda> "
 72 2016-01-21 14:21:40 <Lauda> Someone claimed this apaprently..
 73 2016-01-21 14:21:54 <Lauda> https://www.reddit.com/r/btc/comments/41uu0j
 74 2016-01-21 14:22:06 <sipa> yes, that's correct, but not relevant
 75 2016-01-21 14:22:18 <sipa> there is no need to wait for anyone else to upgrade
 76 2016-01-21 14:22:59 <Lauda> 1.35MB block size in July 2017?
 77 2016-01-21 14:23:07 <sipa> once you upgrade, you youself get the scale improvement
 78 2016-01-21 14:23:26 <sipa> as in: once you upgrade, you'll be able to do 1.75x as many transactions for the same price
 79 2016-01-21 14:23:33 <sipa> independent of whether anyone else upgrades or not
 80 2016-01-21 14:24:01 <sipa> (which probably leads to faster adopting if people care about it, but that's not necessary for the scale argument)
 81 2016-01-21 14:24:06 <Lauda> sipa I've also read somewhere that F2Pool made a deal with Core for 2 MB blocks in 2017, is this true or propaganda?
 82 2016-01-21 14:24:11 <Lauda> No idea where I've read this
 83 2016-01-21 14:24:21 <sipa> i have not seen any proposal
 84 2016-01-21 14:25:15 <bsm1175321> @sipa Any comments on my proposal to tie an extension block mechanism to your new address format, as well as segwit, to alleviate some of these scaling concerns?
 85 2016-01-21 14:25:32 <sipa> bsm1175321: if you can get that implemented in a few weeks, sure :)
 86 2016-01-21 14:25:51 <bsm1175321> I'd like to, but I have a lot on my plate.  :-(
 87 2016-01-21 14:26:06 <sipa> just the address format change without a consensus rule to allow spending would mean that enabling the latter is a hard fork
 88 2016-01-21 14:26:08 <bsm1175321> Starting with a BIP and making a capacity roadmap I think would help a lot.
 89 2016-01-21 14:26:16 <sipa> feel free to write that
 90 2016-01-21 14:26:40 <bsm1175321> http://blog.sldx.com/go-fork-yourself-more-bitcoin-transactions/
 91 2016-01-21 14:26:43 <sipa> i don't mean to sound dismissive, but i wouldn't want to make a claim in a roadmap without having a reasonable implementation ready
 92 2016-01-21 14:27:02 <bsm1175321> I'd like to, but probably won't be able to get to it until next week.  I was hoping to spur someone else to action.
 93 2016-01-21 14:27:52 <bsm1175321> sipa: I appreciate your need for an implementation. But obviously the 2MB crowd are not concerning themselves with such details.
 94 2016-01-21 14:28:07 <bsm1175321> Making an extension block BIP is more PR than anything.
 95 2016-01-21 14:28:22 <sipa> my time is limited too
 96 2016-01-21 14:28:40 <bsm1175321> Anyone else?
 97 2016-01-21 14:30:04 <gavinandresen> Go implement extension block support in the Core wallet code, then come back. If it has an OK user experience and wasn't six months of work, then maybe I'll change my mind about extension blocks.
 98 2016-01-21 14:30:47 <bsm1175321> gavinandresen: It's a grotesque way forward, I give you that. But it's better than doing violence to running bitcoin services who don't/can't upgrade.
 99 2016-01-21 14:31:30 <gavinandresen> you have a strange notion of violence.
100 2016-01-21 14:31:40 <gavinandresen> ... but that discussion isn't appropriate here
101 2016-01-21 14:32:19 <gavinandresen> I'll re-state: go implement a prototype so we can judge it's technical feasibility.
102 2016-01-21 14:32:42 <gavinandresen> If it is technically feasible, then I'll reconsider my position on extension blocks as being a viable scaling mechanism.
103 2016-01-21 14:33:23 <bsm1175321> I think you know that won't be done by the time Classic forces this issue.
104 2016-01-21 14:33:46 <gavinandresen> "okey dokey"
105 2016-01-21 14:33:47 <gavinandresen> "okey dokey"
106 2016-01-21 14:34:25 <bsm1175321> Yeah you're right, breaking peoples bitcoin services is definitely better.
107 2016-01-21 14:35:47 <gavinandresen> send me an email explaining what services will be broken and explaining why they can't upgrade, please.
108 2016-01-21 14:35:48 <gavinandresen> send me an email explaining what services will be broken and explaining why they can't upgrade, please.
109 2016-01-21 14:36:25 <gavinandresen> (again, that discussion isn't appropriate for here, this channel is for active development of stuff)
110 2016-01-21 14:36:42 <bsm1175321> Let's say I built SatoshiDice and I fall ill...
111 2016-01-21 14:37:11 <Lauda> bsm1175321 this is why hard forks need to take a lot of time and consensus
112 2016-01-21 14:37:17 <Lauda> Rushing one makes no sense at all.
113 2016-01-21 14:38:25 <bsm1175321> This fight is way premature.  I'm putting my time into braids, which will add FAR more capacity than any block size increase.  I'd like us to evaluate braids, subchains, Bitcoin-NG on their technical merits to solve this problem, rather than causing a hard fork.
114 2016-01-21 14:38:54 <bsm1175321> A hard fork is a short term band-aid that doesn't solve the underlying problem.
115 2016-01-21 14:40:24 <JackH> a hard fork opens up for more hard forks
116 2016-01-21 14:40:32 <JackH> like more than 21 million coins
117 2016-01-21 14:48:30 <Lauda> bsm1176321 braids?
118 2016-01-21 15:18:20 <Chris_Stewart_5> gavinandresen: Can you embed strings into scriptPubKey's and still have them be valid?
119 2016-01-21 15:18:41 <Chris_Stewart_5> or scriptSigs for that matter
120 2016-01-21 15:19:20 <gavinandresen> scriptPubKeys are not interpreted until they are spent, so you can put anything you like there... but nodes won't relay them, and miners won't mine them.
121 2016-01-21 15:20:12 <gavinandresen> scriptSigs are similar.
122 2016-01-21 15:20:17 <Chris_Stewart_5> so if 'gavin_was_here' was in a script pubkey you just serlialize it byte by byte correct?
123 2016-01-21 15:20:38 <Chris_Stewart_5> .. i'm going through your old test cases :-)
124 2016-01-21 15:20:50 <gavinandresen> do you mean how would you encode it in a scriptpubkey?  If you want it to get relayed/mined, you'd embed it in an OP_RETURN scriptPubKey
125 2016-01-21 15:21:32 <Chris_Stewart_5> i'm trying to rebuild the 'Script' language. There are files called script_valid.json and script_invalid.json which (from what I can tell) indicates valid and invalid script combinations
126 2016-01-21 15:22:04 <gavinandresen> Ah--  if I recall correctly, double-quoted strings are turned into OP_PUSHDATA ... string ...
127 2016-01-21 15:22:15 <gavinandresen> .. by the JSON parsing code for those tests
128 2016-01-21 15:23:03 <gavinandresen> Might be a special case if the string starts with 0x ... my memory is fuzzy
129 2016-01-21 15:23:04 <gavinandresen> Might be a special case if the string starts with 0x ... my memory is fuzzy
130 2016-01-21 15:23:27 <Chris_Stewart_5> Yeah, I just wrote a regex to match the strings that start with '0x' to convert them to their byte representations
131 2016-01-21 15:23:44 <Chris_Stewart_5> Is there a reason the data formats are so inconsistent in the test cases? :/
132 2016-01-21 15:23:57 <gavinandresen> multiple people wrote various test cases....
133 2016-01-21 15:24:23 <Chris_Stewart_5> file i'm looking at btw: https://github.com/bitcoin/bitcoin/blob/master/src/test/data/script_valid.json
134 2016-01-21 15:24:25 <gavinandresen> Or they were written at different times by somebody like me who forgets what they did three years ago
135 2016-01-21 16:21:50 <jonasschnelli> maaku are you sure about "signing process does not use random nonces"... what's https://github.com/bitcoin/secp256k1/blob/master/include/secp256k1.h#L552 for?
136 2016-01-21 16:25:14 <maaku> jonasschnelli: default nonce function is this: https://github.com/bitcoin/secp256k1/blob/master/src/secp256k1.c#L314
137 2016-01-21 16:26:30 <jonasschnelli> maaku: okay. I see. Hmm.. why do we fees/randomize the context with 32byte of entropy? (https://github.com/bitcoin/bitcoin/blob/605c17844ea32b6d237db6d83871164dc7d59dab/src/key.cpp#L307)
138 2016-01-21 18:59:46 <jonasschnelli> meeting?
139 2016-01-21 18:59:52 <wumpus> #startmeeting
140 2016-01-21 18:59:53 <lightningbot`> Meeting started Thu Jan 21 18:59:52 2016 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
141 2016-01-21 18:59:53 <lightningbot`> Useful Commands: #action #agreed #help #info #idea #link #topic.
142 2016-01-21 19:00:06 <wumpus> topic proposals?
143 2016-01-21 19:00:07 <wumpus> topic proposals?
144 2016-01-21 19:00:18 <jonasschnelli> proposed topic opt-in RBF default value
145 2016-01-21 19:01:35 <wumpus> I'd say there's been enough discussion of that on github already today, but ok
146 2016-01-21 19:01:36 <cfields> proposed topic: 0.11 backport release for (at least) chainstate obfuscation
147 2016-01-21 19:01:53 <wumpus> #topic opt-in RBF default value
148 2016-01-21 19:01:56 <jonasschnelli> proposed topic: leveldb corruption
149 2016-01-21 19:02:04 <jonasschnelli> okay. RBF...
150 2016-01-21 19:02:27 <jonasschnelli> today i said lets not get pushed into a corner... but somehow users are afraid of RBF.
151 2016-01-21 19:02:38 <jeremias> hmm, is leveldb prone for corruption?
152 2016-01-21 19:03:53 <jonasschnelli> not saying we should make the RBF default false, but maybe we should consider in in terms to not deeper splitting the community
153 2016-01-21 19:03:58 <wumpus> I've said everything I wanted to say on the topic in https://github.com/bitcoin/bitcoin/pull/7386 https://github.com/bitcoin/bitcoin/pull/7388
154 2016-01-21 19:04:17 <jonasschnelli> Okay. I agree.
155 2016-01-21 19:04:49 <wumpus> #topic 0.11 backport release for (at least) chainstate obfuscation
156 2016-01-21 19:04:53 <jonasschnelli> I think we should then stick to what we said and keep RBF on by default. I'm fine with this it should just be the groups opinion.
157 2016-01-21 19:06:16 <wumpus> ACK on backport release, the code (#7259) is already in there, so it's just a matter of tagging
158 2016-01-21 19:06:41 <gmaxwell> I had suggested we do that back at the last 0.11 release... but the changes aren't super small and obviously correct.
159 2016-01-21 19:06:42 <wumpus> it also has some other fixes like #7381
160 2016-01-21 19:06:45 <cfields> context: it's not possible to downgrade from 0.12 -> 0.11 in most cases.
161 2016-01-21 19:06:51 <cfields> right, sounds good
162 2016-01-21 19:07:02 <phantomcircuit> jonasschnelli, i have yet to see a single entity which accepts unconfirmed transactions raise issue with opt-in RBF
163 2016-01-21 19:07:03 <sdaftuar> will pruning nodes be able to downgrade withotu redownloading the blockchain?  i havent' reviewed that pull yet
164 2016-01-21 19:07:04 <gmaxwell> cfields: right, not if you started on 0.12 or reindexed on 0.12.
165 2016-01-21 19:07:35 <wumpus> jonasschnelli: it seems by far most want to leave it enabled, there are a few people strongly against it, which now have their option
166 2016-01-21 19:07:51 <cfields> gmaxwell: are you nervous about the backport? or the change itself when it went in?
167 2016-01-21 19:07:52 <jonasschnelli> wumpus: Yes. Fully agree.
168 2016-01-21 19:08:01 <wumpus> sdaftuar, downgrading is no issue, unless you've reindexed
169 2016-01-21 19:08:32 <wumpus> reindexing builds a new chainstate with obfuscation enabled
170 2016-01-21 19:09:15 <wumpus> which is why we want to backport so that people get a sane error message instead of an assertion fail
171 2016-01-21 19:09:22 <gmaxwell> cfields: I'm not really nervous, but some expressed nervousness before; and I couldn't disagree. Perhaps we're better now that it's been in master for a long time.
172 2016-01-21 19:09:43 <sdaftuar> wumpus: ah ok
173 2016-01-21 19:09:44 <wumpus> gmaxwell, to be clear this is not a backport of the obfuscation code, just an error
174 2016-01-21 19:10:14 <cfields> wumpus: oh, that wasn't my understanding. guess i need to click on those PRs
175 2016-01-21 19:10:19 <wumpus> gmaxwell, see #7259
176 2016-01-21 19:10:32 <wumpus> ^ cfields
177 2016-01-21 19:10:35 <jonasschnelli> https://github.com/bitcoin/bitcoin/pull/7259
178 2016-01-21 19:10:38 <wumpus> so there's no reason to be nervous
179 2016-01-21 19:10:43 <cfields> wumpus: right, looking
180 2016-01-21 19:12:21 <gmaxwell> oh! just an error.
181 2016-01-21 19:12:24 <cfields> wumpus: i don't care strongly enough to argue, works for me
182 2016-01-21 19:12:26 <gmaxwell> sorry, missed that.
183 2016-01-21 19:12:29 <gmaxwell> okay. sounds great.
184 2016-01-21 19:13:00 <btcdrak> oh i'm late
185 2016-01-21 19:13:11 <wumpus> gmaxwell, the current assertion has put many people on the wrong track (thinking this was corruption), so an error is better. Even better would be versionoing in chainstate like we have for the wallet, so this can be avoided in the future, but this is good for now
186 2016-01-21 19:13:12 <wumpus> gmaxwell, the current assertion has put many people on the wrong track (thinking this was corruption), so an error is better. Even better would be versionoing in chainstate like we have for the wallet, so this can be avoided in the future, but this is good for now
187 2016-01-21 19:13:16 <e4xit> Hello, is this the right channel to ask a question about failing "make" part of building of bitcoin core 0.12?
188 2016-01-21 19:13:35 <jonasschnelli> e4xit: use #bitcoin
189 2016-01-21 19:13:40 <e4xit> ok
190 2016-01-21 19:13:52 <wumpus> e4xit,  normally it's ok but we're in the middle of a meeeting
191 2016-01-21 19:14:03 <e4xit> I thought it sounded like that :)
192 2016-01-21 19:14:25 <cfields> wumpus: version makes sense
193 2016-01-21 19:15:15 <wumpus> I do think we should do a 0.11 backport release immediately after 0.12 final, instead of before, to avoid confusion
194 2016-01-21 19:15:43 <gmaxwell> we could do it concurrently and just not announce the 0.11 update.
195 2016-01-21 19:15:47 <wumpus> (e.g. having both 0.12.0 and 0.11.3 in RC phase)
196 2016-01-21 19:15:56 <wumpus> sure, could be almost immediately
197 2016-01-21 19:15:57 <gmaxwell> ah but yes, we'd get no testing on it.
198 2016-01-21 19:16:25 <wumpus> there's much less testing needed for the 0.11 release than for a new major release, but still makes sense to do one RC
199 2016-01-21 19:17:03 <gmaxwell> yes, I agree with your reasoning. FWIW.
200 2016-01-21 19:17:17 <cfields> proposed next topic: c++11 update
201 2016-01-21 19:17:38 <wumpus> agree this topic is done, but we still had
202 2016-01-21 19:17:42 <wumpus> #topic leveldb corruption
203 2016-01-21 19:17:49 <wumpus> (this is news for me btw)
204 2016-01-21 19:17:55 <cfields> ok
205 2016-01-21 19:17:56 <cfields> ok
206 2016-01-21 19:18:24 <wumpus> @jonasschnelli
207 2016-01-21 19:18:55 <gmaxwell> The issue I saw this morning said the corruption was during IBD. But IIRC we disable fsync on the block files during IBD. Is there more to it than that?
208 2016-01-21 19:19:06 <jonasschnelli> corruption: https://github.com/bitcoin/bitcoin/issues/7382
209 2016-01-21 19:19:10 <jonasschnelli> Isn't that leveldb?
210 2016-01-21 19:19:53 <wumpus> jonasschnelli, that's a strange issue, I don't think it's related to leveldb itself though
211 2016-01-21 19:20:07 <jonasschnelli> I also had a corrupt database after running 0.12 (maybe not related, was running a external SSD).
212 2016-01-21 19:20:08 <jonasschnelli> I also had a corrupt database after running 0.12 (maybe not related, was running a external SSD).
213 2016-01-21 19:20:30 <jonasschnelli> I just think in general, we see lots of db corruptions with bitcoin core.
214 2016-01-21 19:20:52 <jonasschnelli> Wonder if we like to sketch a plan / roadmap for a better strategy
215 2016-01-21 19:20:55 <sipa> oops, did i miss meeting?
216 2016-01-21 19:21:04 <jonasschnelli> (you missed 20 mins)
217 2016-01-21 19:21:06 <gmaxwell> jonasschnelli: I believe that issue is unrelated.
218 2016-01-21 19:21:19 <gmaxwell> jonasschnelli: and I think phantomcircuit can reproduce it now.
219 2016-01-21 19:21:38 <maaku> Jonas well switching to a new, maintained db is the long term plan, no?
220 2016-01-21 19:21:54 <maaku> But we know what remains to be done there
221 2016-01-21 19:22:26 <gmaxwell> I'm not aware of any evidence of leveldb corruption on linux, right now, and I've been running the most agressive testing I can perform on 0.12 for the last month.  Eg.  a node with four daemons running under load test and random kill -9ing the process and random power cuts every few hours and no corruption.
222 2016-01-21 19:22:35 <phantomcircuit> gmaxwell, i reproduced the error once and haven't been able to since
223 2016-01-21 19:22:40 <phantomcircuit> which has me a bit puzzled
224 2016-01-21 19:22:41 <wumpus> just don't blame everything on leveldb: application errors that happen to happen with something stored in the leveldb database are not leveldb corruption errors
225 2016-01-21 19:22:49 <wumpus> this may well be a bug in our code
226 2016-01-21 19:23:00 <jonasschnelli> Indeed.
227 2016-01-21 19:23:04 <gmaxwell> or in the OS/filesystem.
228 2016-01-21 19:23:09 <wumpus> right.
229 2016-01-21 19:23:31 <wumpus> but as we don't have more information, it's impossible to say. Unfortunately he didn't make a backup before upgrading
230 2016-01-21 19:23:32 <jonasschnelli> Also not sure about Virtualized envs (sudden shutdowns)... and Windows.
231 2016-01-21 19:24:09 <jonasschnelli> Okay. I will grab out the logs from the prev. meeting where we did discuss that topic (sqlite, etc.).
232 2016-01-21 19:24:12 <wumpus> it is the only report of this issue that we have
233 2016-01-21 19:24:15 <gmaxwell> I think it's likely that many virtualized envs get fsync wrong, in which case there isn't much that any database could do. :(
234 2016-01-21 19:25:10 <wumpus> ok, next topic?
235 2016-01-21 19:25:14 <dkog> LevelDB can corrupt due to OS performing out-of-order writes... https://www.usenix.org/conference/osdi14/technical-sessions/presentation/pillai
236 2016-01-21 19:26:14 <jonasschnelli> <cfields>
237 2016-01-21 19:26:16 <wumpus> #topic c++11
238 2016-01-21 19:26:31 <cfields> just wanted to give a brief update there
239 2016-01-21 19:26:40 <bsm117532> IIRC there are 6 lines that need to change, relating to the use of shared_ptr/unique_ptr.  I have a patch.
240 2016-01-21 19:26:43 <cfields> afaik, all changes needed for c++11 have gone in and we're ready to switch. atm, the only hold-out is travis. I've talked with their team, and they've indicated that the features we need (trusty, caching) will be ready by the end of the month. So I've proposed that we wait for that to flip the switch, since it's not that far out.
241 2016-01-21 19:26:44 <wumpus> did travis already upgrade?
242 2016-01-21 19:27:17 <wumpus> awesome, thanks for the update cfields
243 2016-01-21 19:27:21 <cfields> wumpus: nothing new, just posting it here for the record
244 2016-01-21 19:27:34 <CodeShark> nice, thanks cfields
245 2016-01-21 19:27:36 <jtimon> we can wait a month, awesome
246 2016-01-21 19:27:36 <sipa> i agree with waiting until we can test
247 2016-01-21 19:27:53 <wumpus> agreed
248 2016-01-21 19:27:59 <btcdrak> proposed topic "EOL policy"
249 2016-01-21 19:28:04 <gmaxwell> There was a report of wangchung from f2pool that he would not run code that required a C++11 compiler. I don't know if anyone has spoken with him to try to figure out what it would take for him to upgrade his operating systems in the future. I think that conversation should happen.
250 2016-01-21 19:28:26 <cfields> gmaxwell: i saw that and i'd really like to understand the concern
251 2016-01-21 19:28:26 <wumpus> or use static linking
252 2016-01-21 19:28:34 <cfields> wangchun: ping
253 2016-01-21 19:28:48 <cfields> fwiw, official binary releases are statically linked
254 2016-01-21 19:28:48 <wumpus> the gitian-built executables don't need any special OS support after the C++11 switch
255 2016-01-21 19:28:50 <btcdrak> mayeb jl2012 can reach out in Chinese
256 2016-01-21 19:28:54 <gmaxwell> cfields: not during the meeting. :)
257 2016-01-21 19:28:54 <wumpus> this is just for compiling
258 2016-01-21 19:29:16 <cfields> ok, sure
259 2016-01-21 19:29:22 <gmaxwell> I'm just bringing it up so it's not a surprise at the 0.13 release time.
260 2016-01-21 19:29:39 <kangx_> let me know anything i can help to bring the message to wangchun.
261 2016-01-21 19:30:17 <jtimon> next topic?
262 2016-01-21 19:30:32 <wumpus> #topic EOL policy
263 2016-01-21 19:30:38 <btcdrak> I have been putting together a software lifecycle document which I'd like further feedback on https://github.com/bitcoin-core/website/pull/37
264 2016-01-21 19:30:39 <cfields> kangx_: i'll ping him in #bitcoin-core-dev after the meeting. feel free to help relay
265 2016-01-21 19:30:51 <kangx_> ok. that is fine with me..
266 2016-01-21 19:30:57 <jtimon> action item talk to wangchun about C++11 eupgrade ?
267 2016-01-21 19:31:00 <cfields> kangx_: thanks :)
268 2016-01-21 19:31:14 <wumpus> I've replied there https://github.com/bitcoin-core/website/pull/37#issuecomment-172494669
269 2016-01-21 19:31:20 <kangx_> sure..
270 2016-01-21 19:31:48 <jonasschnelli> Agree with wumpus about EOL: "I tend to regard the last two major releases as maintained"
271 2016-01-21 19:31:49 <btcdrak> wumpus: sure. just wanted bring to everyone's attention for RFC
272 2016-01-21 19:32:11 <wumpus> btcdrak, yes, just wanted to bring it to attention so I don't have to re-type everything here ;)
273 2016-01-21 19:32:17 <btcdrak> :)
274 2016-01-21 19:32:22 <gmaxwell> I don't know how useful or used our backports are, even just one release back. I think in principle we should continue to do it; but perhaps we're wasting resources on things that aren't helpful to anyone.
275 2016-01-21 19:32:48 <gmaxwell> If there are people who use them (rather than just staying with old versions and not upgrading), they haven't been providing any feedback anyplace I can see them.
276 2016-01-21 19:32:55 <wumpus> perhaps. But it seems there are people willing to do even more work here, like Luke-Jr
277 2016-01-21 19:32:59 <cfields> gmaxwell: it may be a useful policy to just play it as "see if anyone yells"
278 2016-01-21 19:33:11 <jtimon> maybe we could have something like ubuntu's long term support and officially support only the last tw plus the last LTS one ?
279 2016-01-21 19:33:12 <jtimon> maybe we could have something like ubuntu's long term support and officially support only the last tw plus the last LTS one ?
280 2016-01-21 19:33:36 <sipa> jtimon: and how frequently would LTSs be?
281 2016-01-21 19:33:40 <btcdrak> jtimon: I was waiting to see if anyone brought that up.
282 2016-01-21 19:33:45 <wumpus> I don't see a strong reason to switch to another policy than has been implicit already all this time
283 2016-01-21 19:33:57 <jtimon> I don't know, 4 years? I mean, maybe only backport consensus critical stuff
284 2016-01-21 19:33:58 <btcdrak> The thing about LTS is they are maintained for years.
285 2016-01-21 19:33:58 <gmaxwell> wumpus: perhaps-- but just luke doing backports doesn't mean there is meaningful testing. I worry a lot that one of these backports will have some awful bug from integration; fortunately if no one runs them that also doesn't matter.
286 2016-01-21 19:34:05 <sipa> backports are a drain on manpower, and if they end up being unused mostly, they may not get sufficient testing to consider thay safe
287 2016-01-21 19:34:16 <maaku> I think it would be irresponsible not to have a policy at least with regards to security back ports and consensus changes
288 2016-01-21 19:34:32 <gmaxwell> But I think the current policy is not bad, I wouldn't want to make it stronger without any evidence that people care.
289 2016-01-21 19:34:33 <sipa> we should have a policy, i agfee
290 2016-01-21 19:34:36 <wumpus> maaku, we do those
291 2016-01-21 19:34:37 <btcdrak> I just wanted to document EOL given the scale at which Core software is used at enterprise level.
292 2016-01-21 19:34:51 <jtimon> ok, just something that crossed my main, please continue the discussion without the LTS proposal
293 2016-01-21 19:35:09 <gmaxwell> maaku: it's irrelevant if litterally no one uses them. Right now our last 0.10 backport is totally unused as far as I can tell.
294 2016-01-21 19:35:18 <jonasschnelli> EOL is something that people can hold onto. Gives trust, makes a project look stable. I think we should have a clear policy and follow it.
295 2016-01-21 19:35:49 <wumpus> so to be clear: so you're arguing to not do backports at all anymore gmaxwell
296 2016-01-21 19:35:57 <btcdrak> jonasschnelli: exactly
297 2016-01-21 19:36:01 <maaku> It also affects development, with respect to whether features have to be back ported or not changes the design.
298 2016-01-21 19:36:08 <maaku> This has been a point of contention recently.
299 2016-01-21 19:36:12 <gmaxwell> at the last soft fork we saw people mining on it with a signficant fraction of the hashrate, running git _master_, not even a release.
300 2016-01-21 19:36:23 <wumpus> features are not backported, the idea is to backport fixes
301 2016-01-21 19:36:30 <cfields> maaku: good point. c++11 usage will be affected strongly.
302 2016-01-21 19:36:38 <sipa> wumpus: consensus changes are backported though
303 2016-01-21 19:36:48 <wumpus> sipa, yes, to help adoption
304 2016-01-21 19:36:56 <maaku> sipa but how far?
305 2016-01-21 19:36:57 <btcdrak> My own understanding is maintenance releases get softforks and bug fixes only.
306 2016-01-21 19:37:09 <jonasschnelli> btcdrak: +1
307 2016-01-21 19:37:13 <jonasschnelli> Thats a clear policy.
308 2016-01-21 19:37:16 <btcdrak> maaku: as far back as is required for miners
309 2016-01-21 19:37:17 <btcdrak> maaku: as far back as is required for miners
310 2016-01-21 19:37:17 <gmaxwell> wumpus: I don't know. I am observing the backports appear to be a waste of time. From a matter of principle, I think they are important, but the industry doesn't appear to agree.
311 2016-01-21 19:37:19 <sipa> maaku: that's what we're discussion :)
312 2016-01-21 19:37:34 <wumpus> I disagree with completely stopping backports, but ok, if everyone else thinks that I"m happy to drop that work I'm busy enough
313 2016-01-21 19:37:38 <jtimon> wumpus: softforks are also backported
314 2016-01-21 19:37:39 <btcdrak> we dont really have a good way on knowing what miners are running though.
315 2016-01-21 19:37:59 <sipa> i think we should continue them, and clearly document the policy
316 2016-01-21 19:38:06 <gmaxwell> wumpus: I think continuing with what we're doing for now is okay, but I do worry that the backports don't see adequate testing (a symptom of no one actually using them)
317 2016-01-21 19:38:07 <cfields> seems it's hard/impossible to say what will be necessary to backport in the fugure, but imo it'd be reasonable to say explicitly "after version X's release, version Y will receive no more updates"
318 2016-01-21 19:38:13 <btcdrak> I think we should continue with the status quo wumpus has established
319 2016-01-21 19:38:14 <maaku> For the record I don't care what the answer is. But I care strongly that we decide on one policy. :)
320 2016-01-21 19:38:17 <sipa> we should also not feel bad about changing the policy, if we clearly announce
321 2016-01-21 19:38:18 <sipa> we should also not feel bad about changing the policy, if we clearly announce
322 2016-01-21 19:38:39 <sipa> maaku: agree
323 2016-01-21 19:38:57 <gmaxwell> Well I think our current policy is that we backport bugfixes (based on severity and difficulty of backport) and soft-forks to the last major version.
324 2016-01-21 19:39:13 <wumpus> indeed gmaxwell
325 2016-01-21 19:39:14 <wumpus> indeed gmaxwell
326 2016-01-21 19:39:19 <jonasschnelli> I would say to the last *two* major versions..
327 2016-01-21 19:39:22 <sipa> yeah, but it seems to have been pretty adhoc
328 2016-01-21 19:39:28 <jonasschnelli> 0.11 and 0.10 in the current state.
329 2016-01-21 19:39:44 <sipa> jonasschnelli: and once 0.12 is released?
330 2016-01-21 19:39:50 <wumpus> it becomes 0.11 and 0.12
331 2016-01-21 19:39:51 <gmaxwell> jonasschnelli: do you mean when 0.12 is out we should continue backporting to 0.10?
332 2016-01-21 19:39:52 <sipa> only 0.11 and 0.12 then?
333 2016-01-21 19:39:56 <wumpus> yes sipa
334 2016-01-21 19:40:00 <sipa> sounds good to me
335 2016-01-21 19:40:07 <wumpus> although Luke-Jr apparently wants to pick up and maintain 0.10
336 2016-01-21 19:40:14 <jonasschnelli> Once 0.12 is released 0.12 and 0.11 (sorry, was a bit confisuing)
337 2016-01-21 19:40:20 <gmaxwell> jonasschnelli: okay
338 2016-01-21 19:40:28 <sipa> final release of 0.X means EOL of 0.(X-2)
339 2016-01-21 19:40:39 <btcdrak> hurray for math
340 2016-01-21 19:40:54 <jonasschnelli> The signal of and the value of that signal of supporting older versions is extremely valuable IMO (especially in such times)
341 2016-01-21 19:40:54 <jtimon> ok ,topic solved?
342 2016-01-21 19:40:55 <wumpus> it's ad hoc in a way, how ciritical something needs to be to be backported, but there's no way to avoid that
343 2016-01-21 19:40:57 <CodeShark> why would people download a bugfix to an older version rather than just grab the latest version other than custom patches?
344 2016-01-21 19:41:11 <cfields> then i agree with wumpus's goal of doing 0.12 before 0.11 backport. that way we don't have to do it for 0.10 :p
345 2016-01-21 19:41:15 <sipa> CodeShark: custom patches
346 2016-01-21 19:41:19 <jonasschnelli> cfields: hah
347 2016-01-21 19:41:24 <maaku> And since we're on a 6mo cadence, that's 1yr support
348 2016-01-21 19:41:26 <gmaxwell> CodeShark: because they're carrying local patches, or do not want to invalidate integration testing they've performed.
349 2016-01-21 19:41:37 <wumpus> yes, custom patches. The tagging is mostly symbolic then, I agree, but still
350 2016-01-21 19:41:38 <wumpus> yes, custom patches. The tagging is mostly symbolic then, I agree, but still
351 2016-01-21 19:42:07 <wumpus> and "this works and I don't want to risk a large upgrade or read a lot of release notes"
352 2016-01-21 19:42:37 <jonasschnelli> proposed neighbor topic: shorter release cycles?!
353 2016-01-21 19:42:47 <jonasschnelli> 0.12 changelog is --- huge!
354 2016-01-21 19:43:17 <jtimon> jonasschnelli: to what timeframe?
355 2016-01-21 19:43:46 <wangchun> cfields kangx_: pong, i'm on my way to the aiport for early morning flight
356 2016-01-21 19:43:47 <wangchun> cfields kangx_: pong, i'm on my way to the aiport for early morning flight
357 2016-01-21 19:43:48 <wumpus> I don't know,I like a major release per half year, at least you can really call it major
358 2016-01-21 19:44:01 <gmaxwell> I would like a shorter cycle, but I don't know if it's realistic. Right now the long cycle is like a 3 month RC cycle for high risk features that go in early in the cycle.
359 2016-01-21 19:44:06 <wumpus> it's a lot of testing and effort to finalize a release
360 2016-01-21 19:44:07 <jonasschnelli> Not sure, 4month to short?
361 2016-01-21 19:44:15 <maaku> I think 6mo is pretty fast...
362 2016-01-21 19:44:25 <sdaftuar> wumpus: agreed, the overhead of a release is time consuming
363 2016-01-21 19:44:35 <sipa> shorter releases would reduce the "oops release coming we *must* get X in quickly!" fever
364 2016-01-21 19:44:40 <cfields> wangchun: i'll ping you after the meeting in #bitcoin-core-dev. If you're already gone, we can talk about it later
365 2016-01-21 19:44:42 <btcdrak> by the time we get around though it's usually 7+ months irrc
366 2016-01-21 19:44:50 <wumpus> sipa, I don't believe that
367 2016-01-21 19:44:51 <wumpus> sipa, I don't believe that
368 2016-01-21 19:44:58 <wumpus> sipa, it just increases the occurence of that
369 2016-01-21 19:45:02 <gmaxwell> maaku: the cyclelength also contributes to frustration and pressure to get features in.
370 2016-01-21 19:45:06 <sipa> wumpus: fair enough
371 2016-01-21 19:45:08 <btcdrak> if we aimed for 5 months, maybe we'd be closer to 6
372 2016-01-21 19:45:09 <kangx_> ok.
373 2016-01-21 19:45:18 <jonasschnelli> Yes. Maybe 6 months is good. It just feels 0.11 was ages ago... but maybe that's just how a dev feels it.
374 2016-01-21 19:45:23 <kangx_> wangcun: what is your wechat account?
375 2016-01-21 19:45:55 <wumpus> for users it's not really better to have more frequent major releases I think. Upgrading may not always be a trivial process and comes with a risk
376 2016-01-21 19:45:59 <jtimon> gmaxwell: as in longest = more frustration?
377 2016-01-21 19:46:25 <wumpus> it compounds the EOL problem
378 2016-01-21 19:46:26 <jtimon> mo, I guess the opposite
379 2016-01-21 19:46:35 <gmaxwell> jtimon: yes; as in "my work is a waste of time because it won't see the light of day for another 6 months if it doesn't go in now"
380 2016-01-21 19:46:50 <gmaxwell> in any case, I don't think we're in a position to consider a change in that process right now.
381 2016-01-21 19:46:51 <jtimon> gmaxwell: thanks, yeah, makes sense
382 2016-01-21 19:46:57 <wumpus> what are the release cycles for other mature projects?
383 2016-01-21 19:47:13 <btcdrak> Ubuntu is 6 monthly
384 2016-01-21 19:47:14 <btcdrak> Ubuntu is 6 monthly
385 2016-01-21 19:47:40 <maaku> There is a ton of work that goes into releases, like string translation.
386 2016-01-21 19:47:46 <wumpus> indeed maaku
387 2016-01-21 19:47:51 <gmaxwell> wumpus: there are many things that are quarterly and many things that are biannually for major releases (and of course many much slower too)
388 2016-01-21 19:47:59 <jonasschnelli> I think 6 month is perfectly fine... if just the GUI and wallet would be detached, we could to more released there.
389 2016-01-21 19:47:59 <wumpus> it's surprising how devs, of all, seem to underestimate that
390 2016-01-21 19:48:00 <wumpus> it's surprising how devs, of all, seem to underestimate that
391 2016-01-21 19:48:08 <sipa> firefox releases every 6 weeks
392 2016-01-21 19:48:09 <btcdrak> yes. But I think we can wrap up sooner to allow translations/QA and RC
393 2016-01-21 19:48:17 <wumpus> jonasschnelli, +1 on a faster release cycle for the GUI if that was possible
394 2016-01-21 19:48:40 <btcdrak> if we finished dev work at 5 months, then we'd have less slippage from the 6mnth mark
395 2016-01-21 19:48:46 <wumpus> but we have this huge monilithic project and yes everything needs to be synchronized
396 2016-01-21 19:48:55 <wumpus> btcdrak, I plan a release every 6 months
397 2016-01-21 19:48:59 <cfields> oh, reminds me. topic suggestion: current server/wallet inter-dependencies
398 2016-01-21 19:48:59 <jtimon> a year is not multiple of 5 months releases, shorter than 4 months seems to big of a change, I think if we move from 6 months it would be to 4 months no matter what other projects do
399 2016-01-21 19:49:00 <jtimon> a year is not multiple of 5 months releases, shorter than 4 months seems to big of a change, I think if we move from 6 months it would be to 4 months no matter what other projects do
400 2016-01-21 19:49:03 <gmaxwell> wumpus: firefox is now nearly _monthly_ major releases.
401 2016-01-21 19:49:13 <wumpus> gmaxwell, I don't really want to follow firefox inthat
402 2016-01-21 19:49:14 <wumpus> gmaxwell, I don't really want to follow firefox inthat
403 2016-01-21 19:49:16 <maaku> I think we just need more clarity on things like redactor windows.
404 2016-01-21 19:49:23 <jtimon> s/to big/too big
405 2016-01-21 19:49:26 <sipa> i am perfectly fine with 6 months
406 2016-01-21 19:49:26 <wumpus> btcdrak, there are always two releases per year now
407 2016-01-21 19:49:42 <gmaxwell> wumpus: I wouldn't suggest that; only pointing out that there are large projects behind basically any schedule you might consider.
408 2016-01-21 19:49:43 <wumpus> maaku, I always post a release schedule in advance on the mailing list
409 2016-01-21 19:50:13 <wumpus> I'm fine with adding more deadlines though if that feels better :)
410 2016-01-21 19:50:20 <gmaxwell> Slower cycles also mean reduced user feedback. Different parts of the system benefit differently from that.
411 2016-01-21 19:50:21 <jtimon> I'm fine with 6 months but wouldn't oppose to 4 motnhs either
412 2016-01-21 19:50:54 <wumpus> gmaxwell, as said, I'd be OK with faster release cycle for the GUI if that was possible
413 2016-01-21 19:50:58 <gmaxwell> e.g. if most of our current activity were UI facing it would be more adventagious to have a faster cycle.
414 2016-01-21 19:51:00 <wumpus> but not for the core code
415 2016-01-21 19:51:17 <jonasschnelli> Agree.
416 2016-01-21 19:51:20 <sipa> ok
417 2016-01-21 19:51:26 <jonasschnelli> I have to admit wumpus does a awesome job on keeping deadlines for the releases!
418 2016-01-21 19:51:33 <maaku> wumpus your release schedule did not have a refactoring window
419 2016-01-21 19:51:40 <btcdrak> jonasschnelli: +1
420 2016-01-21 19:52:13 <jtimon> yeah, if shortenning it is going to mean not keeping deadlines, let's not do it
421 2016-01-21 19:52:28 <gmaxwell> in any case, I think this discussion is covered.
422 2016-01-21 19:52:30 <wumpus> maaku, true
423 2016-01-21 19:52:57 <btcdrak> so it's basically as written in the EOL PP
424 2016-01-21 19:52:58 <jonasschnelli> maaku: refactoring? We have a main.cpp. We don't need refactoring. :)
425 2016-01-21 19:53:00 <btcdrak> PR
426 2016-01-21 19:53:27 <wumpus> yes, it's the same thing every time, I want 6 months everyone else wants a shorter release cycle, at some point I'm going to make one of you release manager and figure it out :p
427 2016-01-21 19:53:41 <jonasschnelli> :}
428 2016-01-21 19:53:44 <gmaxwell> jonasschnelli: can we move everything back into main.cpp? I'd save a lot of time grepping. :P
429 2016-01-21 19:53:51 <btcdrak> LOL
430 2016-01-21 19:53:56 <jonasschnelli> haha
431 2016-01-21 19:53:58 <wumpus> hehe
432 2016-01-21 19:54:18 <cfields> gmaxwell: and headers.h :)
433 2016-01-21 19:54:18 <wumpus> ok, any other topics? we're running out of time
434 2016-01-21 19:54:21 <gmaxwell> wumpus: The solution is to make everything so wonderful that even you will want a shorter cycle. :) Core is not there yet.
435 2016-01-21 19:54:24 <jtimon> hehe, ok, if wumpus willing is not going to do 4 months then the topic is solved for now
436 2016-01-21 19:55:28 <jtimon> no more topics? end meeting?
437 2016-01-21 19:55:30 <cfields> i proposed lib dependencies as a topic above, but there's really no need to do that here. we can discuss later
438 2016-01-21 19:55:34 <sipa> gmaxwell: ACK on making things wonderful
439 2016-01-21 19:55:38 <sdaftuar> +1
440 2016-01-21 19:55:42 <btcdrak> +2
441 2016-01-21 19:55:48 <lightningbot`> Log:            http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-21-18.59.log.html
442 2016-01-21 19:55:48 <lightningbot`> Meeting ended Thu Jan 21 19:55:48 2016 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
443 2016-01-21 19:55:48 <lightningbot`> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-21-18.59.html
444 2016-01-21 19:55:48 <lightningbot`> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-21-18.59.txt
445 2016-01-21 19:55:48 <wumpus> #endmeeting
446 2016-01-21 19:55:49 <lightningbot`> Log:            http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-21-18.59.log.html
447 2016-01-21 19:55:49 <lightningbot`> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-21-18.59.html
448 2016-01-21 19:55:49 <lightningbot`> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-dev/2016/bitcoin-dev.2016-01-21-18.59.txt
449 2016-01-21 19:55:59 <btcdrak> wumpus: hole in one
450 2016-01-21 19:56:11 <maaku> Did it right this time!
451 2016-01-21 19:56:18 <jonasschnelli> F.I.Y: I'm 99% offline in February (till ~22 feb., vacation)
452 2016-01-21 19:56:24 <gmaxwell> Hurray!
453 2016-01-21 19:56:28 <wumpus> have fun jonasschnelli !
454 2016-01-21 19:56:40 <gmaxwell> opps that was a hurray at the correct use of the bot, not jonasschnelli being gone.
455 2016-01-21 19:56:51 <jonasschnelli> haha... yes. Got this. :)
456 2016-01-21 19:57:06 <btcdrak> cfields: did you manage to move that patch to depends-sources/ on the server?
457 2016-01-21 19:57:14 <cfields> jonasschnelli: where to? still not the US, i assume? :)
458 2016-01-21 19:57:31 <cfields> btcdrak: oh, no. i thought you did. can do if you'd like?
459 2016-01-21 19:57:40 <btcdrak> cfields: yes please :)
460 2016-01-21 19:57:46 <cfields> ok
461 2016-01-21 19:57:46 <jtimon> cfields: what do you wanted to talk about related to lib dependencies?
462 2016-01-21 19:57:54 <btcdrak> cfields: I dont have access to the server
463 2016-01-21 19:58:18 <jonasschnelli> cfields: No. Not us. Beach in Africa.
464 2016-01-21 19:58:42 <cfields> jtimon: internal deps. sdaftuar ran into a problem due to their inter-connectedness. i'm wondering what jonasschnelli's intentions are for the future there
465 2016-01-21 19:59:17 <jonasschnelli> cfields, jtimon: can you elaborate this a bit more?
466 2016-01-21 19:59:35 <jonasschnelli> sorry, explain
467 2016-01-21 19:59:40 <jtimon> jonasschnelli: I was just curious, I don't know about this
468 2016-01-21 19:59:59 <bsm117532> On the C++11 topic, I brought up in https://github.com/bitcoin/bitcoin/pull/6899 that std::auto_ptr is deprecated, and we should replace it with std::unique_ptr for C++11. Bitcoin's usage of auto_ptr doesn't actually trigger the difference in semantics, AFAICT.
469 2016-01-21 20:00:31 <jonasschnelli> cfields: what do you excactly mean with internal deps? Stuff line univalue?
470 2016-01-21 20:00:35 <jonasschnelli> s/line/like
471 2016-01-21 20:00:42 <bsm117532> Is the goal to compile with c++11 by default?
472 2016-01-21 20:01:12 <cfields> jonasschnelli: a while ago i believe you were working on reducing core's dependency on the wallet?
473 2016-01-21 20:01:31 <cfields> (so that it's essentially a 1-way dependency)
474 2016-01-21 20:01:34 <jonasschnelli> cfields: ah.. yes. This is a good point.
475 2016-01-21 20:01:48 <jonasschnelli> We should make a graph on internal dependencis.
476 2016-01-21 20:01:52 <maaku> @bsm117532 c++11 only
477 2016-01-21 20:02:03 <bsm117532> Yay!
478 2016-01-21 20:02:04 <jonasschnelli> adhesion of classes / files.
479 2016-01-21 20:02:09 <bsm117532> maaku: Then I'll make a PR with that change.
480 2016-01-21 20:02:25 <cfields> jonasschnelli: yes.
481 2016-01-21 20:02:26 <jonasschnelli> The wallet should not interact with the core allover the code
482 2016-01-21 20:02:37 <maaku> @bsm117532 we're not there yet!
483 2016-01-21 20:02:40 <jonasschnelli> There should be a clean API, even if its running in the same process
484 2016-01-21 20:02:41 <jonasschnelli> There should be a clean API, even if its running in the same process
485 2016-01-21 20:02:56 <cfields> bsm117532: we're not ready for that change yet. and auto_ptr is deprecated, but still fully valid for c++11. so that can happily wait until it's enforced.
486 2016-01-21 20:03:09 <cfields> jonasschnelli: yes, agreed. very much so :)
487 2016-01-21 20:03:35 <bsm117532> Okeydokey.
488 2016-01-21 20:03:53 <cfields> jonasschnelli: mind poking at sdaftuar's PR? It's a very interesting example of inter-dependencies causing trouble.