< 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
< 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