19:00:52 #startmeeting 19:00:52 Meeting started Thu Jul 14 19:00:52 2016 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:52 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:53 actually here this time 19:01:47 gmaxwell: ping for pings :) 19:01:48 gmaxwell jonasschnelli sdaftuar jtimon kanzure MarcoFalke 19:01:57 pong 19:02:33 topic suggestions? 19:02:41 proposal: open 0.13 PRs (https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.13.0) 19:02:42 (besides 0.13.0rc1) 19:02:52 segwit backport? 19:02:58 ack topic 19:03:13 #topic 0.13.0rc1 19:03:20 #link https://github.com/bitcoin/bitcoin/milestone/20 19:03:29 #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier 19:03:48 I have opened #8323 some days ago and I think we need to have this in 0.13 to avoid later HD/non-HD mix problems 19:03:48 most of the remaining PRs have been merged, but there are still a few open 19:04:09 I beg for reviews... 19:04:13 jonasschnelli, I can review 19:04:24 #link https://github.com/bitcoin/bitcoin/pull/8305 Improve handling of unconnecting headers by sdaftuar 19:04:44 #link https://github.com/bitcoin/bitcoin/pull/8295 Mining-related fixups for 0.13.0 also by sdaftuar 19:04:49 and jonasschnelli's 19:05:04 https://github.com/bitcoin/bitcoin/pull/8323 19:05:14 #link https://github.com/bitcoin/bitcoin/pull/8323 19:05:38 I think #8305 is pretty much ready 19:06:02 has ACK by sipa and is being tested by gmaxwell 19:06:10 i think sipa acked an earlier version of the code 19:06:12 pong 19:06:37 jeremyrubin *ping* 19:07:00 cfields: has your comment there been addressed sufficiently? 19:07:19 oh, thanks sipa :) 19:07:51 wumpus: yes, i'm happy with the slow DOS trickle 19:08:04 instagibbs: yes? 19:08:32 as for #8295, mining changes are always harder to get people to review/test, I'd encourage people to get involved, though I see sipa ACKed that one too 19:09:13 yeah, the reason i didn't include telhr 8295 approach myself was because i incorectly assumed it would require extra counters 19:09:27 jonasschnelli: #8323 still has some open comments 19:09:40 and the existing tests cover it 19:09:41 trivial things though 19:09:48 no blockers 19:09:58 Yes. paveljanik just added some... will fix the trivials together (once there are some) 19:10:05 sipa: are you referring to mining unit tests? 19:10:10 morcos: yes 19:10:25 (well, and any rpc test that mines) 19:10:30 sipa: those aren't worth much, they've been in need of redoing for some time 19:10:43 hmm, ok 19:10:49 jonasschnelli: I'll also review and test it soon 19:10:55 thanks 19:11:03 not that i'm objecting to 8295 though 19:11:07 morcos: i'll test by running old and new in parallel and comparing then 19:12:08 great 19:13:19 sdaftuar: I don't think all items of https://github.com/bitcoin/bitcoin/issues/8294 are currenly being addressed in PRs? 19:13:29 a quick glance at 8323 suggests it won't make problems with key origin stuff, rihgt? 19:14:09 sdaftuar: any blockers remaining there? 19:14:20 (after all currenly 0.13-tagged PRs are merged) 19:14:35 luke-jr: let's discuss that outside the meeting please 19:14:51 …. 19:14:57 wumpus: i was waiting for #8295 to be merged before doing the release notes writeups 19:15:14 oh, should we talk about -blockmaxcost briefly? 19:15:16 sdaftuar: oh release notes writeups aren't urgent, they need to be done for final but not rc1 19:15:17 (what's the point of a meeting if not to discuss the topics raised?) 19:15:41 one of the to do items was better documentation for that option, but as has been pointed out, it's an awful name :) 19:16:08 sdaftuar: suggested replacement? 19:16:25 yes, the 'max cost' confuses people, they think it's about monetary cost 19:16:31 wumpus: +1 19:16:33 (and that's also how translators translate it) 19:16:40 >_< 19:16:50 (and it's a public command line option so the help gets translated) 19:16:59 we could have maxblockvsize instead 19:16:59 blockmaxcost is still just a size limit isn't it? 19:17:02 Cost has been a repeated source of confusion. 19:17:02 but that means the help needs to be improved, not necessarily the option renamed 19:17:03 well, it *is* indirectly monetary 19:17:17 maybe utilization 19:17:20 petertodd: it's the 'cost' as defined in the BIP, which is vsize*4 19:17:40 Score/points/weight/usage/ouchie/bitgo would all be better words for it. 19:17:42 "network resource usage"? 19:17:43 sipa: i think my best idea was to change the term in the BIP. i think we use "block cost" in the BIP. if we change that to something more descriptive, "block size validation cost" or something, and reference that in the documentation for the option, then i think that'd be good enough maybe 19:17:43 it's an abstract cost, and CS students understand that, but for most users it's confusing :) 19:18:01 sdaftuar: yes, agree, let's makr it consistent, whatever we agree upon 19:18:15 sdaftuar: yeah, I think changing the BIP's term is a good idea too - it's still a size, just a redefined size 19:18:23 #agree 19:18:24 block size validation cost would already be better help than there is now 19:18:30 petertodd: it's not a size. 19:18:32 notably, if we had referred to block size in the BIP, that'd help discourage the trolls... 19:18:33 "externality" 19:18:44 luke-jr: it is a size, in cost-space. 19:18:47 well, any reason not use vsize? 19:18:49 segwit *is* a blocksize increase, so just continue to call it a size 19:18:53 sipa: vsize is fine 19:19:00 yes vsize is fine 19:19:09 yes 19:19:10 sipa: (so long as the help text explains what vsize is) 19:19:12 vsize is inaccurate 19:19:15 V means validation? 19:19:21 virtual 19:19:24 going to *4 the meaning, so people specify x.25 now? 19:19:27 hm, we have been using vsize to refer to the scaled down value, not the *4 value? 19:19:27 v for vendetta 19:19:28 ugh, there is nothing virtual about it. 19:19:36 gmaxwell: +1 19:19:38 fractional values for consensus code? 19:19:50 sdaftuar: that's a mistake then 19:19:56 sdaftuar: yes, cost == vsize * 4 19:19:59 re fractional values, haven't we learned from difficulty? 19:20:06 vsize is cost, but scaled down for compatibility with old code 19:20:15 so they don't start sending 4x fees etc 19:20:18 if we use fractional values for display friendlyness, other people will use them in consensus code and cause faults. 19:20:35 * luke-jr grabs a thesaurus 19:20:36 sipa: ::sigh:: point. 19:20:37 agreed 19:20:46 I like weight the best 19:20:56 agree jeremyrubin 19:20:59 because usually you would say a weighted sum 19:21:05 jeremyrubin: nice idea 19:21:07 weight is a pretty good term for it 19:21:09 #agree 19:21:17 good call 19:21:21 and it's not used anywhere yet in bitcoin 19:21:24 (gmaxwell: mentioned first) 19:21:33 outlay? :/ 19:21:41 weight sounds fine 19:22:30 yeah, there's two sizes with their weights, it's a cost heuristic 19:22:40 so: rename blockmaxcost to blockmaxweight? 19:22:43 "weight" also carries a nice intuitive notion 19:22:57 yes, and let's report weight for transactions too 19:22:57 maxblockweightcostheuristic 19:23:06 I read that as block mascot. 19:23:18 hehe 19:23:19 OTOH, if we just call the command line stuff a block size, we help educate people on the fact that segwit is a blocksize increase - some miners will leave it at 1000000, but that's a temporary problem 19:23:21 virtualmaxblockweightcostheuristic 19:23:21 sorry, I missed the first 15 mins or so, but why do we need to rename blockmaxcost ? 19:23:32 petertodd: size is something else 19:23:33 jtimon: because the word cost is confused as fee. 19:24:02 i think "block weight" and -blockmaxweight [ 19:24:11 both work okay 19:24:14 ack 19:24:31 jtimon: well it started as that the help for that option was confusing, then people realized the option was named terribly too, but please just read back :) 19:24:35 mhmm, no, it's costs for the miners, although that's also why they charge you fees 19:24:40 weight also should be fine for GBT; nothing is released using the old cost stuff yet 19:24:59 jtimon: is there a problem with "weight"? 19:25:08 in any case, I support the great cost to weight renaming. 19:25:09 petertodd: that's what i did originally 19:25:14 #action rename blockmaxcost to blockmaxweight 19:25:23 yeah, sorry I'll wait for botbot.me to update 19:25:26 We can chew it over offline 19:25:29 sipa: well, ack your original idea :) 19:25:46 petertodd: but then people started complaining that there had to be a way to limit the serialized size too 19:26:01 jtimon: but that's not the units of the cost, otherwise you would denote it into BTC or something... 19:26:05 jtimon: you can see.logs in slack 19:27:00 jeremyrubin: blockbytescost :) 19:27:34 jeremyrubin: the cost for miners is in size, or in "costs relative to the maximum limit" or whatever, but sorry, let's move on 19:28:20 other topics? 19:28:28 segwit backport 19:28:31 ah yes 19:28:34 #topic segwit backport 19:28:39 btcdrak: I didn't knew, never used the bitcoin slack 19:29:04 wumpus: some people have raised concerns about backporting segwit to 0.12 19:29:24 concerns about doing it at all? 19:29:25 what's the concern? 19:29:31 ^ 19:29:35 well, next chance is 0.13.1 19:29:51 morcos, btcdrak: ? 19:30:21 :), yes i was arguing that it would be a mistake 19:30:33 me too 19:30:36 could you reiterate for the audience 19:30:49 if the backport doesn't get enough review and testing there's no new 0.12 release, simple, no? 19:30:54 I dont' think that it's worth it. I'm not sure there are are benefits that outweight hte cost (weight) in terms of developer time and increased risk for bugs in the backport 19:31:04 one concern i have is that it would likely be the first segwit code that gets actually deployed on the network, and that it is hard to give it the same amount of testing and review as 0.13 did 19:31:04 I think it would easier for miners if it was backported to 0.12, but if it turns out to be too much technical difficulty/risk, well too bad I suppose... 19:31:06 if that were the case then I would have to argue that we wait until 0.14.1 .. so strong argument is needed 19:31:10 jtimon: backports never do, unless they're the tip release 19:31:28 jtimon: agree that its that simple, but woudl be a shame for some people to sacrafice time backporting and reviewing if its not going to pass the bar 19:31:34 yes. I share morcos concerns about backporting 19:31:44 wumpus: "too bad" may result in delayed deployment maybe 19:31:46 luke-jr: so all previous backported softforks were unsafe ? 19:31:58 jtimon: such as? 19:31:59 luke-jr: yes, but delay is better than messing up 19:32:08 about this topic 19:32:21 in the past we've seen miners often run even pre-release code 19:32:27 luke-jr: I don't know if any of them was unsafe, I'm asking 19:32:34 if that is going to happen, my concerns about a backport go down 19:32:38 I hate delays, but minimizing risk is the highest priority 19:32:39 but so does its usefulness 19:32:40 have anyone asked miners that they really need a backport? 19:32:41 i'm strongly against "too bad" -- we need to take our support guarantees seriously 19:32:46 the concern is mostly that we don't want to force people to quickly adopt 0.13 derrived code just to catch up with segwit, otherwise 0.13.1 would be fine. 19:33:03 maaku: we already didn't backport CSV 19:33:11 maaku: there are no guarantees 19:33:11 people are running businesses assuming we support "current plus prior" not "current plus prior, except when it's inconvenient" 19:33:18 maaku: doing segwit in 0.13.1 isn't a violation of the process, that still remains no softforks in major feature releases. 19:33:37 maaku: from the begining we've said that the plan would be 0.12.1, but if it would somehow lapse it would be 0.13.1 19:33:49 gmaxwell: it would mean you could no longer mine on 0.12 19:33:50 jl2012: that's the most important question 19:33:56 this is not about 'inconvenient', this is about risk 19:33:58 gmaxwell: are you more worried about miners or users? 19:34:18 maaku: with things like CPFP I'm not sure that anyone will be mining on 0.12 in short order. But thats something we could inquire about. 19:34:26 morcos: users. 19:34:35 i just think it's very likely to be safer consensus wise to upgrade to 0.13.1 from 0.12.1 than to upgrade to 0.12.2 (segwit backport) which is more likely to have bugs 19:34:49 we wouldn't want a DAO scale disaster over over-hurried release of hardly-reviewed and tested code 19:35:03 wumpus +1 19:35:07 miners that truly need v0.12 might be better off mining with a v0.12 node behind a segwit 0.13 node... 19:35:09 so if it needs to be 0.13.1, it will be 0.13.1 19:35:25 Sure. 19:35:39 wumpus: i thought it was definitely going to be 0.13.1, the question was whether we'd also make a 0.12.2? 19:35:44 maaku: we need to stop guaranteeing things we can't providr 19:36:01 how many miners even use backports? 19:36:05 morcos: no - if it would be in 0.12.2, it could make it into 0.13.0 too 19:36:14 So one risk we have right now is that 0.13.x would end up releasing concurrently or likely ahead of 0.12.2, which would be bad for network consistency in general. 19:36:17 morcos: assuming 0.12.2 is released before 0.13.0 of course 19:36:18 achow101: all of htem right now I think 19:36:22 morcos: maybe rebasing my code to 0.13.1 is not easier than rebasing it to 0.12.2 19:36:24 morcos: then again that ship sailed already 19:37:31 ok, well i don't have a strong opinion on release numbers or timing. my objection is to spreading ourselves too thing by having to thoroughly review a very substantial set of changes in 2 code bases and then putting the network at risk 19:37:32 morcos: oh no, plan was always 0.12.2, but I agree it might be reasonable to not do that based on current timing. 19:38:08 what about releasing 0.13.1 and then 0.12.2? 19:38:20 i think segwit in master is now relatively well reviewed... it will be very difficult to get that level of review in the 0.12 branch, which woud make me uncomfortable releasing that 19:38:53 on top of that, its not something i'd want to spend my time on... i think all our time would be more wisely spent on moving forward with future work 19:38:53 achow101: well if a backport is released at all, why would it matter in what order? 19:39:00 Wouldn't want to make a classic blunder, "never get involved in a land war in Asia"! 19:39:00 anyway, sorry, i have to catch a train, got to run! 19:39:03 assuming the demand for a backport of segwit is for users and not miners, releasing 0.12.2 with segwit backport after releasing it in 0.13 is not unreasonablr 19:39:30 It's also a lot cleaner releasing in 0.13.1 because 0.12 would not have compact blocks 19:39:37 wumpus: order matters a lot for testing 19:39:48 sipa: sure, if it removed getblocktemplate that'd be an easy idea to support 19:39:56 well right now 0.13.0 doesn't have CB for segwit, though I suppose 0.13.1 could. 19:39:57 sipa: yeah, I assumed that was the plan 19:40:00 wumpus: for proper review of the backport without delaying deployment 19:40:03 I do wish we had realized this sooner, instead of seeming like a last minute decision 19:40:09 wumpus: likewise. 19:40:21 achow101: even fewer people will care about 0.12.x if 0.13 is already out 19:40:31 otoh, decisions to do _less_ at the last minute are better than decisions to do _more_. :) 19:40:35 gmaxwell: right, but if we released 0.12.2 then segwit would not have CB. If we release with 0.13.1 then we get CB at the get go. 19:40:37 i guess the question is what has priority: segwit backport or 0.13 release? 19:40:38 gmaxwell: hah, fully agreed 19:40:54 sipa: 0.13 release I think 19:41:00 We have real problems with virtually no one ever using backports. 19:41:06 for me the 0.13 release has priority 19:41:09 +1 release 19:41:17 agree with wumpus 19:41:18 my assumption was that we'd do 0.13.0, then 0.12.2 backport with segwit, then 0.13.1 release with segwit active 19:41:30 0.13 release has priority. 19:41:33 and if that is the case, a backport would be urgent 19:41:36 waiting to release 0.13 to release 0.12.2 first sounds stupid to me 19:41:43 or 0.13.1 would suffer delays 19:41:55 sipa: getting enough review for backport to 0.12.2 would be questionable. 19:41:57 sipa: yes, that was my expectation too, though the release of 0.13 would likely sabotage 0.12.2 deployment. 19:42:00 IMO we should remove any promise to maintain older branches once the newer one has a release, and provide backports only as a at-your-own-risk basis 19:42:08 I'd suggest putting a "if you want 0.12.2 w/ segwit, please let us know" in the release nodes for v0.13.0 19:42:24 petertodd: that's a good idea 19:42:35 Don't we take serious risks in BP SW in 0.12.2? Would it be evil to not BP SW to 0.12 and require 0.13 for SW? Would this delay supermajority activation significant? 19:42:37 if there are critical bugs in 0.12.1, we can always release 0.12.2 to fix them 19:42:37 we didnt backport CSV to 0.11 because the changes were too extensive - to be clear the backport was done, but we decided not to merge it (and there was not enough review either). 19:42:39 jtimon: I think we've done it before too 19:42:56 and depending on the response decide to the the backport or not 19:42:57 btcdrak: tbh, i think that the difficulty of a segwit backport is not that hard 19:43:02 luke-jr: that would be unfortunate in that its the wrong direction for the industry. The lack of professionality in software lifecycle isn't something we should be cementing, though I'm not sure I see much choice when we don't actually get the review/testing. 19:43:11 sipa: you would say that though :) 19:43:12 btcdrak: the original segwit PR was made with mostly 0.12 code still 19:43:14 luke-jr: maybe we should start making more really disruptive changes in major releases. :) 19:43:29 'maintain' older branches does not mean backport everything 19:43:35 agree 19:43:37 gmaxwell: I agree we should strive to support stable branches of course (as I've tried for years now), but the reality is we *can't* as things stand now 19:43:48 just that serious and critical issues are addressed 19:43:53 yes 0.12.2 can still happen if a serioud bug in 0.12.1 is founf 19:44:06 wumpus: not supporting a deployed softfork is a critical issue for a full node 19:44:08 gmaxwell: I've been always in favor of doing disruptive refactors just before branching instead of right after 19:44:39 ok, i need to run 19:44:49 luke-jr: SW could be deployed, I guess the majoriry is already on 0.13 and there is no need to keep 0.12 19:44:57 i'll still work on a backport if there is demand 19:45:08 jonasschnelli: that's a point I suppose 19:45:16 sipa: it might be a useful excercise from a review perspective in any case. 19:45:19 jtimon: that increases the pre-release pressure even more, and the potential number of problems what need to be solved before release ('disruptive refactors' have been known to introduce serious bugs in some cases) 19:45:27 luke-jr: remember that you can always run a node not supporting a soft-fork behind one that does to get the same security 19:45:52 petertodd: true; we should make this more well-known IMO 19:45:58 not sure how many people realise it 19:46:02 luke-jr: good thing for the release notes! 19:46:05 I always point it out. 19:46:08 wumpus: I mean the of the kind that present low risk (like file renaming on moveonly commits) 19:46:16 but it's the sort of thing that needs a diagram. :) 19:46:20 gmaxwell: did you for Eligius? :P 19:46:26 petertodd +1 19:46:32 has anyone actually quantified what level of review is required for a backport? 19:46:32 * luke-jr knows he overlooked it 19:46:33 wumpus: but I guess you're right about the pre-release preassure 19:46:47 segwit was written against 0.12. 19:46:48 actually, I guess it might not entirely work for CSV + mining 19:46:48 jtimon: in any case I doubt raneming and moveonly commits are what really makes it difficult to backport things :) 19:46:53 jtimon: more things like the mempool changes 19:47:34 petertodd: except you can't mine any segwit tx with a 0.12 behind 0.13 19:47:40 well I'd like to see a refactoring window right after branching, maybe 2 weeks 19:47:41 but you don't need to backport segwit from the present, you backport it from when it was merged, no? 19:47:54 maaku: it's not been done yet, so no-- but right now in general we're struggling to maintain the backport releases at all, because virtually no one uses them. 19:48:11 how would any refactor now difficult backporting segwit? 19:48:15 luke-jr: I don't consider that a great configuration for mining, but I think I'd mentioned it for a prior softfork. 19:48:45 we're spread really thin - agree fully on the 'don't get involved in a land war in asia' comment 19:49:16 jl2012: "can't mine" is a smaller group of people than all full node users 19:50:14 btcdrak: I would like to get refactor code reviewed during that "refactor window", just declaring the week of refactor doesn't make things get merged :p 19:50:17 incidentally, in my consulting practice I've always advised clients to use architectures where the exact behavior of full node implementations isn't important, which makes upgrades much less risky 19:51:54 jtimon: ack 19:52:14 petertodd: careful, though that thinking also drives the "I made my own 'node' implementation and have plugged it directly into the public p2p network! yippie!" 19:52:56 in any case, short on time. Are we done on this subject? 19:53:03 8 minutes left 19:53:08 gmaxwell: well, my advice is to either use a lite-client w/ up-to-date full node, or if you're using bitcoin core, plan to put it behind an up-to-date node 19:53:54 petertodd: perhaps we should talk to harding and write a deployment guide that shows things like that layering and test infrastructure. 19:53:55 seems so 19:54:01 gmaxwell: good idea 19:54:15 Generally you should have a two later setup in any case, don't put your production node up exposed to the internet... 19:54:29 gmaxwell: that too... 19:54:47 other topics? last-minute announcements? 19:55:38 I was getting flammed on reddit that it's common knoweldge that bitcoin core's wallet was unusuable for commercial use. I tried to get some unpacking there: https://www.reddit.com/r/Bitcoin/comments/4snk48/roger_ver_and_his_supporters_are_pushing_policies/d5bb73w?context=3 might be worth looking at the comments. 19:56:00 As I've lamented in the past, commercial users just generally don't report issues they encounter. I don't know how to improve that. 19:56:11 can be after the meeting but... 19:56:12 well if bitcoin core's wallet is unusable for commercial use, I wonder what wallet is.. 19:56:25 FWIW I've been encountering wallet issues, and am working on a patch that addresses some of them, especially WRT segwit. 19:56:28 What I could extra there was related to wallet performance, which phantomcircuit has recently done some improvement (and has more in the pipeline) 19:56:42 wumpus: people use centeralized api providers instead almost universally. 19:56:55 But I would like to see removal of "accounts". Is anyone working on that? 19:57:17 bsm117532: I tried to introduce a label API for 0.13 to replace it, then deprecate accounts in 0.14 19:57:21 bsm117532: re: removing accounts, have you checked with joinmarket on what they'll do? they use accounts 19:57:28 bsm117532: but that didn't get enough review 19:57:41 without having to ack or nack #8328 right now, general thoughts about moving consensus files to the consensus folder? I have heard different things, but if it's not clear, I will take it out of the base of my latest consensus branch 19:57:54 yay nay ? 19:58:02 bsm117532: https://github.com/bitcoin/bitcoin/pull/7729 19:58:06 jtimon: yay, after 0 19:58:25 sipa: yeah, I'm assuming after 0.13 branches 19:58:51 petertodd: that'd be really ill-adviced, given that we've been discouraging use of them for years, are you sure? 19:58:52 ironically, one of the complaints I got there was that accounts are discouraged. ::shrugs:: 19:58:56 though i prefer to leave some things as "base logic" like maaku suggests 19:58:58 I mean, if people want before I'm all in, but I highly doubt it 19:59:12 we should ping belcher 19:59:13 wumpus: yes, I'm 99% sure - I use joinmarket all the time 19:59:34 wumpus: I will review 7729 and try to offer some feedback 19:59:39 he's got some homework then... 19:59:45 as I wrote in the PR I think pushing everything used by consensus into `src/consensus` makes the source code less organized and less approachable by newbies 19:59:50 I need to get back on the road, bbl 19:59:53 maaku: agree 19:59:56 sipa: mhmm, you mean making another "base logic" dir and package in the makefile ? 20:00:13 jtimon: well one such piece of base logic is primitives 20:00:26 maaku: less approchable? I'd argue more - makes it easier to understand what consensus is and isn't 20:00:29 gmaxwell: it's also taking so insanely long to remove it 20:00:37 maaku: I strongly disagree (but maybe not all people are mostly interested in the consensus code like me) 20:00:49 gmaxwell: same as I've seen with the label API pull - no one is really interested in it 20:00:54 jtimon: things like prevector and so seem also more broadly usable than consensus 20:00:58 petertodd: that's rarely someone's first question when approaching the code base 20:01:00 I think keeping some base logic outside may work, ultimately serialization libraries might be soft-forks wrt an older consensus implementation 20:01:15 time up 20:01:18 well I hate to say it, but its not like the code is that approachable as is... 20:01:20 wumpus: is this the point where I hang my head in shame and point out that I've forgotten there was a label pull? 20:01:20 #endmeeting