12018-09-11T00:00:50  *** grubles has quit IRC
  22018-09-11T00:01:17  *** grubles has joined #bitcoin-core-dev
  32018-09-11T00:08:39  *** grubles has quit IRC
  42018-09-11T00:12:43  *** Krellan has quit IRC
  52018-09-11T00:28:15  *** qrestlove has joined #bitcoin-core-dev
  62018-09-11T00:32:48  *** qrestlove has quit IRC
  72018-09-11T00:33:12  *** grubles has joined #bitcoin-core-dev
  82018-09-11T00:33:54  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  92018-09-11T00:57:50  *** Victorsueca has quit IRC
 102018-09-11T00:58:49  *** Victorsueca has joined #bitcoin-core-dev
 112018-09-11T01:00:41  *** qrestlove has joined #bitcoin-core-dev
 122018-09-11T01:12:10  *** unholymachine has quit IRC
 132018-09-11T01:19:36  *** AaronvanW has quit IRC
 142018-09-11T01:25:18  *** ken2812221 has quit IRC
 152018-09-11T01:27:02  *** phwalkr has joined #bitcoin-core-dev
 162018-09-11T01:30:15  *** AaronvanW has joined #bitcoin-core-dev
 172018-09-11T01:34:27  *** AaronvanW has quit IRC
 182018-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/
 192018-09-11T01:39:19  *** grubles has quit IRC
 202018-09-11T01:39:30  *** gwillen has joined #bitcoin-core-dev
 212018-09-11T01:44:13  *** phwalkr has quit IRC
 222018-09-11T02:19:44  *** Zenton has quit IRC
 232018-09-11T02:20:44  *** Zenton has joined #bitcoin-core-dev
 242018-09-11T02:21:13  *** Chris_Stewart_5 has quit IRC
 252018-09-11T02:24:59  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 262018-09-11T02:31:00  *** AaronvanW has joined #bitcoin-core-dev
 272018-09-11T02:35:42  *** AaronvanW has quit IRC
 282018-09-11T02:59:13  *** miknotauro has quit IRC
 292018-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
 302018-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)
 312018-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*
 322018-09-11T03:05:14  <achow101> maybe one of the fixes wasn't backported?
 332018-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
 342018-09-11T03:08:13  <sipa> i think this may have been inadvertently fixed by https://github.com/bitcoin/bitcoin/pull/13723
 352018-09-11T03:08:31  <sipa> i won't have time the coming week to look into this more, however
 362018-09-11T03:09:49  <achow101> sipa: I'll take a look at it
 372018-09-11T03:10:11  <achow101> sipa: I think it may have to do with the checking for witness utxo stuff you did in 13723
 382018-09-11T03:13:18  <sipa> yes, that seems plausible
 392018-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?
 402018-09-11T03:18:00  <sipa> achow101: sanity check in the deserializer fails
 412018-09-11T03:18:20  <achow101> ah
 422018-09-11T03:19:11  <sipa> i assume it's non-witness utxo with witness final signature?
 432018-09-11T03:19:20  <achow101> yeah
 442018-09-11T03:21:47  <achow101> sipa: does master replace it with the non-witness utxo with the witness one?
 452018-09-11T03:22:13  <sipa> yup
 462018-09-11T03:22:41  <sipa> i ran just walletprocesspsbt on master, and it converted the non-witness utxo to a witness utxo
 472018-09-11T03:22:54  <sipa> (after the scripts were filled in)
 482018-09-11T03:23:51  <achow101> was that with a wallet with the utxo?
 492018-09-11T03:24:18  <achow101> (i.e. online wallet)
 502018-09-11T03:24:44  <sipa> yes, i believe
 512018-09-11T03:24:54  <sipa> ah, so it may not have converted it, but instead replaced it
 522018-09-11T03:24:56  <achow101> yes
 532018-09-11T03:25:12  <sipa> hmm, so maybe it wasn't related to 0.17/master
 542018-09-11T03:25:13  <achow101> afaik, there is no conversion from non-witness to witness utxo that happens
 552018-09-11T03:26:15  <achow101> I think I know how to fix this, both in master and 0.17
 562018-09-11T03:54:15  <achow101> sipa: #14196 should fix that for the 0.17 branch
 572018-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
 582018-09-11T04:12:30  *** Chris_Stewart_5 has quit IRC
 592018-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..
 602018-09-11T04:20:13  <kallewoof> My approach: custom sighash. Suggested: custom sighash with transaction stuff. But why?
 612018-09-11T04:21:55  *** lnostdal has quit IRC
 622018-09-11T04:21:56  *** phwalkr has joined #bitcoin-core-dev
 632018-09-11T04:22:28  *** copumpkin has quit IRC
 642018-09-11T04:23:07  *** fanquake has joined #bitcoin-core-dev
 652018-09-11T04:23:21  <achow101> kallewoof: easier to implement
 662018-09-11T04:23:27  *** brianhoffman has quit IRC
 672018-09-11T04:23:55  <achow101> also hacking message signing into the transaction format is something that has been discussed in the past
 682018-09-11T04:24:06  *** copumpkin has joined #bitcoin-core-dev
 692018-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.
 702018-09-11T04:26:18  *** phwalkr has quit IRC
 712018-09-11T04:26:19  *** brianhoffman has joined #bitcoin-core-dev
 722018-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
 732018-09-11T04:26:24  *** fanquake has quit IRC
 742018-09-11T04:28:41  *** Jmabsd has joined #bitcoin-core-dev
 752018-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?
 762018-09-11T04:29:42  <Jmabsd> does Bitcoin Core do BIP 44 "m / purpose' / coin_type' / account' / change / address_index" form at all?
 772018-09-11T04:29:46  <achow101> kallewoof: I'm not sure. I haven't really been following the discussion there
 782018-09-11T04:29:56  <achow101> Jmabsd: it uses m/0'/0'/i'
 792018-09-11T04:30:07  <achow101> Jmabsd: and m/0'/1'/i'
 802018-09-11T04:30:26  <Jmabsd> achow101: err, err, so purpose = 0 - or does it even call it purpose?
 812018-09-11T04:30:32  <Jmabsd> achow101: and.. second level is change or account?
 822018-09-11T04:30:49  <achow101> first level has no name. second is change
 832018-09-11T04:31:03  <achow101> well 'internal' (change) and 'external' (receiving)
 842018-09-11T04:31:19  <Jmabsd> achow101: aha so it's an ultrareduced form of BIP 44 ha
 852018-09-11T04:31:36  <achow101> no, bip44 uses unhardened derivation. Core uses all hardened
 862018-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?
 872018-09-11T04:31:47  *** AaronvanW has joined #bitcoin-core-dev
 882018-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.
 892018-09-11T04:33:50  <Jmabsd> achow101: in other words, Bitcoin Core rolled it own thing.
 902018-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
 912018-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?
 922018-09-11T04:37:08  *** AaronvanW has quit IRC
 932018-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
 942018-09-11T04:38:29  <achow101> in general, accounts don't fit into core's wallet model very well
 952018-09-11T04:48:51  *** ken2812221 has joined #bitcoin-core-dev
 962018-09-11T04:53:42  *** profmac has joined #bitcoin-core-dev
 972018-09-11T05:08:50  *** rex4539 has quit IRC
 982018-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
 992018-09-11T05:17:33  <kallewoof> sipa: right. Yeah, maaku convinced me in PR comments
