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
|
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 53DF910C8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Jul 2019 19:28:04 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf1-f181.google.com (mail-pf1-f181.google.com
[209.85.210.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9F31B87C
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Jul 2019 19:28:03 +0000 (UTC)
Received: by mail-pf1-f181.google.com with SMTP id m30so4690517pff.8
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 05 Jul 2019 12:28:03 -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=386ZQlm2YoXDKjl+ZmUReGmenFPWhGeGIwlMsOdUGcE=;
b=kmsqkpUHIrbhF/ng7s8gNsuRTbpKgxHIsImT9/eRKaHUZD4Kf2U6YK9R8LImdTi5Kt
hq7B8xoXj2+IZu73vO4a3aO/12Fmf02n0ee7Zt8wYRbR6CD+lzYlc5YofCdSTurOX6Q9
ISMltgAuwqKFzTbji5zaYATTczpQCjvkV7vjGC8fx07PUdhCgwcSynCqZsmkwEs0pqOj
ieQ4oa6/PCzc81ZrWVswkF/CJnsURnJBZp0n9UnboK26RlDwOPqAdNrb/3u3mu3m3noq
Fw2Y3zCFH3lfTIyDKu2wknwKnPzKsPsXoWR3DWrU20dyvc9q1XQVtQBD21HJqeva457M
X4vA==
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=386ZQlm2YoXDKjl+ZmUReGmenFPWhGeGIwlMsOdUGcE=;
b=BPL2z5ApDU8AiaEvBVERE3xpmP2DsxNS1eqS8DR2uJsG1mR2OgWUwj3RzHSldbyAHo
WqLr6QSIVQa4ZYhSaNujbWkDvyQCQ94hxfGv6vWknWKgsaeobWUDE2js45j7LMFKdInT
0azKauuC6DjcdO/YVfXNHMV3XinPC73LxjkQ7tF1JwKQd/+D35mB0UIE5AN1XFAMenAg
2goN3XcN7TdEImkYpTHDM6cMiP/CL5dbSJInPmMP2niqIGuYMyma1UKL/7/7Fw8MYcuX
2YwVBJf0Fr5ZbrKGQGC+k5OrrpZ5wvzTxBGz8iQbPKm7ToAAoosXn2NLw8iEZOpy39EG
hLQQ==
X-Gm-Message-State: APjAAAU1EWM4N48fechiUpv58AYtF50oaGhwnhM0XRDDZmAwiHfz31uP
q8PWQO/Z/4r2DKJs0kUkXemmpQ==
X-Google-Smtp-Source: APXvYqwz5u07M0VzAHLKrFwjL9FKVy4l0zAue0CjHbf/5j4uVQH7McbDG3snBOxj0FuN5FsiQP8jXw==
X-Received: by 2002:a63:f04:: with SMTP id e4mr7032224pgl.38.1562354883062;
Fri, 05 Jul 2019 12:28:03 -0700 (PDT)
Received: from ?IPv6:2600:380:806a:f0fe:add6:be68:523a:fa95?
([2600:380:806a:f0fe:add6:be68:523a:fa95])
by smtp.gmail.com with ESMTPSA id
p65sm9629251pfp.58.2019.07.05.12.28.01
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 05 Jul 2019 12:28:02 -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: <kSCa9KUmpJox2_aglqhel-WdGlXf14mfKNZ95T4xqsrkQJ2Zh5zFA-Llq-j9cXX87iEPP5_aCkO9oR5kfQGKMBK9ds3Jct1V1FAawwa4CyE=@protonmail.com>
Date: Fri, 5 Jul 2019 12:27:59 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <B853EDF2-8A8A-44B0-A66E-F86175E61EDA@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>
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: Fri, 05 Jul 2019 20:09:01 +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 19:28:04 -0000
> 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 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?
Good morning ZmnSCPxj,
> Using the unspentness-time of a UTXO allows for someone advertising a serv=
ice 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 goods=
, once the stock has been sold, the merchant (assuming the merchant used own=
funds) can simply recover the locked funds, with the potential to reinvest t=
hem elsewhere.
> This allows some time-based hedging for the merchant (they may be willing t=
o wait indefinitely for the stock to be sold, but once the stock is sold, th=
ey can immediately reap the rewards of not having their funds locked anymore=
).
This is a materially different concept than proposed by Tamas.
=E2=80=9C...he gives up his control of the coins until maturity, he can not u=
se them elsewhere until then.=E2=80=9D
> 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.
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 co=
in at any time (no maturity constraint), by dropping the covenant.
If the renter can do this he can simply steal the coin from the owner.
If the owner can do this there is no value to the renter (or as a proof of c=
ost), as the owner retains full control of the coin.
If you mean that the age of the encumbrance is the proof of cost, this requi=
res no covenant. I don=E2=80=99t believe this is what you intended, just cov=
ering all bases.
> Burnt funds cannot be "un-burnt" to easily signal the end of a term for an=
advertisement.
And as I have shown above, nor can a =E2=80=9Clocked-up=E2=80=9D coin be unl=
ocked to do the same.
> Similarly for miner fees.
Well that=E2=80=99s the point, money spent is no longer under one=E2=80=99s c=
ontrol. The provable cost of this surrender was your stated objective. Renti=
ng at a fractional cost of coin face value is a non-recoverable spend by the=
renter to the owner. Burning or spending the same amount in a way that is p=
rovably not to one=E2=80=99s self achieves the exact same result.
> The best that can be done would be to have the nodes of the classified ads=
network automatically decay the spent value of older advertisements to let t=
hem be dropped from their advertisements pool.
The advertiser can presumably trade control of as space on the ad network. I=
t=E2=80=99s not clear to me why this is not simply an independent chain of l=
imited ad space ownership. It might as well be namecoin.
> Less importantly, burning currently has bad resource usage for practical a=
pplications.
> Practical burning requires spending to a provably-unspendable P2PKH or P2S=
H or similar output.
> This adds UTXO entries to the UTXO database that will never be removed.
If an output is provably unspendable (burned) it is not a UTXO.
It is worth noting that not all full node implementations require a store of=
UTXOs, this is an implementation detail. For example, libbitcoin uses a fla=
g on each output to indicate its spentness on the strong branch. As such the=
store size is linear by height.
> This will of course be remedied by compact UTXO representations later, but=
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 will=
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.
I don=E2=80=99t believe you have shown this.
Best,
Eric
> 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 chann=
el.
> 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" t=
he existing "advertisement".
> I found this ability to "revoke" the advertisement appealing, and thereby d=
esigned the Bitcoin Classified Ads Network around the UTXO spentness mechani=
sm.
>=20
> Regards,
> ZmnSCPxj
|
