--- Day changed Thu May 25 2017 00:19 -!- jtimon [~quassel@117.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds] 00:27 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Quit: Leaving] 00:28 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 00:31 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 00:50 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-tmxiuzjmrhfvvvzx] has joined #bitcoin-core-dev 00:55 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:21 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev 01:28 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 01:44 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 255 seconds] 01:51 < phantomcircuit> btw 01:51 < phantomcircuit> git bisect run is pretty neat 01:51 < phantomcircuit> (it was 10420) 01:55 < gmaxwell> phantomcircuit: thanks for bisecting. 01:56 < gmaxwell> ryanofsky: 10420 appears to have broken the build for QT4. See above. 01:57 < phantomcircuit> gmaxwell, tbh i really just wanted to try git bisect run 01:57 < phantomcircuit> it's neat 02:06 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev 02:54 -!- tunafizz [~tuna@c-71-207-56-72.hsd1.pa.comcast.net] has quit [Ping timeout: 245 seconds] 02:54 -!- tunafizz [~tuna@c-71-207-56-72.hsd1.pa.comcast.net] has joined #bitcoin-core-dev 03:07 -!- jtimon [~quassel@117.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 03:08 -!- beatrootfarmer [~Beatrootg@2a02:c7d:12e:100:c89f:cf91:6478:919e] has joined #bitcoin-core-dev 03:12 -!- goatturneer [~Beatrootg@2a02:c7d:12e:100:a162:bb54:a12e:f2f5] has quit [Ping timeout: 240 seconds] 03:22 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 255 seconds] 03:27 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds] 03:29 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 04:00 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 04:12 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection] 04:25 -!- snortblort [3eb79f07@gateway/web/freenode/ip.62.183.159.7] has joined #bitcoin-core-dev 04:43 -!- snortblort [3eb79f07@gateway/web/freenode/ip.62.183.159.7] has quit [Quit: Page closed] 04:56 -!- NewLiberty [~NewLibert@ip-64-134-71-216.public.wayport.net] has joined #bitcoin-core-dev 04:56 -!- NewLiberty_ [~NewLibert@ip-64-134-71-216.public.wayport.net] has joined #bitcoin-core-dev 05:01 < bitcoin-git> [bitcoin] ryanofsky opened pull request #10454: Fix broken q4 test build (master...pr/qt4ctx) https://github.com/bitcoin/bitcoin/pull/10454 05:07 -!- NewLiberty_ [~NewLibert@ip-64-134-71-216.public.wayport.net] has quit [Quit: Leaving] 05:33 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds] 05:35 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 240 seconds] 05:41 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 05:45 -!- marcoagner [~user@177.99.124.166] has quit [Quit: WeeChat 1.0.1] 06:00 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 06:09 -!- Alina-malina [~Alina-mal@37.157.223.80] has joined #bitcoin-core-dev 06:14 -!- Alina-malina [~Alina-mal@37.157.223.80] has quit [Ping timeout: 246 seconds] 06:23 -!- NewLiberty_ [~NewLibert@ip-64-134-71-216.public.wayport.net] has joined #bitcoin-core-dev 06:24 -!- NewLiberty [~NewLibert@ip-64-134-71-216.public.wayport.net] has quit [Ping timeout: 240 seconds] 06:37 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Remote host closed the connection] 06:43 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev 06:50 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev 06:55 -!- d_t [~textual@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has quit [Ping timeout: 260 seconds] 07:20 < bitcoin-git> [bitcoin] ryanofsky opened pull request #10455: Simplify feebumper minimum fee code slightly (master...pr/bumpmin) https://github.com/bitcoin/bitcoin/pull/10455 07:23 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 07:30 -!- Joseph__ [~NewLibert@ip-64-134-71-216.public.wayport.net] has joined #bitcoin-core-dev 07:30 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 07:33 -!- NewLiberty_ [~NewLibert@ip-64-134-71-216.public.wayport.net] has quit [Ping timeout: 240 seconds] 07:36 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 07:38 -!- Alina-malina [~Alina-mal@37.157.223.80] has joined #bitcoin-core-dev 07:41 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 07:43 -!- Alina-malina [~Alina-mal@37.157.223.80] has quit [Ping timeout: 268 seconds] 07:56 -!- goatturneer [~Beatrootg@2a02:c7d:12e:100:a15e:8834:63c:3256] has joined #bitcoin-core-dev 07:59 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has quit [Quit: Leaving] 08:00 < bitcoin-git> [bitcoin] earonesty closed pull request #10442: add a -bip148 option (master...master) https://github.com/bitcoin/bitcoin/pull/10442 08:00 -!- beatrootfarmer [~Beatrootg@2a02:c7d:12e:100:c89f:cf91:6478:919e] has quit [Ping timeout: 246 seconds] 08:27 -!- beatrootfarmer [~Beatrootg@2a02:c7d:12e:100:b80e:9887:11a4:fed7] has joined #bitcoin-core-dev 08:30 -!- goatturneer [~Beatrootg@2a02:c7d:12e:100:a15e:8834:63c:3256] has quit [Ping timeout: 240 seconds] 08:31 -!- beatrootfarmer [~Beatrootg@2a02:c7d:12e:100:b80e:9887:11a4:fed7] has quit [Ping timeout: 255 seconds] 08:43 -!- elkalamar_ [~elkalamar@84.126.69.179.dyn.user.ono.com] has joined #bitcoin-core-dev 08:45 -!- elkalamar [~elkalamar@84.126.69.179.dyn.user.ono.com] has quit [Ping timeout: 240 seconds] 08:45 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 08:45 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev 08:58 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev 08:59 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 09:15 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 09:46 -!- arowser [~quassel@106.120.101.38] has quit [Ping timeout: 240 seconds] 09:46 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 09:48 -!- dstadulis [~dstadulis@184-23-190-30.vpn.dynamic.sonic.net] has quit [Ping timeout: 246 seconds] 09:51 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 09:51 -!- beatrootfarmer [~Beatrootg@2a02:c7d:12e:100:bcef:89ae:d449:eab3] has joined #bitcoin-core-dev 09:51 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 09:58 -!- bsm1175321 [~mcelrath@135.84.167.210] has quit [Ping timeout: 255 seconds] 10:01 -!- juscamarena [~justin@47.148.176.74] has joined #bitcoin-core-dev 10:02 -!- juscamarena is now known as Guest72157 10:02 -!- juscamarena_ [~justin@47.148.176.74] has quit [Ping timeout: 260 seconds] 10:05 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 10:05 -!- belcher [~belcher@unaffiliated/belcher] has quit [Remote host closed the connection] 10:15 -!- Joseph__ [~NewLibert@ip-64-134-71-216.public.wayport.net] has quit [Ping timeout: 255 seconds] 10:46 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 10:49 -!- Alina-malina [~Alina-mal@37.157.223.80] has joined #bitcoin-core-dev 10:53 -!- Alina-malina [~Alina-mal@37.157.223.80] has quit [Changing host] 10:53 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev 11:15 < jonasschnelli> Grml... qt4. 11:16 < wumpus> don't be angry, let the people that care about fix it 11:16 < jonasschnelli> Yeah... ideally it would be in our CI 11:16 < jonasschnelli> otherwise this pops up here and there 11:16 < jonasschnelli> but right, I don't care about qt4. If people do, then they must fix it. 11:18 < wumpus> yes, same there, let the people that care about it add it to CI :) 11:19 < sipa> is Qt4 still intended to be supported? 11:19 < wumpus> yes 11:20 < wumpus> but no one of us actually uses it anymore, for a long time 11:20 < sipa> i believe that gmaxwell's setup had both qt4 and qt5, and configure automatically picked qt4? 11:21 < jonasschnelli> even worse, I think BlueMatt's PPA builds against qt4?! 11:21 < wumpus> there's an issue for qt4 eol, but apparently some people are still relying on it, so if they want to spend work on supporting it it's 100% fine by me, just don't expect me to: https://github.com/bitcoin/bitcoin/issues/8263 11:22 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-tmxiuzjmrhfvvvzx] has quit [Quit: Connection closed for inactivity] 11:22 < wumpus> if both qt4 and qt5 is installed and detected it should pick qt5 11:22 < jonasschnelli> during runtime? Do they compatible ABIs? 11:23 < wumpus> nono at configure time 11:23 < jonasschnelli> But the PPA is pre-built? 11:23 < wumpus> sipa was asking about configure, my answer was to that 11:23 < jonasschnelli> ah. sry 11:24 < jonasschnelli> Yes. It prefers qt5 since a while. 11:24 < wumpus> yes, because of an issue with ubuntu unity tray icon handling apparently qt4 works better on some ubuntu versions 11:25 < wumpus> it's pretty sad, but nothing really to be done about it, except wait for unity to be history 11:25 < wumpus> this is not a problem with our code, or even qt upstream, but with ubuntu specific plugins 11:28 < sipa> how about we just remove the tray icon support...? 11:28 < wumpus> it's possible, but it works fine for other OSes and other linux distros 11:29 < wumpus> I wouldn't mind removing tray icon support, but this in itself is a lousy reason 11:29 < wumpus> sure - disabling it specifically for the ppa would work, including a custom patch 11:30 < sipa> i was about to say that one distro with lousy trayicon support is a bad reason to stick with qt4... except we only stick to qt4 on ubuntu 11:30 < wumpus> that's up to BlueMatt 11:30 < wumpus> exactly! 11:30 < gmaxwell> I don't care about QT4 but I thought we still supported it. 11:30 < gmaxwell> And as sipa mentioned, I have both installed and it's building against 4. 11:31 < gmaxwell> (on debian testing) 11:31 < wumpus> (last time I tried tray icon support on ubuntu 16.04, with self-compiled bitcoin-qt on qt5 it seemed to work fine for me, btw, maybe they've fixed it, at least on some versions... or it's somehow dependent on a combination of circumstances) 11:31 < jonasschnelli> gmaxwell: hmm... bitcoin.m4 should prefere qt5 though... strange 11:31 < gmaxwell> I suppose it's possible something is screwed up, but it seems to be useful that it is since I keep catching build failures. 11:31 < sipa> gmaxwell: perhaps you have some tiny dependency missing for qt5? 11:31 < jonasschnelli> Maybe one of the qt5 libs is missin? 11:31 < jonasschnelli> +g 11:32 < jonasschnelli> config.log should probably tell you why... 11:32 < wumpus> my guess is that the qt5 detection is either broken on your distro, or a required component is missing 11:32 < wumpus> yeah that'd help 11:32 < sipa> well there are two independent issues here... building for qt4 should work if it's intended to be supported 11:32 < sipa> and qt5 should be detected properly for gmaxwell 11:33 < luke-jr> wumpus: I already tried to add it to CI, and then it was supposed to be part of the daily CI.. 11:34 < wumpus> luke-jr: ok, but it isn't? 11:34 < luke-jr> I guess someone removed it? Daily CI thing seems to be closed/dead? 11:34 < wumpus> it's run from a crontab now 11:34 < wumpus> (a new travis CI feature) 11:35 < luke-jr> so what happened to the qt4 part? 11:35 < wumpus> I don't know 11:35 < jonasschnelli> But I guess cron is not sufficient for qt4 support. We want to know before a merge 11:35 < luke-jr> I wonder if .. yeah, maybe it should be a primary QA 11:36 < wumpus> I think the problem back then was that we don't really want to add a new configuration/build for it,and it couldn't be fit into one of the current ones 11:36 < wumpus> but I might misremember 11:37 < luke-jr> well, if you want to reopen https://github.com/bitcoin/bitcoin/pull/7142 , I can rebase.. 11:39 < bitcoin-git> [bitcoin] laanwj reopened pull request #7142: [WIP] Travis: Test build against system Qt4 (master...travis_qt4) https://github.com/bitcoin/bitcoin/pull/7142 11:41 < gmaxwell> wumpus: thanks. I think we need it in build CI or we need to drop support for it. 11:42 < wumpus> gmaxwell: I'm fine with either 11:43 < wumpus> I really don't have an opinion on qt4, just refuse to spend time in it myself 11:45 < wumpus> but I guess it's the same in linux, I doubt e.g. Linus cares personally about all the drivers for ancient devices still in there, but as long as someone is willing to put in the time to keep it working it's better to keep including it instead of nuke it just because, after all it's a community effort 11:47 < gmaxwell> I don't know if I should care about QT4 or not. (don't know what the deployment rate of QT5 is) 11:50 < wumpus> I don't know either, this is the last thing qt.io ever posted on qt4: https://blog.qt.io/blog/2014/11/27/qt-4-8-x-support-to-be-extended-for-another-year/ 11:51 < wumpus> never was able to find a real EOL announcement, but it's been dead in the water for a long time 11:51 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 11:54 < wumpus> not that it says much, I know for fact that some industrial systems are still using qt4, even qt3 probably (was the case a few years ago) 11:55 < luke-jr> FWIW, I looked into adding Qt3 support briefly and decided it would be a pain :p 11:56 < wumpus> qt5 is much better for multimedia/modern app kind of interfaces, but for simple boring widget interfaces there's only a small difference between qt3 and qt4 and the difference between qt4 and qt5 is negible 11:59 < gmaxwell> If QT5 is shipping by default on the common linux distributions, perhaps we should stop QT4 support. Even though the difference is small, the effort to keep supporting it is non-trivial. 11:59 < wumpus> luke-jr: yes the API is quite different, I mean the user experience isn't that different 11:59 -!- marsu [~marsu@LFbn-1-12934-210.w83-199.abo.wanadoo.fr] has joined #bitcoin-core-dev 12:00 < wumpus> gmaxwell: yup qt5 has been the default on linux distros for a few years (don't know exactly how long / since which versions of particular distros though) 12:00 < luke-jr> gmaxwell: Qt5 doesn't have native look/feel on Qt4-based DEs.. but even that seems dead now 12:00 < instagibbs> meeting time? 12:00 < wumpus> but at least in ubuntu 14.04 it already was 12:00 < wumpus> #startmeeting 12:00 < lightningbot> Meeting started Thu May 25 19:00:52 2017 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:00 < BlueMatt> sipa: last i heard we were gonna try to just remove the trayicon 12:01 < jonasschnelli> proposed topic multiwallet-concept 12:01 < BlueMatt> (since it doesnt seem to be "the thing to do" anymore) 12:01 < sipa> woah, meeting! 12:01 < sipa> i totally forgot 12:01 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure blue matt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 instagibbs 12:01 < cfields> hi 12:02 < wumpus> #topic multiwallet-concept 12:03 < luke-jr> .. 12:03 < jonasschnelli> We should think about if we want run-time wallet creation/loading/unloading or per startup -wallet argument. 12:03 < luke-jr> jonasschnelli: IMO both eventually, but the latter is a good first stpe 12:03 < jonasschnelli> Also,.. what should we do with rescan/zapwallet/salvage/upgrade 12:03 < wumpus> yes, in the long term we want both 12:03 < wumpus> in the short term just do what is realistic for the (not too long!) timespan until 0.15 12:03 < sipa> i would disable rescan if you have more than one wallet configured 12:04 < jonasschnelli> the -wallet= approach seems very confusing. You either -usehd on all wallte, -rescan all wallets, etc. 12:04 < sipa> and use the RPC instead 12:04 < sipa> or better, remove it 12:04 < jonasschnelli> We can start with the all or nothing -wallet configuration. But ideally we move it to runtime over RPC 12:05 < jonasschnelli> also,... creation-flags can then be passed in. 12:05 < wumpus> yes 12:05 < sipa> right, all those options that affect the creation of new wallets ideally go into a new-wallet-creation RPC 12:05 < jonasschnelli> yes 12:05 < luke-jr> /GUI 12:05 < sipa> and rescan and upgrade become wallet-specific RPCs 12:05 < wumpus> so the command line options only work for the default wallet 12:05 < jonasschnelli> The GUI can be done later 12:05 < wumpus> that's fine 12:05 < wumpus> yes 12:05 < luke-jr> sipa: they already are? 12:05 < sipa> luke-jr: they're not RPCs 12:05 < sipa> ? 12:05 < luke-jr> sipa: rescan is, although maybe not merged in Core yet? 12:06 < jonasschnelli> I ack luke-jr current PR but deploying that may cause confusion (because of lack of a concept)= 12:06 < sipa> luke-jr: #7061 12:06 < gribble> https://github.com/bitcoin/bitcoin/issues/7061 | [Wallet] Replace -rescan with a new RPC call "rescanblockchain" by jonasschnelli · Pull Request #7061 · bitcoin/bitcoin · GitHub 12:06 * sipa really really really wants to see rescan go away entirely, but fears he cannot win this fight 12:06 < luke-jr> actually, -rescan might be better with multiwallet 12:06 < jonasschnelli> Heh. Its just to handy to remove rescan 12:07 < luke-jr> since you'd want to rescan all the wallets concurrently 12:07 < sipa> fair point 12:07 < luke-jr> the overhead for rescanning N wallets vs 1 is minimal IMO 12:07 < jonasschnelli> Another point is that we should consider wallet flags combined with the new wallet db format we have introduced with the HD chain split. 12:08 < jonasschnelli> wallet flags would probably better allow to store "creation flags" 12:08 < sipa> what do you mean by wallet flags? 12:08 < jtimon> labels? 12:08 < jonasschnelli> I have first implemented wallet flags here: https://github.com/bitcoin/bitcoin/pull/9662 12:08 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/9662/files#diff-b2bb174788c7409b671c46ccc86034bdR1357 12:09 < jonasschnelli> But maybe it's not required for the current feature set. But think like: "is the wallet using HD", "is it using chain split", .. "are pkeys diables"? 12:09 < sipa> yup 12:09 < luke-jr> eh, the wallet already supports that? 12:10 < sipa> but i think that's orthogonal to the new database format 12:10 < jonasschnelli> Yes. But we already do a new wallet-format type in 0.15. Ideally we push in everything that usefull for 0.15+ 12:10 < sipa> a new wallet format in 0.15? 12:10 < sipa> what? 12:10 < jtimon> sounds too optimistic 12:10 < jonasschnelli> the HD chain-split is not backward compatible 12:10 < sipa> oh! 12:10 < jonasschnelli> Not a new database format. 12:10 < sipa> ok 12:10 < wumpus> let's not make multiwallet dependent on a new wallet format 12:10 < sipa> nvm 12:11 < wumpus> okay, makes sense 12:11 < sipa> i thought you were talking about logdb 12:11 < jonasschnelli> nono... 12:11 < jonasschnelli> Just saying that the 0.15er wallet.dat files will not be backward comp. 12:11 < sipa> yeah, sure 12:11 < jonasschnelli> ideally we push in as much as we can... to avoid the same non -back com. in 0.16 12:11 < luke-jr> 0.15-created*? 12:12 < jonasschnelli> 0.15 created.. yes 12:12 < sipa> i think breaking backward compatibility in major releases is fine 12:12 < jonasschnelli> Yes. But if we can avoid it with little effort we may want to do it. 12:12 < jonasschnelli> But lets park this problem for now. 12:12 < jtimon> but his point is the more we get in now the less we have to break the next time 12:12 < gmaxwell> luke-jr: if you what to preserve rescan you need to make it faster. I think rescan is already functionally dead for many users: It takes something like 8 hours on my laptop. 12:12 < jonasschnelli> Way more important is what we do with -zap/-salvage/-upgrade in multiwallet 12:13 < luke-jr> jonasschnelli: forbid them with >1 -wallet? 12:13 < jonasschnelli> luke-jr: yes. why not. 12:13 < gmaxwell> jonasschnelli: I replied to your comment on that PR: I think zap and salvage should ultimately go away or move to another tool. Upgrade, I dunno. 12:13 < jonasschnelli> How would you run a non-hd and a hd-wallet (seems to be a reasonable use case) 12:13 < jonasschnelli> gmaxwell: agree with you 12:13 * sipa suggest removing zap in favor of abandontransaction, replacing salvage with a standalone tool, and leaving ugprade to apply to all wallets 12:13 < luke-jr> jonasschnelli: it just works right now.. 12:14 < jonasschnelli> luke-jr: Can it work? If you call -usehd on a non-hd wallet is stops during init 12:14 < luke-jr> jonasschnelli: don't set -usehd 12:14 < jonasschnelli> The its 1 by default 12:14 < luke-jr> no, it's by default, for existing wallets 12:14 < jonasschnelli> I guess you can't mix right now 12:15 < luke-jr> I test multiwallet with a combo of HD and non-HD 12:15 < jonasschnelli> Okay. Sorry then. 12:15 < sipa> -usehd should go away and become a parameter of the createnewwallet RPC 12:15 < jonasschnelli> yes 12:15 < gmaxwell> what sipa said. 12:15 < luke-jr> createnewwallet won't make 0.15 IMO 12:15 < sipa> that's fine 12:16 < jonasschnelli> I once stared with a standalone wallet tool but had problems with circular dependencies (cfields may know more): https://github.com/bitcoin/bitcoin/pull/8745 12:16 < jonasschnelli> Starting with luke-jr's current PR is fine.. 12:16 < kanzure> is there interaction between multiwallet and accounts? 12:17 < sipa> kanzure: no 12:17 < cfields> jonasschnelli: i'm sure we could get that worked out 12:17 < jonasschnelli> cfields: okay. Great 12:17 < sipa> for the time being, i think that -usehd (if specified) should apply to all wallets, if not specified, every wallet can be whatever it already is 12:17 < wumpus> yes, that's fine, let's aim to get at least basic multiwallet support in 0.15 though 12:17 < jonasschnelli> agree 12:18 < wumpus> not let it slip another release because we want too much from it, or make it conditional on other changes which haven't been done yet 12:18 < sipa> short topic suggestion: variable naming style 12:18 < gmaxwell> sha256 hashes for all variables! 12:18 < jonasschnelli> I just think we should have a (the same) concept in the backhead to avoid extra loops 12:18 < jonasschnelli> lol 12:18 < morcos> if this is better offline, fine, but sipa, how would we remove rescan? 12:18 < kanzure> no abbreviated variable names plzkthx. actually i would take sha256 hashes over abbreviations. 12:18 < sipa> morcos: let's discuss after the meeting 12:18 < wumpus> gmaxwell: I was about to suggest xxd on /dev/urandom, but that works for me too :p 12:18 < morcos> k 12:19 < wumpus> #topic variable naming style 12:19 * cfields would kill for m_ == member 12:19 < luke-jr> pls don't kill 12:19 < sipa> i've recently seen several people write patches with variable names that look like they're hungarian, but aren't 12:19 < sipa> i don't care personally for that particular style, but i like consistency 12:19 < wumpus> the hungerian onvention should die 12:20 < sipa> but what to replace it with? 12:20 < luke-jr> I particularly dislike hungarian-looking names that don't have the hungarian meaning :p 12:21 < gmaxwell> Greek characters. 12:21 < sipa> i guess the first question is, do we want any convention specified (in developer-notes) at all, and enforce it in new code? 12:21 < wumpus> luke-jr: exactly - and that's what happens, because we have abandoned the style a long time ago and don't describe it in the style doc 12:21 < cfields> any convention that ties a variable to a type is broken imo 12:21 < luke-jr> Unicode var names? 12:21 < wumpus> cfields: RIGHT 12:21 < jtimon> is this about gArgs ? 12:21 < luke-jr> no 12:21 < wumpus> people mimic the style but don't know what it means 12:21 < wumpus> they should stop mimicing the style too 12:22 < sipa> wumpus: the only way that's going to happen is by prescribing a style to use in new code 12:22 < cfields> wumpus: well, it's been common practice to mimic the code around your changes 12:22 < gmaxwell> cfields: yes but mimiking the style of hungarin notation and getting it wrong misses the point of it. :P 12:22 < sipa> i've come to dislike the "mimick the code around you" suggestion - it does not lead to consistency 12:22 < wumpus> gmaxwell: haha exactly... something with cargo cults 12:22 < luke-jr> sipa: okay, let's switch to tabs instead of spaces then 12:22 < luke-jr> :P 12:23 < gmaxwell> I'm not aware of any evidence supporting any of these highly structured variable name recommendations as actually providing benefits. 12:23 < jtimon> sipa: right, people do it naturally, but I don't think it should be a convention 12:23 < wumpus> gmaxwell: +1 12:23 < paveljanik> nah, these TAB/spaces wars: delete all indentation and let editor choose the right indentation! ;-) 12:23 < cfields> gmaxwell: m_foo and g_foo are extremely helpful imo 12:23 < cfields> but not much else 12:24 < luke-jr> paveljanik: that's what tabs do 12:24 < gmaxwell> (esp since pretty much no one is sadistic to encode the full type into the name.) 12:24 < paveljanik> nono, tabsonly compress. No TABs/spaces... 12:24 < wumpus> sure, including the scope might be reasonably useful, unlike encoding the type 12:24 < luke-jr> maybe we should use C++ mangled names 12:24 < wumpus> but I'm not looking forward to sweeping code style changes 12:24 < sipa> sigh, nobody is talking about encouraging structured variable name recommendations 12:25 < wumpus> before you know it there are 10 PRs open for renaming variables (again, after the shadow fiasco) 12:25 < jtimon> gmaxwell: I've seen some sadistic java code that was close 12:25 < luke-jr> I like the "style changes only affect new code" policy 12:25 < sipa> luke-jr: me too 12:25 < cfields> sipa: maybe suggest the kind of style policy you have in mind? you mean simple things like camelCase vs under_score? 12:25 < sipa> and even exclude purely moved code 12:25 < wumpus> yes - feel free to write up a style recommendation for new code 12:25 < kanzure> would be nice to have style preference mentioned in docs 12:25 < sipa> cfields: either of those is fine 12:25 < sipa> cfields: but one, not both 12:26 < wumpus> and consistency is good, but please don't be a jerk about it, especially not to new contributors 12:26 < jtimon> ack only one not both 12:26 < jcorgan> my experience is that code is read far more often than it is written, and especially so if it serves as documentation 12:26 < sipa> if i had to choose, i'd say under_score - that's what STL uses 12:27 < jcorgan> when code has disjoint styles, people reading it might wonder if it is different for a reason, or just an accident 12:27 < jtimon> or maybe camelCaseForVariables, UNDER_SCORE_FOR_CONSTANTS 12:27 < sipa> and i'm also fine m_X and g_X if that considered useful 12:27 < morcos> My only real contribution to this discussion is whatever we decide on should be clearly spelled out in developer documentation, so we can just point to it over and over gain. Otherwise we'll come away with an agreement that means somethign different to each party. 12:27 < jtimon> since I believe that's closer to what we have 12:27 < wumpus> morcos: yes yes yes 12:27 < gmaxwell> I'm not a fan of the camelcase, because then you get things wrong based just on the case. seems weird. 12:27 < jcorgan> morcos: now when did that happen recently? 12:27 < luke-jr> camel case isn't bad, but it creates the hungarian confuson 12:28 < gmaxwell> luke-jr: that too 12:28 < sipa> camelcase also is easily confused with hungarian 12:28 < sipa> what luke-jr said 12:28 < wumpus> morcos: most important to get it into a document in the repository, as to make clear reviewrs aren't forcing their personal style preferences 12:28 < jtimon> super ack to morcos suggestion, if it's not documented, it is simply not a convention 12:29 < cfields> morcos: ok, so camelCase today, and hard-fork in a month? 12:29 < cfields> :p 12:29 < jcorgan> my heuristic is, if you can't tell that a body of code was written my multiple authors over time, that's a win 12:29 < luke-jr> let's simply agree for variable names on bit 4. the rest can be subjective. 12:29 < sipa> so, if i would create a PR that added to the dev documentation "For new code, the following style for variables is encouraged: local_variable for local variables, m_variable for members, g_variable for globals" 12:29 < luke-jr> local_* seems annoying 12:29 < sipa> luke-jr: oops, i didn't mean that as a prefix 12:29 < luke-jr> k 12:29 < gmaxwell> I still don't know when to ask someone touching code to fix things per documented style or not. E.g. 10441 cfields introduces both new braced and unbraced iffs in a function that contains both. 12:30 < sipa> variable, a_variable, j, var, bla, foo, ... all good 12:30 < morcos> gmaxwell: he should fix that 12:30 < gmaxwell> okay. I'll nitpick then. 12:30 < wumpus> gmaxwell: if it's cfields you should certainly make him aware of it, he's supposed to know better :) 12:31 < cfields> heh, yes. I think that was a mix of matching nearby code and copy/paste 12:31 * wumpus ducks 12:31 < jtimon> I think moving away from camel case it's the most disruptive option for local variables 12:31 < jtimon> but no strong opinion 12:31 < cfields> i'd certainly never make that mistake again if we added "don't attempt to match nearby code" to the style doc 12:31 < sipa> it's already often used for loop variables etc 12:31 < luke-jr> variables were never camel-case..? 12:31 < jtimon> just saying that it would be nicer if the style was as close as possible to what we have now 12:31 < cfields> without that, i'd never add another unbraced if :) 12:31 < wumpus> abandoning the camels for the snakes 12:32 < sipa> luke-jr: sure some where, CBlockIndex* pindexBlock = ... 12:32 < luke-jr> sipa: that's just hungarian 12:32 < sipa> luke-jr: hungarian is just a more constrained camelcase 12:32 < luke-jr> camelcase is where you use it as a word separater.. 12:32 < sipa> cfields: ack on adding "Do not attempt to match nearby code, unless you're creating a move-only commit" 12:32 < morcos> sipa: +! 12:32 < morcos> 1 12:32 < jtimon> luke-jr: well if camel case it's less common than underscore for variables then my argument goes away 12:33 < jtimon> I really don't know for sure, was just guessing 12:33 < sipa> luke-jr: and hungarian is using case as word separator, plus the requirement that the first word is the type :) 12:33 < morcos> i'll defer to group, but i prefer camel to underscores, but do like at least identifying global variables with g_ or :: or something 12:34 < luke-jr> gCamel/mCamel wouldn't be terrible 12:34 < gmaxwell> I would ACK doing something consistent for globals. 12:34 < sipa> anyway, any comments on those suggestions? encouraging lowercase + underscore for local variables, and m_ for members, g_ for globals, and a mention to not mimick surrounding code? 12:34 < wumpus> I prefer snakecase like sipa 12:34 < gmaxwell> One thing I don't like about C++ is that when there is a variable that isn't local I dunno if its coming from the class or if it's a global... without going and digging in other files. 12:35 < cfields> gmaxwell: hence m_ :) 12:35 < gmaxwell> so if naming helps disambiguate that I would not be unhappy. 12:35 < wumpus> for variable names, for method names we should obviously keep sticking to camelcase 12:35 < morcos> are we ok with combining small words without the udnerscore like feerate or blocksize or something? 12:35 < sipa> wumpus: agree, and class names as well 12:35 < wumpus> sipa: yes 12:35 < sdaftuar> bit_coin right? 12:35 < sipa> morcos: ack from me 12:36 < wumpus> sdaftuar: it's better than BitCoin 12:36 < sipa> one lowercase word is totally fine for local variables 12:36 < wumpus> yes 12:36 < cfields> sipa: ack all of the above 12:36 < luke-jr> I prefer camelcase, except for the annoying conflict w/ hungarian 12:36 < luke-jr> I don't care strongly tho 12:36 < sipa> oh, what to do with the cs_* variables we have now? 12:37 < sipa> do we want an exception for that? 12:37 < morcos> oh ok, so we're keeping camel for class and method names and snake for variables.. ok someone write it up 12:37 < gmaxwell> I would be fine with an exception for cs_. 12:37 < wumpus> cs_ for locks? it's fine with me 12:37 < sipa> so... g_blockindex g_cs_blockindex? 12:37 < wumpus> though I still thing the scope is more useful 12:37 < morcos> but no exception for pblockindex ? 12:38 < sipa> that's hungarian - dia 12:38 < sipa> die 12:38 < sipa> ;) 12:38 < wumpus> pblockindex could just be block_index 12:38 < sipa> indeed 12:38 < wumpus> though we aren't actrually going to rename variables en-messe 12:38 < cfields> [11:17:50] -*- cfields would kill for m_ == member 12:38 < cfields> [11:18:13] pls don't kill 12:38 < sipa> wumpus: indeed 12:38 < gmaxwell> cfields: thou shall not kill 12:38 < sipa> i'll write up a PR, and we discuss there further? 12:38 < gmaxwell> is all I think luke was saying. 12:38 < luke-jr> yes 12:38 < morcos> sounds good 12:39 < sipa> ok, topic closed 12:39 < gmaxwell> sipa to do all the work, agreed. 12:39 < wumpus> I don't want to see any more variable renaming PRs, the Wshadow war made me so tired of that 12:39 < wumpus> other topics? 12:39 < luke-jr> BIP148 12:39 < morcos> next topic 12:39 < wumpus> I have nothing to say about that, at least 12:40 < wumpus> but i f you insist 12:40 < wumpus> #topic BIP148 12:40 < jonasschnelli> I guess we have already enough comments on the PRs.. 12:40 < sipa> my opinion is that it would go against our principles to merge BIP148 into core 12:40 < luke-jr> sipa: how so? 12:40 < BlueMatt> sipa: +100 12:41 < sipa> i've given my opinion more than enough on existing PRs 12:41 < sipa> i strongly disagree with the "less safe" argument 12:41 < wumpus> right, I think everyone already had their say on this 12:41 < sipa> and we shouldn't encourage forks in the network 12:41 < sipa> nor is it out place to push for consensus changes 12:41 < luke-jr> so we should put users at risk by refusing to enforce the new rule? 12:41 < wumpus> let's merge BIP149 instead 12:41 < luke-jr> sipa: refusing to merge is what encourages the fork in this case 12:41 < sipa> luke-jr: i strongly disagree that it puts users more at risk 12:42 < gmaxwell> wumpus: I brought up 149's timeout on the list, but its author hasn't replied, I think it is needlessly long. 12:42 < morcos> My opinion closely matches sdaftuars from : https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014377.html 12:42 < luke-jr> not only does not-merging it encourage a chain split, it also puts users on the side vulnerable to reorg wipeout 12:42 < luke-jr> gmaxwell: I think it's too early 12:43 < morcos> I'd be in favor of 149, but I think we should start by being a bit more public about the idea and building consensus for it before actually merging 12:43 < BlueMatt> gmaxwell: ack, your proposal of 6 months seemed reasonable to me 12:43 < morcos> And eys I agree we could tweak it a bit 12:43 < BlueMatt> morcos: +1 12:43 < wumpus> gmaxwell: yes we need to agree on the timeout at lesat 12:43 < sipa> luke-jr: the only condition under which it helps users avoid a huge reorg is one under which those who didn't upgrade already experienced a (temporary, but long) fork 12:43 < jtimon> as said on the mailing list I think bip148 is rushed and that makes it risky, bip8 on the other hand...(although I'm writing suggestions for changing bip8) 12:44 < luke-jr> sipa: this seems tautological? 12:44 < jtimon> we can merge bip8 without merging bip149 yet, although the sooner it is released the more secure it will be 12:44 < sipa> luke-jr: then how is merging it less risky? 12:44 < sipa> luke-jr: it only helps in case a fork already happened! 12:45 < sipa> while at the same time encouraging said fork 12:45 < gmaxwell> luke-jr: I haven't seen the kind of support required to justify your position on that; afaict so far no exchange or payment processor of note has said they would stick with 148. I think you'd have an argument if there was any of that, but right now I think it's hard to distinguish a subsanstive level of support. (And I've seen some clearly malicious parties pumping support for it too.) 12:45 < luke-jr> sipa: if a fork happens, it puts them on the side that isn't vulnerable to a reorg, and it helps avoid the fork in the first place 12:45 < sipa> not encouraging it seems far safer than slightly reducing the risk in case it does 12:45 < sipa> luke-jr: under the assumption a hashrate majority adopts it 12:45 < sipa> luke-jr: which i think is crazy 12:45 < gmaxwell> My discussions on reddit with people promoting BIP148 seemed to be because they earniestly believed it was the only choice. 12:45 < luke-jr> sipa: BIP148 only needs about 25% hashrate to be successful 12:45 < morcos> At the end of the day I think most of us have no interest in greatly increasing the risk of a devastating currency split. I think 148 does that.. But 149 has a decent chance of not doing that if there have been no other consensus rule changes in the interim. But will require consensus building. 12:46 < gmaxwell> E.g. someone managed to convince them that the project would never adopt something like BIP149. 12:46 < sipa> morcos: +1 12:46 < sipa> it will require consensus building 12:46 < sipa> not discussions here 12:46 < BlueMatt> yup 12:46 < jtimon> gmaxwell: ack on making the period shorter 12:46 < gmaxwell> which seemed really weird to me, because I thought it was pretty obvious that a 149-like thing would be done. 12:47 < petertodd> gmaxwell: it's only obvious if people say that 12:48 < morcos> And to be clear, I think we'd all like to activate segwit via UASF before we could do so with BIP149 (and it would be feasible I think to build support in a shorter time frame), but we just don't have the technical bandwidth to code that up safely in time. 12:48 < wumpus> I think that wasn't obvioius, no 12:48 < luke-jr> if businesses get to decide protocol changes, then I guess bit 4 SW it is 12:49 < gmaxwell> luke-jr: there is a big difference between saying 'businesses get to decide' and saying that the fact that virtually no industry participant is resolute with 148 is a strong sign the support isn't significant enough. If 148 and six months or a year on its clock that would be another matter. 12:49 < sipa> gmaxwell: i don't think it's obvious that BIP149 will happen at all 12:49 < morcos> luke-jr: no one even knows what bit 4 SW is? we might like it, what if its compatible with BIP141 segwit... lets not make decisions based on a single line in a medium post. 12:49 < luke-jr> in the meantime, a sizable portion of the community will be enforcing BIP148, and with success eventually replacing the non-compliant chain 12:50 < luke-jr> gmaxwell: it's only virtually none if you exclude the ones who have supported it 12:50 -!- Joseph__ [~NewLibert@ip-64-134-71-216.public.wayport.net] has joined #bitcoin-core-dev 12:50 < jonasschnelli> luke-jr: that's speculation 12:50 < petertodd> luke-jr: while technically the result of bip148 may be a reorg, in practice if there is a non-trivial split the result will be two currencies, as someone will launch a currency based on a checkpoint 12:50 < jonasschnelli> You can't measure "community" 12:50 < gmaxwell> luke-jr: maybe I'm just not aware then. 12:50 < sipa> luke-jr: i hope you're right, but my expectation is that every economically relevant full node will revert away from bip148 code hours after the hashrate fails to adopts it 12:50 < morcos> luke-jr: I would hope that BIP148 and BIP149 supporters are able to agree at least that they should all support the same thing. 12:51 < luke-jr> sipa: Bitfury has already agreed to enforce BIP148 if the bit-4 thing doesn't activate Segwit by August 12:51 < petertodd> sipa: depends on how much hash rate... lots of incentive for exchanges to support it and let the two coins trade against each other 12:51 < jonasschnelli> sipa: I guess they have also agree (among others) to run Classic 12:51 < jonasschnelli> (meant luke-jr) 12:51 < sipa> luke-jr: well, i hope you're right 12:51 < sipa> but i'm very skeptical about that 12:52 < sipa> topic suggestion: high-priority PRs? 12:52 < luke-jr> if we're divided in opinion on this, we should at *least* give users the choice, even if they want to stick to Core releases 12:52 < gmaxwell> If 148 managed to get the kind of support needed to result in avoiding a chain split, I'm fine with that. But I think it's a very poor and needlessly risky approach. 12:52 < sipa> luke-jr: users already have a choice to not run Core 12:52 < morcos> luke-jr: you already have a release process, release Knots with the option. 12:53 < luke-jr> sipa: many don't want to choose that 12:53 < jonasschnelli> maybe for a reason? 12:53 < sipa> luke-jr: for good reasons, because we don't do reckless things 12:53 -!- NewLiberty_ [~NewLibert@ip-64-134-71-216.public.wayport.net] has joined #bitcoin-core-dev 12:53 < gmaxwell> luke-jr: then perhaps because the realize that we've usually had good judgement... 12:53 < kanzure> what was the default in the bip148 paramflag pull request? 12:53 < petertodd> kanzure: false 12:53 < jcorgan> off 12:53 < luke-jr> gmaxwell: and in this case, we disagree on that judgement. 12:53 < petertodd> kanzure: I wouldn't have concept acked it otherwise... 12:53 < BlueMatt> alright, next topic 12:53 < jtimon> alright, sent suggestions to change bip8 to the mailing list... 12:54 < sdfkjs23> deciding what choices users do or do not get seems overly political to me, if core developers want to make a political statement that's fine, but pretending to be neutral and not allowing an optional switch for bip148 seems disingenuous 12:54 < kanzure> with context of "default off" some of the above comments make less sense 12:54 < cfields> oh, quick topic suggestion: 0.14.2 12:54 < jonasschnelli> sdfkjs23? You can offer it yourself by forking and deploying or patching? 12:54 < gmaxwell> jtimon: I don't think we should change BIP8 generally: the reason we can do a shorter termination with SW is because we've already done one deployment-- so we know what the uptake looks like and how fast it went the first time. 12:54 < petertodd> sdfkjs23: there's a multiple of optional switches that we could add to be neutral - we're not going to add them all, thus we have to make some kind of (hopefully conservative) political statement 12:54 < cfields> (sorry, forgot all about it. we can pick it up after the meeting) 12:55 < luke-jr> jonasschnelli: too many people (and especially companies) refuse to run anything unless Core releases it 12:55 < luke-jr> jonasschnelli: it sucks, but it's reality 12:55 < gmaxwell> sdfkjs23: Offering users settings we believe will harm third parties and the user is not 'neutral'. 12:55 < kanzure> luke-jr: they want default-off merged and that's what will get them interested in bip148? 12:55 < wumpus> #topic 0.14.2 12:55 < jtimon> gmaxwell: the changes are just for providing warnngs in unkown deployments, like bip9 did 12:55 < jonasschnelli> luke-jr: But core is consensus among devs for a reason. And I guess we mostly (never?) merged controversial consensus changes 12:55 < gmaxwell> sdfkjs23: if users want 'neutral' they have a copy of GCC, they can write their own node. 12:55 < petertodd> gmaxwell: +1 12:55 < wumpus> let's do a 0.14.2 soon, even if just for the UPNP CVE 12:55 < gmaxwell> (want neutral in that sense) 12:55 < luke-jr> gmaxwell: we don't all believe that in this case. some of us admit that it's riskier to NOT enforce BIP148 12:55 < wumpus> (of course we want to include some other fixes as well) 12:56 < gmaxwell> sdfkjs23: sofware worth running is always opinionated in many ways, even if you don't realize it. 12:56 < luke-jr> jonasschnelli: it's controversial to fail to enforce the softfork now 12:56 < gmaxwell> wumpus: ack on 0.14.2 I think there are a couple other fairly modest fixes that could be backported. 12:56 < cfields> I'd like to suggest a quick 0.14.2 for the upnp and recent peer visibility fix from marcos, along with whatever else has piled up in the meantime 12:56 -!- Joseph__ [~NewLibert@ip-64-134-71-216.public.wayport.net] has quit [Ping timeout: 240 seconds] 12:56 < cfields> heh, far too slow 12:56 < sipa> sounds good to me 12:56 < jonasschnelli> ack 0.14.2 ... there is also an important GUI fix 12:56 < sdfkjs23> if that's what the main core developers want to say sure, but it's pretty clear that core is then the implementation as defined by this small group here, it is their vision and not open really to general community. 12:56 < morcos> yes i think we could use more public notice on the peer visibility fix 12:57 < wumpus> ok, please mark anything that should be backported to 0,14,2 as such 12:57 < wumpus> (or ask us to do it) 12:57 * jonasschnelli looking... 12:57 < cfields> thanks, will do 12:57 < morcos> even people who have connections, but are behind NAT are going to want to upgrade b/c eventually they wont' have connections (maybe.. i can't remember now) 12:57 < sdaftuar> incoming connections* 12:58 < morcos> yes sorry 12:58 < gmaxwell> morcos: yes, so for backport the visiblity fix, cfields open PR with the connection stuff.. 12:58 < jonasschnelli> wumpus: https://github.com/bitcoin/bitcoin/pull/10231 (closed 0.14.2 milestone... needs backport) 12:58 < jonasschnelli> (should apply IMO) 12:59 < cfields> jonasschnelli: ah, good one if it backports cleanly 12:59 < wumpus> jonasschnelli: that one is correctly marked, will port those in one go at some point (at lesat the ones that cleanly apply or need only small changes) 12:59 < sipa> sdfkjs23: it's open source, anyone can repackage the software in any way they like, and i encourage everyone to do so (as long as they don't misrepresent the choices made)... but Bitcoin Core as a project has established some practices, and those include not accepting consensus rule changes without broad support and weighing the risks - it seems most people in this room now believe that bar isn't 12:59 < luke-jr> sdfkjs23: in this case, it seems it's a minority of pessimistic devs holding back a softfork that the community largely wants and most of the devs are okay with merging, putting users who trust us collectively at a risk they shouldn't be :< 12:59 < kanzure> sdfkjs23: open-source does not mean the project must "merge anything", it means you can compile whatever patches you want. 12:59 < sipa> met for BIP148 13:00 < wumpus> it's time 13:00 < wumpus> #endmeeting 13:00 < lightningbot> Meeting ended Thu May 25 20:00:21 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:00 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-25-19.00.html 13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-25-19.00.txt 13:00 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-05-25-19.00.log.html 13:00 < jonasschnelli> sdfkjs23: with your argument we could not reject optional hard-fork proposals? Right? 13:00 < gmaxwell> luke-jr: I think you're pusing the same kind of irresponsiblity as classic did, just this time it happens to be in favor of changes I want. But I still reject it just the same, the purpose of the system is to come to consensus. Intentionally splitting it is in no ones interest except that of opponents to bitcoin. If you had an order of magnitude more support than I've seen (and perhaps I've mi 13:00 < gmaxwell> ssed some of it) OR months more to gain it-- I'd have a different view. 13:00 < jtimon> luke-jr: sdfkjs23 not merging bip148 is not taking a position against segwit or uasf, it's just being conservative 13:00 < luke-jr> gmaxwell: the split is LESS likely by merging BIP148; it isn't a hardfork 13:01 < luke-jr> jtimon: it's not conservative when it increases the risk 13:01 < sipa> luke-jr: i think you're insane 13:01 < sdfkjs23> i've been following development for some time, i was under the false impression that core was intended to be the 'reference' client, just a generalized client that is neutral towards any consensus changes 13:01 < jtimon> luke-jr: but we don't accept your premise 13:01 < BlueMatt> luke-jr: wut 13:01 < sipa> a split is less likely by merging a consensus change a few months agead of time? 13:01 < paveljanik> luke-jr, in reality, it can even be much worse. People could signal UASF but not enforce it. 13:01 < kanzure> gmaxwell: i think luke-jr is arguing that there is support for bip148 if default-off bip148 is merged. but only on condition of that sort of endorsement from core. seems like a chicken-egg scenario, so perhaps caution is warranted. 13:01 < luke-jr> great, now we get ad hominems as argument 13:01 < gmaxwell> luke-jr: I don't think it's that precise to say that it isn't a hardfork. In the sense that there is a nearly guarenteed hardfork (a miner violating it) which will happen. 13:01 < sipa> luke-jr: apologies for the ad hominem... but i believe your argument it nonsense 13:02 < gmaxwell> luke-jr: with softforks we have historically staged things to minimize the risk of block orphaning, so no hardforked blocks. 13:02 < luke-jr> paveljanik: the signal is irrelevant 13:02 < gmaxwell> kanzure: I haven't seen that. 13:02 < kanzure> haven't seen evidence of community requiring endorsement from core by merging? 13:03 < BlueMatt> luke-jr: if it were true that a vast, vast majority of users, businesses, and miners were not only supporting 148 but actually honestly committing to running it irrespective of what their peers do, maybe, but that is blatanly obviously not the case 13:03 < paveljanik> luke-jr, yes. I also do not think where people get "large support" in the community for BIP148 etc. 13:03 < jtimon> gmaxwell: I disagree, I see it as a controversial softfork 13:03 < sipa> sdfkjs23: bitcoin core implements bitcoin's consensus rules... we need to make a judgement about what those rules are, as they can change and are not under our control 13:03 < luke-jr> BlueMatt: it seems to be the case, perhaps minus businesses 13:03 < gmaxwell> sdfkjs23: nonsense. we are not netural. E.g. We support Bitcoin and are not ambivilant towards things that would damage it. Would you suggest the project also merge a switch that if set allows mtgox to make 600k bitcoin out of thin air to replace the losses, 'neutral' right? 13:03 < luke-jr> BlueMatt: maybe it's not obviously the case, but it certainly isn't obviously NOT the case 13:03 < morcos> luke-jr: even you think only 10% of nodes are running bip148 right? 13:04 < gmaxwell> jtimon: you have a lot of weird opinions. 13:04 < BlueMatt> luke-jr: would you like me to buy you a plane ticket so you can talk to people? 13:04 < luke-jr> jtimon: Segwit itself is a controversial softfork; that's only a barrier for hardforks 13:04 < BlueMatt> I'd be happy to 13:04 < BlueMatt> you spend too much time on reddit and not talking to real people, I think 13:04 < kanzure> BlueMatt: you can also talk with people over the internet. travel is not required. 13:04 < sdfkjs23> gmaxwell, you have a bad habit of using outrageous counter examples, they aren't analogous, please stick to the actual issues at hand 13:04 < luke-jr> morcos: so far, and that's in a short timeframe since binaries were released 13:04 < luke-jr> BlueMatt: go talk to CodeShark, who reports a lot of support in NYC 13:04 < gmaxwell> sdfkjs23: welcome to /ignore -- don't enter my channels and then lecture me on how I should debate. 13:05 < kanzure> sdfkjs23: it's only outrageus for your position from your argument-- that was the point. 13:05 < jtimon> gmaxwell: fair enough, but I think they aren't so weird, they are actually quite simple: what causes chain splits (apart from mistakes) are controversial rule changes, not whether they are hf or sf 13:05 < BlueMatt> luke-jr: I live in NY, and strongly beg to differ 13:05 < sdfkjs23> i'm being civil, and this isn't *your* channel this channel is for core development discussion 13:05 -!- gmaxwell [gmaxwell@wikimedia/KatWalsh/x-0001] has left #bitcoin-core-dev [] 13:05 < sipa> sdfkjs23: and we've now far strayed from that topic, imho 13:05 < sipa> none of this discussion belongs here 13:05 < jcorgan> gentlemen, please 13:05 < petertodd> sipa: quite correct 13:05 < morcos> luke-jr: I think a lot of people support the concept of a UASF, but I actually made it a point to ask people wearing UASF hats what that meant to them.. And many actively preferred BIP149 or something else to BIP148 13:05 < luke-jr> jtimon: what causes chain splits are negligent or malicious miners who fail to enforce the rules 13:05 < sipa> if it's clear that BIP148 is accepted by the ecosystem, then obviously it will be implemented 13:06 < sipa> usually we don't discuss consensus changes here at all 13:06 < petertodd> morcos: indeed, I prefer bip149 13:06 < luke-jr> morcos: preference isn't the question, though. BIP148 is happening, so the question is how many will support and go along with it 13:06 < petertodd> luke-jr: we have to design systems that are robust to negligent and malicious miners 13:06 < sdfkjs23> bip148 was brought up as the topic -- it appears the current argument against it (it is hard to follow because this changes very rapidly) is that there isn't enough 'community' support even though no one can argee on how to even measure it 13:06 < luke-jr> petertodd: and BIP148 does, so long as people enforce it 13:06 < jtimon> luke-jr: let's say halfthe users want to increase the monetary limit to 22 M but the other half doesn't: both chains will be mined and used 13:07 < luke-jr> jtimon: that's not a softfork 13:07 < sipa> sdfkjs23: a consensus change merged a few months before it happens is madness 13:07 < sipa> we hardly have time to create a release in that time 13:07 < luke-jr> sipa: yet you want to delay the merge longer? 13:07 < jonasschnelli> sdfkjs23: this channel is specific for bitcoin-core (the client) development. General bitcoin protocol and consensus discussion shall happen in #bitcoin-dev 13:07 < jtimon> that is a controversial hardfork, let me think of a controversial softfork example 13:07 < sipa> luke-jr: my expectation is that bip148 will not have any effect, but i hope i'm wrong 13:07 < sdfkjs23> a switch which woudl easily allow the community to opt in is now being rejected by 3 or 4 core developers because they find it dangerous 13:07 < luke-jr> jtimon: in this case, it's not controversial anyway 13:07 < jtimon> let's say half the users want to some aml softfork feature 13:07 < sipa> sdfkjs23: then don't run Core; i beg you 13:08 < luke-jr> at least not more controversial than Segwit itself 13:08 < sipa> the maintainers of this software shouldn't determine what the network's consensus rules are 13:08 < jtimon> luke-jr: to me it is controversial on grounds of the deployment plan alone 13:08 < jtimon> like bip109 was 13:09 < jtimon> I mean, that was controversial for other reasons too, but I think you get my point 13:09 < luke-jr> I don't. 13:09 < Lauda> which is why Core should add opt-in consensus proposals, not opt-out 13:09 -!- sipa [~pw@unaffiliated/sipa1024] has left #bitcoin-core-dev [] 13:09 < morcos> luke-jr: sdfkjs23: Lets be clear, the resistance here isn't against UASF, or even a UASF for segwit. It's against the particular activation methodology and schedule for BIP148. It would behoove us all to try to build support from current BIP148 activists for 149 or another more cautious path 13:10 < jonasschnelli> morcos: +1 13:10 < jtimon> +1 13:10 < kanzure> luke-jr: have you considered something like bip148 except with best chain tip selection weighted by segwit-signalling? instead of blanket rjeection of all blocks, you'd get competing long reorgs, which is arguably better than rejecting all blocks. 13:11 < kanzure> wait, no, not better. 13:11 -!- grubles [~grubles@unaffiliated/grubles] has quit [Excess Flood] 13:11 < luke-jr> What "activation methodology" besides UASF are you referring to? 13:11 < kanzure> it's better so long as your confirmation threshold is longer than the reorg length :P 13:11 < jcorgan> this is #bitcoin-dev or even #bitcoin territory, can we please get back to business 13:11 < morcos> luke-jr: you could help, if you wanted to avoid a split, by making the argument that at this point BIP148 doesn't HAVE to happen. Since you are such an advocate for 148, maybe others would take some advice from you if you felt another path safer 13:11 < luke-jr> kanzure: I couldn't change BIP148 if I tried. 13:11 < jonasschnelli> What jcorgan said... 13:11 < kanzure> luke-jr: i said "something like bip148" 13:11 < luke-jr> morcos: the ONLY way to avoid the split is to make sure BIP148 succeeds. It WILL happen. Nobody can change that. 13:12 < morcos> ok. yeah i'm done discussing in this channel. agreed. 13:12 < jtimon> if I proposed something like bip148 but actiavting next week instead of august, would you ack that if some users support it? 13:12 < luke-jr> and BIP149 is NOT safer anyway. 13:12 < jtimon> of course it is, but yeah, let's go #bitcoin or something 13:12 < luke-jr> jtimon: it's not "some users", it's a LOT of users, perhaps even a majority already 13:13 < petertodd> luke-jr: chances are the majority of bitcoin users aren't on any social media at all you know... 13:13 < jtimon> well, if "a LOT of users" supported my like-bip148-but-next-week proposal 13:13 < petertodd> luke-jr: they may not even speak english 13:14 -!- grubles [~grubles@45.76.177.92] has joined #bitcoin-core-dev 13:14 -!- grubles [~grubles@45.76.177.92] has quit [Changing host] 13:14 -!- grubles [~grubles@unaffiliated/grubles] has joined #bitcoin-core-dev 13:14 -!- sipa [~pw@unaffiliated/sipa1024] has joined #bitcoin-core-dev 13:18 < paveljanik> luke-jr, from where you get "a lot of"? 13:22 < instagibbs> discussion has been moved to #bitcoin, fwiw... 13:28 < paveljanik> great. I can't follow such intense communication though :-) 13:30 -!- deego [~user@unaffiliated/deego] has joined #bitcoin-core-dev 13:33 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Ping timeout: 240 seconds] 13:43 -!- dstadulis [~dstadulis@198-27-188-46.static.sonic.net] has joined #bitcoin-core-dev 13:46 < morcos> sipa: are you interested in briefly describing how we'd do away with rescan? 13:47 < sipa> morcos: requiring birthdays on all imports 13:48 < sipa> and rescanning on demand, rather than explicitly 13:51 < morcos> sipa: i've found that sometimes there is a need to import multiple keys in a short period. forcing that to happen in a single importmulti call is a bit cumbersome 13:52 < morcos> it can be easier to do a batch of all the imports with rescan false, and then later do 1 explicit rescan 13:52 < morcos> anyway, thats just my opinion 13:54 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Quit: conversation terminated!] 13:54 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 13:55 -!- cryptapus is now known as cryptapus_afk 13:57 < sipa> morcos: rescanning could also move to a background job 13:57 < sipa> which just restarts if needed 13:57 < jtimon> that sounds simpler 13:59 < jtimon> maybe a rescanning progress bar in the gui, seems very usable, and maybe in the rpc if you ask for imported stuff that needs rescaning and rescan is in progress, throw an error 13:59 < morcos> i don't know about simpler, but yeah a better design 13:59 < jtimon> yeah, I guess I meant simpler to use 13:59 < da2ce7> On a slightly related topic, what contingency planning is there for the case that BIP148 has a non-zero hash-power? 14:00 < da2ce7> That would force all the non-bip148 nodes to checkpoint for continued safe operation. 14:00 < da2ce7> Is there a way to distribute such a checkpoint in a safe manner? 14:01 < da2ce7> Or dose Bitcoin Core not want to merge in such code? 14:01 < jtimon> if bip148 gets the hashrate majority we don't need to do anything 14:01 < jtimon> we will reorg to their chain 14:02 < da2ce7> jtimon, what happens if it has 10%. Then all non-BIP148 nodes are zombie until they checkpoint. 14:02 < sipa> ?? 14:02 < jtimon> no, no zombie, we go on with the majority chain which is also valid to us 14:02 < da2ce7> This is fine, except the risk is asymmetrical. 14:03 < sipa> da2ce7: i don't understand what risk you're even talking about 14:03 < da2ce7> Because if at any date in the future the BIP148 chain overtakes, the non-BIP148 chain will be wiped out. 14:03 < sipa> yes? 14:04 < jtimon> that's what I said, if it gets the hashrate majority non-bip148 nodes will follow their chain, no problem 14:04 < jtimon> I mean, apart from maybe a big reorg 14:05 < da2ce7> If I disagreed with BIP148, I would checkpoint so my transactions wound't face the wipeout risk. The same if for example if BIP148 as replaced with "evil softfork". 14:05 < jtimon> I will wait and see with my node 14:06 < sdfkjs23> a large reorg will cause issues for everyone not paying attention -- or anyone who goes along with cores deployment at this time. essentially core development team is handling the risk for the end client instead of allowing the client to manage the risk with a optional switch. 14:06 < da2ce7> If Bitcoin XT was a soft-fork, I would checkpoint so that my node would NEVER reorg onto their chain, even if they gain a majority hashrate. 14:06 < sipa> you can use invalidateblock 14:06 < sipa> to force your node onto another chain 14:07 < jtimon> oh, I didn't know that option 14:08 -!- Giszmo1 [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Ping timeout: 268 seconds] 14:10 < da2ce7> My personal view is that the risks involved in BIP148 (a partial fix) are less than the risks covert CVE-2017-9230 continuing for a minimum of another 6mth. So I have decided to run BIP148 on my nodes. 14:12 < da2ce7> However it is always a trade-off of risks between mitigating a security vulnerability and the risks of the deployment of the security mitigation. 14:12 < sdfkjs23> core should probably note in the release notes that running their software after august 1st could result in a large reorg 14:16 < da2ce7> It is my view that the miners who don't use covert asicboost have a very strong incentive to support the swiftest deployment of any mitigation of CVE-2017-9230, including BIP148. Hence, I expect the mining power for BIP148 to be similar to the mining power that signals for SegWit now. 14:17 < da2ce7> At this hash-rate the changes of BIP148 failing are very small. 14:18 < da2ce7> *chances. 14:24 < da2ce7> I'm assuming that the miners who support SegWit are don't just support it out of the "good of their heart" but because it partly-mitigates a unfair competitive advantage against them. 14:30 -!- NewLiberty_ [~NewLibert@ip-64-134-71-216.public.wayport.net] has quit [Ping timeout: 240 seconds] 14:39 -!- quark [25872274@gateway/web/freenode/ip.37.135.34.116] has joined #bitcoin-core-dev 14:39 -!- quark is now known as Guest26217 14:39 < jtimon> I really feel I'm missing something here: https://github.com/bitcoin/bitcoin/commit/15ac75f65e6712339f13dd55b401d1b13a94ab41#commitcomment-22285343 and https://github.com/bitcoin/bitcoin/commit/c10271e46f9bba621c4a9943e53d87a792836be5 14:41 < jtimon> I don't know much about the p2p part, but I really don't get it 14:42 -!- Guest26217 is now known as quarkionk 14:43 -!- quarkionk [25872274@gateway/web/freenode/ip.37.135.34.116] has quit [Client Quit] 14:43 < da2ce7> I have been taken back by the core developers from the lack-of-response to my posts on AsicBoost, now CVE-2017-9230. I would have expected that there would be some sort of announcement about the risks and possible mitigation of an accepted Security Vulnerability. - I have not received any negative feedback; In my mailing list post I received three positive responses. - Yet, here I'm met with silence. 14:44 < jtimon> oh, I didn't read this part in the bip: "This deployment is incompatible with the BIP9-segwit deployment and should not be run concurrently with it.", but I really don't understand why, please, help undesrtanding very welcomed 14:47 < sipa> da2ce7: i don't know what you think we can do? 14:48 < da2ce7> Well, at least say: "No you are stupid! The risk of another 6 to 9 mth of Covert ASICBOOST are far-less than the risks of being seen to support BIP148". 14:48 < jtimon> I think we could deploy the proposed fix to covert asicboost with bip8 pretty fast, but maybe still not august 14:48 < sipa> that's something the whole ecosystem needs to decide on 14:49 < jtimon> I mean, miners could accelerate it, I mean the max deployment time 14:50 < jtimon> but for segwit there's already an ongoing activation coordination deployed in many nodes 14:52 < sipa> da2ce7: my personal opinion is that bip148 is reckless even if it succeeds... 14:53 < sipa> it being a solution for some forms of asicboost is not nearly a reason to abandon safe practices 14:53 < sipa> but that's my personal opinion, and others may have another 14:53 < deego> newbie q: how can it just succeed. It has to first be committed, right? right now, it's just a B I "proposal", right? 14:54 < Chris_Stewart_5> sipa: Would you support BIP148 that *only* solves covert ASICBOOST? No segwit stuff involved 14:54 < sipa> Chris_Stewart_5: my problem with bip148 is its deployment, not its rule changes 14:54 < jtimon> right, if that's the urgency let's do just that faster without taking unnecessary risks 14:54 < sipa> it being about asicboost or segwit is orthogonal 14:55 < sipa> deego: it's open source; bitcoin core is a software project, we don't decide or try to tell people what code they should run 14:55 < Chris_Stewart_5> gotcha. I'm interested in solving covert asicboost first because I doubt we are going to get support from the mining majority to solve that, but I'm fairly confident the economic majority would support it 14:55 < jtimon> I wouldn't be sure how to write the code, but it is said that the pre-segwit fix of covert asicboost is simple to implement 14:55 < sipa> and it's not just a proposal... there is software out there that implements bip148 14:55 < Chris_Stewart_5> if we are going to do some sort of UASF.. 14:56 < deego> sipa: i see, thanks 14:56 < jtimon> Chris_Stewart_5: I'm all for adding a bip8 deployment for the covert asicboost fix, and its final activation can be earlier than nov 2017 I think 14:57 < Chris_Stewart_5> jtimon: I like that idea. When is the next release scheduled for core? 14:57 < da2ce7> For me, BIP148 is a reasonable for an emergency soft-fork. Are we fixing an emergency security vulnerability? The more I study CVE-2017-9230, the more I'm inclined to say Yes. 14:57 < jtimon> I mean, I say this because I expect a patch with very little changes, perhaps I'm being too optimistic 14:58 < da2ce7> There is no faster potentially viable rollout of this partial mitigation. 14:58 < jtimon> I believe 14.2 when it's ready, but you could even put it in a 14.3 if this is not ready by the time 14.2 is released 14:58 < da2ce7> With core support it goes to about 100% viable. 14:59 < sipa> da2ce7: i don't understand the need for emergency 14:59 < da2ce7> Bitcoin isn't Bitcoin if there is only one miner. AsicBoost has a exponentially growing advantage for miners who adopt it. 14:59 < sipa> please 15:00 < da2ce7> So it's effect starts off small, but as miners re-invest profit, the effect gets larger. 15:00 < jtimon> I generally disregard claimed needs for emergency, but the simpler it is, the less conservative you need to be with deployment schedules I think 15:00 < Chris_Stewart_5> da2ce7: I think it would be wise to separate the concerns of segwit and covert asicboost 15:00 < sipa> don't use the word exponential where you just mean big 15:00 < sipa> yes, the effect of asicboost may be terrible - or may not exist at all 15:00 < sipa> and i would very much like to fix it 15:01 < sipa> but not with a hasty patch that encourages forking the chain 15:01 < jtimon> Chris_Stewart_5: I agree on separating concerns, I believe that was precisely what gmaxwell's proposal was about 15:01 < sipa> we're better than that 15:01 < da2ce7> I mean, if you have a constant factor advantage in mining, over time that advantage is exponential against your competition that doesn't have this constant factor advantage. - Unless my understanding of the gamer-theory is wrong. 15:03 < jtimon> sipa: let's say (as an example, not an actual proposal) the asicboost fix is included in 14.3 with bip8, minimum activation by miners august, final activation dec 2017, would you say that is conservative enough? 15:03 < sipa> jtimon: with clear community acceptance 15:04 < Chris_Stewart_5> da2ce7: Are you talking about generically using the deployment mechanism specified in BIP148, or BIP148 itself? BIP148 only pertains to segwit IIRC 15:04 < sipa> jtimon: it's not a boolean 15:04 < sipa> jtimon: but the riskier a change is, the higher the bar for acceptance 15:04 < da2ce7> Chris_Stewart_5: SegWit is the only well-tested partial-mitigation of CVE-2017-9230 I know of. 15:04 < da2ce7> So I mean BIP148, activating SegWit. 15:05 < sipa> and i think bip148 is both high risk, and with very unclear support 15:05 < Chris_Stewart_5> sipa: Would worst case be similar to what happened a few years back with BIP66 (or 62)? 15:05 < jtimon> sipa: fair enough, yeah, I'm all for community acceptance, maybe I'm over optimistic about the community wanting the covert asicboost fix 15:07 < Chris_Stewart_5> da2ce7: Yeah, but I think we need to deal with realities of the baggage that comes along with segwit 15:07 < jtimon> but from my conversations with users, it seems pretty clear to everyone that nobody would oppose to such a change unless is benefitting directly from covert asicboost, which nobody seem to claim 15:07 < da2ce7> jtimon, I have no idea how the time to validate the asicboost fix faster than deploying SegWit. The logical soft-fork afterwards with BIP 8 would be to make Witness Commitments non-voluntary. 15:07 < Chris_Stewart_5> I think we all agree segwit is awesome, but we can't stall progress of the system anymore based on the deployment of segwit 15:07 < sipa> i think segwit is much more widely accepted than asicboost being a problem 15:08 < jtimon> da2ce7: I think gmaxwell described it in his proposal, but sadly I don't know how to translate his specification into code 15:09 < jtimon> by it, I mean activate asicboost fix before sw 15:09 < Chris_Stewart_5> I don't think there has been any consensus rule changes since segwit has been deployed, I think fixing covert asicboost would be a good way to get that ball rolling again 15:10 < da2ce7> Since SegWit is not controversial, we can deploy it as a partial mitigation of asicboost. 15:10 < jtimon> Chris_Stewart_5: me too, but yeah, as sipa points out, assuming community support and reasonable dates 15:12 < sipa> da2ce7: totally agree, i just don't think bip148 is a good or likely succesful way of doing that 15:14 < da2ce7> sipa, do you think that my assumption that the miners who signal for SegWit now are likely doing it because they want the partial-fix to AsicBoost Deployed? If so, would they reasonably support a BIP148 soft-fork? 15:22 < sipa> da2ce7: i honestly don't know 15:23 < da2ce7> this we can agree on. :) 15:24 < da2ce7> I'm going to try and refine this assumption with more evidence. With 33% mining support, I think that doing BIP148 is remarkably safe in the face of an active exploit. 15:25 < sipa> 33% of mining support, excluding miners who already signal segwit? 15:27 < da2ce7> I mean, 33% total. For upgraded node, the remaining 67% doesn't exist. - The network effects for a 33% soft-fork are huge. Because of the asymmetrical wipeout risk. 15:27 -!- EagleTM [~EagleTM@x55b4fa0f.dyn.telefonica.de] has joined #bitcoin-core-dev 15:27 < da2ce7> The only risk is that the 67% explicitly attacks the smaller chain. However this is grounds for an immediate change of PoW. 15:29 < Chris_Stewart_5> da2ce7: I don't think so. An immediate change of PoW for the majority of miners following the old rules? Seems rash to me 15:30 < da2ce7> Chris_Stewart_5, no they are not following the old rules, they implement the soft-fork, except at the same time attack the smaller chain maybe by producing 0tx blocks. 15:31 < da2ce7> This is what I mean by an 'explicit attack'. 15:33 -!- marcoagner [~user@177.99.124.166] has joined #bitcoin-core-dev 15:33 < Chris_Stewart_5> da2ce7: So you would encourage an extended chain split, which could last forever? I don't think I would support that. We need to remain on one chain 15:34 -!- marsu [~marsu@LFbn-1-12934-210.w83-199.abo.wanadoo.fr] has quit [Quit: marsu] 15:34 < da2ce7> Chris_Stewart_5 for any other exploit I would encourage a chain split to fix the exploit, In this case is no different. If the miners could make 2btc extra each block, then I would soft-fork with less than 50% to fix this bug. 15:35 < da2ce7> Even if the miners +2btc chain could last for a longer time. 15:41 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 15:42 < da2ce7> I'm going to sleep now. Goodnight all. 15:56 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mgqffioejdiubxzi] has joined #bitcoin-core-dev 16:15 -!- Squidicuz [~squid@pool-72-74-34-138.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 16:16 -!- marcoagner [~user@177.99.124.166] has quit [Quit: WeeChat 1.0.1] 16:38 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Remote host closed the connection] 16:47 -!- jchrome [~jchrome@blk-215-123-241.eastlink.ca] has joined #bitcoin-core-dev 16:48 -!- jchrome [~jchrome@blk-215-123-241.eastlink.ca] has quit [Remote host closed the connection] 16:49 -!- jchrome [~jchrome@blk-215-123-241.eastlink.ca] has joined #bitcoin-core-dev 16:58 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 17:11 -!- str4d [~str4d@27.110.123.91] has joined #bitcoin-core-dev 17:13 -!- bigboog [~jodie@blk-215-123-241.eastlink.ca] has joined #bitcoin-core-dev 17:29 < jtimon> what is the point of https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L2707 ? 17:29 < jtimon> There doesn't seem to be any case where consensusParams.vDeployments[anything].nTimeout == 0 at this point 17:29 < jtimon> not just for segwit, for anything in any supported chain 17:30 < bitcoin-git> [bitcoin] earonesty reopened pull request #10442: add a -bip148 option (master...master) https://github.com/bitcoin/bitcoin/pull/10442 17:35 -!- gmaxwell [gmaxwell@wikimedia/KatWalsh/x-0001] has joined #bitcoin-core-dev 17:59 -!- harrymm [~wayne@104.237.91.189] has quit [Remote host closed the connection] 18:00 -!- dermoth [~thomas@dsl-199-102-156-55.mtl.aei.ca] has quit [Read error: Connection reset by peer] 18:00 -!- rgod [~rgod@pool-74-103-184-166.phlapa.fios.verizon.net] has joined #bitcoin-core-dev 18:00 -!- rgod [~rgod@pool-74-103-184-166.phlapa.fios.verizon.net] has quit [Remote host closed the connection] 18:00 -!- dermoth [~thomas@dsl-199-102-156-55.mtl.aei.ca] has joined #bitcoin-core-dev 18:30 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 258 seconds] 18:35 -!- jchrome [~jchrome@blk-215-123-241.eastlink.ca] has quit [Remote host closed the connection] 18:42 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-mgqffioejdiubxzi] has quit [Quit: Connection closed for inactivity] 18:52 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev 19:03 -!- Eagle[TM] [~EagleTM@x55b56249.dyn.telefonica.de] has joined #bitcoin-core-dev 19:05 -!- EagleTM [~EagleTM@x55b4fa0f.dyn.telefonica.de] has quit [Ping timeout: 240 seconds] 19:28 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 246 seconds] 19:29 -!- d9b4bef9 [~d9b4bef9@207.38.86.239] has quit [Remote host closed the connection] 19:30 -!- d9b4bef9 [~d9b4bef9@207.38.86.239] has joined #bitcoin-core-dev 19:33 -!- owowo [~ovovo@185.9.18.99] has joined #bitcoin-core-dev 19:33 -!- owowo [~ovovo@185.9.18.99] has quit [Changing host] 19:33 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 19:43 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev 19:48 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Quit: Leaving] 19:48 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev 20:00 -!- EagleTM [~EagleTM@x4db3175a.dyn.telefonica.de] has joined #bitcoin-core-dev 20:02 -!- Eagle[TM] [~EagleTM@x55b56249.dyn.telefonica.de] has quit [Ping timeout: 246 seconds] 20:09 -!- belcher [~belcher@unaffiliated/belcher] has quit [Remote host closed the connection] 20:20 -!- RubenSomsen [~RubenSoms@1.217.138.142] has joined #bitcoin-core-dev 20:21 -!- jtimon [~quassel@117.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds] 20:42 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has joined #bitcoin-core-dev 21:30 -!- RubenSomsen [~RubenSoms@1.217.138.142] has quit [Quit: Leaving] 22:18 -!- Guest72157 is now known as juscamarena_ 22:26 -!- goatturneer [~Beatrootg@2a02:c7d:12e:100:147d:a8bf:71d3:d812] has joined #bitcoin-core-dev 22:28 -!- goatturner [~Beatrootg@2a02:c7d:12e:100:39ed:d78f:7640:153b] has joined #bitcoin-core-dev 22:28 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.] 22:30 -!- beatrootfarmer [~Beatrootg@2a02:c7d:12e:100:bcef:89ae:d449:eab3] has quit [Ping timeout: 246 seconds] 22:31 -!- goatturneer [~Beatrootg@2a02:c7d:12e:100:147d:a8bf:71d3:d812] has quit [Ping timeout: 246 seconds] 22:33 -!- goatturner [~Beatrootg@2a02:c7d:12e:100:39ed:d78f:7640:153b] has quit [Ping timeout: 246 seconds] 22:35 -!- goatturner [~Beatrootg@2.126.80.59] has joined #bitcoin-core-dev 22:45 -!- talmai [~T@c-24-147-97-55.hsd1.ma.comcast.net] has quit [Read error: Connection reset by peer] 22:46 -!- kadoban [~mud@unaffiliated/kadoban] has quit [Quit: bye] 22:50 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has quit [Remote host closed the connection] 22:56 -!- chjj [~chjj@unaffiliated/chjj] has quit [Quit: WeeChat 1.7] 22:57 -!- cryptapus_afk [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev 22:59 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 23:00 -!- dermoth [~thomas@dsl-199-102-156-55.mtl.aei.ca] has quit [Read error: Connection reset by peer] 23:00 -!- dermoth [~thomas@dsl-199-102-156-55.mtl.aei.ca] has joined #bitcoin-core-dev 23:28 -!- EagleTM [~EagleTM@x4db3175a.dyn.telefonica.de] has left #bitcoin-core-dev [] 23:29 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection] 23:31 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev 23:51 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]