1 2017-08-08 00:32:39	0|jimpo|What is HSNG? (mentioned in discussion of new addr message)
  2 2017-08-08 00:35:09	0|gmaxwell|Hidden services NG. Tor HS addresses will be becoming 256 bits long.
  3 2017-08-08 00:35:43	0|gmaxwell|NG = next gen, I assume
  4 2017-08-08 00:36:07	0|jimpo|interesting. thx
  5 2017-08-08 01:34:56	0|jimpo|is there anyone working/focussing on extracting libbitcoinconsensus?
  6 2017-08-08 01:36:08	0|Chris_Stewart_5|jimpo: Last I knew jtimon was, not sure if he is still working on it though
  7 2017-08-08 01:39:03	0|bitcoin-git|[13bitcoin] 15eklitzke opened pull request #11005: Tests: Add a lint check for trailing whitespace (06master...06whitespace) 02https://github.com/bitcoin/bitcoin/pull/11005
  8 2017-08-08 03:02:41	0|bitcoin-git|[13bitcoin] 15promag opened pull request #11006: WIP: Improve shutdown process (06master...06201708-fast-shutdown) 02https://github.com/bitcoin/bitcoin/pull/11006
  9 2017-08-08 04:22:38	0|luke-jr|gmaxwell: hmm, but it makes sense to show them up top in the question page :/
 10 2017-08-08 04:27:31	0|gmaxwell|luke-jr: so make the order different for each, questions by least answers answers by most
 11 2017-08-08 05:20:39	0|luke-jr|gmaxwell: done
 12 2017-08-08 07:45:03	0|luke-jr|hm, it's a shame we're releasing 0.15 without bech32 sending :x
 13 2017-08-08 07:45:54	0|gmaxwell|luke-jr: when does segwit activate?
 14 2017-08-08 07:46:17	0|luke-jr|gmaxwell: Aug 21 it looks like
 15 2017-08-08 07:46:38	0|gmaxwell|luke-jr: also it's just not that mature yet,... a serious problem was found in the test vectors of the spec and ref implementations just a week ago.
 16 2017-08-08 07:46:47	0|luke-jr|:<
 17 2017-08-08 07:47:09	0|gmaxwell|luke-jr: dunno if you read the minutes from the last meeting (or was it the one before last) but we were talkign about a short cycle release with segwit wallet support right after 15 in any case.
 18 2017-08-08 07:47:37	0|luke-jr|I didn't, but newbery did mention it to me. I agree a rapid 0.16 would be good.
 19 2017-08-08 07:47:50	0|gmaxwell|https://github.com/sipa/bech32/pull/21 also re: bech32 support.
 20 2017-08-08 07:49:05	0|luke-jr|is there a reason to have a C++ implementation at all? seems to me the proper route to go would be to make a C libbech32, which can be used by Core…?
 21 2017-08-08 07:51:25	0|gmaxwell|a library for 50 lines of code... what are you, a nodejs developer? lpad() ftw? :P  But seriously, a native C++ interface is typesafe. Wrappign a C implementation to give it a C++ friendly interface would probably end up being the same size as the library itself.
 22 2017-08-08 07:51:50	0|gmaxwell|FWIW it's much simpler to implement bech32 than base58.
 23 2017-08-08 07:52:30	0|luke-jr|hmm
 24 2017-08-08 08:25:16	0|achow101|I suspect that #10982 is going to need to be locked soon due to brigading and trolling
 25 2017-08-08 08:25:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/10982 | Disconnect network service bits 6 and 8 until Aug 1, 2018 by TheBlueMatt · Pull Request #10982 · bitcoin/bitcoin · GitHub
 26 2017-08-08 08:25:26	0|jonasschnelli|How do we deal with the service bits 6 and 8? Should NODE_NETWORK_LIMITED avoid bit6 because something else claimed it (although not via BIP process)?
 27 2017-08-08 08:27:19	0|achow101|It was actually bits 5 and 7 that were claimed
 28 2017-08-08 08:30:09	0|luke-jr|kidnapped*? :P
 29 2017-08-08 08:33:09	0|jonasschnelli|achow101: Bip 7 is SW2x, right? Whats 5?
 30 2017-08-08 08:35:33	0|luke-jr|jonasschnelli: BCash I assume
 31 2017-08-08 08:51:30	0|luke-jr|achow101: sigh, would have been nice to get the commit message fixed before merging :/
 32 2017-08-08 08:54:22	0|gmaxwell|unfortunately s2x people were spamming their slack with it and such the moment it went up.
 33 2017-08-08 08:55:10	0|luke-jr|it would also be nice if we didn't merge things because of trolls :x
 34 2017-08-08 09:03:30	0|luke-jr|jonasschnelli: perhaps: uint16_t archival_data_flag = (servicebits & NODE_NETWORK_FLAG_MASK); if (servicebits & NODE_NETWORK) { … } else if (archival_data_flag == NODE_NETWORK_LIMITED_HIGH) { … } else if (archival_data_flag == NODE_NETWORK_LIMITED_LOW) { … } would fit nicely
 35 2017-08-08 09:18:51	0|MarcoFalke|Reminder to call gpg --keyserver pgp.mit.edu --refresh-keys F4316B9B
 36 2017-08-08 09:21:06	0|gmaxwell|achow101: depends on if you count the bits starting at 0 or 1
 37 2017-08-08 09:25:23	0|luke-jr|gmaxwell: which has always been counted from 0..
 38 2017-08-08 09:26:14	0|jnewbery|NODE_NONE must surely be zero?
 39 2017-08-08 09:26:23	0|gmaxwell|depends on your language,  "first bit" is 1<<0.
 40 2017-08-08 09:28:35	0|jonasschnelli|From what I read you usually start a 0
 41 2017-08-08 09:28:36	0|jonasschnelli|*at
 42 2017-08-08 09:28:41	0|bitcoin-git|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/fa8a0639f7b0...627c3c0e495b
 43 2017-08-08 09:28:42	0|bitcoin-git|13bitcoin/06master 1446347ad 15Wladimir J. van der Laan: rpc: Move ValueFromAmount to core_write...
 44 2017-08-08 09:28:42	0|bitcoin-git|13bitcoin/06master 14dac3782 15Wladimir J. van der Laan: doc: Correct AmountFromValue/ValueFromAmount names
 45 2017-08-08 09:28:43	0|bitcoin-git|13bitcoin/06master 14ec05c50 15Wladimir J. van der Laan: rpc: Use ValueFromAmount instead of FormatMoney in TxToUniv...
 46 2017-08-08 09:28:57	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10999: Fix amounts formatting in `decoderawtransaction` (06master...062017_08_decoderawtx_amount) 02https://github.com/bitcoin/bitcoin/pull/10999
 47 2017-08-08 09:42:09	0|bitcoin-git|13bitcoin/06master 14055d95f 15John Newbery: [wallet] return correct error code from resendwallettransaction
 48 2017-08-08 09:42:09	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/627c3c0e495b...4268426b4500
 49 2017-08-08 09:42:10	0|bitcoin-git|13bitcoin/06master 144268426 15Wladimir J. van der Laan: Merge #11002: [wallet] return correct error code from resendwallettransaction...
 50 2017-08-08 09:42:39	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #11002: [wallet] return correct error code from resendwallettransaction (06master...06resendwallettransaction_error_code) 02https://github.com/bitcoin/bitcoin/pull/11002
 51 2017-08-08 09:58:54	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/4268426b4500...2507fd55568b
 52 2017-08-08 09:58:55	0|bitcoin-git|13bitcoin/06master 14861f9a2 15Matt Corallo: Skip remainder of init if upgrade is cancelled
 53 2017-08-08 09:58:56	0|bitcoin-git|13bitcoin/06master 142507fd5 15Wladimir J. van der Laan: Merge #10998: Fix upgrade cancel warnings...
 54 2017-08-08 09:59:45	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10998: Fix upgrade cancel warnings (06master...062017-08-fix-upgrade-cancel-warnings) 02https://github.com/bitcoin/bitcoin/pull/10998
 55 2017-08-08 10:29:58	0|wumpus|doing last checks on 10882, after which I'll merge it. After that I'm planning to tag 0.15.0rc1. Any objections?
 56 2017-08-08 10:30:56	0|wumpus|(ah yes #10483 and #10607 too)
 57 2017-08-08 10:30:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/10483 | scripted-diff: Use the C++11 keyword nullptr to denote the pointer literal instead of the macro NULL by practicalswift · Pull Request #10483 · bitcoin/bitcoin · GitHub
 58 2017-08-08 10:30:58	0|gribble|https://github.com/bitcoin/bitcoin/issues/10607 | scripted-diff: stop using the gArgs wrappers by benma · Pull Request #10607 · bitcoin/bitcoin · GitHub
 59 2017-08-08 10:31:47	0|wumpus|then branching off 0.15, bumping version numbers, then tagging the release
 60 2017-08-08 10:32:52	0|gmaxwell|I think 10882 is still in a state where if you run getnewaddress to the pont where it exhausts your keypool then recieve a transaction your node shuts off.
 61 2017-08-08 10:33:46	0|wumpus|can you coment jnewbery?
 62 2017-08-08 10:33:51	0|wumpus|if so, i'm going to bump it to 0.15.1 instead
 63 2017-08-08 10:34:22	0|jnewbery|Yes, that's the case - I reverted to the commit that had ACKs
 64 2017-08-08 10:35:08	0|wumpus|is it enough of an improvement to merge it like this?
 65 2017-08-08 10:35:44	0|jnewbery|I think it's an improvement
 66 2017-08-08 10:35:54	0|wumpus|(or does it make things worse? I don't know anymore)
 67 2017-08-08 10:36:16	0|gmaxwell|It's a critical improvement, but I think the sequence of events I described should block a release, just like absense of this PR.  Keep in mind that most existing already encrypted wallets have less than 500 keys in their keypool already.
 68 2017-08-08 10:36:32	0|wumpus|you want to block the release on this?
 69 2017-08-08 10:37:12	0|gmaxwell|I think we need to turn HD off without this. We currently have non-trivial funds loss exposure without this.
 70 2017-08-08 10:37:22	0|wumpus|is it a regression since 0.14?
 71 2017-08-08 10:37:46	0|gmaxwell|It was introduced in 0.14 with hdwallet, though we only realized over time all the ways it could fail.
 72 2017-08-08 10:38:07	0|wumpus|I'd really dislike blocking 0.15
 73 2017-08-08 10:38:21	0|wumpus|anyone else think we should delay 0.15?
 74 2017-08-08 10:38:45	0|wumpus|as I understand, the plan is to do a 0.15.1 fairly quick after it anyway
 75 2017-08-08 10:39:02	0|gmaxwell|Agreed! but I don't think it's acceptable to keep shipping stuff we know will basically make people lose funds, and yet I don't think we can ship something that will just fall over on most encrypted wallets in use right now.
 76 2017-08-08 10:39:03	0|wumpus|so every day we delay here delays that, too
 77 2017-08-08 10:39:10	0|gmaxwell|I know.
 78 2017-08-08 10:39:28	0|wumpus|and if it was already broken in 0.14, and still broken in 0.15, releaseing at least won't make things worse
 79 2017-08-08 10:39:51	0|wumpus|delaying just means people will keep using 0.14.x in which it is broken too
 80 2017-08-08 10:40:24	0|gmaxwell|whatever we do next might be fast but it's not going to be days.
 81 2017-08-08 10:40:28	0|wumpus|anyhow, going back to other things then, we can postpone for another day at least
 82 2017-08-08 10:40:50	0|gmaxwell|jnewbery: can you make a second PR with the remaining parts
 83 2017-08-08 10:41:02	0|gmaxwell|I don't understand why that fix was removed.. it's really pretty broken without it.
 84 2017-08-08 10:41:06	0|jnewbery|I plan to
 85 2017-08-08 10:41:09	0|gmaxwell|OK.
 86 2017-08-08 10:41:40	0|jnewbery|because it and the other changes broke a test, and it was suggested I revert to a commit that already had lots of ACKs
 87 2017-08-08 10:41:52	0|wumpus|jnewbery: agree that doing a new PR is better
 88 2017-08-08 10:42:20	0|wumpus|let's just merge 10882 before the review there turns even more into a mess, if some state of a PR is sufficiently accepted and reviewed ideally no new things are added
 89 2017-08-08 10:42:28	0|gmaxwell|(It's not that I don't think we can merge whats there, but I think we can't release with it because it will fail very quickly for basically anyone with a pre-existing encrypted wallet)
 90 2017-08-08 10:42:46	0|wumpus|it will fail for anyone?
 91 2017-08-08 10:43:04	0|wumpus|ok, then I'm not going to merge it, I already had half a hart attack with a 'corrupted' wallet yesterday :p
 92 2017-08-08 10:43:13	0|gmaxwell|wumpus: right now with that PR if you get a transaction while your keypool has under 500 addresses in it, you'll shut down.
 93 2017-08-08 10:43:14	0|jnewbery|yes, I realise now that the combination of 10882 and increasing the keypool defaults probably breaks this for pre-existing wallets
 94 2017-08-08 10:43:42	0|gmaxwell|jnewbery: well this was going to need a look ahead greater than 50 regardless.
 95 2017-08-08 10:44:34	0|wumpus|then why does everyone ack it if it creates a broken situation
 96 2017-08-08 10:44:43	0|gmaxwell|jnewbery: sorry for my earlier comments on it not making it adequately clear that this applies to almost everyone, I just thought that pointing out that it would go down after a getnewaddress loop was enough. :)
 97 2017-08-08 10:46:25	0|luke-jr|wumpus: my only possibly-not-ignored objection I think, is to breaking backward compatibility for RPC :/  (#10989)
 98 2017-08-08 10:46:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/10989 | RPC: Restore backward compatibility, in multiwallet mode by luke-jr · Pull Request #10989 · bitcoin/bitcoin · GitHub
 99 2017-08-08 10:47:16	0|gmaxwell|luke-jr: I think that objection is acknoweldged and set aside. Making MW require the wallet was an intentional decision at least for now that basically everyone supported.
100 2017-08-08 10:47:29	0|jnewbery|wumpus - I think because it's been open for a long time and gone through many iterations, during which time the keypool defaults were increased. I've only just realised the implications from what gmaxwell said just now
101 2017-08-08 10:48:48	0|jnewbery|I can hopefully get a minimal PR on top of #10882 in the next hour that includes juse the getnewaddress fix. gmaxwell, will you be able to review today?
102 2017-08-08 10:48:51	0|gribble|https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
103 2017-08-08 10:49:20	0|luke-jr|so people will just be forced to switch to Knots to actually use MW I guess, whatever
104 2017-08-08 10:50:02	0|luke-jr|I suppose that's the same as with previous versions
105 2017-08-08 10:50:55	0|gmaxwell|luke-jr: come on dude, having to specify which wallet you want is not "having to use".  It's perhaps arguably less useful, but the feature is expiremental in this version.
106 2017-08-08 10:51:06	0|wumpus|multiwallet is experimental
107 2017-08-08 10:51:19	0|wumpus|even if it's completely useless in rc1, I'm not going to block the release on that
108 2017-08-08 10:51:41	0|wumpus|(and I know for sure it's not compltely useless)
109 2017-08-08 10:51:59	0|luke-jr|gmaxwell: no existing software uses the new API, and as you point out, the new API is experimental.. so there's basically no way to get the primary "just keep wallets in sync" benefit without using a new experimental API
110 2017-08-08 10:52:32	0|gmaxwell|luke-jr: bitcoin cli works, and many other things are easy to get working...
111 2017-08-08 10:52:37	0|luke-jr|anyway, I acknowledge that this isn't going to be fixed; I'm just not happy about it.
112 2017-08-08 10:52:45	0|gmaxwell|I agree it dimishes the wallet warming usecase.
113 2017-08-08 10:54:14	0|gmaxwell|luke-jr: the concern people have about accidentally interacting with the wrong wallet is a good one though. It's an obvious footgun and it's more conservative to avoid it for now.
114 2017-08-08 10:54:53	0|gmaxwell|luke-jr: also, perhaps that walletwarming usecase would better be met with a seperate state e.g. a scanwallet=file  where there is no risk of accidentally using it beyond getting some status about it.
115 2017-08-08 10:55:09	0|luke-jr|gmaxwell: yes, I agree that's a reasonable concern. I don't know a way to address it.
116 2017-08-08 10:55:25	0|luke-jr|hopefully MW will be more than warming by 0.16 anyway
117 2017-08-08 10:55:55	0|luke-jr|(I actually think it might have been better to release without *any* RPC MW support, than with what we have now)
118 2017-08-08 10:56:25	0|luke-jr|(that'd solve the footgun issue, while not breaking the warming use case)
119 2017-08-08 10:56:29	0|gmaxwell|luke-jr: fwiw, I think it would be more constructive on concerns like this if instead of just saying it's wrong, if you walked us through the specific case that you care about that it screws up.  It's a lot easier to sympatize with your concern if someone understands it, and they can't unless you explain it.  When you just state matter of factly that it's currently wrong or broken, it's random c
120 2017-08-08 10:56:35	0|gmaxwell|hance if any given person will understand why you think that.
121 2017-08-08 10:57:00	0|gmaxwell|luke-jr: For many people, updating to make the calls (e.g. cli users) is trivial.
122 2017-08-08 10:57:06	0|luke-jr|gmaxwell: my understanding was that it's basically the only real use case 0.15 will support MW for
123 2017-08-08 10:57:09	0|gmaxwell|and being able to actually use MW will be nice.
124 2017-08-08 10:57:46	0|gmaxwell|luke-jr: that wasn't my understanding. Actually, I didn't even really know people were thinking that much about "warming but not using" until I read the release note text re: GUI.  Which I assume you wrote.
125 2017-08-08 10:58:25	0|gmaxwell|Though I agree it's a useful thing to do, esp in a world with pruning.. (also rescan times are a seriously negative part of my life these days)
126 2017-08-08 10:59:02	0|luke-jr|(FWIW, Newbery wrote it)
127 2017-08-08 10:59:04	0|gmaxwell|I manage cold wallets for myself, for blockstream, for varrious projects... and it's not uncommon that I lose hours of waiting due to having to rescan something.
128 2017-08-08 10:59:08	0|gmaxwell|ah okay!
129 2017-08-08 10:59:50	0|jnewbery|yeah - I think for qt-only users warming is the only use in v0.15
130 2017-08-08 11:00:00	0|luke-jr|I suppose a reasonable compromise is to have a command-line option to set a default wallet, and only support it in that case. But probably too late to get it into 0.15
131 2017-08-08 11:00:05	0|jnewbery|but for RPC users, multiwallet is fully supported
132 2017-08-08 11:00:23	0|luke-jr|hmm. can a Qt user even access their wallet via debug console now?
133 2017-08-08 11:01:45	0|jnewbery|yes, just wallet 0
134 2017-08-08 11:01:55	0|jnewbery|#10870
135 2017-08-08 11:01:57	0|gribble|https://github.com/bitcoin/bitcoin/issues/10870 | [Qt] Use wallet 0 in rpc console if running with multiple wallets by jonasschnelli · Pull Request #10870 · bitcoin/bitcoin · GitHub
136 2017-08-08 11:03:42	0|luke-jr|ah
137 2017-08-08 11:05:05	0|jnewbery|gmaxwell - I don't think the getnewaddress changes you're asking for in 10882 address the encrypted-wallet-with-fewer-than-500-keys issue that you just raised
138 2017-08-08 11:05:30	0|jnewbery|basically every HD wallet now has fewer than 500 keys
139 2017-08-08 11:06:20	0|jnewbery|so on upgrade, everyone with an encrypted HD wallet will have their node shut down and be presented with the 'restart with bypasskeypoolcritical blah blah blah' error
140 2017-08-08 11:07:13	0|jnewbery|it's not a loss of funds risk, but it's a terrible first user impression of v0.15
141 2017-08-08 11:08:53	0|gmaxwell|the whole thing is a bit weird. When the wallet is current there is no need for the keypool to have lookahead.
142 2017-08-08 11:10:20	0|gmaxwell|But I didn't want to get into dictating major changes to it.
143 2017-08-08 11:13:08	0|wumpus|maybe it should only enlarge the keypool the first time the user unlocks the wallet
144 2017-08-08 11:13:10	0|wumpus|after upgrading
145 2017-08-08 11:13:18	0|Lauda|Does anyone know what the limiting factor for rescan speed is? I have been running a few imports on a fairly good machine, and I don't see everything being utilized whilst this is taking up a lot of time (single key 2+ hours). Disk I/O maybe?
146 2017-08-08 11:13:56	0|Lauda|CPU <20% on average, 2 GB of RAM out of 32 (with dbcache 12GB).
147 2017-08-08 11:14:37	0|wumpus|rescan could be a lot faster if you'd not care about transaction history, then it'd only have to scan over the utxo set instead of every single block
148 2017-08-08 11:15:15	0|Lauda|I don't, I just care about the final balance (in this case). Is there an option to ignore the TX history?
149 2017-08-08 11:15:49	0|Lauda|Seems like rescan speed will keep getting much worse with time, no?
150 2017-08-08 11:16:36	0|jnewbery|wumpus, the problem is that keypool_critical was changed to 500 during the iterations of this PR (when keypool was changed to 1000). We'd need a way for keypool_critical to be lowered to 50 on the first run after upgrading, or similar. I can't think of a good way to do that
151 2017-08-08 11:20:18	0|Lauda|I should also note that it is taking over 2 hours on a VPS with an SSD. I wonder how much of a difference it would make with an HDD (% duration increase).
152 2017-08-08 11:34:43	0|gmaxwell|the rescan is slow presumably because it deseralizes each block and each transaction and hashes each trasnaction and does dozens of memory allocations for each transactions.
153 2017-08-08 11:35:28	0|gmaxwell|It could probably take your scriptpubkeys and txns as bytes and scan the raw block data without deseralizing things and be 500 times faster... but it would be a fair amount of work to implement that.
154 2017-08-08 11:36:23	0|gmaxwell|jnewbery: keypool_criticial being 50 is not really reasonable in any case. it would miss transactions in many of my existing wallets, for example, and I doubt my usage is that atypical.
155 2017-08-08 11:36:47	0|gmaxwell|jnewbery: I think the bigger point though is that when the wallet is current there is no reason to shut down.
156 2017-08-08 11:37:10	0|gmaxwell|It doesn't matter if there is look ahead if the wallet hasn't fallen behind.
157 2017-08-08 11:37:13	0|wumpus|yes, it will get slower with time, assuming you're donig a full rescan
158 2017-08-08 11:37:31	0|wumpus|if you rescan a more or less fixed number of blocks it should stay at the same speed
159 2017-08-08 11:37:41	0|wumpus|or at least not become much slower...
160 2017-08-08 11:38:44	0|wumpus|and yes, rescan as it is could certainly be optimized, though I doubt anyone sees it as that much of a priority
161 2017-08-08 11:38:58	0|jnewbery|"when the wallet is current there is no reason to shut down." - the getnewaddress change doesn't fix that
162 2017-08-08 11:39:33	0|Lauda|gmaxwell that sounds like a good optimization for the future. Thanks for the responses.
163 2017-08-08 11:39:54	0|wumpus|you're welcome to give it a try of course
164 2017-08-08 11:40:57	0|gmaxwell|jnewbery: I realize this. When you suggested that I thought it would be simpler than another solution.
165 2017-08-08 11:44:09	0|jnewbery|I must have misunderstood you in the issue. I suggested the getnewaddress change because I thought you were talking about running getnewaddress 500 times. I didn't realise there was an upgrade issue until you mentioned it today
166 2017-08-08 11:46:27	0|gmaxwell|I was just trying to give an example where the keypool would be below the threshold. I don't really see them as different... end result is the same regardless of how you get there. Sorry.
167 2017-08-08 11:47:08	0|gmaxwell|e.g. imagine that the crit threshold were still 50, you'd still have existing wallets shut down immediately, or after the user executes a dozen getnewaddresses. :)
168 2017-08-08 11:47:33	0|gmaxwell|Just fewer of them.
169 2017-08-08 11:47:56	0|gmaxwell|but they'd mostly all die eventually except for users that unlock frequently before running out.
170 2017-08-08 11:55:00	0|jnewbery|ok, so how do we fix this?
171 2017-08-08 11:55:12	0|jnewbery|Offline keypool topup would be *really* useful
172 2017-08-08 11:58:12	0|gmaxwell|jnewbery: Can we distinguish the case where we are current vs rescanning? If so, then we just shouldn't perform the shutdown when we're current.
173 2017-08-08 12:04:50	0|gmaxwell|I think it would still be good to stop newaddresses short of the limit, so that we don't immediately go into shutdown on any attempt to rescan when the pool is empty.. but that is a less criticial improvement.
174 2017-08-08 12:05:16	0|jnewbery|We rescan from the wallet's best block on startup. So even with that change, we're going to barf on upgrade
175 2017-08-08 12:06:36	0|jnewbery|(unless you shutdown v0.14, upgrade, start v0.15 before a block has been produced)
176 2017-08-08 12:07:01	0|gmaxwell|hm. but we don't have those blocks at startup.
177 2017-08-08 12:07:29	0|gmaxwell|when we start, the best block should be the same... though yea, IIRC we do a rescan in any case. I think just as a belt and suspenders check.
178 2017-08-08 12:08:01	0|jnewbery|oh, ok. Makes sense
179 2017-08-08 12:11:42	0|morcos|jnewbery: gmaxwell: i dont have all the code handy, but just brainstorming a quick fix for 0.15
180 2017-08-08 12:11:54	0|morcos|wouldn't it be possible to take advantage of the two different limits
181 2017-08-08 12:12:19	0|gmaxwell|I think that initial rescan can be disabled, but it's been so long since I've thought about it, there may be reasons that I am not remembering.
182 2017-08-08 12:12:24	0|morcos|if we set keypoolmin to 500 and keypoolcritical to 25, then don't we not miss anything since our best block has stopped advancing?
183 2017-08-08 12:13:01	0|gmaxwell|oh. that is an interesting point, but what about wallets with empty keypools
184 2017-08-08 12:13:10	0|gmaxwell|(below 25)
185 2017-08-08 12:13:19	0|morcos|then with the release notes we can recommend running walletpasphrase as soon as you startup  so your keypool will top up to the new bigger amounts
186 2017-08-08 12:13:42	0|morcos|oh wait, that doesnt work exactly...
187 2017-08-08 12:13:45	0|morcos|shoot
188 2017-08-08 12:14:06	0|morcos|also it would be potentially a problem for pruned nodes
189 2017-08-08 12:14:18	0|gmaxwell|need a third number, but then I think it does except for but what if there isn't even 25.. and pruned.
190 2017-08-08 12:15:10	0|morcos|i need to look at the code, but right now i actually think it is a broken state to set keypoolmin different from keypoolcritical
191 2017-08-08 12:15:23	0|gmaxwell|morcos: If instead we just make it so that the only time this applies is when the wallet has fallen behind the node tip (or is otherwise rescanned)-- then I think that would be fine.
192 2017-08-08 12:15:56	0|gmaxwell|You'd still get forced into topping up anytime you imported keys, moved wallets between nodes, etc.. but normal operation wouldn't run into it.
193 2017-08-08 12:17:41	0|gmaxwell|I believe the reason we do rescanning at tip even when we're in sync (assuming we still do it) was a concern about reorgs and or the wallet not getting flushed consistently with blocks in an unclean shutdown or something like that.
194 2017-08-08 12:17:59	0|morcos|The scary thing to me is the way we turn off setting the best block, but then potentially turn it back on if we haven't rescanned (thereby missing scanning a bunch of blocks)
195 2017-08-08 12:18:20	0|morcos|i haven't looked at the most recent code, and maybe ryanofsky's suggestion fixed that i don't remember
196 2017-08-08 12:19:00	0|morcos|i'm going to stop giving out ideas until i look more closely at the code again
197 2017-08-08 12:19:23	0|morcos|but for the record wumpus, my view is it would be better to delay 0.15 (even by a week or two) to get this right
198 2017-08-08 12:20:14	0|morcos|i think we're getting pretty well into understanding all the issues now, so would be good to fix it while it's fresh, and it also seems like a big enough problem, that would be nice to fix before release
199 2017-08-08 12:24:34	0|sdaftuar|i think #10982 should be locked
200 2017-08-08 12:24:37	0|gribble|https://github.com/bitcoin/bitcoin/issues/10982 | Disconnect network service bits 6 and 8 until Aug 1, 2018 by TheBlueMatt · Pull Request #10982 · bitcoin/bitcoin · GitHub
201 2017-08-08 12:27:25	0|gmaxwell|:(
202 2017-08-08 12:32:12	0|jnewbery|morcos - I think ryanofsky's change is helpful. I tried including it but it broke tests, so I rolled back to a previous commit
203 2017-08-08 12:34:39	0|jnewbery|gmaxwell - ShutdownIfKeypoolCritical() is only called in CreateWalletFromFile() and AddToWalletIfInvolvingMe(). I think your change would be to remove it from CreateWalletFromFile(), and only call it from AddToWalletIfInvolvingMe() if that function was called by SyncTransaction() (and not by ScanForWalletTransactions())
204 2017-08-08 12:35:51	0|jnewbery|I think I know what I need to do - re-add the getnewaddress changes, re-add ryanofksy's changes about setting best block, and make the change above
205 2017-08-08 12:41:41	0|sdaftuar|MarcoFalke: thank you
206 2017-08-08 12:41:51	0|wumpus|MarcoFalke: you just beat me to it :)
207 2017-08-08 12:42:07	0|MarcoFalke|Too much mail spam :(
208 2017-08-08 12:43:32	0|gmaxwell|:-( sorry that i even commented on it at all, it just made it worse
209 2017-08-08 13:03:38	0|jnewbery|~.
210 2017-08-08 13:03:49	0|sipa|agree.
211 2017-08-08 14:48:31	0|wumpus|jnewbery: maybe reverting the default mempool size increase for 0.15.0 will make this easier?
212 2017-08-08 15:03:10	0|Chris_Stewart_5|How long do we support gcc versions? Curious for #8469
213 2017-08-08 15:03:12	0|gribble|https://github.com/bitcoin/bitcoin/issues/8469 | [POC] Introducing property based testing to Core by Christewart · Pull Request #8469 · bitcoin/bitcoin · GitHub
214 2017-08-08 15:04:18	0|wumpus|Chris_Stewart_5: there's no fixed policy on that - the preference is to support all compilers unless there's a good reason not to, such as lack of c++11 support
215 2017-08-08 15:19:02	0|jnewbery|wumpus: yes, that would resolve the upgrade issue, although I'm sure gmaxwell will argue against that
216 2017-08-08 15:33:22	0|wumpus|sure, I just mean maybe we can't have everything in a timeframe soon enough for 0.15.0 and we need to make choices
217 2017-08-08 15:35:12	0|luke-jr|Chris_Stewart_5: it would be pretty bad to not build on popular stable OSs
218 2017-08-08 15:36:12	0|luke-jr|so I'd check Fedora, Debian, RedHat/CentOS, Gentoo, Ubuntu at least
219 2017-08-08 15:36:28	0|luke-jr|IIRC typically the hold-back is CentOS
220 2017-08-08 15:37:32	0|wumpus|luke-jr: it doesn't even work on travis
221 2017-08-08 15:37:55	0|luke-jr|heh
222 2017-08-08 15:38:16	0|wumpus|gcc 4.8 isn't *that* old and crappy yet, I doubt we should drop support just to be able to do tests in a certain way
223 2017-08-08 15:38:52	0|wumpus|and the tests working on travis is kind of important, so disabling them on gcc 4.8 isn't going to fly either
224 2017-08-08 15:39:03	0|luke-jr|right
225 2017-08-08 15:39:31	0|bitcoin-git|[13bitcoin] 15practicalswift opened pull request #11007: [qt] Fix memory leak when loading a corrupted wallet file (06master...06wallet-corrupted-leak) 02https://github.com/bitcoin/bitcoin/pull/11007
226 2017-08-08 15:39:55	0|Chris_Stewart_5|Yes, 4.8.4 was released in Dec of 2014
227 2017-08-08 15:40:22	0|Chris_Stewart_5|ancient in terms of bitcoin! :P
228 2017-08-08 15:40:23	0|sam_c|gentoo is about to mask 4.8
229 2017-08-08 15:43:46	0|wumpus|besides that, we already got lots of complaints that we're requiring a c++11 compiler, I"d prefer to keep the compiler requirement the same for the forseeable future
230 2017-08-08 15:46:45	0|Chris_Stewart_5|wumpus: Do we have a 'rough' estimate on when 0.15.0 will be done?
231 2017-08-08 15:52:45	0|wumpus|Chris_Stewart_5: yes, rc1 was planned for the 6th, we've slipped two days now
232 2017-08-08 15:54:41	0|wumpus|(which is perfectly normal)
233 2017-08-08 16:04:57	0|luke-jr|sam_c: is it? why?
234 2017-08-08 16:05:31	0|luke-jr|actually, it looks like it's been masked since May, just because it's old O.o
235 2017-08-08 16:08:03	0|Chris_Stewart_5|cool, was just curious
236 2017-08-08 18:58:17	0|jcorgan|congrats
237 2017-08-08 18:59:43	0|AaronvanW|+1
238 2017-08-08 19:00:41	0|arubi|I mean, congrats!  :)  but also that
239 2017-08-08 19:00:41	0|arubi|when's "status" going to change to "locked-in" ?
240 2017-08-08 19:00:46	0|gmaxwell|oh I guess, barring no reorgs segwit lockin is now guarenteed.
241 2017-08-08 19:01:21	0|gmaxwell|arubi: the thing happening now is that there aren't enough blocks left to prevent a lock in, but it won't lock in for another day or so IIRC.
242 2017-08-08 19:01:41	0|arubi|so I was just informed it happens at the end of the period
243 2017-08-08 19:01:56	0|gmaxwell|so even if all blocks for the next of the window don't signal segwit it will still lock in.
244 2017-08-08 19:02:32	0|jcorgan|something like 16-17 hours from now
245 2017-08-08 19:02:42	0|arubi|right, my confusion was re. the 'getblockchaininfo' "status" filed to changing after 95% rather than at the end of the period
246 2017-08-08 19:02:44	0|jcorgan|for end of period
247 2017-08-08 19:03:05	0|Chris_Stewart_5|Mmmm ok
248 2017-08-08 19:19:59	0|gmaxwell|12:19:19 <@betawaffle> gmaxwell: can you congratulate everyone involved in segwit for us?
249 2017-08-08 19:20:11	0|sdaftuar|i guess we can cross "activate segwit" off the list of action items
250 2017-08-08 19:21:47	0|gmaxwell|\O/
251 2017-08-08 19:22:16	0|jnewbery|gmaxwell morcos wumpus (and anyone else who's interested in wallet topup). I've pushed a branch which I think covers gmaxwell's requested logic:
252 2017-08-08 19:22:19	0|jnewbery|- don't shutdown the node on startup if keypool is < keypool_critical
253 2017-08-08 19:22:22	0|jnewbery|- don't shutdown the node if wallet is current
254 2017-08-08 19:22:24	0|jnewbery|- DO shutdown the node if rescanning and keypool drops below
255 2017-08-08 19:22:27	0|jnewbery|#10882
256 2017-08-08 19:22:27	0|jnewbery|keypool_critical
257 2017-08-08 19:22:30	0|gribble|https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
258 2017-08-08 19:22:33	0|gmaxwell|When does the period end? exactly, it would kinda be nice if rc1 lands just after that, so that miners running BIP-91 code can safely try rc1.
259 2017-08-08 19:23:00	0|jnewbery|getnewaddress should also be safe
260 2017-08-08 19:23:28	0|gmaxwell|sdaftuar: now we just need to get people to modulate their hashrate so that the activation coincides with the solar eclipse. It's pretty close.
261 2017-08-08 19:23:29	0|jnewbery|also includes ryanofsky's m_update_best_block
262 2017-08-08 19:23:38	0|gmaxwell|(quick, someone make more spinoffs)
263 2017-08-08 19:23:55	0|luke-jr|lol
264 2017-08-08 19:24:58	0|gmaxwell|jnewbery: where is the branch?
265 2017-08-08 19:25:35	0|jnewbery|#10882
266 2017-08-08 19:25:39	0|gribble|https://github.com/bitcoin/bitcoin/issues/10882 | Keypool topup by jnewbery · Pull Request #10882 · bitcoin/bitcoin · GitHub
267 2017-08-08 19:26:08	0|gmaxwell|jnewbery: oh great
268 2017-08-08 19:27:09	0|jnewbery|This should fix the upgrade issue. bitcoind v0.15 won't shutdown first time you run it with an old encrypted HD wallet
269 2017-08-08 19:31:18	0|jnewbery|but if you don't unlock and topup your keypool before you shutdown the node, then I expect it'll refuse to start the next time (since your node tip will advance but your wallet best block won't)
270 2017-08-08 19:31:43	0|gmaxwell|Right. We may need to do a bit of warning related to this pattern still:
271 2017-08-08 19:31:55	0|gmaxwell|wallet is below 500 because it's old and encrypted.
272 2017-08-08 19:32:10	0|gmaxwell|you start, life is good, but you are not updating the best block.
273 2017-08-08 19:32:30	0|gmaxwell|then you restart, and now the wallet is behind.
274 2017-08-08 19:32:39	0|gmaxwell|it rescans, and life becomes sad.
275 2017-08-08 19:33:59	0|jnewbery|yes, sad, but better than any alternative as far as I can see
276 2017-08-08 19:34:36	0|jnewbery|there is a warning that your keypool is below keypool_min and your best block isn't advancing
277 2017-08-08 19:35:30	0|jnewbery|2017-08-08 19:19:20 Keypool has fallen below keypool_min (500). Wallet will no longer watch for new transactions and best block height will not be advanced.
278 2017-08-08 19:35:34	0|jnewbery|2017-08-08 19:19:20 Unlock wallet, top up keypool and rescan to resume watching for new transactions.
279 2017-08-08 19:35:56	0|jnewbery|Perhaps that could be made more explicit "TOP UP KEYPOOL BEFORE NEXT RESTART!"
280 2017-08-08 19:39:33	0|luke-jr|Can we add a new checkpoint? (Minimally invasive way to lock Segwit in hard)
281 2017-08-08 19:40:05	0|gmaxwell|luke-jr: No.
282 2017-08-08 19:40:19	0|gmaxwell|Thats not a proper or interesting thing to do.
283 2017-08-08 19:40:37	0|luke-jr|just to eliminate the FUD around miners potentially reorging it out
284 2017-08-08 19:41:11	0|gmaxwell|luke-jr: you should do what we would eventually do, make a patch that removes the activation and just replaces it with a height comparison.
285 2017-08-08 19:41:25	0|luke-jr|Isn't it too late for that in 0.15?
286 2017-08-08 19:42:38	0|gmaxwell|probably, but we should still write the patch.
287 2017-08-08 19:43:03	0|luke-jr|to be clear: I meant the new checkpoint specifically for 0.15.0 only
288 2017-08-08 19:43:24	0|gmaxwell|luke-jr: but just pinning the consensus isn't a right thing to do, and especially violating the rules for setting the things.
289 2017-08-08 19:43:39	0|luke-jr|"violating the rules for setting the things."?
290 2017-08-08 19:44:10	0|gmaxwell|luke-jr: there is a spec for setting that requires them to be set at least 2016 blocks in the past.
291 2017-08-08 19:44:23	0|luke-jr|it will be by the time 0.15.0 is released
292 2017-08-08 19:44:24	0|gmaxwell|to avoid legislating the ledger state.
293 2017-08-08 19:44:59	0|gmaxwell|also neighter of these things will prevent the reorg around the activation and steal outputs along the way.
294 2017-08-08 19:45:21	0|gmaxwell|luke-jr: it's important to enforce these things by the time we'd issue SW addresses, less so before.
295 2017-08-08 19:45:37	0|luke-jr|hmm, true, I guess we'd need to be checkpointing the actual activation block for that. and there isn't 2016 blocks there.
296 2017-08-08 19:46:02	0|luke-jr|gmaxwell: Core is more than just a wallet, and wallets besides Core exist..
297 2017-08-08 19:46:08	0|sdaftuar|while on the subject of cleaning up technical debt associated with prior soft fork deployments: #10695 could use review
298 2017-08-08 19:46:09	0|gribble|https://github.com/bitcoin/bitcoin/issues/10695 | [qa] Rewrite BIP65/BIP66 functional tests by sdaftuar · Pull Request #10695 · bitcoin/bitcoin · GitHub
299 2017-08-08 19:46:13	0|sdaftuar|or merge
300 2017-08-08 19:46:50	0|sdaftuar|we should write the csv-height-activation patch first imo
301 2017-08-08 19:46:59	0|jnewbery|10695 looks good to me
302 2017-08-08 19:48:08	0|sdaftuar|jnewbery: did we ever fix the ComparisonTestFramework for the bug i mentioned in the OP of that PR?
303 2017-08-08 19:50:04	0|jnewbery|I think we had buy-in for rewriting the ComparisonTestFramework scripts using the standard BitcoinTestFramework
304 2017-08-08 19:50:35	0|jnewbery|In fact I've already done that for some of them, but it depends on TestNode and will several months of rebasing
305 2017-08-08 19:50:46	0|jnewbery|*will need
306 2017-08-08 19:50:50	0|sdaftuar|re-reading my message there though i think there was an immediate bug that makes our comparisonTestFramework tests (perhaps including p2p-fullblocktest?) not test anything.
307 2017-08-08 19:50:53	0|gmaxwell|jnewbery: I'm still feeling this solution is incomplete. For example, one of my wallets (though not hd) is a encrypted wallet I use for watching cold funds. I'm never going to unlock the darn thing, its keypool is empty right now.   Maybe what we should do for this release is merge the scan and mark as use and topup if possible but instead of shutting down, spam errors that the keypool ran out a
308 2017-08-08 19:50:59	0|gmaxwell|nd your wallet balance may be incorrect.
309 2017-08-08 19:51:51	0|jnewbery|we don't shutdown for non-HD wallets
310 2017-08-08 19:52:18	0|gmaxwell|jnewbery: I know we don't, but my useage pattern wouldn't be any different if this wallet were HD.
311 2017-08-08 19:53:53	0|gmaxwell|I still don't think we have this handling cooked, in that we'll make 0.15 unusable for at least some people or very awkward.  I think we can do better even if I don't know how yet. But it's critical we do something, because without the mark use thing there are several ways to result in serious funds loss. (including giving customers addresses you already gave to other customers, then crediting t
312 2017-08-08 19:53:59	0|gmaxwell|he wrong accounts when people make payments..)
313 2017-08-08 20:00:00	0|sdaftuar|gmaxwell: in your watching cold funds example, would restarting with a -keypoolmin=0 be sufficient for the use case?
314 2017-08-08 20:01:17	0|sdaftuar|(perhaps i don't quite understand the PR though, so ignore me if my question doesn't make sense)
315 2017-08-08 20:03:39	0|gmaxwell|Yes. It is. I suppose we can just release note that. "If you want to run like this, set that." good point.
316 2017-08-08 20:04:53	0|jnewbery|thanks sdaftuar. I think that covers greg's use case
317 2017-08-08 20:05:48	0|jnewbery|gmaxwell can we try to evealuate whether this fixes the immediate problem (potential funds loss). We can fix up awkward behaviour post-branch
318 2017-08-08 20:06:42	0|gmaxwell|my concern there is that we also need to not introduce something that leaves lots (?) of people stuck. But sdaftuar answers how it doesn't.
319 2017-08-08 20:13:13	0|sdaftuar|has anyone given thought to how these keypool parameters work with multiwallet?
320 2017-08-08 20:15:34	0|sdaftuar|eg if we advise people to use -keypoolmin=0 to solve one situation, and they load up two wallets, are they jeopardizing themselves?
321 2017-08-08 20:17:55	0|jnewbery|yes, if you use -keypoolmin=0 you can get into a state where your best block has advanced while your keypool is depleted
322 2017-08-08 20:18:08	0|jnewbery|and so potentially miss transactions
323 2017-08-08 20:18:20	0|bitcoin-git|[13bitcoin] 15gmaxwell opened pull request #11008: Enable disablesafemode by default. (06master...06no-safe-mode) 02https://github.com/bitcoin/bitcoin/pull/11008
324 2017-08-08 20:19:13	0|jnewbery|but keypoolmin is a hidden debug option. I don't think we're going to be advertising it widely
325 2017-08-08 20:20:15	0|bitcoin-git|[13bitcoin] 15rawodb opened pull request #11009: Add information about the next state in getblockchaininfo rpc request (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11009
326 2017-08-08 20:23:45	0|jonasschnelli|sdaftuar, luke-jr: about NODE_NETWORK_LIMITED_*. If we would treat them independently, would this mean, a peer signalling NODE_NETWORK_LIMITED_HIGH will always singal NODE_NETWORK_LIMITED_LOW?
327 2017-08-08 20:23:56	0|jonasschnelli|And there would be no special case for a peer signaling both bits?
328 2017-08-08 20:24:11	0|jonasschnelli|I agree that would make most sense.
329 2017-08-08 20:24:17	0|sdaftuar|jonasschnelli: in my opinion, a peer should signal both if it offers both
330 2017-08-08 20:24:25	0|bitcoin-git|[13bitcoin] 15rawodb closed pull request #11009: Add information about the next state in getblockchaininfo rpc request (06master...06master) 02https://github.com/bitcoin/bitcoin/pull/11009
331 2017-08-08 20:24:57	0|sdaftuar|that way if someone wants to write a bitcoin network client that only worries about one of those properties, they don't need to do any complicated reasoning
332 2017-08-08 20:25:02	0|jonasschnelli|We would just loose the third state for the two new bits for pure logical consistence reasons. But I guess this makes sense.
333 2017-08-08 20:25:43	0|sdaftuar|i would actually suggest that we rename the service bits too, if it's not too much bikeshedding...  NODE_NETWORK is a non-descriptive term for full node to begin with
334 2017-08-08 20:25:58	0|sdaftuar|and putting LIMITED in the name implies denial of "full" services, which i think isn't want we want
335 2017-08-08 20:25:59	0|jonasschnelli|We only have 24 useful service bits (~10 are gone)
336 2017-08-08 20:26:20	0|bitcoin-git|[13bitcoin] 15rawodb opened pull request #11010: Add information about the next state in getblockchaininfo rpc request (06master...06pr/getblockchaininfo) 02https://github.com/bitcoin/bitcoin/pull/11010
337 2017-08-08 20:26:47	0|jonasschnelli|sdaftuar: Agree with renaming
338 2017-08-08 20:26:57	0|jonasschnelli|sdaftuar: any proposals?
339 2017-08-08 20:26:58	0|sdaftuar|i guess i haven't come up with good alternatives yet, but something which means "NODE_RECENT_BLOCKS" or "NODE_REALLY_RECENT_BLOCKS" is along the lines of what i'm thinking
340 2017-08-08 20:27:07	0|sdaftuar|(those are not actual proposals, just intuition)
341 2017-08-08 20:28:03	0|jonasschnelli|The question is also if NODE_NETWORK implies more then just historical block responses...
342 2017-08-08 20:29:50	0|sdaftuar|yeah that's a good question, it's not obvious to me
343 2017-08-08 20:30:09	0|sdaftuar|ie we have non-NODE_NETWORK nodes (pruning nodes) which do all the rest, already
344 2017-08-08 20:31:00	0|jonasschnelli|I guess there is no concrete definition what a peer must confirm to to allow signalling NODE_NETWORK (expect the reference implementation)
345 2017-08-08 20:31:31	0|sipa|yeah, node_network just means "all the things" :)
346 2017-08-08 20:31:38	0|jonasschnelli|also, SPV is also ~NODE_NETWORK (!= pruned)
347 2017-08-08 20:31:54	0|jonasschnelli|~(== bit unset)
348 2017-08-08 20:32:07	0|sdaftuar|right, but SPV is certainly allowed to eg relay addresses... not sure if any do.
349 2017-08-08 20:32:22	0|jonasschnelli|Which results in that NODE_NETWORK_LIMITED somehow includes tx/block relay
350 2017-08-08 20:35:31	0|sipa|i guess it's reasonable to suggest that every node can participate in address murmuring, regardless of service flags
351 2017-08-08 20:35:37	0|sipa|it's an ootional thing regardless
352 2017-08-08 20:36:05	0|sipa|since compact blocks, it doesn't really make sense to have separate services for tx relay and block relay
353 2017-08-08 20:36:47	0|sipa|so the only question is whether we want to have a separate bit for relay vs historical fetch (even if it's just 144 blocks deep)
354 2017-08-08 20:37:39	0|sipa|any client right now will want both
355 2017-08-08 20:38:17	0|jonasschnelli|sipa: for a possible use case where a peer serves historical blocks but won't relay (pure block storage)?
356 2017-08-08 20:38:37	0|sdaftuar|if no clients currently offer one but not the other, i don't think it makes sense to split that now.  we can wait til someone wants to build that.
357 2017-08-08 20:39:06	0|jonasschnelli|Agree
358 2017-08-08 20:41:00	0|sipa|sdaftuar: right... the only downside is that it'd cost another bit later
359 2017-08-08 20:42:07	0|sdaftuar|sipa: we either take that 1 bit cost now or later, right?  unless there's a proposal for distinguishing now that saves a bit, which i missed?
360 2017-08-08 20:46:47	0|sipa|sdaftuar: if we now have 3 bits (relay_tx_and_blocks, blocks_144, blocks_1008), we're good. if we only have (relay_tx_and_blocks_up_to_144, blocks_1008), we may need 2 extra bits later (relay_tx_blocks, blocks_144) totalling 4 bits, where one just implies two other ones
361 2017-08-08 20:48:59	0|jonasschnelli|I think the current definition of NODE_NETWORK_LIMITED_LOW is:
362 2017-08-08 20:49:06	0|jonasschnelli|NODE_NETWORK_LIMITED_LOW means the same as NODE_NETWORK with the limitation of only serving the last 288 (2 day) blocks
363 2017-08-08 20:49:23	0|jonasschnelli|(coupled to the definition of NODE_NETWORK)
364 2017-08-08 20:49:43	0|jonasschnelli|Changing the block value is possible though the client/protocol version?
365 2017-08-08 20:50:47	0|jonasschnelli|If we want relay as an extra option (assume full block SPV may want to service historical blocks but not relay) another bit would be required
366 2017-08-08 20:54:14	0|sdaftuar|sipa: i think blocks_144 and blocks_1008 without relay_tx_and_blocks are sort of nonsensical; by definition you're always willing to provide the current tip, and you never have guarantees that transactions will be relayed to you eg due to policy differences, so i don't think of that as much of a promise.
367 2017-08-08 20:54:19	0|sdaftuar|but putting that aside:
368 2017-08-08 20:54:35	0|sdaftuar|i think we could downgrade those service bits in the future to "may or may not relay blocks and transactions"
369 2017-08-08 20:54:44	0|sdaftuar|if we wanted to save a bit
370 2017-08-08 20:54:49	0|sdaftuar|oh
371 2017-08-08 20:55:03	0|sdaftuar|i guess i'm not sure what i'm comparing...
372 2017-08-08 20:55:59	0|sdaftuar|i'm taking jonas' proposal as relay_tx_and_blocks_up_to_144, relay_tx_and_blocks_up_to_1008
373 2017-08-08 20:56:05	0|sipa|sdaftuar: but there is a technical difference
374 2017-08-08 20:56:21	0|sdaftuar|and suggesting we could in the future add a single bit saying relay_tx_and_blocks
375 2017-08-08 20:56:52	0|sdaftuar|and at the point we add that, we say that there are no promises on the quality of service you get from older nodes that aren't setting the new bit
376 2017-08-08 20:57:03	0|sipa|sdaftuar: for example relay_blocks_tx could imply support for tx/inv(tx)/cmpctblock/blocktxn/getdata(tx), while the other implies support for getblock/getdata(block)/inv(block)
377 2017-08-08 20:57:21	0|sdaftuar|cmpctblock and blocktxn are already separately negotiated
378 2017-08-08 20:57:55	0|sipa|but not advertized
379 2017-08-08 20:58:02	0|sipa|(right?)
380 2017-08-08 20:58:05	0|sdaftuar|right
381 2017-08-08 20:58:15	0|sipa|they're implied by NODE_NETWORK + sufficient protocol version
382 2017-08-08 20:58:33	0|sdaftuar|well they're implied by NODE_SEGWIT, for all practical purposes
383 2017-08-08 20:58:39	0|sdaftuar|but interesting point
384 2017-08-08 20:59:05	0|sdaftuar|i'm not sure it's reasonable for service bits to keep up with p2p protocol improvements
385 2017-08-08 20:59:09	0|sipa|agree
386 2017-08-08 21:00:46	0|gmaxwell|I'm not enthused by all these flags because in general we should not be segmenting up the topology if we can avoid it.
387 2017-08-08 21:01:44	0|sdaftuar|i agree with that.  i also generally want to punt on features we are not sure anyone will implement.
388 2017-08-08 21:02:27	0|sipa|agree
389 2017-08-08 21:02:57	0|sipa|just pointing out that it may cost us an extra bit in the future - perhaps that's ok
390 2017-08-08 21:07:22	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/2507fd55568b...929fd7276c0f
391 2017-08-08 21:07:23	0|bitcoin-git|13bitcoin/06master 144ccc12a 15Suhas Daftuar: [qa] Rewrite BIP66 functional tests...
392 2017-08-08 21:07:23	0|bitcoin-git|13bitcoin/06master 14d4f0d87 15Suhas Daftuar: [qa] Rewrite BIP65 functional tests...
393 2017-08-08 21:07:24	0|bitcoin-git|13bitcoin/06master 14929fd72 15MarcoFalke: Merge #10695: [qa] Rewrite BIP65/BIP66 functional tests...
394 2017-08-08 21:07:47	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #10695: [qa] Rewrite BIP65/BIP66 functional tests (06master...062017-06-fix-bip65-test) 02https://github.com/bitcoin/bitcoin/pull/10695
395 2017-08-08 21:27:38	0|jonasschnelli|Should peers avoid serving blocks above the NODE_NETWORK_LIMITED_LOW|HIGH threshold to reduce finger printing opportunities?
396 2017-08-08 21:28:50	0|jonasschnelli|Assume you have pruned down to 10k blocks and signalling NODE_NETWORK_LIMITED_HIGH, one could fingerprint by checking how deep down you can serve blocks
397 2017-08-08 21:30:22	0|sipa|yes, i think so
398 2017-08-08 21:30:38	0|jonasschnelli|Okay. Will update the BIP
399 2017-08-08 21:31:06	0|jonasschnelli|Or maybe just the implementation... need to check
400 2017-08-08 21:36:03	0|bitcoin-git|[13bitcoin] 15rawodb closed pull request #11010: Add information about the next state in getblockchaininfo rpc request (06master...06pr/getblockchaininfo) 02https://github.com/bitcoin/bitcoin/pull/11010
401 2017-08-08 22:27:03	0|molz|Dear Core Devs, Thank you for all your hard work!  https://i.imgflip.com/1trxh9.jpg
402 2017-08-08 22:29:56	0|sipa|molz: yw!
403 2017-08-08 22:32:17	0|mryandao|could anyone from here answer this: https://bitcoin.stackexchange.com/questions/57416/since-bitcoin-core-0-14-0-how-does-a-node-with-default-settings-compute-the-dus
404 2017-08-08 22:35:53	0|Murch|sipa: Transaction overhead is 10 bytes for P2PKH transactions, since segwit adds flag and marker, which however go into the witness part am I correct to calculate the weight of the tx overhead as 42?
405 2017-08-08 22:36:24	0|Murch|For a transaction that spends at least one P2SHP2PWSH input
406 2017-08-08 22:37:03	0|sipa|Murch: looks right to me
407 2017-08-08 22:37:10	0|sipa|mryandao: yes, will do if i find the time
408 2017-08-08 22:37:14	0|Murch|thank you :)
409 2017-08-08 22:53:03	0|sipa|mryandao: achow101 beat me to it :)
410 2017-08-08 22:53:12	0|achow101|:)
411 2017-08-08 22:54:39	0|bitcoin-git|[13bitcoin] 15gmaxwell opened pull request #11011: [Trivial] Add a comment on the use of prevector in script. (06master...06201708-prevector-comment) 02https://github.com/bitcoin/bitcoin/pull/11011