public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: CryptAxe <cryptaxe@gmail.com>
Cc: "bitcoin-dev@lists.linuxfoundation.org"
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Two Drivechain BIPs
Date: Fri, 08 Dec 2017 10:40:11 -0500	[thread overview]
Message-ID: <gfGMVSmvpcb-lCCILymGhiCS0iI8szcxLyjDsPqfbsolY1u49TL2pcyojqk0DMWF_g_rvzqGn8eS2ROWqCoAed4UHLQE06x6GZxUNS5qywg=@protonmail.com> (raw)
In-Reply-To: <d293b884-5f28-d2db-d7b6-860ee7b17703@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3756 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4642 bytes --]

  reply	other threads:[~2017-12-08 15:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-01 18:38 [bitcoin-dev] Two Drivechain BIPs Paul Sztorc
2017-12-03 21:32 ` Matt Corallo
2017-12-04 19:05   ` Paul Sztorc
2017-12-04 19:36     ` Chris Pacia
2017-12-04 20:11       ` Chris Stewart
2017-12-05 19:55         ` Paul Sztorc
2017-12-07  7:28           ` ZmnSCPxj
2017-12-12 22:16             ` Paul Sztorc
2017-12-05 18:05       ` Paul Sztorc
2017-12-05 18:20         ` AJ West
2017-12-06  4:49         ` ZmnSCPxj
2017-12-06 20:51           ` CryptAxe
2017-12-08 15:40             ` ZmnSCPxj [this message]
2017-12-12 22:29           ` Paul Sztorc
2017-12-14  3:24             ` ZmnSCPxj
2017-12-05  7:41   ` Luke Dashjr

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='gfGMVSmvpcb-lCCILymGhiCS0iI8szcxLyjDsPqfbsolY1u49TL2pcyojqk0DMWF_g_rvzqGn8eS2ROWqCoAed4UHLQE06x6GZxUNS5qywg=@protonmail.com' \
    --to=zmnscpxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=cryptaxe@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox