How length extension attack is possible here? The input of SHA-256 has constant
length of 512 bits in this scheme. And if someone will get some child public
key, there is still no way to reverse it to the parent public key, because even
if the second block of SHA-256 is the same all the times, t
So, things have to be complicated to be secure? By definition, using some
private key, calculating some public key from it and incrementing that key is
secure (it is definitely no worse than address reuse). The only problem with
using "privKey", "(privKey+1) mod n", "(privKey+2) mod n" and so on
Hi again Andrew and ZmnSCPxj,
I have dealt with the resources you provided me
Regarding Provisions I have concentrated my attention to Proof of assets
and I have to say it has been a good "exercise" for my ZKP learning
Regarding Jonas Nick code I'm not sure I would call it "a use of
Taproot"
Hi Erik,
Would sha256-hmac(nonce, publicKeyPoint) still be a suitable/safe alternative
without relying on sha3? That should at the very least eliminate length
extension attacks.
Best,
Arik
> On Mar 19, 2021, at 6:32 PM, Erik Aronesty via bitcoin-dev
> wrote:
>
> use sha3-256. sha256 suffer
On Fri, 2021-03-19 at 20:46 +0100, vjudeu via bitcoin-dev wrote:
> is it safe enough to implement it and use in practice?
This may be harsh but I can assure you that a HD wallet scheme that can
be specified in 3 lines (without even specifying what the security
goals are) should not be assumed safe
