1 2019-07-30T00:00:01  *** VitamineD has quit IRC
  2 2019-07-30T00:04:44  *** tflgen2 has joined #bitcoin-core-dev
  3 2019-07-30T00:08:34  *** AaronvanW has quit IRC
  4 2019-07-30T00:11:22  *** laptop500 has quit IRC
  5 2019-07-30T00:12:14  *** ezegom has quit IRC
  6 2019-07-30T00:12:53  *** ezegom has joined #bitcoin-core-dev
  7 2019-07-30T00:15:43  *** ezegom has quit IRC
  8 2019-07-30T00:15:58  *** ezegom has joined #bitcoin-core-dev
  9 2019-07-30T00:24:35  *** ezegom has quit IRC
 10 2019-07-30T00:24:51  *** ezegom has joined #bitcoin-core-dev
 11 2019-07-30T00:34:53  *** IGHOR has joined #bitcoin-core-dev
 12 2019-07-30T00:35:14  *** bitcoin-git has joined #bitcoin-core-dev
 13 2019-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
 14 2019-07-30T00:35:16  *** bitcoin-git has left #bitcoin-core-dev
 15 2019-07-30T00:38:14  *** bitcoin-git has joined #bitcoin-core-dev
 16 2019-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
 17 2019-07-30T00:38:15  *** bitcoin-git has left #bitcoin-core-dev
 18 2019-07-30T01:01:44  *** Karyon has quit IRC
 19 2019-07-30T01:03:25  *** Karyon has joined #bitcoin-core-dev
 20 2019-07-30T01:03:54  *** bitcoin-git has joined #bitcoin-core-dev
 21 2019-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
 22 2019-07-30T01:03:55  *** bitcoin-git has left #bitcoin-core-dev
 23 2019-07-30T01:04:36  *** JamesAU has joined #bitcoin-core-dev
 24 2019-07-30T01:04:55  <emilengler> How the CTRL+L shortcut is being handled in bitcoin-qt? Over a QAction or a QShortcut?
 25 2019-07-30T01:11:36  *** sdupre has joined #bitcoin-core-dev
 26 2019-07-30T01:16:23  *** ezegom has quit IRC
 27 2019-07-30T01:16:46  *** ezegom has joined #bitcoin-core-dev
 28 2019-07-30T01:17:22  *** ezegom has joined #bitcoin-core-dev
 29 2019-07-30T01:26:43  *** Chris_Stewart_5 has quit IRC
 30 2019-07-30T01:30:06  *** ezegom has quit IRC
 31 2019-07-30T01:33:03  *** JamesAU has quit IRC
 32 2019-07-30T01:38:23  *** emilengler has quit IRC
 33 2019-07-30T01:42:10  *** sdupre has quit IRC
 34 2019-07-30T01:51:04  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 35 2019-07-30T01:52:58  *** booyah has quit IRC
 36 2019-07-30T01:53:30  *** booyah has joined #bitcoin-core-dev
 37 2019-07-30T01:56:39  *** ezegom has joined #bitcoin-core-dev
 38 2019-07-30T01:57:13  *** ezegom has joined #bitcoin-core-dev
 39 2019-07-30T02:08:47  *** ezegom has quit IRC
 40 2019-07-30T02:09:12  *** Chris_Stewart_5 has quit IRC
 41 2019-07-30T02:12:59  *** ezegom has joined #bitcoin-core-dev
 42 2019-07-30T02:15:58  *** captjakk has quit IRC
 43 2019-07-30T02:16:31  *** captjakk has joined #bitcoin-core-dev
 44 2019-07-30T02:18:22  *** booyah has quit IRC
 45 2019-07-30T02:20:12  *** mryandao has quit IRC
 46 2019-07-30T02:20:13  *** booyah has joined #bitcoin-core-dev
 47 2019-07-30T02:20:31  *** ezegom has quit IRC
 48 2019-07-30T02:20:51  *** captjakk has quit IRC
 49 2019-07-30T02:20:57  *** mryandao has joined #bitcoin-core-dev
 50 2019-07-30T02:22:22  *** elichai2 has quit IRC
 51 2019-07-30T02:26:53  *** DeanGuss has joined #bitcoin-core-dev
 52 2019-07-30T02:27:44  *** mdunnio has quit IRC
 53 2019-07-30T02:36:58  *** ezegom has joined #bitcoin-core-dev
 54 2019-07-30T02:37:20  *** ezegom has joined #bitcoin-core-dev
 55 2019-07-30T02:45:07  *** sanket1729 has joined #bitcoin-core-dev
 56 2019-07-30T03:00:01  *** tflgen2 has quit IRC
 57 2019-07-30T03:04:08  *** vexed__ has joined #bitcoin-core-dev
 58 2019-07-30T03:04:13  *** dviola has quit IRC
 59 2019-07-30T03:15:45  *** whatsup has joined #bitcoin-core-dev
 60 2019-07-30T03:16:39  *** ezegom has quit IRC
 61 2019-07-30T03:17:19  *** ezegom has joined #bitcoin-core-dev
 62 2019-07-30T03:17:45  *** bitcoin-git has joined #bitcoin-core-dev
 63 2019-07-30T03:17:46  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/68da54987df4...2410088003a1
 64 2019-07-30T03:17:46  <bitcoin-git> bitcoin/master 62d3f50 Jon Atack: qa: fix deprecated log.warn in feature_dbcrash test
 65 2019-07-30T03:17:47  <bitcoin-git> bitcoin/master 2410088 fanquake: Merge #16491: qa: fix deprecated log.warn in feature_dbcrash test
 66 2019-07-30T03:17:49  *** bitcoin-git has left #bitcoin-core-dev
 67 2019-07-30T03:18:50  *** bitcoin-git has joined #bitcoin-core-dev
 68 2019-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
 69 2019-07-30T03:18:53  *** bitcoin-git has left #bitcoin-core-dev
 70 2019-07-30T03:19:19  *** guest62 has joined #bitcoin-core-dev
 71 2019-07-30T03:20:51  *** whatsup has quit IRC
 72 2019-07-30T03:21:45  *** ezegom has quit IRC
 73 2019-07-30T03:28:20  *** nockk100 has joined #bitcoin-core-dev
 74 2019-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.
 75 2019-07-30T03:37:44  *** bitcoin-git has joined #bitcoin-core-dev
 76 2019-07-30T03:37:45  <bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/2410088003a1...478fe328a793
 77 2019-07-30T03:37:45  <bitcoin-git> bitcoin/master fa6dc7f MarcoFalke: wallet: Enumerate walletdb keys
 78 2019-07-30T03:37:45  *** nockk100 has quit IRC
 79 2019-07-30T03:37:46  <bitcoin-git> bitcoin/master fa6f22b MarcoFalke: wallet: Rename CWalletKey to OldKey
 80 2019-07-30T03:37:46  <bitcoin-git> bitcoin/master 478fe32 fanquake: Merge #16475: wallet: Enumerate walletdb keys
 81 2019-07-30T03:37:48  *** bitcoin-git has left #bitcoin-core-dev
 82 2019-07-30T03:38:39  *** bitcoin-git has joined #bitcoin-core-dev
 83 2019-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
 84 2019-07-30T03:38:40  *** bitcoin-git has left #bitcoin-core-dev
 85 2019-07-30T03:39:13  <achow101> kallewoof: it doesn't interfere, I'll leave a comment
 86 2019-07-30T03:39:26  <kallewoof> Great, thanks!
 87 2019-07-30T03:44:25  *** Eagle[TM] has joined #bitcoin-core-dev
 88 2019-07-30T03:46:22  *** EagleTM has quit IRC
 89 2019-07-30T03:51:03  *** bitcoin-git has joined #bitcoin-core-dev
 90 2019-07-30T03:51:03  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/478fe328a793...33894612c0de
 91 2019-07-30T03:51:04  <bitcoin-git> bitcoin/master faa88d0 MarcoFalke: doc: update labels in CONTRIBUTING.md
 92 2019-07-30T03:51:04  <bitcoin-git> bitcoin/master 3389461 fanquake: Merge #16484: doc: update labels in CONTRIBUTING.md
 93 2019-07-30T03:51:06  *** bitcoin-git has left #bitcoin-core-dev
 94 2019-07-30T03:52:03  *** bitcoin-git has joined #bitcoin-core-dev
 95 2019-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
 96 2019-07-30T03:52:04  *** bitcoin-git has left #bitcoin-core-dev
 97 2019-07-30T03:53:16  *** schnerch_ has joined #bitcoin-core-dev
 98 2019-07-30T03:56:30  *** schnerchi has quit IRC
 99 2019-07-30T03:57:33  *** d_t has joined #bitcoin-core-dev
