--- Day changed Thu Jun 22 2017 00:00 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #10649: Make sure we only mine via the first wallet (master...2017/06/wallet_generate) https://github.com/bitcoin/bitcoin/pull/10649 00:01 -!- neel [~neel@79.184.220.5.ipv4.supernova.orange.pl] has joined #bitcoin-core-dev 00:05 -!- neel [~neel@79.184.220.5.ipv4.supernova.orange.pl] has quit [Ping timeout: 240 seconds] 00:16 -!- neel [~neel@79.184.220.5.ipv4.supernova.orange.pl] has joined #bitcoin-core-dev 00:27 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 276 seconds] 00:38 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #10650: Multiwallet: add RPC endpoint support (master...2017/06/wallet_rpc_endpoint) https://github.com/bitcoin/bitcoin/pull/10650 00:46 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection] 00:47 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev 00:49 -!- neel [~neel@79.184.220.5.ipv4.supernova.orange.pl] has quit [Remote host closed the connection] 00:51 -!- neel [~neel@79.184.220.5.ipv4.supernova.orange.pl] has joined #bitcoin-core-dev 01:01 -!- neel [~neel@79.184.220.5.ipv4.supernova.orange.pl] has quit [Remote host closed the connection] 01:23 -!- ryanku___ [~ryankung@45.32.15.249] has joined #bitcoin-core-dev 01:25 -!- ryankung_ [~ryankung@45.32.15.249] has joined #bitcoin-core-dev 01:28 -!- ryanku___ [~ryankung@45.32.15.249] has quit [Ping timeout: 255 seconds] 01:29 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev 01:34 -!- ryankung_ [~ryankung@45.32.15.249] has quit [] 01:34 -!- ryankun__ [~ryankung@45.32.15.249] has joined #bitcoin-core-dev 01:35 -!- ryankun__ [~ryankung@45.32.15.249] has quit [Client Quit] 01:39 -!- ryankung_ [~ryankung@45.32.15.249] has joined #bitcoin-core-dev 01:40 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has joined #bitcoin-core-dev 01:41 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has quit [Remote host closed the connection] 01:41 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds] 01:42 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 01:43 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has joined #bitcoin-core-dev 01:53 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d083bd9b9c52...c68a9a69278a 01:53 < bitcoin-git> bitcoin/master 5555fa8 MarcoFalke: qa: Add stopatheight test 01:53 < bitcoin-git> bitcoin/master c68a9a6 MarcoFalke: Merge #10632: qa: Add stopatheight test... 01:54 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #10632: qa: Add stopatheight test (master...Mf1706-qaStopAtHeight) https://github.com/bitcoin/bitcoin/pull/10632 02:01 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 02:09 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev 02:18 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has quit [Remote host closed the connection] 02:24 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has joined #bitcoin-core-dev 02:24 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has quit [Read error: Connection reset by peer] 02:25 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 248 seconds] 02:25 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has joined #bitcoin-core-dev 02:30 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 02:50 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has quit [Remote host closed the connection] 02:51 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has joined #bitcoin-core-dev 02:59 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has quit [Remote host closed the connection] 03:02 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has joined #bitcoin-core-dev 03:05 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 255 seconds] 03:07 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has quit [Ping timeout: 255 seconds] 03:10 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has joined #bitcoin-core-dev 03:13 -!- JackH [~laptop@46.231.18.66] has quit [Ping timeout: 255 seconds] 03:13 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev 03:27 -!- JackH [~laptop@77.61.5.33] has joined #bitcoin-core-dev 04:00 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds] 04:03 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 04:06 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has quit [Remote host closed the connection] 04:12 -!- ryankung_ [~ryankung@45.32.15.249] has quit [Ping timeout: 246 seconds] 04:21 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 04:24 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 04:46 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has quit [Ping timeout: 240 seconds] 05:01 -!- Alina-malina [~Alina-mal@37.157.223.80] has joined #bitcoin-core-dev 05:05 -!- JackH [~laptop@77.61.5.33] has quit [Remote host closed the connection] 05:06 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection] 05:07 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has joined #bitcoin-core-dev 05:08 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has quit [Ping timeout: 255 seconds] 05:09 -!- gill3s [~textual@unaffiliated/gill3s] has joined #bitcoin-core-dev 05:13 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has quit [Ping timeout: 246 seconds] 05:17 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has joined #bitcoin-core-dev 05:17 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 05:25 -!- gill3s [~textual@unaffiliated/gill3s] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…] 05:32 -!- Void_ [598ccec6@gateway/web/freenode/ip.89.140.206.198] has joined #bitcoin-core-dev 05:39 -!- marcoagn1 [~user@177.41.193.43] has quit [Ping timeout: 255 seconds] 05:41 -!- marcoagn1 [~user@177.41.193.43] has joined #bitcoin-core-dev 05:44 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 05:47 -!- marcoagn1 [~user@177.41.193.43] has quit [Ping timeout: 246 seconds] 05:51 -!- marcoagn1 [~user@177.41.193.43] has joined #bitcoin-core-dev 05:56 -!- Void_ is now known as pvoid 05:56 -!- pvoid is now known as random 06:04 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has quit [Remote host closed the connection] 06:04 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 06:17 -!- vicenteH` [~user@135.234.15.37.dynamic.jazztel.es] has joined #bitcoin-core-dev 06:17 -!- vicenteH [~user@135.234.15.37.dynamic.jazztel.es] has quit [Ping timeout: 260 seconds] 06:29 -!- neel_ [~neel@static-78-10-119-91.ssp.dialog.net.pl] has joined #bitcoin-core-dev 06:32 -!- ProfMac [43c671dc@gateway/web/freenode/ip.67.198.113.220] has quit [Ping timeout: 260 seconds] 06:32 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev 06:44 -!- Alina-malina [~Alina-mal@37.157.223.80] has quit [Changing host] 06:44 -!- Alina-malina [~Alina-mal@unaffiliated/alina-malina] has joined #bitcoin-core-dev 06:53 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev 06:53 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 06:54 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev 06:57 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds] 07:03 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds] 07:05 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 07:11 -!- Char0n [~Char0n@unaffiliated/char0n] has quit [Ping timeout: 240 seconds] 07:12 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c68a9a69278a...1d991f6f18df 07:12 < bitcoin-git> bitcoin/master 700d8d8 practicalswift: Remove obsolete _MSC_VER check... 07:12 < bitcoin-git> bitcoin/master 1d991f6 Wladimir J. van der Laan: Merge #10642: Remove obsolete _MSC_VER check... 07:12 < bitcoin-git> [bitcoin] laanwj closed pull request #10642: Remove obsolete _MSC_VER check (master...undefined-msc-ver) https://github.com/bitcoin/bitcoin/pull/10642 07:21 -!- To7 [~theo@2604:2000:1382:b7:f9c6:d198:e3aa:b7e6] has joined #bitcoin-core-dev 07:21 -!- chjj [~chjj@unaffiliated/chjj] has quit [Quit: WeeChat 1.8] 07:26 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds] 07:27 -!- jnewbery_ [~john@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 240 seconds] 07:27 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has quit [Ping timeout: 240 seconds] 07:27 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Ping timeout: 260 seconds] 07:28 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 07:29 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 07:29 -!- sdaftuar [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 07:29 -!- sdaftuar [~sdaftuar@static-100-38-11-146.nycmny.fios.verizon.net] has quit [Changing host] 07:29 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev 07:29 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 07:31 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1d991f6f18df...8465b68985f4 07:31 < bitcoin-git> bitcoin/master 2c3fc51 fanquake: [depends] expat 2.2.1 07:31 < bitcoin-git> bitcoin/master 8465b68 Wladimir J. van der Laan: Merge #10628: [depends] expat 2.2.1... 07:31 < bitcoin-git> [bitcoin] laanwj closed pull request #10628: [depends] expat 2.2.1 (master...expat-2-2-1) https://github.com/bitcoin/bitcoin/pull/10628 07:32 -!- Char0n [~Char0n@unaffiliated/char0n] has joined #bitcoin-core-dev 07:33 < sdaftuar> sipa: i've finished my functional test for #10148 -- https://github.com/sdaftuar/bitcoin/tree/test-10148 07:33 < gribble> https://github.com/bitcoin/bitcoin/issues/10148 | Use non-atomic flushing with block replay by sipa · Pull Request #10148 · bitcoin/bitcoin · GitHub 07:47 -!- neel_ [~neel@static-78-10-119-91.ssp.dialog.net.pl] has quit [Remote host closed the connection] 07:49 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has joined #bitcoin-core-dev 07:57 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has quit [Quit: Leaving] 08:04 < bitcoin-git> [bitcoin] laanwj closed pull request #10541: Docs: Update INSTALL.md to add link to build notes (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10541 08:10 -!- echonaut3 [~echonaut@46.101.192.134] has quit [Remote host closed the connection] 08:10 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev 08:17 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/8465b68985f4...87e69c2549c4 08:17 < bitcoin-git> bitcoin/master e5c6168 Pavlos Antoniou: Fix instantiation and array accesses in class base_uint... 08:17 < bitcoin-git> bitcoin/master 87e69c2 Wladimir J. van der Laan: Merge #10530: Fix invalid instantiation and possibly unsafe accesses of array in class base_uint... 08:17 < bitcoin-git> [bitcoin] laanwj closed pull request #10530: Fix invalid instantiation and possibly unsafe accesses of array in class base_uint (master...master) https://github.com/bitcoin/bitcoin/pull/10530 08:20 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit [Killed (Sigyn (Spam is off topic on freenode.))] 08:20 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 08:31 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has quit [Remote host closed the connection] 08:37 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has joined #bitcoin-core-dev 08:39 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has quit [Remote host closed the connection] 08:43 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 08:43 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 08:44 < bitcoin-git> [bitcoin] laanwj closed pull request #8831: Replace CWalletDB::ReadKeyValue with CWallet::LoadKeyValue (master...2016-09-28-cwallet-loadkeyvalue) https://github.com/bitcoin/bitcoin/pull/8831 08:44 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev 08:45 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev 08:46 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 248 seconds] 08:51 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev 08:57 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has joined #bitcoin-core-dev 09:01 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 09:08 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has quit [Remote host closed the connection] 09:09 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has joined #bitcoin-core-dev 09:09 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has quit [Remote host closed the connection] 09:11 -!- nelruk [~nelruk@181.121.114.116] has joined #bitcoin-core-dev 09:17 -!- Guyver2_ [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 09:19 -!- def [~def@kekkonen.niksula.hut.fi] has joined #bitcoin-core-dev 09:20 < earlz> Why is CheckTransaction in CheckBlock just a normal rejection and not a DoS rejection? Is there some valid case where CheckTransaction can fail and it not be a malicious actor? 09:20 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)] 09:20 -!- Guyver2_ is now known as Guyver2 09:23 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/87e69c2549c4...209eef60a9ac 09:23 < bitcoin-git> bitcoin/master 6171826 Alex Morcos: Don't create change at the dust limit, even if it means paying more than expected 09:23 < bitcoin-git> bitcoin/master 209eef6 Wladimir J. van der Laan: Merge #9343: Don't create change at dust limit... 09:23 < sipa> earlz: yes! 09:23 < bitcoin-git> [bitcoin] laanwj closed pull request #9343: Don't create change at dust limit (master...noneconomicchange) https://github.com/bitcoin/bitcoin/pull/9343 09:23 < sipa> soft forks 09:24 < sipa> earlz: the peer may not be aware of a softfork that you are aware of 09:25 < def> https://0x0.st/lFn.txt <- i can't get signrawtransaction to work, any ideas? i know this isn't a support channel but i'm becoming increasingly convinced that this might be a bug in bitcoin-qt 09:33 -!- nelruk [~nelruk@181.121.114.116] has quit [Ping timeout: 240 seconds] 09:34 < sipa> def: can you show the output you are trying to spend? 09:35 < earlz> ah, didn't think about softforks 09:35 -!- CryptoAna [563fac40@gateway/web/freenode/ip.86.63.172.64] has joined #bitcoin-core-dev 09:38 -!- nelruk [~nelruk@181.121.114.116] has joined #bitcoin-core-dev 09:38 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has joined #bitcoin-core-dev 09:39 -!- neel [~neel@static-78-10-119-91.ssp.dialog.net.pl] has quit [Remote host closed the connection] 09:43 -!- CryptoAna [563fac40@gateway/web/freenode/ip.86.63.172.64] has quit [Quit: Page closed] 09:46 -!- nelruk [~nelruk@181.121.114.116] has quit [Ping timeout: 246 seconds] 09:50 -!- nelruk [~nelruk@181.121.114.116] has joined #bitcoin-core-dev 09:54 -!- nelruk [~nelruk@181.121.114.116] has quit [Ping timeout: 240 seconds] 10:00 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 10:00 -!- nelruk [~nelruk@181.121.114.116] has joined #bitcoin-core-dev 10:07 -!- nelruk [~nelruk@181.121.114.116] has quit [Ping timeout: 276 seconds] 10:10 -!- nelruk [~nelruk@181.121.114.116] has joined #bitcoin-core-dev 10:16 < bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/209eef60a9ac...ffce893982d9 10:16 < bitcoin-git> bitcoin/master fd369d2 Kalle Alm: Switched httpserver.cpp to use RAII wrapped libevents. 10:16 < bitcoin-git> bitcoin/master 1ae86ec Karl-Johan Alm: Changed event RAII helper functions to inline to deal with duplicate symbol linker errors. 10:16 < bitcoin-git> bitcoin/master ffce893 Wladimir J. van der Laan: Merge #9517: [refactor] Switched httpserver.cpp to use RAII wrapped libevents.... 10:17 < bitcoin-git> [bitcoin] laanwj closed pull request #9517: [refactor] Switched httpserver.cpp to use RAII wrapped libevents. (master...raii-httpserver) https://github.com/bitcoin/bitcoin/pull/9517 10:17 -!- nelruk [~nelruk@181.121.114.116] has quit [Ping timeout: 240 seconds] 10:20 -!- nelruk [~nelruk@181.121.114.116] has joined #bitcoin-core-dev 10:27 -!- nelruk [~nelruk@181.121.114.116] has quit [Ping timeout: 260 seconds] 10:30 -!- nelruk [~nelruk@181.121.114.116] has joined #bitcoin-core-dev 10:33 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ffce893982d9...b750b33c3cea 10:33 < bitcoin-git> bitcoin/master 8d4dafd Andres G. Aragoneses: contrib/verifybinaries: allow filtering by platform... 10:33 < bitcoin-git> bitcoin/master b750b33 Wladimir J. van der Laan: Merge #10276: contrib/verifybinaries: allow filtering by platform... 10:33 < bitcoin-git> [bitcoin] laanwj closed pull request #10276: contrib/verifybinaries: allow filtering by platform (master...filterByPlatformInVerifySh) https://github.com/bitcoin/bitcoin/pull/10276 10:46 -!- gaf_ [~fag@12.smos-linux.org] has quit [Quit: SMOS - http://smos-linux.org] 10:51 -!- gaf_ [~fag@12.smos-linux.org] has joined #bitcoin-core-dev 10:54 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/b750b33c3cea...01c4b143a87e 10:54 < bitcoin-git> bitcoin/master cf68a48 Pieter Wuille: Deduplicate addrdb.cpp and use CHashWriter/Verifier 10:55 < bitcoin-git> bitcoin/master 01c4b14 Wladimir J. van der Laan: Merge #10248: Rewrite addrdb with less duplication using CHashVerifier... 10:55 < bitcoin-git> [bitcoin] laanwj closed pull request #10248: Rewrite addrdb with less duplication using CHashVerifier (master...chashverifier) https://github.com/bitcoin/bitcoin/pull/10248 10:59 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev 11:04 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 11:05 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10651: Verify binaries from bitcoincore.org and bitcoin.org (master...2017-06-verify-coreorg) https://github.com/bitcoin/bitcoin/pull/10651 11:09 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 240 seconds] 11:10 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 11:18 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 11:18 -!- def [~def@kekkonen.niksula.hut.fi] has left #bitcoin-core-dev [] 11:19 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/01c4b143a87e...4bc853b50fd9 11:19 < bitcoin-git> bitcoin/master 999923e MarcoFalke: [qa] util: Check return code after closing bitcoind proc... 11:19 < bitcoin-git> bitcoin/master 4bc853b MarcoFalke: Merge #10636: [qa] util: Check return code after closing bitcoind proc... 11:19 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #10636: [qa] util: Check return code after closing bitcoind proc (master...Mf1706-qaTraceback) https://github.com/bitcoin/bitcoin/pull/10636 11:25 -!- eenoch [~eenoch@unaffiliated/eenoch] has quit [Ping timeout: 240 seconds] 11:25 -!- bordeaux_facile [~a@128.199.208.178] has quit [Ping timeout: 260 seconds] 11:32 -!- bordeaux_facile [~a@128.199.208.178] has joined #bitcoin-core-dev 11:41 -!- nelsondcg [~nelruk@181.121.114.116] has joined #bitcoin-core-dev 11:42 -!- nelruk [~nelruk@181.121.114.116] has quit [Ping timeout: 240 seconds] 11:44 -!- mryandao [~mryandao@unaffiliated/mryandao] has quit [Ping timeout: 240 seconds] 11:44 -!- mryandao [~mryandao@45.76.118.157] has joined #bitcoin-core-dev 11:44 -!- mryandao [~mryandao@45.76.118.157] has quit [Changing host] 11:44 -!- mryandao [~mryandao@unaffiliated/mryandao] has joined #bitcoin-core-dev 11:46 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4bc853b50fd9...6bef7ca8bc6a 11:46 < bitcoin-git> bitcoin/master 0a5a6b9 Dimitris Tsapakidis: Fixed multiple typos... 11:46 < bitcoin-git> bitcoin/master 6bef7ca Wladimir J. van der Laan: Merge #10633: doc: Fix various typos... 11:47 < bitcoin-git> [bitcoin] laanwj closed pull request #10633: doc: Fix various typos (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10633 11:48 -!- eenoch [~eenoch@unaffiliated/eenoch] has joined #bitcoin-core-dev 11:57 < bitcoin-git> [bitcoin] laanwj pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/6bef7ca8bc6a...8c2098ad1209 11:57 < bitcoin-git> bitcoin/master c8914b9 Andrew Chow: Have `make cov` optionally include branch coverage statistics... 11:57 < bitcoin-git> bitcoin/master 405b86a Andrew Chow: Replace lcov -r commands with faster way... 11:57 < bitcoin-git> bitcoin/master d5711f4 Andrew Chow: Filter subtrees and and benchmarks from coverage report... 11:58 < bitcoin-git> [bitcoin] laanwj closed pull request #10565: [coverage] Remove subtrees and benchmarks from coverage report (master...lcov-remove-extra) https://github.com/bitcoin/bitcoin/pull/10565 12:00 < BlueMatt> meeting? 12:00 < wumpus> #startmeeting 12:00 < lightningbot> Meeting started Thu Jun 22 19:00:45 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 < achow101> hi 12:00 < jonasschnelli> hi 12:00 < wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 12:01 < cfields> hi 12:01 < wumpus> topics? 12:01 < sipa> ohai 12:01 < wumpus> #topic high priority for review 12:01 -!- jtimon [~quassel@c-73-189-35-88.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 12:01 < wumpus> #link https://github.com/bitcoin/bitcoin/projects/8 12:02 < wumpus> any new ones? 12:02 < BlueMatt> should i give up on #10179 (+ #10286)? 12:02 < gribble> https://github.com/bitcoin/bitcoin/issues/10179 | Give CValidationInterface Support for calling notifications on the CScheduler Thread by TheBlueMatt · Pull Request #10179 · bitcoin/bitcoin · GitHub 12:02 < BlueMatt> at least for 15 12:02 < gribble> https://github.com/bitcoin/bitcoin/issues/10286 | Call wallet notify callbacks in scheduler thread (without cs_main) by TheBlueMatt · Pull Request #10286 · bitcoin/bitcoin · GitHub 12:02 < sipa> BlueMatt: no 12:02 < kanzure> hi. 12:03 < BlueMatt> sipa: well i mean point being that is something that really needs to stew in master for a month (or more) before a release 12:03 < BlueMatt> so its hitting up against the 15 deadline already 12:03 < wumpus> why give up? 12:03 < instagibbs> hi 12:03 < BlueMatt> not a huge deal to push to 16 12:03 < BlueMatt> because i dont want to ship 10286 right after merging it 12:03 < BlueMatt> its a real not-gonna-see-the-issues-unless-its-in-master-for-a-month kinda thing :( 12:04 < wumpus> that's about the risk - what would be the main gain for merging it for 0.15? 12:04 < wumpus> eh it's already in high-priority for review category 12:05 < wumpus> we can't bump it anything higher :p 12:05 < BlueMatt> well im asking if we should drop it from high priority, unless we still think we can get both in pretty quick i think we should say we wont until its 16 12:05 < jtimon> I would like review on #8498 12:05 < gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub 12:05 < wumpus> ok, but I mean, what would we lose if we decide to drop it for 0.15. Is there something else would be prioritized before it? 12:06 < wumpus> I don't think it collides with e.g. multiwallet 12:06 -!- ryanofsky_ is now known as ryanofsky 12:06 < BlueMatt> just 10286 - the dont-really-block-on-wallet-for-block-connection thing 12:06 < BlueMatt> its not itself a huge win, but iterative steps towards better disconnection 12:06 < cfields> BlueMatt: I'll try to get through it today, I've put it off long enough :) 12:06 < BlueMatt> i know ryanofsky wanted it for the separate-process-wallet stuff he was working on 12:07 < sipa> BlueMatt: how about we re-assess it next week? 12:07 < BlueMatt> ok, sounds good 12:07 < jtimon> and #8994 too, not sure which one is more likely to get it 12:07 < wumpus> looks like they're both getting reviews 12:07 < sipa> and hope for review in the mean time 12:07 < gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub 12:07 < wumpus> yeah... 12:07 < ryanofsky> yeah i'd prefer 10286 not to be delayed for months 12:07 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection] 12:08 < jonasschnelli> #10286 12:08 < gribble> https://github.com/bitcoin/bitcoin/issues/10286 | Call wallet notify callbacks in scheduler thread (without cs_main) by TheBlueMatt · Pull Request #10286 · bitcoin/bitcoin · GitHub 12:09 < wumpus> ok, any other topics? 12:09 < jtimon> wumpus: well, maybe none of my prs should be in project 8, I don't know 12:09 -!- nel [~nelruk@181.121.114.116] has joined #bitcoin-core-dev 12:09 < phantomcircuit> pong 12:09 < sipa> wumpus: coin selection / effective feerate / bnb 12:09 < wumpus> jtimon: I'm not sure that one warrants extra priority pre-0.15 12:09 < BlueMatt> random PSA: there is now a copy of binaries hosted on https://bitcoincore.org/bin as well as https://bitcoin.org/bin. This will be the new "official" download site (though the bitcoin.org folks said they were gonna keep their mirror up for those who are used to bitcoin.org to not have to hop to another site) 12:10 < wumpus> sipa: that's one topic or three? 12:10 < sipa> wumpus: one 12:10 < wumpus> #topic coin selection / effective feerate / bnb 12:10 < sipa> we have a number of open PRs (and one just merged I think) that interact with coin selection 12:10 < jtimon> wumpus: egoistically for elements project, it would be very nice to have #8994 before 0.15 for next elements rebase (not that bitcoin should care) 12:10 < gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub 12:11 < sipa> #10637 #10360 #10333 12:11 < jtimon> regarding #8498 it's an optimization (perhaps again "not worth it", like #10339) 12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/10360 | [WIP] [Wallet] Target effective value during transaction creation by instagibbs · Pull Request #10360 · bitcoin/bitcoin · GitHub 12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub 12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/10333 | [wallet] fee fixes: always create change, adjust value, and p… by instagibbs · Pull Request #10333 · bitcoin/bitcoin · GitHub 12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/8498 | Optimization: Minimize the number of times it is checked that no money... by jtimon · Pull Request #8498 · bitcoin/bitcoin · GitHub 12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/10339 | Optimization: Calculate block hash less times by jtimon · Pull Request #10339 · bitcoin/bitcoin · GitHub 12:11 < sipa> are instagibbs, achow101, ... here? 12:12 < instagibbs> I'm not sure many are even close to merge. 12:12 < instagibbs> yeah 12:12 < sipa> i agree 12:12 < achow101> i'm here 12:12 < gmaxwell> Hellow meeting. 12:12 -!- nelsondcg [~nelruk@181.121.114.116] has quit [Ping timeout: 260 seconds] 12:12 < instagibbs> 10333 is closest, but needs more revision 12:12 < sipa> but i think there are two approaches to follow here 12:12 < wumpus> jtimon: I really think we should have #8994, but it seems to collide with a lot of other things 12:12 < gribble> https://github.com/bitcoin/bitcoin/issues/8994 | Testchains: Introduce custom chain whose constructor... by jtimon · Pull Request #8994 · bitcoin/bitcoin · GitHub 12:13 < sipa> one is to aim for overhauling coin selection... which will take a long time, and probably should be merged early in a cycle, so not for 0.15 12:13 < gmaxwell> 10333 needs to get in (in some form) because it's an important fix. 12:13 < instagibbs> I can do suggested change that gmaxwell gave, which I noted. 12:13 < sipa> another is to make changes that 1) fix existing bugs and 2) work as a preprocessing step (in the form "let's see if algorithm X finds a good solution... otherwise fallback to what exists" 12:14 < wumpus> agree with doing coin selection changes early in a release cycle 12:14 < sipa> if 10333 is considered a bug fix, perhaps it should be prioritized for 0.15? 12:14 < jtimon> wumpus: I guess that will wait forever then, previous versions were closed because they "collided with mempool/fee stuff", like more than 1 year ago? I'm happy to help people do the trivial rebases for people if that's the problem 12:14 < jtimon> anyway, topic changed... 12:14 < gmaxwell> 10333 should do nothing other than prevent serious overpayment in some corner cases. 12:14 < instagibbs> sipa, It's marked as such, but if people deem it higher priority I'll make it one 12:15 < gmaxwell> (at least once it's twiddled some) 12:15 < sipa> would 10333 + 10637 be reasonable to aim for in 0.15? 12:15 < instagibbs> It needs rebasing likely due to recent dust change merge 12:15 < instagibbs> #10637 12:15 < gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub 12:16 < wumpus> I don't think so 12:16 < instagibbs> latter seems a stretch imo, as great as it would be. 12:16 < wumpus> #10637 would be better for 0.16 IMO 12:16 < gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub 12:16 < sipa> to clarify, 10637 is just a preprocessing step that makes it much more likely to find a match without change, reducing UTXO set size 12:16 < wumpus> the other one is already marked for 0.15 12:16 < sipa> if it fails, it falls back to what we have 12:16 < achow101> I don't think 10637 would be good for 0.15. I haven't entirely made sure that it doesn't do anything stupid 12:16 < instagibbs> sipa, if the code is correct, sure, earlier it wasn't (I'd have to do lots of review to make sure) 12:16 < sipa> ok 12:16 < sipa> instagibbs: of course 12:17 < gmaxwell> I am not in favor of takin total overhaul as a general strategy. The problem is that each logical change has a complex 'whole system impact' question connected to it, which is really hard to reasona about for "hay guies, I replaced the whole thing!" So I would much rather see a series of 'obviously sane' changes followed by "I reworked it to make the code clearer with no substantive change in b 12:17 < wumpus> achow101: agree, no need to hurry it just to make a release 12:17 < instagibbs> it's a nasty web of code, not his fault, just a fact 12:17 < gmaxwell> ehavior". 12:17 < sipa> ok, so let's aim for all coin selection changes in 0.16 12:17 < sipa> apart from bug fixes 12:17 < wumpus> the problem is that at some point the code is so convoluted that no option remains but 'redesign the whole thing' 12:17 < jtimon> yeah, I've been trying to do something like #8494 since at least Jun 10, 2015, but I think actually earlier 12:17 < gmaxwell> :( is it so late to the end of 0.15 that we're slipping things out of it? 12:18 < gribble> https://github.com/bitcoin/bitcoin/issues/8494 | [init, wallet] ParameterInteraction() iff wallet enabled by MarcoFalke · Pull Request #8494 · bitcoin/bitcoin · GitHub 12:18 < wumpus> most of that has been replaced by now, but the coin selection code is arguably some of that 12:18 < sipa> gmaxwell: i wish you were right, but i believe at some point we'll need to bite the bullet 12:18 < sipa> though a number of steps can be taken before that point 12:18 < wumpus> gmaxwell: well it starts to be important, even now, to prioritize things 12:18 < instagibbs> With BnB in place, lays decent groundwork for more extensions 12:18 < gmaxwell> wumpus: will then we stay where we've been stuck for years then? I think it improved a lot, changes we made in 0.14 cleaned up CreateTransaction a lot. 12:19 < jtimon> gmaxwell: agree on that way of doing big refactors, that's the sanest way to review them at least 12:19 < instagibbs> making sane change-making policy could come next 12:19 < instagibbs> sane steps exist i think 12:20 -!- nelsondcg [~nelruk@181.121.114.116] has joined #bitcoin-core-dev 12:21 < gmaxwell> sipa: obviously it needs to be reworked, but I cannot review something that is just "here is replacement code that does everything subtly differently" against threats like "will this cause runaway upbidding" or "will this potentially cause the utxo set size to skyrocket relative to the current code" or "will this trash user privacy" (well hard do to worse than the current on that mark. :P). But 12:21 < gmaxwell> I can review things like instagibbs's effective rate change against those criteria. 12:22 < gmaxwell> I think it's important to seperate intentional behavioral changes from implementation structure. 12:22 < jtimon> so why not try to get merged 10333 first which seems the simpler to review and then revisit the other 2 ? 12:22 < gmaxwell> jtimon: instagibbs has changes he needs to make. 12:22 < gmaxwell> And sure. 12:22 * jtimon nods 12:22 -!- nel [~nelruk@181.121.114.116] has quit [Ping timeout: 246 seconds] 12:22 < sipa> gmaxwell: i'm worried about something like 10360 to cause unintended runaway behaviour due to some interaction as well 12:22 < wumpus> jtimon: yes 12:23 < sipa> gmaxwell: even if it looks perfectly fine by all metrics we considered 12:23 < gmaxwell> Though if integrated correctly (not saying it is yet) 10637 is just a preprocessing stage that can't make things worse. (not saying that it's yet integrated correctly). 12:23 < instagibbs> Action item is me incorporating suggestion to 10333 make more robust and beg for review again here 12:23 < wumpus> so should we add 10333 to high priority for review? 12:24 < achow101> imo, yes 12:25 < gmaxwell> sipa: I don't think it looks fine, I think it fixes a flaw we depend on due to a ~total lack of other mechenisms to sweep txins. 12:25 < sipa> gmaxwell: yes, but i can't reason about its total effect 12:26 < gmaxwell> (it's easy to show that 10360 will abandon more txouts than current code; and also the current code will _create_ txouts that an immediate second run under that patch would not consider spending) 12:26 < sipa> i like the change as such, but who knows what interaction we missed 12:26 < sipa> anyway, probably a discussion for later 12:26 < gmaxwell> So the only thing I don't know if the effect would be castrophic or just merely not perfect. 12:27 < sipa> yes, i think 10333 should be prioritized 12:27 < gmaxwell> ack on 10333. 12:27 < wumpus> ok, added 12:28 < gmaxwell> sipa: I think a simple invarient is that we must spend everything we create at least under more or less stationary conditions. Anything less leads to runaway utxo set growth (though perhaps slowly...). 12:29 < gmaxwell> but thats a minimum and perhaps not sufficient. But still 10360 fails it. 12:29 < gmaxwell> to be fair, it's not 10360's fault so much as that we only pass that criteria now due to bugs that 10360 fixes. 12:30 < sipa> other topics? 12:31 < cfields> quick topic suggestion: add "strongly discourage/forbit default function arguments" to the style guide? 12:31 < luke-jr> cfields: eh, I don't think that's a good idea 12:31 < wumpus> #topic add "strongly discourage/forbit default function arguments" to the style guide 12:31 < cfields> *forbid. forbitting would be too much :p 12:31 < BlueMatt> not always 12:31 < wumpus> f-orbitting 12:31 < gmaxwell> default arguments are a footgun for sure, can we articluate where they are okay-- if they aren't forbidden? 12:31 < sipa> f(ire from) orbit? 12:31 < wumpus> no, I don't think that's a good rule in general either 12:31 < luke-jr> the important thing should be making sure the behaviour doesn't change, when func signatures change 12:31 < BlueMatt> if theres 20 arguments to the function or its a big many-callers function, maybe 12:32 < cfields> gmaxwell: yes, i think that's the discussion I was looking for. 12:32 < luke-jr> "if code calling it before compiles with the new signature, it must behave the same" 12:32 < wumpus> if there's 20 arguments to a function there's something wrong in general 12:32 < BlueMatt> but depends on where, eg I think https://github.com/bitcoin/bitcoin/pull/10179/commits/dd53c6f0a3f9fa34b0d8d0f6b9a3e4df51a3eda7 is probably fine 12:32 < wumpus> please make a rule not to have 20 arguments please 12:32 < wumpus> certainly not booleans :( 12:32 < BlueMatt> (adds a default arg to CScheduler::schedule()) 12:32 < BlueMatt> wumpus: lol, yes, indeed 12:32 < sipa> "It is strongly encouraged to have 19 arguments to functions." 12:32 < wumpus> Foo(false, true, false, true, false, true, true) 12:33 < BlueMatt> wumpus: you forgot the NULL for good measure which may or may not be a pointer :p 12:33 < wumpus> BlueMatt: oh yes 12:33 < wumpus> default arguments are mostly good for one thing: transitions without touching all the code 12:33 < gmaxwell> I think the default arg is okay when going from 0 to 1 arguments to add a flag, for example. 12:33 < sipa> well i think defaults arguments are often used to reduce code impact of a patch... adding an optional argument at the end (especially directly after a non-optional one, and with a type incompatible with the first optional one if any) is perfectly safe and can strongly reduce the amount of code touched 12:34 < sipa> the same can be achieved by adding a fewer-arguments wrapper, though 12:34 < wumpus> e.g. if you add an argument to a function that's called from 400 places, it's usually better to add a default argument, at least temporarily 12:34 < wumpus> right. I think that's a valid use. 12:34 < sipa> i like the approach of creating a new function (with more args, and perhaps even a different name), and changing the old one to be a wrapper around the new one 12:35 < luke-jr> indeed, I have been rebasing the rescanblockchain RPC, and this is needed to minimise the conflicts 12:35 < gmaxwell> The defaults lead to negative interactions with the fact that arguments aren't named. I like sipa's suggestion. 12:35 < wumpus> well if it has the same name there is no effective difference 12:35 < luke-jr> (it adds an argument for a stop-scanning index) 12:35 < BlueMatt> sipa: thats how you end up with AcceptToMemoryPoolWorker(tx, true, false, false, true, NULL, (default) false) 12:35 < BlueMatt> :( 12:35 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 12:35 < gmaxwell> wumpus: because when you make further additions to the arguments, you don't mess things up. 12:35 < sipa> that wrapper approach also is more restrictive: it _just_ allows the exact old use case, and a new one - not a variety of combinations based on multiple optional args 12:36 < wumpus> absent argument naming, I like enums better than booleans 12:36 < wumpus> anyhow, no, I don't think we should add a general rule about this 12:36 < gmaxwell> We had a near consensus fault in the main split as a result of something related to this. IIRC. 12:36 < wumpus> just pay attention at reviews to the specific case 12:36 * luke-jr wishes there was a tool to audit such changes for us 12:36 < cfields> ok 12:36 < wumpus> not everything has to be spelled out in the style guide, that just makes for laziness *we've checked all the checkboxes* 12:37 < gmaxwell> right 12:37 < sipa> also, i wish there was a sed-like took that understood our AST a bit better, so you could add a new argument to a function everywhere 12:37 < sipa> but regexps are fundamentally not strong enough to do that :( 12:37 < wumpus> if only c++ was easier to parse... 12:37 < gmaxwell> though I still think sipa's suggestion is good: if you need to introduce an argument to a function called in many places, wrap it with something that provides the default. Then over time we change call sites to call the new function. 12:37 < luke-jr> at least it's not Perl 12:37 < wumpus> you can do things like that using python + clang, but it's pretty involved, and not fun 12:37 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 12:38 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Quit: Leaving] 12:38 < jtimon> ack on strongly discouraging optional arguments, we have way too many and some are really stupid IMO (ehem, ehem #9717 ) 12:38 < gribble> https://github.com/bitcoin/bitcoin/issues/9717 | Pow: Remove fCheckPOW from CheckBlockHeader by jtimon · Pull Request #9717 · bitcoin/bitcoin · GitHub 12:38 < gmaxwell> then we don't end up with function signatures that are full of a mix of default and non-default arguments. 12:38 < wumpus> even if you have a c++ parser you get such a lot of information into your mutation function, so many cases to handle 12:39 < wumpus> gmaxwell: I fully agree, just don't think it makes sense as a rule 12:39 < gmaxwell> ACK 12:40 < jtimon> you can also have simpler wrappers on functions with less parameters and "default values" instead of optional arguments 12:40 < wumpus> yes 12:40 < gmaxwell> yea, thats what sipa was just saying. 12:40 < sipa> jtimon: that's what i was suggestion 12:40 < jtimon> sipa: sorry, catching up... 12:40 < wumpus> though the advantage of default arguments is that they're self-documenting in the function signature 12:42 < wumpus> anyhow, more topics? 12:42 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.7.1] 12:42 < sipa> do we want to bring up multiwallet API again? 12:42 < jonasschnelli> yes 12:42 < gmaxwell> I don't think I've personally found that too useful except for functions with just a couple arguments with one or two simple flags. FrobThing(&thing,FrobHarder=true). 12:42 < wumpus> #topic multiwallet API 12:42 < jonasschnelli> can we decide what we want to use? path or query string and or versioning? 12:42 < wumpus> path 12:42 < jonasschnelli> I think /v1/wallet/ seems ideal 12:42 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 12:43 < gmaxwell> can we at least put a version in first? 12:43 < wumpus> we've decided that last time, that wallet will be based on endpoints 12:43 < luke-jr> query string <.< 12:43 < jonasschnelli> gmaxwell: yes. See above 12:43 < sipa> luke-jr: i've been thinking about the advantages and disadvantages of both 12:43 < jonasschnelli> luke-jr: what advantages do you see with query strings? 12:43 < wumpus> oh sure /v1/something is fine with me 12:43 < luke-jr> jonasschnelli: it's not hacking the path into a parameter? it's extensible? 12:43 < wumpus> if we can use /v1 as the general node endpoint hten 12:43 < sipa> query string has the advantage that it's more flexible - there could be multiple things to direct the RPC, and they don't need to be in a hierarchical pattern 12:43 < wumpus> and /v1/walletname for the wallet 12:44 < wumpus> don't use query strings with POST 12:44 < wumpus> just don't 12:44 < jonasschnelli> luke-jr: you can still add a query string later if you need non-hirarichal inputs later 12:44 < gmaxwell> path seems fine to me, so long as there is a version, but I'm clueless. I do have some questions though. 12:44 < jonasschnelli> what wumpus sais 12:44 < wumpus> POST has always been used with the idea that the parameters are in the payload 12:44 * luke-jr wants to hear the rest of sipa's thoughts. ☺ 12:44 < wumpus> POST should not have URI parameters 12:44 < jonasschnelli> wumpus: exactly 12:44 < ryanofsky> i think query strings are analogous to command line options, paths are analogous to positional command line arguments 12:44 < sipa> however, most things that would go into the path/query string as well, can just become RPC arguments as well 12:45 < wumpus> if you confuse them, it will be hard to use from some languages 12:45 < sipa> i think that perhaps the wallet name is different, in that it's actually a different "module" you're sending it to 12:45 < jonasschnelli> sipa: indeed... but the /wallet/ endpoint could have a different rpc server once 12:45 < ryanofsky> options are better for non required things that tweak the current operation, arguments are better for required values that determine operation 12:45 < gmaxwell> I think it's likely in the future that we'll support doing this "create transaction in wallet A but also able using coins from wallet B,C"-- seems clear to me how this could work in the GUI. How could we RPC call that? 12:45 < sipa> so i think my preference is path - and for things that don't fit in the normal hierarchical structure, use named RPC arguments 12:45 < wumpus> oh no... not commands from multiple wallets 12:45 < sipa> gmaxwell: ugh... 12:45 < wumpus> can we at least agree on one object to apply commands too 12:46 < luke-jr> BTW, did we consider a generic JSON-RPC "wallet" named param? 12:46 < gmaxwell> it's not really 'from multiple wallets'. 12:46 < sipa> luke-jr: i suggested that before, yes 12:46 < wumpus> gmaxwell: in that case you should just use the raw transactions api 12:46 < wumpus> you can listunspent on multiple wallets, then use thei r utxos 12:46 < sipa> luke-jr: i'd be fine with it, except it's less compatible with a future change that moves it to a different process (which will necessarily have a new endpoint) 12:46 < jonasschnelli> luke-jr: generic wallet named parameter seems fine. Is it mixable with the non-named parameter? 12:46 < wumpus> no need to do some obscure voodoo calling a method on multiple objects on the same time 12:46 < gmaxwell> in any case, without that you are forced to make idiotic pay wallet A from wallet B transactions just to make a large payment. (or as wumpus notes, do something with raw transactions) 12:46 < jonasschnelli> I guess we then would only allow wallet selecting with name bases params? 12:46 < wumpus> that way madness lies 12:47 < luke-jr> sipa: ah, right 12:47 < sipa> so i think this guideline may help: arguments that select something that may in the future move to another process, should go into the path 12:47 < gmaxwell> wumpus: fair enough that you wouldn't want to do a ?wallet=a&wallet=b voodoo in any case there, so no interaction with this question. 12:47 < sipa> other things should be RPC named args 12:47 < jonasschnelli> I guess endpoints will also make process separation simpler 12:47 < sipa> jonasschnelli: that's what i was saying 12:48 < wumpus> sipa: +1 12:48 < jonasschnelli> Okay. Lets then go for /v1/wallet/walletID for now 12:48 < wumpus> yes 12:48 < sipa> ack 12:48 < luke-jr> v0? :P 12:48 < jonasschnelli> WalletID is the wallet filename for now... not sure if this is a problem 12:48 < sipa> luke-jr: v0 already exists :p 12:48 < jonasschnelli> v0 is not what users are expecting.. 12:48 < wumpus> no, v1, v0 is what we had before :) 12:48 < luke-jr> but this isn't changing the API 12:49 < sipa> no, it's creating a new API 12:49 < jonasschnelli> it's just a prevention for future api changes 12:49 < wumpus> yes. 12:49 < gmaxwell> adding /wallet/ is a new API. 12:49 < gmaxwell> even though its a trivial one. 12:49 < wumpus> I think it's good to add it just in case, we should be able to use /v1 as endpoint for non-wallet methods 12:49 < wumpus> and / for both wallet methos and non-wallet methods (wallet will use 'the default wallet') 12:49 < luke-jr> oh, that's a point: how do we specify "no wallet"? 12:49 -!- neel [~neel@79.184.220.5.ipv4.supernova.orange.pl] has joined #bitcoin-core-dev 12:49 < jonasschnelli> Yes. /v1 should do the same / (selecting the default wallet) 12:49 < gmaxwell> oh nice, though if we're going to do that, we need to ban wallet methods on /v1/ right away. 12:50 < wumpus> gmaxwell: yes please 12:50 < sipa> how about we also add /v1/node for all non-wallet RPCs? 12:50 < wumpus> /v1 should do away with wallet methods, / should have them for backward compat 12:50 < sipa> yes 12:50 < jonasschnelli> Wait, do we want to ban non wallet methods sent to /v1/wallet/? 12:50 < jtimon> wumpus: why not use query string with POST? we do everything with POST in the rpc, there's no GET, perhaps a link I could read? 12:50 < wumpus> jonasschnelli: yes 12:50 < sipa> jonasschnelli: yes 12:50 < gmaxwell> well we have node rpcs but we also have pure function rpcs. though I don't know how good it is to bother callers with the fine details of how an rpc is implemented. 12:50 < luke-jr> :| 12:50 < jonasschnelli> Okay. That makes it a bit more complex. :) 12:50 < jonasschnelli> And not user friendly. 12:51 < jtimon> oh, the params after ?, right, sorry 12:51 < sipa> jonasschnelli: how so? 12:51 < instagibbs> we should just ban all calls, start fresh :P 12:51 < luke-jr> sipa: can't just change the endpoint for existing software.. 12:51 < jonasschnelli> what about createrawtransaction? 12:51 < sipa> luke-jr: then use the old API, which keeps working 12:51 < luke-jr> sipa: then you can't select the wallet 12:51 < wumpus> jonasschnelli: well... the methods thaat have both wallet and non-wallet functionality are obviously special here 12:51 < jtimon> sipa: most things? all things I believe, even for GET 12:51 < jonasschnelli> switch over to /wallet when you call fundrawtransaction and back to /node when using signrawtransactionwithkey? 12:52 < wumpus> jonasschnelli: they could be on both, I don't care 12:52 < gmaxwell> having them track that "x is a wallet rpc" vs "y is a node" rpc is already asking a lot. and following this there should be something for pure rpcs that interact not with the node state or wallet. and so on. 12:52 < gmaxwell> I guess I'm raising the same concern as jonasschnelli 12:52 < wumpus> gmaxwell: it's a good preparation for beginning to split off the wallet though 12:52 < sipa> i see there is a usability issue in doing so 12:52 < jonasschnelli> Not sure if we can/should already seperate the calls in endpoints 12:52 < wumpus> gmaxwell: when the wallet would be a separate process it also won't have the node methods 12:52 < gmaxwell> Yes, and I think the wallet split is reasonable, I'm cautioning about what happens if you continue the logic. 12:53 < jonasschnelli> Once we have process separation, then we would need it. Yes. 12:53 < wumpus> also it's a bit starnge to have the same non-wallet methods aliased for every wallet 12:53 < jonasschnelli> We could warn in the release notes. 12:53 < wumpus> aliasing is usually a bad idea 12:53 < luke-jr> I suppose if people want backward compatibility, they can just user per-username default wallets, and have multiple users 12:53 < gmaxwell> Maybe there really are only three kinds: Things that talk to the node, things that talk to a wallet (and maybe also a node), and things that are pure functions. 12:54 < wumpus> what makes /v1/wallet/mywallet getnetworkinfo different from /v1/otherwallet netnetworkinfo 12:54 < wumpus> none has anything to do with wallets 12:54 < wumpus> gmaxwell: yes, those three kinds exist 12:54 < jonasschnelli> Yes. Agree that it looks bad. 12:54 < sipa> can you give an example of the middle one? 12:54 < wumpus> gmaxwell: we've been trying to get rid of " things that talk to a wallet (and maybe also a node)" 12:54 < sipa> oh, signrawtransaction needing UTXO access 12:54 < jonasschnelli> hm... wumpus: not sure. The wallet could have it's own network rules in future 12:54 < wumpus> sipa: getinfo 12:55 < sipa> wumpus: i don't care about getinfo :) 12:55 < gmaxwell> it's a little unfortunate to expose the three kinds to users though. decoderawtransaction and createrawtransaction are pure, signrawtransaction is not. 12:55 < wumpus> jonasschnelli: sure, then it could have a *different* getnetworkinfo 12:55 < wumpus> sipa: there are more, I've listed them in some issue, let me see 12:55 < jonasschnelli> I don't think it's wrong to have node calls in /v1/wallet/mywallet .. it allows us to – in theory – have different peering for different wallets. Also chaintips can be different. 12:56 < wumpus> sipa: #7965 12:56 < sipa> i think i'm fine with making v1 support all non-deprecated non-wallet RPCs as well 12:56 < gribble> https://github.com/bitcoin/bitcoin/issues/7965 | Remaining instances of ENABLE_WALLET in `libbitcoin_server.a` · Issue #7965 · bitcoin/bitcoin · GitHub 12:56 < gmaxwell> I think a split on anything other than wallet vs non-wallet basically exposes implementation details to users. 12:56 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #10652: Small step towards demangling cs_main from CNodeState (master...2017-06-cnodestateaccessors-1) https://github.com/bitcoin/bitcoin/pull/10652 12:56 < gmaxwell> jonasschnelli: those don't sound like very interesting things to accomplish. IMO. 12:56 < luke-jr> I think we're adding too much complexity to make 0.15 :< 12:56 < wumpus> "RPC still has some calls that vary depending on wallet support. We should split these up. This is the more annoying part as it will involve API changes. No non-wallet RPC call should make an assumption about "a wallet"." 12:56 < sipa> can we please at least remove getinfo from v1? 12:56 < BlueMatt> YES 12:57 < wumpus> YES 12:57 < gmaxwell> (and by wallet vs non-wallet, I mean a logical split where the address and transaction manipulating functions which are technically pure would still be wallet functions) 12:57 < jonasschnelli> Okay. Should the call split be in the same PR that introduces the endpoint? 12:57 < wumpus> jonasschnelli: not necessarily, small steps are fine 12:57 < sipa> jonasschnelli: i don't care 12:57 < jonasschnelli> I think it may get pretty big. 12:57 < gmaxwell> we shouldn't ship a release with /v1/ though that has a lot of calls we intend to remove, however. 12:57 < jonasschnelli> And ideally the endpoint is in 0.15 (otherwise multiwallet is not really useful) 12:58 < wumpus> at this point it's better to make progress at all 12:58 < luke-jr> let's get rid of BTC amounts while we're at it! :x 12:58 < sipa> gmaxwell: agree 12:58 < wumpus> gmaxwell: if it's in a release it means it needs to be /v2 12:58 < sipa> jonasschnelli: we have time, i think 12:58 < wumpus> gmaxwell: simple as that 12:58 < gmaxwell> luke-jr: I'd like that but switching to integers could be a v2 thing too... 12:58 < wumpus> sigh 12:58 < sipa> wumpus: sure; but i think we can merge endpoints now, and do another PR before 0.15 to remove some of the unnecessary stuff from the wallet endpoints 12:58 < gmaxwell> wumpus: well will we want to continue supporting v1 for a long time in th case? 12:59 < jtimon> I would not apps anything in the uri, just /v1/wallet/ with {"wallet": "mywalley", "otherparam" : "other value"} 12:59 < sipa> jtimon: the downside of that is that doesn't prepare downstream apps well for a future process split 12:59 < jonasschnelli> jtimon: having it in the JSON layer would make process seperation harder... 12:59 < wumpus> (sorry, just tired of the whole 'switching to integers' thing) 12:59 < sipa> wumpus: i think the current solutions which accepts strings everywhere is perfectly fine 13:00 < gmaxwell> wumpus: oh I thought other people wanted to do that, but the inability to change the api was holding it off. 13:00 < sipa> PLOINK 13:00 < jtimon> luke-jr: super ACK on finally moving from BTC to satoshi once and for all, but last time I tried I had to close the PR 13:00 < luke-jr> sipa fell in the ocean? 13:00 < instagibbs> that's dutch for "meeting over" 13:00 < wumpus> gmaxwell: I mean the problem is that JSON doesn't have integers 13:01 < wumpus> #endmeeting 13:01 < lightningbot> Meeting ended Thu Jun 22 20:01:02 2017 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:01 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-22-19.00.html 13:01 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-22-19.00.txt 13:01 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-06-22-19.00.log.html 13:01 < sipa> instagibbs: indeed; clearly at least wumpus got it 13:01 < gmaxwell> wumpus: yea, I thought the suggestion was integers in strings. sorry if I'm desynced there. 13:01 < BlueMatt> sorry cfields, I didnt want to hold off on PRing #10652 anymore....I only started it last dec :p 13:01 < gribble> https://github.com/bitcoin/bitcoin/issues/10652 | Small step towards demangling cs_main from CNodeState by TheBlueMatt · Pull Request #10652 · bitcoin/bitcoin · GitHub 13:01 < luke-jr> JSON has Numbers, which can be integers just fine 13:02 < wumpus> if only we used a *SANE* RPC mechanism that support uint64 values 13:02 < jtimon> I see, the reason to have the wallet id in the uri is for processes, thanks 13:02 < cfields> BlueMatt: np, great to see 13:02 < sipa> wumpus: ASN.1 13:02 < cfields> haha 13:02 < gmaxwell> wumpus: the issue that its trying to address is that some json libraries coerse json numbers to 32-bit floats and other horrors and do corrupt our values. 13:02 < wumpus> we'd haved save hours, no, days of discussion 13:02 < jonasschnelli> cfields: interested if you know why I got again dependencies issues on travis only: https://travis-ci.org/bitcoin/bitcoin/jobs/245674276#L2089 13:02 < gmaxwell> luke-jr: if you're willing to support proper handling of number we don't need to change anything-- current thing is fine. 13:02 < wumpus> gmaxwell: we currently accept strings as BTC amounts 13:02 < gmaxwell> wumpus: yes, but we don't return them. 13:02 < luke-jr> gmaxwell: current thing confuses internals with externals 13:03 < wumpus> ASN.1 hehe 13:03 < jtimon> unrelated: I would add #9271 to project 6 (libconsensus), although I don't manage to fix the tests if I change the enums for the consensus part. Removing that last part doesn't feel right either 13:03 < gribble> https://github.com/bitcoin/bitcoin/issues/9271 | Theres two types of flags: consensus and script by jtimon · Pull Request #9271 · bitcoin/bitcoin · GitHub 13:04 < gmaxwell> I'm sorry for commenting. perhaps it would just be better addressed by offering an RPC that isn't json in the future. 13:04 < cfields> jonasschnelli: will take a look 13:04 < sipa> gmaxwell: XML? 13:04 < jtimon> I gave up on verifyHeader, but not on verifyTx 13:04 < jonasschnelli> cfields: thanks! 13:04 < wumpus> gmaxwell: no, don't be sorry, I'm sorry for reacting so heavily to it, it's just that it's been discussed so many times, and every time it goes the same 13:05 < jtimon> sipa: SOAP :p 13:05 < luke-jr> wumpus: because we never change the API.. 13:05 < wumpus> some people want solution A, some want B, it never changes 13:05 < gmaxwell> My skin crawls a bit about the big footgun json gives our callers here. :( (though seems luke wasn't even concerned about that) 13:05 < cfields> jonasschnelli: btw, I pinged you a few days ago for discussion about the policy change, but I guess I missed you. I suspect it's too late now to pester you about it for a min? 13:05 < wumpus> two? three? years ago I had a PR open that allows, with a command line argument, to change the encoding of amounts to four different things 13:05 < wumpus> both for accepting and returning 13:06 < wumpus> but no, no one was interested 13:06 < wumpus> we rather just keep discussing it 13:06 < gmaxwell> changing the API from a commandline seems unsafe, however. I think it came up here because we're doing api versions. 13:06 < wumpus> yeah yeah... 13:06 < wumpus> never mind 13:07 < gmaxwell> (e.g. you set the commandline one way then run joinmarket that doesn't know about that, and Bad Things Happen (tm) ... though I apologize if your PR actually addressed that.) 13:08 < wumpus> so, we could switch between just btc amount and "btc amount" and drop the integer variants, also fine with me 13:08 * jtimon ended up in https://zeroc.com/products/ice when talking about rpc...remembers he used it for robots to talk to computers with more computing power 13:08 < luke-jr> wumpus: that would just make the problem worse 13:08 < wumpus> no way that's dangerous as it would just result in incompatible values that wouldn't be parsed instead of 10^8 blowup 13:09 < wumpus> oh yeah of course it just makes things worse 13:09 < wumpus> OF COURSE 13:09 < gmaxwell> wumpus: Thats a good point 13:10 < wumpus> jtimon: it's not just bitcoin, no one ever agrees about RPC mechanisms, ever, anywhere :) 13:10 < luke-jr> lol 13:10 < gmaxwell> actually what effective numeric value does "1.0000" have in javascript? (a string with a 1.00 in it) 13:10 < wumpus> that's why hundreds different ones exist 13:11 < wumpus> 1.0000 if you interpret it as number 13:11 < jtimon> wumpus: right, I just remembered with gmaxwell comments what I had used i the past, I hated soap and liked ice 13:11 < gmaxwell> okay, that looks vaguely safe. I was worring for a moment that it would be 0 or something. 13:12 < wumpus> gmaxwell: javascript:alert("1.0000"+0) 13:13 < bitcoin-git> [bitcoin] achow101 closed pull request #10511: [Tests] Include branch coverage info in coverage test (master...lcov) https://github.com/bitcoin/bitcoin/pull/10511 13:13 -!- CubicEarth [~cubiceart@50-1-104-188.dsl.dynamic.fusionbroadband.com] has joined #bitcoin-core-dev 13:13 < gmaxwell> I don't know how anyone can stand programming in this language because "blart"+0 = "blart0" 13:13 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 246 seconds] 13:15 < sipa> gmaxwell: https://www.destroyallsoftware.com/talks/wat 13:15 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 13:15 < wumpus> gmaxwell: I don't know either, it's just madness 13:16 -!- jtimon [~quassel@c-73-189-35-88.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 13:19 < wumpus> but yes, that probably means that changing a number to a string is going to result in funny results instead of errors immediately 13:26 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.] 13:27 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 13:34 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 13:34 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit] 13:59 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds] 14:12 -!- nelsondcg [~nelruk@181.121.114.116] has quit [Quit: Saliendo] 14:34 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 14:56 -!- jtimon [~quassel@c-73-189-35-88.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 14:57 -!- neel [~neel@79.184.220.5.ipv4.supernova.orange.pl] has quit [Remote host closed the connection] 14:57 < sipa> Can I haz some review on https://github.com/bitcoin-core/leveldb/pull/2 ? 15:05 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 15:10 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 15:12 -!- neel [~neel@79.184.220.5.ipv4.supernova.orange.pl] has joined #bitcoin-core-dev 15:18 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 260 seconds] 15:20 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 15:26 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)] 15:27 < luke-jr> sipa: but I thought we all trusted you to do the LevelDB review? :P 15:31 < sipa> luke-jr: not of my own code 15:32 < luke-jr> oh, that's not just the version bump 15:32 < wumpus> no, the version bump was already done 15:32 -!- neel [~neel@79.184.220.5.ipv4.supernova.orange.pl] has quit [Remote host closed the connection] 15:33 < wumpus> this just moves the atomic pointer code 15:34 < sipa> yes, it makes it prefer the c++11 native construct over the adhoc asm code 15:37 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 260 seconds] 15:38 -!- jtimon [~quassel@c-73-189-35-88.hsd1.ca.comcast.net] has quit [Ping timeout: 255 seconds] 15:39 < wumpus> yep 15:41 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...] 15:45 < gmaxwell> sipa: unrelated to us reviewing it, but any feedback from upstream about it? 15:45 < gmaxwell> I certantly feel much more comfortable using C++ atomics. 15:46 < sipa> gmaxwell: it's even code from upstream 15:46 < sipa> i just changed the priority of choosing one over another 15:46 < sipa> not a single comment in the upstream github repo 15:50 < profall> Can two different people mine to different accounts on the same node? 15:52 < wumpus> since when can you mine on people? 15:53 < profall> Sweat shop with people hashing with pen and paper 15:54 < profall> ASIC, Miner, machine do-dad hashing thing. Want me to rephrase the statement? 15:54 < sipa> what do accounts have to do with iy 15:54 < sipa> what have nodes to do with it 15:56 < wumpus> the question just makes no sense, also this is not the place to ask support questions, try #bitcoin 15:56 < profall> If Miner #1 is mining to address ABC and Miner #2 is mining to address XZY. However, they have are using the same bitcoin core daemon. 15:56 < gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub 15:56 < gribble> https://github.com/bitcoin/bitcoin/issues/2 | Long-term, safe, store-of-value · Issue #2 · bitcoin/bitcoin · GitHub 15:56 < profall> Alright, will ask there. 15:57 < sipa> profall: bitcoin core is irrelevant in this question; all core does is provide a block template to mine from 15:58 < sipa> it does not care what you do with that, where you make the payout go, or where you submit the solved block 15:58 < profall> Alright, thank you sipa 16:15 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 16:25 -!- RoyceX [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev 16:27 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds] 16:28 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 240 seconds] 16:33 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 16:41 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 255 seconds] 16:42 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has quit [Ping timeout: 255 seconds] 16:42 -!- spinza [~spin@196.212.164.26] has quit [Ping timeout: 255 seconds] 16:43 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 16:44 -!- midnightmagic [~midnightm@unaffiliated/midnightmagic] has joined #bitcoin-core-dev 16:51 -!- spinza [~spin@196.212.164.26] has joined #bitcoin-core-dev 16:54 < bitcoin-git> [bitcoin] ryanofsky opened pull request #10653: Simple, backwards compatible RPC multiwallet support (master...pr/multiparam) https://github.com/bitcoin/bitcoin/pull/10653 16:55 < achow101> morcos: sdaftuar: what's the best way to get a long term fee rate (e.g. estimatesmartfee for 1008 blocks)? I need this for #10637. 16:55 < gribble> https://github.com/bitcoin/bitcoin/issues/10637 | Coin Selection with Murchs algorithm by achow101 · Pull Request #10637 · bitcoin/bitcoin · GitHub 16:56 < achow101> right now I am doing this abomination: https://0bin.net/paste/aql1DfVmBRbaZ9ks#P+ZTH6yYhbb4X-+YeCrCU/Mmt85cjNpkBvlqFvxxHFZ since it seems that estimatesmartfee() will return a fee rate of 0 if the confirmation target is out of the data range 16:57 < achow101> (getminimumfeerate in that snippet is a function that gets the fee rate with estimatesmartfee and then returns the max of that or the minrelayfee) 16:58 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev 17:01 -!- RoyceX [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds] 17:29 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] 17:46 -!- jtimon [~quassel@73.189.35.88] has joined #bitcoin-core-dev 17:52 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 17:58 -!- abpa [~abpa@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Textual IRC Client: www.textualapp.com] 18:09 < morcos> achow101: i'm not sure estimatesmartfee is really designed for that kind of stable lower bound.. I agree it shoudl be possible to hack something together though 18:10 < morcos> I'm not sure what you mean about it returning a rate of 0 18:10 < achow101> it returns CFeeRate(0) on failure 18:10 < morcos> That shouldn't happen beyond the very first few blocks after you turn on a new node 18:10 < morcos> Why are you getting a failure 18:10 < achow101> confirmation target is 1008 18:10 < achow101> (It seems like it fails) 18:10 < morcos> Because it returns 0? 18:11 < achow101> yes? maybe I'm wrong. 18:11 < morcos> What do you mean yes? Is it returning 0 18:11 < morcos> It should return an estimate for the highest target it can 18:11 < morcos> If for some reason you are getting 0, that is a problem 18:11 < achow101> I'm still writing the code so I don't know 18:12 < morcos> oh 18:12 < morcos> you know there is an rpc call so you can see what estimatesmartfee will give you on a node 18:13 < achow101> right. It gave me -1 18:13 < morcos> ok, that is surprising 18:13 < achow101> ehh, that's actually for a target of 2016, not 1008 18:13 < morcos> how long has it been up? 18:13 < morcos> ok, yeah 2016 is not supported 18:13 < gmaxwell> $ ./bitcoin-cli estimatefee 1008 18:13 < gmaxwell> -1 18:13 < morcos> anything >1008 will always return -1 18:13 < morcos> ARGHHH 18:13 < morcos> i'm going to strangle all of you people 18:14 < sipa> gmaxwell: estimateSMARTfee :) 18:14 < morcos> estimatefee is deprecated 18:14 < achow101> 18:13:36 18:14 < achow101>  18:14 < achow101> estimatesmartfee 1009 18:14 < achow101> 18:13:36 18:14 < achow101>  18:14 < achow101> { 18:14 < achow101> "feerate": -1, 18:14 < achow101> "blocks": 1009 18:14 < achow101> } 18:14 < achow101> -1 for anything greater than 1008. is that supposed to happen? 18:14 < morcos> yes 18:14 < morcos> that is supposed to happen 18:15 < gmaxwell> estimatesmartfee gave me -1 too but I was calling it with 2016 because some reason I thought that was the maximum. 18:15 < achow101> why doesn't it just use the highest available like it does for 1008? 18:15 < morcos> achow101: because it is telling you that you are using it wrong 18:15 < achow101> oh 18:15 < morcos> it will never be able to give you an answer for 1009 or 2016 18:16 < morcos> but for 1008 you are using it correctly, so it gives you the best answer it can and tells you what target that answer was for 18:16 < morcos> the design is so that if you do estimatesmartfee N for 1 <= N <= 1008 it should very very rarely give you a -1. 18:17 < morcos> This will happen only if you have a brand new node you just started up, or if your node has been down for > 6 weeks 18:17 < achow101> ok 18:17 < morcos> And then it'll only last for a couple of blocks after your node is fully synced 18:17 < morcos> For your purposes I would recommend that you ask estimatesmartfee 1008 18:18 < gmaxwell> achow101: so your issue is just that you weren't using estimator.estimateSmartFee ? 18:18 < achow101> I went off your word and used 2016 originally :p 18:18 < morcos> Look at the blocks it returns, and if it returns blocks < 144 for example, then perhaps you want to take the min with the fallback fee or something 18:18 < gmaxwell> morcos: for clarity, he's changing CreateTransaction code in wallet.cpp not using the RPC. :) 18:18 < gmaxwell> achow101: oh see, don't listen to me. 18:18 < morcos> yeah makes sense, but the answer should be the same as the RPC gives you 18:19 < achow101> ok 18:19 < morcos> i'd also see if you get use the GetMinimumFee function (if thats what its called) which will do smart things like max with the mempool min fee 18:19 < gmaxwell> morcos: looks like he was doing the right thing but I'd quipped call it with 2016 blocks or something. Which he did, which then resulted in "wtf is it using CFeeRate(0) as its return value for error cases" then also saw that estimatefee -1ing on 1008 and sooo. 18:20 < morcos> one thing that might be missing is documentation of the 1008 upper bound 18:20 < morcos> is that in the rpc help? 18:20 < achow101> morcos: nope 18:20 < morcos> yeah that should get added 18:21 < gmaxwell> why doesn't estimatesmartfee 2016 just reutrn the 1008 result (it gives blocks in the result, so if its telling you a lower number, you know) 18:21 < achow101> I was looking at the code for estimatesmartfee too, but not a lot of comments there either :( 18:21 < gmaxwell> fortunately dumb code that just uses the answer w/ a negative feerate will only manage to produce an invalid txn. :) 18:22 < morcos> gmaxwell: well i mean the real answer is this all just built on prior version which always returned -1 if you put something outside the allowable range 18:22 < gmaxwell> doesn't sound very smart. 18:22 < gmaxwell> :P 18:22 < gmaxwell> morcos: than you for the cluestick. 18:23 < morcos> but i do think it is somewhat reasonable for it to indicate to you that you used an argument outside the supported range 18:23 < morcos> also see this: https://github.com/bitcoin/bitcoin/issues/10625 18:24 < morcos> I want to implement this for fee esitmation. But sounds like it would also be good for what you are doing 18:24 < morcos> I guess you'll get it automatically if its just inside of estimatesmartfee 18:26 < morcos> oops slight typo fixed in that issue 18:26 < gmaxwell> well two issues: I think that you should get a best effort answer if you give too big a value-- indicating with blocks would be fine, but also if we can't give an answer we should omit the field, not use -1. 18:27 < gmaxwell> (mentioning it for the future, not blaming anyone (esp not here)-- often magic values for errors results in failures) 18:28 < morcos> Yes I agree 18:28 < morcos> But does that mean we should change it? 18:28 < gmaxwell> I dunno. We could create an estimatesmarterfee with the new interface. 18:28 < morcos> I suppose I should have changed it when I made estimatesmartfee since that was a new AO 18:28 * gmaxwell ducks 18:28 < morcos> API all together 18:29 < gmaxwell> yea, sorry I didn't catch that then. 18:29 < sipa> gmaxwell: saneestimatesmartfee 18:29 < sipa> :p 18:30 < gmaxwell> footgunlessfees (perhaps an overstatement) 18:36 < gmaxwell> It doesn't help that C/C++/and friends don't have option types like rust and haskell, so overloaded error-return types are in people's blood. 18:37 < gmaxwell> Pieter pointed out earlier that C++17 has one, but without looking I'm kind of dubious about its utility because the rest of the language (and libraries) weren't built around it being there. 18:38 < sipa> well, C++17 does not technically exist, but it is with near certain probability expected that it will have it :) 18:46 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 268 seconds] 18:48 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 18:48 -!- jtimon [~quassel@73.189.35.88] has quit [Remote host closed the connection] 19:16 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 19:21 -!- ProfMac_ [43c671dc@gateway/web/freenode/ip.67.198.113.220] has joined #bitcoin-core-dev 19:23 < instagibbs> gmaxwell, so thinking ahead, if we replace IsDust change checks with something more reasonable, is there any reason to try again rather than simply prune/keep the change and exit? 19:26 < instagibbs> I feel like I'm writing extra logic here just to protect our ridiculous IsDust logic :) 19:26 < gmaxwell> Are you asking if there is any reason to loo kat all? 19:27 < gmaxwell> gah, loop at all. 19:27 < sipa> what is looing? 19:27 < sipa> ah 19:31 < instagibbs> correct 19:33 < instagibbs> specifically looping for change, not for fee(different issue we can tackle later) 19:34 < gmaxwell> obviously for fee that is unaviodable without effective rates. 19:34 < gmaxwell> Gonna have to explain what behavior you think we're protecting on the change part. 19:34 * gmaxwell brings up the code now 19:35 < instagibbs> Ok so right now it's 1) < IsDust, dump 2) < MIN_FINAL_CHANGE : loop 3) < MIN_F_C keep 19:35 * instagibbs heading off for now 19:36 < gmaxwell> right if we get a viabile solution and the change is under dust, turn the dust to fee and call it done. 19:37 < gmaxwell> otherwise, if its under min_final_change loop with a bigger target to try to get enough coins to meet that criteria. 19:37 < gmaxwell> otherwise we're done. 19:37 < gmaxwell> and you're asking if that dust were smarter could we skip test 2? 19:37 < instagibbs> yes 19:38 < gmaxwell> I _think_ that even if dust is smart, there is s range of sizes where we would rather take the change than discard to fees, but would prefer our outputs be larger than that. 19:39 < morcos> I think thats the tricky part of the logic 19:39 < gmaxwell> Basically at the sane dust level the output is worth nothing. So obviously better to not create it. But above that it's worth something, but we'd still rather not have a bunch of almost nothing outputs in our wallet. 19:39 < morcos> It depends on both the set of outputs you have (available and are currently using) and the fee rate you are using on this tx as opposed to what you might use on future txs 19:40 < gmaxwell> certantly if you think fees now are lower than average you should be especially eager to aggregate. 19:40 < morcos> I had written up a heuristic previously that did different things depending on what your tx confirm target is 19:41 < morcos> yeah so how "smart" you want to get about this in an automated fashion is tricky 19:41 -!- kexkey [~kexkey@68.168.119.229] has joined #bitcoin-core-dev 19:44 < instagibbs> hm yes the "utxo management" aspect, ok ill keep it around for Future Work 19:53 -!- Guest97515 [~justin@47.148.176.74] has quit [Remote host closed the connection] 19:53 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 19:53 -!- Guest97515 [~justin@47.148.176.74] has joined #bitcoin-core-dev 19:56 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 276 seconds] 19:58 < instagibbs> So in essence we have aspirational utxo amounts/types that the wallet can strive for, and values that are considered worthless 19:59 < instagibbs> former we have no real mechanism in place so min change is what we're using 20:01 -!- wolfspra1l [~wolfsprau@bobbin.q-ag.de] has quit [Quit: leaving] 20:01 -!- wolfspraul [~wolfsprau@bobbin.q-ag.de] has joined #bitcoin-core-dev 20:01 -!- wolfspraul [~wolfsprau@bobbin.q-ag.de] has quit [Client Quit] 20:04 < phantomcircuit> i still think that have a score for a set of utxo's and then just randomly selecting utxo's to try is a reasonable approach 20:05 < bitcoin-git> [bitcoin] RHavar opened pull request #10655: Properly document target_confirmations in listsinceblock (master...listsinceblock) https://github.com/bitcoin/bitcoin/pull/10655 20:15 -!- wolfspraul [~wolfsprau@bobbin.q-ag.de] has joined #bitcoin-core-dev 20:29 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds] 20:33 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 20:46 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 21:13 -!- ula [~kvirc@b2b-78-94-9-226.unitymedia.biz] has quit [Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/] 21:19 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev 21:48 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Remote host closed the connection] 21:49 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has joined #bitcoin-core-dev 21:53 -!- jamesob [~jamesob@c-73-241-180-136.hsd1.ca.comcast.net] has quit [Ping timeout: 240 seconds] 22:31 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 22:37 -!- Lauda [~quassel@unaffiliated/lauda] has quit [Remote host closed the connection] 22:38 -!- Lauda [~quassel@unaffiliated/lauda] has joined #bitcoin-core-dev 22:56 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 255 seconds] 22:57 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev 23:12 -!- bordeaux_facile [~a@128.199.208.178] has quit [Read error: Connection reset by peer] 23:28 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.] 23:28 -!- bordeaux_facile [~a@128.199.208.178] has joined #bitcoin-core-dev 23:32 -!- bordeaux_facile [~a@128.199.208.178] has quit [Client Quit] 23:33 -!- bordeaux_facile [~a@128.199.208.178] has joined #bitcoin-core-dev 23:37 -!- bordeaux_facile [~a@128.199.208.178] has quit [Client Quit] 23:43 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev 23:43 < bitcoin-git> [bitcoin] str4d opened pull request #10657: Utils: Improvements to ECDSA key-handling code (master...libsecp256k1-patches) https://github.com/bitcoin/bitcoin/pull/10657 23:47 -!- bordeaux_facile [~a@128.199.208.178] has joined #bitcoin-core-dev 23:57 -!- bordeaux_facile [~a@128.199.208.178] has quit [Quit: ZNC 1.6.3+deb2 - http://znc.in]