earnestly has quit [Read error: Connection reset by peer]
earnestly has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake opened pull request #27484: doc: remove outdated version number usage from release-process (master...remove_leading_0_versions) https://github.com/bitcoin/bitcoin/pull/27484
test_ has joined #bitcoin-core-dev
bitdex has quit [Quit: = ""]
flooded has quit [Ping timeout: 250 seconds]
vysn has quit [Quit: WeeChat 3.8]
aielima has quit [Quit: Ciao]
vysn has joined #bitcoin-core-dev
pablomartin has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] furszy closed pull request #27478: wallet: bugfix, 'AvailableCoins' invalid output type set for raw PK outputs (master...2023_wallet_fix_p2pk_type) https://github.com/bitcoin/bitcoin/pull/27478
SpellChecker has quit [Quit: bye]
SpellChecker_ has joined #bitcoin-core-dev
vysn has quit [Quit: WeeChat 3.8]
vysn has joined #bitcoin-core-dev
vysn has quit [Quit: WeeChat 3.8]
vysn has joined #bitcoin-core-dev
vasild has joined #bitcoin-core-dev
<bitcoin-git>
[bitcoin] fanquake opened pull request #27485: [WIP] ci: standardize custom libc++ usage in MSAN jobs (master...msan_use_isystem_nostdlib) https://github.com/bitcoin/bitcoin/pull/27485
Guyver2 has joined #bitcoin-core-dev
Guyver2_ has joined #bitcoin-core-dev
Guyver2_ has quit [Client Quit]
Guyver2 has left #bitcoin-core-dev [#bitcoin-core-dev]
Anth0mk- has left #bitcoin-core-dev [#bitcoin-core-dev]
bugs_ has quit [Quit: Leaving]
<provoostenator>
BIP324 question: does key rotation require that both peers agree on which 224 they exchanged?
<provoostenator>
* which 224 messages
<sipa>
It happens in each direction independently, so there is need for agreement.
<sipa>
The sender rotates after sending 224 messages. The receiver rotates after receiving 224 messages.
<provoostenator>
I'm a bit confused how the new key is communicated / how the other side determines it. But I guess that's part of the FSChaCha20Poly1305 / FSChaCha20 standard?
<provoostenator>
Reason I'm asking is because I'm curious how difficult it would be to make this UDP-proof, if we ever want to use that.
<sipa>
There is no way to make this UDP compatible.
mudsip has joined #bitcoin-core-dev
<provoostenator>
Assuming you do the handshake of TCP. Is the rekey the issue? Or does everything have to happen in order?
mudsip has quit [Client Quit]
Talkless has quit [Quit: Konversation terminated!]
salvatoshi has quit [Ping timeout: 246 seconds]
puchka has quit [Quit: leaving]
salvatoshi has joined #bitcoin-core-dev
salvatoshi has quit [Remote host closed the connection]
<sipa>
@Sjors Everything happens in order, there are consecutively message ids. Even without rekeying there is no way to make this approach work for UDP.
<sipa>
You need a very different design for that
bugs_ has joined #bitcoin-core-dev
AaronvanW has joined #bitcoin-core-dev
TheRec has quit []
asoltys has quit [Ping timeout: 240 seconds]
<provoostenator>
Pieter: so if one message doesn't make it across, the counters would be out of sync and the connection is dropped? But that can never happen, because TCP guarantees the correct order and presumably would drop the connection if it can't?
preimage has quit [Quit: WeeChat 3.8]
flooded has joined #bitcoin-core-dev
test_ has quit [Ping timeout: 252 seconds]
<sipa>
TCP will just retransmit in that case
<sipa>
from the application's point of view, TCP is a bidirectional, reliable, stream of bytes
<sipa>
nothing can get dropped
pharonix71 has quit [Remote host closed the connection]
AaronvanW has quit [Remote host closed the connection]