1 2017-04-21 01:27:27	0|michagogo|23:13:32 <gmaxwell> I've mused about the idea about having some shred wallet feature that creates some long timelocked spend of any remaining coins and gives them over to fees... then sends them off somewhere.
  2 2017-04-21 01:27:28	0|michagogo|23:14:25 <gmaxwell> because I am somewhat pained by all the utxo bloat created by people who end up with 0.00001 BTC in a wallet, in 100 inputs, and then they just delete the file because its effectively worthless.
  3 2017-04-21 01:27:33	0|michagogo|Isn't that already a thing?
  4 2017-04-21 01:28:22	0|michagogo|I mean, not built in to Core, but I could have sworn there was something that collects dust and bundles it into an ANYONECANPAY to a 0-value OP_RETURN
  5 2017-04-21 01:33:12	0|gmaxwell|yea, peter todd's dustbgone
  6 2017-04-21 01:34:06	0|michagogo|Yep, that's the one.
  7 2017-04-21 01:34:19	0|michagogo|BTW, something occurred to me earlier.
  8 2017-04-21 01:34:47	0|michagogo|In the latest update (Creators', I think it was called?) to Windows 10, they upgraded WSL
  9 2017-04-21 01:35:42	0|michagogo|And I think one of the big things, besides the fact that it now uses Xenial, is that you can now call Windows binaries from within bash.
 10 2017-04-21 01:36:14	0|michagogo|(Up until now, if you tried putting an exe into there it would try to execute it as a Linux binary and fail)
 11 2017-04-21 01:36:17	0|achow101|oh, they updated to xenial? then you can't cross compile from wsl
 12 2017-04-21 01:36:32	0|michagogo|achow101: yeah, for new installations
 13 2017-04-21 01:36:39	0|michagogo|Wait, really?
 14 2017-04-21 01:36:56	0|achow101|mingw on xenial does work IIRC
 15 2017-04-21 01:37:22	0|michagogo|So why can't you cross-compile?
 16 2017-04-21 01:37:53	0|achow101|well, not that it doesn't work, but rather that something (unknown) is different about it that makes it fail. there's an issue about it
 17 2017-04-21 01:38:25	0|michagogo|Weird.
 18 2017-04-21 01:38:45	0|achow101|michagogo: https://github.com/bitcoin/bitcoin/projects/1
 19 2017-04-21 01:39:01	0|michagogo|I was just confused because you said mingw on xenial does work -- do you mean that there's something different about one of the other packages that does it?
 20 2017-04-21 01:39:23	0|michagogo|Anyway, what occurred to me was this: Gitian supports virtualbox, right?
 21 2017-04-21 01:39:29	0|achow101|yes
 22 2017-04-21 01:39:44	0|achow101|I don't think it does it well though
 23 2017-04-21 01:39:52	0|michagogo|And I assume vboxmanage works the same (in terms of parameters etc) on Windows and Linux?
 24 2017-04-21 01:40:28	0|achow101|idk. I don't use virtualbox
 25 2017-04-21 01:40:48	0|michagogo|If that is the case, it should (I think?) now be possible to run Gitian from within WSL
 26 2017-04-21 01:41:11	0|achow101|couldn't you already do it with lxc?
 27 2017-04-21 01:41:59	0|michagogo|Can you?
 28 2017-04-21 01:42:08	0|michagogo|I would not expect LXC to work in WSL
 29 2017-04-21 01:42:59	0|achow101|i thought someone did it a while ago and it worked, but I don't quite remember. I haven't tried it myself
 30 2017-04-21 01:58:03	0|cfields|Any other gitian builders? Waiting for 1 more sig.
 31 2017-04-21 02:04:10	0|achow101|how many sigs do you need before doing the signed binaries?
 32 2017-04-21 02:10:26	0|luke-jr|https://github.com/bitcoin/bitcoin/pull/7107 should probably be reopened
 33 2017-04-21 02:17:48	0|cfields|achow101: usually 3. But usually wumpus is one of them. Since he uploads the tarballs, it's reassuring to know he's gotten the same result. So without his, I'd prefer to wait for another one/two before signing.
 34 2017-04-21 02:40:13	0|michagogo|cfields: mine's building right now
 35 2017-04-21 02:41:05	0|michagogo|dammit, accidentally hit ctrl-c
 36 2017-04-21 02:42:56	0|michagogo|Anyway, managed to get this for Linux: https://www.irccloud.com/pastebin/NPg3fSPm/
 37 2017-04-21 02:43:12	0|michagogo|Restarting the build for Windows and macOS now
 38 2017-04-21 02:56:53	0|cfields|michagogo: thanks!
 39 2017-04-21 03:18:21	0|michagogo|cfields: https://www.irccloud.com/pastebin/XrNoFzY5/
 40 2017-04-21 04:20:50	0|michagogo|cfields: PR up now
 41 2017-04-21 04:26:09	0|cfields|michagogo: thanks!
 42 2017-04-21 04:31:29	0|cfields|gitian builders: detached sigs pushed for 0.14.1
 43 2017-04-21 04:41:41	0|michagogo|Oops.
 44 2017-04-21 04:42:15	0|michagogo|I was running a while ! loop on the script to do the signed build
 45 2017-04-21 04:43:44	0|michagogo|But the script was returning failure, because the last step is opening a PR, which fails when there's already a PR open for the same branch
 46 2017-04-21 07:34:52	0|chatter29|hey guys
 47 2017-04-21 07:34:54	0|chatter29|allah is doing
 48 2017-04-21 07:34:59	0|chatter29|sun is not doing allah is doing
 49 2017-04-21 07:35:02	0|chatter29|to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger
 50 2017-04-21 08:13:19	0|CubicEarth|Should the default keypool size be increased to 1000?
 51 2017-04-21 08:14:01	0|CubicEarth|Or is HD the new default?
 52 2017-04-21 08:47:43	0|bitcoin-git|13bitcoin/06master 140611bc3 15Shigeya Suzuki: Minor fix in build documentation for FreeBSD 11...
 53 2017-04-21 08:47:43	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/86ea3c2ff247...694062eafec5
 54 2017-04-21 08:47:44	0|bitcoin-git|13bitcoin/06master 14694062e 15Wladimir J. van der Laan: Merge #10245: Minor fix in build documentation for FreeBSD 11...
 55 2017-04-21 08:48:08	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10245: Minor fix in build documentation for FreeBSD 11 (06master...06freebsd-11-build-doc-fix) 02https://github.com/bitcoin/bitcoin/pull/10245
 56 2017-04-21 08:57:15	0|bitcoin-git|13bitcoin/06master 14394ccf7 15Pieter Wuille: Make Boost use std::atomic internally
 57 2017-04-21 08:57:15	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/694062eafec5...0416ea9f743f
 58 2017-04-21 08:57:16	0|bitcoin-git|13bitcoin/06master 140416ea9 15Wladimir J. van der Laan: Merge #10239: Make Boost use std::atomic internally...
 59 2017-04-21 08:57:36	0|bitcoin-git|13bitcoin/06master 14fb463d1 15Russell Yanofsky: [qt] Don't call method on null WalletModel object...
 60 2017-04-21 08:57:36	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/0416ea9f743f...f6f3b58a7250
 61 2017-04-21 08:57:37	0|bitcoin-git|13bitcoin/06master 14f6f3b58 15Wladimir J. van der Laan: Merge #10242: [qt] Don't call method on null WalletModel object...
 62 2017-04-21 08:57:58	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10242: [qt] Don't call method on null WalletModel object (06master...06pr/rbfnull) 02https://github.com/bitcoin/bitcoin/pull/10242
 63 2017-04-21 09:12:47	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f6f3b58a7250...27faa6cccd8d
 64 2017-04-21 09:12:48	0|bitcoin-git|13bitcoin/06master 143577603 15Cory Fields: build: remove wonky auto top-level convenience targets...
 65 2017-04-21 09:12:48	0|bitcoin-git|13bitcoin/06master 1491ab8f5 15Cory Fields: build: fix bitcoin-config.h regeneration after touching build files...
 66 2017-04-21 09:12:49	0|bitcoin-git|13bitcoin/06master 1427faa6c 15Wladimir J. van der Laan: Merge #10228: build: regenerate bitcoin-config.h as necessary...
 67 2017-04-21 09:13:11	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10228: build: regenerate bitcoin-config.h as necessary (06master...06fix-config-h) 02https://github.com/bitcoin/bitcoin/pull/10228
 68 2017-04-21 11:00:57	0|jonasschnelli|#10244 and the IPC approach is in general good. Is there a broad agreement that we want to do this? I vaguely remember gmaxwell had some concerns. Just to give more clear feedback to ryanofsky
 69 2017-04-21 11:00:59	0|gribble|https://github.com/bitcoin/bitcoin/issues/10244 | [qt] Add abstraction layer for accessing node and wallet functionality from gui by ryanofsky · Pull Request #10244 · bitcoin/bitcoin · GitHub
 70 2017-04-21 11:01:09	0|jonasschnelli|I like it
 71 2017-04-21 11:02:07	0|jonasschnelli|But I remember when I also tried to write such *larger* PRs... they just have a hard time getting reviewed. Constant rebase and often great risks when merging.
 72 2017-04-21 11:20:40	0|wumpus|yes it's difficult to do a big change like thta
 73 2017-04-21 11:21:59	0|wumpus|I agree broadly, on the approach, the thing I didn't like about it is that he seemed to add more abstraction layers. What I don't like about that is that it reduces flexibility, hardcoding maybe stupid choices that were made years ago and made sense at the time, buried beneath layers of calls.
 74 2017-04-21 11:22:41	0|wumpus|my original plan was to make ClientModel and WalletModel the abstractions for the core, they are currently thin wrappers around it, and could be extended/changed to support a remote core instance instead
 75 2017-04-21 11:23:14	0|wumpus|along with using async notifications for replies from the core instead of synchronous calls and busy-waiting on locks
 76 2017-04-21 11:23:55	0|wumpus|so I'm happy he's doing it, but it's not in the way that I would, maybe I should just let it go though
 77 2017-04-21 11:26:09	0|wumpus|though I have a hard time reviewing code changes that aren't in line with my own thoughts
 78 2017-04-21 11:26:17	0|wumpus|especially big ones
 79 2017-04-21 11:26:31	0|sipa|wumpus: is your concern that the result makes the client/walletmodel less independent?
 80 2017-04-21 11:26:46	0|sipa|in that it now requires the IPC abstraction below it
 81 2017-04-21 11:27:12	0|wumpus|sipa: mostly that the code becomes even harder to work on
 82 2017-04-21 11:27:46	0|wumpus|it seems like a double abstraction; walletmodel is already an abstraction for core's CWallet
 83 2017-04-21 11:27:49	0|wumpus|now there's a class in between
 84 2017-04-21 11:29:11	0|sipa|seems like a reasonable concern to me... WalletModel and ClientModel don't really have much responsibility anymore
 85 2017-04-21 11:29:28	0|wumpus|the best way to implement remote-anything is not necessarily changing every direct call into a IPC call
 86 2017-04-21 11:30:15	0|wumpus|it's the easiest way to do it, but it's not how modern GUIs are written, ther shouldn't be anything waiting on replies from a remote process inside the GUI thread/loop
 87 2017-04-21 11:31:03	0|wumpus|even for local implementation this is wrong, and it means that while e.g. sending a transaction while cs_main is busy, the GUI hangs instead of being able to show a moving progress indicator
 88 2017-04-21 11:31:20	0|wumpus|I'm much more concerned with that than IPCing everything
 89 2017-04-21 11:31:26	0|sipa|seems reasonable, i don't know much about that
 90 2017-04-21 11:31:50	0|wumpus|so this is kind of calcifying the state of the code that I'm already not happy with
 91 2017-04-21 11:35:04	0|jonasschnelli|wumpus: I completely agree with you.
 92 2017-04-21 11:35:43	0|jonasschnelli|I think it will be very hard to change the GUI towards that goal with the current review strategy
 93 2017-04-21 11:35:46	0|wumpus|jonasschnelli: I tried to talk to him about this, but he seemed convinced that my concern had nothing to do with his changes, and that this can be done first.
 94 2017-04-21 11:36:33	0|jonasschnelli|Also the split between Wallet and Node (walletmodal / clientmodel) makes really sense.
 95 2017-04-21 11:36:39	0|jonasschnelli|*model
 96 2017-04-21 11:37:24	0|wumpus|and he's not entirely incorrect but I in my opinoin it makes sense to combine those two things; if the core and GUI communicate with asynchronous messages, goign from there to an IPC protocol is much easier
 97 2017-04-21 11:37:59	0|jonasschnelli|I often though maybe rewrite the GUI from the ground up,...
 98 2017-04-21 11:38:02	0|wumpus|and will likely be less complex
 99 2017-04-21 11:38:40	0|wumpus|I'm not sure that is a good idea
100 2017-04-21 11:38:51	0|jonasschnelli|Yeah.. me neither... :)
101 2017-04-21 11:38:59	0|wumpus|a rewrite is a lot of work to get feature parity, all bugs are born new, etc
102 2017-04-21 11:39:17	0|wumpus|usually I prefer incremental improvements unless something is total junk, which I think the code is not
103 2017-04-21 11:39:21	0|sipa|wumpus: that was my concern as well... it seems crazy to me that introducing an IPC layer somehow helps making things more asynchronous
104 2017-04-21 11:39:38	0|wumpus|sipa: not the way he's doing it, at least
105 2017-04-21 11:39:45	0|wumpus|in the way I always imagined doing it, it would
106 2017-04-21 11:39:51	0|jonasschnelli|What design would make sense for asynchronous messages?
107 2017-04-21 11:40:22	0|wumpus|jonasschnelli: qt signals/slots? same way that RPCConsole and RPCThread communicate for example
108 2017-04-21 11:41:11	0|jonasschnelli|So each node call would run in its own thread? Or would that be a single node-/wallet-interaction thread with queue?
109 2017-04-21 11:41:13	0|wumpus|signals could be generated by something that listens to a network pipe or local implemantion, most of the GUI code could be oblivous to that
110 2017-04-21 11:41:32	0|wumpus|one thread should be OK usually
111 2017-04-21 11:42:36	0|wumpus|long running operations could be their own thread
112 2017-04-21 11:42:37	0|jonasschnelli|Yes. I think this would be much better... would also require context sensitive activity-inidcators instead of a GUI freeze when communication is in progress
113 2017-04-21 11:42:51	0|wumpus|right
114 2017-04-21 11:43:11	0|jonasschnelli|reminds me that the RPCConcole/RPCThread missed a activity indicator...
115 2017-04-21 11:43:22	0|jonasschnelli|(things like topupkeypool 1000)
116 2017-04-21 11:43:22	0|wumpus|heck, even changing the cursor to a bee as on the Atari ST is better than hanging the GUI
117 2017-04-21 11:43:31	0|jonasschnelli|wumpus: haha
118 2017-04-21 11:43:55	0|wumpus|yes, indeed, it doesn't provide feedback that something is in progress
119 2017-04-21 11:43:59	0|jonasschnelli|Yes. We could start with a general activity indicator ("node communication happening") in the status bar
120 2017-04-21 11:44:21	0|jonasschnelli|I hope we can convince ryanofsky
121 2017-04-21 11:44:23	0|wumpus|in any case showing a modal dialog is still possible
122 2017-04-21 11:44:31	0|wumpus|if you don't want the user to do other things
123 2017-04-21 11:44:59	0|wumpus|that's not hanging the GUI; the dialog could e.g. show an animation, or have an abort butotn, or react to the user in other ways
124 2017-04-21 11:45:30	0|jonasschnelli|Yes. The modal non blocking concept is much better
125 2017-04-21 11:45:45	0|jonasschnelli|Blocking the GUI must be avoided any time
126 2017-04-21 11:45:56	0|jonasschnelli|Otherwise users will force quite
127 2017-04-21 11:46:02	0|jonasschnelli|force kill
128 2017-04-21 11:46:04	0|wumpus|right. And some OSes will blank out the window
129 2017-04-21 12:00:19	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #10248: Introduce CHashVerifier to hash while deserializing (06master...06chashverifier) 02https://github.com/bitcoin/bitcoin/pull/10248
130 2017-04-21 12:02:09	0|wumpus|so on the other hand I like that people actively work on the code and dno't want to discourage it, just because I have some different ideas
131 2017-04-21 12:11:28	0|wumpus|I know I myself have way too many ideas and too little time to work on them
132 2017-04-21 12:13:02	0|sipa|i think the ultimate goal of having the GUI being independent from the core, and being able to start/stop it separate is very nice
133 2017-04-21 12:13:29	0|sipa|if that requires an extra abstraction layer somewhere, fine
134 2017-04-21 12:13:43	0|sipa|but i'm not convinced why that abstraction layer can't be clientmodel/walletmodel
135 2017-04-21 12:24:16	0|jonasschnelli|I think one of ryanofsky arguments is that the client-/walletmodal also contains "business" logic and not only communication handling.
136 2017-04-21 12:24:17	0|jonasschnelli|Which I partially can follow
137 2017-04-21 12:25:04	0|sipa|well that business logic should move to the core
138 2017-04-21 12:25:24	0|sipa|some of it can likely be merged with some code in rpcwallet
139 2017-04-21 12:27:45	0|luke-jr|Random reddit user suggests that txindex should default to on when pruning is disabled.
140 2017-04-21 12:28:26	0|sipa|...?
141 2017-04-21 12:28:55	0|luke-jr|he was annoyed he had to reindex to setup an Electrum server because txindex defaulted to off, and argues that the txindex is small compared to the full blockchain
142 2017-04-21 12:29:10	0|sipa|it's huge compared to the utxo set
143 2017-04-21 12:29:16	0|luke-jr|https://www.reddit.com/r/Bitcoin/comments/66k36g/why_does_electrum_need_special_servers/dgjtg54/?context=3
144 2017-04-21 12:29:24	0|sipa|and people shouldn't rely on having a txindex available
145 2017-04-21 12:29:36	0|luke-jr|I don't think it's avoidable for Electrum
146 2017-04-21 12:29:57	0|sipa|i think electrum server should have a specialized node for that, not rely on bitcoind
147 2017-04-21 12:30:00	0|sipa|but ok
148 2017-04-21 12:30:09	0|jonasschnelli|You suggesting making it default in order to be able to run an electrum server?
149 2017-04-21 12:30:09	0|sipa|still doesn't mean everyone needs that
150 2017-04-21 12:30:29	0|luke-jr|jonasschnelli: relatively low cost, and high benefit to users who want to use Electrum
151 2017-04-21 12:30:50	0|jonasschnelli|Well,... a reindex with txindex takes a day or so?
152 2017-04-21 12:30:50	0|luke-jr|sipa: not everyone needs BLOOM, but we have it enabled by default
153 2017-04-21 12:31:06	0|luke-jr|true
154 2017-04-21 12:31:14	0|jonasschnelli|bloom is network, txindex is loca
155 2017-04-21 12:31:18	0|jonasschnelli|+l
156 2017-04-21 12:31:29	0|luke-jr|jonasschnelli: txindex is used for Electrum network protocol
157 2017-04-21 12:31:35	0|sipa|luke-jr: the way i see it, i'd have removed txindex support entirely with ultraprune
158 2017-04-21 12:31:52	0|jonasschnelli|Yes. Just saying offering bloom is something you do for the public, txindex is local
159 2017-04-21 12:31:54	0|sipa|luke-jr: but that would have caused too much problems for people relying on the software, so made it optional instead
160 2017-04-21 12:32:33	0|sipa|i don't think bitcoind's goal should be indexing the blockchain... for some purposes it's useful to have that feature availab;e
161 2017-04-21 12:32:38	0|sipa|but it's not optimized for it at all
162 2017-04-21 12:33:13	0|luke-jr|perhaps not, but users care less about that than how easy it is to get things going
163 2017-04-21 12:33:37	0|sipa|maybe we should create a separate tool that indexes the chain in a decent way
164 2017-04-21 12:33:42	0|sipa|without doing validation etc
165 2017-04-21 12:35:48	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #10249: Switch CCoinsMap from boost to std unordered_map (06master...06stdcoinmap) 02https://github.com/bitcoin/bitcoin/pull/10249
166 2017-04-21 12:37:01	0|wumpus|no,  txindex should not be default-enabled at any time. By far most people don't use it, while it forces an overhead on everyone.
167 2017-04-21 12:38:09	0|wumpus|if it's an annoyance to have to enable it once, well yes maybe, but there's a cost to everything
168 2017-04-21 12:39:16	0|wumpus|can be kind of annoying if people have some far-out usage of a program and then expect everyone to accomodate to them
169 2017-04-21 12:39:35	0|luke-jr|I suspect there are more Electrum users than Core-wallet users, sadly
170 2017-04-21 12:40:10	0|wumpus|of course there are more electrum users, that doesn't invalidate anything I said, most people running bitcoin core do not run an electrum server
171 2017-04-21 12:40:25	0|luke-jr|everyone using Electrum should be running their own Electrum server
172 2017-04-21 12:41:16	0|wumpus|in any case people shoudl be encouraged to use an index on the utxo set intead of on the whole block chain
173 2017-04-21 12:41:43	0|luke-jr|need an index on the whole blockchain to get tx history
174 2017-04-21 12:42:12	0|wumpus|there should be no need to index the whole block chain ,ever, unless you're doing chain analysis stuff, in which case you're working with such big data thatdoing  an extra reindex should be peanuts
175 2017-04-21 12:44:29	0|sipa|there is something crazy in this reasoning: bitcoin core is too annoying to use due to resource usage, thus people switch to electrum, but then complain they can't easily run their own server... which is even more expensive than just running a full node wallet in the first place
176 2017-04-21 12:44:56	0|sipa|also, doesn't electrum full history require addrindex even?
177 2017-04-21 12:44:58	0|sipa|not just txindex?
178 2017-04-21 12:45:02	0|luke-jr|sipa: many people use Electrum because it supports hardware wallets
179 2017-04-21 12:45:20	0|luke-jr|and yes, Electrum's server generates that itself from the txindex
180 2017-04-21 12:45:31	0|sipa|then why can't it create the txindex too?
181 2017-04-21 12:45:43	0|luke-jr|not sure.
182 2017-04-21 12:46:02	0|sipa|luke-jr: well electrum uses a model that makes it inherently more expensive to run a server
183 2017-04-21 12:46:23	0|luke-jr|sipa: depends whether storage/indexing costs more than doing the filtering on-the-fly for bloom nodes
184 2017-04-21 12:46:25	0|sipa|stupid "the blockchain is my wallet model"
185 2017-04-21 12:46:29	0|wumpus|it could, but remember that it is python code, so doing it there would be slower than having core handle it
186 2017-04-21 12:46:35	0|luke-jr|indexes are far less expensive than filtering for each user
187 2017-04-21 12:46:59	0|sipa|luke-jr: my view is that end users shouldn't need the full blockchain
188 2017-04-21 12:47:08	0|sipa|much less so a fully indexed one
189 2017-04-21 12:47:34	0|sipa|i understand electrum has advantages, but there must be ways to get them without burdening full nodes further
190 2017-04-21 12:47:46	0|luke-jr|sipa: not sure that's avoidable
191 2017-04-21 12:47:59	0|sipa|finding your old transactions should be a rare occurence
192 2017-04-21 12:48:02	0|wumpus|if everyone ran their own trusted full node to connect to, they could run some remote wallet UI instead of electrum on the light device side
193 2017-04-21 12:48:11	0|luke-jr|bloom allows you to get the data from other nodes, and use your own only for consensus, but those other nodes could omit info
194 2017-04-21 12:48:33	0|luke-jr|wumpus: yes, in theory
195 2017-04-21 12:48:47	0|wumpus|luke-jr: everyoen running their own electrum server is theory just as well
196 2017-04-21 12:48:55	0|wumpus|luke-jr: and a much more overhead one at that
197 2017-04-21 12:48:57	0|sipa|without the 'blockchain is my wallet' model, you could easily outsource the recovery of old transactions to a third party
198 2017-04-21 12:49:05	0|wumpus|why would everyone need to index everyone's transactions?
199 2017-04-21 12:49:07	0|wumpus|that's just crazy
200 2017-04-21 12:51:51	0|sipa|to be clear: my concern is indirect... txindex is indeed that not much of a resource problem, but the fact that something 'requires' you to have txindex, implies it requires you to have the full blockchain readily available
201 2017-04-21 12:52:09	0|sipa|an ecosystem that relies on everyone having the full blockchain available is disaster for scalability
202 2017-04-21 12:52:21	0|wumpus|in any case txindex is already supported, people can use it if they want
203 2017-04-21 12:52:45	0|wumpus|what I find deplorable is that people want to burden everyone with it just to avoid a one-time overhead for them
204 2017-04-21 12:53:27	0|sipa|maybe instead we should make pruning default :)
205 2017-04-21 12:53:33	0|instagibbs|^ was about tot say that
206 2017-04-21 12:54:11	0|wumpus|but I guess it fits well in the weird idea that many people have about the block chain, that it's some infinite externality that one can just keep dumping into, without relevant cost to anyone
207 2017-04-21 12:54:17	0|luke-jr|sipa: IMO wait until we can IBD from pruned nodes
208 2017-04-21 12:54:19	0|sdaftuar|sipa: lets merge that default to motivate block download improvements for 0.15 :)
209 2017-04-21 12:54:30	0|sipa|luke-jr: fair point
210 2017-04-21 12:54:54	0|luke-jr|I did make a pruning GUI for Knots, but it uses rwconf :x
211 2017-04-21 12:57:43	0|wumpus|I think offering a choice in the initial GUI dialog would already be nice
212 2017-04-21 12:57:56	0|sipa|agree
213 2017-04-21 12:58:05	0|wumpus|(the one that lets you choose the data directory and shows an estimate of disk usage)
214 2017-04-21 12:58:47	0|wumpus|I wouldn't like pruning to be the default because it means throwing away downloaded data by default. Prefer to err on the safe side.
215 2017-04-21 12:59:12	0|wumpus|it's trivially possible to go from non-pruned to pruned, the other way around can be expensive
216 2017-04-21 13:00:06	0|wumpus|sure if e.g. the machine has little disk space it can be encouraged strongly to prune
217 2017-04-21 13:00:20	0|wumpus|just think it should not be enabled silently
218 2017-04-21 13:01:23	0|bitcoin-git|[13bitcoin] 15sipa opened pull request #10250: Fix some empty vector references (06master...06nonnullref) 02https://github.com/bitcoin/bitcoin/pull/10250
219 2017-04-21 13:02:00	0|luke-jr|wumpus: Knots firstrun: http://i.imgur.com/mKTQrVb.png http://i.imgur.com/jopLsLQ.png
220 2017-04-21 13:02:07	0|sipa|in the GUI, a wizard setup dialog the first time that asks you seems nice
221 2017-04-21 13:02:18	0|wumpus|luke-jr: exactly
222 2017-04-21 13:02:36	0|luke-jr|perhaps I should re-PR rwconf without the GUI stuff?
223 2017-04-21 13:02:43	0|sipa|what is rwconf?
224 2017-04-21 13:02:47	0|luke-jr|although I guess that doesn't help get it to Intro
225 2017-04-21 13:02:56	0|luke-jr|sipa: bitcoin_rw.conf file that the software modifies
226 2017-04-21 13:03:13	0|sipa|which is also used by bitcoind?
227 2017-04-21 13:03:20	0|luke-jr|Knots bitcoind, yes
228 2017-04-21 13:03:22	0|wumpus|luke-jr: is that file at least in the per-network directory?
229 2017-04-21 13:03:43	0|luke-jr|wumpus: yes
230 2017-04-21 13:03:47	0|jonasschnelli|I once started a new GUI wizard with pruning: https://github.com/jonasschnelli/bitcoin/commit/7d8798d4942b7d7980a4c4f90cdd714432696ea7
231 2017-04-21 13:03:49	0|wumpus|luke-jr: great
232 2017-04-21 13:04:21	0|luke-jr|IIRC the hold-back from Core was that you wanted the GUI to use an enum for each setting
233 2017-04-21 13:04:52	0|luke-jr|but maybe just a minimal approach that only uses it for pruning would be okay before that's done
234 2017-04-21 13:05:16	0|jonasschnelli|The idea of the branch above was to ask about pruning / dbcache / folder (what we have right now)
235 2017-04-21 13:05:39	0|wumpus|from a sandboxing point of view I don't really like the idea of daemons writing their own configuration files
236 2017-04-21 13:05:56	0|wumpus|but if it doesn't write bitcoin.conf, well, it's not too bad
237 2017-04-21 13:06:00	0|luke-jr|right, that's why it was an independent file
238 2017-04-21 13:06:03	0|sipa|maybe we should go back to serializing settings into wallet.dat
239 2017-04-21 13:06:03	0|wumpus|right
240 2017-04-21 13:06:59	0|wumpus|also having it in per-network directory cleverly avoids the problem of a testnet and mainnet instance trying to write the file at the same time
241 2017-04-21 13:09:00	0|luke-jr|ok, so plan: 1) split the rwconf low-level from the GUI Options changes, and PR the former only; 2) in a second PR (?), do just the pruning Intro stuff?
242 2017-04-21 13:10:02	0|luke-jr|* [new tag]         v0.14.1.knots20170420 -> v0.14.1.knots20170420 <-- gitian builds please ☺
243 2017-04-21 13:11:59	0|wumpus|yes, I hope adding yet another settings source doesn't introduce a mess, it makes it harder to reason what takes precedence
244 2017-04-21 13:12:04	0|wumpus|ok, will build
245 2017-04-21 13:39:46	0|luke-jr|thx
246 2017-04-21 14:09:26	0|jonasschnelli|Using lambdas in Qt is a no go? Right? It would break Qt4 compile compat?
247 2017-04-21 14:10:18	0|sipa|you cant use c++11 lambdas?
248 2017-04-21 14:11:00	0|jonasschnelli|You can... but I think if you are using Qt "connect" mechanism and directly embed a lambda it will no longer be compilable with Qt4...
249 2017-04-21 14:11:02	0|jonasschnelli|not sure though
250 2017-04-21 14:19:01	0|sipa|a lambda is just a function object
251 2017-04-21 14:19:04	0|jonasschnelli|I'm always surprised what kind of hack from the CoinControl implementation I find: https://github.com/bitcoin/bitcoin/blame/master/src/qt/walletmodel.cpp#L64
252 2017-04-21 14:20:13	0|jonasschnelli|sipa: Yeah. But I think Qt4 can't handle something like connect( inProject, &myProject::signal, [=] () {}); because it's a marco or a MOC function (or whatever Qt uses to decompose)
253 2017-04-21 14:21:28	0|sipa|oh
254 2017-04-21 14:22:44	0|Chris_Stewart_5|sipa: Since we are talking about lambdas, if i use '[&]' on lambdas that will force the arg to be passed by reference, instead of being copied correct?
255 2017-04-21 14:22:53	0|Chris_Stewart_5|for things like this: https://github.com/Christewart/bitcoin/blob/6c929c05c51c266b6d991ff6e370425dee0f391a/src/test/gen/crypto_gen.h#L28
256 2017-04-21 14:23:49	0|jonasschnelli|Chris_Stewart_5: correct
257 2017-04-21 14:24:31	0|jonasschnelli|The L28 above makes a copy of the Key, right?
258 2017-04-21 14:25:16	0|Chris_Stewart_5|From my understanding of it, yes. However it seems like i could scope it with '&'
259 2017-04-21 14:27:29	0|Chris_Stewart_5|The way I have it written now is just the simplest way I could achieve what I was trying to do -- create a generator for a CPrivKey
260 2017-04-21 14:28:03	0|sipa|Chris_Stewart_5: that lambda does not capture anything...
261 2017-04-21 14:29:01	0|sipa|[&] will have no effect
262 2017-04-21 14:29:37	0|sipa|if you want the parameter key to be by reference, you just make it Key& key
263 2017-04-21 14:31:45	0|sipa|[=] and [&] control the capture list, not the parameter list
264 2017-04-21 14:31:54	0|Chris_Stewart_5|by 'capture' you just mean a variable that is a scope larger than that lambda, correct? For instance some global variable?
265 2017-04-21 14:32:15	0|Chris_Stewart_5|by default it copies that global variable if you just provide '[]'?
266 2017-04-21 14:32:34	0|sipa|if you provide [], it does not capture anything
267 2017-04-21 14:32:52	0|sipa|if you provide [=] it captures everything, by value
268 2017-04-21 14:33:12	0|sipa|if you provide [&] it captures everything, by reference
269 2017-04-21 14:34:56	0|Chris_Stewart_5|Thanks for the explanation. That clears up a lot wrt to lambdas for me.
270 2017-04-21 14:36:09	0|sipa|Chris_Stewart_5: http://en.cppreference.com/w/cpp/language/lambda
271 2017-04-21 14:42:00	0|ryanofsky|i kind of like the coding convention where you use unnamed [&] capture for any lambda called synchronously, and named capture [&var1, var2] or [] for any lambda called asynchronously
272 2017-04-21 14:42:56	0|ryanofsky|asynchronously meaning the closure is copied and called after the lambda expression goes out of scope
273 2017-04-21 14:43:38	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #10251: Add balances cache / GUI: use a signal instead of a poll thread (06master...062017/04/gui_rm_locks) 02https://github.com/bitcoin/bitcoin/pull/10251
274 2017-04-21 14:44:04	0|sipa|ryanofsky: that's a nice convention
275 2017-04-21 14:44:25	0|sipa|ryanofsky: is there a way to construct a non-copyable lambda?
276 2017-04-21 14:45:11	0|ryanofsky|in c++14 there definitely is because you can capture by move
277 2017-04-21 14:45:34	0|ryanofsky|so the resulting closure is move-only
278 2017-04-21 14:46:17	0|ryanofsky|otherwise i don't think you can do it directly without std::bind or something
279 2017-04-21 14:46:59	0|sipa|which incurs a performance penalty?
280 2017-04-21 14:47:51	0|ryanofsky|yeah, probably minor unless lambda is capturing a lot of variables or a very big struct by copy
281 2017-04-21 15:14:32	0|bitcoin-git|13bitcoin/06master 14821dd5e 15Jimmy Song: Tests: Add test for getdifficulty...
282 2017-04-21 15:14:32	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/27faa6cccd8d...f3db4c601385
283 2017-04-21 15:14:33	0|bitcoin-git|13bitcoin/06master 14f3db4c6 15Wladimir J. van der Laan: Merge #10229: Tests: Add test for getdifficulty...
284 2017-04-21 15:14:52	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10229: Tests: Add test for getdifficulty (06master...06test_getdifficulty) 02https://github.com/bitcoin/bitcoin/pull/10229
285 2017-04-21 15:30:04	0|bitcoin-git|13bitcoin/06master 14c39a6b9 15Jimmy Song: Tests: Refactor to create witness script creation function...
286 2017-04-21 15:30:04	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f3db4c601385...5352e5e75da9
287 2017-04-21 15:30:05	0|bitcoin-git|13bitcoin/06master 145352e5e 15Wladimir J. van der Laan: Merge #10223: Tests: Refactor to create witness script creation function...
288 2017-04-21 15:30:30	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10223: Tests: Refactor to create witness script creation function (06master...06refactor_blocktools_for_segwit) 02https://github.com/bitcoin/bitcoin/pull/10223
289 2017-04-21 15:32:31	0|stoner19|can anyone link me to the actual code for segwit in bitcoin core?
290 2017-04-21 15:34:24	0|bitcoin-git|13bitcoin/06master 14f478d98 15Pieter Wuille: Fix some empty vector references...
291 2017-04-21 15:34:24	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/5352e5e75da9...1428f3030d99
292 2017-04-21 15:34:25	0|bitcoin-git|13bitcoin/06master 141428f30 15Wladimir J. van der Laan: Merge #10250: Fix some empty vector references...
293 2017-04-21 15:34:28	0|sipa|stoner19: what part? consensus logic? p2p protocol changes? signing code for transactions?
294 2017-04-21 15:34:56	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10250: Fix some empty vector references (06master...06nonnullref) 02https://github.com/bitcoin/bitcoin/pull/10250
295 2017-04-21 15:34:58	0|stoner19|sipa, guess I'm just curious about it all. What needed to be changed in order to implement/signal segwit?
296 2017-04-21 15:35:16	0|sipa|stoner19: signalling is 1 line of code, just changing the block nversion
297 2017-04-21 15:36:08	0|sipa|stoner19: https://github.com/bitcoin/bitcoin/pull/8149/commits
298 2017-04-21 15:36:32	0|stoner19|oh that helps significantly thank you
299 2017-04-21 15:51:27	0|morcos|gmaxwell: sipa: wumpus: i update https://gist.github.com/morcos/d3637f015bc4e607e1fd10d8351e9f41 to contain proposed fee estimation changes for 0.15
300 2017-04-21 15:51:49	0|morcos|It's a bit more thorough description than is included in #10199
301 2017-04-21 15:51:51	0|gribble|https://github.com/bitcoin/bitcoin/issues/10199 | Better fee estimates by morcos · Pull Request #10199 · bitcoin/bitcoin · GitHub
302 2017-04-21 15:52:53	0|morcos|It may have actually started to go into too much detail, but I'm happy to discuss further online if there are more questions
303 2017-04-21 16:42:43	0|bitcoin-git|13bitcoin/06master 1425660e9 15Mario Dian: pass Consensus::Params& to ReceivedBlockTransactions()
304 2017-04-21 16:42:43	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/1428f3030d99...a6548a47a554
305 2017-04-21 16:42:44	0|bitcoin-git|13bitcoin/06master 14a6548a4 15Wladimir J. van der Laan: Merge #10201: pass Consensus::Params& to ReceivedBlockTransactions()...
306 2017-04-21 16:44:03	0|achow101|has 0.14.1 been officially released yet? or still waiting on gitian sigs?
307 2017-04-21 16:45:28	0|bitcoin-git|[13bitcoin] 15luke-jr opened pull request #10252: RPC/Mining: Restore API compatibility for prioritisetransaction (06master...06rpc_prioritise_api) 02https://github.com/bitcoin/bitcoin/pull/10252
308 2017-04-21 16:46:33	0|luke-jr|achow101: thanks for the reminder to build signed bins :D
309 2017-04-21 16:51:40	0|gmaxwell|morcos: 60% threshold at target/2
310 2017-04-21 16:51:42	0|gmaxwell|85% threshold at target
311 2017-04-21 16:52:21	0|gmaxwell|so do we have any reason to expect that the 60% at target/2 won't dominate the estimate?
312 2017-04-21 17:00:01	0|bitcoin-git|[13bitcoin] 15jimmysong opened pull request #10253: Tests: Add test for getnetworkhashps (06master...06test_getnetworkhashps) 02https://github.com/bitcoin/bitcoin/pull/10253
313 2017-04-21 17:50:28	0|jtimon_|wumpus: it seems you added a commit to https://github.com/bitcoin/bitcoin/pull/10201 by mistake?
314 2017-04-21 17:54:34	0|bitcoin-git|[13bitcoin] 15jtimon closed pull request #10227: Make functions in validation.cpp static: (06master...06b14-chainparams-validation-static) 02https://github.com/bitcoin/bitcoin/pull/10227
315 2017-04-21 20:00:33	0|bitcoin-git|[13bitcoin] 15jonasschnelli opened pull request #10254: [Qt] Remove shutdown poll timer and replace it with a signal (06master...062017/04/qt_shutdown) 02https://github.com/bitcoin/bitcoin/pull/10254
316 2017-04-21 20:05:32	0|bitcoin-git|[13bitcoin] 15jimmysong opened pull request #10255: [test] Add test for listaddressgroupings (06master...06test_listaddressgroupings) 02https://github.com/bitcoin/bitcoin/pull/10255
317 2017-04-21 20:46:51	0|morcos|gmaxwell: i think in practice, the 3 calculations are often quite close.
318 2017-04-21 20:47:09	0|morcos|but i wouldn't be concerned if it turned out the target/2 one dominated
319 2017-04-21 20:54:00	0|morcos|you can look at each data point (tx and how long it took to get confirmed) as an independent event in which case you would expect the 60% n/2 and 85% n estimates to be roughly the same
320 2017-04-21 20:55:19	0|morcos|but also you know they aren't really independent and at the extreme end of that , all you care about is the current tx congestion and what fee rate is being cleared down to
321 2017-04-21 20:56:16	0|morcos|the way i looked at it is i could kind of have the best of couple differnet worlds by combining (taking the max) of different estimates
322 2017-04-21 20:57:39	0|morcos|the n/2 estimate allows you to react more quickly b/c lets you look at the more recent history for more of the estimates so you'll react more quickly to changing conditions
323 2017-04-21 20:59:04	0|morcos|but its important to also have an estimate with a 95% threshold so that you do know that your tx is going to be confirmed within a reasonable time frame..  you don't know if some of the data points were accelerated via special arrangement or CPFP'ed or had other special characteristics
324 2017-04-21 20:59:30	0|morcos|also, if you have a long history of 100% of things being concerned, it can take quite some time for estimates to drop
325 2017-04-21 20:59:53	0|morcos|man this is hard to walk through on IRC, it kind of sounds so handwavy
326 2017-04-21 21:03:39	0|sipa|haha
327 2017-04-21 22:40:25	0|gmaxwell|sipa: is there a reason that the CBlock doesn't cache its hash and redblockfromdisk couldn't use something like CHashverifier to populate it on construction?
328 2017-04-21 23:01:12	0|BlueMatt|gmaxwell: not so useful given hash is only 80 bytes...
329 2017-04-21 23:01:21	0|BlueMatt|but, it should cache in some way, indeed
330 2017-04-21 23:17:36	0|gmaxwell|yea, I guess the hashverifier doesn't really matter for performance due to the size.  I keep thinking it hashes the whole block I dunno why readblock from disk is so slow since it doesn't.
331 2017-04-21 23:21:38	0|luke-jr|does it hash every transaction?
332 2017-04-21 23:22:58	0|BlueMatt|gmaxwell: we have a benchmark for that because its so damned slow
333 2017-04-21 23:25:13	0|instagibbs|why is it so damned slow
334 2017-04-21 23:27:54	0|BlueMatt|instagibbs: you're allocating a metric shitload of objects on the heap
335 2017-04-21 23:30:55	0|gmaxwell|oh because of that. right. why do I keep forgetting the allocations.
336 2017-04-21 23:38:38	0|gmaxwell|Luke's revised text for the 0.14.2 changes is confusing. :(
337 2017-04-21 23:38:43	0|gmaxwell|er 0.14.1
338 2017-04-21 23:39:42	0|gmaxwell|I wish text weren't so hard.
339 2017-04-21 23:40:03	0|gmaxwell|Apparently it has people thinking that 0.14.1 change to relay blocks to non-segwit nodes. :( I can see how it's easy to read that way, but didn't notice it before.
340 2017-04-21 23:40:37	0|luke-jr|huh? O.o