1 2017-09-20T00:02:18  *** jannes has quit IRC
  2 2017-09-20T00:03:15  *** StopAndDecrypty has joined #bitcoin-core-dev
  3 2017-09-20T00:03:32  *** StopAndDecrypt has quit IRC
  4 2017-09-20T00:03:47  *** StopAndDecrypty is now known as StopAndDecrypt
  5 2017-09-20T00:33:09  *** Murch has quit IRC
  6 2017-09-20T00:36:41  *** promag has quit IRC
  7 2017-09-20T00:46:26  *** promag has joined #bitcoin-core-dev
  8 2017-09-20T00:48:51  *** Ylbam has quit IRC
  9 2017-09-20T00:50:28  *** promag has quit IRC
 10 2017-09-20T01:06:02  *** dabura667 has joined #bitcoin-core-dev
 11 2017-09-20T01:14:23  <btcdrak> gmaxwell:  We can try again with the security@ email address. I have limited internet access today so cant do it.
 12 2017-09-20T01:15:04  *** chjj has joined #bitcoin-core-dev
 13 2017-09-20T01:16:26  <bitcoin-git> [bitcoin] sipa opened pull request #11372: Address encoding cleanup (master...201709_addr_cleanup) https://github.com/bitcoin/bitcoin/pull/11372
 14 2017-09-20T01:51:33  *** RubenSomsen has joined #bitcoin-core-dev
 15 2017-09-20T01:53:24  *** chjj has quit IRC
 16 2017-09-20T01:56:38  *** chjj has joined #bitcoin-core-dev
 17 2017-09-20T02:01:54  *** chjj has quit IRC
 18 2017-09-20T02:02:27  *** chjj has joined #bitcoin-core-dev
 19 2017-09-20T02:10:32  *** justanotheruser has joined #bitcoin-core-dev
 20 2017-09-20T02:13:50  *** chjj has quit IRC
 21 2017-09-20T02:16:11  *** nioc has left #bitcoin-core-dev
 22 2017-09-20T02:18:53  *** nickler has quit IRC
 23 2017-09-20T02:19:30  *** nickler has joined #bitcoin-core-dev
 24 2017-09-20T02:28:23  *** Murch has joined #bitcoin-core-dev
 25 2017-09-20T02:39:17  *** dabura667_ has joined #bitcoin-core-dev
 26 2017-09-20T02:42:58  *** dabura667 has quit IRC
 27 2017-09-20T02:43:52  *** dabura667_ has quit IRC
 28 2017-09-20T02:57:35  *** StopAndDecrypt has quit IRC
 29 2017-09-20T02:57:59  *** StopAndDecrypt has joined #bitcoin-core-dev
 30 2017-09-20T03:09:53  *** PRab has joined #bitcoin-core-dev
 31 2017-09-20T03:19:36  *** StopAndDecrypty has joined #bitcoin-core-dev
 32 2017-09-20T03:20:03  *** StopAndDecrypt has quit IRC
 33 2017-09-20T03:23:10  *** Giszmo has quit IRC
 34 2017-09-20T03:23:41  *** wxxs has quit IRC
 35 2017-09-20T03:46:31  *** promag has joined #bitcoin-core-dev
 36 2017-09-20T03:47:32  *** Giszmo has joined #bitcoin-core-dev
 37 2017-09-20T03:50:56  *** promag has quit IRC
 38 2017-09-20T04:34:05  *** jtimon has quit IRC
 39 2017-09-20T04:47:19  *** jtimon has joined #bitcoin-core-dev
 40 2017-09-20T04:48:16  *** dabura667 has joined #bitcoin-core-dev
 41 2017-09-20T04:54:58  *** RubenSomsen has quit IRC
 42 2017-09-20T04:59:18  *** harrymm1 has quit IRC
 43 2017-09-20T04:59:49  *** harrymm1 has joined #bitcoin-core-dev
 44 2017-09-20T05:00:05  *** harrymm has quit IRC
 45 2017-09-20T05:00:33  *** harrymm has joined #bitcoin-core-dev
 46 2017-09-20T05:45:16  *** pbase has joined #bitcoin-core-dev
 47 2017-09-20T05:58:08  *** jtimon has quit IRC
 48 2017-09-20T06:28:11  <kallewoof> achow101: the approach given in the doc I linked is outdated, then? I could write/update docs, but I'm honestly stumped on how to approach this. E.g. I am supposed to give a signer, but I don't want to shuffle private GPG keys around to let the VM sign using a key it doesn't hold (I am guessing wildly here).
 49 2017-09-20T06:32:46  <esotericnonsense> kallewoof: there's a section in gitian-building.md that references copying out the assert files?
 50 2017-09-20T06:35:40  <esotericnonsense> (missed most of the conversation, just guessing here)
 51 2017-09-20T06:46:43  *** BashCo has quit IRC
 52 2017-09-20T07:05:13  *** tknp has quit IRC
 53 2017-09-20T07:07:11  <kallewoof> esotericnonsense: I don't think I saw that. Will look, thanks!
 54 2017-09-20T07:07:34  <esotericnonsense> :) right at the bottom
 55 2017-09-20T07:08:13  <kallewoof> Ahh, yeah, I missed that completely. Thanks
 56 2017-09-20T07:15:34  *** BashCo has joined #bitcoin-core-dev
 57 2017-09-20T07:18:50  <bitcoin-git> [bitcoin] Reagent1981 opened pull request #11374: 0.15 (master...0.15) https://github.com/bitcoin/bitcoin/pull/11374
 58 2017-09-20T07:19:23  <bitcoin-git> [bitcoin] fanquake closed pull request #11374: 0.15 (master...0.15) https://github.com/bitcoin/bitcoin/pull/11374
 59 2017-09-20T07:24:01  *** promag has joined #bitcoin-core-dev
 60 2017-09-20T07:25:49  *** timothy has joined #bitcoin-core-dev
 61 2017-09-20T07:27:55  *** promag has quit IRC
 62 2017-09-20T07:27:59  *** Ylbam has joined #bitcoin-core-dev
 63 2017-09-20T07:46:11  *** promag has joined #bitcoin-core-dev
 64 2017-09-20T07:50:55  *** promag has quit IRC
 65 2017-09-20T07:52:31  *** RubenSomsen has joined #bitcoin-core-dev
 66 2017-09-20T08:01:17  *** laurentmt has joined #bitcoin-core-dev
 67 2017-09-20T08:03:58  *** JackH has joined #bitcoin-core-dev
 68 2017-09-20T08:07:35  *** meshcollider has quit IRC
 69 2017-09-20T08:08:35  *** tErik_mc has quit IRC
 70 2017-09-20T08:21:27  *** PaulCapestany has quit IRC
 71 2017-09-20T08:33:25  *** PaulCapestany has joined #bitcoin-core-dev
 72 2017-09-20T08:35:03  *** Geoffy has joined #bitcoin-core-dev
 73 2017-09-20T08:43:12  *** Aaronva__ has quit IRC
 74 2017-09-20T08:44:05  *** promag has joined #bitcoin-core-dev
 75 2017-09-20T08:49:45  <kallewoof> Reading the OP_RETURNTRUE discussion on bitcoin-dev it struck me that if we bump segwit script version at some point, old nodes will all accept the tx without looking, and new nodes will use the new script to verify. A miner running old version could mine txs with invalid scripts and old nodes would accept this block while new nodes would not. This would become a hardfork, no?
 76 2017-09-20T08:51:07  <kallewoof> Wait, no, it would become a softfork. *headscratch*
 77 2017-09-20T08:51:46  <kallewoof> I'm confused about Johnson Lau's statement "If we use a softfork to transform OP_RETURNTRUE into OP_17 (pushing the number 17 to the stack), new nodes will collect the (pubkey, message) pair and try to aggregate with other pairs. This becomes a hardfork.
 78 2017-09-20T08:51:51  <kallewoof> "
 79 2017-09-20T08:53:19  <kallewoof> Old nodes all accept, new nodes do more. It should be a softfork, no?
 80 2017-09-20T08:56:01  *** meshcollider has joined #bitcoin-core-dev
 81 2017-09-20T08:56:06  *** PaulCapestany has quit IRC
 82 2017-09-20T08:59:06  *** vicenteH has joined #bitcoin-core-dev
 83 2017-09-20T08:59:10  *** AaronvanW has joined #bitcoin-core-dev
 84 2017-09-20T09:01:25  *** Guyver2 has joined #bitcoin-core-dev
 85 2017-09-20T09:16:06  *** drizztbsd has joined #bitcoin-core-dev
 86 2017-09-20T09:16:12  *** timothy has quit IRC
 87 2017-09-20T09:17:31  *** drizztbsd is now known as timothy
 88 2017-09-20T09:17:48  *** PaulCapestany has joined #bitcoin-core-dev
 89 2017-09-20T09:34:28  *** PaulCapestany has quit IRC
 90 2017-09-20T09:43:31  *** PaulCapestany has joined #bitcoin-core-dev
 91 2017-09-20T09:57:18  *** wxxs has joined #bitcoin-core-dev
 92 2017-09-20T10:00:46  *** Victor_sueca has joined #bitcoin-core-dev
 93 2017-09-20T10:03:12  *** Victorsueca has quit IRC
 94 2017-09-20T10:08:19  <luke-jr> kallewoof: he's talking about after some hypothetical signature aggregation scheme
 95 2017-09-20T10:08:23  <luke-jr> I'm not convinced it's a real blocker
 96 2017-09-20T10:09:14  <luke-jr> just an additional consideration that needs to be made when such aggregation is introduced
 97 2017-09-20T10:10:21  *** promag has quit IRC
 98 2017-09-20T10:10:25  *** Victor_sueca is now known as Victorsueca
 99 2017-09-20T10:28:04  *** belcher has quit IRC
