JWK is a good option for representing public keys, for an Ed25519 key you would have something like this: { "kty":"OKP", "crv":"Ed25519", "x":"oF0a6lgwrJplzfs4RmDUl-NpfEa0Gc8s7IXei9JFRZ0" }
I don't think you'd need to target specific wallets, you'd probably just generate a ton of keys and match them against any known wallets.
It's been a while since I caught up on the BBR work, are there any ways to tweak the algorithm for cases where you want 'increased fairness' – ie. deferring to other data streams because the current one is a lower…
Wow, I knew it was using SCTP but I didn't know that was inside the DTLS channel. That seems like a lot of overhead.
The spec still says NewReno, but I believe Google are mainly using BBR, if not BBR v2.
JWK is a good option for representing public keys, for an Ed25519 key you would have something like this: { "kty":"OKP", "crv":"Ed25519", "x":"oF0a6lgwrJplzfs4RmDUl-NpfEa0Gc8s7IXei9JFRZ0" }
I don't think you'd need to target specific wallets, you'd probably just generate a ton of keys and match them against any known wallets.
It's been a while since I caught up on the BBR work, are there any ways to tweak the algorithm for cases where you want 'increased fairness' – ie. deferring to other data streams because the current one is a lower…
Wow, I knew it was using SCTP but I didn't know that was inside the DTLS channel. That seems like a lot of overhead.
The spec still says NewReno, but I believe Google are mainly using BBR, if not BBR v2.