< morcos>
Ylbam: It's a very minor point. The idea is that if there is a transaction that is in your wallet but is not in your mempool because it is sequence locked and not yet final according to BIP 68 there is currently no indication through the UI that this is WHY it is not in your mempool.
< morcos>
It's a very unusual circumstance as of right now anyway, because you can't get a tx in your wallet that is sequence locked and not final in the first place unless it happened by virtue or a reorg (it was previously final and is now not)
< morcos>
The only reason I mentioned it is the old version of the BIP 68 implementation in #6312 did make an attempt to display this information in that rare case, but I removed it and saved if for a later improvement
< gavink>
tangent: do you think core should maintain a place for binaries and source to easily be downloaded, so it's easier to write guides, and show control of what core is doing? would linking to bitcoin.org in a guide for bitcoincore.org be ok? (i am looking at writing some guides for running nodes on the core website) thank you
< gavink>
i suppose sourceforge hosts binaries
< phantomcircuit>
jtimon, "UpdateTip"
< Luke-Jr>
gavink: SF has not been used in years
< Luke-Jr>
I agree we should move downloads to the bitcoincore.org domain though
< gavink>
yes i know about SF. Is your server prepared for extra load? I will ask the web collaborators then.
< Luke-Jr>
gavink: the idea is to put bitcoincore.org on the same server currently hosting bitcoin.org (the server is not itself bitcoin.org's)
< gavink>
right ok thanks, i'll see if i can help facilitate this
< GitHub65>
[bitcoin] laanwj closed pull request #6819: WIP: force zeromq to work with static linking+mingw (master...zeromq-mingw) https://github.com/bitcoin/bitcoin/pull/6819
< GitHub18>
[bitcoin] zander opened pull request #7460: Make internal (core) errors show up in the Qt client. (0.12...propagateAlert12) https://github.com/bitcoin/bitcoin/pull/7460
< GitHub50>
[bitcoin] zander opened pull request #7461: Make internal (core) errors show up in the Qt client. (master...propagateAlert) https://github.com/bitcoin/bitcoin/pull/7461
< zander>
I just opened those two; not sure what "Wladimir J. van der Laan"'s nick is. Nothing stands out.. But if you have questions about those MRs, ping me :)
< wumpus>
<-
< zander>
hi
< wumpus>
zander: re: #7461, as the 0 .12 and master change is pretty much the same, there is not really a need to open two pulls, just filing it to master and stating that it needs backport to 0.12 is enough; this makes sure that there is only one place per 'issue' to review/comment instead of multiple (which has led to confusion)
< zander>
wumpus: Ok, my logic was that I had to test it before sumitting a backport MR. But fine, either way.
< wumpus>
zander: yes that's reasonable, it's just that the github way of working doesn't really work very well with multiple branches
< zander>
fair enough
< wumpus>
PRs are pretty much discussion topics, so having two with the same topic will confuse people (like me, thinking it is a duplicate)
< wumpus>
or what you could also do is post a link to a 0.12 branch,and say you've already backported it
< wumpus>
anyhow I'll now just rename one [0.12] but it will get out of hand if we have two pulls for every single thing :)
< zander>
whatever works for you :)
< zander>
I just want to make it as smooth as possible for you.
< zander>
It would be really nice to get this into the next release since any forking stuff going on needs to be shown to the user.
< wumpus>
yes, makes sense
< GitHub168>
[bitcoin] zander closed pull request #7460: [0.12] Make internal (core) errors show up in the Qt client. (0.12...propagateAlert12) https://github.com/bitcoin/bitcoin/pull/7460
< OxADADA>
TIL wumpus is Waldimir.
< OxADADA>
my nick would be 0xADADA if IRC supported nicks starting with 0 :(
< gijensen>
I've been wondering this whole time
< gijensen>
(about your nick I mean)
< OxADADA>
gijensen: everyone does ;)
< cfields>
wumpus: wrt win signing for rc3/final, creating the new cert will revoke the previous one. Previous releases are timestamped, so I don't believe they should be affected.
< cfields>
wumpus: would you prefer to use a new key for rc3 and risk problems with older releases, or stick with the old key and risk issues with win7+ ?
< wumpus>
OxADADA: hah, yes, last time I tried to type your nick I tried 0<tab>, and wondered why nothing would come upr
< wumpus>
cfields: ouch. does that mean all previous releases will stop working on windows?
< wumpus>
cfields: or does it just mean that nothing new can be signed with those keys?
< cfields>
wumpus: since they're timestamped, they're _supposed to_ remain valid as long as the timestamp falls before the revocation time
< cfields>
but i can't attest to that working as described, could only hope
< wumpus>
cfields: ok, let's use the new key for rc3. If this screws up it doesn't really matter if it happens now or for final it'd be a disaster in both cases
< wumpus>
and unavoidable too, unfortunately. I guess we could re-sign old releases but bleh
< wumpus>
I hoep you're right
< cfields>
heh
< cfields>
well, I've for sure always timestamped previous releases
< cfields>
(as long as i've been doing them, anyway)
< cfields>
wumpus: we also have the option of changing the name/org for the key while we're at it. Would you prefer to try to change to Bitcoin Core, or keep all else the same?
< wumpus>
can you just choose that name? sure, yes I'd like it to be Bitcoin Core
< cfields>
yea. Not sure what verification mechanisms it triggers. I'm nervous to go any further because I want to ensure that the old one isn't revoked yet
< Tasoshi>
congrats gmaxwell on raising 55 million dollars
< Tasoshi>
how do you plan on spending them?
< OxADADA>
Tasoshi: If they're smart, they'll prove their value as a modern startup company and buy a Foosball or Table Tennis. If they're "oldschool" they'll prove it by buying Aeron chairs.
< OxADADA>
all the kewl startups must do this, by law.
< * OxADADA>
scoffs at Taek (WHERE IS YOUR FOOSBALL TABL!?)
< zooko>
Hey folks, we're setting up continuous integration for the Zcash project, including running tests in response to PRs.
< Luke-Jr>
zooko: cool. Core has done that for a long time ;)
< GitHub47>
[bitcoin] wangchun opened pull request #7464: Opt-in RBF must be strictly enabled or disabled before GBT can be called (master...master) https://github.com/bitcoin/bitcoin/pull/7464
< zooko>
Luke-Jr: with travis-ci, right? Yeah.
< zooko>
Luke-Jr: one thing that I hope to add soonish is an ARMv8 buildslave. "Soonish" meaning a matter of weeks.
< zooko>
Luke-Jr: anyway, let me know if you have some desired for testing/measurement/CI that might overlap with mine.