< gmaxwell>
jtimon: regarding your comment in lightning-dev, it's kind of rude to the community here to go around to our end users to advocate a pull request that has been open for 7 minutes.
< jtimon>
gmaxwell: thanks, noted. I'm poor in netiquette I think
< jtimon>
I was thinking about them while wrting the btanch though, in my defense
< gmaxwell>
Sure, and in this case I don't think it answers what they were asking about. Their concern was that they want a globally shared public testnet, but without having a 2000 block reorg every couple months that breaks their stuff. :)
< gmaxwell>
and having chainparames in a file doesn't really change that.
< GitHub9>
[bitcoin] TheBlueMatt opened pull request #8995: Add missing cs_main lock to ::GETBLOCKTXN processing (master...2016-10-fix-getblocktxn-locks) https://github.com/bitcoin/bitcoin/pull/8995
< wumpus>
< gmaxwell> and having chainparames in a file doesn't really change that <- well it could. There's no rule that people can't share chainparams file
< wumpus>
with chainparams files they could have arbitrarily defined shared testsnets, sharable by just copying a file
< wumpus>
that's 100% better than having to go through our review process every time whether some network is really worth defining
< wumpus>
or whether it should burden the codebase forever
< wumpus>
I really don't understand the opposition to this idea, are you afraid people will make actual altcoins this way?
< wumpus>
I personally doubt that, as it doesn't let you override things that are not in the codebase in the first place like hash algorithm
< wumpus>
but imagine: people want some testnet and they can just define it and share it, instead of having to bother us
< wumpus>
*without* having to compile their own software
< btcdrak>
I like the idea. Testnet is a mess at the best of times.
< btcdrak>
It's also testnet, I think giving users a bit of freedom to start/join their own test chain means we dont have to worry as much about it.
< wumpus>
and the possibilities for the QA tests are also many, e.g. there was some pull to improve testing by changing the halving interval (8623). This was rejected because it burdens the software with special-case options
< wumpus>
if the parameters are just read from some .json file, no such problem anymore, the test can just define its own parameters
< wumpus>
btcdrak: exactly
< btcdrak>
Also, since there is no incentive to mine a testnet, they are always going to be unstable and unusable. I have spent _month_ chasing testnet miners when their stuff breaks, goes offline. It's been utterly impossible. Then you get people like Ver running consensus incompatible stuff on the main testnet making it unusable for everyone else. At least this way
< btcdrak>
he could test what he wants on a private chain without causing major disruption.
< wumpus>
yes the mining problem would not be solved by this - I guess for that one we do need limited mining algo choice in the chain file, e.g. a 'fake mining' where the blocks are signed regularly by a central party (that's fine for a testnet)
< btcdrak>
Well my own opinion is the diff 1 thing is utterly useless, we'd be much better having a per block retarget on testnet if using PoW.
< wumpus>
the signing key would be in the json, no keys would be hardcoded into the client code, "wumpus signs a block every 10 minutes" fine
< btcdrak>
oh interesting.
< wumpus>
yes, you could also choose PoW with some other parameters
< wumpus>
as long as it is double-SHA256 :-)
< btcdrak>
I have a very well battle tested fast diff adjustment. Certainly the most accurate one in live deployment.
< gmaxwell>
wumpus: congrats, you get the jtimon award for not listening.
< gmaxwell>
wumpus: no one was asking to define more testnets.
< gmaxwell>
wumpus: they were asking to have a public testnet shared among everyone with predictable blocks and no uncontrolled reorgs.
< gmaxwell>
If a config file is a good thing or not is not here nor there. I suppose it's fine (except in so far that it cruds up the code with additional indirection to read things that would otherwise be constants).
< gmaxwell>
Going and telling people, that you're getting this instead when it doesn't do at all what they asked for is insulting.
< wumpus>
that indirection already exits
< wumpus>
from the time this CChainParams structure was defined
< wumpus>
we're just not using it to the fullest
< gmaxwell>
wumpus: get it out of your head that I'm at all commenting on having the files.
< gmaxwell>
I don't care, I think it's a pointless feature that we've already lowered the quality of the codebase to enable, but that wasn't the point.
< wumpus>
sure, but being able to define additional testnets also makes it possible to define more reliable ones, as well as having the wildwest one for testing other things
< wumpus>
god damnit
< btcdrak>
well federated signing will go a long way to help that aim. configurable testnets would be an easy way to achieve that
< wumpus>
YOU don't listen either
< wumpus>
btcdrak: exactly
< gmaxwell>
wumpus: glad we have something in common then. :)
< wumpus>
"lowering the quality of the codebase" why
< wumpus>
how do you suggest doing that in a better way?
< wumpus>
can you stop complaining for once? not only what matters to you matters
< wumpus>
I'm tired of this madness, whatever you do people are going to complain, going to disengage from bitcoin-related things for a while
< gmaxwell>
There are places where we're making multiple function calls in an inner loop to access a constant integer.
< wumpus>
most of that gets optimized out as they're inline functions
< wumpus>
and where not, it usually doesn't matter as it's not used in performance critical loops anyway
< wumpus>
if it is an actual bottleneck somewhere, I'd like to know of course
< gmaxwell>
How would we ever no, no one ever checks? we just end up with GetChainparams().GetConsensus().getdarnaninterger() all of the place.. :P but I don't care and I don't know why you think I care.
< gmaxwell>
please review my commentary earlier. I said _nothing_ negative about having a configuration file.
< gmaxwell>
It is the case that I'm not impressed by it, but whatever.
< gmaxwell>
That isn't what I was commenting on.
< gmaxwell>
I was commenting on jtimon going to people who asked for something specific and telling them that this other thing was what they were getting. Thats all. it creates awkwardness.
< wumpus>
GetChainparams().GetConsensus().getdarnaninterger() is temporary, the idea is to have the consensus parameters either available (e.g. pass them in) or store them locally
< wumpus>
this disentangles from using global structures everywhere, which is useful for testing
< wumpus>
things can be tested in isolation instead of having to take care of all kind of global state that leaks in
< gmaxwell>
K. Thats reasonable.
< gmaxwell>
When I commented to jtimon earlier, I didn't have any recent opinions about the indirection, though I did just spend an hour ripping out checkpoints completely before your comments, so I had something to offer when you brought it up.
< gmaxwell>
I came up with a way to completely eliminate checkpoints-- missing part was how to prevent header flooding attacks-- that I think is deployable. (assuming we're either okay with removing the signature skipping which I still need to benchmark, or we replace it with some not checkpoint thing)...
< btcdrak>
I do wish we could accelerate the libconsensus work, it's so long and drawn out.
< wumpus>
that applies to all projects going on, not just libconsensus
< wumpus>
our development methodology is too slow for handling even all submitted PRs
< wumpus>
and no, I have no clue how to improve it
< wumpus>
too much going on for me to handle anymore at least
< gmaxwell>
tell you what though, -- having lots of things we know we want to do, more than there are hours in a day-- is a lot better problem than the opposite.
< wumpus>
sure, you have a good point there
< wumpus>
it's good that things are going faster than ever, but it does expose the bottlenecks in the process
< gmaxwell>
And we're getting a _ton_ of interesting things done, ... which is a better metric than the ratio of our appetite to our plate. :)
< gmaxwell>
yea.
< gmaxwell>
(sorry for the delayed response, turns out wifi doesn't work so well when you rmmod the driver) :P
< wumpus>
so at least let's try to be understanding of changes other people are trying to do, have some trust in them even if you can't follow them in detail
< wumpus>
this project became too big for any one person to follow everyone
< wumpus>
I'm still trying and it only gives me a headache and lack of sleep
< wumpus>
in any case I'm going to work on GPU drivers a bit more now, still have some outstanding work to do there, maybe I can return to bitcoin with a clearer perspective
< Victorsueca>
morning
< shangzhou>
wumpus: I want to thank you and other devs for the ongoing great contributions.
< btcdrak>
are there any particular things we need to cover in the segwit migration guide?
< gmaxwell>
so far the things I'm aware of are peremiter node deployment, and what to do if you're on older debian without a C++11 compiler.
< gmaxwell>
for the latter, I'm not sure what the answer is.. one option is "use bitcoin.org binaries" but if you have to compile perhaps there is a newer compiler you can install out of the next distro version without breaking things?
< btcdrak>
i wonder if aj has any insights, ping
< btcdrak>
which min version of debian has c++11 support?
< aj>
seems like jessie; the bitcoin.org binaries seemed to work fine for me in a chroot
< gmaxwell>
wheezy doesn't and I had a couple of companies mention this to me, they don't seem too concerned about it but we should have some guidance. I'm pretty sure the binaries will work fine, and I can test... but if there is also an option for people who need/want to compile that would be good too.
< btcdrak>
they could always use the gitian build process to make binaries if they are more paranoid.
< gmaxwell>
may be a product of customization instead of paranoia, but hm indeed, use the same process to build static binaries on another system would also work.
< aj>
i don't see any updated gcc versions in backports
< btcdrak>
gmaxwell: have you looked at the draft blog post and migration stuff harding has been working on?
< wumpus>
yes a depends build on another system with the same architecture should be sufficient
< wumpus>
(or alternatively a depends cross-compile)
< wumpus>
also configure with LDFLAGS=-static-libstdc++
< wumpus>
but that should be all, using the full gitian process should not be necessary if you're just building binaries for yourself
< wumpus>
yes there seem to be random travis failires at the moment with p2p-compactblocks.py, does it pass locally?
< btcdrak>
strangely enough, Travis offers me a "restart job" button, which I can press and it says "successfully restarted job" but nothing happens.
< wumpus>
I pushed it too...
< btcdrak>
wumpus: p2p-compactblocks.py passes locally for me on that PR.
< wumpus>
ok
< Victorsueca>
so the next release is the final one? or we will have another rc?
< btcdrak>
If there are no blockers, next release will be final
< wumpus>
the final release before the end of the world
< Victorsueca>
lol
< Victorsueca>
the end of the world.... as we know it and the beginning of the decentralised currency era! buy bitcoin know while your fiduciary money is still worth something!
< Victorsueca>
wumpus: just converted your sentence into a commercial :D
< PRab>
FYI, I'm running RC2 on Windows 10 64bit and it appears to be working correctly.
< PRab>
Hm... Did something in RC2 change about minimizing/closing?
< PRab>
I think something must have. Before when I clicked the X, it would go into the notification tray. Now it just goes into the taskbar.
< PRab>
I just tried a bunch of the combinations in options->Windows and can't figure out how to make it do the old behavior any more.
< luke-jr>
has some very misleading/confusing language about segwit
< MarcoFalke>
But the minimize/close fix is menitioned
< MarcoFalke>
I think that is what PRab was looking for
< PRab>
Checking it out.
< achow101>
PRab: did you check the "Minimize to tray instead of taskbar" option?
< PRab>
Your talking about - #8481 `d9f0d4e` Fix minimize and close bugs (adlawren), right?
< PRab>
achow101: Yes.
< PRab>
I like the old behavior where Minimize sends it to the taskbar and Close sends it to its notification icon.
< luke-jr>
I don't think that was ever intentional XD
< PRab>
Oh... It was nice that way.
< luke-jr>
could open a PR adding it as a well-defined behaviour option
< luke-jr>
eg Close behaviour: [Exit, Minimize, minimize-to-tray]
< achow101>
for me it has always gone into the tray regardless of which button I clicked
< PRab>
is it a bug or intended that if I have both "Minimize to tray..." and "Minimize on close" checked that when you restore it from the tray, it restores minimized?
< luke-jr>
achow101: indeed, must be platform-specific?
< achow101>
luke-jr: seen it on both ubuntu and windows
< luke-jr>
PRab: it should never appear minimized if you have minimize-to-tray
< PRab>
Then that sounds like a bug to me.
< PRab>
I have both checked. I click close and it goes to the tray. I double click the tray and it shows up in the taskbar minimized. Finally I click the taskbar and it restores the actual window.
< PRab>
I realize this is all fairly petty.
< achow101>
that's probably a bug. I just go used to it. that has been around for a while
< achow101>
*got
< luke-jr>
PRab: works fine here; what OS?
< PRab>
Windows 10
< michagogo>
22:19:47 <midnightmagic> :-/ What the hell. Why would my GnuPG key require a matching email in order to show as verified in github.
< michagogo>
Yeah, annoying to me too
< michagogo>
At least they let you just put yourusername@users.noreply.github.com on the key and it works