12020-09-17T00:00:02 *** Suntop1 has quit IRC
22020-09-17T00:01:06 *** jaybny has quit IRC
32020-09-17T00:02:18 *** jaybny has joined #bitcoin-core-dev
42020-09-17T00:03:01 *** melande1 has quit IRC
52020-09-17T00:03:10 *** AaronvanW has quit IRC
62020-09-17T00:03:24 *** melande1 has joined #bitcoin-core-dev
72020-09-17T00:13:06 *** jaybny has quit IRC
82020-09-17T00:20:07 *** melande1 has quit IRC
92020-09-17T00:20:24 *** melande1 has joined #bitcoin-core-dev
102020-09-17T00:21:07 *** mdunnio has joined #bitcoin-core-dev
112020-09-17T00:22:11 *** ironmarx has joined #bitcoin-core-dev
122020-09-17T00:26:04 *** mdunnio has quit IRC
132020-09-17T00:27:33 *** justanotheruser has joined #bitcoin-core-dev
142020-09-17T00:34:14 *** vasild has quit IRC
152020-09-17T00:34:25 *** vasild has joined #bitcoin-core-dev
162020-09-17T00:38:53 *** AaronvanW has joined #bitcoin-core-dev
172020-09-17T00:44:24 *** AaronvanW has quit IRC
182020-09-17T00:47:35 *** mrostecki has quit IRC
192020-09-17T00:55:41 *** bitcoin-git has joined #bitcoin-core-dev
202020-09-17T00:55:41 <bitcoin-git> [bitcoin] eltociear opened pull request #19965: Fix GitHub format (master...patch-1) https://github.com/bitcoin/bitcoin/pull/19965
212020-09-17T00:55:42 *** bitcoin-git has left #bitcoin-core-dev
222020-09-17T00:57:11 *** bitcoin-git has joined #bitcoin-core-dev
232020-09-17T00:57:11 <bitcoin-git> [bitcoin] fanquake closed pull request #19965: Fix GitHub format (master...patch-1) https://github.com/bitcoin/bitcoin/pull/19965
242020-09-17T00:57:12 *** bitcoin-git has left #bitcoin-core-dev
252020-09-17T00:59:44 *** justanotheruser has quit IRC
262020-09-17T01:01:13 *** Emcy_ has joined #bitcoin-core-dev
272020-09-17T01:01:54 *** Emcy has quit IRC
282020-09-17T01:01:58 *** Emcy_ has joined #bitcoin-core-dev
292020-09-17T01:03:07 *** S3RK has quit IRC
302020-09-17T01:03:13 *** S3RK has joined #bitcoin-core-dev
312020-09-17T01:07:04 *** melande1 has quit IRC
322020-09-17T01:07:30 *** melande1 has joined #bitcoin-core-dev
332020-09-17T01:11:42 *** AaronvanW has joined #bitcoin-core-dev
342020-09-17T01:15:22 *** da39a3ee5e6b4b0d has joined #bitcoin-core-dev
352020-09-17T01:21:00 *** melande1 has quit IRC
362020-09-17T01:21:03 *** sdaftuar_ has quit IRC
372020-09-17T01:21:22 *** melande1 has joined #bitcoin-core-dev
382020-09-17T01:22:49 *** Emcy has joined #bitcoin-core-dev
392020-09-17T01:23:00 *** Emcy_ has quit IRC
402020-09-17T01:23:24 *** sdaftuar_ has joined #bitcoin-core-dev
412020-09-17T01:41:26 *** Highway61 has quit IRC
422020-09-17T01:45:19 *** AaronvanW has quit IRC
432020-09-17T01:53:21 *** Emcy_ has joined #bitcoin-core-dev
442020-09-17T01:54:03 *** Emcy has quit IRC
452020-09-17T02:16:03 *** higherorderbit has quit IRC
462020-09-17T02:18:03 *** melande1 has quit IRC
472020-09-17T02:18:23 *** melande1 has joined #bitcoin-core-dev
482020-09-17T02:19:07 *** melande1 has quit IRC
492020-09-17T02:19:28 *** melande1 has joined #bitcoin-core-dev
502020-09-17T02:21:52 *** higherorderbit has joined #bitcoin-core-dev
512020-09-17T02:21:57 *** mdunnio has joined #bitcoin-core-dev
522020-09-17T02:27:02 *** mdunnio has quit IRC
532020-09-17T02:48:39 *** davec has quit IRC
542020-09-17T02:54:51 *** davec has joined #bitcoin-core-dev
552020-09-17T03:00:01 *** ironmarx has quit IRC
562020-09-17T03:01:07 *** arowser has quit IRC
572020-09-17T03:01:27 *** arowser has joined #bitcoin-core-dev
582020-09-17T03:19:00 *** melande1 has quit IRC
592020-09-17T03:19:22 *** melande1 has joined #bitcoin-core-dev
602020-09-17T03:20:53 *** melande1 has quit IRC
612020-09-17T03:21:15 *** melande1 has joined #bitcoin-core-dev
622020-09-17T03:22:08 *** blackjid has joined #bitcoin-core-dev
632020-09-17T03:29:23 *** mdunnio has joined #bitcoin-core-dev
642020-09-17T03:35:14 *** sky54521 has joined #bitcoin-core-dev
652020-09-17T03:37:42 <sky54521> People so less
662020-09-17T03:37:51 *** worc3131 has quit IRC
672020-09-17T03:38:25 <sky54521> Does anyone online
682020-09-17T03:39:10 *** mdunnio has quit IRC
692020-09-17T03:39:16 <kallewoof> #proposedmeetingtopic how should signet params be prefixed? currently "signet_<..>" e.g. "signet_challenge"
702020-09-17T03:42:23 *** AaronvanW has joined #bitcoin-core-dev
712020-09-17T03:45:11 *** sky54521 has quit IRC
722020-09-17T03:45:46 *** sky54521 has joined #bitcoin-core-dev
732020-09-17T03:47:01 *** S3RK has quit IRC
742020-09-17T03:47:30 *** S3RK has joined #bitcoin-core-dev
752020-09-17T03:53:02 *** melande1 has quit IRC
762020-09-17T03:54:15 *** melande1 has joined #bitcoin-core-dev
772020-09-17T03:55:24 *** da39a3ee5e6b4b0d has quit IRC
782020-09-17T04:01:07 *** arowser has quit IRC
792020-09-17T04:01:25 *** arowser has joined #bitcoin-core-dev
802020-09-17T04:10:49 *** da39a3ee5e6b4b0d has joined #bitcoin-core-dev
812020-09-17T04:11:04 *** melande1 has quit IRC
822020-09-17T04:11:27 *** melande1 has joined #bitcoin-core-dev
832020-09-17T04:15:13 *** AaronvanW has quit IRC
842020-09-17T04:20:57 *** sky54521 has joined #bitcoin-core-dev
852020-09-17T04:21:30 *** sky54521 has joined #bitcoin-core-dev
862020-09-17T04:25:05 *** melande1 has quit IRC
872020-09-17T04:25:30 *** melande1 has joined #bitcoin-core-dev
882020-09-17T04:27:02 *** sky54521 has quit IRC
892020-09-17T04:28:30 *** sky54521 has joined #bitcoin-core-dev
902020-09-17T04:29:48 *** kristapsk___ has quit IRC
912020-09-17T04:44:05 *** arowser has quit IRC
922020-09-17T04:44:23 *** arowser has joined #bitcoin-core-dev
932020-09-17T04:45:22 *** cato_ has quit IRC
942020-09-17T04:45:24 *** morcos has quit IRC
952020-09-17T04:45:24 *** davterra has quit IRC
962020-09-17T04:45:28 *** cato__ has joined #bitcoin-core-dev
972020-09-17T04:45:40 *** morcos has joined #bitcoin-core-dev
982020-09-17T04:45:56 *** davterra has joined #bitcoin-core-dev
992020-09-17T04:46:05 *** arowser has quit IRC
1002020-09-17T04:46:22 *** arowser has joined #bitcoin-core-dev
1012020-09-17T04:51:07 *** arowser has quit IRC
1022020-09-17T04:51:24 *** arowser has joined #bitcoin-core-dev
1032020-09-17T04:52:04 *** DeanWeen has quit IRC
1042020-09-17T04:53:47 *** DeanWeen has joined #bitcoin-core-dev
1052020-09-17T04:58:06 *** arowser has quit IRC
1062020-09-17T04:58:25 *** arowser has joined #bitcoin-core-dev
1072020-09-17T04:59:46 *** S3RK has quit IRC
1082020-09-17T04:59:53 *** S3RK has joined #bitcoin-core-dev
1092020-09-17T05:05:05 *** baldur has quit IRC
1102020-09-17T05:06:01 *** melande1 has quit IRC
1112020-09-17T05:06:27 *** melande1 has joined #bitcoin-core-dev
1122020-09-17T05:17:54 *** baldur has joined #bitcoin-core-dev
1132020-09-17T05:19:54 *** go11111111111 has joined #bitcoin-core-dev
1142020-09-17T05:20:51 *** justanotheruser has joined #bitcoin-core-dev
1152020-09-17T05:22:20 *** go121212 has quit IRC
1162020-09-17T05:24:06 *** arowser has quit IRC
1172020-09-17T05:24:26 *** arowser has joined #bitcoin-core-dev
1182020-09-17T05:25:05 *** arowser has quit IRC
1192020-09-17T05:25:22 *** arowser has joined #bitcoin-core-dev
1202020-09-17T05:28:04 *** melande1 has quit IRC
1212020-09-17T05:28:23 *** melande1 has joined #bitcoin-core-dev
1222020-09-17T05:29:25 *** sky54521 has quit IRC
1232020-09-17T05:34:19 *** MrPaz has quit IRC
1242020-09-17T05:35:56 *** Kiminuo has joined #bitcoin-core-dev
1252020-09-17T05:45:00 *** S3RK has quit IRC
1262020-09-17T05:45:27 *** S3RK has joined #bitcoin-core-dev
1272020-09-17T05:46:40 *** S3RK has quit IRC
1282020-09-17T05:46:48 *** S3RK has joined #bitcoin-core-dev
1292020-09-17T05:47:03 *** ctrlbreak_MAD has joined #bitcoin-core-dev
1302020-09-17T05:47:03 *** S3RK has quit IRC
1312020-09-17T05:47:30 *** S3RK has joined #bitcoin-core-dev
1322020-09-17T05:50:29 *** ctrlbreak has quit IRC
1332020-09-17T05:55:27 *** blackjid has quit IRC
1342020-09-17T06:00:01 *** cltrbreak_MAD2 has joined #bitcoin-core-dev
1352020-09-17T06:01:00 *** melande1 has quit IRC
1362020-09-17T06:01:22 *** melande1 has joined #bitcoin-core-dev
1372020-09-17T06:03:31 *** ctrlbreak_MAD has quit IRC
1382020-09-17T06:12:07 *** AaronvanW has joined #bitcoin-core-dev
1392020-09-17T06:14:00 *** melande1 has quit IRC
1402020-09-17T06:14:30 *** melande1 has joined #bitcoin-core-dev
1412020-09-17T06:17:24 *** tralfaz has joined #bitcoin-core-dev
1422020-09-17T06:18:07 *** davterra has quit IRC
1432020-09-17T06:22:24 *** bcremer has joined #bitcoin-core-dev
1442020-09-17T06:30:08 *** Guyver2 has joined #bitcoin-core-dev
1452020-09-17T06:37:28 *** andreacab has joined #bitcoin-core-dev
1462020-09-17T06:44:35 *** AaronvanW has quit IRC
1472020-09-17T06:47:07 *** arowser has quit IRC
1482020-09-17T06:47:25 *** arowser has joined #bitcoin-core-dev
1492020-09-17T06:52:39 *** andreacab has quit IRC
1502020-09-17T07:03:12 <jonatack> kallewoof: i suppose signetchallenge, as that's how all the others are (except reindex-chainstate that uses lispy kebab-case)
1512020-09-17T07:05:02 *** melande1 has quit IRC
1522020-09-17T07:05:24 *** melande1 has joined #bitcoin-core-dev
1532020-09-17T07:05:51 *** da39a3ee5e6b4b0d has quit IRC
1542020-09-17T07:06:05 *** melande1 has quit IRC
1552020-09-17T07:06:28 *** melande1 has joined #bitcoin-core-dev
1562020-09-17T07:09:35 *** marcoagner has joined #bitcoin-core-dev
1572020-09-17T07:12:46 *** jonatack has quit IRC
1582020-09-17T07:17:35 <gleb> What's the real expectation between blocksonly-mode/block-relay-only-conns and RELAY permission? If a blocksonly-node assignes the permission to a peer, this peer *is allowed* to relay transactions (we won't disconnect them like we do without permission). However, in practice, they would never do, because blocksonly-node tells them not to
1592020-09-17T07:17:35 <gleb> (fRelay=false in the VERSION message).
1602020-09-17T07:17:54 *** da39a3ee5e6b4b0d has joined #bitcoin-core-dev
1612020-09-17T07:18:42 *** S3RK has quit IRC
1622020-09-17T07:18:50 *** S3RK has joined #bitcoin-core-dev
1632020-09-17T07:22:47 *** bcremer has quit IRC
1642020-09-17T07:24:16 *** bitcoin-git has joined #bitcoin-core-dev
1652020-09-17T07:24:16 <bitcoin-git> [bitcoin] ajtowns closed pull request #15502: p2p: Speed up initial connection to p2p network (master...201902-trytoavoiddns) https://github.com/bitcoin/bitcoin/pull/15502
1662020-09-17T07:24:17 *** bitcoin-git has left #bitcoin-core-dev
1672020-09-17T07:28:11 *** sky54521 has joined #bitcoin-core-dev
1682020-09-17T07:28:51 *** go121212 has joined #bitcoin-core-dev
1692020-09-17T07:31:40 *** go11111111111 has quit IRC
1702020-09-17T07:34:24 *** andreacab has joined #bitcoin-core-dev
1712020-09-17T07:51:14 *** andreacab has quit IRC
1722020-09-17T07:51:20 *** andreacab has joined #bitcoin-core-dev
1732020-09-17T07:59:25 *** bitcoin-git has joined #bitcoin-core-dev
1742020-09-17T07:59:25 <bitcoin-git> [bitcoin] robot-dreams opened pull request #19967: test: Replace (dis)?connect_nodes globals with TestFramework methods (master...connect-nodes) https://github.com/bitcoin/bitcoin/pull/19967
1752020-09-17T07:59:26 *** bitcoin-git has left #bitcoin-core-dev
1762020-09-17T08:02:33 *** AstroDroid has joined #bitcoin-core-dev
1772020-09-17T08:02:44 *** jonatack has joined #bitcoin-core-dev
1782020-09-17T08:03:01 *** melande1 has quit IRC
1792020-09-17T08:03:23 *** melande1 has joined #bitcoin-core-dev
1802020-09-17T08:16:02 *** AaronvanW has joined #bitcoin-core-dev
1812020-09-17T08:20:32 *** AaronvanW has quit IRC
1822020-09-17T08:20:49 *** AaronvanW has joined #bitcoin-core-dev
1832020-09-17T08:21:23 *** jonatack has quit IRC
1842020-09-17T08:22:15 *** jonatack has joined #bitcoin-core-dev
1852020-09-17T08:29:44 *** andreacab has quit IRC
1862020-09-17T08:30:01 *** melande1 has quit IRC
1872020-09-17T08:30:10 *** andreacab has joined #bitcoin-core-dev
1882020-09-17T08:30:25 *** melande1 has joined #bitcoin-core-dev
1892020-09-17T08:33:52 *** sethrogers23[m] has joined #bitcoin-core-dev
1902020-09-17T08:34:30 *** promag has joined #bitcoin-core-dev
1912020-09-17T08:34:53 *** andreacab has quit IRC
1922020-09-17T08:51:38 *** nullptr| has quit IRC
1932020-09-17T08:54:29 *** S3RK has quit IRC
1942020-09-17T08:54:56 *** S3RK has joined #bitcoin-core-dev
1952020-09-17T08:58:39 *** nullptr| has joined #bitcoin-core-dev
1962020-09-17T09:00:02 *** AstroDroid has quit IRC
1972020-09-17T09:00:47 *** bosch has joined #bitcoin-core-dev
1982020-09-17T09:04:05 *** arowser has quit IRC
1992020-09-17T09:04:25 *** arowser has joined #bitcoin-core-dev
2002020-09-17T09:05:17 *** kexkey has quit IRC
2012020-09-17T09:07:34 *** S3RK has quit IRC
2022020-09-17T09:07:45 *** andreacab has joined #bitcoin-core-dev
2032020-09-17T09:07:49 *** S3RK has joined #bitcoin-core-dev
2042020-09-17T09:09:04 *** melande1 has quit IRC
2052020-09-17T09:09:24 *** melande1 has joined #bitcoin-core-dev
2062020-09-17T09:17:05 *** arowser has quit IRC
2072020-09-17T09:17:24 *** arowser has joined #bitcoin-core-dev
2082020-09-17T09:21:07 *** arowser has quit IRC
2092020-09-17T09:21:24 *** arowser has joined #bitcoin-core-dev
2102020-09-17T09:22:17 *** blardo has joined #bitcoin-core-dev
2112020-09-17T09:23:00 *** melande1 has quit IRC
2122020-09-17T09:23:24 *** melande1 has joined #bitcoin-core-dev
2132020-09-17T09:25:01 *** promag has quit IRC
2142020-09-17T09:29:31 *** mrostecki has joined #bitcoin-core-dev
2152020-09-17T09:30:59 *** andreacab has quit IRC
2162020-09-17T09:31:25 *** andreacab has joined #bitcoin-core-dev
2172020-09-17T09:36:19 *** andreacab has quit IRC
2182020-09-17T09:47:56 *** da39a3ee5e6b4b0d has quit IRC
2192020-09-17T09:50:03 *** promag has joined #bitcoin-core-dev
2202020-09-17T09:50:50 *** dom0 has joined #bitcoin-core-dev
2212020-09-17T09:54:26 *** shaunsun has joined #bitcoin-core-dev
2222020-09-17T09:59:03 *** shaunsun has quit IRC
2232020-09-17T10:04:27 *** EagleTM has joined #bitcoin-core-dev
2242020-09-17T10:06:00 *** melande1 has quit IRC
2252020-09-17T10:06:25 *** melande1 has joined #bitcoin-core-dev
2262020-09-17T10:08:04 *** melande1 has quit IRC
2272020-09-17T10:08:25 *** melande1 has joined #bitcoin-core-dev
2282020-09-17T10:10:03 *** vasild has quit IRC
2292020-09-17T10:10:15 *** cato_ has joined #bitcoin-core-dev
2302020-09-17T10:11:07 *** cato__ has quit IRC
2312020-09-17T10:12:16 *** vasild has joined #bitcoin-core-dev
2322020-09-17T10:14:22 *** S3RK has quit IRC
2332020-09-17T10:14:32 *** S3RK has joined #bitcoin-core-dev
2342020-09-17T10:15:17 *** S3RK has joined #bitcoin-core-dev
2352020-09-17T10:18:27 *** Earnest18Hilll has joined #bitcoin-core-dev
2362020-09-17T10:34:50 *** bitcoin-git has joined #bitcoin-core-dev
2372020-09-17T10:34:50 <bitcoin-git> [bitcoin] robot-dreams opened pull request #19968: doc: make it easier to work out size of bloom filter (master...bloom-doc) https://github.com/bitcoin/bitcoin/pull/19968
2382020-09-17T10:34:51 *** bitcoin-git has left #bitcoin-core-dev
2392020-09-17T10:35:31 *** jonatack has quit IRC
2402020-09-17T10:43:06 *** arowser has quit IRC
2412020-09-17T10:43:25 *** arowser has joined #bitcoin-core-dev
2422020-09-17T11:05:05 *** Earnest18Hilll has quit IRC
2432020-09-17T11:06:00 *** melande1 has quit IRC
2442020-09-17T11:06:23 *** melande1 has joined #bitcoin-core-dev
2452020-09-17T11:15:06 *** bitcoin-git has joined #bitcoin-core-dev
2462020-09-17T11:15:06 <bitcoin-git> [bitcoin] robot-dreams closed pull request #19967: test: Replace (dis)?connect_nodes globals with TestFramework methods (master...connect-nodes) https://github.com/bitcoin/bitcoin/pull/19967
2472020-09-17T11:15:07 *** bitcoin-git has left #bitcoin-core-dev
2482020-09-17T11:15:36 *** bitcoin-git has joined #bitcoin-core-dev
2492020-09-17T11:15:36 <bitcoin-git> [bitcoin] robot-dreams reopened pull request #19967: test: Replace (dis)?connect_nodes globals with TestFramework methods (master...connect-nodes) https://github.com/bitcoin/bitcoin/pull/19967
2502020-09-17T11:15:37 *** bitcoin-git has left #bitcoin-core-dev
2512020-09-17T11:16:01 *** melande1 has quit IRC
2522020-09-17T11:16:25 *** melande1 has joined #bitcoin-core-dev
2532020-09-17T11:19:57 *** jonatack has joined #bitcoin-core-dev
2542020-09-17T11:25:53 *** S3RK has quit IRC
2552020-09-17T11:43:23 *** MrPaz has joined #bitcoin-core-dev
2562020-09-17T11:51:27 *** Chris_Stewart_5 has quit IRC
2572020-09-17T11:54:33 *** Chris_Stewart_5 has joined #bitcoin-core-dev
2582020-09-17T11:57:07 *** davterra has joined #bitcoin-core-dev
2592020-09-17T11:57:43 *** tralfaz has quit IRC
2602020-09-17T12:00:01 *** blardo has quit IRC
2612020-09-17T12:10:01 *** melande1 has quit IRC
2622020-09-17T12:10:24 *** melande1 has joined #bitcoin-core-dev
2632020-09-17T12:11:14 <sdaftuar_> gleb: if A sends B a version message where frelaytxes=false, that means that B should not announce transactions to A
2642020-09-17T12:11:20 <sdaftuar_> it does not mean that A will not announce transactions to B
2652020-09-17T12:11:27 *** sdaftuar_ is now known as sdaftuar
2662020-09-17T12:12:29 <sdaftuar> the reason that is in the protocol is to support light-clients that might need a window of time to send over a bloom filter to B, to avoid their bandwidth being flooded in between sending a version and sending the filter
2672020-09-17T12:12:32 <sdaftuar> (i believe)
2682020-09-17T12:13:14 <sdaftuar> we piggy-backed off that functionality being present when -blocksonly mode was added
2692020-09-17T12:13:21 <sdaftuar> and then again when block-relay-only peers were added
2702020-09-17T12:18:26 *** Highway61 has joined #bitcoin-core-dev
2712020-09-17T12:21:47 *** promag has quit IRC
2722020-09-17T12:21:50 <gleb> sdaftuar: That's a different thing, I'm talking about sending txs from B->A. It should not announce transactions, and we will disconnect if they do. Except the case if we re-allow it with RELAY permission
2732020-09-17T12:22:00 *** melande1 has quit IRC
2742020-09-17T12:22:03 *** Jayflux has joined #bitcoin-core-dev
2752020-09-17T12:22:27 *** melande1 has joined #bitcoin-core-dev
2762020-09-17T12:22:37 <gleb> Then it's allowed to send transactions B->A and A will process them just fine.
2772020-09-17T12:23:11 <gleb> But node B running Bitcoin Core currently doesn't employ this ability, because it doesn't know it's permitted.
2782020-09-17T12:31:00 *** andreacab has joined #bitcoin-core-dev
2792020-09-17T12:37:38 *** bosch has quit IRC
2802020-09-17T12:39:35 *** Guyver2 has quit IRC
2812020-09-17T12:44:31 *** twistedline__ has quit IRC
2822020-09-17T12:44:53 *** twistedline__ has joined #bitcoin-core-dev
2832020-09-17T12:44:57 *** S3RK has joined #bitcoin-core-dev
2842020-09-17T12:49:04 <sdaftuar> gleb: ah i see
2852020-09-17T12:49:26 <sdaftuar> so in general B has no way of knowing that A has given it those permissions
2862020-09-17T12:49:48 *** S3RK has quit IRC
2872020-09-17T12:51:20 <sdaftuar> hmm. what happens if you connect to a node that is running in blocksonly mode?
2882020-09-17T12:59:45 *** promag has joined #bitcoin-core-dev
2892020-09-17T13:04:20 *** promag has quit IRC
2902020-09-17T13:05:01 *** melande1 has quit IRC
2912020-09-17T13:05:25 *** melande1 has joined #bitcoin-core-dev
2922020-09-17T13:07:08 *** arowser has quit IRC
2932020-09-17T13:07:26 *** arowser has joined #bitcoin-core-dev
2942020-09-17T13:08:07 *** arowser has quit IRC
2952020-09-17T13:08:25 *** arowser has joined #bitcoin-core-dev
2962020-09-17T13:09:10 *** arowser has quit IRC
2972020-09-17T13:09:28 *** arowser has joined #bitcoin-core-dev
2982020-09-17T13:09:45 *** Jayflux has quit IRC
2992020-09-17T13:10:08 *** arowser has quit IRC
3002020-09-17T13:10:27 *** arowser has joined #bitcoin-core-dev
3012020-09-17T13:12:08 *** arowser has quit IRC
3022020-09-17T13:12:27 *** arowser has joined #bitcoin-core-dev
3032020-09-17T13:12:42 *** melande1 has quit IRC
3042020-09-17T13:13:07 *** arowser has quit IRC
3052020-09-17T13:13:25 *** arowser has joined #bitcoin-core-dev
3062020-09-17T13:16:08 *** arowser has quit IRC
3072020-09-17T13:16:26 *** arowser has joined #bitcoin-core-dev
3082020-09-17T13:17:08 *** arowser has quit IRC
3092020-09-17T13:17:26 *** arowser has joined #bitcoin-core-dev
3102020-09-17T13:18:08 *** arowser has quit IRC
3112020-09-17T13:18:27 *** arowser has joined #bitcoin-core-dev
3122020-09-17T13:19:14 *** promag has joined #bitcoin-core-dev
3132020-09-17T13:20:21 *** jonatack has quit IRC
3142020-09-17T13:21:40 *** jonatack has joined #bitcoin-core-dev
3152020-09-17T13:22:17 *** da39a3ee5e6b4b0d has joined #bitcoin-core-dev
3162020-09-17T13:23:03 *** Kiminuo has quit IRC
3172020-09-17T13:28:51 *** andreacab has quit IRC
3182020-09-17T13:29:16 *** andreacab has joined #bitcoin-core-dev
3192020-09-17T13:30:58 *** MaddinSM has joined #bitcoin-core-dev
3202020-09-17T13:31:31 *** bitcoin-git has joined #bitcoin-core-dev
3212020-09-17T13:31:31 <bitcoin-git> [bitcoin] Sjors opened pull request #19969: Send RPC touch-ups (master...2020/09/send_touchups) https://github.com/bitcoin/bitcoin/pull/19969
3222020-09-17T13:31:32 *** bitcoin-git has left #bitcoin-core-dev
3232020-09-17T13:33:49 *** andreacab has quit IRC
3242020-09-17T13:38:05 *** arowser has quit IRC
3252020-09-17T13:38:25 *** arowser has joined #bitcoin-core-dev
3262020-09-17T13:55:41 *** kexkey has joined #bitcoin-core-dev
3272020-09-17T14:00:39 *** mdunnio has joined #bitcoin-core-dev
3282020-09-17T14:02:36 *** promag has quit IRC
3292020-09-17T14:05:58 *** mdunnio has quit IRC
3302020-09-17T14:06:10 *** mdunnio has joined #bitcoin-core-dev
3312020-09-17T14:22:34 *** andreacab has joined #bitcoin-core-dev
3322020-09-17T14:22:34 *** jonatack has quit IRC
3332020-09-17T14:27:46 <gleb> sdaftuar: I don't think there's any difference?
3342020-09-17T14:32:32 *** TheRec has quit IRC
3352020-09-17T14:37:45 *** andreacab has quit IRC
3362020-09-17T14:38:11 *** andreacab has joined #bitcoin-core-dev
3372020-09-17T14:39:26 *** promag has joined #bitcoin-core-dev
3382020-09-17T14:41:06 *** Talkless has joined #bitcoin-core-dev
3392020-09-17T14:42:21 *** andreacab has quit IRC
3402020-09-17T14:43:44 *** da39a3ee5e6b4b0d has quit IRC
3412020-09-17T14:44:14 *** promag has quit IRC
3422020-09-17T15:00:01 *** MaddinSM has quit IRC
3432020-09-17T15:00:06 *** arowser has quit IRC
3442020-09-17T15:00:26 *** arowser has joined #bitcoin-core-dev
3452020-09-17T15:02:06 *** arowser has quit IRC
3462020-09-17T15:02:24 *** arowser has joined #bitcoin-core-dev
3472020-09-17T15:06:31 *** Guyver2 has joined #bitcoin-core-dev
3482020-09-17T15:07:05 *** da39a3ee5e6b4b0d has joined #bitcoin-core-dev
3492020-09-17T15:15:28 *** promag has joined #bitcoin-core-dev
3502020-09-17T15:20:03 *** promag has quit IRC
3512020-09-17T15:20:10 *** S3RK has joined #bitcoin-core-dev
3522020-09-17T15:22:11 *** jMCg has joined #bitcoin-core-dev
3532020-09-17T15:24:03 *** TheRec has joined #bitcoin-core-dev
3542020-09-17T15:24:03 *** TheRec has joined #bitcoin-core-dev
3552020-09-17T15:24:46 *** S3RK has quit IRC
3562020-09-17T15:30:26 *** TheRec_ has joined #bitcoin-core-dev
3572020-09-17T15:30:27 *** TheRec has quit IRC
3582020-09-17T15:30:27 *** TheRec_ has quit IRC
3592020-09-17T15:30:27 *** TheRec_ has joined #bitcoin-core-dev
3602020-09-17T15:33:07 *** da39a3ee5e6b4b0d has quit IRC
3612020-09-17T15:33:56 *** TheRec_ has quit IRC
3622020-09-17T15:34:06 *** TheRec has joined #bitcoin-core-dev
3632020-09-17T15:34:06 *** TheRec has joined #bitcoin-core-dev
3642020-09-17T15:46:56 *** proofofkeags has joined #bitcoin-core-dev
3652020-09-17T15:49:21 *** Sleepnbum has joined #bitcoin-core-dev
3662020-09-17T15:55:05 *** arowser has quit IRC
3672020-09-17T15:55:25 *** arowser has joined #bitcoin-core-dev
3682020-09-17T15:56:26 *** Chris_Stewart_5 has quit IRC
3692020-09-17T16:00:48 *** jonatack has joined #bitcoin-core-dev
3702020-09-17T16:02:03 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3712020-09-17T16:04:41 *** dom0 has quit IRC
3722020-09-17T16:09:08 *** Kiminuo has joined #bitcoin-core-dev
3732020-09-17T16:09:35 *** isis_ is now known as isis
3742020-09-17T16:24:05 *** AaronvanW has quit IRC
3752020-09-17T16:24:06 *** arowser has quit IRC
3762020-09-17T16:24:24 *** arowser has joined #bitcoin-core-dev
3772020-09-17T16:26:06 *** arowser has quit IRC
3782020-09-17T16:26:24 *** arowser has joined #bitcoin-core-dev
3792020-09-17T16:26:50 *** davec has quit IRC
3802020-09-17T16:27:40 *** real_or_random has quit IRC
3812020-09-17T16:29:09 *** real_or_random has joined #bitcoin-core-dev
3822020-09-17T16:33:11 *** Highway62 has joined #bitcoin-core-dev
3832020-09-17T16:35:42 *** Highway61 has quit IRC
3842020-09-17T16:35:42 *** Highway62 is now known as Highway61
3852020-09-17T16:54:39 *** davec has joined #bitcoin-core-dev
3862020-09-17T17:01:26 *** S3RK has joined #bitcoin-core-dev
3872020-09-17T17:08:38 *** Chris_Stewart_5 has quit IRC
3882020-09-17T17:09:16 *** S3RK has quit IRC
3892020-09-17T17:10:49 *** owowo has quit IRC
3902020-09-17T17:16:16 *** owowo has joined #bitcoin-core-dev
3912020-09-17T17:17:28 *** mrostecki_ has joined #bitcoin-core-dev
3922020-09-17T17:19:23 *** mrostecki has quit IRC
3932020-09-17T17:25:03 *** Chris_Stewart_5 has joined #bitcoin-core-dev
3942020-09-17T17:26:51 *** opsec_x12 has joined #bitcoin-core-dev
3952020-09-17T17:29:50 <sipa> #proposedmeetingtopic Size limit for data-driven unit tests
3962020-09-17T17:42:35 *** Highway61 has quit IRC
3972020-09-17T17:43:59 *** davec has quit IRC
3982020-09-17T17:47:45 *** promag has joined #bitcoin-core-dev
3992020-09-17T17:50:23 *** davec has joined #bitcoin-core-dev
4002020-09-17T17:52:05 *** promag has quit IRC
4012020-09-17T17:55:34 *** Highway61 has joined #bitcoin-core-dev
4022020-09-17T17:57:13 *** S3RK has joined #bitcoin-core-dev
4032020-09-17T18:00:02 *** jMCg has quit IRC
4042020-09-17T18:00:26 *** davec has quit IRC
4052020-09-17T18:01:40 *** S3RK has quit IRC
4062020-09-17T18:07:11 *** davec has joined #bitcoin-core-dev
4072020-09-17T18:21:46 *** csslayer1 has joined #bitcoin-core-dev
4082020-09-17T18:31:11 *** lightlike has joined #bitcoin-core-dev
4092020-09-17T18:35:05 *** arowser has quit IRC
4102020-09-17T18:35:24 *** arowser has joined #bitcoin-core-dev
4112020-09-17T18:38:09 <ryanofsky> #proposedmeetingtopic https://github.com/bitcoin-core/bitcoin-devwiki/wiki/AssertLockHeld-PRs
4122020-09-17T18:38:36 *** Sleepnbum has quit IRC
4132020-09-17T18:45:03 <wumpus> many topics today!
4142020-09-17T18:45:59 <sipa> all short ones, i hope
4152020-09-17T18:50:16 <jonatack> we covered the torv3 transition a bit yesterday at https://bitcoincore.reviews/19845#l-270, feel free to drop if no need to re-discuss
4162020-09-17T18:51:56 <wumpus> true, i'll move it last in that case
4172020-09-17T18:54:46 <vasild> I have an excellent idea about renaming sendaddrv2 to a generic capabilities and making it possible to include various options inside it. Like capabilities(send me addrv2, I participate in gossip, whatnot, my favorite color is blue)
4182020-09-17T18:55:01 <vasild> "excellent"... until somebody shoots it down :)
4192020-09-17T18:57:10 <wumpus> things like that were proposed before, though never in the for of a BIP afaik, but I think that's out of scope of BIP155
4202020-09-17T18:58:10 <wumpus> I think it'd be good to keep sendaddrv2's prameters restricted to things concerning, well, network addresses and address gossiping
4212020-09-17T18:58:16 <vasild> I agree it is out of scope, but I also think "I participate in gossip" is out of scope for bip155, if we consider that its purpose is to support larger than 16 byte addresses
4222020-09-17T18:58:17 <sipa> wumpus: agree
4232020-09-17T18:58:33 <sipa> vasild: maybe...
4242020-09-17T18:59:01 <wumpus> the deadlines for 0.21 are also getting closer, in case that's what you were aiming for
4252020-09-17T19:00:06 <vasild> yeah
4262020-09-17T19:00:21 <wumpus> vasild: well at least it's still close enough, proposing a general capability message is a can of worms
4272020-09-17T19:00:35 <jnewbery> moot time
4282020-09-17T19:00:42 <sipa> hi.
4292020-09-17T19:00:46 <vasild> I was just thinking - if we make it sendaddrv2(your address is X, I participate in gossip) we may as well s/sendaddr/capabilities/ :)
4302020-09-17T19:00:54 <wumpus> it also brings back the discussion of when to send it, for example, for a lot of capabilities you'd want to know them at connection time and not at some point later
4312020-09-17T19:01:00 <wumpus> #startmeeting
4322020-09-17T19:01:00 <lightningbot> Meeting started Thu Sep 17 19:01:00 2020 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
4332020-09-17T19:01:00 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
4342020-09-17T19:01:02 <jnewbery> hi
4352020-09-17T19:01:03 <sipa> vasild: i would really avoid doing anything that's unrelated to addr relay
4362020-09-17T19:01:18 <wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball kvaciral ariard digi_james
4372020-09-17T19:01:20 <sipa> just risks expanding the scope unboundedly
4382020-09-17T19:01:21 <wumpus> amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai2
4392020-09-17T19:01:22 <achow101> hi
4402020-09-17T19:01:27 <wumpus> we have a lot of topics for today, so let's start quickly
4412020-09-17T19:01:27 <provoostenator> hi
4422020-09-17T19:01:29 <jonatack> bonsoir
4432020-09-17T19:01:30 <meshcollider> hi
4442020-09-17T19:01:31 <jb55> greetings
4452020-09-17T19:01:33 <wumpus> #topic High priority for review
4462020-09-17T19:01:34 <luke-jr> hi
4472020-09-17T19:01:35 <vasild> sipa: wumpus: ok
4482020-09-17T19:01:42 <kanzure> hi
4492020-09-17T19:01:46 <michaelfolkson> hi
4502020-09-17T19:01:48 <jonasschnelli> hi
4512020-09-17T19:01:51 <wumpus> https://github.com/bitcoin/bitcoin/projects/8 12 blockers, 1 bugfix, 2 chasing concept ACK
4522020-09-17T19:02:10 <sipa> can i have #19953 ?
4532020-09-17T19:02:13 <gribble> https://github.com/bitcoin/bitcoin/issues/19953 | Implement BIP 340-342 validation (Schnorr/taproot/tapscript) by sipa · Pull Request #19953 · bitcoin/bitcoin · GitHub
4542020-09-17T19:02:24 <wumpus> signet should be close to mergable, I hope we can get that one at least in for 0.21
4552020-09-17T19:03:00 <wumpus> PSA: the release schedule deadlines for 0.21 start october 1: https://github.com/bitcoin/bitcoin/issues/18947
4562020-09-17T19:03:01 <provoostenator> #16546 is next in line for hardware wallet support
4572020-09-17T19:03:04 <wumpus> sipa: sure
4582020-09-17T19:03:05 <gribble> https://github.com/bitcoin/bitcoin/issues/16546 | External signer support - Wallet Box edition by Sjors · Pull Request #16546 · bitcoin/bitcoin · GitHub
4592020-09-17T19:04:07 <wumpus> provoostenator: sipa: added
4602020-09-17T19:04:18 <luke-jr> wumpus: let's put #11082 back in?
4612020-09-17T19:04:21 <gribble> https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
4622020-09-17T19:05:00 <luke-jr> although it looks like I already have 2 there, the ramifications of missing 0.21 with this is pretty annoying
4632020-09-17T19:05:27 <wumpus> I'm still not sure about the writable configuration files (didn't we have two conflicting systems now?) but in any case, added
4642020-09-17T19:05:40 <wumpus> not the time to have that discussion now
4652020-09-17T19:05:48 *** Highway61 has quit IRC
4662020-09-17T19:05:59 <wumpus> #topic Endomorphism optimization in libsecp256k1 (sipa)
4672020-09-17T19:06:05 <vasild> I have never seen such dual configs in any other software...
4682020-09-17T19:06:06 <sipa> hi!
4692020-09-17T19:06:25 <sipa> this is mostly a short announcement so it doesn't cause any surprise
4702020-09-17T19:07:05 <sipa> libsecp256k1 started out as an experiment to see how much secp256k1 EC operations could be made by using the GLV endomorphism optimization, which it was specifically designed to support, but not actually implemented anywhere
4712020-09-17T19:07:09 <luke-jr> vasild: that's kinda the point; it reduces to one config format
4722020-09-17T19:07:24 <fjahr> hi
4732020-09-17T19:07:45 <sipa> as it turned out that there is some risk it is encumbered by a patent, the GLV optimization was made optional, and defaults to off (and has been off in every bitcoin core release)
4742020-09-17T19:08:14 <sipa> it looks like that patent is expiring on september 25th, and blockstream had a patent attorney verify that (i'm happy to share their findings, if anyone cares)
4752020-09-17T19:08:27 <wumpus> yay!
4762020-09-17T19:08:31 <cfields> wooo!
4772020-09-17T19:08:36 <luke-jr> sipa: how sure can we be that it can't break consensus?
4782020-09-17T19:08:56 <sipa> so the plan is to switch it to default on after that date, or even rip out the non-GLV code
4792020-09-17T19:08:58 <sipa> luke-jr: good question
4802020-09-17T19:09:13 <luke-jr> is it provable? :x
4812020-09-17T19:09:16 <sipa> libsecp256k1' CI has always tested with both endomorphism enabled and disabled
4822020-09-17T19:09:42 <sipa> including our exhaustive tests, which are probably as close to a mathemetical proof we can get for real software - at least for some aspects
4832020-09-17T19:10:24 <sipa> fwiw, that's a test where the library is compiled with a slightly different curve equation that makes it trivially insecure, and only leaves 12 valid private/public keys
4842020-09-17T19:10:45 <sipa> and in that mode, we can test literally every combination of signature/pubkey/private key
4852020-09-17T19:11:28 <wumpus> nice
4862020-09-17T19:11:31 <sipa> so i think that given that, it shouldn't be any more invasive than regular code changes to libsecp256k1
4872020-09-17T19:11:35 <luke-jr> has it been proven on a mathematical level? (not saying it's a problem if not, just asking)
4882020-09-17T19:12:19 <sipa> luke-jr: for some parts of the code we have actual proofs (some hand-written, some automatic); though admittedly not the part touched by the endomorphism
4892020-09-17T19:12:35 <wumpus> I think he means in mathetmatical theory, not so much the specific code
4902020-09-17T19:12:40 <luke-jr> right
4912020-09-17T19:13:12 <sipa> wumpus: for the group arithmetic, there is a transliteration of the C code to python, which is then symbolically executed and can be automatically proven correct
4922020-09-17T19:13:17 *** guest534543 has joined #bitcoin-core-dev
4932020-09-17T19:13:37 <provoostenator> Very cool, somewhat scary, but how much of a speedup is this?
4942020-09-17T19:13:37 <sipa> the conversion from C to Python (or its semantics) of course aren't, but the algorithms at a slightly higher level are proven
4952020-09-17T19:13:39 <wumpus> sipa: that's a very interesting approach
4962020-09-17T19:13:47 <sipa> provoostenator: 27% for ecdsa verification
4972020-09-17T19:13:59 <provoostenator> Ok, that's worth some code review time alright.
4982020-09-17T19:14:00 <wumpus> very hard to say no to that :)
4992020-09-17T19:14:16 <sipa> well
5002020-09-17T19:14:24 <sipa> arguably, libsecp256k1 originally _only_ had the GLV mode
5012020-09-17T19:14:40 *** davec has quit IRC
5022020-09-17T19:14:43 <sipa> the mode where GLV was disabled (which is now default) was added later
5032020-09-17T19:14:56 <wumpus> yes it was added out of patent concerns
5042020-09-17T19:15:02 <sipa> yes
5052020-09-17T19:15:22 <sipa> but all changes since 2013 have always kept both GLV and non-GLV working, and tested
5062020-09-17T19:15:27 <meshcollider> Interesting, I didn't know that
5072020-09-17T19:15:34 <luke-jr> was the GLV mode ever released in Core?
5082020-09-17T19:15:47 <wumpus> no
5092020-09-17T19:15:59 <sipa> luke-jr: it's a compile time option, and it was never enabled in (default) builds of core
5102020-09-17T19:16:10 <sipa> you could always enable it yourself with --enable-endomorphism
5112020-09-17T19:16:14 *** davec has joined #bitcoin-core-dev
5122020-09-17T19:16:25 <luke-jr> right, not sure how many people actually did that tho :p
5132020-09-17T19:16:43 <wumpus> some people did it for benchmarking at times
5142020-09-17T19:16:49 *** Kiminuo has quit IRC
5152020-09-17T19:16:50 <wumpus> apart from that, dunno
5162020-09-17T19:16:54 <sipa> luke-jr: i assume nobody
5172020-09-17T19:16:57 <vasild> If there are concernts, what about doing all calculus in both and comparing they produce the same result?
5182020-09-17T19:17:12 <luke-jr> we do have a USE flag for it in Gentoo, but no metrics on usage
5192020-09-17T19:17:16 <sipa> vasild: that's arguably what the unit tests are doing
5202020-09-17T19:17:26 <sipa> if they differed, at least one would fail
5212020-09-17T19:17:43 <luke-jr> vasild: you mean in real-world use? what's the point?
5222020-09-17T19:17:46 <meshcollider> sipa: why not just test it out on all secp256k1 keys to make sure ;)
5232020-09-17T19:17:57 <sipa> meshcollider: that's what the exhaustive test mode does
5242020-09-17T19:17:58 <luke-jr> meshcollider: :D
5252020-09-17T19:18:01 <vasild> I mean, in real life, in production, for e.g. 6 months. But I am not suggesting that, just saying "if there are concerns" :)
5262020-09-17T19:18:07 <sipa> vasild: i believe that is pointless
5272020-09-17T19:18:21 <vasild> ok, I can't judge
5282020-09-17T19:18:33 <sipa> due to the cryptographic nature of things, actual correct _random_ usage is never going to trigger an edge case if one existed
5292020-09-17T19:18:34 <luke-jr> I think you could just build with it enabled, and do a full sync
5302020-09-17T19:18:41 <wumpus> trying completely random input is very likely not going to find anything
5312020-09-17T19:18:44 <wumpus> right
5322020-09-17T19:18:45 <luke-jr> if anything deviates, the sync should fail, right?
5332020-09-17T19:19:07 <sipa> luke-jr: in theory it could be accepting invalid signatures, which wouldn't be caught by such a test
5342020-09-17T19:19:17 <sipa> though again, this is true for every change to the cryptographic code
5352020-09-17T19:19:24 <luke-jr> sipa: but vasild's suggestion wouldn't detect that either
5362020-09-17T19:19:30 <sipa> luke-jr: indeed
5372020-09-17T19:19:38 <sipa> the exhaustive test likely would though
5382020-09-17T19:19:58 <sipa> or at least, has a reasonable chance to - it depends on the nature of the hypothetical bug
5392020-09-17T19:20:53 <sipa> https://patents.google.com/patent/US7110538B2/en
5402020-09-17T19:20:59 <wumpus> I'd assume you have 100% code coverage of that code in the test? (not that that proves anything, of course, but at least all paths are being exercised)
5412020-09-17T19:21:19 *** go11111111111 has joined #bitcoin-core-dev
5422020-09-17T19:21:40 <sipa> wumpus: i believe we have code coverage of everything that isn't impossible to reach, but i'll go verify that
5432020-09-17T19:22:01 <wumpus> sipa: thanks!
5442020-09-17T19:22:01 *** go121212 has quit IRC
5452020-09-17T19:22:29 <sipa> so, expect a libsecp256k1 update shortly after september 25th
5462020-09-17T19:22:49 <wumpus> thanks for the announcement sipa, let's move to next topic
5472020-09-17T19:22:51 <sipa> discussion on testing and whatnot can still happen in the PR
5482020-09-17T19:22:55 <sipa> that's all from me
5492020-09-17T19:23:00 <jnewbery> that's great news sipa!
5502020-09-17T19:23:07 <wumpus> #topic How should signet params be prefixed? (kallewoof)
5512020-09-17T19:23:38 <wumpus> basically my comment here https://github.com/bitcoin/bitcoin/pull/18267#discussion_r488814952
5522020-09-17T19:23:48 <jonatack> i suppose signetchallenge, as that's how all the others are, except reindex-chainstate that uses lispy kebab-case
5532020-09-17T19:24:13 <wumpus> I didn't like _ in command line parameters, - would be ok-ish with me (because it matches the - symbol at the beginning), but our convention seems to be to just concatentate
5542020-09-17T19:24:16 <sipa> it looks like all 3 styles are used; there is -rpcpport, there is -reindex-chainstate, there is -output_csv (to bench)
5552020-09-17T19:24:39 <sipa> my preference is the first (just squeeze things), but apart from that i don't care, and i don't think it's worth much discussion time :)
5562020-09-17T19:24:43 <wumpus> _ is definitely the worst to me at least, it's harder to type too
5572020-09-17T19:25:22 <luke-jr> why not -signet=<param>
5582020-09-17T19:25:22 <wumpus> I do think it is good to be consistent and come up with a standard way also for future arguments
5592020-09-17T19:25:44 <achow101> traditionally we just stick them together without any separator, so just do that?
5602020-09-17T19:25:47 <wumpus> luke-jr: because there may be other signet arguments in the future
5612020-09-17T19:26:10 <sipa> there are several alredy
5622020-09-17T19:26:26 <wumpus> and it's more consistent with -regtest -testnet to have it as a boolean anyhow
5632020-09-17T19:26:41 <wumpus> yes
5642020-09-17T19:26:52 <wumpus> achow101: +1
5652020-09-17T19:27:08 <jnewbery> ACK squeezecase
5662020-09-17T19:27:45 <wumpus> okay, the sentiment here seems to be clear, if no one else is going to weigh in, we're going to next topic
5672020-09-17T19:28:14 <wumpus> #topic Size limit for data-driven unit tests (sipa)
5682020-09-17T19:28:27 <sipa> hi!
5692020-09-17T19:29:26 <luke-jr> o hai thar sipa?
5702020-09-17T19:29:27 <sipa> in #19953 i've recently added a unit test with randomly-generated transaction validation success/failure cases, minimized using the fuzzing framework (it's not an actual fuzzer, all input is generated by a python script, but just minimized using the fuzz build)
5712020-09-17T19:29:29 <gribble> https://github.com/bitcoin/bitcoin/issues/19953 | Implement BIP 340-342 validation (Schnorr/taproot/tapscript) by sipa · Pull Request #19953 · bitcoin/bitcoin · GitHub
5722020-09-17T19:29:54 <sipa> which i think is an interesting approach as it permits getting the kind of coverage you get by running the python functional test for days... weeks...
5732020-09-17T19:30:10 <sipa> it's 250 kB now, which seems in line with some of the other tests we have
5742020-09-17T19:30:26 <sipa> but i could extend this to test more things, and in particular more validation flags
5752020-09-17T19:30:33 <luke-jr> does that create a dep on fuzzing stuff for normal tests? :x
5762020-09-17T19:30:41 <sipa> luke-jr: nope, just a json file
5772020-09-17T19:30:51 <sipa> with the output of the whole fuzzing procedure
5782020-09-17T19:31:00 <luke-jr> aha
5792020-09-17T19:31:22 <sipa> anyway, trying to extend this, using the same approach, leaves me with things in the 1-2 MB range
5802020-09-17T19:31:25 <wumpus> I think we should be careful to not add too much data for tests to the repository, git is not that great for bulk data storage, though 250kB seems fine to me
5812020-09-17T19:31:28 <sipa> and i was wondering if that's acceptable
5822020-09-17T19:31:54 <sipa> there are many more tradeoffs possible, which can reduce that - or extend it - in exchange for coverage/development time
5832020-09-17T19:32:07 <sipa> but if people are like "1 MB is just fine", that would simplify things
5842020-09-17T19:32:21 <wumpus> another drawback of large files is that it generates huge diffs, and this isn't really reviewable
5852020-09-17T19:32:23 <jonasschnelli> I guess the runtime memory requirements are unchanged for that?
5862020-09-17T19:32:35 <sipa> jonasschnelli: yes, it's just a (very simple) unit test
5872020-09-17T19:32:40 <wumpus> jonasschnelli: yes, it's only used at test time
5882020-09-17T19:32:41 <sipa> it's also 1 MB of json which is presumably compressed quite a bit by git
5892020-09-17T19:32:42 <cfields> sipa: does it compress at all in git?
5902020-09-17T19:32:47 <vasild> the json contains ascii hex, what if we save it in binary? would be 2x reduce
5912020-09-17T19:32:49 <cfields> hah
5922020-09-17T19:33:22 <wumpus> but as it's part of a unit test it also can't easily be moved to another repository like the fuzz dataset one
5932020-09-17T19:33:48 <sipa> vasild: yes, possible - but if git compresses it already in a similar degree, leaving it in a more readable form has advantages
5942020-09-17T19:33:59 <luke-jr> is there a reason not to just make this part of the fuzzer build?
5952020-09-17T19:34:09 <sipa> luke-jr: it's not a fuzzer
5962020-09-17T19:34:16 <sipa> you can't run it as a fuzzer
5972020-09-17T19:34:34 <sipa> (it would immediately fail, as it's not testing random inputs)
5982020-09-17T19:34:42 <vasild> sipa: right, I guess disk space when checked out is irrelevant for such sizes
5992020-09-17T19:34:57 <luke-jr> sipa: but can't the 250k be generated at test-time?
6002020-09-17T19:35:02 <sipa> luke-jr: it took me days
6012020-09-17T19:35:11 <luke-jr> hmm
6022020-09-17T19:35:15 <sipa> (of CPU time)
6032020-09-17T19:35:17 *** S3RK has joined #bitcoin-core-dev
6042020-09-17T19:35:23 <luke-jr> a special make target?
6052020-09-17T19:35:29 <sipa> it's nondeterministic
6062020-09-17T19:35:36 <jnewbery> is https://github.com/bitcoin-core/qa-assets used for test assets?
6072020-09-17T19:35:42 <jonasschnelli> +1
6082020-09-17T19:35:54 <wumpus> jnewbery: yes, that's what I meant, the only thing is that it takes an extra step then
6092020-09-17T19:35:54 <sipa> luke-jr: to be clear, this is a test that _already_ runs as a functional test, but only for 1 minute
6102020-09-17T19:36:17 <wumpus> someone who wants to read the test also needs that erpository checked out -- not a problem for the CI at leat
6112020-09-17T19:36:28 <sipa> luke-jr: the approach to extract a very-good-coverage unit test from it makes it a bit more accessible and reusable, and gives the same coverage as running the functional test 1000s of times
6122020-09-17T19:36:46 *** AaronvanW has joined #bitcoin-core-dev
6132020-09-17T19:36:58 *** shesek has joined #bitcoin-core-dev
6142020-09-17T19:36:58 *** shesek has joined #bitcoin-core-dev
6152020-09-17T19:37:05 <sipa> wumpus: that's reasonable, i guess
6162020-09-17T19:37:22 <sipa> skip the test if the json file isn't found
6172020-09-17T19:37:28 <sipa> or something like that
6182020-09-17T19:37:35 <wumpus> sipa: yes, sounds fair to me
6192020-09-17T19:38:02 * luke-jr glares at boost for not supporting skips still (last I checked)
6202020-09-17T19:38:24 <wumpus> though there are already some ~250kB json files in the repo, for the tests, I don't think one more is that bad... but let's not make a habit out of it, and also, you're planning to add more data in the future
6212020-09-17T19:38:31 *** promag has joined #bitcoin-core-dev
6222020-09-17T19:38:35 <ryanofsky> I like the qa assetts idea. Skipping the test if input not found is also similar to what we do for backwards compatibility tests
6232020-09-17T19:38:39 <sipa> luke-jr: "return true;" works great
6242020-09-17T19:38:44 <wumpus> yes
6252020-09-17T19:38:55 <luke-jr> sipa: except it gives the impression it passed?
6262020-09-17T19:39:00 <ryanofsky> No objection to 250kb either, though
6272020-09-17T19:39:34 *** S3RK has quit IRC
6282020-09-17T19:39:38 <sipa> luke-jr: "make check" also doesn't run the fuzz tests; does that give the impression they passed? :)
6292020-09-17T19:39:55 <sipa> there could be a "notice: qa-assets not found, so large data-driven tests are skipped"
6302020-09-17T19:39:55 <luke-jr> sipa: boost explicitly says the tests pass..
6312020-09-17T19:40:14 <sipa> luke-jr: in aggregate
6322020-09-17T19:40:20 <luke-jr> sipa: individually
6332020-09-17T19:40:25 <luke-jr> sipa: this is a problem for another test already IIRC
6342020-09-17T19:40:29 <wumpus> ok, I think we've given sipa quite some input on this for now, decision doesn't need to be made in the meeting, only ~20 minutes left, and 1 or 2 topics
6352020-09-17T19:40:38 <wumpus> #topic AssertLockHeld PRs (ryanofsky)
6362020-09-17T19:40:51 <ryanofsky> Debug lockerorder test is a test that passes if skipped, but minor one
6372020-09-17T19:41:10 <ryanofsky> For AssertLockHeld PRs, I just wanted to advertise wiki page https://github.com/bitcoin-core/bitcoin-devwiki/wiki/AssertLockHeld-PRs
6382020-09-17T19:41:29 <ryanofsky> If anyone is interested in AssertLockHeld improvements but confused by the multiple PRs, page summarizes them
6392020-09-17T19:41:57 <sipa> ryanofsky: thanks for that
6402020-09-17T19:42:04 <jonatack> ryanofsky: v nice
6412020-09-17T19:42:06 * sipa is quite overwhelmed by it
6422020-09-17T19:42:11 <wumpus> yes good to have an overview
6432020-09-17T19:42:24 <ryanofsky> Sure, that's all I have for the topic
6442020-09-17T19:42:57 <wumpus> what would "WeaklyAssertLockHeld" do compared to the normal assert?
6452020-09-17T19:43:20 <vasild> indeed! (confusing name)
6462020-09-17T19:43:49 <ryanofsky> They both do the same thing at runtime, which is why my preference is to have one assert instead of two
6472020-09-17T19:44:23 <sipa> and the difference is that one also does a compile-check (if supported) and the other doesn't?
6482020-09-17T19:44:25 <wumpus> it sounds really weird to me a lock is held or not :)
6492020-09-17T19:44:25 <ryanofsky> But if we can't have one assert, there are cases where the stronger assert isn't accepted at compile time and you need to use the weaker one
6502020-09-17T19:44:27 <vasild> btw, one of the clang people suggested that we don't annotate AssertLockHeld() with any compile time attributes and leave it pure run time.
6512020-09-17T19:44:43 <wumpus> oh, like that
6522020-09-17T19:45:28 <luke-jr> I don't get why one would use Assert* instead of EXCLUSIVE_LOCKS_REQUIRED
6532020-09-17T19:45:41 <luke-jr> outside of perhaps a conditional
6542020-09-17T19:45:53 <wumpus> it's an assertion that existed way before the lock annotations did
6552020-09-17T19:46:04 <sipa> lock annotations also only work in clang
6562020-09-17T19:46:09 <wumpus> ouch
6572020-09-17T19:46:11 <luke-jr> oh :/
6582020-09-17T19:46:16 <sipa> and can't be used for some of the more complex cases, i assume
6592020-09-17T19:46:29 <vasild> luke-jr: runtime asserts work always, compile time _warnings_ - only for clang and if you compile with --enable-werror and if clang does not have bugs etc
6602020-09-17T19:46:32 <ryanofsky> luke-jr, infrequently there are cases where the compile can't know EXCLUSIVE_LOCKS_REQUIRED is satisfied and you have to tell it that
6612020-09-17T19:46:46 <sipa> vasild: well, they only work in -DDEBUG_LOCKORDER mode, which you don't want to use for production :)
6622020-09-17T19:46:50 <ryanofsky> that is what assert is useful for
6632020-09-17T19:47:15 <sipa> so they're overlapping but one is not a subset of the other, in terms of what they can detect
6642020-09-17T19:47:16 <ryanofsky> the other thing assert is useful for (i don't think very useful) is when compile time checks are unavailable or disabled or buggy
6652020-09-17T19:47:51 <wumpus> apparently they're clang only so they're often not available
6662020-09-17T19:48:15 <wumpus> i'm fairly sure most people compile with gcc, at least on linux
6672020-09-17T19:48:21 <ryanofsky> right but they run on CI
6682020-09-17T19:49:05 <ryanofsky> and if you are compiling with gcc, you have to enable run time checks and execute the code and hope an assert is hit to see any benefit from it
6692020-09-17T19:49:26 <wumpus> yes
6702020-09-17T19:49:43 <vasild> having CI as the sole protection seems uncomfortable to me - it does not run manual tests
6712020-09-17T19:49:55 <vasild> developers do on their machines
6722020-09-17T19:50:14 <luke-jr> ideally all tests would exist in the automated form ;)
6732020-09-17T19:50:37 <ryanofsky> vasild, compile time checks check correctness at compile time they have no effect on runtime generated code
6742020-09-17T19:50:45 <wumpus> i wonder how many developers are compiling with DEBUG_LOCKORDER anyway, well probably those that are working on locking changes do
6752020-09-17T19:50:51 <ryanofsky> there's 0 benefit to compiling with compiling checks and then running bitcoind locally
6762020-09-17T19:51:02 <vasild> wumpus: it is enabled bug --enable-debug
6772020-09-17T19:51:15 <vasild> by
6782020-09-17T19:51:27 <wumpus> yes
6792020-09-17T19:51:46 <sipa> "Bitcoin Core developer claims enabling debugging introduces bug"
6802020-09-17T19:52:08 <vasild> "fixes the bug by disabling debugging"
6812020-09-17T19:52:15 <luke-jr> src/Makefile:CXXFLAGS = -Wthread-safety-analysis -DDEBUG_LOCKORDER -O1 -ggdb -Wall -Werror=thread-safety-analysis -fsanitize=undefined
6822020-09-17T19:52:18 <luke-jr> apparently I am
6832020-09-17T19:52:43 <jonatack> I debug-build with clang on some PRs
6842020-09-17T19:52:55 <wumpus> ok if we still want to discuss torv3, we'll have to switch topics now
6852020-09-17T19:52:56 <luke-jr> mind you, I never use dev code for mainnet
6862020-09-17T19:53:08 * luke-jr wonders when a 1 hour limit was set in the first place :P
6872020-09-17T19:53:20 <wumpus> because it's good to keep meetings short
6882020-09-17T19:53:23 <wumpus> #topic torv2->torv3 transition, schedule, process (jonatack)
6892020-09-17T19:53:25 <jonatack> Per this Tor ML post https://lists.torproject.org/pipermail/tor-dev/2020-June/014365.html
6902020-09-17T19:53:43 <jonatack> Tor v2 was deprecated the day before yesterday (September 15, 2020) with 0.4.4.x and will be obsoleted in 0.4.6.x (July 15, 2021)
6912020-09-17T19:53:52 <jonatack> Tor v2 is expected to be completely disabled in Tor client stable versions on October 15, 2021
6922020-09-17T19:54:04 <wumpus> previous discussion from the review meeting yesterday: https://bitcoincore.reviews/19845#l-270
6932020-09-17T19:54:12 <luke-jr> is this a network-level change, or just dependency change?
6942020-09-17T19:54:26 <luke-jr> ie, does Tor v2 stop working for old versions too?
6952020-09-17T19:54:39 <jonatack> a half-dozen of us are running nodes with tor v3 services ATM
6962020-09-17T19:54:50 <sipa> luke-jr: i assume it will, due to network infrastructing updating to versions that don't support torv2 anymore
6972020-09-17T19:54:59 <vasild> luke-jr: they say torv2 is going to be removed from the source code of Tor
6982020-09-17T19:54:59 <jonatack> using #19954 / aka PR 19031
6992020-09-17T19:55:01 <gribble> https://github.com/bitcoin/bitcoin/issues/19954 | tor: make a TORv3 hidden service instead of TORv2 by vasild · Pull Request #19954 · bitcoin/bitcoin · GitHub
7002020-09-17T19:55:05 <wumpus> luke-jr: that's not entirely clear to me; but I assume they'll shut down the directory authorities etc for torv2 too
7012020-09-17T19:55:41 <jonatack> "We will release new Tor client stable versions for all supported series that will disable v2."
7022020-09-17T19:55:55 <jonatack> on Oct 15 2021 per https://blog.torproject.org/v2-deprecation-timeline
7032020-09-17T19:56:06 <jonatack> "This effectively means that from today (July 2nd, 2020), the Internet has around 16 months to migrate from v2 to v3 once and for all."
7042020-09-17T19:56:30 <sipa> that sounds like torv2 will stop working in oct 2021
7052020-09-17T19:56:51 <vasild> they probably realize that if they leave torv2 working, there will be still people using it after 10 years
7062020-09-17T19:56:54 <wumpus> let's try to get basic (if we can't get all) torv3 support into 0.21.0
7072020-09-17T19:57:07 <sipa> wumpus: seems doable
7082020-09-17T19:57:22 <jonatack> we're ~5 commits away
7092020-09-17T19:57:26 <wumpus> better to have things prepared in time than to wait for last minute
7102020-09-17T19:57:34 <jonatack> 19845 + 19954 i believe
7112020-09-17T19:57:42 <wumpus> yea it's not too much anymore
7122020-09-17T19:58:10 <vasild> http://www.erisian.com.au/bitcoin-core-dev/log-2020-09-16.html#l-243
7132020-09-17T19:58:24 <sipa> wumpus: also, ack bip155 changes, as those need to be stable before 0.21 if we want it :)
7142020-09-17T19:58:34 <jonatack> at first, will nodes gossip both v2 and v3?
7152020-09-17T19:58:36 <wumpus> sipa: yes
7162020-09-17T19:58:57 <wumpus> jonatack: i think that would make sense
7172020-09-17T19:59:04 <sipa> agree
7182020-09-17T19:59:22 <vasild> stopping gossip of torv2 we can consider after Oct 2021
7192020-09-17T19:59:40 <jonatack> sgtm
7202020-09-17T19:59:41 <wumpus> maybe it should support the case where tor refuses to create a v2 service, to be future proof
7212020-09-17T19:59:59 <wumpus> e.g. not make that a fatal error
7222020-09-17T20:00:36 <sipa> is anything in torcontrol a fatal error?
7232020-09-17T20:00:37 <vasild> in 19954 we only ever try to create torv3 service
7242020-09-17T20:00:40 <jonatack> atm 19954 only rumours v3?
7252020-09-17T20:00:42 *** arowser has quit IRC
7262020-09-17T20:01:01 *** arowser has joined #bitcoin-core-dev
7272020-09-17T20:01:08 <wumpus> sipa: not for bitcoind entirely, but any error will stop it from going forward in torcontrol
7282020-09-17T20:01:26 <vasild> "atm 19954 only rumours v3?" - no, it would rumor (gossip) both torv2 and torv3
7292020-09-17T20:01:49 <wumpus> great!
7302020-09-17T20:02:15 <wumpus> #endmeeting
7312020-09-17T20:02:15 <lightningbot> Meeting ended Thu Sep 17 20:02:15 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
7322020-09-17T20:02:15 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-17-19.01.html
7332020-09-17T20:02:15 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-17-19.01.txt
7342020-09-17T20:02:15 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-09-17-19.01.log.html
7352020-09-17T20:02:18 <jonatack> right, but only v3 service not v2?
7362020-09-17T20:02:29 <vasild> 19954 is only about when bitcoin core creates a tor hidden service automatically via the tor control connection -- it would start creating torv3 with that PR
7372020-09-17T20:02:53 <jonatack> i certainly only see a v3 local address with 19954
7382020-09-17T20:03:00 <luke-jr> I prefer to add features, and remove others, in separate PRs ;)
7392020-09-17T20:03:10 <sipa> luke-jr: fwiw, perhaps i misunderstood your question earlier; the concept of the endomorphism optimization is easy to prove (it's a standard result in algebraic geometry) - so we know that if implemented correctly, it works
7402020-09-17T20:03:27 <luke-jr> sipa: great, that's what I meant
7412020-09-17T20:04:24 <jonatack> vasild: ok i'll look into what happens with the proxy and 19954
7422020-09-17T20:04:43 *** cltrbreak_MAD2 has quit IRC
7432020-09-17T20:04:49 <sipa> luke-jr: in slightly more detail, it's similar to how we know that -(x,y) = (x,-y) for elliptic curve points
7442020-09-17T20:05:10 <luke-jr> >implying I understand EC :p
7452020-09-17T20:05:25 <sipa> luke-jr: "negating a point negates the Y coordinate"
7462020-09-17T20:05:29 *** ctrlbreak has joined #bitcoin-core-dev
7472020-09-17T20:05:30 <sipa> does that sounds familiar?
7482020-09-17T20:05:33 <luke-jr> no
7492020-09-17T20:05:37 <sipa> ok!
7502020-09-17T20:06:16 <sipa> luke-jr: you know how compressed public keys consist of 0x02 or 0x03, followed by 32 bytes X coordinate?
7512020-09-17T20:06:29 <luke-jr> sure
7522020-09-17T20:07:19 <michaelfolkson> With my untrained eye Signet and Tor v3 both seem to be a rush to get in for October. What is the history of new features like that needing updates in minor versions because they weren't fully cooked for the major version they were part of?
7532020-09-17T20:07:29 <sipa> luke-jr: the 0x02 indicates whether the Y coordinate is odd or even; that works because for every point, a point with the same X coordinate but opposite Y coordinate exists (and modulo p, negating changes odd to even and the other way around)
7542020-09-17T20:08:04 <luke-jr> sipa: btw don't feel like you need to explain it to me - I'm sure if I read through gmax's educational material I'd understand
7552020-09-17T20:08:10 <sipa> ok
7562020-09-17T20:09:21 <luke-jr> michaelfolkson: for software in general, there's a general idea that .0 will have bugs :P
7572020-09-17T20:09:21 <michaelfolkson> Haven't seen any gmax educational material teaching EC. Any links?!
7582020-09-17T20:09:59 <michaelfolkson> Ok luke-jr. So it is kind of expected that Signet and Tor might need to be cleaned up in minor versions
7592020-09-17T20:10:02 <wumpus> michaelfolkson: it's often been done
7602020-09-17T20:10:41 <vasild> michaelfolkson: so far torv3 has been going very steadily (no rush so far)
7612020-09-17T20:10:51 <luke-jr> michaelfolkson: crap, I think I lost it
7622020-09-17T20:11:13 *** lightlike has quit IRC
7632020-09-17T20:11:21 <michaelfolkson> Yeah definitely not so far vasild. Just projecting forward
7642020-09-17T20:11:24 <vasild> that does not mean it is not going to be rushed from here :)
7652020-09-17T20:11:29 <wumpus> we've had much more rushed things in .0 major releases, signet and torv3 have been going on for a while and don't seem super hurried
7662020-09-17T20:12:01 <sipa> right, there is a difference between prioritizing and rushing
7672020-09-17T20:12:07 <wumpus> obviously I didn't mean "it needs to be in 0.21 at all costs", that's not how our releases work
7682020-09-17T20:12:11 <luke-jr> michaelfolkson: I think it was once under https://people.xiph.org/~greg/ which is now 404 :/
7692020-09-17T20:12:38 <michaelfolkson> Ah ok never mind. Thanks for looking luke-jr
7702020-09-17T20:12:48 *** S3RK has joined #bitcoin-core-dev
7712020-09-17T20:13:52 <michaelfolkson> And then to stir the pot, ideally we would have Signet in 0.21 to encourage Taproot testing on Signet?
7722020-09-17T20:13:54 <wumpus> signet is entirely opt-in, it's not that bad if it's still somewhat experimental, the important thing is that it doesn't break non-signet use
7732020-09-17T20:14:36 <michaelfolkson> No because it woulds still need to be a custom Signet for Taproot testing
7742020-09-17T20:14:54 <michaelfolkson> And the 0.21 release will be the default Signet (hopefully)
7752020-09-17T20:14:56 <sipa> taproot can be soft-forked into signet if the signers decide so
7762020-09-17T20:15:56 <wumpus> the Tor changes should definitely be correct in one go, it would be really bad to break Tor support, but we have a lot of interest and testing for that so I'm not too afraid
7772020-09-17T20:16:20 <michaelfolkson> Ok so (hopefully) Signet in 0.21 and then Taproot could be soft forked into Signet by the signers in a minor release or the next major Core release?
7782020-09-17T20:16:25 <sipa> kallewoof, aj: would it be useful to have different terms between signet (as in the bitcoind mode that enables signet configuration/rules) and signet (the default global testnet run by you two)
7792020-09-17T20:16:34 *** Aden_ has joined #bitcoin-core-dev
7802020-09-17T20:17:25 *** S3RK has quit IRC
7812020-09-17T20:17:48 <michaelfolkson> Soft forking Signet for Taproot testing should be a given. That obviously doesn't mean anything in terms of a final community decision on Taproot activation etc for mainnet
7822020-09-17T20:18:27 *** csslayer1 has quit IRC
7832020-09-17T20:19:30 *** Highway61 has joined #bitcoin-core-dev
7842020-09-17T20:19:44 <aj> sipa: "default signet", "custom signets" are the terms to distinguish the the one kallewoof and i sign from what anyone else might set up
7852020-09-17T20:20:11 <sipa> aj: that sounds embarassingly sane
7862020-09-17T20:20:53 <michaelfolkson> I think I proposed "main signet" lol
7872020-09-17T20:22:06 *** isis is now known as isis_
7882020-09-17T20:23:31 *** ctrlbreak_MAD has joined #bitcoin-core-dev
7892020-09-17T20:24:58 <michaelfolkson> What is your latest thinking on updating proposed soft forks for mainnet that are already on Signet aj? Still effective hard forks?
7902020-09-17T20:26:09 *** cltrbreak_MAD2 has joined #bitcoin-core-dev
7912020-09-17T20:26:38 *** ctrlbreak has quit IRC
7922020-09-17T20:29:52 *** jaybny has joined #bitcoin-core-dev
7932020-09-17T20:29:52 *** ctrlbreak_MAD has quit IRC
7942020-09-17T20:36:13 *** davidfischer has joined #bitcoin-core-dev
7952020-09-17T20:37:37 *** S3RK has joined #bitcoin-core-dev
7962020-09-17T20:37:40 <aj> michaelfolkson: updates to not-activated-on-testnet/mainnet or not-merged-to-master consensus changes might well be hard forks from vN to v(N+1) (or commit xxxxx^ to xxxxx), question is just how to deal with that
7972020-09-17T20:40:06 <aj> ryanofsky: "AJA" is precisely "2A" except calling it "LOCK_ALREADY_HELD" instead of "WeaklyAssertLock"
7982020-09-17T20:40:44 *** Guyver2 has quit IRC
7992020-09-17T20:42:02 *** S3RK has quit IRC
8002020-09-17T20:43:14 *** promag has quit IRC
8012020-09-17T20:44:13 <elichai2> luke-jr: fwiw I'm running with endomorphism for at least a year while updating each release and IBDing with assumevalid=0
8022020-09-17T20:44:39 *** kristapsk has joined #bitcoin-core-dev
8032020-09-17T20:45:44 *** promag has joined #bitcoin-core-dev
8042020-09-17T20:45:44 *** promag has quit IRC
8052020-09-17T20:46:02 <instagibbs> elichai2, "hello, policia?".gif
8062020-09-17T20:46:36 <instagibbs> what was the overall difference?
8072020-09-17T20:47:34 <elichai2> I didn't test the differences actually, but I think I got something like ~4 hours for full ibd with assumevalid=0 last time, I should retry without redownloading
8082020-09-17T20:48:00 <elichai2> But my point was about "is anyone using this" and "sync will fail if it's wrong" :)
8092020-09-17T20:48:25 <elichai2> Hehe yeah I'm sure they wanna sue me for patent infringement lol
8102020-09-17T20:50:05 *** guest534543 has quit IRC
8112020-09-17T20:50:21 *** jaybny has quit IRC
8122020-09-17T20:50:39 <elichai2> (about the topic, it might be a bit late but I personally would love to see those ifdefs on endo being removed :) I think it will even potentially increase the security of the code because of less preprocessor complexity and compile options)
8132020-09-17T20:57:37 * jonatack elichai2 hears an early-morning knock at the door
8142020-09-17T20:58:12 <jonatack> elichai2: pretty cool that you've been testing it. i wondered what that was, TIL
8152020-09-17T20:59:17 <elichai2> Yeah it's a great perf boost :)
8162020-09-17T21:00:02 *** davidfischer has quit IRC
8172020-09-17T21:00:04 <jonatack> my 4 cores of cpu will be happy about that
8182020-09-17T21:00:13 <instagibbs> IIRC the endomorphism was the inspiration for libsecp
8192020-09-17T21:00:37 <instagibbs> sipa tried it out then got rabbit holed
8202020-09-17T21:00:40 <sipa> instagibbs: yes, read meeting log from today :)
8212020-09-17T21:01:02 <elichai2> I'm also testing with libgmp although that will hopefully won't be needed anymore very soonð
8222020-09-17T21:06:55 *** belcher has joined #bitcoin-core-dev
8232020-09-17T21:07:51 *** promag has joined #bitcoin-core-dev
8242020-09-17T21:10:45 *** someone235 has joined #bitcoin-core-dev
8252020-09-17T21:12:11 *** rc_423 has joined #bitcoin-core-dev
8262020-09-17T21:15:19 *** ghjkhjkhjk has joined #bitcoin-core-dev
8272020-09-17T21:22:10 *** izaki has joined #bitcoin-core-dev
8282020-09-17T21:22:19 *** izaki is now known as Guest55194
8292020-09-17T21:22:22 *** Kiminuo has joined #bitcoin-core-dev
8302020-09-17T21:28:39 <jonatack> vasild: Ok now have the node advertising both torv2 and torv3 local addresses...just needed to set proxy=127.0.0.1:9050 rather than letting bitcoin core create a tor HS automatically, as you mentioned
8312020-09-17T21:29:37 <jonatack> (d'oh--and all good)
8322020-09-17T21:31:03 *** kristapsk has quit IRC
8332020-09-17T21:32:12 <jonatack> i'm fairly confident with respect to PR 19845. will move on to proper review of 19954.
8342020-09-17T21:34:51 *** Aden_ has quit IRC
8352020-09-17T21:35:49 *** luke-jr has quit IRC
8362020-09-17T21:36:13 *** luke-jr has joined #bitcoin-core-dev
8372020-09-17T21:36:55 *** rc_423 has quit IRC
8382020-09-17T21:37:22 *** rc_423 has joined #bitcoin-core-dev
8392020-09-17T21:38:23 *** kristapsk has joined #bitcoin-core-dev
8402020-09-17T21:47:55 *** mrostecki_ has quit IRC
8412020-09-17T22:04:56 *** rc_423 has quit IRC
8422020-09-17T22:05:21 *** rc_423 has joined #bitcoin-core-dev
8432020-09-17T22:10:23 *** vasild has quit IRC
8442020-09-17T22:11:54 *** vasild has joined #bitcoin-core-dev
8452020-09-17T22:12:59 *** davec has quit IRC
8462020-09-17T22:14:43 *** Bullitje has joined #bitcoin-core-dev
8472020-09-17T22:17:39 *** Bullitje_enable has quit IRC
8482020-09-17T22:25:19 *** davec has joined #bitcoin-core-dev
8492020-09-17T22:27:47 *** marcoagner has quit IRC
8502020-09-17T22:38:58 <aj> hm, would it be crazy to allow - and/or _ in config options the same way gmail allows . in addresses? ie just treat -signet-challenge and -signetchallenge (and -s-i-g-n-e-t-c-h-a-l-l-e-n-g-e) as aliases? i find squeezecase a pain to read
8512020-09-17T22:39:41 * sipa suggests: spaces
8522020-09-17T22:40:44 <sipa> ./src/bitcoind "-signet challenge=51"
8532020-09-17T22:41:11 <sipa> aj: we already allow - and -- for everything, i think
8542020-09-17T22:45:19 *** sr_gi has quit IRC
8552020-09-17T22:45:47 *** sr_gi has joined #bitcoin-core-dev
8562020-09-17T22:46:37 *** promag has quit IRC
8572020-09-17T22:48:19 <luke-jr> aj: might be exploitable
8582020-09-17T22:48:41 <luke-jr> "just run the Fun Draw Transaction RPC"
8592020-09-17T22:48:57 <luke-jr> (not command line, but there may be comparable cases now or in the future)
8602020-09-17T22:49:18 <sipa> -fun roll loops
8612020-09-17T22:50:10 *** Highway62 has joined #bitcoin-core-dev
8622020-09-17T22:52:25 *** Highway61 has quit IRC
8632020-09-17T22:52:26 *** Highway62 is now known as Highway61
8642020-09-17T22:53:44 <aj> luke-jr: you could do that exploit already
8652020-09-17T22:54:20 <luke-jr> ?
8662020-09-17T22:54:36 <luke-jr> oh, maybe, but it's a lot more problematic if you make it explicitly innocent
8672020-09-17T22:54:39 <aj> luke-jr: "just run the Fun Draw Transaction RPC -fundrawtransaction"
8682020-09-17T22:54:58 <luke-jr> -fun-draw-transaction is a lot more dangerous than -fundrawtransaction IMO
8692020-09-17T22:57:58 *** promag has joined #bitcoin-core-dev
8702020-09-17T23:06:04 *** davec has quit IRC
8712020-09-17T23:08:25 *** davec has joined #bitcoin-core-dev
8722020-09-17T23:39:09 *** mdunnio has quit IRC