Re: ECPoint compressed state and 1.64

The immediate problem is the changed API, for which we have to find
other solutions before upgrading to the security release.

Bitcoinj uses the ECPoint class to track the compression state of
pubkeys. The reason is Bitcoin addresses are a hash of their encoded
pubkey, so you get a different address wether you derive it from
compressed or uncompressed encoding. Since the payer pays to an address,
this state is relevant for if you can receive your money or not.


I'm already working on tracking compression state ourself, see
https://github.com/bitcoinj/bitcoinj/pull/1941
However due to regression potential of the these changes this can only
go to master, so the current release branch is stuck at BC 1.63.


On 22/10/2019 06.24, Peter Dettman wrote:
> Hi Andreas,
> Could you explain what the immediate issues are with upgrading? It
> sounds like there might be a misunderstanding about what changed.
> 
> The fundamental change was the removal of a (long deprecated) mechanism
> where an ECPoint would remember whether it was decoded from a compressed
> point encoding, and then default to that same format when
> ECPoint.getEncoded() was called.
> 
> We still support decoding end encoding of both compressed and
> uncompressed points, however when encoding the caller must indicate
> whether they want a compressed point encoding using the argument to
> ECPoint.getEncoded(boolean).
> 
> Regards,
> Pete Dettman
> 
> 
> On 21/10/19 7:15 pm, Andreas Schildbach wrote:
>> I understand that we should only use compressed pubkeys. However in
>> reality lots of uncompressed pubkeys are out in the wild and we still
>> need to interoperate with them. In the case of Bitcoin, they're frozen
>> into the blockchain. What's the recommended migration path for apps that
>> still need to deal with uncompressed keys?
>>
>>
> 
> 
>