1 2016-09-28 06:10:10	0|GitHub190|13bitcoin/06master 14fa4bfb4 15MarcoFalke: [wallet, policy] ParameterInteraction: Don't allow 0 fee
  2 2016-09-28 06:10:10	0|GitHub190|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/fc4f4547b7f6...14b7b3fb9f79
  3 2016-09-28 06:10:11	0|GitHub190|13bitcoin/06master 1414b7b3f 15Wladimir J. van der Laan: Merge #8814: [wallet, policy] ParameterInteraction: Don't allow 0 fee...
  4 2016-09-28 06:10:27	0|GitHub50|[13bitcoin] 15laanwj closed pull request #8814: [wallet, policy] ParameterInteraction: Don't allow 0 fee (06master...06Mf1607-walletHighFeeWarn) 02https://github.com/bitcoin/bitcoin/pull/8814
  5 2016-09-28 09:58:26	0|jl2012|when I'm working on rpctests, sometimes the node will generate empty blocks despite the mempool is not empty. It usually happens when the transactions in mempool are big. Why would that happen and how could I force it to mine those txs?
  6 2016-09-28 09:59:11	0|gmaxwell|will it continue to mine empty blocks, not just a one time event?
  7 2016-09-28 10:02:43	0|sipa|jl2012: perhaps an interaction between max block size an cpfp mining?
  8 2016-09-28 10:03:32	0|sipa|if you build a chain of dependent transactions that does not actually fit in a block
  9 2016-09-28 10:04:09	0|gmaxwell|and then there is nothing else to include other than that chain.
 10 2016-09-28 10:04:54	0|jl2012|all parents are confirmed. And keep mining empty blocks
 11 2016-09-28 10:07:31	0|jl2012|oh, not really keeping mining empty blocks forever
 12 2016-09-28 10:08:44	0|jl2012|there is only 1 tx in mempool, but it'd cleanup the mempool only if I generate about 500 blocks
 13 2016-09-28 10:09:31	0|luke-jr|fee too low, so it's waiting for priority?
 14 2016-09-28 10:09:34	0|sipa|anything particular about this tx?
 15 2016-09-28 10:09:50	0|jl2012|about 80kB
 16 2016-09-28 10:10:21	0|jl2012|luke-jr: so it'd rather mining empty blocks, than mining a tx with insufficient fee?
 17 2016-09-28 10:10:56	0|luke-jr|jl2012: it shouldn't happen with the current code afaik, but that's what it sounds like if it's mining it after blocks
 18 2016-09-28 10:11:00	0|luke-jr|I assume there's no locktime?
 19 2016-09-28 10:11:12	0|jl2012|no locktime
 20 2016-09-28 10:12:17	0|sipa|so after 500 blocks, it does mine it?
 21 2016-09-28 10:12:35	0|jl2012|yes, about 400 blocks. I'm try to find the exact number
 22 2016-09-28 10:13:34	0|gmaxwell|"Interesting"
 23 2016-09-28 10:14:23	0|sipa|is the height it activates a nice multiple of 144 after the activation of segwit?
 24 2016-09-28 10:16:08	0|jl2012|well, I find something more strange
 25 2016-09-28 10:16:19	0|jl2012|https://www.irccloud.com/pastebin/QiFCc6YN/
 26 2016-09-28 10:16:43	0|gmaxwell|whats that?
 27 2016-09-28 10:17:07	0|jl2012|I have a loop. Each round it generates 1 block, and print the results of getrawmempool
 28 2016-09-28 10:17:30	0|luke-jr|so it's being pruned and then re-accepted? O.o
 29 2016-09-28 10:17:50	0|jl2012|i will push the code, wait
 30 2016-09-28 10:22:36	0|jl2012|https://github.com/jl2012/bitcoin/blob/sighashpolicy-test/qa/rpc-tests/sighashlimit.py#L161
 31 2016-09-28 10:24:28	0|sipa|jl2012: heh
 32 2016-09-28 10:26:04	0|jl2012|it was it's just generate 1 block, print the mempool
 33 2016-09-28 10:26:15	0|jl2012|nothing strange
 34 2016-09-28 10:27:34	0|jl2012|from the output i assume it was mined at the 11th block, but it re-appeared after that
 35 2016-09-28 10:27:48	0|sipa|that's not possible...
 36 2016-09-28 10:27:55	0|sipa|or shouldn't be possible
 37 2016-09-28 10:28:07	0|sipa|its inputs are spent after mining it
 38 2016-09-28 10:28:33	0|jl2012|by the way the tx is not segwit
 39 2016-09-28 10:29:07	0|jl2012|maybe i should really see if it is really mined. But that's kind of random
 40 2016-09-28 10:29:42	0|sipa|you can call gettransaction to see its number of confirmations, if the transaction applies to the local wallet
 41 2016-09-28 10:30:29	0|jl2012|that's not. But I could read the content of blocks
 42 2016-09-28 10:31:12	0|gmaxwell|how do these tests mine?
 43 2016-09-28 10:31:33	0|gmaxwell|IIRC getblocktemplate can cache templates.
 44 2016-09-28 10:32:17	0|jl2012|gmaxwell, the mempool has only 1 tx, if the mempool is cleaned up after mining one block, the tx is not mined (i suppose)
 45 2016-09-28 10:37:56	0|warren|btcdrak: wow
 46 2016-09-28 10:42:02	0|btcdrak|warren: I assume you are referring to this "<cfields_> wumpus: i've added thin toolchain builders to depends that rid us of the ubuntu toolchain dependency. Only needed once for bootstrap, then we're self-hosted"
 47 2016-09-28 10:43:33	0|warren|cfields_: can the same binary result be reached from another distro's toolchain?
 48 2016-09-28 10:43:47	0|phantomcircuit|luke-jr: there seems to be a bug in getblocktemplate
 49 2016-09-28 10:43:55	0|phantomcircuit|running master
 50 2016-09-28 10:43:56	0|phantomcircuit|"coinbasevalue": 333038622,
 51 2016-09-28 10:44:00	0|phantomcircuit|2016-09-28 10:43:08 ERROR: ConnectBlock(): coinbase pays too much (actual=332777360 vs limit=312500000)
 52 2016-09-28 10:44:04	0|phantomcircuit|(this is on testnet)
 53 2016-09-28 10:44:15	0|sipa|phantomcircuit: ugh!
 54 2016-09-28 10:44:25	0|phantomcircuit|or possibly im just not including transactions?
 55 2016-09-28 10:44:27	0|luke-jr|phantomcircuit: in or outside the context of jl2012's stuff?
 56 2016-09-28 10:44:31	0|phantomcircuit|hmm
 57 2016-09-28 10:44:41	0|phantomcircuit|this seems like im not including transactions actually
 58 2016-09-28 10:44:57	0|sipa|phantomcircuit: that would explain
 59 2016-09-28 10:46:23	0|phantomcircuit|im just guessing based on the difference
 60 2016-09-28 10:47:10	0|jl2012|sorry, seems just a bug in my code
 61 2016-09-28 10:47:14	0|luke-jr|>_<
 62 2016-09-28 10:47:22	0|jl2012|false alarm
 63 2016-09-28 10:47:27	0|sipa|jl2012: goox
 64 2016-09-28 10:47:28	0|sipa|good
 65 2016-09-28 10:47:59	0|jl2012|I have 2 nodes. I generated blocks in one, and the other one is not synced
 66 2016-09-28 10:48:29	0|jl2012|so sometimes it will generate a block with the new tx, but the block is then get orphaned
 67 2016-09-28 10:48:36	0|jl2012|and the tx is returned to the mempool
 68 2016-09-28 10:54:24	0|gmaxwell|jl2012: oh obvious. Good.
 69 2016-09-28 11:34:27	0|wumpus|should I move/clone https://github.com/laanwj/bitcoin-maintainer-tools into bitcoin-core?
 70 2016-09-28 11:41:32	0|sipa|i wonder if we shouldn't try to integrate a buildinfo-less mode into the source tree itself
 71 2016-09-28 11:42:03	0|sipa|./configure --disable-buildinfo
 72 2016-09-28 11:52:21	0|wumpus|maybe, but this is just an experiment for now
 73 2016-09-28 11:53:10	0|wumpus|I don't think that's an argument against the tool though?
 74 2016-09-28 11:54:54	0|sipa|sure, just making an unrelated comment
 75 2016-09-28 11:55:28	0|sipa|but in general of things are useful for the project jn general, i think they should be in repo
 76 2016-09-28 11:55:38	0|wumpus|having it outside the source tree has its advantages, it means easier experimentation, quicker iteration etc
 77 2016-09-28 11:55:44	0|wumpus|not everything having to go through series of ACK
 78 2016-09-28 11:55:53	0|wumpus|these are just my private tools anyhow
 79 2016-09-28 11:56:20	0|wumpus|I think I tend to disagree with that in practice, not everything has to be in the repo
 80 2016-09-28 11:57:23	0|wumpus|sure, if something is needed all the time like the github-merge script it makes sense to have it in the repo
 81 2016-09-28 11:58:01	0|wumpus|although even of that I have my own version, which I incidentally make improvements to, once there's enough I'll file a PR. But having to do that all the time gives a lot of overhead for everyone involved.
 82 2016-09-28 11:58:51	0|wumpus|I have some other scripts too, a few other code analysis tools, and to build release notes, author lists etc. All can be useful, but it's pretty much a meta-project to bitcoin itself.
 83 2016-09-28 12:00:17	0|wumpus|it isn't part of the bitcoin core release cycle either
 84 2016-09-28 12:00:44	0|wumpus|changes can happen any time, even between rcs, or between rc and final
 85 2016-09-28 12:00:53	0|sipa|fair enough
 86 2016-09-28 12:01:04	0|sipa|no objection to moving it to bitcoin-core bte
 87 2016-09-28 12:01:07	0|sipa|*btw
 88 2016-09-28 12:01:54	0|wumpus|thanks
 89 2016-09-28 12:02:56	0|wumpus|I also think we can just be more liberal with changes in a tools repo. If you think something is useful, just do it, no need for long review cycles etc.
 90 2016-09-28 12:04:11	0|sipa|right, agree
 91 2016-09-28 12:04:12	0|wumpus|(or maintaining a listof 130 PRs *despairs*)
 92 2016-09-28 13:21:27	0|jonasschnelli|BlueMatt: A nice... was looking through the code and couldn't find the Auth/MAC
 93 2016-09-28 13:23:43	0|BlueMatt|jonasschnelli: in UDPMessageHeader - chk1 and chk2
 94 2016-09-28 13:24:24	0|BlueMatt|those are just the hash of the message = the magic (yea, yea, not how you're supposed to do a MAC....whatever)
 95 2016-09-28 13:24:29	0|BlueMatt|s/=/+/
 96 2016-09-28 13:25:49	0|BlueMatt|see FillChecksum
 97 2016-09-28 13:26:04	0|jonasschnelli|need to checkout first,... github not searchable on forks. :(
 98 2016-09-28 13:26:28	0|BlueMatt|its all in one file, you can just read that :p
 99 2016-09-28 13:27:27	0|jonasschnelli|wasn't aware of udpnet.cpp :)
100 2016-09-28 13:27:34	0|jonasschnelli|FillChecksum(std::get<3>(msg), std::get<1>(msg), std::get<2>(msg));
101 2016-09-28 13:27:50	0|jonasschnelli|std::get<3>(msg) is a key or something?
102 2016-09-28 13:28:02	0|sipa|it gets the 3rd element of a tuple
103 2016-09-28 13:28:30	0|jonasschnelli|Yes.
104 2016-09-28 13:28:34	0|jonasschnelli|its declared as a uint64_t
105 2016-09-28 13:28:43	0|jonasschnelli|Wonder how it gets popuplated
106 2016-09-28 13:30:30	0|jonasschnelli|Or is FillChecksum(uint64_t magic, UDPMessage& msg, const unsigned int length) similar to our TCP p2p message packeges where magic is the network magic?
107 2016-09-28 13:33:41	0|jonasschnelli|Okay. Got it...
108 2016-09-28 13:33:55	0|jonasschnelli|UDPConnectionInfo.local_magic gets populated through addudpnode
109 2016-09-28 13:34:06	0|jonasschnelli|Yes. Thats a nice simple auth
110 2016-09-28 13:41:48	0|wumpus|yes
111 2016-09-28 14:06:09	0|jonasschnelli|Maybe I missed something: whats the reason why importmulti requires a scriptPubKey https://github.com/bitcoin/bitcoin/pull/7551/files#diff-522490d83dce5375d423b23886e4125eR979?
112 2016-09-28 14:06:23	0|jonasschnelli|Can't I just import pubkeys?
113 2016-09-28 14:06:47	0|GitHub61|13bitcoin/06master 14ac01ff2 15Wladimir J. van der Laan: doc: Add privacy recommendation when running hidden service
114 2016-09-28 14:06:47	0|GitHub61|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/14b7b3fb9f79...7b05af634be4
115 2016-09-28 14:06:48	0|GitHub61|13bitcoin/06master 147b05af6 15Wladimir J. van der Laan: Merge #8823: doc: Add privacy recommendation when running hidden service...
116 2016-09-28 14:07:02	0|GitHub121|[13bitcoin] 15laanwj closed pull request #8823: doc: Add privacy recommendation when running hidden service (06master...062016_09_tor_recommendation) 02https://github.com/bitcoin/bitcoin/pull/8823
117 2016-09-28 14:07:16	0|sipa|jonasschnelli: yes, you can, but it's hard to create an API that always has expected results
118 2016-09-28 14:07:41	0|sipa|we have so many different ways through which we can start treating a particular script as ours
119 2016-09-28 14:07:47	0|sipa|maybe it's an imported address
120 2016-09-28 14:08:06	0|sipa|maybe it is p2sh for a redeemscript that contains something we know
121 2016-09-28 14:08:12	0|sipa|maybe we have the private key
122 2016-09-28 14:08:17	0|sipa|maybe we have a pubkey
123 2016-09-28 14:08:45	0|sipa|i think it's impossible to explain all those conditions
124 2016-09-28 14:08:51	0|sipa|so what does 'importing a pubkey' mean
125 2016-09-28 14:09:23	0|jonasschnelli|Yes. I see your point.
126 2016-09-28 14:09:25	0|sipa|should it make sends to that pubkey spendable? or also p2pkh involving those keys? what about a 1-of-3 multisig that involves those keys?
127 2016-09-28 14:09:38	0|sipa|by forcing the user to state exactly what they want, you avoid that
128 2016-09-28 14:09:52	0|sipa|and you can check whether you can provide the functionality they're asking for
129 2016-09-28 14:10:20	0|jonasschnelli|But explicit requiring the scriptPubKey could be a little bit annoying if you just want to import a P2PKH key?!
130 2016-09-28 14:10:42	0|sipa|it's a compromise between convenience and clarity, yes
131 2016-09-28 14:11:25	0|jonasschnelli|A wait... there is an "address" option for the scriptPubKey... okay. let me continue the testing..
132 2016-09-28 14:11:34	0|jonasschnelli|Makes sense so far.
133 2016-09-28 14:11:37	0|sipa|also, if you just want a p2pkh, you should import just that address, and set watchonly
134 2016-09-28 14:11:59	0|jonasschnelli|Agree. A plain pubkey import is kind of unspecified.
135 2016-09-28 14:12:40	0|sipa|the idea is that 1) you state what you want to see made spendable/solvable/watching, and then 2) all necessary information to accomplish that (which may mean giving redeemscripts, or pubkeys, or private keys)
136 2016-09-28 14:12:55	0|sipa|and in the simplest cases, (2) is empty
137 2016-09-28 14:42:39	0|GitHub190|13bitcoin/06master 145776e8a 15fanquake: [depends] Fix Qt compilation with Xcode 8
138 2016-09-28 14:42:39	0|GitHub190|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/7b05af634be4...dc641415e75e
139 2016-09-28 14:42:40	0|GitHub190|13bitcoin/06master 14dc64141 15Wladimir J. van der Laan: Merge #8820: [depends] Fix Qt compilation with Xcode 8...
140 2016-09-28 14:42:54	0|GitHub22|[13bitcoin] 15laanwj closed pull request #8820: [depends] Fix Qt compilation with Xcode 8 (06master...06depends-qt-xcoderun) 02https://github.com/bitcoin/bitcoin/pull/8820
141 2016-09-28 14:42:59	0|GitHub163|[13bitcoin] 15paveljanik opened pull request #8826: Do not include env_win.cc on non-Windows systems (06master...0620160928_leveldb_no_win) 02https://github.com/bitcoin/bitcoin/pull/8826
142 2016-09-28 14:44:33	0|jonasschnelli|wumpus: IMO this is ready: https://github.com/bitcoin/bitcoin/pull/7551
143 2016-09-28 14:45:00	0|jonasschnelli|Maybe the help text is not perfect...
144 2016-09-28 14:45:03	0|wumpus|awesome
145 2016-09-28 14:45:08	0|wumpus|well, that can be improved later
146 2016-09-28 14:45:12	0|sipa|i'd like to review 7551 as well, but haven't found the time yet
147 2016-09-28 14:46:39	0|wumpus|ok
148 2016-09-28 14:46:40	0|jonasschnelli|Yes. No hurry.
149 2016-09-28 14:47:01	0|jonasschnelli|We should just make sure we merge is some month before 0.14 RC
150 2016-09-28 14:47:21	0|sipa|absolutely
151 2016-09-28 14:47:23	0|wumpus|yes, it is functionality that certainly needs to be in master for a while before the release
152 2016-09-28 14:47:35	0|wumpus|it's complex enough, I'm sure there are problems that will only be found in actual use
153 2016-09-28 14:47:59	0|jonasschnelli|Yes. Its relatively complex and could lead to coins lost in the worst case.
154 2016-09-28 14:51:02	0|wumpus|we reallly need it though. After a while we can then start to deprecate the whole zoo of other import calls.
155 2016-09-28 15:58:25	0|GitHub167|[13bitcoin] 15sdaftuar opened pull request #8827: [qa] Split up slow RPC calls to avoid pruning test timeouts (06master...06fix-pruning-timeout) 02https://github.com/bitcoin/bitcoin/pull/8827
156 2016-09-28 16:02:47	0|GitHub163|[13bitcoin] 15pstratem opened pull request #8828: Move CWalletDB::ReorderTransactions to CWallet (06master...062016-09-28-cwallet-reordertransactions) 02https://github.com/bitcoin/bitcoin/pull/8828
157 2016-09-28 17:40:15	0|GitHub184|[13bitcoin] 15jnewbery opened pull request #8829: Add bitcoin-tx JSON tests (06master...06test-bitcoin-tx-json) 02https://github.com/bitcoin/bitcoin/pull/8829
158 2016-09-28 17:52:52	0|GitHub21|[13bitcoin] 15jnewbery opened pull request #8830: [test] Add option to run bitcoin-util-test.py manually (06master...06test-bitcoin-util-manually) 02https://github.com/bitcoin/bitcoin/pull/8830
159 2016-09-28 17:54:06	0|pedrobranco|Hi, anyone is experiencing high disk space usage when running bitcoin tests (env. is osx)?
160 2016-09-28 17:55:48	0|wumpus|what is 'high disk space usage' these days?
161 2016-09-28 17:58:21	0|pedrobranco|62gb in temporary test folder
162 2016-09-28 17:59:29	0|wumpus|for the RPC tests I guess, not the unit tests?
163 2016-09-28 18:00:16	0|wumpus|does it at least clean up everything again? the RPC tests have recently been changed to execute tests in parallel, this also means that more disk space is required for the instances running at the same time
164 2016-09-28 18:00:46	0|pedrobranco|rpc tests only
165 2016-09-28 18:01:31	0|wumpus|you can reduce the parallelism with some command line option if it's too much
166 2016-09-28 18:01:51	0|pedrobranco|i have 80G free space and it uses it all before ending rpc tests.
167 2016-09-28 18:02:13	0|gmaxwell|62GB sounds like a lot, do the rpc tests really do that? seems implausable to me.
168 2016-09-28 18:02:21	0|pedrobranco|http://pastebin.com/ZDzxBLNF
169 2016-09-28 18:05:46	0|wumpus|try rpc-tests.py -parallel=1
170 2016-09-28 18:06:01	0|pedrobranco|sure
171 2016-09-28 18:06:57	0|GitHub87|[13bitcoin] 15pstratem opened pull request #8831: Replace CWalletDB::ReadKeyValue with CWallet::LoadKeyValue (06master...062016-09-28-cwallet-loadkeyvalue) 02https://github.com/bitcoin/bitcoin/pull/8831
172 2016-09-28 18:08:24	0|wumpus|I also doubt it uses tht much in /tmp though, I only have 22GB free there and never had issues
173 2016-09-28 18:09:14	0|wumpus|not sure how much the travis VMs have but it should be a comparable amount, not  a huge lot
174 2016-09-28 18:10:54	0|phantomcircuit|can someone check the travis issue on #8828 ?
175 2016-09-28 18:10:58	0|phantomcircuit|tests pass locally
176 2016-09-28 18:11:03	0|wumpus|or are these the 'extended tests'?
177 2016-09-28 18:13:38	0|phantomcircuit|oh wait they dont
178 2016-09-28 18:13:39	0|phantomcircuit|huh
179 2016-09-28 18:13:52	0|phantomcircuit|they *did*
180 2016-09-28 18:14:20	0|pedrobranco|with rpc-tests.py -parallel=1 i'm having the same issue. p2p-fullblocktest.py is creating the 65G folder
181 2016-09-28 18:14:49	0|pedrobranco|and fails on the test #133
182 2016-09-28 18:15:19	0|wumpus|which file is so big?
183 2016-09-28 18:15:41	0|wumpus|in your pastebin there's 65G test3jvyn0m1/45 and everything below it is *much* smaller
184 2016-09-28 18:15:55	0|wumpus|so it must be a file in the top levele dir
185 2016-09-28 18:17:23	0|pedrobranco|to continue the tests i had to removed the folder, but i will repeat to show a full disk usage.
186 2016-09-28 18:17:37	0|pedrobranco|*remove
187 2016-09-28 18:21:36	0|pedrobranco|http://pastebin.com/UAYvF1cY
188 2016-09-28 18:21:50	0|pedrobranco|still running tests...
189 2016-09-28 18:25:03	0|arubi|pedrobranco, out of curiosity, can you tell which test?  run `top`?  should be part of the command line
190 2016-09-28 18:25:28	0|wumpus|p2p-fullblocktest
191 2016-09-28 18:25:38	0|pedrobranco|^
192 2016-09-28 18:25:56	0|arubi|oh, I thought it was /still/ running, sorry
193 2016-09-28 18:26:05	0|pedrobranco|np
194 2016-09-28 18:26:05	0|wumpus|I had the same error on openbsd, but that was due to linking a crappy ndb implementation that only supports small files
195 2016-09-28 18:27:28	0|wumpus|test is still running here, disk usage looks fairly stable around ~2GB, at subtest 94 now
196 2016-09-28 18:28:05	0|wumpus|so I still wonder what file is growing so big there - I guess blocks.db?
197 2016-09-28 18:28:13	0|wumpus|(as it's above the node directories)
198 2016-09-28 18:29:08	0|pedrobranco|http://pastebin.com/1cawnCMJ
199 2016-09-28 18:29:29	0|pedrobranco|i will now run p2p-fullblocktest only
200 2016-09-28 18:30:55	0|wumpus|final size is 2.1G    /tmp/testyxoclyo1/14241 for p2p-fullblocktest.py -nocleanup
201 2016-09-28 18:32:01	0|jonasschnelli|I hope libevent does a 2.1.x release before our 0.14 (https://github.com/libevent/libevent/releases/)
202 2016-09-28 18:32:01	0|wumpus|blocks.db ends up at 1.1G, the rest goes to the node0 dir. So it must be something local there that causes some file to balloon, do you have any changes compared to master?
203 2016-09-28 18:32:28	0|wumpus|jonasschnelli: they have done 2.1.x releases, they're just in the beta phase
204 2016-09-28 18:32:58	0|jonasschnelli|Yes. I meant a stable one... so package managers like brew (on OSX) can pick this up
205 2016-09-28 18:33:13	0|wumpus|(finally, since last year or so, 2.1 has been in dev/alpha since 2009 or so...)
206 2016-09-28 18:33:33	0|pedrobranco|it is /var/folders/kt/t6rd1zxx7px8273wlb56c4340000gn/T/testo0lm0oh1/0/blocks.db that has 65G
207 2016-09-28 18:33:59	0|wumpus|pedrobranco: interesting. What OS, what version of python do you have?
208 2016-09-28 18:35:29	0|wumpus|what does 'import dbm.ndbm; print(dbm.ndbm.library)' in python3 print?
209 2016-09-28 18:35:55	0|pedrobranco|OSX 10.11.6 with xcode 7.3.1 , python -V = 2.7.12, python3 -V = 3.5.2
210 2016-09-28 18:35:58	0|pedrobranco|let me see
211 2016-09-28 18:36:17	0|pedrobranco|prints 'GNU gdbm'
212 2016-09-28 18:36:20	0|wumpus|uh oh
213 2016-09-28 18:36:56	0|wumpus|if it prints that on a BSD it probably means it is linked against the system's ndbm, BSDs have a ndbm implementation in their libc
214 2016-09-28 18:37:25	0|wumpus|in openbsd that's a very silly one that can handle up to 64kb files or so :) but on OSX probably different
215 2016-09-28 18:37:36	0|wumpus|let me find something to try for you
216 2016-09-28 18:38:19	0|pedrobranco|thanks for the help wumpus, but i need to leave now. i'll be back in a couple of hours.
217 2016-09-28 18:39:05	0|wumpus|pedrobranco:  see https://github.com/bitcoin/bitcoin/issues/8605 , that's my openbsd problem, if you replace dbm.ndbm with dbm.dumb it will probably work fine
218 2016-09-28 18:39:23	0|wumpus|(in qa/rpc-tests/test-framework/blockstore.py)
219 2016-09-28 18:40:15	0|wumpus|jonasschnelli: you're on OSX right? did you ever notice p2p-fullblocktest using exorbitant disk space?
220 2016-09-28 18:40:28	0|jonasschnelli|I can't remember when i last ran this test...
221 2016-09-28 18:40:30	0|jonasschnelli|let me try
222 2016-09-28 18:40:43	0|jonasschnelli|(currently compiling, will start in a min)
223 2016-09-28 18:40:51	0|wumpus|well it's part of the default pulltester run
224 2016-09-28 18:41:29	0|jonasschnelli|Yes. Never noticed big data dirs...
225 2016-09-28 18:41:36	0|jonasschnelli|But I have a 1GB SSD..
226 2016-09-28 18:41:42	0|jonasschnelli|TB
227 2016-09-28 18:41:43	0|jonasschnelli|:-)
228 2016-09-28 18:42:27	0|wumpus|BTW bitcoin core on FreeBSD nearly works out of the box with ports-provided development packages, not nearly the struggle it is on OpenBSD. Though I don't think I've run the RPC tests yet :)
229 2016-09-28 18:43:16	0|jonasschnelli|oh
230 2016-09-28 18:43:17	0|jonasschnelli|Unexpected exception caught during testing: error('cannot add item to database',)
231 2016-09-28 18:43:35	0|wumpus|hah there goes your 1TB SSD? :-)
232 2016-09-28 18:43:36	0|jonasschnelli|Got the exception after Test 94: PASS [132]
233 2016-09-28 18:43:46	0|jonasschnelli|25M	/var/folders/hp/kb9p9q8x4k3_z_ccy588hxrc0000gn/T/testhuweo6jb/15776
234 2016-09-28 18:43:46	0|jonasschnelli|du -sh /var/folders/hp/kb9p9q8x4k3_z_ccy588hxrc0000gn/T/testhuweo6jb/15776
235 2016-09-28 18:43:54	0|jonasschnelli|25MV
236 2016-09-28 18:43:55	0|jonasschnelli|MB
237 2016-09-28 18:44:03	0|jonasschnelli|Oh.. wait... 128GB
238 2016-09-28 18:44:17	0|jonasschnelli|Yes. Same issue. :)
239 2016-09-28 18:44:22	0|wumpus|:)
240 2016-09-28 18:45:03	0|wumpus|can you try the solution of https://github.com/bitcoin/bitcoin/issues/8605 ? e.g.  replace dbm.ndbm with dbm.dumb in qa/rpc-tests/test-framework/blockstore.py
241 2016-09-28 18:48:36	0|jonasschnelli|running with dbm.dump now
242 2016-09-28 18:49:30	0|jonasschnelli|again 128GB
243 2016-09-28 18:49:45	0|jonasschnelli|and the execp.
244 2016-09-28 18:51:28	0|wumpus|that's very strange. dbm.dumb should be a native python implementation if dbm, not affected by the OS
245 2016-09-28 18:53:20	0|jonasschnelli|Yes. I did change to "import dbm.dumb" in qa/rpc-tests/test_framework/blockstore.py
246 2016-09-28 18:53:22	0|wumpus|note that there are three occurences of "dbm.nbdm" in that file
247 2016-09-28 18:53:32	0|jonasschnelli|ah..
248 2016-09-28 18:53:48	0|luke-jr|uh, the Python tests are trying to use BDB directly? that's unlikely to be 4.8 even on Linux, right? O.o
249 2016-09-28 18:54:19	0|wumpus|luke-jr: that doesn't matter, they're not used to communicate with bitcoind nor used for a wallet
250 2016-09-28 18:54:35	0|luke-jr|oh
251 2016-09-28 18:54:39	0|wumpus|and no, they don't request bdb, they request *a* ndbm implementation, which happens to be bdb on linux
252 2016-09-28 18:55:00	0|wumpus|but on BSDs its the libc ndm implementation, which differs
253 2016-09-28 18:55:14	0|wumpus|anyhow please read back, I feel I'm repeating myself
254 2016-09-28 18:55:51	0|wumpus|jonasschnelli: same problem on freebsd (without .dumb patch) - the file becomes huge
255 2016-09-28 18:56:03	0|jonasschnelli|1GB now...
256 2016-09-28 18:56:16	0|jonasschnelli|(during pass 94)
257 2016-09-28 18:56:21	0|jonasschnelli|test 94
258 2016-09-28 18:56:24	0|wumpus|that's normal size
259 2016-09-28 18:57:21	0|jonasschnelli|I don't have the insight here. Is dbm BDB? Whats the difference between dumb and ndbm?
260 2016-09-28 18:57:26	0|jonasschnelli|(maybe I should read back)
261 2016-09-28 18:59:17	0|luke-jr|jonasschnelli: completely different implementation of a key-value database afaik (and different format ofc)
262 2016-09-28 18:59:28	0|jonasschnelli|https://docs.python.org/dev/library/dbm.html
263 2016-09-28 18:59:42	0|wumpus|they're all key-value stores, which offer the same high-level interface but differ under the hood
264 2016-09-28 18:59:50	0|jonasschnelli|Is the dumb module much slower? If no, why not use dump for the tests?
265 2016-09-28 19:00:06	0|jonasschnelli|*why not use dumb
266 2016-09-28 19:00:07	0|wumpus|I think dumb is much slower, that is what the manual says at least
267 2016-09-28 19:00:10	0|wumpus|I haven't *tried*
268 2016-09-28 19:00:14	0|wumpus|but it seems it's the safe choice
269 2016-09-28 19:00:36	0|jonasschnelli|Theres also a gnu version...
270 2016-09-28 19:00:49	0|luke-jr|gnu is GPL, but I'm not sure we care for Python tests
271 2016-09-28 19:01:07	0|wumpus|gah, we're not going to include it in our source tree
272 2016-09-28 19:01:16	0|wumpus|although BSDs generally don't haev that installed by default
273 2016-09-28 19:01:25	0|wumpus|but dumb works fine as a fallback
274 2016-09-28 19:01:42	0|wumpus|I think we should default to the current db for Linux, and on all BSD variants use dumb
275 2016-09-28 19:01:54	0|wumpus|or use dumb everywhere if the perfrmance is acceptable for this use
276 2016-09-28 19:02:36	0|jonasschnelli|Can you easy switch between dumb/db based on the platform in python? Probably yes.
277 2016-09-28 19:02:38	0|GitHub123|[13bitcoin] 15MarcoFalke opened pull request #8832: [rpc] throw JSONRPCError when utxo set can not be read (06master...06Mf1610-rpcUtxoFail) 02https://github.com/bitcoin/bitcoin/pull/8832
278 2016-09-28 19:03:06	0|wumpus|jonasschnelli: yes, they are just modules that have the same interface
279 2016-09-28 19:03:16	0|wumpus|easy enough to import as <something>
280 2016-09-28 19:07:45	0|wumpus|updated the issue https://github.com/bitcoin/bitcoin/issues/8605
281 2016-09-28 19:12:29	0|jonasschnelli|wumpus: re UTXO set streaming over rest
282 2016-09-28 19:12:37	0|jonasschnelli|Assertion failed: (valid_), function key, file leveldb/db/db_iter.cc, line 67.
283 2016-09-28 19:12:37	0|jonasschnelli|I get an assertion:
284 2016-09-28 19:13:18	0|wumpus|jonasschnelli: ok, maybe someting broke in the rebase, haven't looked at it much, will look at that later
285 2016-09-28 19:13:33	0|jonasschnelli|Thanks...
286 2016-09-28 21:49:46	0|pedrobranco|hi wumpus, so jonasschnelli has able to reproduce the same issue right?