< fanquake>
Would anyone be opposed to having the maintainer-tools commits show up here via the bot, if that's possible? Commits are infrequent, but probably interesting to those watching in here.
< fanquake>
Also since we are moving more important scripts to that repo.
< fanquake>
I'm messaging some users in here directly about review and re-review (don't want to spam the channel). If you'd rather not hear from me, just let me know.
< bitcoin-git>
bitcoin/master a50d9e6 William Casarin: rpcwallet: default include_watchonly to true for watchonly wallets
< bitcoin-git>
bitcoin/master 003a3c7 William Casarin: rpcwallet: document include_watchonly default for watchonly wallets
< bitcoin-git>
bitcoin/master 72ffbdc William Casarin: doc: add release note for include_watchonly default changes
< bitcoin-git>
[bitcoin] fanquake merged pull request #16383: rpcwallet: default include_watchonly to true for watchonly wallets (master...20190713-watchonly-defaults) https://github.com/bitcoin/bitcoin/pull/16383
< fanquake>
harding: Would you be interested in doing another release notes roll-up, similar to what you did in #15081? Currently 17 fragments floating around the repo. Note that one is actually in the doc/release-notes/ folder.
< harding>
fanquake: yes, definitely interested. I'll try to get a PR opened by early next week. Thanks for suggesting it (and for the note about the one in doc/release-notes---I would've missed that).
< bitcoin-git>
[bitcoin] NicolasDorier opened pull request #16629: [Doc] Add documentation for the new whitelist permissions (master...doc/permissions) https://github.com/bitcoin/bitcoin/pull/16629
< bitcoin-git>
[bitcoin] NicolasDorier opened pull request #16631: [Fix] The default whitelistrelay should be true (master...fix/default-whiterelay) https://github.com/bitcoin/bitcoin/pull/16631
< coinmonks>
hey guys, few days ago, I tried to understand the Bitcoin codebase using different metrics, for now i want to understand what is state of Bitcoin contributors and their economic well being..
< bitcoin-git>
[bitcoin] DrahtBot closed pull request #15150: gui: Show wallet selector on console window if there are wallets loaded (master...2019-01-consolewalletselector) https://github.com/bitcoin/bitcoin/pull/15150
< meshcollider>
Firstly apologies from me for the lack of review/merging I've done recently, had an especially busy project at uni which just finished so I'll get a few PRs merged today hopefully
< meshcollider>
Any topics?
< achow101>
People should test and review #16341
< gribble>
https://github.com/bitcoin/bitcoin/issues/16341 | Introduce ScriptPubKeyMan interface and use it for key and script management (aka wallet boxes) by achow101 · Pull Request #16341 · bitcoin/bitcoin · GitHub
< jnewbery>
I think that's a nice change. In general there are a few places where serialization details leak into the wallet implementation unnecessarily. 16624 cleans up some of that.
< achow101>
current coin selection uses branch and bound which uses effective value, and then falls back to the old algo which does not use effective value if that fals
< achow101>
it would be nice to retry random selection
< achow101>
as the fallback and get rid of the old thing entirely
< achow101>
the previous pr was #13307 and it just kind of stalled out
< sipa>
i guess the only reason not to would be because we're not entirely sure that the algorithm works reasonably well on all kinds of utxo sets
< achow101>
I think the main issue was that with SRD as the fallback, we weren't consolidating as much as the legacy algo did
< sipa>
hmm, i was worrying about the opposite, where it might occasionally pick a crazy high number of inputs despite being unnecessary
< achow101>
the simulations I did previously showed that basically for all runs, there were a lot more utxos in the wallet on average
< sipa>
simulations only show behavior for the type of wallets you have data for, though
< achow101>
right..
< achow101>
I think we could mitigate the possiblity of choosing too many utxos by selecting multiple times and choosing the "least waste"
< achow101>
kind of like we do for BnB already
< sipa>
but when you do things like "run SRD 3 times, and pick the cheapest result", the risk of overly large input set goes down dramatically, but you're also worsening the consolidation further
< meshcollider>
Have you got some results that indicate it is somehow better in some aspect then? This seems like the naive approach, why do we want to switch it in?
< achow101>
part of the whole consolidation thing I think was that the legacy algo would actually select dust (negative effective value) for inputs whereas in BnB and SRD, we would ignore those entirely
< sipa>
i suspect that's an inherent tradeoff
< sipa>
anything that does not consume dust will have worse consolidation
< achow101>
also, from murch's original paper, he found that it helped BnB get better exact matches over other methods
< achow101>
one of the issues with the legacy selection is that it does not use effective value which makes doing some other things difficult, according to instagibbs
< sipa>
does SRD use effective value?
< achow101>
yes
< sipa>
hmm, remind me how?
< sipa>
it just doesn't consider anything with negative effective value?
< achow101>
basically
< achow101>
effective value just subtracts the fee required for that input from its value so that we don't have to constantly guess what the fees are going to be
< sipa>
ah right that too, it lets you predict in one pass whether you have enough
< sipa>
i guess you could make the consolidation/dust tradeoff configurable by making it allow negative EV, but limiting how negative it can be (for example as a percentage of the payment value)
< achow101>
yes, so we can get rid of this stupid loop in CreateTransaction
< meshcollider>
Can't the same effective value check just be added to the legacy code
< achow101>
probably
< achow101>
but the legacy code is also kind of pointless as it also tries to do an exact match which we are already doing in BnB
< achow101>
one of the main things that SRD did in my simulations was that it made BnB have more exact matches which helps with privacy
< meshcollider>
This is the thing I don't like about the coin selection, its all super heuristic and the tradeoffs are really hard to identify or compare
< sipa>
it is
< meshcollider>
If you think this is worth revisiting will you reopen the PR?
< sipa>
but it's also an algorithm that has weathered a lot
< achow101>
instagibbs said he would take a crack at it
< meshcollider>
Ok
< achow101>
it would be useful to have other kinds of simulation data rather than just the one or two datasets I got
< sipa>
ping murch :)
< achow101>
he says no everytime I ask
< achow101>
won't give me the secrets to Bitgo's coin selection :p
< sipa>
achow101: just an idea, what happens if you simulate something SRD like, but permit individual utxos whose EV is > -0.2 * feerate*size
< sipa>
rather than > 0
< sipa>
this can be discussed outside of the meeting of course
< achow101>
it probably should be. simulations take a long time
< achow101>
I would assume something with more mean utxos than the simulation that allows any negative EV utxo but not as bad as those that exclude
< sipa>
actually that rule is equivalent to "only utxos that are positive EV at 80% of the feerate"
< achow101>
in terms of fees, including negative ev still does better than current
< meshcollider>
You had a lot of simulations when we switched the BnB initially, what happened to those datasets?
< achow101>
they're all in public gists on github
< achow101>
i have the data somewhere too
< meshcollider>
Yeah I was wondering if they have more variation in types of utxo set than what you've tested so far
< achow101>
those datasets were still only based on two actual datasets, just with different variations of filtering and ordering of the data
< meshcollider>
Ah
< meshcollider>
Alright so we just see what instagibbs does and discuss further in the PR?
< achow101>
all of the different BnB simulations were mostly for different feerates
< achow101>
yeah. i guess the question was really whether this was something even worth pursuing again
< sipa>
i think so
< meshcollider>
If sipa thinks so then I think so too ;)
< meshcollider>
Any other last topics?
< meshcollider>
#endmeeting
< lightningbot>
Meeting ended Fri Aug 16 19:46:04 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< meshcollider>
If it's true, it's kind of sad that just randomly picking utxos pretty much naively is better than the more complicated logic we have currently lol
< achow101>
the question is how do you define better?
< meshcollider>
But I guess "better" is not well-defined
< meshcollider>
Yeah
< achow101>
I suspect that effective value is what makes srd perform better in terms of fees
< achow101>
it would also be nice to cleanup coin selection. right now to understand it you have to read like 5 different functions
< meshcollider>
Yes that would be nice :)
< jb55>
what's the best place to read up on coin selection algos?