1 2017-01-03 00:55:17	0|dviola|hello, the archlinux bitcoin-qt package maintainer builds bitcoin-qt using "--with-incompatible-bdb" and bdb 5.3.28, I have heard there could be potential problems by taking a wallet.dat that was created with newer bdb and then using it on a bitcoin-qt that was compiled with an older version of bdb, are there any tests I could run to know I won't run into issues?
  2 2017-01-03 01:00:25	0|phantomcircuit|dviola, 5.x has a different format than 4.8 which is not backwards compatible
  3 2017-01-03 01:00:35	0|phantomcircuit|if you open a wallet in 5.x it wont open in 4.x
  4 2017-01-03 01:00:45	0|phantomcircuit|so that's a one way trip
  5 2017-01-03 01:08:10	0|dviola|phantomcircuit: I see, so would it be better if I create the wallet using the bitcoin-qt builds from bitcoin.org?
  6 2017-01-03 01:09:23	0|dviola|I'm a little confused because I created a wallet.dat using Arch's build, then used the wallet.dat with bitcoin-qt from bitcoin.org, and it seems to have worked just fine, but I don't have funds in this wallet of course
  7 2017-01-03 01:09:36	0|dviola|I could still see the address and such
  8 2017-01-03 01:09:43	0|dviola|which was the same
  9 2017-01-03 01:15:12	0|dviola|just tested again
 10 2017-01-03 01:15:25	0|luke-jr|dviola: *using* the wallet.dat with bdb5 should break using it with bdb4.. no matter how it was created.
 11 2017-01-03 01:17:59	0|dviola|hrm
 12 2017-01-03 01:19:15	0|dviola|here's what I did: I installed bitcoin-qt with pacman, started a fresh ~/.bitcoin and wallet.dat, I created 5 addresses with name, etc. I copied the wallet.dat to my home dir, I downloaded bitcoin-qt from bitcoin.org, started that with the old wallet.dat and all the address were there
 13 2017-01-03 01:22:32	0|dviola|luke-jr: I understand, but isn't what I did the equivalent of what you said? I'm a little confused over this
 14 2017-01-03 01:27:25	0|dviola|let me show you something...
 15 2017-01-03 01:28:45	0|dviola|this is bitcoin-qt from archlinux (bdb 5.3.28): https://i.imgur.com/iL6MVB2.png
 16 2017-01-03 01:28:55	0|dviola|this is bitcoin-qt from bitcoin.org (bdb 4.8.x): https://i.imgur.com/G50bTJi.png
 17 2017-01-03 01:28:59	0|dviola|same wallet.dat
 18 2017-01-03 01:29:10	0|dviola|I can still read the data from wallet
 19 2017-01-03 01:29:42	0|dviola|I'm confused and I apologize if I should have asked in #bitcoin instead, please let me know if I should go there
 20 2017-01-03 01:31:04	0|luke-jr|dviola: are you sure Arch isn't using bdb4 for the wallet?
 21 2017-01-03 01:31:20	0|luke-jr|if both are installed, I think we prefer it even if incompatible-bdb is allowed via option
 22 2017-01-03 01:35:25	0|dviola|I'm sure, this is how they build it: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/bitcoin#n166
 23 2017-01-03 01:35:32	0|dviola|ldd shows this also: libdb_cxx-5.3.so => /usr/lib/libdb_cxx-5.3.so (0x00007f3aaa8bc000)
 24 2017-01-03 01:36:39	0|dviola|I asked Timothy Redaelli (archlinux bitcoin maintainer) and he said this: https://i.imgur.com/bfvsEcZ.png
 25 2017-01-03 01:42:54	0|dviola|not saying I don't believe what you just said, I guess I'm puzzled as to why it works
 26 2017-01-03 01:55:30	0|dviola|luke-jr: hrm, I only have bdb5 system-wide
 27 2017-01-03 02:04:43	0|dviola|even with an intact ~/.bitcoin it still works fine with both binaries
 28 2017-01-03 02:04:46	0|dviola|bdb4 and 5
 29 2017-01-03 02:05:11	0|dviola|I can see the info from getwalletinfo and do dumpwallet, etc
 30 2017-01-03 02:06:18	0|dviola|I wonder if there is a way to exhaust this and see where it starts to fail
 31 2017-01-03 03:27:08	0|gmaxwell|anyone interested in picking up #8660 ? it's a nice feature, but has gone fallow after main was killed.
 32 2017-01-03 03:27:10	0|gribble|https://github.com/bitcoin/bitcoin/issues/8660 | txoutsbyaddress index (take 2) by djpnewton · Pull Request #8660 · bitcoin/bitcoin · GitHub
 33 2017-01-03 03:28:53	0|gmaxwell|droark: it should just fail to even open, always did in the past.
 34 2017-01-03 03:29:44	0|gmaxwell|maybe some time in BDB 5 they changed the format to be backwards compatible if shut down cleanly?
 35 2017-01-03 03:59:23	0|phantomcircuit|gmaxwell, does it have to handle reorgs correctly?
 36 2017-01-03 04:00:47	0|phantomcircuit|i dont think it would actually if you were saving address -> [block hash/tx index/out index]
 37 2017-01-03 04:01:09	0|phantomcircuit|but that's maybe slightly bigger than just address > txout
 38 2017-01-03 04:07:00	0|phantomcircuit|oh it's just for the utxo?
 39 2017-01-03 04:07:03	0|phantomcircuit|yeah i guess
 40 2017-01-03 05:31:16	0|gmaxwell|phantomcircuit: it's just for the utxo set, the PR is somewhat poorly named!
 41 2017-01-03 05:48:12	0|CodeShark|utxosbyaddress? :)
 42 2017-01-03 05:48:55	0|CodeShark|utxosbyscriptpubkey might even be more useful
 43 2017-01-03 05:54:01	0|CodeShark|I might take a look at it, it is a pretty nice feature
 44 2017-01-03 05:55:27	0|gmaxwell|assuming the database is constructed correctly (lets hope) the difference between by address vs by scriptpubkey is purely a RPC parameter one.
 45 2017-01-03 05:55:55	0|CodeShark|yeah, indeed :)
 46 2017-01-03 05:56:08	0|CodeShark|but we don't have address formats for all scriptpubkey types
 47 2017-01-03 05:58:14	0|CodeShark|how big is the extra index here?
 48 2017-01-03 06:00:16	0|gmaxwell|CodeShark: should be roughly similar in size to the utxo set.
 49 2017-01-03 06:00:41	0|CodeShark|it's something of a reverse lookup, no?
 50 2017-01-03 06:00:58	0|CodeShark|when validating we need to grab scriptpubkey from blockhash:txindex
 51 2017-01-03 06:01:04	0|gmaxwell|right.
 52 2017-01-03 06:01:21	0|gmaxwell|I don't recall what it implements, but
 53 2017-01-03 06:01:34	0|CodeShark|or txhash:outindex, rather ;)
 54 2017-01-03 06:01:37	0|gmaxwell|e.g. it could map(h(scrippubkey)[64 bits]) -> [txid:vout,...]  which would potentially equal in size or smaller even though it's going to be more sparse.
 55 2017-01-03 06:01:54	0|gmaxwell|Well my right was responding to what you meant, of course.
 56 2017-01-03 06:02:58	0|gmaxwell|at least if I'd written this from scratch I would have done that kind of hash, probably with a per database salt to keep clowns from intentionally making your queries slow by causing collisions.
 57 2017-01-03 06:05:35	0|CodeShark|I'm a little ambivalent about using an in-process storage engine for things not required for full validation. I'd love to see an architecture with an external storage engine that can be configured for different kinds of queries. But I guess this index isn't too huge
 58 2017-01-03 06:07:21	0|CodeShark|pulling the consensus-critical stuff out to an external storage engine is perhaps a bit risky, though
 59 2017-01-03 06:07:37	0|CodeShark|and perhaps there are optimization issues as well here with the caching
 60 2017-01-03 06:07:47	0|CodeShark|I'm not too familiar with the cache stuff
 61 2017-01-03 06:09:30	0|CodeShark|the main advantage here is that different people could extend the functionality of the storage engine and queries supported without having to touch any consensus code at all
 62 2017-01-03 06:09:43	0|CodeShark|nor having to rebuild the validation engine
 63 2017-01-03 06:11:38	0|CodeShark|but we already have the existing RPC framework...which encourages just adding more in-process RPC calls
 64 2017-01-03 06:23:13	0|CodeShark|people always talk about keeping these indices external to bitcoind...but without a framework for it that people can easily extend everyone has to reinvent the wheel
 65 2017-01-03 06:24:19	0|CodeShark|...poorly :p
 66 2017-01-03 06:30:09	0|gmaxwell|You can always index whatever you want talking to things over the rpc. but there are plenty of uses for this just from the commandline.
 67 2017-01-03 06:32:39	0|CodeShark|no question it's useful. but there could be a bunch other useful queries for app developers (or even for interactive use from commandline) - and having to merge another in-process RPC call everytime is a bottleneck
 68 2017-01-03 06:33:50	0|CodeShark|or it encourages people to have to maintain their own forks of the entire project so they can customize it
 69 2017-01-03 06:35:16	0|CodeShark|as for an external index, we could get far better performance foregoing the RPC and using a different IPC
 70 2017-01-03 06:35:59	0|CodeShark|also, the indices could be built up during IBD
 71 2017-01-03 06:36:35	0|CodeShark|but these are longer term objectives - I still like this PR :)
 72 2017-01-03 07:59:52	0|jonasschnelli|Is it okay to use GPG's (v2.1+) Ed25516 or even secp256k1 keys for gitian signing?
 73 2017-01-03 08:00:13	0|jonasschnelli|*25519
 74 2017-01-03 08:01:33	0|wumpus|well, it's not forbidden, but I can't count them right now (my gpg is at 1.4.20, ubuntu 16.04 lts)
 75 2017-01-03 08:02:29	0|jonasschnelli|Yes. It's probably to early.
 76 2017-01-03 08:02:31	0|wumpus|I can look at compiling my own for 0.14, but not for 0.13.2 today
 77 2017-01-03 08:02:46	0|phantomcircuit|wumpus, you can install gnupg 2.x
 78 2017-01-03 08:02:50	0|phantomcircuit|it's like gnupg-2 or something
 79 2017-01-03 08:02:54	0|jonasschnelli|gpg2
 80 2017-01-03 08:02:59	0|wumpus|phantomcircuit: oh!
 81 2017-01-03 08:03:25	0|jonasschnelli|I may start with signing with Ed25519, just to have some variety.
 82 2017-01-03 08:03:45	0|gmaxwell|jonasschnelli: distributions ship the table version of gpg, mostly (exclusively?) so AFAICT relatively few people have it.
 83 2017-01-03 08:03:57	0|wumpus|phantomcircuit: jonasschnelli: that gets me 2.1.11
 84 2017-01-03 08:05:36	0|jonasschnelli|I guess for all ecdsa curves (including secp256k1) you need 2.1.16 (or 2.1.17?)
 85 2017-01-03 08:05:37	0|wumpus|gah, it doesn't use the debian alternatives system though, so I have to manually patch up scripts to use gpg2 instead of gpg
 86 2017-01-03 08:05:55	0|jonasschnelli|But watch out when using gpg2
 87 2017-01-03 08:06:01	0|jonasschnelli|It will upgrade you .gpg folder
 88 2017-01-03 08:06:10	0|jonasschnelli|And will no longer be backward comp.
 89 2017-01-03 08:06:15	0|jonasschnelli|So,... make a backup first
 90 2017-01-03 08:06:22	0|wumpus|oops
 91 2017-01-03 08:06:26	0|jcorgan|eww
 92 2017-01-03 08:06:36	0|jonasschnelli|maybe this was too late. :)
 93 2017-01-03 08:06:47	0|CodeShark|lol
 94 2017-01-03 08:06:52	0|wumpus|let's see :) I only looked at the help message, didn't encrypt anything yet
 95 2017-01-03 08:07:59	0|wumpus|good, v1 still works for verifying signatures
 96 2017-01-03 08:08:07	0|wumpus|I'll look at this for 0.14 okay
 97 2017-01-03 08:08:17	0|jonasschnelli|Yes. No hurry.
 98 2017-01-03 08:08:45	0|jonasschnelli|If secp256k1 is supported through GPG, this would allow signing over a hardware wallet without new curves added to them.
 99 2017-01-03 08:11:03	0|wumpus|yea that could be interesting, though it would have to assign a single purpose to keys, don't use keys for signing that are used for bitcoin
