--- Day changed Tue Dec 04 2018
03:22 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 256 seconds]     
04:35 <@provoostenator> Added "signerdisplayaddress [address]". Only supports bech32 and the code ain't pretty, but can be improved later using inferred descriptors. I also tweaked hwi.py displayaddress to work with a descriptor.
04:36 <@provoostenator> My Trezor T display starts flickering and become less or unrepsonsive  if I use hwi.py multiple times to display an address. Perhaps it's not cleaning up the connection properly? (based on #66)
07:33 < achow101> please review https://github.com/achow101/HWI/pull/69 now that 66 has been merged
08:17 <@provoostenator> walletprocesspsbt now automatically calls the signer. Rather hideous code for now, but will push shortly.
08:18 <@provoostenator> It would be nice if hwi.py could infer testnet and the fingerprint directly from a PSBT. I couldn't wrap my head around the serialaztion magic required for that.
08:37 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined ##hwi     
08:38 < achow101> psbt doesn't specify network
08:38 < achow101> the network really doesn't matter when it comes to signing
08:47 <@provoostenator> The device does care though, because it has to select the right app / coin to sign.
08:47 <@provoostenator> The network can be inferred from the BIP32 path coin type.
08:48 <@provoostenator> By the way, what is Core adding to the base64 encoding here? CDataStream ssTx(SER_NETWORK, PROTOCOL_VERSION)
08:49 <@provoostenator> It adds that to the psbt before encoding as
08:57 < achow101> the network is not guaranteed to be inferred from the bip32 path
08:57 < achow101> i would not recommend using that to determine the network
08:58 < achow101> CDataStream doesn't add anything extra to the encoding afaik
08:58 <@provoostenator> We can always keep an optional --cointype ish parameter.
08:59 < achow101> i strongly dislike inferring things that are not guaranteed or explicit
09:00 < achow101> provoostenator: in what cases does the device need to know the network? in my testing, none have cared
09:01 <@sipa> i guess they need to know the network type to show addresses?
09:01 <@provoostenator> Trezor T will complain if it's told something is mainnet but the derivivation coin type is 1
09:01 < achow101> sipa: i suppose so
09:01 < achow101> provoostenator: that's just stupid
09:02 <@provoostenator> I also remember Ledger Nano S silently failing if you try to use the Testnet app for a Mainnet transaction, but not sure if that also applies to HWI.
09:02 <@provoostenator> I think it's a sane safety feature.
09:03 <@provoostenator> They have to keep parts of the HD tree seperated so shitcoin apps don't mess with Bitcoin keys.
09:05 < achow101> if you want to set the network, i think the way to do that is really through a command line option, not inferring from the data passed in
09:05 < achow101> unless it is something that is explicit and guaranteed when passed in, like a descriptor with tpub in it
09:10 <@provoostenator> I'm fine with a command line option, especially if the default is Bitcoin. Question is, what is a universal way to say "testnet"?
09:11 <@provoostenator> My guess is probably the coin types from BIP43 (defined in a SLIP)
09:11 < achow101> --tesetnet
09:12 < achow101> *--testnet
09:12 < achow101> i don't think there is a universal way to signal testnet in derivation paths
09:12 < achow101> core uses the same paths regardless
09:13 <@provoostenator> BIP43 uses coin type 0 for mainnet, 1 for testnet (all coins)
09:13 <@provoostenator> So maybe testnet really is a special case
09:14 <@provoostenator> Using the same keys is bad though. It makes sense for a seed generated by Core because every wallet has a unique seed. But when pulling from an external source we should be more careful.
09:22 <@provoostenator> Full bitcoin-cli workflow now "works": https://github.com/achow101/bitcoin/pull/2
09:23 <@provoostenator> Now we just need to flesh out the API a bit better, e.g. probably less inferring, more explicit params (see above).
09:23 <@provoostenator> And I need to clean up the code :-)
09:27 <@provoostenator> I would like the hwi.py API to be trivially mappable onto a gRPC service, for maximum flexibility, e.g. a JSON API or even protobufs. For Bitcoin Core we can simply stick to the command line interface.
09:28 <@provoostenator> The command outputs already are, since they're mostly just JSON objects.
09:28 <@provoostenator> For inputs we could make all arguments named. Although that's slightly annoying in practice if you use the commandline directly.
09:28 <@provoostenator> https://grpc.io/docs/guides/concepts.html#service-definition
09:30 <@provoostenator> (only the Unary RPC bit is relevant)
09:31 < achow101> we could make a grpc wrapper
09:32 <@provoostenator> Sadly I can't find a gRPC to command-line utility tool, but I guess we can make that ourselves.
09:32 < achow101> hwi.py is basically a wrapper already
09:33 <@provoostenator> I would imagine hwi.py could be called a standalone utility with individual commands, but also with --grpc which launches a server
09:35 <@provoostenator> So "./hwi.py enumerate"  is the same as "./hwi.py --grpc" + "curl ..../enumerate.json"
09:35 < achow101> again, i would prefer for that to be a separate script
09:35 <@sipa> what does hwi use grpc for?
09:36 <@provoostenator> @sipa currently it doesn't
09:36 -!- mode/##hwi [+o achow101] by sipa     
09:36 <@sipa> then why would it?
09:36 <@achow101> all the things that hwi.py does are in hwilib/commands.py anyways
09:36 <@provoostenator> I would just like to design thing with gRPC in mind, but I'm not saying we should implement it now.
09:38 <@provoostenator> It's nice if HWI works for multiple wallets, and conversely, Bitcoin Core can call alternatives to HWI. That's what I'm trying to standardize.
09:45 <@provoostenator> achow101 something like hwi-rpc.py? I wonder if you can cleanly map RPC arguments to ArgumentParser? Otherwise we'd have to abstract commands.py a little bit.
10:01 <@achow101> provoostenator: you can call the functions directly
10:03 <@achow101> process_commands takes an array of arguments, so you should also be able to map the arguments to the correct command line args to use
17:21 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
17:24 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined ##hwi