--- Day changed Mon Jul 18 2016 00:00 < 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 00:04 < GitHub127> [bitcoin] maiiz opened pull request #8357: Update coins.cpp (master...maiiz-patch-1) https://github.com/bitcoin/bitcoin/pull/8357 00:05 < GitHub5> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f5660d381a37...8cb288a6b37d 00:05 < GitHub5> bitcoin/master d6dc1bc Krzysztof Jurewicz: Fix 0.12 release notes on block relaying... 00:05 < GitHub5> bitcoin/master 8cb288a Wladimir J. van der Laan: Merge #8320: Fix 0.12 release notes on block relaying... 00:05 < 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 00:10 < 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 00:14 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 00:18 < jonasschnelli> wumpus: no. 8308 is more or less a feature and can go into 0.14 00:19 < jonasschnelli> IMO it's unclear if "importwallet" should import the HD master seed and set it according to the importet wallet 00:19 < wumpus> thanks, I agree 00:19 < jonasschnelli> *import* somehow implies that "old stuff is unchanged" 00:20 < jonasschnelli> But its good to have the extended master key "xpriv" visible in the dump... but as said. can go into 0.14 00:20 < 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 00:21 < wumpus> the only time you would want that is if you intend the imported wallet to replace your current one 00:21 < wumpus> removing the 0.13 milestone there 00:21 < jonasschnelli> yes. Thanks. 00:21 < jonasschnelli> Re https://github.com/bitcoin/bitcoin/pull/8343/files/51a4ee889e3d317fb51623701f06919adf0ee267#r71106179 00:21 < jonasschnelli> wumpus: I don't think it's possible without non-Client-Versions 00:21 < jonasschnelli> The nWalletMinVersion is tied to the clientversion 00:22 < wumpus> we did a similar thing for network at some point, the P2P version used to be coupled to the client version as well 00:22 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mjxhdyfiqzcezrob] has joined #bitcoin-core-dev 00:22 < wumpus> at some point we created a dedicated network version constant, which is bumped on non-compatible network changes 00:23 < jonasschnelli> wumpus: Yes. We could do this. But detecting 0.12 (and make it fail on 0.12) requires to stick to the clientversion 00:23 < wumpus> using the client version for anything else but reporting forces arbitrary release process constraints on versioning certain behavior 00:23 < wumpus> yes, I agree, you'd leave the old versions the same 00:23 < jonasschnelli> problematic part: https://github.com/bitcoin/bitcoin/blob/master/src/wallet/walletdb.cpp#L637 00:24 < wumpus> this would be a change going forward, for the future, it can't be done retrospectively for versions that are already released :) 00:24 < wumpus> in any case no hurry 00:25 < sipa> wumpus: i guess it can be replaced with a set of strings 00:25 < jonasschnelli> Yes. We should slowly decouple it from CLIENT_VERSION 00:25 < sipa> wumpus: denoting features that the wallet uses 00:25 < jonasschnelli> sipa: you mean set of string about what features it supports? 00:25 < jonasschnelli> ok. 00:25 < wumpus> sipa: and then exit if a non-supported feature is used, yes 00:25 < jonasschnelli> Flags? Bitmask? 00:26 < 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 00:26 < wumpus> e.g. generating errors like 'this wallet uses BIP32 which is not supported in this version' 00:26 < jonasschnelli> ah.. fair enought 00:26 < jonasschnelli> We could do this once we switch over to a different database format (logdb) 00:26 < wumpus> with bitmask you can only report the flag number, and there's no real need to be very compact here 00:26 < jonasschnelli> (which is overdue since years) 00:26 < wumpus> (it'd be something stored only once in the wallet) 00:29 < sipa> wumpus: i like the ext2/3/4 compatibility system 00:30 < sipa> wumpus: with 3 sets of strings/flags 00:31 < 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" 00:31 -!- anu0 [~anu0@unaffiliated/anu0] has joined #bitcoin-core-dev 00:33 < jonasschnelli> sipa: Indeed. This would be good. 00:34 < 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. 00:35 -!- anu1 [~anu0@unaffiliated/anu0] has quit [Ping timeout: 252 seconds] 00:36 < sipa> no, you can just see the switch to such a new system as a 'feature' in the old compatibility system 00:47 -!- xinxi [~xinxi@116.86.156.222] has quit [Remote host closed the connection] 00:49 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 00:49 -!- fengling_ [~fengling@58.135.95.135] has joined #bitcoin-core-dev 01:05 < jonasschnelli> sipa: Yes. Indeed. Possible migration path. 01:06 -!- xinxi [~xinxi@116.86.156.222] has joined #bitcoin-core-dev 01:07 -!- xinxi [~xinxi@116.86.156.222] has quit [Remote host closed the connection] 01:08 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:19 -!- nickler [~nickler@185.12.46.130] has quit [Ping timeout: 264 seconds] 01:25 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev 01:27 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 01:28 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 01:28 -!- molly [~molly@unaffiliated/molly] has quit [Ping timeout: 250 seconds] 01:43 < wumpus> bah, changing all occurences of 'cost' to 'weight' is a huge change 01:44 < wumpus> I'm having second thoughts about it 01:45 < 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 01:49 < wumpus> and don't really want to block the 0.13 branch on this 01:49 < GitHub77> [bitcoin] laanwj closed pull request #8354: mining: Rename `-blockmaxcost` to `-blockmaxweight` (master...2016_07_block_weight) https://github.com/bitcoin/bitcoin/pull/8354 01:51 < sipa> so you want to delay the change until 0.13 is branched off? 01:51 < sipa> or reconsider entirely? 01:51 < wumpus> I don't think I want to do it anymore 01:52 < MarcoFalke> What about only changing -help and rpc calls? 01:52 < MarcoFalke> And then the nasty code cleaup for 0.14? 01:53 < wumpus> I don't think it's worth it 01:53 < wumpus> should have paid more attention to this during the BIP draft 01:54 < wumpus> maybe just change the help message to "Set maximum BIP141 block cost" 01:54 < wumpus> then everyone can look it up if they want 01:55 < wumpus> changing the BIP now because of a word impacts all other implementations too 01:57 < 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 01:57 < GitHub7> [bitcoin] laanwj opened pull request #8359: mining: Improve `-blockmaxcost` help message (master...2016_07_blockmaxcost_doc) https://github.com/bitcoin/bitcoin/pull/8359 02:11 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 02:16 -!- xinxi [~xinxi@116.86.156.222] has joined #bitcoin-core-dev 02:18 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye] 02:23 -!- xinxi [~xinxi@116.86.156.222] has quit [Remote host closed the connection] 02:27 -!- xinxi [~xinxi@116.86.156.222] has joined #bitcoin-core-dev 02:28 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev [] 02:30 -!- jannes [~jannes@178.132.211.90] has joined #bitcoin-core-dev 02:31 -!- xinxi [~xinxi@116.86.156.222] has quit [Ping timeout: 244 seconds] 03:06 < GitHub67> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8cb288a6b37d...03c56f62c2fd 03:06 < GitHub67> bitcoin/master 8cef5bd Wladimir J. van der Laan: mining: Improve `-blockmaxcost` help message... 03:06 < GitHub67> bitcoin/master 03c56f6 Wladimir J. van der Laan: Merge #8359: mining: Improve `-blockmaxcost` help message... 03:06 < GitHub184> [bitcoin] laanwj closed pull request #8359: mining: Improve `-blockmaxcost` help message (master...2016_07_blockmaxcost_doc) https://github.com/bitcoin/bitcoin/pull/8359 03:13 < GitHub83> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/e4382fbef56a0e04b0ed834e8b3a3a16f81db149 03:13 < GitHub83> bitcoin/master e4382fb Wladimir J. van der Laan: qt: periodic translations update 03:22 < GitHub85> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/6c0336c7723da274c8312b82ed2a138f5d57158f 03:22 < GitHub85> bitcoin/master 6c0336c Wladimir J. van der Laan: build: bump version to 0.13.99... 03:22 < wumpus> 0.13 branch was created 03:29 < sipa> \o/ 03:32 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has joined #bitcoin-core-dev 03:36 -!- Samdney [~Samdney@nat-wlan2.rrze.uni-erlangen.de] has joined #bitcoin-core-dev 03:40 -!- fengling_ [~fengling@58.135.95.135] has quit [Quit: WeeChat 1.4] 03:48 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 03:55 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 03:55 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 03:58 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 03:59 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 04:00 -!- YOU-JI [~youyouyou@FL1-125-195-44-154.chb.mesh.ad.jp] has joined #bitcoin-core-dev 04:01 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 04:02 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 04:04 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 04:04 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 04:05 < btcdrak> which tickets are blocking RC1? 04:06 < wumpus> #8343 stilln eeds in 04:06 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 04:07 < wumpus> (but could only be done after the version bump, because of wallet versioning constraints) 04:07 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 04:09 < btcdrak> now the branching has happened, are we clear for a bit of libconsensus refactoring work? 04:09 < btcdrak> (in master obviously) 04:09 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 04:11 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 04:15 < wumpus> I think so... 04:21 < wumpus> for 0.13 there's still plenty of work to do for the release notes: https://github.com/bitcoin/bitcoin/issues/7678 04:28 -!- NicLin [~textual@116.87.237.152] has joined #bitcoin-core-dev 04:41 -!- BitcoinErrorLog [~bitcoiner@c-98-231-56-138.hsd1.fl.comcast.net] has joined #bitcoin-core-dev 04:46 -!- xinxi [~xinxi@116.86.156.222] has joined #bitcoin-core-dev 04:47 -!- instagibbs [~instagibb@pool-100-15-114-5.washdc.fios.verizon.net] has joined #bitcoin-core-dev 05:00 -!- molly [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 05:00 -!- Ginnarr [~Ginnarr@unaffiliated/ginnarr] has quit [Quit: Textual IRC Client: www.textualapp.com] 05:01 -!- anu1 [~anu0@unaffiliated/anu0] has joined #bitcoin-core-dev 05:01 < GitHub24> [bitcoin] laanwj pushed 1 new commit to master: https://github.com/bitcoin/bitcoin/commit/5e3557b8e36308a27dbeb528569abe638c4d01dd 05:01 < GitHub24> bitcoin/master 5e3557b Wladimir J. van der Laan: doc: Clean out release notes... 05:04 -!- anu0 [~anu0@unaffiliated/anu0] has quit [Ping timeout: 276 seconds] 05:08 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:11 < GitHub181> [bitcoin] laanwj pushed 1 new commit to 0.13: https://github.com/bitcoin/bitcoin/commit/37269105c8817a2922410ec17d976263cd589987 05:11 < GitHub181> bitcoin/0.13 3726910 Wladimir J. van der Laan: build: Release notes update... 05:13 -!- anu1 [~anu0@unaffiliated/anu0] has quit [Quit: leaving] 05:13 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 05:13 -!- anu0 [~anu0@unaffiliated/anu0] has joined #bitcoin-core-dev 05:19 -!- BitcoinErrorLog [~bitcoiner@c-98-231-56-138.hsd1.fl.comcast.net] has quit [] 05:19 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 05:21 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 05:21 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 05:23 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 05:23 -!- pedrobra_ [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 05:25 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 05:26 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 05:26 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 258 seconds] 05:29 -!- xinxi [~xinxi@116.86.156.222] has quit [Remote host closed the connection] 05:29 -!- xinxi [~xinxi@116.86.156.222] has joined #bitcoin-core-dev 05:33 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:34 -!- xinxi [~xinxi@116.86.156.222] has quit [Ping timeout: 272 seconds] 05:46 -!- xinxi [~xinxi@116.86.156.222] has joined #bitcoin-core-dev 05:46 -!- xinxi [~xinxi@116.86.156.222] has quit [Client Quit] 05:55 -!- molly is now known as moli 05:57 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] 05:58 -!- achow101 [~achow101@pool-108-2-58-173.phlapa.fios.verizon.net] has joined #bitcoin-core-dev 06:07 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:08 -!- mkarrer_ [~mkarrer@142.red-83-47-107.dynamicip.rima-tde.net] has quit [Ping timeout: 272 seconds] 06:15 -!- mkarrer [~mkarrer@142.red-83-47-107.dynamicip.rima-tde.net] has joined #bitcoin-core-dev 06:22 -!- TomMc [~tom@unaffiliated/tommc] has joined #bitcoin-core-dev 06:23 < 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 06:28 < sipa> wumpus: working on a PR with repease notes about the relay/p2p changes 06:28 < wumpus> sipa: awesome 06:28 < sipa> only overlap with yours is the bloom filter requirement for mempool 06:29 < wumpus> ok 07:03 < 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 07:03 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 07:06 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 07:10 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 07:21 -!- Lysanders [~Lysanders@unaffiliated/lysanders] has quit [Ping timeout: 276 seconds] 07:30 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 07:31 -!- NicLin [~textual@116.87.237.152] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 07:33 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 07:33 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Disconnected by services] 07:33 -!- Arnavion [~Arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 07:34 -!- TomMc [~tom@unaffiliated/tommc] has quit [Quit: WeeChat 1.3] 07:34 -!- YOU-JI [~youyouyou@FL1-125-195-44-154.chb.mesh.ad.jp] has quit [Quit: Leaving...] 07:40 < 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.. 07:40 < jonasschnelli> I expected that the main logic will get all headers first and pass them through NotifyHeaderTip() before actually downloading blocks... 07:42 < sipa> yes, it will 07:43 < sipa> it always notifies with the best known header at the time of calling 07:43 < jtimon> GetSpendHeight() ? tip->nHeight + 1 ? pindexPrev == NULL ? 0 : pindexPrev->nHeight + 1 ? 07:46 < jonasschnelli> sipa: okay. Let me check again.... 07:49 < 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? 07:51 < sipa> jonasschnelli: i cannot parse your sentence 07:51 < jonasschnelli> okay.. I'll try to explain different. 07:51 -!- Arnavion [~Arnavion@unaffiliated/arnavion] has quit [Disconnected by services] 07:51 -!- Arnavion3 [~Arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 07:51 -!- Arnavion3 is now known as Arnavion 07:52 < jonasschnelli> 1.) Im connected to a node with height 421290, I'm currently at 421100 07:52 -!- AtashiCon [arnavion@unaffiliated/arnavion] has quit [Disconnected by services] 07:52 -!- Arnavion3 [~Arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev 07:52 -!- Arnavion3 is now known as AtashiCon 07:52 < jonasschnelli> 2.) NotifyHeaderTip gives me a header somewhere at height 421150 (50 headers in advance) 07:52 < jonasschnelli> 3.) Then I'll get the signals for the blocks till 421150 07:52 < sipa> sounds correct so far 07:53 < jonasschnelli> Is there no way to get signal with "the best known header" (from the remote peers)? 07:53 < jonasschnelli> (or the best known height) 07:53 < jonasschnelli> I want to work on the UI progress 07:53 < sipa> you don't know the peer's best header until we have it as well 07:53 < jonasschnelli> sipa: and main does not load all headers first,.. only a bunch of them, then the blocks? 07:54 < sipa> exactly what do you want to do? 07:54 < jonasschnelli> I'd like to show the "remaning blocks to process" untill we are in sync 07:54 < sipa> show the difference between the height of the last notifybesttip and the last notifybestheader 07:54 < jonasschnelli> So... I'd like to get signaled with "all" the headers first 07:55 < sipa> that's what notifybestheader does... 07:56 < 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. 07:56 < sipa> if it's behind a lot the headers should progress much much faster than the blocks 07:56 < sipa> it usually takes only a minute or two to learn about all headers 07:57 < sipa> ah! 07:57 < sipa> notifybestheader is not called during IBD 07:57 < sipa> oh, no, it is 07:57 < sipa> but with a false parameter 07:57 < jonasschnelli> ah... IBD is also true if I start bitcoin-core with 200 blocks behind. Right? 07:58 < sipa> yes 07:58 < sipa> but it is always called 07:58 < jonasschnelli> Hmm.. let me debug more deep 07:58 < sipa> i'm surprised it only increases 50 07:58 < sipa> headers should increase by 2000 at a time 07:58 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 08:00 < jonasschnelli> Maybe I'm missing the first signal because of my implementation... sipa: could it be that i get older headers in later NotifyHeaderTip()? 08:01 < sipa> at the time of the notify, what you see is always the best known header 08:02 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 08:06 < jonasschnelli> RPC getblockchaininfo report a newer height that I get passed over NotifyHeaderTip() 08:09 < sipa> during IBD that's possible 08:09 < sipa> oh, wait, no 08:09 < sipa> are you not filtering out IBD NotifyHeaderTips somewhere? 08:10 < jonasschnelli> I'm hooking into static void BlockTipChanged(ClientModel *clientmodel, bool initialSync, const CBlockIndex *pIndex, bool fHeader) (clientmodel.cpp) 08:11 < jonasschnelli> Maybe initially I need to get the height from pindexBestHeader? 08:11 < sipa> where else? 08:11 < sipa> ah, pindex->nHeight should work 08:11 < sipa> can i see the code? 08:12 < jonasschnelli> it's highly WIP... but let me push it. 08:13 < jonasschnelli> sipa: https://github.com/jonasschnelli/bitcoin/tree/2016/07/UI-out-of-sync 08:13 < jonasschnelli> use https://github.com/bitcoin/bitcoin/compare/master...jonasschnelli:2016/07/UI-out-of-sync?expand=1 08:14 < jonasschnelli> It works much better if i initially call pindexBestHeader->nHeight; then only "accept" header height over NotifyHeaderTips() if they are > 08:14 < jonasschnelli> Although not sure if this works for reorgs 08:15 < sipa> i'm very confused 08:15 < sipa> where in that code you're showing me do you hook into the notification? 08:16 < sipa> ah, you're adding to setNumBlocks 08:17 < sipa> that's only called once every 250ms 08:17 < jonasschnelli> ahh.. that could be the problem 08:18 < sipa> the header reported through NotifyBestHeader should always be of increasing height 08:18 < sipa> unless there is a very deep reorg to a lower height 08:18 < sipa> but that's extremely unlikely 08:18 < jonasschnelli> Argh.. yes. There is something like: if (!initialSync || now - nLastUpdateNotification > MODEL_UPDATE_DELAY) { 08:18 < jonasschnelli> Thanks sipa! 08:20 < jonasschnelli> we could pass through the fHeader=true signal always... 08:21 < 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 :/ 08:23 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 0.4.2] 08:23 < 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 08:24 < sipa> though i didn't try it myself, so i may be missing things 08:24 < luke-jr> sipa: well, at least changing it in GBT will be annoying once cost is released 08:25 < sipa> ah, GBT 08:25 < sipa> i hadn't considered that we'd change things there as well 08:25 < sipa> but i guess, yes 08:26 < luke-jr> I guess we don't *have* to, but it will just be confusing if GBT was the odd thing out 08:26 < sipa> agree 08:26 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 08:29 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 08:30 < jtimon> yay branch 0.13 forked ! 08:39 < 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 08:39 < sdaftuar> we didn't talk about it last week, but is "sigops cost" a term we want to keep? 08:39 < luke-jr> sdaftuar: it was renamed to just "sigops"; I'm surprised GBT ever mentioned it O.o 08:39 < 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" 08:40 < luke-jr> oh, in Core; that's just a bug then IMO 08:41 < 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 08:41 < sdaftuar> but that seems clunky! 08:41 < luke-jr> sdaftuar: why? 08:41 < luke-jr> sigops are just counted differently, not redefined 08:41 < sdaftuar> it's a different unit now 08:41 < luke-jr> P2SH counted them differently without a rename too 08:41 < luke-jr> the old counting ceases to be relevant at the fork 08:42 < sdaftuar> p2sh didn't change the units/scale of sigops for non-p2sh transactions though 08:42 < luke-jr> … 08:42 < 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 08:42 < luke-jr> so you want to rename it every softfork that affects how it's counted? 08:42 < luke-jr> what's the point? 08:57 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev 09:03 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 09:04 -!- Samdney [~Samdney@nat-wlan2.rrze.uni-erlangen.de] has quit [Ping timeout: 240 seconds] 09:04 < 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? 09:05 < sdaftuar> if not then fine, i agree this is all pointless 09:05 < luke-jr> sdaftuar: a GBT caller cannot know the sigop counting; scale is not different from any other countign changes 09:05 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 09:10 < sipa> sdaftuar, luke-jr: imho we should change the name when the unit's scale changes 09:11 < luke-jr> sigh. 09:11 < sipa> luke-jr: in p2sh, users of non-p2sh transactions would not be affected by the new counting 09:12 < sipa> here, everyone is affected - assuming that the old unit has the same meaning could lead to accidents 09:12 < luke-jr> how? 09:12 < sipa> that's why transaction's "size" is redefined in a backward-compatible way (and not the scaling) 09:12 < sipa> i agree that for sigops it is unlikely to matter 09:12 < sipa> but in general, it is a good practice to rename things when their meaning changes 09:13 < luke-jr> IMO the meaning is essentially the same. 09:13 < luke-jr> it's an arbitrary consensus-critical counting toward an arbitrary limit. 09:13 < sipa> if someone were to charge based on #sigops, it is most definitely not the se 09:13 < sipa> *same 09:14 < 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)? 09:15 < sipa> i was fine with not renaming in GBT, but instead giving the consensus limit along with it 09:15 < luke-jr> yes, because size is something they can calculate external to the consensus system 09:15 < luke-jr> the same is not true of sigops - you can't calculate it independently from the UTXO set 09:16 < sipa> i don't think that's relevant 09:16 < luke-jr> (specifically the UTXOs you're spending) 09:16 < sipa> it's a consensus-constrained resource 09:16 < sipa> its usage may affect fees 09:16 < sipa> this has traditionally not been the case for sigops, so i think it is unlikely to matter 09:17 < 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" 09:17 < sipa> those two properties are completely unrelated 09:18 < luke-jr> if you can't calculate it in the first place, then you can't try to do a sigop-feerate independently 09:18 < 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 09:18 < sdaftuar> shouldn't that quantity be scaled? 09:19 < sipa> sdaftuar: indeed! 09:19 < sipa> luke-jr: wallets can calculate sigops in advance 09:20 < luke-jr> sdaftuar: I guess so. Although I wonder if it ought to be scaled in GetLegacy… 09:22 < jtimon> MarcoFalke: would it make sense to use the "easy to implement" label for #7829 ? 09:24 < jtimon> MarcoFalke: thanks! 09:28 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection] 09:33 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev 09:35 -!- Amnez777 [~Amnez777@37.157.216.155] has quit [Ping timeout: 250 seconds] 09:40 -!- Lysanders [~Lysanders@unaffiliated/lysanders] has joined #bitcoin-core-dev 09:41 < jtimon> BlueMatt: https://github.com/bitcoin/bitcoin/commit/cbda71cf04ef6f2abe6eaa56c3140a6f5cff4feb#commitcomment-18286185 09:42 < GitHub116> [bitcoin] sdaftuar opened pull request #8362: Scale legacy sigop count in CreateNewBlock (master...coinbase-sigops-scale) https://github.com/bitcoin/bitcoin/pull/8362 09:42 < wumpus> luke-jr sipa I just think there's more important things to focus on than changing words now 09:42 < wumpus> I thought it was simply a matter of changing that option, but I severly underestimated things 09:43 < wumpus> and as horrible names go, I don't think anything beats 'segregated withness' itself :) 09:44 < 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 09:46 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection] 09:46 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Remote host closed the connection] 09:46 < 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 09:46 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev 09:47 < wumpus> at some point I got to GetTransactionCost and stopped bothering 09:47 -!- bsm117532 [~mcelrath@38.121.165.30] has quit [Remote host closed the connection] 09:47 < wumpus> (did I really need to change that to GetTransactionWeight?) 09:47 -!- bsm117532 [~mcelrath@38.121.165.30] has joined #bitcoin-core-dev 09:47 < sdaftuar> i think yes 09:47 < sdaftuar> :) 09:48 < sdaftuar> anyway i will try to wrap up and see what it looks like 09:48 < sdaftuar> sipa: what is your preferred language for the new sigop metric, if you have one? 09:48 < sdaftuar> i guess the existing language, not in the BIP, is "sigop cost" 09:49 < luke-jr> can we just leave sigops alone? unlike cost/weight, at least sigops becomes a complete non-issue over time :x 09:49 < wumpus> I was almost afraid that people would complain the unit needs to be Kg after this change :-) 09:49 < luke-jr> wumpus: srsly? 09:50 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev 09:50 < wumpus> no, not really, but GetTransactionWeight sounds weird to me too, though it's lots better than GetTransactionCost 09:50 < jtimon> wumpus: lol then maybe some would prefer the imperial system... 09:50 < sdaftuar> right, GetTransactionCost sounds like fee! 09:50 < luke-jr> "impact" may work as well. 09:50 < wumpus> agree sdaftuar 09:50 < btcdrak> jtimon: ack on imperial measurement. 09:51 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Read error: Connection reset by peer] 09:51 < luke-jr> jtimon: tonal ! 09:53 < sipa> sdaftuar: i don't care strongly about sigops 09:53 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has joined #bitcoin-core-dev 09:53 < sipa> and cost is inconsistent, as the other is not called "size cost" either 09:54 < sdaftuar> i think we could just add "sigops cost" as a term in the BIP, and be done with the issue 09:54 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 09:54 < 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 09:55 < wumpus> there's also at least one other implementation of segwit that will have to be changed with the BIP141 change (the btcd implementation) 09:55 < Chris_Stewart_5> So weight is signifying the subsidy segwit txs receive right? 09:56 < luke-jr> Chris_Stewart_5: no, weight is the replacement for size limits 09:56 < Chris_Stewart_5> luke-jr: size limits of..? 09:56 < luke-jr> of prior versions of Bitcoin 09:56 < luke-jr> it used to be that each byte of the block counted as 1 byte toward a 1 MB limit 09:57 < Chris_Stewart_5> So this is modifying the Script program size, tx size, block size...? 09:57 < luke-jr> now we count bytes as different "weights" toward a 4,000,000 limit 09:57 < Chris_Stewart_5> oh, ok 09:57 < luke-jr> more expensive data affecting the UTXO set have a weight of 4 per byte 09:57 < luke-jr> less expensive data (witness scripts) have a weight of 1 per byte 09:59 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 10:00 < wumpus> sdaftuar: this is how far I got: https://github.com/laanwj/bitcoin/commit/d259111512380e692188d0086d92451085b79c2f 10:00 < 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 10:00 < sipa> Chris_Stewart_5: they're not smaller 10:00 < sipa> where did you get that idea 10:00 < sipa> segwit is a block size increase 10:00 < Chris_Stewart_5> When segwit txs are serialized and sent over the network they don't include scripts, making them smaller? 10:01 < sdaftuar> wumpus: heh, i'm at 19 files, 70 lines changed 10:01 < Chris_Stewart_5> You have to request the scripts, which is what fully validating nodes would do? 10:01 < luke-jr> Chris_Stewart_5: no, segwit txns are no smaller. 10:01 < luke-jr> they do include scripts 10:02 < jtimon> sdaftuar: s/GetTransactionCost/GetTransactionValidationCost/ ? or is that very disruptive too? 10:02 < sdaftuar> jtimon: i'm changing to GetTransactionWeight instead 10:03 < sdaftuar> that makes it consistent with max block weight 10:03 < Chris_Stewart_5> full scripts right? With witnesses included? 10:04 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-sqoaofmpvrygssab] has quit [Ping timeout: 272 seconds] 10:04 < jtimon> sdaftuar: but we're not changing max block weight are we? 10:05 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mjxhdyfiqzcezrob] has quit [Ping timeout: 272 seconds] 10:05 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-xlfrthjzsyaltvzc] has quit [Ping timeout: 272 seconds] 10:05 < sdaftuar> jtimon: that's what's under discussion. i'm preparing a PR for discussion 10:05 < jtimon> I was talking about fixing your concern without changing to max block weight 10:05 < jtimon> ok, great 10:05 -!- sipa [~pw@unaffiliated/sipa1024] has quit [Ping timeout: 272 seconds] 10:05 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-kccfrqpobwcfhmhs] has quit [Ping timeout: 272 seconds] 10:05 -!- jyap [~jyap@unaffiliated/jyap] has quit [Ping timeout: 272 seconds] 10:05 -!- helo [~helo@unaffiliated/helo] has quit [Ping timeout: 272 seconds] 10:06 < sdaftuar> ah yes in that event your function rename shouldn't be too disruptive 10:06 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 272 seconds] 10:06 -!- musalbas- [~musalbas@2001:bc8:30c2::] has quit [Ping timeout: 272 seconds] 10:06 -!- musalbas [~musalbas@2001:bc8:30c2:ff00::] has quit [Ping timeout: 272 seconds] 10:06 -!- michagogo [uid14316@wikia/Michagogo] has quit [Ping timeout: 272 seconds] 10:06 -!- nsh [~lol@wikipedia/nsh] has quit [Ping timeout: 272 seconds] 10:06 -!- cfields [~quassel@unaffiliated/cfields] has quit [Ping timeout: 272 seconds] 10:07 < instagibbs> Chris_Stewart_5, there is no support for grabbing only the scripts or no scripts(if you're upgraded ofc) 10:08 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection] 10:09 -!- NicolasDorier [sid129442@gateway/web/irccloud.com/x-kjhunzojroktxgtm] has joined #bitcoin-core-dev 10:09 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-supfrsmyztrndplf] has joined #bitcoin-core-dev 10:09 -!- cfields [~quassel@unaffiliated/cfields] has joined #bitcoin-core-dev 10:09 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-fetyvlpepnntxfnf] has joined #bitcoin-core-dev 10:10 -!- michagogo [uid14316@wikia/Michagogo] has joined #bitcoin-core-dev 10:10 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev 10:10 -!- sipa [~pw@2a02:348:86:3011::1] has joined #bitcoin-core-dev 10:10 -!- musalbas [~musalbas@2001:bc8:30c2:ff00::] has joined #bitcoin-core-dev 10:11 < sipa> what did i miss? 10:11 -!- jyap [~jyap@2604:180:1:7f5::b59a] has joined #bitcoin-core-dev 10:11 -!- jyap [~jyap@2604:180:1:7f5::b59a] has quit [Changing host] 10:11 -!- jyap [~jyap@unaffiliated/jyap] has joined #bitcoin-core-dev 10:12 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 10:13 -!- adamg [~akg@50.242.93.33] has joined #bitcoin-core-dev 10:14 -!- nsh [~lol@wikipedia/nsh] has joined #bitcoin-core-dev 10:16 < Chris_Stewart_5> sipa: FOMO??? :-). Nothing much was said 10:16 < sipa> fomo? 10:17 < Chris_Stewart_5> fear of missing out, gotta catch up on your contemporary culture 10:17 < sipa> ah 10:18 -!- musalbas- [~musalbas@2001:bc8:30c2::] has joined #bitcoin-core-dev 10:19 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Remote host closed the connection] 10:19 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has joined #bitcoin-core-dev 10:22 -!- btcdrak [uid165369@gateway/web/irccloud.com/x-pembnhmtevagqsfy] has joined #bitcoin-core-dev 10:24 -!- pedrobranco [~pedrobran@79.242.108.93.rev.vodafone.pt] has quit [Ping timeout: 276 seconds] 10:32 -!- helo [~helo@unaffiliated/helo] has joined #bitcoin-core-dev 10:46 < GitHub36> [bitcoin] sdaftuar opened pull request #8363: Rename "block cost" to "block weight" (master...cost-to-weight) https://github.com/bitcoin/bitcoin/pull/8363 10:46 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 264 seconds] 10:47 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has quit [Quit: Bye] 10:50 < 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 10:55 < arubi> sipa, and what if a miner does it? wrt ^ 10:56 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev 10:56 < sipa> arubi: what if a miner does what? 10:57 < 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 10:58 < sipa> i don't understand 10:58 < 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 10:58 < sipa> #7081 fixed it by refusing transactions that have high sigops but low size 10:59 < sipa> i think the correct solution is just to treat those transactions as if they had the corresponding size 10:59 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 11:00 < 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 11:01 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 11:01 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 11:02 -!- Sosumi [~Leon@bl10-113-190.dsl.telepac.pt] has joined #bitcoin-core-dev 11:02 < 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 11:03 < arubi> and you mentioned a vulnerability (which you explained), so.. hence the first question :) 11:05 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection] 11:06 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev 11:10 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [Remote host closed the connection] 11:10 -!- netsin [~jiggalato@unaffiliated/jiggalator] has joined #bitcoin-core-dev 11:11 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 11:15 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 240 seconds] 11:15 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 11:15 -!- cryptapus is now known as cryptapus_afk 11:16 -!- teward [teward@ubuntu/member/teward] has quit [Ping timeout: 250 seconds] 11:22 -!- netsin [~jiggalato@unaffiliated/jiggalator] has quit [] 11:23 -!- teward [teward@ubuntu/member/teward] has joined #bitcoin-core-dev 11:37 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Quit: conversation terminated!] 11:41 -!- cryptapus [~cryptapus@jupiter.osmus.org] has joined #bitcoin-core-dev 11:41 -!- cryptapus [~cryptapus@jupiter.osmus.org] has quit [Changing host] 11:41 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 11:42 < 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 11:42 < BlueMatt> (that one line adds like 4 deps, at least) 11:45 < sipa> longer term i think CheckBlock and ContextualCheckBlock can probably be merged, as we never validate a block anymore without having its context 11:45 < sipa> though some parts of validation need to be factored out... for consistency checking and the verification compact blocks need 12:01 < 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 12:05 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev [] 12:08 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 12:11 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 12:13 < BlueMatt> sipa: yea, I mean not a bad idea, indeed 12:13 < BlueMatt> but, yea, need to pull out the mutation-possible checks 12:24 < 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 12:24 < jtimon> maybe exposing verifyheader (calling both) is enough and we don't care where the check is for this 12:30 < BlueMatt> jtimon: I mean the only thing that the compact blocks stuff cares about is the IsCorruptionPossible() checks 12:30 < BlueMatt> jtimon: those need to be factored out to simplify the compact block code anyway...everything else, whatever 12:33 < jtimon> anyway, not important at the moment I think, I was just surprised to see it moved 12:40 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 272 seconds] 12:49 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev 13:01 -!- anu1 [~anu0@unaffiliated/anu0] has joined #bitcoin-core-dev 13:04 -!- anu0 [~anu0@unaffiliated/anu0] has quit [Ping timeout: 260 seconds] 13:08 -!- go1111111 [~go1111111@104.200.154.97] has quit [Ping timeout: 260 seconds] 13:08 -!- LeMiner [LeMiner@unaffiliated/leminer] has quit [Read error: Connection reset by peer] 13:10 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 13:12 -!- LeMiner [LeMiner@unaffiliated/leminer] has joined #bitcoin-core-dev 13:19 -!- achow101 [~achow101@pool-108-2-58-173.phlapa.fios.verizon.net] has quit [Ping timeout: 244 seconds] 13:20 -!- go1111111 [~go1111111@104.232.116.217] has joined #bitcoin-core-dev 13:35 -!- achow101 [~achow101@pool-108-2-58-173.phlapa.fios.verizon.net] has joined #bitcoin-core-dev 13:42 -!- droark [~droark@c-24-22-36-12.hsd1.or.comcast.net] has joined #bitcoin-core-dev 13:45 -!- nibor [~nibor@185.9.34.66] has joined #bitcoin-core-dev 13:54 < 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 13:55 < 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 13:55 -!- go1111111 [~go1111111@104.232.116.217] has quit [Quit: Leaving] 13:58 < 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 14:08 -!- go1111111 [~go1111111@104.232.116.217] has joined #bitcoin-core-dev 14:13 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: brb] 14:13 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has joined #bitcoin-core-dev 15:01 -!- cryptapus is now known as cryptapus_afk 15:01 -!- spudowiar [~spudowiar@unaffiliated/spudowiar] has quit [Quit: spudowiar OUT.] 15:16 -!- go1111111 [~go1111111@104.232.116.217] has quit [Ping timeout: 250 seconds] 15:24 -!- Samdney [~Samdney@dyn-ant666999.hawo.ipv6.uni-erlangen.de] has left #bitcoin-core-dev ["Verlassend"] 15:25 -!- cryptapus_ [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 15:26 -!- cryptapus_ is now known as cryptapus 15:28 -!- go1111111 [~go1111111@104.200.154.64] has joined #bitcoin-core-dev 15:28 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Client Quit] 15:32 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 15:33 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev 15:37 -!- PRab [~chatzilla@c-68-62-95-247.hsd1.mi.comcast.net] has joined #bitcoin-core-dev 15:37 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Ping timeout: 240 seconds] 15:54 -!- ebfull [~sean@c-50-170-183-94.hsd1.co.comcast.net] has quit [Remote host closed the connection] 15:57 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev 16:29 -!- NicLin [~textual@116.87.237.152] has joined #bitcoin-core-dev 16:44 -!- NicLin [~textual@116.87.237.152] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 16:56 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 17:01 -!- NicLin [~textual@116.87.237.152] has joined #bitcoin-core-dev 17:15 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-supfrsmyztrndplf] has quit [Quit: Connection closed for inactivity] 17:18 -!- gmaxwell [greg@wikimedia/KatWalsh/x-0001] has joined #bitcoin-core-dev 17:29 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has quit [Read error: Connection reset by peer] 17:30 -!- justanotheruser [~Justan@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 17:40 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 276 seconds] 17:43 -!- nickler [~nickler@185.12.46.130] has quit [Ping timeout: 276 seconds] 17:44 -!- skyraider [uid41097@gateway/web/irccloud.com/x-adcqcktwfuinicwx] has joined #bitcoin-core-dev 17:50 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev 17:51 -!- anu1 [~anu0@unaffiliated/anu0] has quit [Ping timeout: 276 seconds] 18:01 < BlueMatt> why is the hd wallet seed interpreted as an ecdsa privkey in a few places? 18:01 < BlueMatt> that seems like type confusion in a cryptographic system 18:02 < BlueMatt> though afaict its not really used as a pubkey anywhere, this seems like a very, very bad idea generally 18:03 < BlueMatt> (every way I can think about it its nbd, just seems like bad practice) 18:06 < sipa> BlueMatt: it's the other way around... we generate a (valid) private key, and then reinterpret it as a seed 18:06 < BlueMatt> yes, this seems strange 18:06 < sipa> this surprised me too 18:06 < BlueMatt> because it seems to be the pubkey thing is only used to go find the data that we want to hash 18:06 < sipa> but i only noticed it after merge, and i can't find any problems with it 18:07 < BlueMatt> yea, I mean it doesnt seem to be broken, just bad practice 18:07 < BlueMatt> (for encrypted wallets we store the pubkey-version in plaintext on disk, afaict, which is not ideal) 18:07 < BlueMatt> ^ about the only real issue I see 18:07 < gmaxwell> more or less bypasses the kdf then. 18:08 < sipa> what kdf? 18:08 < sipa> bip32 does not have any 18:08 < gmaxwell> The computationally hard function used for the passphrase in wallet encryption. But nevermind, I'm incorrect, it doesn't bypass it. 18:09 < sipa> ah, for encryption - no, indeed 18:09 < BlueMatt> gmaxwell: no, remember the padding bug 18:09 < BlueMatt> :( 18:09 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 18:09 < gmaxwell> I don't consider the padding bug interesting. 18:09 < sipa> still needs KDF; just no ec operation anymore 18:09 < BlueMatt> gmaxwell: indeed, I consider it a novelty 18:10 < sipa> BlueMatt: the alternative for the bip32 derivation is that we'd use the private key of the generated root as master key (with chaincode stored on disk), rather than treating it as a seed 18:11 < sipa> which would pretty much have identical security properties 18:11 < BlueMatt> sipa: kinda, ideally we wouldnt store the pubkey of that on disk 18:11 < BlueMatt> sipa: actually, your suggestion is worse 18:12 < BlueMatt> well, different 18:12 -!- nickler [~nickler@185.12.46.130] has quit [Ping timeout: 272 seconds] 18:12 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev 18:12 < gmaxwell> I believe there is a way to quickly disqualify candidate private keys without EC operations in any case; assuming you know two signatures with that key. 18:12 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 18:12 < BlueMatt> well, maybe better? right now you need to have your wallet unlocked to create new pubkeys (ie scan the chain, ish) 18:12 < BlueMatt> but we could store master pubkey on disk and then we wouldnt 18:13 < BlueMatt> dunno if better, but different 18:13 < sipa> BlueMatt: it uses hardened derivation, so you always need to unlock in any case 18:13 < BlueMatt> gmaxwell: mmm, didnt know that 18:13 < gmaxwell> BlueMatt: that would require using public derrivation. 18:13 < BlueMatt> sipa: ahh 18:13 < BlueMatt> well, I mean you could store that as well 18:15 -!- jannes [~jannes@178.132.211.90] has quit [Quit: Leaving] 18:21 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has joined #bitcoin-core-dev 18:21 < BlueMatt> is there any way to get an rpc or so to give you the master key? 18:21 < BlueMatt> if you dump it, probably? 18:29 < BlueMatt> the way I read the current code, every time we go to GenerateNewKey() we will iterate over every key we have already generated before generating a new one (as we never call SetHDChain to store the updated counter on disk)....anyone with a test hd wallet lying around want to see what their disk-counter is? 18:32 -!- Giszmo1 [~leo@ppp-83-171-187-230.dynamic.mnet-online.de] has joined #bitcoin-core-dev 18:35 -!- Giszmo [~leo@ppp-83-171-182-157.dynamic.mnet-online.de] has quit [Ping timeout: 264 seconds] 18:40 < BlueMatt> hmm...I also dont see any discussion of the non-switch of FEATURE_LATEST on the pr....this might complicate future wallet changes...it seems to me that this locks us in such that the next change to wallet version must either be the same non-default or we will, at that time, have to force hd wallets to be the default 18:41 < BlueMatt> I'm not strictly aginst this, just noting that it seems it was not at all discussed but locks us into a future path 18:44 < BlueMatt> oh ffs, ok, I'ma copy this into the hd wallet pr 18:49 < BlueMatt> ok, https://github.com/bitcoin/bitcoin/pull/8035#issuecomment-233508913 18:49 < BlueMatt> few more there, too 18:52 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Ping timeout: 258 seconds] 19:00 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] 19:04 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving] 19:12 < luke-jr> BlueMatt: the odd thing IMO is that it isn't already default, but I'm okay with that 19:13 < luke-jr> normally the default would be bumped immediately, and -walletupgrade needed for old wallets 19:16 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 19:17 -!- jtimon [~quassel@55.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 252 seconds] 19:20 -!- supasonic [~supasonic@172-11-188-177.lightspeed.rcsntx.sbcglobal.net] has quit [Ping timeout: 276 seconds] 19:24 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds] 19:26 -!- jonhbit [~jonhbit@tsarviajado.media.mit.edu] has joined #bitcoin-core-dev 19:27 -!- jonhbit [~jonhbit@tsarviajado.media.mit.edu] has quit [Client Quit] 19:27 -!- FNinTak [~jonhbit@tsarviajado.media.mit.edu] has joined #bitcoin-core-dev 19:28 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 19:36 -!- jonhbit [~jonhbit@tsarviajado.media.mit.edu] has joined #bitcoin-core-dev 19:38 -!- jonhbit [~jonhbit@tsarviajado.media.mit.edu] has left #bitcoin-core-dev [] 19:39 -!- FNinTak [~jonhbit@tsarviajado.media.mit.edu] has quit [Quit: Leaving] 19:48 -!- achow101 [~achow101@pool-108-2-58-173.phlapa.fios.verizon.net] has quit [Read error: Connection reset by peer] 19:52 -!- skyraider [uid41097@gateway/web/irccloud.com/x-adcqcktwfuinicwx] has quit [Quit: Connection closed for inactivity] 20:06 -!- fengling [~fengling@58.135.95.136] has quit [Ping timeout: 240 seconds] 20:07 -!- fengling [~fengling@58.135.95.135] has joined #bitcoin-core-dev 20:37 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 20:42 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Client Quit] 20:46 -!- kadoban [~mud@unaffiliated/kadoban] has joined #bitcoin-core-dev 21:44 -!- fengling [~fengling@58.135.95.135] has quit [Ping timeout: 240 seconds] 21:56 -!- aalex [~aalex@64.187.177.58] has quit [Ping timeout: 258 seconds] 22:00 -!- aalex [~aalex@64.187.177.58] has joined #bitcoin-core-dev 22:04 -!- fengling [~fengling@58.135.95.135] has joined #bitcoin-core-dev 22:16 -!- slackircbridge [~slackircb@45.55.41.36] has quit [Remote host closed the connection] 22:18 -!- slackircbridge [~slackircb@45.55.41.36] has joined #bitcoin-core-dev 22:25 -!- NicLin [~textual@116.87.237.152] has quit [Quit: My Mac has gone to sleep. ZZZzzz…] 22:28 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye] 22:32 -!- fengling [~fengling@58.135.95.135] has quit [Ping timeout: 240 seconds] 22:40 -!- fengling [~fengling@58.135.95.136] has joined #bitcoin-core-dev 23:15 -!- Lysanders [~Lysanders@unaffiliated/lysanders] has quit [Read error: Connection reset by peer] 23:33 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Read error: Connection reset by peer] 23:34 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev