< achow101>
luke-jr: i'd prefer if we dropped the fourth digit
< aj>
achow101: fourth??
< achow101>
aj: e.g. 0.19.0.1
< aj>
achow101: i'd guess we'd keep tacking on ".1" for "whoops, let's pretend that didn't happen" updates either way?
< achow101>
under semver it'd just be another bugfix patch and we increment the third digit
< luke-jr>
achow101: it's already dropped except when we use it
< achow101>
that's the problem
< achow101>
"except when we use it"
< luke-jr>
I'm fine with removing support for it, but IMO that's better left for a second PR
< achow101>
if we're going to change the versioning scheme, it should be done all at once
< luke-jr>
this is less of a change, and more of dropping dead code IMO
< aj>
achow101: hmm, i suppose it'd be approx semver X.Y.Z to bump X every six months with major updates (which probably include some backwards incompat changes), Y when we do a backport of a feature, and Z just when we do bug fixes
< achow101>
that's pretty much what luke-jr's pr does
< aj>
feature backports != consensus changes, but otherwise sure
< achow101>
i don't think we ever backport features
< achow101>
the only close-to-feature things being backported would be consensus changes
< sipa>
i wonder what clang/llvm's scheme is
< sipa>
it seems fairly similar to ours, having a major release every 6 months approximately
< aj>
achow101: i think #19681 and #19606 and #17621 and the last three from #19224 seem like features?
< aj>
sipa: seems to be X.0.Y where X is incremented on the 6 month releases, Y is for updates to them, and the 0 is to avoid confusion against the old scheme
< bitcoin-git>
bitcoin/master 903f3d0 practicalswift: fuzz: Check for addrv1 compatibility before using addrv1 serializer
< bitcoin-git>
bitcoin/master fa463f1 MarcoFalke: Merge #20247: fuzz: Check for addrv1 compatibility before using addrv1 ser...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #20247: fuzz: Check for addrv1 compatibility before using addrv1 serializer. Fuzz addrv2 serialization. (master...fuzzers-netaddr-post-addrv2) https://github.com/bitcoin/bitcoin/pull/20247
< bitcoin-git>
[bitcoin] fanquake closed pull request #20224: doc: CI system link added, clarity increased (squashed into a single commit) (master...master) https://github.com/bitcoin/bitcoin/pull/20224
< sipa>
hebasto: yeah, i will - anyone can do that, though
< hebasto>
sipa: thanks!
< dongcarl>
Is it expected to see "ERROR: no interesting inputs were found. Is the code instrumented for coverage? Exiting." when running `test/fuzz/test_runner.py ~/src/qa-assets/fuzz_seed_corpus/`?
< dongcarl>
This is using the qa-assets corpus on github
< MarcoFalke>
Also, you can use "test_runner.py -l DEBUG ..." for more DEBUG
< luke-jr>
once again, a reminder that #18818 still needs review and is a blocker for 0.21 (it was at least partially backported for 0.20 after branch-off…)
< luke-jr>
wumpus: IMO we should at least have GUI PRs annoucne here
< luke-jr>
kallewoof: for your new signmessage work - it might be a good idea to consider what it would take to sign as the recipient of a Lightning invoice..
< sipa>
luke-jr: that sounds like it would hugely expand the scope
< sipa>
bip322 proves the ability to spend coins sent to a particular bitcoin address; a lightning equivalent sounds like it would need a lightning-specific solution
< luke-jr>
sipa: I mean, half the point is to work for any invoice
< sipa>
luke-jr: i agree conceptually, but the technologies are so wildly different that aiming for something like this sounds like a good way to make sure it never happens
< luke-jr>
☹
< luke-jr>
maybe we should get a Lightning dev to co-author it?
< luke-jr>
otoh, could Core even support the BIP if it had this? :/
< sipa>
no
< luke-jr>
hmm, I suppose it makes sense to limit verification to addresses you can actually send to