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
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
|
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 1D3D1E19
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Jul 2019 18:31:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io1-f67.google.com (mail-io1-f67.google.com
[209.85.166.67])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EE7D787C
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Jul 2019 18:31:05 +0000 (UTC)
Received: by mail-io1-f67.google.com with SMTP id k8so14505385iot.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 04 Jul 2019 11:31:05 -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=RCaI4LunHChNQb+kh1n9Yu+yA0B+smufloSPglMmpiY=;
b=xWh4XAhjHoIIz/bvlkw/CrOdvcKhIrzW4N3GF+T4Kdcnj53wY9MJ1eU8smHokKSmJg
bb7evP0Uk+ixL7v1MRHJ51CjbHeoD3SzgNUxavv6RNBSm+nGplzLElIcnazrWZylAOFY
EXUjfCvul6MHznOEJ/TTNYmOkPpjcIkA4qM1lJPsyOow3ClJv6Ov5JegsaZ4A8su4No2
v6MVOTNc1f5Z/BNPsc0j39ZnWCvi2rkx4Ve0soKxxHTM8Vm61D2+lXmyryeG1ltMYQFX
5HefcXJK4bptJHBWCB19+WgmPQh6UcYGPiEJ3iOiDMt4URQc3eICLw0huE7e882AOih8
vPDg==
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=RCaI4LunHChNQb+kh1n9Yu+yA0B+smufloSPglMmpiY=;
b=ogDoSqUSDwf39ZKd8F/tqtoNgrmS62WjBzEnoKMUS5u2t0LYHh92DyTVkBDID0qQqi
nwGVzDbGzqIlF46IIA5Sm6A44OC2lp23/xmptjjvZF3cW7ZfSzVzhMXEwa9e/FICfGH+
oDV07AAbZrXyt+kt9EMlt/KDaPxEXbTeUT6arxo9e+m4Xe/Uj8WJHMbleQ7x4NjOv4Nt
8cVCF5LACC4nAz/wvgJL49UDwK1WNwoGjJczgiI654mwuCf6BObWDKjvXn3z/E1ZhP1x
qJTbopHTYUSUXYRsv7g0OKzrh+aAMYQRUkVyxyr89GhJP/cbBclq4gEM/ujK5ut/+50G
bFCA==
X-Gm-Message-State: APjAAAUm7LIrkgWbiSaHbsff46NQN6o4xx/Zgc+GVZEroaOBOs9c75z2
lf0siR+eCYDfB6/95THo8gz6kA==
X-Google-Smtp-Source: APXvYqzTPuBoBIZkVOZaHz94xkIiQ3TJlMCare3W98CitN97ILRCYA8HcfZYRNQQJXgb8Trwr8VDNA==
X-Received: by 2002:a6b:7d49:: with SMTP id d9mr4116497ioq.50.1562265065187;
Thu, 04 Jul 2019 11:31:05 -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
c81sm11831893iof.28.2019.07.04.11.31.03
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 04 Jul 2019 11:31:04 -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 13:31:03 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <DDDE70C5-8C81-4513-8554-4363C995B302@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:09 +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 18:31:07 -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.
Burning is not an economic concern and cannot be prevented. As there are few=
er coins, all things being equal, the cost of each increases, and thus fewer=
must be burned to achieve the same cost. So assuming sufficient divisibilit=
y (an existing Bitcoin assumption) it is sustainable. But as I demonstrated,=
it=E2=80=99s not necessary.
> - Pay high fees in self dealing transactions. This could work and would be=
nefit miner.
This is essentially what I suggested, though presumably you mean Bitcoin fee=
s not secondary network.
> - 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. The problem is one migh=
t not have substantial UTXO to imply high enough opportunity cost.
Another reason why simply spending or burning them is preferential.
> - 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.
This implies additional complexity with no benefit to anyone required by the=
scenario, which was my implication.
> - 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.
The terms lend/borrow are misleading here, as I have previously shown. The c=
oin is neither spendable nor consumable. This is why I have used the terms o=
wner/renter. Yes, the renter can sell the remaining rental expense to anothe=
r.
Yes, the potential incremental value over the other scenarios is transferabi=
lity of the output, but this accrues to both to the advertiser/renter and th=
e owner (trade always benefits both parties trading). This transfer incurs a=
fee if on chain, and in the tracking scenario may easily overwhelm the effe=
ctive benefit (fraction of the rental, no higher than dust, not yet expired)=
, making it economically non-transferrable.
In the advertising scenario this transfer can be achieved independent of Bit=
coin, by simply changing the advertisement (e.g. publish a provably-supersed=
ing ad for the same output), avoiding the material on-chain fee. Recall that=
the value of the coin cannot be captured by the advertiser through transfer=
, just the tracking cost.
e
> 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
|
