--- Log opened Fri Aug 02 00:00:27 2019
00:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
00:03 -!- kcalvinalvin [~calvin@104.143.95.18] has quit [Remote host closed the connection]
00:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
00:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
00:12 -!- octomati_ [~textual@c-73-189-22-4.hsd1.ca.comcast.net] has quit [Max SendQ exceeded]
00:34 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has joined #bitcoin-core-dev
00:40 -!- rex4539 [~rex4539@2a02:587:3514:c700:208e:dd68:c646:7c08] has joined #bitcoin-core-dev
00:50 -!- mzygar [~mzygar@212.123.247.72] has joined #bitcoin-core-dev
00:51 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 245 seconds]
01:07 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has quit [Ping timeout: 245 seconds]
01:11 -!- jungly [~quassel@79.8.200.97] has quit [Ping timeout: 268 seconds]
01:12 -!- jungly [~quassel@79.8.200.97] has joined #bitcoin-core-dev
01:34 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
01:37 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has joined #bitcoin-core-dev
01:52 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev
02:00 -!- Xing` [~Xing`@141.98.102.243] has quit []
02:04 -!- theStack [51dfa506@81.223.165.6] has joined #bitcoin-core-dev
02:04 -!- DragonEyes1 [~DragonEye@139.28.218.198] has joined #bitcoin-core-dev
02:06 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev
02:10 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has quit [Ping timeout: 272 seconds]
02:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
02:12 < bitcoin-git> [bitcoin] Bushstar opened pull request #16534: [build] .gitignore add Qt Creator Makefile.am.user (master...patch-3) https://github.com/bitcoin/bitcoin/pull/16534
02:12 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
02:14 -!- inersha [~greg@193.28.36.25] has joined #bitcoin-core-dev
02:24 -!- theStack [51dfa506@81.223.165.6] has quit [Remote host closed the connection]
02:25 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
02:26 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev
02:29 -!- mzygar [~mzygar@212.123.247.72] has quit [Ping timeout: 258 seconds]
02:35 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev
02:36 -!- jonatack [d598a245@213.152.162.69] has quit [Remote host closed the connection]
02:36 -!- mzygar [~mzygar@212.123.247.72] has joined #bitcoin-core-dev
02:45 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has joined #bitcoin-core-dev
02:55 < setpill> in https://github.com/bitcoin/bitcoin/blob/master/contrib/init/bitcoind.service#L8-L9, why does the comment state "except for those explicitly specified as arguments in ExecStart="?
02:56 < setpill> surely aside from "-conf=[..]" the other daemon options can be specified in whatever conf you supply?
03:07 < jonasschnelli> setpill: I guess because the ones specified in ExecStart are overwritten by ExecStart
03:09 < setpill> Ah I see, just a matter of suboptimal phrasing then I guess
03:09 < setpill> To me it sounds like "these options need to be specified as arguments in ExecStart= because they cannot be specified in the conf"
03:09 < jonasschnelli> I guess -datadir is not possible, since datadir defines where the config file is stored...
03:10 < wumpus> yes, AFAIK the only option that cannot be specified in the configuration file is -conf, and -datadir if -conf is not used
03:10 < setpill> I don't think so
03:10 < setpill> I've used a -conf commandline option with a datadir specified in the referenced conf iirc
03:10 < wumpus> datadir only defines the standard location of the config file
03:10 < wumpus> if you override the location of the config file, you can specify a datadir in it
03:10 < wumpus> this allows putting the configuration file in a separate place e.g. /etc/ while the (writable) datadir is somewhere else
03:10 < setpill> Also, datadir implies a blocks dir but that can still be overwritten as well
03:11 < wumpus> right
03:18 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has quit [Ping timeout: 246 seconds]
03:20 < setpill> 12:10 <wumpus> yes, AFAIK the only option that cannot be specified in the configuration file is -conf, and -datadir if -conf is not used
03:20 < setpill> would a "datadir" option in the conf file found in the default location not be respected?
03:42 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev
03:54 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has joined #bitcoin-core-dev
04:17 -!- Xunie__ [~Xunie@unaffiliated/xunie] has quit [Remote host closed the connection]
04:18 -!- Xunie__ [~Xunie@unaffiliated/xunie] has joined #bitcoin-core-dev
04:28 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has quit [Ping timeout: 268 seconds]
04:29 -!- justan0theruser [justanothe@gateway/vpn/nordvpn/justanotheruser] has joined #bitcoin-core-dev
04:29 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 258 seconds]
04:46 < kanzure> replied about mailing list issues.
04:47 < kanzure> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017206.html
04:47 < jonasschnelli> kanzure: thanks!
04:48 < kanzure> jonasschnelli: "congratulations! you have volunteered to moderate!"
04:48 < jonasschnelli> kanzure: I'm not qualifying the "neutral" requirement. :)
04:49 < jonasschnelli> jokes aside: I really think I should not be a moderator
04:58 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has joined #bitcoin-core-dev
05:00 -!- DragonEyes1 [~DragonEye@139.28.218.198] has quit []
05:00 < wumpus> jonasschnelli: I agree, same reason I should not be
05:00 < jonasschnelli> Maybe someone like moneyball or jonatack
05:01 < kanzure> ideally someone opposite of my timezone (e.g. checks the moderation queue when i am usually sleeping)
05:01 < wumpus> setpill: that's a good question actually, I don't know, it might!
05:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:18 < bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/e653eeff7651...9f54e9ab9038
05:18 < bitcoin-git> bitcoin/master fa8a823 MarcoFalke: test: Bump rpc_timeout in feature_dbcrash
05:18 < bitcoin-git> bitcoin/master fa1bb53 MarcoFalke: test: Add -acceptnonstdtxn to self.extra_args[3]
05:18 < bitcoin-git> bitcoin/master fa36aa4 MarcoFalke: Test: Set -acceptnonstdtxn in feature_fee_estimation
05:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:20 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #16493: test: Fix test failures (master...1907-testRpcTimeoutBump) https://github.com/bitcoin/bitcoin/pull/16493
05:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:20 -!- lightlike [~lightlike@2001:16b8:5722:1100:d0c0:631e:b973:5e79] has joined #bitcoin-core-dev
05:27 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
05:32 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has quit [Ping timeout: 258 seconds]
05:32 -!- yen_yenny [b4f695aa@180.246.149.170] has joined #bitcoin-core-dev
05:35 < provoostenator> For todays wallet meeting, it would be good to brainstorm if there's a way to avoid all the [ci skip] commits in #16341.
05:35 < gribble> https://github.com/bitcoin/bitcoin/issues/16341 | Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub
05:35 < provoostenator> I can't figure out how.
05:36 -!- pehjota1 [~pehjota@185.103.96.147] has joined #bitcoin-core-dev
05:36 -!- yen_yenny [b4f695aa@180.246.149.170] has quit [Remote host closed the connection]
05:36 -!- yen_yenny [b4f695aa@180.246.149.170] has joined #bitcoin-core-dev
05:37 < provoostenator> It's not that I mind skipping Travis, but I would find this PR much easier to review if it moved stuff to (Legacy)ScriptPubKeyManager more incrementally.
05:37 -!- yen_yenny [b4f695aa@180.246.149.170] has quit [Remote host closed the connection]
05:52 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Ping timeout: 268 seconds]
05:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:55 < bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/9f54e9ab9038...d759b5d26a7e
05:55 < bitcoin-git> bitcoin/master 4fcb698 Sjors Provoost: [rpc] walletcreatefundedpsbt: use wallet default RBF
05:55 < bitcoin-git> bitcoin/master 9ed062b Sjors Provoost: [doc] rpc: remove "fallback to" from RBF default help
05:55 < bitcoin-git> bitcoin/master d6b3640 Sjors Provoost: [test] walletcreatefundedpsbt: check RBF is disabled when -walletrbf=0
05:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
05:55 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15911: Use wallet RBF default for walletcreatefundedpsbt (master...2019/04/walletcreatefundedpsbt) https://github.com/bitcoin/bitcoin/pull/15911
05:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
05:56 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
06:04 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Ping timeout: 272 seconds]
06:06 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/]
06:08 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has joined #bitcoin-core-dev
06:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:14 < bitcoin-git> [bitcoin] MarcoFalke pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/d759b5d26a7e...be0e8b4bff88
06:14 < bitcoin-git> bitcoin/master 8c8aa19 Antoine Riard: Add BroadcastTransaction utility usage in Chain interface
06:14 < bitcoin-git> bitcoin/master 611291c Antoine Riard: Introduce CWalletTx::SubmitMemoryPoolAndRelay
06:14 < bitcoin-git> bitcoin/master 8753f56 Antoine Riard: Remove duplicate checks in SubmitMemoryPoolAndRelay
06:14 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
06:15 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #15713: refactor: Replace chain relayTransactions/submitMemoryPool by higher method (master...2019-03-refactor-relay-tx-submit-pool) https://github.com/bitcoin/bitcoin/pull/15713
06:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
06:23 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
06:31 -!- keifis [276e9460@fp276e9460.knge108.ap.nuro.jp] has joined #bitcoin-core-dev
06:40 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has quit [Ping timeout: 245 seconds]
06:45 -!- davterra [~none@209.58.185.33] has joined #bitcoin-core-dev
06:50 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev
06:56 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-cifrxgtyifyocxrl] has joined #bitcoin-core-dev
07:01 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has quit [Ping timeout: 260 seconds]
07:03 -!- sdaftuar [~sdaftuar@gateway/tor-sasl/sdaftuar] has joined #bitcoin-core-dev
07:09 < ariard> at what time is wallet meeting ? I would like to get feedbacks on the rework of rescan logic I'm hacking on
07:10 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has joined #bitcoin-core-dev
07:35 -!- ercwl [~ercwl@94.234.45.80] has joined #bitcoin-core-dev
07:39 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
07:42 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has quit [Ping timeout: 245 seconds]
07:43 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
07:44 < achow101> ariard: 1900 utc
07:45 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
07:47 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Remote host closed the connection]
07:49 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
07:49 -!- jimpo [~jimpo@ec2-13-57-39-52.us-west-1.compute.amazonaws.com] has quit [Ping timeout: 258 seconds]
07:50 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
07:50 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
07:50 -!- d_t [~dt@108-65-77-11.lightspeed.sntcca.sbcglobal.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
07:51 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
07:51 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
07:52 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
07:52 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
07:53 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
07:53 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
07:54 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:7df1:4dee:356a:5d1c] has joined #bitcoin-core-dev
07:54 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
07:54 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
07:55 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
07:55 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
07:56 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
07:56 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
07:57 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
07:57 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
08:00 -!- pehjota1 [~pehjota@185.103.96.147] has quit []
08:01 -!- kcalvinalvin [~calvin@104.143.95.18] has joined #bitcoin-core-dev
08:01 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Ping timeout: 246 seconds]
08:02 -!- ercwl [~ercwl@94.234.45.80] has quit [Quit: ercwl]
08:05 -!- kephra [~kephra@184.75.223.219] has joined #bitcoin-core-dev
08:08 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has joined #bitcoin-core-dev
08:09 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:7df1:4dee:356a:5d1c] has quit [Ping timeout: 250 seconds]
08:09 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
08:09 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #16535: test: Explain why -whitelist is used in feature_fee_estimation (master...1908-testDocFeeEst) https://github.com/bitcoin/bitcoin/pull/16535
08:09 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
08:11 -!- nightfall [4fb75870@bzq-79-183-88-112.red.bezeqint.net] has joined #bitcoin-core-dev
08:16 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has joined #bitcoin-core-dev
08:27 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has quit [Read error: Connection reset by peer]
08:27 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has joined #bitcoin-core-dev
08:28 < ariard> thanks achow101
08:30 -!- pinheadmz [~matthewzi@192.154.196.7] has joined #bitcoin-core-dev
08:30 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
08:31 -!- pinheadmz [~matthewzi@192.154.196.7] has quit [Client Quit]
08:35 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Ping timeout: 245 seconds]
08:39 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
08:39 -!- mzygar [~mzygar@212.123.247.72] has quit [Ping timeout: 246 seconds]
08:40 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has quit [Quit: WeeChat 2.3]
08:43 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
08:48 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
08:52 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Ping timeout: 245 seconds]
08:59 -!- spaced0ut [~spaced0ut@unaffiliated/spaced0ut] has joined #bitcoin-core-dev
09:00 -!- kcalvinalvin [~calvin@104.143.95.18] has quit [Ping timeout: 245 seconds]
09:04 -!- kcalvina_ [~calvin@104.143.95.18] has joined #bitcoin-core-dev
09:04 < elichai2> Is InferDescriptor *suppose* to add this fingerprint to keys(they started as regular descriptors with private/public keys, no BIP32 stuff involved)? `pkh([1fb31c4f]03462c64aa6089c6e28536c74b6ec4a8f3eaf2f5c5c36e1ae0abf39d563eeaf11e)` (it's something i'm seeing in my descriptors_tests)
09:07 < sipa> elichai2: it's unnecessary but harmless
09:08 < elichai2> So it's nothing i've done haha thanks :) (FYI it's starting to look nice, this is what my InferDescriptor *returns* to me :) `tap([46d3fd75]031e34802508ce0bbabb71935832c92129c6df82143a924d731c43362495111319,[pkh([1fb31c4f]03462c64aa6089c6e28536c74b6ec4a8f3eaf2f5c5c36e1ae0abf39d563eeaf11e),pk([2611005f]0257dd0c7c2e9036b845ff4f8a90eeed5daf821e7abd1f98dcbc8b65b0006d28ce)])#umstfklz`) 
09:10 -!- ercwl [~ercwl@94.234.45.80] has joined #bitcoin-core-dev
09:15 < elichai2> (I meant parsing and then inferring the scriptpubkey) 
09:15 < sipa> cool!
09:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:18 < bitcoin-git> [bitcoin] ariard opened pull request #16536: [doc] Update and extend benchmarking.md (master...2019-08-update-benchmarking-docs) https://github.com/bitcoin/bitcoin/pull/16536
09:18 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:19 < bitcoin-git> [bitcoin] MarcoFalke pushed 11 commits to master: https://github.com/bitcoin/bitcoin/compare/be0e8b4bff88...3a3d8b835712
09:19 < bitcoin-git> bitcoin/master e0e18a1 Hennadii Stepanov: refactoring: Check IsArgKnown() early
09:19 < bitcoin-git> bitcoin/master e0d187d Hennadii Stepanov: Refactor InterpretNegatedOption() function
09:19 < bitcoin-git> bitcoin/master 265c1b5 Hennadii Stepanov: Add Flags enum to ArgsManager
09:19 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
09:20 < bitcoin-git> [bitcoin] MarcoFalke merged pull request #16097: Refactor: Add Flags enum to ArgsManager class (master...20190526-fix-negated-args) https://github.com/bitcoin/bitcoin/pull/16097
09:20 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
09:27 -!- kljasdfvv [~flack@p200300D46F0E78007906FA620C99F7AE.dip0.t-ipconnect.de] has quit [Quit: Konversation terminated!]
09:28 -!- inersha [~greg@193.28.36.25] has left #bitcoin-core-dev []
09:31 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has quit [Quit: Leaving...]
09:33 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
09:33 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
09:34 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
09:40 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has joined #bitcoin-core-dev
09:47 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has quit [Quit: Leaving...]
09:48 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has joined #bitcoin-core-dev
09:56 -!- emzy_ [~quassel@raspberry.emzy.de] has quit [Changing host]
09:56 -!- emzy_ [~quassel@unaffiliated/emzy] has joined #bitcoin-core-dev
10:10 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
10:16 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Ping timeout: 272 seconds]
10:18 -!- Zenton [~user@unaffiliated/vicenteh] has quit [Ping timeout: 248 seconds]
10:20 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has joined #bitcoin-core-dev
10:21 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]
10:23 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
10:25 -!- kcalvina_ [~calvin@104.143.95.18] has quit [Remote host closed the connection]
10:26 -!- ercwl [~ercwl@94.234.45.80] has quit [Quit: ercwl]
10:26 -!- pinheadmz [~matthewzi@209.209.238.169] has joined #bitcoin-core-dev
10:30 -!- jungly [~quassel@79.8.200.97] has quit [Remote host closed the connection]
10:31 -!- kcalvinalvin [~calvin@104.143.95.18] has joined #bitcoin-core-dev
10:40 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has quit [Remote host closed the connection]
10:50 -!- kcalvinalvin [~calvin@104.143.95.18] has quit [Ping timeout: 258 seconds]
10:51 < elichai2> sipa: arghh. Is it important that every bracket will have it's own significant meaning? because using the same bracket for taproot branches and for bip32 derivations complicates stuff a bit (nothing that can't be handled with a few conditions but still) should be maybe introduce curly brackets?
10:52 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
10:53 < sipa> elichai2: if you think curly brackets is easier, sure
10:55 -!- shesek` [~shesek@141.226.218.109] has joined #bitcoin-core-dev
10:56 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
10:56 -!- jonatack [d598a245@213.152.162.69] has joined #bitcoin-core-dev
10:57 -!- shesek`` [~shesek@141.226.218.3] has quit [Ping timeout: 245 seconds]
11:00 -!- kephra [~kephra@184.75.223.219] has quit []
11:00 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has joined #bitcoin-core-dev
11:18 -!- reallll [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev
11:21 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 258 seconds]
11:30 -!- hebasto [~hebasto@95.164.65.194] has quit [Remote host closed the connection]
11:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
11:36 < bitcoin-git> [bitcoin] Sjors closed pull request #15414: [wallet] allow adding pubkeys from imported private keys to keypool (master...2019/02/keypool_import_private_keys) https://github.com/bitcoin/bitcoin/pull/15414
11:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
11:59 < sipa> TIL: the number of public keys participating in an OP_CHECKMULTISIG and OP_CHECKMULTISIGVERIFY counts towards the 201 non-push opcodes limit, but *only* when executed
12:00 < meshcollider> #startmeeting
12:00 < lightningbot> Meeting started Fri Aug  2 19:00:21 2019 UTC.  The chair is meshcollider. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00 < meshcollider> #bitcoin-core-dev Wallet Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball
12:00 < achow101> hi
12:00 < provoostenator> hi\
12:00 < sipa> hi
12:01 < ariard> hi
12:01 < meshcollider> any topics? :)
12:01 < jonatack> hi
12:01 < jnewbery> hi
12:01 < achow101> Big news is #16528 opened last night for native descriptor wallets
12:01 < gribble> https://github.com/bitcoin/bitcoin/issues/16528 | [WIP] Native Descriptor Wallets (take 2) by achow101 · Pull Request #16528 · bitcoin/bitcoin · GitHub
12:01 < achow101> only 107 commits :p
12:01 < ariard> working on a rework of rescan logic https://gist.github.com/ariard/89f9bcc3a7ab9576fc6d15d251032cfa
12:02 < sipa> achow101: wow
12:02 < ariard> thanks to feedbacks design from ryanosfky
12:02 < sipa> ariard: tip for remembering his nickname: ryan of sky
12:02 < ariard> s/ryanosfky/ryanofsky/g
12:02 < ariard> sipa: already heard this one
12:03 < meshcollider> achow101: The 107 commits include the legacy rework PR right :p
12:03 < achow101> <provoostenator> For todays wallet meeting, it would be good to brainstorm if there's a way to avoid all the [ci skip] commits in #16341.
12:03 < gribble> https://github.com/bitcoin/bitcoin/issues/16341 | Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub
12:03 < achow101> meshcollider: yes
12:03 < kanzure> hi
12:03 < achow101> I think provoostenator has the only topic suggestion today
12:03 < provoostenator> Yes, maybe it's impossible, but's pretty daunting to review otherwise
12:04 < meshcollider> Let's start with that then
12:04 < achow101> I had a look at doing that, and it gave me a headache
12:04 < meshcollider> #topic Avoiding the [ci skip]s in #16341
12:04 < gribble> https://github.com/bitcoin/bitcoin/issues/16341 | Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub
12:05 < achow101> the problem is that a lot of functions are dependent on other ones, so there would need to be a pretty big commit just to add those
12:05 < meshcollider> Yeah I thought the whole reason you put them there in the first place was because we decided it was better than one massive commit that doesn't break stuff
12:05 < achow101> then as you add them into the wallet, things start becoming inconsistent if not all of the things that can effect each other are also added at the same time. these inconsistencies also result in test failures
12:06 < achow101> One idea I had was to combine implementation of the function in LegacyScriptPubKeyMan and replacement in CWallet, but still leave the CWallet stuff there to operate in parallel
12:07 < provoostenator> That's what I was thinking as well
12:07 < achow101> but that seemed kind of pointless because the new code wasn't really doing anything, and we would still need to have the gigantic "delete all the old things" commit at the end
12:08 < provoostenator> Maybe start with a bunch dummy methods in the LegacyScriptPubKeyMan and then move stuff over?
12:08 < provoostenator> Then in the end you still need to delete some calls, but no implementations.
12:08 < achow101> there is also some consistency issues with doing that because the wallet files could be overwritten by two different code paths and become inconsistent, also failing tests
12:08 < meshcollider> It's the moving which is the problem
12:08 < elichai2> crazy idea. PR into PR? (that way they could be reviewed seperatly but merged into master together)
12:09 < sipa> we must go deeper.
12:09 < achow101> elichai2: they're all separate commits, so it shouldn't actually be that hard to review separately
12:10 -!- _atos [~quassel@109-252-72-133.nat.spd-mgts.ru] has joined #bitcoin-core-dev
12:10 < achow101> provoostenator: I don't believe that there is a way to avoid having [ci skip] commits because tests will fail
12:11 < meshcollider> Ease of review > Travis passing on every single commit, as long as the tests pass at the end of the PR I think it's fine :)
12:11 < provoostenator> meshcollider: agree
12:11 < achow101> a lot of the commits are really small too
12:12 < provoostenator> Currently the dimmed-zebra can't help
12:12 < provoostenator> Which makes it super tedious to check if the new function bodies are the same
12:12 < sipa> having intermediary commits that pass CI is helpful for review, as you can be sure about things like "this method changes, did all call sites get updated too?" without needing much work
12:13 < achow101> having them all pass tests would be nice, makes bisect not suck
12:13 < sipa> yeah
12:13 < sipa> not saying it's a strict requirement, though it's certainly very helpful as a policy
12:13 < achow101> I spent a lot of time finding a bug that was introduced in one of the [ci skip] commits but bisect wasn't as helpful since the tests wouldn't get to the part where the bug was triggered
12:14 < achow101> but even then, having them all pass tests wouldn't be helpful since the new code isn't the one that's actually doing the work. it would still just be the old stuff and bisecting would just point you to the gigantic "change everything over" commit
12:15 < jonatack> at least the [ci skip] comments signal when the failure is to be expected, so there's that... but from a review perspective hygienic commits are much better
12:15 < jonatack> commit messages could contain the steps
12:17 < meshcollider> achow101: can CWallet just have an instance of a LegacyScriptPubkeyManager inside it right from the start and call methods inside it as they're moved into it?
12:18 < meshcollider> And then do some inheritance refactoring at the end
12:18 < meshcollider> Then the massive "move everything over" commit would just be deleting methods like foo(){ legacy.foo(); }
12:19 < achow101> no because methods are dependent on other ones
12:20 < achow101> for example, I thought that AddKey would be easy, it should be mostly by itself, right? Nope. Requres AddCryptedKey to be implemented, which requires Encryption stuff to be implemented. For some reason it also requires watch only things so you need to have setWatchOnly, HaveWatchOnly, RemoveWatchOnly
12:20 -!- Zenton [~user@unaffiliated/vicenteh] has joined #bitcoin-core-dev
12:21 < achow101> and you need AddKey for loading keys in the first place!
12:21 < sipa> fun.
12:22 < meshcollider> Yeah... I think the [ci skip] are here to stay then
12:23 < meshcollider> Does anyone else want to discuss anything this week?
12:24 < achow101> (If you couldn't tell, I was very annoyed by this and spent a while cursing the person who wrote this code, which was probably sipa :p)
12:24  * sipa hides.
12:25 < ariard> meshcollider: if anyone has thoughts on this https://gist.github.com/ariard/89f9bcc3a7ab9576fc6d15d251032cfa it would be welcomed
12:25 < ariard> (not necessarily now)
12:26 < achow101> it would be nice for rescan (and other wallet things) to not need cs_main
12:26 < meshcollider> #action Read and feedback on ariard's proposal
12:26 < ariard> main idea is just to use a common thread between index and ChainClient to provide blocks in one sequence instead of redoing the work multiple times
12:26 < achow101> there's been a lot of complaints I've seen recently about RPCs taking a while, probably because cs_main is held by ~everything
12:26 < ariard> achow101: yes that's the end of goal, not relying at all on cs_main
12:27 < ariard> but will need multiple PRs to get there to avoid to big diff
12:27 < ariard> first step move all logic in a thread, future steps  worker thread pool + cache what we need to avoid locking
12:28 < ariard> hope to submit code next week, people will get a better idea
12:29 < emilengler> By the way, what does the LOCK and cs_main mean? I see this nearly everywhere when I look in the code
12:29 < meshcollider> ariard: sounds good!
12:29 < emilengler> And why it needs to be in the curly brackets
12:30 < achow101> emilengler: cs_main is one of the locks, while one thread holds it, no other thread can acquire it. it is used to protect things from concurrency issues like race conditions. LOCK(cs_main) is the way to acquire cs_main, if it is held by someone else, the thread will wait
12:30 < sipa> emilengler: RAII
12:30 < meshcollider> emilengler: cs_main is something which only one thread can "hold" at once, making sure stuff which it protects isn't written twice at the same time or something which would result in race conditions
12:30 < sipa> emilengler: it introduces a lock in the scope it's defined at; it automatically unlocks when it goes out of scope
12:30 < sipa> emilengler: it's a general concept in C++ called RAII
12:30 < ariard> have a look in sync.h and threadsafety.h
12:31 < meshcollider> Anyway I think this wraps up the meeting 
12:31 < emilengler> Ok so it is more a C++ thing? I usually don't work that often with multiple threads
12:31 < meshcollider> We can read the proposal and PR outside
12:31 < meshcollider> #endmeeting
12:31 < lightningbot> Meeting ended Fri Aug  2 19:31:49 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:31 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-08-02-19.00.html
12:31 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-08-02-19.00.txt
12:31 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-08-02-19.00.log.html
12:32 < achow101> anyone have suggestions for things that should be added to tests for descriptor wallets?
12:32 < achow101> I added a --descriptors switch to some of the wallet tests so those tests will also run with descriptor wallets
12:32 < sipa> that's a nice idea
12:32 < sipa> so you can test things against both old-style wallets and new-style ones?
12:33 < achow101> yes
12:33 < meshcollider> emilengler: other languages use locks too for multithreading
12:33 < meshcollider> I think java does
12:33 < achow101> sipa: it just needs to avoid things like imports and ismine
12:34 < meshcollider> achow101: I guess it's easier to suggest more tests when reviewing the tests in the PR 
12:34 < achow101> but at least all of the transaction sending, transaction ismine, etc. things can be tested without writing wholly new tests
12:34 < achow101> meshcollider: better start reviewing then!
12:35 < sipa> emilengler: https://en.wikipedia.org/wiki/Resource_acquisition_is_initialization
12:36 < meshcollider> achow101: just add tests for all the new codepaths :)
12:36 < meshcollider> You wrote it so you should know how to test it :)))
12:36 < achow101> I did a coverage report and I think just about everything has been hit
12:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
12:37 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #16538: test: Add missing sync_blocks to feature_pruning (master...1908-testPruneNoRace) https://github.com/bitcoin/bitcoin/pull/16538
12:37 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
12:38 -!- morcos [~morcos@gateway/tor-sasl/morcos] has quit [Remote host closed the connection]
12:38 -!- morcos [~morcos@gateway/tor-sasl/morcos] has joined #bitcoin-core-dev
12:47 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
12:51 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
12:52 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
12:55 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Excess Flood]
12:56 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
12:58 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
13:06 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]
13:07 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev
13:08 -!- Bullitje_enable [~Bullit01@042-236-158-163.dynamic.caiway.nl] has quit [Read error: Connection reset by peer]
13:12 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
13:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:15 < bitcoin-git> [bitcoin] laanwj pushed 2 commits to 0.18: https://github.com/bitcoin/bitcoin/compare/784e218610d4...673919caf72c
13:15 < bitcoin-git> bitcoin/0.18 5f5b444 David A. Harding: Doc: remove old release notes about systemd and riscv changes
13:15 < bitcoin-git> bitcoin/0.18 673919c Wladimir J. van der Laan: Merge #16532: [0.18] Doc: remove old release notes about systemd and riscv...
13:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:15 < bitcoin-git> [bitcoin] laanwj merged pull request #16532: [0.18] Doc: remove old release notes about systemd and riscv changes (0.18...2019-07-0.18.1-release-notes) https://github.com/bitcoin/bitcoin/pull/16532
13:15 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:20 -!- _atos [~quassel@109-252-72-133.nat.spd-mgts.ru] has quit [Remote host closed the connection]
13:24 -!- reallll is now known as belcher
13:25 < emilengler> Where are the qt icons stored?
13:25 < emilengler> Ok nevermind got it
13:26 < emilengler> They are in src/qt/res
13:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:26 < bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/673919caf72c...bfa7183c4e5a
13:26 < bitcoin-git> bitcoin/0.18 bfa7183 Wladimir J. van der Laan: build: set CLIENT_VERSION_RC to 0 pre-final
13:26 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:27 < wumpus> `git ls-files|grep png`
13:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:28 < bitcoin-git> [bitcoin] Sjors opened pull request #16539: [wallet] lower -txmaxfee default from 0.1 to 0.01 BTC (master...2019/08/lower_txmaxfee) https://github.com/bitcoin/bitcoin/pull/16539
13:28 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:28 < emilengler> wumpus: Also thought about doing this but I wasn't sure about the file format
13:29 < wumpus> we've just disabled jpeg so :-)
13:29 -!- lassulus1 [~lassulus@185.59.221.95] has joined #bitcoin-core-dev
13:30 < emilengler> Maybe a vector?
13:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:33 < bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.18: https://github.com/bitcoin/bitcoin/compare/bfa7183c4e5a...fa27a0760792
13:33 < bitcoin-git> bitcoin/0.18 fa27a07 Wladimir J. van der Laan: doc: Bump manpages pre-final
13:33 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:33 < provoostenator> ^ sorry for the bike-shed risk, but I think it's worth considering every couple of years and it's been 5
13:35 < wumpus> emilengler: yea there's some svg but they're converted to png before being included afaik, don't think we include any actual vector icons for use by the qt code, but not 100% sure
13:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:36 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #16540: test: Add ASSERT_DEBUG_LOG to unit test framework (master...1908-UnitTestAssertDebugLog) https://github.com/bitcoin/bitcoin/pull/16540
13:36 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:37 -!- promag_ [~promag@Bl19-22-20.dsl.telepac.pt] has quit [Remote host closed the connection]
13:38 < wumpus> provoostenator: sorry i'm not sure what that's about
13:38 < provoostenator> wumpus: my PR proposes lowering txmaxfee from 0.1 to 0.01 BTC
13:39 < wumpus> provoostenator: ohh good luck !
13:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:42 < bitcoin-git> [bitcoin] laanwj pushed tag v0.18.1: https://github.com/bitcoin/bitcoin/compare/v0.18.1
13:42 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:45 < wumpus> gkrizek: ^^ the bot really does work great
13:45 < provoostenator> With giant coin joins in mind maybe we should check the max fee per our own inputs, rather than the tx total.
13:45 < provoostenator> *for
13:46 < wumpus> yes, tx total has always been kind of a belts and suspenders measure
13:46 < wumpus> like 'if the total fee is more than *this* it's really absurd and something must be wrong'
13:47 < wumpus> could be because a wallet generates a transaction that's absurdly large, or because the feerate is absurdly large
13:48 < provoostenator> In #16257 I covered the case where a user types "1" as the feeRate thinking it's satoshi per byte. That works nicely with the current 0.1 BTC max.
13:48 < gribble> https://github.com/bitcoin/bitcoin/issues/16257 | [wallet] abort when attempting to fund a transaction above -maxtxfee by Sjors · Pull Request #16257 · bitcoin/bitcoin · GitHub
13:49 < provoostenator> But there may be other fat finger mistakes possible.
13:50 < provoostenator> I believe in earlier days people would sometimes forget a change address, though afaik that's pretty hard to do accidentally now in core.
13:52 < ghost43> provoostenator: is the maxtxfee check still done when using the sendrawtransaction RPC? Not that long ago at least that was the case
13:53 < provoostenator> I'm not sure, because that's no longer part of the wallet.
13:53 < ghost43> (I know the check was done there because it was affecting electrum users)
13:54 < provoostenator> ghost34: yes it still does that check, there's a maxfeerate argument to more easily override it
13:54 < achow101> ghost43: the absurdly high fee error?
13:54 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]
13:54 < ghost43> yes
13:55 < ghost43> we had users with huge wallets creating almost 100 KB txs
13:55 < provoostenator> But it's not done for p2p transaction relay?
13:55 < ghost43> for those, the absurdity is breached around 100 sat/byte
13:55 < ghost43> but the electrum server is using the bitcoind sendrawtransaction RPC
13:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
13:55 < bitcoin-git> [bitcoin] emilengler opened pull request #16541: qt: Add better icon for Open URI (master...2019-08-qt-update-open-uri-icon) https://github.com/bitcoin/bitcoin/pull/16541
13:55 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
13:57 < ghost43> tbh, I think a "feerate" absurdity check would make a lot more sense than an "absolute fee" absurdity check
14:00 -!- lassulus1 [~lassulus@185.59.221.95] has quit []
14:00 < achow101> ghost43: I think it's still an absolute fee. We should definitely change that...
14:00 < achow101> afaik maxtxfee is for the wallet
14:03 -!- davterra [~none@209.58.185.33] has quit [Remote host closed the connection]
14:03 < achow101> ghost43: nvm, I'm wrong. it uses maxtxfee. you could also just bypass that check by using the `allowhighfees` parameter
14:04 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Remote host closed the connection]
14:04 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
14:06 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
14:06 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
14:06 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has quit [Remote host closed the connection]
14:06 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has joined #bitcoin-core-dev
14:06 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
14:07 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
14:08 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
14:08 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
14:09 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
14:09 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
14:10 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
14:10 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
14:11 -!- captjakk [~captjakk@75-166-173-191.hlrn.qwest.net] has quit [Ping timeout: 245 seconds]
14:11 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
14:11 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
14:12 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
14:12 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
14:13 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
14:13 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
14:14 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
14:14 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
14:15 < ghost43> looks like the wallet and the node maximum absolute fees were recently separated: https://github.com/bitcoin/bitcoin/pull/15620
14:15 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
14:16 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
14:16 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
14:16 -!- mdunnio [~mdunnio@38.126.31.226] has joined #bitcoin-core-dev
14:16 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
14:17 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
14:18 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
14:18 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Read error: Connection reset by peer]
14:19 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
14:20 -!- davterra [~none@209.58.185.33] has joined #bitcoin-core-dev
14:21 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has quit [Quit: WeeChat 2.3]
14:21 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has joined #bitcoin-core-dev
14:22 -!- ezegom_ [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Ping timeout: 248 seconds]
14:23 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Ping timeout: 244 seconds]
14:24 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has quit [Client Quit]
14:26 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has joined #bitcoin-core-dev
14:33 -!- Gaz [~Gaz@141.98.102.243] has joined #bitcoin-core-dev
14:45 < emilengler> Is the strprintf function for args who take user-input?
14:46 < sipa> for anything
14:46 < emilengler> But in init.cpp this function is used sometimes and sometimes not
14:46 < emilengler> So what is the actual purpose of it?
14:47 < sipa> it's used to convert things to a string
14:47 < sipa> i don't know what you mean by "sometimes not"
14:48 < emilengler> In the init.cpp at the part where the args are being added their is the second parameter sometimes this function or just a string
14:48 < emilengler> Like in line 356 it isn't used but in 383 it uses for example
14:49 < sipa> there is nothing to convert to a string in line 356
14:49 < sipa> it already is one
14:49 < emilengler> Yep I got it, your previous answer explained it. thanks :)
14:55 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
14:57 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
15:10 -!- captjakk [~captjakk@178.128.232.240] has joined #bitcoin-core-dev
15:18 -!- jarthur_ [~jarthur@207.114.244.5] has joined #bitcoin-core-dev
15:20 -!- jarthur [~jarthur@207.114.244.5] has quit [Ping timeout: 245 seconds]
15:22 -!- jarthur_ [~jarthur@207.114.244.5] has quit [Ping timeout: 272 seconds]
15:22 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Ping timeout: 248 seconds]
15:27 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
15:29 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 258 seconds]
15:30 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev
15:33 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Remote host closed the connection]
15:33 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
15:37 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Ping timeout: 248 seconds]
15:40 -!- davterra [~none@209.58.185.33] has quit [Remote host closed the connection]
15:41 -!- davterra [~none@209.58.185.33] has joined #bitcoin-core-dev
15:46 -!- justan0theruser is now known as justanotheruser
15:46 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds]
15:48 -!- blockstreamspy [cdd118e3@205.209.24.227] has joined #bitcoin-core-dev
15:49 -!- blockstreamspy [cdd118e3@205.209.24.227] has quit [Remote host closed the connection]
15:57 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
16:23 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Remote host closed the connection]
16:23 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has joined #bitcoin-core-dev
16:27 -!- ezegom [~ezegom@rrcs-172-254-90-3.nyc.biz.rr.com] has quit [Ping timeout: 246 seconds]
16:34 -!- captjakk [~captjakk@178.128.232.240] has quit [Remote host closed the connection]
16:40 -!- promag [~promag@83.223.233.21] has joined #bitcoin-core-dev
16:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has joined #bitcoin-core-dev
16:43 < bitcoin-git> [bitcoin] achow101 opened pull request #16542: Return more specific errors about invalid descriptors (master...descriptor-errors) https://github.com/bitcoin/bitcoin/pull/16542
16:43 -!- bitcoin-git [~bitcoin-g@x0f.org] has left #bitcoin-core-dev []
16:48 < achow101> fanquake: maybe we should add a "descriptors" tag as descriptors by themselves aren't wallet related
16:48 < fanquake> achow101: sure
16:55 -!- captjakk [~captjakk@205.209.24.233] has joined #bitcoin-core-dev
16:56 -!- rex4539 [~rex4539@2a02:587:3514:c700:208e:dd68:c646:7c08] has quit [Quit: rex4539]
16:58 < elichai2> achow101: why doesn't `FillableSigningProvider` derives from `FlatSigningProvider`?
17:00 -!- Gaz [~Gaz@141.98.102.243] has quit []
17:00 < elichai2> I guess because his keys are guarded?
17:00 < achow101> elichai2: to not publicly expose the internals
17:00 < elichai2> hmm
17:00 < elichai2> ok, I guess everything I add to `FlatSigningProvider` I need to add to `FillableSigningProvider` but thread safe
17:01 < achow101> Why do you need FillableSigningProvider?
17:01 < elichai2> achow101: right in FlatSigningProvider everything is public
17:01 < elichai2> achow101: I added taproot support for descriptors, it complains now that the `switch (whichType)`  in `IsMine` doesn't cover the new taproot
17:01 -!- dviola [~diego@unaffiliated/dviola] has joined #bitcoin-core-dev
17:02 < achow101> don't use IsMine :)
17:02 < elichai2> I don't use it, I edited `txnouttype`
17:02 < achow101> (but seriously, IsMine is changing with all of the wallet stuff)
17:02 < elichai2> so for now I should just stick to descriptors and then enjoy the rebase? haha
17:03 < achow101> I don't quite follow what you are trying to do
17:03 < elichai2> I guess i'll have to manually test that I'm hashing everything the same way the interperter does
17:03 < elichai2> achow101: `tap(031e34802508ce0bbabb71935832c92129c6df82143a924d731c43362495111319,{{pk(0257dd0c7c2e9036b845ff4f8a90eeed5daf821e7abd1f98dcbc8b65b0006d28ce),{pkh(023e93f827793706dffdca946b64842f69c336c8dd78f32d716ee7e77dfe119418),pk(03ce8db555edec3c68b358cf9bdb7fd9539a9fba064c31bdc9651c68fa658dd6b7)}},pkh(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)})`
17:04 < elichai2> new descriptor :)
17:04 < elichai2> ops I copied an invalid one lol
17:04 < achow101> right, so what does ismine have to do with this?
17:05 < elichai2> ismine switches over `txnouttype`. I had to add `TX_WITNESS_V1_TAPROOT` to it because `txnouttype` is also used in `InferScript`
17:05 < elichai2> I can just add return false there for the taproot ones for now
17:06 < sipa> you should
17:06 < sipa> the old ismine logic shouldn't be used for taproot stuff
17:06 < elichai2> so I'll wait for achow101 native descriptors PR for testing wallet support?
17:06 < achow101> yes
17:06 < elichai2> ok
17:07 < sipa> are you writing signing support?
17:07 < elichai2> I'll start doing manual tests to check that i'm hashing everything correctly
17:07 < sipa> or just derivation for now
17:08 < elichai2> the only way to really know that what i'm doing is correct is by having a test that signs and see that it passes your interperter code
17:08 < elichai2> otherwise my lex ordering or the hashes might be wrong and I won't know
17:08 < sipa> so signing logic should be independent of descriptors
17:08 < sipa> and there you'll need to switch based on txnouttype
17:09 < sipa> but for pretty much everything else i think you can ignore TX_WITNESS_V1_TAPROOT
17:11 < elichai2> yeah, but then I can import a desc and try to sign with it. but I guess i'm trying to do too much, for now i'll test manually and concentrate on adding more tests for the desc and then either ask someone to give my code a quick look (I am pretty new to bitcoin core's code and to c++)  or look into PSBT/signing, but only after i'm 100% done with the desc
17:12 < elichai2> (hopefully by then achow101 will finish and I'll be able to rebase on top of him)
17:12 < sipa> are you adding fields to SignatureData ?
17:12 < achow101> elichai2: you could base on top of #16528 (native descriptor wallets), but it's wip so it could change. but while no one has reviewed it, it probably won't change
17:12 < gribble> https://github.com/bitcoin/bitcoin/issues/16528 | [WIP] Native Descriptor Wallets (take 2) by achow101 · Pull Request #16528 · bitcoin/bitcoin · GitHub
17:13 < elichai2> I'll actually try to review it too next week, though it's a pretty big one heh
17:14 < elichai2> sipa: didn't yet but I basically have the control block in ProduceSignature
17:14 < elichai2> so it shouldn't be too hard
17:14 < sipa> elichai2: i guess the codebase (and the hairy signing logic + descriptor stuff in particular...) can be quite daunting
17:14 < sipa> but it's great that you're getting accustomed to it
17:15 < elichai2> yeah, even though there's a lot of things I don't like/don't get both in c++ and in some design choices it's overall not as hard as I thought it will be (assuming people won't say that everything i'm doing is wrong and bad lol)
17:17 < sipa> yeah, a lot is historical
17:17 < achow101> it's all sipa's fault
17:17 < elichai2> lol
17:17 < sipa> i think maybe at some point we can make the entire signing logic integrated into descriptors
17:17 < sipa> well, a lot of it is, probably
17:17 -!- paulk [~paulk@195.206.169.238] has joined #bitcoin-core-dev
17:17 < elichai2> yeah a lot of the historical stuff are frustrating, but I guess we don't have much of a choice
17:17 < sipa> but maybe not; i'm not sure
17:18 < sipa> btw: https://github.com/sipa/bitcoin/tree/201907_miniscript
17:18 < elichai2> (i.e. the way `ProduceSignature` works is pretty weird/funny)
17:19 < achow101> sipa: finally
17:19 < sipa> it's not yet integrated into descriptors or signing logic
17:19 < elichai2> "bla"
17:19 < elichai2> :P
17:19 < sipa> but it is passing tests (randomly generated script, generating a random satisfaction for it, and feeding it to the script interpreter)
17:19 < achow101> "Various"
17:20 < sipa> don't look at my commits, lol
17:20 < achow101> I guess that's better than just "f" (which I frequently do)
17:20 < sipa> not PR-ready
17:20 -!- ercwl [~ercwl@94.234.45.80] has joined #bitcoin-core-dev
17:20 < elichai2> So I guess we have another interpreter ha
17:20 < sipa> but src/script/miniscript.h should be pretty readable
17:20 < elichai2> what's a gram file?
17:21 < sipa> elichai2: https://github.com/sipa/gramtropy :)
17:21 < achow101> sipa: does this mean that miniscript is finalized now and won't be completely rewritten again?
17:21 < sipa> achow101: yes
17:21 < sipa> i'll try to write things up and send a mail to the list next week
17:21 < achow101> yay
17:22 < elichai2> rightt I saw it somtime in the past. funny tool.
17:22 < elichai2> sipa: awesome!
17:22 < elichai2> I'm curious how will the descritors look like 
17:23 < sipa> wsh(and_v(or_c(c:pk(C),or_c(c:pk(C),v:older(1000))),c:pk(C)))
17:23 < sipa> where C is a pubkey
17:23 < elichai2> hmm so in theory if you use '(' it would hopefully magically work with my desc
17:23 < achow101> that will be part of the descriptor module? so the wallet doesn't need anymore changes
17:24 < elichai2> altough you also use `,` so that might be a problem hmm
17:24 < sipa> elichai2: i expect things to just Just Work(tm)
17:24 -!- ercwl [~ercwl@94.234.45.80] has quit [Client Quit]
17:24 < sipa> achow101: yeah
17:25 < sipa> the only change that affects the wallet i expect will be that we can't use IsSolvable/DummySigner anymore to guess fees
17:25 < elichai2> looks pretty cool :)
17:25 -!- jarthur [~jarthur@2605:6000:1019:4971:c1e1:76c9:1dac:cdbc] has joined #bitcoin-core-dev
17:25 < sipa> because the size of satisfactions depends on which participants are available
17:25 < sipa> so i think we'll add a method to descriptors to ask them what a satisfaction will cost
17:26 < sipa> that's also true for taproot btw
17:28 < elichai2> I'm kind of brute forcing IsSolvable(ProduceSignature) right now, so if the wallet can either 1. sign for the internal key. 2. sign for any of the branches I return cool, which I guess will stop at the first thing that it can sign for
17:28 < elichai2> though I'm not sure it's the right attitude. maybe at the very least sort it by size and try from lower to higher
17:29 < sipa> elichai2: my idea is that we add support in descriptors for marking keys as available/unavailable
17:29 < elichai2> available as in available but not in my wallet? (i.e. multisig)
17:29 < sipa> and there is a cute algorithm that can find the worst case satisfaction cost given which keys are certainly available, which may be available, and which are definitely not available
17:30 < sipa> yeah, available meaning "will participate in signing if requested"
17:30 < sipa> which private keys you have locally should be pretty much completely independent (as your software shouldn't treat having a key locally as different from it being in a hw wallet you control)
17:30 < elichai2> right now the wallet doesn't do anything like that for multisig, right?
17:30 -!- jarthur [~jarthur@2605:6000:1019:4971:c1e1:76c9:1dac:cdbc] has quit [Remote host closed the connection]
17:30 < sipa> right
17:30 < sipa> because it doesn't need to
17:31 < sipa> all satisfactions are the same size
17:31 < elichai2> but some keys might be available but not in the wallet
17:31 < sipa> yeah, currently it distinguishes
17:31 < sipa> that's bad
17:31 < sipa> the concept of "watch only" being tied whether you have keys locally is a mistake
17:32 < achow101> watchonly is no longer a concept in descriptor wallets
17:32 < sipa> yay
17:32 < achow101> other than watchonly wallets, i.e. disable private keys
17:32 < achow101> but ISMINE_WATCHONLY isn't a thing that descriptor wallet ismine can return
17:33 < sipa> good
17:39 -!- jarthur [~jarthur@2605:6000:1019:4971:548c:28ca:f776:c0db] has joined #bitcoin-core-dev
17:39 < elichai2> btw if anyone is interested https://github.com/elichai/bitcoin/tree/2019-07-tap-desc (based on a merge between master and sipa/taproot)
17:40 < elichai2> so how will watch only work with native desc wallet?
17:40 < emilengler> elichai2: TL;DR can you sum it up please :)
17:40 < elichai2> emilengler: sum up what?
17:41 < emilengler> elichai2: You've written if anyone is interested on what? Sorry didn't followed the conversation
17:41 < achow101> emilengler: that's the code he's working on
17:41 < elichai2> oh haha, this is my WIP for taproot descriptors
17:42 < achow101> elichai2: watchonly in native descriptor wallets just means that the wallet doesn't have any private keys at all
17:42 < emilengler> elichai2: ok cool, good luck
17:42 < elichai2> achow101: how will you import such thing? just as an address?
17:42 < elichai2> emilengler: thanks :)
17:42 < achow101> even still, nothing is ever explicitly labeled as watchonly like how it is with legacy wallets
17:43 < achow101> e.g. right now, if you import an address, ismine will return ISMINE_WATCHONLY
17:43 < achow101> in native descriptor wallets, it will return ISMINE_SPENDABLE since ismine in native descriptor wallets is really just a bool
17:43 < gwillen> with multiwallet, I have claimed and continue to claim that the most reasonable thing is to have spendable and watchonly wallets be completely separate wallet.dat files
17:44 < gwillen> then there is no need to dispute over what "watch only" means because you pick
17:44 < sipa> gwillen: yes, that's what's happening
17:44 < sipa> the concept of watch only goes away with descriptor wallets
17:44 < achow101> elichai2: there's an importdescriptors RPC to import things into descriptor wallets. the rest of the import RPCs are disallowed for them
17:44 < sipa> something is treated as ours, or not
17:44 < gwillen> so then the answer to "how does watchonly work" is "any way you want to, you name one of your wallets watchonly.dat and then import whichever keys you want there"
17:45 < achow101> gwillen: pretty much. right now descriptor wallets is not allowing a mix of having private keys and not having them. I'll probably change that before it goes out of WIP
17:46 < gwillen> (I think if you import "just as an address", you can watch, but you won't be able to prepare transactions for offline signing, which would require public keys, redeemscipts, etc. in addition to addresses)
17:46 < elichai2> sipa: unrelated to anything. rebasing a branch with your subtree commit in it is hell lol (which is why I ended up merging instead)
17:46 < sipa> elichai2: oh you can't rebase subtrees
17:47 < sipa> i always just redo them
17:47 < elichai2> sipa: oh really? so when you'll open the taproot PR you'll redo those commits?
17:47 < gwillen> (but you can choose which way you do it dependding on what the particular wallet's function is for you)
17:47 < sipa> elichai2: or anytime i rebase
17:47 < sipa> they're trivial anyway
17:47 < achow101> sipa: with miniscript and taproot, is the expectation that the wallet will have some of the keys for satisfying?
17:48 < sipa> achow101: same as multisig
17:48 < sipa> i don
17:48 < sipa> i don't think we should care whether the user has keys locally or not
17:48 < sipa> if he has any, it'll likely not be all of them
17:48 < elichai2> ha. I tried to do it using rebasing. I tried every trick in the book lol so I gave up. when my commits will be more than a WIP i'll rebase them on top of a manual thing instead of a rebase
17:49 < sipa> i'll do a rebase of my taproot branch soon
17:49 < elichai2> that's fine as long as I don't publish my code there's nothing wrong with it being on top of a merge commit
17:49 < achow101> sipa: right now in descriptor wallets, if we have private keys enabled, we require all of the private keys to be available in order to import a descriptor. that's probably wrong, but I haven't had the chance to really think through it
17:50 < sipa> achow101: yeah i think that's wrong
17:50 < sipa> though it may make sense to configure the wallet to be "strictly single key, all keys present" or so, as a sanity check
17:50 < sipa> another possible setting for sanity checking could be "have at least one participating key in every descriptor"
17:50 < elichai2> achow101: right now as in your pr or as in master?
17:51 < sipa> elichai2: descriptor wallets only exist as a PR
17:51 < achow101> I was unsure whether to allow importing a descriptor that had to priv keys to a privkey enabled wallet
17:51 < achow101> s/had to priv keys/had no privkeys
17:51 < elichai2> sipa: right. that was a sanity check because I don't remember any privkey stuff in the descriptors so I wasn't sure what's up
17:52 < elichai2> achow101: hmm maybe it should be have enough keys to sign for that desc?
17:52 < sipa> elichai2: that's uninteresting
17:52 < achow101> the two ideas I was considering were "enough to sign" and "have at least one key"
17:52 < sipa> if you have a sufficient number of keys locally to sign, you shouldn't be using anything but single key
17:52 < achow101> right
17:52 < achow101> so I think I'll go with the latter
17:53 < sipa> that makes sense
17:53 -!- pinheadmz [~matthewzi@209.209.238.169] has quit [Quit: pinheadmz]
17:53 < elichai2> hmmm. so after you create the pubkeys map you make sure that you have at least one priv key? (or when you enter them into the map you could just set a bool)
17:54 < achow101> elichai2: basically
17:54 < achow101> haven't actually thought through the implementation 
17:54 < elichai2> cool. when do you think the PR will be ready for review?
17:54 < achow101> elichai2: soon(tm)
17:54 < achow101> :)
17:55 < elichai2> what's this tm thing? 😅
17:56 < sipa> https://en.wikipedia.org/wiki/Trademark_symbol
17:56 < achow101> It's a meme about Blizzard and Valve taking forever to release video games
17:56 < achow101> "Soon™: Copyright pending 2004-2019 Blizzard Entertainment, Inc. All rights reserved. "Soon™" does not imply any particular date, time, decade, century, or millennia in the past, present, and certainly not the future. "Soon" shall make no contract or warranty between Blizzard Entertainment and the end user. "Soon" will arrive some day, Blizzard does guarantee that "soon" will be here before the end of time. Maybe. Do not m
17:56 < achow101> ake plans based on "soon" as Blizzard will not be liable for any misuse, use, or even casual glancing at "soon.""
17:56 < sipa> it
17:57 < sipa> it's older than blizzard
17:57 < elichai2> ohhh
17:57 < elichai2> I googled `tm` and I actually found the tarkemark but didn't get the joke lol
17:59 -!- lightlike [~lightlike@2001:16b8:5722:1100:d0c0:631e:b973:5e79] has quit [Remote host closed the connection]
18:02 -!- captjakk [~captjakk@205.209.24.233] has quit [Remote host closed the connection]
18:04 < achow101> elichai2: native descriptor wallets depends on the rework pr (#16341) to be merged first, so it will be ready only after that happens
18:05 < gribble> https://github.com/bitcoin/bitcoin/issues/16341 | Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub
18:05 -!- davterra [~none@209.58.185.33] has quit [Quit: Leaving]
18:05 < achow101> given that 16341 is really big, it might take a while
18:09 -!- btcquant [~textual@210006171042.ctinets.com] has joined #bitcoin-core-dev
18:11 -!- justan0theruser [justanothe@gateway/vpn/nordvpn/justanotheruser] has joined #bitcoin-core-dev
18:12 -!- justanotheruser [justanothe@gateway/vpn/nordvpn/justanotheruser] has quit [Ping timeout: 245 seconds]
18:12 < elichai2> ok, so I guess I'll try to review that one on Monday :)  (though I don't know too much about the wallet itself) 
18:13 -!- justan0theruser is now known as justanotheruser
18:13 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has quit [Quit: WeeChat 2.3]
18:17 -!- jarthur [~jarthur@2605:6000:1019:4971:548c:28ca:f776:c0db] has quit []
18:17 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has joined #bitcoin-core-dev
18:26 -!- promag [~promag@83.223.233.21] has quit [Read error: Connection reset by peer]
18:43 -!- promag [~promag@83.223.233.21] has joined #bitcoin-core-dev
18:50 -!- Karyon [~Karyon@unaffiliated/karyon] has quit [Quit: ZNC - https://znc.in]
18:52 -!- Karyon [~Karyon@unaffiliated/karyon] has joined #bitcoin-core-dev
19:03 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Ping timeout: 258 seconds]
19:07 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
19:12 < fanquake> achow101: "Descriptors" with a horrible yellow colour
19:21 < emilengler> Where are the blocks being written to the disk (file, function)?
19:21 -!- promag [~promag@83.223.233.21] has quit [Remote host closed the connection]
19:21 < emilengler> And how do the blocks are even stored? An urban hymn says through leveldb
19:22 < emilengler> So is there a concret place in the src where the actual writing process happens?
19:22 < achow101> emilengler: somewhere in validation.cpp
19:23 < emilengler> achow101: thanks
19:23 < achow101> blocks are written to the blk*.dat files in the blocks/ folder. leveldb is used for the indexes and other databases
19:24 < achow101> emilengler: look at AcceptBlock, FlushStateToDisk, and FlushBlockFile
19:25 < achow101> and SaveBlockToDisk
19:25 < emilengler> Ok, I will check it :)
19:27 -!- uagerugh [kvirc@gateway/vpn/nordvpn/nptm] has joined #bitcoin-core-dev
19:28 -!- uagerugh [kvirc@gateway/vpn/nordvpn/nptm] has quit [Quit: KVIrc 5.0.0 Aria http://www.kvirc.net/]
19:29 < emilengler> By the way what is the AppVeyor thing and is it normal that it takes forever to finish?
19:30 < sipa> it's a windows CI
19:34 < emilengler> It might be buggy, the status on a GitHub PR which I started a month ago isn't being updated even the build was a success
19:35 < sipa> it absolutely is
19:35 < sipa> :)
19:35 < emilengler> Good to know :D
19:35 < emilengler> No wonder it's windows...
19:37 < mryandao> is there a reason why lots of the logic going on in validation.cpp does not get refactored out into other files?
19:38 < sipa> mryandao: because refactoring is hard
19:38 < sipa> especially consensus critical code
19:38 < mryandao> I see. 
19:38 -!- xzytrewq [quassel@gateway/vpn/nordvpn/nptm] has joined #bitcoin-core-dev
19:41 < emilengler> Refactoring can often lead to some new bugs. Bugs in the consensus are a HUGE problem. A refactor of it would probably take lots of testing and reviewing
19:45 < sipa> there are always efforts to refactor things here and there
19:45 < sipa> over time lots of code has moved
19:46 -!- xzytrewq [quassel@gateway/vpn/nordvpn/nptm] has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
19:46 < achow101> i remember good ol main.cpp
19:47 < sipa> in 2010 there was main.cpp which contained all of what is now validation/net_processing/net/wallet/protocol/coins/pow/...
19:47 < emilengler> I never saw it but the file where the main class is, is mostly bloated. Know this from my personal projects. It might be a curse of C++...
19:48 < emilengler> Bloated at the beginning at least
19:48 < mryandao> i believe at 0.12 it was a bloated main.cpp
19:48 < mryandao> that is not too long ago
19:48 < achow101> checkout some of the older tags, you'll see it there
19:48 < mryandao> the hong kong agreement drama times
19:49 < achow101> main.cpp was only split up and removed in 0.14
19:50 -!- pinheadmz [~matthewzi@209.209.238.169] has joined #bitcoin-core-dev
19:51 < emilengler> I'm currently looking at v0.3.0
19:51 < emilengler> It is bloated in terms of v0.3.0 but not in terms of v0.18 :P
19:51 < emilengler> the main file^^
19:51 < mryandao> i hear poker logic existed in 0.1 or something
19:51 < sipa> well, the code gained a lot of functionality since then
19:51 < mryandao> maybe somebody here can verify
19:51 < sipa> it's unfair to compare total complexity; of course it'll be more complex now
19:52 < achow101> mryandao: checkout v0.1.5 and look for yourself
19:52 < emilengler> Sure
19:52 < sipa> but in https://github.com/bitcoin/bitcoin/blob/v0.3.17/main.cpp you'll find direct calls from main.cpp into the UI :p
19:52 < sipa> which is unthinkable now
19:52 < achow101> I seem to remember that at one point in time that main.cpp was large enough (and github shitty enough) that it wouldn't be fully rendered
19:52 < sipa> yeah
19:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
19:54 < emilengler> <joke>If it hadn't been splitted up, it would be a git lfs file today</joke>
19:55 < mryandao> v0.1.5 is so minimalist
19:55 < mryandao> i like.
19:55 < mryandao> could maintain with just vanilla vim without plugins
19:56 < achow101> it's windows and gui only, so you wouldn't be using vim to dev it
19:56 < mryandao> there's gvim on windows
19:56 < emilengler> Is vim that bad on windows?
19:57 < elichai2> Windows is that bad period. 
19:57 < emilengler> ACK
19:57 < achow101> well vanilla vim doesn't exist on windows
19:57 < emilengler> achow101: What do you mean by this
19:58 < mryandao> i cant find poker in v0.1.5
19:58 < emilengler> mryandao: IIRC the poker was only a GUI thing
19:58 < emilengler> You could try to open the project with a wxWidgets editor
19:58 < emilengler> Then you might find something
19:59 < mryandao> oh, i see it now.
19:59 < mryandao> thanks.
19:59 < mryandao> lol, what a meme.
19:59 < achow101> I thought poker was pre-release
20:00 -!- paulk [~paulk@195.206.169.238] has quit []
20:00 < emilengler> achow101: A friend of me is compiling vanilla vim for windows around every 2 days
20:00 < achow101> emilengler: TIL
20:00 < emilengler> There is also a real vim binary for windows (Not the gui stuff)
20:01 < achow101> I didn't know that the vim project actually published windows releases
20:02 < emilengler> IIRC they still don't
20:02 < emilengler> You need to compile it on your own or use pre-compiled online binaries from others
20:02 < emilengler> But they support windows in terms of cross-platform
20:03 < emilengler> Same with Bitcoin Core and FreeBSD for example
20:03 < achow101> ah
20:03 < achow101> fun fact, bitcoin 0.1 was released before Windows 7
20:05 -!- rex4539 [~rex4539@2a02:587:3514:c700:c14e:4527:71bb:a7c2] has joined #bitcoin-core-dev
20:06 < emilengler> achow101: You're right but I never thought of it
20:06 < emilengler> It was probably compiled on Windows XP because the screenshots from satoshi had this old winxp theming
20:07 -!- rex4539 [~rex4539@2a02:587:3514:c700:c14e:4527:71bb:a7c2] has quit [Client Quit]
20:08 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has quit [Remote host closed the connection]
20:08 -!- emilengler [emilengler@gateway/vpn/privateinternetaccess/emilengler] has quit [Quit: WeeChat 2.3]
20:09 -!- esotericnonsense [~esotericn@unaffiliated/esotericnonsense] has joined #bitcoin-core-dev
20:15 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Remote host closed the connection]
20:16 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #bitcoin-core-dev
20:18 -!- davec [~davec@24.243.249.218] has quit [Ping timeout: 245 seconds]
20:18 -!- Toflar [~Toflar@185.5.172.148] has joined #bitcoin-core-dev
20:26 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev
20:27 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
20:28 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 244 seconds]
20:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 258 seconds]
20:36 -!- mzygar [~mzygar@ip-213-127-8-82.ip.prioritytelecom.net] has joined #bitcoin-core-dev
20:40 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Ping timeout: 260 seconds]
20:41 -!- mzygar [~mzygar@ip-213-127-8-82.ip.prioritytelecom.net] has quit [Ping timeout: 245 seconds]
21:01 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
21:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]
21:50 -!- bulias [7ab309c5@122.179.9.197] has joined #bitcoin-core-dev
21:50 -!- bulias [7ab309c5@122.179.9.197] has left #bitcoin-core-dev []
21:51 -!- anewjoiner [7ab309c5@122.179.9.197] has joined #bitcoin-core-dev
21:57 -!- kcalvinalvin [~calvin@104.143.95.21] has joined #bitcoin-core-dev
22:02 -!- hebasto [~hebasto@95.164.65.194] has joined #bitcoin-core-dev
22:13 -!- elichai2 [uid212594@gateway/web/irccloud.com/x-cifrxgtyifyocxrl] has quit [Quit: Connection closed for inactivity]
22:32 -!- anewjoiner [7ab309c5@122.179.9.197] has quit [Remote host closed the connection]
23:00 -!- Toflar [~Toflar@185.5.172.148] has quit []
23:18 -!- bugbot1 [~bugbot@141.98.101.133] has joined #bitcoin-core-dev
23:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev
--- Log closed Sat Aug 03 00:00:28 2019