< bitcoin-git>
[bitcoin] achow101 opened pull request #13721: Bugfixes for BIP 174 combining and deserialization (master...psbt-fixes) https://github.com/bitcoin/bitcoin/pull/13721
< kallewoof>
I'm torn on https://github.com/bitcoin/bitcoin/pull/12257#discussion_r203741762 -- on the one hand, we want to give correct values for ancestor count; on the other hand, the reason ancestor count is taken into account is because we want to avoid too-long chains of unconfirmed transactions, which is separate. on the third (?) hand, the accurate ancestor count will give a hint at the number of ancestors the resulting transaction
< kallewoof>
will end up having, but on the fifth (!) hand, we want to give a rebate to eliminating multi-utxo-same-dest, and being too strict/accurate here might mean a lot of address reuse remains unspent indefinitely because it creates too many ancestors. in fact, the worse it gets (3,4,5 txs in same output group), the lower the chances the wallet will "fix" the issue.
< kallewoof>
I missed the forth hand. Alas.
< jcorgan>
kallewoof: "on the third (?) hand" <== "on the gripping hand" :-)
< kallewoof>
jcorgan: ohh..
< bitcoin-git>
[bitcoin] hmel opened pull request #13722: [Trivial] Use variable name instead of relying on class layout (master...use_varname_not_this) https://github.com/bitcoin/bitcoin/pull/13722
< gmaxwell>
kallewoof: keep in mind, usually most inputs in a wallet are confirmed and have an ancestor count of zero.
< gmaxwell>
in general the count handling in selection is really just there to get slightly less bad behavior in pathalogical cases.
< gmaxwell>
Probably if your wallet is running out of confirmed outputs, you'd prefer to no longer group them.
< gmaxwell>
(or at least unless you've decided you'd rather not transact at all than reduce your privacy.)
< gmaxwell>
but in that case you should probably be completely avoiding spending unconfirmed coins.
< kallewoof>
gmaxwell: Yeah, that's a good point.
< gmaxwell>
Since any spend of an unconfirmed output is bad for your privacy.
< sipa>
or rather, it would be treated as just OP_0 <keyhash>
< dcousens>
ok! cool, that would explain it
< dcousens>
(was receiving Error: 64: non-mandatory-script-verify-flag (Script evaluated without error but finished with a false/empty top stack element))
< sipa>
dcousens: ah yes, consensus invalid due to the cleanstack rule
< bitcoin-git>
[bitcoin] ken2812221 opened pull request #13724: [contrib] Support ARM and RISC-V symbol check (master...symbol-check-all) https://github.com/bitcoin/bitcoin/pull/13724
< promag>
the 2nd has the advantage of supporting default arguments
< promag>
if the slot declaration is gotoVerifyMessageTab(bool foo = false) for instance
< sipa>
i believe the first one is more lightweight
< sipa>
but i have no opinion either way
< promag>
why more lightweight?
< promag>
lightweight in compile time or runtime?
< promag>
sipa: btw regarding output descriptor, do you think "old behaviour" should be in the grammar? or a call option?
< sipa>
promag: what is a call option?
< promag>
sipa: a option to scantxoutset, like --compability=true or --behavior=old ..
< sipa>
promag: oh this is not about scantxoutset
< sipa>
promag: i want descriptors to be used for everything
< sipa>
in particular, the wallet itself
< sipa>
and in order.to convert existing wallets into a descriptor form, there should be a way of encoding "all the things we used to accept for one key", otherwise you need multiple descriptors even for simple things in the wallet
< promag>
so in 100 years that old() descriptor must represent the same things
< sipa>
but i also want to prevent having several dialects of the language; if it's supported in one place, it should be supported elsewhere (and for scantxoutset it seems useful too, actually)
< sipa>
yes
< promag>
still "old()" meaning is very unclear, specially in the future
< sipa>
yes, "legacy" would be nice, but already has a different meanjng
< promag>
even legacy is not explicit
< promag>
pk_pkh_wpkh_shwpkh(...) :P
< sipa>
yeah...
< promag>
who cares? at least is clear
< sipa>
old on an uncompressed key will just expand to pk and pkh
< promag>
pk_pkh(uncompressed key)
< promag>
I mean, the wallet knows how to export output descriptors
< sipa>
promag: sounds a bit confusing, and make people wonder if why wpkh_wshpk or so wouldn't work
< promag>
sipa: right, on the other hand can't old() can be abused?
< sipa>
promag: i don't like "old" :)
< promag>
ditch it then
< promag>
for scantxoutset, make the caller specify each one
< sdaftuar>
gmaxwell: i think i have a way to benchmark, but my guess would be that it would have minimal impact, after the optimization we did in #9959
< bitcoin-git>
[bitcoin] Empact opened pull request #13728: Run the CI lint stage on mac and linux both (master...bsd-bash-compatibility) https://github.com/bitcoin/bitcoin/pull/13728
< bitcoin-git>
[bitcoin] Empact opened pull request #13729: Scripts and tools: Avoid unnecessarily setting env variables on the lint build (master...ci-lint-env) https://github.com/bitcoin/bitcoin/pull/13729