< hebasto>
wumpus: yes, I think, as an error is "error while loading shared libraries: libxkbcommon-x11.so.0: cannot open shared object file: No such file or directory" during runtime
< shesek>
why does importmulti with timestamp=now sometimes result in a (short) rescan and sometimes does not?
< darosior>
shesek: iirc it always scan 2W of blocks?
< wumpus>
hebasto: yes that sounds like you need the runtime package; it is strange tho, that linking works apparantly but execution does not, is it different platforms maybe ? (e.g. arm versus aarch64)
< hebasto>
wumpus: it's linux 32bit, probably `libxkbcommon-x11-0:i386` is required
< jeremyrubin>
michaelfolkson: either way; I do think that more specific topics are beneficial for the core dev meeting given we're looking at a release in 1 month
< michaelfolkson>
jeremyrubin: Yup specific topics better
< amiti>
The PR is currently a draft & needs some cleaning up, but serves as a proof of concept. The goal is to reduce addr blackholes- aka relaying self advertisements to peers who are unlikely to continue relaying it to the network.
< amiti>
The approach defers initializing the `m_addr_known` for inbound peers until they send us an addr related message. Then, it uses the presence of the filter to decide if a peer is eligible for addr relay before forwarding addresses (in `RelayAddress`).
< amiti>
If something like this were to land into master, it would resolve my concern with the `disabletx` proposal, and #20726 / bip 338 could focus solely on transaction handling, while not having the addr blackhole concern block the end goal of increasing block-relay-only connections.
< amiti>
That said, avoiding addr blackholes is a standalone win for improving addr relay, and currently would apply to block-relay-only connections as well as light clients.
< amiti>
Also want to mention, I do think this patch would be simpler / safer on top of the net/net_processing addr refactoring that jnewbery is doing. So if anyone is interested in helping, you can review this PR or #21236.
< gribble>
https://github.com/bitcoin/bitcoin/issues/21236 | Net processing: Extract `addr` send functionality into MaybeSendAddr() by jnewbery · Pull Request #21236 · bitcoin/bitcoin · GitHub
< amiti>
That’s all! Let me know if you have any questions or feedback :)
< * michaelfolkson>
needs time to read
< sipa>
amiti: is there are risk of having both sides "wait" until they see an addr?
< luke-jr>
amiti types fast :P
< amiti>
def a risk, but shouldn't be a problem in the implementation
< amiti>
also there's asymmetry, we setup addr relay for outbound connections
< jnewbery>
in the current implementation, we'll always send our initial self-advertisement to outbounds
< amiti>
(other than block-relay-only)
< sipa>
not sure how i feel about making the assumption that a peer who doesn't relay addresses to us would be necessarily uninterested in getting them
< jnewbery>
if they want them, they can send a getaddr
< lightlike>
some peers might be blackholes by not actively sending addrs further, but they will still require addrs. should they use getaddr for that only?
< sipa>
jnewbery: ah, that's a good point
< aj>
sipa: we send GETADDR to our outbounds always, and consider inbounds non-blackholes if we receive GETADDR
< jnewbery>
i think it'd be strange if a node wanted addrs but didn't send a getaddr
< sipa>
that's fair
< ariard>
i need to think about how it might affect lightclients, not sure if they do addr-relay with any consistency
< wumpus>
light clients never do addr relay afaik
< amiti>
lightlike: yeah, I don't think we can prevent all situations of blackholing, but the patch should mitigate some normal usage patterns
< sipa>
if we're going to give addresses to a peer, we must assume they can relay them further
< luke-jr>
wumpus: but ideally they would
< jeremyrubin>
so to summarize; it's basically don't send addrs till they've been requested once?
< luke-jr>
or at least keep an addr db
< ariard>
wumpus: that's my memory too but ideally they should
< amiti>
jeremyrubin: yes but with the added clause of to inbound peers
< sipa>
you can't have a mode where you consider a peer both a blackhole, but still give them addresses... because such a state could be abused to bias addr relay
< jnewbery>
jeremyrubin: or if that peer has relayed an addr to us
< sipa>
so i think it's correct to only use as criterion does this peer _want_ addresses or not; not whether they're going to relay it further
< jeremyrubin>
sipa: +1
< jeremyrubin>
How much bandwidth does this save amiti?
< jamesob>
hi, sorry am late
< sipa>
jeremyrubin: i think it's mostly an attempt at avoiding black holing?
< amiti>
jeremyrubin: hm, I don't know. the motivation was more about addr relay than bandwidth.
< jeremyrubin>
I'm just trying to grok why we care
< jeremyrubin>
if it can't stop a malicious peer from becoming a black hole
< amiti>
its for reducing the total black holes
< jeremyrubin>
why do we care if a honest peer is a black hole?
< jeremyrubin>
so we don't advertise them or something?
< jnewbery>
jeremyrubin: not much bandwidth. At most we only send one addr message per peer every 30 seconds
< sipa>
jeremyrubin: because in general you assume the network has some minimal number of honest peers
< amiti>
so, a key component of addr relay is self advertisement. approximately once a day we announce our addr to each peer, and when we receive those messages from others, we relay to 1-2 peers
< aj>
jeremyrubin: we only choose a few peers to relay to every day via RelayAddress() don't want to pick ones that don't care about addresses
< sipa>
this doesn't have any effect if all your peers are intentionally-blackholing attackers
< amiti>
the idea is an ongoing trickle of announcing addrs
< jeremyrubin>
Ok I'm just trying to understand why we care about blackholes, which the PR could better motivate
< jeremyrubin>
I can take it out of band from the meeting though
< amiti>
jeremyrubin: has your question been answered here?
< sipa>
seems like a reasonable idea; maybe we can also discuss it further in a P2P meeting
< jnewbery>
sipa: right, this isn't effective against peers 'maliciously' not relaying your addrs, but I don't think anything can be, except a diversity of peers.
< sipa>
jnewbery: indeed
< jeremyrubin>
amiti: no; it's OK though. I just don't see which resource this is saving us
< jnewbery>
jeremyrubin: it's not saving a resource
< amiti>
its less about resource saving and more about addr propagation
< aj>
jeremyrubin: see net_processing::RelayAddress
< sipa>
jnewbery: it more a "you *definitely* don't care about addresses? ok, then i'll send them to someone else instead"
< jnewbery>
sipa: exactly
< amiti>
sipa: exactly
< amiti>
:)
< wumpus>
time for next topic?
< wumpus>
#topic Release timeline for Taproot activation and parameters (jeremyrubin)
< amiti>
yeah sounds good
< amiti>
thanks for the input!
< jeremyrubin>
ok, so we had a meeting on tuesday in ##taproot-activation
< jeremyrubin>
I posted notes to bitcoin-dev mailing list
< sipa>
amiti: i feel a comic coming up? :)
< jeremyrubin>
The outcome of that is that we're looking at a release with parameters in the next month, assuming there's not strong opposition for whatever reason
< amiti>
sipa: suggestions always welcome :)
< achow101>
didn't we have this discussion last week?
< jeremyrubin>
With respect to ST, we agreed that we should fix for a Novemeber 15th height regardless of release date/starttime
< michaelfolkson>
achow101: Updates, progress since last week
< jeremyrubin>
achow101: it didn't have sufficient heads up that a meeting was happening for it to be a respectful process
< sipa>
i'm planning to through all the activation related PRs for code review; new comments on what activation is actually appropriate
< sipa>
s/new/no/
< michaelfolkson>
+1 for a black hole amiti comic
< michaelfolkson>
Full nodes in outer space
< jeremyrubin>
can we keep it on topic?
< jeremyrubin>
Does anyone have any reservations with a release during April?
< wumpus>
summary from last week was: wumpus so summary re: taproot activation: aim for april 3 for 0.21.1rc1, review both PRs asap, please hold up merging conflicting PRs for now
< wumpus>
michaelfolkson: yessss
< achow101>
I think we can keep the timeline that we discussed last week
< aj>
are we aiming for taproot activation params in rc2 not rc1 then?
< wumpus>
aj: w-why
< achow101>
aj: rc1, but have space for an rc2 for other issues that may crop up
< luke-jr>
aj: no? rc1 should be a cnadidate..
< wumpus>
the aim should always be to get things into the first possible rc
< aj>
okay
< aj>
april 3 sounds very quick!
< wumpus>
planning for something to do in rc2 sounds really strange to me but dunno
< jeremyrubin>
Ok, wumpus does it seem that we can get rc1 by then?
< wumpus>
aj: yes it might be too soon
< wumpus>
jeremyrubin: to be honest? no
< michaelfolkson>
Are there any follow up PRs planned for either achow101 PR or aj PR? I think achow101 has said he plans at least one follow up. I think all of aj fuzzing PRs are merged?
< luke-jr>
jeremyrubin: aim for it, so the inevitable slip is a slip :P
< wumpus>
if you mean "can you go through the release process by then" sure, but it seems somewhat rushed, did we decide which of the two PRs to choose yet?
< aj>
wumpus: "by then" == "may 1st" ?
< achow101>
michaelfolkson: only followup is the activation parameters. other followups don't need backport
< michaelfolkson>
achow101: Ok cool
< jeremyrubin>
There's some question of which of the PRs. hence sep topic
< achow101>
actually april 10th for rc1 still keeps the timeline.
< wumpus>
aj: people are talking about *april 3*
< jeremyrubin>
w.r.t. the mid-MTP thing, the starttime is less sensitive than the stoptime
< aj>
wumpus: i think jeremyrubin's/##t-a's last timeline was rc1 out the door by may 1st?
< jeremyrubin>
so I don't think we need to worry that much about releasing with whatever start we want
< wumpus>
achow101: bumping it to april 10 does sound a bit more realistic
< luke-jr>
MTP was never a viable option to begin with
< BlueMatt>
wumpus: in the meeting there was also discussion of "it takes the time it takes, if it slips, ok, if it slips past mid-may, then we bump the eventual lock-in time, if it doesnt, then we always set activation to estimated-release + 1 week or so"
< jeremyrubin>
My suggestion was rc1 may 1st, starttime may 7th, 1st period signalling mid may
< wumpus>
aj: I was pasting from the conclusion of last week's IRC meeting, I do not know what was discussed elsewhere
< michaelfolkson>
Currently achow101 PR is entirely block height and aj PR is a mix of block height and MTP
< aj>
wumpus: aha, thanks
< BlueMatt>
so the timeline can and shoulld de dependent on when the release finishes, its not a "we have to get release by X"
< BlueMatt>
at least in the taproot-activation discussion
< jeremyrubin>
BlueMatt: sure, but we should set a schedule we're trying to keep
< achow101>
BlueMatt: yes, but also, deadlines are a motivator, even if they are fuzzy
< wumpus>
BlueMatt: that's the only thing that makes sense anyway
< jeremyrubin>
april 3 seems unrealistic
< sipa>
doesn't the start date needs wider coordination? like talking to miners and businesses to see if they're ready to deploy?
< BlueMatt>
if we dont know when the code gets merged, then we cant pick a day, until then, the schedule is merge + whatever.
< luke-jr>
sipa: if they aren't, they just don't signal
< wumpus>
'do a release at all costs' is a big nope to me
< jeremyrubin>
sipa: No; start date is not super sensitive IMO compared to stop date
< luke-jr>
sipa: but yes, wider coordination on startheight is important anyway
< sipa>
okay, not going to wade into that
< BlueMatt>
s/stop/activation/
< jeremyrubin>
activation is sensitive OTOH
< jeremyrubin>
the outcome of that was we'll project out a height for November 15th
< michaelfolkson>
It would be nice to announce a start height as early as we can
< michaelfolkson>
But not at expense of rushing
< jeremyrubin>
michaelfolkson: doesn't matter till it's in a release
< BlueMatt>
anyway, not sure there's more discussion to be had here - the code can be merged when its ready, until then, its just speculation
< wumpus>
was one PR chosen? is it clsoe to merge?
< jeremyrubin>
next topic?
< BlueMatt>
review the code, decide on the pr, and then talk again
< BlueMatt>
wumpus: nope, thats up to code review, mostly.
< jeremyrubin>
wumpus: (as in, next topic is about that)
< BlueMatt>
because, ultimately, no one could decide.
< wumpus>
we didn't even decide a PR yet? yes, I think this is pointless like this, let's move on
< sipa>
BlueMatt: nack
< luke-jr>
wumpus: yes, achow101's
< achow101>
both PRs are at one ack
< wumpus>
#topic How far do we want to backport BIP350/bech32m support? (sipa)
< BlueMatt>
sipa: to...?
< sipa>
i *really* dislike using "this things seems to get reviewed faster" as a criterion to decide how consensus changes will be activated
< luke-jr>
sipa: not sure why BIP350 would be eligible for backporting at all
< sipa>
there should be a clear proposal, with buy-in, and then we implement that
< BlueMatt>
sipa: nooooo, thats not what I was suggesting, I was suggesting a part of the criteria is what code reviewers think of it
< sipa>
BlueMatt: hmm ok
< wumpus>
sipa: right, I don't think it's great to have two competing PRs for this at all, I think it would make sense to choose one and close the other kind of asap
< michaelfolkson>
If you'd prefer entirely block height then you'd prefer achow101 PR. Please read my SE link on that
< BlueMatt>
as in, which one happens is basically "people are kinda fine with whatever, but if code reviewers feel strongly about one vs the other's safety in code, then we go with that"
< sipa>
i'm happy to do code review for all of them
< achow101>
luke-jr: presumably to allow sending to taproot without upgrading major release?
< luke-jr>
ST (with heights) has wide support; this MTP variant does not.
< wumpus>
it really doesn't make sense to discuss a timeline every week if there is no progress in that regard
< sipa>
but i'm not going to ack merging until it's clear which one is chosen
< ariard>
i've reviewed both, i've a preference for bip9-amendment, would review both anyway
< michaelfolkson>
I personally have a preference for a consistent use of block height across the activation mechanims
< ariard>
but better to focus on one
< michaelfolkson>
Mixing block height and MTP doesn't make sense to me
< michaelfolkson>
But as I said please read my SE post and suggest edits and improvements
< BlueMatt>
sipa: ultimately, there's....rather strong personalities who are stuck in the sand on picking one, but a small enough set of people and an equal amount on both sides, so deciding is gonna require code review deciding on code safety :/
< sipa>
sigh
< jeremyrubin>
wumpus: I agree, but then the most likely outcome is a UASF BIP lOT=true released before we agree on anything, which is precisely what certain people have NACKd
< jeremyrubin>
so it seems deleterious to not just decide on one or the other
< michaelfolkson>
I think reviewers can come to a view on block height versus a mix of block height and MTP perrsonally
< jeremyrubin>
Either can be compatible with a subsequent BIP8 release
< michaelfolkson>
jeremyrubin: Any UASF is entirely irrelevant to this discussion
< sipa>
i don't care about one or the other; i think all of this is a storm in a cup of water
< sipa>
just pick one ffs
< BlueMatt>
michaelfolkson: jeremyrubin please take it to taproot-activation.
< ariard>
sipa: thanks!
< wumpus>
if we want to get to to all the topics today, we should move on
< BlueMatt>
sipa: well, the people who show up in taproot-activation are....the people who feel the strongest and the most stubborn about it. without more voices there, there will be no agreement, sadly.
< ariard>
we should do a fair coins toss fwiw
< BlueMatt>
anyway, lets move on, this isnt the right venue to debate it.
< wumpus>
we can also discuss taproot for the rest of the meeting, of course
< luke-jr>
thought we were trying to give sipa the floor for BIP350
< wumpus>
~20 mins to go
< achow101>
re the actual topic: I think it makes sense to backport to 0.21 and 0.20
< gribble>
https://github.com/bitcoin/bitcoin/issues/21472 | BIP 350: Implement Bech32m and use it for v1+ segwit addresses (0.19 backport) by sipa · Pull Request #21472 · bitcoin/bitcoin · GitHub
< jeremyrubin>
I agree you should be able to pay addresses you see, even if you don't know how to create such an address
< sipa>
but it would be unfortunate if adoption (once activated etc) is hampered by the fact that you can't send to it from stable bitcoin core releases
< sipa>
i'm ok with 0.21 and 0.20
< luke-jr>
0.20 will be end-maint in Aug too
< wumpus>
well if he already made a PR for it, then I don't see why not to backport
< sipa>
also ok with just 0.21, if that's what we decide
< wumpus>
*if* we are going to do another 0.19 release is another question of course
< jnewbery>
I've reviewed 0.20 and 0.21. Both look good to me.
< sipa>
i just opened backports as far back as they were nontrivial
< luke-jr>
seems better to just limit to 0.21
< luke-jr>
I don't think anyone plans to backport Taproot itself to 0.20?
< luke-jr>
consensus code I mean
< achow101>
luke-jr: you don't need taproot in order to make taproot outputs
< wumpus>
luke-jr: that doesn't matter here, it's for sending to it
< wumpus>
might backport one release further for that
< jeremyrubin>
sipa: one question; if taproot doesn't activate can you still send to these addresses?
< luke-jr>
achow101: but if you're doing economic stuff, you should be using a full node
< jeremyrubin>
Might be kinda weird if you can pay to them before they activate
< jeremyrubin>
(that's true for next-release as well as backport)
< sipa>
jeremyrubin: being able to send to future addresses is pretty essential for smooth upgrading
< jeremyrubin>
sipa: you could only enable sending to them from wallet iff it activates and height > minactiveheight
< wumpus>
that would be weird but also, why would anyone do that
< jeremyrubin>
not sure, many ways to lose money I spose
< aj>
jeremyrubin: been able to send to them since 0.19 due to #15846
< jeremyrubin>
there is not community consensus on either one
< jeremyrubin>
IDK it's the topic again so I thought I'd summarize
< wumpus>
well you proposed two topics I don't know why
< wumpus>
if it's unnecessary let's move on
< BlueMatt>
i think we covered this pretty fully
< michaelfolkson>
I agree we need to break the deadlock on the two PRs asap. Spreading review effort over two PRs at this stage is not optimal
< sipa>
michaelfolkson: and we're not going to do that here
< wumpus>
#topic Windows code signing issues (achow101)
< achow101>
The windows code signing key expired yesterday. I've been trying to renew it, but somehow in that process, comodo revoked the key. This is causing users who install 0.20 or 0.21 on windows to be unable to run the installer
< wumpus>
uh oh
< aj>
yikes
< wumpus>
do you know why they revoked the key?
< bitcoin-git>
[bitcoin] sipa closed pull request #21472: BIP 350: Implement Bech32m and use it for v1+ segwit addresses (0.19 backport) (0.19...202103_bech32m_0.19) https://github.com/bitcoin/bitcoin/pull/21472
< achow101>
comodo has also changed how they are verifying the Bitcoin Core Code Signing Association which is making it harder to get the renewed key. jonasschnelli_ is working on that, but it could be a while
< achow101>
so it is possible that for the next release, we may not have a windows code signing key
< achow101>
and also we probably need to re-sign 0.20 and 0.21
< wumpus>
yes
< achow101>
I have no idea why the key was revoked
< achow101>
I emailed support and they haven't responded :/
< wumpus>
is it possible to install on windows without a signing key?
< achow101>
yes
< achow101>
there is a non-codesigned installer
< luke-jr>
but the codesigned one is a no-go?
< wumpus>
can we get a key from a different provider if comodo becomes difficult?
< luke-jr>
"it connects the graphical Linux applications via a Remote Desktop Protocol (RDP) connection to the main Windows display"
< luke-jr>
sounds ugly for end users
< wumpus>
luke-jr: anyhow this is off topic now
< wumpus>
achow101: ok
< luke-jr>
sorry
< aj>
was this the last topic?
< wumpus>
aj: I think so! I didn't expect to get this far but hadn't noticed the speedytrial one was more or less duplicate
< aj>
wumpus: great success!
< wumpus>
#endmeeting
< jnewbery>
speedymeeting
< jnewbery>
thanks wumpus!
< jeremyrubin>
it wasn't intended to be duplicate -- it does really help to break topics into smaller chunks so that you can build consensus on one part of the puzzle without needing the other
< sipa>
jeremyrubin: fwiw, the reason why sending to future addresses needs to be supported (at least as a relay policy) is that otherwise you force wallets to keep up with it (e.g. say some service supports withdrawals, and does batching, ... one customer gives a future address and another gives a current address... batching them together both payments get stuck)
< jeremyrubin>
sipa: yeah, noted. I think it's good as long as no one puts tools out to *generate* taproot addresses ahead of activation
< sipa>
jeremyrubin: this i think was a snafu with bech32 that resulted in it actually failing (basically nobody supported sending to future addresses, because they *had* to: relay policy didn't allow it either)
< jeremyrubin>
I could see there being confusion with "Taproot is locked in" and "Taproot is active"
< achow101>
dongcarl: yes
< jeremyrubin>
sipa: yeah I think in general you send to a bad address you pay the price is the best we can do
< sipa>
but i think the combination of support relay of sending to: always; support relay of spending: only when rules are active
< sipa>
is ideal
< jeremyrubin>
yeah I agree because you can be tricked into relaying bad txs after activation
< jeremyrubin>
so it makes sense to only relay spends you suspect you can fully validate
< wumpus>
jnewbery: yw!
< jeremyrubin>
yw?
< wumpus>
jeremyrubin: yes i understand your motivation for splitting it up, it just came as a bit of a shock just after the monster topic was concluded to see it come up again :)
< wumpus>
in any case, let's not make it a meeting topiuc again until at least the PR has been decided
< jeremyrubin>
wumpus: probably could have gone in reverse order
< jeremyrubin>
I was hoping that in the meeting, w.r.t. PRs, we could have discussed the practicality of reviewing/merging/backporting either
< jeremyrubin>
And if it fits in with the timeline being desired
< wumpus>
I think we need to do that after a PR has been decided
< wumpus>
with such a tight schedule it is a really bad idea to spread the time and resources over two PRs here
< jeremyrubin>
wumpus: I think the issue is that "people" have decided on a tight schedule
< jeremyrubin>
that's my only preference for AJ's PR
< jeremyrubin>
is if we are trying to meet that timeline or not
< aj>
jeremyrubin: fwiw, 21377 cleanly backports currently
< jeremyrubin>
aj: yep
< aj>
jeremyrubin: (modulo 21489, which also cleanly backports)
< wumpus>
this should make it at least possible to still install while we resolve the signign key issues
< hebasto>
jonasschnelli_: maybe `libxkbcommon-x11-0:i386` package for Linux32 build?
< jonasschnelli>
hebasto just saw that. Will add
< hebasto>
jonasschnelli: thanks
< harding>
wumpus: that breaks the links on https://bitcoincore.org/en/download/ ; is it possible to use the same file name, or is that just too problematic?
< harding>
(I can also change the link on the download page if you'd prefer that.)
< wumpus>
harding: that is a good idea but I don't feel like doing the entire process (like regenerate SHA256SUMS.asc) again
< wumpus>
let's just change the link
< harding>
wumpus: will do, thanks.
< wumpus>
also the -unsigned in the file name will likely alert people what to expect