From: "David A. Harding" <dave@dtrt•org>
To: Thomas Hartman <thomashartman1@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] reviving op_difficulty
Date: Sat, 22 Aug 2020 12:46:20 -0400 [thread overview]
Message-ID: <20200822164619.vh3rdmdqf6vlmcji@ganymede> (raw)
In-Reply-To: <CAHAXnDXhAFQHiBCJ=H=1ZGHdHWhgLh1rG3pCPR5o48ziZzV+zQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1873 bytes --]
On Sun, Aug 16, 2020 at 11:41:30AM -0400, Thomas Hartman via bitcoin-dev wrote:
> First, I would like to pay respects to tamas blummer, RIP.
>
> https://bitcoinmagazine.com/articles/remembering-tamas-blummer-pioneering-bitcoin-developer
RIP, Tamas.
> Tamas proposed an additional opcode for enabling bitcoin difficulty
> futures, on this list at
>
> https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg07991.html
Subsequent to Blummer's post, I heard from Jeremy Rubin about a
scheme[1] that allows difficulty futures without requiring any changes
to Bitcoin. In short, it takes advantage of the fact that changes in
difficulty also cause a difference in maturation time between timelocks
and height-locks. As an simple example:
1. Alice and Bob create an unsigned transaction that deposits their
money into a 2-of-2 multisig.
2. They cooperate to create and sign two conflicting spends from the multisig:
a. Pays Alice with an nLockTime(height) of CURRENT_HEIGHT + 2016 blocks
b. Pays Bob with an nLockTime(time) of CURRENT_TIME + 2016 * 10 * 60 seconds
3. After both conflicting spends are signed, Alice and Bob sign and
broadcast the deposit transaction from #1.
4. If hashrate increases during the subsequent period, the spend that
pays Alice will mature first, so she broadcasts it and receives that
money. If hashrate decreases, the spend to Bob matures first, so he
receives the money.
Of course, this basic formula can be tweaked to create other contracts,
e.g. a contract that only pays if hashrate goes down more than 25%.
As far as I can tell, this method should be compatible with offchain
commitments (e.g. payments within channels) and could be embedded in a
taproot commitment using OP_CLTV or OP_CSV instead of nLockTime.
-Dave
[1] https://powswap.com/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2020-08-22 16:47 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
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 [this message]
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=20200822164619.vh3rdmdqf6vlmcji@ganymede \
--to=dave@dtrt$(echo .)org \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=thomashartman1@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