1 2017-08-07 01:30:06	0|bitcoin-git|[13bitcoin] 15TheBlueMatt opened pull request #10998: 2017 08 fix upgrade cancel warnings (06master...062017-08-fix-upgrade-cancel-warnings) 02https://github.com/bitcoin/bitcoin/pull/10998
  2 2017-08-07 06:50:25	0|bitcoin-git|13bitcoin/06master 141de73f4 15Matt Corallo: Disconnect network service bits 6 and 8 until Aug 1, 2018...
  3 2017-08-07 06:50:25	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/a9dd11144152...c8b62c7de3d4
  4 2017-08-07 06:50:26	0|bitcoin-git|13bitcoin/06master 14c8b62c7 15Wladimir J. van der Laan: Merge #10982: Disconnect network service bits 6 and 8 until Aug 1, 2018...
  5 2017-08-07 06:51:10	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10982: Disconnect network service bits 6 and 8 until Aug 1, 2018 (06master...062017-08-bad-service-bits) 02https://github.com/bitcoin/bitcoin/pull/10982
  6 2017-08-07 07:04:57	0|bitcoin-git|[13bitcoin] 15laanwj pushed 5 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c8b62c7de3d4...c1c671feb163
  7 2017-08-07 07:04:58	0|bitcoin-git|13bitcoin/06master 14efac91e 15Matt Corallo: Always wait for threadGroup to exit in bitcoind shutdown...
  8 2017-08-07 07:04:58	0|bitcoin-git|13bitcoin/06master 14fce3f4f 15Matt Corallo: Fix resume-of-reindex-after-restart...
  9 2017-08-07 07:04:59	0|bitcoin-git|13bitcoin/06master 1413ab353 15Matt Corallo: Check for empty coinsview instead of just-reset coinsview in init...
 10 2017-08-07 07:05:32	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10919: Fix more init bugs. (06master...062017-07-init-bugs) 02https://github.com/bitcoin/bitcoin/pull/10919
 11 2017-08-07 07:06:32	0|bitcoin-git|13bitcoin/06master 1401699fb 15Matt Corallo: Fix resendwallettransactions assert failure if -walletbroadcast=0
 12 2017-08-07 07:06:32	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/c1c671feb163...fa646369489d
 13 2017-08-07 07:06:33	0|bitcoin-git|13bitcoin/06master 14fa64636 15Wladimir J. van der Laan: Merge #10995: Fix resendwallettransactions assert failure if -walletbroadcast=0...
 14 2017-08-07 07:07:10	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10995: Fix resendwallettransactions assert failure if -walletbroadcast=0 (06master...062018-08-walletbroadcast-assert) 02https://github.com/bitcoin/bitcoin/pull/10995
 15 2017-08-07 09:38:11	0|jonasschnelli|Anyone willing to review NODE_NETWORK_LIMITED BIP before opening a PR? https://github.com/jonasschnelli/bips/wiki/NODE_NETWORK_LIMITED-BIP-DRAFT
 16 2017-08-07 09:38:14	0|jonasschnelli|gmaxwell: some of your comments about required block limits are now working into the BIP.
 17 2017-08-07 09:38:17	0|jonasschnelli|I'm not sure about the undefined state of signalling both bits (the BIP states this mode as undefined but required to at least serve the last 90days/12'960)
 18 2017-08-07 09:38:19	0|jonasschnelli|To leave enough room for future requirements
 19 2017-08-07 09:39:40	0|sipa|jonasschnelli: thanks for working on this
 20 2017-08-07 09:40:20	0|sipa|jonasschnelli: i'm not sure that both bits available should have a meaning at all
 21 2017-08-07 09:40:38	0|sipa|as network nodes aggregate the bits they see by OR'ing them
 22 2017-08-07 09:41:30	0|sipa|a node that at some point advertizes _LOW and later advertizes _HIGH, may result in nodes aggregating it to the combination of both
 23 2017-08-07 09:42:44	0|sipa|so maybe LOW should mean "i can relay blocks and transactions at the tip, and also can be asked for blocks up to X deep", while HIGH only means "I can be asked for blocks between A and B deep"
 24 2017-08-07 09:42:59	0|sipa|typically you'd set both
 25 2017-08-07 09:43:10	0|sipa|or just LOW
 26 2017-08-07 09:46:15	0|sipa|(just an idea, see what others think)
 27 2017-08-07 09:49:37	0|gmaxwell|sipa: meh, I don't think the "I can do deep but not the tip" really makes sense, what you raise would be resolved by just defining each to be or newer and letting you combine them.
 28 2017-08-07 09:52:17	0|jonasschnelli|From a practical standpoint LOW is for the ones who prune to the minimum (current prune=550), HIGH probably for the ones who prune not to the minimum and/or use manual pruning. Also the depth value we set in HIGH will probably give those a guideline who not want to prune to the minimum
 29 2017-08-07 09:52:52	0|jonasschnelli|I agree that setting both bits could remain completely undefined
 30 2017-08-07 09:53:09	0|jonasschnelli|It just felt wasteful not to define the state when signalling both bits
 31 2017-08-07 09:54:01	0|jonasschnelli|Maybe there are some peers who run manual pruning mode but haven't pruned so far and this state could be covered by both bits?
 32 2017-08-07 10:02:44	0|sipa|gmaxwell: ?
 33 2017-08-07 10:20:54	0|wumpus|holy shit 2017-08-07 10:20:38 Error: Error loading wallet.dat: Wallet corrupted
 34 2017-08-07 10:21:21	0|jonasschnelli|wumpus: oh! Master?
 35 2017-08-07 10:22:02	0|wumpus|apparently I still have #10952 merged
 36 2017-08-07 10:22:03	0|gribble|https://github.com/bitcoin/bitcoin/issues/10952 | [wallet] Remove vchDefaultKey and have better first run detection by achow101 · Pull Request #10952 · bitcoin/bitcoin · GitHub
 37 2017-08-07 10:22:09	0|wumpus|let me try with master
 38 2017-08-07 10:22:21	0|gmaxwell|wumpus: I was about to suggest 10952 to fix it.
 39 2017-08-07 10:22:32	0|gmaxwell|(or usehd=0)
 40 2017-08-07 10:22:44	0|jonasschnelli|The default key is sneaky!
 41 2017-08-07 10:23:36	0|wumpus|master is ok
 42 2017-08-07 10:24:52	0|wumpus|this is an old, pre-hd wallet that survived a long time - will try to figure out why #10952 rejects it later
 43 2017-08-07 10:24:54	0|gribble|https://github.com/bitcoin/bitcoin/issues/10952 | [wallet] Remove vchDefaultKey and have better first run detection by achow101 · Pull Request #10952 · bitcoin/bitcoin · GitHub
 44 2017-08-07 10:25:08	0|jonasschnelli|What are the incentives / reasons why someone pruned to a larger target then the 550 minimum?
 45 2017-08-07 10:26:00	0|jonasschnelli|(with the current p2p signaling)
 46 2017-08-07 10:26:17	0|wumpus|the only reason I can think of is to support swapping wallets that can run a bit more out of sync
 47 2017-08-07 10:26:34	0|jonasschnelli|Good point
 48 2017-08-07 10:26:43	0|gmaxwell|jonasschnelli: having prune specified in megabytes is pretty daft.
 49 2017-08-07 10:26:49	0|jonasschnelli|He
 50 2017-08-07 10:26:51	0|gmaxwell|I think in the future we'll have a small set of options.
 51 2017-08-07 10:26:55	0|jonasschnelli|Yes
 52 2017-08-07 10:27:35	0|gmaxwell|and people will set larger ones to support the network more and due to rescans as mentioned.
 53 2017-08-07 10:28:18	0|jonasschnelli|Yes. I think the thresholds we set in the BIP may have influence what options
 54 2017-08-07 10:28:31	0|sipa|it helps to realize that effectively every reachable nodes that serves you blocks is altruistic
 55 2017-08-07 10:28:32	0|jonasschnelli|We will have / users will choose
 56 2017-08-07 10:30:22	0|gmaxwell|I think the advice in the BIP about connections is not really great advice. It's vague, and I think if followed it will cause a lot of pressure on pruned nodes (Esp because they will likely be much more rare among listening nodes for some time).  The network is self balancing.  If there is more demand on a node, it'll end up disconnecting some peers, and those peers will move elsewhere.
 57 2017-08-07 10:30:52	0|gmaxwell|I think nodes should likely choose uniformly among all peers offering what they need.
 58 2017-08-07 10:31:32	0|jonasschnelli|I see this point. gmaxwell: would removing the connection part in the BIP makes sense?
 59 2017-08-07 10:31:44	0|sipa|gmaxwell: i don't understand what you suggested earlier to deal with the OR'ing?
 60 2017-08-07 10:31:48	0|jonasschnelli|(Leaving it up to the impl.)
 61 2017-08-07 10:31:54	0|gmaxwell|if in the future pruned nodes become much more common as listening nodes than unpruned nodes, then it may make sense to try to avoid unpruned if you don't need them; but I don't expect that during the working life of this BIP (Basically by that point we'll have to have made other related service flag changes).
 62 2017-08-07 10:32:45	0|gmaxwell|sipa: It is a set mean the same as the 1week option.
 63 2017-08-07 10:33:00	0|gmaxwell|it's OR safe.
 64 2017-08-07 10:33:23	0|sipa|parse error
 65 2017-08-07 10:33:36	0|gmaxwell|@#$@# keyboard
 66 2017-08-07 10:33:48	0|gmaxwell|(loses long strings of text)
 67 2017-08-07 10:33:54	0|sipa|you need a new laptop
 68 2017-08-07 10:34:02	0|gmaxwell|sipa: If both are set, it means the same as the 1week option.
 69 2017-08-07 10:34:46	0|gmaxwell|Your suggestion allows a psycho signal "old but not new", which would just end up making that peer get ignored by peer selection (at best).
 70 2017-08-07 10:35:02	0|sipa|that's an option too
 71 2017-08-07 10:35:43	0|sipa|i'm just trying to not lose information by making the bits indicate orthogonal services
 72 2017-08-07 10:35:56	0|gmaxwell|I don't think we should worry too much about using bits here. We will need a new addr message in the not so far future.
 73 2017-08-07 10:36:11	0|gmaxwell|(because of HSNG and I2P)
 74 2017-08-07 10:37:19	0|gmaxwell|and we avoid using them for other things.
 75 2017-08-07 10:37:21	0|sipa|in that light, i wonder if we'll regret the choice of combining possibly 3 independent things into one bits (tx relay, block at tip relay, blocks up to a day old fetch)
 76 2017-08-07 10:38:30	0|gmaxwell|I dunno, I think block at tip relay basically needs to impliy 288 in any case, you'll need it for reorg, and the peer will not find your block announcements useful if you can't help the peer reorg.
 77 2017-08-07 10:38:46	0|gmaxwell|seems dangerous to me to introduce nodes in the topology that can't help you reorg.
 78 2017-08-07 10:39:06	0|sipa|yes, i agree
 79 2017-08-07 10:39:39	0|sipa|i'm just wondering whether maybe at some point we'll regret it due to evolutions we don't foresee now
 80 2017-08-07 10:39:49	0|gmaxwell|for sure, but then we'll change it then.
 81 2017-08-07 10:40:55	0|sipa|making the bits independent does not need to imply there is  recommendation or even permission to use them in odd ways "i relay blocks at the tip, and older than 3 months, except those between 1 and 2 years old!"
 82 2017-08-07 10:41:50	0|gmaxwell|if you can signal it, everyone will need code to handle it.
 83 2017-08-07 10:42:05	0|gmaxwell|which will me realizing that the sensless combination exists in the first place.
 84 2017-08-07 10:42:20	0|sipa|which will me?
 85 2017-08-07 10:42:49	0|gmaxwell|in general I prefer to avoid even being able to encode something that makes no more sense because it guarentees more corner cases you must handle.
 86 2017-08-07 12:06:33	0|wumpus|seems I found the bug in #10952: https://github.com/bitcoin/bitcoin/pull/10952/files#r131637416
 87 2017-08-07 12:06:35	0|gribble|https://github.com/bitcoin/bitcoin/issues/10952 | [wallet] Remove vchDefaultKey and have better first run detection by achow101 · Pull Request #10952 · bitcoin/bitcoin · GitHub
 88 2017-08-07 12:10:48	0|gmaxwell|"value": 1.00,
 89 2017-08-07 12:11:03	0|gmaxwell|^ decoderawtransaction is not zero extending the value field. :-/
 90 2017-08-07 12:14:00	0|wumpus|it's not using the correct formatting function
 91 2017-08-07 12:14:26	0|wumpus|https://github.com/bitcoin/bitcoin/blob/master/src/core_write.cpp#L187
 92 2017-08-07 12:15:31	0|wumpus|uses FormatMoney directly instead of ValueFromAmount
 93 2017-08-07 12:16:04	0|wumpus|I'll make a PR
 94 2017-08-07 12:34:10	0|gmaxwell|argh!
 95 2017-08-07 12:47:55	0|wumpus|sigh, I fixed it locally, now the tests are broken - lol
 96 2017-08-07 12:56:56	0|bitcoin-git|[13bitcoin] 15laanwj opened pull request #10999: Fix amounts formatting in `decoderawtransaction` (06master...062017_08_decoderawtx_amount) 02https://github.com/bitcoin/bitcoin/pull/10999
 97 2017-08-07 12:59:10	0|wumpus|gmaxwell: ^^
 98 2017-08-07 12:59:35	0|gmaxwell|tests exist to make sure we don't fix bugs, apparently. :P
 99 2017-08-07 13:00:14	0|wumpus|well in this case it's good that the test is so literal - we should catch misformats here - however it checks against the wrong answer :P
100 2017-08-07 13:05:42	0|gmaxwell|has this always been broken
101 2017-08-07 13:05:45	0|gmaxwell|?
102 2017-08-07 13:52:41	0|wumpus|at the least for very long (since the univalue switch?)
103 2017-08-07 13:53:16	0|wumpus|and at that time it's very possible that we weren't padding all amounts to 8 digits yet
104 2017-08-07 13:54:05	0|gmaxwell|I wonder if I managed to lose money due to this at some point. It's not entirely unlikely.
105 2017-08-07 14:15:23	0|wumpus|we started always returning 8 decimals in this commit in july 2015, https://github.com/bitcoin/bitcoin/commit/e061e2778d592826970483e0844308c4e9a12626
106 2017-08-07 14:17:26	0|wumpus|it was assumed that app RPC-facing stuff was using ValueFromAmount, but apparently TxToUniv in core_io didn't, probably because of some dependency tangle
107 2017-08-07 14:18:01	0|wumpus|I've checked the other remaining uses of FormatMoney afaik they're all in debug logging
108 2017-08-07 14:36:08	0|Lightsword|anything still needed for #10301?
109 2017-08-07 14:36:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/10301 | Check if sys/random.h is required for getentropy. by jameshilliard · Pull Request #10301 · bitcoin/bitcoin · GitHub
110 2017-08-07 15:19:35	0|bitcoin-git|[13bitcoin] 15promag opened pull request #11000: test: Add resendwallettransactions functional tests (06master...06201708-resendwallettransactions-test) 02https://github.com/bitcoin/bitcoin/pull/11000
111 2017-08-07 15:24:19	0|promag|wumpus: ^^
112 2017-08-07 15:25:29	0|bitcoin-git|13bitcoin/06master 14ee2d10a 15James Hilliard: Check if sys/random.h is required for getentropy on OSX.
113 2017-08-07 15:25:29	0|bitcoin-git|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/fa646369489d...318392ca7cda
114 2017-08-07 15:25:30	0|bitcoin-git|13bitcoin/06master 14318392c 15Wladimir J. van der Laan: Merge #10301: Check if sys/random.h is required for getentropy....
115 2017-08-07 15:25:42	0|bitcoin-git|[13bitcoin] 15laanwj closed pull request #10301: Check if sys/random.h is required for getentropy. (06master...06getentropy-rand) 02https://github.com/bitcoin/bitcoin/pull/10301
116 2017-08-07 15:28:02	0|wumpus|promag: congrats on #11000 I guess?
117 2017-08-07 15:28:03	0|gribble|https://github.com/bitcoin/bitcoin/issues/11000 | test: Add resendwallettransactions functional tests by promag · Pull Request #11000 · bitcoin/bitcoin · GitHub
118 2017-08-07 15:28:41	0|promag|heh did nothing all week to catch it :P
119 2017-08-07 15:28:41	0|wumpus|promag: I think you need to add it to the test lists
120 2017-08-07 15:28:51	0|promag|right!
121 2017-08-07 15:30:24	0|promag|wumpus: extended script?
122 2017-08-07 15:30:44	0|promag|does it have to be run in travis?
123 2017-08-07 15:35:59	0|wumpus|if it takes up to a few seconds you should add it to the normal tests
124 2017-08-07 15:36:20	0|wumpus|extended tests is for tests that take significant time
125 2017-08-07 15:41:27	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #11001: [tests] Test disconnecting unsupported service bits logic. (06master...06unsupported_service_bits_test) 02https://github.com/bitcoin/bitcoin/pull/11001
126 2017-08-07 17:21:08	0|jonasschnelli|gmaxwell: re: https://github.com/jonasschnelli/bips/wiki/NODE_NETWORK_LIMITED-BIP-DRAFT#network-health-optional
127 2017-08-07 17:21:08	0|jonasschnelli|What if the BIP would recommend (optional) to connect - once in sync – to a lower percentage (10%) of the percentage of available NODE_NETWORK_LIMITED in addrman? Probably over-specifing?
128 2017-08-07 17:21:37	0|jonasschnelli|Nah.. nm. Let me remove that part...
129 2017-08-07 17:40:37	0|luke-jr|jonasschnelli: dislike that it still requires 90 days for both bits set. Would prefer if it didn't imply anything more than the 2 days
130 2017-08-07 17:41:00	0|jonasschnelli|Oh. Yes. Let me remove that part...
131 2017-08-07 17:42:19	0|jonasschnelli|luke-jr: its removed now
132 2017-08-07 17:43:18	0|luke-jr|jonasschnelli: rather than forbid the bits when NODE_NETWORK is set, I suggest leaving them entirely undefined in that circumstance
133 2017-08-07 17:44:26	0|jonasschnelli|luke-jr: I don't think one should signal LIMITED and NODE_NETWORK. It may confuse primitive implementations
134 2017-08-07 17:45:12	0|luke-jr|jonasschnelli: forbidding such primitive implementations is why to undefine it now :p
135 2017-08-07 17:45:18	0|luke-jr|jonasschnelli: please use BIP number 159
136 2017-08-07 17:48:54	0|sdaftuar|jonasschnelli: i think it's clearest if setting a bit has meaning independent from looking at other bits.
137 2017-08-07 17:49:10	0|sdaftuar|eg if you want to know if a node has all historical blocks, just check NODE_NETWORK
138 2017-08-07 17:49:31	0|sdaftuar|if you want to know if it serves recent blocks, just check NODE_LIMITED_*
139 2017-08-07 17:49:36	0|sdaftuar|and not owrry about setting both
140 2017-08-07 17:49:42	0|jonasschnelli|I see. Makes sense... I'll fix that
141 2017-08-07 17:54:59	0|jonasschnelli|Fixed
142 2017-08-07 18:13:45	0|xHire|jonasschnelli: please, what does committing a transaction in the context of fee bumping mean? (doing translation; `git blame qt/walletmodel.cpp` pointed to you :c))
143 2017-08-07 18:15:00	0|jonasschnelli|committing means probably add the wallet and broadcast? Need to check that source code comment later. Thx
144 2017-08-07 18:15:12	0|jonasschnelli|Add to the
145 2017-08-07 18:15:49	0|xHire|right, that makes sense. thanks!
146 2017-08-07 18:51:46	0|sdaftuar|gmaxwell: luke-jr: is it important that we cache the last call to CNB in getblocktemplate() and return it to callers who are calling getblocktemplate more frequently than every 5 seconds?
147 2017-08-07 18:52:17	0|sdaftuar|i've finally gotten around to revisiting #10200, and i think it would make sense to drop that cache, and make the proposed new CNB parameters for recent transaction inclusion arguments to getblocktemplate
148 2017-08-07 18:52:19	0|gribble|https://github.com/bitcoin/bitcoin/issues/10200 | Mining: Skip recent transactions if fee difference is small by sdaftuar · Pull Request #10200 · bitcoin/bitcoin · GitHub
149 2017-08-07 18:52:36	0|sdaftuar|(rather than bitcoind arguments, which is where that PR started)
150 2017-08-07 18:53:33	0|luke-jr|sdaftuar: the cache is AFAIK mainly used for multiple clients calling GBT at almost the same time
151 2017-08-07 18:54:25	0|luke-jr|I'm not sure it makes sense to expose the parameters over RPC like that anyway.
152 2017-08-07 18:54:35	0|luke-jr|(why would a miner want to run with different configurations?)
153 2017-08-07 18:54:48	0|sdaftuar|the CNB parameters?  it seemd like it would be annoying to restart bitcoind if you wanted to change the parameter
154 2017-08-07 18:54:51	0|sdaftuar|eg in response to network conditions
155 2017-08-07 18:55:33	0|sdaftuar|i hadn't considered multiple rpc clients calling gbt on the same server...  i figured that for a single client, cnb should be fast enough that we could just invoke it each time
156 2017-08-07 18:55:46	0|sdaftuar|but no idea how much load it could take from multiple clients
157 2017-08-07 18:58:34	0|sdaftuar|eh, i will punt on it for now and just leave it as a bitcoind argument i guess
158 2017-08-07 19:14:29	0|luke-jr|sdaftuar: there are more than just mining parameters that are nice to adjust at runtime. Yet another use for a setconfig RPC..
159 2017-08-07 19:15:51	0|sdaftuar|sure, i agree with that in general
160 2017-08-07 19:38:38	0|SopaXorzTaker|When will the alert key be published?
161 2017-08-07 19:38:50	0|SopaXorzTaker|(don't forget to withdraw the coins that are sitting there, devs!)
162 2017-08-07 19:53:18	0|bitcoin-git|[13bitcoin] 15jnewbery opened pull request #11002: [wallet] return correct error code from resendwallettransaction (06master...06resendwallettransaction_error_code) 02https://github.com/bitcoin/bitcoin/pull/11002
163 2017-08-07 20:29:20	0|jnewbery|jonasschnelli: I agree with sdaftuar and sipa that bits should be considered independently.
164 2017-08-07 20:30:42	0|jnewbery|it makes logic straightforward: if (NODE_NETWORK) {can serve me all blocks} else if (NODE_LIMITED_HIGH) {can serve me blocks up to 8 days} else if (NODE_LIMITED_LOW) {can serve be blocks up to 2 days} else {can't serve me blocks}
165 2017-08-07 20:31:06	0|jnewbery|I'd remove the line "The required behaviour when signaling both bits (NODE_NETWORK_LIMITED_LOW & NODE_NETWORK_LIMITED_HIGH) is currently undefined."
166 2017-08-07 20:33:41	0|jnewbery|I also think we should consider sipa's point about orthogonal services having their own bits (tx relay, block relay, addr relay, blocks up to 8 days). It's not like we're short of bits. And the edge-handling code isn't that difficult. For now, just reject if one but not all of them are set.
167 2017-08-07 20:37:56	0|gmaxwell|if we reject, then we can't use them seperately in the future because older peers will ignore us.
168 2017-08-07 20:39:38	0|sipa|jnewbery: i changed the links on the wiki to be section references rather than URLs, and added more
169 2017-08-07 20:48:51	0|eck|i want to extend the backupwallet command so that there's a new optional argument, the file mode of the backup file. For a change like this, is it better to ask for interest on the mailing list? or should I just write the code and send a PR?
170 2017-08-07 20:50:21	0|eck|arguably this would be better done by allowing there to be different rpcusers with different sets of permissions, but that change seems too expansive
171 2017-08-07 21:02:12	0|jnewbery|sipa: looks good. I think everything in #9889 is now covered
172 2017-08-07 21:02:13	0|gribble|https://github.com/bitcoin/bitcoin/issues/9889 | TODO for release notes 0.15.0 · Issue #9889 · bitcoin/bitcoin · GitHub
173 2017-08-07 21:03:56	0|luke-jr|jnewbery: that wastes bits
174 2017-08-07 21:05:17	0|jnewbery|gmaxwell you're right. Reject is incorrect. Should have said 'ignore bits if one but not all of them are set'
175 2017-08-07 21:05:32	0|luke-jr|unless perhaps it's if (NODE_NETWORK) else if (NODE_LIMITED_LOW) else if (NODE_LIMITED_HIGH) …
176 2017-08-07 21:06:34	0|luke-jr|then the LIMITED bits are properly ignored if NETWORK is set, and if both LIMITED are set, behaviour is only guaranteed as LIMITED_LOW (ie, what the BIP currently says)
177 2017-08-07 21:07:06	0|luke-jr|(leaving the LIMITED_LOW | LIMITED_HIGH combination for a LOW + deterministic assortment of history)
178 2017-08-07 21:12:26	0|sdaftuar|i think we should interpret bits as only being affirmative for a given property, and not denying other services.  imo that is the clearest way to describe your state, even if not information maximizing.
179 2017-08-07 21:15:18	0|jnewbery|I agree. I don't think the meaning of a single bit should be dependent on other bits
180 2017-08-07 21:16:27	0|sipa|agree
181 2017-08-07 21:27:30	0|promag|jnewbery: updated #11000, ty
182 2017-08-07 21:27:31	0|gribble|https://github.com/bitcoin/bitcoin/issues/11000 | test: Add resendwallettransactions functional tests by promag · Pull Request #11000 · bitcoin/bitcoin · GitHub
183 2017-08-07 21:28:18	0|bitcoin-git|[13bitcoin] 15eklitzke opened pull request #11003: Docs: Capitalize bullet points in CONTRIBUTING guide (06master...06contributing_grammar) 02https://github.com/bitcoin/bitcoin/pull/11003
184 2017-08-07 21:32:40	0|jnewbery|thanks promag
185 2017-08-07 21:42:43	0|luke-jr|jnewbery: so we just burn 1 bit for every resolution of chain archival? :/
186 2017-08-07 21:43:11	0|jnewbery|if there are only two resolutions, that's not a problem
187 2017-08-07 21:43:26	0|luke-jr|there aren't.
188 2017-08-07 21:43:44	0|luke-jr|even with just this BIP, there are three. and no reason to expect it to end with that.
189 2017-08-07 21:43:51	0|jnewbery|by the time we run out of bits, we'll already have the new addr message
190 2017-08-07 21:43:59	0|luke-jr|why do we want a new addr message?
191 2017-08-07 21:44:54	0|jnewbery|06:35 < gmaxwell> I don't think we should worry too much about using bits here. We will need a new addr message in the not so far future.
192 2017-08-07 21:44:57	0|jnewbery|06:36 < gmaxwell> (because of HSNG and I2P)
193 2017-08-07 21:46:20	0|luke-jr|making the IP size longer isn't really a reason to use service bits unwisely
194 2017-08-07 22:02:48	0|bitcoin-git|13bitcoin/06master 145e35cd9 15John Newbery: [tests] Test disconnecting unsupported service bits logic....
195 2017-08-07 22:02:48	0|bitcoin-git|13bitcoin/06master 14fa8a063 15MarcoFalke: Merge #11001: [tests] Test disconnecting unsupported service bits logic....
196 2017-08-07 22:02:48	0|bitcoin-git|[13bitcoin] 15MarcoFalke pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/318392ca7cda...fa8a0639f7b0
197 2017-08-07 22:03:31	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11001: [tests] Test disconnecting unsupported service bits logic. (06master...06unsupported_service_bits_test) 02https://github.com/bitcoin/bitcoin/pull/11001
198 2017-08-07 22:25:32	0|Hello|everyone, Can somebody inform me on how to check if the coin chain has split ? is there a RPC command ?
199 2017-08-07 22:26:07	0|sipa|getchaintips
200 2017-08-07 22:30:56	0|Hello|hey sipa thank you for the tip but it says method not found
201 2017-08-07 22:31:33	0|LordCow|bitcoin-cli getchaintips
202 2017-08-07 22:31:58	0|Hello|I forgot to mention I want to check this on a alt coin wallet
203 2017-08-07 22:39:22	0|Hello|Client version is 1.0.0.0-g9ccfb23-beta
204 2017-08-07 22:43:57	0|gmaxwell|oh jesus I broke the release notes wiki, pieter is fixing it.
205 2017-08-07 22:44:32	0|gmaxwell|Pro tip: if you hit edit, then change the title for a page on the wiki, it nukes the history.
206 2017-08-07 22:45:22	0|gmaxwell|(people are circulating links to the release notes wiki as if it were the 0.15 release notes, so I tried to change the title to say it's a draft)
207 2017-08-07 22:48:11	0|sipa|Hello: then go yell at its developers
208 2017-08-07 22:48:49	0|sipa|gmaxwell: fixed
209 2017-08-07 22:50:36	0|Hello|Sipa: I can't yell at myself lmao
210 2017-08-07 22:52:24	0|sipa|Hello: in any case, off topic here
211 2017-08-07 22:52:54	0|Hello|sipa: thanks for replying have a nice day
212 2017-08-07 23:53:23	0|gmaxwell|luke-jr: you should move the block of new questions at the top of https://luke.dashjr.org/programs/kycpoll/answers.php to the bottom, now it just looks stupid with one response.