1 2017-10-25 00:19:04	0|aj|jtimon: +1 on hardcoding blocks for the tests, that's a much better idea
  2 2017-10-25 00:27:49	0|jtimon|1) Move from range of heights to just a single height (wait to see if anybody asks for block hash alternatively), adapt tests
  3 2017-10-25 00:27:49	0|jtimon|2) Move results from numbers to strings (keep in satoshi), adapt tests
  4 2017-10-25 00:27:49	0|jtimon|3) Move from generate(101) to hardcoded blocks in tests
  5 2017-10-25 00:27:49	0|jtimon|aj: thanks for the feedback again, and of course thanks jb55 for the idea, my current TODO list for #10757:
  6 2017-10-25 00:27:50	0|jtimon|4) Use at least 1 segwit tx to test the dunctionality
  7 2017-10-25 00:27:52	0|gribble|https://github.com/bitcoin/bitcoin/issues/10757 | RPC: Introduce getblockstats to plot things by jtimon · Pull Request #10757 · bitcoin/bitcoin · GitHub
  8 2017-10-25 01:39:08	0|luke-jr|hmm, or maybe when/if we finally do a hardfork, just declare that all UTXOs *without* the high tx.nVersion bit set are void.. anyone who consents to the HF must set the bit for their outputs, with the understanding that the original chain can/will softfork these to be invalid when/if the HF split
  9 2017-10-25 06:56:23	0|bitcoin-git|[13bitcoin] 15Sjors opened pull request #11556: [Qt] Improved copy for RBF checkbox and tooltip (06master...06rbf-ui-text) 02https://github.com/bitcoin/bitcoin/pull/11556
 10 2017-10-25 07:19:35	0|gribble|https://github.com/bitcoin/bitcoin/issues/11555 | ПОМОГИТЕ!!!!!!! · Issue #11555 · bitcoin/bitcoin · GitHub
 11 2017-10-25 07:19:35	0|Varunram|#11555 looks like a troll issue..
 12 2017-10-25 08:29:20	0|meshcollider|Heh the renaming of "Easy to implement" -> "Good first issue" means the 0.16 release schedule is now a "Good first issue"
 13 2017-10-25 08:32:02	0|sipa|it has some nontrivial dependencies, though :)
 14 2017-10-25 08:37:38	0|luke-jr|lol
 15 2017-10-25 08:57:25	0|Varunram|though if someone did contribute that, would be great ;)
 16 2017-10-25 10:46:02	0|bitcoin-git|[13bitcoin] 15Sjors opened pull request #11557: WIP: Use Sat/WU instead of (μ/m)BTC/kB and show percentage fee (06master...06fee-sat-per-wu) 02https://github.com/bitcoin/bitcoin/pull/11557
 17 2017-10-25 12:48:55	0|bitcoin-git|[13bitcoin] 15sipsorcery opened pull request #11558: Minimal code changes to allow msvc compilation (06master...06code_msvc) 02https://github.com/bitcoin/bitcoin/pull/11558
 18 2017-10-25 13:05:24	0|bitcoin-git|[13bitcoin] 15racmnet opened pull request #11559: Create bitcoin.git (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/11559
 19 2017-10-25 13:06:25	0|bitcoin-git|[13bitcoin] 15fanquake closed pull request #11559: Create bitcoin.git (06master...06patch-1) 02https://github.com/bitcoin/bitcoin/pull/11559
 20 2017-10-25 14:57:06	0|Grandpa_|Hello, - an old lowtech grandpa on the line here - hoping you guys can help me figure out what to do.  I have an old Bitcoin Core wallet with some old BTC coins in it. It haven't spent any or even touched the wallet (other than upgrading to Core 0.15.0.1 a few day ago) since May 2017 - prior to the Segwit implementation and the Bitoin Cash and Gold forks that I have been trying to follow through the media.
 21 2017-10-25 14:57:17	0|Grandpa_|Now I would like to transfer some to Bitstamp (the only place where I have an acct) in case I would like to sell a litle bit. But I would of course also like to NOT LOSE the Bitcoin Cash and Gold coins which now (as far as I am able to discern from media coverage) reside inside the belly of each of my old Bitcoins.  I've tried to make sense of Bitstamp's official statements but there isn't really any usable information ther
 22 2017-10-25 14:57:26	0|Grandpa_|So: Could someone among you PLEASE share some insight as to what to actually do? Since Bitstamp has automatically credited costumer accts with pre-BTCash holdings with one BTCash for each old BTC, do they also automatically do this with BTC that are transferred now? If not, how to go about it from inside Bitcoin Core (with the least possible difficulty and complexity for an aging chap who struggles with the technicalities i
 23 2017-10-25 15:00:13	0|gmaxwell|Grandpa_: Bitcoin Cash will not 'replay' your bitcoin transactions. You can send bitcoin without worrying about that.  Bitcoin gold doesn't really exist yet, but they claim that when it does it will also not be vulnerable to replay, so again, should be no reason to worry there.
 24 2017-10-25 15:00:57	0|gmaxwell|When you pay with your bitcoin core wallet, only the bitcoin will move... the Bcash (and presumably bgold) will just stay where they are.
 25 2017-10-25 15:01:24	0|Grandpa_|So you are saying that I can safely transfer som BTC to Bitstamp and they will take care of it_
 26 2017-10-25 15:01:26	0|Grandpa_|?
 27 2017-10-25 15:01:54	0|Grandpa_|How can they stay where they are if the BTC are sent away?
 28 2017-10-25 15:03:00	0|gmaxwell|No, I am saying you can send btc to bitstamp and other currencies will not be effected.
 29 2017-10-25 15:03:17	0|gmaxwell|Grandpa_: because they are entirely seperate systems that diverged from bitcoin in the past, they will not see your transactions.
 30 2017-10-25 15:03:35	0|gmaxwell|(and, in fact, your bitcoin transactions are not compatible with them).
 31 2017-10-25 15:03:39	0|Grandpa_|Should a make a copy of my wallet before sending then?
 32 2017-10-25 15:03:50	0|Grandpa_|With the old balance?
 33 2017-10-25 15:03:55	0|gmaxwell|That could make it a little easier to later send the bcash/bgold.
 34 2017-10-25 15:04:15	0|gmaxwell|Though it is not strictly needed, as you can rescan your wallet on those systems.
 35 2017-10-25 15:04:30	0|Grandpa_|How else could I preserve the gold/cash?
 36 2017-10-25 15:04:50	0|gmaxwell|it would be preserved even if you didn't back up the wallet because the keys are never removed from the wallet.
 37 2017-10-25 15:05:33	0|Grandpa_|I mean, if I now send away some coins reducing wallet balance to 0 / could I later extract cash and gold from it_
 38 2017-10-25 15:05:35	0|Grandpa_|?
 39 2017-10-25 15:06:01	0|gmaxwell|Yes, that is what I've been trying to tell you.
 40 2017-10-25 15:06:09	0|Grandpa_|Oh, my.
 41 2017-10-25 15:06:28	0|Grandpa_|Sound scary though.
 42 2017-10-25 15:06:31	0|Grandpa_|Sounds
 43 2017-10-25 15:07:15	0|gmaxwell|it isn't really-- these things are just totally seperate cryptocurrencies where they just happened to also pay everyone that owned bitcoin at a certian time on them.
 44 2017-10-25 15:07:38	0|gmaxwell|So its like importing the same private key into a litecoin and bitcoin wallet. They're still seperate.
 45 2017-10-25 15:09:15	0|Grandpa_|But the recommended path would, however, be to just make a copy of the wallet before sending? And then later on use it for the other two? How exactly would I go about it if I want to get rid of the bcash asap (which I dont like?)
 46 2017-10-25 15:09:57	0|sipa|can we move this to #bitcoin ?
 47 2017-10-25 15:10:29	0|Grandpa_|how do I do that?
 48 2017-10-25 15:10:40	0|Grandpa_|start there anew?
 49 2017-10-25 15:11:05	0|sipa|type exactly:
 50 2017-10-25 15:11:08	0|sipa|/join #bitcoin
 51 2017-10-25 15:49:50	0|Grandpa_|Thank you sincerely for your coaching guys! Might be checking in later.
 52 2017-10-25 15:53:42	0|bitcoin-git|[13bitcoin] 15TheBlueMatt closed pull request #11487:  Check that new headers are not a descendant of an invalid block (06master...062017-10-acceptblock-validity-check) 02https://github.com/bitcoin/bitcoin/pull/11487
 53 2017-10-25 16:06:10	0|cfields|ugh, the whitespace linter is annoying
 54 2017-10-25 16:07:11	0|cfields|</unhelpful grumble>
 55 2017-10-25 16:08:17	0|sipa|good, that means it's working
 56 2017-10-25 18:22:16	0|gmaxwell|Is anyone here permitted on the segwit2x list?  it would be nice for someone to ask what the heck this refers to:
 57 2017-10-25 18:22:22	0|gmaxwell|7. I've been paying close attention to the Bitcoin Core 0.15.x rollout. Based on instability and bugs that upstream Bitcoin Core project is seeing
 58 2017-10-25 18:22:25	0|gmaxwell|- ie. Core's bugs not ours - segwit2x will stay on Bitcoin Core 0.14.x
 59 2017-10-25 18:22:27	0|gmaxwell|through the November fork.  This is the most stable path for users, based
 60 2017-10-25 18:22:30	0|gmaxwell|on upstream Bitcoin Core instability.
 61 2017-10-25 18:44:20	0|wxss|gmaxwell: the segwit2x-dev branch (based on 0.15) crashes at least 5x during IBD
 62 2017-10-25 18:44:49	0|gmaxwell|?!
 63 2017-10-25 18:44:57	0|gmaxwell|wxss: are you sure your hardware isn't just fucked?
 64 2017-10-25 18:45:28	0|gmaxwell|gah. must resist urge to ask you about the crashes, I do not intent to help them fix their broken grap.
 65 2017-10-25 18:45:31	0|gmaxwell|er crap.
 66 2017-10-25 18:46:40	0|wxss|I haven't seen it with the Core client (0.15.x) so I'm pretty sure my hw is ok
 67 2017-10-25 18:47:30	0|gmaxwell|well it would be no shock to me if they broke it.
 68 2017-10-25 18:48:11	0|wxss|me neither, anyway it was just an observation.
 69 2017-10-25 19:02:49	0|achow101|I like how he doesn't report the bug upstream and just complains about it instead :/
 70 2017-10-25 19:05:35	0|gmaxwell|we claims that _we're_ seeing instability.
 71 2017-10-25 19:05:42	0|gmaxwell|AFAICT this is simply untrue.
 72 2017-10-25 19:05:46	0|andytoshi|fwiw adam is on the list and can maybe forward a message
 73 2017-10-25 19:06:19	0|gmaxwell|s/we/he/
 74 2017-10-25 19:07:02	0|achow101|are you not able to get on the list?
 75 2017-10-25 19:08:32	0|gmaxwell|I have no idea now, when they first opened it they were telling people that it was only for supporters and people who agreed they would deploy it, but if adam is on it then perhaps; I don't really have any interest in being on it, and I don't think jeff will reply to me.
 76 2017-10-25 19:26:06	0|aj|gmaxwell: i'd give 80% odds it's talking about the qt bugs fixed in 0.15.0.1... i doubt it's anything unknown or unfixed given the "Bitcoin Core project is seeing" them wording
 77 2017-10-25 19:26:48	0|gmaxwell|well the things fixed in 0.15.0.1 wouldn't really make a lot of sense in that context... because ... they're fixed.
 78 2017-10-25 19:27:28	0|Chris_Stewart_5|gmaxwell: Don't let your pesky facts get in the way of the narrative
 79 2017-10-25 19:29:31	0|aj|gmaxwell: the sensible reason for basing on 0.14 is that rebasing 0.14->0.15 on top of btc1 is too hard; but that's embarassing to admit, and rebasing btc1 on top of 0.15 would also be embarassing
 80 2017-10-25 19:36:21	0|MarcoFalke|0.15.0.1 only fixed the gui oob crash. The "peers.dat" crash will be fixed in 0.15.0.2.
 81 2017-10-25 19:36:32	0|MarcoFalke|I am not aware of any other bugs or instabilities.
 82 2017-10-25 19:43:10	0|achow101|peers.dat crash?
 83 2017-10-25 19:44:33	0|bitcoin-git|[13bitcoin] 15sdaftuar opened pull request #11560: Connect to a new outbound peer if our tip is stale (06master...062017-10-stale-tip-new-peer) 02https://github.com/bitcoin/bitcoin/pull/11560
 84 2017-10-25 19:45:28	0|sdaftuar|gmaxwell: cfields: i think i have a working implementation of what we talked about yesterday ^^^
 85 2017-10-25 19:46:35	0|cfields|sdaftuar: great, will take a look
 86 2017-10-25 19:46:42	0|sdaftuar|thanks!
 87 2017-10-25 19:50:19	0|aj|MarcoFalke: (hm, #11508 was the other one i was thinking of, but i don't think the bug was only introduced in master)
 88 2017-10-25 19:50:22	0|gribble|https://github.com/bitcoin/bitcoin/issues/11508 | Fix crash via division by zero assertion by jonasschnelli · Pull Request #11508 · bitcoin/bitcoin · GitHub
 89 2017-10-25 19:51:40	0|MarcoFalke|aj: Indeed. achow101: #11252
 90 2017-10-25 19:51:42	0|gribble|https://github.com/bitcoin/bitcoin/issues/11252 | [P2P] When clearing addrman clear mapInfo and mapAddr. by instagibbs · Pull Request #11252 · bitcoin/bitcoin · GitHub
 91 2017-10-25 19:56:01	0|gmaxwell|MarcoFalke: #11252 exists in 0.14.x and presumably all prior versions back to addrman's introduction.
 92 2017-10-25 19:56:02	0|gribble|https://github.com/bitcoin/bitcoin/issues/11252 | [P2P] When clearing addrman clear mapInfo and mapAddr. by instagibbs · Pull Request #11252 · bitcoin/bitcoin · GitHub
 93 2017-10-25 19:57:38	0|MarcoFalke|I noticed quite a few issue reports after release of 0.15. Did no one report it previously?
 94 2017-10-25 19:57:45	0|gmaxwell|11508 was fixing an issue added in master just two days before it... so not in 0.15 wither.
 95 2017-10-25 19:58:35	0|gmaxwell|MarcoFalke: I wouldn't be surprised if the crashes that 0.15.0.1 fixed caused addrman file corruption.
 96 2017-10-25 20:00:30	0|achow101|MarcoFalke: ah, ok. I forgot about that
 97 2017-10-25 20:00:41	0|gmaxwell|MarcoFalke: yes it was reported prior to 0.15's release: 11079
 98 2017-10-25 20:03:06	0|MarcoFalke|Oh right. (I looked at the date of the all responses and assumed it was filed 2 weeks ago as well.)
 99 2017-10-25 20:03:59	0|gmaxwell|well at least you established that he could have actually thought there were issues w 0.15
100 2017-10-25 20:19:47	0|gmaxwell|BlueMatt: the ppa is not updated to 0.15 https://www.reddit.com/r/Bitcoin/comments/78ot5o/we_are_now_more_than_2300_nodes_satoshi_01501_o/dovrkeo/ ?
101 2017-10-25 20:20:34	0|gmaxwell|sdaftuar: so remind me a bit about how the scheduler works...  when the network hits 30 minutes with no blocks will all peers make their additional connection at exactly the same time?
102 2017-10-25 20:21:38	0|BlueMatt|gmaxwell: wat
103 2017-10-25 20:21:44	0|BlueMatt|no....
104 2017-10-25 20:21:46	0|BlueMatt|checking
105 2017-10-25 20:37:43	0|sturles|I am on a 3G network, downgraded to GPRS speeds after exceeding daily quota limit.  Now my node has been stuck for hours on "Timeout downloading block [...] disconnecting".  Is it possible to make it more patient, or will I have to wait until after midnight for more blocks?  Does it keep the dowloaded part, or is it discarded before trying to download from the next node?
106 2017-10-25 20:42:04	0|gmaxwell|discarded, unfortunately, though the timeout is 20 minutes, so if you can't transfer a block in that time you're going to fall behind regardless.
107 2017-10-25 20:43:21	0|sturles|Would be nice if it could at least keep valid downloaded transactions in the mempool, to allow for a more compact block download next time.
108 2017-10-25 20:44:40	0|sturles|It seems to download more than one block in parallel, which makes it more likely to time out.
109 2017-10-25 20:45:02	0|Chris_Stewart_5|sturles: Perhaps you could use -blocksonly if you are on mobile?
110 2017-10-25 20:45:31	0|sturles|I need the bandwidht for downloading two or more blocks in 20 minutes.
111 2017-10-25 20:46:53	0|sturles|Chris_Stewart_5: That would not be helpful, I think.  I would have to download every block in full, instead of just the unseen parts (ca compact block).
112 2017-10-25 20:47:36	0|Chris_Stewart_5|sturles: I think it would eliminate your mempool problems, but it might not matter since you have to dl the entire block any way
113 2017-10-25 20:48:10	0|sturles|I don't have a mempool problem that I am aware of.
114 2017-10-25 20:49:47	0|sturles|How does sending transactions work with -blocksonly?  I guess fee estimation will be off, and privacy will certainly be worse since all unconfirmed transactions I know about are my own.
115 2017-10-25 20:57:43	0|Chris_Stewart_5|sturles: That would be a problem AFAIK
116 2017-10-25 20:59:10	0|gmaxwell|sturles: the timeout is increased when there are more blocks in flight.
117 2017-10-25 21:00:47	0|gmaxwell|sturles: it can't get anything from the partially sent block because its sent as a large single message. the bitcoin p2p layer deals with messages as big atomic units.
118 2017-10-25 21:01:24	0|gmaxwell|It would technically be possible to do something like tear viable transactions out of a partially sent block when disconnecting a peer but it would be a big pile of tricky additional code.
119 2017-10-25 21:02:19	0|gmaxwell|sturles: its interesting to me that you had block downloads fail on a running node with a mempool. they should have been fetched via compact blocks and been fast to transfer.
120 2017-10-25 21:02:26	0|gmaxwell|I wonder why it didn't.
121 2017-10-25 21:08:09	0|sipa|gmaxwell: he must have been behind already
122 2017-10-25 21:08:19	0|sturles|My node had been offline for several hours, and had downloaded up to the tip about 25 minutes before the speed was downgraded.  Perhaps the mempool was not up to date yet when the network speed was limited?
123 2017-10-25 21:09:34	0|sturles|I assume progress=1.000000 means it doesn't know about any newer blocks.
124 2017-10-25 21:09:36	0|bitcoin-git|[13bitcoin] 15theuni opened pull request #11562: bench: use std::chrono rather than gettimeofday (06master...06bench-clock-chrono) 02https://github.com/bitcoin/bitcoin/pull/11562
125 2017-10-25 21:09:54	0|gmaxwell|no progress is meaningless when its near 1, its just based on timestamps.
126 2017-10-25 21:10:24	0|gmaxwell|sturles: right your mempool only learns about new txn coming in, and most txn getting confirmed now were broadcast quite a while ago (mempool is draining out)
127 2017-10-25 21:10:49	0|gmaxwell|so probably a block came in after you were limited and had very few mempool hits, and you fetched it and couldn't manage it in 20 minutes.
128 2017-10-25 21:10:51	0|sturles|height=491698 was downloaded at 17:48:40 UTC, seconds after my speed was downgraded.
129 2017-10-25 21:11:41	0|sturles|I now have "blocks": 491699, which means one block has been successfully downloaded after that.
130 2017-10-25 21:12:43	0|gmaxwell|you might end up back in sync if you -connect to a single peer. ... other peers sending you txn while you fetch that block might be making the difference.
131 2017-10-25 21:13:54	0|sturles|I think I'll just wait 47 minutes for a new day. :-)
132 2017-10-25 21:14:52	0|gmaxwell|thanks for reporting, I think I know what we need to do to better handle things like this... just so many things to do, and not enough time.