< bitcoin-git>
bitcoin/master 82dee87 Sebastian Falbesoner: test: test decodepsbt fee calculation (count input value only once per UTX...
< bitcoin-git>
bitcoin/master 2a78472 MarcoFalke: Merge #19597: test: test decodepsbt fee calculation (count input value onl...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #19597: test: test decodepsbt fee calculation (count input value only once per UTXO) (master...20200726-test-check-deceodepsbt-fee-calculation) https://github.com/bitcoin/bitcoin/pull/19597
< bitcoin-git>
bitcoin/master 78c312c Martin Ankerl: Replace current benchmarking framework with nanobench
< bitcoin-git>
bitcoin/master 4ebe2f6 Wladimir J. van der Laan: Merge #18011: Replace current benchmarking framework with nanobench
< bitcoin-git>
[bitcoin] laanwj merged pull request #18011: Replace current benchmarking framework with nanobench (master...2019-10-nanobench) https://github.com/bitcoin/bitcoin/pull/18011
< fanquake>
#proposedmeetingtopic 0.20.1rc1 testing. Has anyone had/seen any issues during testing so far? Has anything come up that would require an rc2?
< fanquake>
I have moved #19033 to the 0.20.2 milestone.
< bitcoin-git>
bitcoin/master c251d71 Jon Atack: p2p, refactoring: use CInv helpers in net_processing.cpp
< bitcoin-git>
bitcoin/master 17de75b Wladimir J. van der Laan: Merge #19590: p2p, refactor: add `CInv` transaction message helpers; use i...
< bitcoin-git>
[bitcoin] laanwj merged pull request #19590: p2p, refactor: add `CInv` transaction message helpers; use in net processing (master...CInv-transaction-message-helpers) https://github.com/bitcoin/bitcoin/pull/19590
< bitcoin-git>
[bitcoin] theStack opened pull request #19626: refactor: replace sizeof(a)/sizeof(a[0]) by ARRAYLEN(a) (master...20200726-refactor-replace-sizeof-by-arraylen) https://github.com/bitcoin/bitcoin/pull/19626
< luke-jr>
I wonder if nodes ought to prefer blocks with expected version over equal-work blocks with unexpected version
< instagibbs>
prefer as is preciousblock?
< instagibbs>
as in
< instagibbs>
oh sorry, yes, i had to read the entire sentence
< luke-jr>
similar
< luke-jr>
it could make sense, because if features are activated the node doesn't support, it ceases to be a full node
< luke-jr>
(and for new nodes, it gives a small bias toward activation of new features they do support?)
< instagibbs>
first seen in general gives good convergence properties. Some new asicboost like thing could result in more profitable selfish mining attacks or similar
< fanquake>
wumpus: sounds good
< bitcoin-git>
[bitcoin] hebasto opened pull request #19627: build: Drop per-host faketime wrappers in gitian-linux build (master...200729-fake) https://github.com/bitcoin/bitcoin/pull/19627
< wumpus>
one proposed meeting topic: 0.20.1rc1 testing (fanquake)
< wumpus>
any last minute topic ideas?
< jeremyrubin>
hi
< jeremyrubin>
Maybe backports of wtxid v.s. the thing suhas proposed?
< wumpus>
ok
< wumpus>
#topic High priority for review
< achow101>
#19077 pls
< gribble>
https://github.com/bitcoin/bitcoin/issues/19077 | wallet: Add sqlite as an alternative wallet database and use it for new descriptor wallets by achow101 · Pull Request #19077 · bitcoin/bitcoin · GitHub
< jamesob>
achow101: looking forward to reading that one
< wumpus>
achow101: added
< wumpus>
I'm happy we got through all the preparation PRs and got to the main one now :)
< meshcollider>
Yes \o/
< jeremyrubin>
not a devel topic, but gentle nudge for anyone who could use more funding to get themselves added to https://bitcoindevlist.com/, the community has been very generous lately & it's easy to setup via github sponsors (who are matching up to $5k in your first year)
< wumpus>
thanks
< wumpus>
anything else to add/remove or that is ready for merge?
< wumpus>
#topic 0.20.1rc1 testing
< luke-jr>
is what ready for merge? O.o
< wumpus>
Has anyone had/seen any issues during testing so far?
< wumpus>
luke-jr: anything on high priority for review
< luke-jr>
ah
< MarcoFalke>
Might be ready to ship
< MarcoFalke>
Only change since rc has been a doc commit and a travis commit
< hebasto>
^ agree
< wumpus>
I think so too
< luke-jr>
by my count, I only see 13 nodes using 0.20.1; but I haven't paid much attention to this in the past
< luke-jr>
and it's expected that there will be some delay in my stats picking things up
< wumpus>
no new problems have been reported with .1 afaik
< wumpus>
luke-jr: happy to hear 13 people are testing it :)
< wumpus>
(at least)
< wumpus>
I'm planning to tag -final soon then, it's good to get this release out of the door
< wumpus>
#topic backport of wtxid versus alternative (jeremyrubin)
< jeremyrubin>
Hmmm well it seems we lost suhas a moment ago
< luke-jr>
I thought we figured out we didn't strictly need either?
< wumpus>
MarcoFalke: I think that's a good point, might make sense to include wtxid relay only in the 20.x release after 21.0
< jnewbery>
The biggest difference is removing the unbroadcast stuff, which was only merged after v0.20 forked, but even that's pretty limited in where it interacts with the rest of the code
< jeremyrubin>
Out of curiosity, can we backport either easily to a 19.x? Would that matter?
< luke-jr>
(so long as the policy changes were left for 0.21+)
< sdaftuar>
sorry my connection is super laggy right now. but i assume we could easily backport #19620 to any recent release
< jeremyrubin>
luke-jr: it would be nice to have less dependency though on when policy changes are advisable
< wumpus>
hm 0.19 backport would be much more work (code differs more) and gets much less testing
< jeremyrubin>
sdaftuar's patch seems to be really simple compared to wtxid relay
< jnewbery>
my opinion is that there's no strong reason not to backport wtxid relay to 0.20. It should be a trivial review for anyone who reviewed it on master, and we want wtxid relay to be widely deployed independent of taproot
< jnewbery>
I think 19620 is independently good and should also be backported
< jeremyrubin>
maybe backport both to 0.20, sdaftuar patch to 0.19?
< sdaftuar>
anyway i definitely wanted wtxid relay to be part of 0.20, so i think jnewbery is right to say the backport isn't terrible, but backporting p2p features isn't something we usually do
< luke-jr>
sdaftuar: considering we don't need it for Taproot(consensus), is there another reason you want wtxid relay in 0.20?
< jeremyrubin>
I guess the question which I'm uncertain enough is how big of a deal is it going to be for 0.19.x nodes if taproot rolls out and they have no protections
< wumpus>
we can make an exception to normallly not backporting p2p features as it's requirement for taproot
< wumpus>
which will also be backported
< instagibbs>
we normally backport activations, hence this yeah
< sdaftuar>
luke-jr: i'm not sure i do want it in 0.20 now, i just meant when i wrote it back in january, i had been hoping it would make the 0.20.0 release :)
< luke-jr>
ah
< jnewbery>
19620 should be a trivial backport to 0.19 (it's only 10-20 lines of code changed). I don't think we should backport wtxid relay to 0.19
< jeremyrubin>
luke-jr: sipa seemed to be exceptionally frustrated when i suggested that last week, so while possible maybe better to not plan to do that
< sipa>
luke-jr: what do you mean by that? it would require some rule that taproot-capable nodes don't relay such transactions to older peers
< sipa>
which is a possibility, but i think just backporting #19620 is a lot simpler
< luke-jr>
sipa: I mean we can deploy Taproot(consensus) independently from / in parallel to Taproot(policy)
< luke-jr>
the former is going to take at least a year anyway, so 0.21 will be mature by the time it activates
< sipa>
luke-jr: sure... but that won't protect old nodes
< jeremyrubin>
jnewbery: that sounds good to me as an actionalble plan forward. Is it enough that 0.19.x nodes with the patch won't get bad dos?
< sipa>
(by the time things actually start being relayed, from whatever codebase)
< luke-jr>
sipa: that's true no matter what release we put it into?
< sipa>
luke-jr: yes, fair - but at least there could easily be a 0.20 and 0.19 perhaps with 19620 in it, so people who don't want to immediately upgrade to a new major version would have an option
< sdaftuar>
honestly i'm not super concerned about bandwidth waste to old nodes. it's better to not waste bandwidth, of course, but i think if people have a couple alternatives to avoid it (upgrade to latest minor release or major release) it's not a big deal
< jnewbery>
sdaftuar: I agree
< wumpus>
I agree too
< luke-jr>
sipa: I'm not opposed
< sipa>
ok
< jnewbery>
0.18 is EOL in Feb next year, Taproot won't activate before then, probably
< jnewbery>
so if we backport 19620 to 0.19, anyone on a supported version has a minor release they can upgrade to
< wumpus>
yes
< jeremyrubin>
I also agree with this to an extent, but I think there are probably some older node users who would be noisy, and I wouldn't want that to translate into opposition to other development work on later versions
< jeremyrubin>
jnewbery: I don't think anyone can complain about that plan
< sdaftuar>
they can just put an upgraded node in between their old node and the network
< sipa>
yeah, seems reasonable to me
< luke-jr>
jeremyrubin: if someone insists on using a pre-0.19 version, they can fund longer-term maintenance thereof..
< luke-jr>
or what sdaftuar suggested
< sipa>
of course, i don't think we have obligations to maintain EOL versions
< jeremyrubin>
When is EOL for 0.19?
< wumpus>
so the plan is to backport #19606 to 0.20 and #19620 to 0.19 and 0.20?
< sipa>
random thought: should the bitcoincore twitter account announce when major releases go unsupported/EOL ?
< sdaftuar>
i think your pr about orphan fetching just got conflicted due to a refactor that was merged
< instagibbs>
"maintenance end" I think luke-jr
< sipa>
sdaftuar: will fix soon, seems trivial
< instagibbs>
im reading the website
< sdaftuar>
so perhaps we should highlight the followup prs that would be backported as well?
< luke-jr>
instagibbs: yeah, me too - it's not clear when EOL is
< sdaftuar>
(if more than one)
< achow101>
0.19 eol is after 0.22
< instagibbs>
eolAfter EOL, users must upgrade to a later version to receive security updates, even though the community may provide fixes for critical issues on a best effort basis.
< instagibbs>
i think maintenance is more what we're considering
< sipa>
so wtxid relay is #18044 #19590 #19569... anything else?
< jnewbery>
if we're agreed that #19606 should go in, then can I encourage anyone who reviewed #18044 to look at it soon, while the original PR is still fresh for them
< jeremyrubin>
wait is it going into the upcoming minor?
< jeremyrubin>
I thought it's the next 0.20 minor?
< MarcoFalke>
And should it be released before 0.21? That would imply that 0.20.x users are testing the 0.21.0 release
< MarcoFalke>
jeremyrubin: Not in the one that is rc right now
< jnewbery>
jeremyrubin: no. 20.1 already has an rc
< jeremyrubin>
that's what I thought, was confused by the 'get it in'
< jeremyrubin>
will review
< sdaftuar>
MarcoFalke: are you suggesting that the 0.20.x that has wtxid-relay should be held until 0.21 is released?
< wumpus>
yes, that's what he suggests
< MarcoFalke>
sdaftuar: I am asking if we should
< wumpus>
I think it makes sense
< jeremyrubin>
I think it should release whenever it's appropriate maybe? Because isn't there a benefit to having deeper backport penetration before 0.21 launches?
< sdaftuar>
that seems reasonabel to me as well, i hadn't consideredt hat
< sdaftuar>
i think we should get the other mitigation in sooner though
< MarcoFalke>
Not saying we must, but something to consider
< wumpus>
sdaftuar: definitely, it's different for the other one as it's not a feature
< jeremyrubin>
what about plugging in sdaftuar's minor mitigation into the one into current rc? Or is that bad to disrupt that flow?
< wumpus>
no
< sdaftuar>
jeremyrubin: it has 0 acks i think!
< sipa>
i think that would a serious violation of process
< sipa>
there is no bug to be fixed here
< sipa>
and no regression in the release
< sipa>
and it's not even in master!
< luke-jr>
one could argue wasting bandwidth is a bug
< wumpus>
0.20.1 is done, we've just decided that in last topic, it's reasonably urgent to get it released and ther ehave been no cricital problems, and anyhow, what sipa says
< sdaftuar>
no bandwidth is being wasetd now though
< sdaftuar>
well
< instagibbs>
it's not a regression except for the fact other nodes will be doing different behavior someday
< sdaftuar>
you know hwat i mean
< instagibbs>
maybe
< sipa>
it can go in 0.20.2
< wumpus>
yes
< instagibbs>
yeah i dont think there's a rush there
< sipa>
agree
< MarcoFalke>
agree with sipa
< wumpus>
again, please do not try to rush things
< sdaftuar>
agree with marco
< jeremyrubin>
I'm just trying to understand sdaftuar's comment that the mitigation goes in sooner
< sdaftuar>
into 0.20 branch
< jeremyrubin>
ah I thought you were meaning a 0.20.3 and 0.20.4 which seemed excessive
< jnewbery>
I don't think it matters that much which order they get merged into the 0.20 branch. 19620 is so tiny that conflicts aren't an issue whichever order things happen
< wumpus>
jnewbery: that's good to know
< sdaftuar>
jnewbery: i interpreted the delay of 0.20.x with wtxid-relay as a suggestion to hold off on the merge
< sdaftuar>
in case we needed another 0.20 minor release
< jnewbery>
My comment earlier about reviewing now was more about people reviewing when wtxid hasn't been paged out of their memory. Nothing about changing or rushing process
< sdaftuar>
and i was thinking that in that event, we might as well get the other mitigation out there since it's pretty easy
< jnewbery>
but if it interferes with the normal 0.20.x release process, then there's no problem waiting
< sipa>
jnewbery: that makes sense
< MarcoFalke>
Jup, good to have the backport open already, so that it can get review, but no rush in merging it
< sipa>
i can't remember if we ever made that consideration before - that a feature would appear in a backport release before a new major release
< sipa>
new features in backports are arguably rare in any case
< jeremyrubin>
I mean is wtxid relay really a feature or a architectural mitigation? You could argue it belonged in 0.13...
< sdaftuar>
feature
< jnewbery>
I don't think such semantic distinctions are very interesting. It's a large code change
< sdaftuar>
anyway i think we have a plan forward?
< sipa>
i think so
< wumpus>
yes
< sdaftuar>
i'll make some backports
< instagibbs>
great
< jnewbery>
sdaftuar: you mean 19620->v0.20 and 19620->v0.19?
< sdaftuar>
yeah
< sdaftuar>
thx for biting the bullet on wtxid-relay :)
< jnewbery>
sdaftuar: of course. It wasn't actually that bad
< jeremyrubin>
+1 fast work!
< wumpus>
any other topics?
< instagibbs>
reviewing it was also not painful at all fwiw
< sdaftuar>
is there a p2p focused irc meeting happening?
< instagibbs>
hint hint
< sdaftuar>
(you can make that a topic if you want, if not a one word answer)
< sipa>
jnewbery inquired if there was interest in one last week or the week before, iirc
< sipa>
haven't heard anything since
< jnewbery>
sdaftuar: yes. I said I'd figure out a way to schedule it but haven't done so yet
< jnewbery>
my preference would be for roughly the same time as this but on a different day, but that's perhaps unfair to some people who might want to attend
< sdaftuar>
ok, cool. +1 if we can get the timing to work out
< sdaftuar>
i have some p2p stuff i would love to discuss with others
< MarcoFalke>
Do it on Friday opposite bi-weekly of the wallet meeting ;)
< instagibbs>
we have us west, east, eastern europe, at least among contributors
< instagibbs>
for p2p
< luke-jr>
MarcoFalke: IIRC there's people who want to attend, whom this time does not work for
< ajonas>
Might want to check with AJ to see if he's interested
< jnewbery>
unfortunately it turns out the flatearthers were wrong and there isn't a time that's convenient for everyone
< luke-jr>
jnewbery: hmm, putting it that way.. can we modify the Earth to be flat? :P
< sdaftuar>
might be a consensus change
< sipa>
if the model doesn't fit the data, change the data
< troygiorshev>
likely people who this time won't work for aren't here right now to say it :)
< luke-jr>
troygiorshev: heh, true
< sipa>
troygiorshev: yes, that was my concern too with asking it here ;)
< sipa>
"Can everyone who is absent raise their hands?"
< luke-jr>
maybe ask at the opposite time review club meeting?
< jeremyrubin>
luke-jr: you should know that it's not a modification if you're changing it to how it already is
< luke-jr>
jeremyrubin: wut
< * jeremyrubin>
is a flat earther
< luke-jr>
…
< sipa>
i think this concludes the meeting?
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu Jul 30 19:55:20 2020 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< jnewbery>
action is still with me to figure out a time (/method for deciding a time). If anyone has suggestions or wants to help, feel free to message me
< instagibbs>
troygiorshev, im mentally going through a checklist of p2p constributors instead of asking here :P
< jeremyrubin>
just pick a time and move it forward by 30 minutes every time someone complains?
< sipa>
jnewbery: easy, whenever a block with a height that's a multiple of 2016 is mined
< luke-jr>
sipa: what is the drift on that?
< instagibbs>
yes we need more incentive to skew block times :|
< aj>
MarcoFalke: p2p meetings at 5am on saturday? thanks, i'll pass...
< fanquake>
heh
< bitcoin-git>
[bitcoin] Empact opened pull request #19631: test: Wait for 'cmpctblock' in p2p_compactblocks when it is expected (master...2020-07-receive_block_announcment) https://github.com/bitcoin/bitcoin/pull/19631