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.
Regards,
ZmnSCPxj
-------- 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).
Regards,
ZmnSCPxj
I'm curious if anyone on this list could help answer this.
Thanks!
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