100 2019-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.
101 2019-07-30T04:04:13  <sipa> hugohn: ha
102 2019-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.
103 2019-07-30T04:10:49  <hugohn> *GetSigningProvider, not GetScriptPubKeyMan
104 2019-07-30T04:18:49  *** roconnor has quit IRC
105 2019-07-30T04:20:13  *** d3spwn has quit IRC
106 2019-07-30T04:23:43  *** peleion has quit IRC
107 2019-07-30T04:27:11  *** d3spwn has joined #bitcoin-core-dev
108 2019-07-30T04:32:07  *** nullptr| has quit IRC
109 2019-07-30T04:32:57  *** Anduck has quit IRC
110 2019-07-30T04:33:38  *** Anduck has joined #bitcoin-core-dev
111 2019-07-30T04:34:28  *** nullptr| has joined #bitcoin-core-dev
112 2019-07-30T04:48:09  *** tryphe has quit IRC
113 2019-07-30T04:53:35  *** elichai2 has joined #bitcoin-core-dev
114 2019-07-30T04:53:54  *** tryphe has joined #bitcoin-core-dev
115 2019-07-30T04:56:06  *** d_t has quit IRC
116 2019-07-30T05:00:43  *** guest62 has quit IRC
117 2019-07-30T05:27:18  *** rex4539 has quit IRC
118 2019-07-30T05:37:20  *** bitcoin-git has joined #bitcoin-core-dev
119 2019-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
120 2019-07-30T05:37:33  *** bitcoin-git has left #bitcoin-core-dev
121 2019-07-30T06:00:02  *** vexed__ has quit IRC
122 2019-07-30T06:05:55  *** rex4539 has joined #bitcoin-core-dev
123 2019-07-30T06:10:44  *** keyboardsurfer has joined #bitcoin-core-dev
124 2019-07-30T06:34:52  *** kcalvinalvin has joined #bitcoin-core-dev
125 2019-07-30T06:38:14  *** guest69 has joined #bitcoin-core-dev
126 2019-07-30T07:00:47  *** peleion has joined #bitcoin-core-dev
127 2019-07-30T07:02:47  *** elichai2 has quit IRC
128 2019-07-30T07:12:28  *** morcos has quit IRC
129 2019-07-30T07:14:03  *** AaronvanW has joined #bitcoin-core-dev
130 2019-07-30T07:15:17  *** Eagle[TM] has quit IRC
131 2019-07-30T07:16:49  *** Aaronvan_ has joined #bitcoin-core-dev
132 2019-07-30T07:20:21  *** AaronvanW has quit IRC
133 2019-07-30T07:21:17  *** morcos has joined #bitcoin-core-dev
134 2019-07-30T07:26:08  *** davec has quit IRC
135 2019-07-30T07:27:10  *** davec has joined #bitcoin-core-dev
136 2019-07-30T07:29:46  *** kljasdfvv has joined #bitcoin-core-dev
137 2019-07-30T07:39:07  *** rex4539 has quit IRC
138 2019-07-30T07:53:29  *** jungly has joined #bitcoin-core-dev
139 2019-07-30T07:59:43  *** Guyver2 has joined #bitcoin-core-dev
140 2019-07-30T08:00:44  *** laptop500 has joined #bitcoin-core-dev
141 2019-07-30T08:04:52  *** niska has quit IRC
142 2019-07-30T08:11:00  *** niska has joined #bitcoin-core-dev
143 2019-07-30T08:30:37  *** setpill has joined #bitcoin-core-dev
144 2019-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.
145 2019-07-30T08:31:31  <fanquake> Is/would there any benefit to keeping them siloed ?
146 2019-07-30T08:32:10  *** bitcoin-git has joined #bitcoin-core-dev
147 2019-07-30T08:32:10  <bitcoin-git> [bitcoin] meshcollider pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/33894612c0de...ff57fb457892
148 2019-07-30T08:32:11  <bitcoin-git> bitcoin/master 914923d Peter Bushnell: Add setting as known type
149 2019-07-30T08:32:11  <bitcoin-git> bitcoin/master ff57fb4 MeshCollider: Merge #15709: wallet: Do not add "setting" key as unknown
150 2019-07-30T08:32:13  *** bitcoin-git has left #bitcoin-core-dev
151 2019-07-30T08:32:50  *** bitcoin-git has joined #bitcoin-core-dev
152 2019-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
153 2019-07-30T08:32:51  *** bitcoin-git has left #bitcoin-core-dev
154 2019-07-30T08:36:00  *** bitcoin-git has joined #bitcoin-core-dev
155 2019-07-30T08:36:01  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ff57fb457892...53b5a4f7eca9
156 2019-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...
157 2019-07-30T08:36:02  <bitcoin-git> bitcoin/master 53b5a4f fanquake: Merge #16483: doc: update Python command in msvc readme
158 2019-07-30T08:36:03  *** bitcoin-git has left #bitcoin-core-dev
159 2019-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
160 2019-07-30T08:36:39  *** kcalvinalvin has quit IRC
161 2019-07-30T08:36:58  *** bitcoin-git has joined #bitcoin-core-dev
162 2019-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
163 2019-07-30T08:37:00  *** bitcoin-git has left #bitcoin-core-dev
164 2019-07-30T08:39:27  <fanquake> meshcollider: right, cheers
165 2019-07-30T08:41:54  <meshcollider> fanquake: in a pure descriptor wallet you would probably have 6 separate scriptpubkeymanagers though yes
166 2019-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
167 2019-07-30T08:46:03  *** kristapsk___ has joined #bitcoin-core-dev
168 2019-07-30T08:46:15  <fanquake> meshcollider: 👍
169 2019-07-30T08:47:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
170 2019-07-30T08:48:08  *** kristapsk_ has quit IRC
171 2019-07-30T09:00:01  *** keyboardsurfer has quit IRC
172 2019-07-30T09:09:56  *** timothy has joined #bitcoin-core-dev
173 2019-07-30T09:12:27  *** victorSN has quit IRC
174 2019-07-30T09:15:12  *** victorSN has joined #bitcoin-core-dev
175 2019-07-30T09:15:28  *** espadrine has joined #bitcoin-core-dev
176 2019-07-30T09:18:10  *** ezegom has joined #bitcoin-core-dev
177 2019-07-30T09:23:18  *** ezegom has quit IRC
178 2019-07-30T09:40:08  *** tryphe has quit IRC
179 2019-07-30T09:40:42  *** tryphe has joined #bitcoin-core-dev
180 2019-07-30T09:55:08  *** guest69 has quit IRC
181 2019-07-30T10:07:34  *** bitcoin-git has joined #bitcoin-core-dev
182 2019-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
183 2019-07-30T10:07:35  *** bitcoin-git has left #bitcoin-core-dev
184 2019-07-30T10:56:03  *** DeanGuss has quit IRC
185 2019-07-30T10:56:55  *** DeanGuss has joined #bitcoin-core-dev
186 2019-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.
187 2019-07-30T11:07:10  *** lightlike has joined #bitcoin-core-dev
188 2019-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).
189 2019-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.
190 2019-07-30T11:09:10  <jonasschnelli> (compared to the fixed 4 bytes command it would be +1 byte)
191 2019-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
192 2019-07-30T11:10:44  *** DeanGuss has quit IRC
193 2019-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.
194 2019-07-30T11:11:52  <jonasschnelli> Skipping a message needs one to read the "header" (in v2 case the command ID/name)
195 2019-07-30T11:11:59  *** emilengler has joined #bitcoin-core-dev
196 2019-07-30T11:17:27  *** anemous has joined #bitcoin-core-dev
197 2019-07-30T11:17:39  *** brianhoffman_ has joined #bitcoin-core-dev
198 2019-07-30T11:19:51  *** Sentineo has quit IRC
199 2019-07-30T11:20:07  *** Sentineo has joined #bitcoin-core-dev
200 2019-07-30T11:20:28  *** brianhoffman has quit IRC
201 2019-07-30T11:20:29  *** brianhoffman_ is now known as brianhoffman
202 2019-07-30T11:31:48  *** anemous has quit IRC
203 2019-07-30T11:36:40  *** anemous has joined #bitcoin-core-dev
204 2019-07-30T11:37:07  *** jungly has quit IRC
205 2019-07-30T11:38:37  *** jungly has joined #bitcoin-core-dev
206 2019-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
207 2019-07-30T11:39:05  <jonasschnelli> idles forever at my end
208 2019-07-30T11:51:11  *** anemous has quit IRC
209 2019-07-30T11:55:11  *** jonatack has joined #bitcoin-core-dev
210 2019-07-30T12:00:02  *** espadrine has quit IRC
211 2019-07-30T12:04:22  *** Mister_X1 has joined #bitcoin-core-dev
212 2019-07-30T12:04:39  <fanquake> jonasschnelli: loading ok for me here.
213 2019-07-30T12:15:29  <jonasschnelli> fanquake: maybe a local browser issue then
214 2019-07-30T12:15:42  <jonasschnelli> jup.
215 2019-07-30T12:30:30  *** elichai2 has joined #bitcoin-core-dev
216 2019-07-30T13:43:07  *** bitcoin-git has joined #bitcoin-core-dev
217 2019-07-30T13:43:08  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/53b5a4f7eca9...bd35ec36f5d6
218 2019-07-30T13:43:08  <bitcoin-git> bitcoin/master 29ee4c4 Daniel Kraft: Specify AM_CPPFLAGS for ZMQ.
219 2019-07-30T13:43:09  <bitcoin-git> bitcoin/master bd35ec3 Wladimir J. van der Laan: Merge #16434: build: Specify AM_CPPFLAGS for ZMQ
220 2019-07-30T13:43:11  *** bitcoin-git has left #bitcoin-core-dev
221 2019-07-30T13:44:07  *** bitcoin-git has joined #bitcoin-core-dev
222 2019-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
223 2019-07-30T13:44:10  *** bitcoin-git has left #bitcoin-core-dev
224 2019-07-30T13:49:46  <stevenroose> sipa, achow: importpubkey ought to recognize p2shwpkh addresses, right?
225 2019-07-30T13:49:56  <stevenroose> ah nvm
226 2019-07-30T13:50:28  *** d_t has joined #bitcoin-core-dev
227 2019-07-30T13:50:58  *** ezegom has joined #bitcoin-core-dev
228 2019-07-30T13:53:45  *** michagogo has quit IRC
229 2019-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
230 2019-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)
231 2019-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
232 2019-07-30T14:21:48  *** mryandao has quit IRC
233 2019-07-30T14:25:29  *** mryandao has joined #bitcoin-core-dev
234 2019-07-30T14:32:41  <elichai2> so I can negate the tweak and add it to the taproot key to get the internal key. cool
235 2019-07-30T14:34:11  *** spinza has quit IRC
236 2019-07-30T14:38:43  *** spinza has joined #bitcoin-core-dev
237 2019-07-30T14:39:09  <BlueMatt> jonasschnelli: I really hope we're not so starved for bandwidth that we can't afford 3 extra bytes
238 2019-07-30T14:39:24  <BlueMatt> and if we are, we can just have more things in each inv, no?
239 2019-07-30T14:42:55  *** mdunnio has joined #bitcoin-core-dev
240 2019-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.
241 2019-07-30T14:45:21  <jonasschnelli> BlueMatt: bundling inv's.. sure. Not always possible.
242 2019-07-30T14:45:23  <BlueMatt> over-optimizing is the root of all evil :p
243 2019-07-30T14:45:38  <jonasschnelli> Sure. But I think we are in an acceptable range of optimizing.
244 2019-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
245 2019-07-30T14:46:33  <BlueMatt> if we're not, we can bundle more
246 2019-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
247 2019-07-30T14:47:00  <BlueMatt> in exchange for a constant length header
248 2019-07-30T14:47:04  <BlueMatt> which is way easier to deal with
249 2019-07-30T14:48:33  *** mdunnio has quit IRC
250 2019-07-30T14:49:42  *** mdunnio has joined #bitcoin-core-dev
251 2019-07-30T14:50:54  *** d_t has quit IRC
252 2019-07-30T14:50:57  *** mdunnio has quit IRC
253 2019-07-30T14:51:28  *** mdunnio has joined #bitcoin-core-dev
254 2019-07-30T14:54:34  <sipa> jonasschnelli: i don't care much about variable length either, but it seems a sticking point for BlueMatt
255 2019-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
256 2019-07-30T14:56:48  <sipa> elichai2: IsSolvable meams "you know enough to sign under all conditions, if you had the private keys"
257 2019-07-30T14:57:13  <sipa> elichai2: taproot descriptors would always be solvable
258 2019-07-30T14:57:38  *** roconnor has joined #bitcoin-core-dev
259 2019-07-30T14:57:40  <elichai2> i'm talking about a different `IsSolvable` haha
260 2019-07-30T14:57:43  <elichai2> in sign.cpp
261 2019-07-30T14:57:57  <elichai2> (the one that's used in descriptors_test.cpp )
262 2019-07-30T14:57:59  <sipa> oh, i see
263 2019-07-30T14:59:03  *** bitcoin-git has joined #bitcoin-core-dev
264 2019-07-30T14:59:03  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/bd35ec36f5d6...74f1a27f2f45
265 2019-07-30T14:59:03  <bitcoin-git> bitcoin/master 0c78e49 practicalswift: tests: Switch one of the Travis jobs to an unsigned char environment (-fun...
266 2019-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...
267 2019-07-30T14:59:05  *** bitcoin-git has left #bitcoin-core-dev
268 2019-07-30T14:59:33  *** bitcoin-git has joined #bitcoin-core-dev
269 2019-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
270 2019-07-30T14:59:35  *** bitcoin-git has left #bitcoin-core-dev
271 2019-07-30T14:59:41  <sipa> elichai2: the concept of solvable there needs to go away i think
272 2019-07-30T14:59:55  <sipa> elichai2: it captures whether you're able to estimate fees
273 2019-07-30T15:00:02  *** Mister_X1 has quit IRC
274 2019-07-30T15:00:17  <elichai2> wait what. I thought it checks if you have the right script+private key
275 2019-07-30T15:00:30  <elichai2> like, it literally tries to produce a signature
276 2019-07-30T15:02:10  <jonasschnelli> BlueMatt, sipa: sorry... was on the phone. BlueMatt: what are the benefits of a constant length "header"?
277 2019-07-30T15:02:32  *** reardencode has quit IRC
278 2019-07-30T15:02:35  <jonasschnelli> Also, V2's "header" is the encrypted length & MAC TAG
279 2019-07-30T15:03:30  *** lliehu1 has joined #bitcoin-core-dev
280 2019-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.
281 2019-07-30T15:04:48  <jonasschnelli> I also don't fully buy into the anit-collision argument
282 2019-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?
283 2019-07-30T15:06:23  <sipa> elichai2: it basically checks if you can sign with a dummysigner (which doesn't need private keys)
284 2019-07-30T15:06:38  <sipa> elichai2: you shouldn't need taproot specific logic; just signing logix
285 2019-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
286 2019-07-30T15:08:49  *** reardencode has joined #bitcoin-core-dev
287 2019-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
288 2019-07-30T15:10:09  <jonasschnelli> [16:46:57]  <BlueMatt>	in exchange for a constant length header [...] which is way easier to deal with
289 2019-07-30T15:10:32  <jonasschnelli> ^^^ can you elaborate a bit more on this?
290 2019-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
291 2019-07-30T15:11:18  <jonasschnelli> You have a raw packet on the stream [3 bytes encrypted length] + [ ? encrypted payload ] + [ 16 bytes MAC]
292 2019-07-30T15:11:28  <jonasschnelli> (varlen already)
293 2019-07-30T15:11:35  <jonasschnelli> you check the mac and decrypt
294 2019-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)
295 2019-07-30T15:13:10  *** reardencode has quit IRC
296 2019-07-30T15:13:26  <phantomcircuit> jonasschnelli, it's infinitely easier to parse a constant length header than a variable length one
297 2019-07-30T15:13:56  <jonasschnelli> phantomcircuit: easier in what context?
298 2019-07-30T15:14:10  <jonasschnelli> I mean the message that follows has very likely also variable length fields
299 2019-07-30T15:14:37  *** Chris_Stewart_5 has quit IRC
300 2019-07-30T15:15:07  <sipa> elichai2: yes, you need taproot signing logic
301 2019-07-30T15:15:23  <sipa> if you have that, IsSolvable will work automatically
302 2019-07-30T15:15:29  *** davterra has quit IRC
303 2019-07-30T15:17:17  *** reardencode has joined #bitcoin-core-dev
304 2019-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 :)
305 2019-07-30T15:19:32  *** setpill has quit IRC
306 2019-07-30T15:20:29  *** bitcoin-git has joined #bitcoin-core-dev
307 2019-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
308 2019-07-30T15:20:42  *** bitcoin-git has left #bitcoin-core-dev
309 2019-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
310 2019-07-30T15:27:26  <sipa> elichai2: for key paths, it would contain the tweak and the pubkey it's derived from
311 2019-07-30T15:27:46  <sipa> elichai2: for script paths it would contain leaf version, script, and Merkle path
312 2019-07-30T15:28:04  <sipa> the advantage is that this approach works evenn when you don't know all scripts
313 2019-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
314 2019-07-30T15:28:33  <sipa> right
315 2019-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
316 2019-07-30T15:28:49  <sipa> i don't
317 2019-07-30T15:29:01  <elichai2> because that mean you might not really "own" the coins
318 2019-07-30T15:29:43  <sipa> there is a difference between treating a coin as yours, and participating in signing
319 2019-07-30T15:30:11  <sipa> the descriptor side of things will always have the whole tree, and is used for determining what is yours
320 2019-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)
321 2019-07-30T15:30:28  <elichai2> sipa: right
322 2019-07-30T15:30:30  <sipa> i think it can be CScript
323 2019-07-30T15:30:42  <elichai2> even with the redundancy?
324 2019-07-30T15:31:05  <sipa> the scripts shouldn't be in the normal script map i think
325 2019-07-30T15:31:17  <sipa> as they're distinct anyway
326 2019-07-30T15:31:42  <sipa> as in: they ought to be a distinct namespace, because taproot scripts have different semantics
327 2019-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?
328 2019-07-30T15:32:48  <elichai2> sipa: but if I have `tap(key, [p2k(...), p2kh(...)])` I want to use the PKDescriptor and PKHDescriptor descriptors
329 2019-07-30T15:33:04  <elichai2> and in the end it's still `OP_CHECKSIG`
330 2019-07-30T15:34:26  *** kljasdfvv has quit IRC
331 2019-07-30T15:35:29  <sipa> hugohn: the IsMine logic will just be descriptors
332 2019-07-30T15:35:44  <sipa> in no way should taproot stuff influence the old legacy IsMine code
333 2019-07-30T15:36:00  <sipa> elichai2: ok, so?
334 2019-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
335 2019-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?
336 2019-07-30T15:38:32  <sipa> hugohn: no
337 2019-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
338 2019-07-30T15:38:49  <sipa> hugohn: there is a map of scriptPubKeys
339 2019-07-30T15:39:10  <sipa> hugohn: that is not the same map as the mapScripts in signing providers
340 2019-07-30T15:39:28  <elichai2> makes sense. so the ExpandHelper could also generate all the possible script paths and add them to the provider
341 2019-07-30T15:39:57  <sipa> right, or the taproot specific code does that
342 2019-07-30T15:40:06  <elichai2> right
343 2019-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)
344 2019-07-30T15:42:33  *** captjakk has joined #bitcoin-core-dev
345 2019-07-30T15:42:56  <sipa> elichai2: i think it makes sense that descripts for now only support tapscript v0
346 2019-07-30T15:43:02  <sipa> *descriptors
347 2019-07-30T15:43:27  <sipa> i think for psbt extensions we do want to support encoding other tapscript versions
348 2019-07-30T15:43:40  <elichai2> 👍 yeah. probably won't see a new tapscript version for a while haha
349 2019-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.
350 2019-07-30T15:46:54  <sipa> hugohn: i don't think the descriptor wallet code will need to change at all
351 2019-07-30T15:47:17  <sipa> hugohn: taproot descriptors will still be populating the list of scriptPubKeys to watch for
352 2019-07-30T15:47:48  <sipa> the mapScripts/taproot tree elichai2 and i were talking about is for internal scripts, not scriptPubKeys
353 2019-07-30T15:48:26  *** jcorgan has joined #bitcoin-core-dev
354 2019-07-30T15:48:48  <elichai2> yep. the scriptPubKey is the easiest part.
355 2019-07-30T15:48:52  <phantomcircuit> jonasschnelli, it means you can just copy the a buffer into the fields without much real logic
356 2019-07-30T15:52:05  <sipa> jonasschnelli: well for new message types they can be selected to not collide with existing ones
357 2019-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?
358 2019-07-30T15:52:21  *** afigs has joined #bitcoin-core-dev
359 2019-07-30T15:52:32  <sipa> hugohn: signingprovider will get extra fields yes
360 2019-07-30T15:52:44  <sipa> but they should 't really interact with descriptor wallets
361 2019-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
362 2019-07-30T15:53:39  <elichai2> phantomcircuit: bitcoin core already uses variables sizes for everything.
363 2019-07-30T15:55:00  <sipa> elichai2: i think BlueMatt's comment is mostly for the sake of other implementations
364 2019-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
365 2019-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?
366 2019-07-30T15:56:06  <BlueMatt> elichai2: we actually dont for the headers
367 2019-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
368 2019-07-30T15:56:39  <jonasschnelli> Yes. I think in general it's an acceptable idea... but...
369 2019-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
370 2019-07-30T15:57:09  <BlueMatt> jonasschnelli: the header is not, no? and its a different layer - net vs protocol/net_processing deserialization
371 2019-07-30T15:57:21  <BlueMatt> the net code isnt aware of what the message contains, or how to deserialize it
372 2019-07-30T15:57:25  <BlueMatt> and it is dead simple
373 2019-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
374 2019-07-30T15:58:31  <jonasschnelli> In current v2: the headers is the short-ID where ID 1-12 is a varlen string message-command
375 2019-07-30T15:58:33  <BlueMatt> dont think endlessly debating it is really worth it, that is
376 2019-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
377 2019-07-30T15:59:06  * BlueMatt -> lunch
378 2019-07-30T15:59:13  <sipa> well, the payload is also variable size, obviously
379 2019-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.
380 2019-07-30T15:59:31  <jonasschnelli> sipa: excactly.
381 2019-07-30T16:00:10  <BlueMatt> the compexity it adds is, however, non-0, and the cost it removes *is* 0 :p
382 2019-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).
383 2019-07-30T16:00:32  <jonasschnelli> BlueMatt: I disagree. :)
384 2019-07-30T16:00:44  <sipa> hugohn: yes, descriptors very much interact with signingproviders
385 2019-07-30T16:00:54  <sipa> hugohn: but the wallet code shouldn't
386 2019-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)
387 2019-07-30T16:00:59  <jonasschnelli> BlueMatt: ^
388 2019-07-30T16:01:18  <hugohn> sipa: right. ok it's clear to me now. thanks!
389 2019-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
390 2019-07-30T16:02:07  <sipa> though i need to read up on the openssl chacha/poly1305 design to understand it better
391 2019-07-30T16:03:34  <jonasschnelli> sipa: Yeah, that's maybe a point. Though, in most cases, you'll never ever use variable length messages.
392 2019-07-30T16:03:53  <jonasschnelli> BIP324 defines short ids (single byte command) for every message.
393 2019-07-30T16:04:00  <jonasschnelli> New messages could do the same,...
394 2019-07-30T16:04:11  <sipa> jonasschnelli: there may be coordination issues there
395 2019-07-30T16:04:17  <jonasschnelli> using string based message commands is more for extensions that don't want to deal with short IDs
396 2019-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.
397 2019-07-30T16:04:57  *** mdunnio has quit IRC
398 2019-07-30T16:05:02  <jonasschnelli> The fallback to string base commands is unused in the ideal case
399 2019-07-30T16:05:30  <jonasschnelli> except a fork-coin adds shit messages and don't bother with adding a short ID
400 2019-07-30T16:05:34  *** mdunnio has joined #bitcoin-core-dev
401 2019-07-30T16:06:39  *** mdunnio has quit IRC
402 2019-07-30T16:06:53  *** mdunnio has joined #bitcoin-core-dev
403 2019-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
404 2019-07-30T16:07:07  <jonasschnelli> And I do think 3 bytes matter. Especially if we know that almost 50% of our messages. are <=64bytes.
405 2019-07-30T16:07:31  <jonasschnelli> Which results that 3bytes may be 5%.
406 2019-07-30T16:07:38  <jonasschnelli> (BTCFlood though)
407 2019-07-30T16:08:03  <jonasschnelli> phantomcircuit: ehm?
408 2019-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?
409 2019-07-30T16:09:32  *** pinheadmz_ has quit IRC
410 2019-07-30T16:09:42  <sipa> jonasschnelli: let me think think things through the next days
411 2019-07-30T16:09:49  <sipa> hugohn: yw
412 2019-07-30T16:10:18  <jonasschnelli> sipa:  Sure. Thanks for digging in!
413 2019-07-30T16:10:44  <jonasschnelli> phantomcircuit: https://bitcoinbuilds.org/v2.png
414 2019-07-30T16:10:50  *** afigs has quit IRC
415 2019-07-30T16:11:17  * jonasschnelli break
416 2019-07-30T16:12:04  *** bitcoin-git has joined #bitcoin-core-dev
417 2019-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
418 2019-07-30T16:12:12  *** bitcoin-git has left #bitcoin-core-dev
419 2019-07-30T16:12:51  *** emilengler has quit IRC
420 2019-07-30T16:17:11  <phantomcircuit> jonasschnelli, the length is encrypted?
421 2019-07-30T16:17:32  <jonasschnelli> jup
422 2019-07-30T16:17:35  <phantomcircuit> i guess that makes sense
423 2019-07-30T16:17:38  <phantomcircuit> shrug
424 2019-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.
425 2019-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....
426 2019-07-30T16:20:43  <BlueMatt> in this case its not as much an issue cause at least its only twice
427 2019-07-30T16:20:58  <BlueMatt> so, again, not worth endless debate around it, I'm happy to not care anymore.
428 2019-07-30T16:21:05  <BlueMatt> just answering your question of why
429 2019-07-30T16:21:42  *** wbnns has quit IRC
430 2019-07-30T16:21:46  *** tryphe_ has joined #bitcoin-core-dev
431 2019-07-30T16:22:13  *** mariorz has quit IRC
432 2019-07-30T16:22:40  <jonasschnelli> thanks! i totaly agree with all of your point... but... we deal with inner messages (decrypted)
433 2019-07-30T16:23:09  *** tryphe has quit IRC
434 2019-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)
435 2019-07-30T16:23:48  <sipa> jonasschnelli: the 'encrypted length' field covers the sum of message type and payload, or not?
436 2019-07-30T16:24:02  <sipa> (i think it should)
437 2019-07-30T16:24:04  *** NicolasDorier has quit IRC
438 2019-07-30T16:24:18  *** fjahr has quit IRC
439 2019-07-30T16:25:05  <jonasschnelli> the payload of a encrypted packet is [message command short ID + message payload]
440 2019-07-30T16:25:26  <jonasschnelli> so the encrypted length is on the network layer
441 2019-07-30T16:25:35  <sipa> ok, so the encrypted length is the length of the encrypted payload, not just the message payload?
442 2019-07-30T16:25:45  <jonasschnelli> yes
443 2019-07-30T16:25:50  *** pinheadmz has joined #bitcoin-core-dev
444 2019-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.
445 2019-07-30T16:26:16  *** fjahr has joined #bitcoin-core-dev
446 2019-07-30T16:26:51  *** NicolasDorier has joined #bitcoin-core-dev
447 2019-07-30T16:26:52  *** wbnns has joined #bitcoin-core-dev
448 2019-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
449 2019-07-30T16:27:48  <sipa> so there are no additional variable length buffers or so involved
450 2019-07-30T16:28:02  <sipa> just a decision where the command ends and where the message payload begins
451 2019-07-30T16:28:11  <jonasschnelli> yes.
452 2019-07-30T16:28:24  *** mariorz has joined #bitcoin-core-dev
453 2019-07-30T16:28:37  <jonasschnelli> eventually the v2 header is the 3 byte payload length
454 2019-07-30T16:28:54  *** captjakk has quit IRC
455 2019-07-30T16:29:28  *** captjakk has joined #bitcoin-core-dev
456 2019-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
457 2019-07-30T16:30:12  <jonasschnelli> (though I hope I'm right)
458 2019-07-30T16:30:15  *** captjakk has quit IRC
459 2019-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
460 2019-07-30T16:30:33  *** captjakk has joined #bitcoin-core-dev
461 2019-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)
462 2019-07-30T16:31:19  <sipa> if you do it afterwards, it'll may hard to avoid a copy
463 2019-07-30T16:32:01  <jonasschnelli> I see...
464 2019-07-30T16:32:01  <sipa> with fixed command size you could split on the fly without that risk
465 2019-07-30T16:32:03  *** mdunnio has quit IRC
466 2019-07-30T16:32:12  <jonasschnelli> hmm?
467 2019-07-30T16:32:25  <sipa> it'd just be "first 3 bytes go here, other bytes go there"
468 2019-07-30T16:32:31  <sipa> without looking at what those bytes are
469 2019-07-30T16:32:38  <sipa> (3 or 4 or whatever)
470 2019-07-30T16:32:53  <jonasschnelli> I see
471 2019-07-30T16:33:04  <sipa> there actually is another solution: putting the information on variable length command or not in the length field
472 2019-07-30T16:33:12  <sipa> but that's... even less conventional
473 2019-07-30T16:33:38  <jonasschnelli> so.. your saying, before we decrypt, we place the 4 byte command string into a buffer and the payload
474 2019-07-30T16:34:03  <sipa> if decryption is in-place, sure
475 2019-07-30T16:34:08  *** promag has joined #bitcoin-core-dev
476 2019-07-30T16:34:11  <jonasschnelli> then decrypt the fix length command and not needing to deal with buffers anymore
477 2019-07-30T16:34:20  <jonasschnelli> I think this is a valid point
478 2019-07-30T16:34:26  <sipa> let me write things in pseudocode
479 2019-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?
480 2019-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
481 2019-07-30T16:35:09  <jonasschnelli> and if not, we do a copy.
482 2019-07-30T16:35:25  <sipa> jonasschnelli: copy should always be avoidable
483 2019-07-30T16:35:43  <jonasschnelli> yes.
484 2019-07-30T16:36:31  *** mariorz has quit IRC
485 2019-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
486 2019-07-30T16:36:44  <jonasschnelli> I need to go through the code...
487 2019-07-30T16:36:47  <phantomcircuit> (although i do understand it being after makes it easier to stream data out)
488 2019-07-30T16:36:51  <sipa> phantomcircuit: but it's also the only option if you want to avoid a copy
489 2019-07-30T16:37:09  <phantomcircuit> sipa, uh why
490 2019-07-30T16:37:23  <phantomcircuit> wait a copy on the sender or a copy on the receivers side?
491 2019-07-30T16:37:41  <sipa> phantomcircuit: you'd need to buffer the unencrypted data when sending
492 2019-07-30T16:37:46  *** digi_james has quit IRC
493 2019-07-30T16:38:06  <sipa> or the encrypted data, also possible
494 2019-07-30T16:38:10  <phantomcircuit> sipa, it's probably getting buffered anyways but in smaller pieces
495 2019-07-30T16:38:18  <sipa> maybe
496 2019-07-30T16:38:48  *** digi_james has joined #bitcoin-core-dev
497 2019-07-30T16:39:03  *** mariorz has joined #bitcoin-core-dev
498 2019-07-30T16:39:04  <phantomcircuit> either way objects being serialized are going to be copied into a buffer
499 2019-07-30T16:39:25  *** jarthur has joined #bitcoin-core-dev
500 2019-07-30T16:39:27  <sipa> sure, but putting MAC first means an additional buffering either way on top of whatever else is being done
501 2019-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
502 2019-07-30T16:40:11  <sipa> ok, fair, put otherwise: you're going to need to go over your data twice
503 2019-07-30T16:40:17  *** behradkhodayar has joined #bitcoin-core-dev
504 2019-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
505 2019-07-30T16:42:16  *** anemous has joined #bitcoin-core-dev
506 2019-07-30T16:42:31  *** behrad_khodayar has joined #bitcoin-core-dev
507 2019-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
508 2019-07-30T16:43:04  <sipa> the mac is computed over the encrypted data
509 2019-07-30T16:43:14  <phantomcircuit> yeah that's what i said
510 2019-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
511 2019-07-30T16:43:42  <sipa> if the mac goes last, you can interleave encryption and sending
512 2019-07-30T16:44:10  <phantomcircuit> yeah but you cant deallocate anything anyways so it's just a very small latency win
513 2019-07-30T16:44:37  <sipa> for large messages it may matter, but agree it's a small point
514 2019-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
515 2019-07-30T16:45:09  <phantomcircuit> i mean our largest message is like 2MB right?
516 2019-07-30T16:45:12  <sipa> well you very much can decrypt before checking mac
517 2019-07-30T16:45:20  <sipa> you just can't use the data before doing so
518 2019-07-30T16:45:30  <phantomcircuit> chacha20 + mac over 2MB on even an rpi3 is going to be basically instant
519 2019-07-30T16:45:49  <sipa> or can't make any decision that the other party can observe based on that decrypted data even
520 2019-07-30T16:46:27  <phantomcircuit> right
521 2019-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
522 2019-07-30T16:47:28  <sipa> phantomcircuit: 7.5 ms on a RK3399 ARM64 CPU to decrypt/auth 1MB of data
523 2019-07-30T16:47:46  <sipa> that's not nothing
524 2019-07-30T16:48:03  <sipa> the poly1305 code can be optimized more, though
525 2019-07-30T16:48:22  <jonasschnelli> sipa: I don't think we need to copy
526 2019-07-30T16:48:35  *** davterra has joined #bitcoin-core-dev
527 2019-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
528 2019-07-30T16:49:56  <sipa> jonasschnelli: yeah, that's fair
529 2019-07-30T16:50:16  <jonasschnelli> Looking at the (old) V2 code,... I think there is no copy involved
530 2019-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
531 2019-07-30T16:51:09  <jonasschnelli> So the variable length message command is more or less part of the message (which is vlen anyways)
532 2019-07-30T16:51:17  *** behradkhodayar has quit IRC
533 2019-07-30T16:51:34  <sipa> and you can, and it's probably fine... just a bit scary
534 2019-07-30T16:51:48  <jonasschnelli> sipa: decrypting on the fly is orthogonal to the fixed length command string, right?
535 2019-07-30T16:52:10  <sipa> ah i see, with that CDataStream trick it is
536 2019-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
537 2019-07-30T16:52:47  <jonasschnelli> yes
538 2019-07-30T16:52:51  <sipa> yup, agree
539 2019-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.
540 2019-07-30T16:53:55  <jonasschnelli> We then eventually only do xors in the network code
541 2019-07-30T16:54:23  <sipa> heh, good point
542 2019-07-30T16:54:53  <sipa> ok, i agree that the ability to decode on the fly isn't an argument against variable length commands
543 2019-07-30T16:55:54  <jonasschnelli> The remaining question is whether the variable length command increases message type detectability
544 2019-07-30T16:56:23  <sipa> not if the encrypted length covers the command as well
545 2019-07-30T16:56:39  <jonasschnelli> Yes. It does. So I also think it's not an agrument.
546 2019-07-30T16:56:50  *** Chris_Stewart_5 has joined #bitcoin-core-dev
547 2019-07-30T16:57:17  <jonasschnelli> Which makes me again think saving 3 bytes is worth the variable length command
548 2019-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"
549 2019-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
550 2019-07-30T16:58:41  <jonasschnelli> sipa: Yes. I think that definition clears up things
551 2019-07-30T16:58:46  <sipa> so i'm fine with whatever
552 2019-07-30T16:59:14  <jonasschnelli> Somehow I care about those 3 bytes... maybe wrongly.
553 2019-07-30T16:59:19  <sipa> including BlueMatt's suggestion earlier of only supporting 1-byte and 12-byte commands
554 2019-07-30T16:59:58  <jonasschnelli> Though there is a yes/no wether a V2 inv is larger than a V1 inv.
555 2019-07-30T17:00:03  *** jungly has quit IRC
556 2019-07-30T17:00:42  <jonasschnelli> though with a 4 bytes fixed length command. It would still be 1 bytes smaller then V1.
557 2019-07-30T17:01:07  <jonasschnelli> *than V1*
558 2019-07-30T17:02:36  *** mdunnio has joined #bitcoin-core-dev
559 2019-07-30T17:06:51  *** profmac has quit IRC
560 2019-07-30T17:07:33  *** mdunnio has quit IRC
561 2019-07-30T17:10:33  *** profmac has joined #bitcoin-core-dev
562 2019-07-30T17:11:12  *** promag has quit IRC
563 2019-07-30T17:11:59  *** promag has joined #bitcoin-core-dev
564 2019-07-30T17:25:11  *** mdunnio has joined #bitcoin-core-dev
565 2019-07-30T17:49:37  *** spaced0ut has quit IRC
566 2019-07-30T17:51:59  *** timothy has quit IRC
567 2019-07-30T17:55:51  *** captjakk has quit IRC
568 2019-07-30T17:56:33  *** bitcoin-git has joined #bitcoin-core-dev
569 2019-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
570 2019-07-30T17:56:35  *** bitcoin-git has left #bitcoin-core-dev
571 2019-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
572 2019-07-30T17:59:40  *** behradkhodayar has joined #bitcoin-core-dev
573 2019-07-30T18:00:02  *** lliehu1 has quit IRC
574 2019-07-30T18:03:41  *** pinheadmz has quit IRC
575 2019-07-30T18:03:55  *** bitcoin-git has joined #bitcoin-core-dev
576 2019-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
577 2019-07-30T18:03:56  *** bitcoin-git has left #bitcoin-core-dev
578 2019-07-30T18:04:36  *** michagogo has joined #bitcoin-core-dev
579 2019-07-30T18:04:40  *** MarconM has joined #bitcoin-core-dev
580 2019-07-30T18:05:02  *** mdunnio has quit IRC
581 2019-07-30T18:05:45  *** bitcoin-git has joined #bitcoin-core-dev
582 2019-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
583 2019-07-30T18:05:47  *** bitcoin-git has left #bitcoin-core-dev
584 2019-07-30T18:07:50  *** behradkhodayar has quit IRC
585 2019-07-30T18:10:34  <BlueMatt> ^ seeking concept review :)
586 2019-07-30T18:10:59  <BlueMatt> also seeking ibd benchmarks from multiple peers....(jamesob :p)
587 2019-07-30T18:12:50  *** mdunnio has joined #bitcoin-core-dev
588 2019-07-30T18:14:56  *** jarthur has quit IRC
589 2019-07-30T18:15:33  *** pinheadmz has joined #bitcoin-core-dev
590 2019-07-30T18:15:35  *** jarthur has joined #bitcoin-core-dev
591 2019-07-30T18:17:00  *** anemous has quit IRC
592 2019-07-30T18:18:44  *** reallll has joined #bitcoin-core-dev
593 2019-07-30T18:21:23  *** belcher has quit IRC
594 2019-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
595 2019-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
596 2019-07-30T18:25:36  <gleb> Oops, you are right, it would announce already known transactions potentially.
597 2019-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)
598 2019-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).
599 2019-07-30T18:46:27  <gleb> So the question is really how we should act at the node which triggers rebroadcast.
600 2019-07-30T18:46:52  <sipa> an alternative to rebroadcasting is of course mempool (full mempool, not relay) reconciliation...
601 2019-07-30T18:48:27  <gleb> Which is essentially just batching rebroadcasts over an hour or whatever.
602 2019-07-30T18:49:56  *** hebasto has quit IRC
603 2019-07-30T18:54:38  *** jarthur has quit IRC
604 2019-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)
605 2019-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.
606 2019-07-30T18:58:47  <sipa> it can be orthogonal of course; post-erlay the rebroadcasts can just stay normal invs too
607 2019-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
608 2019-07-30T19:01:17  *** jarthur has joined #bitcoin-core-dev
609 2019-07-30T19:02:37  *** anemous has joined #bitcoin-core-dev
610 2019-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.
611 2019-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.
612 2019-07-30T19:10:25  <gleb> In the case of regular inv rebroadcast *
613 2019-07-30T19:12:33  *** captjakk has joined #bitcoin-core-dev
614 2019-07-30T19:12:56  *** reallll is now known as belcher
615 2019-07-30T19:14:04  *** mdunnio has quit IRC
616 2019-07-30T19:17:08  *** davex_ has quit IRC
617 2019-07-30T19:21:57  *** mdunnio has joined #bitcoin-core-dev
618 2019-07-30T19:23:14  *** mdunnio has quit IRC
619 2019-07-30T19:28:20  *** mdunnio has joined #bitcoin-core-dev
620 2019-07-30T19:32:28  <phantomcircuit> BlueMatt, it's 10% faster to skip the bip30 checks
621 2019-07-30T19:33:07  *** ezegom has quit IRC
622 2019-07-30T19:34:07  *** ezegom has joined #bitcoin-core-dev
623 2019-07-30T19:34:13  <BlueMatt> hmm, fun.
624 2019-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
625 2019-07-30T19:37:51  <BlueMatt> if you write a test that tests shit like that, I'll be happy :p
626 2019-07-30T19:44:31  *** jarthur has quit IRC
627 2019-07-30T19:44:42  *** roconnor has quit IRC
628 2019-07-30T19:45:10  *** jarthur has joined #bitcoin-core-dev
629 2019-07-30T19:53:47  *** mdunnio has quit IRC
630 2019-07-30T19:54:05  *** mdunnio has joined #bitcoin-core-dev
631 2019-07-30T19:57:58  <BlueMatt> fanquake: care2merge #16433
632 2019-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
633 2019-07-30T19:59:16  <jonasschnelli> BlueMatt: hell.. It's 4am for poor fanquake. Let me have a look. :)
634 2019-07-30T19:59:30  <BlueMatt> oh, ehh, bad timezone conversion, was thinking it was later than it was
635 2019-07-30T19:59:32  <sipa> I thought fanquake lived in a timeless realm
636 2019-07-30T19:59:38  <jonasschnelli> heh
637 2019-07-30T19:59:40  <BlueMatt> whatever, its trivial
638 2019-07-30T20:00:07  *** captjakk has quit IRC
639 2019-07-30T20:00:33  *** captjakk has joined #bitcoin-core-dev
640 2019-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
641 2019-07-30T20:02:02  <jonasschnelli> BlueMatt: your utACK didn't end up in the commit merge message because you missed the commit hash :P
642 2019-07-30T20:02:08  <BlueMatt> jonasschnelli: meh
643 2019-07-30T20:02:13  <BlueMatt> its trivial enough I figured no one cared
644 2019-07-30T20:02:22  <BlueMatt> jimpo: hmm?
645 2019-07-30T20:02:32  <jonasschnelli> somehow github-merge.py does
646 2019-07-30T20:02:35  *** bitcoin-git has joined #bitcoin-core-dev
647 2019-07-30T20:02:36  <bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/74f1a27f2f45...39763b75556b
648 2019-07-30T20:02:36  <bitcoin-git> bitcoin/master 0000ff0 MarcoFalke: txmempool: Remove unused default value MemPoolRemovalReason::UNKNOWN
649 2019-07-30T20:02:36  <bitcoin-git> bitcoin/master 39763b7 Jonas Schnelli: Merge #16433: txmempool: Remove unused default value MemPoolRemovalReason:...
650 2019-07-30T20:02:37  *** jarthur has quit IRC
651 2019-07-30T20:02:49  *** bitcoin-git has left #bitcoin-core-dev
652 2019-07-30T20:02:53  <BlueMatt> jonasschnelli: right, I mean no reason to need or care about anoher ack on something that trivial
653 2019-07-30T20:03:02  <jonasschnelli> sure
654 2019-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?
655 2019-07-30T20:03:26  <BlueMatt> jimpo: right, thats why I was referencing
656 2019-07-30T20:03:35  *** bitcoin-git has joined #bitcoin-core-dev
657 2019-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
658 2019-07-30T20:03:48  *** bitcoin-git has left #bitcoin-core-dev
659 2019-07-30T20:04:06  <BlueMatt> jimpo: ah, you're right
660 2019-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
661 2019-07-30T20:04:12  <BlueMatt> jimpo: yea, doesn't matter
662 2019-07-30T20:04:31  <BlueMatt> no, specifically it doesnt matter cause it doesn't reveal information
663 2019-07-30T20:04:52  *** captjakk has quit IRC
664 2019-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
665 2019-07-30T20:05:03  <BlueMatt> so hiding the fact that you have those blocks...welll...you're not hiding anything
666 2019-07-30T20:05:09  <jimpo> well yes, that too
667 2019-07-30T20:05:41  <jimpo> I mean, I still think having the BlockRequestAllowed check in addition to the BLOCK_VALID_SCRIPTS check is valuable
668 2019-07-30T20:05:54  <jimpo> but just on the stop block should be fine
669 2019-07-30T20:06:27  <BlueMatt> hmm? no my point with that comment was that BlockRequestAllowed already does the BLOCK_VALID_SCRIPTS check for you
670 2019-07-30T20:06:30  <BlueMatt> so....no reason to call it again
671 2019-07-30T20:06:39  <jimpo> yes, I agree with that
672 2019-07-30T20:06:45  <jimpo> I am removing the redundant check
673 2019-07-30T20:07:09  <jimpo> but it's still better to do the full BlockRequestAllowed check instead of just the BLOCK_VALID_SCRIPTS check
674 2019-07-30T20:07:25  *** ezegom has quit IRC
675 2019-07-30T20:07:42  *** farmerwampum has quit IRC
676 2019-07-30T20:08:00  <BlueMatt> not just better, you must
677 2019-07-30T20:08:09  *** jarthur has joined #bitcoin-core-dev
678 2019-07-30T20:08:28  *** pinheadmz has quit IRC
679 2019-07-30T20:08:29  <jimpo> just to prevent fingerprinting, right? Or is there another reason?
680 2019-07-30T20:08:33  <BlueMatt> right
681 2019-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
682 2019-07-30T20:08:53  <phantomcircuit> except that it doesn't let a miner steal coins just destroy them
683 2019-07-30T20:08:54  <phantomcircuit> so like
684 2019-07-30T20:08:55  <BlueMatt> phantomcircuit: ehhh, the cache flushing shit is....complicated
685 2019-07-30T20:08:55  <phantomcircuit> why
686 2019-07-30T20:09:02  <BlueMatt> phantomcircuit: go read the comment(s) there, and then test it anyway :P
687 2019-07-30T20:09:09  *** ezegom has joined #bitcoin-core-dev
688 2019-07-30T20:09:27  <phantomcircuit> BlueMatt, there's no cache flushing issues
689 2019-07-30T20:09:49  <phantomcircuit> the BIP30 checks are literally always cache miss down to disk unless the blocks invalid
690 2019-07-30T20:09:50  *** pinheadmz has joined #bitcoin-core-dev
691 2019-07-30T20:10:41  <phantomcircuit> sdaftuar, did i read your comment right?
692 2019-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?
693 2019-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%
694 2019-07-30T20:11:28  <BlueMatt> jimpo: thats my understanding yes, not sure what your reasoning is
695 2019-07-30T20:11:37  <BlueMatt> phantomcircuit: ah, right, sorry, I'm mis-thinking about this
696 2019-07-30T20:12:07  *** pinheadmz has quit IRC
697 2019-07-30T20:13:17  *** captjakk has joined #bitcoin-core-dev
698 2019-07-30T20:14:54  <phantomcircuit> BlueMatt, wait does leveldb do a bloomfilter lookup for key existence?
699 2019-07-30T20:15:02  <sipa> yes
700 2019-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?
701 2019-07-30T20:16:33  *** pinheadmz has joined #bitcoin-core-dev
702 2019-07-30T20:18:36  <sipa> yes
703 2019-07-30T20:18:46  <sipa> and the bloomfilter is likely cached in ram
704 2019-07-30T20:20:54  *** ezegom has quit IRC
705 2019-07-30T20:22:23  *** ezegom has joined #bitcoin-core-dev
706 2019-07-30T20:26:07  <jonasschnelli> #proposedmeetingtopic bitcoin-dev mailing list moderation
707 2019-07-30T20:26:17  <BlueMatt> oh boy
708 2019-07-30T20:26:31  <jonasschnelli> heh... don't fear
709 2019-07-30T20:26:48  *** mdunnio has quit IRC
710 2019-07-30T20:26:55  <jonasschnelli> It's just about ramping up more people so we can have actual debates without +48h lags
711 2019-07-30T20:27:11  *** bitcoin-git has joined #bitcoin-core-dev
712 2019-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
713 2019-07-30T20:27:12  *** bitcoin-git has left #bitcoin-core-dev
714 2019-07-30T20:37:48  <phantomcircuit> sipa, well it's most definitely faster without the 34m lookups at least
715 2019-07-30T20:38:12  <phantomcircuit> it also made generating (very bad) data on leveldb Get calls vs dbcache easier
716 2019-07-30T20:41:14  *** mdunnio has joined #bitcoin-core-dev
717 2019-07-30T20:54:38  *** emilengler has joined #bitcoin-core-dev
718 2019-07-30T21:00:01  *** MarconM has quit IRC
719 2019-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?
720 2019-07-30T21:02:22  <fanquake> promag: it’ll be a missing SDK. Assuming your building for MacOS
721 2019-07-30T21:03:57  *** spake has joined #bitcoin-core-dev
722 2019-07-30T21:06:43  *** bitcoin-git has joined #bitcoin-core-dev
723 2019-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
724 2019-07-30T21:06:44  *** bitcoin-git has left #bitcoin-core-dev
725 2019-07-30T21:10:22  *** Guyver2 has quit IRC
726 2019-07-30T21:12:10  *** mdunnio has quit IRC
727 2019-07-30T21:14:08  *** jarthur has quit IRC
728 2019-07-30T21:20:07  *** EagleTM has joined #bitcoin-core-dev
729 2019-07-30T21:23:30  *** bitcoin-git has joined #bitcoin-core-dev
730 2019-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
731 2019-07-30T21:23:34  *** bitcoin-git has left #bitcoin-core-dev
732 2019-07-30T21:27:34  *** mdunnio has joined #bitcoin-core-dev
733 2019-07-30T21:31:27  *** bitcoin-git has joined #bitcoin-core-dev
734 2019-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
735 2019-07-30T21:31:29  *** bitcoin-git has left #bitcoin-core-dev
736 2019-07-30T21:37:48  *** rex4539 has joined #bitcoin-core-dev
737 2019-07-30T21:38:37  *** promag has quit IRC
738 2019-07-30T21:38:49  *** promag has joined #bitcoin-core-dev
739 2019-07-30T21:45:13  *** mdunnio has quit IRC
740 2019-07-30T21:49:07  *** mdunnio has joined #bitcoin-core-dev
741 2019-07-30T21:51:02  *** brianhoffman_ has joined #bitcoin-core-dev
742 2019-07-30T21:53:22  *** brianhoffman has quit IRC
743 2019-07-30T21:53:22  *** brianhoffman_ is now known as brianhoffman
744 2019-07-30T21:53:37  *** bitcoin-git has joined #bitcoin-core-dev
745 2019-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
746 2019-07-30T21:53:40  *** bitcoin-git has left #bitcoin-core-dev
747 2019-07-30T21:54:31  *** bitcoin-git has joined #bitcoin-core-dev
748 2019-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
749 2019-07-30T21:54:35  *** bitcoin-git has left #bitcoin-core-dev
750 2019-07-30T21:54:52  *** ezegom has quit IRC
751 2019-07-30T21:55:31  *** ezegom has joined #bitcoin-core-dev
752 2019-07-30T21:56:08  <promag> fanquake: which sdk?
753 2019-07-30T21:59:41  <fanquake> promag: the macOS SDK. Are you building depends for a macOS HOST?
754 2019-07-30T22:00:08  <promag> I'm on a mac, building for mac
755 2019-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
756 2019-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
757 2019-07-30T22:02:51  *** ercwl has joined #bitcoin-core-dev
758 2019-07-30T22:03:26  *** ezegom has quit IRC
759 2019-07-30T22:04:29  *** ezegom has joined #bitcoin-core-dev
760 2019-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
761 2019-07-30T22:05:25  <fanquake> promag: oh, did you recently update your macOS or Xcode?
762 2019-07-30T22:06:03  <promag> fanquake: nope, I don't recall doing it, at least recently
763 2019-07-30T22:06:09  <promag> why?
764 2019-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.
765 2019-07-30T22:08:55  <fanquake> Otherwise unsure atm.
766 2019-07-30T22:09:13  *** ezegom has quit IRC
767 2019-07-30T22:12:29  <promag> should it work if I have the previous sdk?
768 2019-07-30T22:12:34  <promag> fanquake: ^
769 2019-07-30T22:13:57  *** mdunnio has quit IRC
770 2019-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.
771 2019-07-30T22:15:16  <fanquake> Although, at least it’s easy to download and extract the new SDK on a mac.
772 2019-07-30T22:25:24  *** promag has quit IRC
773 2019-07-30T22:26:08  *** promag has joined #bitcoin-core-dev
774 2019-07-30T22:27:52  *** petezz4 has joined #bitcoin-core-dev
775 2019-07-30T22:35:44  *** Zenton has quit IRC
776 2019-07-30T22:39:57  *** ezegom has joined #bitcoin-core-dev
777 2019-07-30T22:41:00  *** ezegom has joined #bitcoin-core-dev
778 2019-07-30T22:45:28  *** ezegom has quit IRC
779 2019-07-30T22:46:13  *** EagleTM has quit IRC
780 2019-07-30T22:47:03  <phantomcircuit> BlueMatt, what am i missing
781 2019-07-30T23:04:43  *** justanotheruser has quit IRC
782 2019-07-30T23:08:55  *** bitcoin-git has joined #bitcoin-core-dev
783 2019-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
784 2019-07-30T23:09:02  *** bitcoin-git has left #bitcoin-core-dev
785 2019-07-30T23:12:43  *** ezegom has joined #bitcoin-core-dev
786 2019-07-30T23:14:41  *** captjakk has quit IRC
787 2019-07-30T23:15:09  *** captjakk has joined #bitcoin-core-dev
788 2019-07-30T23:19:31  *** captjakk has quit IRC
789 2019-07-30T23:24:54  *** promag has quit IRC
790 2019-07-30T23:25:06  *** promag has joined #bitcoin-core-dev
791 2019-07-30T23:28:36  *** ercwl has quit IRC
792 2019-07-30T23:28:39  *** kristapsk___ is now known as kristapsk
793 2019-07-30T23:29:25  *** ercwl has joined #bitcoin-core-dev
794 2019-07-30T23:29:38  *** ezegom has quit IRC
795 2019-07-30T23:29:54  *** ezegom has joined #bitcoin-core-dev
796 2019-07-30T23:30:53  *** ezegom has joined #bitcoin-core-dev
797 2019-07-30T23:37:50  *** Aaronvan_ has quit IRC
798 2019-07-30T23:51:36  *** captjakk has joined #bitcoin-core-dev
799 2019-07-30T23:51:36  *** astro has quit IRC
800 2019-07-30T23:52:36  *** ezegom has quit IRC
801 2019-07-30T23:53:06  *** guest69 has joined #bitcoin-core-dev
802 2019-07-30T23:55:53  *** captjakk has quit IRC
803 2019-07-30T23:55:59  *** captjakk has joined #bitcoin-core-dev
804 2019-07-30T23:56:51  *** astro has joined #bitcoin-core-dev
805 2019-07-30T23:57:37  *** ezegom has joined #bitcoin-core-dev