< 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
< 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
< 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
< 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?