< GitHub39>
[bitcoin] theuni closed pull request #6526: Move blocksize and related parameters to consensusparams (master...blocksize-consensus) https://github.com/bitcoin/bitcoin/pull/6526
< wumpus>
cfields_: strange - I had no problems with gitan
< wumpus>
cfields_: maybe pre-7283 caches cause trouble?
< wumpus>
cfields_: yes, I think that's the problem. 7283 sets faketime for the dependencies to a date in 2000, instead of 2006
< cfields_>
wumpus: could be. I didn't look into it at the time, I just nuked the cache and the next build succeeded
< wumpus>
right
< wumpus>
so: if during gitian build you get errors about timestamps, try removing your caches
< wumpus>
if we have to revert 7283 I'd say don't merge it again, it's just not worth it
< cfields_>
wumpus: iirc the issue was that timestamps were in the future. So I assumed that it had something to do with committing a change on my machine and quickly building it inside gitian, where the current time may be slightly behind the committed time
< cfields_>
cory@cory-i7:~/dev/bitcoin(arm-bins)$ date
< cfields_>
Fri Jun 10 10:52:33 EDT 2016
< cfields_>
ubuntu@ubuntu:~$ date
< cfields_>
Fri Jun 10 14:46:03 UTC 2016
< cfields_>
^^ my system clock is indeed apparently skewed. so building a commit within ~6min could've caused me issues i think?
< cfields_>
oh, and those timezones are confusing too :)
< sipa>
our modified txsize calculation is being abused by huge cheap transactions with tons of inputs
< sipa>
i
< wumpus>
ugh
< sipa>
i'm unsure whether this is intended behaviour
< sipa>
it's clearly cleaning up lots of utxos
< wumpus>
large transactions with lots of inputs have always been quite popular
< sipa>
it's certainly suboptimal for miners
< wumpus>
but it getting away with so little fee is curious
< sipa>
well in modified txsize, inputs are free
< sipa>
(unless they have a scriptSig of over 110 bytes)
< warren>
I've always felt that costs should be imposed during creation of each UTXO, but it's too late to change that without upsetting people...
< sipa>
gmaxwell: ^
< wumpus>
having inputs entirely free is a curious decision, although it works to clean up utxos I guess
< morcos>
sipa: i'm not sure what the concern is exactly
< morcos>
modified tx size is only used for priority
< morcos>
these things are still booted from a limited mempool by feerate based on actual tx size
< sipa>
ah, i see
< morcos>
i'm guessing they are just getting in via the free tx rate limiting
< sipa>
morcos: thanks for clearing that up, i forgot it didn't apply everywhere
< gmaxwell>
why pinging me, the modified txsize stuff was only ever used for priority.
< sipa>
ok, false alarm :)
< sipa>
it also explains why they aren't confirming
< gmaxwell>
sipa: thanks for the change to outpoint, thats indeed much better. Any thoughts on the recursive orphan issue? I was thinking of just adding the insertion time to the maporphan object and just deleting old orphans from time to time... which is probably an independantly good thing to do.
< sipa>
gmaxwell: i'd go further and make an encapsulated OrphanMap object that just has 'add','delete', 'deleterecursive'
< sipa>
but trying to limit changes now
< gmaxwell>
kind of an annoying thing about just deleting recursively, ... say the orphan was included in a block instead of conflicted, in that case the deletion should not be recursive.
< sipa>
yes, that's why you'd also have a non-recursive delete
< sipa>
it's very similar to the mempool, actually...