public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Tier Nolan <tier.nolan@gmail•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] reviving op_difficulty
Date: Mon, 17 Aug 2020 05:04:42 +0000	[thread overview]
Message-ID: <Y9rFseQ13QJ0TspORM_a542mUib8lJV2IiDe8GXS5SrxkvXbVI13MfbgGqVoSVftumcYNBBKut6Fz840ehS5VfvF2AsO_qNTyzvs6tTCpBk=@protonmail.com> (raw)
In-Reply-To: <CAE-z3OVCcAL2x39TswA8zrZ+yjSqdx4hccTWn9Ug8MQ5=k-Pgg@mail.gmail.com>

Good morning Tier, Thomas, and aj,

> On Sun, Aug 16, 2020 at 4:50 PM Thomas Hartman via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> > My understanding is that adding a single op_difficulty operation as
> > proposed would enable not true difficulty futures but binary options
> > on difficulty.
> >
> > https://en.wikipedia.org/wiki/Binary_option
>
> Any kind of opcode is a binary option.  Either the output can be spent or it can't.
>
> You could get a pseudo-continuous future by having lots of outputs with different thresholds.
>
> Alice and Bob create a transaction with 100 outputs and each having 1% of the future's value.
>
> Output 0:  Pay Alice if diff < 1.00 trillion else Bob
> Output 1:  Pay Alice if diff < 1.01 trillion else Bob
> ....
> Output 98:  Pay Alice if diff < 1.98 trillion else Bob
> Output 99:  Pay Alice if diff < 1.99 trillion else Bob
>
> If the difficulty is 1.25 trillion, then Alice gets outputs 0-24 and Bob gets outputs 25-99.  The future has a tick size of 1%.  It isn't very efficient though

Taproot MAST to the rescue.

* Alice and Bob agree on the number of ticks N and payout schedule.
* Alice and Bob generate N fresh keypairs and share them.
* Alice and Bob generate tapleaf scripts of the form:
  * script[i] = Alice[i] && Bob[i] && diff < 1.00 trillion + i * tick_size && CLTV(deadline)
* Alice and Bob generate the taproot MAST for the above scripts.
* Alice and Bob generate, but do ***NOT*** sign, a funding transaction paying out to the generated taproot MAST.
* Bob generates partial signatures for N payout transactions, with lower-difficulty-targets paying out less to Alice and more to Bob, and higher-difficulty-targets paying out more to Alice and less to Bob.
  * This requires spending the [i]th tapleaf script with the appropriate difficulty target.
* Alice saves all the Bob signatures.
* At deadline, Alice rationally selects the highest-paying version that is still acceptable, based on the actual difficulty target at the time.

This requires publishing only O(log N) data (the merkle path to the selected tapleaf).
This translates to the 100-tick example requiring only one TXO, 1 scripthash, and 7 or so Merkle-tree-path hashes, compared to the above example which requires 100 TXOs and 100 script hashes.

The same scheme can be used with `OP_CTV` and without keypairs being involved, but basically anything `OP_CTV` can do, signing keypairs with pre-generated signatures from all participants can do just as well, with higher storage and setup costs.

Regards,
ZmnSCPxj


  reply	other threads:[~2020-08-17  5:04 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-16 15:41 Thomas Hartman
2020-08-16 18:59 ` Tier Nolan
2020-08-17  5:04   ` ZmnSCPxj [this message]
2020-08-17 19:48     ` Thomas Hartman
2020-08-17 23:14       ` ZmnSCPxj
2020-09-01 20:07         ` Thomas Hartman
2020-09-02 14:40           ` Thomas Hartman
2020-08-17 21:55     ` Tier Nolan
2020-08-19 21:15   ` Thomas Hartman
2020-08-19 23:32     ` Thomas Hartman
2020-08-16 22:29 ` Anthony Towns
2020-08-22 16:46 ` David A. Harding
2020-09-02 18:27   ` Jeremy

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='Y9rFseQ13QJ0TspORM_a542mUib8lJV2IiDe8GXS5SrxkvXbVI13MfbgGqVoSVftumcYNBBKut6Fz840ehS5VfvF2AsO_qNTyzvs6tTCpBk=@protonmail.com' \
    --to=zmnscpxj@protonmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=tier.nolan@gmail$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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