1 2017-02-20 00:38:10	0|instagibbs|gmaxwell, commits so nice they're credited twice
  2 2017-02-20 01:38:57	0|bitcoin-git|[13bitcoin] 15droark opened pull request #9806: txoutsbyaddress index (take 3) (06master...06gettxoutsbyaddress) 02https://github.com/bitcoin/bitcoin/pull/9806
  3 2017-02-20 01:47:54	0|bitcoin-git|[13bitcoin] 15fanquake opened pull request #9807: RPC doc fix-ups. (06master...06rpc-test-trivial-fixups) 02https://github.com/bitcoin/bitcoin/pull/9807
  4 2017-02-20 04:19:31	0|gmaxwell|https://www.reddit.com/r/Bitcoin/comments/5uy4h6/bitcoin_core_0140_release_candidate_1_available/ddyj3sx/  report that the transparent overlay isn't transparent.  (thinking about it I have no idea if it was transparent for me...)
  5 2017-02-20 04:19:54	0|achow101|I'm doing a fix for unifying the boolean verbose arguments with the RPCs. should the default be a boolean, or a verbosity number?
  6 2017-02-20 04:20:00	0|achow101|gmaxwell: it's supposed to be transparent?
  7 2017-02-20 04:23:03	0|sipa|it's modal, not transparent?
  8 2017-02-20 04:24:02	0|sipa|oh, release notes say semi-transparent
  9 2017-02-20 04:25:18	0|achow101|the pr for it, #8371 says its supposed to be semi-transparent. but that screenshot does not look very semi-transparent
 10 2017-02-20 04:25:20	0|gribble|https://github.com/bitcoin/bitcoin/issues/8371 | [Qt] Add out-of-sync modal info layer by jonasschnelli · Pull Request #8371 · bitcoin/bitcoin · GitHub
 11 2017-02-20 04:26:34	0|sipa|maybe the transparent part is the background, where you can see the actual tab?
 12 2017-02-20 04:27:46	0|achow101|it looks like you have to look really close. then you can see the background
 13 2017-02-20 04:27:53	0|achow101|zoom in. a lot
 14 2017-02-20 04:29:46	0|gmaxwell|I'm just a messager!
 15 2017-02-20 04:51:37	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 16 2017-02-20 04:56:16	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 17 2017-02-20 04:56:16	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 18 2017-02-20 04:56:16	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 19 2017-02-20 04:56:17	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 20 2017-02-20 04:56:17	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 21 2017-02-20 04:56:17	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 22 2017-02-20 04:56:18	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 23 2017-02-20 04:56:18	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 24 2017-02-20 04:56:18	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 25 2017-02-20 04:56:19	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 26 2017-02-20 04:56:19	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 27 2017-02-20 04:56:20	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 28 2017-02-20 04:56:20	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 29 2017-02-20 04:56:21	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 30 2017-02-20 04:56:32	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 31 2017-02-20 04:56:32	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 32 2017-02-20 04:56:33	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 33 2017-02-20 04:56:33	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 34 2017-02-20 04:56:34	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 35 2017-02-20 04:56:34	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 36 2017-02-20 04:56:35	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 37 2017-02-20 04:56:35	0|Guest80933|Sirs How can I start with signature campaign. I am just a newbie in bitcointalk.org
 38 2017-02-20 05:04:42	0|bitcoin-git|[13bitcoin] 15GCarneiroA opened pull request #9808: Master (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9808
 39 2017-02-20 07:25:03	0|wumpus|gmaxwell: I like the idea of always adding a warning to getinfo's warning field though. We could introduce that in a minor 0.14 release
 40 2017-02-20 07:35:10	0|jonasschnelli|Has there been talk to default enable -walletrbf=1 in 0.15? Or should the direction be that one can set the rbf flag per send*?
 41 2017-02-20 07:54:55	0|wumpus|jonasschnelli: not sure about that. We'd have be sure there are no significant wallets or companies that have problems accepting RBF transactions before making it default
 42 2017-02-20 08:14:18	0|cannon-c|Default RBF would make fee increase for faster processing easier for the non-tech savvy. I see lots of
 43 2017-02-20 08:14:59	0|cannon-c|questions referring how to get transactions unstuck, most wallets that are not core, are difficult for non-technical to resend transaction.
 44 2017-02-20 08:16:01	0|cannon-c|But I believe should notify users that RBF is set, with easily accessible ability to uncheck. Just my opinion
 45 2017-02-20 08:18:43	0|cannon-c|Wouldn't RBF fee increase in lieu of sending new transaction that is stuck, prevent transaction ID from changing? If so I see how RBF would be great advantage
 46 2017-02-20 08:30:31	0|gmaxwell|wumpus: fwiw, I believe several other wallets are producing OO rbf (electrum and green address)
 47 2017-02-20 08:31:01	0|gmaxwell|wumpus: also, you can always bump your way out of flagging, which should reduce the issue.
 48 2017-02-20 08:31:22	0|gmaxwell|jonasschnelli: I think we should hear feedback for how things go for bumpfee users in 0.14.x
 49 2017-02-20 08:31:37	0|jonasschnelli|I think OO rbf should be the default and optionally, if you want to pay a 0-conf merchant, you may want to switch it of.
 50 2017-02-20 08:31:51	0|jonasschnelli|*off
 51 2017-02-20 08:32:13	0|gmaxwell|jonasschnelli: I think bumping it off is somewhat superior to switching it off, unless you're really sure you want it off.
 52 2017-02-20 08:32:44	0|gmaxwell|rationale: even if the rx side will ignore the unconfirmed tx with it off, it might just confirm right away.
 53 2017-02-20 08:58:34	0|wumpus|gmaxwell: okay that would be a good argument to enable it by default on master now, at least
 54 2017-02-20 08:58:39	0|jonasschnelli|0.14.0rc1 sync against random peers
 55 2017-02-20 08:58:40	0|jonasschnelli|2017-02-19 20:25:48 UpdateTip: new best=00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 height=1 version=0x00000001 log2_work=33.000022 tx=2 date='2009-01-09 02:54:25' progress=0.000000 cache=0.0MiB(1tx)
 56 2017-02-20 08:58:46	0|jonasschnelli|2017-02-19 23:06:26 UpdateTip: new best=000000000000000002204d1e9885416bfef39a2259a48a3eb5d36b6e8e21fad7 height=453816 version=0x20000002 log2_work=86.006491 tx=197951144 date='2017-02-19 23:00:41' progress=0.999994 cache=4096.3MiB(7229926tx) warning='2 of last 100 blocks have unexpected version'
 57 2017-02-20 08:59:24	0|wumpus|is it syncing or stuck?
 58 2017-02-20 08:59:30	0|jonasschnelli|No.. it's fast. :)
 59 2017-02-20 08:59:46	0|gmaxwell|453816 is currentish.
 60 2017-02-20 08:59:50	0|wumpus|ooh! great.I thought you were worried about the version warning
 61 2017-02-20 08:59:59	0|jonasschnelli|453816  was at 2017-02-19 23:06:26
 62 2017-02-20 09:00:03	0|gmaxwell|that is with increased dbcache, obviously.
 63 2017-02-20 09:00:11	0|jonasschnelli|7GB cache. yes.
 64 2017-02-20 09:00:33	0|wumpus|oh only 7GB cache :-)
 65 2017-02-20 09:00:36	0|gmaxwell|a little cheating there because it has never flushed at all. :P
 66 2017-02-20 09:00:46	0|jonasschnelli|Almost same sync-times then we has with 0.13.0 but more blocks. :)
 67 2017-02-20 09:01:03	0|wumpus|yes seems the bottleneck now is really i/o for the utxo database
 68 2017-02-20 09:01:21	0|gmaxwell|well, sipa has code that makes it ~33% faster.
 69 2017-02-20 09:01:21	0|sipa|last week gmaxwell and i tried to sync a 0.7.2 node from scratch, with -connect to a fast new node
 70 2017-02-20 09:01:23	0|jonasschnelli|flush takes only a couple of seconds on that machine.. so neglectable
 71 2017-02-20 09:01:48	0|gmaxwell|jonasschnelli: flush of the utxo cache, with 4gb in is not going to take a couple seconds.
 72 2017-02-20 09:01:56	0|gmaxwell|try a minute.
 73 2017-02-20 09:02:03	0|wumpus|but yes with database in RAM or on a SSD it's surprisingly fast
 74 2017-02-20 09:02:09	0|jonasschnelli|I'll measure my shutdown now...
 75 2017-02-20 09:02:22	0|gmaxwell|also, part of the time is hidden in the next start up.
 76 2017-02-20 09:02:35	0|wumpus|too bad that that doesn't help my odroid64 :-)
 77 2017-02-20 09:02:52	0|jonasschnelli|Maybe 15s
 78 2017-02-20 09:02:52	0|sipa|jonasschnelli: flushing means that every subsequent spend from an out-of-cache tx afterwards needs a read from disk and deserialization
 79 2017-02-20 09:03:03	0|jonasschnelli|I'm using a 1GB/s SSD
 80 2017-02-20 09:03:18	0|sipa|so the slowdown is partially in later entries
 81 2017-02-20 09:03:27	0|wumpus|yes it's not the flushing itself, as in writing, that poses a bottleneck with leveldb. leveldb is very fast with writing. It's that the flush empties the entire db
 82 2017-02-20 09:03:56	0|wumpus|+cache
 83 2017-02-20 09:04:05	0|jonasschnelli|https://0bin.net/paste/RdqE7Qkd8uMcew8H#o5kz3c7fBGijX2ZXzJ4d8fAozAN0h5IAQvaD8gwaeRz
 84 2017-02-20 09:04:10	0|sipa|half of the time is constructing the batch for leveldb to write
 85 2017-02-20 09:04:41	0|wumpus|<gmaxwell> well, sipa has code that makes it ~33% faster.<- that's good news! how?
 86 2017-02-20 09:04:51	0|sipa|wumpus: per txout caching
 87 2017-02-20 09:05:13	0|gmaxwell|It unfortunately increases the size of the utxo database on disk somewhat.
 88 2017-02-20 09:05:13	0|wumpus|sipa: ah nice
 89 2017-02-20 09:05:22	0|sipa|and undo data
 90 2017-02-20 09:05:36	0|wumpus|by how much?
 91 2017-02-20 09:05:45	0|gmaxwell|Less than double. I think it's a clear win.
 92 2017-02-20 09:06:15	0|gmaxwell|Basically the keys get repeated.. leveldb has some compaction of that, but its not perfect.
 93 2017-02-20 09:06:21	0|wumpus|could anything be gained by compressing undo data?
 94 2017-02-20 09:06:25	0|gmaxwell|and the undo data is only slightly larger.
 95 2017-02-20 09:06:39	0|wumpus|as you say "repeated", compression seems obvs answer
 96 2017-02-20 09:06:40	0|sipa|undo data is already compressed pretty well
 97 2017-02-20 09:06:44	0|wumpus|ok
 98 2017-02-20 09:07:04	0|gmaxwell|well we can reduce the size of all blocks by ~27% using different stuff, I don't think we've looked to shrink undo data much more than it alread is.
 99 2017-02-20 09:07:06	0|sipa|but the size increase on the chainstate should be investigated more carefully
