< bitcoin-git> [bitcoin] MeshCollider reopened pull request #14491: Allow descriptor imports with importmulti (master...201810_importmulti_desc_2) https://github.com/bitcoin/bitcoin/pull/14491
< * Hayro> #cvv2 #cvv2 #cvv2 #cvv2 #cvv2 #cvv2 #cvv2 #cvv2 #cvv2 freenode
< bitcoin-git> [bitcoin] pengfangzhi opened pull request #14644: 0.17 (master...0.17) https://github.com/bitcoin/bitcoin/pull/14644
< * Hayro> alayınızın bacisini sikim
< bitcoin-git> [bitcoin] sipa closed pull request #14644: 0.17 (master...0.17) https://github.com/bitcoin/bitcoin/pull/14644
< bitcoin-git> [bitcoin] sipa opened pull request #14646: Add expansion cache functions to descriptors (unused for now) (master...201811_descriptcache) https://github.com/bitcoin/bitcoin/pull/14646
< meshcollider> achow101: ok #14491 is rebased and reopened, you might want to quickly review it before basing on top of it just to save yourself rebasing later if you spot something wrong
< gribble> https://github.com/bitcoin/bitcoin/issues/14491 | Allow descriptor imports with importmulti by MeshCollider · Pull Request #14491 · bitcoin/bitcoin · GitHub
< achow101> thanks!
< provoostenator> sipa thanks for the meeting ping. It's on my calendar now, but couldn't make it. ryanofsky: glad to hear "[found by?] sjors bugs" are a thing :-)
< provoostenator> gwillen: I'll take your offline signing GUI for a spin. A WIP PR seems a good way to get more feedback and make sure this work isn't forgotten if you suddenly decide to retire on a beach.
< provoostenator> I'm thinking of adding a RPC utility function "deriveaddress" which takes a descriptor and spits out an address. That way you don't need a watch-only wallet if all you need is to generate a fresh address. Can probably reuse code from scantxoutset.
< sipa> provoostenator: could be a utility too, in a separate binary
< provoostenator> Like #13926 for general purpose utilities? Or maybe for generating / verifying scripts and addresses?
< gribble> https://github.com/bitcoin/bitcoin/issues/13926 | [Tools] bitcoin-wallet - a tool for creating and managing wallets offline by jnewbery · Pull Request #13926 · bitcoin/bitcoin · GitHub
< sipa> provoostenator: i'm thinking there is probably enough that can be done with psbt and descriptors that can be put in a separate utility
< provoostenator> That said, a slightly more ambitious version of the above command - combined with an address index - could give you the next available address in a range.
< * sipa> hates address indexes
< sipa> anything that requires a full blockchain is imho not worth spending time on
< provoostenator> Tend to agree on address indexes being total overkill. It might be better to use a wallet at that point.
< sipa> yes.
< sipa> that's what they're for
< provoostenator> It's nice to have an ephemeral wallet though, which would need an address index.
< provoostenator> (or be slow)
< sipa> i don't see why; in general making a backup of a file isn't hard
< sipa> it's nice to know you can *recover* your money with a short string as an assurance; but there's not reason why that can't be slow
< provoostenator> Plausible deniability. Memorize 24 words, type them in plus a deriviation path.
< sipa> and give up your privacy to whoever is running the index service
< provoostenator> James Bond is not going to sit around for hours waiting for a rescan, but I agree it's probably fine in more normal cases :-)
< provoostenator> It would be your own node.
< provoostenator> Plausible deniability in this case means having a node, maybe with some coins, but not all your coins.
< sipa> i don't believe long term everyone having a fully indexed archival node is interesting or reasonable
< provoostenator> Right, it wouldn't be interesting for everyone, these indexes are optional for that reason.
< sipa> with bip157 it's also much less needed
< sipa> (it's still slow, but several times faster to rescan)
< sipa> and outsourcable
< provoostenator> BIP157 does make sense as a faster-enough alternative to an address index for the above use case.
< sipa> it's not quite the same, but as i said, i think "short phrase to access your coins" isn't a reasonable normal use case if you care about privacy and resource costs
< provoostenator> But back to the seperate utility. I imagine there's often things that need wallet and or blockchain context. But since code can be reused between binaries, that doesn't have to be a show stopper.
< sipa> sure it'd be built from the same source code
< sipa> like bitcoin-tx
< provoostenator> Adding psbt and descriptor to support to bitcoin-tx makes sense to me. A generateaddress seems a bit out of scope for that though?
< sipa> well bitcoin-tx is really designed to operate on transactions
< sipa> all its commands are things that modify transactions
< sipa> perhaps psbt can be included
< sipa> but i think something more traditional does make sense too, where you have a tool that exactly mirrors bitcoin-cli like usage
< sipa> except it doesn't invoke a bitcoind but does everything locally
< provoostenator> Right, similar to the offline wallet tool in 13926
< sipa> right
< provoostenator> Maybe just call it bitcoin-tool?
< sipa> hah
< provoostenator> RPC does have the benefit over being accessible over TCP though, so e.g. a web server can use those utility methods. Another approach would be to make those utilities easier to package in libraries.
< luke-jr> provoostenator: just make encrypted backups :x
< provoostenator> luke-jr: that was a great idea until forced decryption became a thing.
< luke-jr> no different from forced 24 words
< bitcoin-git> [bitcoin] ch4ot1c opened pull request #14647: build: Remove illegal spacing in darwin.mk (master...build/darwin-spaces-fix) https://github.com/bitcoin/bitcoin/pull/14647
< wcp> help my phone
< wcp> fix my phone
< wcp> done
< bitcoin-git> [bitcoin] luke-jr opened pull request #14649: RPC: add weight to mempool entry output (master...rpc_mempoolentry_weight) https://github.com/bitcoin/bitcoin/pull/14649