< warren>
KVM ... qemu-system-x86_64 gets stuck with 100% CPU usage, target.log is blank
< sipa>
on what hardware
< sipa>
?
< sipa>
in particular: do you have hardware acceleration?
< sipa>
if running inside a VM, it may be resorting to software emulation
< warren>
model name : Intel(R) Core(TM) i5-4690S CPU @ 3.20GHz
< warren>
used KVM on this hardware before, I'll figure it out
< jonasschnelli>
prioritisetransaction <txid> 0 100000000 should lead to (always) include the transaction in the next getblocktemplate call, right?
< gmaxwell>
no, due to caching.
< gmaxwell>
if the block doesn't change IIRC we'll cache the CNB result for up to 30 seconds.
< jonasschnelli>
Is there a way to drain the cache?
< gmaxwell>
mine a new block.
< gmaxwell>
don't call getblocktemplate for (IIRC) 30 seconds before.
< jonasschnelli>
okay... thanks gmaxwell!
< gmaxwell>
Sorry I don't have a more useful suggestion!
< jonasschnelli>
Well... that's already useful. I know now why.
< Lauda>
ping wumpus
< gmaxwell>
what is the gpg undocumented option to restrict recv-key to only fetch a key it already knows?
< gmaxwell>
--refresh-keys ah ha
< gmaxwell>
Lauda: thanks
< bitcoin-git>
[bitcoin] jonasschnelli opened pull request #9947: Add true/false return value to prioritisetransaction (master...2017/03/ptx) https://github.com/bitcoin/bitcoin/pull/9947
< Lauda>
You're welcome.
< jonasschnelli>
Should we allow to add a fee delta on txn's that are not in the mempool, ... right now we do. I hink we can't change that behavior..
< dcousens_>
Yeah, I personally use the current behaviour of "CAmount &delta = mapDeltas[hash]; delta += nFeeDelta;" to prioritize transactions before they are in the mempool
< gmaxwell>
jonasschnelli: it is an intentional feature that took extra effort to support. Without it, priority is much less effective.
< gmaxwell>
since txn you want to prioritize might not otherwise make it into your mempool at all.
< jonasschnelli>
Yes. I see... maybe the return value then should be wether the transaction was already in the mempool or now.
< jonasschnelli>
*not
< dcousens_>
ooi, in the above statement, "Amount &delta = mapDeltas[hash]; delta += nFeeDelta;", mapDeltas[hash] if unitialized, does it get default constructed to 0 somehow?
< jonasschnelli>
Can anyone help me understand why CreateTransaction (CDummySigner VerifyScript seems to be the problem) if I want to use watch-only addresses (no pubkeys available).
< jonasschnelli>
If the address is P2PKH, it should be capable to calculate the fee, right...
< bitcoin-git>
bitcoin/master 6c1fb73 John Newbery: Improve logging in bctest.py if there is a formatting mismatch
< bitcoin-git>
bitcoin/master ac23a7c MarcoFalke: Merge #9945: Improve logging in bctest.py if there is a formatting mismatch...
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #9945: Improve logging in bctest.py if there is a formatting mismatch (master...improve_bctest_logging) https://github.com/bitcoin/bitcoin/pull/9945
< bitcoin-git>
[bitcoin] practicalswift opened pull request #9949: [bench] Avoid function call arguments which are pointers to uninitialized values (master...avoid-pointers-to-unitialized-values-in-function-calls) https://github.com/bitcoin/bitcoin/pull/9949
< arubi>
oh, that's where it's pointing, thought it should point to the tag?
< wumpus>
that's on purpose. It points at the historical release notes in master, that's the most recent version of the release notes for a version
< arubi>
understood
< wumpus>
the one in the tag may be older, e.g. sometimes there are post-mortem fixes, and it can no longer be changed
< arubi>
yea, now I figure the one it points to is kept up to date with the release
< wumpus>
normally release notes aren't edited after the release, but it sometimes happens if there's something very wrong
< arubi>
I see where I got confused then, I thought for some reason the link would point to the 0.14 branch, and not the 0.14.0 tag, so at some point when 0.14.1 is released then the link points to the same place, but really no reason for it to work like that :)
< bitcoin-git>
[bitcoin] TheBlueMatt opened pull request #9953: Fix shutdown hang with >= 8 -addnodes set (master...2017-03-exit-with-addnode) https://github.com/bitcoin/bitcoin/pull/9953
< CubicEarth>
What would be the computational bottle neck if validation was parallelized to the point of being able to run on a GPU? During chain-sync for example.
< arubi>
I think if you could get signature validation on a GPU that would be cool CubicEarth :)
< gmaxwell>
CubicEarth: I would be mildly surprised if it were possible to make it faster that way.
< arubi>
:(
< arubi>
oh this is -core-dev, sorry
< wumpus>
GPUs are fking unstable on most user's computers
< gmaxwell>
big lesson from mining there, remarkable how bad it was ... I hope things have improved?
< wumpus>
utilizing the CPU and GPU during verification by default would be a good way to cause fires and such :)
< wumpus>
doesn't seem so, especially on laptops it's bad, even if it doesn't overheat immediately there's usually crash issues with ancient drivers, strange edge cases, and so on. Unless you have to deal with GPUs (e.g. game develpoment) I"d suggest staying far from using them for anything to be used by end-users. For research in well-controlled settings/hardware they're ok.
< wumpus>
at least you can troubleshoot on-site then...
< BlueMatt>
gmaxwell: i had to replace the gpu in my workstation because a reasonably-high-end consumer gpu was unstable randomly on a machine that literally only ever displays terminals
< BlueMatt>
they're fucking terrible
< BlueMatt>
the workstation-class ones seem to be stable, but its clear literally no one ever bothered to test the drivers against them
< CubicEarth>
that makes sense for laptops... I was imaging using a typical 4-card mining rig
< gmaxwell>
What was thefeeling around eliminating the requirement for gbtresults on segwit activation? IMO we shouldn't have behavior changes like that triggered by network events, if it is at all possible to avoid. And also changing the version returned to include segwit, even if the flag isn't set-- we're enforce the rules, which is what matters.
< gmaxwell>
and there are plenty of miners who will already process transactions.
< sdaftuar>
gmaxwell: i'm on board, i was just thinking today abotu coding that up and suggesting it as a backport to the 0.14 branch
< gmaxwell>
yes, well the addnode bug matt is fixing will call for a 0.14.1 at some point. so I was just thinking it would be good to get that done and in it too.
< sdaftuar>
agreed
< gmaxwell>
I'm sorry guys. Didn't make it 24 hours after release before finding something that calls for a 0.14.1. :(
< BlueMatt>
gmaxwell: yea sucks, but oh well
< warren>
wumpus: Recently a friend asked what I thought about some startup that aims to accelerate SATA controllers with "low cost desktop GPU's" ...
< gmaxwell>
I'm sure you must have misheard something.
< gmaxwell>
for example, maybe they intend to accelerate 200 disk raid with 10 disks of parity.
< TD-Linux>
warren, just wait until people ask you to solve all their problems with FPGAs
< warren>
gmaxwell: hand wavy "everything is possible" presentation including that and somehow blockchains. My first question was "Is this reliable?"
< sdaftuar>
gmaxwell: how important do you think it is that CreateNewBlock be fast, when invoked post-segwit activation by a miner that doesn't support it? in order to be fast, we'd have to cache extra information in the mempool, which i'm not eager to do unless really necessary
< sdaftuar>
(making it work at all, on the other hand, is not very hard)
< gmaxwell>
sdaftuar: I think it would be okay if it became slower in that case.
< gmaxwell>
my expectation is that we'd eventually go back to the current behavior in a later release. (basically: I think it's fine for a new release to change the interface, it's not so fine for network events to change the interface, if it can be avoided.)
< luke-jr>
BlueMatt: why remove virtual?
< BlueMatt>
luke-jr: because I was told you normally remove virtual if you're using override to indicate that you are the implementor of an interface and not something which will be subclassed and overriden
< BlueMatt>
I dont care either way, talk to ryanofsky
< ryanofsky>
i don't care much either. i suggested it mainly to be consistent with our other code which uses override. and fwiw, google style guide says "For clarity, use exactly one of override, final, or virtual when declaring an override."
< luke-jr>
I was under the impression *only* virtuals could have an override, and unless a method is virtual, overrides would de facto get ignored
< BlueMatt>
no, you have to be implementing a virtual to get override
< ryanofsky>
it's a compile error to write override on a method that's not virtual, so writing both virtual and override is redundant
< BlueMatt>
but dont, yourself, have to be virtual
< luke-jr>
oh, I see, these are on subclasses
< paveljanik>
BlueMatt, should I make torControlThread static as well (one line below gBase in src/torcontrol.cpp)?
< BlueMatt>
paveljanik: anything that can be, probably should be
< BlueMatt>
i mean especially for such a generic name like "base", but I suppose why not
< paveljanik>
ok
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #9955: Don't require segwit in getblocktemplate for segwit signalling or mining (master...2017-03-mining-segwit-changes) https://github.com/bitcoin/bitcoin/pull/9955
< warren>
Is anyone using gitian with qemu-system-x86_64 (not LXC)? It seems that the base-trusty-amd64.qcow2 images generated by make-base-vm are currently unbootable. qemu-system-x86_64 gets stuck with 100% CPU usage on one core, very little memory use, nothing in logs but a localhost:16 VNC port shows it is stuck at trying to boot the disk image.
< luke-jr>
warren: I do, but my base VM is somewhat old
< achow101>
warren: I use qemu with gitian and haven't had any issues with make-base-vm
< warren>
I did as recently as last month, but using the latest gitian-builder's make-base-vm the new base-trusty-amd64.qcow2 I get no longer works with gbuild.
< warren>
achow101: how long ago did you make your base image?