< jonasschnelli>
Is it even required to fully catch up the chain?
< jonasschnelli>
(still ~40weeks behing)
< jonasschnelli>
*behind
< wumpus>
jonasschnelli: a sudden VM shutdown is somewhat realistic yes
< jonasschnelli>
okay.. will try as soon as i have access to that machine.
< wumpus>
you don't need to catch up with the chain - it does make sense to wait for the dbcache to be flushed a few times, but it's easy enough to reproduce around ~200000
< wumpus>
(supposing you stick to default dbcache number and don't set it to 4GB so that nothing ever gets flushed)
< jonasschnelli>
wumpus: I'm using default values... just double-clicked bitcoin-qt.exe
< GitHub158>
bitcoin/master caa3d42 Luke Dashjr: Bugfix: RPC: blockchain: Display correct defaults in help for verifychain method
< GitHub158>
bitcoin/master 420a82f Luke Dashjr: Bugfix: Describe dblogsize option correctly (it refers to the wallet database, not memory pool)
< GitHub158>
bitcoin/master 5f9260f Luke Dashjr: Bugfix: If genproclimit is omitted to RPC setgenerate, don't change it; also show correct default in getmininginfo
< GitHub126>
[bitcoin] laanwj closed pull request #6905: Use constants and minor fixes by luke-jr (master...lukejr-constants-no-mergeConf) https://github.com/bitcoin/bitcoin/pull/6905
< GitHub120>
[bitcoin] laanwj opened pull request #6938: build: If both Qt4 and Qt5 are installed, use Qt5 (master...2015_11_prefer_qt5) https://github.com/bitcoin/bitcoin/pull/6938
< GitHub145>
bitcoin/master dbacc69 Wladimir J. van der Laan: build: If both Qt4 and Qt5 are installed, use Qt5...
< GitHub145>
bitcoin/master 193f7b5 Wladimir J. van der Laan: Merge pull request #6938...
< GitHub40>
[bitcoin] laanwj closed pull request #6938: build: If both Qt4 and Qt5 are installed, use Qt5 (master...2015_11_prefer_qt5) https://github.com/bitcoin/bitcoin/pull/6938
< wangchun>
We've lately got lots of 20000-sigop blocks, it seems someone is flooding the network with 144-sigop and 225-sigop transactions
< petertodd>
wangchun: link to such a tx? luke-jr had some code to filter that stuff out
< gmaxwell>
Was there any argument against my proposal for making the effective fee rate based on max(size, sigops/20k*max_block_size) instead of size?
< gmaxwell>
for ordinary txn there is no change.
< gmaxwell>
petertodd: do you see any problem with that approach?
< petertodd>
gmaxwell: none, and luke-jr's mining branch does that already IIRc
< Luke-Jr>
mine just rejects transactions that don't have a reasonable sigop-to-size ratio
< Luke-Jr>
I think that is better than adjusting fee, because absurd sigop-to-size ratios have no legitimate use case.
< gmaxwell>
Luke-Jr: what I suggest just avoids having to decide whats absurd.
< Luke-Jr>
that may make it worse, since the cost for an absurd one can't be much higher than the cost for a barely-reasonable one :/
< mcelrath>
I don't think it's up to us to decide what is a legitimate use case. If they're paying a reasonable fee, why reject it?
< Luke-Jr>
mcelrath: fees are not entitlement
< Luke-Jr>
mcelrath: besides, it's very objective in this case
< Luke-Jr>
signatures and keys *must* be a certain size. so if the ratio isn't met, there's no possibility of a real signature verification
< gmaxwell>
it's true, less than ~73 bytes per sigop is clearly an attack.
< gmaxwell>
except the inaccurate accounting nonsense.
< gmaxwell>
:(
< gmaxwell>
Luke-Jr: so I think the inaccurate accounting nonsense breaks your thinking.
< Luke-Jr>
?
< mcelrath>
I decoded one, it's a giant pile (500) of $0.06 (or so) payments to a lot of P2PKH addresses. Not sure I'd call that an attack...
< Luke-Jr>
mcelrath: what makes you assume it fails the sigop ratio limit?
< gmaxwell>
Luke-Jr: what ratio test are you using?
< gmaxwell>
if you're using under ~20 bytes per sigop you're going to deny some p2pkh output heavy txn..
< gmaxwell>
and checkmultsig output heavy is really hard to not exclude with a static limit.
< gmaxwell>
because it counts as 20 even if s just a 1 of 1
< Luke-Jr>
it's configurable
< Luke-Jr>
and apparently defaults to unlimited (facepalm)
< gmaxwell>
in any case, what I suggest is just superior, because it changes to prioritization to "fee per percentage of the block the transaction is taking up, in the most limiting direction"
< gmaxwell>
like the postal service using the MAX of the dimensions of a package as a limit.
< mcelrath>
FWIW I like gmaxwell's suggestion.
< Luke-Jr>
in any case, this is a miner policy thing, and both should be easy for miners to do
< Luke-Jr>
deciding policy should not be a development discussion
< jtimon>
gmaxwell: re max(size, sigops/20k*max_block_size) nothing against, just that one thinks about putting more things in that formula (ie utxo_size_delta(tx) to encourage a more efficient usage of the utxo space)
< jtimon>
I mean, being policy, we don't have to have the perfect formula from the start
< jtimon>
eventually, if we like a tx cost function a lot, we can make it consensus
< davec>
I brought it up over in bitcoin-dev, but I'll put it here too for visibility. As of block 583930 on testnet, the CLTV soft fork is active although there is a lot of hash power still mining under the pre-CLTV rules.
< davec>
That means once it's released and everybody switches over testnet is going to have a huge reorg
< * helo>
grabs popcorn and spins up a node
< belcher>
i seem to recall testnet gets reorg'd a lot anyway
< davec>
True, but unless I'm mistaken I think the release is planned for Feb
< davec>
that will be months worth of blocks the CLTV side wil have to catch up with, etc
< davec>
Might be worth considering adding a minimum timestamp to the activation rules
< davec>
I had a typo in the block height - it's 582930
< gmaxwell>
davec: yea, mentioned here previously.
< gmaxwell>
davec: you're incorrect about your belief
< gmaxwell>
the release was planned for a couple days ago, I expect it will be next week.
< davec>
oh good to know about the release, so it won't be too bad then
< gmaxwell>
davec: yup! it's obnoxious though.
< gmaxwell>
though there is deciesively more hashpower on the CLTV side now at least.
< gmaxwell>
jtimon: that formula has nothing to do with the blocksize limit.
< davec>
I was also planning a release for next week with the CLTV rules, so that will line up well with Core
< gmaxwell>
the schedue was "end of october" and it's all backported but we're shepearding a couple other fixes for our releases.
< wumpus>
we could do a release now if that's necessary
< gmaxwell>
I don't currently think we need to rush that fast.
< davec>
Yeah, a few days won't matter. For some reason I thought the next release was Feb and that could've been really nasty.
< davec>
(as far as potential for a months long reorg)
< gmaxwell>
davec: in any case, there are pools mining on master so...
< wumpus>
the next major release is (probably) feb
< gmaxwell>
But we do not couple soft-forks to bitcoin core major releases.
< gmaxwell>
(which is why CLTV is in the prior branches already)