12017-08-07T00:35:54  *** J-wolf has quit IRC
  22017-08-07T01:05:26  *** J-wolf has joined #bitcoin-core-dev
  32017-08-07T01:24:05  *** miknotauro has quit IRC
  42017-08-07T01:25:43  *** Deacyded has joined #bitcoin-core-dev
  52017-08-07T01:29:28  *** Deacydal has quit IRC
  62017-08-07T01:30:05  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10998: 2017 08 fix upgrade cancel warnings (master...2017-08-fix-upgrade-cancel-warnings) https://github.com/bitcoin/bitcoin/pull/10998
  72017-08-07T01:40:08  *** Chris_Stewart_5 has quit IRC
  82017-08-07T01:43:20  *** ekerstein has joined #bitcoin-core-dev
  92017-08-07T01:52:23  *** Ylbam has quit IRC
 102017-08-07T02:02:07  *** J-wolf has quit IRC
 112017-08-07T02:34:45  *** r251d has joined #bitcoin-core-dev
 122017-08-07T02:39:36  *** shaolinfry has joined #bitcoin-core-dev
 132017-08-07T02:50:23  *** J-wolf has joined #bitcoin-core-dev
 142017-08-07T03:00:53  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 152017-08-07T03:02:33  *** luke-jr has quit IRC
 162017-08-07T03:03:13  *** luke-jr has joined #bitcoin-core-dev
 172017-08-07T03:03:24  *** J-wolf has quit IRC
 182017-08-07T03:09:22  *** ekerstein has quit IRC
 192017-08-07T03:50:09  *** Chris_Stewart_5 has quit IRC
 202017-08-07T04:13:19  *** r251d has quit IRC
 212017-08-07T04:32:38  *** marcoagner has quit IRC
 222017-08-07T04:43:33  *** marcoagner has joined #bitcoin-core-dev
 232017-08-07T04:49:31  *** Electro has joined #bitcoin-core-dev
 242017-08-07T05:12:50  *** dabura667 has joined #bitcoin-core-dev
 252017-08-07T05:14:15  *** dabura667 has quit IRC
 262017-08-07T05:14:28  *** Giszmo has joined #bitcoin-core-dev
 272017-08-07T05:28:38  *** dabura667 has joined #bitcoin-core-dev
 282017-08-07T05:29:29  *** dabura667 has quit IRC
 292017-08-07T05:34:49  *** veleiro has quit IRC
 302017-08-07T05:55:42  *** miknotauro has joined #bitcoin-core-dev
 312017-08-07T06:06:26  *** J-wolf has joined #bitcoin-core-dev
 322017-08-07T06:21:15  *** J-wolf has quit IRC
 332017-08-07T06:28:03  *** KevinPan has joined #bitcoin-core-dev
 342017-08-07T06:35:24  *** Electro has quit IRC
 352017-08-07T06:50:11  *** jonasschnelli_ has quit IRC
 362017-08-07T06:50:25  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a9dd11144152...c8b62c7de3d4
 372017-08-07T06:50:25  <bitcoin-git> bitcoin/master 1de73f4 Matt Corallo: Disconnect network service bits 6 and 8 until Aug 1, 2018...
 382017-08-07T06:50:26  <bitcoin-git> bitcoin/master c8b62c7 Wladimir J. van der Laan: Merge #10982: Disconnect network service bits 6 and 8 until Aug 1, 2018...
 392017-08-07T06:50:30  *** jonasschnelli has joined #bitcoin-core-dev
 402017-08-07T06:50:33  *** jonasschnelli has joined #bitcoin-core-dev
 412017-08-07T06:51:10  <bitcoin-git> [bitcoin] laanwj closed pull request #10982: Disconnect network service bits 6 and 8 until Aug 1, 2018 (master...2017-08-bad-service-bits) https://github.com/bitcoin/bitcoin/pull/10982
 422017-08-07T06:52:17  *** BashCo has quit IRC
 432017-08-07T06:52:40  *** elkalamar has quit IRC
 442017-08-07T06:52:53  *** BashCo has joined #bitcoin-core-dev
 452017-08-07T06:57:37  *** BashCo has quit IRC
 462017-08-07T07:04:56  <bitcoin-git> [bitcoin] laanwj pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/c8b62c7de3d4...c1c671feb163
 472017-08-07T07:04:57  <bitcoin-git> bitcoin/master efac91e Matt Corallo: Always wait for threadGroup to exit in bitcoind shutdown...
 482017-08-07T07:04:57  <bitcoin-git> bitcoin/master fce3f4f Matt Corallo: Fix resume-of-reindex-after-restart...
 492017-08-07T07:04:58  <bitcoin-git> bitcoin/master 13ab353 Matt Corallo: Check for empty coinsview instead of just-reset coinsview in init...
 502017-08-07T07:05:31  <bitcoin-git> [bitcoin] laanwj closed pull request #10919: Fix more init bugs. (master...2017-07-init-bugs) https://github.com/bitcoin/bitcoin/pull/10919
 512017-08-07T07:06:31  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c1c671feb163...fa646369489d
 522017-08-07T07:06:31  <bitcoin-git> bitcoin/master 01699fb Matt Corallo: Fix resendwallettransactions assert failure if -walletbroadcast=0
 532017-08-07T07:06:32  <bitcoin-git> bitcoin/master fa64636 Wladimir J. van der Laan: Merge #10995: Fix resendwallettransactions assert failure if -walletbroadcast=0...
 542017-08-07T07:07:09  <bitcoin-git> [bitcoin] laanwj closed pull request #10995: Fix resendwallettransactions assert failure if -walletbroadcast=0 (master...2018-08-walletbroadcast-assert) https://github.com/bitcoin/bitcoin/pull/10995
 552017-08-07T07:13:44  *** J-wolf has joined #bitcoin-core-dev
 562017-08-07T07:13:47  *** BashCo has joined #bitcoin-core-dev
 572017-08-07T07:21:19  *** J-wolf has quit IRC
 582017-08-07T07:21:48  *** Ylbam has joined #bitcoin-core-dev
 592017-08-07T07:31:10  *** bryyan has quit IRC
 602017-08-07T07:31:22  *** dobak has joined #bitcoin-core-dev
 612017-08-07T08:05:48  *** cdecker has quit IRC
 622017-08-07T08:06:12  *** cdecker has joined #bitcoin-core-dev
 632017-08-07T08:08:56  *** timothy has joined #bitcoin-core-dev
 642017-08-07T08:20:49  *** JackH has joined #bitcoin-core-dev
 652017-08-07T08:29:09  *** dobak has quit IRC
 662017-08-07T08:48:11  *** JackH has quit IRC
 672017-08-07T09:04:49  *** sam_c has quit IRC
 682017-08-07T09:09:22  *** sam_c has joined #bitcoin-core-dev
 692017-08-07T09:21:36  *** AaronvanW has joined #bitcoin-core-dev
 702017-08-07T09:23:52  *** Alina-malina has quit IRC
 712017-08-07T09:23:59  *** Aaronvan_ has joined #bitcoin-core-dev
 722017-08-07T09:26:04  *** Alina-malina has joined #bitcoin-core-dev
 732017-08-07T09:26:38  *** AaronvanW has quit IRC
 742017-08-07T09:36:02  *** sam_c has quit IRC
 752017-08-07T09:38:04  *** sam_c has joined #bitcoin-core-dev
 762017-08-07T09:38:10  <jonasschnelli> Anyone willing to review NODE_NETWORK_LIMITED BIP before opening a PR? https://github.com/jonasschnelli/bips/wiki/NODE_NETWORK_LIMITED-BIP-DRAFT
 772017-08-07T09:38:14  <jonasschnelli> gmaxwell: some of your comments about required block limits are now working into the BIP.
 782017-08-07T09:38:16  <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)
 792017-08-07T09:38:19  <jonasschnelli> To leave enough room for future requirements
 802017-08-07T09:39:40  <sipa> jonasschnelli: thanks for working on this
 812017-08-07T09:40:19  <sipa> jonasschnelli: i'm not sure that both bits available should have a meaning at all
 822017-08-07T09:40:37  <sipa> as network nodes aggregate the bits they see by OR'ing them
 832017-08-07T09:41:29  <sipa> a node that at some point advertizes _LOW and later advertizes _HIGH, may result in nodes aggregating it to the combination of both
 842017-08-07T09:42:43  <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"
 852017-08-07T09:42:58  <sipa> typically you'd set both
 862017-08-07T09:43:10  <sipa> or just LOW
 872017-08-07T09:46:14  <sipa> (just an idea, see what others think)
 882017-08-07T09:49:37  <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.
 892017-08-07T09:52:16  <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
 902017-08-07T09:52:52  <jonasschnelli> I agree that setting both bits could remain completely undefined
 912017-08-07T09:53:09  <jonasschnelli> It just felt wasteful not to define the state when signalling both bits
 922017-08-07T09:54:01  <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?
 932017-08-07T10:02:44  <sipa> gmaxwell: ?
 942017-08-07T10:09:43  *** Ylbam has quit IRC
 952017-08-07T10:13:44  *** Deacydal has joined #bitcoin-core-dev
 962017-08-07T10:16:50  *** Deacyded has quit IRC
 972017-08-07T10:20:53  <wumpus> holy shit 2017-08-07 10:20:38 Error: Error loading wallet.dat: Wallet corrupted
 982017-08-07T10:21:02  *** Alina-malina has quit IRC
 992017-08-07T10:21:02  *** Alina-malina has joined #bitcoin-core-dev
