12021-06-04T00:16:14 *** lightlike <lightlike!~lightlike@user/lightlike> has quit IRC (Quit: Leaving)
22021-06-04T00:18:28 <hebasto> something strange with github right now -- cannot checkout the latest `v0.20.2rc2` tag
32021-06-04T00:18:47 <sipa> git fetch -t upstream ?
42021-06-04T00:19:38 <hebasto> ah, `-t`-- yes, thank you
52021-06-04T00:20:02 <hebasto> should go sleep, certainly
62021-06-04T00:22:20 <hebasto> sipa: but usually `fetch` fetched tags without `-t`...
72021-06-04T00:27:13 <achow101> I ran into that problem too. usually fetch fetches tags but for some reason it didn't today
82021-06-04T00:27:53 <hebasto> is this tag a lightweight one?
92021-06-04T00:29:58 <hebasto> oh, I found out -- https://github.com/bitcoin/bitcoin/commit/5d2ebdd2b71fadfcbadc32d074c83e1ff92043b5 does not belong to the 0.20 branch
102021-06-04T00:30:33 <achow101> ah, so laanwj forgot to push the branch itself
112021-06-04T00:42:07 *** evias <evias!~evias__@user/evias> has quit IRC (Quit: This computer has gone to sleep)
122021-06-04T01:04:30 *** jarthur <jarthur!~jarthur@2603-8080-1540-002d-7c3e-5f85-a09f-91e1.res6.spectrum.com> has quit IRC (Quit: jarthur)
132021-06-04T01:17:36 *** SenX <SenX!~textual@2600:1700:42f0:f60:c0f4:898b:4a73:14b1> has joined #bitcoin-core-dev
142021-06-04T03:29:51 *** SenX <SenX!~textual@2600:1700:42f0:f60:c0f4:898b:4a73:14b1> has quit IRC (Quit: My iMac has gone to sleep. ZZZzzzâ¦)
152021-06-04T03:30:18 *** ksprd3 <ksprd3!~ksprd@public-gprs385937.centertel.pl> has quit IRC (Ping timeout: 264 seconds)
162021-06-04T03:38:08 <jarolrod> has boost been taking a long time to download using depends recently or is it just me
172021-06-04T03:56:27 *** ksprd3 <ksprd3!~ksprd@public-gprs385937.centertel.pl> has joined #bitcoin-core-dev
182021-06-04T04:33:16 *** belcher_ <belcher_!~belcher@user/belcher> has joined #bitcoin-core-dev
192021-06-04T04:36:11 *** belcher <belcher!~belcher@user/belcher> has quit IRC (Ping timeout: 245 seconds)
202021-06-04T05:00:02 *** ksprd3 <ksprd3!~ksprd@public-gprs385937.centertel.pl> has quit IRC (Ping timeout: 272 seconds)
212021-06-04T05:14:14 *** ksprd3 <ksprd3!~ksprd@public-gprs385937.centertel.pl> has joined #bitcoin-core-dev
222021-06-04T05:19:31 *** ksprd3 <ksprd3!~ksprd@public-gprs385937.centertel.pl> has quit IRC (Ping timeout: 245 seconds)
232021-06-04T05:22:04 *** vnogueira <vnogueira!~vnogueira@user/vnogueira> has quit IRC (Ping timeout: 252 seconds)
242021-06-04T05:26:13 <martinus> ankerl
252021-06-04T05:26:38 *** martinus <martinus!~martinus@046125249061.public.t-mobile.at> has quit IRC (Quit: Leaving)
262021-06-04T05:29:28 *** vnogueira <vnogueira!~vnogueira@user/vnogueira> has joined #bitcoin-core-dev
272021-06-04T05:33:27 *** ksprd3 <ksprd3!~ksprd@public-gprs385937.centertel.pl> has joined #bitcoin-core-dev
282021-06-04T05:36:56 *** smartin <smartin!~Icedove@88.135.18.171> has joined #bitcoin-core-dev
292021-06-04T05:39:50 *** ksprd3 <ksprd3!~ksprd@public-gprs385937.centertel.pl> has quit IRC (Ping timeout: 265 seconds)
302021-06-04T05:40:39 *** vnogueira <vnogueira!~vnogueira@user/vnogueira> has quit IRC (Remote host closed the connection)
312021-06-04T05:42:35 *** goatpig <goatpig!~goat@blocksettle-gw.cust.31173.se> has joined #bitcoin-core-dev
322021-06-04T05:52:56 *** ksprd3 <ksprd3!~ksprd@public-gprs385937.centertel.pl> has joined #bitcoin-core-dev
332021-06-04T05:58:56 *** ksprd3 <ksprd3!~ksprd@public-gprs385937.centertel.pl> has quit IRC (Ping timeout: 272 seconds)
342021-06-04T06:08:41 *** davterra <davterra!~davterra@178.128.106.205> has quit IRC (Ping timeout: 245 seconds)
352021-06-04T06:15:18 *** ksprd3 <ksprd3!~ksprd@public-gprs385937.centertel.pl> has joined #bitcoin-core-dev
362021-06-04T06:16:10 *** vnogueira <vnogueira!~vnogueira@user/vnogueira> has joined #bitcoin-core-dev
372021-06-04T06:19:31 *** ksprd3 <ksprd3!~ksprd@public-gprs385937.centertel.pl> has quit IRC (Ping timeout: 245 seconds)
382021-06-04T06:26:14 *** Guest32 <Guest32!~Guest32@cpc157823-brnt5-2-0-cust196.4-2.cable.virginm.net> has joined #bitcoin-core-dev
392021-06-04T06:26:43 *** Guest32 <Guest32!~Guest32@cpc157823-brnt5-2-0-cust196.4-2.cable.virginm.net> has left #bitcoin-core-dev
402021-06-04T06:31:58 *** ksprd3 <ksprd3!~ksprd@public-gprs385937.centertel.pl> has joined #bitcoin-core-dev
412021-06-04T06:37:01 *** ksprd3 <ksprd3!~ksprd@public-gprs385937.centertel.pl> has quit IRC (Ping timeout: 245 seconds)
422021-06-04T06:51:57 *** ksprd3 <ksprd3!~ksprd@public-gprs385937.centertel.pl> has joined #bitcoin-core-dev
432021-06-04T06:56:42 *** ksprd3 <ksprd3!~ksprd@public-gprs385937.centertel.pl> has quit IRC (Ping timeout: 264 seconds)
442021-06-04T06:59:17 *** Kiminuo <Kiminuo!~Kiminuo@141.98.103.92> has joined #bitcoin-core-dev
452021-06-04T07:10:30 *** Kiminuo <Kiminuo!~Kiminuo@141.98.103.92> has quit IRC (Ping timeout: 264 seconds)
462021-06-04T07:30:54 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
472021-06-04T07:30:54 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #22146: Reject invalid coin height and output index when loading assumeutxo (master...2106-auHeight) https://github.com/bitcoin/bitcoin/pull/22146
482021-06-04T07:30:55 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
492021-06-04T07:41:29 *** evias <evias!~evias__@196.red-88-6-131.staticip.rima-tde.net> has joined #bitcoin-core-dev
502021-06-04T07:48:14 *** lkqwejhhgasdjhgn <lkqwejhhgasdjhgn!~kljkljklk@p200300d46f03bc00ce1eb7ce7a269f20.dip0.t-ipconnect.de> has joined #bitcoin-core-dev
512021-06-04T07:52:20 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
522021-06-04T07:52:20 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c7dd9ff71b9c...a748782a11f0
532021-06-04T07:52:20 <bitcoin-git> bitcoin/master 3d552b0 Sjors Provoost: [doc] explain why CheckBlock() is called before AcceptBlock()
542021-06-04T07:52:20 <bitcoin-git> bitcoin/master a748782 MarcoFalke: Merge bitcoin/bitcoin#15545: [doc] explain why CheckBlock() is called befo...
552021-06-04T07:52:22 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
562021-06-04T07:52:37 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
572021-06-04T07:52:37 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #15545: [doc] explain why CheckBlock() is called before AcceptBlock (master...2019/03/clarify-checkblock) https://github.com/bitcoin/bitcoin/pull/15545
582021-06-04T07:52:38 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
592021-06-04T07:57:14 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
602021-06-04T08:04:53 <vasild> michaelfolkson: for me the meetings' time of the day is a showstopper
612021-06-04T08:06:02 <michaelfolkson> vasild: Without doxing your specific location are you Asia Pacific timezone?
622021-06-04T08:06:37 <vasild> michaelfolkson: I am in Central Europe (GMT+2)
632021-06-04T08:07:29 <michaelfolkson> Oh ok, just other commitments in evenings? I am GMT+1 and timings are fine for me
642021-06-04T08:07:52 <vasild> family time, dinner, sleep early :)
652021-06-04T08:08:08 <michaelfolkson> Fair enough :)
662021-06-04T08:08:18 <michaelfolkson> I feel bad for Asia Pacific people, often in the middle of the night for them
672021-06-04T08:08:32 <vasild> yeah, that's even worse
682021-06-04T08:11:54 <vasild> jnewbery: wrt running the fuzzer in CI, I did not follow the discussion closely, was something decided about it? It occurred to me that it makes sense to run the fuzzer on CI on every pull request using the pre-generated seeds if that increases the code coverage. E.g. if without the fuzzer a CI run gets 80% coverage of a pull and if with the fuzzer that gets to e.g. 85% then it makes sense to run
692021-06-04T08:12:00 <vasild> it on every pull
702021-06-04T08:13:26 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
712021-06-04T08:13:26 <bitcoin-git> [bitcoin] MarcoFalke pushed 1 commit to 0.20: https://github.com/bitcoin/bitcoin/compare/8b5c83b4aa8c...5d2ebdd2b71f
722021-06-04T08:13:26 <bitcoin-git> bitcoin/0.20 5d2ebdd W. J. van der Laan: build: Bump version to 0.20.2rc2
732021-06-04T08:13:28 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
742021-06-04T08:13:46 <MarcoFalke> laanwj: sipa: hebasto: Fixed by typing "git push bitcoin-core 5d2ebdd2b71fadfcbadc32d074c83e1ff92043b5:0.20"
752021-06-04T08:14:23 <MarcoFalke> At least that fixed it for me: " * [new tag] v0.20.2rc2 -> v0.20.2rc2"
762021-06-04T08:15:26 <MarcoFalke> vasild: I'd be a hard NACK removing the fuzz tests. Might as well remove all other tests
772021-06-04T08:16:21 <vasild> I agree, but this was discussed in a meeting recently, IIRC due to some sporadic timeouts
782021-06-04T08:16:40 <_aj_> MarcoFalke: once #21496 is done, could run against the existing fuzz corpus without actually compiling for fuzzing -- could see that being worth a try
792021-06-04T08:16:42 <gribble> https://github.com/bitcoin/bitcoin/issues/21496 | fuzz: execute each file in dir without fuzz engine by AnthonyRonning · Pull Request #21496 · bitcoin/bitcoin · GitHub
802021-06-04T08:18:01 <vasild> some problems in my pulls were discovered only by the fuzz+some-sanitizer CI
812021-06-04T08:59:04 <laanwj> MarcoFalke: thanks for fixing it, i was wondering what went wrong
822021-06-04T09:09:56 <michaelfolkson> vasild: I saw you added to P2P current priorities "Add some basic docs/howto at doc/i2p.md, similarly to doc/tor.md"
832021-06-04T09:10:44 <michaelfolkson> vasild: Feel free to use any of this SE post https://bitcoin.stackexchange.com/questions/103402/how-can-i-use-bitcoin-core-with-the-anonymous-network-protocol-i2p
842021-06-04T09:11:18 <michaelfolkson> vasild: I quite like the idea of using StackExchange as a staging ground or place for drafts before they are ready to add to Core docs :)
852021-06-04T09:11:32 <jonatack> michaelfolkson: there is a wide range of area within the CET timezone (maybe other timezones too but CET I know well), e.g. sun setting and rising much "earlier" in the eastern parts
862021-06-04T09:11:43 <vasild> michaelfolkson: thanks for the link, I should do that before 22.0 release
872021-06-04T09:18:22 *** Conor <Conor!uid501933@id-501933.charlton.irccloud.com> has quit IRC (Quit: Connection closed for inactivity)
882021-06-04T11:15:25 *** tutwidi[m] <tutwidi[m]!~tutwidima@2001:470:69fc:105::ead> has joined #bitcoin-core-dev
892021-06-04T11:29:50 *** thedragon <thedragon!~thedragon@user/thedragon> has joined #bitcoin-core-dev
902021-06-04T11:36:08 *** thedragon <thedragon!~thedragon@user/thedragon> has quit IRC (Quit: Leaving)
912021-06-04T11:54:52 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 272 seconds)
922021-06-04T11:56:05 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
932021-06-04T11:56:05 <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a748782a11f0...3ac5209662ce
942021-06-04T11:56:05 <bitcoin-git> bitcoin/master e4356f6 Daniel Kraft: Testcase for wallet issue with orphaned rewards.
952021-06-04T11:56:05 <bitcoin-git> bitcoin/master 3ac5209 MarcoFalke: Merge bitcoin/bitcoin#18795: Test: wallet issue with orphaned rewards
962021-06-04T11:56:07 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
972021-06-04T11:56:22 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
982021-06-04T11:56:22 <bitcoin-git> [bitcoin] MarcoFalke merged pull request #18795: Test: wallet issue with orphaned rewards (master...orphanedreward-test) https://github.com/bitcoin/bitcoin/pull/18795
992021-06-04T11:56:23 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1002021-06-04T11:56:44 *** ksprd3 <ksprd3!~ksprd@212.14.60.132> has joined #bitcoin-core-dev
1012021-06-04T12:04:18 *** thedragon <thedragon!~thedragon@user/thedragon> has joined #bitcoin-core-dev
1022021-06-04T12:08:09 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
1032021-06-04T12:32:54 <jnewbery> MarcoFalke: saying "we might as well remove all other tests" is not helpful. The point is that we've loaded so many additional tasks onto the CI that it gives frequent false failures.
1042021-06-04T12:33:48 <jnewbery> If developers first thought when seeing a failing CI is "it's probably a spurious failure, I'll hit re-run", then it's worse than useless.
1052021-06-04T12:34:45 <jnewbery> and the approach of "let's just spend money and throw more CPU at the problem" isn't a good solution
1062021-06-04T12:34:51 <hebasto> it appears that `lupdate` can produce XLIFF file directly; the drawback is that `-locations relative` does not work in this case
1072021-06-04T12:35:16 <hebasto> laanwj: luke-jr: ^
1082021-06-04T12:38:30 *** goatpig <goatpig!~goat@blocksettle-gw.cust.31173.se> has quit IRC (Quit: Konversation terminated!)
1092021-06-04T12:40:05 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1102021-06-04T12:40:05 <bitcoin-git> [bitcoin] sdaftuar opened pull request #22147: p2p: Protect last outbound HB compact block peer (master...2021-06-reserve-outbound-hb) https://github.com/bitcoin/bitcoin/pull/22147
1112021-06-04T12:40:06 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1122021-06-04T12:43:00 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1132021-06-04T12:43:00 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3ac5209662ce...346e52afd6d5
1142021-06-04T12:43:00 <bitcoin-git> bitcoin/master fa4245d MarcoFalke: doc: Various validation doc fixups
1152021-06-04T12:43:00 <bitcoin-git> bitcoin/master 346e52a fanquake: Merge bitcoin/bitcoin#22121: doc: Various validation doc fixups
1162021-06-04T12:43:02 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1172021-06-04T12:43:17 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1182021-06-04T12:43:17 <bitcoin-git> [bitcoin] fanquake merged pull request #22121: doc: Various validation doc fixups (master...2106-docVal) https://github.com/bitcoin/bitcoin/pull/22121
1192021-06-04T12:43:18 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1202021-06-04T12:49:20 *** sagi <sagi!~sagi@bzq-79-178-136-188.red.bezeqint.net> has quit IRC (Ping timeout: 272 seconds)
1212021-06-04T13:02:05 *** kabaum <kabaum!~kabaum@h-46-59-13-35.A163.priv.bahnhof.se> has quit IRC (Ping timeout: 265 seconds)
1222021-06-04T13:06:42 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1232021-06-04T13:06:43 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #22149: test: Add temporary logging to debug #20975 (master...2106-testDebug) https://github.com/bitcoin/bitcoin/pull/22149
1242021-06-04T13:06:43 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1252021-06-04T13:07:21 *** bomb-on <bomb-on!~bomb-on@194.144.47.113> has joined #bitcoin-core-dev
1262021-06-04T13:20:53 <MarcoFalke> jnewbery: Sure but then the first attempt should be to fix the spurious failure, not to remove the whole test config
1272021-06-04T13:22:15 <MarcoFalke> Without any way to run the fuzz tests in CI, they will quickly become stale
1282021-06-04T13:23:21 <MarcoFalke> We've already moved the fuzz memory sanitizers out of the ci config. The memory issues are rare enough that they can be fixed up after a merge
1292021-06-04T13:24:04 <MarcoFalke> Though the other issues (logic bugs in the fuzz code, other sanitizer issues, ...) are far more frequent and need to be dealt with in the pull that introduces the issue
1302021-06-04T13:26:04 *** jonatack <jonatack!jonatack@user/jonatack> has quit IRC (Ping timeout: 272 seconds)
1312021-06-04T13:27:54 <MarcoFalke> If there is a specific fuzz test that is slow and not too helpful, we could remove that one
1322021-06-04T13:29:44 <MarcoFalke> Also, we have plenty of intermittent failures in the functional test suite, which are waiting to be fixed
1332021-06-04T13:37:08 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1342021-06-04T13:37:08 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #22150: test: Remove unused node from feature_nulldummy (master...2106-testFaster) https://github.com/bitcoin/bitcoin/pull/22150
1352021-06-04T13:37:09 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1362021-06-04T13:42:17 *** sagi <sagi!~sagi@bzq-79-178-136-188.red.bezeqint.net> has joined #bitcoin-core-dev
1372021-06-04T13:47:01 *** ksprd3 <ksprd3!~ksprd@212.14.60.132> has quit IRC (Ping timeout: 245 seconds)
1382021-06-04T14:06:36 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Remote host closed the connection)
1392021-06-04T14:06:50 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
1402021-06-04T14:13:33 *** ksprd3 <ksprd3!~ksprd@212.14.60.132> has joined #bitcoin-core-dev
1412021-06-04T14:44:35 *** davterra <davterra!~davterra@178.128.106.205> has joined #bitcoin-core-dev
1422021-06-04T14:49:49 *** TheCharlatan <TheCharlatan!~drgrid@2a01:4f9:4a:2adc::2> has joined #bitcoin-core-dev
1432021-06-04T14:58:17 *** ksprd3 <ksprd3!~ksprd@212.14.60.132> has quit IRC (Quit: WeeChat 3.1)
1442021-06-04T14:59:38 *** lightlike <lightlike!~lightlike@user/lightlike> has joined #bitcoin-core-dev
1452021-06-04T15:36:05 *** jarthur <jarthur!~jarthur@2603-8080-1540-002d-c1fc-d572-2f65-fc99.res6.spectrum.com> has joined #bitcoin-core-dev
1462021-06-04T15:39:18 *** copumpkin <copumpkin!~woohoo@user/copumpkin> has quit IRC (Quit: My MacBook has gone to sleep. ZZZzzzâ¦)
1472021-06-04T15:39:55 *** copumpkin <copumpkin!~woohoo@user/copumpkin> has joined #bitcoin-core-dev
1482021-06-04T15:40:05 *** copumpkin <copumpkin!~woohoo@user/copumpkin> has quit IRC (Client Quit)
1492021-06-04T15:40:40 *** copumpkin <copumpkin!~woohoo@user/copumpkin> has joined #bitcoin-core-dev
1502021-06-04T15:40:52 *** copumpkin <copumpkin!~woohoo@user/copumpkin> has quit IRC (Client Quit)
1512021-06-04T15:41:24 *** copumpkin <copumpkin!~woohoo@user/copumpkin> has joined #bitcoin-core-dev
1522021-06-04T15:41:40 *** copumpkin <copumpkin!~woohoo@user/copumpkin> has quit IRC (Client Quit)
1532021-06-04T15:42:19 *** copumpkin <copumpkin!~woohoo@user/copumpkin> has joined #bitcoin-core-dev
1542021-06-04T15:42:28 *** copumpkin <copumpkin!~woohoo@user/copumpkin> has quit IRC (Client Quit)
1552021-06-04T15:43:06 *** copumpkin <copumpkin!~woohoo@user/copumpkin> has joined #bitcoin-core-dev
1562021-06-04T15:43:16 *** copumpkin <copumpkin!~woohoo@user/copumpkin> has quit IRC (Client Quit)
1572021-06-04T15:43:54 *** copumpkin <copumpkin!~woohoo@user/copumpkin> has joined #bitcoin-core-dev
1582021-06-04T15:44:03 *** copumpkin <copumpkin!~woohoo@user/copumpkin> has quit IRC (Client Quit)
1592021-06-04T15:44:35 *** copumpkin <copumpkin!~woohoo@user/copumpkin> has joined #bitcoin-core-dev
1602021-06-04T15:44:51 *** copumpkin <copumpkin!~woohoo@user/copumpkin> has quit IRC (Client Quit)
1612021-06-04T15:45:57 *** lkqwejhhgasdjhgn <lkqwejhhgasdjhgn!~kljkljklk@p200300d46f03bc00ce1eb7ce7a269f20.dip0.t-ipconnect.de> has quit IRC (Quit: Konversation terminated!)
1622021-06-04T16:18:45 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
1632021-06-04T16:18:45 <bitcoin-git> [bitcoin] hebasto opened pull request #22151: build: Follow Transifex docs to prepare XLIFF source (master...210604-xliff) https://github.com/bitcoin/bitcoin/pull/22151
1642021-06-04T16:18:47 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
1652021-06-04T16:36:53 *** prusnak[m] <prusnak[m]!~stickmatr@2001:470:69fc:105::98c> has quit IRC (Quit: node-irc says goodbye)
1662021-06-04T16:36:53 *** orionwl[m] <orionwl[m]!~orionwlx0@2001:470:69fc:105::80> has quit IRC (Quit: node-irc says goodbye)
1672021-06-04T16:36:53 *** vincenzopalazzo <vincenzopalazzo!~vincenzop@2001:470:69fc:105::a67> has quit IRC (Quit: node-irc says goodbye)
1682021-06-04T16:36:53 *** kvaciral[m] <kvaciral[m]!~kvaciralx@2001:470:69fc:105::17b> has quit IRC (Quit: node-irc says goodbye)
1692021-06-04T16:36:53 *** dongcarl[m] <dongcarl[m]!~dongcarlm@2001:470:69fc:105::82> has quit IRC (Quit: node-irc says goodbye)
1702021-06-04T16:36:53 *** mrjumper[m] <mrjumper[m]!~mr-jumper@2001:470:69fc:105::7f1> has quit IRC (Quit: node-irc says goodbye)
1712021-06-04T16:36:54 *** devrandom <devrandom!~devrandom@2001:470:69fc:105::d4d> has quit IRC (Quit: node-irc says goodbye)
1722021-06-04T16:36:55 *** tutwidi[m] <tutwidi[m]!~tutwidima@2001:470:69fc:105::ead> has quit IRC (Quit: node-irc says goodbye)
1732021-06-04T16:37:51 *** orionwl[m] <orionwl[m]!~orionwlx0@2001:470:69fc:105::80> has joined #bitcoin-core-dev
1742021-06-04T16:40:14 *** vincenzopalazzo <vincenzopalazzo!~vincenzop@2001:470:69fc:105::a67> has joined #bitcoin-core-dev
1752021-06-04T16:40:14 *** devrandom <devrandom!~devrandom@2001:470:69fc:105::d4d> has joined #bitcoin-core-dev
1762021-06-04T16:40:14 *** mrjumper[m] <mrjumper[m]!~mr-jumper@2001:470:69fc:105::7f1> has joined #bitcoin-core-dev
1772021-06-04T16:40:14 *** prusnak[m] <prusnak[m]!~stickmatr@2001:470:69fc:105::98c> has joined #bitcoin-core-dev
1782021-06-04T16:40:26 *** dongcarl[m] <dongcarl[m]!~dongcarlm@2001:470:69fc:105::82> has joined #bitcoin-core-dev
1792021-06-04T16:40:27 *** kvaciral[m] <kvaciral[m]!~kvaciralx@2001:470:69fc:105::17b> has joined #bitcoin-core-dev
1802021-06-04T16:40:27 *** tutwidi[m] <tutwidi[m]!~tutwidima@2001:470:69fc:105::ead> has joined #bitcoin-core-dev
1812021-06-04T16:46:59 *** lukedashjr <lukedashjr!~luke-jr@user/luke-jr> has joined #bitcoin-core-dev
1822021-06-04T16:47:30 <ryanofsky> A compromise short of disabling unreliable tests, could be adding a way to mark them flaky. Flaky tests would still run but just collect debug info and not cause the CI to fail
1832021-06-04T16:47:40 <ryanofsky> This would also let us track which tests are unreliable over time
1842021-06-04T16:49:50 *** devrandom <devrandom!~devrandom@2001:470:69fc:105::d4d> has quit IRC (Quit: node-irc says goodbye)
1852021-06-04T16:50:06 *** devrandom <devrandom!~devrandom@2001:470:69fc:105::d4d> has joined #bitcoin-core-dev
1862021-06-04T16:50:13 *** luke-jr <luke-jr!~luke-jr@user/luke-jr> has quit IRC (Ping timeout: 265 seconds)
1872021-06-04T16:50:15 *** lukedashjr is now known as luke-jr
1882021-06-04T16:50:28 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 244 seconds)
1892021-06-04T16:51:06 <luke-jr> hebasto: can we postprocess to remove the locations entirely? (do they serve a purpose?)
1902021-06-04T16:52:35 *** luke-jr <luke-jr!~luke-jr@user/luke-jr> has quit IRC (Quit: ZNC - http://znc.sourceforge.net)
1912021-06-04T16:53:32 *** luke-jr <luke-jr!~luke-jr@user/luke-jr> has joined #bitcoin-core-dev
1922021-06-04T17:00:33 *** jonatack <jonatack!jonatack@user/jonatack> has joined #bitcoin-core-dev
1932021-06-04T17:07:50 *** lukedashjr <lukedashjr!~luke-jr@user/luke-jr> has joined #bitcoin-core-dev
1942021-06-04T17:09:45 *** copumpkin <copumpkin!~woohoo@user/copumpkin> has joined #bitcoin-core-dev
1952021-06-04T17:10:31 *** luke-jr <luke-jr!~luke-jr@user/luke-jr> has quit IRC (Ping timeout: 264 seconds)
1962021-06-04T17:10:41 *** lukedashjr is now known as luke-jr
1972021-06-04T17:11:59 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
1982021-06-04T17:13:19 <hebasto> luke-jr: do you mean for the source file?
1992021-06-04T17:13:56 <hebasto> probably locations are used by Qt Linguist
2002021-06-04T17:14:14 <hebasto> but not sure
2012021-06-04T18:04:49 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Remote host closed the connection)
2022021-06-04T18:05:02 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
2032021-06-04T18:08:48 <achow101> #proposedwalletmeetingtopic subtract fee from recipients intended behavior and edge cases
2042021-06-04T18:10:33 *** earnestly <earnestly!~earnest@user/earnestly> has joined #bitcoin-core-dev
2052021-06-04T18:13:16 *** luke-jr <luke-jr!~luke-jr@user/luke-jr> has quit IRC (Ping timeout: 245 seconds)
2062021-06-04T18:13:57 *** luke-jr <luke-jr!~luke-jr@user/luke-jr> has joined #bitcoin-core-dev
2072021-06-04T18:24:42 *** kabaum <kabaum!~kabaum@host-78-77-217-248.mobileonline.telia.com> has joined #bitcoin-core-dev
2082021-06-04T18:40:00 *** kabaum <kabaum!~kabaum@host-78-77-217-248.mobileonline.telia.com> has quit IRC (Ping timeout: 244 seconds)
2092021-06-04T19:00:37 <achow101> #startmeeting
2102021-06-04T19:00:38 <core-meetingbot> Meeting started Fri Jun 4 19:00:37 2021 UTC. The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
2112021-06-04T19:00:38 <core-meetingbot> Available commands: action commands idea info link nick
2122021-06-04T19:00:49 <sipa> hi
2132021-06-04T19:00:54 <jonatack> hi
2142021-06-04T19:01:08 <achow101> #bitcoin-core-dev Wallet Meeting: achow101 _aj_ amiti ariard BlueMatt cfields Chris_Stewart_5 darosior digi_james dongcarl elichai2 emilengler fanquake fjahr gleb glozow gmaxwell gwillen hebasto instagibbs jamesob jarolrod jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral laanwj lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik petertodd
2152021-06-04T19:01:09 <achow101> phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild
2162021-06-04T19:01:34 <achow101> I have a topic, but are there any other topics for today?
2172021-06-04T19:01:51 <sipa> topic suggestion: what to prioritize for taproot wallet support? there are probably half a dozen things that need to be done
2182021-06-04T19:01:58 <michaelfolkson> hi
2192021-06-04T19:02:06 <jarolrod> hi
2202021-06-04T19:02:17 <fjahr> hi
2212021-06-04T19:02:40 <achow101> #topic subtract fee from recipients intended behavior and edge cases (achow101)
2222021-06-04T19:02:40 <core-meetingbot> topic: subtract fee from recipients intended behavior and edge cases (achow101)
2232021-06-04T19:03:05 <achow101> What is the exact behavior and use case we expect for the subtract fee from recipients feature?
2242021-06-04T19:03:35 <sipa> can you give an example of where the expected behavior isn't clear?
2252021-06-04T19:03:45 <ryanofsky> (context is https://github.com/bitcoin/bitcoin/pull/22008#pullrequestreview-676528963)
2262021-06-04T19:03:55 <achow101> ryanofsky noticed that the current implementation (after 17331 removed the loop) will increase the recipient amounts if a dropped change output was more than the required fee
2272021-06-04T19:04:22 <achow101> I looked at the previous looping implementation, and it looks like that would actually just overpay the fees in that case. it would reduce the fee from the recipients, then drop the change output to fee
2282021-06-04T19:04:35 <achow101> I think neither of these things are what we want to do
2292021-06-04T19:05:42 <michaelfolkson> Your view is... achow101? :)
2302021-06-04T19:05:46 <sipa> what does dropped mean here? don't you "start" from a transaction without change, and add it if necessary?
2312021-06-04T19:06:04 <achow101> michaelfolkson: https://github.com/bitcoin/bitcoin/pull/22008#issuecomment-854880614
2322021-06-04T19:06:18 <jonatack> sipa: was wondering this too
2332021-06-04T19:06:36 <achow101> sipa: we start from a transaction with change, then subtract the fees from it. then if it is below dust or the exact match window, we remove the change output
2342021-06-04T19:06:52 <achow101> with subtract fee from output, we skip the "subtract fees from it" step
2352021-06-04T19:07:06 <sipa> achow101: only in the current knapsack?
2362021-06-04T19:07:14 <achow101> sipa: always
2372021-06-04T19:07:22 <achow101> we do this regardless of the algorithm
2382021-06-04T19:07:52 <achow101> with BnB, the change always ends up in the exact match window since we do the same math, so the change is always dropped
2392021-06-04T19:08:07 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 264 seconds)
2402021-06-04T19:08:10 <ryanofsky> IMO the choice is just between slightly overpaying fees and being pedantic about the word "subtract". Or just keeping current behavior and mostly subtracting sometimes adding to recipient when it's most efficient
2412021-06-04T19:09:01 <ryanofsky> This is good for the use-case of transferring funds between wallets, which is at least is where I've used subtract from recipient before
2422021-06-04T19:09:04 <michaelfolkson> I do think paying a little more than the recipient is expecting is strange behavior for both the sender and the receiver
2432021-06-04T19:09:38 <ryanofsky> It deserves to be documented, sure
2442021-06-04T19:09:39 <achow101> what we've always done is overpay fees, probably too much
2452021-06-04T19:09:40 <sipa> ryanofsky: i think that's the most important use case
2462021-06-04T19:09:51 <sipa> moving all funds from one wallet to another
2472021-06-04T19:09:56 <ryanofsky> But I think you choose behavior based on use cases, not on being pedantic about terminology
2482021-06-04T19:10:12 <achow101> ryanofsky: the use case I've seen the most is moving all funds from one wallet to another, in which case this discussion doesn't matter
2492021-06-04T19:10:33 <achow101> but we don't really know what people actually use this for
2502021-06-04T19:10:46 <ryanofsky> achow101, it matters because in one case you overpay the miner, in the other case you have a little more funds in your new wallet
2512021-06-04T19:11:21 *** Guest37 <Guest37!~Guest37@116.68.83.230> has joined #bitcoin-core-dev
2522021-06-04T19:11:53 <sipa> is this a long term problem? i'd imagine that in a BnB + SRD world, you have two algorithms one that aims for no-change solutions, and one that aims for with-change solutions, and you pick the best one
2532021-06-04T19:11:59 <ryanofsky> but it doesn't matter that much, it is always a case where amount is less than the estimated cost of creating & spending the utxo
2542021-06-04T19:12:09 <Guest37> Im looking for a developer, anyone freelancing?
2552021-06-04T19:12:11 <sipa> and if the with-change solution results in too low change, you just discard that solution
2562021-06-04T19:12:24 <michaelfolkson> Guest37: Sorry, in the middle of a meeting
2572021-06-04T19:12:28 <sipa> or you convert it to a no-change one, and consider it in that form
2582021-06-04T19:13:02 <jonatack> use case: i subtractfeefromamount in the case of say, selling btc to a party who chooses the fee rate they want to use for the txn
2592021-06-04T19:13:11 <Guest37> its okay, after call me.paying big bucks for a bitcoin competitor. "Bitcoin Green" - Runs 100% sustainable. No electricity used ever.
2602021-06-04T19:13:16 <sipa> Guest37: go away
2612021-06-04T19:13:17 <Guest37> PM me before u miss the launch
2622021-06-04T19:13:17 <ryanofsky> sipa, this is all after coin selection, when the algorithm has already run and then we discover the change output is uneconomical
2632021-06-04T19:13:41 <Guest37> *scoff* nerds
2642021-06-04T19:13:45 <achow101> I think this case is an extreme edge case
2652021-06-04T19:13:50 <ryanofsky> so we discard the change output, and pay slightly more fees in the normal case
2662021-06-04T19:13:57 <achow101> especially after effective value
2672021-06-04T19:14:19 <ryanofsky> and in the subtract from recipients case we can do a little better and send the extra amount to recipients, which is what the code is doing now
2682021-06-04T19:14:21 *** Guest37 <Guest37!~Guest37@116.68.83.230> has quit IRC (Client Quit)
2692021-06-04T19:14:34 <ryanofsky> but agree it is not very important
2702021-06-04T19:14:56 <sipa> ryanofsky: which means it increases the waste metric (once that's in use), and will hopefully not be favored if an actual no-change solutions exists too
2712021-06-04T19:15:17 <sipa> ?
2722021-06-04T19:15:37 <ryanofsky> Not sure, I'm not familiar with the waste metric yet
2732021-06-04T19:15:52 <achow101> sipa: I don't think the waste metric accounts for change being dust, yet
2742021-06-04T19:16:03 <sipa> it should, i think
2752021-06-04T19:16:13 <sipa> overpaying fee is waste
2762021-06-04T19:16:36 <achow101> right, we do consider that when we know there is no change
2772021-06-04T19:17:38 <achow101> actually, thinking on it, I don't think knapsack can even find a solution where change would be dust.
2782021-06-04T19:17:47 <achow101> since it targets a minimum change value
2792021-06-04T19:18:41 <ryanofsky> Then maybe it is even more rare and only happens with manual coin selection
2802021-06-04T19:18:52 <sipa> i'm thinking something similar
2812021-06-04T19:19:21 <achow101> indeed
2822021-06-04T19:19:23 <jonatack> test coverage on this may be nice, if missing
2832021-06-04T19:19:29 <sipa> in whatever situation where you'd end up with change that's uneconomical (which dust definitely is), there *should* exist a better no-change solution that BnB would find
2842021-06-04T19:20:09 <sipa> at the very least, the one that's exactly the same but with the change converged to fee
2852021-06-04T19:20:16 <sipa> (but possibly, a better one too)
2862021-06-04T19:20:23 *** gwillen <gwillen!~gwillen@user/gwillen> has joined #bitcoin-core-dev
2872021-06-04T19:20:24 <ryanofsky> Either way, I'm just defending current behavior, and don't see a benefit in changing besides being more strict about "subtract". But I don't think it would be a huge deal to change
2882021-06-04T19:21:11 <achow101> ryanofsky: the current behavior is accidental though, and if you look at before 17331, we would always overpay
2892021-06-04T19:21:48 <ryanofsky> Ok, I did write the code intentionally that way when I suggested in in the other PR, but maybe I misread previous behavior
2902021-06-04T19:22:41 <achow101> I didn't realize that at that time. if I did, we would have had this discussion several weeks ago
2912021-06-04T19:22:48 <ryanofsky> I was trying not to change behavior, but I think I was basing it on your existing changes in that PR not the previous code.
2922021-06-04T19:23:45 <ryanofsky> Anyway, that would be another reason to change, which is fine
2932021-06-04T19:24:40 <achow101> I'll do some further analysis on the actual conditions this could occur and we can revisit this later
2942021-06-04T19:24:50 <achow101> as usual, coin selection remains inscrutable
2952021-06-04T19:25:11 <achow101> #topic what to prioritize for taproot wallet support? (sipa)
2962021-06-04T19:25:11 <core-meetingbot> topic: what to prioritize for taproot wallet support? (sipa)
2972021-06-04T19:25:20 <ryanofsky> Sure, and you should really do what you want there ultimately
2982021-06-04T19:26:27 <michaelfolkson> Can you give an update on where we are with Taproot wallet support to start with sipa? I saw this PR though haven't looked through it yet https://github.com/bitcoin/bitcoin/pull/21365
2992021-06-04T19:26:35 <sipa> so a rough list of missing things in master: signing support, descriptor inference support, multisig support (multi(k,...) doesn't exist in taproot), actual PSBT support with extensions so spending paths can be conveyed, support for easily constructing no-keypath descriptors, ...
3002021-06-04T19:27:05 <sipa> do we want to try to get signing support in 22.0?
3012021-06-04T19:27:17 <achow101> I think we should try to get signing support for 22.0
3022021-06-04T19:27:24 <achow101> and basic descriptor inference
3032021-06-04T19:27:47 <fjahr> hell yeah :)
3042021-06-04T19:28:17 <sipa> signing for basic stuff is done (which is really only useful for keypath signing, but in theory does script paths too)
3052021-06-04T19:28:17 <achow101> michaelfolkson: we have tr() descriptor construction with keys only now. you can import them into a watch only descriptor wallet
3062021-06-04T19:28:59 <sipa> so we punt multisig support and other descriptor extensions
3072021-06-04T19:29:11 <sipa> and just try to get basic key path signing to work
3082021-06-04T19:29:16 <achow101> I think that's reasonable
3092021-06-04T19:29:54 <achow101> also 22.0 should be released before taproot activates, so I don't think we need to have support for everything at the very beginning
3102021-06-04T19:29:56 <sipa> we'll want PSBT extensions for taproot (and musig, once that's a bit further along), but that's a larger discussion than just the bitcoin core wallet
3112021-06-04T19:30:44 <michaelfolkson> So that would just be #21365 that needs review and merging for 22.0?
3122021-06-04T19:30:46 <gribble> https://github.com/bitcoin/bitcoin/issues/21365 | Basic Taproot signing support for descriptor wallets by sipa · Pull Request #21365 · bitcoin/bitcoin · GitHub
3132021-06-04T19:30:58 <sipa> plus inference support
3142021-06-04T19:31:20 <achow101> basic inference support shouldn't be particularly hard
3152021-06-04T19:31:52 <achow101> do we need to add OutputType::BECH32M?
3162021-06-04T19:32:05 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
3172021-06-04T19:32:08 <sipa> that's a good question
3182021-06-04T19:32:13 <sipa> i'd say yes
3192021-06-04T19:32:28 <sipa> because it's something receivers care about
3202021-06-04T19:32:35 <achow101> agreed
3212021-06-04T19:32:55 <achow101> that also shouldn't be hard
3222021-06-04T19:33:04 <sipa> indeed
3232021-06-04T19:33:18 <sipa> i don't know much about the interaction with descriptor wallets, but i can try
3242021-06-04T19:33:40 <achow101> I can look at it
3252021-06-04T19:33:50 <achow101> I don't think it requires much in the wallet itself
3262021-06-04T19:34:06 <michaelfolkson> Inference support is just docs, error messages, things like that?
3272021-06-04T19:34:27 <sipa> lots of RPCs report inferred descriptors
3282021-06-04T19:34:59 <achow101> michaelfolkson: inference support is getting the descriptor for a given scriptPubKey
3292021-06-04T19:35:08 <michaelfolkson> Oh ok, thanks
3302021-06-04T19:35:46 <achow101> reminder that feature freeze is in ~10 days
3312021-06-04T19:36:40 <achow101> anything else to discuss?
3322021-06-04T19:37:05 <sipa> GetDestinationForKey... doesn't need BECH32M support, right?
3332021-06-04T19:37:45 <sipa> that's only for legacy wallets i assume (and hope)
3342021-06-04T19:38:14 <achow101> sipa: should be for legacy wallets only
3352021-06-04T19:38:16 <achow101> so no
3362021-06-04T19:38:42 <sipa> dumpwallet is disabled for descriptor wallets?
3372021-06-04T19:38:46 <achow101> yes
3382021-06-04T19:39:35 <achow101> #endmeeting
3392021-06-04T19:39:36 <core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
3402021-06-04T19:39:36 <core-meetingbot> Meeting ended Fri Jun 4 19:39:35 2021 UTC.
3412021-06-04T19:39:36 <core-meetingbot> Minutes: https://bitcoin.jonasschnelli.ch/ircmeetings/logs/bitcoin-core-dev/2021/bitcoin-core-dev.2021-06-04-19.00.moin.txt
3422021-06-04T19:40:01 <michaelfolkson> Did you ever consider doing a wallet current priorities page? Like the P2P one on the dev wiki? https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Current-Priorities
3432021-06-04T19:41:30 <michaelfolkson> When people update it it makes it easier to follow what people are working on wallet related
3442021-06-04T19:41:44 <achow101> we could add one
3452021-06-04T19:42:19 <michaelfolkson> Sounds like Taproot support is the current priority generally for the wallet
3462021-06-04T19:42:40 <warren> BTW did anyone announce the move of #bitcoin-core-dev to Libera? Libera had retweeted those announcements for other projects.
3472021-06-04T19:44:05 <michaelfolkson> warren: It was announced in some places, there are always going to be more places it could be announced in. You want a tweet specifically from say a Bitcoin Core Twitter account?
3482021-06-04T19:44:46 <sipa> laanwj: want to tweet about the IRC move from bitcoincoreorg?
3492021-06-04T19:45:11 <laanwj> sure
3502021-06-04T19:46:16 <laanwj> no problem with that, though i generally don't tweet IRC related things, definitely not on the bitcoincoreorg account, it seems more developer-internal than announcement
3512021-06-04T19:46:19 <ryanofsky> Wow, I thought the whole reason we used IRC was so no one would find us. Maybe this tweeting thing will turn over a new leaf :)
3522021-06-04T19:46:23 <sipa> laanwj: that's fair
3532021-06-04T19:46:27 <laanwj> ryanofsky: that
3542021-06-04T19:46:47 <sipa> we don't really have "user facing" stuff on IRC, maybe other projects do
3552021-06-04T19:47:13 <warren> that's a good point, I guess it matters for the other channels not this
3562021-06-04T19:47:17 <achow101> I do remember seeing (and tweeting) a few wtf tweets when freenode closed the channel
3572021-06-04T19:47:25 <warren> but there is no "official" account to tweet for the user channels
3582021-06-04T19:47:35 <laanwj> if you want to make a "community channel" that's okay but it probably shouldn't be here
3592021-06-04T19:47:49 <warren> I retract that question.
3602021-06-04T19:47:57 <laanwj> at least with libera we have free well-working bridging to matrix
3612021-06-04T19:48:09 <laanwj> so if you want a lot of people here, just ask
3622021-06-04T19:48:22 <jonatack> no tweet sgtm
3632021-06-04T19:48:30 <warren> Is Matrix good? I hadn't heard about code quality and association with altcoin devs made me suspicious early on.
3642021-06-04T19:48:52 <laanwj> yes, matrix is basically discord but free software
3652021-06-04T19:49:08 <achow101> sipa: what about bech32m in the gui?
3662021-06-04T19:49:26 <sipa> achow101: we probably want that too, but i don't think it's a short term requirement
3672021-06-04T19:49:41 <sipa> as long as we don't intend to expose creation of taproot wallets by default
3682021-06-04T19:49:44 <laanwj> +e2e encryption
3692021-06-04T19:49:56 <laanwj> but not if you IRC bridge ofc
3702021-06-04T19:50:10 <achow101> sipa: I suppose right now if you can make a taproot wallet, you can also use the cli to get addresses
3712021-06-04T19:50:48 <sipa> right
3722021-06-04T19:51:09 <sipa> you'll need RPC to import the descriptor anyway
3732021-06-04T19:53:16 <laanwj> warren: not sure where you get the association with altcoin devs from--but in any case it's used in large scale outside cryptocurrency, for example FOSDEM 2021 was done entirely on matrix
3742021-06-04T20:01:08 <achow101> sipa: are you going to do both OutputType::BECH32M and infer support, or would you like me to take a look at one (or both) of them?
3752021-06-04T20:01:37 <sipa> i'll do inference
3762021-06-04T20:01:57 <achow101> ok, I'll do outputtype then
3772021-06-04T20:02:02 *** kabaum <kabaum!~kabaum@host-78-77-217-248.mobileonline.telia.com> has joined #bitcoin-core-dev
3782021-06-04T20:02:02 <warren> laanwj: apparently major early funding came from altcoin ecosystems. glad to hear it doesn't matter now.
3792021-06-04T20:02:40 <michaelfolkson> Added a wallet current priorities page/IRC meetings page on the dev wiki https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Wallet-Current-Priorities-and-IRC-meetings
3802021-06-04T20:02:46 <michaelfolkson> (for the wallet)
3812021-06-04T20:02:58 <laanwj> warren: fair enough, it's the same thing that makes me skeptical about radicle as a decentralized github at the moment
3822021-06-04T20:03:46 <warren> same problem with signal I guess
3832021-06-04T20:03:57 <michaelfolkson> I drafted an example for you sipa, hope you don't mind :)
3842021-06-04T20:04:02 <laanwj> i have been trying to keep track of it but really it's too much about tokens and "governance" instead of delivering useful functionality
3852021-06-04T20:04:04 <michaelfolkson> Please correct if inaccurate
3862021-06-04T20:04:22 <laanwj> yes
3872021-06-04T20:05:38 <sipa> who would have thought that money corrupts
3882021-06-04T20:06:26 <sipa> "Many solutions were suggested for this problem, but most of these were largely concerned with the movement of small green pieces of paper, which was odd because on the whole it wasn't the small green pieces of paper that were unhappy."
3892021-06-04T20:07:34 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
3902021-06-04T20:07:35 <bitcoin-git> [bitcoin] mzumsande opened pull request #22153: test: Fix p2p_leak.py intermittent failure (master...202106_fix_p2p_leak) https://github.com/bitcoin/bitcoin/pull/22153
3912021-06-04T20:07:36 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
3922021-06-04T20:07:59 <laanwj> hehe, yes it's supposed to be a motivation for people to do useful things, i'm not convinced
3932021-06-04T20:09:58 <michaelfolkson> Some people manage to stay just as productive post money. Admittedly some don't :)
3942021-06-04T20:11:54 *** smartin <smartin!~Icedove@88.135.18.171> has quit IRC (Quit: smartin)
3952021-06-04T20:13:02 *** GIANTWORLDKEEPER <GIANTWORLDKEEPER!~pjetcetal@2.95.204.25> has quit IRC (Quit: EXIT)
3962021-06-04T20:13:49 *** GIANTWORLDKEEPER <GIANTWORLDKEEPER!~pjetcetal@2.95.204.25> has joined #bitcoin-core-dev
3972021-06-04T20:27:57 *** Talkless <Talkless!~Talkless@mail.dargis.net> has joined #bitcoin-core-dev
3982021-06-04T20:29:06 *** kabaum <kabaum!~kabaum@host-78-77-217-248.mobileonline.telia.com> has quit IRC (Ping timeout: 264 seconds)
3992021-06-04T20:29:23 <hebasto> observing vandal-like actions in Ukrainian translation on Transifex; made local backups just in case
4002021-06-04T20:30:55 <sipa> hebasto: i hope it has history, and changes can be reverted?
4012021-06-04T20:31:39 <hebasto> sipa: right, on per-message basis
4022021-06-04T20:34:03 <hebasto> I've send a message to that user asking for more attention (in case his three actions in a row were made by accident)
4032021-06-04T20:38:00 *** kabaum <kabaum!~kabaum@host-78-77-217-248.mobileonline.telia.com> has joined #bitcoin-core-dev
4042021-06-04T20:39:12 <hebasto> is 0.20.2rc2 supposed to be signed for windows only, or macos as well?
4052021-06-04T20:47:38 *** kabaum <kabaum!~kabaum@host-78-77-217-248.mobileonline.telia.com> has quit IRC (Ping timeout: 268 seconds)
4062021-06-04T20:54:39 *** evias <evias!~evias__@user/evias> has quit IRC (Quit: This computer has gone to sleep)
4072021-06-04T20:57:19 *** lightlike <lightlike!~lightlike@user/lightlike> has quit IRC (Quit: Leaving)
4082021-06-04T21:08:02 *** kabaum <kabaum!~kabaum@host-78-77-217-248.mobileonline.telia.com> has joined #bitcoin-core-dev
4092021-06-04T21:23:08 <achow101> hebasto: it should have a macos sig too, just waiting on jonasschnelli
4102021-06-04T21:23:25 <hebasto> achow101: ok
4112021-06-04T21:23:55 <achow101> sipa: what about importing tr() descriptors and bech32m addresses into legacy wallets? I guess it would make sense to be able to watch them with a legacy wallet?
4122021-06-04T21:25:22 <sipa> achow101: just watching would be easy i guess, just convert them to watched scripts
4132021-06-04T21:25:45 <achow101> but that would also end up watching the p2sh wrapped versions too (I think)
4142021-06-04T21:25:52 <sipa> right
4152021-06-04T21:26:06 <sipa> that could be avoided with more special casing, i guess
4162021-06-04T21:26:20 <sipa> but also doing more (like enabling updating PSBT with that, once there are extensions) will be hard
4172021-06-04T21:26:37 <achow101> my thought was to just completely disallow bech32m for legacy wallets
4182021-06-04T21:26:44 <sipa> i think that makes sense
4192021-06-04T21:26:47 <achow101> which should take care of any future things too
4202021-06-04T21:37:13 <sipa> right
4212021-06-04T21:48:00 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
4222021-06-04T21:48:01 <bitcoin-git> [bitcoin] achow101 opened pull request #22154: Add OutputType::BECH32M and related wallet support for fetching bech32m addresses (master...outputtype-bech32m) https://github.com/bitcoin/bitcoin/pull/22154
4232021-06-04T21:48:02 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
4242021-06-04T21:54:02 *** SenX <SenX!~textual@2600:1700:42f0:f60:c0f4:898b:4a73:14b1> has joined #bitcoin-core-dev
4252021-06-04T21:57:07 *** belcher_ is now known as belcher
4262021-06-04T22:00:46 *** kabaum <kabaum!~kabaum@host-78-77-217-248.mobileonline.telia.com> has quit IRC (Ping timeout: 245 seconds)
4272021-06-04T22:03:25 *** OP_NOP_ <OP_NOP_!~OP_NOP@154.3.250.73> has joined #bitcoin-core-dev
4282021-06-04T22:07:11 *** OP_NOP <OP_NOP!~OP_NOP@154.29.131.8> has quit IRC (Ping timeout: 252 seconds)
4292021-06-04T22:15:19 *** Guest75 <Guest75!~Guest75@host-212-171-3-157.retail.telecomitalia.it> has joined #bitcoin-core-dev
4302021-06-04T22:15:43 *** Guest75 <Guest75!~Guest75@host-212-171-3-157.retail.telecomitalia.it> has quit IRC (Client Quit)
4312021-06-04T22:53:08 *** nopf <nopf!~nopf@n218103136056.netvigator.com> has joined #bitcoin-core-dev
4322021-06-04T22:53:08 *** nopf <nopf!~nopf@n218103136056.netvigator.com> has quit IRC (K-Lined)
4332021-06-04T22:56:42 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 264 seconds)
4342021-06-04T22:58:30 *** Talkless <Talkless!~Talkless@mail.dargis.net> has quit IRC (Quit: Konversation terminated!)
4352021-06-04T23:02:11 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has joined #bitcoin-core-dev
4362021-06-04T23:11:06 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has joined #bitcoin-core-dev
4372021-06-04T23:11:06 <bitcoin-git> [bitcoin] ryanofsky opened pull request #22155: wallet test: Add test for subtract fee from recipient behavior (master...pr/subfee) https://github.com/bitcoin/bitcoin/pull/22155
4382021-06-04T23:11:07 *** bitcoin-git <bitcoin-git!~bitcoin-g@x0f.org> has left #bitcoin-core-dev
4392021-06-04T23:19:00 *** SenX <SenX!~textual@2600:1700:42f0:f60:c0f4:898b:4a73:14b1> has quit IRC (Quit: My iMac has gone to sleep. ZZZzzzâ¦)
4402021-06-04T23:37:50 *** sipsorcery <sipsorcery!~sipsorcer@2a02:8084:6981:7880::3> has quit IRC (Ping timeout: 268 seconds)
4412021-06-04T23:40:58 <sipa> achow101: this is a much harder problem than i thought
4422021-06-04T23:41:04 <sipa> inferring tr descriptors
4432021-06-04T23:41:19 <sipa> fun edge case: what if you have repeated subtrees
4442021-06-04T23:42:01 *** davterra <davterra!~davterra@178.128.106.205> has quit IRC (Read error: Connection reset by peer)
4452021-06-04T23:42:26 *** davterra <davterra!~davterra@178.128.106.205> has joined #bitcoin-core-dev
4462021-06-04T23:43:59 <achow101> sipa: for 22.0, I think we can have just the minimum of "OP_1 <pubkey>" -> "tr(<pubkey>)"
4472021-06-04T23:44:08 <sipa> sure
4482021-06-04T23:44:20 <sipa> well, that's not correct
4492021-06-04T23:44:35 <sipa> even single-key cases get tweaked
4502021-06-04T23:44:52 <sipa> but still, that wouldn't be hard to do
4512021-06-04T23:45:18 <achow101> but the tweak is reversible?
4522021-06-04T23:45:25 <sipa> no
4532021-06-04T23:45:45 <sipa> it's similar to P2PKH in a way
4542021-06-04T23:45:56 <sipa> you can't infer the pubkey from the scriptPubKey
4552021-06-04T23:46:31 <sipa> but if you started from an expanded descriptor, you have enough information in the SigningProvider to infer
4562021-06-04T23:48:08 <achow101> ah, without the internal key, you can't get the tweak
4572021-06-04T23:48:21 <sipa> right, the tweak is literally just H(internal key)
4582021-06-04T23:50:06 <achow101> but with access to the SigningProvider, it is possible to get at least the internal key
4592021-06-04T23:50:32 <sipa> the rest too
4602021-06-04T23:50:49 <sipa> it's just a bit tricky to infer a tree structure from a bunch of leaves
4612021-06-04T23:50:53 <achow101> how is the tree stored in the SigningProvider?
4622021-06-04T23:51:06 <sipa> as a map (script -> controlblock)
4632021-06-04T23:51:16 <sipa> which is kind of how i expect it to end up in PSBT as well
4642021-06-04T23:51:40 <sipa> though obviously the internal structure can change if some other approach is taken
4652021-06-04T23:52:10 <sipa> if the internal structure is literally the tree it'd be easier, but i think that would be hard to map to something PSBT-like I think
4662021-06-04T23:52:22 <sipa> unless it's a field of the form "here is the serialized tree, go nuts"
4672021-06-04T23:52:52 <achow101> that would be the easiest
4682021-06-04T23:52:58 <achow101> but perhaps not privacy preserving
4692021-06-04T23:53:16 <sipa> right, it'd be nice if it was possible to give "this is the only branch you need to care about"
4702021-06-04T23:53:58 <achow101> so the problem is if you have the same script in different parts of the tree
4712021-06-04T23:54:07 <sipa> oh
4722021-06-04T23:54:09 <sipa> lol
4732021-06-04T23:54:16 <sipa> this problem just cannot occur
4742021-06-04T23:54:22 <achow101> phew
4752021-06-04T23:54:29 <sipa> because to have repeated subtrees, you need repeated leaves
4762021-06-04T23:54:40 <sipa> and repeated leaves can't be encoded in a (script -> control) map
4772021-06-04T23:54:44 <sipa> it'd need to be a multimap
4782021-06-04T23:54:48 <achow101> I was going to point that out
4792021-06-04T23:54:52 <sipa> thanks!
4802021-06-04T23:55:24 <achow101> why couldn't we have repeated leaves?
4812021-06-04T23:55:56 <sipa> in descriptor form they're possible
4822021-06-04T23:56:05 <sipa> but not in the SigningProvider form i have now
4832021-06-04T23:56:12 <sipa> (they're also pointless...)
4842021-06-04T23:56:49 <achow101> so we could just disallow them
4852021-06-04T23:57:42 <sipa> yeah, though they can't be detected in descriptor form
4862021-06-04T23:57:47 <sipa> only after derivation
4872021-06-04T23:58:07 <sipa> e.g. you could have tr(KEY,{xpub/*,pubkey}), and pubkey matches the xpub/* derivation at index 1923098173981
4882021-06-04T23:59:29 <achow101> hmm