12020-10-15T00:00:02  *** ermau has quit IRC
   22020-10-15T00:00:17  *** DeanGuss has quit IRC
   32020-10-15T00:00:28  *** bitcoin-git has joined #bitcoin-core-dev
   42020-10-15T00:00:28  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c2c4dbaebd95...661fe5d65cc6
   52020-10-15T00:00:29  <bitcoin-git> bitcoin/master fa1f6f2 MarcoFalke: net: Send post-verack handshake messages at most once
   62020-10-15T00:00:29  <bitcoin-git> bitcoin/master 661fe5d fanquake: Merge #20146: net: Send post-verack handshake messages at most once
   72020-10-15T00:00:31  *** bitcoin-git has left #bitcoin-core-dev
   82020-10-15T00:00:45  *** bitcoin-git has joined #bitcoin-core-dev
   92020-10-15T00:00:45  <bitcoin-git> [bitcoin] fanquake merged pull request #20146: net: Send post-verack handshake messages at most once (master...2010-netPostVerackHandshake) https://github.com/bitcoin/bitcoin/pull/20146
  102020-10-15T00:00:46  *** bitcoin-git has left #bitcoin-core-dev
  112020-10-15T00:03:56  *** proofofkeags has quit IRC
  122020-10-15T00:05:34  *** DeanGuss has joined #bitcoin-core-dev
  132020-10-15T00:15:22  *** murray_ has left #bitcoin-core-dev
  142020-10-15T00:15:48  *** murrayn has joined #bitcoin-core-dev
  152020-10-15T00:17:08  *** AaronvanW has joined #bitcoin-core-dev
  162020-10-15T00:22:09  *** zyga has joined #bitcoin-core-dev
  172020-10-15T00:23:14  *** promag has quit IRC
  182020-10-15T00:23:26  *** promag has joined #bitcoin-core-dev
  192020-10-15T00:39:16  *** S3RK has joined #bitcoin-core-dev
  202020-10-15T00:39:44  *** molz_ has quit IRC
  212020-10-15T00:41:00  *** gleb has quit IRC
  222020-10-15T00:43:25  *** S3RK has quit IRC
  232020-10-15T00:44:18  *** gleb has joined #bitcoin-core-dev
  242020-10-15T00:44:53  *** promag has quit IRC
  252020-10-15T00:45:29  *** promag has joined #bitcoin-core-dev
  262020-10-15T00:49:25  *** AaronvanW has quit IRC
  272020-10-15T00:53:09  *** mol has joined #bitcoin-core-dev
  282020-10-15T01:07:59  *** S3RK has joined #bitcoin-core-dev
  292020-10-15T01:11:25  *** mol_ has joined #bitcoin-core-dev
  302020-10-15T01:15:13  *** mol has quit IRC
  312020-10-15T01:19:28  *** S3RK has quit IRC
  322020-10-15T01:22:22  *** bitcoin-git has joined #bitcoin-core-dev
  332020-10-15T01:22:22  <bitcoin-git> [bitcoin] fanquake opened pull request #20150: [0.19] Backports (0.19...more_019_backports) https://github.com/bitcoin/bitcoin/pull/20150
  342020-10-15T01:22:23  *** bitcoin-git has left #bitcoin-core-dev
  352020-10-15T01:23:36  *** mol_ has quit IRC
  362020-10-15T01:30:02  *** sipsorcery has quit IRC
  372020-10-15T01:34:23  *** DeanGuss has quit IRC
  382020-10-15T01:41:20  *** mol has joined #bitcoin-core-dev
  392020-10-15T01:43:26  *** justanotheruser has quit IRC
  402020-10-15T01:45:02  *** Eagle[TM] has joined #bitcoin-core-dev
  412020-10-15T01:47:00  *** EagleTM has quit IRC
  422020-10-15T02:03:10  *** Livestradamus has quit IRC
  432020-10-15T02:03:26  *** IPGlider has quit IRC
  442020-10-15T02:15:39  *** IPGlider has joined #bitcoin-core-dev
  452020-10-15T02:19:10  *** DeanGuss has joined #bitcoin-core-dev
  462020-10-15T02:27:06  *** Livestradamus has joined #bitcoin-core-dev
  472020-10-15T02:32:44  *** andreacab has joined #bitcoin-core-dev
  482020-10-15T02:37:03  *** andreacab has quit IRC
  492020-10-15T02:37:05  *** glozow has quit IRC
  502020-10-15T02:41:49  *** da39a3ee5e6b4b0d has quit IRC
  512020-10-15T02:45:42  *** troygiorshev has quit IRC
  522020-10-15T02:46:30  *** troygiorshev has joined #bitcoin-core-dev
  532020-10-15T02:46:47  *** AaronvanW has joined #bitcoin-core-dev
  542020-10-15T02:50:17  *** da39a3ee5e6b4b0d has joined #bitcoin-core-dev
  552020-10-15T02:55:04  *** da39a3ee5e6b4b0d has quit IRC
  562020-10-15T03:00:01  *** zyga has quit IRC
  572020-10-15T03:16:00  <fanquake> ☃️ feature freeze day ☃️
  582020-10-15T03:17:14  <sipa> NOT YET
  592020-10-15T03:18:57  <aj> sipa: it's thursday even in Honolulu, so i think fanquake is right
  602020-10-15T03:19:32  <fanquake> meshcollider will surely tell us it's nearly over
  612020-10-15T03:19:34  *** AaronvanW has quit IRC
  622020-10-15T03:22:07  <meshcollider> T minus 7hours
  632020-10-15T03:22:15  <meshcollider> It's not over til I merge sqlite wallets!
  642020-10-15T03:22:25  *** mol has quit IRC
  652020-10-15T03:22:28  <meshcollider> And don't take that satisfaction away from me ;)
  662020-10-15T03:23:52  <fanquake> heh. As long as you don't merge it in the next few minutes  💥
  672020-10-15T03:24:17  <meshcollider> Nah don't worry I don't have my key with me, it'll be a few hours til I'm home
  682020-10-15T03:24:59  <meshcollider> I could just click the github "Merge" button and break everything though...
  692020-10-15T03:25:23  <fanquake> 🤙 I'm about to rip out some non-endomorphison
  702020-10-15T03:25:46  <meshcollider> 🎉
  712020-10-15T03:26:24  <fanquake> Gotta love patents on multiplication
  722020-10-15T03:29:15  *** bitcoin-git has joined #bitcoin-core-dev
  732020-10-15T03:29:16  <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/661fe5d65cc6...f2e6d1443013
  742020-10-15T03:29:17  <bitcoin-git> bitcoin/master 52380bf Pieter Wuille: Squashed 'src/secp256k1/' changes from 8ab24e8dad..c6b6b8f1bb
  752020-10-15T03:29:18  <bitcoin-git> bitcoin/master 9e5626d Pieter Wuille: Update libsecp256k1 subtree to latest master
  762020-10-15T03:29:19  <bitcoin-git> bitcoin/master f2e6d14 fanquake: Merge #20147: Update libsecp256k1 (endomorphism, test improvements)
  772020-10-15T03:29:20  *** bitcoin-git has left #bitcoin-core-dev
  782020-10-15T03:29:35  *** bitcoin-git has joined #bitcoin-core-dev
  792020-10-15T03:29:36  <bitcoin-git> [bitcoin] fanquake merged pull request #20147: Update libsecp256k1 (endomorphism, test improvements) (master...202010_secp256k1) https://github.com/bitcoin/bitcoin/pull/20147
  802020-10-15T03:29:36  *** mol has joined #bitcoin-core-dev
  812020-10-15T03:29:37  *** bitcoin-git has left #bitcoin-core-dev
  822020-10-15T03:30:24  <sipa> \o/
  832020-10-15T03:48:13  *** promag has quit IRC
  842020-10-15T03:48:30  *** promag has joined #bitcoin-core-dev
  852020-10-15T03:53:10  *** promag has quit IRC
  862020-10-15T03:53:45  *** promag has joined #bitcoin-core-dev
  872020-10-15T03:55:20  *** ferringb has joined #bitcoin-core-dev
  882020-10-15T04:01:16  *** S3RK has joined #bitcoin-core-dev
  892020-10-15T04:10:13  *** balbirs has quit IRC
  902020-10-15T04:10:45  *** balbirs has joined #bitcoin-core-dev
  912020-10-15T04:14:15  *** sr_gi has quit IRC
  922020-10-15T04:14:45  *** sr_gi has joined #bitcoin-core-dev
  932020-10-15T04:18:53  <meshcollider> \o/
  942020-10-15T04:32:09  *** dermoth_ has joined #bitcoin-core-dev
  952020-10-15T04:32:28  *** dermoth has quit IRC
  962020-10-15T04:32:30  *** dermoth_ is now known as dermoth
  972020-10-15T04:38:03  *** mol_ has joined #bitcoin-core-dev
  982020-10-15T04:42:13  *** mol has quit IRC
  992020-10-15T04:44:11  *** flag has quit IRC
 1002020-10-15T04:50:55  *** flag has joined #bitcoin-core-dev
 1012020-10-15T04:55:46  *** rc_423_ has joined #bitcoin-core-dev
 1022020-10-15T04:56:05  *** rc_423 has quit IRC
 1032020-10-15T05:16:26  *** AaronvanW has joined #bitcoin-core-dev
 1042020-10-15T05:21:46  *** mol has joined #bitcoin-core-dev
 1052020-10-15T05:22:03  *** mol_ has quit IRC
 1062020-10-15T05:50:04  *** AaronvanW has quit IRC
 1072020-10-15T05:56:38  *** S3RK has quit IRC
 1082020-10-15T05:56:55  *** DeanGuss has quit IRC
 1092020-10-15T05:57:10  *** S3RK has joined #bitcoin-core-dev
 1102020-10-15T05:57:12  *** DeanGuss has joined #bitcoin-core-dev
 1112020-10-15T06:00:02  *** ferringb has quit IRC
 1122020-10-15T06:02:55  *** S3RK has quit IRC
 1132020-10-15T06:22:48  *** larsivi has joined #bitcoin-core-dev
 1142020-10-15T06:26:01  *** Pavlenex has joined #bitcoin-core-dev
 1152020-10-15T06:30:39  *** justanotheruser has joined #bitcoin-core-dev
 1162020-10-15T06:34:38  *** andreacab has joined #bitcoin-core-dev
 1172020-10-15T06:38:54  *** andreacab has quit IRC
 1182020-10-15T06:46:34  *** andreacab has joined #bitcoin-core-dev
 1192020-10-15T06:49:16  *** mrostecki has joined #bitcoin-core-dev
 1202020-10-15T06:59:15  *** promag has quit IRC
 1212020-10-15T06:59:29  *** promag has joined #bitcoin-core-dev
 1222020-10-15T07:02:57  *** mrostecki has quit IRC
 1232020-10-15T07:11:27  *** mrostecki has joined #bitcoin-core-dev
 1242020-10-15T07:11:35  *** promag has quit IRC
 1252020-10-15T07:12:10  *** promag has joined #bitcoin-core-dev
 1262020-10-15T07:13:19  *** bitcoin-git has joined #bitcoin-core-dev
 1272020-10-15T07:13:19  <bitcoin-git> [bitcoin] meshcollider pushed 27 commits to master: https://github.com/bitcoin/bitcoin/compare/f2e6d1443013...8ed37f6c8497
 1282020-10-15T07:13:20  <bitcoin-git> bitcoin/master 54729f3 Andrew Chow: Add libsqlite3
 1292020-10-15T07:13:20  <bitcoin-git> bitcoin/master e87df82 Andrew Chow: Add sqlite to travis and depends
 1302020-10-15T07:13:21  <bitcoin-git> bitcoin/master 7577b6e Andrew Chow: Add SQLiteDatabase and SQLiteBatch dummy classes
 1312020-10-15T07:13:22  *** bitcoin-git has left #bitcoin-core-dev
 1322020-10-15T07:14:14  *** bitcoin-git has joined #bitcoin-core-dev
 1332020-10-15T07:14:14  <bitcoin-git> [bitcoin] meshcollider merged pull request #19077: wallet: Add sqlite as an alternative wallet database and use it for new descriptor wallets (master...sqlite-wallet) https://github.com/bitcoin/bitcoin/pull/19077
 1342020-10-15T07:14:15  *** bitcoin-git has left #bitcoin-core-dev
 1352020-10-15T07:14:23  <aj> \o/
 1362020-10-15T07:14:35  *** Ga1aCt1Cz00 has joined #bitcoin-core-dev
 1372020-10-15T07:15:13  *** jesseposner has quit IRC
 1382020-10-15T07:15:30  <meshcollider> achow101: 🥳
 1392020-10-15T07:16:53  *** Ga1aCt1Cz00_ has quit IRC
 1402020-10-15T07:45:49  *** vincenzopalazzo has joined #bitcoin-core-dev
 1412020-10-15T07:46:40  *** jesseposner has joined #bitcoin-core-dev
 1422020-10-15T07:47:03  *** AaronvanW has joined #bitcoin-core-dev
 1432020-10-15T07:48:54  *** andreacab has quit IRC
 1442020-10-15T07:56:20  *** promag has quit IRC
 1452020-10-15T07:57:13  *** promag has joined #bitcoin-core-dev
 1462020-10-15T07:57:50  *** jouke has joined #bitcoin-core-dev
 1472020-10-15T08:03:36  *** S3RK has joined #bitcoin-core-dev
 1482020-10-15T08:07:36  *** S3RK has quit IRC
 1492020-10-15T08:08:05  *** S3RK has joined #bitcoin-core-dev
 1502020-10-15T08:13:23  *** Guyver2 has joined #bitcoin-core-dev
 1512020-10-15T08:19:25  *** AaronvanW has quit IRC
 1522020-10-15T08:23:19  *** bitcoin-git has joined #bitcoin-core-dev
 1532020-10-15T08:23:19  <bitcoin-git> [bitcoin] laanwj pushed 20 commits to master: https://github.com/bitcoin/bitcoin/compare/8ed37f6c8497...3caee1694657
 1542020-10-15T08:23:20  <bitcoin-git> bitcoin/master f8c099e Pieter Wuille: --- [TAPROOT] Refactors ---
 1552020-10-15T08:23:21  <bitcoin-git> bitcoin/master 107b57d Pieter Wuille: scripted-diff: put ECDSA in name of signature functions
 1562020-10-15T08:23:21  <bitcoin-git> bitcoin/master 8bd2b4e Pieter Wuille: refactor: rename scriptPubKey in VerifyWitnessProgram to exec_script
 1572020-10-15T08:23:23  *** bitcoin-git has left #bitcoin-core-dev
 1582020-10-15T08:23:38  *** bitcoin-git has joined #bitcoin-core-dev
 1592020-10-15T08:23:38  <bitcoin-git> [bitcoin] laanwj merged pull request #19953: Implement BIP 340-342 validation (Schnorr/taproot/tapscript) (master...taproot) https://github.com/bitcoin/bitcoin/pull/19953
 1602020-10-15T08:23:40  *** bitcoin-git has left #bitcoin-core-dev
 1612020-10-15T08:24:08  <sipa> \\\o///
 1622020-10-15T08:25:06  <jonatack> boom \o/
 1632020-10-15T08:30:29  <wumpus> \o/
 1642020-10-15T08:30:57  * sipa does the tapdance
 1652020-10-15T08:31:01  *** AaronvanW has joined #bitcoin-core-dev
 1662020-10-15T08:31:06  <sipa> actually wait no, i can't dance
 1672020-10-15T08:31:11  *** sdaftuar has quit IRC
 1682020-10-15T08:31:36  *** sdaftuar has joined #bitcoin-core-dev
 1692020-10-15T08:35:11  <wumpus> (don't let it being merged stop you from reviewing further if you were still in progress)
 1702020-10-15T08:35:14  * wumpus neither
 1712020-10-15T08:37:01  *** bitcoin-git has joined #bitcoin-core-dev
 1722020-10-15T08:37:01  <bitcoin-git> [bitcoin] hebasto opened pull request #20152: doc: Update wallet files in files.md (master...201015-sqlite) https://github.com/bitcoin/bitcoin/pull/20152
 1732020-10-15T08:37:02  *** bitcoin-git has left #bitcoin-core-dev
 1742020-10-15T08:37:21  *** da39a3ee5e6b4b0d has joined #bitcoin-core-dev
 1752020-10-15T08:42:25  <sipa> what is the meeting topic command?
 1762020-10-15T08:42:44  *** jonatack has quit IRC
 1772020-10-15T08:43:06  <MarcoFalke> #proposedmeetingtopic
 1782020-10-15T08:43:26  <MarcoFalke> Is there anything left to discuss, now that everything is merged?
 1792020-10-15T08:44:19  <sipa> #proposedmeetingtopic taproot relay policy / activation on testnet/signet
 1802020-10-15T08:47:01  *** jeremyrubin has quit IRC
 1812020-10-15T08:47:14  <wumpus> also wanted to get it merged so that other pre-0.21 PRs don't make it require rebase
 1822020-10-15T08:47:26  <wumpus> with that many ACKs
 1832020-10-15T08:51:53  *** Pavlenex has quit IRC
 1842020-10-15T08:52:43  *** Pavlenex has joined #bitcoin-core-dev
 1852020-10-15T08:53:53  <MarcoFalke> Makes sense, and as the code is not active yet, it can still be changed freely
 1862020-10-15T08:56:41  *** bitcoin-git has joined #bitcoin-core-dev
 1872020-10-15T08:56:42  <bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/3caee1694657...3956165903cf
 1882020-10-15T08:56:42  <bitcoin-git> bitcoin/master 6020ce3 Gregory Sanders: DecodeHexTx: Try case where txn has inputs first
 1892020-10-15T08:56:43  <bitcoin-git> bitcoin/master 27fc6a3 Gregory Sanders: DecodeHexTx: Break out transaction decoding logic into own function
 1902020-10-15T08:56:43  <bitcoin-git> bitcoin/master 3956165 Wladimir J. van der Laan: Merge #17775: DecodeHexTx: Try case where txn has inputs first
 1912020-10-15T08:56:45  *** bitcoin-git has left #bitcoin-core-dev
 1922020-10-15T08:58:11  *** bitcoin-git has joined #bitcoin-core-dev
 1932020-10-15T08:58:11  <bitcoin-git> [bitcoin] laanwj merged pull request #17775: DecodeHexTx: Try case where txn has inputs first (master...decode_wit_first) https://github.com/bitcoin/bitcoin/pull/17775
 1942020-10-15T08:58:12  *** bitcoin-git has left #bitcoin-core-dev
 1952020-10-15T09:00:02  *** larsivi has quit IRC
 1962020-10-15T09:07:45  *** jesseposner has quit IRC
 1972020-10-15T09:10:13  <kallewoof> Won't be at meeting but my 2 sats on signet and taproot activation: I don't think there's a reason to delay activation. My suggestion is to set activation for a week or so from now (long enough for a trivial pull request to get ACKs and be merged + to update the servers issuing blocks). I guess the question is whether this is affected by feature freeze or not. If it is, I suggest we activate it after 0.21 branch split in
 1982020-10-15T09:10:14  <kallewoof> master only.
 1992020-10-15T09:11:29  <kallewoof> If people want to try out the actual real taproot activation mechanism for activation on signet, the story changes I guess.
 2002020-10-15T09:12:10  <sipa> kallewoof: the nice thing about signet is that really consensus rules are decided by the signers - even if the rest of the network doesn't enforce
 2012020-10-15T09:12:49  *** belcher has quit IRC
 2022020-10-15T09:13:16  <sipa> the reason i brought it up is that i realize that master will now relay (valid) taproot spends... which may be unexpected, and feels wrong without activation plan
 2032020-10-15T09:13:37  <kallewoof> sipa: yeah, but p2p layer is affected... propagation can be delayed or fail unless one peer is a miner
 2042020-10-15T09:14:13  <kallewoof> sipa: in pre-activation? i thought it policy-rejected
 2052020-10-15T09:14:19  <sipa> kallewoof: no
 2062020-10-15T09:15:01  <sipa> i think segwit had special rules about relay before activation, because it was also a p2p change
 2072020-10-15T09:15:18  <kallewoof> ohh! i didn't realize that.
 2082020-10-15T09:15:22  <aj> sipa: (if the network enforces rules prior to "real" activation, and there's a hard-fork, you need more than just signers to fix things up)
 2092020-10-15T09:15:46  <aj> sipa: (probably no need for hard-forks in the taproot implementation now though so, whatevs)
 2102020-10-15T09:15:52  *** S3RK has quit IRC
 2112020-10-15T09:16:03  *** S3RK has joined #bitcoin-core-dev
 2122020-10-15T09:17:42  <sipa> the last softfork before that, CSV, was implemented & activated in the same release, 0.12.1
 2132020-10-15T09:18:28  <sipa> but i think we should disable relay for networks which have no activation defined (i.e., all but regtest and maybe signet)
 2142020-10-15T09:20:16  <kallewoof> sipa: my vote is to keep it enabled on signet, as that means we can just flip it on whenever and it will just work™️
 2152020-10-15T09:21:32  *** belcher has joined #bitcoin-core-dev
 2162020-10-15T09:22:37  *** jonatack has joined #bitcoin-core-dev
 2172020-10-15T09:27:43  *** bitcoin-git has joined #bitcoin-core-dev
 2182020-10-15T09:27:43  <bitcoin-git> [bitcoin] jonatack closed pull request #19874: cli, bugfix: degrade -getinfo gracefully for older servers (master...getinfo-handle-older-servers-gracefully) https://github.com/bitcoin/bitcoin/pull/19874
 2192020-10-15T09:27:44  *** bitcoin-git has left #bitcoin-core-dev
 2202020-10-15T09:28:03  *** bitcoin-git has joined #bitcoin-core-dev
 2212020-10-15T09:28:03  <bitcoin-git> [bitcoin] jonatack reopened pull request #19874: cli, bugfix: degrade -getinfo gracefully for older servers (master...getinfo-handle-older-servers-gracefully) https://github.com/bitcoin/bitcoin/pull/19874
 2222020-10-15T09:28:04  *** bitcoin-git has left #bitcoin-core-dev
 2232020-10-15T09:28:52  <kallewoof> I get the sneaky suspicion that enum class with bit fiddling is... not the way to go. Tempted to just do const uint8_t's and skip the enum part altogether..
 2242020-10-15T09:30:27  *** bitcoin-git has joined #bitcoin-core-dev
 2252020-10-15T09:30:27  <bitcoin-git> [bitcoin] sipa closed pull request #19997: History for Taproot PR #19953 (master...taproot-history) https://github.com/bitcoin/bitcoin/pull/19997
 2262020-10-15T09:30:28  *** bitcoin-git has left #bitcoin-core-dev
 2272020-10-15T09:32:29  *** Pavlenex has quit IRC
 2282020-10-15T09:33:37  *** S3RK has quit IRC
 2292020-10-15T09:33:56  *** AaronvanW has quit IRC
 2302020-10-15T09:37:37  *** Pavlenex has joined #bitcoin-core-dev
 2312020-10-15T09:38:16  *** jonatack has quit IRC
 2322020-10-15T09:38:58  *** da39a3ee5e6b4b0d has quit IRC
 2332020-10-15T09:40:39  *** jonatack has joined #bitcoin-core-dev
 2342020-10-15T09:43:46  *** mol_ has joined #bitcoin-core-dev
 2352020-10-15T09:45:02  *** bitcoin-git has joined #bitcoin-core-dev
 2362020-10-15T09:45:03  <bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/3956165903cf...e3b474c54866
 2372020-10-15T09:45:03  <bitcoin-git> bitcoin/master 883cea7 Pieter Wuille: Restore compatibility with old CSubNet serialization
 2382020-10-15T09:45:04  <bitcoin-git> bitcoin/master 886be97 Pieter Wuille: Ignore incorrectly-serialized banlist.dat entries
 2392020-10-15T09:45:04  <bitcoin-git> bitcoin/master e3b474c Wladimir J. van der Laan: Merge #20140: Restore compatibility with old CSubNet serialization
 2402020-10-15T09:45:05  *** justanotheruser has quit IRC
 2412020-10-15T09:45:06  *** bitcoin-git has left #bitcoin-core-dev
 2422020-10-15T09:45:22  *** bitcoin-git has joined #bitcoin-core-dev
 2432020-10-15T09:45:22  <bitcoin-git> [bitcoin] laanwj merged pull request #20140: Restore compatibility with old CSubNet serialization (master...202010_subnet_ser_compact) https://github.com/bitcoin/bitcoin/pull/20140
 2442020-10-15T09:45:23  *** bitcoin-git has left #bitcoin-core-dev
 2452020-10-15T09:46:56  *** mol has quit IRC
 2462020-10-15T09:47:32  *** Pavlenex has quit IRC
 2472020-10-15T09:47:45  *** jonatack has quit IRC
 2482020-10-15T09:50:03  *** jonatack has joined #bitcoin-core-dev
 2492020-10-15T09:51:56  *** bitcoin-git has joined #bitcoin-core-dev
 2502020-10-15T09:51:56  <bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/e3b474c54866...560dea9b26f7
 2512020-10-15T09:51:57  <bitcoin-git> bitcoin/master d681a28 Luke Dashjr: RPC: getpeerinfo: Deprecate "whitelisted" field (replaced by "permissions")
 2522020-10-15T09:51:57  <bitcoin-git> bitcoin/master 5b57dc5 Luke Dashjr: RPC: getpeerinfo: Wrap long help line for bytesrecv_per_msg
 2532020-10-15T09:51:58  <bitcoin-git> bitcoin/master 560dea9 MarcoFalke: Merge #19770: RPC: getpeerinfo: Deprecate "whitelisted" field (replaced by...
 2542020-10-15T09:51:59  *** bitcoin-git has left #bitcoin-core-dev
 2552020-10-15T09:52:26  *** bitcoin-git has joined #bitcoin-core-dev
 2562020-10-15T09:52:26  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #19770: RPC: getpeerinfo: Deprecate "whitelisted" field (replaced by "permissions") (master...deprecate_whitelisted) https://github.com/bitcoin/bitcoin/pull/19770
 2572020-10-15T09:52:27  *** bitcoin-git has left #bitcoin-core-dev
 2582020-10-15T09:56:03  *** BjarniRunar1 has joined #bitcoin-core-dev
 2592020-10-15T09:58:48  *** S3RK has joined #bitcoin-core-dev
 2602020-10-15T10:01:42  *** bitcoin-git has joined #bitcoin-core-dev
 2612020-10-15T10:01:43  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/560dea9b26f7...711ddce94377
 2622020-10-15T10:01:43  <bitcoin-git> bitcoin/master faad92f MarcoFalke: test: Remove unused nVersion=1 in p2p tests
 2632020-10-15T10:01:44  <bitcoin-git> bitcoin/master 711ddce Wladimir J. van der Laan: Merge #20131: test: Remove unused nVersion=1 in p2p tests
 2642020-10-15T10:01:46  *** bitcoin-git has left #bitcoin-core-dev
 2652020-10-15T10:02:02  *** bitcoin-git has joined #bitcoin-core-dev
 2662020-10-15T10:02:02  <bitcoin-git> [bitcoin] laanwj merged pull request #20131: test: Remove unused nVersion=1 in p2p tests (master...2010-testnVersion) https://github.com/bitcoin/bitcoin/pull/20131
 2672020-10-15T10:02:03  *** bitcoin-git has left #bitcoin-core-dev
 2682020-10-15T10:10:23  *** vasild has quit IRC
 2692020-10-15T10:12:23  *** vasild has joined #bitcoin-core-dev
 2702020-10-15T10:14:23  *** shesek has quit IRC
 2712020-10-15T10:18:33  *** Coralie12Moscisk has joined #bitcoin-core-dev
 2722020-10-15T10:23:50  *** jonatack has quit IRC
 2732020-10-15T10:23:56  *** S3RK has quit IRC
 2742020-10-15T10:24:29  *** S3RK has joined #bitcoin-core-dev
 2752020-10-15T10:25:56  *** jonatack has joined #bitcoin-core-dev
 2762020-10-15T10:27:57  *** AaronvanW has joined #bitcoin-core-dev
 2772020-10-15T10:28:24  *** csknk has joined #bitcoin-core-dev
 2782020-10-15T11:31:23  *** lightningbot has joined #bitcoin-core-dev
 2792020-10-15T11:32:32  *** tralfaz has joined #bitcoin-core-dev
 2802020-10-15T11:32:37  *** DeanGuss has quit IRC
 2812020-10-15T11:32:37  *** davterra has quit IRC
 2822020-10-15T11:32:49  *** DeanGuss has joined #bitcoin-core-dev
 2832020-10-15T11:33:35  *** S3RK has quit IRC
 2842020-10-15T11:34:03  *** S3RK has joined #bitcoin-core-dev
 2852020-10-15T11:35:38  *** Ga1aCt1Cz00_ has joined #bitcoin-core-dev
 2862020-10-15T11:35:55  *** Ga1aCt1Cz00 has quit IRC
 2872020-10-15T11:37:53  *** Eagle[TM] has quit IRC
 2882020-10-15T11:38:11  *** EagleTM has joined #bitcoin-core-dev
 2892020-10-15T11:42:04  *** Ga1aCt1Cz00 has joined #bitcoin-core-dev
 2902020-10-15T11:42:15  *** Ga1aCt1Cz00_ has quit IRC
 2912020-10-15T11:54:56  *** Ga1aCt1Cz00_ has joined #bitcoin-core-dev
 2922020-10-15T11:55:33  *** Ga1aCt1Cz00 has quit IRC
 2932020-10-15T11:59:59  *** Ga1aCt1Cz00_ has quit IRC
 2942020-10-15T12:00:01  *** BjarniRunar1 has quit IRC
 2952020-10-15T12:04:07  *** kristapsk___ has joined #bitcoin-core-dev
 2962020-10-15T12:04:31  *** kristapsk_ has quit IRC
 2972020-10-15T12:08:48  *** Ga1aCt1Cz00 has joined #bitcoin-core-dev
 2982020-10-15T12:22:30  *** kerbyu has joined #bitcoin-core-dev
 2992020-10-15T12:33:07  <jamesob> wow, big merge day. congrats sipa, achow101!
 3002020-10-15T12:35:25  <elichai2> 🥳🥳🥳🥳
 3012020-10-15T12:38:22  *** Ga1aCt1Cz00_ has joined #bitcoin-core-dev
 3022020-10-15T12:39:53  *** Ga1aCt1Cz00 has quit IRC
 3032020-10-15T12:46:35  *** AaronvanW has joined #bitcoin-core-dev
 3042020-10-15T12:49:27  *** bitcoin-git has joined #bitcoin-core-dev
 3052020-10-15T12:49:27  <bitcoin-git> [bitcoin] kallewoof opened pull request #20154: BIP-322 support (master...202010-bip322) https://github.com/bitcoin/bitcoin/pull/20154
 3062020-10-15T12:49:28  *** bitcoin-git has left #bitcoin-core-dev
 3072020-10-15T12:50:22  <kallewoof> andytoshi: hope you didn't spend too much time on your implementation. I have begun working on a rough implementation of BIP 322 support here, FYI: https://github.com/bitcoin/bitcoin/pull/20154
 3082020-10-15T12:52:07  *** willcl_ark is now known as [github-bot]
 3092020-10-15T12:53:15  <hebasto> is #20120 rtm?
 3102020-10-15T12:53:17  <gribble> https://github.com/bitcoin/bitcoin/issues/20120 | net, rpc, test, bugfix: update GetNetworkName, GetNetworksInfo, regression tests by jonatack · Pull Request #20120 · bitcoin/bitcoin · GitHub
 3112020-10-15T12:54:59  <andytoshi> kallewoof: no, i spent about 30 minutes on it :) the old spec was super straightforward (at least, with the existing rust-bitcoin/miniscript infrastructure i have)
 3122020-10-15T12:55:16  <andytoshi> the new spec is bigger but i think will integrate much better with my descriptors library
 3132020-10-15T12:55:30  *** molz_ has joined #bitcoin-core-dev
 3142020-10-15T12:56:00  <kallewoof> andytoshi: it seems to integrate really well with bitcoin core, from what i can tell so far. the old code was a split out thing of its own
 3152020-10-15T12:56:22  <kallewoof> andytoshi: cool to hear you're working on it. feedback and such super welcome :)
 3162020-10-15T12:57:06  *** molz_ has quit IRC
 3172020-10-15T12:57:16  <andytoshi> right, that's also what was going to happen with the rust-miniscript implementation ... de/serialization was easy but then providing a usable sign/verify API seemed pretty unnatural. i think this one will be better because i can write a function that takes a descriptor + message and converts it to a to_spend transaction
 3182020-10-15T12:57:25  *** molz_ has joined #bitcoin-core-dev
 3192020-10-15T12:57:36  <andytoshi> (and i guess now, will also take a value ... i'm curious why you changed this this morning...i don't have strong feelings either way, i just don't understand it)
 3202020-10-15T12:57:43  *** [github-bot] is now known as wilcl_ark
 3212020-10-15T12:58:45  *** mol_ has quit IRC
 3222020-10-15T13:00:34  <kallewoof> andytoshi: uh... i somehow thought the sum of amounts was required in the signature, but now that you mention it, i think i was confused..
 3232020-10-15T13:01:29  <kallewoof> andytoshi: I'll revert that one now. Thanks for pointing it out
 3242020-10-15T13:03:55  *** jonatack has joined #bitcoin-core-dev
 3252020-10-15T13:05:03  <andytoshi> cool :) the value made it a little harder, API-wise, because it means that you need to know upfront whether you're going to use the to_spend purely as a dummy input when proving funds, or not (and you have to konw how many funds you're planning to prove)
 3262020-10-15T13:05:18  <andytoshi> you sorta have to know this now, in choosing whether to use an OP_TRUE descriptor or a "real" one
 3272020-10-15T13:05:40  *** jesseposner has joined #bitcoin-core-dev
 3282020-10-15T13:06:12  <kallewoof> andytoshi: that makes sense -- yeah, i think i managed to convince myself that the signatures commit to the amounts, so we need to have those available and why not just stuff them in the virtual to_sign tx... but that's not how it works at all.
 3292020-10-15T13:06:58  <luke-jr> oh blah, sqlite isn't optional? :/
 3302020-10-15T13:07:25  *** Exho has joined #bitcoin-core-dev
 3312020-10-15T13:08:41  * MarcoFalke updates all build scripts to install sqlite-dev
 3322020-10-15T13:09:17  <MarcoFalke> This is probably the first time a dependecy has been added in years. Others were only removals.
 3332020-10-15T13:09:52  * luke-jr begins on a PR to fix it optional
 3342020-10-15T13:10:37  *** jesseposner has quit IRC
 3352020-10-15T13:18:44  * kallewoof calls it a day at "checker.CheckECDSASignature(vchSig, vchPubKey, scriptCode, sigversion)" returning false. :) Will compare sighashes tomorrow. Maybe I should've implemented this in btcdeb first.
 3362020-10-15T13:20:56  *** luke-jr has quit IRC
 3372020-10-15T13:21:18  *** luke-jr has joined #bitcoin-core-dev
 3382020-10-15T13:26:51  *** tralfaz is now known as davterra
 3392020-10-15T13:28:58  <andytoshi> kallewoof: sounds good, hopefully i'll have some test vectors in the next 6-8 hours we can compare
 3402020-10-15T13:29:28  <kallewoof> andytoshi: nice!
 3412020-10-15T13:29:44  *** harrigan has quit IRC
 3422020-10-15T13:30:26  *** kerbyu has quit IRC
 3432020-10-15T13:31:32  *** jonatack has quit IRC
 3442020-10-15T13:31:38  *** doomas has joined #bitcoin-core-dev
 3452020-10-15T13:31:39  *** harrigan has joined #bitcoin-core-dev
 3462020-10-15T13:33:00  *** shesek has joined #bitcoin-core-dev
 3472020-10-15T13:33:00  *** shesek has joined #bitcoin-core-dev
 3482020-10-15T13:33:34  *** mol has joined #bitcoin-core-dev
 3492020-10-15T13:36:03  *** molz_ has quit IRC
 3502020-10-15T13:38:55  *** jonatack has joined #bitcoin-core-dev
 3512020-10-15T13:45:51  *** kexkey has joined #bitcoin-core-dev
 3522020-10-15T13:45:52  *** glozow has joined #bitcoin-core-dev
 3532020-10-15T13:53:46  *** bitcoin-git has joined #bitcoin-core-dev
 3542020-10-15T13:53:46  <bitcoin-git> [bitcoin] luke-jr opened pull request #20156: Make sqlite support optional (compile-time) (master...opt_sqlite) https://github.com/bitcoin/bitcoin/pull/20156
 3552020-10-15T13:53:47  *** bitcoin-git has left #bitcoin-core-dev
 3562020-10-15T14:06:16  *** vincenzopalazzo has quit IRC
 3572020-10-15T14:11:32  *** DeanWeen has joined #bitcoin-core-dev
 3582020-10-15T14:12:46  *** DeanGuss has quit IRC
 3592020-10-15T14:16:14  *** promag has quit IRC
 3602020-10-15T14:16:18  <jamesob> anyone ever seen "/usr/bin/ld: error: [...]: <corrupt x86 property (0xc0000002) size: 0x8>" during compilation before? I'm getting a truckload of them, but compilation seems to succeed anyway. Think it has to do with having installed the debian gcc-9 package, but not sure. Google turns up nothing.
 3612020-10-15T14:16:30  *** promag has joined #bitcoin-core-dev
 3622020-10-15T14:16:44  *** davterra has quit IRC
 3632020-10-15T14:16:57  *** davterra has joined #bitcoin-core-dev
 3642020-10-15T14:18:03  <jamesob> s/compilation/link & ar time
 3652020-10-15T14:24:14  *** da39a3ee5e6b4b0d has joined #bitcoin-core-dev
 3662020-10-15T14:31:27  *** promag has quit IRC
 3672020-10-15T14:32:03  *** promag has joined #bitcoin-core-dev
 3682020-10-15T14:34:30  *** promag has quit IRC
 3692020-10-15T14:34:31  <yanmaani> jamesob: yeah, me too
 3702020-10-15T14:34:34  <yanmaani> what OS?
 3712020-10-15T14:34:43  *** promag has joined #bitcoin-core-dev
 3722020-10-15T14:34:59  <jamesob> Linux slug 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) x86_64 GNU/Linux
 3732020-10-15T14:35:00  <yanmaani> I use gcc 8.3.0 @ debian (devuan)
 3742020-10-15T14:35:02  <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
 3752020-10-15T14:35:19  <jamesob> I get it when compiling with gcc or clang; I think it's an issue with ld/ar
 3762020-10-15T14:35:50  <yanmaani> Linux hostname 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) x86_64 GNU/Linux
 3772020-10-15T14:35:52  <gribble> https://github.com/bitcoin/bitcoin/issues/1 | JSON-RPC support for mobile devices ("ultra-lightweight" clients) · Issue #1 · bitcoin/bitcoin · GitHub
 3782020-10-15T14:35:55  <promag> does it make sense to support multiple -blocksdir where one is rw but the others are ro? so that older blocks can be kept on a slower disk?
 3792020-10-15T14:36:13  <yanmaani> promag: you may be interested in overlayfs
 3802020-10-15T14:36:22  <yanmaani> or just some caching setup
 3812020-10-15T14:37:13  <luke-jr> promag: probably
 3822020-10-15T14:37:22  <promag> yanmaani: yes, I though about that, but then in instead of prunning it would move blocks the the other place
 3832020-10-15T14:37:28  <luke-jr> promag: needs some thought, though, as it also makes sense to move them automatically
 3842020-10-15T14:37:38  <promag> luke-jr: right
 3852020-10-15T14:37:59  <yanmaani> uh, how are you going to automatically move blocks to a RO fs?
 3862020-10-15T14:38:04  <luke-jr> FWIW Signet may be broken on master since it lacks Taproot activation params
 3872020-10-15T14:38:40  <promag> yanmaani: no, I mean RO as in bitcoind doesn't writes new blocks there
 3882020-10-15T14:38:44  <yanmaani> the simple solution is to have a cronjob that checks mtime/ctime and moves+symlinks them
 3892020-10-15T14:38:48  <yanmaani> oh, not a RO fs
 3902020-10-15T14:38:56  <yanmaani> just do overlayfs or something IMO
 3912020-10-15T14:39:04  <promag> not ro fs, "RO" -blocksdir
 3922020-10-15T14:40:04  <promag> yanmaani: I understand this can be overcome out of bitcoind, but the idea would be to add a -prunestrategy=archive for instance
 3932020-10-15T14:40:27  <luke-jr> yanmaani: for example, it can be an external drive you unplug when you leave home
 3942020-10-15T14:40:28  <promag> just a thought..
 3952020-10-15T14:41:01  <luke-jr> and blocks would just not prune-to-slow-storage while you're away from home
 3962020-10-15T14:41:05  <luke-jr> when you get back, then they move
 3972020-10-15T14:41:12  <yanmaani> luke-jr: But then you have a problem when you start bitcoind in such cases, no?
 3982020-10-15T14:41:17  <promag> luke-jr: exactly
 3992020-10-15T14:41:23  <luke-jr> and if you need to use (eg) a rescan RPC, you plug in the drive
 4002020-10-15T14:41:30  <promag> it can be copy first, then delete old
 4012020-10-15T14:41:31  <luke-jr> yanmaani: that's exactly what this would avoid
 4022020-10-15T14:42:01  <yanmaani> I guess if you have the DB, yeah. Couldn't it just ignore missing blocks until they're needed?
 4032020-10-15T14:42:13  <promag> yup
 4042020-10-15T14:42:14  <yanmaani> so you can do whatever you want and bitcoind will just deal with it
 4052020-10-15T14:42:24  <promag> this might interact with assumeutxo cc jamesob
 4062020-10-15T14:42:26  <yanmaani> instead of re-implementing overlayfs in bitcoin core
 4072020-10-15T14:43:08  <promag> yanmaani: overlayfs is cool if you dont care where each file is stored
 4082020-10-15T14:43:27  <promag> and it's platform dependant
 4092020-10-15T14:43:36  <yanmaani> you can move them around by yourself though
 4102020-10-15T14:43:45  <yanmaani> or just set a cronjob to move+symlink
 4112020-10-15T14:44:09  <promag> yes I could
 4122020-10-15T14:44:28  <promag> or have it automatic
 4132020-10-15T14:44:34  <jamesob> promag: should be compatible with assumeutxo since blocksdir access is largely unchanged; blocks have always come out of order anyway
 4142020-10-15T14:45:00  <jamesob> well... not always, but for a while :)
 4152020-10-15T14:45:39  *** Mercury_Vapor has quit IRC
 4162020-10-15T14:45:43  <promag> jamesob: but what happens if you have to validate and a block isn't there?
 4172020-10-15T14:46:44  <jamesob> promag: validation doesn't require access to blockfiles per se because all the data you're relying on is stored in (i) the headers chain and (ii) the utxo set
 4182020-10-15T14:47:10  *** bitcoin-git has joined #bitcoin-core-dev
 4192020-10-15T14:47:10  <bitcoin-git> [bitcoin] luke-jr opened pull request #20157: Bugfix: chainparams: Add missing (disabled) Taproot deployment for Signet (master...signet_taproot_fix) https://github.com/bitcoin/bitcoin/pull/20157
 4202020-10-15T14:47:12  *** bitcoin-git has left #bitcoin-core-dev
 4212020-10-15T14:47:59  <provoostenator> I'd like to nominate https://github.com/bitcoin-core/gui/pull/96 for v0.21 too
 4222020-10-15T14:48:26  <provoostenator> Also note it's impossible to create an unnamed wallet with the GUI atm
 4232020-10-15T14:49:10  <promag> jamesob: https://github.com/jamesob/assumeutxo-docs/tree/2019-04-proposal/proposal#do-you-perform-any-extra-validation-on-a-loaded-snapshot-besides-comparing-its-hash-to-the-assumeutxo-value
 4242020-10-15T14:49:48  <promag> jamesob: but if blocks are available locally then this is not required right?
 4252020-10-15T14:50:06  <promag> "this" as in ibd
 4262020-10-15T14:50:38  <jamesob> promag: ibd is still required to make sure that the blocks on disk render into the utxo set that you expect
 4272020-10-15T14:51:13  <jamesob> I guess that'd be more like a reindex
 4282020-10-15T14:52:22  <promag> thanks jamesob
 4292020-10-15T14:52:53  <jamesob> sure thing
 4302020-10-15T14:52:57  *** Mercury_Vapor has joined #bitcoin-core-dev
 4312020-10-15T15:00:01  *** doomas has quit IRC
 4322020-10-15T15:01:56  <jamesob> man it is now amazingly hard to replicate the slew of CI errors locally
 4332020-10-15T15:03:39  *** andreacab has joined #bitcoin-core-dev
 4342020-10-15T15:04:06  <sdaftuar> i thought it was a video game where you keep clicking the re-run button til it passes?
 4352020-10-15T15:04:11  * sdaftuar ducks
 4362020-10-15T15:05:01  <promag> sdaftuar: like go away pls
 4372020-10-15T15:06:02  <promag> luke-jr: another approach would be -prunedir which if set it would move there instead of deleting
 4382020-10-15T15:06:46  *** jesseposner has joined #bitcoin-core-dev
 4392020-10-15T15:06:59  <luke-jr> promag: keep in mind it may be desirable to actually prune too
 4402020-10-15T15:07:11  <luke-jr> promag: eg, keep blocks with your own txs in them in storage, but prune everything else
 4412020-10-15T15:08:15  <promag> that requires to have wallets loaded
 4422020-10-15T15:08:39  <luke-jr> not necessarily (see prune locks)
 4432020-10-15T15:09:41  <promag> ah you mean #19463
 4442020-10-15T15:09:44  <gribble> https://github.com/bitcoin/bitcoin/issues/19463 | Prune locks by luke-jr · Pull Request #19463 · bitcoin/bitcoin · GitHub
 4452020-10-15T15:10:13  <luke-jr> promag: anyway, my point is it probably shouldn't literally hijack the pruning logic
 4462020-10-15T15:10:21  <luke-jr> it is fundamentally different
 4472020-10-15T15:10:35  <promag> don't want to change the logic
 4482020-10-15T15:10:46  <promag> just want to s/delete/move
 4492020-10-15T15:12:00  *** jesseposner has quit IRC
 4502020-10-15T15:14:22  *** Emcy has quit IRC
 4512020-10-15T15:15:03  *** Emcy has joined #bitcoin-core-dev
 4522020-10-15T15:22:25  *** gonemad3 has joined #bitcoin-core-dev
 4532020-10-15T15:28:05  <luke-jr> #proposedmeetingtopic Getting BIP 8 logic in before freeze
 4542020-10-15T15:28:05  <yanmaani> https://travis-ci.org/github/namecoin/namecoin-core/jobs/736047101 What could cause this Travis failure? It seems to relate to #11394 and https://github.com/bitcoin/bitcoin/commit/6e4e98ee8ce2da3cca2e2fd210e9e8dbc9b1c936
 4552020-10-15T15:28:07  <gribble> https://github.com/bitcoin/bitcoin/issues/11394 | Perform a weaker subtree check in Travis by sipa · Pull Request #11394 · bitcoin/bitcoin · GitHub
 4562020-10-15T15:29:50  *** kabaum has joined #bitcoin-core-dev
 4572020-10-15T15:44:48  *** kristapsk___ is now known as kristapsk
 4582020-10-15T15:45:22  *** bitcoin-git has joined #bitcoin-core-dev
 4592020-10-15T15:45:22  <bitcoin-git> [bitcoin] laanwj pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/711ddce94377...0d2248235375
 4602020-10-15T15:45:23  <bitcoin-git> bitcoin/master 6df7882 Jon Atack: net: add peer network to CNodeStats
 4612020-10-15T15:45:23  <bitcoin-git> bitcoin/master 4938a10 Jon Atack: rpc, test: expose CNodeStats network in RPC getpeerinfo
 4622020-10-15T15:45:24  <bitcoin-git> bitcoin/master 5133fab Jon Atack: cli: simplify -netinfo using getpeerinfo network field
 4632020-10-15T15:45:25  *** bitcoin-git has left #bitcoin-core-dev
 4642020-10-15T15:45:42  *** bitcoin-git has joined #bitcoin-core-dev
 4652020-10-15T15:45:42  <bitcoin-git> [bitcoin] laanwj merged pull request #20002: net, rpc, cli: expose peer network in getpeerinfo; simplify/improve -netinfo (master...getpeerinfo-GetNetClass) https://github.com/bitcoin/bitcoin/pull/20002
 4662020-10-15T15:45:44  *** bitcoin-git has left #bitcoin-core-dev
 4672020-10-15T15:51:03  *** proofofkeags has joined #bitcoin-core-dev
 4682020-10-15T15:51:44  *** andreacab has quit IRC
 4692020-10-15T15:52:18  *** andreacab has joined #bitcoin-core-dev
 4702020-10-15T15:55:06  *** jesseposner has joined #bitcoin-core-dev
 4712020-10-15T16:04:10  *** andreacab has quit IRC
 4722020-10-15T16:04:35  *** andreacab has joined #bitcoin-core-dev
 4732020-10-15T16:13:27  *** jeremyrubin has joined #bitcoin-core-dev
 4742020-10-15T16:15:24  *** jesseposner has quit IRC
 4752020-10-15T16:17:47  *** da39a3ee5e6b4b0d has quit IRC
 4762020-10-15T16:21:20  *** Talkless has joined #bitcoin-core-dev
 4772020-10-15T16:22:11  <hebasto> provoostenator: https://github.com/bitcoin-core/gui/pull/96
 4782020-10-15T16:22:29  <hebasto> provoostenator: agree about 0.21
 4792020-10-15T16:47:04  *** andreacab has quit IRC
 4802020-10-15T16:47:30  *** andreacab has joined #bitcoin-core-dev
 4812020-10-15T16:50:16  *** jesseposner has joined #bitcoin-core-dev
 4822020-10-15T16:51:40  *** andreacab has quit IRC
 4832020-10-15T16:52:27  *** ossifrage has quit IRC
 4842020-10-15T17:15:30  <yanmaani> Do you get my posts to the bitcoin-dev list? I can see them online, but I get the "your message awaits approval" message
 4852020-10-15T17:38:01  *** davec has quit IRC
 4862020-10-15T17:42:06  *** davec has joined #bitcoin-core-dev
 4872020-10-15T17:57:43  *** DeanWeen has quit IRC
 4882020-10-15T17:58:28  <provoostenator> #16546 can be dropped from the high priority list: it won't make it into 0.21 and hardware wallets already have a project
 4892020-10-15T17:58:30  <gribble> https://github.com/bitcoin/bitcoin/issues/16546 | External signer support - Wallet Box edition by Sjors · Pull Request #16546 · bitcoin/bitcoin · GitHub
 4902020-10-15T17:58:55  <provoostenator> That said, it now works with Sqlite!
 4912020-10-15T17:59:07  *** AaronvanW has quit IRC
 4922020-10-15T18:00:02  *** gonemad3 has quit IRC
 4932020-10-15T18:02:09  *** Cory has quit IRC
 4942020-10-15T18:05:47  *** kristapsk has quit IRC
 4952020-10-15T18:06:10  *** kristapsk has joined #bitcoin-core-dev
 4962020-10-15T18:06:44  *** justanotheruser has joined #bitcoin-core-dev
 4972020-10-15T18:09:21  *** Cory has joined #bitcoin-core-dev
 4982020-10-15T18:16:36  *** joerodgers has joined #bitcoin-core-dev
 4992020-10-15T18:20:30  *** bitcoin-git has joined #bitcoin-core-dev
 5002020-10-15T18:20:30  <bitcoin-git> [bitcoin] laanwj pushed 8 commits to master: https://github.com/bitcoin/bitcoin/compare/0d2248235375...9855422e65ca
 5012020-10-15T18:20:30  <bitcoin-git> bitcoin/master 567008d Hennadii Stepanov: p2p: Add DumpAnchors()
 5022020-10-15T18:20:31  <bitcoin-git> bitcoin/master c29272a Hennadii Stepanov: p2p: Add ReadAnchors()
 5032020-10-15T18:20:31  <bitcoin-git> bitcoin/master bad16af Hennadii Stepanov: p2p: Add CConnman::GetCurrentBlockRelayOnlyConns()
 5042020-10-15T18:20:32  *** bitcoin-git has left #bitcoin-core-dev
 5052020-10-15T18:21:38  *** Lthere has joined #bitcoin-core-dev
 5062020-10-15T18:22:15  *** bitcoin-git has joined #bitcoin-core-dev
 5072020-10-15T18:22:15  <bitcoin-git> [bitcoin] laanwj merged pull request #17428: p2p: Try to preserve outbound block-relay-only connections during restart (master...20191109-anchors) https://github.com/bitcoin/bitcoin/pull/17428
 5082020-10-15T18:22:16  *** bitcoin-git has left #bitcoin-core-dev
 5092020-10-15T18:26:48  <phantomcircuit> sipa, can an attacker with access to the private key generate two signatures from the same private key for the same message?
 5102020-10-15T18:26:53  <phantomcircuit> with schnorr signatures?
 5112020-10-15T18:27:21  <phantomcircuit> i assume so
 5122020-10-15T18:27:26  <sipa> generally you don't call someone with a private key an attacker ;)
 5132020-10-15T18:27:43  <sdaftuar> "signer"
 5142020-10-15T18:27:44  <sipa> but yes - the term you're looking for (i think) is a "unique signature", and no EC based signature schemes are
 5152020-10-15T18:27:51  <phantomcircuit> sipa, if they're trying to abuse poorly written wallet software they are :P
 5162020-10-15T18:27:59  <sdaftuar> "user"
 5172020-10-15T18:28:07  <phantomcircuit> that's what i thought
 5182020-10-15T18:28:23  <phantomcircuit> it's still an attacker... just not of the signature scheme itself
 5192020-10-15T18:28:26  <jeremyrubin> I think phantomcircuit is more asking if a signing oracle will ever generate different signatures for same msg
 5202020-10-15T18:28:52  *** bitcoin-git has joined #bitcoin-core-dev
 5212020-10-15T18:28:52  <bitcoin-git> [bitcoin] dongcarl opened pull request #20158: tree-wide: De-globalize ChainstateManager (master...2020-06-libbitcoinruntime) https://github.com/bitcoin/bitcoin/pull/20158
 5222020-10-15T18:28:53  *** bitcoin-git has left #bitcoin-core-dev
 5232020-10-15T18:28:58  <sipa> phantomcircuit: to be clear, the bip340 signing algorithm is deterministic if no auxiliary randomness is used
 5242020-10-15T18:29:08  <phantomcircuit> jeremyrubin, not if they will, but if they can, which sipa has answered
 5252020-10-15T18:29:17  <sipa> but nobody is required (or can be verified to) follow that algorithm
 5262020-10-15T18:29:35  <phantomcircuit> sipa, yeah i understand now, i was confused by the bip340 language about malleability
 5272020-10-15T18:30:02  <sipa> there is one context where we actually treat someone with a private key as an attacker in BIP340, and it's a rather unusual requirement: nobody (even those with private keys) should be able to construct a signature for which the single-sig validation and batch-validation algorithm produce a different result (with more than negligible probability)
 5282020-10-15T18:30:03  <phantomcircuit> i thought that my original reading was unlikely so im here asking :)
 5292020-10-15T18:30:31  <sipa> well, i don't think it should be an unusual requirement - but in practice it seems it's not part of the standard attack model for signatures
 5302020-10-15T18:30:57  <phantomcircuit> sipa, indeed cause then you could validate a transaction that is then rejected by block validation, would be a nasty issue
 5312020-10-15T18:32:37  <sipa> in ed25519 land, this property clearly does not hold: https://hdevalence.ca/blog/2020-10-04-its-25519am
 5322020-10-15T18:33:12  *** DeanWeen has joined #bitcoin-core-dev
 5332020-10-15T18:33:13  <sipa> and it's trivial to make signatures (with private key) that validate in some implementations and not others, with tons of variants
 5342020-10-15T18:34:55  <phantomcircuit> sipa, for most signature scheme use the cost of rejecting a signature that would be valid elsewhere is typically zero
 5352020-10-15T18:35:11  <phantomcircuit> this is a sort of unique case in which everybody has to actually 100% agree
 5362020-10-15T18:37:55  <phantomcircuit> sipa, do you know ballpark how many signatures are in a typical 'full' block right now?
 5372020-10-15T18:40:28  <sipa> around 6000 txins per block, and i assume only a fraction have more than one signature
 5382020-10-15T18:42:09  <jeremyrubin> #proposedmeetingtopic small announcement on behalf of BGIN
 5392020-10-15T18:46:36  *** bitcoin-git has joined #bitcoin-core-dev
 5402020-10-15T18:46:37  <bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/9855422e65ca...9ad7cd2887ab
 5412020-10-15T18:46:37  <bitcoin-git> bitcoin/master 3069b56 Amiti Uttarwar: [doc] Improve help for getpeerinfo connection_type field.
 5422020-10-15T18:46:38  <bitcoin-git> bitcoin/master 41dca08 Amiti Uttarwar: [trivial] Extract connection type doc into file where it is used.
 5432020-10-15T18:46:39  <bitcoin-git> bitcoin/master 9ad7cd2 Wladimir J. van der Laan: Merge #20090: [doc] Tiny followups to new getpeerinfo connection type fiel...
 5442020-10-15T18:46:40  *** bitcoin-git has left #bitcoin-core-dev
 5452020-10-15T18:46:56  *** bitcoin-git has joined #bitcoin-core-dev
 5462020-10-15T18:46:56  <bitcoin-git> [bitcoin] laanwj merged pull request #20090: [doc] Tiny followups to new getpeerinfo connection type field  (master...2020-09-getpeerinfo-conn-type-release-notes) https://github.com/bitcoin/bitcoin/pull/20090
 5472020-10-15T18:46:57  *** bitcoin-git has left #bitcoin-core-dev
 5482020-10-15T18:49:40  *** lightlike has joined #bitcoin-core-dev
 5492020-10-15T18:50:57  *** Pavlenex has quit IRC
 5502020-10-15T18:58:10  *** promag_ has joined #bitcoin-core-dev
 5512020-10-15T18:59:32  *** promag_ has quit IRC
 5522020-10-15T19:00:15  *** promag_ has joined #bitcoin-core-dev
 5532020-10-15T19:00:27  <wumpus> #startmeeting
 5542020-10-15T19:00:27  <lightningbot> Meeting started Thu Oct 15 19:00:27 2020 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
 5552020-10-15T19:00:27  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
 5562020-10-15T19:00:28  <provoostenator> hi
 5572020-10-15T19:00:30  *** promag has quit IRC
 5582020-10-15T19:00:32  <emzy> hi
 5592020-10-15T19:00:37  <hebasto> hi
 5602020-10-15T19:00:39  <jnewbery> hi
 5612020-10-15T19:00:49  <luke-jr> hi
 5622020-10-15T19:00:54  <kanzure> hi
 5632020-10-15T19:00:57  *** promag_ is now known as promag
 5642020-10-15T19:01:05  <promag> hi
 5652020-10-15T19:01:06  *** promag_ has joined #bitcoin-core-dev
 5662020-10-15T19:01:10  <wumpus> two proposed topics taproot relay policy / activation on testnet/signet (sipa),  Getting BIP 8 logic in before freeze (luke-jr)
 5672020-10-15T19:01:26  <luke-jr> wumpus: there was a third by jeremyrubin O.o
 5682020-10-15T19:01:33  <luke-jr> [18:42:09] <jeremyrubin> #proposedmeetingtopic small announcement on behalf of BGIN
 5692020-10-15T19:01:33  <jonatack> hi
 5702020-10-15T19:02:03  <elichai2> hi
 5712020-10-15T19:02:06  <wumpus> PSA today is the feature freeze for 0.21, it seems we managed to merge all the features on the milestone
 5722020-10-15T19:02:12  <wumpus> luke-jr: strange, didn't see it in http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt
 5732020-10-15T19:02:18  <luke-jr> wumpus: thought it was tomorrow? :x
 5742020-10-15T19:02:20  <provoostenator> Note that the GUI repo doesn't have a milestone
 5752020-10-15T19:02:43  <MarcoFalke> provoostenator: Right. Is there any feature we missed from the GUI?
 5762020-10-15T19:02:52  <MarcoFalke> bugfixes can go in any time
 5772020-10-15T19:02:57  <luke-jr> [16:22:11] <hebasto> provoostenator: https://github.com/bitcoin-core/gui/pull/96
 5782020-10-15T19:02:59  <wumpus> there are some PRs left of course, but nothing that can be labeled feature imo https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.21.0
 5792020-10-15T19:03:19  <wumpus> provoostenator: good point, didn't look at the gui repo at all
 5802020-10-15T19:03:24  <luke-jr> wumpus: would be nice to get some of BIP 8 in, so there's less backported with activation
 5812020-10-15T19:03:24  <MarcoFalke> We still have 14 days to find and fix all bugs
 5822020-10-15T19:04:01  <luke-jr> but I'll save that for the dedicated topic
 5832020-10-15T19:04:08  <wumpus> luke-jr: well 10-15 is today here https://github.com/bitcoin/bitcoin/issues/18947 , but does it matter, everything tagged as feature was merged
 5842020-10-15T19:04:26  <wumpus> (except for the GUI one apparently, if it's ready for merge it should go in)
 5852020-10-15T19:04:38  <luke-jr> wumpus: doesn't mean much when only a few people can edit tags :/
 5862020-10-15T19:05:00  <wumpus> luke-jr: the idea is that things get proposed for the milestone in meetings, or in the channel at least
 5872020-10-15T19:05:08  <dongcarl> hi
 5882020-10-15T19:05:30  <luke-jr> oh well, BIP 8 isn't strictly feature anyway
 5892020-10-15T19:05:33  <fjahr_> hi
 5902020-10-15T19:06:01  <wumpus> #topic Pending bugfixes for 0.21
 5912020-10-15T19:06:47  <wumpus> any bugfixes that we should get in for the release missing on the milestone?
 5922020-10-15T19:07:14  <jonatack> i'd propose 20120, 20115, 19961, and maybe 19874
 5932020-10-15T19:07:15  <luke-jr> I found #20157,  not sure how important it is
 5942020-10-15T19:07:16  <gribble> https://github.com/bitcoin/bitcoin/issues/20157 | Bugfix: chainparams: Add missing (disabled) Taproot deployment for Signet by luke-jr · Pull Request #20157 · bitcoin/bitcoin · GitHub
 5952020-10-15T19:07:37  <sipa> luke-jr: should definitely be fixed before release
 5962020-10-15T19:07:42  <sipa> #20120
 5972020-10-15T19:07:44  <gribble> https://github.com/bitcoin/bitcoin/issues/20120 | net, rpc, test, bugfix: update GetNetworkName, GetNetworksInfo, regression tests by jonatack · Pull Request #20120 · bitcoin/bitcoin · GitHub
 5982020-10-15T19:07:45  <luke-jr> > #20120, #20115, #19961, and maybe #19874
 5992020-10-15T19:07:45  <gribble> https://github.com/bitcoin/bitcoin/issues/20120 | net, rpc, test, bugfix: update GetNetworkName, GetNetworksInfo, regression tests by jonatack · Pull Request #20120 · bitcoin/bitcoin · GitHub
 6002020-10-15T19:07:46  <jonatack> plus the upcoming fix for #19543
 6012020-10-15T19:07:47  <gribble> https://github.com/bitcoin/bitcoin/issues/20115 | cli: -netinfo quick updates/fixups and release note by jonatack · Pull Request #20115 · bitcoin/bitcoin · GitHub
 6022020-10-15T19:07:49  <gribble> https://github.com/bitcoin/bitcoin/issues/19961 | doc: tor.md updates by jonatack · Pull Request #19961 · bitcoin/bitcoin · GitHub
 6032020-10-15T19:07:50  <gribble> https://github.com/bitcoin/bitcoin/issues/19874 | cli, bugfix: degrade -getinfo gracefully for older servers by jonatack · Pull Request #19874 · bitcoin/bitcoin · GitHub
 6042020-10-15T19:07:51  <gribble> https://github.com/bitcoin/bitcoin/issues/19543 | Normalize fee units for RPC ("BTC/kB" and "sat/B) · Issue #19543 · bitcoin/bitcoin · GitHub
 6052020-10-15T19:08:09  <hebasto> #20080 or #19933
 6062020-10-15T19:08:11  <gribble> https://github.com/bitcoin/bitcoin/issues/20080 | Strip any trailing `/` in -datadir path by hebasto · Pull Request #20080 · bitcoin/bitcoin · GitHub
 6072020-10-15T19:08:14  <gribble> https://github.com/bitcoin/bitcoin/issues/19933 | wallet: bugfix; if datadir has a trailing / listwalletdir would strip lead char of walletname by Saibato · Pull Request #19933 · bitcoin/bitcoin · GitHub
 6082020-10-15T19:08:41  <luke-jr> oh yes, one of those are important to get in ☺
 6092020-10-15T19:08:51  <wumpus> jonatack: i'm not convinced  #19874 is really a bugfix
 6102020-10-15T19:08:53  <gribble> https://github.com/bitcoin/bitcoin/issues/19874 | cli, bugfix: degrade -getinfo gracefully for older servers by jonatack · Pull Request #19874 · bitcoin/bitcoin · GitHub
 6112020-10-15T19:09:17  <luke-jr> afaik -getinfo has never worked with old servers gracefully
 6122020-10-15T19:09:21  <ariard> hi
 6132020-10-15T19:09:23  <jonatack> agree that it's optional. the doc/tor.md is still in draft but will open v soon
 6142020-10-15T19:09:47  <sipa> i think documentation improvements can be done after feature freeze
 6152020-10-15T19:09:58  <MarcoFalke> tests and docs can go in any time
 6162020-10-15T19:10:07  <jonatack> sipa: agree, i held off on those to get the features in
 6172020-10-15T19:11:31  <provoostenator> #18788 would be good tests to add
 6182020-10-15T19:11:34  <gribble> https://github.com/bitcoin/bitcoin/issues/18788 | tests: Update more tests to work with descriptor wallets by achow101 · Pull Request #18788 · bitcoin/bitcoin · GitHub
 6192020-10-15T19:11:56  <wumpus> 19543 was already tagged
 6202020-10-15T19:12:18  <luke-jr> oh, did achow101 want to make descriptor wallets tied to sqlite? where does that stand?
 6212020-10-15T19:12:28  <luke-jr> #20156 is IMO a bugfix
 6222020-10-15T19:12:30  <gribble> https://github.com/bitcoin/bitcoin/issues/20156 | Make sqlite support optional (compile-time) by luke-jr · Pull Request #20156 · bitcoin/bitcoin · GitHub
 6232020-10-15T19:12:37  <provoostenator> luke-jr: that's already merged
 6242020-10-15T19:12:40  <wumpus> yes, that was his plan, to make it clearer that those are two different wallet formats
 6252020-10-15T19:12:57  <meshcollider> Please can we decide which of 19933 and 20080 we want to keep and which one to close?
 6262020-10-15T19:13:03  <luke-jr> provoostenator: tying the two together is?
 6272020-10-15T19:13:07  <wumpus> luke-jr: i think 'return a null in a field' is graceful enough, it just shouldn't crash
 6282020-10-15T19:13:09  <MarcoFalke> I like #20080
 6292020-10-15T19:13:11  <gribble> https://github.com/bitcoin/bitcoin/issues/20080 | Strip any trailing `/` in -datadir path by hebasto · Pull Request #20080 · bitcoin/bitcoin · GitHub
 6302020-10-15T19:13:20  <provoostenator> luke-jr: descriptor == sqlite for new wallet yes
 6312020-10-15T19:13:25  <provoostenator> see my comment as well
 6322020-10-15T19:13:33  <promag> +1 #20080
 6332020-10-15T19:13:35  <gribble> https://github.com/bitcoin/bitcoin/issues/20080 | Strip any trailing `/` in -datadir path by hebasto · Pull Request #20080 · bitcoin/bitcoin · GitHub
 6342020-10-15T19:13:42  <provoostenator> Unless achow101 changed his mind about that, but I think that was the point of getting it in before release
 6352020-10-15T19:13:44  <wumpus> 20080 was already tagged right
 6362020-10-15T19:13:46  <MarcoFalke> I promise to test 20080 soon
 6372020-10-15T19:13:51  <wumpus> please don't repeat things
 6382020-10-15T19:13:56  <luke-jr> wumpus: 'return a null in a field' ?
 6392020-10-15T19:14:16  <wumpus> I'm having a lot of trouble keeping track of PRs mentioned here to add them to the milestone
 6402020-10-15T19:14:21  <luke-jr> oh, for -getinfo; sure; or just an error even
 6412020-10-15T19:14:25  <wumpus> luke-jr: yes
 6422020-10-15T19:14:37  <meshcollider> Alright 20080 it is, I'll close 19933
 6432020-10-15T19:15:09  <wumpus> meshcollider: yes makes sense
 6442020-10-15T19:16:14  <wumpus> I think I've tagged everything mentioned, if not, please let me know
 6452020-10-15T19:16:57  <promag> wumpus: maybe #20125
 6462020-10-15T19:16:59  <gribble> https://github.com/bitcoin/bitcoin/issues/20125 | rpc, wallet: Expose database format in getwalletinfo by promag · Pull Request #20125 · bitcoin/bitcoin · GitHub
 6472020-10-15T19:17:26  <luke-jr> 20080 should get 0.19.x and 0.20.x tags too I think
 6482020-10-15T19:17:30  <wumpus> promag: sounds like a feature to me
 6492020-10-15T19:17:49  <MarcoFalke> luke-jr: It already has
 6502020-10-15T19:17:55  <wumpus> (though maybe a necessary one, I don't' know)
 6512020-10-15T19:17:57  <luke-jr> o
 6522020-10-15T19:17:57  *** bitcoin-git has joined #bitcoin-core-dev
 6532020-10-15T19:17:58  <bitcoin-git> [bitcoin] meshcollider closed pull request #19933: wallet: bugfix; if datadir has a trailing '/'  listwalletdir would strip lead char of walletname (master...wallet-fix-missing-chars-boost-1.47) https://github.com/bitcoin/bitcoin/pull/19933
 6542020-10-15T19:18:08  *** bitcoin-git has left #bitcoin-core-dev
 6552020-10-15T19:18:14  <jonatack> agree with promag about 20125
 6562020-10-15T19:18:18  <wumpus> luke-jr: let's discuss the 0.21 milestone now not other ones
 6572020-10-15T19:18:36  *** belcher has quit IRC
 6582020-10-15T19:19:09  <wumpus> ok adding 20125...
 6592020-10-15T19:19:14  <promag> wumpus: not really... just adds "format" key to the rpc response
 6602020-10-15T19:19:27  *** belcher has joined #bitcoin-core-dev
 6612020-10-15T19:19:28  <wumpus> well it's not a bugfix at least
 6622020-10-15T19:19:36  <wumpus> but I don't care it seems minimal enough
 6632020-10-15T19:19:52  <promag> wumpus: right
 6642020-10-15T19:20:43  <wumpus> that concludes the topic I guess
 6652020-10-15T19:20:53  <luke-jr> I'm not sure it makes sense to expose that detail, but meh
 6662020-10-15T19:21:06  <wumpus> #topic taproot relay policy / activation on testnet/signet (sipa)
 6672020-10-15T19:21:18  <sipa> hi
 6682020-10-15T19:21:31  <wumpus> luke-jr: especially if it's linked to descriptor wallets it seems a bit redundant, but yeah...
 6692020-10-15T19:21:32  <promag> luke-jr: could still be rejected ;)
 6702020-10-15T19:21:41  <sipa> there are a few aspects here
 6712020-10-15T19:21:50  <wumpus> if it's useful for troubleshooting/diagnosis it should be in
 6722020-10-15T19:22:12  <sipa> one is relay of v1 transaction outputs; bitcoin core will do that since #15846
 6732020-10-15T19:22:15  <gribble> https://github.com/bitcoin/bitcoin/issues/15846 | [POLICY] Make sending to future native witness outputs standard by sipa · Pull Request #15846 · bitcoin/bitcoin · GitHub
 6742020-10-15T19:22:54  <sipa> but since the merge of #19953, we'll also relay spends of (valid) taproot outputs
 6752020-10-15T19:22:57  <gribble> https://github.com/bitcoin/bitcoin/issues/19953 | Implement BIP 340-342 validation (Schnorr/taproot/tapscript) by sipa · Pull Request #19953 · bitcoin/bitcoin · GitHub
 6762020-10-15T19:23:09  <sipa> i think that's undesirable, at least until activation is defined, or even until actually activated
 6772020-10-15T19:23:44  * luke-jr did suggest splitting that out of the PR a few months ago :P
 6782020-10-15T19:24:07  <sipa> luke-jr: well, we do want it on regtest
 6792020-10-15T19:24:24  <luke-jr> regtest supports acceptnonstdtxn, but ok
 6802020-10-15T19:26:03  <sipa> talking to sdaftuar a bit, i think we should just reject creation and spending of v1 outputs until taproot is _active_
 6812020-10-15T19:26:17  <sipa> as a policy rule (not through script validation, which is more invasive)
 6822020-10-15T19:27:16  <sipa> or at least creation as soon as an activation is defined
 6832020-10-15T19:27:36  <sipa> (so that the behavior on mainnet before an activation is defined is essentially as if it didn't exist at all)
 6842020-10-15T19:28:06  <sipa> i can open a PR/issue and discuss further there
 6852020-10-15T19:28:30  <sipa> but i wanted to bring this up, as it may be unexpected that master is now doing taproot validation on the mempool
 6862020-10-15T19:28:43  <wumpus> I think that makes sense, to do that as a policy rule
 6872020-10-15T19:28:59  <MarcoFalke> so the spends would be valid taproot spends (with witness) only?
 6882020-10-15T19:29:28  <sipa> so right now: all v1 creation is relayed, v1 spends are relayed only if valid according to taproot rules
 6892020-10-15T19:29:52  <ariard> is there any disadvantage of doing this?
 6902020-10-15T19:30:20  <sipa> my proposal: v1 creation is not relayed while taproot activation is defined but not yet active; v1 spending is only relayed after being actually active
 6912020-10-15T19:30:23  *** ossifrage has joined #bitcoin-core-dev
 6922020-10-15T19:30:40  <provoostenator> Why not always relay?
 6932020-10-15T19:31:02  <MarcoFalke> provoostenator: Someone will give away their coins, surely
 6942020-10-15T19:31:03  <provoostenator> Doesn't seem ideal to have a bunch of nodes out there not relaying v1 transactions.
 6952020-10-15T19:31:23  <sipa> provoostenator: they'd all start relaying as soon as activation happens
 6962020-10-15T19:31:31  <sipa> before that point, we don't care
 6972020-10-15T19:31:59  *** jesseposner has quit IRC
 6982020-10-15T19:32:03  <ariard> sipa: so you want to hardcode the loosening policy change based on the consensus activation IIRC ?
 6992020-10-15T19:32:07  <luke-jr> well, activation isn't in 0.21.0, so not these
 7002020-10-15T19:32:38  <sipa> luke-jr: indeed, the only effect on 0.21.0 would be making spending of v1 non relayed
 7012020-10-15T19:32:50  <jnewbery> sipa: what's the difference between 'not relayed while taproot activation is defined but not yet active' and 'only relayed after being actually active'
 7022020-10-15T19:33:31  <provoostenator> Did we relay v1 to/from transactions before taproot was merged?
 7032020-10-15T19:33:37  <sipa> jnewbery: creation would be relayed as long as no activation parameters are set (the idea being that without activation parameters, it should be treated as an unknown future upgrade that can still change)
 7042020-10-15T19:33:41  <aj> jnewbery: 0.21.0 will be not-defined and not-active, so will always relay creation of taproot outputs, but not spends of them
 7052020-10-15T19:34:16  <sipa> maybe this is a simpler principle: before activation is _defined_, behavior should be identical to before taproot was merged
 7062020-10-15T19:34:21  <aj> sipa: i'm not sure it makes much sense to make it harder to spend a taproot output than to create one? creating one before activation is how you lose money?
 7072020-10-15T19:34:43  <jeremyrubin> aj: i thought we checked outputs standardness?
 7082020-10-15T19:35:02  <jnewbery> sipa aj: thanks
 7092020-10-15T19:35:10  <aj> jeremyrubin: 15846
 7102020-10-15T19:35:12  <luke-jr> aj: the spend we make harder, may be a theft
 7112020-10-15T19:35:20  <luke-jr> you can't steal if you can't spend
 7122020-10-15T19:35:22  <jeremyrubin> #15846
 7132020-10-15T19:35:24  <gribble> https://github.com/bitcoin/bitcoin/issues/15846 | [POLICY] Make sending to future native witness outputs standard by sipa · Pull Request #15846 · bitcoin/bitcoin · GitHub
 7142020-10-15T19:35:41  <aj> luke-jr: prior to activation miners can spend trivially
 7152020-10-15T19:35:58  <luke-jr> aj: miners don't rely on others' policy
 7162020-10-15T19:36:11  <sipa> aj: my suggestion is that relay of creation and spending only differs before activation is defined... to match pre-taproot-implemented behavior
 7172020-10-15T19:36:27  <sipa> after activation is defined, both are disallowed until it is actually active
 7182020-10-15T19:36:29  *** Talkless has quit IRC
 7192020-10-15T19:37:45  <luke-jr> (OT: wumpus: #19502 should probably get milestoned)
 7202020-10-15T19:37:47  <gribble> https://github.com/bitcoin/bitcoin/issues/19502 | Bugfix: Wallet: Soft-fail exceptions within ListWalletDir file checks by luke-jr · Pull Request #19502 · bitcoin/bitcoin · GitHub
 7212020-10-15T19:37:51  <sipa> aj: which is ultimately due to softfork safeness... if we treat taproot as subject to change still (which i think we should until activation is defined), we shouldn't permit spending it to be relayed
 7222020-10-15T19:38:09  <wumpus> luke-jr: ok
 7232020-10-15T19:38:24  <jeremyrubin> has that been reverted though somehow?
 7242020-10-15T19:38:33  <sipa> jeremyrubin: what?
 7252020-10-15T19:38:42  <jeremyrubin> looking at the current code and I'm not seeing that logic still
 7262020-10-15T19:38:46  <aj> sipa: right, immediately after activation (supported by 0.21.1 say), you have all nodes relaying creation, but only 0.21.1 nodes relaying spends. vs having 0.21.0 and 0.21.1 nodes validating and relaying spends if we leave things as they are now
 7272020-10-15T19:39:36  <jeremyrubin> Ah
 7282020-10-15T19:39:39  <jeremyrubin> it went into Solver
 7292020-10-15T19:39:51  *** AaronvanW has joined #bitcoin-core-dev
 7302020-10-15T19:40:35  <sipa> aj: i think permitting spends right now is bad... it's just gratuitous policy difference between 0.21 and pre-0.21 nodes
 7312020-10-15T19:40:54  <sipa> the extra rule for suspending relay of outputs is user protection before activation
 7322020-10-15T19:41:07  <sipa> anyway, will open an issue
 7332020-10-15T19:41:08  <aj> sipa: the principle (no behaviour change prior to activation) makes sense, just doesn't seem like it has much benefit (people still lose money if they create outputs earlier, because miners will claim them via a non-std tx) and slight costs (will make relay slightly harder due to implementation-but-no-activation nodes not relaying)
 7342020-10-15T19:41:21  <wumpus> 20 minutes left, we might want to move to the next topic
 7352020-10-15T19:41:30  <sipa> aj: if their own node rejects relay, miners will never see the tx :)
 7362020-10-15T19:41:46  <luke-jr> sipa: no reason their own node would :P
 7372020-10-15T19:41:53  <wumpus> #topic  Getting BIP 8 logic in before freeze (luke-jr)
 7382020-10-15T19:42:03  <luke-jr> I've implemented the current BIP 8 as logic only (no activations) in #19573. This is probably not the final BIP 8 (aj's been working on some revisions), but having it merged in 0.21 means we can have a smaller diff to add Taproot activation later.
 7392020-10-15T19:42:04  <gribble> https://github.com/bitcoin/bitcoin/issues/19573 | Replace unused BIP 9 logic with draft BIP 8 by luke-jr · Pull Request #19573 · bitcoin/bitcoin · GitHub
 7402020-10-15T19:42:06  <luke-jr> Would be nice to get this merged before 0.21.0rc1 if possible. Anyone who wants to help review (or other) can join ##taproot-activation to help get this done quickly.
 7412020-10-15T19:42:09  <luke-jr> Note the PR depends on #19401 and #20157. These are fairly trivial, and the former already has 2 ACKs.
 7422020-10-15T19:42:11  <gribble> https://github.com/bitcoin/bitcoin/issues/19401 | QA: Use GBT to get block versions correct by luke-jr · Pull Request #19401 · bitcoin/bitcoin · GitHub
 7432020-10-15T19:42:12  <gribble> https://github.com/bitcoin/bitcoin/issues/20157 | Bugfix: chainparams: Add missing (disabled) Taproot deployment for Signet by luke-jr · Pull Request #20157 · bitcoin/bitcoin · GitHub
 7442020-10-15T19:43:31  *** rafaelpac has joined #bitcoin-core-dev
 7452020-10-15T19:45:03  <wumpus> i don't know, it does feel a bit rushed to me, to merge something (that should be a no-op otherwise) last minute just to minimize the diff later, especially when we don't even know yet if it's the final state of the BIP
 7462020-10-15T19:45:13  <wumpus> not a small project either
 7472020-10-15T19:45:48  <luke-jr> hmm, true
 7482020-10-15T19:46:01  <sipa> no strong opinion... it doesn't seem very invasive, but on the other hand, this can also easily be backported along with actual activation parameters
 7492020-10-15T19:46:18  <sipa> it also may turn out to be wasted effort
 7502020-10-15T19:46:26  *** ossifrage has quit IRC
 7512020-10-15T19:47:13  <luke-jr> not sure how it could be wasted effort
 7522020-10-15T19:47:29  <luke-jr> sipa: your topic, you had mentioned signet/testnet activation - that might or might not be a reason to do this sooner
 7532020-10-15T19:47:38  <jeremyrubin> i think it makes sense to wait for cleaner git history
 7542020-10-15T19:48:03  <luke-jr> jeremyrubin: I'm assuming the two trivial PRs would be merged first as part of this process
 7552020-10-15T19:48:20  <sipa> oh right, i didn't bring that up... do we want to define an activation on testnet?
 7562020-10-15T19:48:36  <sipa> that's something that was done historically, but with signet i think there may be less need now
 7572020-10-15T19:48:40  <luke-jr> I think it makes sense to test BIP 8 with testnet
 7582020-10-15T19:49:30  <wumpus> it should activate there at some time i guess
 7592020-10-15T19:50:18  <sipa> always possible in .1 or whatever point release too, of course
 7602020-10-15T19:50:19  <aj> probably shouldn't activate on testnet with a different activation method than we plan on using for mainnet?
 7612020-10-15T19:50:32  <luke-jr> sipa: true
 7622020-10-15T19:50:35  *** rafaelpac has quit IRC
 7632020-10-15T19:51:04  <luke-jr> maybe that's a good solution: testnet in .1, and mainnet not until .2
 7642020-10-15T19:51:05  <sipa> it'd be nice to see things active on signet first before suggesting testnet changes
 7652020-10-15T19:51:05  <wumpus> sipa: right
 7662020-10-15T19:51:20  <aj> kallewoof's not awake, but i was thinking maybe lock taproot as it stands in immediately on the default signet, and if worst comes to worst just restart the signet chain if needed
 7672020-10-15T19:51:20  <sipa> (as in signet it can be rolled out without code changes...)
 7682020-10-15T19:52:00  <wumpus> that's great
 7692020-10-15T19:52:12  <luke-jr> signet doesn't even need an activation, does it?
 7702020-10-15T19:52:15  <luke-jr> just always-active?
 7712020-10-15T19:52:16  <MarcoFalke> wait, if spends are made non-standard, it needs conde changes for signet
 7722020-10-15T19:52:21  <aj> sipa: (not-relaying taproot-txs if activation hasn't happened will affect the "without code changes" part a bit
 7732020-10-15T19:52:43  <aj> luke-jr: yeah, that's what i'm thinking
 7742020-10-15T19:52:55  <aj> luke-jr: (i mean, "always-active" is an activation)
 7752020-10-15T19:53:02  <luke-jr> the policy changes sipa suggested are conditional on the deployment state AFAIK?
 7762020-10-15T19:53:21  <MarcoFalke> so I guess s/without/minimal/
 7772020-10-15T19:53:25  <aj> luke-jr: right, but *nodes* have to know the deployment state in that case, not just miners
 7782020-10-15T19:53:31  <luke-jr> so always-active would trigger the spending policy
 7792020-10-15T19:53:50  <sipa> i think we can flesh these things out the next few days
 7802020-10-15T19:53:55  <aj> yep
 7812020-10-15T19:54:04  <luke-jr> yeah, let's give jeremyrubin some minutes ☺
 7822020-10-15T19:54:18  <jeremyrubin> i need like 1 min
 7832020-10-15T19:54:27  <jeremyrubin> so no rush
 7842020-10-15T19:54:47  <wumpus> #topic Small announcement on behalf of BGIN (jeremyrubin)
 7852020-10-15T19:55:00  <jeremyrubin> Matsuo has asked me to share the following
 7862020-10-15T19:55:02  <jeremyrubin> FYI bgin-global.org is hosting an event for core devs the first week of Nov, please fill out this form https://forms.gle/99yUnQdtAkAwt5SW7 to assist scheduling or email schwentker@bsafe.network with any questions. Goal of the event is to help core dev sustainability, so should be of interest for all here.
 7872020-10-15T19:55:12  <jeremyrubin> https://bgin-global.org
 7882020-10-15T19:55:20  <luke-jr> during a pandemic? O.o
 7892020-10-15T19:55:29  <achow101> Who's bgin?
 7902020-10-15T19:55:33  <jeremyrubin> it's a virtual event
 7912020-10-15T19:55:36  <luke-jr> i c
 7922020-10-15T19:55:56  <luke-jr> "Blockchain Governance Initiative Network "
 7932020-10-15T19:55:58  <jeremyrubin> BGIN is "Blockchain Governance Initiative Network (BGIN)"
 7942020-10-15T19:56:05  <jeremyrubin> I'd ignore the acronym tho
 7952020-10-15T19:56:11  <luke-jr> so this is like NY agreement in organization form? :x
 7962020-10-15T19:56:20  <jeremyrubin> no
 7972020-10-15T19:56:40  <aj> there's also coinbase looking to support bitcoin dev projects as of an hour or so ago https://twitter.com/coinbase/status/1316801517983334401
 7982020-10-15T19:56:42  <jeremyrubin> it's the sort of name that you have to have to get intl participation from people in intl financial regulation
 7992020-10-15T19:56:53  <luke-jr> jeremyrubin: lol
 8002020-10-15T19:56:56  <jeremyrubin> so it's started by Matsuo and others
 8012020-10-15T19:57:31  <jeremyrubin> the point being that a lot of various regulators want to chat about how Bitcoin works and how they engage, but also understanding how standards emerge
 8022020-10-15T19:57:57  <jeremyrubin> But a part of that is they want to understand and potentiall support development through research grants
 8032020-10-15T19:58:32  <wumpus> that sounds pretty scary tbh
 8042020-10-15T19:58:36  <jeremyrubin> so it's maybe folk you'd rather not talk to at all depending on your preferences, but it is a good faith effort afaict
 8052020-10-15T19:58:57  <jeremyrubin> :shrug:
 8062020-10-15T19:59:15  <jeremyrubin> I'd encourage you to email concerns to schwentker@bsafe.network
 8072020-10-15T20:00:05  <luke-jr> jeremyrubin: it sounds like they're just giving webinars and we'd simply watch it? O.o
 8082020-10-15T20:00:14  <jeremyrubin> no i don't think so
 8092020-10-15T20:00:26  <jeremyrubin> I think they want to hear from you directly
 8102020-10-15T20:00:41  <MarcoFalke> end meeting?
 8112020-10-15T20:00:44  <wumpus> ok, I think everything is said, thanks for the announcement
 8122020-10-15T20:00:46  <wumpus> #endmeeting
 8132020-10-15T20:00:46  <lightningbot> Meeting ended Thu Oct 15 20:00:46 2020 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
 8142020-10-15T20:00:46  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-10-15-19.00.html
 8152020-10-15T20:00:46  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-10-15-19.00.txt
 8162020-10-15T20:00:46  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2020/bitcoin-core-dev.2020-10-15-19.00.log.html
 8172020-10-15T20:00:49  <luke-jr> >how they engage
 8182020-10-15T20:00:51  <luke-jr> "don't
 8192020-10-15T20:01:21  <luke-jr> jk, maybe should tell them to get rid of the travel rule tho ;)
 8202020-10-15T20:01:22  <jeremyrubin> I mean, there are practical things that are relatively improtant to engage them on
 8212020-10-15T20:01:26  <jeremyrubin> E.g., travel rule
 8222020-10-15T20:01:30  <luke-jr> jeremyrubin: yeah, joking
 8232020-10-15T20:01:31  <jeremyrubin> do you owe taxes on BCash
 8242020-10-15T20:01:40  <luke-jr> not anymore
 8252020-10-15T20:01:55  <emzy> jeremyrubin: I also find it strange. But can I as a none dev also join?
 8262020-10-15T20:02:07  <jeremyrubin> If you had a contract denom in Bitcoin do you owe BCash and Bitcoin after a fork?
 8272020-10-15T20:02:11  <luke-jr> emzy: who is to say you're not a dev? ;)
 8282020-10-15T20:02:16  <achow101> luke-jr: re: sqlite and descriptors. The intention for the foreseeable future is sqlite == descriptors and descriptors == sqlite. So adjust #20156 accordingly
 8292020-10-15T20:02:17  <gribble> https://github.com/bitcoin/bitcoin/issues/20156 | Make sqlite support optional (compile-time) by luke-jr · Pull Request #20156 · bitcoin/bitcoin · GitHub
 8302020-10-15T20:02:20  <emzy> luke-jr: me :)
 8312020-10-15T20:02:39  <luke-jr> achow101: what needs adjustment?
 8322020-10-15T20:02:53  <sipa> achow101: no way to convert legacy bdb wallets to legacy sqlite ones?
 8332020-10-15T20:03:19  <jeremyrubin> Anyways, i don't think there is malintnet but up to you to give benefit of the doubt or express concerns to them directly
 8342020-10-15T20:03:23  <jeremyrubin> i am a mere herald
 8352020-10-15T20:03:31  <aj> "legacy sqlite" wow, already :)
 8362020-10-15T20:03:33  <luke-jr> wumpus: 20156 missed milestoning
 8372020-10-15T20:03:45  <luke-jr> aj: lol
 8382020-10-15T20:03:49  <sipa> aj: legacy meaning non-descriptor
 8392020-10-15T20:03:49  <jeremyrubin> emzy: I think you'd be fine to join, just fill out the form
 8402020-10-15T20:03:56  <achow101> luke-jr: to enforce that descriptor wallets can't be made of sqlite is disabled. Dunno of you already did that, still going through my email backlog
 8412020-10-15T20:03:57  <aj> sipa: yeah :)
 8422020-10-15T20:04:19  <emzy> jeremyrubin: I did. At least I can tell you here what happend :)
 8432020-10-15T20:04:47  <luke-jr> achow101: I didn't remove any code enforcing it, at least
 8442020-10-15T20:04:54  <achow101> sipa: maybe dump them createfromdump, but I'm not intending on making a migration for it
 8452020-10-15T20:04:56  <jeremyrubin> emzy: wat?
 8462020-10-15T20:05:39  <emzy> jeremyrubin: I submitted the form.
 8472020-10-15T20:05:59  <sipa> achow101: well the question is if the format should be supported i think, regardless of how someone can create it
 8482020-10-15T20:06:02  <luke-jr> error = Untranslated(strprintf("Failed to load database path '%s'. Data is not in required format.", path.string()));
 8492020-10-15T20:06:12  <luke-jr> I guess that error could be clearer
 8502020-10-15T20:06:19  <luke-jr> or maybe just remove descriptor support entirely
 8512020-10-15T20:06:25  <sipa> it's ok to say non-descriptor-sqlite wallets are unsupported
 8522020-10-15T20:06:33  <jonatack> achow101: right, the main reason for adding a db format field to getwalletinfo or -getinfo is because a bdb wallet can be descriptor
 8532020-10-15T20:06:38  <sipa> if we don't test that
 8542020-10-15T20:06:43  *** DeanWeen has quit IRC
 8552020-10-15T20:06:56  <sipa> but whatever combinations are supported should be tested
 8562020-10-15T20:07:07  <wumpus> i'm all for not supporting too many combinations
 8572020-10-15T20:07:11  <sipa> and those that aren't should at least get a warning
 8582020-10-15T20:07:19  <wumpus> be careful here, anything you support for the wallet needs to be support for pretty much near forever
 8592020-10-15T20:07:21  <sipa> (or otherwise be impossible to create)
 8602020-10-15T20:07:23  <achow101> luke-jr: I'll have a look when I get home, but I was intending on writing a full without-bdb and without-sqlite thing that disabled legacy or descriptors respectively
 8612020-10-15T20:07:25  <wumpus> as those files will be around for a long time
 8622020-10-15T20:07:44  <wumpus> it's also confusing for users
 8632020-10-15T20:07:57  <wumpus> two types of wallet is enough, avoid the combinatorial cmplexity
 8642020-10-15T20:08:43  <sipa> yeah
 8652020-10-15T20:09:07  <sipa> that's fair
 8662020-10-15T20:09:20  <achow101> jonatack: I think that's useful for experts who do unsupported things, but for most users, the format should be tied to the type
 8672020-10-15T20:09:52  <jeremyrubin> 2**256 wallets for added security
 8682020-10-15T20:10:16  *** bitcoin-git has joined #bitcoin-core-dev
 8692020-10-15T20:10:16  <bitcoin-git> [bitcoin] dongcarl closed pull request #20050: validation: Prune (in)direct g_chainman usage related to ::LookupBlockIndex (bundle 1) (master...2020-09-libbitcoinruntime-v4) https://github.com/bitcoin/bitcoin/pull/20050
 8702020-10-15T20:10:17  *** bitcoin-git has left #bitcoin-core-dev
 8712020-10-15T20:12:13  <wumpus> heh
 8722020-10-15T20:12:40  <achow101> sipa: I think it will be supported but not recommended, aka you had to jump through a lot of hoops to get to legacy sqlite
 8732020-10-15T20:13:01  <sipa> yeah, ok
 8742020-10-15T20:13:32  <luke-jr> i can use sqlite wit uncompressed pubkeys?
 8752020-10-15T20:13:40  <luke-jr> :P
 8762020-10-15T20:13:48  <achow101> sure
 8772020-10-15T20:14:07  <achow101> Descriptora can have uncompressed keys
 8782020-10-15T20:14:12  <luke-jr> :o
 8792020-10-15T20:14:27  <luke-jr> I meant the old wallet format tho
 8802020-10-15T20:14:43  <luke-jr> we should probably drop support for that.. it isn't actually compatible post-segwit anyway :x
 8812020-10-15T20:15:07  *** filchef has quit IRC
 8822020-10-15T20:15:17  <sipa> you mean sqlite non-descriptor with uncompressed keys?
 8832020-10-15T20:15:24  <achow101> Yeah but you and Matt will complain about it
 8842020-10-15T20:15:31  *** filchef has joined #bitcoin-core-dev
 8852020-10-15T20:15:33  <luke-jr> lol
 8862020-10-15T20:16:53  <luke-jr> Qt should stop using camelcase so I don't need to guess at if they did ToolTip or Tooltip
 8872020-10-15T20:17:12  <achow101> Is actually toolTip
 8882020-10-15T20:17:22  <luke-jr> )(%#&)#_)#
 8892020-10-15T20:17:41  <luke-jr> (I'm actually calling SetToolTip, so it's okay)
 8902020-10-15T20:20:02  <promag> descriptors:true wallet doesn't mean it's sqlite right?
 8912020-10-15T20:20:38  <promag> only true starting with 0.21, at least that's my understanding
 8922020-10-15T20:21:00  <achow101> yes
 8932020-10-15T20:21:03  <promag> that's why I'm suggesting "format" in getwalletinfo response
 8942020-10-15T20:22:38  <promag> nit, and maybe in the gui we could have some thing/icon/whatever for these things - like getwalletinfo
 8952020-10-15T20:22:39  *** DeanWeen has joined #bitcoin-core-dev
 8962020-10-15T20:23:23  <luke-jr> promag: descriptors:true will mean sqlite in all supported configurations AIUI
 8972020-10-15T20:24:49  <promag> luke-jr: you can still open a 0.20 descriptors wallet?
 8982020-10-15T20:25:20  <luke-jr> promag: 0.20 doesn't support descriptors
 8992020-10-15T20:25:37  <luke-jr> I don't think..
 9002020-10-15T20:25:41  <promag> <.<
 9012020-10-15T20:28:47  <promag> luke-jr: you are right
 9022020-10-15T20:28:54  <promag> #16528
 9032020-10-15T20:28:57  <gribble> https://github.com/bitcoin/bitcoin/issues/16528 | Native Descriptor Wallets using DescriptorScriptPubKeyMan by achow101 · Pull Request #16528 · bitcoin/bitcoin · GitHub
 9042020-10-15T20:30:01  <promag> 0.20 has some descriptors stuff, but not the option to create descriptors wallet
 9052020-10-15T20:30:16  *** ossifrage has joined #bitcoin-core-dev
 9062020-10-15T20:34:01  *** vincenzopalazzo has joined #bitcoin-core-dev
 9072020-10-15T20:35:10  <achow101> Irs only helpful for people who have descriptor wallets on old master
 9082020-10-15T20:36:32  <promag> right
 9092020-10-15T20:37:22  * luke-jr likes git-worktree
 9102020-10-15T20:37:24  <promag> on the long run the plan is to enforce descriptors?
 9112020-10-15T20:37:52  <promag> and as a consequence it will be sqlite?
 9122020-10-15T20:38:06  <achow101> Yes
 9132020-10-15T20:38:08  <promag> or we will also support non descriptor wallets in sqlite?
 9142020-10-15T20:39:28  <achow101> It will be supported as in if you somehow make one, we won't explode
 9152020-10-15T20:39:52  <luke-jr> will we explode on promag's bdb descriptor wallet? ;)
 9162020-10-15T20:40:02  <achow101> But actually making one is going to be non trivial
 9172020-10-15T20:40:23  <achow101> Same for bdb descriptor wallets
 9182020-10-15T20:41:39  <achow101> luke-jr: I've been running the sqlite branch with 3 of the 4 combinations of format and type without any issue
 9192020-10-15T20:41:54  <achow101> For the past 3 months or so
 9202020-10-15T20:42:17  <promag> "non trivial" why?
 9212020-10-15T20:42:21  <achow101> Only one I haven't run is legacy sqlite
 9222020-10-15T20:42:26  *** lightlike has quit IRC
 9232020-10-15T20:43:47  <achow101> promag: to avoid combinatorial complexity in the migration code
 9242020-10-15T20:45:41  *** jesseposner has joined #bitcoin-core-dev
 9252020-10-15T20:46:09  <achow101> I'll open an issue that lays out the full plan and a timeline
 9262020-10-15T20:52:53  <aj> luke-jr: git-worktree is the best. shame paths end up hardcoded so ccache stuff isn't shared across them though
 9272020-10-15T20:53:24  <luke-jr> aj: wait, what? ccache doesn't care about paths, does it?
 9282020-10-15T20:53:58  <sipa> your ccache cache is shared i think?
 9292020-10-15T20:54:07  <sipa> it's in $HOME/.ccache
 9302020-10-15T20:55:04  <luke-jr> hmm, I thought I configured my ccache to be on tmpfs tho
 9312020-10-15T20:55:20  <luke-jr> ah yes cache directory                     /var/tmp/ccache-dev
 9322020-10-15T20:55:27  <sipa> ah, or wherever you configure it to be
 9332020-10-15T20:57:55  *** promag has quit IRC
 9342020-10-15T20:58:34  *** promag has joined #bitcoin-core-dev
 9352020-10-15T21:00:02  *** Lthere has quit IRC
 9362020-10-15T21:00:17  <aj> luke-jr: ccache doesn't directly, but the path ends up going into the preprocessed source somewhere or something which makes ccache's input different each time... not sure how though now that i look
 9372020-10-15T21:00:18  *** wilcl_ark is now known as willcl_ark
 9382020-10-15T21:03:07  *** promag has quit IRC
 9392020-10-15T21:05:45  <aj> oh, i'm wrong, ccache has a `hash_dir` flag that makes it hash the working dir, and it's -g that puts the working dir in the .o files
 9402020-10-15T21:06:05  <sipa> still, worktrees are very useful
 9412020-10-15T21:06:30  <sipa> i have separate ones for fuzzer builds (so i don't need to re-run ./configure with the fuzzer flags all the time)
 9422020-10-15T21:06:33  <sipa> and sanitizer builds
 9432020-10-15T21:07:22  <sipa> you can't checkout the same branch in two worktrees simultaneously, but you can use git checkout --detach in one to just switch to code of a branch in another
 9442020-10-15T21:10:23  <luke-jr> aj: it being in the .o should be okay?
 9452020-10-15T21:10:43  <luke-jr> sipa: you can checkout the same branch if you really want to :D
 9462020-10-15T21:10:52  <sipa> luke-jr: how so?
 9472020-10-15T21:11:21  <sipa> is there some --use-the-force option?
 9482020-10-15T21:11:37  <luke-jr> IIRC
 9492020-10-15T21:12:13  <luke-jr> --force
 9502020-10-15T21:12:36  *** Guyver2 has quit IRC
 9512020-10-15T21:15:35  *** vincenzopalazzo has quit IRC
 9522020-10-15T21:16:05  *** filchef has quit IRC
 9532020-10-15T21:22:25  *** Antimatter has joined #bitcoin-core-dev
 9542020-10-15T21:30:00  *** justanotheruser has quit IRC
 9552020-10-15T21:32:07  *** Pavlenex has joined #bitcoin-core-dev
 9562020-10-15T21:38:31  *** Exho has quit IRC
 9572020-10-15T21:39:49  *** Pavlenex has quit IRC
 9582020-10-15T21:40:44  *** rabidus has joined #bitcoin-core-dev
 9592020-10-15T21:43:54  <sipa> if anyone gets this warning with gcc 9, it's a compiler bug (which just produces a bogus warning):
 9602020-10-15T21:43:57  <sipa> src/ecmult_impl.h:496:48: warning: array subscript [1, 268435456] is outside array bounds of ‘struct secp256k1_strauss_point_state[1]’ [-Warray-bounds] 496 |             secp256k1_gej tmp = a[state->ps[np].input_pos];
 9612020-10-15T21:59:28  *** bitcoin-git has joined #bitcoin-core-dev
 9622020-10-15T21:59:28  <bitcoin-git> [bitcoin] theStack opened pull request #20159: test: mining_getblocktemplate_longpoll.py improvements (use MiniWallet, add logging) (master...20201015-test-improve-mining_getblocktemplate_longpoll) https://github.com/bitcoin/bitcoin/pull/20159
 9632020-10-15T21:59:35  *** owowo has quit IRC
 9642020-10-15T21:59:40  *** bitcoin-git has left #bitcoin-core-dev
 9652020-10-15T22:04:17  *** owowo has joined #bitcoin-core-dev
 9662020-10-15T22:10:19  <luke-jr> btw, why do we use "org.bitcoinfoundation.Bitcoin-Qt" on macOS?
 9672020-10-15T22:11:03  *** vasild has quit IRC
 9682020-10-15T22:12:34  *** vasild has joined #bitcoin-core-dev
 9692020-10-15T22:14:05  <jb55> awkward
 9702020-10-15T22:14:42  <phantomcircuit> luke-jr, iirc wasn't gavin the one signing the macos builds?
 9712020-10-15T22:14:54  <phantomcircuit> probably just legacy from that
 9722020-10-15T22:15:11  <sipa> i think changing it was brought up before, but would break compatibility with existing settings so wasn't done?
 9732020-10-15T22:16:03  <sipa> (it's awkward that it was ever set to that - even when the foundation was actively sponsoring developers - but little that can be done about that now)
 9742020-10-15T22:16:48  <luke-jr> sipa: it doesn't look like it would from the context :/
 9752020-10-15T22:19:40  <sipa> there is some discussion about it in #17462
 9762020-10-15T22:19:42  <gribble> https://github.com/bitcoin/bitcoin/issues/17462 | build: macOS fix Info.plist by RandyMcMillan · Pull Request #17462 · bitcoin/bitcoin · GitHub
 9772020-10-15T22:22:34  *** promag_ is now known as promag
 9782020-10-15T22:24:06  <promag> achow101: is there anything preventing swaping CWallet::database in runtime? so 1) load with bdb 2) swap database 3) write all ?
 9792020-10-15T22:24:25  <promag> *swap to sqlite
 9802020-10-15T22:24:35  <achow101> promag: you might end up missing a few records
 9812020-10-15T22:24:41  <achow101> I'd definitely wouldn't recommend doing that
 9822020-10-15T22:24:51  <promag> not all records are loaded ok
 9832020-10-15T22:25:36  <achow101> promag: all records are loaded, it's just a matter of making sure that "write all" wrote them all
 9842020-10-15T22:25:46  <achow101> there's no existing "write all"
 9852020-10-15T22:25:58  <promag> oh ok
 9862020-10-15T22:26:02  <luke-jr> all records might not be loaded
 9872020-10-15T22:26:05  <luke-jr> IIRC moves don't
 9882020-10-15T22:26:37  <achow101> there are some records that aren't loaded because they aren't useful, just kept around for back compat. obviously back compat doesn't matter if you move to sqlite
 9892020-10-15T22:26:37  <phantomcircuit> sipa, iirc the foundation was paying for the certificate, something about it being easier for a "foundation" to get one than for an individual
 9902020-10-15T22:26:56  <luke-jr> achow101: uh, pretty sure we still show them
 9912020-10-15T22:27:16  <phantomcircuit> who knows if that was true or if it was pretextual though..
 9922020-10-15T22:27:39  <achow101> luke-jr: no? I mean things like "default key" or the original "version"
 9932020-10-15T22:27:47  <achow101> (version is now "minversion")
 9942020-10-15T22:28:00  <promag> don't see a reason to remove load-bdb, that way the user could just send the funds to new wallet and we wouldn't have to do the migration tool
 9952020-10-15T22:28:26  <achow101> The surefire way to migrate format is to grab a cursor on the original db, iterate it, and write every key/value pair in the new db
 9962020-10-15T22:29:07  <luke-jr> achow101: well, I don't think moves get loaded either
 9972020-10-15T22:29:35  <achow101> luke-jr: moves as in the old move rpc?
 9982020-10-15T22:29:39  <luke-jr> yes
 9992020-10-15T22:30:10  <achow101> I thought those records just got renamed and redefined for labels
