Good morning Omar,
BIP32 includes this text:
> In case parse_256(I_L) >= n or K_i is the point at infinity, the resulting
> key is invalid, and one should proceed with the next value for i.
This seems to suggest that it is possible for an attacker with sufficient
compute power to find two cont
Dear Gregory,
First of all, I would like to express my deep appreciation to your entire
craft in the FOSS ecosystem, specially in Bitcoin, even more In Blockstream.
I think you are a brilliant engineer and very principled leader. your
efforts are an inspiration for many, a truly enduring forever m
Hello Gregory,
Thanks for you feedback.
The BIP has been updated to explicitly specify the multiparty key
derivation scheme which hopefully addresses your concerns.
Please have a look at the updated draft of the BIP at the link below:
https://github.com/commerceblock/pay-to-contract-protocol-sp
Thank you for your time Gregory, I really appreciate that.
What we are describing here is a method to embed cryptographic signatures
into a public key based on HD Wallets - BIP32.
In a practical application, we should have two cryptographic signatures
from both sides, I don't think in that case yo
This construction appears to me to be completely insecure.
Say my pubkey (the result of the derivation path) is P.
We agree to contract C1. A payment is made to P + G*H(C1).
But in secret, I constructed contract C2 and pubkey Q and set P = Q + G*H(C2).
Now I can take that payment (paid to Q
Hey all,
A lot of us familiar with the pay to contract protocol, and how it uses
cleverly the homomorphic property of elliptic curve encryption system to
achieve it.
Unfortunately, there is no standard specification on how to conduct such
transactions in the cyberspace.
We have developed a basic