1002017-08-07T10:21:20  <jonasschnelli> wumpus: oh! Master?
1012017-08-07T10:22:01  <wumpus> apparently I still have #10952 merged
1022017-08-07T10:22:03  <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
1032017-08-07T10:22:09  <wumpus> let me try with master
1042017-08-07T10:22:20  <gmaxwell> wumpus: I was about to suggest 10952 to fix it.
1052017-08-07T10:22:32  <gmaxwell> (or usehd=0)
1062017-08-07T10:22:43  <jonasschnelli> The default key is sneaky!
1072017-08-07T10:23:35  <wumpus> master is ok
1082017-08-07T10:24:52  <wumpus> this is an old, pre-hd wallet that survived a long time - will try to figure out why #10952 rejects it later
1092017-08-07T10:24:54  <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
1102017-08-07T10:25:08  <jonasschnelli> What are the incentives / reasons why someone pruned to a larger target then the 550 minimum?
1112017-08-07T10:26:00  <jonasschnelli> (with the current p2p signaling)
1122017-08-07T10:26:17  <wumpus> the only reason I can think of is to support swapping wallets that can run a bit more out of sync
1132017-08-07T10:26:34  <jonasschnelli> Good point
1142017-08-07T10:26:42  <gmaxwell> jonasschnelli: having prune specified in megabytes is pretty daft.
1152017-08-07T10:26:48  <jonasschnelli> He
1162017-08-07T10:26:50  <gmaxwell> I think in the future we'll have a small set of options.
1172017-08-07T10:26:54  <jonasschnelli> Yes
1182017-08-07T10:27:35  <gmaxwell> and people will set larger ones to support the network more and due to rescans as mentioned.
1192017-08-07T10:28:20  <jonasschnelli> Yes. I think the thresholds we set in the BIP may have influence what options
1202017-08-07T10:28:31  <sipa> it helps to realize that effectively every reachable nodes that serves you blocks is altruistic
1212017-08-07T10:28:31  <jonasschnelli> We will have / users will choose
1222017-08-07T10:30:20  *** Yogaqueef has joined #bitcoin-core-dev
1232017-08-07T10:30:22  <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.
1242017-08-07T10:30:52  <gmaxwell> I think nodes should likely choose uniformly among all peers offering what they need.
1252017-08-07T10:31:31  <jonasschnelli> I see this point. gmaxwell: would removing the connection part in the BIP makes sense?
1262017-08-07T10:31:44  <sipa> gmaxwell: i don't understand what you suggested earlier to deal with the OR'ing?
1272017-08-07T10:31:47  <jonasschnelli> (Leaving it up to the impl.)
1282017-08-07T10:31:54  <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).
1292017-08-07T10:32:44  <gmaxwell> sipa: It is a set mean the same as the 1week option.
1302017-08-07T10:32:59  <gmaxwell> it's OR safe.
1312017-08-07T10:33:23  <sipa> parse error
1322017-08-07T10:33:35  <gmaxwell> @#$@# keyboard
1332017-08-07T10:33:47  <gmaxwell> (loses long strings of text)
1342017-08-07T10:33:54  <sipa> you need a new laptop
1352017-08-07T10:34:01  <gmaxwell> sipa: If both are set, it means the same as the 1week option.
1362017-08-07T10:34:45  <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).
1372017-08-07T10:35:01  <sipa> that's an option too
1382017-08-07T10:35:42  <sipa> i'm just trying to not lose information by making the bits indicate orthogonal services
1392017-08-07T10:35:56  <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.
1402017-08-07T10:36:11  <gmaxwell> (because of HSNG and I2P)
1412017-08-07T10:37:18  <gmaxwell> and we avoid using them for other things.
1422017-08-07T10:37:21  <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)
1432017-08-07T10:38:30  <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.
1442017-08-07T10:38:45  <gmaxwell> seems dangerous to me to introduce nodes in the topology that can't help you reorg.
1452017-08-07T10:39:07  <sipa> yes, i agree
1462017-08-07T10:39:38  <sipa> i'm just wondering whether maybe at some point we'll regret it due to evolutions we don't foresee now
1472017-08-07T10:39:59  <gmaxwell> for sure, but then we'll change it then.
1482017-08-07T10:40:55  <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!"
1492017-08-07T10:41:49  <gmaxwell> if you can signal it, everyone will need code to handle it.
1502017-08-07T10:42:04  <gmaxwell> which will me realizing that the sensless combination exists in the first place.
1512017-08-07T10:42:19  <sipa> which will me?
1522017-08-07T10:42:49  <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.
1532017-08-07T10:43:03  * sipa zZzZ
1542017-08-07T11:03:08  *** jannes has joined #bitcoin-core-dev
1552017-08-07T11:35:15  *** SopaXorzTaker has joined #bitcoin-core-dev
1562017-08-07T11:39:26  *** miknotauro has quit IRC
1572017-08-07T11:43:01  *** Deacyde has joined #bitcoin-core-dev
1582017-08-07T11:43:30  *** Deacydal has quit IRC
1592017-08-07T11:45:37  *** gaf_ has quit IRC
1602017-08-07T11:46:24  *** gaf_ has joined #bitcoin-core-dev
1612017-08-07T12:06:32  <wumpus> seems I found the bug in #10952: https://github.com/bitcoin/bitcoin/pull/10952/files#r131637416
1622017-08-07T12:06:34  <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
1632017-08-07T12:10:47  <gmaxwell>       "value": 1.00,
1642017-08-07T12:11:02  <gmaxwell> ^ decoderawtransaction is not zero extending the value field. :-/
1652017-08-07T12:11:44  *** JackH has joined #bitcoin-core-dev
1662017-08-07T12:13:59  <wumpus> it's not using the correct formatting function
1672017-08-07T12:14:26  <wumpus> https://github.com/bitcoin/bitcoin/blob/master/src/core_write.cpp#L187
1682017-08-07T12:15:31  <wumpus> uses FormatMoney directly instead of ValueFromAmount
1692017-08-07T12:16:03  <wumpus> I'll make a PR
1702017-08-07T12:34:09  <gmaxwell> argh!
1712017-08-07T12:39:48  *** Matt- has quit IRC
1722017-08-07T12:47:55  <wumpus> sigh, I fixed it locally, now the tests are broken - lol
1732017-08-07T12:56:55  <bitcoin-git> [bitcoin] laanwj opened pull request #10999: Fix amounts formatting in `decoderawtransaction` (master...2017_08_decoderawtx_amount) https://github.com/bitcoin/bitcoin/pull/10999
1742017-08-07T12:59:09  <wumpus> gmaxwell: ^^
1752017-08-07T12:59:35  <gmaxwell> tests exist to make sure we don't fix bugs, apparently. :P
1762017-08-07T13:00:13  <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
1772017-08-07T13:05:42  <gmaxwell> has this always been broken
1782017-08-07T13:05:44  <gmaxwell> ?
1792017-08-07T13:16:24  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1802017-08-07T13:30:57  *** afk11 has quit IRC
1812017-08-07T13:35:59  *** afk11 has joined #bitcoin-core-dev
1822017-08-07T13:44:24  *** belcher has quit IRC
1832017-08-07T13:52:41  <wumpus> at the least for very long (since the univalue switch?)
1842017-08-07T13:53:16  <wumpus> and at that time it's very possible that we weren't padding all amounts to 8 digits yet
1852017-08-07T13:54:04  <gmaxwell> I wonder if I managed to lose money due to this at some point. It's not entirely unlikely.
1862017-08-07T13:57:01  *** laurentmt has joined #bitcoin-core-dev
1872017-08-07T14:00:09  *** belcher has joined #bitcoin-core-dev
1882017-08-07T14:05:36  *** Guyver2 has joined #bitcoin-core-dev
1892017-08-07T14:15:23  <wumpus> we started always returning 8 decimals in this commit in july 2015, https://github.com/bitcoin/bitcoin/commit/e061e2778d592826970483e0844308c4e9a12626
1902017-08-07T14:17:26  <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
1912017-08-07T14:18:00  <wumpus> I've checked the other remaining uses of FormatMoney afaik they're all in debug logging
1922017-08-07T14:36:07  <Lightsword> anything still needed for #10301?
1932017-08-07T14:36:12  <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
1942017-08-07T14:37:45  *** laurentmt has quit IRC
1952017-08-07T14:39:54  *** laurentmt has joined #bitcoin-core-dev
1962017-08-07T14:46:24  *** laurentmt has quit IRC
1972017-08-07T15:08:28  *** JackH has quit IRC
1982017-08-07T15:14:29  *** Dizzle has joined #bitcoin-core-dev
1992017-08-07T15:15:07  *** BashCo has quit IRC
2002017-08-07T15:15:46  *** BashCo has joined #bitcoin-core-dev
2012017-08-07T15:15:58  *** Murch has joined #bitcoin-core-dev
2022017-08-07T15:19:34  <bitcoin-git> [bitcoin] promag opened pull request #11000: test: Add resendwallettransactions functional tests (master...201708-resendwallettransactions-test) https://github.com/bitcoin/bitcoin/pull/11000
2032017-08-07T15:20:05  *** BashCo has quit IRC
2042017-08-07T15:23:46  *** promag has joined #bitcoin-core-dev
2052017-08-07T15:24:18  <promag> wumpus: ^^
2062017-08-07T15:25:28  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fa646369489d...318392ca7cda
2072017-08-07T15:25:29  <bitcoin-git> bitcoin/master ee2d10a James Hilliard: Check if sys/random.h is required for getentropy on OSX.
2082017-08-07T15:25:29  <bitcoin-git> bitcoin/master 318392c Wladimir J. van der Laan: Merge #10301: Check if sys/random.h is required for getentropy....
2092017-08-07T15:25:41  <bitcoin-git> [bitcoin] laanwj closed pull request #10301: Check if sys/random.h is required for getentropy. (master...getentropy-rand) https://github.com/bitcoin/bitcoin/pull/10301
2102017-08-07T15:28:01  <wumpus> promag: congrats on #11000 I guess?
2112017-08-07T15:28:03  <gribble> https://github.com/bitcoin/bitcoin/issues/11000 | test: Add resendwallettransactions functional tests by promag · Pull Request #11000 · bitcoin/bitcoin · GitHub
2122017-08-07T15:28:40  <wumpus> promag: I think you need to add it to the test lists
2132017-08-07T15:28:40  <promag> heh did nothing all week to catch it :P
2142017-08-07T15:28:50  <promag> right!
2152017-08-07T15:29:21  *** veleiro has joined #bitcoin-core-dev
2162017-08-07T15:30:23  <promag> wumpus: extended script?
2172017-08-07T15:30:43  <promag> does it have to be run in travis?
2182017-08-07T15:35:58  <wumpus> if it takes up to a few seconds you should add it to the normal tests
2192017-08-07T15:36:19  <wumpus> extended tests is for tests that take significant time
2202017-08-07T15:38:50  *** veleiro has quit IRC
2212017-08-07T15:41:26  <bitcoin-git> [bitcoin] jnewbery opened pull request #11001: [tests] Test disconnecting unsupported service bits logic. (master...unsupported_service_bits_test) https://github.com/bitcoin/bitcoin/pull/11001
2222017-08-07T15:45:59  *** BashCo has joined #bitcoin-core-dev
2232017-08-07T15:54:43  *** belcher has quit IRC
2242017-08-07T16:02:31  *** belcher has joined #bitcoin-core-dev
2252017-08-07T16:06:30  *** veleiro has joined #bitcoin-core-dev
2262017-08-07T16:18:58  *** Guyver2 has quit IRC
2272017-08-07T16:22:32  *** promag has quit IRC
2282017-08-07T16:30:30  *** Chris_Stewart_5 has quit IRC
2292017-08-07T16:31:08  *** veleiro has quit IRC
2302017-08-07T16:43:21  *** str4d has joined #bitcoin-core-dev
2312017-08-07T16:47:22  *** spudowiar has joined #bitcoin-core-dev
2322017-08-07T16:47:45  *** spudowiar has left #bitcoin-core-dev
2332017-08-07T16:49:03  *** veleiro has joined #bitcoin-core-dev
2342017-08-07T16:50:22  *** str4d has quit IRC
2352017-08-07T16:50:54  *** jrayhawk_ is now known as jrayhawkj
2362017-08-07T16:50:55  *** jrayhawkj is now known as jrayhawk
2372017-08-07T16:52:42  *** abpa has joined #bitcoin-core-dev
2382017-08-07T16:52:57  *** str4d has joined #bitcoin-core-dev
2392017-08-07T16:58:18  *** miknotauro has joined #bitcoin-core-dev
2402017-08-07T16:59:36  *** timothy has quit IRC
2412017-08-07T17:06:48  *** promag has joined #bitcoin-core-dev
2422017-08-07T17:09:35  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2432017-08-07T17:21:07  <jonasschnelli> gmaxwell: re: https://github.com/jonasschnelli/bips/wiki/NODE_NETWORK_LIMITED-BIP-DRAFT#network-health-optional
2442017-08-07T17:21:08  <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?
2452017-08-07T17:21:37  <jonasschnelli> Nah.. nm. Let me remove that part...
2462017-08-07T17:26:36  *** d_t has joined #bitcoin-core-dev
2472017-08-07T17:34:46  *** PaulCapestany has joined #bitcoin-core-dev
2482017-08-07T17:40:37  <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
2492017-08-07T17:40:59  <jonasschnelli> Oh. Yes. Let me remove that part...
2502017-08-07T17:42:18  <jonasschnelli> luke-jr: its removed now
2512017-08-07T17:43:17  <luke-jr> jonasschnelli: rather than forbid the bits when NODE_NETWORK is set, I suggest leaving them entirely undefined in that circumstance
2522017-08-07T17:44:21  *** abpa has quit IRC
2532017-08-07T17:44:25  <jonasschnelli> luke-jr: I don't think one should signal LIMITED and NODE_NETWORK. It may confuse primitive implementations
2542017-08-07T17:45:11  <luke-jr> jonasschnelli: forbidding such primitive implementations is why to undefine it now :p
2552017-08-07T17:45:18  <luke-jr> jonasschnelli: please use BIP number 159
2562017-08-07T17:45:53  *** arubi has quit IRC
2572017-08-07T17:46:50  *** arubi has joined #bitcoin-core-dev
2582017-08-07T17:47:51  *** arubi has quit IRC
2592017-08-07T17:48:52  *** arubi has joined #bitcoin-core-dev
2602017-08-07T17:48:53  <sdaftuar> jonasschnelli: i think it's clearest if setting a bit has meaning independent from looking at other bits.
2612017-08-07T17:49:09  <sdaftuar> eg if you want to know if a node has all historical blocks, just check NODE_NETWORK
2622017-08-07T17:49:30  <sdaftuar> if you want to know if it serves recent blocks, just check NODE_LIMITED_*
2632017-08-07T17:49:35  <sdaftuar> and not owrry about setting both
2642017-08-07T17:49:41  <jonasschnelli> I see. Makes sense... I'll fix that
2652017-08-07T17:49:48  *** dgenr8 has quit IRC
2662017-08-07T17:50:05  *** Chris_Stewart_5 has quit IRC
2672017-08-07T17:54:58  <jonasschnelli> Fixed
2682017-08-07T18:04:19  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2692017-08-07T18:13:45  <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))
2702017-08-07T18:14:39  *** str4d has quit IRC
2712017-08-07T18:14:59  <jonasschnelli> committing means probably add the wallet and broadcast? Need to check that source code comment later. Thx
2722017-08-07T18:15:11  <jonasschnelli> Add to the
2732017-08-07T18:15:17  *** str4d has joined #bitcoin-core-dev
2742017-08-07T18:15:48  <xHire> right, that makes sense. thanks!
2752017-08-07T18:33:38  *** laurentmt has joined #bitcoin-core-dev
2762017-08-07T18:34:51  *** Chris_St1 has joined #bitcoin-core-dev
2772017-08-07T18:35:14  *** laurentmt has quit IRC
2782017-08-07T18:35:28  *** Chris_Stewart_5 has quit IRC
2792017-08-07T18:37:18  *** Chris_St1 has quit IRC
2802017-08-07T18:37:28  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2812017-08-07T18:37:41  *** dermoth has quit IRC
2822017-08-07T18:38:04  *** dermoth has joined #bitcoin-core-dev
2832017-08-07T18:47:34  *** Cheeseo has joined #bitcoin-core-dev
2842017-08-07T18:51:46  <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?
2852017-08-07T18:52:17  <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
2862017-08-07T18:52:19  <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
2872017-08-07T18:52:35  <sdaftuar> (rather than bitcoind arguments, which is where that PR started)
2882017-08-07T18:53:32  <luke-jr> sdaftuar: the cache is AFAIK mainly used for multiple clients calling GBT at almost the same time
2892017-08-07T18:54:25  <luke-jr> I'm not sure it makes sense to expose the parameters over RPC like that anyway.
2902017-08-07T18:54:34  <luke-jr> (why would a miner want to run with different configurations?)
2912017-08-07T18:54:48  <sdaftuar> the CNB parameters?  it seemd like it would be annoying to restart bitcoind if you wanted to change the parameter
2922017-08-07T18:54:51  <sdaftuar> eg in response to network conditions
2932017-08-07T18:55:32  <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
2942017-08-07T18:55:46  <sdaftuar> but no idea how much load it could take from multiple clients
2952017-08-07T18:58:34  <sdaftuar> eh, i will punt on it for now and just leave it as a bitcoind argument i guess
2962017-08-07T19:14:29  <luke-jr> sdaftuar: there are more than just mining parameters that are nice to adjust at runtime. Yet another use for a setconfig RPC..
2972017-08-07T19:15:05  *** Aaronvan_ is now known as AaronvanW
2982017-08-07T19:15:50  <sdaftuar> sure, i agree with that in general
2992017-08-07T19:19:46  *** promag has quit IRC
3002017-08-07T19:27:53  *** d_t has quit IRC
3012017-08-07T19:31:07  *** Chris_Stewart_5 has quit IRC
3022017-08-07T19:38:38  <SopaXorzTaker> When will the alert key be published?
3032017-08-07T19:38:49  <SopaXorzTaker> (don't forget to withdraw the coins that are sitting there, devs!)
3042017-08-07T19:41:20  *** abpa has joined #bitcoin-core-dev
3052017-08-07T19:45:51  *** chjj has quit IRC
3062017-08-07T19:52:29  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3072017-08-07T19:53:17  <bitcoin-git> [bitcoin] jnewbery opened pull request #11002: [wallet] return correct error code from resendwallettransaction (master...resendwallettransaction_error_code) https://github.com/bitcoin/bitcoin/pull/11002
3082017-08-07T19:57:20  *** chjj has joined #bitcoin-core-dev
3092017-08-07T19:59:51  *** Ylbam has joined #bitcoin-core-dev
3102017-08-07T20:01:00  *** str4d has quit IRC
3112017-08-07T20:13:15  *** sam_c has quit IRC
3122017-08-07T20:13:32  *** sam_c has joined #bitcoin-core-dev
3132017-08-07T20:21:23  *** sam_c has quit IRC
3142017-08-07T20:22:24  *** sam_c has joined #bitcoin-core-dev
3152017-08-07T20:24:22  *** chjj has quit IRC
3162017-08-07T20:29:19  <jnewbery> jonasschnelli: I agree with sdaftuar and sipa that bits should be considered independently.
3172017-08-07T20:30:42  <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}
3182017-08-07T20:31:05  <jnewbery> I'd remove the line "The required behaviour when signaling both bits (NODE_NETWORK_LIMITED_LOW & NODE_NETWORK_LIMITED_HIGH) is currently undefined."
3192017-08-07T20:32:15  *** SopaXorzTaker has quit IRC
3202017-08-07T20:33:41  <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.
3212017-08-07T20:37:52  *** Dizzle has quit IRC
3222017-08-07T20:37:55  <gmaxwell> if we reject, then we can't use them seperately in the future because older peers will ignore us.
3232017-08-07T20:39:37  <sipa> jnewbery: i changed the links on the wiki to be section references rather than URLs, and added more
3242017-08-07T20:48:50  <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?
3252017-08-07T20:50:21  <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
3262017-08-07T21:02:11  <jnewbery> sipa: looks good. I think everything in #9889 is now covered
3272017-08-07T21:02:13  <gribble> https://github.com/bitcoin/bitcoin/issues/9889 | TODO for release notes 0.15.0 · Issue #9889 · bitcoin/bitcoin · GitHub
3282017-08-07T21:03:55  <luke-jr> jnewbery: that wastes bits
3292017-08-07T21:05:16  <jnewbery> gmaxwell you're right. Reject is incorrect. Should have said 'ignore bits if one but not all of them are set'
3302017-08-07T21:05:31  <luke-jr> unless perhaps it's if (NODE_NETWORK) else if (NODE_LIMITED_LOW) else if (NODE_LIMITED_HIGH) …
3312017-08-07T21:06:33  <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)
3322017-08-07T21:07:05  <luke-jr> (leaving the LIMITED_LOW | LIMITED_HIGH combination for a LOW + deterministic assortment of history)
3332017-08-07T21:08:02  *** jamesob has joined #bitcoin-core-dev
3342017-08-07T21:08:03  *** promag has joined #bitcoin-core-dev
3352017-08-07T21:12:25  <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.
3362017-08-07T21:15:17  <jnewbery> I agree. I don't think the meaning of a single bit should be dependent on other bits
3372017-08-07T21:16:26  <sipa> agree
3382017-08-07T21:16:34  *** abpa has quit IRC
3392017-08-07T21:17:47  *** chjj has joined #bitcoin-core-dev
3402017-08-07T21:19:32  *** abpa has joined #bitcoin-core-dev
3412017-08-07T21:22:22  *** sam_c has quit IRC
3422017-08-07T21:23:34  *** sam_c has joined #bitcoin-core-dev
3432017-08-07T21:27:29  <promag> jnewbery: updated #11000, ty
3442017-08-07T21:27:31  <gribble> https://github.com/bitcoin/bitcoin/issues/11000 | test: Add resendwallettransactions functional tests by promag · Pull Request #11000 · bitcoin/bitcoin · GitHub
3452017-08-07T21:28:17  <bitcoin-git> [bitcoin] eklitzke opened pull request #11003: Docs: Capitalize bullet points in CONTRIBUTING guide (master...contributing_grammar) https://github.com/bitcoin/bitcoin/pull/11003
3462017-08-07T21:28:46  *** dgenr8 has joined #bitcoin-core-dev
3472017-08-07T21:29:27  *** veleiro has quit IRC
3482017-08-07T21:32:39  <jnewbery> thanks promag
3492017-08-07T21:34:31  *** abpa has quit IRC
3502017-08-07T21:37:35  *** unholymachine has quit IRC
3512017-08-07T21:40:05  *** unholymachine has joined #bitcoin-core-dev
3522017-08-07T21:41:00  *** abpa has joined #bitcoin-core-dev
3532017-08-07T21:42:42  <luke-jr> jnewbery: so we just burn 1 bit for every resolution of chain archival? :/
3542017-08-07T21:43:10  <jnewbery> if there are only two resolutions, that's not a problem
3552017-08-07T21:43:25  <luke-jr> there aren't.
3562017-08-07T21:43:43  <luke-jr> even with just this BIP, there are three. and no reason to expect it to end with that.
3572017-08-07T21:43:50  <jnewbery> by the time we run out of bits, we'll already have the new addr message
3582017-08-07T21:43:59  <luke-jr> why do we want a new addr message?
3592017-08-07T21:44:54  <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.
3602017-08-07T21:44:56  <jnewbery> 06:36 < gmaxwell> (because of HSNG and I2P)
3612017-08-07T21:46:19  <luke-jr> making the IP size longer isn't really a reason to use service bits unwisely
3622017-08-07T22:02:47  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/318392ca7cda...fa8a0639f7b0
3632017-08-07T22:02:47  <bitcoin-git> bitcoin/master 5e35cd9 John Newbery: [tests] Test disconnecting unsupported service bits logic....
3642017-08-07T22:02:48  <bitcoin-git> bitcoin/master fa8a063 MarcoFalke: Merge #11001: [tests] Test disconnecting unsupported service bits logic....
3652017-08-07T22:03:30  <bitcoin-git> [bitcoin] MarcoFalke closed pull request #11001: [tests] Test disconnecting unsupported service bits logic. (master...unsupported_service_bits_test) https://github.com/bitcoin/bitcoin/pull/11001
3662017-08-07T22:05:24  *** sam_c has quit IRC
3672017-08-07T22:06:30  *** laurentmt has joined #bitcoin-core-dev
3682017-08-07T22:08:08  *** sam_c has joined #bitcoin-core-dev
3692017-08-07T22:20:23  *** veleiro has joined #bitcoin-core-dev
3702017-08-07T22:24:49  *** Hello has joined #bitcoin-core-dev
3712017-08-07T22:25:03  *** d_t has joined #bitcoin-core-dev
3722017-08-07T22:25:31  <Hello> everyone, Can somebody inform me on how to check if the coin chain has split ? is there a RPC command ?
3732017-08-07T22:26:07  <sipa> getchaintips
3742017-08-07T22:27:28  *** sam_c has quit IRC
3752017-08-07T22:28:34  *** sam_c has joined #bitcoin-core-dev
3762017-08-07T22:30:55  <Hello> hey sipa thank you for the tip but it says method not found
3772017-08-07T22:31:33  <LordCow> bitcoin-cli getchaintips
3782017-08-07T22:31:57  <Hello> I forgot to mention I want to check this on a alt coin wallet
3792017-08-07T22:34:22  *** Chris_Stewart_5 has quit IRC
3802017-08-07T22:39:21  <Hello> Client version is 1.0.0.0-g9ccfb23-beta
3812017-08-07T22:40:10  *** laurentmt has quit IRC
3822017-08-07T22:43:56  <gmaxwell> oh jesus I broke the release notes wiki, pieter is fixing it.
3832017-08-07T22:44:32  <gmaxwell> Pro tip: if you hit edit, then change the title for a page on the wiki, it nukes the history.
3842017-08-07T22:45:21  <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)
3852017-08-07T22:47:53  *** promag has quit IRC
3862017-08-07T22:48:11  <sipa> Hello: then go yell at its developers
3872017-08-07T22:48:48  <sipa> gmaxwell: fixed
3882017-08-07T22:50:36  <Hello> Sipa: I can't yell at myself lmao
3892017-08-07T22:52:23  <sipa> Hello: in any case, off topic here
3902017-08-07T22:52:54  <Hello> sipa: thanks for replying have a nice day
3912017-08-07T22:53:00  *** promag has joined #bitcoin-core-dev
3922017-08-07T22:57:40  *** Hello has quit IRC
3932017-08-07T23:01:00  *** miknotauro has quit IRC
3942017-08-07T23:01:01  *** arubi has quit IRC
3952017-08-07T23:02:01  *** arubi has joined #bitcoin-core-dev
3962017-08-07T23:02:29  *** Giszmo has quit IRC
3972017-08-07T23:09:55  *** elkalamar has joined #bitcoin-core-dev
3982017-08-07T23:22:34  *** Soligor has quit IRC
3992017-08-07T23:33:12  *** Soligor has joined #bitcoin-core-dev
4002017-08-07T23:38:02  *** Ylbam has quit IRC
4012017-08-07T23:53:23  <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.
4022017-08-07T23:58:40  *** promag has quit IRC