1 2015-06-08 05:33:30 <gmaxwell> I'm getting a spurrious
  2 2015-06-08 05:33:31 <gmaxwell> "errors" : "WARNING: check your network connection, 0 blocks received in the last 4 hours (24 expected)"
  3 2015-06-08 05:33:35 <gmaxwell> on testnet with 0.11
  4 2015-06-08 05:34:02 <gmaxwell> the blocks on the tip of testnet are actually somewhat in the future.
  5 2015-06-08 06:12:37 <flound1129> having lots of problems syncing RC1
  6 2015-06-08 06:12:44 <flound1129> segfaults, etc.
  7 2015-06-08 06:12:51 <flound1129> using prune=1000
  8 2015-06-08 06:16:01 <sipa> flound1129: a bit more details are welcome :)
  9 2015-06-08 06:16:10 <sipa> debug.log output for example
 10 2015-06-08 06:16:23 <sipa> run in gdb and get a stack trace
 11 2015-06-08 06:16:47 <flound1129> k
 12 2015-06-08 06:17:54 <flound1129> using boost 1.55 on ubuntu 14.04
 13 2015-06-08 06:18:00 <flound1129> I'll try again under gdb
 14 2015-06-08 06:18:22 <flound1129> debug.log not helpful
 15 2015-06-08 06:18:24 <sipa> if it crashes, type thread apply all bt
 16 2015-06-08 06:18:27 <flound1129> just block lines
 17 2015-06-08 06:18:30 <sipa> in gdb
 18 2015-06-08 06:18:42 <sipa> and put the output somewhere
 19 2015-06-08 06:19:33 <sipa> gmaxwell: seems an issue was just posted about that
 20 2015-06-08 06:19:38 <sipa> for mainnet...
 21 2015-06-08 07:48:32 <flound1129> getting tons of hashMerkleRoot mismatch
 22 2015-06-08 07:48:35 <flound1129> filling up log
 23 2015-06-08 07:50:51 <wumpus> gmaxwell: there is a problem with the computation resulting in more false positives than expected (see #5947, sipa commented on it); maybe we should disable it until that's fixed
 24 2015-06-08 07:51:43 <gmaxwell> wumpus: in the case I gave it just made no sense. e.g. claimed 0 blocks when in fact there had been many.
 25 2015-06-08 07:52:21 <wumpus> ok, if there is also a reported mainnet issue that's it, I'm going to disable it for rc2
 26 2015-06-08 08:11:16 <flound1129> it looks like it's failing on block 221992
 27 2015-06-08 08:11:30 <flound1129> continually spewing those hashMerkleRoot mismatch lines into the log
 28 2015-06-08 08:16:54 <phantomcircuit> wumpus, in general i doubt there is a sane threshold
 29 2015-06-08 08:17:13 <phantomcircuit> anything high enough to not cause false positives is going to be so high as to be effectively useless
 30 2015-06-08 08:18:20 <wumpus> phantomcircuit: IIRC the threshold isn't the problem, the computation is
 31 2015-06-08 08:18:36 <wumpus> flound1129: can you pastebin the log lines around the error?
 32 2015-06-08 08:25:10 <flound1129> it's just continually streaming that error into the log
 33 2015-06-08 08:25:20 <flound1129> let me see what's before the first one
 34 2015-06-08 08:26:24 <flound1129> http://pastebin.com/bwJHLN1M
 35 2015-06-08 08:44:35 <stormJanuary> Hlw
 36 2015-06-08 08:46:13 <mjerr> https://test-insight.bitpay.com/blocks .. seems like AntMiner is mining the 'free' 20minute block without including any transactions
 37 2015-06-08 08:58:40 <wumpus> flound1129: strange.
 38 2015-06-08 09:02:18 <wumpus> this error should happen when the block data received doesn't match the block header. But this should already have been checked when receiving the block (and is DoSable offense), somehow such a block ended up in your block storage and it's trying to connect it in a loop
 39 2015-06-08 09:02:53 <wumpus> this points at some corruption issue, either a hardware/software issue or state bug in bitcoind
 40 2015-06-08 09:03:29 <wumpus> but *usually* corruption issues such as overlapping blocks show up as a deserialization error
 41 2015-06-08 09:04:04 <gmaxwell> wumpus: the prior corrupt on reindex stuff would manifest like that for me.
 42 2015-06-08 09:06:49 <wumpus> so it succesfully deserializes the block, but it's just not what it expects it to be ... flound1129 can you upload your block index ~/bitcoin/blocks/index as well as the last three or so blkXXXX files?
 43 2015-06-08 09:07:00 <wumpus> gmaxwell: right
 44 2015-06-08 09:48:10 <phantomcircuit> mjerr, that's actually pretty interesting
 45 2015-06-08 09:59:46 <wumpus> more like sad, they're hoarding testnet coins
 46 2015-06-08 10:25:15 <volante> can someone please explain why steps 2, 4, and 8 are needed in this process? https://en.bitcoin.it/w/images/en/7/70/Bitcoin_OpCheckSig_InDetail.png
 47 2015-06-08 10:26:19 <sipa> step 2 has been useless for ages, as OP_CODESEPARATOR does not actually do anymore what it was intended for
 48 2015-06-08 10:26:46 <sipa> step 4 should always be a no-op in practice
 49 2015-06-08 10:27:01 <sipa> step 8: ask satoshi why this would be necessary
 50 2015-06-08 10:29:58 <volante> TxCopy already has the txid/index of the input transaction so i don't see how including the script adds any security
 51 2015-06-08 10:30:19 <sipa> it does not add security
 52 2015-06-08 10:30:34 <mjerr> phantomcircuit, I don't mind them hoarding all of them, but it takes forever to have a normal tx included.. and the normal blocks that they mine are completely full (to the soft limit)..
 53 2015-06-08 10:32:21 <phantomcircuit> mjerr, my guess would be that their software isn't super smart
 54 2015-06-08 10:32:48 <sipa> volante: some parts of bitcoin's design are intrincate and very useful but non-obvious
 55 2015-06-08 10:33:07 <sipa> volante: others just don't seem to have a reason, but are they way they are just because satoshi did things in a particular way
 56 2015-06-08 10:33:17 <volante> haha, so one day that feature might prove useful, and then we'll know why satoshi included it
 57 2015-06-08 10:33:59 <sipa> i guess it's useful if we'd ever have simple hwardware signing devices that support complex scripts
 58 2015-06-08 10:34:17 <sipa> because it means you need to tell the device which scriptPubKey it's signing for without giving it the transaction being spent
 59 2015-06-08 10:34:27 <sipa> and if you lie, the created transaction is invalid
 60 2015-06-08 10:36:57 <gmaxwell> sipa: including the pubkey under the signature, is a good and virtuious thing that corrects a flaw in the ordinary ECDSA construction; that its not a proof-of-knoweldge because it doesn't commit to the pubkey.  ... but that flaw isn't ordinarly relevant to bitcoin and we do commit by virtue of always signing the input txid. So who knows.
 61 2015-06-08 10:40:15 <mjerr> phantomcircuit, but wouldnt any standard software make it right? seems to me they changed that on purpose
 62 2015-06-08 10:40:56 <phantomcircuit> mjerr, no you have to write custom software to push that rule to it's limit (which they appear to have done)
 63 2015-06-08 10:42:19 <gmaxwell> why do you assume it's antminer?
 64 2015-06-08 10:42:35 <mjerr> it says so on bitpay
 65 2015-06-08 10:42:37 <mjerr> https://test-insight.bitpay.com/blocks
 66 2015-06-08 10:42:44 <mjerr> can be wrong of course
 67 2015-06-08 10:43:43 <gmaxwell> ...
 68 2015-06-08 10:45:06 <gmaxwell> they're saying it based on some text in the coinbase transaction that anyone could put there.
 69 2015-06-08 10:46:32 <mjerr> Yea, someone is abusing it though..
 70 2015-06-08 10:48:33 <warren> anyone have a lot of testnet coins?
 71 2015-06-08 10:58:24 <warren> bitcoin-cli getbalance "*" 0  <--- Is this command supposed to show 0-conf transactions owned by the local wallet?  It doesn't work in 0.10.2
 72 2015-06-08 10:58:29 <warren> I know it worked back in 0.8
 73 2015-06-08 11:00:26 <warren> bitcoin-cli getbalance "" 0 <--- actually this works
 74 2015-06-08 11:06:41 <jonasschnelli> warren: 0.8 is pretty old. :) did you test with 0.9.5 and 0.10.0?
 75 2015-06-08 11:06:46 <jonasschnelli> test/compare
 76 2015-06-08 11:10:30 <warren> jonasschnelli: I've been away for a while
 77 2015-06-08 11:10:48 <sipa> warren: welcome back then :D
 78 2015-06-08 11:10:50 <warren> "*" used to work and it broke at some point, I don't know if that was a bug or intentional.
 79 2015-06-08 11:11:12 <jonasschnelli> what if you use ""?
 80 2015-06-08 11:11:17 <warren> "" works
 81 2015-06-08 11:11:25 <sipa> warren: may have been due to the doublespending/malleability protection added in... i forget what version
 82 2015-06-08 11:11:38 <jonasschnelli> Yes. "*" should work after... maybe file a issue and write a PR?
 83 2015-06-08 11:11:58 <warren> sipa: huh?  malleability has nothing to do with the accounts
 84 2015-06-08 11:12:00 <jonasschnelli> should work after the documentation/help
 85 2015-06-08 11:12:05 <sipa> also, does -spendzeroconfchange change anything?
 86 2015-06-08 11:12:25 <sipa> oh, default is true, never mind
 87 2015-06-08 11:12:29 <warren> (accounts ... the thing I wish bitcoin core didn't have.  it's never been useful IMHO.)
 88 2015-06-08 11:12:40 <sipa> they're scheduled for deprecation
 89 2015-06-08 11:13:25 <warren> I'll figure out when it stopped working
 90 2015-06-08 14:13:41 <dhill> who runs testnet3 dns seed testnet-seed.alexykot.me ?
 91 2015-06-08 14:40:16 <wumpus> Alex Kotenko (added by aschildbach)
 92 2015-06-08 15:02:25 <dgenr8> warren: getbalance "*" only includes balances with a non-blank account
 93 2015-06-08 15:30:02 <dgenr8> warren: that was wrong... getbalance("*") is equivalent to bare getbalance().  both include everything
 94 2015-06-08 15:31:39 <andytoshi> i've got a script which monitors new git commits by checking `git log origin/master --not master` .. is there a way that i can monitor topic branches with this without doing anything ugly to the script
 95 2015-06-08 15:31:52 <andytoshi> like, can i make my `origin/master` label actually reference origin/topicbranch?
 96 2015-06-08 15:32:01 <dgenr8> warren: just verified the same problem with minconf parameter getbalance "*" 0 in v0.10.999
 97 2015-06-08 16:00:25 <StephenM347> andytoshi: you can rename a remote, and then rename it back to origin
 98 2015-06-08 16:03:13 <andytoshi> StephenM347: i don't wanna rename the remote, i wanna rename the branch
 99 2015-06-08 16:03:39 <andytoshi> that is `origin/master` should point at `origin/topic`
