1 2018-05-23 01:17:39	0|fanquake|https://blog.qt.io/blog/2018/05/22/qt-5-11-released/
  2 2018-05-23 01:18:05	0|fanquake|Qt for WebAssembly "Tech Preview". I guess they were listening to our IRC discussion..
  3 2018-05-23 03:23:29	0|bitcoin-git|[13bitcoin] 15achow101 opened pull request #13307: Replace coin selection fallback strategy with Single Random Draw (06master...06srd-fallback) 02https://github.com/bitcoin/bitcoin/pull/13307
  4 2018-05-23 05:01:17	0|bitcoin-git|[13bitcoin] 15ken2812221 opened pull request #13308: Qt594 (06master...06qt594) 02https://github.com/bitcoin/bitcoin/pull/13308
  5 2018-05-23 05:01:27	0|bitcoin-git|[13bitcoin] 15ken2812221 closed pull request #13308: Qt594 (06master...06qt594) 02https://github.com/bitcoin/bitcoin/pull/13308
  6 2018-05-23 06:24:11	0|jonasschnelli|roasbeef: Thanks! Is there a paper or a specs? Or just the code?
  7 2018-05-23 06:40:48	0|bitcoin-git|[13bitcoin] 15martinus opened pull request #13309: Faster unit tests: directloy operate with CMutableTransaction (06master...06SignSignature-with-CMutableTransaction) 02https://github.com/bitcoin/bitcoin/pull/13309
  8 2018-05-23 09:36:38	0|eshays|hey guys, my bitcoin core program didnt close correctly and upon relaunch im stuck on replaying block 0%
  9 2018-05-23 09:37:18	0|eshays|in the debug log im being shown that its currently rolling forward numbers
 10 2018-05-23 09:37:30	0|eshays|but ive had it running for 24 hours and still on 0%
 11 2018-05-23 09:42:08	0|booyah|corruption of kind that makes the recovery function hang forever?   eshays can you attach gdb to it   gdb -p $(pidof bitcoind)  and see in which function it is
 12 2018-05-23 09:43:11	0|booyah|eshays: in gdb, command: "thread apply all bt" (and press enter). Pastebin the result
 13 2018-05-23 09:44:14	0|eshays|im sorry im pretty unaware of all the terms, where do i find gdb
 14 2018-05-23 09:45:41	0|booyah|eshays: sorry, forgot you are on Windows. In this case just pastebin some portion of debug.log from end (check if there are no confidentail IP addresses or btc addresses).  After that, imo, shut down the node, make a copy of entire data-directory of bitcoin to have snapshot of corrupted files, and start again to see if it's the same
 15 2018-05-23 09:46:22	0|eshays|start the whole sync again?
 16 2018-05-23 09:46:40	0|booyah|<eshays> version v0.16.0 running Windows 10   ; 2TB harddrive with atleast 1.5TB free     (and include this information if you post to github issue)
 17 2018-05-23 09:47:25	0|booyah|eshays: after saving debug.log,  shut down the node fully (eg kill process) and start it again.  But I think it will try to continue again, it should not redownload chain from scratch
 18 2018-05-23 09:47:27	0|eshays|if im closing and opening debug and this is progressing with new entries is that a good sign?
 19 2018-05-23 09:47:30	0|eshays|2018-05-23 09:46:41 Rolling forward 0000000000000000001f0ffad4402279360668ba5b071ee3206971199bd732f7 (492215) 2018-05-23 09:46:50 Rolling forward 0000000000000000006d7c1822119613361d0fdb4594ec68990a37d1c42472da (492216) 2018-05-23 09:46:57 Rolling forward 00000000000000000046d5cabb24f80c5f60e614cb9450b14f5f86548dbac7af (492217) 2018-05-23 09:47:03 Rolling forward 0000000000000000001a5530ee669c4438fa706d53f8e5135f8256488df66
 20 2018-05-23 09:48:34	0|booyah|eshays: looks like progress. current block is 523985.
 21 2018-05-23 09:49:09	0|eshays|i had been syncing with maybe 15000 blocks left when it closed.
 22 2018-05-23 09:49:26	0|echeveria|yes, if you close improperly you lose sync progress partially.
 23 2018-05-23 09:49:49	0|booyah|the bug seems to be that for 24 hours it was stuck right?  what exactly do you mean by stuck, eshays?
 24 2018-05-23 09:50:15	0|eshays|it appears to be continually rolling forward in debug but never moving off 0%
 25 2018-05-23 09:50:48	0|booyah|eshays: the progress information, is in the GUI right?
 26 2018-05-23 09:51:07	0|eshays|yes it says "replaying blocks...
 27 2018-05-23 09:51:15	0|eshays|"press q to shutdown"
 28 2018-05-23 09:51:19	0|eshays|"0%"
 29 2018-05-23 09:51:23	0|booyah|maybe the GUI rolling forward message should include (last block: %d)
 30 2018-05-23 09:52:45	0|eshays|thanks anyway guys, im gonna let it sit and continue rolling forward.
 31 2018-05-23 09:53:01	0|booyah|eshays: let of known on #bitcoin if all worked out, see you
 32 2018-05-23 09:53:07	0|booyah|*let us
 33 2018-05-23 09:53:11	0|eshays|will do
 34 2018-05-23 09:54:37	0|luke-jr|I don't think the rolling forward reports any progress info
 35 2018-05-23 09:56:40	0|booyah|luke-jr: he pasted above that it does?
 36 2018-05-23 09:56:58	0|booyah|"00000000000000000046d5cabb24f80c5f60e614cb9450b14f5f86548dbac7af (492217) 2018-05-23 09:47:03 Rolling forward"
 37 2018-05-23 09:57:04	0|luke-jr|that's the debug log
 38 2018-05-23 09:57:10	0|luke-jr|I'm talking about the % reported to the GUI
 39 2018-05-23 09:57:24	0|luke-jr|so it will say 0% the whole time until it finishes
 40 2018-05-23 09:57:37	0|provoostenator|Why (and where) is dbcache wiped after each prune event? IIUC prune deletes block storage files, while dbache is mostly the UTXO set, which doesn't change.
 41 2018-05-23 09:58:25	0|luke-jr|provoostenator: prune events cause dbcache to get flushed out to disk, so you don't need to [potentially] replay the blocks you're about to prune
 42 2018-05-23 10:05:32	0|provoostenator|Is that process described in more detail anywhere?
 43 2018-05-23 10:07:12	0|provoostenator|luke-jr: what do you mean by replaying a block? Is that in the event of a crash?
 44 2018-05-23 10:08:13	0|luke-jr|that's the main difference between dbcache and flushed to disk, yes
 45 2018-05-23 10:09:26	0|provoostenator|Would it make sense to have a --I_feel_lucky flag that doesn't flush cache during IBD and just starts from scratch if there is a crash?
 46 2018-05-23 10:12:47	0|luke-jr|I doubt it would make a huge performance difference
 47 2018-05-23 10:13:24	0|luke-jr|what might help is doing some kind of CoW of the dbcache, and flushing it to disk in parallel rather than pausing the sync for it
 48 2018-05-23 10:14:30	0|provoostenator|Indeed only if it made a big difference. I'm still trying to figure out why a larger dbcache and bigger prune events are slower than master.
 49 2018-05-23 10:15:15	0|provoostenator|I don't think it's the duration of the flush events, though I haven't checked.
 50 2018-05-23 10:15:57	0|provoostenator|CoW?
 51 2018-05-23 10:16:45	0|provoostenator|Maybe some way to write to disk what's needed, but not remove it from memory?
 52 2018-05-23 10:17:49	0|luke-jr|copy-on-write
 53 2018-05-23 10:18:00	0|luke-jr|writing to disk is what's slow
 54 2018-05-23 10:31:23	0|bitconner|jonasschnelli, the readme in the aezeed package has a high-level description of the design https://github.com/lightningnetwork/lnd/tree/master/aezeed
 55 2018-05-23 10:31:50	0|jonasschnelli|bitconner: thanks!
 56 2018-05-23 10:37:39	0|jonasschnelli|roasbeef, bitconner: why static 16 bytes of entropy? Is that considered "enought"?
 57 2018-05-23 10:42:59	0|provoostenator|I'm running #12404 on a t2.medium EC2 instance (4 GB RAM, 2 CPUs), using dbcache=3000. After 72 hours it's at block 435K (while master is at 487K and #11658 is at 506K). There were 10 prune events. They take less than a minute, but blocks can take multiple minutes to process.
 58 2018-05-23 10:43:02	0|gribble|https://github.com/bitcoin/bitcoin/issues/12404 | Prune more aggressively during IBD by Sjors · Pull Request #12404 · bitcoin/bitcoin · GitHub
 59 2018-05-23 10:43:05	0|gribble|https://github.com/bitcoin/bitcoin/issues/11658 | During IBD, when doing pruning, prune 10% extra to avoid pruning again soon after by luke-jr · Pull Request #11658 · bitcoin/bitcoin · GitHub
 60 2018-05-23 10:43:09	0|jonasschnelli|roasbeef, bitconner: 2nd, has AEZ enough cryptoanalysis?
 61 2018-05-23 10:44:19	0|luke-jr|provoostenator: I'm not sure EC2 is usable for benchmarking.. isn't it cloud stuff?
 62 2018-05-23 10:44:48	0|provoostenator|luke-jr: well, it's slow stuff, buy maybe it's slow in cloud-specific way that's not relevant for any other conceivable device?
 63 2018-05-23 10:45:27	0|luke-jr|provoostenator: cloud is about resource sharing; so one VM might get more real-world CPU time than another due to the VMs it shares with
 64 2018-05-23 10:46:12	0|luke-jr|for a reliable benchmark comparison, you should really use real hardware doing nothing else
 65 2018-05-23 10:46:17	0|provoostenator|It's not CPU bound though.
 66 2018-05-23 10:46:27	0|luke-jr|the most often shared resource is I/O
 67 2018-05-23 10:51:56	0|provoostenator|Not as good as real computers, but in my experience they're still reasonably consistent. If so, then it's still useful to know what it is about a large cache that could slow things down.
 68 2018-05-23 10:54:28	0|bitcoin-git|[13bitcoin] 15promag opened pull request #13310: Report progress in ReplayBlocks while rolling forward (06master...062018-05-replayblocks-progress) 02https://github.com/bitcoin/bitcoin/pull/13310
 69 2018-05-23 10:57:23	0|jtimon|I think it should be almost done, but I'm temped to move https://github.com/bitcoin/bitcoin/pull/10757 to a new PR just to avoid the unicorns...
 70 2018-05-23 11:59:10	0|promag|review request -> #13100
 71 2018-05-23 11:59:14	0|gribble|https://github.com/bitcoin/bitcoin/issues/13100 | Add menu entry to open wallet by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
 72 2018-05-23 12:00:07	0|promag|BlueMatt: rebase #12979?
 73 2018-05-23 12:00:11	0|gribble|https://github.com/bitcoin/bitcoin/issues/12979 | Split validationinterface into parallel validation/mempool interfaces by TheBlueMatt · Pull Request #12979 · bitcoin/bitcoin · GitHub
 74 2018-05-23 13:22:21	0|jnewbery|jonasscnelli: if you're around and merging, #13011 looks ready
 75 2018-05-23 13:22:24	0|gribble|https://github.com/bitcoin/bitcoin/issues/13011 | Cache witness hash in CTransaction by MarcoFalke · Pull Request #13011 · bitcoin/bitcoin · GitHub
 76 2018-05-23 13:25:45	0|bitcoin-git|[13bitcoin] 15jtimon opened pull request #13311: Don't edit Chainparams after initialization (06master...06b17-regtest-only-params) 02https://github.com/bitcoin/bitcoin/pull/13311
 77 2018-05-23 13:48:13	0|jonasschnelli|GitHub wrote back the 2nd time regarding Unicorns:
 78 2018-05-23 13:48:13	0|jonasschnelli|https://0bin.net/paste/OzcXoKdVaVQHasqc#xLOsrdPisBsMaBq7Fj33AYBd3FloWOnd1WkNKkTh5yP
 79 2018-05-23 13:49:53	0|BlueMatt|nice!
 80 2018-05-23 13:50:08	0|jnewbery|That's great. Thanks for continuing to push for this, Jonas.
 81 2018-05-23 13:53:57	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #13312: docs: Add a note about the source code filename naming convention (06master...06lowercase-filenames) 02https://github.com/bitcoin/bitcoin/pull/13312
 82 2018-05-23 14:00:18	0|fanquake|wew
 83 2018-05-23 14:13:05	0|bitcoin-git|[13bitcoin] 15jamesob reopened pull request #13200: Process logs in a separate thread (06master...062018-05-asynclog) 02https://github.com/bitcoin/bitcoin/pull/13200
 84 2018-05-23 14:55:02	0|MarcoFalke|Is it fine to remove pulls that need rebase for several days from the high priority list?
 85 2018-05-23 15:01:09	0|fanquake|MarcoFalke Probably depends if the rebase matters or not.
 86 2018-05-23 15:01:14	0|fanquake|If the PR is on there for high level discussion etc then a rebase doesn't necessarily block that from happening.
 87 2018-05-23 15:01:47	0|MarcoFalke|fanquake: Though, if it has a couple of concept ack, but is just sitting around ...
 88 2018-05-23 15:02:27	0|MarcoFalke|Agree if they are up for concept ack discussion, they can stay.
 89 2018-05-23 15:03:15	0|MarcoFalke|Otherwise there is no use in having them up, as any utACKs would need to be followed up by a re-utACK to be of any use.
 90 2018-05-23 17:00:24	0|bitcoin-git|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/6916024768ec...b9551d3663fc
 91 2018-05-23 17:00:25	0|bitcoin-git|13bitcoin/06master 1435e77a0 15Jorge Timón: RPC: Introduce getblockstats
 92 2018-05-23 17:00:25	0|bitcoin-git|13bitcoin/06master 14cda8e36 15Jorge Timón: Refactor: RPC: Separate GetBlockChecked() from getblock()...
 93 2018-05-23 17:00:26	0|bitcoin-git|13bitcoin/06master 144cbfb6a 15Jorge Timón: Tests: Test new getblockstats RPC...
 94 2018-05-23 17:00:42	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10757: RPC: Introduce getblockstats to plot things (06master...06b15-rpc-plotter) 02https://github.com/bitcoin/bitcoin/pull/10757
 95 2018-05-23 17:25:56	0|bitcoin-git|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/b9551d3663fc...3c2a41a9fc3c
 96 2018-05-23 17:25:57	0|bitcoin-git|13bitcoin/06master 14faab55f 15MarcoFalke: Make CMutableTransaction constructor explicit...
 97 2018-05-23 17:25:57	0|bitcoin-git|13bitcoin/06master 14fac1223 15MarcoFalke: Cache witness hash in CTransaction
 98 2018-05-23 17:25:58	0|bitcoin-git|13bitcoin/06master 143c2a41a 15Wladimir J. van der Laan: Merge #13011: Cache witness hash in CTransaction...
 99 2018-05-23 17:26:31	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13011: Cache witness hash in CTransaction (06master...06Mf1804-cacheWitnessHash) 02https://github.com/bitcoin/bitcoin/pull/13011
100 2018-05-23 17:50:59	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/3c2a41a9fc3c...7f4db9a7c354
101 2018-05-23 17:51:00	0|bitcoin-git|13bitcoin/06master 140bf4318 15Wladimir J. van der Laan: net: Serve blocks directly from disk when possible...
102 2018-05-23 17:51:01	0|bitcoin-git|13bitcoin/06master 147f4db9a 15Wladimir J. van der Laan: Merge #13151: net: Serve blocks directly from disk when possible...
103 2018-05-23 17:51:43	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #13151: net: Serve blocks directly from disk when possible (06master...062018_05_direct_from_disk) 02https://github.com/bitcoin/bitcoin/pull/13151
104 2018-05-23 17:54:22	0|MarcoFalke|wumpus: Thanks for going through the high priority list.
105 2018-05-23 17:54:29	0|MarcoFalke|I feel like we should put #13253 on there
106 2018-05-23 17:54:32	0|gribble|https://github.com/bitcoin/bitcoin/issues/13253 | [0.16] Further Backports by fanquake · Pull Request #13253 · bitcoin/bitcoin · GitHub
107 2018-05-23 17:54:41	0|MarcoFalke|so we can move forward with the rc tag
108 2018-05-23 18:18:54	0|kanzure|v0.16.0 memory consumption compared to v0.15.0 is ~3x higher, is this known/expected?
109 2018-05-23 18:19:18	0|kanzure|or has the mempool grown lately. maybe that would explain my observation.
110 2018-05-23 18:19:39	0|sipa|i don't think the memory usage should be significantly different
111 2018-05-23 18:20:25	0|kanzure|even with -txindex?
112 2018-05-23 18:20:47	0|sipa|that shouldn't affect memory usage, only disk usage
113 2018-05-23 18:21:21	0|sipa|how much memory are we talking about, and which -dbcache and -maxmempool settings?
114 2018-05-23 18:22:46	0|kanzure|only have relative increase at the moment, will investigate
115 2018-05-23 18:23:59	0|kanzure|using default -dbcache and -maxmempool values. maybe these changed between versions?
116 2018-05-23 18:24:40	0|sipa|no
117 2018-05-23 18:24:50	0|kanzure|actual usage is 8.25 GB
118 2018-05-23 18:24:53	0|sipa|WOW
119 2018-05-23 18:24:56	0|sipa|RSS?
120 2018-05-23 18:24:58	0|sipa|or virtual?
121 2018-05-23 18:26:27	0|kanzure|yeah this seems wrong. that's not bitcoind-specific.
122 2018-05-23 18:28:44	0|sipa|?
123 2018-05-23 18:29:16	0|kanzure|switched to pm briefly
124 2018-05-23 18:32:33	0|tim____|hello
125 2018-05-23 18:32:54	0|tim____|I have a question
126 2018-05-23 18:36:42	0|kanzure|alright problem most likely due to ridiculous rpcthreads config value
127 2018-05-23 19:11:48	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #13314: Fix FreeBSD build by including utilstrencodigs.h (06master...062018_05_freebsd_build) 02https://github.com/bitcoin/bitcoin/pull/13314
128 2018-05-23 19:52:24	0|Iamvip987|Hello
129 2018-05-23 20:53:55	0|promag|is test/functional/wallet_multiwallet.py --usecli working on master? can anyone verify?
130 2018-05-23 21:19:34	0|harding|promag: works here.
131 2018-05-23 21:19:56	0|promag|hm, harding: thanks
132 2018-05-23 22:50:58	0|promag_|another "test_framework.authproxy.JSONRPCException: The mempool was not loaded yet (-1)"
133 2018-05-23 22:51:22	0|promag|^ https://travis-ci.org/bitcoin/bitcoin/jobs/382884494
134 2018-05-23 23:35:42	0|moneyball|Hello, thanks to jimpo reaching out to GitHub, their support got back to us with the following good news: "You should be seeing fewer unicorns as of this morning!  We've shipped a change that improves our caching (easy thing to do in computer science) which should improve your situation.
135 2018-05-23 23:35:42	0|moneyball|Unicorns are real and they may still exist but if you see one and refresh it should go away (cache updates).  If you're seeing a "double unicorn", in general that's awesome but actually meaning you saw a unicorn after refreshing from a unicorn, please reach out.  Drop me the PR that is problematic and we'll dig into it further.  I hope you don't see any double unicorns."