100 2017-01-03 08:11:16	0|jonasschnelli|Yes. Indeed.
101 2017-01-03 08:12:26	0|jonasschnelli|I'd also prefer Ed25519,... not supported by (all?) available hardware wallets I guess.
102 2017-01-03 08:15:00	0|wumpus|ed25519 would have the advantage it can be used for ssh too
103 2017-01-03 08:15:16	0|jonasschnelli|Oh. Yes.
104 2017-01-03 08:15:35	0|wumpus|(even if you compile it without openssl :p)
105 2017-01-03 08:16:05	0|jonasschnelli|Right. ed25519 & chacha20Poly1305@openssh. Nice combo.
106 2017-01-03 08:17:55	0|wumpus|yes
107 2017-01-03 08:32:33	0|bitcoin-git|13bitcoin/06master 149e351c9 15Jonas Schnelli: SetMerkleBranch: remove unused code, remove cs_main lock requirement
108 2017-01-03 08:32:33	0|bitcoin-git|[13bitcoin] 15jonasschnelli pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/53442af0aac3...510c0d9c79a5
109 2017-01-03 08:32:34	0|bitcoin-git|13bitcoin/06master 14510c0d9 15Jonas Schnelli: Merge #9446: SetMerkleBranch: remove unused code, remove cs_main lock requirement...
110 2017-01-03 08:32:50	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #9446: SetMerkleBranch: remove unused code, remove cs_main lock requirement (06master...062016/12/merklebranch) 02https://github.com/bitcoin/bitcoin/pull/9446
111 2017-01-03 08:59:32	0|wumpus|uploaded binaries and pushed 0.13.2 release announcement to the mailing lists, waiting for travis on bitcoin.org (https://github.com/bitcoin-dot-org/bitcoin.org/pull/1470), feel free to get the rest of the announcement cycle started
112 2017-01-03 09:02:11	0|gmaxwell|jonasschnelli: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-January/013397.html  A spv wallet should _never_ be showing transactions from untrusted peers.
113 2017-01-03 09:02:29	0|gmaxwell|jonasschnelli: because the peers can feed them any garbage they want and the spv client has no idea about it.
114 2017-01-03 09:02:52	0|jonasschnelli|(phonecall, will response soon)
115 2017-01-03 09:04:03	0|gmaxwell|and you get lovely results like https://people.xiph.org/~greg/21mbtc.png
116 2017-01-03 09:08:17	0|sipa|gmaxwell: but what if you trust a peer enough to not relay invalid txn, but not enough to not spy on you?
117 2017-01-03 09:08:44	0|jonasschnelli|gmaxwell: I see.
118 2017-01-03 09:09:09	0|jonasschnelli|I mentioned this in the bitcoin-dev mail, because users relay on it,... even if its fundamentally broken.
119 2017-01-03 09:09:23	0|sipa|rely
120 2017-01-03 09:09:36	0|jonasschnelli|rely. Thanks sipa. :)
121 2017-01-03 09:09:52	0|jonasschnelli|Also,... it looked like, that my feeler PR: https://github.com/bitcoin/bitcoin/pull/9238 did get some rejects.
122 2017-01-03 09:11:13	0|jonasschnelli|In a long shot, I could imagine, BFD (filter digest / filter commitments) for filtering from untrusted peers, and BIP39 for filtering from trusted peers (once BIP150 has ben established).
123 2017-01-03 09:11:25	0|jonasschnelli|Even if BIP39 is not the most efficient way.
124 2017-01-03 09:11:32	0|sipa|BIP39?
125 2017-01-03 09:11:35	0|sipa|are you sure?
126 2017-01-03 09:11:37	0|jonasschnelli|37! argh
127 2017-01-03 09:11:57	0|jonasschnelli|Bloom Filter
128 2017-01-03 09:13:19	0|jonasschnelli|But I think there is no solution for a non-BIP37 0-conf "filtering" without running into these privacy issues related to bip37
129 2017-01-03 09:13:35	0|gmaxwell|jonasschnelli: for your wokrin in 9238 just transfer all transactions, any filtering scheme will trash privacy, and transfering transactions is an aggregate of 14 kilobit/s.
130 2017-01-03 09:13:54	0|gmaxwell|But displaying unconfirmed transactions in any non-validating wallet is just an invite to abuse.
131 2017-01-03 09:14:37	0|gmaxwell|Many lite wallets that do this today are utterly crippled by it, because they also spend unconfirmed coins, so a single troublemaker giving them some fake payments makes them unusable. (or at least they did a half year ago.)
132 2017-01-03 09:15:13	0|jonasschnelli|gmaxwell: Yes. Agree. But the user-experience without displaying incoming funds will probably be not acceptable "in the field".
133 2017-01-03 09:15:27	0|gmaxwell|please.
134 2017-01-03 09:16:40	0|jonasschnelli|I don't know. I also don't like the 0-conf displaying. While working on the Core wallets SPV mode, I just had the feeling that people will not use it because of the missing 0-conf display.
135 2017-01-03 09:16:49	0|gmaxwell|I think it's a bad idea to release features that would require an emergency software update to disable them as soon as one board person spends an hour making a few like hack that sends out garbage transactions and spins up a bunch of sybil nodes.
136 2017-01-03 09:17:58	0|jonasschnelli|0-conf / spv should probably only be possible in conjunction with BIP150 and a trusted peer (at home or somewhere)
137 2017-01-03 09:18:36	0|gmaxwell|In any case, just send all the data. As mentioned it's 14kbit/sec.  The history is really the only annoying part about that.
138 2017-01-03 09:19:28	0|jonasschnelli|gmaxwell: do you mean send all the data if someone request a filtered mempool?
139 2017-01-03 09:19:36	0|jonasschnelli|or just for tv invs?
140 2017-01-03 09:19:40	0|jonasschnelli|*tx
141 2017-01-03 09:20:12	0|gmaxwell|I mean don't do any tx filtering.
142 2017-01-03 09:21:27	0|gmaxwell|Same as we do today. Please. implementing spv mode in core doesn't mean implementing all the flaws and vulnerabilities in other software slavishly. Thats pointless. If someone wants something that is going to blast out there addresses, validate nothing, etc.. they can already use bitcoinj based software.
143 2017-01-03 09:21:43	0|jonasschnelli|Heh. True.
144 2017-01-03 09:22:02	0|gmaxwell|:) at least the spv behavior in core can be private.
145 2017-01-03 09:22:12	0|jonasschnelli|I have implemented the BFD relevant hooks. IsBlockRelevantToWallet(pindex).
146 2017-01-03 09:23:41	0|jonasschnelli|gmaxwell: The only usability issues are: catch-up a couple of weeks (144*<day> MBs, take a while) and the missing 0-conf. Maybe this is acceptable to prevent privacy.
147 2017-01-03 09:24:52	0|gmaxwell|I think it's not bad, especially if we had better facilities for keeping it caught up in the background.
148 2017-01-03 09:24:57	0|jonasschnelli|Though, I haven't fully understood the semi.-trusted oracle idea for the BDF. I would expect to have the BDF in the coinbase...
149 2017-01-03 09:26:01	0|jonasschnelli|But somehow the BFD is required for older blocks as well
150 2017-01-03 09:26:11	0|gmaxwell|It's not really great to go from nothing to consensus rule if it can be avoided: No design survives first contact with users.  Better to prove out the idea and refine it before its required, which is possible here.
151 2017-01-03 09:27:30	0|jonasschnelli|From where would you get the BFD (maybe its not bloom filters in the end)? A new p2p command?
152 2017-01-03 09:28:15	0|gmaxwell|just another type of element that you can getdata, perhaps more than one.
153 2017-01-03 09:29:54	0|jonasschnelli|this would result in trusting the peer, right? The whole signing thing of BFDs would still be a thing? Or just compare BFDs from the data retrived from other peers?
154 2017-01-03 09:30:22	0|jonasschnelli|Probably easy to sybil you with fake data
155 2017-01-03 09:30:59	0|gmaxwell|I thought you were referring to the filter itselt and not the hash root... Unclear, multiple models are possible and _all_ are better than BIP37.
156 2017-01-03 09:31:40	0|jonasschnelli|Right, tx withhold is also possible with BIP37.
157 2017-01-03 09:32:19	0|gmaxwell|and asking multiple peers is very inefficient with BIP37.. needs n-times the bandwidth.
158 2017-01-03 09:33:20	0|jonasschnelli|good point.
159 2017-01-03 09:37:16	0|btcdrak|Requesting review for release blog post https://github.com/bitcoin-core/bitcoincore.org/pull/305
160 2017-01-03 09:40:25	0|gmaxwell|jonasschnelli: but pulling data from peers is just one option, you could-- for example-- go get a hash root (root of a tree of digest hashes) from a website and pop that into a configuration.
161 2017-01-03 09:41:11	0|gmaxwell|(and then use that for filtering the past-- then the future, past that root, you just fetch whole blocks)
162 2017-01-03 10:23:43	0|BlueMatt|cfields: ohhh, static CNodeState::cs....missed the static part
163 2017-01-03 10:24:30	0|BlueMatt|cfields: ok, I'll make it static in the pr and add a TODO: do something smarter
164 2017-01-03 10:24:39	0|BlueMatt|cfields: oh, wait, no, really dont want to do that
165 2017-01-03 10:26:37	0|BlueMatt|cfields: that would mean that #9375 + multithreaded processmessages wouldnt accomplish anything :/
166 2017-01-03 10:26:39	0|gribble|https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
167 2017-01-03 10:28:07	0|sipa|BlueMatt: but the same is true for the current code, no?
168 2017-01-03 10:28:15	0|sipa|which uses cs_main
169 2017-01-03 10:31:42	0|BlueMatt|sipa: no, I dont believe so, #9375 + #9419 + a fix for https://github.com/bitcoin/bitcoin/pull/9375#discussion_r94180477 (which just means making fWantsCmpctWitness atomic) + multithreaded ProcessMessages will work
170 2017-01-03 10:31:44	0|gribble|https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
171 2017-01-03 10:31:45	0|gribble|https://github.com/bitcoin/bitcoin/issues/9419 | Stop Using cs_main for CNodeState/State() by TheBlueMatt · Pull Request #9419 · bitcoin/bitcoin · GitHub
172 2017-01-03 10:33:10	0|sipa|BlueMatt: ah, i see
173 2017-01-03 10:33:16	0|BlueMatt|it may be the case that we dont need State() at all for that, though
174 2017-01-03 10:33:16	0|sipa|right
175 2017-01-03 10:35:39	0|BlueMatt|yea, no, so to make it all work we need to have a State()->fWantsCmpctWitness and pfrom->GetSendVersion() call without cs_main
176 2017-01-03 10:51:55	0|bitcoin-git|13bitcoin/060.13 1477eaadb 15Wladimir J. van der Laan: doc: Clean out release notes on 0.13.x branch...
177 2017-01-03 10:51:55	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/77eaadb6c9619370b09513fecba13cfe656d63d6
178 2017-01-03 10:52:58	0|bitcoin-git|13bitcoin/06master 1403e1d6c 15Wladimir J. van der Laan: doc: Add historical release notes for 0.13.2
179 2017-01-03 10:52:58	0|bitcoin-git|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02https://github.com/bitcoin/bitcoin/commit/03e1d6ce349cc83b92140fec7d0c5f88893c0a9c
180 2017-01-03 10:54:47	0|jonasschnelli|gmaxwell: thanks.
181 2017-01-03 10:55:24	0|jonasschnelli|gmaxwell: you mentioned here (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012637.html) a rough specs for a better filter structure then bloom
182 2017-01-03 10:55:31	0|jonasschnelli|Do you have any specification for that?
183 2017-01-03 10:59:32	0|BlueMatt|cfields: hmmm, regarding #9441, do we really want to run the entire ProcessMessages loop (calling SendMessages potentially umpteen times) just to process multiple messages from the same node?
184 2017-01-03 10:59:34	0|gribble|https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub
185 2017-01-03 10:59:51	0|BlueMatt|(ie remove the loop inside ProcessMessages and move it to ThreadProcessMessages)
186 2017-01-03 11:01:04	0|timothy|buiding bitcoin-core 0.13.2 on archlinux...
187 2017-01-03 11:03:20	0|sipa|BlueMatt: i was wondering about that too
188 2017-01-03 11:03:54	0|sipa|BlueMatt: but there is hardly any (contentious) locking going on anymore in between
189 2017-01-03 11:04:06	0|BlueMatt|yea, but SendMessages.....
190 2017-01-03 11:04:11	0|sipa|Ah.
191 2017-01-03 11:04:32	0|sipa|i hadn't considered that
192 2017-01-03 11:04:38	0|sipa|that defeats the purpose
193 2017-01-03 11:05:11	0|sipa|hmm, i was about to say that it negatively impacts batching of invs and addrs
194 2017-01-03 11:05:29	0|sipa|but since we have explicit random delays for those, i don't think that's really an issue anymore
195 2017-01-03 11:05:42	0|BlueMatt|yea, I dont think it breaks anything
196 2017-01-03 11:05:48	0|BlueMatt|just repeatedly calls SendMessages to do nothing
197 2017-01-03 11:06:13	0|sipa|oh, it won't break anything
198 2017-01-03 11:06:54	0|BlueMatt|I assume you didnt touch cs_vSend due to https://github.com/bitcoin/bitcoin/pull/9419/commits/c214d120a363a05ba9afdccff6b4bda6e29ae7c4, cfields?
199 2017-01-03 11:10:08	0|BlueMatt|cfields: other than that, I got through #9441 and it looks good to me
200 2017-01-03 11:10:10	0|gribble|https://github.com/bitcoin/bitcoin/issues/9441 | Net: Massive speedup. Net locks overhaul by theuni · Pull Request #9441 · bitcoin/bitcoin · GitHub
201 2017-01-03 11:17:15	0|sipa|thanks
202 2017-01-03 11:17:47	0|BlueMatt|sipa: cool, see you tomorrow afternoon
203 2017-01-03 11:17:57	0|BlueMatt|anyone else at RWC? sipa, cfields and I likely will be
204 2017-01-03 11:51:23	0|timothy|is MALLOC_ARENA_MAX=1 still "recommended" on linux?
205 2017-01-03 12:01:19	0|sipa|timothy: i expect that setting it so low may come with lower performancr
206 2017-01-03 12:01:29	0|sipa|but i don't think anyone ever benchmarked it
207 2017-01-03 12:03:18	0|sipa|it's certainly recommended if you are very tight on memory
208 2017-01-03 12:04:00	0|timothy|is -reindex-chainstate is faster than -reindex?
209 2017-01-03 12:04:07	0|timothy|without the second is :P
210 2017-01-03 12:09:34	0|sipa|yes
211 2017-01-03 12:09:55	0|sipa|but it only works when your blocks and blocks/index are not corrupted
212 2017-01-03 13:47:43	0|jonasschnelli|bitcoin-qt tells me today when running with a fresh datadir: "Last received block was generated 7 year(s) and 52 week(s) ago."
213 2017-01-03 13:49:33	0|wumpus|jonasschnelli: so it regards it as an edge case, 52 weeks but not a year yet. curious :)
214 2017-01-03 13:50:03	0|jonasschnelli|qint64 remainder = secs % YEAR_IN_SECONDS;
215 2017-01-03 13:50:11	0|jonasschnelli|Na. I don't fix that.
216 2017-01-03 13:50:32	0|wumpus|yeah it's silly but not a serious issue
217 2017-01-03 14:07:39	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #9460: Fix a few typos in translated strings (06master...062017_01_messages_update) 02https://github.com/bitcoin/bitcoin/pull/9460
218 2017-01-03 14:41:15	0|luke-jr|wumpus: btcdrak: bad signature on sendy release ann
219 2017-01-03 14:42:05	0|wumpus|luke-jr: are you checking the html or text attachment?
220 2017-01-03 14:43:11	0|wumpus|in case of the html you should run gpg on the raw html file
221 2017-01-03 14:43:21	0|wumpus|(both attachments verify OK here)
222 2017-01-03 14:44:06	0|luke-jr|both
223 2017-01-03 14:44:21	0|luke-jr|how do you run GPG on the raw HTML file, seeing as the HTML is outside the signature? :/
224 2017-01-03 14:44:39	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/03e1d6ce349c...e0dc3d70c6ec
225 2017-01-03 14:44:40	0|bitcoin-git|13bitcoin/06master 14a9d6151 15Wladimir J. van der Laan: qt,wallet: Fix a few typos in messages...
226 2017-01-03 14:44:40	0|bitcoin-git|13bitcoin/06master 14d45b21e 15Wladimir J. van der Laan: qt: Fill in English numerusforms...
227 2017-01-03 14:44:41	0|bitcoin-git|13bitcoin/06master 14e0dc3d7 15Wladimir J. van der Laan: Merge #9460: Fix a few typos in translated strings...
228 2017-01-03 14:44:55	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #9460: Fix a few typos in translated strings (06master...062017_01_messages_update) 02https://github.com/bitcoin/bitcoin/pull/9460
229 2017-01-03 14:44:55	0|btcdrak|luke-jr: matches for me
230 2017-01-03 14:45:08	0|wumpus|that mail has a text/plain as well as a text/html mime attachment - just save them to a file and run gpg on them?
231 2017-01-03 14:46:31	0|luke-jr|hmm, that works. I wonder what copy/paste is changing
232 2017-01-03 14:46:56	0|btcdrak|Thunderbird also automatically validated it for me.
233 2017-01-03 14:47:04	0|jonasschnelli|Same here
234 2017-01-03 14:47:13	0|luke-jr|my mail client normally auto-validates, but it didn't like the formatting or something
235 2017-01-03 14:53:44	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #9461: [Qt] Improve progress display during headers-sync and peer-finding (06master...062017/01/qt_sync) 02https://github.com/bitcoin/bitcoin/pull/9461
236 2017-01-03 15:14:51	0|jonasschnelli|luke-jr: I think squashing makes sense when one commit overwrites many lines from a former commit in the same PR.
237 2017-01-03 15:14:57	0|jonasschnelli|But Okay for #8877
238 2017-01-03 15:14:59	0|gribble|https://github.com/bitcoin/bitcoin/issues/8877 | Qt RPC console: history sensitive-data filter, and saving input line when browsing history by luke-jr · Pull Request #8877 · bitcoin/bitcoin · GitHub
239 2017-01-03 15:15:38	0|luke-jr|jonasschnelli: there are some cases where I think it may make sense, yes
240 2017-01-03 15:16:07	0|jonasschnelli|But your right, squashing and loosing "logical history" is not ideal
241 2017-01-03 15:20:10	0|jonasschnelli|can anyone give https://github.com/bitcoin/bitcoin/pull/8877 a final review?
242 2017-01-03 15:54:47	0|cfields|BlueMatt: yes, cs_vSend wasn't touched because of your PR. I've just been operating under the assumption that the lock around SendMessages will be removed by one PR or another.
243 2017-01-03 15:55:45	0|btcdrak|jonasschnelli: done.
244 2017-01-03 15:57:42	0|jonasschnelli|thanks btcdrak
245 2017-01-03 15:57:54	0|bitcoin-git|[13bitcoin] 15jonasschnelli pushed 12 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/e0dc3d70c6ec...6dc4c43d326e
246 2017-01-03 15:57:54	0|jonasschnelli|now I own you a review. :)
247 2017-01-03 15:57:55	0|bitcoin-git|13bitcoin/06master 14fc95daa 15Jonas Schnelli: Qt/RPCConsole: Save current command entry when browsing history...
248 2017-01-03 15:57:56	0|bitcoin-git|13bitcoin/06master 149044908 15Jonas Schnelli: Qt/RPCConsole: Don't store commands with potentially sensitive information in the history...
249 2017-01-03 15:57:56	0|bitcoin-git|13bitcoin/06master 14de8980d 15Luke Dashjr: Bugfix: Do not add sensitive information to history for real...
250 2017-01-03 15:58:06	0|bitcoin-git|[13bitcoin] 15jonasschnelli closed pull request #8877: Qt RPC console: history sensitive-data filter, and saving input line when browsing history (06master...06qt_console_history_filter) 02https://github.com/bitcoin/bitcoin/pull/8877
251 2017-01-03 16:02:10	0|jtimon|#9271 needs rebase but could still get some general feedback
252 2017-01-03 16:02:12	0|gribble|https://github.com/bitcoin/bitcoin/issues/9271 | An error has occurred and has been logged. Please contact this bot's administrator for more information.
253 2017-01-03 16:02:16	0|instagibbs|can someone explain ProcessBlockAvailability? The comment for it is unclear: "/** Check whether the last unknown block a peer advertised is not yet known. */"
254 2017-01-03 16:02:29	0|instagibbs|check whether an unknown block is unknown... ok!
255 2017-01-03 16:05:06	0|jtimon|also, friendly reminder https://github.com/bitcoin/bitcoin/pull/8855 https://github.com/bitcoin/bitcoin/pull/9279 and https://github.com/bitcoin/bitcoin/pull/8498 still *don't* need rebase
256 2017-01-03 16:07:23	0|instagibbs|nevermind, think I got it
257 2017-01-03 16:13:11	0|gribble|https://github.com/bitcoin/bitcoin/issues/9152 | Wallet/RPC: sweepprivkeys method to scan UTXO set and send to local wallet by luke-jr · Pull Request #9152 · bitcoin/bitcoin · GitHub
258 2017-01-03 16:25:57	0|BlueMatt|cfields: hmmm...yes, re: moving the loop into net_processing I figured that was just due to not complicating that pr too much, thanks
259 2017-01-03 16:26:32	0|cfields|BlueMatt: np, thanks for review
260 2017-01-03 16:26:57	0|BlueMatt|cfields: as for not having a per-node loop....hum...can we re-add it in net.cpp with two lines so that its not a (proabbly barely noticeable) regression?
261 2017-01-03 16:27:59	0|BlueMatt|bool fMoreNodeWork = ... while (fMoreNodeWork) ProcessMessages
262 2017-01-03 16:28:09	0|cfields|BlueMatt: I'm not sure there's any actual change from the current behavior
263 2017-01-03 16:28:13	0|sdaftuar|instagibbs: ProcessBlockAvailability is for when you get block announcements via inv (before you have the header)
264 2017-01-03 16:28:40	0|BlueMatt|cfields: you mean like from current master or from current pr?
265 2017-01-03 16:29:03	0|BlueMatt|sdaftuar: we still have crap for that? can we just remove it and replace with "getheaders"
266 2017-01-03 16:29:11	0|cfields|BlueMatt: oh.. it doesn't swallow all messages at once for fairness. I'm pretty sure emptying the node's full queue before moving on would be a DDoS vector
267 2017-01-03 16:29:16	0|cfields|BlueMatt: from master
268 2017-01-03 16:29:44	0|sdaftuar|BlueMatt: i think we could!
269 2017-01-03 16:29:56	0|cfields|BlueMatt: see the comment here: https://github.com/bitcoin/bitcoin/pull/9441/commits/99599884147ea4db3f960b0e706b039ba1553c80#r94270593
270 2017-01-03 16:32:37	0|BlueMatt|cfields: I believe the improvements against master come largely from removing lock contention between the message processing loop and the read-from-wire loop?
271 2017-01-03 16:32:44	0|BlueMatt|or do I have that backwards?
272 2017-01-03 16:33:22	0|BlueMatt|cfields: re: swallowing from one node...that isnt how I read the old code?
273 2017-01-03 16:34:03	0|BlueMatt|I mean certainly if we got a packet which only had one message we'd not process more than one message at a time, but if the loop is slow to go around (it appears to be sometimes due to various messages being slow) then we might have multiple to process per-peer
274 2017-01-03 16:34:15	0|cfields|BlueMatt: sorry, by no change in current behavior, i meant the swallowing-one-message part. Obviously fixing the lock contention is a behavioural change :)
275 2017-01-03 16:34:27	0|BlueMatt|and in that case I think we'd prefer to only call SendMessages less often (though, to be fair, doing them back-to-back is less likely to be slow than otherwise)
276 2017-01-03 16:35:10	0|cfields|BlueMatt: take a look at the current code. I really don't think the new behavior is different, other than the case of corrupted messages
277 2017-01-03 16:35:16	0|BlueMatt|cfields: to answer in a different way: why do we need to change from the current behavior
278 2017-01-03 16:35:27	0|BlueMatt|cfields: whats the break you're referring to in that comment?
279 2017-01-03 16:35:31	0|BlueMatt|(line numbers are confusing here)
280 2017-01-03 16:35:42	0|BlueMatt|the !message.complete() one?
281 2017-01-03 16:36:01	0|cfields|and yes, sendmessages needs to be broken up and fixed in lots of different ways, but imo not here
282 2017-01-03 16:36:03	0|cfields|sec
283 2017-01-03 16:36:13	0|BlueMatt|definitely agreed, not here
284 2017-01-03 16:36:32	0|cfields|BlueMatt: whoops, that should be 2538
285 2017-01-03 16:36:33	0|BlueMatt|just trying to figure out if re-adding a while somewhere in that pr is better or worse, since this is all we can hope for in 0.14 :)
286 2017-01-03 16:37:00	0|BlueMatt|ohhhhhh, I hadnt seen /that/ break
287 2017-01-03 16:37:24	0|cfields|yes. So the loop only continues in 2 cases, iirc.
288 2017-01-03 16:37:38	0|cfields|bad hash, or uhmm.. bad start chars maybe?
289 2017-01-03 16:37:44	0|BlueMatt|wait, so on current master we will continue the loop if the message is somehow corrupted, but otherwise wont? wtf.....
290 2017-01-03 16:37:58	0|BlueMatt|oh, no, just bad hash
291 2017-01-03 16:38:02	0|BlueMatt|yea, this makes no sense
292 2017-01-03 16:38:39	0|cfields|BlueMatt: indeed, those are the cases that the node should be punished for, but instead they get a free pass.
293 2017-01-03 16:38:41	0|cfields|go figure.
294 2017-01-03 16:39:17	0|BlueMatt|well, i guess if your checksum is bad its not like we did any work for you anyway...
295 2017-01-03 16:39:35	0|cfields|sure, but that should at least toss you to the back of the line
296 2017-01-03 16:40:31	0|cfields|BlueMatt: so you agree now that the loop behavior isn't changed here significantly? (or, at least, only for the better?)
297 2017-01-03 16:41:15	0|BlueMatt|yes, agreed
298 2017-01-03 16:41:27	0|cfields|ok
299 2017-01-03 16:41:29	0|BlueMatt|I suppose I wouldnt want to go audit for whether it was a dos vuln to change it in this pr
300 2017-01-03 16:41:31	0|BlueMatt|so, good :)
301 2017-01-03 16:42:05	0|cfields|heh
302 2017-01-03 16:42:34	0|cfields|BlueMatt: as a follow-up for 0.14, if you're concerned about it, we could add a quick hack to quickly exit SendMessages if it hasn't been at least x msec since the last call
303 2017-01-03 16:42:45	0|cfields|but i don't think there's any real need, since this has been the behavior all along
304 2017-01-03 16:44:07	0|BlueMatt|yea, I'm less concerned about that...still hoping for parallel processmessages but....that seems stretchy now :/
305 2017-01-03 16:44:32	0|cfields|:(
306 2017-01-03 16:45:12	0|BlueMatt|depends on how many reviewers pop their heads up this week, I suppose
307 2017-01-03 16:46:27	0|cfields|BlueMatt: other than the current PRs, how much remains there? I think that 9441 should cut down on the scary races a good bit?
308 2017-01-03 16:46:57	0|BlueMatt|yea, I think after current PRs its just one or five std::atomics in CNode and then the one commit which fuckes around with the ProcessMessages loop
309 2017-01-03 16:47:08	0|BlueMatt|which would need rebased on your stuff, but probably wouldnt be too hard
310 2017-01-03 16:47:55	0|cfields|these are atomics that fix more than just CNodeStats which has always been racy anyway?
311 2017-01-03 16:48:16	0|BlueMatt|I havent looked as of the latest stuff so you'd know better than I
312 2017-01-03 16:48:23	0|BlueMatt|I mean we should probably atomic-ify CNodeStats...
313 2017-01-03 16:48:27	0|BlueMatt|easy enough
314 2017-01-03 16:48:30	0|cfields|I'll check out your branch again
315 2017-01-03 16:48:54	0|BlueMatt|cool
316 2017-01-03 16:49:17	0|BlueMatt|I'll probably not get much done until thurs....early flight tomorrow so will likely be super tired during the day at rwc
317 2017-01-03 16:49:32	0|cfields|yea, I was thinking about that yesterday. I think it may make sense to just actually keep the stats in CNodeStats with one lock. See nRecvBytes as an example
318 2017-01-03 16:49:43	0|cfields|then when we need the stats, just do a quick lock and copy out
319 2017-01-03 16:49:56	0|BlueMatt|iirc that like automagically ended up with lock inversions
320 2017-01-03 16:50:05	0|BlueMatt|i think i looked into that, but dont remember now
321 2017-01-03 16:50:14	0|BlueMatt|seems weird that it would, but....something something...
322 2017-01-03 16:50:41	0|cfields|hmm, not sure how. I'll look again
323 2017-01-03 16:50:58	0|cfields|BlueMatt: btw, you're good with the boost changes that 9441 include?
324 2017-01-03 16:51:30	0|BlueMatt|which boost changes? you mean #9289?
325 2017-01-03 16:51:32	0|cfields|if so, mind re-acking #9289 ?
326 2017-01-03 16:51:32	0|gribble|https://github.com/bitcoin/bitcoin/issues/9289 | net: drop boost::thread_group by theuni · Pull Request #9289 · bitcoin/bitcoin · GitHub
327 2017-01-03 16:51:35	0|gribble|https://github.com/bitcoin/bitcoin/issues/9289 | net: drop boost::thread_group by theuni · Pull Request #9289 · bitcoin/bitcoin · GitHub
328 2017-01-03 16:51:36	0|cfields|yes
329 2017-01-03 16:53:04	0|BlueMatt|aww fuck, got rebased, yea, I'm pretty sure nothing changed that I didnt think was reasonable or good...I'll try to take another look tomorrow, but I'm pretty sure that ack is still valid
330 2017-01-03 16:53:06	0|bitcoin-git|[13bitcoin] 15MarcoFalke opened pull request #9462: [qt] Do not translate tilde character (06master...06Mf1701-qtTransTilde) 02https://github.com/bitcoin/bitcoin/pull/9462
331 2017-01-03 16:55:00	0|cfields|BlueMatt: np, thanks
332 2017-01-03 16:56:10	0|cfields|BlueMatt: if i could fixup the racy stuff that would affect parallel processing, want me to PR? Or does that just complicate the current PR maze?
333 2017-01-03 16:57:02	0|BlueMatt|cfields: up to you...I had assumed you were waiting on the current prs to clean up a bit, but if you can do it without stepping on your own toes feel free
334 2017-01-03 16:58:24	0|cfields|ok. I'll at least try to get something ready on top of the queued-up changes. If it happens to not depend on them, I'll go ahead and submit it.
335 2017-01-03 16:58:48	0|BlueMatt|sounds good, thanks
336 2017-01-03 16:59:18	0|BlueMatt|I'll look into the same tomorrow on the flight if I'm not asleep the whole time
337 2017-01-03 16:59:41	0|cfields|heh, ok
338 2017-01-03 17:00:09	0|BlueMatt|ehh, by "the same" I meant redoing the parallel-processmessages pr
339 2017-01-03 17:00:13	0|BlueMatt|that was super unclear....
340 2017-01-03 17:30:52	0|instagibbs|is there a plan for multiwallet for 0.14, or is it too late
341 2017-01-03 17:35:02	0|gmaxwell|we're not at the feature freeze yet, and it seems done +/- things that need to be fixed due to review.
342 2017-01-03 17:35:15	0|gmaxwell|Several people have said they would review it.
343 2017-01-03 17:35:45	0|gmaxwell|It would be really great it multiwallet and the utxo scriptpubkey index could make it in.
344 2017-01-03 17:42:19	0|instagibbs|#8694 needs rebase though
345 2017-01-03 17:42:21	0|gribble|https://github.com/bitcoin/bitcoin/issues/8694 | Basic multiwallet support by luke-jr · Pull Request #8694 · bitcoin/bitcoin · GitHub
346 2017-01-03 17:44:12	0|luke-jr|instagibbs: #8776 goes first
347 2017-01-03 17:44:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/8776 | Wallet refactoring leading up to multiwallet by luke-jr · Pull Request #8776 · bitcoin/bitcoin · GitHub
348 2017-01-03 17:44:28	0|instagibbs|ok, ill review
349 2017-01-03 17:45:30	0|luke-jr|actually #8776 looks ready to merge. 3 reviews already
350 2017-01-03 17:45:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/8776 | Wallet refactoring leading up to multiwallet by luke-jr · Pull Request #8776 · bitcoin/bitcoin · GitHub
351 2017-01-03 17:45:38	0|luke-jr|yes we know gribble --.
352 2017-01-03 17:49:25	0|BlueMatt|luke-jr: good time to go rebase 8694 then :p
353 2017-01-03 17:49:36	0|luke-jr|sure
354 2017-01-03 17:51:25	0|luke-jr|oh, need #8775 still as well
355 2017-01-03 17:51:27	0|gribble|https://github.com/bitcoin/bitcoin/issues/8775 | RPC refactoring: Access wallet using new GetWalletForJSONRPCRequest by luke-jr · Pull Request #8775 · bitcoin/bitcoin · GitHub
356 2017-01-03 17:52:22	0|luke-jr|instagibbs: ^ could use review
357 2017-01-03 18:03:38	0|luke-jr|(once those two get in, looks reasonable to split up 8694 further into base/Qt/RPC PRs)
358 2017-01-03 20:09:50	0|sdaftuar|BlueMatt: if I understand 9375 correctly, I think that when there is a fork, and some nodes have tip A and others tip B, #9375 would cause all nodes to end up downloading both A and B.
359 2017-01-03 20:09:52	0|gribble|https://github.com/bitcoin/bitcoin/issues/9375 | Relay compact block messages prior to full block connection by TheBlueMatt · Pull Request #9375 · bitcoin/bitcoin · GitHub
360 2017-01-03 20:10:14	0|sdaftuar|i guess that could result in a testnet DoS vector?
361 2017-01-03 20:10:32	0|sdaftuar|maybe that's the least of our testnet problems though
362 2017-01-03 21:52:42	0|bitcoin-git|[13bitcoin] 15sipa pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6dc4c43d326e...ce5c1f4acae4
363 2017-01-03 21:52:43	0|bitcoin-git|13bitcoin/06master 14680b0c0 15Suhas Daftuar: Release cs_main before calling ProcessNewBlock (cmpctblock handling)
364 2017-01-03 21:52:43	0|bitcoin-git|13bitcoin/06master 14bd02bdd 15Suhas Daftuar: Release cs_main before processing cmpctblock as header
365 2017-01-03 21:52:43	0|bitcoin-git|13bitcoin/06master 14ce5c1f4 15Pieter Wuille: Merge #9252: Release cs_main before calling ProcessNewBlock, or processing headers (cmpctblock handling)...
366 2017-01-03 21:52:56	0|bitcoin-git|[13bitcoin] 15sipa closed pull request #9252: Release cs_main before calling ProcessNewBlock, or processing headers (cmpctblock handling) (06master...06cb-lock) 02https://github.com/bitcoin/bitcoin/pull/9252
367 2017-01-03 22:11:49	0|bitcoin-git|[13bitcoin] 15sipa pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/ce5c1f4acae4...2a524b8e8fe6
368 2017-01-03 22:11:50	0|bitcoin-git|13bitcoin/06master 145394b39 15Luke Dashjr: Wallet: Split main logic from InitLoadWallet into CreateWalletFromFile
369 2017-01-03 22:11:50	0|bitcoin-git|13bitcoin/06master 14fb0c934 15Luke Dashjr: Wallet: Let the interval-flushing thread figure out the filename
370 2017-01-03 22:11:51	0|bitcoin-git|13bitcoin/06master 142a524b8 15Pieter Wuille: Merge #8776: Wallet refactoring leading up to multiwallet...
371 2017-01-03 22:15:55	0|gmaxwell|\O/
372 2017-01-03 22:31:14	0|Chris_Stewart_5|Can we have OP_1NEGATE used as a push op code for witness program versioning?
373 2017-01-03 22:32:58	0|sipa|no, only OP_0, and OP_1..OP_16
374 2017-01-03 22:34:17	0|Chris_Stewart_5|Interesting, thanks sipa
375 2017-01-03 22:35:10	0|Chris_Stewart_5|Actually, is there any reason for this?
376 2017-01-03 22:35:18	0|sipa|not really
377 2017-01-03 22:35:26	0|sipa|it was considered sufficient :)
378 2017-01-03 22:38:58	0|luke-jr|by some* maybe; IMO it was overlooked.
379 2017-01-03 22:40:04	0|Chris_Stewart_5|Defintely a protocol 'quirk' since the BIP does say '1 byte push opcodes'
380 2017-01-03 22:40:29	0|luke-jr|not worth the effort to fix at this point though
381 2017-01-03 22:41:04	0|sipa|fix the bip :)
382 2017-01-03 22:41:13	0|sipa|(to match the code)
383 2017-01-03 22:41:31	0|Chris_Stewart_5|but it is so much easier to criticize! :P. I'll submit a pull req later..
384 2017-01-03 22:45:01	0|sipa|thanks!
385 2017-01-03 23:12:13	0|sipa|Chris_Stewart_5: the BIP clearly says "for 0 to 16", no?
386 2017-01-03 23:12:27	0|sipa|(i missed that when suggesting you send a PR, sorry)
387 2017-01-03 23:12:58	0|Chris_Stewart_5|sipa: What is '0 to 16'? Bytes? Technically OP_1 is 0x51
388 2017-01-03 23:13:13	0|Chris_Stewart_5|I don't like the wording in that regard either.
389 2017-01-03 23:13:23	0|sipa|the value being pushed
390 2017-01-03 23:13:31	0|Chris_Stewart_5|Why not explicitly state what ops they are?
391 2017-01-03 23:13:35	0|sipa|sure
392 2017-01-03 23:13:46	0|sipa|i trying to find the misunderstanding
393 2017-01-03 23:13:49	0|Chris_Stewart_5|instead having to do the conversion in your head?
394 2017-01-03 23:13:55	0|sipa|if it isn't clear, reformulating helps
395 2017-01-03 23:14:22	0|Chris_Stewart_5|I don't think I have a misunderstanding per se, but I think can be clearer. Instead of having to infer the op codes from the text I think they should just be explicitly stated
396 2017-01-03 23:14:51	0|Chris_Stewart_5|Plus it falls more inline with the actual implementation IMO
397 2017-01-03 23:14:56	0|sipa|fair enough
398 2017-01-03 23:17:07	0|fanquake|sipa You shouldn't see significant speedup with #8610 if you have a large -dbcache set (like 2048), should you?
399 2017-01-03 23:17:09	0|gribble|https://github.com/bitcoin/bitcoin/issues/8610 | Share unused mempool memory with coincache by sipa · Pull Request #8610 · bitcoin/bitcoin · GitHub
400 2017-01-03 23:17:49	0|sipa|fanquake: depends how large, but the effect should certainly be less dramativ
401 2017-01-03 23:17:52	0|sipa|*dramatic
402 2017-01-03 23:19:11	0|fanquake|Ok. Just ran through with -dbcache=2048 on master and that PR. Both basically the same (~800s) to reindex to 280k blocks.
403 2017-01-03 23:19:39	0|fanquake|I think I'll run through again without uping the dbcache at all. That seemed to show the most significant speedup.
404 2017-01-03 23:21:55	0|sipa|if you set dbcache to 10 i'm sure the difference will be spectacular :D
405 2017-01-03 23:22:25	0|luke-jr|Chris_Stewart_5: adding "valid" seems to make it less clear IMO
406 2017-01-03 23:23:01	0|Chris_Stewart_5|luke-jr: How so? A invalid 1 byte op code is OP_1NEGATE
407 2017-01-03 23:23:46	0|sipa|how about "a select subset of 1-byte push opcodes" ?
408 2017-01-03 23:23:47	0|Chris_Stewart_5|before it was a blanket statement, a 'one byte push op code' or something like that
409 2017-01-03 23:23:55	0|fanquake|heh yes I'm sure it would. When I first tested with 300mb dbcache there was something like a 30% speedup.
410 2017-01-03 23:23:56	0|sipa|oh, and OP_0 is not a 1-byte push
411 2017-01-03 23:24:05	0|Chris_Stewart_5|oo interesting
412 2017-01-03 23:24:11	0|Chris_Stewart_5|good point :/
413 2017-01-03 23:24:43	0|sipa|fanquake: if you feel like benchmarking, i have a few more utxo cache changes to test coming up :)
414 2017-01-03 23:26:09	0|fanquake|sipa sure
415 2017-01-03 23:26:42	0|Chris_Stewart_5|sipa: Then maybe just a 'select set of op codes' and then enumerate them like I have?
416 2017-01-03 23:27:22	0|sipa|Chris_Stewart_5: sgtm
417 2017-01-03 23:28:29	0|luke-jr|Chris_Stewart_5: OP_1NEGATE is valid though
418 2017-01-03 23:28:52	0|luke-jr|it's just not matched for witness purposes
419 2017-01-03 23:29:04	0|Chris_Stewart_5|(*this)[0] < OP_1 does it fail this predicate?
420 2017-01-03 23:31:09	0|Chris_Stewart_5|luke-jr: Here: https://github.com/bitcoin/bitcoin/blob/14d01309bed59afb08651f2b701ff90371b15b20/src/script/script.cpp#L228
421 2017-01-03 23:32:36	0|sipa|Chris_Stewart_5: depends what *this is...
422 2017-01-03 23:34:38	0|BlueMatt|sdaftuar: yes, your comment about only calling NewPoWValidBlock on things that are better than our current tip is a good one
423 2017-01-03 23:34:47	0|BlueMatt|sdaftuar: and build on our tip
424 2017-01-03 23:36:02	0|BlueMatt|sdaftuar: re: https://github.com/bitcoin/bitcoin/pull/9375#discussion_r94483881 I think I'm missing your point here? did you mean to comment a bit further down where the check is to set bool send?