< dcousens>
Hmph, I just got a bunch of RPC server socket timeouts over 1.5 days old lol
< dcousens>
socket sending timeout: 85865s
< dcousens>
Maybe under 1.5 days, but over 1 day. Anyway, entering a line feed to STDIN unlocked the file descriptor? Suddenly got "socket send error Bad file descriptor (9)"
< dcousens>
And now my node has resumed catching up on the last day of missed blocks
< dcousens>
Any ideas? Wondering where I should start with debugging this
< dcousens>
(obviously an RPC call didn't give up CS_MAIN until the socket closed?)
< gijensen>
Shorter timeouts? What was the last RPC call you made?
< wangchun>
BlueMatt: ping
< BlueMatt>
wangchun: yea, I mean I definitely understand what you're proposing, but I dont believe that any such soft fork would ever occur
< wangchun>
so if you merge a patch that remove the block size limit completely NOW, but this patch does not take into effect until 2017-01-01
< BlueMatt>
once its in there, the political pressure to not remove it is too strong
< BlueMatt>
and, what do you set the limit to?
< wangchun>
And time now is 2016-09-30, we have a consensus to upgrade to 2MB, that is fine, merge another patch for 2MB,
< BlueMatt>
the political pressure to set the limit to something like 10mb at that time from people like coinbase would be huge...and 10mb would result in 0 fees for a long time to come
< wangchun>
this new patch is soft fork for those running 0.12+, only hard fork for those running 0.11 or lower
< wangchun>
and if no consensus on 2016-09-30, we can just remove the earlier patch, that nothing happens for those running 0.11 or lower, and it is a soft fork for those running 0.12+
< BlueMatt>
suresure, but how do we pick the number in 2016-09?
< wangchun>
this buys lots of time for waiting for the consensus
< BlueMatt>
like, the selection of the number would fall to miners
< BlueMatt>
how would miners pick the block size at that point?
< wangchun>
three months buffer for a soft fork is enough
< wangchun>
but for hard fork, we need probably a year
< wangchun>
that's how these numbers are chosen
< BlueMatt>
I understand that part, sure
< BlueMatt>
but how will *you* pick the block size come 2016-09
< BlueMatt>
and how will you, and the other miners agree on something in 2016-09?
< BlueMatt>
otherwise we end up with an infinite blocksize and bitcoin blows up :/
< wangchun>
any block size below 33.5MB is soft fork to those have upgraded
< BlueMatt>
33M will clearly break bitcoin in many way
< BlueMatt>
s
< BlueMatt>
and what if we cant get 51% to agree to a number?
< BlueMatt>
then we end up with 33M and we have no fees and massive blocks :(
< wangchun>
just change it back to 1MB
< BlueMatt>
but there is no "just change it"
< BlueMatt>
it has to be a soft fork, so miners have to agree to do it
< wangchun>
it is soft fork for those upgraded
< BlueMatt>
but miners have to agree
< wangchun>
yes, it is
< kanzure>
no way to change back
< BlueMatt>
yes, it is a soft fork
< BlueMatt>
but miners have to agree to do a soft fork
< wangchun>
change it back is soft fork for those have upgraded, and it is no fork for those havn't.
< wangchun>
OK, I explain it again...
< BlueMatt>
nono, I understand
< BlueMatt>
it is a soft fork for those who have upgraded, I agree
< wangchun>
We schedule a "virtual" hard fork NOW, but only active it one year into the future
< dcousens>
gijensen: sendrawtx
< BlueMatt>
but my point is that a soft fork is not an upgrade by users, it is an upgrade by miners...what we're doing is setting the blocksize to 32M in 2017 if miners do nothing. Miners can soft fork it back down to something else before 2017, but they have to agree
< wangchun>
after 9 months, if we have a detailed hard fork specs ready by then, go ahead,
< warren>
wangchun: You have certainty that the bandwidth situation will be better a year from now?
< wangchun>
otherwise change it back to what it was
< kanzure>
wangchun: there is no way to ensure agreement about reverting to 1 MB in the event of catastrophic failure...... bitcoin miners will still continue to mine, even if 32 MB breaks the network.
< kanzure>
wangchun: so they have no reason to agree to activate the soft-fork to "change it back".....
< wangchun>
The hard fork is just an option for the future
< kanzure>
even if everything is broken, maybe they will be OK with this
< wangchun>
Who are "they"?
< kanzure>
miners.
< BlueMatt>
wangchun: once its in the code it is no longer an option. it is an option for miners to soft-fork to decrease it again or set it to 1M, but if miners do not, then it is not an option
< kanzure>
wangchun: bluematt's concern is the following scenario: (1) hard-fork block size increase, (2) the bitcoin network is broken, (3) miners disagree with #2, (4) miners do NOT activate soft-fork to "change it back".
< wangchun>
OK, merge 2MB now but not activate it until 2017-01-01
< jl2012>
wangchun, would you please elaborate you rationale of completing removing limit?
< warren>
wangchun: Keep in mind that those miners who want to agree to a soft-fork might be at a significant orphan disadvantage to others who have greater connectivity. It could be dangerous to make any assumptions about what the network and mining power distribution will look like in the future.
< wangchun>
completely remove the limit is better, as it gives an option for any proposals
< wangchun>
not just 2MB
< BlueMatt>
jl2012: the rationale is that we know a hard fork needs at least a year to be deployed, so his proposal is to start it now
< BlueMatt>
jl2012: by removing the limit, +/-
< BlueMatt>
jl2012: and then soft fork it back down
< jl2012>
but not completely removing
< BlueMatt>
jl2012: well, remove up to the network message size limit, ie ~32M
< jl2012>
that's basically completely remove
< BlueMatt>
yes
< wangchun>
sure, when the activate date getting close, add another patch soft fork it back to the consensus we have by then
< jl2012>
if the consensus is X MB is tolerable, than X MB, not >X MB
< jl2012>
wangchun, what if miners do not do to SF?
< wangchun>
It will be no worse than the current debate we have.
< jl2012>
much worse
< kanzure>
the network will be broken, though. much worse.
< BlueMatt>
wangchun: my big concern is we have no idea /who/ "the miners" will be in a year...bitfury may be 50% by themselves...
< kanzure>
the scenario was (2) the network is broken, and (3) miners disagree.
< jl2012>
yes, don't forget their new chips
< BlueMatt>
or (2) the network is broken and (3) bitfury disagrees, since they have better bandwidth than other people
< wangchun>
How about merge 2MB now schedule it one year later?
< kanzure>
that's true, bitfury has good bandwidth
< jl2012>
"2MB now but not activate it until 2017-01-01" is basically another BIP102. Personally I don't think it is bad, if the date is far enough
< BlueMatt>
(if anyone from bitfury is reading this, I dont mean to pick on y'all...just needed to pick someone...I mean ffs in a year /I/ might be 50% of the network...)
< gijensen>
dcousens, I have no idea where you'd start. I thought the timeout for RPC was limited to "timeout" too, so I didn't think that could happen.
< jl2012>
just my 2 cents
< morcos>
wangchun: I also like the idea. I think we have spent too long trying to solve a technical problem when we really have a social problem.
< kanzure>
agreed with morcos.
< BlueMatt>
wangchun: you mean 4mb in a year
< BlueMatt>
we're already doing 2mb...scheduling 2mb now means 4mb
< wangchun>
Many people do not want hard fork just because it is risky,
< jl2012>
BlueMatt, no need to mix segwit in this discussion
< wangchun>
then we give them enough time to prepare the fork
< wangchun>
that is the point
< jl2012>
segwit can adapt a HF
< warren>
wangchun: Say for example, the network breaks in some way with huge blocks, but miners with super fast centralized servers and very fast connectivity between each other decide they like it this way. Miners with less bandwidth would have less ability to influence a soft-fork vote since they are orphaned out often due to the huge blocks. It could be quite dangerous to make any assumptions about what the network and mining power distribution
< warren>
will look like in the future.
< BlueMatt>
jl2012: hmm? no, its rather important? if we just want 2mb, no need to do that in a hf (if people are worried about a hf, lets increase the nonce space instead)
< jl2012>
BIP141 will allow only 1.75MB with normal use
< jl2012>
and assuming 100% people use it
< wangchun>
warren: just 2mb or 4mb won't "break the network"
< BlueMatt>
as for a 2.5/3ish mb hf, if I knew people would work on better relay mechanisms, I would be fine with that, mostly...but so far I'm +/- the only person at all who has worked on better relay
< BlueMatt>
no, sorry, thats a lie, wangchun has as well
< wangchun>
the problem is those nodes left behind a hard fork will be at risk
< wangchun>
that is the issue this is trying to solve
< BlueMatt>
but I'm not aware of anyone except for wangchun and I who have spent any serious time implementing better relay
< BlueMatt>
0.12 was a big step, but we need better relay, not just validation time for another step
< Luke-Jr>
+1 for more nonce space; sadly, I'm sure Classic would reject that too :\
< jl2012>
wangchun, yes, that's the biggest risk of hardfork. That's why the flag date has to be far enough
< * Luke-Jr>
might as well throw it out there just in case
< wangchun>
but now we do not have the consensus, we need something to buy us some time. That it is.
< jl2012>
people are running legacy clients. E.g. I'm still running 0.9.5 for other applications to work
< BlueMatt>
wangchun: in any case, I think there is some agreement on something around 2mb...if people really dont think the 1.75 of segwit is enough, forming consensus around a 2mb hf just to bump up segwith by .25mb is probably not hard, and could be done rather quickly, I think
< BlueMatt>
wangchun: given 0.12 is adopted quickly, block process times and p2p relay should be improved enough that 2mb wont hurt decentralization incentives
< wangchun>
Then we need to get the code merged as soon as possible
< wangchun>
Activation date is not that important
< wangchun>
but it should be far enough
< * BlueMatt>
will complain loudly if its any less than a year from when the code is released
< jl2012>
wangchun, I think consensus has been reached that 2MB is tolerable. The only remaining question is how to archive 2MB
< BlueMatt>
thats probably still really tight, but I'd say at least a year
< wangchun>
BlueMatt: I agree
< wangchun>
Then we are talking something not happen until 2017
< gijensen>
dcousens, ignore that. "timeout" doesn't effect RPC. I'm curious if it lasted longer than the specified RPC timeout though (set by bundling a timeout parameter via RPC or -rpcclienttimeout on bitcoin-cli)
< wangchun>
Until it is too late, we need to do something
< BlueMatt>
warren: how about we go jointly propose a hard fork that activates in like late feb 2017 that also includes more nonce space (so that people cant argue its too trivial a change for a hard fork) :)
< BlueMatt>
wangchun:
< BlueMatt>
is who I meant to tag
< wangchun>
good to me
< BlueMatt>
maybe early march, but whatever, first half of 2017
< Luke-Jr>
BlueMatt: jtoomim is already opposing more nonce space though, implying all sorts of nonsense accusations
< jtoomim>
changing the headers probably breaks compatibility with SPV wallets.
< BlueMatt>
jtoomim: it doesnt change the headers in any meaningful way
< jtoomim>
hmm, let me look through the irc chat first
< jtoomim>
i got linked into this discussion without context
< jtoomim>
and i've been running into a lot of trolls trying to add bugs to Classic
< Luke-Jr>
jtoomim: changing anything should break compatibility with SPV wallets; that it doesn't just goes to show the "SPV" wallets out there are buggy
< jtoomim>
so i'm in super-pessimistic mode rightnow
< Luke-Jr>
jtoomim: if you mean me, it's in your head only
< jtoomim>
no, not you luke
< jtoomim>
mostly james
< jtoomim>
by the way, i wanted to apologize to you
< jtoomim>
i think i accused you of being a troll, but in retrospect, you were innocent
< jtoomim>
changing the PoW function is a reasonable thing in this context, just not for classic
< jtoomim>
it's a reasonable thing for the minority branch to do
< warren>
jtoomim: It's quite dangerous to do a HF to fullnodes that is seen as a SF to SPV?
< jtoomim>
although i think it would be better to use AuxPoW and merge-mine
< jtoomim>
is that a question or a statement!
< jtoomim>
s/!/./
< warren>
Wondering your opinion on that.
< jtoomim>
i don't think it's quite dangerous, no, but i do think we should be careful during testing to make sure it goes as expected
< warren>
Err ... I mean the SPV clients can't tell the difference, and that's dangerous.
< jtoomim>
well, only if you think that the fork is going to be contentious
< Luke-Jr>
warren: it'd be a 200k proof, but SPV clients *could* tell if they did fraud proofs
< jtoomim>
but SPV wallets can either wait it out, or import their keys, or watch the block versions or something
< jtoomim>
i've been thinking about including an increase to the coinbase scriptsig size in the HF
< jtoomim>
i don't think that would affect SPV wallets
< jtoomim>
but i really want to keep the change count as low as is safe for this HF
< jtoomim>
which means mostly just tx validation cost limits (bytes hashed), versionbits logic, and the blocksize limit itself
< Luke-Jr>
jtoomim: how about expanding versionbits to use all 32 bits?
< Luke-Jr>
jtoomim: right now it's like 30 bits to avoid hardforking only
< randy-waterhouse>
can't see how this discussion should be in bitcoin-core-dev ... take it too bitcoin-dev or bitcoin-classic?
< Luke-Jr>
randy-waterhouse: fair
< jtoomim>
luke-jr, it would break compatibiltiy with SPV.
< jtoomim>
unless no SPV wallets even look at the nVersion field
< jtoomim>
which i doubt
< jtoomim>
ok
< warren>
BlueMatt: wangchun: Just throwing out ideas here ... it's certainly positive to add reasons to make a hardfork more worthwhile than 1.75MB -> 2MB like adding extra nonce space. I think we could do even better than that, as we have had a hardfork wishlist for years and this gives us an opportunity to fix more than one problem. I wonder if people would be OK with agreeing on the current roadmap to get us to an effective 1.75MB+ in a few mon
< warren>
ths, and also set a deadline for HF wishlist item implementation (BIPs and code) for a scheduled hardfork in early 2017. Whatever isn't fully approved in peer tech review before that deadline is cut. Everyone could become far more productive if we agreed to end the drama and work on real improvements together in this manner?
< Lightsword>
BlueMatt, btw looks like ckpool now has what is essentially an internal relay network for multi-node regional deployments, but only works for trusted stratum server nodes
< BlueMatt>
Lightsword: yea, if we all spv mine it's fine! :/
< Lightsword>
BlueMatt, yeah….it’s different from the HO mining at least since it ships around ckpool’s workinfos between nodes or something like that
< BlueMatt>
suresure, if its your own nodes I get it
< GitHub67>
[bitcoin] MarcoFalke opened pull request #7381: [walletdb] Fix syntax error in key parser (master...Mf1601-walletdbKeyparserFix) https://github.com/bitcoin/bitcoin/pull/7381
< MarcoFalke>
At least I know where I lost all the coins to...
< murch>
Good morning. I started running 0.12rc01 recently. Today my node was not running, it was reporting a corrupted database. debug.log only appears to have the last hour, is there anything else useful that I can provide for more information?
< GitHub24>
[bitcoin] laanwj closed pull request #6700: bloom_tests: Do not depend on specific serialisations (master...bloom_tests_not_ser) https://github.com/bitcoin/bitcoin/pull/6700
< wumpus>
jonasschnelli, it's one of the next pulls I plan on looking at
< jonasschnelli>
Nice. Thanks!
< wumpus>
it's a one step towards getting rid of #ifdef DISABLE_WALLETs in bitcoin_server code, which currently causes a circular dependency between the server and the wallet libraries
< jonasschnelli>
wumpus: Yes. I have some changes that fully removes #ifdef DISABLE_WALLET
< jonasschnelli>
So.. I'm slowly picking out parts, carefully rewrite them and submit them as sep. PR.
< jonasschnelli>
Otherwise the review burden is to heigh.
< Yoghur114>
is there a reason things like 'free transaction rejected by rate limiter', 'inputs already spent', 'nonstandard transaction: dust', etc. log messages are logged as an error?
< jonasschnelli>
Yoghur114: Agree. This is not ideal.
< jonasschnelli>
Should be a INFO:
< jonasschnelli>
Feel free to change it. :)
< wumpus>
Yoghur114: that should be no longer the case with 0.12
< wumpus>
by default, validation errors for incoming P2P transactions aren't even logged anymore, unless -debug=mempoolrej is set, in which case you get a debug message not an ERROR
< morcos>
This seems suspiciously like something I might have introduce with messing around with ModifyNewCoins and BatchWrite in PR's 5967 and 6932
< morcos>
But I couldn't see antyhing in a quick scan. For some reason I added a check to make sure hashBlock wasn't NULL in the coins_tests.cpp No idea why now. But the test passes without that.