<bitcoin-git>
bitcoin/master ff945e5 Samuel Dobson: MOVEONLY: Move utility functions from rpcwallet to wallet/rpc/util
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] MarcoFalke merged pull request #23640: MOVEONLY: Move helper functions from rpcwallet to wallet/rpc/util (master...202111_split_walletrpc_util) https://github.com/bitcoin/bitcoin/pull/23640
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
jarthur has quit [Quit: jarthur]
sdfgsdfg has joined #bitcoin-core-dev
goatpig has joined #bitcoin-core-dev
sdfgsdfg has quit [Quit: ZzzZ]
brunoerg has joined #bitcoin-core-dev
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] meshcollider opened pull request #23647: Split rpcwallet into multiple smaller parts (master...202111_split_walletrpc_total) https://github.com/bitcoin/bitcoin/pull/23647
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
smartin has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
dougefish has quit [Ping timeout: 252 seconds]
Guest70 has joined #bitcoin-core-dev
Guest70 has quit [Client Quit]
goatpig has quit [Ping timeout: 256 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
goatpig has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Remote host closed the connection]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] dougEfresh opened pull request #23648: test: Add functional test for -maxuploadtarget with byte unit '1M' (master...test-byteunit-maxuploadtarget) https://github.com/bitcoin/bitcoin/pull/23648
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] dougEfresh closed pull request #23584: test: Adding functional test for -maxuploadtarget with byte unit 'M' (master...maxuploadtarget-functional-byteunit) https://github.com/bitcoin/bitcoin/pull/23584
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
flooded is now known as _flood
Zayn has joined #bitcoin-core-dev
Zayn has left #bitcoin-core-dev [#bitcoin-core-dev]
sdfgsdfg has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
Kaizen_Kintsugi has quit [Remote host closed the connection]
Kaizen_Kintsugi has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
<laanwj>
dongcarl: it depends on translatability of the error message; if it's general enough: say, someone with basic knowledge of bitcoin internals can understand it, it should be translated
<laanwj>
dongcarl: on the other hand if it's a message about some internal failure scenario then it shouldn't be, it would just confuse and demotivate translators and result in sub-par error messages
<laanwj>
but that's the reason to have the *option* of passing a translation string in
<b10c>
TLDR: buggy patches to their peer selection. An unmaintained heuristic filtered newer Bitcoin Core peers. But, (IMO) unpublished patches are out of scope for the Bitcoin Core project.
<b10c>
However, with currently only ~50% of nodes upgraded, it could still be relevant to warn node operators about e.g. only being connected to peers old that don't relay P2TR spends.
<sipa>
a first question is: how would this even be detectable
___nick___ has quit [Ping timeout: 256 seconds]
<b10c>
Something like this could be a feature we want before the next soft-fork affecting transaction relay.
<b10c>
sipa: right
<b10c>
Bump PROTOCOL_VERSION for soft-fork tx relay? service flag e.g. TAPROOT_RELAY? Flag in the version message indicate soft-fork readiness?
<sipa>
but this isn't about softforks
<sipa>
it's about any change in relay policy
<sipa>
though, at least the past few years, the only invasive changes to relay policy (in bitcoin core at least) have been due to softforks, i think
<b10c>
and the next question would be: How to warn node operators (besides logging to debug.log)? getnodealerts/getnodewarnings RPC?
<sipa>
i think the best approach (assuming there was a way to detect it), would be to add more outgoing connections and/or rotate them faster
<laanwj>
we've become kind fo careful about warnings that are not relevant to most users
<sipa>
we kind of do something like that when we believe we're only connected to consensus-incompatible peers already
tru3nrg has quit [Quit: Connection closed]
<sipa>
but detecting is kind of ugly, i think... because it goes to concerns like should we try to inform our peers about the entirety of our relay policy?
<sipa>
and i'm not sure the problem is big enough of a concern to even get into that
<sipa>
relay policy is just policy, after all
<b10c>
hmm agree, if it would only be for soft-forks maybe a simple flag would be enough. but gets messy with the entirety of policy
brunoerg has joined #bitcoin-core-dev
<lightlike>
has this also been an issue in normal circumstances? The mailing list post talks about some artifical addnode scenario, extra automtic outbounds wouldn't help with that.
<laanwj>
i do think some heuristic would make sense when broadcasting, e.g. when you broadcast a transaction and no peer relays it back to you
mamilis has joined #bitcoin-core-dev
<sipa>
laanwj: that would be useful!
mamilis has quit [Client Quit]
<sipa>
though, that may not be sufficient for this case even
<b10c>
that would help in the sender case, not in the miner case
<sipa>
as it would only make the original tx broadcasters notice, not intermediaries
<b10c>
lightlike: I haven't heard about any other case
Guest92 has joined #bitcoin-core-dev
<sipa>
given that the first P2TR spends actually reached miners fine within a few blocks kind of shows there were no relay problems (that we know of)
<sipa>
and if it's just unfortunate local configuration on the miners side, i don't think this would do much, given what lightlike said
<laanwj>
peers witholding certain transactions from you is a subset of the general eclipse problem
Guest92 has quit [Client Quit]
<laanwj>
if you're worried about that, especially as a miner you'd likely want to make sure you connect to a few trusted peers (preferably over overlay networks)
brunoerg has quit [Ping timeout: 268 seconds]
<sipa>
b10c: oh i see, your assumption was that it would be warning operators, not just trying to fix things automatically
<sipa>
i think the only reliable way to warn operators is by shutting down...
<b10c>
that is definitely reliable for a mining pool, but also a DoS vector
<sipa>
indeed
<laanwj>
shutting down based on a heuristic about connected peers seems kind of drastic
<sipa>
yes, i only mentioned it in jest
<laanwj>
you can do that of course (a watchdog kind of script), but i see no reason to build that into bitcoin core
<b10c>
one idea was a RPC interface (e.g. getnodewarnings) to hook into from your monitoring stack
<b10c>
to at least have something well defined
<laanwj>
but if you have monitoring software, why not call getpeerinfo
<MarcoFalke>
there is already getblockchaininfo()[warnings]
<sipa>
yeah...
<laanwj>
i suppose all the information you need to decide about node versions is there
<laanwj>
it's never more than a heuristic, untrusted nodes can lie about versions, version bits, etc
<laanwj>
service bits*
<b10c>
cool, thanks! This discussion was helpful for me. Maybe a heuristic for a sender if his transaction got relayed back to him... Everything else might be to ambitious and messy
<sipa>
yeah i don't really have any good ideas
<b10c>
not relayed*
<laanwj>
(which is also what makes it somewhat scary as a built-in warning; i remember the spurious new-unsupported-version warnings with the block version bits when miners started using them for... other things)
<laanwj>
right
<laanwj>
any other topics?
<laanwj>
closing the meeting, thanks everyone for attending
<bitcoin-git>
[bitcoin] Baumgartl opened pull request #23658: contrib: add check for wget command in install_db4.sh (master...contrib-patches) https://github.com/bitcoin/bitcoin/pull/23658
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
Kaizen_Kintsugi has quit [Remote host closed the connection]
Kaizen_Kintsugi has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 252 seconds]
Kaizen_Kintsugi has quit [Ping timeout: 268 seconds]
Kaizen_K_ has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
Kaizen_Kintsugi_ has joined #bitcoin-core-dev
Kaizen_K_ has quit [Ping timeout: 268 seconds]
ZeroMaster has quit [Remote host closed the connection]
Kaizen_K_ has joined #bitcoin-core-dev
ZeroMaster has joined #bitcoin-core-dev
Kaizen_Kintsugi has joined #bitcoin-core-dev
Kaizen_Kintsugi_ has quit [Ping timeout: 268 seconds]
AaronvanW has quit [Remote host closed the connection]
<jamesob>
was there some merge causing unrebased PRs to start failing? seeing a lot of unrelated "TypeError: generatetoaddress() missing 1 required keyword-only argument: 'invalid_call'" failures in the functional tests for new PRs
littlesh has quit [Quit: Going offline, see ya! (www.adiirc.com)]