1 2016-07-18 01:49:57	0|GitHub30|[13bitcoin] 15Tyler-Hardin closed pull request #8349: Qt: Clearer warning about being out of sync (06master...06issue8060) 02https://github.com/bitcoin/bitcoin/pull/8349
  2 2016-07-18 02:28:57	0|ebfull|luke-jr: we should team up to coordinate integration/UX strategy for #7601 and #7534
  3 2016-07-18 03:20:04	0|GitHub157|[13bitcoin] 15maiiz closed pull request #8336: TX fees and policy: fix relaypriority calculation error Issues #8334 (06master...06issues-8334) 02https://github.com/bitcoin/bitcoin/pull/8336
  4 2016-07-18 05:43:36	0|wumpus|phantomcircuit: not yet
  5 2016-07-18 05:46:38	0|GitHub121|[13bitcoin] 15laanwj pushed 3 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/bc94b8748782...37303934fe8f
  6 2016-07-18 05:46:39	0|GitHub121|13bitcoin/06master 1496fa953 15Suhas Daftuar: Improve handling of unconnecting headers...
  7 2016-07-18 05:46:39	0|GitHub121|13bitcoin/06master 14e91cf4b 15Suhas Daftuar: Add test for handling of unconnecting headers
  8 2016-07-18 05:46:40	0|GitHub121|13bitcoin/06master 143730393 15Wladimir J. van der Laan: Merge #8305: Improve handling of unconnecting headers...
  9 2016-07-18 05:46:48	0|GitHub135|[13bitcoin] 15laanwj closed pull request #8305: Improve handling of unconnecting headers (06master...06fix-relay-2hr-rule) 02https://github.com/bitcoin/bitcoin/pull/8305
 10 2016-07-18 05:58:58	0|GitHub1|[13bitcoin] 15laanwj pushed 7 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/37303934fe8f...238300b39894
 11 2016-07-18 05:58:59	0|GitHub1|13bitcoin/06master 145b95dd2 15Jonas Schnelli: [Wallet] extend CKeyMetadata with HD keypath
 12 2016-07-18 05:58:59	0|GitHub1|13bitcoin/06master 14b1c7b24 15Jonas Schnelli: [Wallet] report optional HDKeypath/HDMasterKeyId in validateaddress
 13 2016-07-18 05:59:00	0|GitHub1|13bitcoin/06master 14986c223 15Jonas Schnelli: [Wallet] print hd masterkeyid in getwalletinfo
 14 2016-07-18 05:59:11	0|GitHub6|[13bitcoin] 15laanwj closed pull request #8323: Add HD keypath to CKeyMetadata, report metadata in validateaddress (06master...062016/07/hd_013) 02https://github.com/bitcoin/bitcoin/pull/8323
 15 2016-07-18 06:00:34	0|wumpus|jonasschnelli: should #8308 be a blocker for the 0.13 rc1?
 16 2016-07-18 06:03:46	0|wumpus|(it's labeled milestone 0.13, but #8206 is not)
 17 2016-07-18 06:10:52	0|GitHub68|[13bitcoin] 15laanwj opened pull request #8354: mining: Rename `-blockmaxcost` to `-blockmaxweight` (06master...062016_07_block_weight) 02https://github.com/bitcoin/bitcoin/pull/8354
 18 2016-07-18 06:24:06	0|GitHub81|[13bitcoin] 15laanwj pushed 6 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/238300b39894...f5660d381a37
 19 2016-07-18 06:24:07	0|GitHub81|13bitcoin/06master 146dd4bc2 15Suhas Daftuar: Exclude witness transactions in addPackageTxs() pre-segwit activation
 20 2016-07-18 06:24:07	0|GitHub81|13bitcoin/06master 14f15c2cd 15Suhas Daftuar: CreateNewBlock: add support for size-accounting to addPackageTxs...
 21 2016-07-18 06:24:08	0|GitHub81|13bitcoin/06master 14d2e46e1 15Suhas Daftuar: Remove addScoreTxs()
 22 2016-07-18 06:24:13	0|GitHub37|[13bitcoin] 15laanwj closed pull request #8295: Mining-related fixups for 0.13.0 (06master...06cnb-segwit) 02https://github.com/bitcoin/bitcoin/pull/8295
 23 2016-07-18 06:37:57	0|GitHub46|[13bitcoin] 15maiiz opened pull request #8355: [Wallet]fix relaypriority calculation error Issues #8334 (06master...06issues-8334) 02https://github.com/bitcoin/bitcoin/pull/8355
 24 2016-07-18 06:42:17	0|wumpus|am I missing some context re: #8349? did someone get into a fight with the guy?
 25 2016-07-18 06:43:36	0|paveljanik|wumpus, I do not think so.
 26 2016-07-18 06:44:31	0|wumpus|I was thinking it was awesome that someone addressed #8334, then at the same moment he closed the pull and deleted the branch
 27 2016-07-18 06:44:54	0|wumpus|addressed #8060, sorry
 28 2016-07-18 06:48:18	0|paveljanik|strange, yes.
 29 2016-07-18 06:48:48	0|GitHub94|[13bitcoin] 15maiiz closed pull request #8355: [Wallet]fix relaypriority calculation error Issues #8334 (06master...06issues-8334) 02https://github.com/bitcoin/bitcoin/pull/8355
 30 2016-07-18 06:49:27	0|wumpus|now maiiz is doing the same in #8355, either this is a github issue or people are trolling us...
 31 2016-07-18 06:51:52	0|paveljanik|maiiz probably has a problem with github web interface.
 32 2016-07-18 07:00:19	0|GitHub190|[13bitcoin] 15NicolasDorier opened pull request #8356: Wallet: Minimum output value depends on fee instead of minTxRelayFee (06master...06wallet-min-output) 02https://github.com/bitcoin/bitcoin/pull/8356
 33 2016-07-18 07:04:58	0|GitHub127|[13bitcoin] 15maiiz opened pull request #8357: Update coins.cpp (06master...06maiiz-patch-1) 02https://github.com/bitcoin/bitcoin/pull/8357
 34 2016-07-18 07:05:08	0|GitHub5|13bitcoin/06master 14d6dc1bc 15Krzysztof Jurewicz: Fix 0.12 release notes on block relaying...
 35 2016-07-18 07:05:08	0|GitHub5|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/f5660d381a37...8cb288a6b37d
 36 2016-07-18 07:05:09	0|GitHub5|13bitcoin/06master 148cb288a 15Wladimir J. van der Laan: Merge #8320: Fix 0.12 release notes on block relaying...
 37 2016-07-18 07:05:13	0|GitHub49|[13bitcoin] 15laanwj closed pull request #8320: Fix 0.12 release notes on block relaying (06master...060.12-release-notes-block-relaying) 02https://github.com/bitcoin/bitcoin/pull/8320
 38 2016-07-18 07:10:40	0|GitHub20|[13bitcoin] 15MarcoFalke closed pull request #7615: [WIP] [wallet] Couple minimum change with minimum relay fee (06master...06Mf1602-walletMinChange) 02https://github.com/bitcoin/bitcoin/pull/7615
 39 2016-07-18 07:18:52	0|jonasschnelli|wumpus: no. 8308 is more or less a feature and can go into 0.14
 40 2016-07-18 07:19:18	0|jonasschnelli|IMO it's unclear if "importwallet" should import the HD master seed and set it according to the importet wallet
 41 2016-07-18 07:19:33	0|wumpus|thanks, I agree
 42 2016-07-18 07:19:42	0|jonasschnelli|*import* somehow implies that "old stuff is unchanged"
 43 2016-07-18 07:20:13	0|jonasschnelli|But its good to have the extended master key "xpriv" visible in the dump... but as said. can go into 0.14
 44 2016-07-18 07:20:36	0|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
 45 2016-07-18 07:21:01	0|wumpus|the only time you would want that is if you intend  the imported wallet to replace your current one
 46 2016-07-18 07:21:03	0|wumpus|removing the 0.13 milestone there
 47 2016-07-18 07:21:14	0|jonasschnelli|yes. Thanks.
 48 2016-07-18 07:21:18	0|jonasschnelli|Re https://github.com/bitcoin/bitcoin/pull/8343/files/51a4ee889e3d317fb51623701f06919adf0ee267#r71106179
 49 2016-07-18 07:21:37	0|jonasschnelli|wumpus: I don't think it's possible without non-Client-Versions
 50 2016-07-18 07:21:51	0|jonasschnelli|The nWalletMinVersion is tied to the clientversion
 51 2016-07-18 07:22:24	0|wumpus|we did a similar thing for network at some point, the P2P version used to be coupled to the client version as well
 52 2016-07-18 07:22:52	0|wumpus|at some point we created a dedicated network version constant, which is bumped on non-compatible network changes
 53 2016-07-18 07:23:03	0|jonasschnelli|wumpus: Yes. We could do this. But detecting 0.12 (and make it fail on 0.12) requires to stick to the clientversion
 54 2016-07-18 07:23:18	0|wumpus|using the client version for anything else but reporting forces arbitrary release process constraints on versioning certain behavior
 55 2016-07-18 07:23:32	0|wumpus|yes, I agree, you'd leave the old versions the same
 56 2016-07-18 07:23:57	0|jonasschnelli|problematic part: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/walletdb.cpp#L637
 57 2016-07-18 07:24:13	0|wumpus|this would be a change going forward, for the future, it can't be done retrospectively for versions that are already released :)
 58 2016-07-18 07:24:22	0|wumpus|in any case no hurry
 59 2016-07-18 07:25:10	0|sipa|wumpus: i guess it can be replaced with a set of strings
 60 2016-07-18 07:25:22	0|jonasschnelli|Yes. We should slowly decouple it from CLIENT_VERSION
 61 2016-07-18 07:25:27	0|sipa|wumpus: denoting features that the wallet uses
 62 2016-07-18 07:25:34	0|jonasschnelli|sipa: you mean set of string about what features it supports?
 63 2016-07-18 07:25:37	0|jonasschnelli|ok.
 64 2016-07-18 07:25:46	0|wumpus|sipa: and then exit if a non-supported feature is used, yes
 65 2016-07-18 07:25:48	0|jonasschnelli|Flags? Bitmask?
 66 2016-07-18 07:26:05	0|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
 67 2016-07-18 07:26:18	0|wumpus|e.g. generating errors like 'this wallet uses BIP32 which is not supported in this version'
 68 2016-07-18 07:26:28	0|jonasschnelli|ah.. fair enought
 69 2016-07-18 07:26:47	0|jonasschnelli|We could do this once we switch over to a different database format (logdb)
 70 2016-07-18 07:26:48	0|wumpus|with bitmask you can only report the flag number, and there's no real need to be very compact here
 71 2016-07-18 07:26:54	0|jonasschnelli|(which is overdue since years)
 72 2016-07-18 07:27:00	0|wumpus|(it'd be something stored only once in the wallet)
 73 2016-07-18 07:29:57	0|sipa|wumpus: i like the ext2/3/4 compatibility system
 74 2016-07-18 07:30:12	0|sipa|wumpus: with 3 sets of strings/flags
 75 2016-07-18 07:31:06	0|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"
 76 2016-07-18 07:33:40	0|jonasschnelli|sipa: Indeed. This would be good.
 77 2016-07-18 07:34:18	0|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.
 78 2016-07-18 07:36:40	0|sipa|no, you can just see the switch to such a new system as a 'feature' in the old compatibility system
 79 2016-07-18 08:05:28	0|jonasschnelli|sipa: Yes. Indeed. Possible migration path.
 80 2016-07-18 08:43:41	0|wumpus|bah, changing all occurences of 'cost' to 'weight' is a huge change
 81 2016-07-18 08:44:33	0|wumpus|I'm having second thoughts about it
 82 2016-07-18 08:45:26	0|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
 83 2016-07-18 08:49:15	0|wumpus|and don't really want to block the 0.13 branch on this
 84 2016-07-18 08:49:58	0|GitHub77|[13bitcoin] 15laanwj closed pull request #8354: mining: Rename `-blockmaxcost` to `-blockmaxweight` (06master...062016_07_block_weight) 02https://github.com/bitcoin/bitcoin/pull/8354
 85 2016-07-18 08:51:23	0|sipa|so you want to delay the change until 0.13 is branched off?
 86 2016-07-18 08:51:37	0|sipa|or reconsider entirely?
 87 2016-07-18 08:51:49	0|wumpus|I don't think I want to do it anymore
 88 2016-07-18 08:52:48	0|MarcoFalke|What about only changing -help and rpc calls?
 89 2016-07-18 08:52:56	0|MarcoFalke|And then the nasty code cleaup for 0.14?
 90 2016-07-18 08:53:09	0|wumpus|I don't think it's worth it
 91 2016-07-18 08:53:37	0|wumpus|should have paid more attention to this during the BIP draft
 92 2016-07-18 08:54:39	0|wumpus|maybe just change the help message to "Set maximum BIP141 block cost"
 93 2016-07-18 08:54:59	0|wumpus|then everyone can look it up if they want
 94 2016-07-18 08:55:31	0|wumpus|changing the BIP now because of a word impacts all other implementations too
 95 2016-07-18 08:57:02	0|GitHub191|[13bitcoin] 15MarcoFalke opened pull request #8358: [doc] gbuild: Set memory explicitly (default is too low) (06master...06Mf1607-docBuild) 02https://github.com/bitcoin/bitcoin/pull/8358
 96 2016-07-18 08:57:38	0|GitHub7|[13bitcoin] 15laanwj opened pull request #8359: mining: Improve `-blockmaxcost` help message (06master...062016_07_blockmaxcost_doc) 02https://github.com/bitcoin/bitcoin/pull/8359
 97 2016-07-18 10:06:13	0|GitHub67|13bitcoin/06master 148cef5bd 15Wladimir J. van der Laan: mining: Improve `-blockmaxcost` help message...
 98 2016-07-18 10:06:13	0|GitHub67|[13bitcoin] 15laanwj pushed 2 new commits to 06master: 02https://github.com/bitcoin/bitcoin/compare/8cb288a6b37d...03c56f62c2fd
 99 2016-07-18 10:06:14	0|GitHub67|13bitcoin/06master 1403c56f6 15Wladimir J. van der Laan: Merge #8359: mining: Improve `-blockmaxcost` help message...
100 2016-07-18 10:06:23	0|GitHub184|[13bitcoin] 15laanwj closed pull request #8359: mining: Improve `-blockmaxcost` help message (06master...062016_07_blockmaxcost_doc) 02https://github.com/bitcoin/bitcoin/pull/8359
101 2016-07-18 10:13:54	0|GitHub83|13bitcoin/06master 14e4382fb 15Wladimir J. van der Laan: qt: periodic translations update
102 2016-07-18 10:13:54	0|GitHub83|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02https://github.com/bitcoin/bitcoin/commit/e4382fbef56a0e04b0ed834e8b3a3a16f81db149
103 2016-07-18 10:22:40	0|GitHub85|13bitcoin/06master 146c0336c 15Wladimir J. van der Laan: build: bump version to 0.13.99...
104 2016-07-18 10:22:40	0|GitHub85|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02https://github.com/bitcoin/bitcoin/commit/6c0336c7723da274c8312b82ed2a138f5d57158f
105 2016-07-18 10:22:50	0|wumpus|0.13 branch was created
106 2016-07-18 10:29:43	0|sipa|\o/
107 2016-07-18 11:05:30	0|btcdrak|which tickets are blocking RC1?
108 2016-07-18 11:06:46	0|wumpus|#8343 stilln eeds in
109 2016-07-18 11:07:06	0|wumpus|(but could only be done after the version bump, because of wallet versioning constraints)
110 2016-07-18 11:09:19	0|btcdrak|now the branching has happened, are we clear for a bit of libconsensus refactoring work?
111 2016-07-18 11:09:37	0|btcdrak|(in master obviously)
112 2016-07-18 11:15:51	0|wumpus|I think so...
113 2016-07-18 11:21:34	0|wumpus|for 0.13 there's still plenty of work to do for the release notes: https://github.com/bitcoin/bitcoin/issues/7678
114 2016-07-18 12:01:37	0|GitHub24|13bitcoin/06master 145e3557b 15Wladimir J. van der Laan: doc: Clean out release notes...
115 2016-07-18 12:01:37	0|GitHub24|[13bitcoin] 15laanwj pushed 1 new commit to 06master: 02https://github.com/bitcoin/bitcoin/commit/5e3557b8e36308a27dbeb528569abe638c4d01dd
116 2016-07-18 12:11:52	0|GitHub181|13bitcoin/060.13 143726910 15Wladimir J. van der Laan: build: Release notes update...
117 2016-07-18 12:11:52	0|GitHub181|[13bitcoin] 15laanwj pushed 1 new commit to 060.13: 02https://github.com/bitcoin/bitcoin/commit/37269105c8817a2922410ec17d976263cd589987
118 2016-07-18 13:23:57	0|GitHub75|[13bitcoin] 15laanwj opened pull request #8360: doc: Add a few items to release notes (060.13...062016_07_release_notes) 02https://github.com/bitcoin/bitcoin/pull/8360
119 2016-07-18 13:28:06	0|sipa|wumpus: working on a PR with repease notes about the relay/p2p changes
120 2016-07-18 13:28:29	0|wumpus|sipa: awesome
121 2016-07-18 13:28:37	0|sipa|only overlap with yours is the bloom filter requirement for mempool
122 2016-07-18 13:29:05	0|wumpus|ok
123 2016-07-18 14:03:42	0|GitHub87|[13bitcoin] 15sipa opened pull request #8361: Some 0.13 release notes about p2p changes (060.13...06relnotes-0.13) 02https://github.com/bitcoin/bitcoin/pull/8361
124 2016-07-18 14:40:10	0|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..
125 2016-07-18 14:40:41	0|jonasschnelli|I expected that the main logic will get all headers first and pass them through NotifyHeaderTip() before actually downloading blocks...
126 2016-07-18 14:42:49	0|sipa|yes, it will
127 2016-07-18 14:43:00	0|sipa|it always notifies with the best known header at the time of calling
128 2016-07-18 14:43:17	0|jtimon|GetSpendHeight() ? tip->nHeight + 1 ? pindexPrev == NULL ? 0 : pindexPrev->nHeight + 1 ?
129 2016-07-18 14:46:53	0|jonasschnelli|sipa: okay. Let me check again....
130 2016-07-18 14:49:55	0|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?
131 2016-07-18 14:51:01	0|sipa|jonasschnelli: i cannot parse your sentence
132 2016-07-18 14:51:17	0|jonasschnelli|okay.. I'll try to explain different.
133 2016-07-18 14:52:05	0|jonasschnelli|1.) Im connected to a node with height 421290, I'm currently at 421100
134 2016-07-18 14:52:34	0|jonasschnelli|2.) NotifyHeaderTip gives me a header somewhere at height 421150 (50 headers in advance)
135 2016-07-18 14:52:47	0|jonasschnelli|3.) Then I'll get the signals for the blocks till 421150
136 2016-07-18 14:52:55	0|sipa|sounds correct so far
137 2016-07-18 14:53:10	0|jonasschnelli|Is there no way to get signal with "the best known header" (from the remote peers)?
138 2016-07-18 14:53:19	0|jonasschnelli|(or the best known height)
139 2016-07-18 14:53:28	0|jonasschnelli|I want to work on the UI progress
140 2016-07-18 14:53:29	0|sipa|you don't know the peer's best header until we have it as well
141 2016-07-18 14:53:51	0|jonasschnelli|sipa: and main does not load all headers first,.. only a bunch of them, then the blocks?
142 2016-07-18 14:54:14	0|sipa|exactly what do you want to do?
143 2016-07-18 14:54:30	0|jonasschnelli|I'd like to show the "remaning blocks to process" untill we are in sync
144 2016-07-18 14:54:56	0|sipa|show the difference between the height of the last notifybesttip and the last notifybestheader
145 2016-07-18 14:54:58	0|jonasschnelli|So... I'd like to get signaled with "all" the headers first
146 2016-07-18 14:55:26	0|sipa|that's what notifybestheader does...
147 2016-07-18 14:56:00	0|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.
148 2016-07-18 14:56:34	0|sipa|if it's behind a lot the headers should progress much much faster than the blocks
149 2016-07-18 14:56:44	0|sipa|it usually takes only a minute or two to learn about all headers
150 2016-07-18 14:57:13	0|sipa|ah!
151 2016-07-18 14:57:20	0|sipa|notifybestheader is not called during IBD
152 2016-07-18 14:57:45	0|sipa|oh, no, it is
153 2016-07-18 14:57:50	0|sipa|but with a false parameter
154 2016-07-18 14:57:51	0|jonasschnelli|ah... IBD is also true if I start bitcoin-core with 200 blocks behind. Right?
155 2016-07-18 14:58:02	0|sipa|yes
156 2016-07-18 14:58:10	0|sipa|but it is always called
157 2016-07-18 14:58:18	0|jonasschnelli|Hmm.. let me debug more deep
158 2016-07-18 14:58:35	0|sipa|i'm surprised it only increases 50
159 2016-07-18 14:58:43	0|sipa|headers should increase by 2000 at a time
160 2016-07-18 15:00:12	0|jonasschnelli|Maybe I'm missing the first signal because of my implementation... sipa: could it be that i get older headers in later NotifyHeaderTip()?
161 2016-07-18 15:01:51	0|sipa|at the time of the notify, what you see is always the best known header
162 2016-07-18 15:06:33	0|jonasschnelli|RPC getblockchaininfo report a newer height that I get passed over NotifyHeaderTip()
163 2016-07-18 15:09:06	0|sipa|during IBD that's possible
164 2016-07-18 15:09:12	0|sipa|oh, wait, no
165 2016-07-18 15:09:31	0|sipa|are you not filtering out IBD NotifyHeaderTips somewhere?
166 2016-07-18 15:10:25	0|jonasschnelli|I'm hooking into static void BlockTipChanged(ClientModel *clientmodel, bool initialSync, const CBlockIndex *pIndex, bool fHeader) (clientmodel.cpp)
167 2016-07-18 15:11:05	0|jonasschnelli|Maybe initially I need to get the height from pindexBestHeader?
168 2016-07-18 15:11:24	0|sipa|where else?
169 2016-07-18 15:11:42	0|sipa|ah, pindex->nHeight should work
170 2016-07-18 15:11:44	0|sipa|can i see the code?
171 2016-07-18 15:12:27	0|jonasschnelli|it's highly WIP... but let me push it.
172 2016-07-18 15:13:21	0|jonasschnelli|sipa: https://github.com/jonasschnelli/bitcoin/tree/2016/07/UI-out-of-sync
173 2016-07-18 15:13:34	0|jonasschnelli|use https://github.com/bitcoin/bitcoin/compare/master...jonasschnelli:2016/07/UI-out-of-sync?expand=1
174 2016-07-18 15:14:29	0|jonasschnelli|It works much better if i initially call pindexBestHeader->nHeight; then only "accept" header height over NotifyHeaderTips() if they are >
175 2016-07-18 15:14:47	0|jonasschnelli|Although not sure if this works for reorgs
176 2016-07-18 15:15:19	0|sipa|i'm very confused
177 2016-07-18 15:15:34	0|sipa|where in that code you're showing me do you hook into the notification?
178 2016-07-18 15:16:57	0|sipa|ah, you're adding to setNumBlocks
179 2016-07-18 15:17:02	0|sipa|that's only called once every 250ms
180 2016-07-18 15:17:40	0|jonasschnelli|ahh.. that could be the problem
181 2016-07-18 15:18:18	0|sipa|the header reported through NotifyBestHeader should always be of increasing height
182 2016-07-18 15:18:30	0|sipa|unless there is a very deep reorg to a lower height
183 2016-07-18 15:18:36	0|sipa|but that's extremely unlikely
184 2016-07-18 15:18:42	0|jonasschnelli|Argh.. yes. There is something like: if (!initialSync || now - nLastUpdateNotification > MODEL_UPDATE_DELAY) {
185 2016-07-18 15:18:57	0|jonasschnelli|Thanks sipa!
186 2016-07-18 15:20:10	0|jonasschnelli|we could pass through the fHeader=true  signal always...
187 2016-07-18 15:21:53	0|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 :/
188 2016-07-18 15:23:47	0|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
189 2016-07-18 15:24:02	0|sipa|though i didn't try it myself, so i may be missing things
190 2016-07-18 15:24:43	0|luke-jr|sipa: well, at least changing it in GBT will be annoying once cost is released
191 2016-07-18 15:25:40	0|sipa|ah, GBT
192 2016-07-18 15:25:50	0|sipa|i hadn't considered that we'd change things there as well
193 2016-07-18 15:25:52	0|sipa|but i guess, yes
194 2016-07-18 15:26:20	0|luke-jr|I guess we don't *have* to, but it will just be confusing if GBT was the odd thing out
195 2016-07-18 15:26:39	0|sipa|agree
196 2016-07-18 15:30:54	0|jtimon|yay branch 0.13 forked !
197 2016-07-18 15:39:03	0|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
198 2016-07-18 15:39:28	0|sdaftuar|we didn't talk about it last week, but is "sigops cost" a term we want to keep?
199 2016-07-18 15:39:30	0|luke-jr|sdaftuar: it was renamed to just "sigops"; I'm surprised GBT ever mentioned it O.o
200 2016-07-18 15:39:54	0|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"
201 2016-07-18 15:40:23	0|luke-jr|oh, in Core; that's just a bug then IMO
202 2016-07-18 15:41:06	0|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
203 2016-07-18 15:41:13	0|sdaftuar|but that seems clunky!
204 2016-07-18 15:41:15	0|luke-jr|sdaftuar: why?
205 2016-07-18 15:41:23	0|luke-jr|sigops are just counted differently, not redefined
206 2016-07-18 15:41:35	0|sdaftuar|it's a different unit now
207 2016-07-18 15:41:38	0|luke-jr|P2SH counted them differently without a rename too
208 2016-07-18 15:41:50	0|luke-jr|the old counting ceases to be relevant at the fork
209 2016-07-18 15:42:10	0|sdaftuar|p2sh didn't change the units/scale of sigops for non-p2sh transactions though
210 2016-07-18 15:42:31	0|luke-jr|…
211 2016-07-18 15:42:35	0|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
212 2016-07-18 15:42:42	0|luke-jr|so you want to rename it every softfork that affects how it's counted?
213 2016-07-18 15:42:52	0|luke-jr|what's the point?
214 2016-07-18 16:04:57	0|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?
215 2016-07-18 16:05:06	0|sdaftuar|if not then fine, i agree this is all pointless
216 2016-07-18 16:05:40	0|luke-jr|sdaftuar: a GBT caller cannot know the sigop counting; scale is not different from any other countign changes
217 2016-07-18 16:10:56	0|sipa|sdaftuar, luke-jr: imho we should change the name when the unit's scale changes
218 2016-07-18 16:11:10	0|luke-jr|sigh.
219 2016-07-18 16:11:34	0|sipa|luke-jr: in p2sh, users of non-p2sh transactions would not be affected by the new counting
220 2016-07-18 16:12:00	0|sipa|here, everyone is affected - assuming that the old unit has the same meaning could lead to accidents
221 2016-07-18 16:12:11	0|luke-jr|how?
222 2016-07-18 16:12:24	0|sipa|that's why transaction's "size" is redefined in a backward-compatible way (and not the scaling)
223 2016-07-18 16:12:39	0|sipa|i agree that for sigops it is unlikely to matter
224 2016-07-18 16:12:56	0|sipa|but in general, it is a good practice to rename things when their meaning changes
225 2016-07-18 16:13:16	0|luke-jr|IMO the meaning is essentially the same.
226 2016-07-18 16:13:30	0|luke-jr|it's an arbitrary consensus-critical counting toward an arbitrary limit.
227 2016-07-18 16:13:35	0|sipa|if someone were to charge based on #sigops, it is most definitely not the se
228 2016-07-18 16:13:40	0|sipa|*same
229 2016-07-18 16:14:46	0|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)?
230 2016-07-18 16:15:27	0|sipa|i was fine with not renaming in GBT, but instead giving the consensus limit along with it
231 2016-07-18 16:15:32	0|luke-jr|yes, because size is something they can calculate external to the consensus system
232 2016-07-18 16:15:52	0|luke-jr|the same is not true of sigops - you can't calculate it independently from the UTXO set
233 2016-07-18 16:16:02	0|sipa|i don't think that's relevant
234 2016-07-18 16:16:05	0|luke-jr|(specifically the UTXOs you're spending)
235 2016-07-18 16:16:11	0|sipa|it's a consensus-constrained resource
236 2016-07-18 16:16:23	0|sipa|its usage may affect fees
237 2016-07-18 16:16:53	0|sipa|this has traditionally not been the case for sigops, so i think it is unlikely to matter
238 2016-07-18 16:17:21	0|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"
239 2016-07-18 16:17:34	0|sipa|those two properties are completely unrelated
240 2016-07-18 16:18:32	0|luke-jr|if you can't calculate it in the first place, then you can't try to do a sigop-feerate independently
241 2016-07-18 16:18:37	0|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
242 2016-07-18 16:18:47	0|sdaftuar|shouldn't that quantity be scaled?
243 2016-07-18 16:19:14	0|sipa|sdaftuar: indeed!
244 2016-07-18 16:19:28	0|sipa|luke-jr: wallets can calculate sigops in advance
245 2016-07-18 16:20:06	0|luke-jr|sdaftuar: I guess so. Although I wonder if it ought to be scaled in GetLegacy…
246 2016-07-18 16:22:01	0|jtimon|MarcoFalke: would it make sense to use the "easy to implement" label for #7829 ?
247 2016-07-18 16:24:55	0|jtimon|MarcoFalke: thanks!
248 2016-07-18 16:41:43	0|jtimon|BlueMatt: https://github.com/bitcoin/bitcoin/commit/cbda71cf04ef6f2abe6eaa56c3140a6f5cff4feb#commitcomment-18286185
249 2016-07-18 16:42:15	0|GitHub116|[13bitcoin] 15sdaftuar opened pull request #8362: Scale legacy sigop count in CreateNewBlock (06master...06coinbase-sigops-scale) 02https://github.com/bitcoin/bitcoin/pull/8362
250 2016-07-18 16:42:16	0|wumpus|luke-jr sipa I just think there's more important things to focus on than changing words now
251 2016-07-18 16:42:54	0|wumpus|I thought it was simply a matter of changing that option, but I severly underestimated things
252 2016-07-18 16:43:34	0|wumpus|and as horrible names go, I don't think anything beats 'segregated withness' itself :)
253 2016-07-18 16:44:54	0|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
254 2016-07-18 16:46:38	0|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
255 2016-07-18 16:47:09	0|wumpus|at some point I got to GetTransactionCost and stopped bothering
256 2016-07-18 16:47:23	0|wumpus|(did I really need to change that to GetTransactionWeight?)
257 2016-07-18 16:47:43	0|sdaftuar|i think yes
258 2016-07-18 16:47:49	0|sdaftuar|:)
259 2016-07-18 16:48:01	0|sdaftuar|anyway i will try to wrap up and see what it looks like
260 2016-07-18 16:48:42	0|sdaftuar|sipa: what is your preferred language for the new sigop metric, if you have one?
261 2016-07-18 16:48:54	0|sdaftuar|i guess the existing language, not in the BIP, is "sigop cost"
262 2016-07-18 16:49:39	0|luke-jr|can we just leave sigops alone? unlike cost/weight, at least sigops becomes a complete non-issue over time :x
263 2016-07-18 16:49:44	0|wumpus|I was almost afraid that people would complain the unit needs to be Kg after this change :-)
264 2016-07-18 16:49:54	0|luke-jr|wumpus: srsly?
265 2016-07-18 16:50:24	0|wumpus|no, not really, but GetTransactionWeight sounds weird to me too, though it's lots better than GetTransactionCost
266 2016-07-18 16:50:38	0|jtimon|wumpus: lol then maybe some would prefer the imperial system...
267 2016-07-18 16:50:41	0|sdaftuar|right, GetTransactionCost sounds like fee!
268 2016-07-18 16:50:46	0|luke-jr|"impact" may work as well.
269 2016-07-18 16:50:51	0|wumpus|agree sdaftuar
270 2016-07-18 16:50:59	0|btcdrak|jtimon: ack on imperial measurement.
271 2016-07-18 16:51:04	0|luke-jr|jtimon: tonal !
272 2016-07-18 16:53:25	0|sipa|sdaftuar: i don't care strongly about sigops
273 2016-07-18 16:53:49	0|sipa|and cost is inconsistent, as the other is not called "size cost" either
274 2016-07-18 16:54:15	0|sdaftuar|i think we could just add "sigops cost" as a term in the BIP, and be done with the issue
275 2016-07-18 16:54:53	0|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
276 2016-07-18 16:55:39	0|wumpus|there's also at least one other implementation of segwit that will have to be changed with the BIP141 change (the btcd implementation)
277 2016-07-18 16:55:45	0|Chris_Stewart_5|So weight is signifying the subsidy segwit txs receive right?
278 2016-07-18 16:56:21	0|luke-jr|Chris_Stewart_5: no, weight is the replacement for size limits
279 2016-07-18 16:56:37	0|Chris_Stewart_5|luke-jr: size limits of..?
280 2016-07-18 16:56:44	0|luke-jr|of prior versions of Bitcoin
281 2016-07-18 16:56:58	0|luke-jr|it used to be that each byte of the block counted as 1 byte toward a 1 MB limit
282 2016-07-18 16:57:11	0|Chris_Stewart_5|So this is modifying the Script program size, tx size, block size...?
283 2016-07-18 16:57:12	0|luke-jr|now we count bytes as different "weights" toward a 4,000,000 limit
284 2016-07-18 16:57:17	0|Chris_Stewart_5|oh, ok
285 2016-07-18 16:57:42	0|luke-jr|more expensive data affecting the UTXO set have a weight of 4 per byte
286 2016-07-18 16:57:59	0|luke-jr|less expensive data (witness scripts) have a weight of 1 per byte
287 2016-07-18 17:00:06	0|wumpus|sdaftuar: this is how far I got: https://github.com/laanwj/bitcoin/commit/d259111512380e692188d0086d92451085b79c2f
288 2016-07-18 17:00:17	0|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
289 2016-07-18 17:00:30	0|sipa|Chris_Stewart_5: they're not smaller
290 2016-07-18 17:00:34	0|sipa|where did you get that idea
291 2016-07-18 17:00:45	0|sipa|segwit is a block size increase
292 2016-07-18 17:01:00	0|Chris_Stewart_5|When segwit txs are serialized and sent over the network they don't include scripts, making them smaller?
293 2016-07-18 17:01:10	0|sdaftuar|wumpus: heh, i'm at 19 files, 70 lines changed
294 2016-07-18 17:01:17	0|Chris_Stewart_5|You have to request the scripts, which is what fully validating nodes would do?
295 2016-07-18 17:01:18	0|luke-jr|Chris_Stewart_5: no, segwit txns are no smaller.
296 2016-07-18 17:01:32	0|luke-jr|they do include scripts
297 2016-07-18 17:02:16	0|jtimon|sdaftuar: s/GetTransactionCost/GetTransactionValidationCost/ ? or is that very disruptive too?
298 2016-07-18 17:02:50	0|sdaftuar|jtimon: i'm changing to GetTransactionWeight instead
299 2016-07-18 17:03:01	0|sdaftuar|that makes it consistent with max block weight
300 2016-07-18 17:03:24	0|Chris_Stewart_5|full scripts right? With witnesses included?
301 2016-07-18 17:04:29	0|jtimon|sdaftuar: but we're not changing max block weight are we?
302 2016-07-18 17:05:11	0|sdaftuar|jtimon: that's what's under discussion.  i'm preparing a PR for discussion
303 2016-07-18 17:05:13	0|jtimon|I was talking about fixing your concern without changing to max  block weight
304 2016-07-18 17:05:36	0|jtimon|ok, great
305 2016-07-18 17:06:05	0|sdaftuar|ah yes in that event your function rename shouldn't be too disruptive
306 2016-07-18 17:07:35	0|instagibbs|Chris_Stewart_5, there is no support for grabbing only the scripts or no scripts(if you're upgraded ofc)
307 2016-07-18 17:11:04	0|sipa|what did i miss?
308 2016-07-18 17:16:01	0|Chris_Stewart_5|sipa: FOMO??? :-). Nothing much was said
309 2016-07-18 17:16:26	0|sipa|fomo?
310 2016-07-18 17:17:24	0|Chris_Stewart_5|fear of missing out, gotta catch up on your contemporary culture
311 2016-07-18 17:17:30	0|sipa|ah
312 2016-07-18 17:46:39	0|GitHub36|[13bitcoin] 15sdaftuar opened pull request #8363: Rename "block cost" to "block weight" (06master...06cost-to-weight) 02https://github.com/bitcoin/bitcoin/pull/8363
313 2016-07-18 17:50:08	0|GitHub50|[13bitcoin] 15f139975 opened pull request #8364: Fix counting of sigops cost in mempool check (06master...06fix-mempool-sigops) 02https://github.com/bitcoin/bitcoin/pull/8364
314 2016-07-18 17:55:56	0|arubi|sipa, and what if a miner does it?  wrt ^
315 2016-07-18 17:56:35	0|sipa|arubi: what if a miner does what?
316 2016-07-18 17:57:53	0|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
317 2016-07-18 17:58:14	0|sipa|i don't understand
318 2016-07-18 17:58:38	0|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
319 2016-07-18 17:58:48	0|sipa|#7081 fixed it by refusing transactions that have high sigops but low size
320 2016-07-18 17:59:03	0|sipa|i think the correct solution is just to treat those transactions as if they had the corresponding size
321 2016-07-18 18:00:40	0|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
322 2016-07-18 18:02:45	0|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
323 2016-07-18 18:03:38	0|arubi|and you mentioned a vulnerability (which you explained), so.. hence the first question :)
324 2016-07-18 18:42:44	0|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
325 2016-07-18 18:42:51	0|BlueMatt|(that one line adds like 4 deps, at least)
326 2016-07-18 18:45:23	0|sipa|longer term i think CheckBlock and ContextualCheckBlock can probably be merged, as we never validate a block anymore without having its context
327 2016-07-18 18:45:57	0|sipa|though some parts of validation need to be factored out... for consistency checking and the verification compact blocks need
328 2016-07-18 19:01:30	0|GitHub89|[13bitcoin] 15sipa opened pull request #8365: Treat high-sigop transactions as larger rather than rejecting them (06master...06unifysigopcost) 02https://github.com/bitcoin/bitcoin/pull/8365
329 2016-07-18 19:13:01	0|BlueMatt|sipa: yea, I mean not a bad idea, indeed
330 2016-07-18 19:13:14	0|BlueMatt|but, yea, need to pull out the mutation-possible checks
331 2016-07-18 19:24:12	0|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
332 2016-07-18 19:24:43	0|jtimon|maybe exposing verifyheader (calling both) is enough and we don't care where the check is for this
333 2016-07-18 19:30:19	0|BlueMatt|jtimon: I mean the only thing that the compact blocks stuff cares about is the IsCorruptionPossible() checks
334 2016-07-18 19:30:54	0|BlueMatt|jtimon: those need to be factored out to simplify the compact block code anyway...everything else, whatever
335 2016-07-18 19:33:58	0|jtimon|anyway, not important at the moment I think, I was just surprised to see it moved
336 2016-07-18 20:54:01	0|GitHub175|[13bitcoin] 15jonasschnelli opened pull request #8366: [Wallet] Ensure <0.13 clients can't open HD wallets (060.13...062016/07/hd_minversion) 02https://github.com/bitcoin/bitcoin/pull/8366
337 2016-07-18 20:55:21	0|GitHub57|[13bitcoin] 15jonasschnelli closed pull request #8343: [Wallet] Ensure <0.13 clients can't open HD wallets (06master...062016/07/hd_minversion) 02https://github.com/bitcoin/bitcoin/pull/8343
338 2016-07-18 20:58:22	0|GitHub83|[13bitcoin] 15jonasschnelli opened pull request #8367: [Wallet] Ensure <0.13 clients can't open HD wallets (06master...062016/07/hd_minversion_014) 02https://github.com/bitcoin/bitcoin/pull/8367