100 2017-02-20 09:07:29	0|sipa|if it increases significantly, it may not be a win for systems with slow disks
101 2017-02-20 09:07:31	0|wumpus|true, undo data is deleted together with the blocks on pruning
102 2017-02-20 09:07:40	0|wumpus|chainstate growth is much more worrying
103 2017-02-20 09:07:47	0|sipa|yes :(
104 2017-02-20 09:07:53	0|gmaxwell|also, I'm sure now we have enough improvements that the sse2-sha256 will be more of a speedup, I think jonasschnelli benchmarked 5% in IBD time, and that was before assumevalid.
105 2017-02-20 09:08:09	0|gmaxwell|wumpus: well the growth, whatever it is, should be roughly a constant factor.
106 2017-02-20 09:08:13	0|jonasschnelli|Yes. IBD is not much of a difference...
107 2017-02-20 09:08:22	0|jonasschnelli|with wumpuses sse2
108 2017-02-20 09:08:37	0|wumpus|5% is pretty nice
109 2017-02-20 09:08:41	0|jonasschnelli|Yes. Sure.
110 2017-02-20 09:08:43	0|gmaxwell|jonasschnelli: I think 5% isn't bad. y'all expect too much from optimizations. And on top of assume valid and that 33% gain that 5% will be much larger.
111 2017-02-20 09:08:48	0|sipa|oh, so... we were unable to get 0.7.2 to sync past some block in 2015
112 2017-02-20 09:09:04	0|jonasschnelli|But I think it's great for nodes running in sync.
113 2017-02-20 09:09:05	0|wumpus|compound growth, heh
114 2017-02-20 09:09:09	0|gmaxwell|even with massively increased locks.
115 2017-02-20 09:09:21	0|wumpus|all those 5% and 3% stacked on top of each other do count
116 2017-02-20 09:09:23	0|gmaxwell|In libsecp256k1 we celebrate 1% improvements.
117 2017-02-20 09:10:25	0|jonasschnelli|We often focus on IBD improvments,... they are great. Boiling hot water quick is great,... but keeping it warm with low amount of energy also counts. :)
118 2017-02-20 09:11:02	0|sipa|well IBD time is a biased proxy for block validation time
119 2017-02-20 09:11:10	0|sipa|and it keeps users happy
120 2017-02-20 09:11:48	0|sipa|many of the improvements to IBD time do matter for single node validation... except assumevalid, though we get sigcache in return
121 2017-02-20 09:12:48	0|jonasschnelli|Yes. That's true. But sse2 5% in IBD may results in 10-15% during in-sync state because of lesser IO. My Pine64 (RPi clone) would really love that.
122 2017-02-20 09:13:18	0|jonasschnelli|(and it actually has SHA256 NI)
123 2017-02-20 09:17:17	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #9808: Master (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/9808
124 2017-02-20 09:18:49	0|jonasschnelli|wumpus: since we have 0.14 now branched off, we could try to make a little step towards refactoring out BDB. Maybe check #9143?
125 2017-02-20 09:18:51	0|gribble|https://github.com/bitcoin/bitcoin/issues/9143 | Refactor ZapWalletTxes to avoid layer violations by jonasschnelli · Pull Request #9143 · bitcoin/bitcoin · GitHub
126 2017-02-20 09:25:09	0|cbits|@jonasschnelli I'm in the camp that rbf should either be set by default with a checkbox to unset it per transaction, or entirely off in the settings. Or the other option, of having it not set by default, but you get the behavior I first described if you set rbf on.
127 2017-02-20 09:26:37	0|cbits|Electrum currently makes you set rbf on for every transaction even after making the option visible in the settings. Which imo is annoying. Should be default.
128 2017-02-20 09:27:02	0|jonasschnelli|cbits: I think the GUI can handle RBF pretty well. I see more potential in improving the RPC API.
129 2017-02-20 09:27:20	0|jonasschnelli|The gui will very likely have https://github.com/bitcoin/bitcoin/pull/9697 in 0.15.
130 2017-02-20 09:27:33	0|jonasschnelli|And a per-tx-opt-in checkbox
131 2017-02-20 09:27:53	0|jonasschnelli|And, the GUI offers user verification before sending (to inform better about the RBF state).
132 2017-02-20 09:30:45	0|cbits|jonasschnelli: nice. Didn't see that pull. I'll check it out.
133 2017-02-20 09:40:30	0|jonasschnelli|I'm setting up a new gitian machine... but facing an error with the vm sudoers config:
134 2017-02-20 09:40:31	0|jonasschnelli|https://0bin.net/paste/V1mMAN3IRN2c1lSE#Xuff715O4aijc+o9h04ohmF145+fRrXqojsb11jDxmy
135 2017-02-20 09:40:37	0|jonasschnelli|Any idea how to fix that?
136 2017-02-20 09:41:03	0|jonasschnelli|It seems that the prompt breaks the make-base-vm process
137 2017-02-20 09:46:37	0|wumpus|strange
138 2017-02-20 09:47:46	0|wumpus|is this a sudo issue in the VM or the host machine? confusing
139 2017-02-20 09:47:56	0|wumpus|looks something *on* the vm, so changing sudoers won't help you either
140 2017-02-20 09:50:31	0|jonasschnelli|Yes. Seems to be on the VM.
141 2017-02-20 09:50:53	0|jonasschnelli|I'm using make-base-vm on a non-VM host. Using -KVM
142 2017-02-20 09:50:56	0|wumpus|I created a new base image twice yesterday - no issues
143 2017-02-20 09:51:59	0|wumpus|this is kvm or lxc?
144 2017-02-20 09:52:29	0|jonasschnelli|KVM
145 2017-02-20 09:52:38	0|wumpus|okay what I tried is LXC
146 2017-02-20 09:52:53	0|jonasschnelli|Just tried LXC and seems to have worked..
147 2017-02-20 09:55:11	0|wumpus|the upgrader should probably be passed some kind of silent/don't prompt flag for the KVM image build
148 2017-02-20 09:57:44	0|jonasschnelli|After using LXC, the base image was named "base-trusty-amd64" instead of "base-trusty-amd64.qcow2"... renamed and trying to gbuild now
149 2017-02-20 10:04:27	0|wumpus|jonasschnelli: that is the correct naming
150 2017-02-20 10:04:35	0|wumpus|lxc image is not a qcow
151 2017-02-20 10:04:51	0|jonasschnelli|ah... I guess I need to set USE_LXC
152 2017-02-20 10:13:11	0|wumpus|yep
153 2017-02-20 10:16:27	0|jonasschnelli|libexec/config-bootstrap-fixup: line 15: target-bin/bootstrap-fixup.in: No such file or directory
154 2017-02-20 10:20:29	0|wumpus|never seen that one before
155 2017-02-20 10:24:03	0|wumpus|not sure if KVM will work at all in my setup, but will try making a KVM image
156 2017-02-20 10:50:12	0|wumpus|jonasschnelli: I get the same error as you
157 2017-02-20 10:50:28	0|wumpus|making an issue
158 2017-02-20 11:00:51	0|wumpus|https://github.com/devrandom/gitian-builder/issues/144
159 2017-02-20 11:01:42	0|wumpus|would be nice if we could resolve this before final
160 2017-02-20 12:03:27	0|bitcoin-git|[13bitcoin] 15GCarneiroA opened pull request #9809: Master (060.10...06master) 02https://github.com/bitcoin/bitcoin/pull/9809
161 2017-02-20 12:04:36	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #9809: Master (060.10...06master) 02https://github.com/bitcoin/bitcoin/pull/9809
162 2017-02-20 13:50:21	0|achow101|jonasschnelli: that's an issue with vmbuilder. see https://bugs.launchpad.net/vmbuilder/+bug/1659952
163 2017-02-20 13:51:08	0|jonasschnelli|achow101: Nice! thanks. You should probably report that also here -> https://github.com/devrandom/gitian-builder/issues/144
164 2017-02-20 15:25:22	0|paveljanik|anyone running Windows here?
165 2017-02-20 15:25:34	0|paveljanik|can you please try loading mempool.dat?
166 2017-02-20 16:26:48	0|bitcoin-git|[13bitcoin] 15laanwj pushed 4 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/390a39bb5cf4...1a9fd5cb9d13
167 2017-02-20 16:26:49	0|bitcoin-git|13bitcoin/06master 1450c5657 15Luke Dashjr: Qt/Intro: Storage shouldn't grow significantly with pruning enabled
168 2017-02-20 16:26:49	0|bitcoin-git|13bitcoin/06master 149adb694 15Luke Dashjr: Qt/Intro: Move sizeWarningLabel text into C++ code
169 2017-02-20 16:26:49	0|bitcoin-git|13bitcoin/06master 14f6d18f5 15Luke Dashjr: Qt/Intro: Explain a bit more what will happen first time
170 2017-02-20 16:27:09	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9724: Qt/Intro: Add explanation of IBD process (06master...06intro_explain) 02https://github.com/bitcoin/bitcoin/pull/9724
171 2017-02-20 16:29:43	0|bitcoin-git|13bitcoin/06master 141bfe6b4 15Mitchell Cash: Use package name variable inside $(package)_file_name variable
172 2017-02-20 16:29:43	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/1a9fd5cb9d13...7ca2f542708b
173 2017-02-20 16:29:44	0|bitcoin-git|13bitcoin/06master 147ca2f54 15Wladimir J. van der Laan: Merge #9794: Minor update to qrencode package builder...
174 2017-02-20 16:30:07	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9794: Minor update to qrencode package builder (06master...06minor_depends_fix) 02https://github.com/bitcoin/bitcoin/pull/9794
175 2017-02-20 16:30:31	0|bitcoin-git|13bitcoin/06master 142dad022 15Wladimir J. van der Laan: Merge #9760: [wallet] Remove importmulti always-true check...
176 2017-02-20 16:30:31	0|bitcoin-git|13bitcoin/06master 14ec1267f 15Russell Yanofsky: [wallet] Remove importmulti always-true check...
177 2017-02-20 16:30:31	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7ca2f542708b...2dad02232af1
178 2017-02-20 16:30:56	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9760: [wallet] Remove importmulti always-true check (06master...06pr/multitaut) 02https://github.com/bitcoin/bitcoin/pull/9760
179 2017-02-20 16:32:23	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/2dad02232af1...aa791e29114f
180 2017-02-20 16:32:24	0|bitcoin-git|13bitcoin/06master 14279f944 15Luke Dashjr: QA: Test GBT size/weight limit values
181 2017-02-20 16:32:24	0|bitcoin-git|13bitcoin/06master 149fc7f0b 15Luke Dashjr: Bugfix: RPC/Mining: GBT should return 1 MB sizelimit before segwit activates
182 2017-02-20 16:32:25	0|bitcoin-git|13bitcoin/06master 14aa791e2 15Wladimir J. van der Laan: Merge #9619: Bugfix: RPC/Mining: GBT should return 1 MB sizelimit before segwit activates...
183 2017-02-20 16:32:41	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9619: Bugfix: RPC/Mining: GBT should return 1 MB sizelimit before segwit activates (06master...06bugfix_gbt_presw) 02https://github.com/bitcoin/bitcoin/pull/9619
184 2017-02-20 16:36:59	0|bitcoin-git|13bitcoin/060.14 146552729 15Luke Dashjr: Bugfix: RPC/Mining: GBT should return 1 MB sizelimit before segwit activates...
185 2017-02-20 16:36:59	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 060.14: 02https://github.com/bitcoin/bitcoin/compare/40c754cb38cd...861cb0c83db0
186 2017-02-20 16:37:00	0|bitcoin-git|13bitcoin/060.14 14861cb0c 15Luke Dashjr: QA: Test GBT size/weight limit values...
187 2017-02-20 16:50:15	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/aa791e29114f...7639d38f14b1
188 2017-02-20 16:50:16	0|bitcoin-git|13bitcoin/06master 1413f6085 15Wladimir J. van der Laan: netbase: Make InterruptibleRecv return an error code instead of bool
189 2017-02-20 16:50:17	0|bitcoin-git|13bitcoin/06master 143ddfe29 15Wladimir J. van der Laan: netbase: Do not print an error on connection timeouts through proxy...
190 2017-02-20 16:50:17	0|bitcoin-git|13bitcoin/06master 147639d38 15Wladimir J. van der Laan: Merge #9726: netbase: Do not print an error on connection timeouts through proxy...
191 2017-02-20 16:50:42	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9726: netbase: Do not print an error on connection timeouts through proxy (06master...062017_02_intr_recv_error) 02https://github.com/bitcoin/bitcoin/pull/9726
192 2017-02-20 17:02:46	0|paveljanik|sipa, wumpus: #9810 - any idea (seems to be crlf on serialization ;-)?
193 2017-02-20 17:02:47	0|gribble|https://github.com/bitcoin/bitcoin/issues/9810 | 0.14 not loading mempool.dat? · Issue #9810 · bitcoin/bitcoin · GitHub
194 2017-02-20 17:03:07	0|paveljanik|binary on write?
195 2017-02-20 17:03:25	0|paveljanik|Windows...
196 2017-02-20 17:04:02	0|wumpus|that could be the explanation, good catch! how is the file opened?
197 2017-02-20 17:04:25	0|wumpus|if its opened in text (instead of binary) mode, windows will convert \n to \r\n
198 2017-02-20 17:06:31	0|paveljanik|it is written with "w" and opened with "r"
199 2017-02-20 17:06:52	0|wumpus|that should be "wb" and "rb"
200 2017-02-20 17:07:00	0|wumpus|so you've found the issue, congrats
201 2017-02-20 17:07:02	0|paveljanik|Hmm, this reminds me: zerocoin was missing =, we are missing b ;-)
202 2017-02-20 17:07:19	0|paveljanik|we should congrat to the reporter!
203 2017-02-20 17:07:50	0|wumpus|I mean you've found the probable solution
204 2017-02-20 17:08:06	0|paveljanik|but really: any dev with Windows to really test this?
205 2017-02-20 17:08:22	0|wumpus|are you going to make a PR?
206 2017-02-20 17:08:57	0|paveljanik|for master and you'll backport?
207 2017-02-20 17:09:14	0|wumpus|yes
208 2017-02-20 17:09:31	0|paveljanik|give me a few minutes
209 2017-02-20 17:15:40	0|bitcoin-git|[13bitcoin] 15paveljanik opened pull request #9813: Read/write mempool.dat as a binary. (06master...0620170220_mempool_binary) 02https://github.com/bitcoin/bitcoin/pull/9813
210 2017-02-20 17:25:27	0|wumpus|paveljanik: thanks
211 2017-02-20 17:25:53	0|paveljanik|you're welcome!
212 2017-02-20 17:27:44	0|paveljanik|we use "w" for PID and log
213 2017-02-20 17:28:54	0|paveljanik|and in tests
214 2017-02-20 17:28:58	0|paveljanik|all "text" files
215 2017-02-20 17:32:44	0|cfields|windows users who ran rc1 will need to delete mempool.dat. Not sure if that
216 2017-02-20 17:32:50	0|cfields|'s worth adding to the release notes or not
217 2017-02-20 17:34:32	0|paveljanik|it is auto fixed at the first exit?
218 2017-02-20 17:34:38	0|paveljanik|by saving the new file...
219 2017-02-20 17:36:14	0|cfields|ah, right.
220 2017-02-20 17:39:44	0|wumpus|for text files it makes sense not to add 'b', otherwise you cannot open it in notepad
221 2017-02-20 18:03:18	0|achow101|paveljanik: I can test on windows, as soon as I my windows node finishes syncing
222 2017-02-20 18:03:40	0|paveljanik|achow101, great!
223 2017-02-20 18:13:28	0|achow101|if only we could figure out how to make cross compiling work on xenial... cross compiling for windows is such a pain now
224 2017-02-20 18:23:07	0|sipa|achow101: what fails?
225 2017-02-20 18:23:45	0|achow101|sipa: https://github.com/bitcoin/bitcoin/projects/1
226 2017-02-20 18:23:47	0|achow101|still unresolved
227 2017-02-20 18:33:42	0|achow101|paveljanik: your fix didn't work for me on ubuntu 16.04
228 2017-02-20 18:34:08	0|paveljanik|achow101, on Ubuntu?
229 2017-02-20 18:34:21	0|paveljanik|you have tried the provided mempool.dat?
230 2017-02-20 18:34:29	0|paveljanik|My fix fixes save on Windows...
231 2017-02-20 18:35:05	0|achow101|oh, it was windows specific? I am testing on both ubuntu and windows, just waiting for windows to finish building
232 2017-02-20 18:46:07	0|achow101|paveljanik: for some reason I had to delete the mempool.dats before it would work properly
233 2017-02-20 18:51:13	0|paveljanik|yes, this is probably caused by the issue fixed ;-)
234 2017-02-20 18:51:57	0|paveljanik|achow101, can you please try again with the master-saved mempool.dat?
235 2017-02-20 18:52:18	0|paveljanik|and then run fixed tree with the old mempool.dat?
236 2017-02-20 18:52:40	0|paveljanik|it won't use it. But at exit, it should rewrite it and then on the new start it should use it.
237 2017-02-20 19:17:00	0|achow101|ok, it looks like it does rewrite the old one and actually uses it
238 2017-02-20 20:12:41	0|paveljanik|achow101, perfect!
239 2017-02-20 20:37:01	0|BlueMatt|what am I missing? why are we going out of our way to prefer data() over &v[0]?
240 2017-02-20 20:37:15	0|BlueMatt|I mean its more readable, sure, but I dont believe it is safer in any measurable way?
241 2017-02-20 20:38:13	0|BlueMatt|or, maybe I'm missing in docs...is it that data() is defined for 0-length vectors (though not dereferenceable - it can return any garbage it wants), but &[0] is not?
242 2017-02-20 20:43:15	0|gwillen|BlueMatt: I believe &[0] should be defined for zero-length vectors, it's legal to take a pointer to the slot right after the end of an array (this is what e.g. a .end() iterator is)
243 2017-02-20 20:43:34	0|gwillen|see the _second_ (not accepted) answer which quotes the standard: http://stackoverflow.com/questions/988158/take-the-address-of-a-one-past-the-end-array-element-via-subscript-legal-by-the
244 2017-02-20 20:43:47	0|midnightmagic|huh, that's interesting. I've been fighting with almost that exact same thing.
245 2017-02-20 20:45:01	0|BlueMatt|gwillen: hmm? I mean that doesnt inherintly mean C++ allows it as well?
246 2017-02-20 20:45:11	0|sipa|BlueMatt: vect[0] is a reference to non-existing data if vector is empty, which is illegal
247 2017-02-20 20:45:19	0|sipa|you can have a pointer to non-existing data, but not a reference
248 2017-02-20 20:45:51	0|BlueMatt|ahh, ok, so it is illegal in C++ but not C?
249 2017-02-20 20:45:55	0|gwillen|sipa: but &foo[0] is a pointer, not a reference
250 2017-02-20 20:45:56	0|BlueMatt|(well, vector but not array)
251 2017-02-20 20:46:01	0|gwillen|and a pointer to one past the end is definitely legal
252 2017-02-20 20:46:10	0|sipa|gwillen: &foo[0] = &(foo[0])
253 2017-02-20 20:46:19	0|sipa|that's taking the address of a reference to non-existing data
254 2017-02-20 20:46:32	0|BlueMatt|sipa: see stackoverflow link from gwillen, it sppears to be legal in C
255 2017-02-20 20:46:35	0|gwillen|do you believe it's different in C++ with a vector than in C with an array?
256 2017-02-20 20:46:41	0|sipa|C doesn't have references
257 2017-02-20 20:46:47	0|gwillen|right
258 2017-02-20 20:46:47	0|sipa|the question doesn't apply
259 2017-02-20 20:47:02	0|sipa|a[b] in C is just syntactic sugar for *(a+b)
260 2017-02-20 20:47:06	0|gwillen|but in C that construction would appear to actually dereference an invalid pointer, but the standard gives it a pass
261 2017-02-20 20:47:27	0|gwillen|and explicity says that if you do &foo[x] it turns into foo+x and does not dereference
262 2017-02-20 20:47:36	0|sipa|well that's about arrays
263 2017-02-20 20:47:49	0|sipa|which are defined by the language
264 2017-02-20 20:47:53	0|BlueMatt|mmm, ok
265 2017-02-20 20:48:08	0|gwillen|well, it actually also says this pass applies to the * operator as well, and &(*foo) does not dereference either, which is slightly more general
266 2017-02-20 20:48:22	0|sipa|but vector is a standard library class, where vect[x] is an operator that returns a reference to a vector element
267 2017-02-20 20:48:25	0|gwillen|but I suppose that would be hard to spec for user-defined operators
268 2017-02-20 20:48:30	0|sipa|which is just impossible to do if there are no elements
269 2017-02-20 20:50:14	0|sipa|for example, a vector implementation (and in practice does) contains a pointer to the first element of the data
270 2017-02-20 20:50:27	0|sipa|but initializes it to nullptr if there are no elements allocated
271 2017-02-20 20:50:45	0|sipa|vect[0] would then be implemented as a dereference of nullptr
272 2017-02-20 20:51:11	0|sipa|so forcing vect[0] to be valid for empty vectors would outlaw the obviously simplest implementation
273 2017-02-20 20:51:14	0|gwillen|nod*
274 2017-02-20 20:51:48	0|BlueMatt|yea, ok
275 2017-02-20 20:51:50	0|sipa|whereas array[0] is simply a reference to the element 1 past the array... not nullptr
276 2017-02-20 20:52:06	0|gwillen|right
277 2017-02-20 20:52:21	0|sipa|actually, i believe that C and/or C++ require every object to have non-zero allocation space
278 2017-02-20 20:52:49	0|sipa|otherwise alias detection is nearly impossible
279 2017-02-20 20:56:44	0|luke-jr|hmm
280 2017-02-20 20:57:06	0|luke-jr|&foo[0] actually called operator[] in C++, rather than just being (foo+0)?
281 2017-02-20 20:57:16	0|sipa|for vectors, yes
282 2017-02-20 20:57:19	0|luke-jr|I guess it would have to :x
283 2017-02-20 20:57:31	0|sipa|for arrays i don't know
284 2017-02-20 20:57:53	0|luke-jr|a shame, &foo[0] looks nicer XD
285 2017-02-20 20:58:28	0|sipa|also, (foo+0) for a vector would be nonsense... you can't add 0 to a vector
286 2017-02-20 20:58:39	0|luke-jr|☺
287 2017-02-20 21:01:44	0|sipa|FATAL: ThreadSanitizer CHECK failed: ../../../../src/libsanitizer/sanitizer_common/sanitizer_deadlock_detector1.cc:122 "((len)) > ((0U))" (0x0, 0x0)
288 2017-02-20 21:01:47	0|sipa|#0 <null> <null> (libtsan.so.0+0x00000007c0d3)
289 2017-02-20 21:01:48	0|gribble|https://github.com/bitcoin/bitcoin/issues/0 | HTTP Error 404: Not Found
290 2017-02-20 21:01:50	0|sipa|#1 <null> <null> (libtsan.so.0+0x00000007c0db)
291 2017-02-20 21:01:51	0|gribble|https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
292 2017-02-20 21:01:52	0|sipa|#2 __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) <null> (libtsan.so.0+0x000000081303)
293 2017-02-20 21:01:54	0|gribble|https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub
294 2017-02-20 21:01:55	0|sipa|much sad
295 2017-02-20 21:02:13	0|sipa|assertion failure inside tsan :(
296 2017-02-20 21:50:04	0|BlueMatt|god damnit gribble
297 2017-02-20 21:51:06	0|sipa|indeed!
298 2017-02-20 21:51:20	0|btcdrak|issue 0 as well lol
299 2017-02-20 22:04:16	0|BlueMatt|should we mention somewhere in the release notes that 0.14 has mega-super-amazing-faster block relay?
300 2017-02-20 22:07:23	0|sipa|there is an issue about that by cory i think
301 2017-02-20 22:07:25	0|sipa|or a pr
302 2017-02-20 22:08:19	0|BlueMatt|ok, good...I often dont read release-notes stuff :/
303 2017-02-20 22:08:23	0|BlueMatt|I suppose I'm a bad contributor :/
304 2017-02-20 23:50:01	0|gmaxwell|BlueMatt: you should measure it.
305 2017-02-20 23:50:20	0|BlueMatt|gmaxwell: which part?
306 2017-02-20 23:52:57	0|gmaxwell|preferably the mega-super-amazing parts.
307 2017-02-20 23:53:54	0|BlueMatt|fast-relay: we have good measurements for how long validation takes
308 2017-02-20 23:53:57	0|BlueMatt|you win by that much :)