< bitcoin-git>
bitcoin/master cea91a1 Luke Dashjr: Bugfix: GUI: Use unsigned long long type to avoid implicit conversion of M...
< bitcoin-git>
bitcoin/master c31bc5b Luke Dashjr: Consolidate service flag bit-to-name conversion to a shared serviceFlagToS...
< bitcoin-git>
bitcoin/master de369c7 Jonas Schnelli: Merge #18165: Consolidate service flag bit-to-name conversion to a shared ...
< bitcoin-git>
[bitcoin] jonasschnelli merged pull request #18165: Consolidate service flag bit-to-name conversion to a shared serviceFlagToStr function (master...svcflags2str) https://github.com/bitcoin/bitcoin/pull/18165
< bitcoin-git>
[bitcoin] promag opened pull request #19104: gui, test: Fix Cannot queue arguments of type size_t (master...2020-05-register-metatypes) https://github.com/bitcoin/bitcoin/pull/19104
< promag>
I was going to see if changing font fixes it
< hebasto>
jonasschnelli: not sure if I could test on my equipment
< jonasschnelli>
hebasto: good point. I wonder if the issue is also present on HiDPI ubuntu
< promag>
jonasschnelli: I can test that
< promag>
I'm getting
< promag>
CoreText note: Client requested name ".SFNSMono-Regular", it will get Times-Roman rather than the intended font. All system UI font access should be through proper APIs such as CTFontCreateUIFontForLanguage() or +[NSFont systemFontOfSize:].
< bitcoin-git>
[bitcoin] troygiorshev opened pull request #19107: p2p: Refactor, move all header verification into the network layer, without changing behavior (master...p2p-refactor-header) https://github.com/bitcoin/bitcoin/pull/19107
< bitcoin-git>
[bitcoin] hebasto opened pull request #19108: qt, refactor: Drop unneeded Q_DECLARE_METATYPE (master...200529-metatype) https://github.com/bitcoin/bitcoin/pull/19108
< vasild>
Assertion failed: detected inconsistent lock order at /home/vd/gh/bitcoin/bitcoin/src/sync.cpp:128, details in debug log.
< vasild>
Abort trap (core dumped)
< vasild>
hmm
< dongcarl>
Hey jonasschnelli, I wanted to confirm my overall understanding of the topology of the open PRs related to BIP324. Here?s my understanding:
< dongcarl>
- #14032 is an old PR that has many of its changes already merged, is superseded by jonasschnelli:2019/08/net_v2, and could potentially be closed. Question here: is there anything there that isn?t in jonasschnelli:2019/08/net_v2?
< dongcarl>
- #18242 -> #14032 seems to be the main line of progression
< dongcarl>
- #15197 + #15206 seem to be additional improvements that 1. Can be merged independently of the main line of progression, 2. Can help/simplify the implementation of BIP324. Question here: Could you give concrete examples as to how they help/simplify the implementation?
< dongcarl>
Sorry, some of my apostrophes got converted to question marks. *shakes fist at Synergy*
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #19110: test: Explain that a bug should be filed when the tests fail (master...2005-testBug) https://github.com/bitcoin/bitcoin/pull/19110
< jonasschnelli>
dongcarl: 14032 was an overview/concept. The only relevant PR now is 18242
< jonasschnelli>
15206/15197 are now BIP324 irrelevant
< jonasschnelli>
So as for BIP342, just focus on #18242
< 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
< jonasschnelli>
The rest are just relicts that might be a refactor/improvement on its own.
< jonasschnelli>
Once 18242 is merged,... I would like to "complete" it with the ECDH handshake (another mid size PR).
< jonasschnelli>
After that,... i could be enabled behind an experimental off-by-default runtime argument
< dongcarl>
jonasschnelli: I see, so after #18242, we need #14049, and then BIP324 handshake + BIP324 ECDH calc + BIP324 HKDF key deriv (last few commits from 2019/08/net_v2)?
< 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
< jonasschnelli>
Yeah. It needs 14049 with some actual handshake implementation. My remote branch you may look at could be outdated and if recent, it may only be the concept.
< dongcarl>
Sounds good, I think we're on the same page
< jonasschnelli>
HKDF is already implemented,... but not the actually symmetric key derivation from the ecdh_secret
< jonasschnelli>
But...
< jonasschnelli>
(there is always a but)
< dongcarl>
haha
< jonasschnelli>
BIP342 is still in discussion.
< jonasschnelli>
Questions came up about the missing MAC of the encrypted length field
< jonasschnelli>
(sipa eventually likes to take a deeper look)
< jonasschnelli>
I think it is fine since we use a different encryption context for it.
< jonasschnelli>
then... secondly, there are discussions about possible handshake upgrades with downgrade protection (which are currently not directly supported by the bip).
< jonasschnelli>
Thats the main reason why the BIP is still not submitted
< jonasschnelli>
(as well as the fact that the implementation often reveals conceptual issues)
< jonasschnelli>
despite the – eventually – altering BIP324, I think we can finalise the implementation and hide it behind an experimental runtime parameter.
< jonasschnelli>
(which will still allow changing it without users getting mad)
< dongcarl>
I see I see, I didn't see that discussion in the gist before, will take a closer look there.
< dongcarl>
any links to the discussions about downgrade protection?
< jonasschnelli>
I guess it is email only,... mainly real_or_random and sipa
< sipa>
i need to respond :)
< jonasschnelli>
We hoped for a coredev meeting to tackle it.
< jonasschnelli>
sipa: no hurry.
< sipa>
we've been talking to boneh about our authentication scheme as well
< sipa>
(a week or two ago)
< jonasschnelli>
the blind auth scheme?
< sipa>
yeah
< jonasschnelli>
okay... thats next step of next step. :)
< jonasschnelli>
sipa: do you think it could have implications for v2/BIP342?
< jonasschnelli>
or would it be more "on the top"?
< sipa>
it's why we think we need an upgrade mechanism in BIP342
< sipa>
so that the authentication can be done as part of the handshake, rather than as a application level thing later on
< jonasschnelli>
ah.. i see
< sipa>
but i think the upgrade mechanism can be very simple; just the connecting party sending a "i'm done; here is my hash of the session key"
< jonasschnelli>
Yeah. Would be great to have a place/time to discuss the upgrade mechanism
< sipa>
and the other side responding "ok, here is my hash"
< dongcarl>
is the blind auth scheme you guys are talking about just the new version of the single-party countersign?
< sipa>
anything else would be left unspecified, and close the connection
< sipa>
dongcarl: yes
< jonasschnelli>
I'll take it up soon (the upgrade mechanism) and will bother sipa and real_or_random with a concrete BIP change
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #19112: rpc: Remove special case for unknown service flags (master...2005-rpcServiceFlagsUnknown) https://github.com/bitcoin/bitcoin/pull/19112
< ariard>
jonasschnelli: fyi will host a Review Club session on seralizer/deserializer commits of #18242 in 2 weeks
< 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
< ariard>
will dig into the rational of MACIng the encrypted length field or not for the occasion