Good morning CryptAxe,

I have come to realize that P2PKH is powerful enough to write a Theft Contract from which other Accomplice Contracts can derive.

The core of the Theft Contract and the Accomplice Contract is that they are both HTLCs. The difference is that the Theft Contract, the timelock is anyone-can-spend after the time limit. The Accomplice Contract is an ordinary HTLC.

However, P2PKH, plus an off-chain method, can be combined to form a HTLC with anyone-can-spend after the timelock.

P2PKH includes <pubKeyHash>. Spending from a P2PKH reveals the preimage to <pubKeyHash>, the public key. Thus, the Accomplice Contract can use the P2PKH <pubKeyHash> as the hash, and when the P2PKH is spent, acquire the public key to be used as the preimage of the hashlock.

The remaining ingredient is a timelock with anyone-can-spend after the time limit. And I belatedly realized that I have in fact seen an offchain method of imposing a timelock on information: https://www.gwern.net/Self-decrypting-files To create a timelock, the "mastermind" thief encrypts the private key to the P2PKH in such a timelocked-encryption scheme, and publishes it as part of the theft attempt to commit themselves to the timelock, together with a zero-knowledge proof that the timelock-encrypted private key is correctly the private key to the given public key hash (I am not mathematically gifted enough to know if such a proof if possible, however, and if this is impossible, then this entire scheme cannot work). Thus, if the thief does not spend the P2PKH (which reveals the preimage to the hash, which unlocks the Accomplice Contracts and pays the accomplices), then someone else can grind the timelock-encryption and spend the P2PKH (and also incidentally unlocks the Accomplice Contracts anyway).

Of course, timelock-encryption is significantly less reliable as a time measure (different sequential processing speeds yield different timelocks from the same timelock-encrypted data), but that may be enough to have a reasonably trustless Thief-Accomplice coordination structure.

Another issue is that if the Accomplice does not cooperate and the theft fails, the Accomplices may still grind the timelock-encryption and acquire the private key, from which they can compute the public key, which is also the preimage to their hashlock. So there may not actually be an incentive to coordinate with the Thief under this structure. But perhaps this idea may trigger someone else to consider how to exploit the precise mathematics of P2PKH to create something similar to a HTLC.

-------- Original Message --------

Subject: Re: [bitcoin-dev] Two Drivechain BIPs

Local Time: December 7, 2017 4:51 AM

UTC Time: December 6, 2017 8:51 PM

From: bitcoin-dev@lists.linuxfoundation.org

To: bitcoin-dev@lists.linuxfoundation.org

On 12/05/2017 08:49 PM, ZmnSCPxj via bitcoin-dev wrote:

This vulnerability can be fixed if withdrawals are restricted to

simple P2PKH or P2WPKH only,

Limiting the withdrawal outputs to P2PKH and perhaps P2WPKH (would there

be any network benefit to supporting witness pubkeys for withdrawals?)

wouldn't be too much work for me. The downside is that people might want

to withdraw to multisig scripts, or any other legitimate P2SH. If it

prevents a huge issue, then it is probably worth it.

but in the presence of Scriptless Script and Bellare-Neven signatures,

that may be sufficient to create the Theft Contract and the Accomplice

Contract (but I know too little of Scriptless Script to be sure).

I'm curious if anyone on this list could help answer this.

bitcoin-dev mailing list

bitcoin-dev@lists.linuxfoundation.org

https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev