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
|
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 EECA2BBC
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Jul 2019 19:31:16 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f66.google.com (mail-io1-f66.google.com
[209.85.166.66])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3D1B987C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Jul 2019 19:31:16 +0000 (UTC)
Received: by mail-io1-f66.google.com with SMTP id i10so14596070iol.13
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 04 Jul 2019 12:31:16 -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=fCcBZm0l9Qnqvw8pq9zh8mHVhpvxW6LPdUf3zE6JWCE=;
b=xwQUKd6Pohgz0uwrW5YWRepVKL67n3+/dpTXJ/9+T9jCqh3CVREewxPOk3fTneFPDs
9K2T5gxUaZwZ5itHNc349Vt2gEkc5q75wOimR6UMB0Gdo70KGIjEjV/53uu1u1QWNqZc
EdqIt7Y9D1Z5iIYQEKUS81Yl8JyTe7Qv0SEqaW86GyuQLDyMw+KN59qYDWiAvhAaPP8m
m3hmqOa6E6oqBDhLSECQKUPBBgPBELYk5kaifooJ5aO0lM1vRTTSJmoTCC5f6TKt5N1r
PmEsANeuZAgr6H7UP90RYKhspQV+G/wuJzrnr/0uQhV876gwl6YBl6L4Rbh7500eoR19
sD/w==
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=fCcBZm0l9Qnqvw8pq9zh8mHVhpvxW6LPdUf3zE6JWCE=;
b=MZ+RrGvoCK+e9eD5zMCnSF8OUBfx8xGVVPlPwvUY1EEiEBd40qCTT+e1VT99wF7FbM
IpWTpp0t3+G1LKtWeWLoBaZKOpKV7wdbX8j/0YPQ3ydM8lKWHqcwFEInys3Uxck24/KE
QuxPIVF1wwLmCZOWbIVydXFL4YXYXVtuQbDZxL7JsBIQ/bYIFgRPpMzNwAHi4vO/5azI
oIOJi0MAmjMwqYj5RmjJ3caVy2Nf8uUs0CpEHCiKELEZXijpzGWv91YWFHPGdkubn7lS
bXdxkwpPkqti7INGsoO2vf3zhUx8bhgEVaj/hSWS+/yMW3p7YRuhlPfMASeUlK4f4POe
b+lQ==
X-Gm-Message-State: APjAAAV/a6qdb91LPWZd2NGHfihYObW8sMs3q8WxP/XUtBbh4DDfC2ph
xT7t0Stgm8tvrIv91s8fs0RnBA==
X-Google-Smtp-Source: APXvYqytH6kYMtOMAdXmNKaqYHox4quO1QmIOnCeZ2iK1qHYsFD3EpJW0pmpKqPniCzqG1QlkYZsBw==
X-Received: by 2002:a02:ce37:: with SMTP id v23mr49757103jar.2.1562268675483;
Thu, 04 Jul 2019 12:31:15 -0700 (PDT)
Received: from ?IPv6:2600:380:c458:7e3a:5803:ef0e:5551:2919?
([2600:380:c458:7e3a:5803:ef0e:5551:2919])
by smtp.gmail.com with ESMTPSA id
r139sm13495535iod.61.2019.07.04.12.31.14
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 04 Jul 2019 12:31:14 -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: <BFC25438-CA9F-4F95-A79C-089EE3C52917@gmail.com>
Date: Thu, 4 Jul 2019 14:31:12 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <5DC8D144-7376-4BAA-ABEC-9579D3B9F5D1@voskuil.org>
References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com>
<BF027CD0-FE29-4DD1-AB96-DE92B597AD18@gmail.com>
<3F46CDD5-DA80-49C8-A51F-8066680EF347@voskuil.org>
<A4A6099F-F115-4CBF-B7D5-F16581476126@gmail.com>
<063D7C06-F5D8-425B-80CE-CAE03A1AAD0C@voskuil.org>
<0AA10217-E1CC-46D1-9B43-038CEEF942CD@gmail.com>
<E72C4A8E-F850-400B-B19B-7D06B8A169EC@voskuil.org>
<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>
<BFC25438-CA9F-4F95-A79C-089EE3C52917@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: Fri, 05 Jul 2019 13:54:27 +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: Thu, 04 Jul 2019 19:31:17 -0000
> On Jul 4, 2019, at 12:10, Tamas Blummer <tamas.blummer@gmail.com> wrote:
>=20
> Hi Eric,
>=20
> there are some other ways to impose cost on use without direct billing, e.=
g.:
>=20
> - Burn Bitcoins to use the service, as you mentioned. This could work and w=
ould benefit remaining Bitcoin owner, but is unsustainable.
>=20
> - Pay high fees in self dealing transactions. This could work and would be=
nefit miner.
>=20
> - Time lock own Bitcoins. This is forgoing control of an UTXO for a time p=
eriod, which implies opportunity cost. This could be done with CLTV (OP_HODL=
). It damages the current owner but benefits no one.
I meant to point out that a voluntarily trade cannot represent =E2=80=9Cdama=
ge=E2=80=9D to the person making it. The person chooses the action because i=
t is preferred over alternatives (i.e. it is beneficial). Such choices are t=
he only objective expression of preference, a fundamental principle of praxe=
ology.
> The problem is one might not have substantial UTXO to imply high enough o=
pportunity cost.
>=20
> - Pay someone else to time lock. This is paying someone to lock an UTXO fo=
r a time span. Payment and time lock could be combined in the same transacti=
on.
>=20
> - Transferable borrowed Bitcoin. This needs the covenant. This benefits t=
hose who consciously give up control for a time span. Its advantage is that s=
ince transferable it can be sold if no longer needed, thereby shortening the=
term of the original arrangement. It coul be re-rented for a shorter time p=
eriod.
>=20
> Tamas Blummer
>=20
>=20
>> On Jul 4, 2019, at 18:43, Eric Voskuil <eric@voskuil.org> wrote:
>>=20
>> Hi ZmnSCPxj,
>>=20
>> Generalizing a bit this appears to be the same with one exception. The am=
ount of encumbered coin is relevant to an external observer. Of course the e=
ffective dust limit is the maximum necessary encumbrance otherwise.
>>=20
>> In the case of simple tracking, the market value of the coin is not relev=
ant, all that is required is a valid output. Hence the devolution to 1 sat t=
racking. In your scenario the objective is to establish a meaningful cost fo=
r the output.
>>=20
>> A community of people using this as a sort of hashcash spam protection ca=
n raise the amount of encumbered coin (i.e. advertising threshold price) req=
uired in that context. The cost of this encumberance includes not only at le=
ast one tx fee but market cost of the coin rental.
>>=20
>> At a 1 year advertisement term, 10% APR capital cost, and threshold of 1 e=
ncumbered coin, the same is achieved by burning .1 coin. In other words the r=
enter (advertiser) has actually paid to the coin owner .1 coin to rent 1 coi=
n for one year.
>>=20
>> As with Bitcoin mining, it is the consumed cost that matters in this scen=
ario, (i.e., not the hash rate, or in this case the encumbered coin face val=
ue). Why would the advertiser not simply be required to burn .1 coin for the=
same privilege, just as miners burn energy? Why would it not make more sens=
e to spend that coin in support of the secondary network (e.g. paying for co=
nfirmation security), just as with the burning of energy in Bitcoin mining?
>>=20
>> e
>>=20
>>> On Jul 3, 2019, at 23:57, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>>>=20
>>> Good morning Eric,
>>>=20
>>>=20
>>>>> and thanks to you and ZmnSCPxj we now have two additional uses cases f=
or UTXOs that are only temporarily accessible to their current owner.
>>>>=20
>>>> Actually you have a single potentially-valid use case, the one I have p=
resented. The others I have shown to be invalid (apart from scamming) and no=
additional information to demonstrate errors in my conclusions have been of=
fered.
>>>=20
>>> I presented another use case, that of the "Bitcoin Classified Ads Networ=
k".
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083=
.html
>>>=20
>>> Advertisements are "backed" by an unspent TXO.
>>> In order to limit their local resource consumption, nodes of this networ=
k will preferentially keep advertisements that are backed by higher UTXO val=
ues divided by advertisement size, and drop those with too low UTXO value di=
vided by advertisement size.
>>>=20
>>> Thus, spammers will either need to rent larger UTXO values for their spa=
m, paying for the higher rent involved, or fall back to pre-Bitcoin spamming=
methods.
>>> Thus I think I have presented a use-case that is viable for this and doe=
s not simply devolve to "just burn a 1-satoshi output".
>>>=20
>>> I still do not quite support generalized covenants as the use-case is al=
ready possible on current Bitcoin (and given that with just a little more tr=
ansaction introspection this enables Turing-completeness), but the basic con=
cept of "renting a UTXO of substantial value" appears sound to me.
>>>=20
>>>=20
>>> Regards,
>>> ZmnSCPxj
>=20
|
