12016-07-18T00:02:31  *** molz has quit IRC
  22016-07-18T00:15:47  *** Ylbam has quit IRC
  32016-07-18T00:19:13  *** xinxi has joined #bitcoin-core-dev
  42016-07-18T00:25:47  *** xinxi has quit IRC
  52016-07-18T00:28:14  *** netsin has quit IRC
  62016-07-18T00:28:49  *** netsin has joined #bitcoin-core-dev
  72016-07-18T00:32:51  *** netsin has quit IRC
  82016-07-18T00:35:00  *** netsin has joined #bitcoin-core-dev
  92016-07-18T00:38:28  *** jcliff42 has quit IRC
 102016-07-18T00:45:57  *** netsin has quit IRC
 112016-07-18T00:50:02  *** YOU-JI has joined #bitcoin-core-dev
 122016-07-18T01:13:58  *** fengling has joined #bitcoin-core-dev
 132016-07-18T01:17:21  *** TomMc has quit IRC
 142016-07-18T01:26:40  *** jtimon has quit IRC
 152016-07-18T01:34:33  *** Giszmo has joined #bitcoin-core-dev
 162016-07-18T01:36:28  *** Giszmo1 has quit IRC
 172016-07-18T01:40:46  *** belcher has quit IRC
 182016-07-18T01:46:31  *** netsin has joined #bitcoin-core-dev
 192016-07-18T01:46:47  *** jtimon has joined #bitcoin-core-dev
 202016-07-18T01:49:57  <GitHub30> [bitcoin] Tyler-Hardin closed pull request #8349: Qt: Clearer warning about being out of sync (master...issue8060) https://github.com/bitcoin/bitcoin/pull/8349
 212016-07-18T01:52:29  *** netsin has quit IRC
 222016-07-18T01:53:11  *** Justinus has quit IRC
 232016-07-18T02:05:35  *** Justinus has joined #bitcoin-core-dev
 242016-07-18T02:14:16  *** Justinus has quit IRC
 252016-07-18T02:16:52  *** YOU-JI has quit IRC
 262016-07-18T02:28:56  <ebfull> luke-jr: we should team up to coordinate integration/UX strategy for #7601 and #7534
 272016-07-18T02:37:18  *** Chris_Stewart_5 has quit IRC
 282016-07-18T02:48:41  *** xinxi has joined #bitcoin-core-dev
 292016-07-18T02:53:33  *** xinxi has quit IRC
 302016-07-18T03:11:53  *** justanotheruser has quit IRC
 312016-07-18T03:11:59  *** justanot1eruser has joined #bitcoin-core-dev
 322016-07-18T03:12:36  *** justanot1eruser is now known as justanotheruser
 332016-07-18T03:20:04  <GitHub157> [bitcoin] maiiz closed pull request #8336: TX fees and policy: fix relaypriority calculation error Issues #8334 (master...issues-8334) https://github.com/bitcoin/bitcoin/pull/8336
 342016-07-18T03:46:54  *** xinxi has joined #bitcoin-core-dev
 352016-07-18T03:47:22  *** YOU-JI has joined #bitcoin-core-dev
 362016-07-18T04:01:22  *** netsin has joined #bitcoin-core-dev
 372016-07-18T04:14:27  *** xinxi has quit IRC
 382016-07-18T04:22:23  *** xinxi has joined #bitcoin-core-dev
 392016-07-18T04:56:52  *** netsin has quit IRC
 402016-07-18T05:03:54  *** xinxi has quit IRC
 412016-07-18T05:04:34  *** achow101 has quit IRC
 422016-07-18T05:11:55  *** jtimon has quit IRC
 432016-07-18T05:25:56  *** xinxi has joined #bitcoin-core-dev
 442016-07-18T05:31:35  *** netsin has joined #bitcoin-core-dev
 452016-07-18T05:34:19  *** YOU-JI has quit IRC
 462016-07-18T05:43:35  <wumpus> phantomcircuit: not yet
 472016-07-18T05:46:38  <GitHub121> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/bc94b8748782...37303934fe8f
 482016-07-18T05:46:39  <GitHub121> bitcoin/master 96fa953 Suhas Daftuar: Improve handling of unconnecting headers...
 492016-07-18T05:46:39  <GitHub121> bitcoin/master e91cf4b Suhas Daftuar: Add test for handling of unconnecting headers
 502016-07-18T05:46:40  <GitHub121> bitcoin/master 3730393 Wladimir J. van der Laan: Merge #8305: Improve handling of unconnecting headers...
 512016-07-18T05:46:47  <GitHub135> [bitcoin] laanwj closed pull request #8305: Improve handling of unconnecting headers (master...fix-relay-2hr-rule) https://github.com/bitcoin/bitcoin/pull/8305
 522016-07-18T05:47:45  *** xinxi has quit IRC
 532016-07-18T05:49:11  *** slackircbridge has quit IRC
 542016-07-18T05:50:47  *** slackircbridge has joined #bitcoin-core-dev
 552016-07-18T05:58:58  <GitHub1> [bitcoin] laanwj pushed 7 new commits to master: https://github.com/bitcoin/bitcoin/compare/37303934fe8f...238300b39894
 562016-07-18T05:58:59  <GitHub1> bitcoin/master 5b95dd2 Jonas Schnelli: [Wallet] extend CKeyMetadata with HD keypath
 572016-07-18T05:58:59  <GitHub1> bitcoin/master b1c7b24 Jonas Schnelli: [Wallet] report optional HDKeypath/HDMasterKeyId in validateaddress
 582016-07-18T05:59:00  <GitHub1> bitcoin/master 986c223 Jonas Schnelli: [Wallet] print hd masterkeyid in getwalletinfo
 592016-07-18T05:59:11  <GitHub6> [bitcoin] laanwj closed pull request #8323: Add HD keypath to CKeyMetadata, report metadata in validateaddress (master...2016/07/hd_013) https://github.com/bitcoin/bitcoin/pull/8323
 602016-07-18T06:00:34  <wumpus> jonasschnelli: should #8308 be a blocker for the 0.13 rc1?
 612016-07-18T06:03:46  <wumpus> (it's labeled milestone 0.13, but #8206 is not)
 622016-07-18T06:10:52  <GitHub68> [bitcoin] laanwj opened pull request #8354: mining: Rename `-blockmaxcost` to `-blockmaxweight` (master...2016_07_block_weight) https://github.com/bitcoin/bitcoin/pull/8354
 632016-07-18T06:11:15  *** netsin has quit IRC
 642016-07-18T06:24:06  <GitHub81> [bitcoin] laanwj pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/238300b39894...f5660d381a37
 652016-07-18T06:24:07  <GitHub81> bitcoin/master f15c2cd Suhas Daftuar: CreateNewBlock: add support for size-accounting to addPackageTxs...
 662016-07-18T06:24:07  <GitHub81> bitcoin/master 6dd4bc2 Suhas Daftuar: Exclude witness transactions in addPackageTxs() pre-segwit activation
 672016-07-18T06:24:08  <GitHub81> bitcoin/master d2e46e1 Suhas Daftuar: Remove addScoreTxs()
 682016-07-18T06:24:13  <GitHub37> [bitcoin] laanwj closed pull request #8295: Mining-related fixups for 0.13.0 (master...cnb-segwit) https://github.com/bitcoin/bitcoin/pull/8295
 692016-07-18T06:37:57  <GitHub46> [bitcoin] maiiz opened pull request #8355: [Wallet]fix relaypriority calculation error Issues #8334 (master...issues-8334) https://github.com/bitcoin/bitcoin/pull/8355
 702016-07-18T06:42:17  <wumpus> am I missing some context re: #8349? did someone get into a fight with the guy?
 712016-07-18T06:43:35  <paveljanik> wumpus, I do not think so.
 722016-07-18T06:44:31  <wumpus> I was thinking it was awesome that someone addressed #8334, then at the same moment he closed the pull and deleted the branch
 732016-07-18T06:44:54  <wumpus> addressed #8060, sorry
 742016-07-18T06:45:53  *** xinxi has joined #bitcoin-core-dev
 752016-07-18T06:48:18  <paveljanik> strange, yes.
 762016-07-18T06:48:48  <GitHub94> [bitcoin] maiiz closed pull request #8355: [Wallet]fix relaypriority calculation error Issues #8334 (master...issues-8334) https://github.com/bitcoin/bitcoin/pull/8355
 772016-07-18T06:49:27  <wumpus> now maiiz is doing the same in #8355, either this is a github issue or people are trolling us...
 782016-07-18T06:51:52  <paveljanik> maiiz probably has a problem with github web interface.
 792016-07-18T06:56:39  *** adamg has quit IRC
 802016-07-18T07:00:19  <GitHub190> [bitcoin] NicolasDorier opened pull request #8356: Wallet: Minimum output value depends on fee instead of minTxRelayFee (master...wallet-min-output) https://github.com/bitcoin/bitcoin/pull/8356
 812016-07-18T07:04:57  <GitHub127> [bitcoin] maiiz opened pull request #8357: Update coins.cpp (master...maiiz-patch-1) https://github.com/bitcoin/bitcoin/pull/8357
 822016-07-18T07:05:07  <GitHub5> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f5660d381a37...8cb288a6b37d
 832016-07-18T07:05:08  <GitHub5> bitcoin/master d6dc1bc Krzysztof Jurewicz: Fix 0.12 release notes on block relaying...
 842016-07-18T07:05:08  <GitHub5> bitcoin/master 8cb288a Wladimir J. van der Laan: Merge #8320: Fix 0.12 release notes on block relaying...
 852016-07-18T07:05:12  <GitHub49> [bitcoin] laanwj closed pull request #8320: Fix 0.12 release notes on block relaying (master...0.12-release-notes-block-relaying) https://github.com/bitcoin/bitcoin/pull/8320
 862016-07-18T07:10:40  <GitHub20> [bitcoin] MarcoFalke closed pull request #7615: [WIP] [wallet] Couple minimum change with minimum relay fee (master...Mf1602-walletMinChange) https://github.com/bitcoin/bitcoin/pull/7615
 872016-07-18T07:14:06  *** MarcoFalke has joined #bitcoin-core-dev
 882016-07-18T07:18:51  <jonasschnelli> wumpus: no. 8308 is more or less a feature and can go into 0.14
 892016-07-18T07:19:17  <jonasschnelli> IMO it's unclear if "importwallet" should import the HD master seed and set it according to the importet wallet
 902016-07-18T07:19:33  <wumpus> thanks, I agree
 912016-07-18T07:19:42  <jonasschnelli> *import* somehow implies that "old stuff is unchanged"
 922016-07-18T07:20:12  <jonasschnelli> But its good to have the extended master key "xpriv" visible in the dump... but as said. can go into 0.14
 932016-07-18T07:20:36  <wumpus> indeed, it's something that needs to be considered carefully, youd don't expect to switch to another HD chain automatically when importing say, an old wallet
 942016-07-18T07:21:01  <wumpus> the only time you would want that is if you intend  the imported wallet to replace your current one
 952016-07-18T07:21:03  <wumpus> removing the 0.13 milestone there
 962016-07-18T07:21:14  <jonasschnelli> yes. Thanks.
 972016-07-18T07:21:18  <jonasschnelli> Re https://github.com/bitcoin/bitcoin/pull/8343/files/51a4ee889e3d317fb51623701f06919adf0ee267#r71106179
 982016-07-18T07:21:36  <jonasschnelli> wumpus: I don't think it's possible without non-Client-Versions
 992016-07-18T07:21:51  <jonasschnelli> The nWalletMinVersion is tied to the clientversion
1002016-07-18T07:22:24  <wumpus> we did a similar thing for network at some point, the P2P version used to be coupled to the client version as well
1012016-07-18T07:22:30  *** Ylbam has joined #bitcoin-core-dev
1022016-07-18T07:22:51  <wumpus> at some point we created a dedicated network version constant, which is bumped on non-compatible network changes
1032016-07-18T07:23:02  <jonasschnelli> wumpus: Yes. We could do this. But detecting 0.12 (and make it fail on 0.12) requires to stick to the clientversion
1042016-07-18T07:23:18  <wumpus> using the client version for anything else but reporting forces arbitrary release process constraints on versioning certain behavior
1052016-07-18T07:23:32  <wumpus> yes, I agree, you'd leave the old versions the same
1062016-07-18T07:23:56  <jonasschnelli> problematic part: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/walletdb.cpp#L637
1072016-07-18T07:24:13  <wumpus> this would be a change going forward, for the future, it can't be done retrospectively for versions that are already released :)
1082016-07-18T07:24:21  <wumpus> in any case no hurry
1092016-07-18T07:25:10  <sipa> wumpus: i guess it can be replaced with a set of strings
1102016-07-18T07:25:22  <jonasschnelli> Yes. We should slowly decouple it from CLIENT_VERSION
1112016-07-18T07:25:27  <sipa> wumpus: denoting features that the wallet uses
1122016-07-18T07:25:33  <jonasschnelli> sipa: you mean set of string about what features it supports?
1132016-07-18T07:25:36  <jonasschnelli> ok.
1142016-07-18T07:25:46  <wumpus> sipa: and then exit if a non-supported feature is used, yes
1152016-07-18T07:25:48  <jonasschnelli> Flags? Bitmask?
1162016-07-18T07:26:05  <wumpus> strings are slightly better in this case because you can report the name of the feature even in versions that don't support it
1172016-07-18T07:26:18  <wumpus> e.g. generating errors like 'this wallet uses BIP32 which is not supported in this version'
1182016-07-18T07:26:28  <jonasschnelli> ah.. fair enought
1192016-07-18T07:26:47  <jonasschnelli> We could do this once we switch over to a different database format (logdb)
1202016-07-18T07:26:48  <wumpus> with bitmask you can only report the flag number, and there's no real need to be very compact here
1212016-07-18T07:26:54  <jonasschnelli> (which is overdue since years)
1222016-07-18T07:26:59  <wumpus> (it'd be something stored only once in the wallet)
1232016-07-18T07:29:57  <sipa> wumpus: i like the ext2/3/4 compatibility system
1242016-07-18T07:30:11  <sipa> wumpus: with 3 sets of strings/flags
1252016-07-18T07:31:06  <sipa> 1) "if you don't know one of these, ignore" 2) "if you don't know any of these, only open read-only" 3) "if you don't know any of these, refuse to mount"
1262016-07-18T07:31:37  *** anu0 has joined #bitcoin-core-dev
1272016-07-18T07:33:39  <jonasschnelli> sipa: Indeed. This would be good.
1282016-07-18T07:34:17  <jonasschnelli> But the problem is, such stuff should had be implemented at the beginning. Now it should/must be tied to a more radical wallet format change.
1292016-07-18T07:35:10  *** anu1 has quit IRC
1302016-07-18T07:36:39  <sipa> no, you can just see the switch to such a new system as a 'feature' in the old compatibility system
1312016-07-18T07:47:09  *** xinxi has quit IRC
1322016-07-18T07:49:26  *** fengling has quit IRC
1332016-07-18T07:49:46  *** fengling_ has joined #bitcoin-core-dev
1342016-07-18T08:05:28  <jonasschnelli> sipa: Yes. Indeed. Possible migration path.
1352016-07-18T08:06:10  *** xinxi has joined #bitcoin-core-dev
1362016-07-18T08:07:26  *** xinxi has quit IRC
1372016-07-18T08:08:13  *** Guyver2 has joined #bitcoin-core-dev
1382016-07-18T08:19:04  *** nickler has quit IRC
1392016-07-18T08:25:17  *** nickler has joined #bitcoin-core-dev
1402016-07-18T08:27:30  *** laurentmt has joined #bitcoin-core-dev
1412016-07-18T08:28:20  *** laurentmt has quit IRC
1422016-07-18T08:28:53  *** molly has quit IRC
1432016-07-18T08:43:41  <wumpus> bah, changing all occurences of 'cost' to 'weight' is a huge change
1442016-07-18T08:44:32  <wumpus> I'm having second thoughts about it
1452016-07-18T08:45:26  <wumpus> changing it just in user-facing messages is doable, but it also appears in the RPC API, in variable names, in tons of comments
1462016-07-18T08:49:15  <wumpus> and don't really want to block the 0.13 branch on this
1472016-07-18T08:49:58  <GitHub77> [bitcoin] laanwj closed pull request #8354: mining: Rename `-blockmaxcost` to `-blockmaxweight` (master...2016_07_block_weight) https://github.com/bitcoin/bitcoin/pull/8354
1482016-07-18T08:51:22  <sipa> so you want to delay the change until 0.13 is branched off?
1492016-07-18T08:51:37  <sipa> or reconsider entirely?
1502016-07-18T08:51:48  <wumpus> I don't think I want to do it anymore
1512016-07-18T08:52:48  <MarcoFalke> What about only changing -help and rpc calls?
1522016-07-18T08:52:56  <MarcoFalke> And then the nasty code cleaup for 0.14?
1532016-07-18T08:53:08  <wumpus> I don't think it's worth it
1542016-07-18T08:53:37  <wumpus> should have paid more attention to this during the BIP draft
1552016-07-18T08:54:38  <wumpus> maybe just change the help message to "Set maximum BIP141 block cost"
1562016-07-18T08:54:59  <wumpus> then everyone can look it up if they want
1572016-07-18T08:55:31  <wumpus> changing the BIP now because of a word impacts all other implementations too
1582016-07-18T08:57:02  <GitHub191> [bitcoin] MarcoFalke opened pull request #8358: [doc] gbuild: Set memory explicitly (default is too low) (master...Mf1607-docBuild) https://github.com/bitcoin/bitcoin/pull/8358
1592016-07-18T08:57:38  <GitHub7> [bitcoin] laanwj opened pull request #8359: mining: Improve `-blockmaxcost` help message (master...2016_07_blockmaxcost_doc) https://github.com/bitcoin/bitcoin/pull/8359
1602016-07-18T09:11:23  *** Guyver2 has quit IRC
1612016-07-18T09:16:08  *** xinxi has joined #bitcoin-core-dev
1622016-07-18T09:18:23  *** kadoban has quit IRC
1632016-07-18T09:23:09  *** xinxi has quit IRC
1642016-07-18T09:27:10  *** xinxi has joined #bitcoin-core-dev
1652016-07-18T09:28:28  *** MarcoFalke has left #bitcoin-core-dev
1662016-07-18T09:30:25  *** jannes has joined #bitcoin-core-dev
1672016-07-18T09:31:48  *** xinxi has quit IRC
1682016-07-18T10:06:13  <GitHub67> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8cb288a6b37d...03c56f62c2fd
1692016-07-18T10:06:13  <GitHub67> bitcoin/master 8cef5bd Wladimir J. van der Laan: mining: Improve `-blockmaxcost` help message...
1702016-07-18T10:06:14  <GitHub67> bitcoin/master 03c56f6 Wladimir J. van der Laan: Merge #8359: mining: Improve `-blockmaxcost` help message...
1712016-07-18T10:06:23  <GitHub184> [bitcoin] laanwj closed pull request #8359: mining: Improve `-blockmaxcost` help message (master...2016_07_blockmaxcost_doc) https://github.com/bitcoin/bitcoin/pull/8359
1722016-07-18T10:13:54  <GitHub83> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/e4382fbef56a0e04b0ed834e8b3a3a16f81db149
1732016-07-18T10:13:54  <GitHub83> bitcoin/master e4382fb Wladimir J. van der Laan: qt: periodic translations update
1742016-07-18T10:22:39  <GitHub85> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/6c0336c7723da274c8312b82ed2a138f5d57158f
1752016-07-18T10:22:39  <GitHub85> bitcoin/master 6c0336c Wladimir J. van der Laan: build: bump version to 0.13.99...
1762016-07-18T10:22:50  <wumpus> 0.13 branch was created
1772016-07-18T10:29:43  <sipa> \o/
1782016-07-18T10:32:57  *** Ginnarr has joined #bitcoin-core-dev
1792016-07-18T10:36:23  *** Samdney has joined #bitcoin-core-dev
1802016-07-18T10:40:57  *** fengling_ has quit IRC
1812016-07-18T10:48:58  *** pedrobranco has joined #bitcoin-core-dev
1822016-07-18T10:55:05  *** pedrobranco has quit IRC
1832016-07-18T10:55:24  *** pedrobranco has joined #bitcoin-core-dev
1842016-07-18T10:58:35  *** pedrobranco has quit IRC
1852016-07-18T10:59:00  *** pedrobranco has joined #bitcoin-core-dev
1862016-07-18T11:00:04  *** YOU-JI has joined #bitcoin-core-dev
1872016-07-18T11:01:59  *** pedrobranco has quit IRC
1882016-07-18T11:02:22  *** pedrobranco has joined #bitcoin-core-dev
1892016-07-18T11:04:33  *** pedrobra_ has joined #bitcoin-core-dev
1902016-07-18T11:04:33  *** pedrobranco has quit IRC
1912016-07-18T11:05:30  <btcdrak> which tickets are blocking RC1?
1922016-07-18T11:06:46  <wumpus> #8343 stilln eeds in
1932016-07-18T11:06:52  *** pedrobranco has joined #bitcoin-core-dev
1942016-07-18T11:07:06  <wumpus> (but could only be done after the version bump, because of wallet versioning constraints)
1952016-07-18T11:07:18  *** pedrobra_ has quit IRC
1962016-07-18T11:09:18  <btcdrak> now the branching has happened, are we clear for a bit of libconsensus refactoring work?
1972016-07-18T11:09:37  <btcdrak> (in master obviously)
1982016-07-18T11:09:57  *** pedrobranco has quit IRC
1992016-07-18T11:11:25  *** pedrobranco has joined #bitcoin-core-dev
2002016-07-18T11:15:50  <wumpus> I think so...
2012016-07-18T11:21:34  <wumpus> for 0.13 there's still plenty of work to do for the release notes: https://github.com/bitcoin/bitcoin/issues/7678
2022016-07-18T11:28:12  *** NicLin has joined #bitcoin-core-dev
2032016-07-18T11:41:33  *** BitcoinErrorLog has joined #bitcoin-core-dev
2042016-07-18T11:46:29  *** xinxi has joined #bitcoin-core-dev
2052016-07-18T11:47:34  *** instagibbs has joined #bitcoin-core-dev
2062016-07-18T12:00:12  *** molly has joined #bitcoin-core-dev
2072016-07-18T12:00:59  *** Ginnarr has quit IRC
2082016-07-18T12:01:09  *** anu1 has joined #bitcoin-core-dev
2092016-07-18T12:01:36  <GitHub24> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/5e3557b8e36308a27dbeb528569abe638c4d01dd
2102016-07-18T12:01:36  <GitHub24> bitcoin/master 5e3557b Wladimir J. van der Laan: doc: Clean out release notes...
2112016-07-18T12:04:45  *** anu0 has quit IRC
2122016-07-18T12:08:33  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2132016-07-18T12:11:51  <GitHub181> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/37269105c8817a2922410ec17d976263cd589987
2142016-07-18T12:11:51  <GitHub181> bitcoin/0.13 3726910 Wladimir J. van der Laan: build: Release notes update...
2152016-07-18T12:13:32  *** anu1 has quit IRC
2162016-07-18T12:13:50  *** pedrobranco has quit IRC
2172016-07-18T12:13:53  *** anu0 has joined #bitcoin-core-dev
2182016-07-18T12:19:43  *** BitcoinErrorLog has quit IRC
2192016-07-18T12:19:49  *** pedrobranco has joined #bitcoin-core-dev
2202016-07-18T12:21:31  *** pedrobra_ has joined #bitcoin-core-dev
2212016-07-18T12:21:31  *** pedrobranco has quit IRC
2222016-07-18T12:23:29  *** pedrobranco has joined #bitcoin-core-dev
2232016-07-18T12:23:29  *** pedrobra_ has quit IRC
2242016-07-18T12:25:33  *** pedrobranco has quit IRC
2252016-07-18T12:26:12  *** pedrobranco has joined #bitcoin-core-dev
2262016-07-18T12:26:22  *** Chris_Stewart_5 has quit IRC
2272016-07-18T12:29:10  *** xinxi has quit IRC
2282016-07-18T12:29:53  *** xinxi has joined #bitcoin-core-dev
2292016-07-18T12:33:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2302016-07-18T12:34:40  *** xinxi has quit IRC
2312016-07-18T12:46:12  *** xinxi has joined #bitcoin-core-dev
2322016-07-18T12:55:00  *** molly is now known as moli
2332016-07-18T12:57:40  *** Chris_Stewart_5 has quit IRC
2342016-07-18T12:58:37  *** achow101 has joined #bitcoin-core-dev
2352016-07-18T13:07:43  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2362016-07-18T13:08:14  *** mkarrer_ has quit IRC
2372016-07-18T13:15:32  *** mkarrer has joined #bitcoin-core-dev
2382016-07-18T13:22:59  *** TomMc has joined #bitcoin-core-dev
2392016-07-18T13:23:57  <GitHub75> [bitcoin] laanwj opened pull request #8360: doc: Add a few items to release notes (0.13...2016_07_release_notes) https://github.com/bitcoin/bitcoin/pull/8360
2402016-07-18T13:28:06  <sipa> wumpus: working on a PR with repease notes about the relay/p2p changes
2412016-07-18T13:28:28  <wumpus> sipa: awesome
2422016-07-18T13:28:36  <sipa> only overlap with yours is the bloom filter requirement for mempool
2432016-07-18T13:29:05  <wumpus> ok
2442016-07-18T14:03:42  <GitHub87> [bitcoin] sipa opened pull request #8361: Some 0.13 release notes about p2p changes (0.13...relnotes-0.13) https://github.com/bitcoin/bitcoin/pull/8361
2452016-07-18T14:03:42  *** pedrobranco has quit IRC
2462016-07-18T14:06:43  *** pedrobranco has joined #bitcoin-core-dev
2472016-07-18T14:10:13  *** jtimon has joined #bitcoin-core-dev
2482016-07-18T14:21:54  *** Lysanders has quit IRC
2492016-07-18T14:30:42  *** pedrobranco has quit IRC
2502016-07-18T14:31:34  *** NicLin has quit IRC
2512016-07-18T14:33:18  *** pedrobranco has joined #bitcoin-core-dev
2522016-07-18T14:33:34  *** Arnavion has quit IRC
2532016-07-18T14:33:39  *** Arnavion has joined #bitcoin-core-dev
2542016-07-18T14:34:23  *** TomMc has quit IRC
2552016-07-18T14:34:48  *** YOU-JI has quit IRC
2562016-07-18T14:40:09  <jonasschnelli> Is there a way to get the best known height? I just figured out, that NotifyHeaderTip() will not pass it the best known height header..
2572016-07-18T14:40:41  <jonasschnelli> I expected that the main logic will get all headers first and pass them through NotifyHeaderTip() before actually downloading blocks...
2582016-07-18T14:42:49  <sipa> yes, it will
2592016-07-18T14:43:00  <sipa> it always notifies with the best known header at the time of calling
2602016-07-18T14:43:17  <jtimon> GetSpendHeight() ? tip->nHeight + 1 ? pindexPrev == NULL ? 0 : pindexPrev->nHeight + 1 ?
2612016-07-18T14:46:53  <jonasschnelli> sipa: okay. Let me check again....
2622016-07-18T14:49:55  <jonasschnelli> sipa: but it seems it loads a couple of headers, then the according blocks and not all headers to the best known height. Right?
2632016-07-18T14:51:01  <sipa> jonasschnelli: i cannot parse your sentence
2642016-07-18T14:51:17  <jonasschnelli> okay.. I'll try to explain different.
2652016-07-18T14:51:37  *** Arnavion has quit IRC
2662016-07-18T14:51:41  *** Arnavion3 has joined #bitcoin-core-dev
2672016-07-18T14:51:45  *** Arnavion3 is now known as Arnavion
2682016-07-18T14:52:05  <jonasschnelli> 1.) Im connected to a node with height 421290, I'm currently at 421100
2692016-07-18T14:52:20  *** AtashiCon has quit IRC
2702016-07-18T14:52:24  *** Arnavion3 has joined #bitcoin-core-dev
2712016-07-18T14:52:28  *** Arnavion3 is now known as AtashiCon
2722016-07-18T14:52:34  <jonasschnelli> 2.) NotifyHeaderTip gives me a header somewhere at height 421150 (50 headers in advance)
2732016-07-18T14:52:47  <jonasschnelli> 3.) Then I'll get the signals for the blocks till 421150
2742016-07-18T14:52:55  <sipa> sounds correct so far
2752016-07-18T14:53:10  <jonasschnelli> Is there no way to get signal with "the best known header" (from the remote peers)?
2762016-07-18T14:53:18  <jonasschnelli> (or the best known height)
2772016-07-18T14:53:28  <jonasschnelli> I want to work on the UI progress
2782016-07-18T14:53:29  <sipa> you don't know the peer's best header until we have it as well
2792016-07-18T14:53:50  <jonasschnelli> sipa: and main does not load all headers first,.. only a bunch of them, then the blocks?
2802016-07-18T14:54:14  <sipa> exactly what do you want to do?
2812016-07-18T14:54:30  <jonasschnelli> I'd like to show the "remaning blocks to process" untill we are in sync
2822016-07-18T14:54:56  <sipa> show the difference between the height of the last notifybesttip and the last notifybestheader
2832016-07-18T14:54:57  <jonasschnelli> So... I'd like to get signaled with "all" the headers first
2842016-07-18T14:55:25  <sipa> that's what notifybestheader does...
2852016-07-18T14:56:00  <jonasschnelli> sipa: I do that.. but its not really what i wanted. Say I'm 300 blocks behind. The GUI now report 50 blocks behind, slowly reduces that number, jumps back to 50, etc.
2862016-07-18T14:56:33  <sipa> if it's behind a lot the headers should progress much much faster than the blocks
2872016-07-18T14:56:44  <sipa> it usually takes only a minute or two to learn about all headers
2882016-07-18T14:57:13  <sipa> ah!
2892016-07-18T14:57:19  <sipa> notifybestheader is not called during IBD
2902016-07-18T14:57:44  <sipa> oh, no, it is
2912016-07-18T14:57:50  <sipa> but with a false parameter
2922016-07-18T14:57:51  <jonasschnelli> ah... IBD is also true if I start bitcoin-core with 200 blocks behind. Right?
2932016-07-18T14:58:02  <sipa> yes
2942016-07-18T14:58:10  <sipa> but it is always called
2952016-07-18T14:58:18  <jonasschnelli> Hmm.. let me debug more deep
2962016-07-18T14:58:35  <sipa> i'm surprised it only increases 50
2972016-07-18T14:58:43  <sipa> headers should increase by 2000 at a time
2982016-07-18T14:58:53  *** pedrobranco has quit IRC
2992016-07-18T15:00:12  <jonasschnelli> Maybe I'm missing the first signal because of my implementation... sipa: could it be that i get older headers in later NotifyHeaderTip()?
3002016-07-18T15:01:51  <sipa> at the time of the notify, what you see is always the best known header
3012016-07-18T15:02:08  *** pedrobranco has joined #bitcoin-core-dev
3022016-07-18T15:06:33  <jonasschnelli> RPC getblockchaininfo report a newer height that I get passed over NotifyHeaderTip()
3032016-07-18T15:09:05  <sipa> during IBD that's possible
3042016-07-18T15:09:12  <sipa> oh, wait, no
3052016-07-18T15:09:31  <sipa> are you not filtering out IBD NotifyHeaderTips somewhere?
3062016-07-18T15:10:25  <jonasschnelli> I'm hooking into static void BlockTipChanged(ClientModel *clientmodel, bool initialSync, const CBlockIndex *pIndex, bool fHeader) (clientmodel.cpp)
3072016-07-18T15:11:05  <jonasschnelli> Maybe initially I need to get the height from pindexBestHeader?
3082016-07-18T15:11:23  <sipa> where else?
3092016-07-18T15:11:41  <sipa> ah, pindex->nHeight should work
3102016-07-18T15:11:44  <sipa> can i see the code?
3112016-07-18T15:12:27  <jonasschnelli> it's highly WIP... but let me push it.
3122016-07-18T15:13:20  <jonasschnelli> sipa: https://github.com/jonasschnelli/bitcoin/tree/2016/07/UI-out-of-sync
3132016-07-18T15:13:33  <jonasschnelli> use https://github.com/bitcoin/bitcoin/compare/master...jonasschnelli:2016/07/UI-out-of-sync?expand=1
3142016-07-18T15:14:29  <jonasschnelli> It works much better if i initially call pindexBestHeader->nHeight; then only "accept" header height over NotifyHeaderTips() if they are >
3152016-07-18T15:14:47  <jonasschnelli> Although not sure if this works for reorgs
3162016-07-18T15:15:19  <sipa> i'm very confused
3172016-07-18T15:15:34  <sipa> where in that code you're showing me do you hook into the notification?
3182016-07-18T15:16:56  <sipa> ah, you're adding to setNumBlocks
3192016-07-18T15:17:01  <sipa> that's only called once every 250ms
3202016-07-18T15:17:40  <jonasschnelli> ahh.. that could be the problem
3212016-07-18T15:18:18  <sipa> the header reported through NotifyBestHeader should always be of increasing height
3222016-07-18T15:18:29  <sipa> unless there is a very deep reorg to a lower height
3232016-07-18T15:18:35  <sipa> but that's extremely unlikely
3242016-07-18T15:18:42  <jonasschnelli> Argh.. yes. There is something like: if (!initialSync || now - nLastUpdateNotification > MODEL_UPDATE_DELAY) {
3252016-07-18T15:18:57  <jonasschnelli> Thanks sipa!
3262016-07-18T15:20:10  <jonasschnelli> we could pass through the fHeader=true  signal always...
3272016-07-18T15:21:52  <luke-jr> wumpus: just think of how much more trouble it will be to change s/cost/weight/ *after* 0.13 gets released, if we end up back at that :/
3282016-07-18T15:23:38  *** Chris_Stewart_5 has quit IRC
3292016-07-18T15:23:46  <sipa> luke-jr, wumpus: i'm also a bit surprised by how large you fear the impact of the change is... the term cost (in externally-facing code) is only for blocks, not transactions
3302016-07-18T15:24:02  <sipa> though i didn't try it myself, so i may be missing things
3312016-07-18T15:24:42  <luke-jr> sipa: well, at least changing it in GBT will be annoying once cost is released
3322016-07-18T15:25:39  <sipa> ah, GBT
3332016-07-18T15:25:49  <sipa> i hadn't considered that we'd change things there as well
3342016-07-18T15:25:51  <sipa> but i guess, yes
3352016-07-18T15:26:20  <luke-jr> I guess we don't *have* to, but it will just be confusing if GBT was the odd thing out
3362016-07-18T15:27:24  <sipa> agree
3372016-07-18T15:27:24  *** pedrobranco has quit IRC
3382016-07-18T15:29:32  *** pedrobranco has joined #bitcoin-core-dev
3392016-07-18T15:30:54  <jtimon> yay branch 0.13 forked !
3402016-07-18T15:39:03  <sdaftuar> hmm, it seems that "sigops cost" isn't explicitly defined in bip 141 (though i guess it's implied), yet we refer to that term in the output of gbt
3412016-07-18T15:39:28  <sdaftuar> we didn't talk about it last week, but is "sigops cost" a term we want to keep?
3422016-07-18T15:39:29  <luke-jr> sdaftuar: it was renamed to just "sigops"; I'm surprised GBT ever mentioned it O.o
3432016-07-18T15:39:53  <sdaftuar>             "         \"sigops\" : n,               (numeric) total SigOps cost, as counted for purposes of block limits; if key is not present, sigop cost is unknown and clients MUST NOT assume it is zero\n"
3442016-07-18T15:40:22  <luke-jr> oh, in Core; that's just a bug then IMO
3452016-07-18T15:41:06  <sdaftuar> it seems strange to me that we'd choose to redefine a term...?  at the least we'd have to say "total BIP141-sigops" or something
3462016-07-18T15:41:13  <sdaftuar> but that seems clunky!
3472016-07-18T15:41:14  <luke-jr> sdaftuar: why?
3482016-07-18T15:41:22  <luke-jr> sigops are just counted differently, not redefined
3492016-07-18T15:41:34  <sdaftuar> it's a different unit now
3502016-07-18T15:41:37  <luke-jr> P2SH counted them differently without a rename too
3512016-07-18T15:41:49  <luke-jr> the old counting ceases to be relevant at the fork
3522016-07-18T15:42:09  <sdaftuar> p2sh didn't change the units/scale of sigops for non-p2sh transactions though
3532016-07-18T15:42:31  <luke-jr> …
3542016-07-18T15:42:35  <sdaftuar> i don't think we can just multiply everything by 100 and not change the name, even if mathematically it's the same effect
3552016-07-18T15:42:42  <luke-jr> so you want to rename it every softfork that affects how it's counted?
3562016-07-18T15:42:51  <luke-jr> what's the point?
3572016-07-18T15:57:53  *** netsin has joined #bitcoin-core-dev
3582016-07-18T16:03:35  *** MarcoFalke has joined #bitcoin-core-dev
3592016-07-18T16:04:31  *** Samdney has quit IRC
3602016-07-18T16:04:56  <sdaftuar> luke-jr: i see that getblocktemplate also returns a "sigoplimit" which is explained as "(numeric) cost limit of sigops in blocks", assuming we change that language as well, is there any reason a gbt caller would care what scale the sigops counting is being done in?
3612016-07-18T16:05:06  <sdaftuar> if not then fine, i agree this is all pointless
3622016-07-18T16:05:40  <luke-jr> sdaftuar: a GBT caller cannot know the sigop counting; scale is not different from any other countign changes
3632016-07-18T16:05:45  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3642016-07-18T16:10:56  <sipa> sdaftuar, luke-jr: imho we should change the name when the unit's scale changes
3652016-07-18T16:11:10  <luke-jr> sigh.
3662016-07-18T16:11:33  <sipa> luke-jr: in p2sh, users of non-p2sh transactions would not be affected by the new counting
3672016-07-18T16:12:00  <sipa> here, everyone is affected - assuming that the old unit has the same meaning could lead to accidents
3682016-07-18T16:12:11  <luke-jr> how?
3692016-07-18T16:12:23  <sipa> that's why transaction's "size" is redefined in a backward-compatible way (and not the scaling)
3702016-07-18T16:12:39  <sipa> i agree that for sigops it is unlikely to matter
3712016-07-18T16:12:56  <sipa> but in general, it is a good practice to rename things when their meaning changes
3722016-07-18T16:13:16  <luke-jr> IMO the meaning is essentially the same.
3732016-07-18T16:13:29  <luke-jr> it's an arbitrary consensus-critical counting toward an arbitrary limit.
3742016-07-18T16:13:34  <sipa> if someone were to charge based on #sigops, it is most definitely not the se
3752016-07-18T16:13:40  <sipa> *same
3762016-07-18T16:14:46  <sipa> do you agree that if we'd apply the same logic to size/cost, peoplr would be in trouble, because they may pay 4x too high a fee? (if they apply a feerate measured in bytes to a cost variable)?
3772016-07-18T16:15:27  <sipa> i was fine with not renaming in GBT, but instead giving the consensus limit along with it
3782016-07-18T16:15:31  <luke-jr> yes, because size is something they can calculate external to the consensus system
3792016-07-18T16:15:52  <luke-jr> the same is not true of sigops - you can't calculate it independently from the UTXO set
3802016-07-18T16:16:01  <sipa> i don't think that's relevant
3812016-07-18T16:16:04  <luke-jr> (specifically the UTXOs you're spending)
3822016-07-18T16:16:11  <sipa> it's a consensus-constrained resource
3832016-07-18T16:16:22  <sipa> its usage may affect fees
3842016-07-18T16:16:53  <sipa> this has traditionally not been the case for sigops, so i think it is unlikely to matter
3852016-07-18T16:17:21  <sipa> but in general, i don't think we can apply the argument "it needs UTXOs to calculate, thus it is safe to arbitrarily rescale"
3862016-07-18T16:17:34  <sipa> those two properties are completely unrelated
3872016-07-18T16:18:32  <luke-jr> if you can't calculate it in the first place, then you can't try to do a sigop-feerate independently
3882016-07-18T16:18:37  <sdaftuar> sipa: luke-jr: speaking of sigops, i just noticed this, looks like a bug? https://github.com/bitcoin/bitcoin/blob/master/src/miner.cpp#L190
3892016-07-18T16:18:47  <sdaftuar> shouldn't that quantity be scaled?
3902016-07-18T16:19:13  <sipa> sdaftuar: indeed!
3912016-07-18T16:19:28  <sipa> luke-jr: wallets can calculate sigops in advance
3922016-07-18T16:20:05  <luke-jr> sdaftuar: I guess so. Although I wonder if it ought to be scaled in GetLegacy…
3932016-07-18T16:22:01  <jtimon> MarcoFalke: would it make sense to use the "easy to implement" label for #7829 ?
3942016-07-18T16:24:55  <jtimon> MarcoFalke: thanks!
3952016-07-18T16:28:11  *** netsin has quit IRC
3962016-07-18T16:33:22  *** netsin has joined #bitcoin-core-dev
3972016-07-18T16:35:56  *** Amnez777 has quit IRC
3982016-07-18T16:40:53  *** Lysanders has joined #bitcoin-core-dev
3992016-07-18T16:41:43  <jtimon> BlueMatt: https://github.com/bitcoin/bitcoin/commit/cbda71cf04ef6f2abe6eaa56c3140a6f5cff4feb#commitcomment-18286185
4002016-07-18T16:42:15  <GitHub116> [bitcoin] sdaftuar opened pull request #8362: Scale legacy sigop count in CreateNewBlock (master...coinbase-sigops-scale) https://github.com/bitcoin/bitcoin/pull/8362
4012016-07-18T16:42:15  <wumpus> luke-jr sipa I just think there's more important things to focus on than changing words now
4022016-07-18T16:42:54  <wumpus> I thought it was simply a matter of changing that option, but I severly underestimated things
4032016-07-18T16:43:33  <wumpus> and as horrible names go, I don't think anything beats 'segregated withness' itself :)
4042016-07-18T16:44:54  <sdaftuar> wumpus: i've started to make an attempt at the change myself.  agreed that it's a bit tedious!  but i think if we're willing to consider merging, it'd be better to clear the language now than be saddled with it indefinitely
4052016-07-18T16:46:06  *** netsin has quit IRC
4062016-07-18T16:46:25  *** bsm117532 has quit IRC
4072016-07-18T16:46:37  <wumpus> my experience is that people will get used to any term, but if you really think pushing on with it makes sense I'm not opposed to it
4082016-07-18T16:46:53  *** bsm117532 has joined #bitcoin-core-dev
4092016-07-18T16:47:09  <wumpus> at some point I got to GetTransactionCost and stopped bothering
4102016-07-18T16:47:12  *** bsm117532 has quit IRC
4112016-07-18T16:47:23  <wumpus> (did I really need to change that to GetTransactionWeight?)
4122016-07-18T16:47:40  *** bsm117532 has joined #bitcoin-core-dev
4132016-07-18T16:47:42  <sdaftuar> i think yes
4142016-07-18T16:47:48  <sdaftuar> :)
4152016-07-18T16:48:01  <sdaftuar> anyway i will try to wrap up and see what it looks like
4162016-07-18T16:48:42  <sdaftuar> sipa: what is your preferred language for the new sigop metric, if you have one?
4172016-07-18T16:48:54  <sdaftuar> i guess the existing language, not in the BIP, is "sigop cost"
4182016-07-18T16:49:38  <luke-jr> can we just leave sigops alone? unlike cost/weight, at least sigops becomes a complete non-issue over time :x
4192016-07-18T16:49:44  <wumpus> I was almost afraid that people would complain the unit needs to be Kg after this change :-)
4202016-07-18T16:49:53  <luke-jr> wumpus: srsly?
4212016-07-18T16:50:01  *** netsin has joined #bitcoin-core-dev
4222016-07-18T16:50:23  <wumpus> no, not really, but GetTransactionWeight sounds weird to me too, though it's lots better than GetTransactionCost
4232016-07-18T16:50:38  <jtimon> wumpus: lol then maybe some would prefer the imperial system...
4242016-07-18T16:50:41  <sdaftuar> right, GetTransactionCost sounds like fee!
4252016-07-18T16:50:45  <luke-jr> "impact" may work as well.
4262016-07-18T16:50:50  <wumpus> agree sdaftuar
4272016-07-18T16:50:59  <btcdrak> jtimon: ack on imperial measurement.
4282016-07-18T16:51:00  *** pedrobranco has quit IRC
4292016-07-18T16:51:04  <luke-jr> jtimon: tonal !
4302016-07-18T16:53:24  <sipa> sdaftuar: i don't care strongly about sigops
4312016-07-18T16:53:41  *** Samdney has joined #bitcoin-core-dev
4322016-07-18T16:53:48  <sipa> and cost is inconsistent, as the other is not called "size cost" either
4332016-07-18T16:54:15  <sdaftuar> i think we could just add "sigops cost" as a term in the BIP, and be done with the issue
4342016-07-18T16:54:27  *** pedrobranco has joined #bitcoin-core-dev
4352016-07-18T16:54:53  <luke-jr> I think "BIP 141 sigops" would make for a reasonable compromise since it makes it easy to drop "BIP 141" in the future
4362016-07-18T16:55:38  <wumpus> there's also at least one other implementation of segwit that will have to be changed with the BIP141 change (the btcd implementation)
4372016-07-18T16:55:45  <Chris_Stewart_5> So weight is signifying the subsidy segwit txs receive right?
4382016-07-18T16:56:20  <luke-jr> Chris_Stewart_5: no, weight is the replacement for size limits
4392016-07-18T16:56:37  <Chris_Stewart_5> luke-jr: size limits of..?
4402016-07-18T16:56:43  <luke-jr> of prior versions of Bitcoin
4412016-07-18T16:56:58  <luke-jr> it used to be that each byte of the block counted as 1 byte toward a 1 MB limit
4422016-07-18T16:57:10  <Chris_Stewart_5> So this is modifying the Script program size, tx size, block size...?
4432016-07-18T16:57:12  <luke-jr> now we count bytes as different "weights" toward a 4,000,000 limit
4442016-07-18T16:57:17  <Chris_Stewart_5> oh, ok
4452016-07-18T16:57:42  <luke-jr> more expensive data affecting the UTXO set have a weight of 4 per byte
4462016-07-18T16:57:59  <luke-jr> less expensive data (witness scripts) have a weight of 1 per byte
4472016-07-18T16:59:47  *** Guyver2 has joined #bitcoin-core-dev
4482016-07-18T17:00:06  <wumpus> sdaftuar: this is how far I got: https://github.com/laanwj/bitcoin/commit/d259111512380e692188d0086d92451085b79c2f
4492016-07-18T17:00:16  <Chris_Stewart_5> luke-jr: At the risk of asking a stupid question, why is this needed? Shouldn't segwit txs literally be smaller than old txs? Why have this artificial multiplier
4502016-07-18T17:00:29  <sipa> Chris_Stewart_5: they're not smaller
4512016-07-18T17:00:34  <sipa> where did you get that idea
4522016-07-18T17:00:44  <sipa> segwit is a block size increase
4532016-07-18T17:00:59  <Chris_Stewart_5> When segwit txs are serialized and sent over the network they don't include scripts, making them smaller?
4542016-07-18T17:01:10  <sdaftuar> wumpus: heh, i'm at 19 files, 70 lines changed
4552016-07-18T17:01:21  <Chris_Stewart_5> You have to request the scripts, which is what fully validating nodes would do?
4562016-07-18T17:01:21  <luke-jr> Chris_Stewart_5: no, segwit txns are no smaller.
4572016-07-18T17:01:31  <luke-jr> they do include scripts
4582016-07-18T17:02:16  <jtimon> sdaftuar: s/GetTransactionCost/GetTransactionValidationCost/ ? or is that very disruptive too?
4592016-07-18T17:02:50  <sdaftuar> jtimon: i'm changing to GetTransactionWeight instead
4602016-07-18T17:03:01  <sdaftuar> that makes it consistent with max block weight
4612016-07-18T17:03:23  <Chris_Stewart_5> full scripts right? With witnesses included?
4622016-07-18T17:04:28  *** NicolasDorier has quit IRC
4632016-07-18T17:04:28  <jtimon> sdaftuar: but we're not changing max block weight are we?
4642016-07-18T17:05:06  *** Ylbam has quit IRC
4652016-07-18T17:05:06  *** jl2012 has quit IRC
4662016-07-18T17:05:11  <sdaftuar> jtimon: that's what's under discussion.  i'm preparing a PR for discussion
4672016-07-18T17:05:12  <jtimon> I was talking about fixing your concern without changing to max  block weight
4682016-07-18T17:05:36  <jtimon> ok, great
4692016-07-18T17:05:44  *** sipa has quit IRC
4702016-07-18T17:05:45  *** btcdrak has quit IRC
4712016-07-18T17:05:54  *** jyap has quit IRC
4722016-07-18T17:05:54  *** helo has quit IRC
4732016-07-18T17:06:05  <sdaftuar> ah yes in that event your function rename shouldn't be too disruptive
4742016-07-18T17:06:22  *** luke-jr has quit IRC
4752016-07-18T17:06:22  *** musalbas- has quit IRC
4762016-07-18T17:06:22  *** musalbas has quit IRC
4772016-07-18T17:06:22  *** michagogo has quit IRC
4782016-07-18T17:06:23  *** nsh has quit IRC
4792016-07-18T17:06:23  *** cfields has quit IRC
4802016-07-18T17:07:35  <instagibbs> Chris_Stewart_5, there is no support for grabbing only the scripts or no scripts(if you're upgraded ofc)
4812016-07-18T17:08:49  *** netsin has quit IRC
4822016-07-18T17:09:03  *** Ylbam has joined #bitcoin-core-dev
4832016-07-18T17:09:03  *** NicolasDorier has joined #bitcoin-core-dev
4842016-07-18T17:09:04  *** cfields has joined #bitcoin-core-dev
4852016-07-18T17:09:37  *** jl2012 has joined #bitcoin-core-dev
4862016-07-18T17:10:07  *** michagogo has joined #bitcoin-core-dev
4872016-07-18T17:10:35  *** netsin has joined #bitcoin-core-dev
4882016-07-18T17:10:40  *** sipa has joined #bitcoin-core-dev
4892016-07-18T17:10:58  *** musalbas has joined #bitcoin-core-dev
4902016-07-18T17:11:03  <sipa> what did i miss?
4912016-07-18T17:11:24  *** jyap has joined #bitcoin-core-dev
4922016-07-18T17:11:24  *** jyap has joined #bitcoin-core-dev
4932016-07-18T17:12:53  *** luke-jr has joined #bitcoin-core-dev
4942016-07-18T17:14:37  *** adamg has joined #bitcoin-core-dev
4952016-07-18T17:14:56  *** nsh has joined #bitcoin-core-dev
4962016-07-18T17:16:00  <Chris_Stewart_5> sipa: FOMO??? :-). Nothing much was said
4972016-07-18T17:16:26  <sipa> fomo?
4982016-07-18T17:17:24  <Chris_Stewart_5> fear of missing out, gotta catch up on your contemporary culture
4992016-07-18T17:17:29  <sipa> ah
5002016-07-18T17:18:10  *** musalbas- has joined #bitcoin-core-dev
5012016-07-18T17:19:10  *** pedrobranco has quit IRC
5022016-07-18T17:19:37  *** pedrobranco has joined #bitcoin-core-dev
5032016-07-18T17:22:49  *** btcdrak has joined #bitcoin-core-dev
5042016-07-18T17:24:33  *** pedrobranco has quit IRC
5052016-07-18T17:32:21  *** helo has joined #bitcoin-core-dev
5062016-07-18T17:46:39  <GitHub36> [bitcoin] sdaftuar opened pull request #8363: Rename "block cost" to "block weight" (master...cost-to-weight) https://github.com/bitcoin/bitcoin/pull/8363
5072016-07-18T17:46:40  *** midnightmagic has quit IRC
5082016-07-18T17:47:31  *** Sosumi has quit IRC
5092016-07-18T17:50:08  <GitHub50> [bitcoin] f139975 opened pull request #8364: Fix counting of sigops cost in mempool check (master...fix-mempool-sigops) https://github.com/bitcoin/bitcoin/pull/8364
5102016-07-18T17:55:56  <arubi> sipa, and what if a miner does it?  wrt ^
5112016-07-18T17:56:07  *** midnightmagic has joined #bitcoin-core-dev
5122016-07-18T17:56:35  <sipa> arubi: what if a miner does what?
5132016-07-18T17:57:53  <arubi> well, I guess I'm asking if creating large legacy sigops blocks will be easy for a miner in case the sigops limit is high
5142016-07-18T17:58:13  <sipa> i don't understand
5152016-07-18T17:58:38  <sipa> arubi: the problem that #7081 fixed was that the mining code produces very suboptimal blocks when there are high-legacy-sigops transactions in the mempool
5162016-07-18T17:58:48  <sipa> #7081 fixed it by refusing transactions that have high sigops but low size
5172016-07-18T17:59:03  <sipa> i think the correct solution is just to treat those transactions as if they had the corresponding size
5182016-07-18T17:59:03  *** Chris_Stewart_5 has quit IRC
5192016-07-18T18:00:40  <arubi> sipa, I think I understand.  the reason I'm interested is because I've experienced this on segnet4.  broadcasting bare multisig txs was impossible without setting bytespersigop=1
5202016-07-18T18:01:04  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5212016-07-18T18:01:20  *** aalex has joined #bitcoin-core-dev
5222016-07-18T18:02:14  *** Sosumi has joined #bitcoin-core-dev
5232016-07-18T18:02:44  <arubi> it was confusing, something like a 1-of-16 would go through, but not a "sane" 1-of-2 or 2-3,  iirc.  I eventually just set bytesper..=1 and forgot about it
5242016-07-18T18:03:38  <arubi> and you mentioned a vulnerability (which you explained), so.. hence the first question :)
5252016-07-18T18:05:56  *** netsin has quit IRC
5262016-07-18T18:06:34  *** netsin has joined #bitcoin-core-dev
5272016-07-18T18:10:08  *** netsin has quit IRC
5282016-07-18T18:10:22  *** netsin has joined #bitcoin-core-dev
5292016-07-18T18:11:51  *** kadoban has joined #bitcoin-core-dev
5302016-07-18T18:15:51  *** cryptapus_afk has quit IRC
5312016-07-18T18:15:56  *** cryptapus has joined #bitcoin-core-dev
5322016-07-18T18:15:57  *** cryptapus is now known as cryptapus_afk
5332016-07-18T18:16:02  *** teward has quit IRC
5342016-07-18T18:22:03  *** netsin has quit IRC
5352016-07-18T18:23:31  *** teward has joined #bitcoin-core-dev
5362016-07-18T18:37:34  *** cryptapus_afk has quit IRC
5372016-07-18T18:41:07  *** cryptapus has joined #bitcoin-core-dev
5382016-07-18T18:41:07  *** cryptapus has joined #bitcoin-core-dev
5392016-07-18T18:42:44  <BlueMatt> jtimon: its an obvious change (current time is context by most definitions) which removes one more #include for the single CheckBlock call in blockencodings.cpp
5402016-07-18T18:42:50  <BlueMatt> (that one line adds like 4 deps, at least)
5412016-07-18T18:45:23  <sipa> longer term i think CheckBlock and ContextualCheckBlock can probably be merged, as we never validate a block anymore without having its context
5422016-07-18T18:45:56  <sipa> though some parts of validation need to be factored out... for consistency checking and the verification compact blocks need
5432016-07-18T19:01:30  <GitHub89> [bitcoin] sipa opened pull request #8365: Treat high-sigop transactions as larger rather than rejecting them (master...unifysigopcost) https://github.com/bitcoin/bitcoin/pull/8365
5442016-07-18T19:05:13  *** MarcoFalke has left #bitcoin-core-dev
5452016-07-18T19:08:31  *** Chris_Stewart_5 has quit IRC
5462016-07-18T19:11:44  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5472016-07-18T19:13:01  <BlueMatt> sipa: yea, I mean not a bad idea, indeed
5482016-07-18T19:13:13  <BlueMatt> but, yea, need to pull out the mutation-possible checks
5492016-07-18T19:24:11  <jtimon> BlueMatt: well, yeah, i guess strictly is context, but any caller can have time. In contrast, not all callers may have access to the the block index. If we were to expose checkblockheader and contextualcheckblockheader in libconsensus separately maybe some SPV callers use checkblockheader but not contextualblockheader...anyway, I guess we can move it back later when we're talking about exposing things
5502016-07-18T19:24:43  <jtimon> maybe exposing verifyheader (calling both) is enough and we don't care where the check is for this
5512016-07-18T19:30:18  <BlueMatt> jtimon: I mean the only thing that the compact blocks stuff cares about is the IsCorruptionPossible() checks
5522016-07-18T19:30:54  <BlueMatt> jtimon: those need to be factored out to simplify the compact block code anyway...everything else, whatever
5532016-07-18T19:33:58  <jtimon> anyway, not important at the moment I think, I was just surprised to see it moved
5542016-07-18T19:40:16  *** Chris_Stewart_5 has quit IRC
5552016-07-18T19:49:59  *** spudowiar has joined #bitcoin-core-dev
5562016-07-18T20:01:25  *** anu1 has joined #bitcoin-core-dev
5572016-07-18T20:04:42  *** anu0 has quit IRC
5582016-07-18T20:08:12  *** go1111111 has quit IRC
5592016-07-18T20:08:20  *** LeMiner has quit IRC
5602016-07-18T20:10:24  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5612016-07-18T20:12:26  *** LeMiner has joined #bitcoin-core-dev
5622016-07-18T20:19:42  *** achow101 has quit IRC
5632016-07-18T20:20:17  *** go1111111 has joined #bitcoin-core-dev
5642016-07-18T20:35:54  *** achow101 has joined #bitcoin-core-dev
5652016-07-18T20:42:41  *** droark has joined #bitcoin-core-dev
5662016-07-18T20:45:35  *** nibor has joined #bitcoin-core-dev
5672016-07-18T20:54:00  <GitHub175> [bitcoin] jonasschnelli opened pull request #8366: [Wallet] Ensure <0.13 clients can't open HD wallets (0.13...2016/07/hd_minversion) https://github.com/bitcoin/bitcoin/pull/8366
5682016-07-18T20:55:20  <GitHub57> [bitcoin] jonasschnelli closed pull request #8343: [Wallet] Ensure <0.13 clients can't open HD wallets (master...2016/07/hd_minversion) https://github.com/bitcoin/bitcoin/pull/8343
5692016-07-18T20:55:41  *** go1111111 has quit IRC
5702016-07-18T20:58:22  <GitHub83> [bitcoin] jonasschnelli opened pull request #8367: [Wallet] Ensure <0.13 clients can't open HD wallets (master...2016/07/hd_minversion_014) https://github.com/bitcoin/bitcoin/pull/8367
5712016-07-18T21:08:02  *** go1111111 has joined #bitcoin-core-dev
5722016-07-18T21:13:32  *** spudowiar has quit IRC
5732016-07-18T21:13:50  *** spudowiar has joined #bitcoin-core-dev
5742016-07-18T22:01:17  *** cryptapus is now known as cryptapus_afk
5752016-07-18T22:01:58  *** spudowiar has quit IRC
5762016-07-18T22:16:05  *** go1111111 has quit IRC
5772016-07-18T22:24:10  *** Samdney has left #bitcoin-core-dev
5782016-07-18T22:25:02  *** cryptapus_ has joined #bitcoin-core-dev
5792016-07-18T22:26:01  *** cryptapus_ is now known as cryptapus
5802016-07-18T22:28:37  *** go1111111 has joined #bitcoin-core-dev
5812016-07-18T22:28:57  *** cryptapus has quit IRC
5822016-07-18T22:32:34  *** cryptapus has joined #bitcoin-core-dev
5832016-07-18T22:32:34  *** cryptapus has joined #bitcoin-core-dev
5842016-07-18T22:33:41  *** supasonic has joined #bitcoin-core-dev
5852016-07-18T22:37:50  *** PRab has joined #bitcoin-core-dev
5862016-07-18T22:37:51  *** cryptapus has quit IRC
5872016-07-18T22:54:34  *** ebfull has quit IRC
5882016-07-18T22:57:57  *** belcher has joined #bitcoin-core-dev
5892016-07-18T23:29:40  *** NicLin has joined #bitcoin-core-dev
5902016-07-18T23:44:35  *** NicLin has quit IRC
5912016-07-18T23:56:08  *** Guyver2 has quit IRC