1 2018-09-11T00:00:50  *** grubles has quit IRC
  2 2018-09-11T00:01:17  *** grubles has joined #bitcoin-core-dev
  3 2018-09-11T00:08:39  *** grubles has quit IRC
  4 2018-09-11T00:12:43  *** Krellan has quit IRC
  5 2018-09-11T00:28:15  *** qrestlove has joined #bitcoin-core-dev
  6 2018-09-11T00:32:48  *** qrestlove has quit IRC
  7 2018-09-11T00:33:12  *** grubles has joined #bitcoin-core-dev
  8 2018-09-11T00:33:54  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  9 2018-09-11T00:57:50  *** Victorsueca has quit IRC
 10 2018-09-11T00:58:49  *** Victorsueca has joined #bitcoin-core-dev
 11 2018-09-11T01:00:41  *** qrestlove has joined #bitcoin-core-dev
 12 2018-09-11T01:12:10  *** unholymachine has quit IRC
 13 2018-09-11T01:19:36  *** AaronvanW has quit IRC
 14 2018-09-11T01:25:18  *** ken2812221 has quit IRC
 15 2018-09-11T01:27:02  *** phwalkr has joined #bitcoin-core-dev
 16 2018-09-11T01:30:15  *** AaronvanW has joined #bitcoin-core-dev
 17 2018-09-11T01:34:27  *** AaronvanW has quit IRC
 18 2018-09-11T01:38:08  <jamesob> I'm no great fan of azure but maybe we should consider using some of this free compute time for things like per-commit build validation: https://azure.microsoft.com/en-us/blog/announcing-azure-pipelines-with-unlimited-ci-cd-minutes-for-open-source/
 19 2018-09-11T01:39:19  *** grubles has quit IRC
 20 2018-09-11T01:39:30  *** gwillen has joined #bitcoin-core-dev
 21 2018-09-11T01:44:13  *** phwalkr has quit IRC
 22 2018-09-11T02:19:44  *** Zenton has quit IRC
 23 2018-09-11T02:20:44  *** Zenton has joined #bitcoin-core-dev
 24 2018-09-11T02:21:13  *** Chris_Stewart_5 has quit IRC
 25 2018-09-11T02:24:59  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 26 2018-09-11T02:31:00  *** AaronvanW has joined #bitcoin-core-dev
 27 2018-09-11T02:35:42  *** AaronvanW has quit IRC
 28 2018-09-11T02:59:13  *** miknotauro has quit IRC
 29 2018-09-11T03:01:59  <sipa> wumpus, achow101: so today i've used the PSBT implementation in 0.17.0rc2 for actual transactions, and noticed a bug or at least weird behaviour that seems fixed in master
 30 2018-09-11T03:03:48  <sipa> the workflow was using createrawtransaction + converttopsbt + walletprocesspsbt on an online system (which just had an importaddress of a P2SH segwit address, but not the full key), which as expected produced a PSBT with no scripts, and a non-witness UTXO (as it couldn't know whether the address was segwit or not)
 31 2018-09-11T03:04:50  <sipa> and then on an offline system i used walletprocesspsbt, which added scripts signed the transaction (as expected), but then produced a PSBT with still a non-witness UTXO is... which finalizepsbt *failed to deserialize*
 32 2018-09-11T03:05:14  <achow101> maybe one of the fixes wasn't backported?
 33 2018-09-11T03:05:47  <sipa> the workaround was to use walletprocesspsbt on the offline system with sign=false, move it back to an online system (which had master running), which converted the non-witness UTXO to a witness UTXO, then move it back to the online system for signing + finalizing
 34 2018-09-11T03:08:13  <sipa> i think this may have been inadvertently fixed by https://github.com/bitcoin/bitcoin/pull/13723
 35 2018-09-11T03:08:31  <sipa> i won't have time the coming week to look into this more, however
 36 2018-09-11T03:09:49  <achow101> sipa: I'll take a look at it
 37 2018-09-11T03:10:11  <achow101> sipa: I think it may have to do with the checking for witness utxo stuff you did in 13723
 38 2018-09-11T03:13:18  <sipa> yes, that seems plausible
 39 2018-09-11T03:17:35  <achow101> sipa: I see why it doesn't replace the non-witness psbt, but you said finalizepsbt couldn't deserialize it?
 40 2018-09-11T03:18:00  <sipa> achow101: sanity check in the deserializer fails
 41 2018-09-11T03:18:20  <achow101> ah
 42 2018-09-11T03:19:11  <sipa> i assume it's non-witness utxo with witness final signature?
 43 2018-09-11T03:19:20  <achow101> yeah
 44 2018-09-11T03:21:47  <achow101> sipa: does master replace it with the non-witness utxo with the witness one?
 45 2018-09-11T03:22:13  <sipa> yup
 46 2018-09-11T03:22:41  <sipa> i ran just walletprocesspsbt on master, and it converted the non-witness utxo to a witness utxo
 47 2018-09-11T03:22:54  <sipa> (after the scripts were filled in)
 48 2018-09-11T03:23:51  <achow101> was that with a wallet with the utxo?
 49 2018-09-11T03:24:18  <achow101> (i.e. online wallet)
 50 2018-09-11T03:24:44  <sipa> yes, i believe
 51 2018-09-11T03:24:54  <sipa> ah, so it may not have converted it, but instead replaced it
 52 2018-09-11T03:24:56  <achow101> yes
 53 2018-09-11T03:25:12  <sipa> hmm, so maybe it wasn't related to 0.17/master
 54 2018-09-11T03:25:13  <achow101> afaik, there is no conversion from non-witness to witness utxo that happens
 55 2018-09-11T03:26:15  <achow101> I think I know how to fix this, both in master and 0.17
 56 2018-09-11T03:54:15  <achow101> sipa: #14196 should fix that for the 0.17 branch
 57 2018-09-11T03:54:16  <gribble> https://github.com/bitcoin/bitcoin/issues/14196 | [0.17][psbt] always drop the unnecessary utxo and convert non-witness utxo to witness when necessary by achow101 · Pull Request #14196 · bitcoin/bitcoin · GitHubAsset 1Asset 1
 58 2018-09-11T04:12:30  *** Chris_Stewart_5 has quit IRC
 59 2018-09-11T04:19:45  <kallewoof> Several people on https://github.com/bitcoin/bips/pull/725 (Generic Signed Message Format) are suggesting I use a fake tx that the prover simply signs. I'm not sure what the benefits of doing this are, though..
 60 2018-09-11T04:20:13  <kallewoof> My approach: custom sighash. Suggested: custom sighash with transaction stuff. But why?
 61 2018-09-11T04:21:55  *** lnostdal has quit IRC
 62 2018-09-11T04:21:56  *** phwalkr has joined #bitcoin-core-dev
 63 2018-09-11T04:22:28  *** copumpkin has quit IRC
 64 2018-09-11T04:23:07  *** fanquake has joined #bitcoin-core-dev
 65 2018-09-11T04:23:21  <achow101> kallewoof: easier to implement
 66 2018-09-11T04:23:27  *** brianhoffman has quit IRC
 67 2018-09-11T04:23:55  <achow101> also hacking message signing into the transaction format is something that has been discussed in the past
 68 2018-09-11T04:24:06  *** copumpkin has joined #bitcoin-core-dev
 69 2018-09-11T04:25:38  <kallewoof> achow101: is it, really? (easier to implement) In bitcoin core, I would add a BaseSignatureChecker that took a sighash and that's all. Just call VerifyScript with the inputs from the SignatureProof container.
 70 2018-09-11T04:26:18  *** phwalkr has quit IRC
 71 2018-09-11T04:26:19  *** brianhoffman has joined #bitcoin-core-dev
 72 2018-09-11T04:26:19  <kallewoof> achow101: with a tx, you would have to create the two transactions, do the custom tweakeries to ensure it is not actually sendable, then sign it
 73 2018-09-11T04:26:24  *** fanquake has quit IRC
 74 2018-09-11T04:28:41  *** Jmabsd has joined #bitcoin-core-dev
 75 2018-09-11T04:29:02  <Jmabsd> What is the structure of Bitcoin Core's HD wallet now (derivation paths); it's not going with BIP 44/49 today is it?
 76 2018-09-11T04:29:42  <Jmabsd> does Bitcoin Core do BIP 44 "m / purpose' / coin_type' / account' / change / address_index" form at all?
 77 2018-09-11T04:29:46  <achow101> kallewoof: I'm not sure. I haven't really been following the discussion there
 78 2018-09-11T04:29:56  <achow101> Jmabsd: it uses m/0'/0'/i'
 79 2018-09-11T04:30:07  <achow101> Jmabsd: and m/0'/1'/i'
 80 2018-09-11T04:30:26  <Jmabsd> achow101: err, err, so purpose = 0 - or does it even call it purpose?
 81 2018-09-11T04:30:32  <Jmabsd> achow101: and.. second level is change or account?
 82 2018-09-11T04:30:49  <achow101> first level has no name. second is change
 83 2018-09-11T04:31:03  <achow101> well 'internal' (change) and 'external' (receiving)
 84 2018-09-11T04:31:19  <Jmabsd> achow101: aha so it's an ultrareduced form of BIP 44 ha
 85 2018-09-11T04:31:36  <achow101> no, bip44 uses unhardened derivation. Core uses all hardened
 86 2018-09-11T04:31:44  <Jmabsd> achow101: so Bitcoin Core cut away the "coin" and the "account" derivation, and set purpose to 0 - that's pretty much it yes?
 87 2018-09-11T04:31:47  *** AaronvanW has joined #bitcoin-core-dev
 88 2018-09-11T04:32:45  <kallewoof> achow101: Gotcha. Thanks for the hints though. Perhaps I am overthinking the added complexity of requiring tx creation capabilities when you're just out to sign something using a privkey.
 89 2018-09-11T04:33:50  <Jmabsd> achow101: in other words, Bitcoin Core rolled it own thing.
 90 2018-09-11T04:33:52  <achow101> Jmabsd: or really bip44 is bip32 with stuff added onto it. the original description of suggested derivations paths is very similar to core: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#the-default-wallet-layout
 91 2018-09-11T04:36:51  <Jmabsd> achow101: did Bitcoin Core have any particular point with _not_ implementing an accounts abstraction - it's just Bitcoin Core wants to provide one single wallet balance, yes?
 92 2018-09-11T04:37:08  *** AaronvanW has quit IRC
 93 2018-09-11T04:38:07  <achow101> Jmabsd: accounts wouldn't have worked with Core's wallet structure. also, the existing accounts system (which could hmaybe ave been used) was being removed and naming would have been confusing
 94 2018-09-11T04:38:29  <achow101> in general, accounts don't fit into core's wallet model very well
 95 2018-09-11T04:48:51  *** ken2812221 has joined #bitcoin-core-dev
 96 2018-09-11T04:53:42  *** profmac has joined #bitcoin-core-dev
 97 2018-09-11T05:08:50  *** rex4539 has quit IRC
 98 2018-09-11T05:16:24  <sipa> kallewoof: advantage of hacking tx format: hw wallets may not need any changes to produce a signature. downside: hw wallets wouldn't know that they're actually signing a message rather than a tx
 99 2018-09-11T05:17:33  <kallewoof> sipa: right. Yeah, maaku convinced me in PR comments
100 2018-09-11T05:17:37  <sipa> Jmabsd: the "accounts" feature as imagined by bip32/bip44 is more like what we now call multiwallet
101 2018-09-11T05:17:47  <sipa> kallewoof: i'm not sure whether that's a good or a bad thing
102 2018-09-11T05:17:58  <kallewoof> I think it's an OK downside that HW wallets don't realize they're not signing a tx
103 2018-09-11T05:18:04  <kallewoof> given the benefits.
104 2018-09-11T05:18:49  <sipa> kallewoof: i agree with luke as well that the signer actually ought to be aware that they're signing a message rather than a tx
105 2018-09-11T05:19:08  <kallewoof> The HW firmware you mean?
106 2018-09-11T05:19:17  <sipa> well, the human
107 2018-09-11T05:19:31  <sipa> but the only way to guarantee that is having the HW be aware, so it can say
108 2018-09-11T05:19:51  <kallewoof> *nods*
109 2018-09-11T05:20:38  *** DougieBot5000_ has joined #bitcoin-core-dev
110 2018-09-11T05:21:27  <kallewoof> I guess the question then becomes: is it bad to make it possible for people to HW sign a message even before HW wallets support it?
111 2018-09-11T05:21:55  <kallewoof> maaku's point about proof of reserve and such sound useful
112 2018-09-11T05:23:47  <sipa> oh he is suggesting to actually make it a full transaction, not just a signature
113 2018-09-11T05:23:53  <sipa> that gosles even further
114 2018-09-11T05:23:57  <sipa> *goes
115 2018-09-11T05:24:00  *** DougieBot5000 has quit IRC
116 2018-09-11T05:24:26  <kallewoof> Yeah
117 2018-09-11T05:24:51  <kallewoof> 2 transactions. One input tx whose output takes the scriptPubKey and one output tx spending it
118 2018-09-11T05:25:19  <sipa> right, but the first is constructed by the verifiedlr i suppose and not actually included in the proof
119 2018-09-11T05:26:03  <sipa> it's true that it's a very straightforward way of building a forward compatible signing mechanism... but it also sounds scary that someone could be tricked into thinking they're creating a transaction, but they're really signing a message they don't want to
120 2018-09-11T05:26:12  <kallewoof> I think the idea is that you provide the scriptPubKey, sigScript etc and then construct the two txs, and sign or verify them.
121 2018-09-11T05:26:48  <kallewoof> Wouldn't the opposite be more scary? (Think you are signing a msg but creating a tx)
122 2018-09-11T05:27:08  <sipa> oh absolutely, but there is no risk for that in either idea
123 2018-09-11T05:27:22  <kallewoof> Right
124 2018-09-11T05:29:45  <kallewoof> What if a tx version 0xffffffff was reserved for "message transactions"?
125 2018-09-11T05:30:02  <kallewoof> Should be pretty straightforward to check and point out for a user.
126 2018-09-11T05:30:22  <sipa> that's irrelevant
127 2018-09-11T05:30:37  <sipa> there are many ways you can modify a tx to indicate it's really something else
128 2018-09-11T05:31:01  <sipa> the question whethee you want it to be signable by a non-aware piece of software or hardware
129 2018-09-11T05:31:13  <kallewoof> I have a hard time envisioning the situation where someone is fooled into signing a msg when they meant to sign a tx
130 2018-09-11T05:31:25  <sipa> how so?
131 2018-09-11T05:31:38  <sipa> your online machine is hacked, but you trust your hw devicw
132 2018-09-11T05:31:54  <sipa> that is exactly the scenario it is designdd for
133 2018-09-11T05:32:25  <kallewoof> Right, but what would they do with me proving I own funds X?
134 2018-09-11T05:32:35  <kallewoof> Or proving that I am behind "msg=Hello World"
135 2018-09-11T05:32:41  <sipa> signing a message can be far more than proving you have funds
136 2018-09-11T05:32:56  <sipa> if you don't know what you're signing, you shouldn't sign it
137 2018-09-11T05:33:44  *** AaronvanW has joined #bitcoin-core-dev
138 2018-09-11T05:33:46  <kallewoof> Fair enough. So you're saying, don't make it possible for HW wallets to sign these things unless the HW firmware gets an update to explicitly support it.
139 2018-09-11T05:34:00  <sipa> right
140 2018-09-11T05:34:25  <sipa> i also understand the argument that actually using a full tx structure gives a lot of compatibility options
141 2018-09-11T05:34:34  <sipa> it also makes it bigger
142 2018-09-11T05:34:42  <kallewoof> Well, not the proof per se.
143 2018-09-11T05:34:48  <kallewoof> The temporary memory foot print, yes.
144 2018-09-11T05:35:05  <sipa> well i believe maaku's idea is to actually use a tx as proof
145 2018-09-11T05:35:21  <sipa> so that it automatically includes whatever future structures get added to it
146 2018-09-11T05:36:19  <kallewoof> Maybe I misunderstood yeah. His talk about 'deterministic' made me assume it would recreate the tx both when signing and when verifying.
147 2018-09-11T05:36:29  <sipa> perhaps
148 2018-09-11T05:36:33  <sipa> it's unclear to me
149 2018-09-11T05:37:10  <sipa> in any case, i agree it is very forward compatible, but i'd prefer something where the signers need to be aware
150 2018-09-11T05:37:54  <sipa> i'm sure you can combine the two, by using a tx like structure, but changing the sighash algorithm, for example, so it can never be a valid transaction
151 2018-09-11T05:38:04  *** AaronvanW has quit IRC
152 2018-09-11T05:38:17  <sipa> though than you also lose the ability for unaware signers to create message sigs... which i think is inevitable
153 2018-09-11T05:38:24  *** Krellan has joined #bitcoin-core-dev
154 2018-09-11T05:40:54  <kallewoof> The whole idea behind using the transaction format is so you can drop it in as is, without doing custom stuff. Making a non-tx tx sounds like it defeats the purpose.
155 2018-09-11T05:41:32  <sipa> it still maintains all forward compatibility
156 2018-09-11T05:41:38  <sipa> just not backward compatibility
157 2018-09-11T05:42:00  *** miknotauro has joined #bitcoin-core-dev
158 2018-09-11T05:42:51  <kallewoof> Hm..
159 2018-09-11T05:44:06  <sipa> my preference is still something simple that's just a single scriptSig/witness though
160 2018-09-11T05:50:56  <wumpus> good to catch this in the rc phase at least!
161 2018-09-11T05:52:02  *** fanquake has joined #bitcoin-core-dev
162 2018-09-11T05:52:08  *** lnostdal has joined #bitcoin-core-dev
163 2018-09-11T05:52:12  <sipa> wumpus: it's a weird case, and not exactly following the intended workflow... but still, ending up with a non-deserializable psbt string is definitely not acceptable
164 2018-09-11T05:52:41  <wumpus> yes it shouldn't really happen
165 2018-09-11T06:03:47  *** Jmabsd has quit IRC
166 2018-09-11T06:14:34  *** Apocalyptic has quit IRC
167 2018-09-11T06:16:23  *** Apocalyptic has joined #bitcoin-core-dev
168 2018-09-11T06:27:14  *** ghost43 has quit IRC
169 2018-09-11T06:27:28  *** ghost43 has joined #bitcoin-core-dev
170 2018-09-11T06:34:30  *** AaronvanW has joined #bitcoin-core-dev
171 2018-09-11T06:39:12  *** AaronvanW has quit IRC
172 2018-09-11T06:51:59  *** phwalkr has joined #bitcoin-core-dev
173 2018-09-11T06:54:30  *** phwalkr has quit IRC
174 2018-09-11T07:00:24  *** fanquake has quit IRC
175 2018-09-11T07:02:39  *** fanquake has joined #bitcoin-core-dev
176 2018-09-11T07:10:37  <fanquake> Since gitian-builder started supporting docker containers, has anyone been using it directly on macOS, rather than having to run inside a VM? i.e macOS -> Debian VM -> gitian-builder?
177 2018-09-11T07:11:10  <wumpus> I haven't, sounds like a cool idea though
178 2018-09-11T07:11:23  <fanquake> I played around with getting it working today, only one issue with the macOS date command. Otherwise, seems to work ok. I've built 0.17.0rc3 sigs that match.
179 2018-09-11T07:11:45  <wumpus> moving to less layers of containers means less moving parts and hopefully more reliability
180 2018-09-11T07:12:15  <wumpus> great !
181 2018-09-11T07:13:20  <fanquake> wumpus Yep, one of the complaints about gitian building was always that it was hard to do, and having to essentially run multiple VMs never helped.
182 2018-09-11T07:16:56  *** brianhoffman_ has joined #bitcoin-core-dev
183 2018-09-11T07:17:47  *** brianhoffman has quit IRC
184 2018-09-11T07:17:47  *** brianhoffman_ is now known as brianhoffman
185 2018-09-11T07:20:41  <wumpus> if there's anything we've learned from years of maintainership it's that big redesigned always take much longer than expected and these kind of incremental improvements are worth doing, even if the long-term plan it to throw out gitian completely
186 2018-09-11T07:23:12  <warren> fanquake: what does "date -u" return on macos?
187 2018-09-11T07:23:45  <fanquake> warren Tue 11 Sep 2018 07:23:21 UTC
188 2018-09-11T07:23:56  <warren> fanquake: date +%s ?
189 2018-09-11T07:24:13  <fanquake> warren 1536650642
190 2018-09-11T07:24:27  <warren> k th
191 2018-09-11T07:24:56  <wumpus> fanquake: I suppose that also depends on the locale?
192 2018-09-11T07:26:04  <fanquake> wumpus passing -u Should show the date in UTC. Otherwise if I just do 'date' I'll see "Tue 11 Sep 2018 15:25:52 AWST", which does use my locale.
193 2018-09-11T07:26:27  <wumpus> timezone, yes, but I mean the YYYY/MM/DD ordering still might be locale dependent
194 2018-09-11T07:26:43  <wumpus> or the language of the months
195 2018-09-11T07:27:59  <fanquake> wumpus yes probably. One problem I saw with gitian-builder was using "date +"%F %T" -u -f -", on macOS that'll give you "date: illegal time format"
196 2018-09-11T07:28:31  <fanquake> However, given that you have to install coreutils for sha256sum (which macOS doesn't have), I just swapped to using the coreutils supplied date as well.
197 2018-09-11T07:29:07  <fanquake> macs seem to be pretty bad all over for locale dependance issues. Have seen them before with sed as well.
198 2018-09-11T07:30:07  <wumpus> shell script is a bad language if you want locale independence, or even architecture independence
199 2018-09-11T07:30:32  <wumpus> it relies on so many external exectubles
200 2018-09-11T07:31:45  *** cisba has quit IRC
201 2018-09-11T07:34:59  <fanquake> wumpus Are you proposing re-writing Core in Rust at Core-Dev?
202 2018-09-11T07:35:17  *** AaronvanW has joined #bitcoin-core-dev
203 2018-09-11T07:35:19  <wumpus> noooooo :)
204 2018-09-11T07:35:34  <mryandao> isnt blue matt already working on one?
205 2018-09-11T07:36:12  <dongcarl> mryandao: rust-bitcoin isn't a rewrite yet, and BlueMatt isn't the only developer
206 2018-09-11T07:36:38  <mryandao> my apologies for inappropriate attribution :(
207 2018-09-11T07:37:10  <wumpus> rust-bitcoin is a library that implements some bitcoin primitives in rust, it's not meant as a replacement for bitcoin core, but something like python-bitcoinlib
208 2018-09-11T07:37:24  <wumpus> (it could be used as part of a node implementation of course)
209 2018-09-11T07:37:36  <warren> fanquake: locale in unix terms is more language than timezone which is a different name
210 2018-09-11T07:37:57  <kallewoof> I very recently discovered it, following andrew poelstra's github trace, actually. he seems to be very active!
211 2018-09-11T07:38:23  <mryandao> anyone balsy enough to run parity-bitcoin?
212 2018-09-11T07:40:03  *** AaronvanW has quit IRC
213 2018-09-11T07:40:11  <fanquake> warren thanks
214 2018-09-11T07:40:49  <dongcarl> wumpus and I talked about perhaps writing a standalone P2P bitcoin server in Rust that can FFI with bitcoind
215 2018-09-11T07:42:09  <dongcarl> The main benefit being memory safety, and zero-cost abstractions for managing all the connections
216 2018-09-11T07:42:52  <wumpus> right, bitcoind as 'consensus engine' with the network-facing parts in rust
217 2018-09-11T07:42:59  <warren> YES!!!
218 2018-09-11T07:42:59  <mryandao> any chance for a libconsensus rewrite in rust?
219 2018-09-11T07:43:16  <wumpus> mryandao: that's a very bad idea
220 2018-09-11T07:43:23  <dongcarl> I don't think everything needs to be rewritten in Rust
221 2018-09-11T07:43:27  <dongcarl> libconsensus should be in C
222 2018-09-11T07:43:43  <dongcarl> as FFI to C is well-implemented for almost all languages
223 2018-09-11T07:43:48  <wumpus> the whole point is that rewriting the consensus code in differnet language
224 2018-09-11T07:43:52  <wumpus> is EXTREMELY DANGEROUS
225 2018-09-11T07:43:57  <wumpus> and has a very high fork risk
226 2018-09-11T07:43:57  <fanquake> ^
227 2018-09-11T07:43:58  <warren> mryandao: Good idea only if you can faithfully reproduce all bugs, even unknown bugs
228 2018-09-11T07:43:59  <wumpus> don't do this
229 2018-09-11T07:44:32  <wumpus> all the non-concensus parts are fair game though
230 2018-09-11T07:44:37  <warren> +1
231 2018-09-11T07:45:07  <mryandao> sorry, i just couldnt resist when i hear re-write
232 2018-09-11T07:45:08  <mryandao> kek
233 2018-09-11T07:45:34  <warren> mryandao: multiple people here started years ago on the side of "This is crazy! We need to write a specification of what is Bitcoin." and a year or two of study later realize reimplmentations are too dangerous.
234 2018-09-11T07:45:50  <dongcarl> I'd like to eventually get to a point where bitcoind is just a consensus engine, but I think the reasonable first step is to start with just the p2p parts
235 2018-09-11T07:45:56  <wumpus> mryandao: sarcasm doesn't travel well over IRC, sorry
236 2018-09-11T07:46:20  <wumpus> exactly, what warren says, you'd not be the first to propose it's seriously
237 2018-09-11T07:46:46  <dongcarl> I believe that it would be wise to revisit libconsensus, as I know that most PRs related to it have become stale
238 2018-09-11T07:47:13  <mryandao> what if a future C++ compiler tweaks the behavior of libconsensus though
239 2018-09-11T07:47:15  <warren> Yes it would be really nice to be able to use most of bitcoin core as libraries in other projects.
240 2018-09-11T07:47:16  <mryandao> could happen?
241 2018-09-11T07:47:25  <dongcarl> revisit as in see if the API need changes, and organize an effort to actually get it done
242 2018-09-11T07:47:26  <warren> It sucks that that drags in libstdc++ as a dependency
243 2018-09-11T07:47:48  <wumpus> mryandao: yes, even different compiler versions or CPU architectures have a slight hardfork risk - that's a really bad reason to increase the risk even more
244 2018-09-11T07:48:21  <wumpus> warren: at least that tends to be installed everywhere, I'd say boost is much worse
245 2018-09-11T07:49:01  <fanquake> dongcarl, are you going to Tokyo? Maybe add that to the list of discussion topics?
246 2018-09-11T07:49:16  <dongcarl> fanquake: Yes, I was proposing that in IRC yesterday.
247 2018-09-11T07:49:18  <warren> mryandao: the bigger risk is undiscovered bugs in the dependent libraries, this blew up several times in the past. Bitcoin devs found/reported/fixed many bugs in openssl and spent years to carefully write a replacement to get rid of openssl.
248 2018-09-11T07:49:23  <wumpus> mryandao: e.g. there has been a case in the past (in OpenSSL) where 32/64 bit architectures had different behavior and could be forked
249 2018-09-11T07:49:26  <dongcarl> fanquake: where do I add to the list?
250 2018-09-11T07:49:35  <fanquake> dongcarl, ah sorry
251 2018-09-11T07:49:40  *** timothy has joined #bitcoin-core-dev
252 2018-09-11T07:49:59  <fanquake> I think the easiest way is to email the organisers. They are maintaining a list of proposed topics.
253 2018-09-11T07:50:12  <wumpus> mryandao: these are not exactly new concerns FWIW
254 2018-09-11T07:51:07  <fanquake> At least good progress has been made over the last 3-4 years continually dropping dependencies.
255 2018-09-11T07:51:15  <wumpus> yes
256 2018-09-11T07:51:18  <warren> mryandao: other implmenetations exist, they might be good, but they would be better if you could swap out the consensus parts of their code for libconsensus from Core
257 2018-09-11T07:51:21  <fanquake> I saw soneone talking (again) about fulling ridding the codebase of OpenSSL a few days ago.
258 2018-09-11T07:51:45  <wumpus> I think the current situation where OpenSSL is only used for randomness is ok
259 2018-09-11T07:52:21  <warren> "they might be good" is being polite. People here argue that they are dangerous to rely upon without also checking for consistency with a Core node.
260 2018-09-11T07:52:51  <warren> wumpus: huh, thought folks here wrote a replacement for that too years ago?
261 2018-09-11T07:52:57  <warren> maybe they don't trust themselves
262 2018-09-11T07:53:08  <wumpus> (sure, dropping the dependency completely would be great, but at least it doesn't touch consensus code anymore, and replacing randomness is a huge risk)
263 2018-09-11T07:53:54  <wumpus> warren: yes, but it's hard to get enough confidence in it imo
264 2018-09-11T07:54:09  <warren> ah, I hadn't heard an update on that for a while.
265 2018-09-11T07:54:45  <wumpus> I don't think it's actively being worked on at the moment, someone could pick it up, but it doesn't seem like that much of a priority, certainly compared to the risks
266 2018-09-11T07:56:08  <fanquake> There has been #5885 and #10299
267 2018-09-11T07:56:11  <gribble> https://github.com/bitcoin/bitcoin/issues/5885 | [WIP] Replace OpenSSL PRNG with built-in Fortuna implementation by sipa · Pull Request #5885 · bitcoin/bitcoin · GitHub
268 2018-09-11T07:56:12  <gribble> https://github.com/bitcoin/bitcoin/issues/10299 | Remove OpenSSL by sipa · Pull Request #10299 · bitcoin/bitcoin · GitHub
269 2018-09-11T07:56:33  <warren> My handler says to just rely on the hardware RNG directly without mixing other entropy. There's a new kernel option for that.
270 2018-09-11T07:56:52  <wumpus> thanks, yes what fanquake says, the code is there if someone wants to pick it up
271 2018-09-11T07:57:03  <wumpus> warren: HAH
272 2018-09-11T07:57:26  <dongcarl> wumpus: pick it up as in rebase it?
273 2018-09-11T07:57:42  <wumpus> proprietary, secret sauce random, with no-backdoor guarantee!
274 2018-09-11T07:58:02  <fanquake> warren maybe you can write us something like BIP42 for that
275 2018-09-11T07:58:07  <wumpus> dongcarl: rebasing would be the first step, I'm not sure what other work is involved
276 2018-09-11T07:58:49  <fanquake> Would also need to carve openssl out of the depends system if that isn't a part of the PRs already. See how that affects Qt/building etc.
277 2018-09-11T08:01:00  <wumpus> you can't remove it from the depends system as long as qt still relies on it for the payment request shit
278 2018-09-11T08:02:04  <dongcarl> Looks like provoostenator tried working on it in his branches?
279 2018-09-11T08:02:06  <wumpus> (which I was trying to depecrate, just when bitpay got the *genius* idea to require it)
280 2018-09-11T08:03:16  <wumpus> #11622
281 2018-09-11T08:03:20  <gribble> https://github.com/bitcoin/bitcoin/issues/11622 | build: Add --disable-bip70 configure option by laanwj · Pull Request #11622 · bitcoin/bitcoin · GitHub
282 2018-09-11T08:03:37  <wumpus> of all the PRs I tried to do and didn't go through, I think that one hurt the most
283 2018-09-11T08:04:01  <fanquake> :'(
284 2018-09-11T08:04:49  <dongcarl> ooof...
285 2018-09-11T08:07:48  *** setpill has joined #bitcoin-core-dev
286 2018-09-11T08:08:05  <wumpus> the whole move has caused bitpay to lose a lot of merchants and users, I hope they'll be reduced enough at some point that they don't carry much weight anymore
287 2018-09-11T08:08:38  <wumpus> but for now, it's realistic to drop the dependency of bitcoind on openssl, but not the bitcoin-qt one
288 2018-09-11T08:09:14  <wumpus> (in -qt it's used in *two* ways, directly to validate the payment messages, and indirectly through qt to fetch https:// URLs)
289 2018-09-11T08:09:42  * dongcarl facepalm
290 2018-09-11T08:09:53  *** setpill has quit IRC
291 2018-09-11T08:10:51  <warren> wumpus: I think there is still strong enough reason to begin the deprecation process, without beginning the process we'll NEVER get rid of openssl
292 2018-09-11T08:11:42  <wumpus> warren: I think most scenarios that care about dependencies (e.g., on servers) already don't involve building the GUI
293 2018-09-11T08:11:43  *** setpill has joined #bitcoin-core-dev
294 2018-09-11T08:11:56  <wumpus> so dropping the direct dependency for randomness will help most, there
295 2018-09-11T08:13:11  <wumpus> but if you really want to take on deprecating BIP70 with bitpay against you, I'll support you, but it's not something I want to take up, I don't have the motivation nor energy
296 2018-09-11T08:13:18  <dongcarl> From https://github.com/bitcoin/bitcoin/pull/10299#issuecomment-298785082 it seems like sipa was going to "propose some other RNG changes first"
297 2018-09-11T08:13:24  <dongcarl> Did that end up happening?
298 2018-09-11T08:13:50  <wumpus> no, sipa kind of dropped the project to persue other things (this was talked about at last meeting AFAIK)
299 2018-09-11T08:13:58  <dongcarl> pinging fanquake, keeper of the PRs, adder of the labels
300 2018-09-11T08:14:00  *** ylbam has joined #bitcoin-core-dev
301 2018-09-11T08:14:10  <dongcarl> I see
302 2018-09-11T08:15:06  <dongcarl> wumpus: are there other dependencies that could be dropped that aren't yet?
303 2018-09-11T08:16:01  <wumpus> https://github.com/bitcoin/bitcoin/projects/3
304 2018-09-11T08:16:58  <warren> We will be able to drop boost entirely at some point?
305 2018-09-11T08:17:30  <fanquake> Eventually, yes, I think it's possible. Cory has various work in process to rid out the "harder" to replace Boost.
306 2018-09-11T08:17:36  <fanquake> *rip
307 2018-09-11T08:17:55  <wumpus> there's a lot of work in that direction, which I think would be pointless if the eventual goal is not to drop boost. It's not close, though.
308 2018-09-11T08:18:23  <wumpus> the toughest hurdle is the multi-index strcuture used in mempool
309 2018-09-11T08:18:27  <fanquake> However I have been overly optimistic about removing Boost in the past, hah. https://github.com/bitcoin/bitcoin/issues/8875#issuecomment-280325296
310 2018-09-11T08:19:15  <wumpus> there's no current or future c++ standard library support planned for that as far as I know, and reimplementing it is difficult, as well as risky
311 2018-09-11T08:19:39  <wumpus> the other things are more or less straightforward work, although some have to wait for a future c++ standard (like filesystem)
312 2018-09-11T08:19:58  <fanquake> I'd like to do any dependency bumping pretty early on for 0.18, it got left (especially qt) until pretty late in the 0.17.0 cycle, so would prefer to do it earlier this time.
313 2018-09-11T08:20:42  <fanquake> Also have to pull in that c++14 requirement :p
314 2018-09-11T08:20:44  <wumpus> I agree, it's better to do such things early-on in the cycle
315 2018-09-11T08:21:46  <wumpus> also want to get the windows unicode patches in asap, the more time is left for noticing problems with them
316 2018-09-11T08:25:53  <dongcarl> wumpus: what is the multi-index structure? a collection that can be indexed into by multiple types or have multiple indices, or both?
317 2018-09-11T08:26:53  <fanquake> dongcarl https://www.boost.org/doc/libs/1_68_0/libs/multi_index/doc/index.html
318 2018-09-11T08:27:37  <wumpus> dongcarl: multiple indices, like an sql database: https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.h#L461
319 2018-09-11T08:27:53  <fanquake> wumpus I think #14184 can go in. Unrelated, but I seem to have been getting some bad Qt mirrors lately, really slow downloads.
320 2018-09-11T08:27:55  <gribble> https://github.com/bitcoin/bitcoin/issues/14184 | Scripts and tools: increased timeout downloading by cisba · Pull Request #14184 · bitcoin/bitcoin · GitHub
321 2018-09-11T08:28:27  <wumpus> fanquake: yes, why not
322 2018-09-11T08:30:38  <dongcarl> gh down for anyone else?
323 2018-09-11T08:30:48  *** copumpkin has quit IRC
324 2018-09-11T08:30:50  <wumpus> works for me
325 2018-09-11T08:31:22  *** brianhoffman has quit IRC
326 2018-09-11T08:34:59  *** brianhoffman has joined #bitcoin-core-dev
327 2018-09-11T08:36:05  *** AaronvanW has joined #bitcoin-core-dev
328 2018-09-11T08:38:12  <kallewoof> works for me as well
329 2018-09-11T08:39:10  *** copumpkin has joined #bitcoin-core-dev
330 2018-09-11T08:40:42  *** AaronvanW has quit IRC
331 2018-09-11T08:44:24  *** phwalkr has joined #bitcoin-core-dev
332 2018-09-11T08:52:09  *** justanotheruser has quit IRC
333 2018-09-11T08:56:20  *** phwalkr has quit IRC
334 2018-09-11T09:04:19  *** fanquake has quit IRC
335 2018-09-11T09:07:05  *** fanquake has joined #bitcoin-core-dev
336 2018-09-11T09:13:23  *** Rootsudo has quit IRC
337 2018-09-11T09:16:52  *** phwalkr has joined #bitcoin-core-dev
338 2018-09-11T09:24:22  *** phwalkr has quit IRC
339 2018-09-11T09:25:06  *** setpill has quit IRC
340 2018-09-11T09:25:26  *** setpill has joined #bitcoin-core-dev
341 2018-09-11T09:28:44  *** fanquake has quit IRC
342 2018-09-11T09:30:04  *** setpill has quit IRC
343 2018-09-11T09:31:48  *** setpill has joined #bitcoin-core-dev
344 2018-09-11T09:36:43  *** AaronvanW has joined #bitcoin-core-dev
345 2018-09-11T09:41:36  *** AaronvanW has quit IRC
346 2018-09-11T09:43:55  <wumpus> rc3 binaries up https://bitcoincore.org/bin/bitcoin-core-0.17.0/test.rc3/
347 2018-09-11T09:59:38  *** Guyver2 has joined #bitcoin-core-dev
348 2018-09-11T10:02:07  *** phwalkr has joined #bitcoin-core-dev
349 2018-09-11T10:02:39  *** AaronvanW has joined #bitcoin-core-dev
350 2018-09-11T10:06:00  *** belcher has joined #bitcoin-core-dev
351 2018-09-11T10:15:57  *** unholymachine has joined #bitcoin-core-dev
352 2018-09-11T10:16:31  *** Aaronvan_ has joined #bitcoin-core-dev
353 2018-09-11T10:18:27  *** AaronvanW has quit IRC
354 2018-09-11T10:39:15  <wumpus> github is sluggish here as well now
355 2018-09-11T10:39:26  <wumpus> at least the website
356 2018-09-11T10:40:47  *** SopaXorzTaker has joined #bitcoin-core-dev
357 2018-09-11T10:40:49  <wumpus> https://github.com/zw/bitcoin-gh-meta stopped updating?
358 2018-09-11T10:42:17  *** spinza has quit IRC
359 2018-09-11T10:42:17  *** belcher has quit IRC
360 2018-09-11T10:42:31  *** belcher has joined #bitcoin-core-dev
361 2018-09-11T10:43:42  *** ylbam has quit IRC
362 2018-09-11T10:44:50  *** Victorsueca has quit IRC
363 2018-09-11T10:46:01  *** Victorsueca has joined #bitcoin-core-dev
364 2018-09-11T10:48:53  <wumpus> ok contacted iwilcox, they're not on IRC but managed to find an email
365 2018-09-11T10:54:10  *** spinza has joined #bitcoin-core-dev
366 2018-09-11T10:54:56  *** timothy has quit IRC
367 2018-09-11T10:55:10  *** phwalkr has quit IRC
368 2018-09-11T10:57:10  *** belcher has joined #bitcoin-core-dev
369 2018-09-11T10:59:16  *** Chris_Stewart_5 has joined #bitcoin-core-dev
370 2018-09-11T11:15:06  *** setpill has quit IRC
371 2018-09-11T11:16:27  <echeveria> gentle reminder that it's all on github archive as well.
372 2018-09-11T11:17:12  *** setpill has joined #bitcoin-core-dev
373 2018-09-11T11:24:26  <wumpus> echeveria: the problem is that my release not generation script relies on this specific layout, but sure, I could adapt it if we don't get this running again
374 2018-09-11T11:26:30  *** Aaronvan_ is now known as AaronvanW
375 2018-09-11T11:26:50  <wumpus> echeveria: do you know how to request issue/PR metadata from a specific project from it?
376 2018-09-11T11:28:29  <wumpus> nah, I guess I could request it from github itself through the issue API, the useful thing was having an automatic local mirror of issue data
377 2018-09-11T11:37:49  *** queip has joined #bitcoin-core-dev
378 2018-09-11T11:44:16  <echeveria> wumpus: you can grep the data from it if needed, it's just blobs of JSON data straight from the firehose.
379 2018-09-11T11:44:53  <echeveria> same place the other mirror came from actually.
380 2018-09-11T11:59:50  <wumpus> github is completely AWOL here
381 2018-09-11T12:01:43  *** Krellan has quit IRC
382 2018-09-11T12:02:21  *** Krellan has joined #bitcoin-core-dev
383 2018-09-11T12:03:00  *** drexl has quit IRC
384 2018-09-11T12:16:25  *** Chris_Stewart_5 has quit IRC
385 2018-09-11T12:23:30  *** setpill has quit IRC
386 2018-09-11T12:37:29  *** drexl has joined #bitcoin-core-dev
387 2018-09-11T12:38:01  *** timothy has joined #bitcoin-core-dev
388 2018-09-11T12:40:39  *** promag has joined #bitcoin-core-dev
389 2018-09-11T12:41:35  *** RubenSomsen has quit IRC
390 2018-09-11T12:51:24  *** Kvaciral has joined #bitcoin-core-dev
391 2018-09-11T12:51:33  *** Victorsueca has quit IRC
392 2018-09-11T12:52:51  *** Victorsueca has joined #bitcoin-core-dev
393 2018-09-11T12:53:49  *** rafalcpp has joined #bitcoin-core-dev
394 2018-09-11T13:06:53  *** DougieBot5000_ is now known as DougieBot5000
395 2018-09-11T13:20:09  *** EucOcVrFfr2D has joined #bitcoin-core-dev
396 2018-09-11T13:21:05  *** WudsyWudsyWudsy has joined #bitcoin-core-dev
397 2018-09-11T13:23:21  <EucOcVrFfr2D> Hi does anyone know a tool to compute P2SH from a redeem script? I tried github.com/kallewoof/btcdeb but doesn't seem to offer that feature.
398 2018-09-11T13:24:17  *** WudsyWudsyWudsy has left #bitcoin-core-dev
399 2018-09-11T13:25:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
400 2018-09-11T13:30:16  <EucOcVrFfr2D> I'm asking because i can't wrap my head around the correctness of the test in the PSBT (rpc_psbt.json)
401 2018-09-11T13:32:37  <EucOcVrFfr2D> Oh i might just have fund the answer myself
402 2018-09-11T13:34:01  <EucOcVrFfr2D> https://github.com/bitcoin/bitcoin/blob/v0.17.0rc3/test/functional/data/rpc_psbt.json#L90 the PSBT contains a PartiallySignedInput where RedeemScript=[OP_2, 029583bf39ae0a609747ad199addd634fa6108559d6c5cd39b4c2183f1ab96e07f, 02dab61ff49a14db6a7d02b0cd1fbb78fc4b18312b5b4e54dae4dba2fbfef536d7, OP_2, OP_CHECKMULTISIGVERIFY] and the ScriptPubKey=[OP_HASH160, 0fb9463421696b82c833af241c78c17ddbde4934, OP_EQUAL]
403 2018-09-11T13:36:14  <EucOcVrFfr2D> Now, HASH160(redeemScript) != 0fb9463421696b82c833af241c78c17ddbde4934 , but interestingly if i change the OP_CHECKMULTISIGVERIFY into OP_CHECKMULTISIG ... the hash is correct!
404 2018-09-11T13:40:56  <EucOcVrFfr2D> The expected result in that test is equal to the input, the author @achow101 wanted to make sure bitcoind doesn't 'crash' on that scenario but it silently moves on. The scenario is when we're trying to sign a PSBT input but one of the requirement fails -> https://github.com/bitcoin/bips/blame/master/bip-0174.mediawiki#L342
405 2018-09-11T13:45:08  <EucOcVrFfr2D> It's still a bit confusing why bitcoind does not fail when calling 'walletprocesspsbt' with such an ill-formed PartiallySignedInput.
406 2018-09-11T13:45:12  <EucOcVrFfr2D> /fin
407 2018-09-11T13:47:46  <EucOcVrFfr2D> any clue/help/feedback/comment highly appreciated :)
408 2018-09-11T13:47:52  *** SopaXorzTaker has quit IRC
409 2018-09-11T14:01:20  <achow101> EucOcVrFfr2D: the not failing is to aid with a future RPC analyzepsbt which tells you what is wrong with your psbt
410 2018-09-11T14:01:28  *** adiabat has quit IRC
411 2018-09-11T14:02:02  <EucOcVrFfr2D> achow101: Oh good to know!
412 2018-09-11T14:05:24  *** dqx has quit IRC
413 2018-09-11T14:09:48  <EucOcVrFfr2D> achow101: By the way, i found a duplicate test for the SIGNER role (still in functional/data/rpc_psbt.json), i opened a PR to remove it https://github.com/bitcoin/bitcoin/pull/14199
414 2018-09-11T14:19:02  *** phwalkr has joined #bitcoin-core-dev
415 2018-09-11T14:23:00  *** EucOcVrFfr2D has quit IRC
416 2018-09-11T14:27:49  *** grafcaps has joined #bitcoin-core-dev
417 2018-09-11T14:31:43  *** itaseski has joined #bitcoin-core-dev
418 2018-09-11T14:32:08  *** copumpkin has quit IRC
419 2018-09-11T14:41:40  <BlueMatt> wumpus: there's a helluvalot more in rust-bitcoin than just primitives, but, ok, it *includes* primitives :p
420 2018-09-11T14:45:01  *** grafcaps has quit IRC
421 2018-09-11T14:45:09  *** YSqTU2XbB has joined #bitcoin-core-dev
422 2018-09-11T14:48:21  *** copumpkin has joined #bitcoin-core-dev
423 2018-09-11T14:49:28  *** copumpkin has quit IRC
424 2018-09-11T14:58:18  *** grubles has joined #bitcoin-core-dev
425 2018-09-11T15:04:08  *** jhfrontz has joined #bitcoin-core-dev
426 2018-09-11T15:05:16  *** miknotauro has quit IRC
427 2018-09-11T15:06:30  *** promag has quit IRC
428 2018-09-11T15:07:01  *** copumpkin has joined #bitcoin-core-dev
429 2018-09-11T15:07:33  *** YSqTU2XbB has quit IRC
430 2018-09-11T15:16:19  <wumpus> BlueMatt: yes 'building blocks', I didn't mean 'primitives' in any insulting sense
431 2018-09-11T15:16:19  *** Victorsueca has quit IRC
432 2018-09-11T15:17:13  <wumpus> I just meant it's not intended to be a self-contained node implementation but as a library to use from other software
433 2018-09-11T15:17:29  *** Victorsueca has joined #bitcoin-core-dev
434 2018-09-11T15:31:57  *** harrymm has quit IRC
435 2018-09-11T15:44:47  *** grubles has quit IRC
436 2018-09-11T15:49:34  *** harrymm has joined #bitcoin-core-dev
437 2018-09-11T15:57:07  *** jarthur has joined #bitcoin-core-dev
438 2018-09-11T15:57:16  *** Dizzle has joined #bitcoin-core-dev
439 2018-09-11T16:03:07  *** phwalkr has quit IRC
440 2018-09-11T16:08:37  *** SopaXorzTaker has joined #bitcoin-core-dev
441 2018-09-11T16:11:14  *** miknotauro has joined #bitcoin-core-dev
442 2018-09-11T16:21:03  *** Krellan has quit IRC
443 2018-09-11T16:21:36  *** Krellan has joined #bitcoin-core-dev
444 2018-09-11T16:27:46  *** promag has joined #bitcoin-core-dev
445 2018-09-11T16:58:19  *** promag has quit IRC
446 2018-09-11T17:07:57  *** Krellan has quit IRC
447 2018-09-11T17:20:28  *** jhfrontz has quit IRC
448 2018-09-11T17:27:04  *** timothy has quit IRC
449 2018-09-11T17:30:39  <jnewbery> What do people think about having bitcoind/-qt not create a default wallet on startup if one doesn't already exist? That was one of my motivations for #13059.
450 2018-09-11T17:30:40  <gribble> https://github.com/bitcoin/bitcoin/issues/13059 | Dynamic wallet load / create / unload · Issue #13059 · bitcoin/bitcoin · GitHub
451 2018-09-11T17:31:28  <jnewbery> The idea is that a fresh start-up of bitcoind/qt wuoldn't crete a wallet until a user tried to carry out a task that required wallet, at which point it would prompt them to create.
452 2018-09-11T17:32:11  <sipa> jnewbery: that sounds great to me
453 2018-09-11T17:32:40  <jnewbery> creating the wallet at run time instead of startup allows the user to specify wallet features like disableprivatekeys (#9662) and avoidreuse (#13756)
454 2018-09-11T17:32:44  <gribble> https://github.com/bitcoin/bitcoin/issues/9662 | Add createwallet "disableprivatekeys" option: a sane mode for watchonly-wallets by jonasschnelli · Pull Request #9662 · bitcoin/bitcoin · GitHub
455 2018-09-11T17:32:46  <gribble> https://github.com/bitcoin/bitcoin/issues/13756 | wallet: -avoidreuse feature for improved privacy by kallewoof · Pull Request #13756 · bitcoin/bitcoin · GitHub
456 2018-09-11T17:33:11  <gmaxwell> jnewbery: been recommended several times before. achow tried to do it, prior to multwallet and there were some dumb roadblocks for running without a wallet and loading it later that should be gone.
457 2018-09-11T17:33:42  <jnewbery> I think that #13100 is really the last piece in the puzzle before we can actually do this
458 2018-09-11T17:33:44  <gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add dynamic wallets support by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
459 2018-09-11T17:33:45  <gmaxwell> It'll also allow a wallet to be 'born encrypted' and not end up with a bunch of stupid never used retired keys in it from before encryption.
460 2018-09-11T17:34:38  <gmaxwell> jnewbery: 'promt to create' -- why prompt?
461 2018-09-11T17:35:07  <sipa> gmaxwell: if you want it born encrypted you at least need to prompt for a password
462 2018-09-11T17:35:31  <sipa> but it could also prompt for things like do you have a hw wallet you want integrated
463 2018-09-11T17:35:36  <jnewbery> gmaxwell: I guess maybe that's the wrong wording. The user would need to create a wallet before doing any wallet activities
464 2018-09-11T17:35:50  <gmaxwell> sipa: no, you just choose 'encrypt wallet'.. and that prompts for the password and creates it.
465 2018-09-11T17:35:53  <andytoshi> gmaxwell: if you're restoring a wallet and forget to load the old wallet (say), having Core silently create a new one is annoying and potentially confusing
466 2018-09-11T17:36:26  <gmaxwell> andytoshi: okay, fair enough but the effect of that is that RPCs that currently wont ever fail gain a new failure condition (no wallet yet)
467 2018-09-11T17:36:49  <jnewbery> Those RPCs do fail when no wallet is loaded (eg start with -nowallet)
468 2018-09-11T17:37:13  <gmaxwell> Do they even show up in the rpc list when no wallet is loaded?
469 2018-09-11T17:37:14  <andytoshi> that's frustrating from an API-stability standpoint but in some contexts "succeeding" with a wallet the user didn't intend to create is even worse
470 2018-09-11T17:37:32  <gmaxwell> I'm convinced. I'd just imagined it another way.
471 2018-09-11T17:37:50  *** grubles has joined #bitcoin-core-dev
472 2018-09-11T17:38:06  <gmaxwell> As soon as you want to use the oppturnity to take more settings then obviously you need to run an explicit create command.
473 2018-09-11T17:38:39  <andytoshi> it may be worth adding a command-line option to automatically create a wallet, for people with automated systems (eg integration tests) that depend on the old behaviour
474 2018-09-11T17:38:47  <andytoshi> or not, those systems can just add an extra "createwallet" RPC call to their scripts
475 2018-09-11T17:38:57  * andytoshi stops bikeshedding
476 2018-09-11T17:40:02  <jnewbery> when no wallet is loaded, the wallet RPCs don't show up in the help list. I think that's probably not what we want
477 2018-09-11T17:41:17  <jnewbery> Actually, only the wallet 'management' methods are shown: `createwallet`, `loadwallet`, `unloadwallet` and `listwallets`
478 2018-09-11T17:41:20  <jnewbery> I think that's ok
479 2018-09-11T17:43:44  <wumpus> I think that's fine
480 2018-09-11T17:43:54  <wumpus> if the wallet module is not loaded, wallet RPCs don't show up
481 2018-09-11T17:44:32  <wumpus> you can't use them so why would they show up
482 2018-09-11T17:45:16  <wumpus> just like if you build with --disable-wallet, the wallet options shouldn't show up
483 2018-09-11T17:46:53  <wumpus> (although, yeah, if you build with wallet but have no wallet loaded, there's no wallet to apply the wallet calls to, that's kind of a strange case)
484 2018-09-11T17:47:26  <wumpus> (I think that behavior was inherited from running with -disable-wallet option)
485 2018-09-11T17:47:48  <wumpus> at run time, not compile time
486 2018-09-11T17:47:55  *** unholymachine has quit IRC
487 2018-09-11T17:47:57  <sipa> well bitcoind can't prompt for anything
488 2018-09-11T17:48:20  <sipa> so either bitcoind or "bitcoin-qt -server" still need to automatically create a wallet
489 2018-09-11T17:48:30  <sipa> or they should require configuring one
490 2018-09-11T17:48:44  <wumpus> or-pass a password to the creation call
491 2018-09-11T17:48:47  <jnewbery> wumpus: there's a slight distinction here. If the wallet *component* is not compiled in, then calls to wallet RPCs fail with "method not found". If the wallet component is compiled in, but no wallet is loaded (either with -nowallet at startup or unloadwallet RPC), then calls to wallet RPCs fail with "Method not found (wallet method is disabled because no wallet is loaded)"
492 2018-09-11T17:49:02  <wumpus> jnewbery: yes you're right
493 2018-09-11T17:49:37  <wumpus> jnewbery: run-time -disablewallet is not really a thing anymore, it just means "0 wallets loaded"
494 2018-09-11T17:50:16  <jnewbery> oh, I forgot about that option
495 2018-09-11T17:50:22  <wumpus> the user could always decide to load a wallet later
496 2018-09-11T17:50:27  <wumpus> or, create one
497 2018-09-11T17:50:31  <jnewbery> That would fail with "method not found"
498 2018-09-11T17:50:41  <jnewbery> (same as if wallet had not been compiled in)
499 2018-09-11T17:50:42  <wumpus> oh it does?
500 2018-09-11T17:50:54  <wumpus> I thought that simply meant "load no wallets"
501 2018-09-11T17:51:11  <jnewbery> yes - -disablewallet means "run without the wallet component" -nowallet means "run with the wallet component but no wallet loaded at startup"
502 2018-09-11T17:51:15  <wumpus> I'm confused as usual
503 2018-09-11T17:52:02  <jnewbery> it's confusing because until multiwallet was implemented, -nowallet didn't make sense
504 2018-09-11T17:52:54  <wumpus> right
505 2018-09-11T17:54:39  <wumpus> I didn't know those things were seperate
506 2018-09-11T17:56:00  <wumpus> it makes sense, though
507 2018-09-11T17:56:01  <jnewbery> -nowallet is kind of a hidden feature. It's not documented and relies on the automatic `-no<option>` conversion.
508 2018-09-11T17:56:33  <wumpus> disablewallet is really "I have no wallet and don't want any to be created either"
509 2018-09-11T17:56:41  *** adiabat has joined #bitcoin-core-dev
510 2018-09-11T17:56:53  <wumpus> would make sense to document that one, unless it becomes the default :)
511 2018-09-11T17:58:10  <wumpus> well... I don't know, you'd still want to load the default wallet by default
512 2018-09-11T17:58:16  <wumpus> if it exists
513 2018-09-11T17:59:08  <jnewbery> Yes, -disablewallet really does completely disable the wallet component (eg, the RPC methods are not registered). It's documented.
514 2018-09-11T17:59:51  <jnewbery> yeah, it's slightly different from making -nowallet default. Like you say, if the wallet already exists, then it should be loaded. The proposed change is just if the wallet does not exist in the wallets directory.
515 2018-09-11T18:00:17  <wumpus> I like that idea, to make creation of the wallet a separate step
516 2018-09-11T18:01:10  <jnewbery> Great. Thanks all for the input.
517 2018-09-11T18:01:24  <wumpus> in the GUI it could be some user friendly wizard that runs by default, in bitcoind it'd have to be a commmand, but it's no different from RDBM software where there's no database by default
518 2018-09-11T18:01:40  *** michaelsdunn1 has joined #bitcoin-core-dev
519 2018-09-11T18:04:47  <wumpus> this call might have a lot of optional arguments
520 2018-09-11T18:05:39  <wumpus> (though most of the options can be changed later, setting the encryption on first run makes sense, to avoid creating and discarding a keypool)
521 2018-09-11T18:06:43  <jnewbery> Yes, I much prefer an RPC with lots of optional arguments (that can be omitted when using named args) to having a multitude of command-line arguments when calling bitcoind
522 2018-09-11T18:07:04  <wumpus> absolutely
523 2018-09-11T18:08:04  <gmaxwell> 10:48:20 < sipa> so either bitcoind or "bitcoin-qt -server" still need to automatically create a wallet
524 2018-09-11T18:08:05  <gmaxwell> please no
525 2018-09-11T18:08:23  <gmaxwell> just make the wallet needing rpcs fail until one is created.
526 2018-09-11T18:09:24  <wumpus> yes, like -nowallet
527 2018-09-11T18:09:43  <jnewbery> yes, that's the plan
528 2018-09-11T18:09:58  <gmaxwell> Right now I have something like 50 wallet files, 99% of them are just never used dummy wallets. Where I managed to run bitcoind without a wallet, it created one.. then later I wasn't _sure_ if that wallet was ever actually used or not, so I moved it out of the way and backed it up.
529 2018-09-11T18:10:20  <gmaxwell> if not creating by default were a QT only feature, it wouldn't help me at all.
530 2018-09-11T18:10:40  <wumpus> agree gmaxwell
531 2018-09-11T18:11:03  <jnewbery> sounds like #13926 would also be helpful for you
532 2018-09-11T18:11:05  <gribble> https://github.com/bitcoin/bitcoin/issues/13926 | [Tools] bitcoin-wallet-tool by jnewbery · Pull Request #13926 · bitcoin/bitcoin · GitHub
533 2018-09-11T18:11:10  <jnewbery> </shill>
534 2018-09-11T18:11:28  <wumpus> I'm very careful to *usually* build bitcoind without wallet support when I don't need a wallet, or at least run with disablewallet, still I have the same problem in lesser magnitude
535 2018-09-11T18:12:03  <gmaxwell> jnewbery: I don't think anything helps here, no tool could tell if I ever yanked a key out of a wallet and used the key for something.
536 2018-09-11T18:12:19  <jnewbery> oh, I can't help you with that
537 2018-09-11T18:12:50  <gmaxwell> yea, I normally run with disablewallet, but it turns out that if I do 1000 runs, in 45 of them I manage to fail to provide the argument. :)
538 2018-09-11T18:12:52  <wumpus> you mean, yank a key from the keypool without marking it as used?
539 2018-09-11T18:13:16  <wumpus> right
540 2018-09-11T18:13:27  <gmaxwell> I could have gotten keys out from a plaintext dump, unfortunately. So 'used' isn't sufficient.
541 2018-09-11T18:14:13  *** Chris_Stewart_5 has quit IRC
542 2018-09-11T18:17:59  *** Chris_Stewart_5 has joined #bitcoin-core-dev
543 2018-09-11T18:19:38  *** owowo has quit IRC
544 2018-09-11T18:24:52  *** owowo has joined #bitcoin-core-dev
545 2018-09-11T18:34:43  *** dqx has joined #bitcoin-core-dev
546 2018-09-11T18:42:20  *** Krellan has joined #bitcoin-core-dev
547 2018-09-11T19:01:55  *** SopaXorzTaker has quit IRC
548 2018-09-11T19:05:34  *** miknotauro has quit IRC
549 2018-09-11T19:09:55  *** grubles has quit IRC
550 2018-09-11T19:12:02  *** promag has joined #bitcoin-core-dev
551 2018-09-11T19:12:03  <phantomcircuit> gmaxwell, yeah i too have a bajillion wallets
552 2018-09-11T19:12:11  <phantomcircuit> 99.9999% of which have never been used
553 2018-09-11T19:12:46  *** Dizzle has left #bitcoin-core-dev
554 2018-09-11T19:16:42  *** Krellan has quit IRC
555 2018-09-11T19:27:24  *** Krellan has joined #bitcoin-core-dev
556 2018-09-11T19:27:50  *** jarthur has quit IRC
557 2018-09-11T19:31:03  *** Chris_Stewart_5 has quit IRC
558 2018-09-11T19:39:32  *** lnostdal has quit IRC
559 2018-09-11T19:39:38  <phantomcircuit> MarcoFalke, updated #14147 to fix that issue and some of the style violations
560 2018-09-11T19:39:40  <gribble> https://github.com/bitcoin/bitcoin/issues/14147 | net: Refactor ThreadSocketHandler by pstratem · Pull Request #14147 · bitcoin/bitcoin · GitHubAsset 1Asset 1
561 2018-09-11T19:41:50  *** Chris_Stewart_5 has joined #bitcoin-core-dev
562 2018-09-11T19:43:04  *** promag has quit IRC
563 2018-09-11T19:51:46  *** lnostdal has joined #bitcoin-core-dev
564 2018-09-11T20:01:31  *** phwalkr has joined #bitcoin-core-dev
565 2018-09-11T20:05:02  *** phwalkr has quit IRC
566 2018-09-11T20:06:07  *** jarthur has joined #bitcoin-core-dev
567 2018-09-11T20:07:19  *** grubles has joined #bitcoin-core-dev
568 2018-09-11T20:17:02  *** farmerwampum_ has joined #bitcoin-core-dev
569 2018-09-11T20:18:38  *** farmerwampum has quit IRC
570 2018-09-11T20:18:38  *** farmerwampum_ is now known as farmerwampum
571 2018-09-11T20:22:11  <MarcoFalke> phantomcircuit: thx looks good now
572 2018-09-11T20:24:07  *** grubles has quit IRC
573 2018-09-11T20:24:58  *** grubles has joined #bitcoin-core-dev
574 2018-09-11T20:29:50  *** promag has joined #bitcoin-core-dev
575 2018-09-11T20:39:19  *** molz has quit IRC
576 2018-09-11T20:44:34  *** Chris_Stewart_5 has quit IRC
577 2018-09-11T20:54:09  <ken2812221> MarcoFalke: Is #14007 ready for merge or it needs more ACK?
578 2018-09-11T20:54:12  <gribble> https://github.com/bitcoin/bitcoin/issues/14007 | tests: Run functional test on Windows and enable it on Appveyor by ken2812221 · Pull Request #14007 · bitcoin/bitcoin · GitHub
579 2018-09-11T20:55:09  <MarcoFalke> Id like to have someon else review the test changes as well
580 2018-09-11T21:01:16  <ken2812221> Fine. But it seems bitcoinack shows 0 ack on that PR. It has 2 ack for sure.
581 2018-09-11T21:06:32  <wumpus> it is a bit fiddly with spelling of acks sometimes
582 2018-09-11T21:08:19  *** morcos has quit IRC
583 2018-09-11T21:08:41  *** morcos has joined #bitcoin-core-dev
584 2018-09-11T21:17:52  <phantomcircuit> can i use #define for poll / select er selection?
585 2018-09-11T21:19:15  *** Victorsueca has quit IRC
586 2018-09-11T21:20:15  <gmaxwell> I would expect you to have a define and a configure thing that detects the availablity of poll.
587 2018-09-11T21:20:29  *** Victorsueca has joined #bitcoin-core-dev
588 2018-09-11T21:20:33  <gmaxwell> ideally copied out of some other project that does both and has been around for a long time.
589 2018-09-11T21:21:07  <gmaxwell> maybe squid cache
590 2018-09-11T21:24:00  <phantomcircuit> gmaxwell, it's kind of awkward cause i want that... but not on windows
591 2018-09-11T21:42:55  *** morcos has quit IRC
592 2018-09-11T21:43:29  *** sipa has quit IRC
593 2018-09-11T21:44:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
594 2018-09-11T21:44:59  <jarthur> libevent uses defines to figure out what's available, final decision on what to use made at runtime. Python does something similar.
595 2018-09-11T21:45:17  *** sipa has joined #bitcoin-core-dev
596 2018-09-11T21:45:20  <jarthur> https://github.com/libevent/libevent/blob/29cc8386a2f7911eaa9336692a2c5544d8b4734f/event.c#L77
597 2018-09-11T21:50:44  *** morcos has joined #bitcoin-core-dev
598 2018-09-11T22:01:41  *** belcher has quit IRC
599 2018-09-11T22:05:35  *** phwalkr has joined #bitcoin-core-dev
600 2018-09-11T22:07:41  <phantomcircuit> jarthur, good info
601 2018-09-11T22:08:02  *** ppaqmj has quit IRC
602 2018-09-11T22:09:47  <phantomcircuit> right now i have have an #ifndef WIN32 #define HAVE_POLL
603 2018-09-11T22:09:56  <phantomcircuit> but that's obviously not exactly right..
604 2018-09-11T22:10:14  *** phwalkr has quit IRC
605 2018-09-11T22:13:22  <jarthur> Python example, compile time - https://github.com/python/cpython/blob/e2b40f4ce954ea3d35a73541029b2253abd9d245/Modules/selectmodule.c#L1216 -- run time https://github.com/python/cpython/blob/3.7/Lib/selectors.py
606 2018-09-11T22:17:02  *** michaelsdunn1 has quit IRC
607 2018-09-11T22:18:42  *** jarthur has quit IRC
608 2018-09-11T22:40:52  *** justanotheruser has joined #bitcoin-core-dev
609 2018-09-11T22:49:19  *** unholymachine has joined #bitcoin-core-dev
610 2018-09-11T23:07:55  *** grubles has quit IRC
611 2018-09-11T23:12:24  *** Guyver2 has quit IRC
612 2018-09-11T23:12:36  *** itaseski has quit IRC
613 2018-09-11T23:14:04  *** Victorsueca has quit IRC
614 2018-09-11T23:14:59  *** phwalkr has joined #bitcoin-core-dev
615 2018-09-11T23:15:24  *** Victorsueca has joined #bitcoin-core-dev
616 2018-09-11T23:15:27  *** phwalkr has quit IRC
617 2018-09-11T23:31:42  *** promag has quit IRC
618 2018-09-11T23:42:06  *** AaronvanW has quit IRC