--- Log opened Tue Sep 11 00:00:05 2018 00:00 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Remote host closed the connection] 00:02 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 00:10 < 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? 00:11 < wumpus> I haven't, sounds like a cool idea though 00:11 < 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. 00:11 < wumpus> moving to less layers of containers means less moving parts and hopefully more reliability 00:12 < wumpus> great ! 00:13 < 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. 00:16 -!- brianhoffman_ [~brianhoff@pool-71-163-147-195.washdc.fios.verizon.net] has joined #bitcoin-core-dev 00:17 -!- brianhoffman [~brianhoff@pool-108-31-201-103.washdc.fios.verizon.net] has quit [Ping timeout: 240 seconds] 00:17 -!- brianhoffman_ is now known as brianhoffman 00:20 < 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 00:23 < warren> fanquake: what does "date -u" return on macos? 00:23 < fanquake> warren Tue 11 Sep 2018 07:23:21 UTC 00:23 < warren> fanquake: date +%s ? 00:24 < fanquake> warren 1536650642 00:24 < warren> k th 00:24 < wumpus> fanquake: I suppose that also depends on the locale? 00:26 < 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. 00:26 < wumpus> timezone, yes, but I mean the YYYY/MM/DD ordering still might be locale dependent 00:26 < wumpus> or the language of the months 00:27 < 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" 00:28 < 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. 00:29 < fanquake> macs seem to be pretty bad all over for locale dependance issues. Have seen them before with sed as well. 00:30 < wumpus> shell script is a bad language if you want locale independence, or even architecture independence 00:30 < wumpus> it relies on so many external exectubles 00:31 -!- cisba [d41fee72@gateway/web/freenode/ip.212.31.238.114] has quit [Ping timeout: 252 seconds] 00:34 < fanquake> wumpus Are you proposing re-writing Core in Rust at Core-Dev? 00:35 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 00:35 < wumpus> noooooo :) 00:35 < mryandao> isnt blue matt already working on one? 00:36 < dongcarl> mryandao: rust-bitcoin isn't a rewrite yet, and BlueMatt isn't the only developer 00:36 < mryandao> my apologies for inappropriate attribution :( 00:37 < 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 00:37 < wumpus> (it could be used as part of a node implementation of course) 00:37 < warren> fanquake: locale in unix terms is more language than timezone which is a different name 00:37 < kallewoof> I very recently discovered it, following andrew poelstra's github trace, actually. he seems to be very active! 00:38 < mryandao> anyone balsy enough to run parity-bitcoin? 00:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds] 00:40 < fanquake> warren thanks 00:40 < dongcarl> wumpus and I talked about perhaps writing a standalone P2P bitcoin server in Rust that can FFI with bitcoind 00:42 < dongcarl> The main benefit being memory safety, and zero-cost abstractions for managing all the connections 00:42 < wumpus> right, bitcoind as 'consensus engine' with the network-facing parts in rust 00:42 < warren> YES!!! 00:42 < mryandao> any chance for a libconsensus rewrite in rust? 00:43 < wumpus> mryandao: that's a very bad idea 00:43 < dongcarl> I don't think everything needs to be rewritten in Rust 00:43 < dongcarl> libconsensus should be in C 00:43 < dongcarl> as FFI to C is well-implemented for almost all languages 00:43 < wumpus> the whole point is that rewriting the consensus code in differnet language 00:43 < wumpus> is EXTREMELY DANGEROUS 00:43 < wumpus> and has a very high fork risk 00:43 < fanquake> ^ 00:43 < warren> mryandao: Good idea only if you can faithfully reproduce all bugs, even unknown bugs 00:43 < wumpus> don't do this 00:44 < wumpus> all the non-concensus parts are fair game though 00:44 < warren> +1 00:45 < mryandao> sorry, i just couldnt resist when i hear re-write 00:45 < mryandao> kek 00:45 < 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. 00:45 < 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 00:45 < wumpus> mryandao: sarcasm doesn't travel well over IRC, sorry 00:46 < wumpus> exactly, what warren says, you'd not be the first to propose it's seriously 00:46 < dongcarl> I believe that it would be wise to revisit libconsensus, as I know that most PRs related to it have become stale 00:47 < mryandao> what if a future C++ compiler tweaks the behavior of libconsensus though 00:47 < warren> Yes it would be really nice to be able to use most of bitcoin core as libraries in other projects. 00:47 < mryandao> could happen? 00:47 < dongcarl> revisit as in see if the API need changes, and organize an effort to actually get it done 00:47 < warren> It sucks that that drags in libstdc++ as a dependency 00:47 < 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 00:48 < wumpus> warren: at least that tends to be installed everywhere, I'd say boost is much worse 00:49 < fanquake> dongcarl, are you going to Tokyo? Maybe add that to the list of discussion topics? 00:49 < dongcarl> fanquake: Yes, I was proposing that in IRC yesterday. 00:49 < 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. 00:49 < 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 00:49 < dongcarl> fanquake: where do I add to the list? 00:49 < fanquake> dongcarl, ah sorry 00:49 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 00:49 < fanquake> I think the easiest way is to email the organisers. They are maintaining a list of proposed topics. 00:50 < wumpus> mryandao: these are not exactly new concerns FWIW 00:51 < fanquake> At least good progress has been made over the last 3-4 years continually dropping dependencies. 00:51 < wumpus> yes 00:51 < 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 00:51 < fanquake> I saw soneone talking (again) about fulling ridding the codebase of OpenSSL a few days ago. 00:51 < wumpus> I think the current situation where OpenSSL is only used for randomness is ok 00:52 < 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. 00:52 < warren> wumpus: huh, thought folks here wrote a replacement for that too years ago? 00:52 < warren> maybe they don't trust themselves 00:53 < 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) 00:53 < wumpus> warren: yes, but it's hard to get enough confidence in it imo 00:54 < warren> ah, I hadn't heard an update on that for a while. 00:54 < 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 00:56 < fanquake> There has been #5885 and #10299 00:56 < 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 00:56 < gribble> https://github.com/bitcoin/bitcoin/issues/10299 | Remove OpenSSL by sipa · Pull Request #10299 · bitcoin/bitcoin · GitHub 00:56 < warren> My handler says to just rely on the hardware RNG directly without mixing other entropy. There's a new kernel option for that. 00:56 < wumpus> thanks, yes what fanquake says, the code is there if someone wants to pick it up 00:57 < wumpus> warren: HAH 00:57 < dongcarl> wumpus: pick it up as in rebase it? 00:57 < wumpus> proprietary, secret sauce random, with no-backdoor guarantee! 00:58 < fanquake> warren maybe you can write us something like BIP42 for that 00:58 < wumpus> dongcarl: rebasing would be the first step, I'm not sure what other work is involved 00:58 < 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. 01:01 < wumpus> you can't remove it from the depends system as long as qt still relies on it for the payment request shit 01:02 < dongcarl> Looks like provoostenator tried working on it in his branches? 01:02 < wumpus> (which I was trying to depecrate, just when bitpay got the *genius* idea to require it) 01:03 < wumpus> #11622 01:03 < gribble> https://github.com/bitcoin/bitcoin/issues/11622 | build: Add --disable-bip70 configure option by laanwj · Pull Request #11622 · bitcoin/bitcoin · GitHub 01:03 < wumpus> of all the PRs I tried to do and didn't go through, I think that one hurt the most 01:04 < fanquake> :'( 01:04 < dongcarl> ooof... 01:07 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev 01:08 < 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 01:08 < wumpus> but for now, it's realistic to drop the dependency of bitcoind on openssl, but not the bitcoin-qt one 01:09 < wumpus> (in -qt it's used in *two* ways, directly to validate the payment messages, and indirectly through qt to fetch https:// URLs) 01:09 * dongcarl facepalm 01:09 -!- setpill [~setpill@unaffiliated/setpill] has quit [Client Quit] 01:10 < 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 01:11 < wumpus> warren: I think most scenarios that care about dependencies (e.g., on servers) already don't involve building the GUI 01:11 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev 01:11 < wumpus> so dropping the direct dependency for randomness will help most, there 01:13 < 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 01:13 < dongcarl> From https://github.com/bitcoin/bitcoin/pull/10299#issuecomment-298785082 it seems like sipa was going to "propose some other RNG changes first" 01:13 < dongcarl> Did that end up happening? 01:13 < wumpus> no, sipa kind of dropped the project to persue other things (this was talked about at last meeting AFAIK) 01:13 < dongcarl> pinging fanquake, keeper of the PRs, adder of the labels 01:14 -!- ylbam [uid99779@gateway/web/irccloud.com/x-escjocgrnoajznba] has joined #bitcoin-core-dev 01:14 < dongcarl> I see 01:15 < dongcarl> wumpus: are there other dependencies that could be dropped that aren't yet? 01:16 < wumpus> https://github.com/bitcoin/bitcoin/projects/3 01:16 < warren> We will be able to drop boost entirely at some point? 01:17 < fanquake> Eventually, yes, I think it's possible. Cory has various work in process to rid out the "harder" to replace Boost. 01:17 < fanquake> *rip 01:17 < 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. 01:18 < wumpus> the toughest hurdle is the multi-index strcuture used in mempool 01:18 < fanquake> However I have been overly optimistic about removing Boost in the past, hah. https://github.com/bitcoin/bitcoin/issues/8875#issuecomment-280325296 01:19 < 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 01:19 < wumpus> the other things are more or less straightforward work, although some have to wait for a future c++ standard (like filesystem) 01:19 < 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. 01:20 < fanquake> Also have to pull in that c++14 requirement :p 01:20 < wumpus> I agree, it's better to do such things early-on in the cycle 01:21 < wumpus> also want to get the windows unicode patches in asap, the more time is left for noticing problems with them 01:25 < dongcarl> wumpus: what is the multi-index structure? a collection that can be indexed into by multiple types or have multiple indices, or both? 01:26 < fanquake> dongcarl https://www.boost.org/doc/libs/1_68_0/libs/multi_index/doc/index.html 01:27 < wumpus> dongcarl: multiple indices, like an sql database: https://github.com/bitcoin/bitcoin/blob/master/src/txmempool.h#L461 01:27 < fanquake> wumpus I think #14184 can go in. Unrelated, but I seem to have been getting some bad Qt mirrors lately, really slow downloads. 01:27 < gribble> https://github.com/bitcoin/bitcoin/issues/14184 | Scripts and tools: increased timeout downloading by cisba · Pull Request #14184 · bitcoin/bitcoin · GitHub 01:28 < wumpus> fanquake: yes, why not 01:30 < dongcarl> gh down for anyone else? 01:30 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Ping timeout: 244 seconds] 01:30 < wumpus> works for me 01:31 -!- brianhoffman [~brianhoff@pool-71-163-147-195.washdc.fios.verizon.net] has quit [Ping timeout: 272 seconds] 01:34 -!- brianhoffman [~brianhoff@pool-71-163-147-195.washdc.fios.verizon.net] has joined #bitcoin-core-dev 01:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 01:38 < kallewoof> works for me as well 01:39 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-core-dev 01:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 264 seconds] 01:44 -!- phwalkr [~phwalkr@210-84-32-251.dyn.iinet.net.au] has joined #bitcoin-core-dev 01:52 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 2.0] 01:56 -!- phwalkr [~phwalkr@210-84-32-251.dyn.iinet.net.au] has quit [Remote host closed the connection] 02:04 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Remote host closed the connection] 02:07 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev 02:13 -!- Rootsudo [rootsudo@gateway/vpn/privateinternetaccess/rootsudo] has quit [Ping timeout: 245 seconds] 02:16 -!- phwalkr [~phwalkr@210-84-32-251.dyn.iinet.net.au] has joined #bitcoin-core-dev 02:24 -!- phwalkr [~phwalkr@210-84-32-251.dyn.iinet.net.au] has quit [Remote host closed the connection] 02:25 -!- setpill [~setpill@unaffiliated/setpill] has quit [Ping timeout: 252 seconds] 02:25 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev 02:28 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [] 02:30 -!- setpill [~setpill@unaffiliated/setpill] has quit [Ping timeout: 240 seconds] 02:31 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev 02:36 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 02:41 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds] 02:43 < wumpus> rc3 binaries up https://bitcoincore.org/bin/bitcoin-core-0.17.0/test.rc3/ 02:59 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev 03:02 -!- phwalkr [~phwalkr@210-84-32-251.dyn.iinet.net.au] has joined #bitcoin-core-dev 03:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:06 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 03:15 -!- unholymachine [~quassel@2601:8c:c003:9f16:c85d:56a3:bb17:3855] has joined #bitcoin-core-dev 03:16 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 03:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds] 03:39 < wumpus> github is sluggish here as well now 03:39 < wumpus> at least the website 03:40 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 03:40 < wumpus> https://github.com/zw/bitcoin-gh-meta stopped updating? 03:42 -!- spinza [~spin@155.93.246.187] has quit [Quit: Coyote finally caught up with me...] 03:42 -!- belcher [~belcher@unaffiliated/belcher] has quit [Read error: Connection reset by peer] 03:42 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 03:42 -!- belcher [~belcher@unaffiliated/belcher] has quit [Remote host closed the connection] 03:43 -!- ylbam [uid99779@gateway/web/irccloud.com/x-escjocgrnoajznba] has quit [Quit: Connection closed for inactivity] 03:44 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 03:46 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 03:48 < wumpus> ok contacted iwilcox, they're not on IRC but managed to find an email 03:54 -!- spinza [~spin@155.93.246.187] has joined #bitcoin-core-dev 03:54 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 03:55 -!- phwalkr [~phwalkr@210-84-32-251.dyn.iinet.net.au] has quit [Remote host closed the connection] 03:57 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev 03:59 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 04:15 -!- setpill [~setpill@unaffiliated/setpill] has quit [Ping timeout: 252 seconds] 04:16 < echeveria> gentle reminder that it's all on github archive as well. 04:17 -!- setpill [~setpill@unaffiliated/setpill] has joined #bitcoin-core-dev 04:24 < 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 04:26 -!- Aaronvan_ is now known as AaronvanW 04:26 < wumpus> echeveria: do you know how to request issue/PR metadata from a specific project from it? 04:28 < 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 04:37 -!- queip [~queip@unaffiliated/rezurus] has joined #bitcoin-core-dev 04:44 < echeveria> wumpus: you can grep the data from it if needed, it's just blobs of JSON data straight from the firehose. 04:44 < echeveria> same place the other mirror came from actually. 04:59 < wumpus> github is completely AWOL here 05:01 -!- Krellan [~Krellan@2601:640:4000:9258:cd59:fa78:494:77ae] has quit [Read error: Connection reset by peer] 05:02 -!- Krellan [~Krellan@2601:640:4000:9258:cd59:fa78:494:77ae] has joined #bitcoin-core-dev 05:03 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has quit [Remote host closed the connection] 05:16 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds] 05:23 -!- setpill [~setpill@unaffiliated/setpill] has quit [Quit: o/] 05:37 -!- drexl [~drexl@cpc130676-camd16-2-0-cust445.know.cable.virginm.net] has joined #bitcoin-core-dev 05:38 -!- timothy [~tredaelli@redhat/timothy] has joined #bitcoin-core-dev 05:40 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev 05:41 -!- RubenSomsen [uid301948@gateway/web/irccloud.com/x-lbkisxrhbjmgcsff] has quit [Quit: Connection closed for inactivity] 05:51 -!- Kvaciral [~Kvaciral@5ED6B9A2.cm-7-7c.dynamic.ziggo.nl] has joined #bitcoin-core-dev 05:51 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 05:52 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 05:53 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev 06:06 -!- DougieBot5000_ is now known as DougieBot5000 06:20 -!- EucOcVrFfr2D [~smuxi@193.37.252.100] has joined #bitcoin-core-dev 06:21 -!- WudsyWudsyWudsy [~Woodsy@1.143.89.30] has joined #bitcoin-core-dev 06:23 < 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. 06:24 -!- WudsyWudsyWudsy [~Woodsy@1.143.89.30] has left #bitcoin-core-dev [] 06:25 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 06:30 < EucOcVrFfr2D> I'm asking because i can't wrap my head around the correctness of the test in the PSBT (rpc_psbt.json) 06:32 < EucOcVrFfr2D> Oh i might just have fund the answer myself 06:34 < 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] 06:36 < EucOcVrFfr2D> Now, HASH160(redeemScript) != 0fb9463421696b82c833af241c78c17ddbde4934 , but interestingly if i change the OP_CHECKMULTISIGVERIFY into OP_CHECKMULTISIG ... the hash is correct! 06:40 < 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 06:45 < EucOcVrFfr2D> It's still a bit confusing why bitcoind does not fail when calling 'walletprocesspsbt' with such an ill-formed PartiallySignedInput. 06:45 < EucOcVrFfr2D> /fin 06:47 < EucOcVrFfr2D> any clue/help/feedback/comment highly appreciated :) 06:47 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Quit: Leaving] 07:01 < achow101> EucOcVrFfr2D: the not failing is to aid with a future RPC analyzepsbt which tells you what is wrong with your psbt 07:01 -!- adiabat [~adiabat@63.209.32.102] has quit [Ping timeout: 244 seconds] 07:02 < EucOcVrFfr2D> achow101: Oh good to know! 07:05 -!- dqx [~dqx@unaffiliated/dqx] has quit [Ping timeout: 252 seconds] 07:09 < 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 07:19 -!- phwalkr [~phwalkr@210-84-32-251.dyn.iinet.net.au] has joined #bitcoin-core-dev 07:23 -!- EucOcVrFfr2D [~smuxi@193.37.252.100] has quit [Ping timeout: 252 seconds] 07:27 -!- grafcaps [~haroldbr@75.114.234.144] has joined #bitcoin-core-dev 07:31 -!- itaseski [~itaseski@213.135.178.20] has joined #bitcoin-core-dev 07:32 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Quit: Textual IRC Client: www.textualapp.com] 07:41 < BlueMatt> wumpus: there's a helluvalot more in rust-bitcoin than just primitives, but, ok, it *includes* primitives :p 07:45 -!- grafcaps [~haroldbr@75.114.234.144] has quit [Read error: Connection reset by peer] 07:45 -!- YSqTU2XbB [~smuxi@93-39-70-146.ip74.fastwebnet.it] has joined #bitcoin-core-dev 07:48 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-core-dev 07:49 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has quit [Client Quit] 07:58 -!- grubles [~grubles@gateway/tor-sasl/grubles] has joined #bitcoin-core-dev 08:04 -!- jhfrontz [~Adium@S010664777dad4333.cc.shawcable.net] has joined #bitcoin-core-dev 08:05 -!- miknotauro [~miknotaur@187.207.79.62] has quit [Ping timeout: 246 seconds] 08:06 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection] 08:07 -!- copumpkin [~copumpkin@haskell/developer/copumpkin] has joined #bitcoin-core-dev 08:07 -!- YSqTU2XbB [~smuxi@93-39-70-146.ip74.fastwebnet.it] has quit [Ping timeout: 252 seconds] 08:16 < wumpus> BlueMatt: yes 'building blocks', I didn't mean 'primitives' in any insulting sense 08:16 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 08:17 < wumpus> I just meant it's not intended to be a self-contained node implementation but as a library to use from other software 08:17 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 08:31 -!- harrymm [~harrymm@69.161.195.103] has quit [Ping timeout: 252 seconds] 08:44 -!- grubles [~grubles@gateway/tor-sasl/grubles] has quit [Ping timeout: 256 seconds] 08:49 -!- harrymm [~harrymm@49.48.44.246] has joined #bitcoin-core-dev 08:57 -!- jarthur [~jarthur@207.114.244.5] has joined #bitcoin-core-dev 08:57 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev 09:03 -!- phwalkr [~phwalkr@210-84-32-251.dyn.iinet.net.au] has quit [Ping timeout: 240 seconds] 09:08 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev 09:11 -!- miknotauro [~miknotaur@187.207.79.62] has joined #bitcoin-core-dev 09:21 -!- Krellan [~Krellan@2601:640:4000:9258:cd59:fa78:494:77ae] has quit [Read error: Connection reset by peer] 09:21 -!- Krellan [~Krellan@2601:640:4000:9258:cd59:fa78:494:77ae] has joined #bitcoin-core-dev 09:27 -!- promag [~promag@83.223.251.80] has joined #bitcoin-core-dev 09:58 -!- promag [~promag@83.223.251.80] has quit [Remote host closed the connection] 10:07 -!- Krellan [~Krellan@2601:640:4000:9258:cd59:fa78:494:77ae] has quit [Remote host closed the connection] 10:20 -!- jhfrontz [~Adium@S010664777dad4333.cc.shawcable.net] has quit [Quit: Leaving.] 10:27 -!- timothy [~tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!] 10:30 < 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. 10:30 < gribble> https://github.com/bitcoin/bitcoin/issues/13059 | Dynamic wallet load / create / unload · Issue #13059 · bitcoin/bitcoin · GitHub 10:31 < 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. 10:32 < sipa> jnewbery: that sounds great to me 10:32 < jnewbery> creating the wallet at run time instead of startup allows the user to specify wallet features like disableprivatekeys (#9662) and avoidreuse (#13756) 10:32 < 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 10:32 < gribble> https://github.com/bitcoin/bitcoin/issues/13756 | wallet: -avoidreuse feature for improved privacy by kallewoof · Pull Request #13756 · bitcoin/bitcoin · GitHub 10:33 < 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. 10:33 < jnewbery> I think that #13100 is really the last piece in the puzzle before we can actually do this 10:33 < gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add dynamic wallets support by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub 10:33 < 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. 10:34 < gmaxwell> jnewbery: 'promt to create' -- why prompt? 10:35 < sipa> gmaxwell: if you want it born encrypted you at least need to prompt for a password 10:35 < sipa> but it could also prompt for things like do you have a hw wallet you want integrated 10:35 < jnewbery> gmaxwell: I guess maybe that's the wrong wording. The user would need to create a wallet before doing any wallet activities 10:35 < gmaxwell> sipa: no, you just choose 'encrypt wallet'.. and that prompts for the password and creates it. 10:35 < 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 10:36 < 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) 10:36 < jnewbery> Those RPCs do fail when no wallet is loaded (eg start with -nowallet) 10:37 < gmaxwell> Do they even show up in the rpc list when no wallet is loaded? 10:37 < 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 10:37 < gmaxwell> I'm convinced. I'd just imagined it another way. 10:37 -!- grubles [~grubles@gateway/tor-sasl/grubles] has joined #bitcoin-core-dev 10:38 < gmaxwell> As soon as you want to use the oppturnity to take more settings then obviously you need to run an explicit create command. 10:38 < 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 10:38 < andytoshi> or not, those systems can just add an extra "createwallet" RPC call to their scripts 10:38 * andytoshi stops bikeshedding 10:40 < 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 10:41 < jnewbery> Actually, only the wallet 'management' methods are shown: `createwallet`, `loadwallet`, `unloadwallet` and `listwallets` 10:41 < jnewbery> I think that's ok 10:43 < wumpus> I think that's fine 10:43 < wumpus> if the wallet module is not loaded, wallet RPCs don't show up 10:44 < wumpus> you can't use them so why would they show up 10:45 < wumpus> just like if you build with --disable-wallet, the wallet options shouldn't show up 10:46 < 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) 10:47 < wumpus> (I think that behavior was inherited from running with -disable-wallet option) 10:47 < wumpus> at run time, not compile time 10:47 -!- unholymachine [~quassel@2601:8c:c003:9f16:c85d:56a3:bb17:3855] has quit [Read error: Connection reset by peer] 10:47 < sipa> well bitcoind can't prompt for anything 10:48 < sipa> so either bitcoind or "bitcoin-qt -server" still need to automatically create a wallet 10:48 < sipa> or they should require configuring one 10:48 < wumpus> or-pass a password to the creation call 10:48 < 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)" 10:49 < wumpus> jnewbery: yes you're right 10:49 < wumpus> jnewbery: run-time -disablewallet is not really a thing anymore, it just means "0 wallets loaded" 10:50 < jnewbery> oh, I forgot about that option 10:50 < wumpus> the user could always decide to load a wallet later 10:50 < wumpus> or, create one 10:50 < jnewbery> That would fail with "method not found" 10:50 < jnewbery> (same as if wallet had not been compiled in) 10:50 < wumpus> oh it does? 10:50 < wumpus> I thought that simply meant "load no wallets" 10:51 < jnewbery> yes - -disablewallet means "run without the wallet component" -nowallet means "run with the wallet component but no wallet loaded at startup" 10:51 < wumpus> I'm confused as usual 10:52 < jnewbery> it's confusing because until multiwallet was implemented, -nowallet didn't make sense 10:52 < wumpus> right 10:54 < wumpus> I didn't know those things were seperate 10:56 < wumpus> it makes sense, though 10:56 < jnewbery> -nowallet is kind of a hidden feature. It's not documented and relies on the automatic `-no