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
|
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 C9B41C58
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Jul 2019 17:10:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com
[209.85.221.46])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F039487E
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Jul 2019 17:10:33 +0000 (UTC)
Received: by mail-wr1-f46.google.com with SMTP id r1so1006710wrl.7
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 04 Jul 2019 10:10:33 -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=Xz8QpDw/QhVwgfcPamoCMsuoUHCgP4XxUuf5ML52PgE=;
b=RUXusQNhMohVeOTifCTOsHJk6pIVbVtitYubrP4cWaLKtWl9ubVf8FWTlLjcnmoL97
ARoMoZQe9kmt8pQF9AedJfj9OuYvKhW6bljeMohLhMhyFy7UUvdv2yxOGrveuUTWgzNI
y0DI2F5YGSprTUaU5S9rWqwZKMJu3S7pjHtP1Vauo+oSrE5RhMDfLX7Cb+L5A53tuTDS
JuS13CoNeaFQYZYUS60hRpwixY5WsxnfKTK5vu0u9jqGmK5H/Yd4bHh9U0qQPztwH+SA
qE4XruloLROvjhnscH8ibjDQuJEJns7P8YwJJ7EcGvbbR6jnjp7cVqTl1VYyTNVeOjPY
uqsg==
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=Xz8QpDw/QhVwgfcPamoCMsuoUHCgP4XxUuf5ML52PgE=;
b=RjHDle8NW6GwLs54aGPFE+ZQZH5jQIPx22sOpJ1o2+GGggDXiGoEfDOIwtNxvDNq1X
noifswsQ7qsWTBf8hG1CdamNAp0L7tn67BQi6zE2Mo5MHvUeAdWzdtKkvCMVDUNpWYg4
2NIg0xFy4v7JWx/D9MIwYvaOiHRlXCZxe0D42k6p3qgao1HS9H5wtwu/t3la8T6ej966
IUxSNJoD/R84MwjvdZqfDYWGwY6HhgnbN5Hdk4Ym37IfDqPWpd5vWLYo+wWWRCEkkdLH
RdUlD2pb3+Xl893dIDrpGW9F5u/cNBpn1jqHHJXV4WYgDJ8/3q3+Wyx9iDvngq825RCu
FMRw==
X-Gm-Message-State: APjAAAX+CXODR5PYzb5d+hvCeEQFfs0l6VJDA/+CPleWcILafL6+K6Ww
FU4NyHH9WKs2f8HULiyiEgU=
X-Google-Smtp-Source: APXvYqyJW6x7wOV4BMlbDu8R2m7tM1MD3XHxULD3XrXtWWUTC/UL1LOa3y1QUuQqJb0ylBVqoqmkLQ==
X-Received: by 2002:adf:f186:: with SMTP id h6mr17035303wro.274.1562260232499;
Thu, 04 Jul 2019 10:10:32 -0700 (PDT)
Received: from p200300dd67126444742440456c913622.dip0.t-ipconnect.de
(p200300DD67126444742440456C913622.dip0.t-ipconnect.de.
[2003:dd:6712:6444:7424:4045:6c91:3622])
by smtp.gmail.com with ESMTPSA id
o6sm10744968wra.27.2019.07.04.10.10.31
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Thu, 04 Jul 2019 10:10:31 -0700 (PDT)
From: Tamas Blummer <tamas.blummer@gmail.com>
Message-Id: <BFC25438-CA9F-4F95-A79C-089EE3C52917@gmail.com>
Content-Type: multipart/signed;
boundary="Apple-Mail=_1C744C09-FE87-4ECA-8B9F-33DE9453B2B4";
protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 4 Jul 2019 19:10:31 +0200
In-Reply-To: <F17F2E86-BFA4-456E-85F9-0D6583692AEC@voskuil.org>
To: Eric Voskuil <eric@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>
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: Fri, 05 Jul 2019 13:53:35 +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 17:10:34 -0000
--Apple-Mail=_1C744C09-FE87-4ECA-8B9F-33DE9453B2B4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=us-ascii
Hi Eric,
there are some other ways to impose cost on use without direct billing, =
e.g.:
- Burn Bitcoins to use the service, as you mentioned. This could work =
and would benefit remaining Bitcoin owner, but is unsustainable.
- Pay high fees in self dealing transactions. This could work and would =
benefit miner.
- Time lock own Bitcoins. This is forgoing control of an UTXO for a time =
period, 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 might not have substantial UTXO to imply high enough opportunity =
cost.
- Pay someone else to time lock. This is paying someone to lock an UTXO =
for a time span. Payment and time lock could be combined in the same =
transaction.
- Transferable borrowed Bitcoin. This needs the covenant. This benefits =
those who consciously give up control for a time span. Its advantage is =
that since 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 period.
Tamas Blummer
> 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 =
amount of encumbered coin is relevant to an external observer. Of course =
the effective dust limit is the maximum necessary encumbrance otherwise.
>=20
> In the case of simple tracking, the market value of the coin is not =
relevant, all that is required is a valid output. Hence the devolution =
to 1 sat tracking. In your scenario the objective is to establish a =
meaningful cost for the output.
>=20
> A community of people using this as a sort of hashcash spam protection =
can raise the amount of encumbered coin (i.e. advertising threshold =
price) required in that context. The cost of this encumberance includes =
not only at least 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 encumbered coin, the same is achieved by burning .1 coin. In other =
words the renter (advertiser) has actually paid to the coin owner .1 =
coin to rent 1 coin for one year.
>=20
> As with Bitcoin mining, it is the consumed cost that matters in this =
scenario, (i.e., not the hash rate, or in this case the encumbered coin =
face value). 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 sense to spend that coin in support of the secondary =
network (e.g. paying for confirmation 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 for UTXOs that are only temporarily accessible to their current =
owner.
>>>=20
>>> Actually you have a single potentially-valid use case, the one I =
have presented. The others I have shown to be invalid (apart from =
scamming) and no additional information to demonstrate errors in my =
conclusions have been offered.
>>=20
>> I presented another use case, that of the "Bitcoin Classified Ads =
Network".
>> =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083.h=
tml
>>=20
>> Advertisements are "backed" by an unspent TXO.
>> In order to limit their local resource consumption, nodes of this =
network will preferentially keep advertisements that are backed by =
higher UTXO values divided by advertisement size, and drop those with =
too low UTXO value divided by advertisement size.
>>=20
>> Thus, spammers will either need to rent larger UTXO values for their =
spam, 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 =
does not simply devolve to "just burn a 1-satoshi output".
>>=20
>> I still do not quite support generalized covenants as the use-case is =
already possible on current Bitcoin (and given that with just a little =
more transaction introspection this enables Turing-completeness), but =
the basic concept of "renting a UTXO of substantial value" appears sound =
to me.
>>=20
>>=20
>> Regards,
>> ZmnSCPxj
--Apple-Mail=_1C744C09-FE87-4ECA-8B9F-33DE9453B2B4
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-----
iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAl0eMwcACgkQ9nKRxRdx
ORyWQQf+MAc8plWrBW3s9aIko1UBre8YbfS3KDyTPNxWXRNLpOQoqopVv7PzSJwJ
tIpocYQW4xVBHWfAwP+FKAfaNwn++5PsOgl0Qeh4IdfQKSsjSFZpSiCdxhj9OPHy
/OcFieMb0uPENqawljAGJULZ1KeJsUWz8waSB1IVZ4grZg/6W/Lm2+SS2hyLXK9h
0mU8XwpFN5WybhpTbC8t8d7DoKWeaJYK97Rn84SyWKUne15caRgr6CKNmgq28tmY
uKMxlxeeoTF040t9EO/gRY9GBMvMlR6oppUluu//aLeZJi9+oJ3GG/IvPHaqKW3G
hDx3ivmTlkdZmKxTFRsirwG9JBI7VQ==
=Sh+N
-----END PGP SIGNATURE-----
--Apple-Mail=_1C744C09-FE87-4ECA-8B9F-33DE9453B2B4--
|
