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
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
|
Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CEE1E1C21
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Jul 2019 22:22:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pg1-f194.google.com (mail-pg1-f194.google.com
[209.85.215.194])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 04E1E4C3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 6 Jul 2019 22:22:02 +0000 (UTC)
Received: by mail-pg1-f194.google.com with SMTP id o13so5766532pgp.12
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 06 Jul 2019 15:22:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=voskuil-org.20150623.gappssmtp.com; s=20150623;
h=mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=HOA7mmoxANMIVTVwEyIDWZgdM8dpBmZ3icAWH2oIkfQ=;
b=UrvI5EdLsqXsb3XXvR8NpOqqdaPh7azDL3E/Qvb0ZyKdFHYK0/EcCAPj39MdI2KXyK
ugrnwLQCP1g2pOpV7fTHCRn9DYGWFBuiPbhijYA5RkMmkv5CKzFvXJSz5qzY4ZzWb+lU
dDWdaOMyLTAyftpPw5F57UGJuPubsrFBo/7Cfg22/oF6QkQxwpu2GVRa3mZZ/g7jkfPS
MQu2pLpuxQnGsOm+Xbv36O8NUoWiFWjS4lxbrcYMlW4usDuHaSb4F74ZaGE5dIwcOy4J
Hi/2UMZoNYz7cZNjGhuY015NlRki0Jb+eUHp0aEXecQhy/cC0UX+6Q3/jH3rRgEQOd8G
4nMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
:content-transfer-encoding:message-id:references:to;
bh=HOA7mmoxANMIVTVwEyIDWZgdM8dpBmZ3icAWH2oIkfQ=;
b=eW1Vkjh2UqovoT93ncjNsXRcGN0EcPZXLFhUfXC9ox/ZPxw5WwAL01ub8POyrGy3bB
/kjS+xtpzgplp84eXtzbE9yIV37pQ6xqB+PsC7JmtqU5ph47h+Ug6Ygc0cjEM98sxMZL
8/lpTx6g4tGvyuCuqGyy4l3t8WBz+ZAABgM3zoIeUfgInvs+aSo91MFcQU0NFNGjXtxt
6pGq7pFGT2F6foLwtbxN0RP3Hw7KM297doALAmfBoZMB/+pAOutrESe2+3M2gPEZJxt6
zf/eNm6A8P9y3/EABuZUW0Ji3N8Z/Pt0DF78kvv5OcdHIs1is6aPUEcVKQc+3OwhwvbP
6igA==
X-Gm-Message-State: APjAAAUlIUkE0OwbA1/IfLTct6S/P3FhzS2/zVn2sOs/96afQCgpVhUO
kyTg+pqtfVsACMO4JXqWUiZMKw==
X-Google-Smtp-Source: APXvYqzY1Xm4MM3mY2fjOPnMYE0TrncqNJF2sVbS/j5/F71g9BvoWePaNmBOgxtYIVlWeu6N/GCr+Q==
X-Received: by 2002:a17:90a:f498:: with SMTP id
bx24mr14069773pjb.91.1562451722463;
Sat, 06 Jul 2019 15:22:02 -0700 (PDT)
Received: from ?IPv6:2600:380:7031:6d39:a1fb:7c32:9a36:499?
([2600:380:7031:6d39:a1fb:7c32:9a36:499])
by smtp.gmail.com with ESMTPSA id
t8sm16188119pfq.31.2019.07.06.15.22.00
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Sat, 06 Jul 2019 15:22:01 -0700 (PDT)
Content-Type: text/plain;
charset=utf-8
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (16F203)
In-Reply-To: <8D68DC86-1173-43AC-BC84-FE2834741C13@gmail.com>
Date: Sat, 6 Jul 2019 15:21:59 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <16B94409-AB0A-49E3-8B0D-C52A4B1C6ACA@voskuil.org>
References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com>
<A64C3DCB-10CE-45EA-9A1B-7E3D13DF90EA@gmail.com>
<6B9A04E2-8EEE-40A0-8B39-64AA0F478CAB@voskuil.org>
<SEQmsx6ck79biVthBbBk1b9r9-R45sBwqWrv3FewQIBl4J18sOlwAPRt8sbTIbrBB8DX538GfwQkU40lyODmEkGSwah_VmbXT8iOr2Jcjlw=@protonmail.com>
<F17F2E86-BFA4-456E-85F9-0D6583692AEC@voskuil.org>
<kSCa9KUmpJox2_aglqhel-WdGlXf14mfKNZ95T4xqsrkQJ2Zh5zFA-Llq-j9cXX87iEPP5_aCkO9oR5kfQGKMBK9ds3Jct1V1FAawwa4CyE=@protonmail.com>
<B853EDF2-8A8A-44B0-A66E-F86175E61EDA@voskuil.org>
<4mT6iC4Va7Afg15a5NLbddAnF2a_vAcQSXYr_jg_5IyEK2ezblJff7EJZakoqvp4BJlLitt9Zlq1_l5JadR0nVss7VDPW-pv8jXGh7lkFC4=@protonmail.com>
<A1ADD0BB-F62F-47AF-B043-53BDF3A88CC3@voskuil.org>
<UyUISFwgh_-KtxpCJonltkqTvVbI9-NBukizE8tKSjB2V12otZiCWQ64sn8oqYk5NDftNHxW3koT9EPOWwVrOkXTP8Dqc-0W0wPGRK-wT34=@protonmail.com>
<0851B842-34A1-427F-95DC-A1D6AB416FB9@voskuil.org>
<8D68DC86-1173-43AC-BC84-FE2834741C13@gmail.com>
To: Tamas Blummer <tamas.blummer@gmail.com>
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, MIME_QP_LONG_LINE,
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: Sun, 07 Jul 2019 03:31:26 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Generalized covenants with taproot enable
riskless or risky lending,
prevent credit inflation through fractional reserve
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: Sat, 06 Jul 2019 22:22:03 -0000
> On Jul 6, 2019, at 06:34, Tamas Blummer <tamas.blummer@gmail.com> wrote:
>=20
> Hi Eric,
>=20
>> On Jul 6, 2019, at 03:28, Eric Voskuil <eric@voskuil.org> wrote:
>>=20
>>=20
>>=20
>>> On Jul 5, 2019, at 17:17, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>>>=20
>>> Good morning Eric,
>>>=20
>>>> But it=E2=80=99s worth noting that early recovery of the UTXO entirely e=
liminates the value of the time lock cost to the ad market. The most obvious=
example is one encumbering the coin to himself, then releasing it with his o=
wn two signatures whenever he wants. In other words, there is no encumbrance=
at all, just a bunch of pointless obscurantion.
>>>=20
>>> You still do not understand.
>>> I strongly suggest actually reading the post instead of skimming it.
>>=20
>> I am responding to the cryptoeconomic principles, not the implementation d=
etails. Based on your comments here I am not misrepresenting those principle=
s.
>>=20
>> For example, I have shown that the multisig unlock implementation reduces=
the presumably-encumbered UTXO to simply a UTXO. You have not disputed that=
. In fact below you have accepted it (more below).
>>=20
>>> The advertisement is broadcast to new nodes on the ad network if and onl=
y if its backing UTXO remains unspent.
>>> Once the UTXO is spent, then the advertisement is considered no longer v=
alid and will be outright deleted by existing nodes, and new nodes will not l=
earn of them (and would consider it spam if it is forced to them when the UT=
XO is already spent, possibly banning the node that pushes the advertisement=
at them).
>>>=20
>>> Thus the locked-ness of the UTXO is the lifetime of the advertisement.
>>=20
>> The term =E2=80=9Clocked=E2=80=9D here is misused. A unspent output that c=
an be spent at any time is just an unspent output. The fact that you can =E2=
=80=9Cunencumber=E2=80=9D your own coins should make this exceedingly obviou=
s:
>>=20
>>> Once you disencumber the coins (whether your own, or rented) then your a=
dvertisement is gone; forever.
>>=20
>> As I have shown, there is no *actual* encumbrance.
>>=20
> If you have to forgo using your money while using a service that encumbers=
you. You incur opportunity cost proportional to time you use the service an=
d the amount you waived to use elsewhere.
> No crypto is needed to understand this.
My use of =E2=80=9Cencumbrance=E2=80=9D in this thread has been consistently=
a reference to a covenant. When the covenant can be released at any time it=
serves no purpose whatsoever, being an encumbrance in name only.
I gave a detailed explanation of opportunity cost, and gave you a scenario w=
here that opportunity cost could actually be used - to purchase a tracking o=
utput (i.e., a fixed term asset tracked for that term). And I have discussed=
at length the use of opportunity cost in the hash-cash-like anti-spam ad sc=
enario.
So it=E2=80=99s not clear to me why you continue to imply that the nature of=
either covenants or opportunity cost is the point at issue, and by implying=
I don=E2=80=99t understand them.
**The central issue in your proposal is that constrained coins can neither b=
e used as borrowed money nor the tracking of perpetual assets.** This conclu=
sion is not based on a failure to understand the nature of covenants or the c=
oncept of opportunity cost. It is the necessary consequence of attempting to=
trade something today that will provably disappear tomorrow. The sole possi=
ble value of such an instrument is to scam the eventual bag-holders.
A secondary issue, in the valid fixed-term asset tracking scenario, is that t=
he cost of tracking is dust (and at least one transfer fee). The cost of suc=
h tracking is a function only of the market price of a satoshi. The financia=
l value of renting one dust output is also limited in time by economic inte=
rest (i.e., at 10% it is cheaper to buy than rent if the fixed term exceeds 7=
.2 years). So while valid, is not likely to be demanded until one satoshi be=
comes worth the overhead of renting it.
The opportunity of interest represents opportunity cost when forgone. This c=
an be used to show proof-of-cost (ad scenario), and that level can float as a=
price on the anti-spam market. This is a perfectly valid scenario, as I hav=
e said.
The issue with that specific proposal is that it uses covenants in an irrati=
onal manner. The ability to release the covenant at any time eliminates the c=
ost it would otherwise represent. One could either simply burn or spend coin=
outright, or use an actual encumbrance (as you propose) to =E2=80=9Cburn=E2=
=80=9D (provably destroy) the opportunity, but a non-encumbrance adds nothin=
g except complexity.
>>> Your advertisement exists only as long as the UTXO is unspent.
>>=20
>> Exactly, which implies *any* UTXO is sufficient. All that the ad network r=
equires is proof of ownership of any UTXO.
>>=20
> Not any, but one with significant value, so a service with limited bandwit=
h can prioritize by that.
Not significant, which is arbitrary, but sufficient - a result of supply and=
demand. Clearly my intent here is that no covenant on the UTXO is required i=
n the scenario. As the preceding discussions conclude, without disagreement,=
all that is required is that the (sufficient) output remains unspent, not t=
hat it be encumbered.
>> Best,
>> Eric
>>=20
>>> Regards.
>>> ZmnSCPxj
>=20
> Best,
>=20
> Tamas Blummer
|
