1 2017-03-08 00:17:41 0|cfields|gitian builders: v0.14.0 detached sigs are pushed
2 2017-03-08 01:01:16 0|midnightmagic|cfields: \o thanks
3 2017-03-08 06:22:33 0|wumpus|all gitian signatures match this time, this is great
4 2017-03-08 06:25:15 0|wumpus|thanks cfields
5 2017-03-08 06:34:52 0|sipa|awesome!
6 2017-03-08 07:34:29 0|warren|anyone having problems with gitian where it gets stuck at "Checking if target is up" ?
7 2017-03-08 07:43:16 0|jonasschnelli|warren: what are you using LXC/KVM?
8 2017-03-08 07:43:36 0|jonasschnelli|warren: maybe check the gitian-builder/logs directory. Cat target.log / install.log
9 2017-03-08 07:46:20 0|warren|KVM ... qemu-system-x86_64 gets stuck with 100% CPU usage, target.log is blank
10 2017-03-08 08:25:01 0|sipa|on what hardware
11 2017-03-08 08:25:03 0|sipa|?
12 2017-03-08 08:31:03 0|sipa|in particular: do you have hardware acceleration?
13 2017-03-08 08:31:19 0|sipa|if running inside a VM, it may be resorting to software emulation
14 2017-03-08 08:45:31 0|warren|model name : Intel(R) Core(TM) i5-4690S CPU @ 3.20GHz
15 2017-03-08 08:45:51 0|warren|used KVM on this hardware before, I'll figure it out
16 2017-03-08 09:28:23 0|jonasschnelli|prioritisetransaction <txid> 0 100000000 should lead to (always) include the transaction in the next getblocktemplate call, right?
17 2017-03-08 09:30:00 0|gmaxwell|no, due to caching.
18 2017-03-08 09:30:22 0|gmaxwell|if the block doesn't change IIRC we'll cache the CNB result for up to 30 seconds.
19 2017-03-08 09:30:42 0|jonasschnelli|Is there a way to drain the cache?
20 2017-03-08 09:30:53 0|gmaxwell|mine a new block.
21 2017-03-08 09:31:12 0|gmaxwell|don't call getblocktemplate for (IIRC) 30 seconds before.
22 2017-03-08 09:31:54 0|jonasschnelli|okay... thanks gmaxwell!
23 2017-03-08 09:32:10 0|gmaxwell|Sorry I don't have a more useful suggestion!
24 2017-03-08 09:33:26 0|jonasschnelli|Well... that's already useful. I know now why.
25 2017-03-08 09:45:07 0|Lauda|ping wumpus
26 2017-03-08 09:48:11 0|gmaxwell|what is the gpg undocumented option to restrict recv-key to only fetch a key it already knows?
27 2017-03-08 09:55:09 0|gmaxwell|--refresh-keys ah ha
28 2017-03-08 09:55:13 0|gmaxwell|Lauda: thanks
29 2017-03-08 10:02:25 0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #9947: Add true/false return value to prioritisetransaction (06master...062017/03/ptx) 02https://github.com/bitcoin/bitcoin/pull/9947
30 2017-03-08 10:34:26 0|Lauda|You're welcome.
31 2017-03-08 10:58:52 0|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..
32 2017-03-08 10:59:37 0|dcousens_|Yeah, I personally use the current behaviour of "CAmount &delta = mapDeltas[hash]; delta += nFeeDelta;" to prioritize transactions before they are in the mempool
33 2017-03-08 11:00:41 0|gmaxwell|jonasschnelli: it is an intentional feature that took extra effort to support. Without it, priority is much less effective.
34 2017-03-08 11:01:06 0|gmaxwell|since txn you want to prioritize might not otherwise make it into your mempool at all.
35 2017-03-08 11:01:16 0|jonasschnelli|Yes. I see... maybe the return value then should be wether the transaction was already in the mempool or now.
36 2017-03-08 11:01:17 0|jonasschnelli|*not
37 2017-03-08 11:07:53 0|dcousens_|ooi, in the above statement, "Amount &delta = mapDeltas[hash]; delta += nFeeDelta;", mapDeltas[hash] if unitialized, does it get default constructed to 0 somehow?
38 2017-03-08 11:08:36 0|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).
39 2017-03-08 11:09:06 0|jonasschnelli|If the address is P2PKH, it should be capable to calculate the fee, right...
40 2017-03-08 11:09:16 0|jonasschnelli|Guess not possible for P2SH
41 2017-03-08 11:09:47 0|jonasschnelli|*[...] understand why CreateTransaction *fails*
42 2017-03-08 11:18:38 0|bitcoin-git|13bitcoin/06master 146c1fb73 15John Newbery: Improve logging in bctest.py if there is a formatting mismatch
43 2017-03-08 11:18:38 0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/47510ad3dd51...ac23a7c1f19b
44 2017-03-08 11:18:39 0|bitcoin-git|13bitcoin/06master 14ac23a7c 15MarcoFalke: Merge #9945: Improve logging in bctest.py if there is a formatting mismatch...
45 2017-03-08 11:18:59 0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9945: Improve logging in bctest.py if there is a formatting mismatch (06master...06improve_bctest_logging) 02https://github.com/bitcoin/bitcoin/pull/9945
46 2017-03-08 11:28:34 0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #9949: [bench] Avoid function call arguments which are pointers to uninitialized values (06master...06avoid-pointers-to-unitialized-values-in-function-calls) 02https://github.com/bitcoin/bitcoin/pull/9949
47 2017-03-08 11:59:13 0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9790: doc/release-notes: Various cleanups (060.14...060.14-relnotes) 02https://github.com/bitcoin/bitcoin/pull/9790
48 2017-03-08 12:42:27 0|NicolasDorier|jonasschnelli: you may encounter the same problem I stumbled upon while doing my watchonlyhd stuff
49 2017-03-08 12:42:32 0|NicolasDorier|take a look at https://github.com/bitcoin/bitcoin/pull/9728/files#diff-b2bb174788c7409b671c46ccc86034bdL1859
50 2017-03-08 12:43:29 0|NicolasDorier|basically, watchonly addresses are untrusted if not confirmed
51 2017-03-08 12:43:36 0|NicolasDorier|might be your problem
52 2017-03-08 12:46:22 0|jonasschnelli|NicolasDorier. Thanks... ill have a look
53 2017-03-08 12:46:44 0|NicolasDorier|jonasschnelli: this PR https://github.com/bitcoin/bitcoin/pull/9830 expose the istrusted flag, it might help you to debug
54 2017-03-08 13:18:07 0|bitcoin-git|13bitcoin/06master 14fdab309 15practicalswift: [trivial] Fix typos introduced in 7184e25c80aa8b1629a700bb7a7e290ad0bb2792
55 2017-03-08 13:18:07 0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ac23a7c1f19b...8bfa13b15b84
56 2017-03-08 13:18:08 0|bitcoin-git|13bitcoin/06master 148bfa13b 15MarcoFalke: Merge #9936: [trivial] Fix three typos introduced into walletdb.h in commit 7184e25...
57 2017-03-08 13:18:26 0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #9936: [trivial] Fix three typos introduced into walletdb.h in commit 7184e25 (06master...06fix-typos-introduced-in-commit-7184e25c) 02https://github.com/bitcoin/bitcoin/pull/9936
58 2017-03-08 14:48:08 0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #9951: Wallet database handling abstractions/simplifications (06master...062017_03_wallet_dbwrapper) 02https://github.com/bitcoin/bitcoin/pull/9951
59 2017-03-08 14:53:28 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9900: Ban "invalid messagestart" nodes (06master...06patch-2) 02https://github.com/bitcoin/bitcoin/pull/9900
60 2017-03-08 15:04:07 0|BlueMatt|wumpus: (or someone) should set v0.14.0 as a release on github (https://github.com/bitcoin/bitcoin/releases)
61 2017-03-08 15:05:48 0|wumpus|yes
62 2017-03-08 15:23:54 0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #9952: Add historical release notes for 0.14.0 (06master...062017_03_014_release_notes) 02https://github.com/bitcoin/bitcoin/pull/9952
63 2017-03-08 15:26:37 0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8bfa13b15b84...6996e066b538
64 2017-03-08 15:26:38 0|bitcoin-git|13bitcoin/06master 142de6930 15Wladimir J. van der Laan: Add historical release notes for 0.14.0
65 2017-03-08 15:26:39 0|bitcoin-git|13bitcoin/06master 146996e06 15Wladimir J. van der Laan: Merge #9952: Add historical release notes for 0.14.0...
66 2017-03-08 15:27:00 0|arubi|release notes link on github releases is wrong, points to master (which also 404s)
67 2017-03-08 15:27:02 0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9952: Add historical release notes for 0.14.0 (06master...062017_03_014_release_notes) 02https://github.com/bitcoin/bitcoin/pull/9952
68 2017-03-08 15:27:13 0|wumpus|arubi: should be fixed now
69 2017-03-08 15:27:18 0|wumpus|arubi: you checked too early
70 2017-03-08 15:27:20 0|arubi|ah yes
71 2017-03-08 15:27:34 0|arubi|well it still says master :)
72 2017-03-08 15:27:50 0|arubi|oh, that's where it's pointing, thought it should point to the tag?
73 2017-03-08 15:28:17 0|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
74 2017-03-08 15:28:33 0|arubi|understood
75 2017-03-08 15:29:02 0|wumpus|the one in the tag may be older, e.g. sometimes there are post-mortem fixes, and it can no longer be changed
76 2017-03-08 15:29:59 0|arubi|yea, now I figure the one it points to is kept up to date with the release
77 2017-03-08 15:48:40 0|wumpus|normally release notes aren't edited after the release, but it sometimes happens if there's something very wrong
78 2017-03-08 16:00:28 0|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 :)
79 2017-03-08 16:26:56 0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #9953: Fix shutdown hang with >= 8 -addnodes set (06master...062017-03-exit-with-addnode) 02https://github.com/bitcoin/bitcoin/pull/9953
80 2017-03-08 18:45:55 0|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.
81 2017-03-08 18:47:26 0|arubi|I think if you could get signature validation on a GPU that would be cool CubicEarth :)
82 2017-03-08 18:48:42 0|gmaxwell|CubicEarth: I would be mildly surprised if it were possible to make it faster that way.
83 2017-03-08 18:48:53 0|arubi|:(
84 2017-03-08 18:49:09 0|arubi|oh this is -core-dev, sorry
85 2017-03-08 18:52:28 0|wumpus|GPUs are fking unstable on most user's computers
86 2017-03-08 18:53:06 0|gmaxwell|big lesson from mining there, remarkable how bad it was ... I hope things have improved?
87 2017-03-08 18:53:11 0|wumpus|utilizing the CPU and GPU during verification by default would be a good way to cause fires and such :)
88 2017-03-08 18:54:47 0|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.
89 2017-03-08 18:56:14 0|wumpus|at least you can troubleshoot on-site then...
90 2017-03-08 19:02:30 0|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
91 2017-03-08 19:02:40 0|BlueMatt|they're fucking terrible
92 2017-03-08 19:03:28 0|BlueMatt|the workstation-class ones seem to be stable, but its clear literally no one ever bothered to test the drivers against them
93 2017-03-08 19:03:38 0|CubicEarth|that makes sense for laptops... I was imaging using a typical 4-card mining rig
94 2017-03-08 19:09:40 0|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.
95 2017-03-08 19:10:04 0|gmaxwell|and there are plenty of miners who will already process transactions.
96 2017-03-08 19:38:16 0|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
97 2017-03-08 19:39:04 0|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.
98 2017-03-08 19:39:09 0|sdaftuar|agreed
99 2017-03-08 19:39:33 0|gmaxwell|I'm sorry guys. Didn't make it 24 hours after release before finding something that calls for a 0.14.1. :(
100 2017-03-08 19:45:54 0|BlueMatt|gmaxwell: yea sucks, but oh well
101 2017-03-08 19:56:23 0|warren|wumpus: Recently a friend asked what I thought about some startup that aims to accelerate SATA controllers with "low cost desktop GPU's" ...
102 2017-03-08 19:58:56 0|gmaxwell|I'm sure you must have misheard something.
103 2017-03-08 19:59:37 0|gmaxwell|for example, maybe they intend to accelerate 200 disk raid with 10 disks of parity.
104 2017-03-08 20:01:31 0|TD-Linux|warren, just wait until people ask you to solve all their problems with FPGAs
105 2017-03-08 20:10:23 0|warren|gmaxwell: hand wavy "everything is possible" presentation including that and somehow blockchains. My first question was "Is this reliable?"
106 2017-03-08 20:11:31 0|BlueMatt|ok, whos' blocked getting review/merge?
107 2017-03-08 20:11:53 0|gribble|https://github.com/bitcoin/bitcoin/issues/9725 | CValidationInterface Cleanups by TheBlueMatt ÷ Pull Request #9725 ÷ bitcoin/bitcoin ÷ GitHub
108 2017-03-08 20:16:22 0|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
109 2017-03-08 20:17:03 0|sdaftuar|(making it work at all, on the other hand, is not very hard)
110 2017-03-08 20:24:24 0|gmaxwell|sdaftuar: I think it would be okay if it became slower in that case.
111 2017-03-08 20:25:50 0|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.)
112 2017-03-08 20:54:52 0|luke-jr|BlueMatt: why remove virtual?
113 2017-03-08 20:55:51 0|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
114 2017-03-08 20:56:01 0|BlueMatt|I dont care either way, talk to ryanofsky
115 2017-03-08 20:58:39 0|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."
116 2017-03-08 21:00:40 0|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
117 2017-03-08 21:02:05 0|BlueMatt|no, you have to be implementing a virtual to get override
118 2017-03-08 21:02:10 0|ryanofsky|it's a compile error to write override on a method that's not virtual, so writing both virtual and override is redundant
119 2017-03-08 21:02:11 0|BlueMatt|but dont, yourself, have to be virtual
120 2017-03-08 21:04:07 0|luke-jr|oh, I see, these are on subclasses
121 2017-03-08 21:10:59 0|paveljanik|BlueMatt, should I make torControlThread static as well (one line below gBase in src/torcontrol.cpp)?
122 2017-03-08 21:11:13 0|BlueMatt|paveljanik: anything that can be, probably should be
123 2017-03-08 21:11:23 0|BlueMatt|i mean especially for such a generic name like "base", but I suppose why not
124 2017-03-08 21:11:37 0|paveljanik|ok
125 2017-03-08 22:01:04 0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #9955: Don't require segwit in getblocktemplate for segwit signalling or mining (06master...062017-03-mining-segwit-changes) 02https://github.com/bitcoin/bitcoin/pull/9955
126 2017-03-08 23:04:07 0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #9956: Reorganise qa directory (06master...06reorganise_qa) 02https://github.com/bitcoin/bitcoin/pull/9956
127 2017-03-08 23:21:10 0|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.
128 2017-03-08 23:48:04 0|luke-jr|warren: I do, but my base VM is somewhat old
129 2017-03-08 23:50:12 0|achow101|warren: I use qemu with gitian and haven't had any issues with make-base-vm
130 2017-03-08 23:51:27 0|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.
131 2017-03-08 23:51:43 0|warren|achow101: how long ago did you make your base image?
132 2017-03-08 23:51:58 0|achow101|whenever 0.14.0rc3 was tagged
133 2017-03-08 23:52:18 0|achow101|(last week I think)
134 2017-03-08 23:55:00 0|bitcoin-git|[13bitcoin] 15deannolan opened pull request #9958: RPC:Refactor: Remove unreachable code refs #9573 (06master...06RPC_refactor) 02https://github.com/bitcoin/bitcoin/pull/9958