< hebasto>
wumpus: sipa: could block nicebbs on the GH?
< sipa>
hebasto: i'm not convinced that's spam
< hebasto>
ok, will try to translate it :D
< hebasto>
sipa: sorry for false alarming
< sipa>
np
< fanquake>
yea I don't think that's spam either
< ossifrage>
Should bitcoind be more aggressive in banning nodes that send high-hash or bad-diffbits?
< bitcoin-git>
[bitcoin] achow101 opened pull request #18855: tests: feature_backwards_compatibility.py test downgrade after upgrade (master...test-backcompat-updowngrade) https://github.com/bitcoin/bitcoin/pull/18855
< luke-jr>
ossifrage: no
< luke-jr>
ossifrage: we're already too aggressive
< sipa>
i don't see a good reason not to disconnect on invalid PoW, actually
< sipa>
that's unambiguously invalid, for as long as the protocol existed
< luke-jr>
disconnect != ban
< luke-jr>
though having difficulty coming up with a scenario where banning would be bad
< luke-jr>
oh, thought of one:
< luke-jr>
a hardfork to reclaim always-zero bits in the header
< luke-jr>
we'd of course reject the HF blocks, but we still want to share our best chain with such nodes
< luke-jr>
disconnection might be a problem there too
< sipa>
i think banning is desired behavior between nodes on different sides of a HF
< sipa>
to partition as quickly as possible, and not waste connection slots on either side with peers they disagree with
< luke-jr>
partitioning is bad and should not happen with a HF
< sipa>
?!
< luke-jr>
furthermore, it is at best a false sense of "security" since anyone can start a bridge later
< sipa>
there is nothing to bridge
< luke-jr>
sipa: I'm talking about real HFs, not scamcoins calling themselves HFs
< luke-jr>
also HFs that *only* make invalid blocks valid
< luke-jr>
in this example
< luke-jr>
so the HF'd nodes would always prefer the pre-HF chain
< luke-jr>
so long as they see it
< luke-jr>
and it's more work ofc
< sipa>
as long as no such HF is defined, there is no need to accomodate ot
< sipa>
right now, seeing a peer give you a block with invalid PoW is a sign that peer is, from your perspective, completely broken
< luke-jr>
I'm not suggesting accomidation, just not going out of the way to disconnect it..
< luke-jr>
outgoing connections, sure, since those are providing services to us primarily
< luke-jr>
but inbound connections are primarily for the sake of the other node
< sipa>
that's reasonable
< yevaud>
luke-jr: objectively, providing a connection to someone incoming who you know is on a different chain is a denial of service attack against them.
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #18855: tests: feature_backwards_compatibility.py test downgrade after upgrade (master...test-backcompat-updowngrade) https://github.com/bitcoin/bitcoin/pull/18855
< elichai2>
jonasschnelli: Hi, I'm trying to review #18242, and I don't get something, it looks like you use AAD a lot in relation with chacha(ie encrypting the AAD), why is that? traditionally AAD is Additional Authenticated Data (meaning not encrypted) and also `CHACHA20_POLY1305_AEAD_AAD_LEN = 3` is that because the AAD is always the length which is capped at 24bits?
< gribble>
https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
< elichai2>
I read the BIP again, and maybe I understand it now. you create 2 instances of chacha, `chacha_K1` and `chacha_K2` you encrypt the length of the data with `chacha_K1` and the data with chacha_K2`, but you use the encrypted `chacha_K1` length as the AAD of `chacha_K2`+Poly1305?
< elichai2>
* I read the BIP again, and maybe I understand it now. you create 2 instances of chacha, `chacha_K1` and `chacha_K2` you encrypt the length of the data with `chacha_K1` and the data with `chacha_K2`, but you use the encrypted `chacha_K1` length as the AAD of `chacha_K2`+Poly1305?
< jonasschnelli>
elichai2: hi
< jonasschnelli>
the AD is encrypted to keep the package length confidential
< jonasschnelli>
it's based on the openssh chacha20poly1305 protocol
< jonasschnelli>
and yes the AAD length is always 3 bytes.
< jonasschnelli>
23bits length plus 1 bit rekey flag
< jonasschnelli>
with encrypted package length, it makes the stream pseudo-random... and it would allow to pad random data (to obfuscate size-based package detection, which is not in the scope of the BIP though)
< elichai2>
oh, openssh does this whole encrypt the length separately?
< elichai2>
But do we really gain anything by encrypting the length? it will probably be really easy to see anyway
< elichai2>
I haven't realized this is almost 100% openSSH protocol, I thought only their impl was used not the protocol itself, thanks!
< jonasschnelli>
elichai2: expect the reusing of the AAD keystream and the 3byte length, it's very much then openssh version
< jonasschnelli>
*except
< elichai2>
you mean limiting the length to constant size 3 bytes?
< jonasschnelli>
that and mainly not throwing a way 60 bytes per AAD chacha round
< sipa>
i would be very surprised that the compiler emits an rdrand instruction anywhere without invoking a corresponding intrinsic, though
< sipa>
but that's specific to rdrand... e.g. the compiler will happily emit sse4 instructions for normal non-intrinsic c code when you compile with -msse4
< sipa>
so in general, you always want to move code that needs certain hardware assumptions to a separate module that gets compiled with those flags, and only invoke its functions after testing at runtime the feature is available
< vasild>
so there is room for improvement wrt the current inline assembly which assumes the instruction is present and if not would crash at runtime
< vasild>
although I guess the instruction is available on all platforms where bitcoin core is being run, otherwise somebody would have reported the crash
< sipa>
the current code is fine
< sipa>
InitHardwareRand checks whether the instruction is available at runtime, and GetRdRand is only called if it reports true in g_rdrand_supported
< vasild>
ah
< vasild>
I was looking at GetRdRand() in isolation
< sipa>
but if we'd compile the entirety of random.cpp with -mrdrnd, the compiler might also emit rdrand instructions in other functions (though i would be surprised if it did)
< sipa>
there are compiler-specific extensions that let you compile just one function with different hardware assumptions, but i'm not sure they exist for all compilers we support
< vasild>
"emit rdrand instructions in other functions" -- I don't get this, which other functions?
< sipa>
literally anything
< vasild>
if you have a function like `int f(int x) { return x * 2; }`?
< sipa>
if you compile a module with -mrdrnd it means the compiler assumes all code in that module will be run on hardware that supports the rdrand instruction
< vasild>
right
< sipa>
as i said, i wouldn't expect a compiler to do that for rdrand... it's a very specific purpose instruction that likely wouldn't be used unless you explicitly invoke it using an intrinsic
< vasild>
hmm, I see your point now
< sipa>
but for other target flags it absolutely will
< sipa>
elichai2: which arguably we told it it was fine to do
< elichai2>
right. but it's also a limitation of C and C++ that you can't always know what will be constantly evaluated and what will be in the global init
< sipa>
you totally can; constexpr keyword
< sipa>
only it doesn't work for vector registers :p
< vasild>
sipa: ok, thanks for the patience with explanations. I catch up slowly, but otoh tend to forget quickly...