< phantomcircuit> instagibbs, that's to do with the flushing interval of the wallet
< phantomcircuit> but i thought that was set to something ludicrously fast already
< GitHub14> [bitcoin] sipa closed pull request #7478: Bitcoin S+ (master...0.12) https://github.com/bitcoin/bitcoin/pull/7478
< instagibbs> phantomcircuit, could it be due to my laptop having some sucky io issues
< instagibbs> Core tends to make my machine freeze up more than just about anything else I run
< Luke-Jr> wumpus: can you ask support@github.com to relink bitcoin/bips to the same network as genjix/bips?
< wumpus> Luke-Jr: don't know, I'm not sure why it got unliked from petertodd's repo
< wumpus> unlinked*
< wumpus> instagibbs: have you tried assigning a lower number of cores? (-par=)?
< Luke-Jr> wumpus: most likely due to my inquiry last month, but they only accept an admin request to re-attach it :/
< wumpus> you asked them to detach it?
< Luke-Jr> no, I inquired about #<n> references hitting upstream repos; I *thought* they said it should just work without changes..
< Luke-Jr> but that was approximately the same time as the detaching occurred
< wumpus> so they likely made a mistake. Ok, I'll send a mail
< Luke-Jr> best I can tell, yes. but as a non-admin they don't seem to want to be clear on it in their replies to me.
< wumpus> https://github.com/petertodd/bips is now seen as a fork of bitcoin/bips
< wumpus> so apparently it is still the same network, but they changed the parent
< Luke-Jr> it's genjix/bips (and its forks) that's cut-off
< Luke-Jr> petertodd/bips was originally a fork of genjix/bips (the origin)
< wumpus> hmm
< Luke-Jr> my repo is also a fork of genjix/bips, so with the current situation I cannot open PRs
< wumpus> yes, I get it, they cut off a part of the tree and made bitcoin/bips the parent of that
< wumpus> so if I ask them to attach it to genjix/bips it should be ok again?
< Luke-Jr> If petertodd/bips is parented to bitcoin/bips now, I think attaching bitcoin/bips to genjix/bips will work
< Luke-Jr> putting it back to how it was before might need petertodd to be making the request
< wumpus> but that might mean that #<n> references again hit upstream repos
< Luke-Jr> was this ever an actual problem for bips?
< wumpus> I don't know. You reported it to them?
< Luke-Jr> it came up as a supposed problem on IRC, but I never confirmed it
< Luke-Jr> the response I got was that as long as the # existed in the repo it was being mentioned on, it shouldn't go across repos
< wumpus> ok... well I sent a request to reconnect it, we'll see what they come back with
< Luke-Jr> thanks
< petertodd> Luke-Jr: you can probably reconnect your repo to bitcoin/bips instead
< Luke-Jr> petertodd: that won't help everyone else branched off genjix
< petertodd> Luke-Jr: how many people are branched off genjix? can't be all that many
< wumpus> good point
< Luke-Jr> https://github.com/genjix/bips says 6 now. (it said a lot more a week ago..)
< wumpus> in a way having bitcoin/bips at the root is advantageous
< petertodd> wumpus: agreed, much more clear
< Luke-Jr> wumpus: ok, so email them nevermind and I'll just recreate mine or something
< petertodd> wumpus: I kept on getting pull-reqs meant for bitcoin/bips myself
< Luke-Jr> 5 others is no big deal
< petertodd> Luke-Jr: yeah, recreating works
< wumpus> ok, cancelled
< wumpus> hopefully rc3 can be -final this week
< petertodd> +1
< Luke-Jr> hopefully my release notes PR can be merged first <.<
< wumpus> I'm not really happy about this state of affairs re: priority in mining policy. It's clearly something that reasonable people can disagree on
< wumpus> I'd prefer to just keep it as a setting, but I understand it complicates the mempool code. On the other hand, removing some policy just because it streamlines the code is not really a good argument in itself.
< petertodd> wumpus: though if the policy is rarely used...
< wumpus> but who knows? luke-jr is against the change, and its very possible that he's not the only one
< Luke-Jr> wumpus: the mempool code can ignore priority without removing it from mining
< wumpus> right
< Luke-Jr> the result of this is that gratis transactions fail under high load/spam conditions, but priority transactions that pay a sufficient relay fee still get mined
< Luke-Jr> (speaking of gratis transactions, I was under the impression we were removing support for them from the wallet in 0.12, but it apparently still supports them? or is that a bug/oversight?)
< wumpus> that may be a bug/oversight yes...
< petertodd> do we have stats yet on how often we're under gratis-relaying conditions anyway? I run my nodes with 50MB mempool limits, and they're non-gratis basically 100% of the time
< Luke-Jr> petertodd: how could we? most nodes are pre-0.12, which has no such limits
< petertodd> Luke-Jr: sure, but I mean has anyone with a v0.12 node with default settings been keeping track of this?
< Luke-Jr> I would imagine until the block size nonsense is over, we wouldn't likely see gratis conditions
< petertodd> as in, you think we're seeing spam attacks to push the average usage up?
< Luke-Jr> gotta make Bitcoin look backlogged, after all <.<
< Luke-Jr> petertodd: clearly
< Luke-Jr> petertodd: actual volume is like 400k/block avg, and yet the block sizes are way higher :/
< petertodd> could definitely be true, especially with how actual day-to-day usage isn't impacted at all - tx fees are still really low
< Luke-Jr> this is why I think Classic has more like 10% economic support instead of 5% :p
< GitHub16> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e7ea5db0c190...326f010332a6
< GitHub16> bitcoin/master fa616c2 MarcoFalke: [doc] Update release-process.md
< GitHub16> bitcoin/master 326f010 Wladimir J. van der Laan: Merge #7465: [doc] Update release-process.md...
< GitHub59> [bitcoin] laanwj closed pull request #7465: [doc] Update release-process.md (master...Mf1601-releaseProc) https://github.com/bitcoin/bitcoin/pull/7465
< petertodd> Luke-Jr: speaking of, I'd like to get some clarify from the classic types on when they'd do another blocksize increase - what's the criteria exactly?
< petertodd> in particular, how much money do I have to spend on fees to force the issue prematurely...
< Luke-Jr> heh
< petertodd> it's also notable how jgarzik has been promoting non-bitcoin fintech uses of the blockchain for bitfury - demand for those is potentially basically infinite
< GitHub25> [bitcoin] laanwj pushed 1 new commit to 0.12: https://github.com/bitcoin/bitcoin/commit/b9ed8c996912aed9031caf0e3e6e32530ae6187a
< GitHub25> bitcoin/0.12 b9ed8c9 MarcoFalke: [doc] Update release-process.md...
< Luke-Jr> wumpus: any interest in moving icon rendering to `make distdir` stage? I have working code :p cons: requires rsvg & imagemagick to build from git
< wumpus> rather not require any graphical tools for building/deploying bitcoin
< wumpus> just make it a developer script that people can run when they actually touch the icons
< Luke-Jr> (building from tarball unaffected)
< wumpus> icon updates are rare enough to warrant running a special script when they happen
< wumpus> this also allows QA on the produced images, e.g. what if someone has a crappy version of svg, it'd basically include rsvg and imagemagick into the deterministic base
< Luke-Jr> I suppose. Unfortunately, it's also rare enough that it's probably not worth doing for that purpose alone. The value to me is for a different Knots icon without a binary patch file.
< wumpus> to be even more heretical: can't qt render svg images directly?
< wumpus> (probably means an even worse situation of having rsvg, which is notoriously leaky and buggy, as a dependency of bitcoin-qt, but OK)
< Luke-Jr> Qt's SVG rendering can't handle the shadows
< Luke-Jr> and requires a plugin
< wumpus> right
< GitHub105> [bitcoin] instagibbs opened pull request #7480: Changed getnetworkhps value to double to avoid overflow. (master...hashps) https://github.com/bitcoin/bitcoin/pull/7480
< GitHub193> [bitcoin] sdaftuar opened pull request #7482: [P2P] Ensure headers count is correct (master...fix-download-timeouts) https://github.com/bitcoin/bitcoin/pull/7482
< GitHub118> [bitcoin] luke-jr opened pull request #7483: Render icons from SVG (master...svg_icon) https://github.com/bitcoin/bitcoin/pull/7483
< GitHub57> [bitcoin] luke-jr closed pull request #7483: Render icons from SVG (master...svg_icon) https://github.com/bitcoin/bitcoin/pull/7483
< GitHub88> [bitcoin] luke-jr reopened pull request #7483: Render icons from SVG (master...svg_icon) https://github.com/bitcoin/bitcoin/pull/7483
< GitHub97> [bitcoin] luke-jr closed pull request #7483: Render icons from SVG (master...svg_icon) https://github.com/bitcoin/bitcoin/pull/7483
< GitHub100> [bitcoin] luke-jr opened pull request #7485: Use system univalue by default (master...sys_univalue_def) https://github.com/bitcoin/bitcoin/pull/7485
< GitHub59> [bitcoin] luke-jr reopened pull request #7483: Render icons from SVG (master...svg_icon) https://github.com/bitcoin/bitcoin/pull/7483
< Luke-Jr> cfields: Fetching qrencode… ERROR: no certificate subject alternative name matches requested host name `fukuchi.org'.
< Luke-Jr> on Travis..
< wumpus> that happens on 0.10 too; for some reason it doesn't even try the fallback after that
< * Luke-Jr> ponders if updating ca-certificates is sufficient
< fkhan> Luke-Jr using --no-check-certificate or building wget from source (1.17) can alleviate that
< Luke-Jr> I'm not sure why we're using https at all, considering we check the file hash
< fkhan> the dbus http mirror has a 301 to the wrong url, also
< fkhan> well, i thought the freedesktop ssl error was related to the fukuchi.org one, but totally separate (and was thinkign the same when i saw that last week :))
< fkhan> so, in dbus' case, it actually works better when using https
< fkhan> (until they change the redirect that is)
< fkhan> whoops, nvm, its fine now
< midnightmagic> Luke-Jr: protocol munging by malicious upstream ISP maybe?