1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
|
Return-Path: <dave@dtrt.org>
Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id AD4D4C0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 22 Aug 2020 16:47:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by whitealder.osuosl.org (Postfix) with ESMTP id 9C57987E2F
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 22 Aug 2020 16:47:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from whitealder.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id owxBEgo6tpbI
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 22 Aug 2020 16:47:33 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87])
by whitealder.osuosl.org (Postfix) with ESMTPS id 99F2D87E2B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 22 Aug 2020 16:47:33 +0000 (UTC)
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
(envelope-from <dave@dtrt.org>)
id 1k9Wfz-0006wk-Qj; Sat, 22 Aug 2020 12:47:31 -0400
Date: Sat, 22 Aug 2020 12:46:20 -0400
From: "David A. Harding" <dave@dtrt.org>
To: Thomas Hartman <thomashartman1@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200822164619.vh3rdmdqf6vlmcji@ganymede>
References: <CAHAXnDXhAFQHiBCJ=H=1ZGHdHWhgLh1rG3pCPR5o48ziZzV+zQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="l5bv5a6itujcvsvb"
Content-Disposition: inline
In-Reply-To: <CAHAXnDXhAFQHiBCJ=H=1ZGHdHWhgLh1rG3pCPR5o48ziZzV+zQ@mail.gmail.com>
User-Agent: NeoMutt/20180716
Subject: Re: [bitcoin-dev] reviving op_difficulty
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 22 Aug 2020 16:47:34 -0000
--l5bv5a6itujcvsvb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Aug 16, 2020 at 11:41:30AM -0400, Thomas Hartman via bitcoin-dev wr=
ote:
> First, I would like to pay respects to tamas blummer, RIP.
>=20
> 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
>=20
> https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg079=
91.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 multis=
ig:
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 se=
conds
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/
--l5bv5a6itujcvsvb
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl9BS9sACgkQ2dtBqWwi
adP+hxAAg7uPYPtIXTpa7H0+3sSrqcgNiXwbe52Pj0YTxgeb0f6TK4F/cvJ68zDE
oDHlep5kVopfvhVD1bq6+XB3RFrKHPGIq1gt1EtRrabAD5oD8VyqE/7vj4icwGUQ
k8yVPQyX6h/sdZJvB2GMMUXVL0Zq2Lkex63DSVHvaI42Damd7SCLqgRNwb0frr9E
PUea8BnBNb55dKWHI2RW3XVfnryp1FfudB+K3iKHpJ2h3C7osUCyx5d9sg+YPxKZ
9ShmJK2Qn5xhDnnJfYuSwT8mehJ8mO6YlrL/YQNcKGYhSOxFWXiVTGFWXgs6Jvip
DoEPN+c17bVLOjH1CfTacptMUoairrV6U4oawpgrJeMnGPq36zaCT94zV1yJGxaH
GODvAJIha+PSFRGzbT71geeHMxjc2qfjGhp8PqIBQz5NiBjdCC2DPwcKK0Uck2pz
34pf604XMTbLYYmBshQ19kfTQW3kzUi0lcLdShxkif9Ewov5MMqxmxKAtLGdbps2
V5TxBUnTc0d6n88encuKbiit3wAaWBA2rZl27YDwqWH0p5t3Cj8F3HaDP3FyWTp2
1d78yXk+61jkg4jCicSx7upReqX03gQcQ8PnOu18ULSluFc2fYeIC5X33moVWf2J
E4D6p3yVD7+SsXNqbjcUOVKoMd9rHEmYwzvtRkxyP0IVAWsXgkQ=
=Xt3l
-----END PGP SIGNATURE-----
--l5bv5a6itujcvsvb--
|
