< pierre_rochard>
ken2812221: I took a look at #14007 in bitcoinacks.com, I wasn't picking up "tack" or "re-ack" in my parser, that's fixed now. Please don't hesitate to file an issue or PM me if you notice inconsistencies, I do want this to be a reliable tool
< kallewoof>
jimpo: reading https://github.com/bitcoin/bips/pull/725#pullrequestreview-154741923 it looks like you're suggesting the proof of funds should be a (fakeish) transaction, and the messsage signing should not be. Am I understanding that right? If so, it seems like you could just do transaction in both cases to simplify the spec. I.e. for signing message, craft two txs with the latter spending the former and former using
< kallewoof>
scriptPubKey of proof
< jimpo>
kallewoof: What about the data being signed? If I wanted you to sign an arbitrary message, would it be in an OP_RETURN or something?
< kallewoof>
jimpo: for proof of funds? I am thinking there'd be a txin with prevout=<sighash> and n=0 or something (where <sighash> includes the message)
< kallewoof>
you meant for signmessage, actually. same thing though.
< jimpo>
Yeah, I think you're understanding me right. But I'm suggesting using the fake transaction to generate the sighash, but as for as actual RPC messages and payloads and stuff, end users would just interact with the proof container, not the transaction itself.
< kallewoof>
right
< jimpo>
:-/ For sign message, that just seems overcomplicated
< kallewoof>
I have already had people object to signmessage being a transaction for UI reasons (e.g. the trezor people).
< jimpo>
manufacturing a tx for proof of funds makes sense to me because you are saying that this transaction with these already exiting UTXOs could actually exist
< kallewoof>
Right.
< jimpo>
but for sign message, manufacturing two dummy transactions seems very artificial and I don't see the benefit
< kallewoof>
The only benefit would be in that the two protocols "meet up" after the custom tx creation point. It's not a big deal IMO.
< jimpo>
Yeah, I see them meeting up at the sighash point :-)
< kallewoof>
I should probably write the code for this to geta better idea for what is actually necessary.
< luke-jr>
following the "this version is outdated" link at the top has the explicit limits
< luke-jr>
Change history has Issue 6: IEEE Std 1003.1-2001/Cor 2-2004, item XSH/TC2/D6/91 is applied, updating the ERRORS section to remove the error case related to abstime from the pthread_cond_wait() function, and to make the error case related to abstime mandatory for pthread_cond_timedwait() for consistency with other functions.
< luke-jr>
so I guess this was to make the failure deterministic?
< wumpus>
yes, makes sense
< wumpus>
an invalid *absolute* time passed in would be really strange
< wumpus>
I can see relative times ending up all over the place, including negative, but absolute ones
< luke-jr>
yes, an absolute max is silly here :/
< luke-jr>
oh, the nanosecond value is a *part*
< luke-jr>
ie, the 1000mil should overflow into seconds
< wumpus>
yes, nanoseconds field ending up >= 1000 million would be unequivocally wrong
< luke-jr>
What's this boost::exception_detail::clone_impl<boost::exception_detail::error_info_injectorboost::condition_error above?
< luke-jr>
maybe there's an invalid object somewhere?
< wumpus>
I don't know; if this was simple C code we'd probably already have found the problem, all this c++/boost exception verboseness adds nothing
< wumpus>
all those conversions between time formats, too
< wumpus>
what is a boost::chrono::system_clock::time_point, even
< luke-jr>
does GDB work on WSL?
< wumpus>
it's not a simple object wrapping seconds and nano/microseconds at least...
< luke-jr>
maybe he can get a backtrace and/or run some print commands
< wumpus>
I don't know
< wumpus>
so it is likely that timeToWaitFor passed to wait_unti is invalid, it would probably help trying to print that
< wumpus>
assuming this uses the BOOST_VERSION >= 105000 arm, of course
< luke-jr>
I figure a backtrace will help find out what we're actually using for the timeout object on our end
< wumpus>
if it uses the other one with toPosixTime, well here be dragons...
< luke-jr>
no point looking at the post-conversions value, since we can already guess it's invalid
< wumpus>
timeToWaitFor is the pre-conversion value
< wumpus>
we could ask what was the last version that did work, and see if there's been changes to that code since
< wumpus>
appaarently 0.16.x is all broken, but they don't say whether 0.15.x worked
< luke-jr>
has WSL been around that long? O.o
< wumpus>
it's been around for a while (as beta feature)
< wumpus>
even years ago when I still had at least one windows computer
< ken2812221>
pierre_rochard: thanks!!
< wumpus>
MarcoFalke: interesting, it looks like we have no direct dependency on LIBSSL at all anymore
< wumpus>
(doing a gitian build just to be sure)
< wumpus>
paymentrequestplus.cpp does some manipulation of certificates, but that appears to be part of crypto, not ssl
< gmaxwell>
\O/
< wumpus>
#startmeeting
< lightningbot>
Meeting started Thu Sep 13 19:00:05 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
< achow101>
MarcoFalke: there was that thing sipa pointed out
< achow101>
with psbt
< achow101>
#14196
< gribble>
https://github.com/bitcoin/bitcoin/issues/14196 | [0.17][psbt] always drop the unnecessary utxo and convert non-witness utxo to witness when necessary by achow101 · Pull Request #14196 · bitcoin/bitcoin · GitHubAsset 1Asset 1
< achow101>
I'm not sure if it is necessarily a bug, it is annoying though when encountered
< promag>
regarding missing pieces for multi wallets, hope to get #13100 and #13339 done shortly
< gribble>
https://github.com/bitcoin/bitcoin/issues/14197 | [psbt] Convert non-witness UTXOs to witness if witness sig created by achow101 · Pull Request #14197 · bitcoin/bitcoin · GitHub
< wumpus>
#topic refactor/linter PRs
< wumpus>
stop it stop it stop it stop it stop it stop it stop it stop it
< wumpus>
thx :p
< jnewbery>
I think a lot of people get the sense that there are a lot of refactor/linter PRs these days
< wumpus>
yes, it's too often
< jnewbery>
I'd hate to discourage any contributions, but I think it would be a better use of reviewer time and people would enjoy working on the project more if more PRs were focused on features/bugfixes :)
< achow101>
wumpus: unfortunately practicalswift isn't here to hear that
< meshcollider>
Lol
< promag>
we can write a lint to prevent new linters with grep
< gmaxwell>
I would describe the concern more broadly as there is a significant fraction of all PRs (maybe a majority) with basically no articulable direct or near term benefit to users... or even just exciting changes. In any project there is going to be some amount of house keeping for sure, and I'm super happy people want to work on bits of cleanup.
< wumpus>
I've told him a few times that tcleanups are okay, but not too often, say once a month or so, but they just keep coming, it's oversnowing the useful PRs
< provoostenator>
I like linters and other techniques to produce code consistentency, but obviously it shouldn't be become an obsession.
< wumpus>
it's becoming an obsession for me (in the negative sense)
< gmaxwell>
I feel really bad about finding myself in a position of saying "NAK. Your code is probably fine, but it's not worth anyones time to review it because it doesn't improve things enough."
< wumpus>
if this keeps up, I'll close them blindly
< ryanofsky>
i don't understand why you can't just tag them and look at the tag once a month
< provoostenator>
Maybe someone should just combine them all in one giant lint PR and come back in a few months?
< wumpus>
who doesn't he do that himself though?
< gmaxwell>
ryanofsky: because 'when you look' doesn't change the fact that there is a review/correctness burden.
< wumpus>
because some of us actually have to look at the list of allPRs and this is really discouraging
< jnewbery>
I don't think any more needs to be said about any individual contributor, but if we can all rate limit own own refactor PRs, I think we'd appreciate it
< wumpus>
yes, please
< MarcoFalke>
ryanofsky: They show up in the list of pulls by default
< promag>
however those monthly cleanups can be bigger and harder to merge
< gmaxwell>
Also it's a lot easier to churn out 'safe' refactor/cleanup changes and it's also easier to review/comment on them, so it changes the balance of activity in the project in general.
< MarcoFalke>
Can we add a pull request GitHub template that asks for clear motivation of the changes?
< wumpus>
the problem is that our proojct is one big bottleneck, I think if it was divided into hierarchical subsystems like Linux it'd be better, but it's not really possible to have that workflow with github
< wumpus>
all proposed changes end up in one big list
< MarcoFalke>
I.e. The changes need to improve user experience or significantly improve developer experience
< gmaxwell>
wumpus: dunno there, I mean, even if its subsystems, all of them need to be free of exploitable crashes. :) (okay maybe a few subsystems would really be isolated from any possible hostile input...)
< jnewbery>
wumpus: is that true? If wallet and node were better separated, would it be possible to have a master branch and a wallet dev branch for example?
< jonasschnelli>
should we submodule the test system?
< gmaxwell>
MarcoFalke: I also was thinking about articulate the benefit.
< meshcollider>
wumpus: that's the point of GitHub "projects" isn't it
< gmaxwell>
er, directing people to articulate the benefit.
< MarcoFalke>
yeah ^
< wumpus>
ideally I don't want to have to look at every PR individually anymore, in the case of Linux there's subsystem maintainers that make their own tree of updates and it can be merged (or rejected) at one
< gmaxwell>
I do think we do want general code tidying some too... but those shouldn't be a signficant fraction of the PR flow.
< wumpus>
jnewbery: this is not a technical issue about separation in the source tree, Linux is also one big tree
< jnewbery>
wumpus: I'll read the danvet post
< wumpus>
it's just that top-level PRs don't really scale
< wumpus>
I can't manually, humanly, handle 200+ PRs, sorry
< jnewbery>
proposed topic: wallet maintainer
< MarcoFalke>
I have seen that practicalswift also runs a bot(?) to comment on pull request directly with feedback harvested from clang-tidy
< wumpus>
and if it keeps going like this, at some point it's going to break down
< MarcoFalke>
I think these are more useful than linters
< sipa>
i plan to do more wallet work soon, to push descriptors and other things forward
< wumpus>
so we need a different way of woring
< sipa>
now i have to run, sorry; will be back next week
< wumpus>
later sipa
< promag>
o/
< promag>
MarcoFalke: agree ^
< wumpus>
#topic wallet maintainer
< wumpus>
MarcoFalke> I.e. The changes need to improve user experience or significantly improve developer experience <- yes
< MarcoFalke>
ok, will write up something today
< MarcoFalke>
sipa is gone, so let's assign him to be wallet maintainer?
< gmaxwell>
ACK.
< achow101>
+1
< sdaftuar>
i thought we already did that
< jnewbery>
I think wumpus has wanted a wallet maintainer for a while, and sipa is probably too busy to take that role. I wonder if there are any actions we can take to find someone to be wallet maintainer in, say, the next six months
< meshcollider>
I feel like he has already been assigned that role many times
< wumpus>
best if it fixes a reported issue, or something that is clearly either a problem from a user perspective, a performance or security issue, etc
< promag>
vote jnewbery for wallet maintainer :P
< jnewbery>
promag: -1
< provoostenator>
What is the wallet maintainer job description?
< wumpus>
it's like a game of hot potato
< MarcoFalke>
jnewbery: I am not aware of any single person that really knows what is going on in the wallet
< pierre_rochard>
ryanofsky?
< jnewbery>
MarcoFalke: that makes everyone equally qualified
< wumpus>
provoostenator: review and merge wallet changes
< gmaxwell>
sipa is closest, mostly as a side effect of knowing everything.
< jonasschnelli>
I think sipa is kinda the wallet maintainer... or am I wrong?
< jnewbery>
but seriuosly, I think it's more important to have a sensitivity to what they don't know rather than have an encyclopedic knowledge of everything
< provoostenator>
Well, some degree of not understanding can be compensated by not merging without ACK's from people who do.
< wumpus>
yes, exactly jnewbery
< jnewbery>
and it's only 15k lines of code. How difficult can it be?
< wumpus>
it's a matter of judgement I guess
< gmaxwell>
jnewbery: tada, disqualified. :P
< achow101>
jnewbery: I think it's a bit cleaner now with accounts gone
< achow101>
less idiotic to understand
< wumpus>
it's not even that bad if you dn't fully understand it now, if you're willing to learn it
< MarcoFalke>
So I believe the closest to a wallet maintainer would be the people that worked most on it in the last two releases
< jnewbery>
my point in raising this topic is not "let's find a wallet maintainer today", but "can we take steps now to identify someone who might be a good wallet maintainer in a few months"
< wumpus>
yes, getting rid of accounts did make it less crazy
< jnewbery>
It seems that waiting around for someone to volunteer or step up hasn't really worked
< gmaxwell>
having to support old stuff is just a pain. It's hard to do without having had a lot of exposure to the history as there are many poorly documented properties that the existing stuff obeys.
< wumpus>
I wonder how Linus picks subsystem maintainers
< wumpus>
though, I guess, people actually volunteer
< gmaxwell>
jnewbery: I dunno, I think things are working in the sense that its becoming simpler and more people are contributing to that part actively than were in the past.
< jnewbery>
gmaxwell: we're still too bottlenecked on wumpus
< meshcollider>
Make a large wallet PR and the first person GitHub picks as a "suggested reviewer" is the new maintainer
< wumpus>
jnewbery: yes
< jnewbery>
so we need to make a wumpus bot or delegate to maintainers
< gmaxwell>
Github just doesn't really directly facilitate that kind of workflow.
< wumpus>
ideally I could just leave for a bit and things would continue
< promag>
honestly I think jnewbery has done a great job cleaning and maintaining and improving wallet code
< achow101>
the solution is to just upload wumpus's mind and then start 20 instances of him :p
< gmaxwell>
like why are we actually bottlenecked on wumpus? perhaps wumpus needs to start tagging things with "I'm not going to merge this PR"
< wumpus>
achow101: yes!
< provoostenator>
I'd be fine with jnewbery doing this as well.
< meshcollider>
jnewbery: in all honesty, would you not want the role
< wumpus>
me too
< jamesob>
instagibbs seems to know wallet pretty well
< gmaxwell>
it's not like there is an actual technical physical bottleneck on wumpus.
< jnewbery>
I'm flattered, honestly, but already too busy with bitcoin optech, residency stuff, etc
< jnewbery>
perhaps something for discussion in tokyo
< MarcoFalke>
I think the bottleneck is not clicking the merge button (any of the 4 maintainers can do this)
< MarcoFalke>
The bottleneck is review and signing off on the merge
< MarcoFalke>
(when ready)
< wumpus>
yes, which is not always an easy judgement, but still
< provoostenator>
So it's more like a "sudo ACK"?
< gmaxwell>
well if we're concerned about review cycles then we need to talk about focusing resources on whats important. So perhaps more than 'foo maintainer' we need someone curating the priority list for a subsystem.
< wumpus>
if you know a certain part of the code well enough you could be maintainer of it
< wumpus>
like, in Linux, if you wrote a certain driver, you're pretty much maintainer of it by default
< gmaxwell>
the high priority PRs things helps, at least as we close for a release...
< MarcoFalke>
We could assign jnewbery and ryanofsky and other contributors the right to sign off on wallet changes and then some maintainer merges the changes.
< MarcoFalke>
So have more than one wallet maintainer
< wumpus>
well the maintainer of a subsystem would also curate prioriteit
< wumpus>
the problems seems to be finding people, *NOT* finding things for them to do :)
< achow101>
MarcoFalke: isn't that the point of ACK's though?
< meshcollider>
MarcoFalke: isn't that basically just an ACK then
< promag>
right achow101
< MarcoFalke>
Not every ACK means merge
< gmaxwell>
wumpus: well curating priority projects for a subsystem is less risky task, probably more people willing to do it, and fewer concerns about whos doing it.
< MarcoFalke>
more like the "sudo ACK" (provoostenator)
< wumpus>
well it's more subtle than that, otherwise it could jsut be a bot
< MarcoFalke>
In the future I want it to be done by a bot, but thats a differnt topic
< wumpus>
you also have to have a feeling who is the right person to ACK something
< wumpus>
which would be possible if someone was a maintainer of that subsystem
< provoostenator>
Does Github allow putting a "maintainer" badge on someone so it's more obvious for people that these maintainer ACK's are required / strongly recommended.
< wumpus>
but we're circling around
< gmaxwell>
like who would actually understand if this is broken or will cause problems down the road, vs who just looked at it and went yep no undefined behavior!
< meshcollider>
provoostenator: mo
< meshcollider>
No*
< wumpus>
gmaxwell: righ
< wumpus>
anyhow, if someone wants to be wallet maintainer, or maintainer of some other subsystem, let me know
< clarkmoody>
provoostenator: maintainers.md
< wumpus>
clarkmoody: yep
< provoostenator>
Ok, that works.
< wumpus>
you can define a path there, and who is maintainer, I think github even parses it somehow
< promag>
and what should a maintainer do? :P
< meshcollider>
So in terms of steps, be more active I'm looking for someone to push into the role? What else is possible
< gmaxwell>
I think we should all act as though we were the maintainers of things more.
< jnewbery>
meshcollider: yes, I think so
< wumpus>
promag: just be very active in maintaining a piece of code, like, review all PRs that change it, judge when a change is good, etc
< gmaxwell>
not only does this potentially reduce work for others, but it helps identify people who are organically doing the job anyways. Which is, for the most part, what other projects do.
< gmaxwell>
I think the issue wumpus struggles with is in part because no one is doing the job already.
< gmaxwell>
:)
< gmaxwell>
If someone were, it would be both less of an issue, and an easier thing to decide.
< wumpus>
I mean I could pull a Guido van Rossum and just stop merging things and let you figure it out for yourself, but I'd prefer to have a saner path forward
< provoostenator>
So we can just mark a bunch of people as Code Owners (as well maintainers.md) for the wallet and require review from at least one of them, as a step in the right direction?
< wumpus>
but it's not given that I will be doing this forever
< promag>
anyhow, if someone wants to be wallet maintainer, or maintainer of some other subsystem, let me know <-- wumpus: they should just step up?
< promag>
like, ken2812221 looks like windows maintainer?
< meshcollider>
provoostenator: that's effectively how RTM is judged anyway
< wumpus>
promag: good idea!
< wumpus>
he's doing a great job with the windows unicode support
< gmaxwell>
The important thing is actually doing the work, meaning taking a concerted effort to review and understand changes, their short and long term implications-- their impact on the users, network, rest of the code base, their historical context... along with sheparding things along to make sure the required stuff gets done (if not actually doing it themselves)
< wumpus>
I'm—somewhat disappointed—that windows still needs so much platform-specific code, but it's better than breaking on non-english people's PCs
< gmaxwell>
These are things that almost everyone can do more of.
< wumpus>
gmaxwell: agree
< wumpus>
if someone was doing the work then assigning someone a maintainer label was easy
< wumpus>
that's how jonasschnelli became GUI maintainer, for ex.
< gmaxwell>
So I think thats really an action item people can take from this discussion, look for oppturnityies do to more of that yourself, and to help others do the same.
< wumpus>
yes
< gmaxwell>
opportunities*
< gmaxwell>
Were there any other topics? kind of a bummer of a meeting. :)
< meshcollider>
John had a third
< jnewbery>
I had one more quick one on archiving meeting notes (sorry - didn't mean to take up all the time. Thought they'd all be quick)
< wumpus>
#topic archiving meeting notes
< jnewbery>
Botbotme is shutting down. not sure if anyone uses it
< wumpus>
so just a matter of copying those to bitcoincore.org and voila
< meshcollider>
Ideally could run both botbot and the meetbot on the bitcoincore.org server directly ?
< provoostenator>
Perhaps irc.bitcoincore.org could run such an instance? It's a much nicer format imo.
< wumpus>
it needs to be checked into git so I don't think it can happen fully automatically
< provoostenator>
Different subdomain means you can skip the Github flow (initially).
< achow101>
wumpus: it could run in a sub domain
< MarcoFalke>
provoostenator: I would want to host random irc logs on the bitcoincore domain
< MarcoFalke>
Can be a completely separate trash.bitcoin-core-dev-logs.domain
< wumpus>
these are only logs of the meeting
< provoostenator>
You can pick which channel(s) to log. Or are you worried even about what could end up in this channel?
< jamesob>
re: cutting down on refactoring PRs: one option might be to add a policy that forces refactoring-only PRs to document how each changed git hunk is covered by tests. If no test exists, obviously the proposing contributor would have to write one.
< wumpus>
oh you want to log the entire channel?
< MarcoFalke>
Yeah, I think it makes sense
< meshcollider>
BotBot currently does and I think that's worth keeping up
< achow101>
I think it currently makes more sense to log the entire channel with botbot going down
< provoostenator>
I've linked to botbot logs in Github tickets more than once. Whatever tool we use, being able to deep-link to a specific message is very nice.
< wumpus>
jamesob: I think that's good policy for any change, yes
< meshcollider>
Agree
< MarcoFalke>
Can botbot be hosted on GitHub (or at least the assets?)
< jamesob>
wumpus: my only reservation is that that's a pretty high burden for large changes from established contributors... but maybe that makes it even more worthwhile :)
< wumpus>
it can't run from github
< wumpus>
jamesob: the biggest issue here is the volume, not so much the changes themselves, many don't even change the compiled code or are obviously correct like removing an argument
< MarcoFalke>
Can it store the logs in a git repo?
< wumpus>
jamesob: whichi s okay, but not of 5 of such PRs are opened every day
< meshcollider>
MarcoFalke: I'm sure you could turn the log directory into a git repo either way
< wumpus>
MarcoFalke: sure, though if commits need to be signed :)
< provoostenator>
OTS?
< jamesob>
wumpus: very much agreed. I was just thinking that such a policy (plainly advertised in a PR template, say) would filter out half-baked or lazy refactors (or at least allow a justified quick close)
< wumpus>
when commigint to bitcoincore.org, really a human needs to be invovled
< meshcollider>
Don't need to sign the commits if they're just pushed to a separate meeting-log repo
< MarcoFalke>
If it is a binary blob (db) it might not work with git (or GitHub at least)
< wumpus>
oh, no it's just text files
< MarcoFalke>
kewl
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Sep 13 20:00:58 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< promag>
jamesob: we already ask to split such pulls to ease review
< MarcoFalke>
So (1) contact lincolnloop to fetcht the text logs of BotBot (2) put them on GitHub (3) Run a bot somewhere that keeps them up to date and hosts them on some domain?
< promag>
jamesob: and how can we enforce that policy?
< MarcoFalke>
DrahtBot can close prs that are refactoring that is not covered by tests ;)
< MarcoFalke>
Though, that would close almost all refactoring prs
< jamesob>
if the author didn't provide a coverage list and the PR is marked refactoring, it's an immediate close
< achow101>
MarcoFalke: Is it necessary to get the logs from lincolnloop? We have the logs on at least two other sites as text files
< promag>
how can DrathBot know if it's covered or not?
< MarcoFalke>
achow101: If they are complete, then I guess not
< MarcoFalke>
promag: make cov
< achow101>
MarcoFalke: they look complete. they're in the topic
< meshcollider>
So make a new repo in bitcoin-core called irc-logs or something and upload them ?
< promag>
regarding scantxoutset release notes, should create separate file or append to release-notes.md?
< achow101>
promag: use the wiki?
< achow101>
or did that get merged in?
< MarcoFalke>
achow101: They don't have html anchors, so hard to link to them for reference
< MarcoFalke>
So I'd prefer them in a botbot-html-format
< MarcoFalke>
The wiki is not yet merged in
< meshcollider>
Yeah ideally all the logs are easily viewable from a botbot-like site
< wumpus>
does take viewing the source to find it, though :)
< aj>
oh, i can fix that
< aj>
oh, no i can't, at least not the documented way :(
< aj>
oh well, it includes line numbers visibly now so it should be easy-ish, but not point and click
< gmaxwell>
damn, never thought I'd see the day... windows 10 has a networking feature that I wish linux had.
< gmaxwell>
Apparently you can set a socket option to make a TCP connection use LEDBAT congestion control, on a per socket basis.
< gmaxwell>
but fortunately, MS has ways of making me not feel too bad.. apparently only "approved software" can use the socket option.
< gmaxwell>
Thats too bad, it would make for a meaningful improvement in bitcoin node usability for many users if we could use that.
< TD-Linux>
if it's really useful you could do a userspace implementation a la uTP
< gmaxwell>
TD-Linux: utility vs sheer mass of OMG RCE VULNERABLE CODE...
< gmaxwell>
the utility of it is that peers pulling many old blocks from us utterly slams the network connections of people with bufferbloated links.
< gmaxwell>
And short of LEDBAT there isn't really a good fix for it.
< gmaxwell>
But I don't know that the problem is severe enough that we'd want to ship a userspace network stack...
< TD-Linux>
fair. also those people can prune
< gmaxwell>
TD-Linux: they don't need to prune, they can just turn off service old blocks (set the upload limiter to zero)
< gmaxwell>
serving*
< gmaxwell>
But indeed, unfortunately having to have them configure stuff is kinda lame... since only a small portion of people who should do it actually will.
< gmaxwell>
the rest will just have a bad time, and turn it off.
< achow101>
wumpus: is #12493 ready to be merged? it has several acks