< luke-jr> spudI think you'll get arguments for using pb at all
< cfields> wumpus: considering there's already an 0.14.1rc1, I'd prefer not to sign the binaries with incorrect version
< cfields> i'd say just go ahead with release without signature
< bitcoin-git> [bitcoin] jimmysong opened pull request #10515: [test] Add test for getchaintxstats (master...test_getchaintxstats) https://github.com/bitcoin/bitcoin/pull/10515
< achow101> does anyone know if the waitforblock/waitfornewblock RPCs are used or will be used sometime in the future?
< achow101> The PR that adds them says that they are for testing and travis, but I don't see anything which actually uses those commands.
< achow101> cfields: ^^^ (you're the one who added them)
< bitcoin-git> [bitcoin] luke-jr opened pull request #10516: Backports for 0.14.2 (0.14...0.14.2_fixes) https://github.com/bitcoin/bitcoin/pull/10516
< bitcoin-git> [bitcoin] jonasschnelli opened pull request #10517: Factor out CCoinsView based AreInputsStandard/IsWitnessStandard (master...2017/06/policy_compile) https://github.com/bitcoin/bitcoin/pull/10517
< spudowiar> luke-jr: I meant changing the use of Protocol Buffers in Payment Requests
< phantomcircuit> spudowiar, the payments protocol stuff is basically just broken
< spudowiar> I was just suggesting switching from Google Protocol Buffers to nanopb, because nanopb generates nicer code
< spudowiar> (It's a protoc plugin)
< jonasschnelli> spudowiar: is nanopb a dropin replacement for protoc?
< spudowiar> jonasschnelli: It's a plugin for protoc. It generates different code but nicer code. It's primarily designed for C and microcontrollers though so it might not be that good a fit. Something to take a look at though.
< jonasschnelli> Thanks... will take a closer look soon.
< jonasschnelli> Just curios,.. whats the reason for including ctaes.c in aes.c and adding CT_AES to EXTRA_DIST? instead of compiling/linking it regularly?
< spudowiar> Has anyone tested secp256k1 with ctgrind?
< spudowiar> (Valgrind constant time checker by Adam Langley)
< spudowiar> I mean libsecp256k1
< spudowiar> Actually, looking at the Modern Crypto mailing list, looks gmaxwell or someone did something similar
< jtimon> jnewbery: perhaps if we can't agree on changing the current make check we can at least start by adding new targets that could replace it, check-functional, check-all or something
< jtimon> I would love to run the functional tests from the makefile
< bitcoin-git> [bitcoin] biniek opened pull request #10518: Fix translation error (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10518
< cfields> achow101: they were needed at one point to fix a race with the wallet. They're probably unnecessary now.
< cfields> jonasschnelli: it's a .c file, but we want to make sure it gets compiled as c++, to avoid accidentally mixing in c flags
< cfields> jonasschnelli: because we add everything to cxxflags. We might forget to (for ex) add fPIC/fPIE to CFLAGS
< jonasschnelli> cfields: thanks. I see.
< spudowiar> jonasschnelli: So, if Core RPC doesn't have a method for getting the xpub, should I just create one for my HWW support?
< spudowiar> Basically, I'm going to do a HWW plugin that's either a command or a server and supports JSON-RPC
< spudowiar> e.g. You could do `bitcoin-qt -hww-cmd=bitcoin-hww-trezor`
< spudowiar> Or even `bitcoin-qt -hww-server=http://user:password@othermachine:8332` and connect to another bitcoind
< spudowiar> So, I guess I should just create another method or smth
< bitcoin-git> [bitcoin] achow101 opened pull request #10519: [RPC] Remove waitforblock and waitfornewblock (master...rm-waitforblock-rpcs) https://github.com/bitcoin/bitcoin/pull/10519
< jonasschnelli> spudowiar: for HWW support, Core needs flexible keypath (BIP44) with support for pub-key-derivation (currently only hardened derivation is supported), there is a PR from NicolasDorier (check it out).
< jonasschnelli> You don't want to mix xpriv with support for single child key private key exports
< jonasschnelli> mixing non hardened derivation with private child key export is kinda careless
< spudowiar> jonasschnelli: I have all the necessary patches from NicolasDorier applied to my tree
< spudowiar> jonasschnelli: Anyway, the HWW plugin has an RPC method gethwwinfo
< spudowiar> That contains some information about the hardware wallet
< spudowiar> Like the xpub
< jonasschnelli> spudowiar: So you are adding those methods to Core? Or do you have a "middleware" between Core and the HWW?
< jonasschnelli> Do you intend to PR that stuff?
< spudowiar> So, I have a HWW plugin (a command called bitcoin-hww-trezor)
< spudowiar> And CWallet starts that process
< spudowiar> Then I can send RPC requests over stdio to the process and it can send RPC requests back to Core
< spudowiar> So, when something is signed, it sends signrawtransaction to the HWW plugin
< spudowiar> And the HWW plugin will do stuff like send validateaddress (to get the keypath) and decoderawtransaction, etc.
< spudowiar> Also, there's a gethwwinfo which is sent by Core right at the start to get the xpub, etc.
< jonasschnelli> cool stuff
< spudowiar> Although this is quite a bit more complicated than my previous method so I'm not sure how good an idea it is
< spudowiar> Previous method was just start the process when signing needs to happen and pipe a JSON representation of the transaction, with some metadata
< jonasschnelli> IMO working with watchonlys on the Core side and send out the unsigned transaction to a plugin could make more sense?
< spudowiar> That's what it does
< jonasschnelli> ah! cool
< spudowiar> So, if it's a hardware wallet, CWallet::IsMine will treat watch only as normal keys
< spudowiar> e.g. ISMINE_WATCH_UNSOLVABLE => ISMINE_NO and ISMINE_WATCH_SOLVABLE => ISMINE_SPENDABLE
< bitcoin-git> [bitcoin] sipa closed pull request #10518: Fix translation error (master...patch-1) https://github.com/bitcoin/bitcoin/pull/10518
< spudowiar> jonasschnelli: What do you think about using a file descriptor for the child? Because having bi directional JSON-RPC gets a bit messy
< spudowiar> But I could do stdin, stdout and a file descriptor for a socket (to the Bitcoin daemon RPC server)
< spudowiar> Hmm, maybe not actually
< spudowiar> To be honest, only when you want to sign something should it handle the messages
< spudowiar> nvm
< spudowiar> :)
< luke-jr> spudowiar: why do you need bi-directional?
< spudowiar> luke-jr: Because then you can do "Bitcoin Core asks HWW signrawtransaction", "HWW asks Bitcoin Core gettransaction", "HWW responds to signrawtransaction"
< luke-jr> ah
< gmaxwell> spudowiar: I think it should be safe to assume the wallet needs the inputs and just pass them.
< gmaxwell> it can just drop them if it doesn't need them.
< spudowiar> gmaxwell: I was thinking of mimicking an API like signrawtransaction though
< gmaxwell> apparently not, since that api doesn't have two way communication. :P
< spudowiar> Well, it's going to be over stdio :)
< spudowiar> It's basically mimicking the API, because you could just as easily have the HWW plugin connect to the Bitcoin Core over HTTP RPC
< spudowiar> Except it's doing it over stdio
< spudowiar> Which happens to be where the other call came from :)
< sipa> thinking further, it seems strange that the HW/wrapper would need to know what it's missing
< spudowiar> What do you mean?
< sipa> especially if we ever get schnorr multisig or even aggregation
< sipa> the signrawtransaction API is "pass it in partially signed transactions, and do with it what you can"
< sipa> i think that's a good approach, also for HW wallets
< spudowiar> Yeah, but it needs to have the input transactions
< sipa> so pass them
< sipa> the wallet knows whether the HW wallet needs them
< spudowiar> Right, so don't bother with the JSON-RPC emulation then?
< sipa> i think that's unnecessarily complicating the API
< spudowiar> Well, I kept my old branch behind (without this stuff), so that's fine :)
< spudowiar> This was just an experiment :)
< bitcoin-git> [bitcoin] practicalswift opened pull request #10521: Limit variable scope (master...tighten-scope) https://github.com/bitcoin/bitcoin/pull/10521
< bitcoin-git> [bitcoin] practicalswift opened pull request #10522: Remove unused variables (master...unused-strings) https://github.com/bitcoin/bitcoin/pull/10522
< bitcoin-git> [bitcoin] practicalswift opened pull request #10523: Perform member initialization in initialization lists where possible (master...initialization-list) https://github.com/bitcoin/bitcoin/pull/10523
< bitcoin-git> [bitcoin] practicalswift opened pull request #10524: Fix incorrect format strings (master...u-for-unsigned-int) https://github.com/bitcoin/bitcoin/pull/10524