1002018-09-11T05:17:37  <sipa> Jmabsd: the "accounts" feature as imagined by bip32/bip44 is more like what we now call multiwallet
1012018-09-11T05:17:47  <sipa> kallewoof: i'm not sure whether that's a good or a bad thing
1022018-09-11T05:17:58  <kallewoof> I think it's an OK downside that HW wallets don't realize they're not signing a tx
1032018-09-11T05:18:04  <kallewoof> given the benefits.
1042018-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
1052018-09-11T05:19:08  <kallewoof> The HW firmware you mean?
1062018-09-11T05:19:17  <sipa> well, the human
1072018-09-11T05:19:31  <sipa> but the only way to guarantee that is having the HW be aware, so it can say
1082018-09-11T05:19:51  <kallewoof> *nods*
1092018-09-11T05:20:38  *** DougieBot5000_ has joined #bitcoin-core-dev
1102018-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?
1112018-09-11T05:21:55  <kallewoof> maaku's point about proof of reserve and such sound useful
1122018-09-11T05:23:47  <sipa> oh he is suggesting to actually make it a full transaction, not just a signature
1132018-09-11T05:23:53  <sipa> that gosles even further
1142018-09-11T05:23:57  <sipa> *goes
1152018-09-11T05:24:00  *** DougieBot5000 has quit IRC
1162018-09-11T05:24:26  <kallewoof> Yeah
1172018-09-11T05:24:51  <kallewoof> 2 transactions. One input tx whose output takes the scriptPubKey and one output tx spending it
1182018-09-11T05:25:19  <sipa> right, but the first is constructed by the verifiedlr i suppose and not actually included in the proof
1192018-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
1202018-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.
1212018-09-11T05:26:48  <kallewoof> Wouldn't the opposite be more scary? (Think you are signing a msg but creating a tx)
1222018-09-11T05:27:08  <sipa> oh absolutely, but there is no risk for that in either idea
1232018-09-11T05:27:22  <kallewoof> Right
1242018-09-11T05:29:45  <kallewoof> What if a tx version 0xffffffff was reserved for "message transactions"?
1252018-09-11T05:30:02  <kallewoof> Should be pretty straightforward to check and point out for a user.
1262018-09-11T05:30:22  <sipa> that's irrelevant
1272018-09-11T05:30:37  <sipa> there are many ways you can modify a tx to indicate it's really something else
1282018-09-11T05:31:01  <sipa> the question whethee you want it to be signable by a non-aware piece of software or hardware
1292018-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
1302018-09-11T05:31:25  <sipa> how so?
1312018-09-11T05:31:38  <sipa> your online machine is hacked, but you trust your hw devicw
1322018-09-11T05:31:54  <sipa> that is exactly the scenario it is designdd for
1332018-09-11T05:32:25  <kallewoof> Right, but what would they do with me proving I own funds X?
1342018-09-11T05:32:35  <kallewoof> Or proving that I am behind "msg=Hello World"
1352018-09-11T05:32:41  <sipa> signing a message can be far more than proving you have funds
1362018-09-11T05:32:56  <sipa> if you don't know what you're signing, you shouldn't sign it
1372018-09-11T05:33:44  *** AaronvanW has joined #bitcoin-core-dev
1382018-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.
1392018-09-11T05:34:00  <sipa> right
1402018-09-11T05:34:25  <sipa> i also understand the argument that actually using a full tx structure gives a lot of compatibility options
1412018-09-11T05:34:34  <sipa> it also makes it bigger
1422018-09-11T05:34:42  <kallewoof> Well, not the proof per se.
1432018-09-11T05:34:48  <kallewoof> The temporary memory foot print, yes.
1442018-09-11T05:35:05  <sipa> well i believe maaku's idea is to actually use a tx as proof
1452018-09-11T05:35:21  <sipa> so that it automatically includes whatever future structures get added to it
1462018-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.
1472018-09-11T05:36:29  <sipa> perhaps
1482018-09-11T05:36:33  <sipa> it's unclear to me
1492018-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
1502018-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
1512018-09-11T05:38:04  *** AaronvanW has quit IRC
1522018-09-11T05:38:17  <sipa> though than you also lose the ability for unaware signers to create message sigs... which i think is inevitable
1532018-09-11T05:38:24  *** Krellan has joined #bitcoin-core-dev
1542018-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.
1552018-09-11T05:41:32  <sipa> it still maintains all forward compatibility
1562018-09-11T05:41:38  <sipa> just not backward compatibility
1572018-09-11T05:42:00  *** miknotauro has joined #bitcoin-core-dev
1582018-09-11T05:42:51  <kallewoof> Hm..
1592018-09-11T05:44:06  <sipa> my preference is still something simple that's just a single scriptSig/witness though
1602018-09-11T05:50:56  <wumpus> good to catch this in the rc phase at least!
1612018-09-11T05:52:02  *** fanquake has joined #bitcoin-core-dev
1622018-09-11T05:52:08  *** lnostdal has joined #bitcoin-core-dev
1632018-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
1642018-09-11T05:52:41  <wumpus> yes it shouldn't really happen
1652018-09-11T06:03:47  *** Jmabsd has quit IRC
1662018-09-11T06:14:34  *** Apocalyptic has quit IRC
1672018-09-11T06:16:23  *** Apocalyptic has joined #bitcoin-core-dev
1682018-09-11T06:27:14  *** ghost43 has quit IRC
1692018-09-11T06:27:28  *** ghost43 has joined #bitcoin-core-dev
1702018-09-11T06:34:30  *** AaronvanW has joined #bitcoin-core-dev
1712018-09-11T06:39:12  *** AaronvanW has quit IRC
1722018-09-11T06:51:59  *** phwalkr has joined #bitcoin-core-dev
1732018-09-11T06:54:30  *** phwalkr has quit IRC
1742018-09-11T07:00:24  *** fanquake has quit IRC
1752018-09-11T07:02:39  *** fanquake has joined #bitcoin-core-dev
1762018-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?
1772018-09-11T07:11:10  <wumpus> I haven't, sounds like a cool idea though
1782018-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.
1792018-09-11T07:11:45  <wumpus> moving to less layers of containers means less moving parts and hopefully more reliability
1802018-09-11T07:12:15  <wumpus> great !
1812018-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.
1822018-09-11T07:16:56  *** brianhoffman_ has joined #bitcoin-core-dev
1832018-09-11T07:17:47  *** brianhoffman has quit IRC
1842018-09-11T07:17:47  *** brianhoffman_ is now known as brianhoffman
1852018-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
1862018-09-11T07:23:12  <warren> fanquake: what does "date -u" return on macos?
1872018-09-11T07:23:45  <fanquake> warren Tue 11 Sep 2018 07:23:21 UTC
1882018-09-11T07:23:56  <warren> fanquake: date +%s ?
1892018-09-11T07:24:13  <fanquake> warren 1536650642
1902018-09-11T07:24:27  <warren> k th
1912018-09-11T07:24:56  <wumpus> fanquake: I suppose that also depends on the locale?
1922018-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.
1932018-09-11T07:26:27  <wumpus> timezone, yes, but I mean the YYYY/MM/DD ordering still might be locale dependent
1942018-09-11T07:26:43  <wumpus> or the language of the months
1952018-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"
1962018-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.
1972018-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.
1982018-09-11T07:30:07  <wumpus> shell script is a bad language if you want locale independence, or even architecture independence
1992018-09-11T07:30:32  <wumpus> it relies on so many external exectubles
2002018-09-11T07:31:45  *** cisba has quit IRC
2012018-09-11T07:34:59  <fanquake> wumpus Are you proposing re-writing Core in Rust at Core-Dev?
2022018-09-11T07:35:17  *** AaronvanW has joined #bitcoin-core-dev
2032018-09-11T07:35:19  <wumpus> noooooo :)
2042018-09-11T07:35:34  <mryandao> isnt blue matt already working on one?
2052018-09-11T07:36:12  <dongcarl> mryandao: rust-bitcoin isn't a rewrite yet, and BlueMatt isn't the only developer
2062018-09-11T07:36:38  <mryandao> my apologies for inappropriate attribution :(
2072018-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
2082018-09-11T07:37:24  <wumpus> (it could be used as part of a node implementation of course)
2092018-09-11T07:37:36  <warren> fanquake: locale in unix terms is more language than timezone which is a different name
2102018-09-11T07:37:57  <kallewoof> I very recently discovered it, following andrew poelstra's github trace, actually. he seems to be very active!
2112018-09-11T07:38:23  <mryandao> anyone balsy enough to run parity-bitcoin?
2122018-09-11T07:40:03  *** AaronvanW has quit IRC
2132018-09-11T07:40:11  <fanquake> warren thanks
2142018-09-11T07:40:49  <dongcarl> wumpus and I talked about perhaps writing a standalone P2P bitcoin server in Rust that can FFI with bitcoind
2152018-09-11T07:42:09  <dongcarl> The main benefit being memory safety, and zero-cost abstractions for managing all the connections
2162018-09-11T07:42:52  <wumpus> right, bitcoind as 'consensus engine' with the network-facing parts in rust
2172018-09-11T07:42:59  <warren> YES!!!
2182018-09-11T07:42:59  <mryandao> any chance for a libconsensus rewrite in rust?
2192018-09-11T07:43:16  <wumpus> mryandao: that's a very bad idea
2202018-09-11T07:43:23  <dongcarl> I don't think everything needs to be rewritten in Rust
2212018-09-11T07:43:27  <dongcarl> libconsensus should be in C
2222018-09-11T07:43:43  <dongcarl> as FFI to C is well-implemented for almost all languages
2232018-09-11T07:43:48  <wumpus> the whole point is that rewriting the consensus code in differnet language
2242018-09-11T07:43:52  <wumpus> is EXTREMELY DANGEROUS
2252018-09-11T07:43:57  <wumpus> and has a very high fork risk
2262018-09-11T07:43:57  <fanquake> ^
2272018-09-11T07:43:58  <warren> mryandao: Good idea only if you can faithfully reproduce all bugs, even unknown bugs
2282018-09-11T07:43:59  <wumpus> don't do this
2292018-09-11T07:44:32  <wumpus> all the non-concensus parts are fair game though
2302018-09-11T07:44:37  <warren> +1
2312018-09-11T07:45:07  <mryandao> sorry, i just couldnt resist when i hear re-write
2322018-09-11T07:45:08  <mryandao> kek
2332018-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.
2342018-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
2352018-09-11T07:45:56  <wumpus> mryandao: sarcasm doesn't travel well over IRC, sorry
2362018-09-11T07:46:20  <wumpus> exactly, what warren says, you'd not be the first to propose it's seriously
2372018-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
2382018-09-11T07:47:13  <mryandao> what if a future C++ compiler tweaks the behavior of libconsensus though
2392018-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.
2402018-09-11T07:47:16  <mryandao> could happen?
2412018-09-11T07:47:25  <dongcarl> revisit as in see if the API need changes, and organize an effort to actually get it done
2422018-09-11T07:47:26  <warren> It sucks that that drags in libstdc++ as a dependency
2432018-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
2442018-09-11T07:48:21  <wumpus> warren: at least that tends to be installed everywhere, I'd say boost is much worse
2452018-09-11T07:49:01  <fanquake> dongcarl, are you going to Tokyo? Maybe add that to the list of discussion topics?
2462018-09-11T07:49:16  <dongcarl> fanquake: Yes, I was proposing that in IRC yesterday.
2472018-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.
2482018-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
2492018-09-11T07:49:26  <dongcarl> fanquake: where do I add to the list?
2502018-09-11T07:49:35  <fanquake> dongcarl, ah sorry
2512018-09-11T07:49:40  *** timothy has joined #bitcoin-core-dev
2522018-09-11T07:49:59  <fanquake> I think the easiest way is to email the organisers. They are maintaining a list of proposed topics.
2532018-09-11T07:50:12  <wumpus> mryandao: these are not exactly new concerns FWIW
2542018-09-11T07:51:07  <fanquake> At least good progress has been made over the last 3-4 years continually dropping dependencies.
2552018-09-11T07:51:15  <wumpus> yes
2562018-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
2572018-09-11T07:51:21  <fanquake> I saw soneone talking (again) about fulling ridding the codebase of OpenSSL a few days ago.
2582018-09-11T07:51:45  <wumpus> I think the current situation where OpenSSL is only used for randomness is ok
2592018-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.
2602018-09-11T07:52:51  <warren> wumpus: huh, thought folks here wrote a replacement for that too years ago?
2612018-09-11T07:52:57  <warren> maybe they don't trust themselves
2622018-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)
2632018-09-11T07:53:54  <wumpus> warren: yes, but it's hard to get enough confidence in it imo
2642018-09-11T07:54:09  <warren> ah, I hadn't heard an update on that for a while.
2652018-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
2662018-09-11T07:56:08  <fanquake> There has been #5885 and #10299
2672018-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
2682018-09-11T07:56:12  <gribble> https://github.com/bitcoin/bitcoin/issues/10299 | Remove OpenSSL by sipa · Pull Request #10299 · bitcoin/bitcoin · GitHub
2692018-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.
2702018-09-11T07:56:52  <wumpus> thanks, yes what fanquake says, the code is there if someone wants to pick it up
2712018-09-11T07:57:03  <wumpus> warren: HAH
2722018-09-11T07:57:26  <dongcarl> wumpus: pick it up as in rebase it?
2732018-09-11T07:57:42  <wumpus> proprietary, secret sauce random, with no-backdoor guarantee!
2742018-09-11T07:58:02  <fanquake> warren maybe you can write us something like BIP42 for that
2752018-09-11T07:58:07  <wumpus> dongcarl: rebasing would be the first step, I'm not sure what other work is involved
2762018-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.
2772018-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
2782018-09-11T08:02:04  <dongcarl> Looks like provoostenator tried working on it in his branches?
2792018-09-11T08:02:06  <wumpus> (which I was trying to depecrate, just when bitpay got the *genius* idea to require it)
2802018-09-11T08:03:16  <wumpus> #11622
2812018-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
2822018-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
2832018-09-11T08:04:01  <fanquake> :'(
2842018-09-11T08:04:49  <dongcarl> ooof...
2852018-09-11T08:07:48  *** setpill has joined #bitcoin-core-dev
2862018-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
2872018-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
2882018-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)
2892018-09-11T08:09:42  * dongcarl facepalm
2902018-09-11T08:09:53  *** setpill has quit IRC
2912018-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
2922018-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
2932018-09-11T08:11:43  *** setpill has joined #bitcoin-core-dev
2942018-09-11T08:11:56  <wumpus> so dropping the direct dependency for randomness will help most, there
2952018-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
2962018-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"
2972018-09-11T08:13:24  <dongcarl> Did that end up happening?
2982018-09-11T08:13:50  <wumpus> no, sipa kind of dropped the project to persue other things (this was talked about at last meeting AFAIK)
2992018-09-11T08:13:58  <dongcarl> pinging fanquake, keeper of the PRs, adder of the labels
3002018-09-11T08:14:00  *** ylbam has joined #bitcoin-core-dev
3012018-09-11T08:14:10  <dongcarl> I see
3022018-09-11T08:15:06  <dongcarl> wumpus: are there other dependencies that could be dropped that aren't yet?
3032018-09-11T08:16:01  <wumpus> https://github.com/bitcoin/bitcoin/projects/3
3042018-09-11T08:16:58  <warren> We will be able to drop boost entirely at some point?
3052018-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.
3062018-09-11T08:17:36  <fanquake> *rip
3072018-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.
3082018-09-11T08:18:23  <wumpus> the toughest hurdle is the multi-index strcuture used in mempool
3092018-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
3102018-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
3112018-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)
3122018-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.
3132018-09-11T08:20:42  <fanquake> Also have to pull in that c++14 requirement :p
3142018-09-11T08:20:44  <wumpus> I agree, it's better to do such things early-on in the cycle
3152018-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
3162018-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?
3172018-09-11T08:26:53  <fanquake> dongcarl https://www.boost.org/doc/libs/1_68_0/libs/multi_index/doc/index.html
3182018-09-11T08:27:37  <wumpus> dongcarl: multiple indices, like an sql database: https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.h#L461
3192018-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.
3202018-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
3212018-09-11T08:28:27  <wumpus> fanquake: yes, why not
3222018-09-11T08:30:38  <dongcarl> gh down for anyone else?
3232018-09-11T08:30:48  *** copumpkin has quit IRC
3242018-09-11T08:30:50  <wumpus> works for me
3252018-09-11T08:31:22  *** brianhoffman has quit IRC
3262018-09-11T08:34:59  *** brianhoffman has joined #bitcoin-core-dev
3272018-09-11T08:36:05  *** AaronvanW has joined #bitcoin-core-dev
3282018-09-11T08:38:12  <kallewoof> works for me as well
3292018-09-11T08:39:10  *** copumpkin has joined #bitcoin-core-dev
3302018-09-11T08:40:42  *** AaronvanW has quit IRC
3312018-09-11T08:44:24  *** phwalkr has joined #bitcoin-core-dev
3322018-09-11T08:52:09  *** justanotheruser has quit IRC
3332018-09-11T08:56:20  *** phwalkr has quit IRC
3342018-09-11T09:04:19  *** fanquake has quit IRC
3352018-09-11T09:07:05  *** fanquake has joined #bitcoin-core-dev
3362018-09-11T09:13:23  *** Rootsudo has quit IRC
3372018-09-11T09:16:52  *** phwalkr has joined #bitcoin-core-dev
3382018-09-11T09:24:22  *** phwalkr has quit IRC
3392018-09-11T09:25:06  *** setpill has quit IRC
3402018-09-11T09:25:26  *** setpill has joined #bitcoin-core-dev
3412018-09-11T09:28:44  *** fanquake has quit IRC
3422018-09-11T09:30:04  *** setpill has quit IRC
3432018-09-11T09:31:48  *** setpill has joined #bitcoin-core-dev
3442018-09-11T09:36:43  *** AaronvanW has joined #bitcoin-core-dev
3452018-09-11T09:41:36  *** AaronvanW has quit IRC
3462018-09-11T09:43:55  <wumpus> rc3 binaries up https://bitcoincore.org/bin/bitcoin-core-0.17.0/test.rc3/
3472018-09-11T09:59:38  *** Guyver2 has joined #bitcoin-core-dev
3482018-09-11T10:02:07  *** phwalkr has joined #bitcoin-core-dev
3492018-09-11T10:02:39  *** AaronvanW has joined #bitcoin-core-dev
3502018-09-11T10:06:00  *** belcher has joined #bitcoin-core-dev
3512018-09-11T10:15:57  *** unholymachine has joined #bitcoin-core-dev
3522018-09-11T10:16:31  *** Aaronvan_ has joined #bitcoin-core-dev
3532018-09-11T10:18:27  *** AaronvanW has quit IRC
3542018-09-11T10:39:15  <wumpus> github is sluggish here as well now
3552018-09-11T10:39:26  <wumpus> at least the website
3562018-09-11T10:40:47  *** SopaXorzTaker has joined #bitcoin-core-dev
3572018-09-11T10:40:49  <wumpus> https://github.com/zw/bitcoin-gh-meta stopped updating?
3582018-09-11T10:42:17  *** spinza has quit IRC
3592018-09-11T10:42:17  *** belcher has quit IRC
3602018-09-11T10:42:31  *** belcher has joined #bitcoin-core-dev
3612018-09-11T10:43:42  *** ylbam has quit IRC
3622018-09-11T10:44:50  *** Victorsueca has quit IRC
3632018-09-11T10:46:01  *** Victorsueca has joined #bitcoin-core-dev
3642018-09-11T10:48:53  <wumpus> ok contacted iwilcox, they're not on IRC but managed to find an email
3652018-09-11T10:54:10  *** spinza has joined #bitcoin-core-dev
3662018-09-11T10:54:56  *** timothy has quit IRC
3672018-09-11T10:55:10  *** phwalkr has quit IRC
3682018-09-11T10:57:10  *** belcher has joined #bitcoin-core-dev
3692018-09-11T10:59:16  *** Chris_Stewart_5 has joined #bitcoin-core-dev
3702018-09-11T11:15:06  *** setpill has quit IRC
3712018-09-11T11:16:27  <echeveria> gentle reminder that it's all on github archive as well.
3722018-09-11T11:17:12  *** setpill has joined #bitcoin-core-dev
3732018-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
3742018-09-11T11:26:30  *** Aaronvan_ is now known as AaronvanW
3752018-09-11T11:26:50  <wumpus> echeveria: do you know how to request issue/PR metadata from a specific project from it?
3762018-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
3772018-09-11T11:37:49  *** queip has joined #bitcoin-core-dev
3782018-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.
3792018-09-11T11:44:53  <echeveria> same place the other mirror came from actually.
3802018-09-11T11:59:50  <wumpus> github is completely AWOL here
3812018-09-11T12:01:43  *** Krellan has quit IRC
3822018-09-11T12:02:21  *** Krellan has joined #bitcoin-core-dev
3832018-09-11T12:03:00  *** drexl has quit IRC
3842018-09-11T12:16:25  *** Chris_Stewart_5 has quit IRC
3852018-09-11T12:23:30  *** setpill has quit IRC
3862018-09-11T12:37:29  *** drexl has joined #bitcoin-core-dev
3872018-09-11T12:38:01  *** timothy has joined #bitcoin-core-dev
3882018-09-11T12:40:39  *** promag has joined #bitcoin-core-dev
3892018-09-11T12:41:35  *** RubenSomsen has quit IRC
3902018-09-11T12:51:24  *** Kvaciral has joined #bitcoin-core-dev
3912018-09-11T12:51:33  *** Victorsueca has quit IRC
3922018-09-11T12:52:51  *** Victorsueca has joined #bitcoin-core-dev
3932018-09-11T12:53:49  *** rafalcpp has joined #bitcoin-core-dev
3942018-09-11T13:06:53  *** DougieBot5000_ is now known as DougieBot5000
3952018-09-11T13:20:09  *** EucOcVrFfr2D has joined #bitcoin-core-dev
3962018-09-11T13:21:05  *** WudsyWudsyWudsy has joined #bitcoin-core-dev
3972018-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.
3982018-09-11T13:24:17  *** WudsyWudsyWudsy has left #bitcoin-core-dev
3992018-09-11T13:25:51  *** Chris_Stewart_5 has joined #bitcoin-core-dev
4002018-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)
4012018-09-11T13:32:37  <EucOcVrFfr2D> Oh i might just have fund the answer myself
4022018-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]
4032018-09-11T13:36:14  <EucOcVrFfr2D> Now, HASH160(redeemScript) != 0fb9463421696b82c833af241c78c17ddbde4934 , but interestingly if i change the OP_CHECKMULTISIGVERIFY into OP_CHECKMULTISIG ... the hash is correct!
4042018-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
4052018-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.
4062018-09-11T13:45:12  <EucOcVrFfr2D> /fin
4072018-09-11T13:47:46  <EucOcVrFfr2D> any clue/help/feedback/comment highly appreciated :)
4082018-09-11T13:47:52  *** SopaXorzTaker has quit IRC
4092018-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
4102018-09-11T14:01:28  *** adiabat has quit IRC
4112018-09-11T14:02:02  <EucOcVrFfr2D> achow101: Oh good to know!
4122018-09-11T14:05:24  *** dqx has quit IRC
4132018-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
4142018-09-11T14:19:02  *** phwalkr has joined #bitcoin-core-dev
4152018-09-11T14:23:00  *** EucOcVrFfr2D has quit IRC
4162018-09-11T14:27:49  *** grafcaps has joined #bitcoin-core-dev
4172018-09-11T14:31:43  *** itaseski has joined #bitcoin-core-dev
4182018-09-11T14:32:08  *** copumpkin has quit IRC
4192018-09-11T14:41:40  <BlueMatt> wumpus: there's a helluvalot more in rust-bitcoin than just primitives, but, ok, it *includes* primitives :p
4202018-09-11T14:45:01  *** grafcaps has quit IRC
4212018-09-11T14:45:09  *** YSqTU2XbB has joined #bitcoin-core-dev
4222018-09-11T14:48:21  *** copumpkin has joined #bitcoin-core-dev
4232018-09-11T14:49:28  *** copumpkin has quit IRC
4242018-09-11T14:58:18  *** grubles has joined #bitcoin-core-dev
4252018-09-11T15:04:08  *** jhfrontz has joined #bitcoin-core-dev
4262018-09-11T15:05:16  *** miknotauro has quit IRC
4272018-09-11T15:06:30  *** promag has quit IRC
4282018-09-11T15:07:01  *** copumpkin has joined #bitcoin-core-dev
4292018-09-11T15:07:33  *** YSqTU2XbB has quit IRC
4302018-09-11T15:16:19  <wumpus> BlueMatt: yes 'building blocks', I didn't mean 'primitives' in any insulting sense
4312018-09-11T15:16:19  *** Victorsueca has quit IRC
4322018-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
4332018-09-11T15:17:29  *** Victorsueca has joined #bitcoin-core-dev
4342018-09-11T15:31:57  *** harrymm has quit IRC
4352018-09-11T15:44:47  *** grubles has quit IRC
4362018-09-11T15:49:34  *** harrymm has joined #bitcoin-core-dev
4372018-09-11T15:57:07  *** jarthur has joined #bitcoin-core-dev
4382018-09-11T15:57:16  *** Dizzle has joined #bitcoin-core-dev
4392018-09-11T16:03:07  *** phwalkr has quit IRC
4402018-09-11T16:08:37  *** SopaXorzTaker has joined #bitcoin-core-dev
4412018-09-11T16:11:14  *** miknotauro has joined #bitcoin-core-dev
4422018-09-11T16:21:03  *** Krellan has quit IRC
4432018-09-11T16:21:36  *** Krellan has joined #bitcoin-core-dev
4442018-09-11T16:27:46  *** promag has joined #bitcoin-core-dev
4452018-09-11T16:58:19  *** promag has quit IRC
4462018-09-11T17:07:57  *** Krellan has quit IRC
4472018-09-11T17:20:28  *** jhfrontz has quit IRC
4482018-09-11T17:27:04  *** timothy has quit IRC
4492018-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.
4502018-09-11T17:30:40  <gribble> https://github.com/bitcoin/bitcoin/issues/13059 | Dynamic wallet load / create / unload · Issue #13059 · bitcoin/bitcoin · GitHub
4512018-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.
4522018-09-11T17:32:11  <sipa> jnewbery: that sounds great to me
4532018-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)
4542018-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
4552018-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
4562018-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.
4572018-09-11T17:33:42  <jnewbery> I think that #13100 is really the last piece in the puzzle before we can actually do this
4582018-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
4592018-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.
4602018-09-11T17:34:38  <gmaxwell> jnewbery: 'promt to create' -- why prompt?
4612018-09-11T17:35:07  <sipa> gmaxwell: if you want it born encrypted you at least need to prompt for a password
4622018-09-11T17:35:31  <sipa> but it could also prompt for things like do you have a hw wallet you want integrated
4632018-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
4642018-09-11T17:35:50  <gmaxwell> sipa: no, you just choose 'encrypt wallet'.. and that prompts for the password and creates it.
4652018-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
4662018-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)
4672018-09-11T17:36:49  <jnewbery> Those RPCs do fail when no wallet is loaded (eg start with -nowallet)
4682018-09-11T17:37:13  <gmaxwell> Do they even show up in the rpc list when no wallet is loaded?
4692018-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
4702018-09-11T17:37:32  <gmaxwell> I'm convinced. I'd just imagined it another way.
4712018-09-11T17:37:50  *** grubles has joined #bitcoin-core-dev
4722018-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.
4732018-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
4742018-09-11T17:38:47  <andytoshi> or not, those systems can just add an extra "createwallet" RPC call to their scripts
4752018-09-11T17:38:57  * andytoshi stops bikeshedding
4762018-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
4772018-09-11T17:41:17  <jnewbery> Actually, only the wallet 'management' methods are shown: `createwallet`, `loadwallet`, `unloadwallet` and `listwallets`
4782018-09-11T17:41:20  <jnewbery> I think that's ok
4792018-09-11T17:43:44  <wumpus> I think that's fine
4802018-09-11T17:43:54  <wumpus> if the wallet module is not loaded, wallet RPCs don't show up
4812018-09-11T17:44:32  <wumpus> you can't use them so why would they show up
4822018-09-11T17:45:16  <wumpus> just like if you build with --disable-wallet, the wallet options shouldn't show up
4832018-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)
4842018-09-11T17:47:26  <wumpus> (I think that behavior was inherited from running with -disable-wallet option)
4852018-09-11T17:47:48  <wumpus> at run time, not compile time
4862018-09-11T17:47:55  *** unholymachine has quit IRC
4872018-09-11T17:47:57  <sipa> well bitcoind can't prompt for anything
4882018-09-11T17:48:20  <sipa> so either bitcoind or "bitcoin-qt -server" still need to automatically create a wallet
4892018-09-11T17:48:30  <sipa> or they should require configuring one
4902018-09-11T17:48:44  <wumpus> or-pass a password to the creation call
4912018-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)"
4922018-09-11T17:49:02  <wumpus> jnewbery: yes you're right
4932018-09-11T17:49:37  <wumpus> jnewbery: run-time -disablewallet is not really a thing anymore, it just means "0 wallets loaded"
4942018-09-11T17:50:16  <jnewbery> oh, I forgot about that option
4952018-09-11T17:50:22  <wumpus> the user could always decide to load a wallet later
4962018-09-11T17:50:27  <wumpus> or, create one
4972018-09-11T17:50:31  <jnewbery> That would fail with "method not found"
4982018-09-11T17:50:41  <jnewbery> (same as if wallet had not been compiled in)
4992018-09-11T17:50:42  <wumpus> oh it does?
5002018-09-11T17:50:54  <wumpus> I thought that simply meant "load no wallets"
5012018-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"
5022018-09-11T17:51:15  <wumpus> I'm confused as usual
5032018-09-11T17:52:02  <jnewbery> it's confusing because until multiwallet was implemented, -nowallet didn't make sense
5042018-09-11T17:52:54  <wumpus> right
5052018-09-11T17:54:39  <wumpus> I didn't know those things were seperate
5062018-09-11T17:56:00  <wumpus> it makes sense, though
5072018-09-11T17:56:01  <jnewbery> -nowallet is kind of a hidden feature. It's not documented and relies on the automatic `-no<option>` conversion.
5082018-09-11T17:56:33  <wumpus> disablewallet is really "I have no wallet and don't want any to be created either"
5092018-09-11T17:56:41  *** adiabat has joined #bitcoin-core-dev
5102018-09-11T17:56:53  <wumpus> would make sense to document that one, unless it becomes the default :)
5112018-09-11T17:58:10  <wumpus> well... I don't know, you'd still want to load the default wallet by default
5122018-09-11T17:58:16  <wumpus> if it exists
5132018-09-11T17:59:08  <jnewbery> Yes, -disablewallet really does completely disable the wallet component (eg, the RPC methods are not registered). It's documented.
5142018-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.
5152018-09-11T18:00:17  <wumpus> I like that idea, to make creation of the wallet a separate step
5162018-09-11T18:01:10  <jnewbery> Great. Thanks all for the input.
5172018-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
5182018-09-11T18:01:40  *** michaelsdunn1 has joined #bitcoin-core-dev
5192018-09-11T18:04:47  <wumpus> this call might have a lot of optional arguments
5202018-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)
5212018-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
5222018-09-11T18:07:04  <wumpus> absolutely
5232018-09-11T18:08:04  <gmaxwell> 10:48:20 < sipa> so either bitcoind or "bitcoin-qt -server" still need to automatically create a wallet
5242018-09-11T18:08:05  <gmaxwell> please no
5252018-09-11T18:08:23  <gmaxwell> just make the wallet needing rpcs fail until one is created.
5262018-09-11T18:09:24  <wumpus> yes, like -nowallet
5272018-09-11T18:09:43  <jnewbery> yes, that's the plan
5282018-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.
5292018-09-11T18:10:20  <gmaxwell> if not creating by default were a QT only feature, it wouldn't help me at all.
5302018-09-11T18:10:40  <wumpus> agree gmaxwell
5312018-09-11T18:11:03  <jnewbery> sounds like #13926 would also be helpful for you
5322018-09-11T18:11:05  <gribble> https://github.com/bitcoin/bitcoin/issues/13926 | [Tools] bitcoin-wallet-tool by jnewbery · Pull Request #13926 · bitcoin/bitcoin · GitHub
5332018-09-11T18:11:10  <jnewbery> </shill>
5342018-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
5352018-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.
5362018-09-11T18:12:19  <jnewbery> oh, I can't help you with that
5372018-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. :)
5382018-09-11T18:12:52  <wumpus> you mean, yank a key from the keypool without marking it as used?
5392018-09-11T18:13:16  <wumpus> right
5402018-09-11T18:13:27  <gmaxwell> I could have gotten keys out from a plaintext dump, unfortunately. So 'used' isn't sufficient.
5412018-09-11T18:14:13  *** Chris_Stewart_5 has quit IRC
5422018-09-11T18:17:59  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5432018-09-11T18:19:38  *** owowo has quit IRC
5442018-09-11T18:24:52  *** owowo has joined #bitcoin-core-dev
5452018-09-11T18:34:43  *** dqx has joined #bitcoin-core-dev
5462018-09-11T18:42:20  *** Krellan has joined #bitcoin-core-dev
5472018-09-11T19:01:55  *** SopaXorzTaker has quit IRC
5482018-09-11T19:05:34  *** miknotauro has quit IRC
5492018-09-11T19:09:55  *** grubles has quit IRC
5502018-09-11T19:12:02  *** promag has joined #bitcoin-core-dev
5512018-09-11T19:12:03  <phantomcircuit> gmaxwell, yeah i too have a bajillion wallets
5522018-09-11T19:12:11  <phantomcircuit> 99.9999% of which have never been used
5532018-09-11T19:12:46  *** Dizzle has left #bitcoin-core-dev
5542018-09-11T19:16:42  *** Krellan has quit IRC
5552018-09-11T19:27:24  *** Krellan has joined #bitcoin-core-dev
5562018-09-11T19:27:50  *** jarthur has quit IRC
5572018-09-11T19:31:03  *** Chris_Stewart_5 has quit IRC
5582018-09-11T19:39:32  *** lnostdal has quit IRC
5592018-09-11T19:39:38  <phantomcircuit> MarcoFalke, updated #14147 to fix that issue and some of the style violations
5602018-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
5612018-09-11T19:41:50  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5622018-09-11T19:43:04  *** promag has quit IRC
5632018-09-11T19:51:46  *** lnostdal has joined #bitcoin-core-dev
5642018-09-11T20:01:31  *** phwalkr has joined #bitcoin-core-dev
5652018-09-11T20:05:02  *** phwalkr has quit IRC
5662018-09-11T20:06:07  *** jarthur has joined #bitcoin-core-dev
5672018-09-11T20:07:19  *** grubles has joined #bitcoin-core-dev
5682018-09-11T20:17:02  *** farmerwampum_ has joined #bitcoin-core-dev
5692018-09-11T20:18:38  *** farmerwampum has quit IRC
5702018-09-11T20:18:38  *** farmerwampum_ is now known as farmerwampum
5712018-09-11T20:22:11  <MarcoFalke> phantomcircuit: thx looks good now
5722018-09-11T20:24:07  *** grubles has quit IRC
5732018-09-11T20:24:58  *** grubles has joined #bitcoin-core-dev
5742018-09-11T20:29:50  *** promag has joined #bitcoin-core-dev
5752018-09-11T20:39:19  *** molz has quit IRC
5762018-09-11T20:44:34  *** Chris_Stewart_5 has quit IRC
5772018-09-11T20:54:09  <ken2812221> MarcoFalke: Is #14007 ready for merge or it needs more ACK?
5782018-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
5792018-09-11T20:55:09  <MarcoFalke> Id like to have someon else review the test changes as well
5802018-09-11T21:01:16  <ken2812221> Fine. But it seems bitcoinack shows 0 ack on that PR. It has 2 ack for sure.
5812018-09-11T21:06:32  <wumpus> it is a bit fiddly with spelling of acks sometimes
5822018-09-11T21:08:19  *** morcos has quit IRC
5832018-09-11T21:08:41  *** morcos has joined #bitcoin-core-dev
5842018-09-11T21:17:52  <phantomcircuit> can i use #define for poll / select er selection?
5852018-09-11T21:19:15  *** Victorsueca has quit IRC
5862018-09-11T21:20:15  <gmaxwell> I would expect you to have a define and a configure thing that detects the availablity of poll.
5872018-09-11T21:20:29  *** Victorsueca has joined #bitcoin-core-dev
5882018-09-11T21:20:33  <gmaxwell> ideally copied out of some other project that does both and has been around for a long time.
5892018-09-11T21:21:07  <gmaxwell> maybe squid cache
5902018-09-11T21:24:00  <phantomcircuit> gmaxwell, it's kind of awkward cause i want that... but not on windows
5912018-09-11T21:42:55  *** morcos has quit IRC
5922018-09-11T21:43:29  *** sipa has quit IRC
5932018-09-11T21:44:46  *** Chris_Stewart_5 has joined #bitcoin-core-dev
5942018-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.
5952018-09-11T21:45:17  *** sipa has joined #bitcoin-core-dev
5962018-09-11T21:45:20  <jarthur> https://github.com/libevent/libevent/blob/29cc8386a2f7911eaa9336692a2c5544d8b4734f/event.c#L77
5972018-09-11T21:50:44  *** morcos has joined #bitcoin-core-dev
5982018-09-11T22:01:41  *** belcher has quit IRC
5992018-09-11T22:05:35  *** phwalkr has joined #bitcoin-core-dev
6002018-09-11T22:07:41  <phantomcircuit> jarthur, good info
6012018-09-11T22:08:02  *** ppaqmj has quit IRC
6022018-09-11T22:09:47  <phantomcircuit> right now i have have an #ifndef WIN32 #define HAVE_POLL
6032018-09-11T22:09:56  <phantomcircuit> but that's obviously not exactly right..
6042018-09-11T22:10:14  *** phwalkr has quit IRC
6052018-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
6062018-09-11T22:17:02  *** michaelsdunn1 has quit IRC
6072018-09-11T22:18:42  *** jarthur has quit IRC
6082018-09-11T22:40:52  *** justanotheruser has joined #bitcoin-core-dev
6092018-09-11T22:49:19  *** unholymachine has joined #bitcoin-core-dev
6102018-09-11T23:07:55  *** grubles has quit IRC
6112018-09-11T23:12:24  *** Guyver2 has quit IRC
6122018-09-11T23:12:36  *** itaseski has quit IRC
6132018-09-11T23:14:04  *** Victorsueca has quit IRC
6142018-09-11T23:14:59  *** phwalkr has joined #bitcoin-core-dev
6152018-09-11T23:15:24  *** Victorsueca has joined #bitcoin-core-dev
6162018-09-11T23:15:27  *** phwalkr has quit IRC
6172018-09-11T23:31:42  *** promag has quit IRC
6182018-09-11T23:42:06  *** AaronvanW has quit IRC