< luke-jr>
so after spending several hours trying to get a Rust compiler, I'm once again concluding it is still not realistically usable yet (cc dongcarl)
< luke-jr>
(got pretty far, but rustc is segfaulting building the std lib, and I have no clue where to go from there)
< luke-jr>
(but that's only for 1.29.0 which is ancient and requires LLVM that has been dropped from Gentoo etc)
< shesek>
harding, whether the docs are correct, I don't need it
< luke-jr>
harding: yes, because size was broken at that point
< harding>
shesek: I just tested with -deprecatedrpc=size and I can get the `size` field in getmempoolentry, so the docs are wrong about the feature being removed in 0.20.
< harding>
Looks like it's remove in master though.
< provoostenator>
Oh wait, it magically apears after 11 minutes
< provoostenator>
Sadly no auto-scroll :-)
< provoostenator>
MarcoFalke: I think you still need to activate cirrus CI for the GUI repo?
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #17458: Refactor OutputGroup effective value calculations and filtering to occur within the struct (master...cleanup-outputgroups) https://github.com/bitcoin/bitcoin/pull/17458
< bitcoin-git>
[bitcoin] MarcoFalke reopened pull request #17458: Refactor OutputGroup effective value calculations and filtering to occur within the struct (master...cleanup-outputgroups) https://github.com/bitcoin/bitcoin/pull/17458
< provoostenator>
To many double negatives, so the proposal is to store Merkle branches in the wallet?
< sipa>
yes
< sipa>
at least optionally
< jonatack>
hi
< achow101>
also we should probably remove the descriptor wallets project from the repo now that it's done. maybe we should add one for hwardware wallets and one for sqlite wallets?
< sipa>
but probably better to have this discussion with luke-jr present
< provoostenator>
Is that to make it easier to do transaction lookups without a txindex?
< provoostenator>
But yes, we can defer discussion until he's around.
< meshcollider>
achow101: sounds sensible, I'm not sure I can add/remove projects so maybe sipa can do that for us :)
< meshcollider>
So tl;dr for the hardware wallet write-up for now is: go and review #11413 ?
< provoostenator>
Hardware wallet project would be welcome. My writeup contains a few PR's that can be added, recursion should find the rest, or pingme.
< provoostenator>
meshcollider: there's roughly two things one can review, based on interest
< provoostenator>
1) bunch of send RPC related PR's
< provoostenator>
The UI is tangential to my hardware wallet PR's though, beacuse you won't need to touch PSBT manually.
< provoostenator>
Though I can see how in multisig you might receive a PSBT via "email", load it and then sign on a device. So eventually it'll have a role.
< achow101>
topic suggestion: how much bdb code do people want to review?
< meshcollider>
#topic BDB code review (achow101)
< provoostenator>
But my initial implementation assumes single sig, with only modest thought put into multisig (I closed a PR for that, too much of a stack)
< provoostenator>
Is there a choice in how much?
< achow101>
I've split out chunks of #18971 into a bunch of seperate PRs that are pretty easy to review
< sipa>
cfields: i think what you're concerned about is the automatic construction of spans, not the conversion
< cfields>
sipa: yes, that.
< sipa>
cfields: i was hesitant myself, but ended up just matching the std::span behavior
< cfields>
for ex, in VerifyWitnessProgram, ExecuteWitnessScript gets called with different types of scripts depending on which branch it falls into. Just makes it hard to assume what the param ends up as.
< sipa>
the way i see is that an automatically-created span acts as a "common denominator" for all containers that can be passed to it
< sipa>
so by having a Span<const T> are argument to a function, you automatically enable passing any constant contiguous container to it
< sipa>
i wonder if we need being able to do so from temporaries, though
< cfields>
There are only a handful, and they sure look like magic :p
< cfields>
but point taken about matching std::span.
< sipa>
i think it makes sense to write a big comment about pitfalls with spans
< sipa>
they're kind of the same ones that exist for references in the first place, but for references that's masked due to automatic lifetime extension
< sipa>
as in:
< sipa>
std::string Foo();
< sipa>
std::string& x = Foo();
< sipa>
works and is well-defined, as the temporary returned by Foo gets its lifetime automatically extended to that of x
< sipa>
but if there is a function call in between, that magic disappears
< cfields>
+1 to some pitfalls docs.
< sipa>
the only actual danger i can imagine is when you're constructing a span from a temporary, and then assigning that span to a variable
< sipa>
(and that temporary isn't a span itself)
< jnewbery>
cfields: you're very welcome to come to review club next week and tell us about the pitfalls of spans: https://bitcoincore.reviews/18468.html :)
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #19331: build: Do not include server symbols in wallet (master...2006-WalletNoServerSym) https://github.com/bitcoin/bitcoin/pull/19331
< cfields>
jnewbery: haha, I don't know what those pitfalls are, that's why I was running things by sipa :)
< sipa>
cfields: you seem pretty good at noticing them (the vector resize, and the span-from-temporary one...)
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #19332: test: Fix intermittent test failure in feature_backwards_compatibility (master...2006-testIntBack) https://github.com/bitcoin/bitcoin/pull/19332
< bsm117532>
#proposedwalletmeetingtopic descriptor specification for watch-only wallets, and repeated payments without address use via BIP32 paths
< bsm117532>
Maybe that doesn't work outside a meeting...
< gwillen>
bsm117532: it does, the bot won't respond but the log gets scraped for them later, before the meeting