100 2017-09-20T10:35:53  *** SopaXorzTaker has joined #bitcoin-core-dev
101 2017-09-20T11:18:33  *** alreadylate has joined #bitcoin-core-dev
102 2017-09-20T11:19:49  *** phoenix has joined #bitcoin-core-dev
103 2017-09-20T11:20:13  *** phoenix is now known as Guest81071
104 2017-09-20T11:21:53  <Guest81071> can i get any  useful ideas to implement to develop bitcoin
105 2017-09-20T11:24:16  <Guest81071> how can i develop or contribute to bitcoin
106 2017-09-20T11:36:05  <StopAndDecrypt_> Guest81071
107 2017-09-20T11:36:14  <StopAndDecrypt_> http://www.righto.com/2014/02/bitcoins-hard-way-using-raw-bitcoin.html
108 2017-09-20T11:36:22  <StopAndDecrypt_> http://codesuppository.blogspot.com/2014/01/how-to-parse-bitcoin-blockchain.html
109 2017-09-20T11:38:50  <StopAndDecrypt_> http://www.samlewis.me/2017/06/a-peek-under-bitcoins-hood/
110 2017-09-20T11:58:19  <vicenteH> I use addwitnessaddress command to generate a segwit address. To save/restore in cold storage that segwit address should I dump private key from original address, then import that private key, get the original address and execute addwitnessaddress again?
111 2017-09-20T11:59:21  *** jtimon has joined #bitcoin-core-dev
112 2017-09-20T12:01:24  <Guest81071> what is the scope of devoloping the applications using bit coins
113 2017-09-20T12:01:54  <Guest81071> what applications can be developed
114 2017-09-20T12:07:35  *** meshcollider has quit IRC
115 2017-09-20T12:09:54  *** dabura667 has quit IRC
116 2017-09-20T12:25:30  *** ula has quit IRC
117 2017-09-20T12:32:00  *** ula has joined #bitcoin-core-dev
118 2017-09-20T12:56:29  *** meshcollider has joined #bitcoin-core-dev
119 2017-09-20T13:00:17  <meshcollider> Guest81071: try asking in #bitcoin - this chat is only for discussion on bitcoin core development not general development
120 2017-09-20T13:03:00  <meshcollider> vicenteH: yeah I believe so, at least until proper segwit support in wallets is added in 0.15.1
121 2017-09-20T13:07:52  *** Guest81071 has quit IRC
122 2017-09-20T13:08:58  <vicenteH> meshcollider: thank you
123 2017-09-20T13:21:30  *** SopaXorzTaker is now known as RoshHaShanaXT
124 2017-09-20T13:40:29  *** justanotheruser has quit IRC
125 2017-09-20T13:45:46  *** promag has joined #bitcoin-core-dev
126 2017-09-20T14:04:28  *** RubenSomsen has quit IRC
127 2017-09-20T14:06:42  <promag> jnewbery: thanks for #11370, udpated
128 2017-09-20T14:06:44  <gribble> https://github.com/bitcoin/bitcoin/issues/11370 | [test] Add getblockchaininfo functional test by promag · Pull Request #11370 · bitcoin/bitcoin · GitHub
129 2017-09-20T14:07:14  *** promag has quit IRC
130 2017-09-20T14:29:03  *** Chris_Stewart_5 has joined #bitcoin-core-dev
131 2017-09-20T14:30:49  *** promag has joined #bitcoin-core-dev
132 2017-09-20T14:34:37  *** Ylbam has quit IRC
133 2017-09-20T14:42:03  <promag> jnewbery: is 10740 ready for review?
134 2017-09-20T14:42:11  <promag> #10740
135 2017-09-20T14:42:14  <gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
136 2017-09-20T14:42:59  <esotericnonsense> #11366 updated
137 2017-09-20T14:43:00  <gribble> https://github.com/bitcoin/bitcoin/issues/11366 | [rpc] Fix pruneheight help description in getblockchaininfo by esotericnonsense · Pull Request #11366 · bitcoin/bitcoin · GitHub
138 2017-09-20T14:46:40  *** promag has quit IRC
139 2017-09-20T14:47:14  *** promag has joined #bitcoin-core-dev
140 2017-09-20T14:50:20  <jnewbery> promag : just waiting for Travis to complete. There was a bad automatic rebase before. If Travis passes, then I'd definitely appreciate some review at this stage
141 2017-09-20T14:51:05  *** Ylbam has joined #bitcoin-core-dev
142 2017-09-20T14:51:21  *** promag has quit IRC
143 2017-09-20T14:56:13  *** Murch has joined #bitcoin-core-dev
144 2017-09-20T15:01:39  *** pbase has quit IRC
145 2017-09-20T15:05:35  *** JackH has quit IRC
146 2017-09-20T15:06:00  <bitcoin-git> [bitcoin] esotericnonsense closed pull request #11366: [rpc] Fix pruneheight help description in getblockchaininfo (master...2017-09-getblockchaininfo-docs) https://github.com/bitcoin/bitcoin/pull/11366
147 2017-09-20T15:06:15  *** meshcollider has quit IRC
148 2017-09-20T15:06:19  <esotericnonsense> (put the changes in #11367 as it's pretty small).
149 2017-09-20T15:06:21  <gribble> https://github.com/bitcoin/bitcoin/issues/11367 | [rpc] getblockchaininfo: add size_on_disk, prune_target_size by esotericnonsense · Pull Request #11367 · bitcoin/bitcoin · GitHub
150 2017-09-20T15:09:39  <esotericnonsense> sorry about the repeated pushes, should be done now, missed your style adjustment on while {} promag.
151 2017-09-20T15:11:47  *** promag has joined #bitcoin-core-dev
152 2017-09-20T15:18:13  *** Chris_Stewart_5 has quit IRC
153 2017-09-20T15:18:30  *** promag has quit IRC
154 2017-09-20T15:19:04  *** JackH has joined #bitcoin-core-dev
155 2017-09-20T15:23:48  *** Sentineo has joined #bitcoin-core-dev
156 2017-09-20T15:40:34  <BlueMatt> https://github.com/bitcoin/bitcoin/issues/11373 should just be closed with "Your filesystem permissions have been set to prevent bitcoind from accessing its datadir, which prevents it from starting" (unless someone wants to change it to a "we need a better error message for this bug" issue)
157 2017-09-20T15:42:20  *** Chris_Stewart_5 has joined #bitcoin-core-dev
158 2017-09-20T15:50:19  *** Aaronvan_ has joined #bitcoin-core-dev
159 2017-09-20T15:52:33  *** AaronvanW has quit IRC
160 2017-09-20T15:55:54  *** chartractegg has joined #bitcoin-core-dev
161 2017-09-20T15:56:08  *** promag has joined #bitcoin-core-dev
162 2017-09-20T15:57:25  *** chartractegg has quit IRC
163 2017-09-20T16:00:40  <promag> jnewbery: do you think there should be a PR to replace start+stop with restart_node? or you see an incremental change instead?
164 2017-09-20T16:01:37  *** Chris_Stewart_5 has quit IRC
165 2017-09-20T16:06:22  *** chartractegg has joined #bitcoin-core-dev
166 2017-09-20T16:06:35  *** BashCo has quit IRC
167 2017-09-20T16:11:46  *** promag has quit IRC
168 2017-09-20T16:23:45  *** chartractegg has left #bitcoin-core-dev
169 2017-09-20T16:30:35  *** PaulCapestany has quit IRC
170 2017-09-20T16:32:17  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/4f7e37e26c5d...44313d82508b
171 2017-09-20T16:32:17  <bitcoin-git> bitcoin/master e53fa4a Andrew Chow: Remove custom fee radio group...
172 2017-09-20T16:32:18  <bitcoin-git> bitcoin/master 44313d8 Wladimir J. van der Laan: Merge #11334: qt: Remove custom fee radio group and remove nCustomFeeRadio setting...
173 2017-09-20T16:32:57  <bitcoin-git> [bitcoin] laanwj closed pull request #11334: qt: Remove custom fee radio group and remove nCustomFeeRadio setting (master...rm-nCustomFeeRadio) https://github.com/bitcoin/bitcoin/pull/11334
174 2017-09-20T16:33:34  *** alreadylate has quit IRC
175 2017-09-20T16:34:25  *** alreadylate has joined #bitcoin-core-dev
176 2017-09-20T16:39:00  *** PaulCapestany has joined #bitcoin-core-dev
177 2017-09-20T16:40:37  *** alreadylate has quit IRC
178 2017-09-20T16:47:28  <wumpus> BlueMatt: boost::filesystem::create_directory: Permission denied: "/home/user/.bitcoin"     seems clear enough to me
179 2017-09-20T16:48:58  <jnewbery> promag: I think it's fine for that to be included in your getblockchaininfo PR
180 2017-09-20T16:50:00  *** RubenSomsen has joined #bitcoin-core-dev
181 2017-09-20T16:51:30  *** BashCo has joined #bitcoin-core-dev
182 2017-09-20T16:52:16  <jnewbery> Also, #10740 passes travis after manual rebase fixed the test issue. Ready for initial review
183 2017-09-20T16:52:17  <gribble> https://github.com/bitcoin/bitcoin/issues/10740 | [wallet] dynamic loading/unloading of wallets by jnewbery · Pull Request #10740 · bitcoin/bitcoin · GitHub
184 2017-09-20T16:53:22  <bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/44313d82508b...28474802758a
185 2017-09-20T16:53:23  <bitcoin-git> bitcoin/master fa2c3b6 MarcoFalke: doc: Bump manpages to 0.15.99
186 2017-09-20T16:53:24  <bitcoin-git> bitcoin/master fa65dcd MarcoFalke: doc: Update release notes for 0.16.0
187 2017-09-20T16:53:24  <bitcoin-git> bitcoin/master 2847480 Wladimir J. van der Laan: Merge #11305: [doc] Update release notes and manpages for 0.16...
188 2017-09-20T16:53:56  <bitcoin-git> [bitcoin] laanwj closed pull request #11305: [doc] Update release notes and manpages for 0.16 (master...Mf1709-doc016) https://github.com/bitcoin/bitcoin/pull/11305
189 2017-09-20T16:57:21  *** Chris_Stewart_5 has joined #bitcoin-core-dev
190 2017-09-20T16:58:57  *** geezas has joined #bitcoin-core-dev
191 2017-09-20T17:08:10  <bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/28474802758a...551d7bf604fb
192 2017-09-20T17:08:10  <bitcoin-git> bitcoin/master fdc3293 practicalswift: Document assumptions that are being made to avoid NULL pointer dereferences
193 2017-09-20T17:08:11  <bitcoin-git> bitcoin/master 551d7bf Wladimir J. van der Laan: Merge #11132: Document assumptions that are being made to avoid NULL pointer dereferences...
194 2017-09-20T17:08:40  <bitcoin-git> [bitcoin] laanwj closed pull request #11132: Document assumptions that are being made to avoid NULL pointer dereferences (master...document-non-nullptr-assumptions) https://github.com/bitcoin/bitcoin/pull/11132
195 2017-09-20T17:10:08  *** wxxs has quit IRC
196 2017-09-20T17:10:45  *** laurentmt has quit IRC
197 2017-09-20T17:12:19  *** promag has joined #bitcoin-core-dev
198 2017-09-20T17:17:07  *** promag has quit IRC
199 2017-09-20T17:18:15  *** atroxes has joined #bitcoin-core-dev
200 2017-09-20T17:18:27  *** abpa has joined #bitcoin-core-dev
201 2017-09-20T17:22:05  *** PaulCapestany has quit IRC
202 2017-09-20T17:23:12  *** wxxs has joined #bitcoin-core-dev
203 2017-09-20T17:24:34  *** chjj has joined #bitcoin-core-dev
204 2017-09-20T17:35:22  *** ThomasV has joined #bitcoin-core-dev
205 2017-09-20T17:41:33  *** PaulCapestany has joined #bitcoin-core-dev
206 2017-09-20T17:42:34  <ThomasV> is it true that core will let users reuse the same private key in p2pkh, p2wpkh and p2wpkh-in-p2sh ?
207 2017-09-20T17:42:43  <ThomasV> sipa: ^
208 2017-09-20T17:42:46  <chainhead> if they use addwitnessaddress
209 2017-09-20T17:47:50  <jl2012> if it is compressed key, and with addwitnessaddress
210 2017-09-20T17:49:20  *** vicenteH has quit IRC
211 2017-09-20T17:50:45  <sipa> ThomasV: for now, yes, we have no choice
212 2017-09-20T17:50:57  <ThomasV> no choice??
213 2017-09-20T17:51:07  <sipa> that's how addwitnessafdress already works
214 2017-09-20T17:51:26  <ThomasV> sipa: if you release that, you will have to keep supporting that forever
215 2017-09-20T17:51:43  <sipa> ThomasV: addwitnessaddress has existed since 0.13.0
216 2017-09-20T17:51:47  <ThomasV> because users will expect to see their coins when they import an address
217 2017-09-20T17:52:30  <ThomasV> do you plan to do something about that?
218 2017-09-20T17:52:31  *** AaronvanW has joined #bitcoin-core-dev
219 2017-09-20T17:52:42  <sipa> in a future version we plan to redesign the logoc for determining which addresses are ours, and have split chain for each type of address
220 2017-09-20T17:53:13  <sipa> and perhaps deprecate importprivkey in favor of importmulti (which requires passing all relevant information)
221 2017-09-20T17:53:46  *** aashu has joined #bitcoin-core-dev
222 2017-09-20T17:53:49  <aashu> join
223 2017-09-20T17:54:25  <sipa> i agree it's a bad situation that we accept payments to addresses we didn't create, but it's a too invasive change to make in a minor release
224 2017-09-20T17:54:34  *** aashu has quit IRC
225 2017-09-20T17:54:34  *** duringo has joined #bitcoin-core-dev
226 2017-09-20T17:54:41  *** Aaronvan_ has quit IRC
227 2017-09-20T17:55:07  <sipa> it's an issue that has existed for a long time too (for example, core also accepts payments to pay to pubkeys for corresponding keys of addresses that were created)
228 2017-09-20T17:56:53  <ThomasV> well, p2pk is a bit different, because you do not create a bitcoin address for it
229 2017-09-20T17:57:23  <ghost43> so then if a user somehow exports a private key from Core, and tries to import that in another software, what should that other software do with it? try to convert that to all types of outputs?
230 2017-09-20T17:57:48  <ThomasV> ghost43: that's what I want to avoid
231 2017-09-20T17:58:07  <ThomasV> that would encourage key reuse
232 2017-09-20T17:58:33  <sipa> internally, the ismine logic basically decides what is our based on the ability to sign... which is a mistake, but rewriting that code replacing it with something sane will take time
233 2017-09-20T17:58:43  <sipa> ThomasV: i understand
234 2017-09-20T18:01:09  <sipa> ghost43: i don't think you should associate any type of output with a key... a key is just a key and not an address
235 2017-09-20T18:01:16  <sipa> but that's not how things work now
236 2017-09-20T18:02:09  <ThomasV> sipa: a key is just a key, but the serialization of a key is not just a key
237 2017-09-20T18:02:41  <ThomasV> it has a byte that disambiguates compressed/uncompressed
238 2017-09-20T18:02:50  <ThomasV> and that's a good thing
239 2017-09-20T18:02:59  <ThomasV> we really need to extend that
240 2017-09-20T18:03:03  <sipa> i disagree
241 2017-09-20T18:03:10  *** laurentmt has joined #bitcoin-core-dev
242 2017-09-20T18:03:16  <goatpig> maybe it's time to agree on a set of identifiers for common script types
243 2017-09-20T18:03:24  *** laurentmt has quit IRC
244 2017-09-20T18:03:31  <sipa> if you want to import an address, give the address; if you want to spend from it, give its associated key
245 2017-09-20T18:03:36  *** tknp has joined #bitcoin-core-dev
246 2017-09-20T18:03:56  <sipa> i think it's unmaintainable to keep implying the address from just the key
247 2017-09-20T18:04:40  <goatpig> not as a requirement, but just allow those wallets who want to to forward that information in a standardized fashion?
248 2017-09-20T18:04:51  <sipa> give the address + privkey?
249 2017-09-20T18:05:07  <sipa> importing addresses doesn't sound like something a normal user would do frequently
250 2017-09-20T18:05:18  <goatpig> no they usually import the privkey
251 2017-09-20T18:05:26  <ghost43> give the full scriptPubKey + the private key, haha
252 2017-09-20T18:05:42  <goatpig> expect the software they using it with to know which scripts to look for on chain
253 2017-09-20T18:05:59  <goatpig> cant tell if this is just pebkac and should be ignored, or if there is a need to cover this case
254 2017-09-20T18:06:02  <goatpig> but it exists alright
255 2017-09-20T18:06:19  <sipa> i expect the same issue does exist at least for importing hd chains, though
256 2017-09-20T18:06:26  <goatpig> now it does
257 2017-09-20T18:06:32  <goatpig> before, not necessarely
258 2017-09-20T18:06:32  <ThomasV> sipa: that's interesting. why dont you post that in the ML?
259 2017-09-20T18:06:39  <goatpig> if you stick to BIP44, p2pkh is basically implied
260 2017-09-20T18:06:47  <sipa> ghost43: right
261 2017-09-20T18:06:57  <sipa> ThomasV: i hate the ml
262 2017-09-20T18:06:58  <ThomasV> goatpig: please no bip44
263 2017-09-20T18:07:13  <goatpig> ThomasV: is that a voldermort moment?
264 2017-09-20T18:07:26  <ThomasV> sipa: if you hate it, why did you answer to my post?
265 2017-09-20T18:07:36  <sipa> i felt i had to
266 2017-09-20T18:08:02  <ThomasV> yeah, but you kept the real annsyer until now
267 2017-09-20T18:08:07  <sipa> hmm?
268 2017-09-20T18:08:20  <sipa> you're asking my opinion
269 2017-09-20T18:08:20  <ThomasV> I asked what core plans to do regarding key imports
270 2017-09-20T18:08:29  <ThomasV> oh come on..
271 2017-09-20T18:08:38  <sipa> ah, right
272 2017-09-20T18:08:44  <ThomasV> your opinion counts
273 2017-09-20T18:09:51  <sipa> let me find the mail
274 2017-09-20T18:10:07  <ghost43> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015007.html
275 2017-09-20T18:11:01  <ThomasV> goatpig: I guess you know what I think of bip44
276 2017-09-20T18:11:16  <goatpig> oh i do
277 2017-09-20T18:11:25  <goatpig> i agree with your position on the WIF thing
278 2017-09-20T18:11:28  <goatpig> extending it would help
279 2017-09-20T18:12:12  <goatpig> otherwise, id fall back on Lombrozo's BIP124 and flesh that out?
280 2017-09-20T18:12:37  <ThomasV> goatpig: bip124 is not really specified
281 2017-09-20T18:13:12  <goatpig> therefor it wont be as resistant to proposals
282 2017-09-20T18:14:32  <ThomasV> goatpig: I am interested in it too
283 2017-09-20T18:15:06  <goatpig> i mean the WIF is for single keys
284 2017-09-20T18:15:16  <goatpig> but at least if we can agree on some stuff for entire chains
285 2017-09-20T18:15:46  <ThomasV> well, if we had a decent bip124 we could use it for single keys too
286 2017-09-20T18:18:29  *** promag has joined #bitcoin-core-dev
287 2017-09-20T18:20:52  <sipa> ThomasV: thanks for bringing it up. thinking more about it, i think my main issue is that we should start thinking about addresses and keys as orthogonal things (there are some things you consider yours - addresses, and then some things you know how to sign for - keys)... especially with things like hardware wallets, multisig
288 2017-09-20T18:21:07  <sipa> however, that doesn't mean there can't be a format that encapsulates both
289 2017-09-20T18:21:52  <sipa> i'll respond on the list
290 2017-09-20T18:21:56  <ThomasV> well, what is the point of having a serialization format, if it is not to encapsulate ?
291 2017-09-20T18:22:35  *** PaulCapestany has quit IRC
292 2017-09-20T18:22:45  <sipa> ThomasV: well there can be separate formats, i guess
293 2017-09-20T18:23:52  <ThomasV> sipa: electrum has orthogonal classes for wallets and keystores. a wallet is defined by the type of output script, regardless of how keys are stored
294 2017-09-20T18:24:02  <sipa> right, sounds great
295 2017-09-20T18:24:45  <ThomasV> so we can use hardware or software keystores in multisig wallets, with the same wallet class
296 2017-09-20T18:25:38  <ThomasV> but I believe that what we export and show to users should be encapsulated
297 2017-09-20T18:26:32  <sipa> right, but you also need a way to export/import a chain or address without revealing the key
298 2017-09-20T18:26:49  <sipa> for an address that's easy, as it's just an address
299 2017-09-20T18:27:13  <sipa> though i saw there was talk of including a birthtime too
300 2017-09-20T18:27:13  <ThomasV> a wallet cannot import an address unless it is a special wallet type
301 2017-09-20T18:27:31  <sipa> sure
302 2017-09-20T18:27:57  <sipa> but i'm sure some software will exist that can import arbitrary individual addresses
303 2017-09-20T18:29:03  <goatpig> and that's fine
304 2017-09-20T18:29:12  <ThomasV> electrum can do it. my point is that wallet class does not have a keystore
305 2017-09-20T18:29:44  <ThomasV> there is a wallet class that just means "a set of imported addresses"
306 2017-09-20T18:29:47  <goatpig> the issue would be importing a private key and failing to find all funds that key can sign for
307 2017-09-20T18:30:09  <sipa> goatpig: i think it's a terrible idea to treat every output you can sign for as your own
308 2017-09-20T18:30:28  <ThomasV> there also is a keystore class for imported private keys, but it has nothing to do with imported addresses, and it assumes p2pkh
309 2017-09-20T18:31:10  <andytoshi> goatpig: taken literally that leads to trivial attacks (e.g. you can sign for a 1-of-2 multisig with me, but that output isn't yours and if you have one you can't consider it as a final payment)
310 2017-09-20T18:31:46  <sipa> ThomasV: my point is that we should really think about importing something as either an address/chain (something to look for) or as private key (something to sign with) - there can be a convenience method to encode both simultaneously
311 2017-09-20T18:32:04  <sipa> and i'm not opposed to such a convenience, but i don't have many opinions on it
312 2017-09-20T18:32:51  <goatpig> sipa: andytoshi: the idea is not for me to support all of these possible script variations, it's to able to tell my user: "my software does not support all of tehse variations, do not use to import from this key"
313 2017-09-20T18:32:52  <ThomasV> sipa: current wallets allow to import private keys, and they assume p2pkh
314 2017-09-20T18:33:06  <ThomasV> it is difficult to undo that
315 2017-09-20T18:33:14  <sipa> ThomasV: we don't need to continue that practice
316 2017-09-20T18:33:22  *** duringo_ has joined #bitcoin-core-dev
317 2017-09-20T18:33:34  <sipa> have a new private key format that does not have any implied address
318 2017-09-20T18:34:22  <ThomasV> sipa: stop supporting privkey imports in core, and see how users will react :D
319 2017-09-20T18:34:48  <sipa> ThomasV: i'm not saying we should stop supporting imports
320 2017-09-20T18:34:56  <ThomasV> sipa: ok, I read you
321 2017-09-20T18:35:06  <sipa> but the modern way of doing it is using importmulti, where you just give both the address and the private key
322 2017-09-20T18:35:15  <sipa> (and the import checks that that private indeed can sign for that address)
323 2017-09-20T18:35:54  <sipa> and if it's P2SH it also requires giving the relevant redeemscript
324 2017-09-20T18:35:57  <goatpig> sipa: that could turn into a GUI nightmare, just saying
325 2017-09-20T18:36:33  <sipa> goatpig: perhaps
326 2017-09-20T18:36:46  <goatpig> well between expecting that much info from the user
327 2017-09-20T18:36:49  *** duringo has quit IRC
328 2017-09-20T18:37:02  <goatpig> or agreeing to a header byte that refer to a table telling you how to derive the script hash
329 2017-09-20T18:37:04  *** PaulCapestany has joined #bitcoin-core-dev
330 2017-09-20T18:37:08  <goatpig> obviously i'd pick the easy way out
331 2017-09-20T18:37:43  <sipa> as said, i'm not opposed to a convenience method to encode all of it
332 2017-09-20T18:37:52  *** Chris_Stewart_5 has quit IRC
333 2017-09-20T18:38:08  <ThomasV> sipa: what do you think of bip124?
334 2017-09-20T18:38:09  <goatpig> i believe that's what we're hinting towards
335 2017-09-20T18:38:14  <sipa> ThomasV: i haven't looked at it
336 2017-09-20T18:38:23  <goatpig> it's a bit lean atm
337 2017-09-20T18:39:12  <ThomasV> goatpig: all it needs is a way to extend script with variables
338 2017-09-20T18:39:14  <sipa> so for example an issue i see is CLTV/CSV
339 2017-09-20T18:39:36  <sipa> i expect people at some point will want a standard way of using these in scripts]
340 2017-09-20T18:40:06  <sipa> an "address import" for one of those will need to include the locktime/sequence requirement number, or you can't derive the scriptPubKey
341 2017-09-20T18:40:14  <ThomasV> right
342 2017-09-20T18:40:34  <sipa> an approach that just requires you to pass the full scriptPubKey you're looking for is an elegant, but not perfectly convenient, method
343 2017-09-20T18:41:05  <sipa> but as a 'raw' export/import function, i think that's totally acceptable
344 2017-09-20T18:42:04  <goatpig> for cltv you could imply the position on the address chain is the cltv member
345 2017-09-20T18:42:11  <goatpig> for csv idk if you can sneak around like that
346 2017-09-20T18:43:42  <sipa> yuck.
347 2017-09-20T18:43:47  <goatpig> aww
348 2017-09-20T18:44:00  <sipa> cltv can have a locktime in seconds
349 2017-09-20T18:44:17  <goatpig> i was thinking on the block count after confirmation variant only
350 2017-09-20T18:44:51  <ThomasV> sipa: you mean the full script, not its hash?
351 2017-09-20T18:45:41  <goatpig> sipa: you have to think of backups as well as imports in the case of cltv/csv
352 2017-09-20T18:45:54  <sipa> ThomasV: yes, that's what importmulti requires
353 2017-09-20T18:45:55  <goatpig> the least user inputed data, the better
354 2017-09-20T18:46:19  <sipa> goatpig: well at least everything expect the private keys is much less sensitive
355 2017-09-20T18:46:44  <sipa> but yes, you're right, that's an issue
356 2017-09-20T18:46:54  <adiabat> it may also make sense to standardize on an importable utxo format, with optional privatekey field
357 2017-09-20T18:47:12  <adiabat> I use this in my lightning software between wallet / lightning layer
358 2017-09-20T18:47:42  *** RoshHaShanaXT has quit IRC
359 2017-09-20T18:47:51  <adiabat> could enable imports without rescanning or anything
360 2017-09-20T18:48:00  <ThomasV> sipa: ok, so Iguess the issue is to find a good serialization for what importmulti needs
361 2017-09-20T18:48:21  <sipa> ThomasV: for a subset, at least...
362 2017-09-20T18:49:10  <sipa> unfortunately the checksum properties in bech32 degrade when there are more than 89 characters
363 2017-09-20T18:49:41  <sipa> ThomasV: did you see my comment on your only-v0-witness commit?
364 2017-09-20T18:49:48  <goatpig> use several lines, have a counter in each line
365 2017-09-20T18:49:51  <ThomasV> sipa: yes I saw it
366 2017-09-20T18:50:18  <sipa> goatpig: yuck :)
367 2017-09-20T18:50:27  <goatpig> so mean!
368 2017-09-20T18:50:27  <ThomasV> sipa: but soft forks are not so common, so I have time to think about it :)
369 2017-09-20T18:50:41  <sipa> ThomasV: depends on how fast your users upgrafe
370 2017-09-20T18:50:54  <ThomasV> yeah
371 2017-09-20T18:50:57  <sipa> we saw with p2sh that it took years before every wallet was able to send to it
372 2017-09-20T18:51:26  <sipa> i expect that for bip173 it will be less time, but i'd rather  ot have that delay for every softfork
373 2017-09-20T18:51:41  <ThomasV> I understand
374 2017-09-20T18:51:54  <ThomasV> will do
375 2017-09-20T18:51:58  <sipa> thanks!
376 2017-09-20T19:00:10  <ThomasV> ok, dinner time
377 2017-09-20T19:00:31  <sipa> ok, lunch time
378 2017-09-20T19:05:08  *** ThomasV has quit IRC
379 2017-09-20T19:08:02  <gmaxwell> adiabat: have you seen achow's psbt format?  not what you're suggesting but its relevant. It could perhaps incorporate what you're thinking by gaining extra fields to carry around the private key for an input.
380 2017-09-20T19:08:23  *** alreadylate has joined #bitcoin-core-dev
381 2017-09-20T19:12:25  *** wbobeirne has joined #bitcoin-core-dev
382 2017-09-20T19:15:08  *** promag has quit IRC
383 2017-09-20T19:15:50  *** wbobeirne has quit IRC
384 2017-09-20T19:25:24  *** Miezel has joined #bitcoin-core-dev
385 2017-09-20T19:35:28  *** alreadylate has quit IRC
386 2017-09-20T19:37:04  *** owowo has quit IRC
387 2017-09-20T19:41:23  *** alreadylate has joined #bitcoin-core-dev
388 2017-09-20T19:42:14  *** owowo has joined #bitcoin-core-dev
389 2017-09-20T19:44:50  *** wampy has quit IRC
390 2017-09-20T19:54:17  *** vicenteH has joined #bitcoin-core-dev
391 2017-09-20T19:55:35  *** PaulCapestany has quit IRC
392 2017-09-20T19:57:49  *** PaulCapestany has joined #bitcoin-core-dev
393 2017-09-20T19:57:51  *** timothy has quit IRC
394 2017-09-20T19:58:16  <adiabat> gmaxwell: saw the post; looks interesting and not quite what I have, but something similar
395 2017-09-20T19:58:29  <adiabat> github link in that doesn't seem to work though
396 2017-09-20T19:58:41  <adiabat> (link from the mailing list post I mean)
397 2017-09-20T19:59:55  *** chjj has quit IRC
398 2017-09-20T20:02:13  *** alreadylate has quit IRC
399 2017-09-20T20:02:36  *** promag has joined #bitcoin-core-dev
400 2017-09-20T20:06:56  *** promag has quit IRC
401 2017-09-20T20:10:39  *** Miezel_ has joined #bitcoin-core-dev
402 2017-09-20T20:10:43  *** Miezel has quit IRC
403 2017-09-20T20:12:29  <tknp> i might be missing something simple but is there a single rpc call to display the btc value of the items in a vin array using 'getblock'
404 2017-09-20T20:15:37  <sipa> no
405 2017-09-20T20:15:49  <sipa> bitcoind doesn't have that information
406 2017-09-20T20:16:34  *** RubenSomsen has quit IRC
407 2017-09-20T20:17:19  *** meshcollider has joined #bitcoin-core-dev
408 2017-09-20T20:17:20  <tknp> ok thanks. i'll do some more reading. the value i'm after does look to be in the output of gettxout of the txid of the vin in question
409 2017-09-20T20:17:33  <goatpig> outpoint value?
410 2017-09-20T20:19:07  <tknp> oh sorry, i don't mean the monetary value of btc but the 'value' key that relates to the number of bitcoins paid for the output
411 2017-09-20T20:19:24  *** promag has joined #bitcoin-core-dev
412 2017-09-20T20:19:58  <achow101> adiabat: which link?
413 2017-09-20T20:20:21  <meshcollider> adiabat: that's because it was given a BIP number 174 and moved filename, it's here now: https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki
414 2017-09-20T20:20:22  <goatpig> yeah, you want the value of the outpoint the txin is pointing at
415 2017-09-20T20:20:38  <goatpig> i dont think the RPC let's you request outpoints at all
416 2017-09-20T20:21:05  <goatpig> well i guess the proper term is resolving the outpoint
417 2017-09-20T20:22:05  <tknp> goatpid correct. was hoping to not have to make a secondary rpc call for each tx input with the proper vout value
418 2017-09-20T20:22:49  <goatpig> that resolution is expensive, you cant expect a call to get a tx would just go ahead and resolve the outpoints on the off chance the caller might want it
419 2017-09-20T20:23:47  *** promag has quit IRC
420 2017-09-20T20:23:48  <tknp> yup, was hoping that there was a convenience method cooked in with the understanding that it was expensive to call. like a hidden valid value for the format param that would do the resolving
421 2017-09-20T20:24:09  <goatpig> im just guessing here
422 2017-09-20T20:24:20  <goatpig> but i expect core has the dataset necessary to resolve arbitrary outpoints
423 2017-09-20T20:24:27  <goatpig> or maybe not
424 2017-09-20T20:24:33  <goatpig> that's just a guess on my part
425 2017-09-20T20:24:37  <gmaxwell> Bitcoind doesn't have the information.
426 2017-09-20T20:24:44  <goatpig> you need to resolve outpoints to verify incoming zero conf tx
427 2017-09-20T20:24:52  <gmaxwell> Providing it would require an additional quite expensive index, or a sequential scan of the blockchain.
428 2017-09-20T20:24:56  <sipa> it only has the information about unspent outputs
429 2017-09-20T20:25:03  <gmaxwell> goatpig: yes but he is asking about getblock.
430 2017-09-20T20:25:04  <goatpig> but you could do that by just maintaining the utxo set and checking outpoints in zc vs that
431 2017-09-20T20:25:08  <sipa> which is sufficient for validating new blocks
432 2017-09-20T20:25:12  <goatpig> well then he should use armory =D
433 2017-09-20T20:25:18  <goatpig> cause it has a supernode teehee
434 2017-09-20T20:25:37  <gmaxwell> and was unusably slow and will be again eventually. :P
435 2017-09-20T20:26:01  <goatpig> =( so mean
436 2017-09-20T20:26:03  <gmaxwell> haha
437 2017-09-20T20:26:27  <goatpig> man it;s hard to keep up, i wrote the first supernode in 2013, blockchain is like 7 times as large now
438 2017-09-20T20:26:31  <gmaxwell> Sorry. Just the point there is that it's not provided not because bitcoind is lazy or something, but because it has a real non-trivial cost.
439 2017-09-20T20:27:02  <goatpig> yes, just maintaining the dataset to resolve arbirtary tx hashes is expensive
440 2017-09-20T20:27:12  <tknp> understood and thanks. i'll deal with making separate requests through other means
441 2017-09-20T20:29:07  <achow101> gmaxwell: isn't txindex like that
442 2017-09-20T20:29:26  <achow101> an index that can be used to grab arbitrary outpoints
443 2017-09-20T20:30:00  <sipa> achow101: very inefficiently, yes
444 2017-09-20T20:30:14  <gmaxwell> does it still even work? :( I stopped using it on all my hosts because its such a slowdown.
445 2017-09-20T20:30:25  <sipa> (it read the entire block for each output you're looking up)
446 2017-09-20T20:30:26  <achow101> gmaxwell: I use it on my node, seems to work
447 2017-09-20T20:30:47  <achow101> but the index itself is 12 GB apparently
448 2017-09-20T20:31:52  <achow101> syncing a new node with txindex is probably a massive slowdown, but I have had it enabled for several years now so when I synced it wasn't that bad
449 2017-09-20T20:38:14  *** belcher has joined #bitcoin-core-dev
450 2017-09-20T20:39:38  *** ThomasV has joined #bitcoin-core-dev
451 2017-09-20T20:41:10  <adiabat> I run txindex on mainnet and testnet3, it doesn't slow it down too much
452 2017-09-20T20:41:49  <adiabat> then again I'm running on spinning disks so it's pretty slow no matter what :P
453 2017-09-20T20:48:49  *** owowo has quit IRC
454 2017-09-20T21:13:23  *** duringo has joined #bitcoin-core-dev
455 2017-09-20T21:18:18  *** duringo has quit IRC
456 2017-09-20T21:18:31  *** duringo has joined #bitcoin-core-dev
457 2017-09-20T21:37:05  *** ThomasV has quit IRC
458 2017-09-20T21:41:22  *** wxxs has quit IRC
459 2017-09-20T21:44:13  <Sentineo> I run txindex on an odroid xu4
460 2017-09-20T21:44:27  <Sentineo> works fine too, usb stick has the blockchain
461 2017-09-20T21:45:03  <Sentineo> syncing is a pain in the b, but otherwise kt is fine
462 2017-09-20T21:55:41  *** Guyver2 has quit IRC
463 2017-09-20T22:10:46  *** Cheeseo has joined #bitcoin-core-dev
464 2017-09-20T22:11:54  *** Miezel_ has quit IRC
465 2017-09-20T22:14:07  <bitcoin-git> [bitcoin] tomasvdw opened pull request #11376: Ensure backupwallet fails when attempting to backup to source file (master...core) https://github.com/bitcoin/bitcoin/pull/11376
466 2017-09-20T22:22:04  *** ghost43 has quit IRC
467 2017-09-20T22:22:18  *** ghost43 has joined #bitcoin-core-dev
468 2017-09-20T22:26:19  *** duringo has quit IRC
469 2017-09-20T22:48:32  *** Cory has quit IRC
470 2017-09-20T22:49:14  *** cheese_ has joined #bitcoin-core-dev
471 2017-09-20T22:53:10  *** Cory has joined #bitcoin-core-dev
472 2017-09-20T22:54:57  *** Aaronvan_ has joined #bitcoin-core-dev
473 2017-09-20T22:55:52  *** Aaronva__ has joined #bitcoin-core-dev
474 2017-09-20T22:57:08  *** AaronvanW has quit IRC
475 2017-09-20T22:59:32  *** Aaronvan_ has quit IRC
476 2017-09-20T23:10:58  *** owowo has joined #bitcoin-core-dev
477 2017-09-20T23:13:31  *** Geoffy has quit IRC
478 2017-09-20T23:35:19  *** Aaronva__ is now known as AaronvanW
479 2017-09-20T23:40:22  *** rockhouse has quit IRC
480 2017-09-20T23:43:55  *** cheese_ has quit IRC
481 2017-09-20T23:46:41  *** Cheeseo has quit IRC
482 2017-09-20T23:47:22  <bitcoin-git> [bitcoin] sipa pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/551d7bf604fb...98212745c8ac
483 2017-09-20T23:47:22  <bitcoin-git> bitcoin/master 05cae8a Marko Bencun: range-based loops and const qualifications in net.cpp...
484 2017-09-20T23:47:23  <bitcoin-git> bitcoin/master 9821274 Pieter Wuille: Merge #10888: range-based loops and const qualifications in net.cpp...
485 2017-09-20T23:47:52  <bitcoin-git> [bitcoin] sipa closed pull request #10888: range-based loops and const qualifications in net.cpp (master...netcpp_cosmetics2) https://github.com/bitcoin/bitcoin/pull/10888
486 2017-09-20T23:53:53  *** rockhouse has joined #bitcoin-core-dev
487 2017-09-20T23:54:24  *** chjj has joined #bitcoin-core-dev
488 2017-09-20T23:57:12  *** chjj has quit IRC
489 2017-09-20T23:57:22  *** Murch has quit IRC
490 2017-09-20T23:58:22  *** abpa has quit IRC