< 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?
< gribble> https://github.com/bitcoin/bitcoin/issues/19681 | 0.19: Add txids with non-standard inputs to reject filter by sdaftuar · Pull Request #19681 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19606 | Backport wtxid relay to v0.20 by jnewbery · Pull Request #19606 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/17621 | IsUsedDestination should count any known single-key address by instagibbs · Pull Request #17621 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19224 | [0.20] Backports by fanquake · Pull Request #19224 · bitcoin/bitcoin · GitHub
< achow101> aj: might be the first time in recent memory
< achow101> I looked through the release notes last week and every one had only bugfixes afaict
< 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
< fanquake> LLVM did releas a 7.1.0 though
< aj> the .1 was for an ABI break apparently
< AdulrunaRedviva> good morning all
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d67883d01e50...fa463f116377
< 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
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fa463f116377...67d4643a1a76
< bitcoin-git> bitcoin/master defe48a Hennadii Stepanov: doc: Update wallet files in files.md
< bitcoin-git> bitcoin/master 67d4643 fanquake: Merge #20152: doc: Update wallet files in files.md
< bitcoin-git> [bitcoin] fanquake merged pull request #20152: doc: Update wallet files in files.md (master...201015-sqlite) https://github.com/bitcoin/bitcoin/pull/20152
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/67d4643a1a76...c1564baf3b5e
< bitcoin-git> bitcoin/master 47e2a35 skmcontrib: doc: Document ALLOW_HOST_PACKAGES dependency option
< bitcoin-git> bitcoin/master c1564ba Wladimir J. van der Laan: Merge #19124: doc: Document ALLOW_HOST_PACKAGES dependency option
< bitcoin-git> [bitcoin] laanwj merged pull request #19124: doc: Document ALLOW_HOST_PACKAGES dependency option (master...allowHostDoc) https://github.com/bitcoin/bitcoin/pull/19124
< wumpus> amiti: seems #19877 is ready for merge just needs one last rebase
< gribble> https://github.com/bitcoin/bitcoin/issues/19877 | [test] clarify rpc_net & p2p_disconnect_ban functional tests by amitiuttarwar · Pull Request #19877 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/c1564baf3b5e...83363f7b62f9
< bitcoin-git> bitcoin/master fa2b778 MarcoFalke: test: Remove unused -blockversion from tests
< bitcoin-git> bitcoin/master fa7fb0e MarcoFalke: test: Default blockversion to 4 in feature_block
< bitcoin-git> bitcoin/master fa9b485 MarcoFalke: test: Add test for -blockversion
< bitcoin-git> [bitcoin] laanwj merged pull request #20167: test: Add test for -blockversion (master...2010-testBlockversion) https://github.com/bitcoin/bitcoin/pull/20167
< vasild> https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L1346 - this looks strange, it would check whether both POLLERR and POLLHUP are set at the same time.
< vasild> I guess this never happens
< vasild> no, I am not fully awake, ignore the above
< bitcoin-git> [bitcoin] fanquake opened pull request #20253: net: use std::chrono throughout maxOutbound logic (master...net_unused_outbound) https://github.com/bitcoin/bitcoin/pull/20253
< bitcoin-git> [bitcoin] vasild opened pull request #20254: Add I2P support using statically configured destinations (master...i2p_static) https://github.com/bitcoin/bitcoin/pull/20254
< jonasschnelli> wumpus: I think you should add githubmerge.pushmirrors=git@github.com:bitcoin-core/gui.git to your merge master repository
< bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/83363f7b62f9...55b1ffcd259c
< bitcoin-git> bitcoin/master 7b2e42e Hennadii Stepanov: qt: Add WalletFrame::sizeHint
< bitcoin-git> bitcoin/master 55b1ffc Jonas Schnelli: Merge bitcoin-core/gui#116: Fix unreasonable default size of the main wind...
< bitcoin-git> [bitcoin] jonatack closed pull request #20240: script: fix linter error in test runner (master...fix-python-linter-error) https://github.com/bitcoin/bitcoin/pull/20240
< wumpus> jonasschnelli: will try!
< jonatack> i'm still writing tests on the various rpc send methods, and still finding inconsistencies, allowed invalid params and similar bugs...
< 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
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20255: util: Add Assume() identity function (master...2010-assume) https://github.com/bitcoin/bitcoin/pull/20255
< bitcoin-git> [bitcoin] laanwj opened pull request #20256: qt: Pre-splitoff translations update (master...2020_10_translations_update) https://github.com/bitcoin/bitcoin/pull/20256
< MarcoFalke> dongcarl: What is the full output
< MarcoFalke> What configure flags?
< 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…)
< gribble> https://github.com/bitcoin/bitcoin/issues/18818 | Fix release tarball generated by gitian by luke-jr · Pull Request #18818 · bitcoin/bitcoin · GitHub
< 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
< luke-jr> that's already the case I guess
< sipa> right