summaryrefslogtreecommitdiff
path: root/4b/39d9a6e71464d3d6c1f5961e65c09f5b8c2ecd
blob: 80eae4ca1c8b6bf052aecfafef3f4fb7c6d9e3dc (plain)
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
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
Return-Path: <tamas.blummer@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 2D61BF73
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 May 2019 19:10:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com
	[209.85.128.52])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D67D1821
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 May 2019 19:10:57 +0000 (UTC)
Received: by mail-wm1-f52.google.com with SMTP id c77so6976013wmd.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Thu, 23 May 2019 12:10:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=from:message-id:mime-version:subject:date:in-reply-to:cc:to
	:references; bh=mi1GeUfcm5xZFf/TRp7WbuihSDJm/cX0vzLJ927tamI=;
	b=l1InZKRZRD+o9sVhwL0husY+9Y5p2fyreHq1SXEnSU5yVKvbItkp8VgKfdimdW8JuR
	TU+eLZBxhUtkeCnd3mHCZDPCg+pTyQq536x3qkDuSiywEOIw7Z/HCKD0tCfe+T07Q26s
	w+X+mjMzLkuR71SO27ZwVfNYkaeQkpczeeIr7lJcWBpfJ8qsxNAyOxuXxrz6eNKOve8L
	ARHlQKa7c6KDIJAuUZK6qvNvpKBpBBfpJISZrCMGiYsZc0w+e4m1vHJb5LdYr6HIxHMt
	a+Vci8W/UO+2qfT6CeJ4tX4ZkjsU8KB97AtgXlOh3X8mTNh5MvjF9G6Zm0nBwhnmo7p+
	kQYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:from:message-id:mime-version:subject:date
	:in-reply-to:cc:to:references;
	bh=mi1GeUfcm5xZFf/TRp7WbuihSDJm/cX0vzLJ927tamI=;
	b=qsqEAF7sp+FaeDn1k5UB77X5PWTuEtU6iZaGii4l3UJsrzvQxTsG1HOy5qAALb9K7x
	VfKP4BZ4RMXKpnl2bXd28zWDiUTlnZcn8q60Qtt1qY92AD+Sr/OrLtEKR60tQTHPjN6a
	bg7RN/uHOmXCbbkwuiamveWT959DZomN95dwlD0dLNtqKr9dd6OSztUdqZ2LN2TCRmWN
	OiL/eOuY7FExItxLs5x9jj6+hjNuMxNekpzNA8J5YhbRkFL7xAi103CErqEi713vZ2yk
	ojF3hdSUbo+pf7gz+yiE9NeWLUEb+4gDOL59ts600ljZXWRkEsWf91UdwYUU6Njj+vNa
	K3Ng==
X-Gm-Message-State: APjAAAVcqme/Pd5UTwq0RdLwj9m9pyoksj2q+IffmxEDRWipBjmqizuJ
	U4mqtSOt3J/XdJLR9xxfLNQ=
X-Google-Smtp-Source: APXvYqzqL4/lcNXqqCQ44dsYsQN/9q2ZSFtlvDwHHQBln7XfB24ZHgtbf+RJ0wziHPSH0m1RIpCMsA==
X-Received: by 2002:a1c:3d87:: with SMTP id k129mr13592709wma.21.1558638656462;
	Thu, 23 May 2019 12:10:56 -0700 (PDT)
Received: from p200300dd67196b11c120770d4d53396f.dip0.t-ipconnect.de
	(p200300DD67196B11C120770D4D53396F.dip0.t-ipconnect.de.
	[2003:dd:6719:6b11:c120:770d:4d53:396f])
	by smtp.gmail.com with ESMTPSA id q68sm333591wme.11.2019.05.23.12.10.55
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Thu, 23 May 2019 12:10:55 -0700 (PDT)
From: Tamas Blummer <tamas.blummer@gmail.com>
Message-Id: <31A492B1-AFDD-4A4D-AC2C-2020F8EF2954@gmail.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_5D2293EA-F66D-4935-9D12-5D444CF793AF";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 23 May 2019 21:10:53 +0200
In-Reply-To: <CABm2gDoFS=dNbqzEo+RcWb32Kx4QM7YHLxYLOG54a=RGR8rQcw@mail.gmail.com>
To: =?utf-8?Q?Jorge_Tim=C3=B3n?= <jtimon@jtimon.cc>
References: <CAD5xwhgHyR5qdd09ikvA_vgepj4o+Aqb0JA_T6FuqX56ZNe1RQ@mail.gmail.com>
	<42F53D61-BAAE-464F-BB0D-4D0CDC554D9A@gmail.com>
	<CABm2gDoFS=dNbqzEo+RcWb32Kx4QM7YHLxYLOG54a=RGR8rQcw@mail.gmail.com>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
	RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 23 May 2019 19:19:23 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets)
 without an oracle and 3rd party.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
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: Thu, 23 May 2019 19:10:59 -0000


