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
|
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 8C309155F
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Jul 2019 23:20:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com
[209.85.210.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D943A87B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Jul 2019 23:20:18 +0000 (UTC)
Received: by mail-pf1-f169.google.com with SMTP id i189so4870195pfg.10
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 05 Jul 2019 16:20:18 -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=Jr9FxKbaSSn7iRc/2swytjR6lJ2vb/TKX3jfJPRi3mg=;
b=0L16nl/BM9mNQdBJk66shOeKhvZIDRPKc4//MQ6esf1JuRtRxiPGzkh6YLMR7+65Xl
LiQnkpkrtJKxQETbRdV71bFs1sBF7Gi7rKPp9LdxZH7u6Nz4P9b/e1fJYuCak8dS93jS
o2ZrfjWRYtLkzEtt3iWuhT+sI7xBkWxIa0tXwG8lHUTyOqe3bwedBfFge8il/Gv/q1Zn
u3NdYMiurZU281iGtotQ/UlWaR0sGKzFXvoS+lxsMUhjHZ5OBrXBiaUjKT3RlSaOyC/R
4d66byEsyknV8rEX94ZFw6pTrOkuOp1zPgKuRO7Y52Yw7/Sku4o/0rNRB6v+gmQx/AKM
c0vQ==
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=Jr9FxKbaSSn7iRc/2swytjR6lJ2vb/TKX3jfJPRi3mg=;
b=h5lYw9JsARkJv48EMK9oHCwn2cLd0R7SF+EQrNGhENTir1BI2MG4DTa/I/stfZFUXG
lCeUsE7OtilsAE8Qi0g+53LGkXp0BkmMtk1veTdSWqS3uTyPXDzP/r6qDk4eRzijWtQg
c9ww2FAql9gMYJvqqqdXZCf8eKHSW+l8tmzrn5pebA9EP9iiwUv5Xv7hPTy+S1xpIVq0
T5fEXqq2FmYiOwr0ZVZJWcQ7v/GrBV7Dne+A5aR9WofO/XmtAgK7mDsSgon/fyeOnP8n
RSqCxk+vyvIQGuSIBIKYCz7HVAY3YFnWROZshoQot3FoWkE+OqYPiYnSwQGOmOSZnoyT
HHhA==
X-Gm-Message-State: APjAAAWl3aaFccIvREwQ6DqKrPRar3vgyBeEg2sCf3zaFyTfERlw0dHp
iHVSG93JhXuaQDzumnNmtyiBMQ==
X-Google-Smtp-Source: APXvYqxC3ejHbgSy3ayoosEN/ko5A9totZwpFasNpM4bO/OHXwyGfPnEESdafp4SUE7eUafrSdacng==
X-Received: by 2002:a17:90a:f488:: with SMTP id
bx8mr8302870pjb.91.1562368818303;
Fri, 05 Jul 2019 16:20:18 -0700 (PDT)
Received: from ?IPv6:2601:600:a080:16bb:c899:e1f8:fb96:3f43?
([2601:600:a080:16bb:c899:e1f8:fb96:3f43])
by smtp.gmail.com with ESMTPSA id j6sm9693040pjd.19.2019.07.05.16.20.17
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 05 Jul 2019 16:20:17 -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: <B853EDF2-8A8A-44B0-A66E-F86175E61EDA@voskuil.org>
Date: Fri, 5 Jul 2019 16:20:17 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <F9B77954-7F2A-4A8D-8ABF-502A9F48F503@voskuil.org>
References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com>
<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>
<kSCa9KUmpJox2_aglqhel-WdGlXf14mfKNZ95T4xqsrkQJ2Zh5zFA-Llq-j9cXX87iEPP5_aCkO9oR5kfQGKMBK9ds3Jct1V1FAawwa4CyE=@protonmail.com>
<B853EDF2-8A8A-44B0-A66E-F86175E61EDA@voskuil.org>
To: ZmnSCPxj <ZmnSCPxj@protonmail.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: Sat, 06 Jul 2019 01:34:57 +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: Fri, 05 Jul 2019 23:20:19 -0000
> On Jul 5, 2019, at 12:27, Eric Voskuil <eric@voskuil.org> wrote:
>=20
>=20
>> On Jul 4, 2019, at 21:05, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>>=20
>> Good morning Eric,
>>=20
>>> As with Bitcoin mining, it is the consumed cost that matters in this sce=
nario, (i.e., not the hash rate, or in this case the encumbered coin face va=
lue). Why would the advertiser not simply be required to burn .1 coin for th=
e same privilege, just as miners burn energy? Why would it not make more sen=
se to spend that coin in support of the secondary network (e.g. paying for c=
onfirmation security), just as with the burning of energy in Bitcoin mining?=
>=20
> Good morning ZmnSCPxj,
>=20
>> Using the unspentness-time of a UTXO allows for someone advertising a ser=
vice or producer to "close up shop" by simply spending the advertising UTXO.=
>> For instance, if the advertisement is for sale of a limited stock of good=
s, once the stock has been sold, the merchant (assuming the merchant used ow=
n funds) can simply recover the locked funds, with the potential to reinvest=
them elsewhere.
>> This allows some time-based hedging for the merchant (they may be willing=
to wait indefinitely for the stock to be sold, but once the stock is sold, t=
hey can immediately reap the rewards of not having their funds locked anymor=
e).
>=20
> This is a materially different concept than proposed by Tamas.
>=20
> =E2=80=9C...he gives up his control of the coins until maturity, he can no=
t use them elsewhere until then.=E2=80=9D
>=20
>> Similarly, an entity renting out a UTXO for an advertisement might allow f=
or early reclamation of the UTXO in exchange for partial refund of fee; as t=
he value in the UTXO is now freed to be spent elsewhere, the lessor can leas=
e it to another advertiser.
>=20
> You appear to be proposing a design whereby either the owner or the renter=
(not entirely clear to me which) can spend the =E2=80=9Clocked up=E2=80=9D c=
oin at any time (no maturity constraint), by dropping the covenant.
>=20
> If the renter can do this he can simply steal the coin from the owner.
>=20
> If the owner can do this there is no value to the renter (or as a proof of=
cost), as the owner retains full control of the coin.
>=20
> If you mean that the age of the encumbrance is the proof of cost, this req=
uires no covenant. I don=E2=80=99t believe this is what you intended, just c=
overing all bases.
>=20
>> Burnt funds cannot be "un-burnt" to easily signal the end of a term for a=
n advertisement.
>=20
> And as I have shown above, nor can a =E2=80=9Clocked-up=E2=80=9D coin be u=
nlocked to do the same.
>=20
>> Similarly for miner fees.
>=20
> Well that=E2=80=99s the point, money spent is no longer under one=E2=80=99=
s control. The provable cost of this surrender was your stated objective. Re=
nting at a fractional cost of coin face value is a non-recoverable spend by t=
he renter to the owner. Burning or spending the same amount in a way that is=
provably not to one=E2=80=99s self achieves the exact same result.
>=20
>> The best that can be done would be to have the nodes of the classified ad=
s network automatically decay the spent value of older advertisements to let=
them be dropped from their advertisements pool.
>=20
> The advertiser can presumably trade control of as space on the ad network.=
It=E2=80=99s not clear to me why this is not simply an independent chain of=
limited ad space ownership. It might as well be namecoin.
>=20
>> Less importantly, burning currently has bad resource usage for practical a=
pplications.
>> Practical burning requires spending to a provably-unspendable P2PKH or P2=
SH or similar output.
>> This adds UTXO entries to the UTXO database that will never be removed.
I forgot to add that it is certainly possible to burn using a nonstandard sc=
ript, such as the non-zero OP_RETURN you suggested, without a consensus chan=
ge. This can be, as you say, made more practical with a policy change. But s=
uch changes are up to individual node operators as they require no deviation=
from consensus. Yet ultimately this is a miner preference, and anyone can m=
ine. Finally, as I pointed out, burning is not necessary. Simply spending th=
e coin as a fee is sufficient.
> If an output is provably unspendable (burned) it is not a UTXO.
>=20
> It is worth noting that not all full node implementations require a store o=
f UTXOs, this is an implementation detail. For example, libbitcoin uses a fl=
ag on each output to indicate its spentness on the strong branch. As such th=
e store size is linear by height.
>=20
>> This will of course be remedied by compact UTXO representations later, bu=
t not today.
>> Similarly, it would be very nice to have non-0-amount `OP_RETURN` outputs=
, as `OP_RETURN` outputs are never stored in the UTXO database.
>> However, this will require a change in node relay policy, which again wil=
l take time to make possible, and would not be practical today.
>>=20
>> Thus I think use of UTXO is better than burning or mining-fee-spending.
>=20
> I don=E2=80=99t believe you have shown this.
>=20
> Best,
> Eric
>=20
>> Also, mostly trivia:
>> The use of UTXOs to advertise services is not original to me --- I found t=
he LN channel gossip to be the inspiration for this.
>> Publicly-announced channels indicate the backing UTXO that funds the chan=
nel.
>> The purpose of publicly announcing the channels is to be able to provide t=
he service, of forwarding across the Lightning Network; thus the public anno=
uncement serves as an advertisement for the service.
>> Channel closure immediately spends the UTXO, and also doubles to "revoke"=
the existing "advertisement".
>> I found this ability to "revoke" the advertisement appealing, and thereby=
designed the Bitcoin Classified Ads Network around the UTXO spentness mecha=
nism.
>>=20
>> Regards,
>> ZmnSCPxj
|
