andrewtoth has quit [Remote host closed the connection]
kevkevin has joined #bitcoin-core-dev
andrewtoth has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoincore.org] azuchi opened pull request #1050: Add japanese translations for security advisories in Bitcoin Core v22.0 (master...translate-security-advisories-22.0) https://github.com/bitcoin-core/bitcoincore.org/pull/1050
<glozow>
I see 2 topics proposed by fjahr, any last-minute ones to add?
<dergoegge>
hi
<josie>
hi
<sdaftuar>
hi
<tdb3>
hi
<glozow>
#topic package relay updates (glozow)
<darosior>
hi
<glozow>
#30110 is the priority PR - it's a lot of commits, but mostly just moving things out of net_processing, and then around 800 lines test code at the end. I've also rebased #20831 on top of it.
<instagibbs>
do you expect the mainline cluster mempool PR ready after the postlin/merge PR?
<sipa>
(nothing to add, carry on)
<Murch[m]>
hi
<sdaftuar>
instagibbs: not quite; we still need a reimplementation if the txgraph module before i take that out of draft
<instagibbs>
k
<fanquake>
"legacy wallet update since I won't be at the meeting tomorrow: Main PRs to review are #30328 and https://github.com/bitcoin-core/gui/pull/824. I will address the current review comments next week." from the scrollback
<fjahr>
Hi, so the Testnet 4 BIP and PR (#29775) seem pretty much final except for two remaining questions, I will post both because they are somewhat connected:
<fjahr>
1. Can we embed interesting scripts in the chains initial blocks and add a checkpoint? We can and I have been working on it but I think I won’t be able to finish it before the feature freeze due to travelling etc. I am still developing the tooling for this and will use it to put scripts into the chain, just not at the start of Testnet 4. But it will make it possible and ease the launch for an eventual Testnet 5. Do people
<fjahr>
think this is absolutely necessary and should delay merging Testnet 4? My opinion is clearly no and I have heard similar feedback but I wanted to make sure this has been brought up.
<pablomartin>
hey
<fjahr>
And 2. Do we need another reset before merging? I would say here the feedback is split. Had we gotten 1. done this would have made the reset necessary but some might still want it nonetheless. Personally I don’t see an issue with the “pre-mine” of 40k blocks. Many of these coins seem to be available through free faucets which makes it easier for anyone to get some right from the start. There is some distribution among
<fjahr>
several miners and it’s not clear to me if a more public re-launch gives us a fairer result. Maybe someone invests a bit more hashrate in order to get all of those first 40k blocks. And not resetting allows us to also set a min chain work as sjors mentioned on the PR. So I see more upside on not resetting personally but happy to discuss it.
<sipa>
I don't see the issue with "pre-mine". If testnet4 coins have no value, this is irrelevant. If they do, it has failed and we shouldn't continue with it anyway.
<fjahr>
sipa: yepp
<glozow>
fwiw I don't think reproducing interesting scripts should be necessary for starting a new testnet
<darosior>
i have not been following the work on testnet4 but regarding the first question, it doesn't seem crucial to me for weird scripts to be specifically at the very beginning of the chain
<sipa>
also agreed on not treating the interesting scripts thing as a blocker
<instagibbs>
darosior +1
Olsen has joined #bitcoin-core-dev
<stickies-v>
1. no I don't think this should hold up testnet4, this shouldn't be an inherent quality of a testnet, even though it'd be nice if they get added at some point
<sipa>
because once testnet4 is "active" it'll be much easier for people to contribute "interesting scripts" themselves
<darosior>
Yes good point
<jonatack>
fjahr: I agree with your suggestion on each point.
<tdb3>
same
<b10c>
where are you working on the "interesting script" part? I ran into a few recently that I might want to contribute/have in there
<fjahr>
the repo is here: https://github.com/fjahr/test_chain_init but I have done more that I haven't pushed yet, so please give me a bit of time, I can announce when it's ready for contributions
<b10c>
sure, will open an issue
<fjahr>
b10c: cool, thanks!
<glozow>
fjahr: should we move on to your next topic?
kashifs has joined #bitcoin-core-dev
<fjahr>
sure
<glozow>
#topic AssumeUTXO mainnet in v28 (fjahr)
<fjahr>
Here, I would like to ask for conceptual feedback on #30516 if others agree with maflcko that the metadata needs to be changed once more.
<fjahr>
And also I would like to ask for review of #29519 again
<gribble>
https://github.com/bitcoin/bitcoin/issues/29519 | p2p: For assumeutxo, download snapshot chain before background chain by mzumsande · Pull Request #29519 · bitcoin/bitcoin · GitHub
<fjahr>
Unless there are questions I think there isn’t much to discuss. A lot has been done on AssumeUTXO (see #29616) and I think we can add the mainnet params next week with a little more help. Thanks!
<maflcko>
fjahr: I'd say it doesn't need to be changed, but once the bug is fixed, the unused field seems clearer to remove, no?
<furszy>
fjahr: q: guess the time in which the interesting scripts are included is important due to feature activations? e.g. pre/post taproot activation.
<luke-jr_>
fjahr: #28598 shouldn't be considered optional
<gribble>
https://github.com/bitcoin/bitcoin/issues/28598 | assumeutxo: Ensure transactions are not presented as confirmed until background sync is complete · Issue #28598 · bitcoin/bitcoin · GitHub
<darosior>
luke-jr_: the feature is opt-in, if you are opting into using an "assumed and trusted utxo set" in the first place it doesn't seem critical
<fjahr>
maflcko: We added it without critical use initially and it got conceptual acks and review just a few months ago. The idea was that we could use it for something interesting later. I don't want to remove it unless more people agree with you that we don't want these future/uncritical uses anymore
<glozow>
Should we move on?
<fjahr>
yepp, thanks all!
<Murch[m]>
Oh, on the Testnet topic: the BIP is also close to getting merged, if you want to take a look
<darosior>
Can i get achow101's #22838? I think it's very close.
<gribble>
https://github.com/bitcoin/bitcoin/issues/22838 | descriptors: Be able to specify change and receiving in a single descriptor string by achow101 · Pull Request #22838 · bitcoin/bitcoin · GitHub
<glozow>
Sure. Wow, seems very popular.
<glozow>
Ok. Anything else to discuss?
<sipa>
#28280 is already on the list, and seems pretty close too (there are some open review comments, but none seem blockers)
<pinheadmz>
yeah like i said, lots of false positives
<pinheadmz>
the bot just helps out, its not the moderator
<pinheadmz>
but if someone is rude and bot doesnt pick it up thats something i need to adjust
<pinheadmz>
it usually thinks "crack <hash>" is some kind of threat :-P
<sipa>
vasild: i think the comments are marked off-topic on github due to the author having received a temporary ban, not because the ai bot thought they were offtopic
<pinheadmz>
s/ crACK
<glozow>
#endmeeting
<vasild>
so if somebody gets a temp ban all his comments on all issues and prs are marked off-topic? That seems a bit too aggressive?
<pinheadmz>
sipa vasild hm actually that does look like a partial misake
<pinheadmz>
there is an option in the ban dialog to hide all the authors comments (if its a massive spammer) but i didnt check that box for this guy
<sipa>
ah
<pinheadmz>
although a lot of comments on that thread are off topic ...
<kanzure>
can you give a summary of when a 24 hour ban in this project has actually been helpful?
<kanzure>
why not just actual bans
<pinheadmz>
so this might actually be a bug with github because this is not expected
<pinheadmz>
kanzure the policy dictates temporary bans to "cool off"
<kanzure>
also, i don't think that arguing is productive in /meta - i think it is more important to say what you are going to do, then do it.
<pinheadmz>
with increasing duration. 1 day then 2, then 4 etc
<pinheadmz>
i dont think we want permananet bans, someone might be a jerk today but have a real issue next week
<kanzure>
i have already registered my criticism of having a policy-- just ban who you need to ban.
<pinheadmz>
re: arguing in meta... could you elaborate?
<kanzure>
sorry but that's not how anonymous contributions work! identity is costless.
<kanzure>
if they have a real issue next week then they can report it anyway regardless of their ban
<instagibbs>
b10c something I've noticed for a while is my non-listening node seems to have much higher % round-trips for compact blocks vs my listening node. I havent thought deeply about this but wondering how expected this is
<instagibbs>
65% 0.5RTT completion(non-listening) vs 92% on my listening node
Olsen has quit [Quit: Client closed]
pablomartin has quit [Ping timeout: 248 seconds]
andrewtoth has quit [Remote host closed the connection]
pablomartin4btc has quit [Ping timeout: 260 seconds]
jarthur has joined #bitcoin-core-dev
kashifs has quit [Quit: Client closed]
<gmaxwell>
instagibbs: I'm 85% sure it's because your listening node gets mass connected by someone who is forwarding transactions that a stock core node wouldn't.
<gmaxwell>
instagibbs: either just running fullrbf on, or doing some kind agressive forwarding.
<sipa>
rejected transactions make it into the reconstruction cache, right? so even being fed transactions you reject may suffice with improving reconstruction
<gmaxwell>
sipa: it does, but there are so many now that the default extrapool is way too small.
<sipa>
right, it'd need to be done aggressively to avoid being cycled out before the block is found
<gmaxwell>
In tests I got people to perform I had them enable fullrbf OR massively increase the extrapool size. Both improved reconstruction rates (though fullrbf appears to do a little better) but only on listening nodes, outbound only continued to have miserable reconstruction rates-- which is I presume because no one ever forwarded them the required txn.
<gmaxwell>
also the number of missed txn is pretty extreme, for blocks that have any misses on an outbound only node the average number missed is currently 97 txn over the last 288 blocks.
<gmaxwell>
which I think would be somewhat difficult to fix via improved block relay protocols.
<instagibbs>
interesting
Talkless has joined #bitcoin-core-dev
pablomartin4btc_ has quit [Ping timeout: 245 seconds]
<instagibbs>
and yes distribution of misses for me is like 0, 1, or MANY
Talkless has quit [Ping timeout: 260 seconds]
pablomartin4btc_ has joined #bitcoin-core-dev
<gmaxwell>
I suspect that if you took an inbound node and made an effort to block all mass connectors the reconstruction rate would drop again.
pablomartin4btc_ has quit [Ping timeout: 252 seconds]