BIP proposal, Pay to Contract BIP43 Application

ZmnSCPxj raised concerns about the possibility of an attacker finding two contracts whose derivations alias each other and the possibility of multiple contracting systems. Omar Shibli responded to Gregory Maxwell's feedback with some fixes which he submitted on Github. Omar Shibli further expressed his opinion that the security fix was redundant. However, Gregory Maxwell found this construction insecure and mentioned a scenario where an attacker could take a payment made to one pubkey and assert it was a payment made to another pubkey.In August 2017, Omar Shibli shared his method for embedding cryptographic signatures into a public key based on HD Wallets - BIP32, in a trade finance application. He proposed defining various levels in BIP32 path to compute child public keys and addresses. He also provided an example of contract commitment address computation. However, Gregory Maxwell found this construction insecure and mentioned a scenario where an attacker could take a payment made to one pubkey and assert it was a payment made to another pubkey. Gregory also pointed out that the proposal did not address durability issues. Omar Shibli updated the BIP to address Gregory's concerns.The email thread includes a message from Omar Shibli expressing his appreciation for Gregory Maxwell's work in the FOSS ecosystem, particularly in Bitcoin and Blockstream. He also submitted fixes to Gregory's concerns regarding a security fix patch in the CKD function (BIP32) and requested his review. In another email, Omar shared an updated draft of a BIP specifying the multiparty key derivation scheme for the pay-to-contract protocol and sought feedback. Gregory had previously raised concerns about the security of the construction and durability issues which were not addressed in the proposal. Omar clarified the application of the construction, provided an example and updated the BIP to address Gregory's concerns. The full BIP draft is available on GitHub.A team has developed a basic trade finance application to conduct transactions using the Homomorphic Payment Addresses and the Pay-to-Contract Protocol paper. They have generalised it and made it BIP43 complaint. The team defines levels in BIP32 path as m / purpose' / coin_type' / contract_id' / *. Contract_id is an arbitrary number within the valid range of indices. Then, they define contract base as following prefix: m / purpose' / coin_type' / contract_id'. Contract commitment address is computed by hashing a document with a cryptographic hash function of your choice (e.g. Blake2), mapping the hash to partial derivation path and computing child public key by chaining the derivation path from step 2 with contract base. Payment address funds could be reclaimed only if the customer_contract_signature is provided by the customer. In terms of durability, their app is pretty simple at this point, they don't store anything, they let customer download and manage the files.The construction appears to be completely insecure, according to Gregory Maxwell. He believes that this is because the pubkey is easily manipulated. The team updated the BIP to explicitly specify the multiparty key derivation scheme, which they hope will address Maxwell's concerns. The BIP draft can be found on GitHub. Omar, from the team, thanks Gregory for his feedback and welcomes any further feedback.The email conversation is about a method to embed cryptographic signatures into public keys based on HD Wallets - BIP32. The application uses two cryptographic signatures from both sides for practical purposes. The proposed construction includes contract base, payment base, and payment address which can only be reclaimed by the customer_contract_signature. The current application is not very durable as it doesn't store anything, instead, the customer downloads and manages the files. Gregory Maxwell raises concerns about the security of the construction, its applications, and durability issues. Omar Shibli describes an abstract idea where levels are defined in BIP32 path, contract_id is an arbitrary number within valid indices and contract commitment address is computed using a cryptographic hash function. He also provides an example to illustrate the process. The full BIP draft is available on GitHub, and they seek feedback to develop a standard.A developer named Omar Shibli has proposed a new method for conducting transactions using the Homomorphic Payment Addresses and Pay-to-Contract Protocol, which uses the homomorphic property of elliptic curve encryption to achieve payment. The proposal defines levels in BIP32 path and contract commitment address that is computed by hashing a document with a cryptographic hash function, partitioning the array into parts, converting each part to an integer in decimal format, and joining all strings with a slash. The proposal does not address security concerns around payment to contracts or durability issues when losing funds if the exact contract is lost. There is no standard specification on how to conduct such transactions in cyberspace, but developers hope this proposal will result in a standard for the benefit of the community. The full BIP draft can be found at the provided link.The pay-to-contract protocol