andrewtoth has quit [Remote host closed the connection]
andrewtoth_ has quit [Remote host closed the connection]
brunoerg has quit [Ping timeout: 268 seconds]
andrewtoth_ has joined #bitcoin-core-dev
bomb-on has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
gnaf has joined #bitcoin-core-dev
gnaf has quit [Quit: Konversation terminated!]
bomb-on has quit [Read error: Connection reset by peer]
bomb-on has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
<provoostenator>
The addrman documentation is pretty clear about when put stuff _into_ a "tried" bucket, but I'm having a hard time understanding when we actually use the tried bucket over the new bucket.
jarthur has joined #bitcoin-core-dev
<provoostenator>
Inside the Select() implementation it says there's a 50% chance of using the tried or the new table.
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
<provoostenator>
And Select() is called in net.cpp when making outbound connections. So that part makes sense.
<provoostenator>
IIUC in response to GetAddr we use both new and tried, but do check against IsTerrible?
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
gnaf has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
kexkey has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
kexkey has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
gnaf has quit [Ping timeout: 268 seconds]
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
bomb-on has quit [Quit: aллилѹіа!]
sipsorcery has quit [Ping timeout: 268 seconds]
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
bomb-on has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
gnaf has joined #bitcoin-core-dev
sipsorcery has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 264 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
<lightlike>
provoostenator: correct, Select() first flips a coin between new/tried, and then searches inside the respective table until it's found an address. GetAddr() picks randomly non-terrible addresses, it doesn't take care whether they are in new or tried
<provoostenator>
And addresses that we proactively gossip?
<sipa>
there is no such thing
<sipa>
we gossip addresses (a) our own, periodically (b) relaying addrs received from other peers (c) in response to getaddr
<provoostenator>
Right, I meant (b)
<sipa>
addrman isn't involved there
<provoostenator>
I see, not even a check against IsTerrible?
<provoostenator>
I first assumed we would only relay tried addresses, but that's obviously not so.
<provoostenator>
Presumably because then there'd be too few?
___nick___ has joined #bitcoin-core-dev
<sipa>
generally rumoured addresses wouldn't be things we already know
<sipa>
so perhaps you're suggesting is that rumoured addr messages should be drawn from addrman rather than from what we receive from others?
<sipa>
that's... not impossible, but very different from what we call relay
<provoostenator>
Not so much suggesting, but wondering why.
<sipa>
well the idea is that when you gossip your own address, the expectation is that it will generally reach a substantial fraction of the network nodes
<sipa>
not just your peers
<provoostenator>
It would indeed propagate very slowly if your peers first had to check it and their peers, etc.
<provoostenator>
R=0.0001 slowly :-)
<sipa>
idd
gene has joined #bitcoin-core-dev
<provoostenator>
So (b) is only done to serve (a)? (even though of course we can't check that it's not used to broadcast other stuff)
brunoerg has joined #bitcoin-core-dev
<sipa>
indeed, (b) is what makes (a) relay to the entire network
brunoerg has quit [Ping timeout: 260 seconds]
sipsorcery has quit [Ping timeout: 268 seconds]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] achow101 opened pull request #23417: wallet, spkm: Move key management from DescriptorScriptPubKeyMan to wallet level KeyManager (master...wallet-keyman) https://github.com/bitcoin/bitcoin/pull/23417
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
sipsorcery has joined #bitcoin-core-dev
satoshi has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
satoshi has quit [Quit: satoshi]
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 268 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
brunoerg has joined #bitcoin-core-dev
brunoerg has quit [Ping timeout: 260 seconds]
bitcoin-git has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] MarcoFalke opened pull request #23418: Fix signed integer overflow in prioritisetransaction RPC (master...2111-txPoolPrioOverflow) https://github.com/bitcoin/bitcoin/pull/23418
bitcoin-git has left #bitcoin-core-dev [#bitcoin-core-dev]
<shiza>
Those are tidy version numbers compared to bumping 0 to 22. But the beauty doesn't justify a revision of the topic.
<shiza>
Rolling back costs more than keeping forward.
<shiza>
Anyway, old wallets are going to start causing problems, so better warn users early that things are moving faster now.
<satoshi>
Would correct myself, the current version number should be Bitcoin 0.22.0. Reaching 0.99 is not that far in future, Reaching 1.0.0 would have the CLIENT_VERSION 1 million. It makes more sense to me, than reaching 99.0 in 15 years. This is not a rush for highest CLIENT_VERSION.
brunoerg has quit [Ping timeout: 264 seconds]
<satoshi>
CLIENT_VERSION would flip to a million in a few years from now. We should not do that, after us there will be many releases. It makes sense to keep the version format as it was otherwise the flip happens faster than it should.
<sipa>
CLIENT_VERSION _has not changed_
<satoshi>
it will change when reached 99.0
<satoshi>
CLIENT_VERSION will be 1000000
<sipa>
that's entirely orthogonal to the version naming discussion
<sipa>
The old version scheme was woefully obsolete; it had basically digressed into effectively being 0.MAJOR.MINOR, where the 0 was redundant. There were reasonable discussions to be had about whether that was sufficient to justify replacing it, and about what the new scheme should be. But we're not going to revert back to a older worse scheme. This discussion is pointless.
<sipa>
Version 0.0.1 of ZeroVer was published by Mahmoud Hashemi, with help from Moshe, Mark, Kurt, and other patient collaborators, on 2018-04-01. ZeroVer is satire, please do not use it. We sincerely hope no project release schedules were harmed as a result of this humble attempt at programmer humor.
<sipa>
It's making fun of projects that never manage to get rid of their 0-based version number.
<shiza>
bitcoincore.org source is public, you can propose fixes to it
<luke-jr>
would make more sense to bump to 22.0.1 for the first bugfix release instead of 22.1, but is it worth arguing? not so sure
<earnestly>
I'm surprised the satire wasn't obvious, those leading quotes are excellent
<earnestly>
Version numbers don't really need to mean anything. A single number that increases is usually enough. What does .1 add? All it signals is "This is a version you don't have to update to"
<earnestly>
Some add meaning like semver for API/ABI changes, etc. It's often not enough in practice and people end up doing version pinning through git checkouts
<luke-jr>
earnestly: it doesn't signal that; you need a way to express "fixes only" vs "new features"
<satoshi>
luke-jr I don't see any problem with that, technically 0.999.0 would produce CLIENT_VERSION 9990000. Bitcoin 2.1.0 would be 21000000.
<luke-jr>
earnestly: consider the recent 0.20.x release
<earnestly>
In both cases it's just indicating "You don't have to update"
<luke-jr>
earnestly: it's more important to upgrade for fixes (.1) than features (.0)
<earnestly>
I don't know anymore, I've spent so many years looking at this, and I just can't see it as a long term viable model. In the end it doesn't really matter and people do what they want
<earnestly>
But in general, and thankfully so, more people are realising that just keeping things up to date is a much better strategy than any notion of patching, backporting, etc.
radixrat has quit [Quit: leaving]
<luke-jr>
earnestly: it's not
<earnestly>
Considering backporting empricially doesn't even work
<shiza>
In a world that Bitcoin never hard forks itself, the leading 0 is unnecesary.
Guest67 has joined #bitcoin-core-dev
<luke-jr>
of course it does
brunoerg has joined #bitcoin-core-dev
<earnestly>
Not even redhat and debian can keep up with the CVEs, let alone the non-CVEs
<luke-jr>
shiza: the version is for Bitcoin Core, not Bitcoin
<earnestly>
That's how you get glibc GHOST
<luke-jr>
earnestly: nobody said backporting needs to be centralised
<earnestly>
So no, backporting is a fools game. Security researchers have been calling this out for over a decade now
<shiza>
I need more sleep, obviously.
<earnestly>
So, people are learning, slowly
<earnestly>
luke-jr: There is no backporting outside of people dedicated, and paid, to do so. Everything else is version pinning
<luke-jr>
earnestly: bleeding edge introduces new vulns
<earnestly>
This is true, it introduces unknowns. But addressing the knowns is more valuable
<luke-jr>
that's what backports do
<earnestly>
In theory this is true but in practice it doesn't pan out
<earnestly>
It could be one of those 80/20 things at best but even then it's not even close
<earnestly>
(And that's just for stuff which is open source, and backportable)
<shiza>
You are both right, unfortunately.
<luke-jr>
earnestly: are you saying Core 0.20.2 has known vulnerabilities?
<luke-jr>
what isn't panning out with it?
<earnestly>
I assume any non-trivial codebase has them
<earnestly>
backporting doesn't scale, it doesn't work as a strategy
<lightlike>
sipa: your zerover Issue seems unnecessary to me, Bitcoin is rightfully listed in the "Emeritii" section as a former member of the club.
<luke-jr>
0.20.2 is likely more secure than 22.0 (aside from the impending degradation of 0.20 due to Taproot)
brunoerg has quit [Ping timeout: 260 seconds]
<earnestly>
You can have a microcosm of developers and users maintaining backporting for a specific bit of software for some time but eventually they burn out and stop
<sipa>
lightlike: OH!
<luke-jr>
earnestly: it extends the lifetime
<shiza>
earnestly: a single active branch difficults planning upgrades
<luke-jr>
earnestly: it gives the newer versions more time to mature, and have their bugs worked out
<sipa>
Certainly backport releases get much less testing than master, and that's unfortunate. But we're also not going to stop creating backports. Sometimes new features actually unintentionally interfere with how the software is used by some.
<earnestly>
shiza: branch management is outside of it
<sipa>
earnestly: i really have no idea what you're talking about
<earnestly>
luke-jr: At the same rate it regresses the bug discovery rate as fewer use it
<sipa>
the project maintainers create backport releases, just along with new releases
<luke-jr>
earnestly: no, not the same rate
<earnestly>
Not all project maintainers do that
<shiza>
earnestly: no, if you only maintain master, distros can't keep up to it, and people is forced to compile compilers
<luke-jr>
earnestly: bugs discovered in 22.0 that predate it will get fixed in backports
<sipa>
earnestly: this channel is about Bitcoin Core development
<earnestly>
shiza: I'm not suggesting that
<sipa>
i'm not talking about anything else
<luke-jr>
^
<earnestly>
sipa: I'm only mentioning it to luke-jr, not you
<luke-jr>
earnestly: blaming backports because some people don't do backports, is nonsense
<earnestly>
I didn't blame backports for anything
<sipa>
certainly if nobody used the backport releases at all, we shouldn't make them
<earnestly>
Yeah, that sort of thing is completely up to you
<sipa>
but they are used; not nearly as much as new releases, but they see usage
<sipa>
earnestly: i have no idea what you're trying to argue for, or against, then
<earnestly>
Yeah, backporting and patches are still quite common for the time being
<luke-jr>
On another note, any idea if this is legit C++? namespace x { class y { static void z(); }; }
<luke-jr>
or do you need the full class definition?
<sipa>
luke-jr: legal
<luke-jr>
sipa: ty
<sipa>
you can have a "void x::y::z() { ... }" or "namespace x { void y::z() { ... } }" afterwards to provide the definition
<earnestly>
shiza: (fwiw, I did once make a distro with nothing but HEAD/tip versions of everything from glibc, mpfr, etc. to linux, ffmpeg, etc.)
<shiza>
earnestly: I understood your point (the second time)
<luke-jr>
earnestly: sounds like Gentoo with ACCEPT_KEYWORDS=⁑ :p
<earnestly>
luke-jr: (On a side note, I can't express how nice git (or any vcs) for providing a nice standard way to pull/clone/checkout all these repos)
<luke-jr>
sipa: what if x::y::z is private in the real class? :x
Kaizen_Kintsugi has quit [Remote host closed the connection]
Kaizen_Kintsugi has joined #bitcoin-core-dev
brunoerg has joined #bitcoin-core-dev
<sipa>
luke-jr: doesn't matter, afaict
<sipa>
private/protected/public is about access to members from other classes
<sipa>
it's not about where the implementation code can live
brunoerg has quit [Remote host closed the connection]
<satoshi>
Bitcoin 0.1.0 : static const int VERSION = 101; Bitcoin 0.3.0 : static const int VERSION = 300; Bitcoin 0.10.0 : return strprintf("%d.%d.%d", nVersion / 1000000, (nVersion / 10000) % 100, (nVersion / 100) % 100); Additional: https://github.com/bitcoin/bips/blob/master/bip-0014.mediawiki
<sipa>
satoshi: that change was made in release v0.3.13, in september 2010, by satoshi
<sipa>
BIP14 is about separating the protocol version from the implementation version
<sipa>
it's not dictating how implementations choose to set their version numbers (in fact, it's the opposite; it's letting them choose it independently from the protocol version number)
<sipa>
anyway, this discussion is going nowhere
<sipa>
at this point i'm going to assume you're a troll
<satoshi>
We talking about Bitcoin Core not the version number of Spesmilo.
<satoshi>
BIP 14 don't say that we should have 22.0, it is however referring to RFC 1945