10002020-10-15T22:30:22  <luke-jr> what?
10012020-10-15T22:30:26  <promag> bdb2sqlite.py incoming
10022020-10-15T22:30:39  <achow101> but also, that's for back compat, and if you are going to sqlite, back compat doesn't matter
10032020-10-15T22:30:56  <luke-jr> achow101: I would be annoyed if migrating my wallet lost data
10042020-10-15T22:31:16  <luke-jr> {"account": "a", "category": "move", "time": 1296345052, "amount": 0.00100000, "otheraccount": "b", "comment": ""},
10052020-10-15T22:31:25  <luke-jr> this shouldn't disappear from listtransactions just because I upgrade
10062020-10-15T22:31:28  <achow101> luke-jr: right, which is also why I prefer the straight record-to-record migration rather than what is loaded in CWallet
10072020-10-15T22:39:49  *** Livestradamus has quit IRC
10082020-10-15T22:39:49  *** IPGlider has quit IRC
10092020-10-15T22:40:55  *** Livestradamus has joined #bitcoin-core-dev
10102020-10-15T22:41:04  *** IPGlider has joined #bitcoin-core-dev
10112020-10-15T22:47:08  *** bitcoin-git has joined #bitcoin-core-dev
10122020-10-15T22:47:08  <bitcoin-git> [bitcoin] sipa opened pull request #20161: Minor Taproot follow-ups (master...202010_taproot_followup) https://github.com/bitcoin/bitcoin/pull/20161
10132020-10-15T22:47:10  *** bitcoin-git has left #bitcoin-core-dev
10142020-10-15T23:00:29  *** AaronvanW has quit IRC
10152020-10-15T23:18:39  *** justanotheruser has joined #bitcoin-core-dev
10162020-10-15T23:35:09  *** snex has joined #bitcoin-core-dev
10172020-10-15T23:35:11  *** bitcoin-git has joined #bitcoin-core-dev
10182020-10-15T23:35:12  <bitcoin-git> [bitcoin] jonatack opened pull request #20162: p2p, compiler warnings: specify Announcement::m_state bitfield to be 8 bits (master...bitfield-too-small-warning) https://github.com/bitcoin/bitcoin/pull/20162
10192020-10-15T23:35:12  *** bitcoin-git has left #bitcoin-core-dev
10202020-10-15T23:35:40  *** snex has left #bitcoin-core-dev
10212020-10-15T23:36:33  <fanquake> Yea I’m fairly certain we can’t change that MacOS string without breaking something
10222020-10-15T23:40:27  *** fjahr_ is now known as fjahr
10232020-10-15T23:46:03  *** proofofkeags has quit IRC
10242020-10-15T23:47:55  *** _joerodgers has joined #bitcoin-core-dev
10252020-10-15T23:52:09  *** joerodgers has quit IRC