12019-07-30T00:00:01 *** VitamineD has quit IRC
22019-07-30T00:04:44 *** tflgen2 has joined #bitcoin-core-dev
32019-07-30T00:08:34 *** AaronvanW has quit IRC
42019-07-30T00:11:22 *** laptop500 has quit IRC
52019-07-30T00:12:14 *** ezegom has quit IRC
62019-07-30T00:12:53 *** ezegom has joined #bitcoin-core-dev
72019-07-30T00:15:43 *** ezegom has quit IRC
82019-07-30T00:15:58 *** ezegom has joined #bitcoin-core-dev
92019-07-30T00:24:35 *** ezegom has quit IRC
102019-07-30T00:24:51 *** ezegom has joined #bitcoin-core-dev
112019-07-30T00:34:53 *** IGHOR has joined #bitcoin-core-dev
122019-07-30T00:35:14 *** bitcoin-git has joined #bitcoin-core-dev
132019-07-30T00:35:14 <bitcoin-git> [bitcoin] ezegom opened pull request #16492: <WIP> Add feeRate argument to bumpFee RPC (master...feerate_bumpfee) https://github.com/bitcoin/bitcoin/pull/16492
142019-07-30T00:35:16 *** bitcoin-git has left #bitcoin-core-dev
152019-07-30T00:38:14 *** bitcoin-git has joined #bitcoin-core-dev
162019-07-30T00:38:14 <bitcoin-git> [bitcoin] ezegom closed pull request #16492: <WIP> Add feeRate argument to bumpFee RPC (master...feerate_bumpfee) https://github.com/bitcoin/bitcoin/pull/16492
172019-07-30T00:38:15 *** bitcoin-git has left #bitcoin-core-dev
182019-07-30T01:01:44 *** Karyon has quit IRC
192019-07-30T01:03:25 *** Karyon has joined #bitcoin-core-dev
202019-07-30T01:03:54 *** bitcoin-git has joined #bitcoin-core-dev
212019-07-30T01:03:54 <bitcoin-git> [bitcoin] ezegom reopened pull request #16492: <WIP> Add feeRate argument to bumpFee RPC (master...feerate_bumpfee) https://github.com/bitcoin/bitcoin/pull/16492
222019-07-30T01:03:55 *** bitcoin-git has left #bitcoin-core-dev
232019-07-30T01:04:36 *** JamesAU has joined #bitcoin-core-dev
242019-07-30T01:04:55 <emilengler> How the CTRL+L shortcut is being handled in bitcoin-qt? Over a QAction or a QShortcut?
252019-07-30T01:11:36 *** sdupre has joined #bitcoin-core-dev
262019-07-30T01:16:23 *** ezegom has quit IRC
272019-07-30T01:16:46 *** ezegom has joined #bitcoin-core-dev
282019-07-30T01:17:22 *** ezegom has joined #bitcoin-core-dev
292019-07-30T01:26:43 *** Chris_Stewart_5 has quit IRC
302019-07-30T01:30:06 *** ezegom has quit IRC
312019-07-30T01:33:03 *** JamesAU has quit IRC
322019-07-30T01:38:23 *** emilengler has quit IRC
332019-07-30T01:42:10 *** sdupre has quit IRC
342019-07-30T01:51:04 *** Chris_Stewart_5 has joined #bitcoin-core-dev
352019-07-30T01:52:58 *** booyah has quit IRC
362019-07-30T01:53:30 *** booyah has joined #bitcoin-core-dev
372019-07-30T01:56:39 *** ezegom has joined #bitcoin-core-dev
382019-07-30T01:57:13 *** ezegom has joined #bitcoin-core-dev
392019-07-30T02:08:47 *** ezegom has quit IRC
402019-07-30T02:09:12 *** Chris_Stewart_5 has quit IRC
412019-07-30T02:12:59 *** ezegom has joined #bitcoin-core-dev
422019-07-30T02:15:58 *** captjakk has quit IRC
432019-07-30T02:16:31 *** captjakk has joined #bitcoin-core-dev
442019-07-30T02:18:22 *** booyah has quit IRC
452019-07-30T02:20:12 *** mryandao has quit IRC
462019-07-30T02:20:13 *** booyah has joined #bitcoin-core-dev
472019-07-30T02:20:31 *** ezegom has quit IRC
482019-07-30T02:20:51 *** captjakk has quit IRC
492019-07-30T02:20:57 *** mryandao has joined #bitcoin-core-dev
502019-07-30T02:22:22 *** elichai2 has quit IRC
512019-07-30T02:26:53 *** DeanGuss has joined #bitcoin-core-dev
522019-07-30T02:27:44 *** mdunnio has quit IRC
532019-07-30T02:36:58 *** ezegom has joined #bitcoin-core-dev
542019-07-30T02:37:20 *** ezegom has joined #bitcoin-core-dev
552019-07-30T02:45:07 *** sanket1729 has joined #bitcoin-core-dev
562019-07-30T03:00:01 *** tflgen2 has quit IRC
572019-07-30T03:04:08 *** vexed__ has joined #bitcoin-core-dev
582019-07-30T03:04:13 *** dviola has quit IRC
592019-07-30T03:15:45 *** whatsup has joined #bitcoin-core-dev
602019-07-30T03:16:39 *** ezegom has quit IRC
612019-07-30T03:17:19 *** ezegom has joined #bitcoin-core-dev
622019-07-30T03:17:45 *** bitcoin-git has joined #bitcoin-core-dev
632019-07-30T03:17:46 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/68da54987df4...2410088003a1
642019-07-30T03:17:46 <bitcoin-git> bitcoin/master 62d3f50 Jon Atack: qa: fix deprecated log.warn in feature_dbcrash test
652019-07-30T03:17:47 <bitcoin-git> bitcoin/master 2410088 fanquake: Merge #16491: qa: fix deprecated log.warn in feature_dbcrash test
662019-07-30T03:17:49 *** bitcoin-git has left #bitcoin-core-dev
672019-07-30T03:18:50 *** bitcoin-git has joined #bitcoin-core-dev
682019-07-30T03:18:50 <bitcoin-git> [bitcoin] fanquake merged pull request #16491: qa: fix deprecated log.warn in feature_dbcrash test (master...test-fix-feature_dbcrash-warn-deprecation) https://github.com/bitcoin/bitcoin/pull/16491
692019-07-30T03:18:53 *** bitcoin-git has left #bitcoin-core-dev
702019-07-30T03:19:19 *** guest62 has joined #bitcoin-core-dev
712019-07-30T03:20:51 *** whatsup has quit IRC
722019-07-30T03:21:45 *** ezegom has quit IRC
732019-07-30T03:28:20 *** nockk100 has joined #bitcoin-core-dev
742019-07-30T03:37:38 <kallewoof> achow101: https://github.com/bitcoin/bitcoin/pull/16440#discussion_r308332901 I basically need the wallet interface to give me a way to sign things from the QT side, and this was the only approach I could think of. sipa suggested I ping you to make sure I wasn't trampling on stuff with the descriptor wallet changes you are working on.
752019-07-30T03:37:44 *** bitcoin-git has joined #bitcoin-core-dev
762019-07-30T03:37:45 <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/2410088003a1...478fe328a793
772019-07-30T03:37:45 <bitcoin-git> bitcoin/master fa6dc7f MarcoFalke: wallet: Enumerate walletdb keys
782019-07-30T03:37:45 *** nockk100 has quit IRC
792019-07-30T03:37:46 <bitcoin-git> bitcoin/master fa6f22b MarcoFalke: wallet: Rename CWalletKey to OldKey
802019-07-30T03:37:46 <bitcoin-git> bitcoin/master 478fe32 fanquake: Merge #16475: wallet: Enumerate walletdb keys
812019-07-30T03:37:48 *** bitcoin-git has left #bitcoin-core-dev
822019-07-30T03:38:39 *** bitcoin-git has joined #bitcoin-core-dev
832019-07-30T03:38:39 <bitcoin-git> [bitcoin] fanquake merged pull request #16475: wallet: Enumerate walletdb keys (master...1907-walletDbKeys) https://github.com/bitcoin/bitcoin/pull/16475
842019-07-30T03:38:40 *** bitcoin-git has left #bitcoin-core-dev
852019-07-30T03:39:13 <achow101> kallewoof: it doesn't interfere, I'll leave a comment
862019-07-30T03:39:26 <kallewoof> Great, thanks!
872019-07-30T03:44:25 *** Eagle[TM] has joined #bitcoin-core-dev
882019-07-30T03:46:22 *** EagleTM has quit IRC
892019-07-30T03:51:03 *** bitcoin-git has joined #bitcoin-core-dev
902019-07-30T03:51:03 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/478fe328a793...33894612c0de
912019-07-30T03:51:04 <bitcoin-git> bitcoin/master faa88d0 MarcoFalke: doc: update labels in CONTRIBUTING.md
922019-07-30T03:51:04 <bitcoin-git> bitcoin/master 3389461 fanquake: Merge #16484: doc: update labels in CONTRIBUTING.md
932019-07-30T03:51:06 *** bitcoin-git has left #bitcoin-core-dev
942019-07-30T03:52:03 *** bitcoin-git has joined #bitcoin-core-dev
952019-07-30T03:52:03 <bitcoin-git> [bitcoin] fanquake merged pull request #16484: doc: update labels in CONTRIBUTING.md (master...1907-docNoTrivial) https://github.com/bitcoin/bitcoin/pull/16484
962019-07-30T03:52:04 *** bitcoin-git has left #bitcoin-core-dev
972019-07-30T03:53:16 *** schnerch_ has joined #bitcoin-core-dev
982019-07-30T03:56:30 *** schnerchi has quit IRC
992019-07-30T03:57:33 *** d_t has joined #bitcoin-core-dev
1002019-07-30T04:02:58 <hugohn> sipa: fwiw I found the issue, the redeem script was expanded in the signing provider but it was a _different_ provider. the caller needs to retrieve the expanded provider (instead of using the original one it got from Parse()) before doing the lookup.
1012019-07-30T04:04:13 <sipa> hugohn: ha
1022019-07-30T04:06:11 <hugohn> silly mistake :D so the correct importing flow is to TopUp(), which generates the cache, then call GetScriptPubKeyMan() to retrieve an expanded provider using the fresh cache, then do DetermineOutputType.
1032019-07-30T04:10:49 <hugohn> *GetSigningProvider, not GetScriptPubKeyMan
1042019-07-30T04:18:49 *** roconnor has quit IRC
1052019-07-30T04:20:13 *** d3spwn has quit IRC
1062019-07-30T04:23:43 *** peleion has quit IRC
1072019-07-30T04:27:11 *** d3spwn has joined #bitcoin-core-dev
1082019-07-30T04:32:07 *** nullptr| has quit IRC
1092019-07-30T04:32:57 *** Anduck has quit IRC
1102019-07-30T04:33:38 *** Anduck has joined #bitcoin-core-dev
1112019-07-30T04:34:28 *** nullptr| has joined #bitcoin-core-dev
1122019-07-30T04:48:09 *** tryphe has quit IRC
1132019-07-30T04:53:35 *** elichai2 has joined #bitcoin-core-dev
1142019-07-30T04:53:54 *** tryphe has joined #bitcoin-core-dev
1152019-07-30T04:56:06 *** d_t has quit IRC
1162019-07-30T05:00:43 *** guest62 has quit IRC
1172019-07-30T05:27:18 *** rex4539 has quit IRC
1182019-07-30T05:37:20 *** bitcoin-git has joined #bitcoin-core-dev
1192019-07-30T05:37:20 <bitcoin-git> [bitcoin] Bushstar reopened pull request #15709: wallet: Do not add "setting" key as unknown (master...walletdb-settings) https://github.com/bitcoin/bitcoin/pull/15709
1202019-07-30T05:37:33 *** bitcoin-git has left #bitcoin-core-dev
1212019-07-30T06:00:02 *** vexed__ has quit IRC
1222019-07-30T06:05:55 *** rex4539 has joined #bitcoin-core-dev
1232019-07-30T06:10:44 *** keyboardsurfer has joined #bitcoin-core-dev
1242019-07-30T06:34:52 *** kcalvinalvin has joined #bitcoin-core-dev
1252019-07-30T06:38:14 *** guest69 has joined #bitcoin-core-dev
1262019-07-30T07:00:47 *** peleion has joined #bitcoin-core-dev
1272019-07-30T07:02:47 *** elichai2 has quit IRC
1282019-07-30T07:12:28 *** morcos has quit IRC
1292019-07-30T07:14:03 *** AaronvanW has joined #bitcoin-core-dev
1302019-07-30T07:15:17 *** Eagle[TM] has quit IRC
1312019-07-30T07:16:49 *** Aaronvan_ has joined #bitcoin-core-dev
1322019-07-30T07:20:21 *** AaronvanW has quit IRC
1332019-07-30T07:21:17 *** morcos has joined #bitcoin-core-dev
1342019-07-30T07:26:08 *** davec has quit IRC
1352019-07-30T07:27:10 *** davec has joined #bitcoin-core-dev
1362019-07-30T07:29:46 *** kljasdfvv has joined #bitcoin-core-dev
1372019-07-30T07:39:07 *** rex4539 has quit IRC
1382019-07-30T07:53:29 *** jungly has joined #bitcoin-core-dev
1392019-07-30T07:59:43 *** Guyver2 has joined #bitcoin-core-dev
1402019-07-30T08:00:44 *** laptop500 has joined #bitcoin-core-dev
1412019-07-30T08:04:52 *** niska has quit IRC
1422019-07-30T08:11:00 *** niska has joined #bitcoin-core-dev
1432019-07-30T08:30:37 *** setpill has joined #bitcoin-core-dev
1442019-07-30T08:30:40 <fanquake> achow101: In https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Wallet-Class-Structure-Changes#cwallet-changes, can you explain "These may all be the same ScriptPubKeyManager or different."? Reading through I got the impression that legacy/p2sh/bech would each be in separate ScriptPubKeyManagers.
1452019-07-30T08:31:31 <fanquake> Is/would there any benefit to keeping them siloed ?
1462019-07-30T08:32:10 *** bitcoin-git has joined #bitcoin-core-dev
1472019-07-30T08:32:10 <bitcoin-git> [bitcoin] meshcollider pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/33894612c0de...ff57fb457892
1482019-07-30T08:32:11 <bitcoin-git> bitcoin/master 914923d Peter Bushnell: Add setting as known type
1492019-07-30T08:32:11 <bitcoin-git> bitcoin/master ff57fb4 MeshCollider: Merge #15709: wallet: Do not add "setting" key as unknown
1502019-07-30T08:32:13 *** bitcoin-git has left #bitcoin-core-dev
1512019-07-30T08:32:50 *** bitcoin-git has joined #bitcoin-core-dev
1522019-07-30T08:32:50 <bitcoin-git> [bitcoin] meshcollider merged pull request #15709: wallet: Do not add "setting" key as unknown (master...walletdb-settings) https://github.com/bitcoin/bitcoin/pull/15709
1532019-07-30T08:32:51 *** bitcoin-git has left #bitcoin-core-dev
1542019-07-30T08:36:00 *** bitcoin-git has joined #bitcoin-core-dev
1552019-07-30T08:36:01 <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ff57fb457892...53b5a4f7eca9
1562019-07-30T08:36:01 <bitcoin-git> bitcoin/master e0324c3 Aaron Clauson: Updated python command in readme so it will work on systems that have both...
1572019-07-30T08:36:02 <bitcoin-git> bitcoin/master 53b5a4f fanquake: Merge #16483: doc: update Python command in msvc readme
1582019-07-30T08:36:03 *** bitcoin-git has left #bitcoin-core-dev
1592019-07-30T08:36:37 <meshcollider> fanquake: for example, if you have an old wallet, the legacy wallet structure is wrapped as a scriptpubkeymanager, and all address types would point to it
1602019-07-30T08:36:39 *** kcalvinalvin has quit IRC
1612019-07-30T08:36:58 *** bitcoin-git has joined #bitcoin-core-dev
1622019-07-30T08:36:59 <bitcoin-git> [bitcoin] fanquake merged pull request #16483: doc: update Python command in msvc readme (master...update_msvc_readme) https://github.com/bitcoin/bitcoin/pull/16483
1632019-07-30T08:37:00 *** bitcoin-git has left #bitcoin-core-dev
1642019-07-30T08:39:27 <fanquake> meshcollider: right, cheers
1652019-07-30T08:41:54 <meshcollider> fanquake: in a pure descriptor wallet you would probably have 6 separate scriptpubkeymanagers though yes
1662019-07-30T08:45:09 <meshcollider> if you have a wpkh() descriptor for your bech32 addresses it wouldnt make sense for the legacy output type to point to that for example
1672019-07-30T08:46:03 *** kristapsk___ has joined #bitcoin-core-dev
1682019-07-30T08:46:15 <fanquake> meshcollider: ð
1692019-07-30T08:47:25 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1702019-07-30T08:48:08 *** kristapsk_ has quit IRC
1712019-07-30T09:00:01 *** keyboardsurfer has quit IRC
1722019-07-30T09:09:56 *** timothy has joined #bitcoin-core-dev
1732019-07-30T09:12:27 *** victorSN has quit IRC
1742019-07-30T09:15:12 *** victorSN has joined #bitcoin-core-dev
1752019-07-30T09:15:28 *** espadrine has joined #bitcoin-core-dev
1762019-07-30T09:18:10 *** ezegom has joined #bitcoin-core-dev
1772019-07-30T09:23:18 *** ezegom has quit IRC
1782019-07-30T09:40:08 *** tryphe has quit IRC
1792019-07-30T09:40:42 *** tryphe has joined #bitcoin-core-dev
1802019-07-30T09:55:08 *** guest69 has quit IRC
1812019-07-30T10:07:34 *** bitcoin-git has joined #bitcoin-core-dev
1822019-07-30T10:07:34 <bitcoin-git> [bitcoin] practicalswift closed pull request #16312: tests: Reduce memory usage by 0.5 GB when compiling script_tests.cpp (master...fix-absurd-memory-usage-when-compiling-script_build) https://github.com/bitcoin/bitcoin/pull/16312
1832019-07-30T10:07:35 *** bitcoin-git has left #bitcoin-core-dev
1842019-07-30T10:56:03 *** DeanGuss has quit IRC
1852019-07-30T10:56:55 *** DeanGuss has joined #bitcoin-core-dev
1862019-07-30T11:06:37 <jonasschnelli> sipa, BlueMatt: I'm unsure about the fixed 4byte message string. We would "waste" 3 bytes on each inv compared to the short-id approach. I don't expect much collisions with a space of 256-12 possible short-IDs.
1872019-07-30T11:07:10 *** lightlike has joined #bitcoin-core-dev
1882019-07-30T11:07:25 <jonasschnelli> New commands that are not broadly used on the network could still use a string,.... and only get a short ID after some time (to avoid collisions).
1892019-07-30T11:08:39 <jonasschnelli> What we could do, instead, of using the value 1-12 for string based message commands, ... we could use value 0 as an indicator for a 4 byte string base command.
1902019-07-30T11:09:10 <jonasschnelli> (compared to the fixed 4 bytes command it would be +1 byte)
1912019-07-30T11:09:46 <jonasschnelli> The argument, "but parsing variable length!" I don't buy that completely,.. because one needs to deal with vlen anyways
1922019-07-30T11:10:44 *** DeanGuss has quit IRC
1932019-07-30T11:11:15 <jonasschnelli> you need to verify the MAC tag therefore deserializing,... so one needs to read the whole content of the stream anyways. Maybe I don't see the point, but messages are vlen anyway.
1942019-07-30T11:11:52 <jonasschnelli> Skipping a message needs one to read the "header" (in v2 case the command ID/name)
1952019-07-30T11:11:59 *** emilengler has joined #bitcoin-core-dev
1962019-07-30T11:17:27 *** anemous has joined #bitcoin-core-dev
1972019-07-30T11:17:39 *** brianhoffman_ has joined #bitcoin-core-dev
1982019-07-30T11:19:51 *** Sentineo has quit IRC
1992019-07-30T11:20:07 *** Sentineo has joined #bitcoin-core-dev
2002019-07-30T11:20:28 *** brianhoffman has quit IRC
2012019-07-30T11:20:29 *** brianhoffman_ is now known as brianhoffman
2022019-07-30T11:31:48 *** anemous has quit IRC
2032019-07-30T11:36:40 *** anemous has joined #bitcoin-core-dev
2042019-07-30T11:37:07 *** jungly has quit IRC
2052019-07-30T11:38:37 *** jungly has joined #bitcoin-core-dev
2062019-07-30T11:38:57 <jonasschnelli> Is it just me or does travis hang while fetching the pull request page? https://travis-ci.org/bitcoin/bitcoin/pull_requests
2072019-07-30T11:39:05 <jonasschnelli> idles forever at my end
2082019-07-30T11:51:11 *** anemous has quit IRC
2092019-07-30T11:55:11 *** jonatack has joined #bitcoin-core-dev
2102019-07-30T12:00:02 *** espadrine has quit IRC
2112019-07-30T12:04:22 *** Mister_X1 has joined #bitcoin-core-dev
2122019-07-30T12:04:39 <fanquake> jonasschnelli: loading ok for me here.
2132019-07-30T12:15:29 <jonasschnelli> fanquake: maybe a local browser issue then
2142019-07-30T12:15:42 <jonasschnelli> jup.
2152019-07-30T12:30:30 *** elichai2 has joined #bitcoin-core-dev
2162019-07-30T13:43:07 *** bitcoin-git has joined #bitcoin-core-dev
2172019-07-30T13:43:08 <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/53b5a4f7eca9...bd35ec36f5d6
2182019-07-30T13:43:08 <bitcoin-git> bitcoin/master 29ee4c4 Daniel Kraft: Specify AM_CPPFLAGS for ZMQ.
2192019-07-30T13:43:09 <bitcoin-git> bitcoin/master bd35ec3 Wladimir J. van der Laan: Merge #16434: build: Specify AM_CPPFLAGS for ZMQ
2202019-07-30T13:43:11 *** bitcoin-git has left #bitcoin-core-dev
2212019-07-30T13:44:07 *** bitcoin-git has joined #bitcoin-core-dev
2222019-07-30T13:44:07 <bitcoin-git> [bitcoin] laanwj merged pull request #16434: build: Specify AM_CPPFLAGS for ZMQ (master...zmq-cppflags) https://github.com/bitcoin/bitcoin/pull/16434
2232019-07-30T13:44:10 *** bitcoin-git has left #bitcoin-core-dev
2242019-07-30T13:49:46 <stevenroose> sipa, achow: importpubkey ought to recognize p2shwpkh addresses, right?
2252019-07-30T13:49:56 <stevenroose> ah nvm
2262019-07-30T13:50:28 *** d_t has joined #bitcoin-core-dev
2272019-07-30T13:50:58 *** ezegom has joined #bitcoin-core-dev
2282019-07-30T13:53:45 *** michagogo has quit IRC
2292019-07-30T14:12:15 <elichai2> I finished with the descriptors but I'm trying to figure out `IsSolvable` right now. and i'm not sure how does taproot fit in the SigningProvider API. the first thing oviously to check is to convert the point to P2PK and check if it can sign for that key. but if it can't I need to somhow be able to reconstruct the tree out of the signing provider. I'm thinking of adding it as a member, but is it okay that there
2302019-07-30T14:12:16 <elichai2> might be duplicate scripts between that tree and the `scripts` map? or maybe I should store there a tree to `CScriptID` and then get the right scripts through that map and try to solve for all the possible leafs(and the first that return true i'll return true)
2312019-07-30T14:17:03 <elichai2> hmm and even if I have the correct tweak I need to find the correct internal key, and I guess brute forcing the tweak against all the pubkeys in the map isn't a good solution heh
2322019-07-30T14:21:48 *** mryandao has quit IRC
2332019-07-30T14:25:29 *** mryandao has joined #bitcoin-core-dev
2342019-07-30T14:32:41 <elichai2> so I can negate the tweak and add it to the taproot key to get the internal key. cool
2352019-07-30T14:34:11 *** spinza has quit IRC
2362019-07-30T14:38:43 *** spinza has joined #bitcoin-core-dev
2372019-07-30T14:39:09 <BlueMatt> jonasschnelli: I really hope we're not so starved for bandwidth that we can't afford 3 extra bytes
2382019-07-30T14:39:24 <BlueMatt> and if we are, we can just have more things in each inv, no?
2392019-07-30T14:42:55 *** mdunnio has joined #bitcoin-core-dev
2402019-07-30T14:44:59 <jonasschnelli> BlueMatt: What does afford means in that context? :-) We can afford it, but It's more a question of waste/optimizing.
2412019-07-30T14:45:21 <jonasschnelli> BlueMatt: bundling inv's.. sure. Not always possible.
2422019-07-30T14:45:23 <BlueMatt> over-optimizing is the root of all evil :p
2432019-07-30T14:45:38 <jonasschnelli> Sure. But I think we are in an acceptable range of optimizing.
2442019-07-30T14:46:31 <BlueMatt> I mean if we're in a place where we can't bundle invs, then we have low tx traffic, and we can afford a few more bytes per message without anyone caring about the bw usage
2452019-07-30T14:46:33 <BlueMatt> if we're not, we can bundle more
2462019-07-30T14:46:53 <BlueMatt> I just dont really think an extra 3 bytes on a 32 byte thing to send really has much cost
2472019-07-30T14:47:00 <BlueMatt> in exchange for a constant length header
2482019-07-30T14:47:04 <BlueMatt> which is way easier to deal with
2492019-07-30T14:48:33 *** mdunnio has quit IRC
2502019-07-30T14:49:42 *** mdunnio has joined #bitcoin-core-dev
2512019-07-30T14:50:54 *** d_t has quit IRC
2522019-07-30T14:50:57 *** mdunnio has quit IRC
2532019-07-30T14:51:28 *** mdunnio has joined #bitcoin-core-dev
2542019-07-30T14:54:34 <sipa> jonasschnelli: i don't care much about variable length either, but it seems a sticking point for BlueMatt
2552019-07-30T14:55:41 <sipa> jonasschnelli: but also just diminishing returns; there is a 16 byte MAC per message; maybe saving 8 bytes per message matters, but saving 3 more is quickly becoming negligable for all but the shortest messages
2562019-07-30T14:56:48 <sipa> elichai2: IsSolvable meams "you know enough to sign under all conditions, if you had the private keys"
2572019-07-30T14:57:13 <sipa> elichai2: taproot descriptors would always be solvable
2582019-07-30T14:57:38 *** roconnor has joined #bitcoin-core-dev
2592019-07-30T14:57:40 <elichai2> i'm talking about a different `IsSolvable` haha
2602019-07-30T14:57:43 <elichai2> in sign.cpp
2612019-07-30T14:57:57 <elichai2> (the one that's used in descriptors_test.cpp )
2622019-07-30T14:57:59 <sipa> oh, i see
2632019-07-30T14:59:03 *** bitcoin-git has joined #bitcoin-core-dev
2642019-07-30T14:59:03 <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/bd35ec36f5d6...74f1a27f2f45
2652019-07-30T14:59:03 <bitcoin-git> bitcoin/master 0c78e49 practicalswift: tests: Switch one of the Travis jobs to an unsigned char environment (-fun...
2662019-07-30T14:59:04 <bitcoin-git> bitcoin/master 74f1a27 Wladimir J. van der Laan: Merge #15134: tests: Switch one of the Travis jobs to an unsigned char env...
2672019-07-30T14:59:05 *** bitcoin-git has left #bitcoin-core-dev
2682019-07-30T14:59:33 *** bitcoin-git has joined #bitcoin-core-dev
2692019-07-30T14:59:33 <bitcoin-git> [bitcoin] laanwj merged pull request #15134: tests: Switch one of the Travis jobs to an unsigned char environment (-funsigned-char) (master...unsigned-char) https://github.com/bitcoin/bitcoin/pull/15134
2702019-07-30T14:59:35 *** bitcoin-git has left #bitcoin-core-dev
2712019-07-30T14:59:41 <sipa> elichai2: the concept of solvable there needs to go away i think
2722019-07-30T14:59:55 <sipa> elichai2: it captures whether you're able to estimate fees
2732019-07-30T15:00:02 *** Mister_X1 has quit IRC
2742019-07-30T15:00:17 <elichai2> wait what. I thought it checks if you have the right script+private key
2752019-07-30T15:00:30 <elichai2> like, it literally tries to produce a signature
2762019-07-30T15:02:10 <jonasschnelli> BlueMatt, sipa: sorry... was on the phone. BlueMatt: what are the benefits of a constant length "header"?
2772019-07-30T15:02:32 *** reardencode has quit IRC
2782019-07-30T15:02:35 <jonasschnelli> Also, V2's "header" is the encrypted length & MAC TAG
2792019-07-30T15:03:30 *** lliehu1 has joined #bitcoin-core-dev
2802019-07-30T15:04:35 <jonasschnelli> A 32byte field for defining the message type seems very large for the message variety we are expecting in the next years.
2812019-07-30T15:04:48 <jonasschnelli> I also don't fully buy into the anit-collision argument
2822019-07-30T15:05:58 <jonasschnelli> Maybe if we consider collisions be a thing in the future, we could say short-ID tables are bound to a certain net-protocol version?
2832019-07-30T15:06:23 <sipa> elichai2: it basically checks if you can sign with a dummysigner (which doesn't need private keys)
2842019-07-30T15:06:38 <sipa> elichai2: you shouldn't need taproot specific logic; just signing logix
2852019-07-30T15:08:17 <emilengler> How does bitcoin-qt detects when Ctrl-L was pressed? I can't find something like a QShortcut or a QAction
2862019-07-30T15:08:49 *** reardencode has joined #bitcoin-core-dev
2872019-07-30T15:08:54 <elichai2> sipa: yeah but to "try" you sign with the dummy signature I need to convert it to something it knows. it calls `ProduceSignature` which does things like: https://github.com/bitcoin/bitcoin/blob/master/src/script/sign.cpp#L213
2882019-07-30T15:10:09 <jonasschnelli> [16:46:57] <BlueMatt> in exchange for a constant length header [...] which is way easier to deal with
2892019-07-30T15:10:32 <jonasschnelli> ^^^ can you elaborate a bit more on this?
2902019-07-30T15:10:38 <elichai2> so I need to "try" producing signatures for the scripts, right? because I can't asusme it's using a dummy signer and will return true for whatever pubkey. so I need to try with the internal key as P2PK and then with each script until `SignStep` returns true
2912019-07-30T15:11:18 <jonasschnelli> You have a raw packet on the stream [3 bytes encrypted length] + [ ? encrypted payload ] + [ 16 bytes MAC]
2922019-07-30T15:11:28 <jonasschnelli> (varlen already)
2932019-07-30T15:11:35 <jonasschnelli> you check the mac and decrypt
2942019-07-30T15:12:32 <jonasschnelli> then "deserialize" the message ([ ? payload]), where the header is actually the message command (which is varlen compared to the 24byte V1 headers)
2952019-07-30T15:13:10 *** reardencode has quit IRC
2962019-07-30T15:13:26 <phantomcircuit> jonasschnelli, it's infinitely easier to parse a constant length header than a variable length one
2972019-07-30T15:13:56 <jonasschnelli> phantomcircuit: easier in what context?
2982019-07-30T15:14:10 <jonasschnelli> I mean the message that follows has very likely also variable length fields
2992019-07-30T15:14:37 *** Chris_Stewart_5 has quit IRC
3002019-07-30T15:15:07 <sipa> elichai2: yes, you need taproot signing logic
3012019-07-30T15:15:23 <sipa> if you have that, IsSolvable will work automatically
3022019-07-30T15:15:29 *** davterra has quit IRC
3032019-07-30T15:17:17 *** reardencode has joined #bitcoin-core-dev
3042019-07-30T15:18:49 <elichai2> great. so i'll add a map of taproot trees to `FlatSigningProvider` and recalc the internal key by negation, Thanks :)
3052019-07-30T15:19:32 *** setpill has quit IRC
3062019-07-30T15:20:29 *** bitcoin-git has joined #bitcoin-core-dev
3072019-07-30T15:20:29 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #16493: test: Bump rpc_timeout in feature_dbcrash (master...1907-testRpcTimeoutBump) https://github.com/bitcoin/bitcoin/pull/16493
3082019-07-30T15:20:42 *** bitcoin-git has left #bitcoin-core-dev
3092019-07-30T15:26:53 <sipa> elichai2: i'd add TaprootPath entries to SigningProvider (with a map from keyid, or from pubkey, unsure), one for each spending path
3102019-07-30T15:27:26 <sipa> elichai2: for key paths, it would contain the tweak and the pubkey it's derived from
3112019-07-30T15:27:46 <sipa> elichai2: for script paths it would contain leaf version, script, and Merkle path
3122019-07-30T15:28:04 <sipa> the advantage is that this approach works evenn when you don't know all scripts
3132019-07-30T15:28:23 <elichai2> hmm so you're suggesting to split it to paths in the first place for the situation that you don't know all the paths
3142019-07-30T15:28:33 <sipa> right
3152019-07-30T15:28:41 <elichai2> although i'll argue that you shouldn't be able to sign for an address that you don't know all the paths for
3162019-07-30T15:28:49 <sipa> i don't
3172019-07-30T15:29:01 <elichai2> because that mean you might not really "own" the coins
3182019-07-30T15:29:43 <sipa> there is a difference between treating a coin as yours, and participating in signing
3192019-07-30T15:30:11 <sipa> the descriptor side of things will always have the whole tree, and is used for determining what is yours
3202019-07-30T15:30:12 <elichai2> and in the end of the path do you think it should be a CScript or a CScriptID to the map of scripts that is already that (and probably will already have those scripts because i'm using descriptors for the leafs so ExpandHelper will fill it up)
3212019-07-30T15:30:28 <elichai2> sipa: right
3222019-07-30T15:30:30 <sipa> i think it can be CScript
3232019-07-30T15:30:42 <elichai2> even with the redundancy?
3242019-07-30T15:31:05 <sipa> the scripts shouldn't be in the normal script map i think
3252019-07-30T15:31:17 <sipa> as they're distinct anyway
3262019-07-30T15:31:42 <sipa> as in: they ought to be a distinct namespace, because taproot scripts have different semantics
3272019-07-30T15:32:38 <hugohn> sipa: wouldn't that complicate the new IsMine() logic, which is now just a look up in the "regular" scripts map?
3282019-07-30T15:32:48 <elichai2> sipa: but if I have `tap(key, [p2k(...), p2kh(...)])` I want to use the PKDescriptor and PKHDescriptor descriptors
3292019-07-30T15:33:04 <elichai2> and in the end it's still `OP_CHECKSIG`
3302019-07-30T15:34:26 *** kljasdfvv has quit IRC
3312019-07-30T15:35:29 <sipa> hugohn: the IsMine logic will just be descriptors
3322019-07-30T15:35:44 <sipa> in no way should taproot stuff influence the old legacy IsMine code
3332019-07-30T15:36:00 <sipa> elichai2: ok, so?
3342019-07-30T15:37:34 <sipa> elichai2: expanding a PK descriptor gives you a script; inside a taproot descriptor you put that in the tree rather than directly in the script map
3352019-07-30T15:37:52 <hugohn> yeah I mean for native descriptor wallets, not the legacy ones. i.e., DescriptorScriptPubKeyMan::IsMine() . That will have to change if we add tapscripts to a different map, no?
3362019-07-30T15:38:32 <sipa> hugohn: no
3372019-07-30T15:38:32 <elichai2> I just realized that when I'm expanding I use `MakeScripts` on the subdescriptors and not`ExpandHelper` so it wouldn't automatically get added to the FlatSigningProvider
3382019-07-30T15:38:49 <sipa> hugohn: there is a map of scriptPubKeys
3392019-07-30T15:39:10 <sipa> hugohn: that is not the same map as the mapScripts in signing providers
3402019-07-30T15:39:28 <elichai2> makes sense. so the ExpandHelper could also generate all the possible script paths and add them to the provider
3412019-07-30T15:39:57 <sipa> right, or the taproot specific code does that
3422019-07-30T15:40:06 <elichai2> right
3432019-07-30T15:41:47 <elichai2> btw, I see that your code right now hard codes `0xc0` in the consensus code, and it doesn't compose it in a way. I'm thinking if it's worth the effort to really add a leaf version already or do the same (which isn't good in engineering stand point but not sure if it's worth the effort assuming that other parts hard code it)
3442019-07-30T15:42:33 *** captjakk has joined #bitcoin-core-dev
3452019-07-30T15:42:56 <sipa> elichai2: i think it makes sense that descripts for now only support tapscript v0
3462019-07-30T15:43:02 <sipa> *descriptors
3472019-07-30T15:43:27 <sipa> i think for psbt extensions we do want to support encoding other tapscript versions
3482019-07-30T15:43:40 <elichai2> ð yeah. probably won't see a new tapscript version for a while haha
3492019-07-30T15:46:07 <hugohn> sipa: you're right I got those 2 mixed up, oops. So it's the `LookupHelper` for SigningProvider that will have to change to account for tapscripts, IsMine won't.
3502019-07-30T15:46:54 <sipa> hugohn: i don't think the descriptor wallet code will need to change at all
3512019-07-30T15:47:17 <sipa> hugohn: taproot descriptors will still be populating the list of scriptPubKeys to watch for
3522019-07-30T15:47:48 <sipa> the mapScripts/taproot tree elichai2 and i were talking about is for internal scripts, not scriptPubKeys
3532019-07-30T15:48:26 *** jcorgan has joined #bitcoin-core-dev
3542019-07-30T15:48:48 <elichai2> yep. the scriptPubKey is the easiest part.
3552019-07-30T15:48:52 <phantomcircuit> jonasschnelli, it means you can just copy the a buffer into the fields without much real logic
3562019-07-30T15:52:05 <sipa> jonasschnelli: well for new message types they can be selected to not collide with existing ones
3572019-07-30T15:52:15 <hugohn> sipa: right descriptor part won't change, but the Signing Provider will need to change, right? as it involves looking up for things to sign which include internal scripts?
3582019-07-30T15:52:21 *** afigs has joined #bitcoin-core-dev
3592019-07-30T15:52:32 <sipa> hugohn: signingprovider will get extra fields yes
3602019-07-30T15:52:44 <sipa> but they should 't really interact with descriptor wallets
3612019-07-30T15:53:30 <sipa> jonasschnelli: but it also supports "uncoordinated new messages" because until there are 1000s of message types, the chance for collisions will be negligae
3622019-07-30T15:53:39 <elichai2> phantomcircuit: bitcoin core already uses variables sizes for everything.
3632019-07-30T15:55:00 <sipa> elichai2: i think BlueMatt's comment is mostly for the sake of other implementations
3642019-07-30T15:55:40 <jonasschnelli> phantomcircuit: I get the point. But in out context and with the V2 encryption packet that is already vlen this point has little weight IMO
3652019-07-30T15:56:05 <elichai2> oh. but they will need to implement the variable size type/functions anyway for the rest of the stuff in bitcoin. so why not use the same type we use everywhere?
3662019-07-30T15:56:06 <BlueMatt> elichai2: we actually dont for the headers
3672019-07-30T15:56:14 <sipa> jonasschnelli: i'm personally perfectly fine with the approach you suggested, but given BlueMatt's criticism i found this idea of just shortening the field perhaps a useful middle grou d
3682019-07-30T15:56:39 <jonasschnelli> Yes. I think in general it's an acceptable idea... but...
3692019-07-30T15:56:40 <elichai2> BlueMatt: oh really? ok. sorry, I don't know much about the p2p layer so i'll remove myself from this conversation ha
3702019-07-30T15:57:09 <BlueMatt> jonasschnelli: the header is not, no? and its a different layer - net vs protocol/net_processing deserialization
3712019-07-30T15:57:21 <BlueMatt> the net code isnt aware of what the message contains, or how to deserialize it
3722019-07-30T15:57:25 <BlueMatt> and it is dead simple
3732019-07-30T15:58:12 <BlueMatt> but, honestly, I dont think its *really* worth it. I find variable length headers distasteful given the million and one issues that have existed in implementing them, but if you really, really want to save 3 bytes, I'm not gonna argue for them
3742019-07-30T15:58:31 <jonasschnelli> In current v2: the headers is the short-ID where ID 1-12 is a varlen string message-command
3752019-07-30T15:58:33 <BlueMatt> dont think endlessly debating it is really worth it, that is
3762019-07-30T15:58:59 <BlueMatt> right, yes, I was under the impression that was the only variable length in the message header/the part that net has to deal with
3772019-07-30T15:59:06 * BlueMatt -> lunch
3782019-07-30T15:59:13 <sipa> well, the payload is also variable size, obviously
3792019-07-30T15:59:24 <jonasschnelli> BlueMatt: From a design perspective, I dislike variable length headers as much as you do. But I think in our case its fine and the complexity it adds is near 0.
3802019-07-30T15:59:31 <jonasschnelli> sipa: excactly.
3812019-07-30T16:00:10 <BlueMatt> the compexity it adds is, however, non-0, and the cost it removes *is* 0 :p
3822019-07-30T16:00:18 <hugohn> sipa: descriptors do depend on the Signing Providers to expand their cache, so they interact somewhat? (which was my bug yesterday). But descriptors don't need to know how SPs generate the cache (and therefore won't need to change at all for Taproot to work).
3832019-07-30T16:00:32 <jonasschnelli> BlueMatt: I disagree. :)
3842019-07-30T16:00:44 <sipa> hugohn: yes, descriptors very much interact with signingproviders
3852019-07-30T16:00:54 <sipa> hugohn: but the wallet code shouldn't
3862019-07-30T16:00:54 <jonasschnelli> That's why I'd like to hear what the "non-0 complexity" is,.. why a vlen headers adds complexity in our case (not in a general case)
3872019-07-30T16:00:59 <jonasschnelli> BlueMatt: ^
3882019-07-30T16:01:18 <hugohn> sipa: right. ok it's clear to me now. thanks!
3892019-07-30T16:01:49 <sipa> jonasschnelli: actually one issue about the variable length header scares me a bit, namely tha6 the encryption is designed to hide message types
3902019-07-30T16:02:07 <sipa> though i need to read up on the openssl chacha/poly1305 design to understand it better
3912019-07-30T16:03:34 <jonasschnelli> sipa: Yeah, that's maybe a point. Though, in most cases, you'll never ever use variable length messages.
3922019-07-30T16:03:53 <jonasschnelli> BIP324 defines short ids (single byte command) for every message.
3932019-07-30T16:04:00 <jonasschnelli> New messages could do the same,...
3942019-07-30T16:04:11 <sipa> jonasschnelli: there may be coordination issues there
3952019-07-30T16:04:17 <jonasschnelli> using string based message commands is more for extensions that don't want to deal with short IDs
3962019-07-30T16:04:43 <jonasschnelli> sipa: eventually,... but as long as all new message types come with a short ID, I don't think there is.
3972019-07-30T16:04:57 *** mdunnio has quit IRC
3982019-07-30T16:05:02 <jonasschnelli> The fallback to string base commands is unused in the ideal case
3992019-07-30T16:05:30 <jonasschnelli> except a fork-coin adds shit messages and don't bother with adding a short ID
4002019-07-30T16:05:34 *** mdunnio has joined #bitcoin-core-dev
4012019-07-30T16:06:39 *** mdunnio has quit IRC
4022019-07-30T16:06:53 *** mdunnio has joined #bitcoin-core-dev
4032019-07-30T16:06:55 <phantomcircuit> jonasschnelli, it means you can have a simple bent pipe that isn't doing decryption but does understand the headers
4042019-07-30T16:07:07 <jonasschnelli> And I do think 3 bytes matter. Especially if we know that almost 50% of our messages. are <=64bytes.
4052019-07-30T16:07:31 <jonasschnelli> Which results that 3bytes may be 5%.
4062019-07-30T16:07:38 <jonasschnelli> (BTCFlood though)
4072019-07-30T16:08:03 <jonasschnelli> phantomcircuit: ehm?
4082019-07-30T16:08:45 <jonasschnelli> If you don't understand decryption, you won't be able to read the payload length and therefore would never come to the point where a fix length header would matter? Not?
4092019-07-30T16:09:32 *** pinheadmz_ has quit IRC
4102019-07-30T16:09:42 <sipa> jonasschnelli: let me think think things through the next days
4112019-07-30T16:09:49 <sipa> hugohn: yw
4122019-07-30T16:10:18 <jonasschnelli> sipa: Sure. Thanks for digging in!
4132019-07-30T16:10:44 <jonasschnelli> phantomcircuit: https://bitcoinbuilds.org/v2.png
4142019-07-30T16:10:50 *** afigs has quit IRC
4152019-07-30T16:11:17 * jonasschnelli break
4162019-07-30T16:12:04 *** bitcoin-git has joined #bitcoin-core-dev
4172019-07-30T16:12:04 <bitcoin-git> [bitcoin] promag opened pull request #16494: wallet: Drop support to serialize OldKey (master...2019-07-drop-oldkey-serialize) https://github.com/bitcoin/bitcoin/pull/16494
4182019-07-30T16:12:12 *** bitcoin-git has left #bitcoin-core-dev
4192019-07-30T16:12:51 *** emilengler has quit IRC
4202019-07-30T16:17:11 <phantomcircuit> jonasschnelli, the length is encrypted?
4212019-07-30T16:17:32 <jonasschnelli> jup
4222019-07-30T16:17:35 <phantomcircuit> i guess that makes sense
4232019-07-30T16:17:38 <phantomcircuit> shrug
4242019-07-30T16:20:04 <BlueMatt> jonasschnelli: to answer your question, in a general case, the way you write a network layer (eg the way bitcoin core does it today) is step 1) read message header, step 2) check stuff about the header, step 3) allocate buffer for the size it told you, step 4) read message. this keeps things nice and simple, you dont have much allocation complexity and you avoid most buffer overflow issues if you misallocate in your network stack.
4252019-07-30T16:20:05 <BlueMatt> hence my (strongly-held) view that variable-length, when it is reasonably avoidable, is always bad protocol design. obviously there are tradeoffs, but more lines of code that allocate and then read into a buffer in async networking have been the source of such a huge number of buffer overflow vulns over the years....
4262019-07-30T16:20:43 <BlueMatt> in this case its not as much an issue cause at least its only twice
4272019-07-30T16:20:58 <BlueMatt> so, again, not worth endless debate around it, I'm happy to not care anymore.
4282019-07-30T16:21:05 <BlueMatt> just answering your question of why
4292019-07-30T16:21:42 *** wbnns has quit IRC
4302019-07-30T16:21:46 *** tryphe_ has joined #bitcoin-core-dev
4312019-07-30T16:22:13 *** mariorz has quit IRC
4322019-07-30T16:22:40 <jonasschnelli> thanks! i totaly agree with all of your point... but... we deal with inner messages (decrypted)
4332019-07-30T16:23:09 *** tryphe has quit IRC
4342019-07-30T16:23:37 <jonasschnelli> the buffer is allocated and the data has ben read regardless of a fix length header or not (in our case of encrypted messages)
4352019-07-30T16:23:48 <sipa> jonasschnelli: the 'encrypted length' field covers the sum of message type and payload, or not?
4362019-07-30T16:24:02 <sipa> (i think it should)
4372019-07-30T16:24:04 *** NicolasDorier has quit IRC
4382019-07-30T16:24:18 *** fjahr has quit IRC
4392019-07-30T16:25:05 <jonasschnelli> the payload of a encrypted packet is [message command short ID + message payload]
4402019-07-30T16:25:26 <jonasschnelli> so the encrypted length is on the network layer
4412019-07-30T16:25:35 <sipa> ok, so the encrypted length is the length of the encrypted payload, not just the message payload?
4422019-07-30T16:25:45 <jonasschnelli> yes
4432019-07-30T16:25:50 *** pinheadmz has joined #bitcoin-core-dev
4442019-07-30T16:26:16 <BlueMatt> jonasschnelli: I'm not sure you read my point? my pont was that most protocols have variable length bodies, but those are handled at a different level than the constant-length header.
4452019-07-30T16:26:16 *** fjahr has joined #bitcoin-core-dev
4462019-07-30T16:26:51 *** NicolasDorier has joined #bitcoin-core-dev
4472019-07-30T16:26:52 *** wbnns has joined #bitcoin-core-dev
4482019-07-30T16:27:13 <sipa> BlueMatt: right, but here it is still a fixed length header + variable length message; the command is just the first few bytes of that variable length message
4492019-07-30T16:27:48 <sipa> so there are no additional variable length buffers or so involved
4502019-07-30T16:28:02 <sipa> just a decision where the command ends and where the message payload begins
4512019-07-30T16:28:11 <jonasschnelli> yes.
4522019-07-30T16:28:24 *** mariorz has joined #bitcoin-core-dev
4532019-07-30T16:28:37 <jonasschnelli> eventually the v2 header is the 3 byte payload length
4542019-07-30T16:28:54 *** captjakk has quit IRC
4552019-07-30T16:29:28 *** captjakk has joined #bitcoin-core-dev
4562019-07-30T16:29:38 <jonasschnelli> I see all the design points. but I don't think there are practical costs for a variable length message command in v2
4572019-07-30T16:30:12 <jonasschnelli> (though I hope I'm right)
4582019-07-30T16:30:15 *** captjakk has quit IRC
4592019-07-30T16:30:30 <sipa> jonasschnelli: so... either you're going to make the decision between splitting the command from payload on the fly (before you've validated the MAC) or you do it afterwards
4602019-07-30T16:30:33 *** captjakk has joined #bitcoin-core-dev
4612019-07-30T16:31:01 <sipa> if you do it on the fly there is a risk of creating a decryption oracle (not saying there is... but running any code based on decrypted but unauthenticated data is a red flag)
4622019-07-30T16:31:19 <sipa> if you do it afterwards, it'll may hard to avoid a copy
4632019-07-30T16:32:01 <jonasschnelli> I see...
4642019-07-30T16:32:01 <sipa> with fixed command size you could split on the fly without that risk
4652019-07-30T16:32:03 *** mdunnio has quit IRC
4662019-07-30T16:32:12 <jonasschnelli> hmm?
4672019-07-30T16:32:25 <sipa> it'd just be "first 3 bytes go here, other bytes go there"
4682019-07-30T16:32:31 <sipa> without looking at what those bytes are
4692019-07-30T16:32:38 <sipa> (3 or 4 or whatever)
4702019-07-30T16:32:53 <jonasschnelli> I see
4712019-07-30T16:33:04 <sipa> there actually is another solution: putting the information on variable length command or not in the length field
4722019-07-30T16:33:12 <sipa> but that's... even less conventional
4732019-07-30T16:33:38 <jonasschnelli> so.. your saying, before we decrypt, we place the 4 byte command string into a buffer and the payload
4742019-07-30T16:34:03 <sipa> if decryption is in-place, sure
4752019-07-30T16:34:08 *** promag has joined #bitcoin-core-dev
4762019-07-30T16:34:11 <jonasschnelli> then decrypt the fix length command and not needing to deal with buffers anymore
4772019-07-30T16:34:20 <jonasschnelli> I think this is a valid point
4782019-07-30T16:34:26 <sipa> let me write things in pseudocode
4792019-07-30T16:34:44 <promag> hi, make on depends/ gives "./google/protobuf/stubs/common.h:38:10: fatal error: 'assert.h' file not found" .. hints?
4802019-07-30T16:35:01 <jonasschnelli> though, we could optimize of that case and avoid a copy if the message command is a 1byte short ID
4812019-07-30T16:35:09 <jonasschnelli> and if not, we do a copy.
4822019-07-30T16:35:25 <sipa> jonasschnelli: copy should always be avoidable
4832019-07-30T16:35:43 <jonasschnelli> yes.
4842019-07-30T16:36:31 *** mariorz has quit IRC
4852019-07-30T16:36:32 <phantomcircuit> sipa, putting the mac after the data is just asking for implementers to decrypt the payload before checking the mac
4862019-07-30T16:36:44 <jonasschnelli> I need to go through the code...
4872019-07-30T16:36:47 <phantomcircuit> (although i do understand it being after makes it easier to stream data out)
4882019-07-30T16:36:51 <sipa> phantomcircuit: but it's also the only option if you want to avoid a copy
4892019-07-30T16:37:09 <phantomcircuit> sipa, uh why
4902019-07-30T16:37:23 <phantomcircuit> wait a copy on the sender or a copy on the receivers side?
4912019-07-30T16:37:41 <sipa> phantomcircuit: you'd need to buffer the unencrypted data when sending
4922019-07-30T16:37:46 *** digi_james has quit IRC
4932019-07-30T16:38:06 <sipa> or the encrypted data, also possible
4942019-07-30T16:38:10 <phantomcircuit> sipa, it's probably getting buffered anyways but in smaller pieces
4952019-07-30T16:38:18 <sipa> maybe
4962019-07-30T16:38:48 *** digi_james has joined #bitcoin-core-dev
4972019-07-30T16:39:03 *** mariorz has joined #bitcoin-core-dev
4982019-07-30T16:39:04 <phantomcircuit> either way objects being serialized are going to be copied into a buffer
4992019-07-30T16:39:25 *** jarthur has joined #bitcoin-core-dev
5002019-07-30T16:39:27 <sipa> sure, but putting MAC first means an additional buffering either way on top of whatever else is being done
5012019-07-30T16:39:47 <phantomcircuit> but there's no easy way as of now i think to serialize directly into the buffer you're going to use for the send() call
5022019-07-30T16:40:11 <sipa> ok, fair, put otherwise: you're going to need to go over your data twice
5032019-07-30T16:40:17 *** behradkhodayar has joined #bitcoin-core-dev
5042019-07-30T16:42:14 <phantomcircuit> i think right now you'd do something like, serialize a bunch of stuff into a buffer forming an unencrypted message, copy chunks for chacha20 and mac, then send the chunk and the mac after you've processed all the chunks
5052019-07-30T16:42:16 *** anemous has joined #bitcoin-core-dev
5062019-07-30T16:42:31 *** behrad_khodayar has joined #bitcoin-core-dev
5072019-07-30T16:42:45 <phantomcircuit> but if you just do the chacha20 encryption of the buffer with the unencrypted message in place you can easily calculate the mac before without a copy
5082019-07-30T16:43:04 <sipa> the mac is computed over the encrypted data
5092019-07-30T16:43:14 <phantomcircuit> yeah that's what i said
5102019-07-30T16:43:28 <sipa> so you can do one pass of encrypting-in-place + mac, send mac, and then go back over your encrypted data and send it out
5112019-07-30T16:43:42 <sipa> if the mac goes last, you can interleave encryption and sending
5122019-07-30T16:44:10 <phantomcircuit> yeah but you cant deallocate anything anyways so it's just a very small latency win
5132019-07-30T16:44:37 <sipa> for large messages it may matter, but agree it's a small point
5142019-07-30T16:44:52 <phantomcircuit> as long as it's very clear you cant decrypt things before checking the mac im sure it's fine... but doing so is going to look like a performance/latency win to a naive implementer
5152019-07-30T16:45:09 <phantomcircuit> i mean our largest message is like 2MB right?
5162019-07-30T16:45:12 <sipa> well you very much can decrypt before checking mac
5172019-07-30T16:45:20 <sipa> you just can't use the data before doing so
5182019-07-30T16:45:30 <phantomcircuit> chacha20 + mac over 2MB on even an rpi3 is going to be basically instant
5192019-07-30T16:45:49 <sipa> or can't make any decision that the other party can observe based on that decrypted data even
5202019-07-30T16:46:27 <phantomcircuit> right
5212019-07-30T16:47:05 <phantomcircuit> i cant see that being an issue in most languages... but things that are very very "async" might try to decrypt, consume and calculate the mac in parallel
5222019-07-30T16:47:28 <sipa> phantomcircuit: 7.5 ms on a RK3399 ARM64 CPU to decrypt/auth 1MB of data
5232019-07-30T16:47:46 <sipa> that's not nothing
5242019-07-30T16:48:03 <sipa> the poly1305 code can be optimized more, though
5252019-07-30T16:48:22 <jonasschnelli> sipa: I don't think we need to copy
5262019-07-30T16:48:35 *** davterra has joined #bitcoin-core-dev
5272019-07-30T16:49:29 <jonasschnelli> We have a. CDataStream where the encrypted payload sits. Then we decrypt that "buffer" with ChaCha (after the MAC check). We read the eventually variable length command from that now decrypted CDataStream,... then directly deserialize from that CDataStream
5282019-07-30T16:49:56 <sipa> jonasschnelli: yeah, that's fair
5292019-07-30T16:50:16 <jonasschnelli> Looking at the (old) V2 code,... I think there is no copy involved
5302019-07-30T16:51:04 <sipa> it'd be nice to be able to decrypt on the fly though, so if you have a slow CPU + slow network, the message is already mostly decrypted by the time the last part of the packet arrives
5312019-07-30T16:51:09 <jonasschnelli> So the variable length message command is more or less part of the message (which is vlen anyways)
5322019-07-30T16:51:17 *** behradkhodayar has quit IRC
5332019-07-30T16:51:34 <sipa> and you can, and it's probably fine... just a bit scary
5342019-07-30T16:51:48 <jonasschnelli> sipa: decrypting on the fly is orthogonal to the fixed length command string, right?
5352019-07-30T16:52:10 <sipa> ah i see, with that CDataStream trick it is
5362019-07-30T16:52:31 <sipa> you effectively leave the command inside the CDataStream you give to the net processing code, but with the offset placed after it
5372019-07-30T16:52:47 <jonasschnelli> yes
5382019-07-30T16:52:51 <sipa> yup, agree
5392019-07-30T16:53:34 <jonasschnelli> Also, the important part of "on the fly" is probably precomputing the ChaCha20 stream up a a certain "cache" size.
5402019-07-30T16:53:55 <jonasschnelli> We then eventually only do xors in the network code
5412019-07-30T16:54:23 <sipa> heh, good point
5422019-07-30T16:54:53 <sipa> ok, i agree that the ability to decode on the fly isn't an argument against variable length commands
5432019-07-30T16:55:54 <jonasschnelli> The remaining question is whether the variable length command increases message type detectability
5442019-07-30T16:56:23 <sipa> not if the encrypted length covers the command as well
5452019-07-30T16:56:39 <jonasschnelli> Yes. It does. So I also think it's not an agrument.
5462019-07-30T16:56:50 *** Chris_Stewart_5 has joined #bitcoin-core-dev
5472019-07-30T16:57:17 <jonasschnelli> Which makes me again think saving 3 bytes is worth the variable length command
5482019-07-30T16:58:04 <sipa> i like the perspective of "the command is just the first bytes of the message payload, and we detect the command after allocating/receiving/decrypting/authenticating the whole payload"
5492019-07-30T16:58:30 <jonasschnelli> Maybe one could think passing a CDataStream to the next layer with a pointer not pointing the the buffer start is ugly stuff
5502019-07-30T16:58:41 <jonasschnelli> sipa: Yes. I think that definition clears up things
5512019-07-30T16:58:46 <sipa> so i'm fine with whatever
5522019-07-30T16:59:14 <jonasschnelli> Somehow I care about those 3 bytes... maybe wrongly.
5532019-07-30T16:59:19 <sipa> including BlueMatt's suggestion earlier of only supporting 1-byte and 12-byte commands
5542019-07-30T16:59:58 <jonasschnelli> Though there is a yes/no wether a V2 inv is larger than a V1 inv.
5552019-07-30T17:00:03 *** jungly has quit IRC
5562019-07-30T17:00:42 <jonasschnelli> though with a 4 bytes fixed length command. It would still be 1 bytes smaller then V1.
5572019-07-30T17:01:07 <jonasschnelli> *than V1*
5582019-07-30T17:02:36 *** mdunnio has joined #bitcoin-core-dev
5592019-07-30T17:06:51 *** profmac has quit IRC
5602019-07-30T17:07:33 *** mdunnio has quit IRC
5612019-07-30T17:10:33 *** profmac has joined #bitcoin-core-dev
5622019-07-30T17:11:12 *** promag has quit IRC
5632019-07-30T17:11:59 *** promag has joined #bitcoin-core-dev
5642019-07-30T17:25:11 *** mdunnio has joined #bitcoin-core-dev
5652019-07-30T17:49:37 *** spaced0ut has quit IRC
5662019-07-30T17:51:59 *** timothy has quit IRC
5672019-07-30T17:55:51 *** captjakk has quit IRC
5682019-07-30T17:56:33 *** bitcoin-git has joined #bitcoin-core-dev
5692019-07-30T17:56:34 <bitcoin-git> [bitcoin] MarcoFalke opened pull request #16497: gui: Generate bech32 addresses by default (take 2, fixup) (master...1907-guiBech32Take2) https://github.com/bitcoin/bitcoin/pull/16497
5702019-07-30T17:56:35 *** bitcoin-git has left #bitcoin-core-dev
5712019-07-30T17:59:22 <sipa> gleb: have you seen the discussion last thursday on changes to wallet rebroadcasting? i wonder if you have any thoughts on interaction with erlay
5722019-07-30T17:59:40 *** behradkhodayar has joined #bitcoin-core-dev
5732019-07-30T18:00:02 *** lliehu1 has quit IRC
5742019-07-30T18:03:41 *** pinheadmz has quit IRC
5752019-07-30T18:03:55 *** bitcoin-git has joined #bitcoin-core-dev
5762019-07-30T18:03:55 <bitcoin-git> [bitcoin] TheBlueMatt reopened pull request #16323: Call ProcessNewBlock() asynchronously (master...2019-07-background-pnb) https://github.com/bitcoin/bitcoin/pull/16323
5772019-07-30T18:03:56 *** bitcoin-git has left #bitcoin-core-dev
5782019-07-30T18:04:36 *** michagogo has joined #bitcoin-core-dev
5792019-07-30T18:04:40 *** MarconM has joined #bitcoin-core-dev
5802019-07-30T18:05:02 *** mdunnio has quit IRC
5812019-07-30T18:05:45 *** bitcoin-git has joined #bitcoin-core-dev
5822019-07-30T18:05:45 <bitcoin-git> [bitcoin] TheBlueMatt reopened pull request #16324: Get cs_main out of the critical path in ProcessMessages (master...2019-07-peerstate-initial-moves) https://github.com/bitcoin/bitcoin/pull/16324
5832019-07-30T18:05:47 *** bitcoin-git has left #bitcoin-core-dev
5842019-07-30T18:07:50 *** behradkhodayar has quit IRC
5852019-07-30T18:10:34 <BlueMatt> ^ seeking concept review :)
5862019-07-30T18:10:59 <BlueMatt> also seeking ibd benchmarks from multiple peers....(jamesob :p)
5872019-07-30T18:12:50 *** mdunnio has joined #bitcoin-core-dev
5882019-07-30T18:14:56 *** jarthur has quit IRC
5892019-07-30T18:15:33 *** pinheadmz has joined #bitcoin-core-dev
5902019-07-30T18:15:35 *** jarthur has joined #bitcoin-core-dev
5912019-07-30T18:17:00 *** anemous has quit IRC
5922019-07-30T18:18:44 *** reallll has joined #bitcoin-core-dev
5932019-07-30T18:21:23 *** belcher has quit IRC
5942019-07-30T18:22:04 <gleb> sipa: I think it would work right away by just applying the same reasoning and looking at it as if the transaction was new
5952019-07-30T18:23:16 <sipa> gleb: but if different nodes had inconsistent rebroadcasting rules (or even randomization in whether/when to try rebroadcasting), erlay would suffer
5962019-07-30T18:25:36 <gleb> Oops, you are right, it would announce already known transactions potentially.
5972019-07-30T18:45:32 <gleb> There would be 2 kinds of nodes: those which have it in the mempool and those which don't. For the latter we can't do anything â we can only apply the default protocol (flooding/erlay) (unless we pass a flag along with a tx, but we're not gonna do this)
5982019-07-30T18:45:53 <gleb> For the former â I guess according to the rebroadcast reasoning they won't re-relay anything if it's received from somewhere (only if their own timer triggers).
5992019-07-30T18:46:27 <gleb> So the question is really how we should act at the node which triggers rebroadcast.
6002019-07-30T18:46:52 <sipa> an alternative to rebroadcasting is of course mempool (full mempool, not relay) reconciliation...
6012019-07-30T18:48:27 <gleb> Which is essentially just batching rebroadcasts over an hour or whatever.
6022019-07-30T18:49:56 *** hebasto has quit IRC
6032019-07-30T18:54:38 *** jarthur has quit IRC
6042019-07-30T18:56:48 <gleb> Yeah, I think exchanging sketches of rebroadcasts every hour or so might work. It's really mempool reconciliation done right (no point to reconcile obviously known to both parties fresh txs or low-fee garbage)
6052019-07-30T18:57:37 <gleb> I'm not sure estimation would work that well as in Erlay â I can't tell how often rebroadcasts would happen and how different the rules will be and all that.
6062019-07-30T18:58:47 <sipa> it can be orthogonal of course; post-erlay the rebroadcasts can just stay normal invs too
6072019-07-30T18:59:35 <sipa> though if their bandwidth is considerable, we'll want a reconciliation based solution, whether by integrating into erlay, or by having a separate independent reconciliation step for rebroadcasts
6082019-07-30T19:01:17 *** jarthur has joined #bitcoin-core-dev
6092019-07-30T19:02:37 *** anemous has joined #bitcoin-core-dev
6102019-07-30T19:10:00 <gleb> Yeah. I think we can't do much if rebroadcast uses regular invs though, as I explained above w.r.t 2 kinds of nodes. Anything coming to my mind about "integrating into erlay" is really complicated separate things.
6112019-07-30T19:10:01 <gleb> So in this case if Erlay's estimation formula adjusts to this stuff we're good, otherwise we might loose a bit of efficiency.
6122019-07-30T19:10:25 <gleb> In the case of regular inv rebroadcast *
6132019-07-30T19:12:33 *** captjakk has joined #bitcoin-core-dev
6142019-07-30T19:12:56 *** reallll is now known as belcher
6152019-07-30T19:14:04 *** mdunnio has quit IRC
6162019-07-30T19:17:08 *** davex_ has quit IRC
6172019-07-30T19:21:57 *** mdunnio has joined #bitcoin-core-dev
6182019-07-30T19:23:14 *** mdunnio has quit IRC
6192019-07-30T19:28:20 *** mdunnio has joined #bitcoin-core-dev
6202019-07-30T19:32:28 <phantomcircuit> BlueMatt, it's 10% faster to skip the bip30 checks
6212019-07-30T19:33:07 *** ezegom has quit IRC
6222019-07-30T19:34:07 *** ezegom has joined #bitcoin-core-dev
6232019-07-30T19:34:13 <BlueMatt> hmm, fun.
6242019-07-30T19:37:36 <BlueMatt> phantomcircuit: well you at least need to fix sdaftuar's comment on the pr, but mostly I'm highly dubious of reorg conditions around the bip30 shit
6252019-07-30T19:37:51 <BlueMatt> if you write a test that tests shit like that, I'll be happy :p
6262019-07-30T19:44:31 *** jarthur has quit IRC
6272019-07-30T19:44:42 *** roconnor has quit IRC
6282019-07-30T19:45:10 *** jarthur has joined #bitcoin-core-dev
6292019-07-30T19:53:47 *** mdunnio has quit IRC
6302019-07-30T19:54:05 *** mdunnio has joined #bitcoin-core-dev
6312019-07-30T19:57:58 <BlueMatt> fanquake: care2merge #16433
6322019-07-30T19:58:02 <gribble> https://github.com/bitcoin/bitcoin/issues/16433 | txmempool: Remove unused default value MemPoolRemovalReason::UNKNOWN by MarcoFalke · Pull Request #16433 · bitcoin/bitcoin · GitHub
6332019-07-30T19:59:16 <jonasschnelli> BlueMatt: hell.. It's 4am for poor fanquake. Let me have a look. :)
6342019-07-30T19:59:30 <BlueMatt> oh, ehh, bad timezone conversion, was thinking it was later than it was
6352019-07-30T19:59:32 <sipa> I thought fanquake lived in a timeless realm
6362019-07-30T19:59:38 <jonasschnelli> heh
6372019-07-30T19:59:40 <BlueMatt> whatever, its trivial
6382019-07-30T20:00:07 *** captjakk has quit IRC
6392019-07-30T20:00:33 *** captjakk has joined #bitcoin-core-dev
6402019-07-30T20:01:47 <jimpo> BlueMatt: Thinking about https://github.com/bitcoin/bitcoin/pull/16442#discussion_r308429740 more (the BlockRequestAllowed comment), I think just checking the stop block might be OK
6412019-07-30T20:02:02 <jonasschnelli> BlueMatt: your utACK didn't end up in the commit merge message because you missed the commit hash :P
6422019-07-30T20:02:08 <BlueMatt> jonasschnelli: meh
6432019-07-30T20:02:13 <BlueMatt> its trivial enough I figured no one cared
6442019-07-30T20:02:22 <BlueMatt> jimpo: hmm?
6452019-07-30T20:02:32 <jonasschnelli> somehow github-merge.py does
6462019-07-30T20:02:35 *** bitcoin-git has joined #bitcoin-core-dev
6472019-07-30T20:02:36 <bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/74f1a27f2f45...39763b75556b
6482019-07-30T20:02:36 <bitcoin-git> bitcoin/master 0000ff0 MarcoFalke: txmempool: Remove unused default value MemPoolRemovalReason::UNKNOWN
6492019-07-30T20:02:36 <bitcoin-git> bitcoin/master 39763b7 Jonas Schnelli: Merge #16433: txmempool: Remove unused default value MemPoolRemovalReason:...
6502019-07-30T20:02:37 *** jarthur has quit IRC
6512019-07-30T20:02:49 *** bitcoin-git has left #bitcoin-core-dev
6522019-07-30T20:02:53 <BlueMatt> jonasschnelli: right, I mean no reason to need or care about anoher ack on something that trivial
6532019-07-30T20:03:02 <jonasschnelli> sure
6542019-07-30T20:03:05 <jimpo> I assume the concern is some pathological case where there's a stale chain where some of the early stale blocks are more than 1 month old but the latest blocks in the chain are less than 1 month old?
6552019-07-30T20:03:26 <BlueMatt> jimpo: right, thats why I was referencing
6562019-07-30T20:03:35 *** bitcoin-git has joined #bitcoin-core-dev
6572019-07-30T20:03:35 <bitcoin-git> [bitcoin] jonasschnelli merged pull request #16433: txmempool: Remove unused default value MemPoolRemovalReason::UNKNOWN (master...1907-txmempoolNoUnknownDefault) https://github.com/bitcoin/bitcoin/pull/16433
6582019-07-30T20:03:48 *** bitcoin-git has left #bitcoin-core-dev
6592019-07-30T20:04:06 <BlueMatt> jimpo: ah, you're right
6602019-07-30T20:04:11 <jimpo> In that cause, it's plausible that the node has been online less than a month and synced up the earlier stale blocks since the chain is "active" in some sense
6612019-07-30T20:04:12 <BlueMatt> jimpo: yea, doesn't matter
6622019-07-30T20:04:31 <BlueMatt> no, specifically it doesnt matter cause it doesn't reveal information
6632019-07-30T20:04:52 *** captjakk has quit IRC
6642019-07-30T20:04:52 <BlueMatt> if you are BLOCK_VALID_SCRIPTS at the top of the fork, then you are clearly also BLOCK_VALID_SCRIPTS everywhere down the fork path
6652019-07-30T20:05:03 <BlueMatt> so hiding the fact that you have those blocks...welll...you're not hiding anything
6662019-07-30T20:05:09 <jimpo> well yes, that too
6672019-07-30T20:05:41 <jimpo> I mean, I still think having the BlockRequestAllowed check in addition to the BLOCK_VALID_SCRIPTS check is valuable
6682019-07-30T20:05:54 <jimpo> but just on the stop block should be fine
6692019-07-30T20:06:27 <BlueMatt> hmm? no my point with that comment was that BlockRequestAllowed already does the BLOCK_VALID_SCRIPTS check for you
6702019-07-30T20:06:30 <BlueMatt> so....no reason to call it again
6712019-07-30T20:06:39 <jimpo> yes, I agree with that
6722019-07-30T20:06:45 <jimpo> I am removing the redundant check
6732019-07-30T20:07:09 <jimpo> but it's still better to do the full BlockRequestAllowed check instead of just the BLOCK_VALID_SCRIPTS check
6742019-07-30T20:07:25 *** ezegom has quit IRC
6752019-07-30T20:07:42 *** farmerwampum has quit IRC
6762019-07-30T20:08:00 <BlueMatt> not just better, you must
6772019-07-30T20:08:09 *** jarthur has joined #bitcoin-core-dev
6782019-07-30T20:08:28 *** pinheadmz has quit IRC
6792019-07-30T20:08:29 <jimpo> just to prevent fingerprinting, right? Or is there another reason?
6802019-07-30T20:08:33 <BlueMatt> right
6812019-07-30T20:08:40 <phantomcircuit> BlueMatt, either im missing something or this will cause reorg issues in exactly the same way an invalid script would
6822019-07-30T20:08:53 <phantomcircuit> except that it doesn't let a miner steal coins just destroy them
6832019-07-30T20:08:54 <phantomcircuit> so like
6842019-07-30T20:08:55 <BlueMatt> phantomcircuit: ehhh, the cache flushing shit is....complicated
6852019-07-30T20:08:55 <phantomcircuit> why
6862019-07-30T20:09:02 <BlueMatt> phantomcircuit: go read the comment(s) there, and then test it anyway :P
6872019-07-30T20:09:09 *** ezegom has joined #bitcoin-core-dev
6882019-07-30T20:09:27 <phantomcircuit> BlueMatt, there's no cache flushing issues
6892019-07-30T20:09:49 <phantomcircuit> the BIP30 checks are literally always cache miss down to disk unless the blocks invalid
6902019-07-30T20:09:50 *** pinheadmz has joined #bitcoin-core-dev
6912019-07-30T20:10:41 <phantomcircuit> sdaftuar, did i read your comment right?
6922019-07-30T20:11:11 <jimpo> BlueMatt: To be clear, you agree that there's no need to additionally check BlockRequestAllowed on the start block right? Is your reasoning the same as mine?
6932019-07-30T20:11:25 <phantomcircuit> BlueMatt, oh and the 10% is probably the smallest improvement possible, an rpi with a spinning disk would almost certainly be more than 10%
6942019-07-30T20:11:28 <BlueMatt> jimpo: thats my understanding yes, not sure what your reasoning is
6952019-07-30T20:11:37 <BlueMatt> phantomcircuit: ah, right, sorry, I'm mis-thinking about this
6962019-07-30T20:12:07 *** pinheadmz has quit IRC
6972019-07-30T20:13:17 *** captjakk has joined #bitcoin-core-dev
6982019-07-30T20:14:54 <phantomcircuit> BlueMatt, wait does leveldb do a bloomfilter lookup for key existence?
6992019-07-30T20:15:02 <sipa> yes
7002019-07-30T20:16:12 <phantomcircuit> so maybe it doesn't do a disk lookup and instead is just the cost of the bloomfilter that's being saved?
7012019-07-30T20:16:33 *** pinheadmz has joined #bitcoin-core-dev
7022019-07-30T20:18:36 <sipa> yes
7032019-07-30T20:18:46 <sipa> and the bloomfilter is likely cached in ram
7042019-07-30T20:20:54 *** ezegom has quit IRC
7052019-07-30T20:22:23 *** ezegom has joined #bitcoin-core-dev
7062019-07-30T20:26:07 <jonasschnelli> #proposedmeetingtopic bitcoin-dev mailing list moderation
7072019-07-30T20:26:17 <BlueMatt> oh boy
7082019-07-30T20:26:31 <jonasschnelli> heh... don't fear
7092019-07-30T20:26:48 *** mdunnio has quit IRC
7102019-07-30T20:26:55 <jonasschnelli> It's just about ramping up more people so we can have actual debates without +48h lags
7112019-07-30T20:27:11 *** bitcoin-git has joined #bitcoin-core-dev
7122019-07-30T20:27:11 <bitcoin-git> [bitcoin] MarcoFalke closed pull request #16264: policy: Add experimental -mempoolreplacement=full (off by default) (master...1906-policyFullRbf) https://github.com/bitcoin/bitcoin/pull/16264
7132019-07-30T20:27:12 *** bitcoin-git has left #bitcoin-core-dev
7142019-07-30T20:37:48 <phantomcircuit> sipa, well it's most definitely faster without the 34m lookups at least
7152019-07-30T20:38:12 <phantomcircuit> it also made generating (very bad) data on leveldb Get calls vs dbcache easier
7162019-07-30T20:41:14 *** mdunnio has joined #bitcoin-core-dev
7172019-07-30T20:54:38 *** emilengler has joined #bitcoin-core-dev
7182019-07-30T21:00:01 *** MarconM has quit IRC
7192019-07-30T21:02:18 <emilengler> I don't get where the bitcoin-qt rpc console detecs when Ctrl-L is being pressed? With the help of the grep command I've only found the way how Ctrl-Q is being handled. Can someone tell me where I find it?
7202019-07-30T21:02:22 <fanquake> promag: itâll be a missing SDK. Assuming your building for MacOS
7212019-07-30T21:03:57 *** spake has joined #bitcoin-core-dev
7222019-07-30T21:06:43 *** bitcoin-git has joined #bitcoin-core-dev
7232019-07-30T21:06:43 <bitcoin-git> [bitcoin] instagibbs opened pull request #16500: GetFee should round up to avoid undershooting feerate (master...fix_filter_mempool_mistmatch) https://github.com/bitcoin/bitcoin/pull/16500
7242019-07-30T21:06:44 *** bitcoin-git has left #bitcoin-core-dev
7252019-07-30T21:10:22 *** Guyver2 has quit IRC
7262019-07-30T21:12:10 *** mdunnio has quit IRC
7272019-07-30T21:14:08 *** jarthur has quit IRC
7282019-07-30T21:20:07 *** EagleTM has joined #bitcoin-core-dev
7292019-07-30T21:23:30 *** bitcoin-git has joined #bitcoin-core-dev
7302019-07-30T21:23:30 <bitcoin-git> [bitcoin] ronaldstoner opened pull request #16501: Update configure.ac to remove extra no in $use_tests (master...master) https://github.com/bitcoin/bitcoin/pull/16501
7312019-07-30T21:23:34 *** bitcoin-git has left #bitcoin-core-dev
7322019-07-30T21:27:34 *** mdunnio has joined #bitcoin-core-dev
7332019-07-30T21:31:27 *** bitcoin-git has joined #bitcoin-core-dev
7342019-07-30T21:31:27 <bitcoin-git> [bitcoin] ronaldstoner closed pull request #16501: Update configure.ac to remove extra no in $use_tests (master...master) https://github.com/bitcoin/bitcoin/pull/16501
7352019-07-30T21:31:29 *** bitcoin-git has left #bitcoin-core-dev
7362019-07-30T21:37:48 *** rex4539 has joined #bitcoin-core-dev
7372019-07-30T21:38:37 *** promag has quit IRC
7382019-07-30T21:38:49 *** promag has joined #bitcoin-core-dev
7392019-07-30T21:45:13 *** mdunnio has quit IRC
7402019-07-30T21:49:07 *** mdunnio has joined #bitcoin-core-dev
7412019-07-30T21:51:02 *** brianhoffman_ has joined #bitcoin-core-dev
7422019-07-30T21:53:22 *** brianhoffman has quit IRC
7432019-07-30T21:53:22 *** brianhoffman_ is now known as brianhoffman
7442019-07-30T21:53:37 *** bitcoin-git has joined #bitcoin-core-dev
7452019-07-30T21:53:37 <bitcoin-git> [bitcoin] promag opened pull request #16502: wallet: Drop unused OldKey (master...2019-07-drop-oldkey) https://github.com/bitcoin/bitcoin/pull/16502
7462019-07-30T21:53:40 *** bitcoin-git has left #bitcoin-core-dev
7472019-07-30T21:54:31 *** bitcoin-git has joined #bitcoin-core-dev
7482019-07-30T21:54:31 <bitcoin-git> [bitcoin] promag closed pull request #16494: wallet: Drop support to serialize OldKey (master...2019-07-drop-oldkey-serialize) https://github.com/bitcoin/bitcoin/pull/16494
7492019-07-30T21:54:35 *** bitcoin-git has left #bitcoin-core-dev
7502019-07-30T21:54:52 *** ezegom has quit IRC
7512019-07-30T21:55:31 *** ezegom has joined #bitcoin-core-dev
7522019-07-30T21:56:08 <promag> fanquake: which sdk?
7532019-07-30T21:59:41 <fanquake> promag: the macOS SDK. Are you building depends for a macOS HOST?
7542019-07-30T22:00:08 <promag> I'm on a mac, building for mac
7552019-07-30T22:01:47 <phantomcircuit> sdaftuar, sorry im confused i dont see how removing the bip30 check would prevent a reorg to a greater pow chain
7562019-07-30T22:02:12 <fanquake> Does the version of macOS youâre on have the correct SDK? Are you testing the tool chain update PR
7572019-07-30T22:02:51 *** ercwl has joined #bitcoin-core-dev
7582019-07-30T22:03:26 *** ezegom has quit IRC
7592019-07-30T22:04:29 *** ezegom has joined #bitcoin-core-dev
7602019-07-30T22:04:42 <promag> fanquake: `xcrun --sdk macosx --show-sdk-path` gives /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
7612019-07-30T22:05:25 <fanquake> promag: oh, did you recently update your macOS or Xcode?
7622019-07-30T22:06:03 <promag> fanquake: nope, I don't recall doing it, at least recently
7632019-07-30T22:06:09 <promag> why?
7642019-07-30T22:08:00 <fanquake> In newer versions of Xcode some of the headers our depends packages rely on arenât where they used to be, and there a a script you can run thatâll put them back. See this comment: https://github.com/bitcoin/bitcoin/pull/16392#issuecomment-515268092 and the one Iâm referencing.
7652019-07-30T22:08:55 <fanquake> Otherwise unsure atm.
7662019-07-30T22:09:13 *** ezegom has quit IRC
7672019-07-30T22:12:29 <promag> should it work if I have the previous sdk?
7682019-07-30T22:12:34 <promag> fanquake: ^
7692019-07-30T22:13:57 *** mdunnio has quit IRC
7702019-07-30T22:14:34 <fanquake> promag: no, in that PR itâll be looking for the newer one. Thinking about that, we could drop the requirements.
7712019-07-30T22:15:16 <fanquake> Although, at least itâs easy to download and extract the new SDK on a mac.
7722019-07-30T22:25:24 *** promag has quit IRC
7732019-07-30T22:26:08 *** promag has joined #bitcoin-core-dev
7742019-07-30T22:27:52 *** petezz4 has joined #bitcoin-core-dev
7752019-07-30T22:35:44 *** Zenton has quit IRC
7762019-07-30T22:39:57 *** ezegom has joined #bitcoin-core-dev
7772019-07-30T22:41:00 *** ezegom has joined #bitcoin-core-dev
7782019-07-30T22:45:28 *** ezegom has quit IRC
7792019-07-30T22:46:13 *** EagleTM has quit IRC
7802019-07-30T22:47:03 <phantomcircuit> BlueMatt, what am i missing
7812019-07-30T23:04:43 *** justanotheruser has quit IRC
7822019-07-30T23:08:55 *** bitcoin-git has joined #bitcoin-core-dev
7832019-07-30T23:08:55 <bitcoin-git> [bitcoin] ariard opened pull request #16503: Remove p2pEnabled from Chain interface (master...2019-07-remove-p2p-chain) https://github.com/bitcoin/bitcoin/pull/16503
7842019-07-30T23:09:02 *** bitcoin-git has left #bitcoin-core-dev
7852019-07-30T23:12:43 *** ezegom has joined #bitcoin-core-dev
7862019-07-30T23:14:41 *** captjakk has quit IRC
7872019-07-30T23:15:09 *** captjakk has joined #bitcoin-core-dev
7882019-07-30T23:19:31 *** captjakk has quit IRC
7892019-07-30T23:24:54 *** promag has quit IRC
7902019-07-30T23:25:06 *** promag has joined #bitcoin-core-dev
7912019-07-30T23:28:36 *** ercwl has quit IRC
7922019-07-30T23:28:39 *** kristapsk___ is now known as kristapsk
7932019-07-30T23:29:25 *** ercwl has joined #bitcoin-core-dev
7942019-07-30T23:29:38 *** ezegom has quit IRC
7952019-07-30T23:29:54 *** ezegom has joined #bitcoin-core-dev
7962019-07-30T23:30:53 *** ezegom has joined #bitcoin-core-dev
7972019-07-30T23:37:50 *** Aaronvan_ has quit IRC
7982019-07-30T23:51:36 *** captjakk has joined #bitcoin-core-dev
7992019-07-30T23:51:36 *** astro has quit IRC
8002019-07-30T23:52:36 *** ezegom has quit IRC
8012019-07-30T23:53:06 *** guest69 has joined #bitcoin-core-dev
8022019-07-30T23:55:53 *** captjakk has quit IRC
8032019-07-30T23:55:59 *** captjakk has joined #bitcoin-core-dev
8042019-07-30T23:56:51 *** astro has joined #bitcoin-core-dev
8052019-07-30T23:57:37 *** ezegom has joined #bitcoin-core-dev