Anthony Towns

Usual reasons not to retroactively fix style stuff are: - it makes it hard to follow history (git blame just points to the reindent commit for every line in the...

> related question: Is the sync state exposed anywhere via RPC? `getchaintips` showed nothing happening either. Seems like it might be good to at least report the per-peer value of...

> First of all, `ValidatedAndStoreRedownloadedHeader` indeed doesn't deal with the peer deciding to continue from one of the mixed-in locator entries, but it doesn't need to; we will, in the...

> Is that not what you're seeing? Here's some logs (for commit fc2e19e61261cedade18d1a5b9de2075523fa6aa merged onto 22d96d76ab02fc73e7fe0d810bacee4c982df085). I reset chainwork so that 1,156,000 testnet headers is enough. Peers 0 and 1...

> After seeing the discussion between @ajtowns and @sipa regarding bandwidth optimization involving what locators we send and how we process "skipping ahead" in our headers download (in the situation...

> this 25 descendants chain limit is only a configuration parameter on bitcoind, not a BIP 125 requirement Note that BIP 125 enforcement could be considered a configuration parameter too...

FWIW, I think of `s = x + H(R,P,m)*q` (where either `P != q*G` or `R != x*G` or both) as a "partial signature", so "partial validation" takes a tuple...

The ECDH implementation in openssl only reports "x" back to the user (and this seems to be what's recommended in NIST SP800-56A / 5.7.1.2 http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf and http://www.secg.org/sec1-v2.pdf ). That makes...

Is there a reason why discarding y in ECDH is risky? Hashing the ECDH-generated secret makes perfect sense to me (and it's something the openssl API directly supports, so seems...

apoelstra: yeah, that was pretty much what I came up with. which would have convinced me if no one else was implementing ECDH, but since it's only one bit of...