--Apple-Mail=_5D2293EA-F66D-4935-9D12-5D444CF793AF
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

The parameter used is property of the block just like the block height =
is a property and is already evaluated in scripts,
so no new kind of dependency or encapsulation break.

The transaction itself was not invalid in a re-org but evtl. others =
spending it if the difficulty on that fork is different,
this is however intended as then on that fork the other was the winner.

Tamas Blummer

> On May 23, 2019, at 21:03, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
>=20
> The complains I could imagine about this, (apart from being a very
> specific use case) are the same complains I heard about op_expiry.
> Namely, that in a reorg, the same tx, having been valid in a given
> block could potentially become invalid in some other block mining it.
> I guess in this case the situation is less likely in this case than
> with op_expiry, but it is still possible.
> Another complain I could imagine is this kind of forces the
> implementation to break some existing encapsulations, but I guess
> those are just implementation details not that relevant here.
> I personally don't have strong feelings towards this proposal one way
> or the other, I'm just imagining what other people may complain about.
>=20
> On Thu, May 23, 2019 at 8:33 PM Tamas Blummer via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>=20
>> Difficulty change has profound impact on miner=E2=80=99s production =
thereby introduce the biggest risk while considering an investment.
>> Commodity markets offer futures and options to hedge risks on =
traditional trading venues. Some might soon list difficulty futures.
>>=20
>> I think we could do much better than them natively within Bitcoin.
>>=20
>> A better solution could be a transaction that uses nLocktime =
denominated in block height, such that it is valid after the difficulty =
adjusted block in the future.
>> A new OP_DIFFICULTY opcode would put onto stack the value of =
difficulty for the block the transaction is included into.
>> The output script may then decide comparing that value with a strike =
which key can spend it.
>> The input of the transaction would be a multi-sig escrow of those who =
entered the bet.
>> The winner would broadcast.
>>=20
>> Once signed by both the transaction would not carry any counterparty =
risk and would not need an oracle to settle according to the bet.
>>=20
>> I plan to draft a BIP for this as I think this opcode would serve =
significant economic interest of Bitcoin economy, and is compatible with =
Bitcoin=E2=80=99s aim not to introduce 3rd party to do so.
>>=20
>> Do you see a fault in this proposal or want to contribute?
>>=20
>> Tamas Blummer
>>=20
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


--Apple-Mail=_5D2293EA-F66D-4935-9D12-5D444CF793AF
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAlzm8D0ACgkQ9nKRxRdx
ORzZXgf/e/nH1YsPgW1IFZI7aGaACXFCc+hlvtcuWpfY7nN2bzkgqdrX5m0aP5O0
HSzuMXCOh0QkhxFCYtg7bl7gjJDf+BfahwLVRRAIkWw5ImDPGs4e4qrbjo0+/60q
a8g3YYrgLZqpKmYiPt3Wbn1yoETjFUsb0BKz+86RRseg04Ri13Gx7Ge1acDd8OSx
C7rsqC6oPLBt+j92L5+BJOJv5SdOEq5802uCd5b2o6gQLV7ZSGaHXjC76+03E6QG
Zw7+rbyeaHeLdKRSkcjRNR8YJFXDJ/u0jlizaRJATSAuKOze3e4MwafVcE9YYu0Q
0lr79bbGs6k3BBBiBY1T/l0Q55NepA==
=4Cx4
-----END PGP SIGNATURE-----

--Apple-Mail=_5D2293EA-F66D-4935-9D12-5D444CF793AF--