100 2015-06-08 16:04:43 <StephenM347> andytoshi: So couldn't you rename origin/master to origin/temp, and rename origin/topic to origin/master?
101 2015-06-08 16:05:09 <andytoshi> StephenM347: how do i do that?
102 2015-06-08 16:05:51 <StephenM347> git remote rename origin temp
103 2015-06-08 16:06:21 <StephenM347> ehh, maybe not
104 2015-06-08 16:06:41 <StephenM347> (maybe not what you're looking for, actually)
105 2015-06-08 16:08:44 <andytoshi> yeah, not quite :/
106 2015-06-08 17:53:58 <Anduck> would there be any idea to be able to download blockchain but skip the verifying?
107 2015-06-08 17:54:28 <Anduck> i could point my node to connect to my another node - so i know i get valid data and don't need verifying
108 2015-06-08 17:55:36 <hulkhogan_> Anduck: i recently had to move my node to another device and encountered this, i copied ~/.bitcoin/chainstate and ~/.bitcoin/blocks into the new node's ~/.bitcoin dir and it effectively let me skip verification for initial sync
109 2015-06-08 17:55:37 <Anduck> low power cpu's are taking very long time to download & verify the chain. been like over a week now
110 2015-06-08 17:55:40 <phantomcircuit> Anduck, you've basically just described an spv client
111 2015-06-08 17:55:49 <Anduck> phantomcircuit: no, not spv
112 2015-06-08 17:56:04 <phantomcircuit> Anduck, only thing i can think of that's sane is to add your own checkpoint
113 2015-06-08 17:56:06 <hulkhogan_> Anduck: I did this on a RPI/Beaglebone so it would have taken a awhile using the p2p network
114 2015-06-08 17:56:19 <Anduck> hulkhogan_: that's a good idea. should've done that =)
115 2015-06-08 18:35:20 <StephenM347> RPC call sendtoaddress doesn't include any fee, what's the reason for this?
116 2015-06-08 18:37:45 <sipa> because fee is meaningfully specified as a value per byte, and the byte size isn't known in advantage
117 2015-06-08 18:37:52 <sipa> it's computed using the txfee setting
118 2015-06-08 18:38:59 <StephenM347> oic, the -txfee command line arg? Is there a way to set the -txfee (which is actually fee per kb?) via RPC?
119 2015-06-08 18:39:11 <sipa> not afaik
120 2015-06-08 18:39:25 <sipa> i also don't know how it integrates with the fee estimation code
121 2015-06-08 18:47:05 <gavinandresen> StephenM347 sipa : the settxfee RPC call overrides all automatic fee estimation, and says "I want to pay THIS many BTC per kilobyte transaction size"
122 2015-06-08 18:47:47 <sipa> gavinandresen: oh, good to know!
123 2015-06-08 18:48:52 <ajweiss> there's also an estimatefee rpc call that gives you the estimates
124 2015-06-08 18:49:26 <StephenM347> gavinandresen: Thanks!
125 2015-06-08 19:04:21 <StephenM347> gavinandresen: is there a way to get the current value of the -txfee param?
126 2015-06-08 19:09:53 <harding> StephenM347: I think it's in getinfo or getwalletinfo
127 2015-06-08 19:11:05 <StephenM347> harding: sure enough, getinfo has a paytxfee property with the value. Thanks!
128 2015-06-08 19:13:02 <harding> StephenM347: if it's also in getwalletinfo, you're probably better off using that as getinfo (or parts thereof) are more likely to be removed in the future.
129 2015-06-08 19:13:45 <harding> Hmm.  I guess it isn't in getwalletinfo.  It should be somewhere else...
130 2015-06-08 19:14:52 <harding> Checked the docs, it doesn't seem to be.  Sorry.
131 2015-06-08 19:16:16 <StephenM347> harding: Seems like something that maybe should be added to getwalletinfo, though
132 2015-06-08 19:16:33 <gavinandresen> yes, should be added to getwalletinfo.  Good first project for a newbie developer....
133 2015-06-08 19:16:46 <sipa> ack
134 2015-06-08 19:18:23 <StephenM347> gavinandresen: sipa: I'm on it :)
135 2015-06-08 19:19:25 <StephenM347> (not a newbie to C++, just don't have intimate familiarity with all of the bitcoin core code)
136 2015-06-08 19:19:35 <gavinandresen> StephenM347: if you want to make us REALLY happy and impressed, add a regression test to qa/rpc-tests that exercises settxfee (including settxfee 0 to go back to "I trust your estimates")
137 2015-06-08 19:24:15 <shurnormal> If a branch isn't fully merged, does that mean it's still undeprecated?
138 2015-06-08 19:26:11 <maraoz> would a bitcoin core node respond to a reorg > 500 blocks correctly?
139 2015-06-08 19:26:30 <Amer> hi
140 2015-06-08 19:26:55 <Amer> how can i be part of bitcoin :D
141 2015-06-08 19:27:13 <sipa> maraoz: it should
142 2015-06-08 19:27:29 <sipa> at least recent versions
143 2015-06-08 19:27:35 <sdaftuar> i have noticed a situation where 0.9 could have trouble with such a reorg
144 2015-06-08 19:27:41 <sipa> oh definitely
145 2015-06-08 19:28:03 <sipa> it was broken for a long time, before headers-first
146 2015-06-08 19:28:29 <sipa> and even with headers-first, there were some performance issues afaik, where mempool management made very long reorgs very slow
147 2015-06-08 19:30:08 <maraoz> sipa: thanks. yeah I thought without headers first it would not be able to handle it.
148 2015-06-08 19:30:34 <sipa> maraoz: it's been broken in various ways
149 2015-06-08 19:31:03 <sipa> a long time ago it was broken because the getblocks/inv cycle actually failed to learn about enough blocks to trigger the reorg
150 2015-06-08 19:47:21 <StephenM347> The getnetworkinfo, getblockchaininfo, and getwalletinfo results do not include the errors field that getinfo contains. Is this intentional, or should it be updated?
151 2015-06-08 19:48:04 <sipa> that should be fixed too
152 2015-06-08 19:48:34 <StephenM347> sipa: I'll do it in the same PR then
153 2015-06-08 20:01:52 <shurnormal> Then is 0.9 deprecated or not? Is there any wiki page or updated board covering the status of branches?
154 2015-06-08 20:03:08 <sipa> 0.9 is still being maintained for some critical fixes
155 2015-06-08 20:03:51 <sipa> though this is more on a "crap, people are still using it and can't easily upgrade" basis, not a "we commit to maintaining that branch"
156 2015-06-08 20:08:51 <Luke-Jr> shurnormal: despite some fixes being backported, only the most recent release ever receives enough testing to be recommended
157 2015-06-08 20:11:43 <shurnormal> Ah nice to know. And thanks to the team for the .9 support o/
158 2015-06-08 20:12:39 <sipa> shurnormal: what do you need 0.9 for?
159 2015-06-08 20:13:20 <StephenM347> sipa: is there a README on running the python qa? I don't see one. Running it with python 2 and getting 'Symbol not found: __ZN5boost10filesystem6detail9copy...'
160 2015-06-08 20:13:43 <shurnormal> I just laze on checking out branches, if you want to deprecate .9 you have all my blessing.
161 2015-06-08 20:13:52 <shurnormal> [trollface]
162 2015-06-08 20:14:58 <sipa> shurnormal: consider 0.9 hereby deprecated
163 2015-06-08 20:18:19 <shurnormal> awww,.. that machine compiles so fuc slowly
164 2015-06-08 20:34:37 <StephenM347> I'm running '/usr/bin/python2.7 ./qa/rpc-tests/wallet.py' and getting some file system errors, anyone have any insight on this? Is this not how to run a test?
165 2015-06-08 20:52:20 <gavinandresen> StephenM347: cd qa/rpc-tests then run from there.  If you want to run from another directory, you have to tell the test where to find the bitcoind / bitcoin-cli executables.
166 2015-06-08 20:54:42 <harding> StephenM347: https://github.com/bitcoin/bitcoin/tree/master/qa/rpc-tests also says you can do qa/pull-tester/rpc-tests.sh <testname>
167 2015-06-08 20:57:17 <StephenM347> gavinandresen: harding: thanks, working now!
168 2015-06-08 21:31:23 <Luke-Jr> petertodd: if (chainparams.RequireStandard() && GetArg("-acceptnonstdtxn", false))  return InitError(_("acceptnonstdtxn is not currently supported for %s chain", chainparams.strNetworkID));
169 2015-06-08 22:44:21 <petertodd> Luke-Jr: mind re-posting that to the pull-req thread, so I can respond there?
170 2015-06-08 22:44:43 <petertodd> Luke-Jr: (would prefer to keep discussion in one place; it's a reasonable suggestion)
171 2015-06-08 22:45:49 <Luke-Jr> petertodd: done
172 2015-06-08 22:58:37 <flound1129> wumpus: will do
173 2015-06-08 22:58:44 <flound1129> I already deleted them, trying to sync again
174 2015-06-08 22:58:45 <flound1129> though
175 2015-06-08 22:58:56 <flound1129> it's happened the last 3 times so hopefully I'll be able to reproduce
176 2015-06-08 23:00:18 <flound1129> it did look like it was a bad peer (there were misbehaving peer messages in the log earlier) but it kept looping instead of banning the peer
177 2015-06-08 23:46:27 <petertodd> Luke-Jr: thanks!