< kanzure>
dandelion was discussed.. but not in the group. so i wasn't there.
< kanzure>
it was one of the smaller meeting rooms with like only 5 chairs
< Chris_Stewart_5>
Yes, a lot of the discussion was around avoiding mempool duplication / segregating a mempool for dandelion
< Chris_Stewart_5>
and privacy vulnerabilities that can be exposed by relay policies with your mempool
< sipa>
plus bandwidth protection
< sipa>
and especially the combination with unconfirmed dependencies is tricky
< Chris_Stewart_5>
I believe sdaftuar has a write up of this some where...
< Chris_Stewart_5>
maybe not -- at least i can't dig it up.
< Chris_Stewart_5>
if anyone wants to take a stab at answering this loaded question ;) ttps://bitcoin.stackexchange.com/questions/81503/what-is-the-tradeoff-between-privacy-and-implementation-complexity-of-dandelion
< Murch>
you're missing an h there. ;)
< Murch>
gmaxwell: Want to take that one? 0:-)
< * sipa>
would like to see sdaftuar answer that
< sipa>
i don't remember all the problems
< sipa>
and suggested solutions
< Chris_Stewart_5>
+1, or MarcoFalke
< bitcoin-git>
[bitcoin] kallewoof opened pull request #14847: refactor: SHA256Autodetect dead stores (master...20181129-sha256autodetect-deadstores) https://github.com/bitcoin/bitcoin/pull/14847
< Chris_Stewart_5>
since I believe he has the current implmentation in #13947
< sdaftuar>
"what is the hold up with implementing Dandelion in Bitcoin Core" <-- definitely a loaded question
< sdaftuar>
but sure i'll take a stab at it
< sipa>
yeah, the answer to that part is "it's not done" :)
< sdaftuar>
sipa: done
< bitcoin-git>
[bitcoin] kallewoof closed pull request #14492: autoconf: add 'test' alias for 'tests' to configure (master...ac-test-arg-alias) https://github.com/bitcoin/bitcoin/pull/14492
< kallewoof>
wumpus / fanquake: #13258 has a lot of utACKs (5+, with most of them on latest commit id). Good to merge? I guess a tACK would be nice though..
< phantomcircuit>
kallewoof, yeah that broke the tests when it's not there lol
< phantomcircuit>
which i guess is sort of better?
< kallewoof>
phantomcircuit: I'm a bit confused. Are you getting an error from just typing "make check"?
< phantomcircuit>
kallewoof, yes, it's complaining about there being no tests in the test
< phantomcircuit>
kallewoof, it's cause the test is being run by ./src/test/test_bitcoin
< phantomcircuit>
but isn't actually there
< sipa>
we should just ignore that error
< sipa>
if possihle
< kallewoof>
huh, i see it now
< phantomcircuit>
the test file should just be removed by the autoconf stuff
< phantomcircuit>
when EVENT_SET_MEM_FUNCTIONS_IMPLEMENTED isn't defined
< phantomcircuit>
but like
< phantomcircuit>
autoconf magic so i cant help
< sipa>
how can it delete a file?
< sipa>
it shoulrn't modify your sourcr code
< phantomcircuit>
sipa, autoconf can remove it from the make file
< kallewoof>
phantomcircuit: maybe a test in configure.ac around line 1101 for EVENT_SET_MEM_FUNCTIONS_IMPLEMENTED and then use the results of that in Makefile.am to conditionally add raii test cpp file.
< e4xit>
~
< e4xit>
\]
< e4xit>
'
< sipa>
it's not working
< provoostenator>
luke-jr: we could keep the more abstract variable name, but just explain in the help that that is what it _currently_ does
< fanquake>
kallewoof thanks
< bitcoin-git>
[bitcoin] fanquake closed pull request #14846: Docs: Adds development guidelines about Scripts shebang to developer-notes.md. (master...add_scripts_development_guidelines) https://github.com/bitcoin/bitcoin/pull/14846
< provoostenator>
(oops, I meant the upstream #11082)
< gribble>
https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
< provoostenator>
#13676 is a documentation change, hopefully read for a final blessing?
< provoostenator>
Any thoughts on how to add wallet specific configuration? Right now all bitcoind wallet related configs seem to apply to all wallets.
< provoostenator>
Context: WIP for ##hwi to add a -signer config where an external script / RPC can be found that can sign a transaction. But I think it makes sense for preferences like RBF and spendzeroconfchange too.
< provoostenator>
Another approach could be store these preferences in the wallet instead of passing them to bitcoind, similar to setwalletflag in #13756
< gmaxwell>
Sometimes things that are booleans eventually get more settings, avoid reuse, case in point, is likely to evolve into a treshold of how much extra you're willing to pay to avoid reuse.
< provoostenator>
Which suggests we should rename setwalletflag to something more generic like setwalletconfig?
< provoostenator>
sipa: does your wallet overhaul ambition include completely changing the way data is stored in it, or can we just add this type of setting data without getting in the way of the descriptor refactor?
< meshcollider>
I believe the plan is just to slowly migrate the actual keys and scripts at the moment, no change to the rest
< meshcollider>
Perhaps this config change should be taken out into its own PR though if it's going to become more independent
< provoostenator>
Or we change it later, but before the next release.
< promag>
could start to add support for per-wallet options (which take the global option value) - which affects RPC and UI - then discuss how to load/store them?
< provoostenator>
Though that's always scary
< sipa>
provoostenator: i have no intention of touching anything but keys/scripts
< provoostenator>
promag: storing the settings in the wallet should be great for GUI development, way less tedious than dealing with gArgs
< promag>
dumb question: do old versions destroy unknown records in wallets?
< provoostenator>
We just need a generic way to store a map of settings.
< provoostenator>
Not sure, but you can always bump the wallet version to prevent that AFAIK.
< sipa>
promag: no
< provoostenator>
How old wallets deal with new payloads is the kind of thing we can test with #12134 (shameless plug).
< provoostenator>
I might at some point volunteer to write this generic settings stuff, but feel free to beat me to it.
< meshcollider>
Sounds good
< meshcollider>
Ok next topic then?
< provoostenator>
But I think it's the cleanest way to add information about hardware wallets to specific wallets.
< achow101>
i think jonasschnelli added a bit field of features supported with the privkey disabled stuff, so we could have the per wallet options already
< provoostenator>
achow101 correct, and 13756 ^ adds avoid_reuse as another flag, but flags can only be boolean.
< provoostenator>
In addition that PR adds getters and setters for these flags.
< gribble>
https://github.com/bitcoin/bitcoin/issues/11082 | Add new bitcoin_rw.conf file that is used for settings modified by this software itself by luke-jr · Pull Request #11082 · bitcoin/bitcoin · GitHub
< provoostenator>
This is great. I build some QT stuff on top of it, which makes me reluctant to touch any settings related UI until that's merged.
< provoostenator>
Maybe more people can review it before hopefully a final rebase?
< provoostenator>
In ancient version of this PR luke-jr added a whole bunch of settings from Knots along with this. That was too much at once, but the idea of making it easier to add more settings to the GUI is certainly appealing.
< promag>
provoostenator: probably rebasing first is better?
< promag>
provoostenator: but I'll take a look too
< provoostenator>
Well, he already did that two weeks ago.
< meshcollider>
This isn't wallet specific, but I'll take a look too yep
< achow101>
topic suggestion: external signers api (provoostenator's idea mentioned earlier)
< provoostenator>
True, though I'd say 99% of GUI users are using it as a wallet, and it's blocking wallet stuff.
< meshcollider>
Perhaps we can add it to high priority once Luke's getbalance stuff is gone :)
< provoostenator>
And when I say "hardware" I mean any program that can sign things.
< provoostenator>
So could also be a remote multisig service that sends you a bunch of text messages with a cool down period. But local hardware is the easiest.
< achow101>
if we were to include hwi now, the commands used would have to have a bunch of flags
< provoostenator>
The way I see it we wouldn't include HWI in Core, at least not yet. The user would be expected to download HWI or alternative on their own.
< achow101>
so some genralized api using descriptors would be useful, especially for having other external signers other than hwi. so someone could write their own program for their hardware device drivers and not have to repliacte all of the same options
< achow101>
the only problem i see is that a descriptor requires knowledge of keys, but you may not have knowledge of keys to begin with to get the descriptor
< provoostenator>
I introduced the concept of a pseudo-descriptor (see "Signer API") to get around that.
< provoostenator>
E.g. wpkh(00000000/84h/1h/0h/0/*) means "gimme all the receive keys"
< provoostenator>
The answer to which would be an actual descriptor, or an array of descriptors if the final derivation is hardened.
< sipa>
why is it not an actual descriptor?
< sipa>
(only half following)
< provoostenator>
The flow is as follows:
< achow101>
sipa: you don't have the keys yet, you are trying to get them
< provoostenator>
Wallet asks driver for a list of devices, and their master fingerprin
< provoostenator>
Wallet asks driver for keys given a master fingerprint and derivation hints
< sipa>
the wallet should just ask the driver for a descriptor for its receive addresses?
< meshcollider>
So basically it is a descriptor with a placeholder key which gets replaced?
< sipa>
why does that need to look like a descriptor
< provoostenator>
It also needs to ask for change addresses.
< provoostenator>
What it needs depends on the wallet.
< meshcollider>
Is it just to specify the format?
< provoostenator>
So a descriptor keeps it generic.
< sipa>
i think my question is: should it treat HW devices/drivers that deal with arbitrary key trees, and the wallet decides which keys to use for what
< sipa>
or is it the driver that decides which keys to use for what
< provoostenator>
I was thinking both.
< sipa>
that seems like the worst of both worlds :)
< provoostenator>
By default we ask for a standard BIP44/49/84 path
< provoostenator>
But the driver can tell us, via enumerate (the first thing we call), that the device insists on a different structure.
< provoostenator>
But I agree this needs more thought.
< sipa>
yeah, ok, you can see it as a 'hint' from the wallet "hey this key path would seem nice to me, agree?"
< provoostenator>
We could also, like sipa suggests, just require that the driver tells us what the receive and change trees are.
< provoostenator>
But I prefer the hint option, because for example the user may have already set changetype and receivetype for a reason.
< provoostenator>
Whereas the driver might default to something lame backwards compatible like p2sh wrapped segwit.
< sipa>
that makes sense
< provoostenator>
Also, I wonder if the concept of "change chain" and "receive chain" is abstract enough to allow for more fancy things. For multisig it should be.
< provoostenator>
We probably need some way for the driver to communicate capabilities.
< provoostenator>
Which again could look like descriptors for lack anything else, e.g. to indicate which address types and whether multisig is supported.
< achow101>
add a new command "getfeatures"?
< provoostenator>
achow101: or just spit it out as part of the enumerate command, but yes.
< meshcollider>
Alright, any other topics?
< provoostenator>
sipa asked for volunteers write tests for #14565