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
|
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 30B7B1624
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Jul 2019 23:44:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com
[209.85.210.196])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 613DF70D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Jul 2019 23:44:48 +0000 (UTC)
Received: by mail-pf1-f196.google.com with SMTP id b13so292406pfo.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 05 Jul 2019 16:44:48 -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=MORgeyH2rFbANrL4IkDnriesnvdkRdC1BBLXEzOqPGE=;
b=lCUWoJter6QhaEUEm1O1SyxKKPduq9Dju2ofrjBGQEFS+/9jnbayaPRZy6LK1emKMu
InB3njQvjpGE6fqQPafNsmtv5O/4QbkJTVmDRwjueZXhENp6xfGgIyQM/Meym/nYVmpV
5XxdrRGUuz02OlT7BQiwVN7fXrVqUHwm378jBLgHIRkQkcKULR4m5oaRiLiJ9T7bmf6q
XZ47qGaWD6d+vh75kQ+ahKYovYcY+hWKuNv74NU5THnnU9X4wQ6FbmLUNCDoqvR6/aVG
TKjPlDbBABcWhkIrv6HrI+cD8RS1G+jyJB9lsDYw3UEasorty+Z9ts+zRtc2guhdBkz3
jhPw==
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=MORgeyH2rFbANrL4IkDnriesnvdkRdC1BBLXEzOqPGE=;
b=E7IO3caZKDCuYSpTt2DT2Nt4e0ogdUeErBdqGflLXNJ7HZzegwah7oiho/kEAUtIq9
oTcTB4aaVrui1FWvBxmOJwtv3Tr6mn7Poj5gPRxxoUBN6H09tTJ3PmDyrBt159IvQgYv
e5n40JX5TCnl5jFYXXX8FMpXfUnD20nSu5gB+BDFXxATg6JiQ9H+7xZVs1pxfasStBdw
w8LDXMTj4Mc2wNmskyGd2/4zQAQph6X+hxHcMzQzzBSto8RCYsGggXQAVK4Z3HDqyicJ
yDQ9dg2QuVcul1NgYSG+jDw4QWlmAT1Jd9O0y3Z+IiW9Xx1HHCcBiWG8v9RL8HFYN68H
n4/g==
X-Gm-Message-State: APjAAAWjVogF9oL0In+42M8SMpenwIxqq5mjaN0V4/sJu1rH5/LfGwdt
1TXGdzkqeVlzjH2Q90sEQq5/dw==
X-Google-Smtp-Source: APXvYqzT4N99TrRpq3aVJLiH37QAqMKJwy/WRMmFFF5LGSrkj/6zXVZtcOa+DH74MN0/d+UD4+ignw==
X-Received: by 2002:a63:e250:: with SMTP id y16mr7861413pgj.392.1562370287857;
Fri, 05 Jul 2019 16:44:47 -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
65sm10637884pff.148.2019.07.05.16.44.46
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Fri, 05 Jul 2019 16:44:47 -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: <4mT6iC4Va7Afg15a5NLbddAnF2a_vAcQSXYr_jg_5IyEK2ezblJff7EJZakoqvp4BJlLitt9Zlq1_l5JadR0nVss7VDPW-pv8jXGh7lkFC4=@protonmail.com>
Date: Fri, 5 Jul 2019 16:44:45 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A1ADD0BB-F62F-47AF-B043-53BDF3A88CC3@voskuil.org>
References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com>
<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>
<4mT6iC4Va7Afg15a5NLbddAnF2a_vAcQSXYr_jg_5IyEK2ezblJff7EJZakoqvp4BJlLitt9Zlq1_l5JadR0nVss7VDPW-pv8jXGh7lkFC4=@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: 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:44:49 -0000
> On Jul 5, 2019, at 16:16, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>=20
> Good morning Eric,
>=20
>=20
> Sent with ProtonMail Secure Email.
>=20
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M=
essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
> On Saturday, July 6, 2019 3:27 AM, Eric Voskuil <eric@voskuil.org> wrote:
>=20
>>> On Jul 4, 2019, at 21:05, ZmnSCPxj ZmnSCPxj@protonmail.com wrote:
>>> Good morning Eric,
>>>=20
>>>> As with Bitcoin mining, it is the consumed cost that matters in this sc=
enario, (i.e., not the hash rate, or in this case the encumbered coin face v=
alue). Why would the advertiser not simply be required to burn .1 coin for t=
he same privilege, just as miners burn energy? Why would it not make more se=
nse 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 se=
rvice 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 goo=
ds, once the stock has been sold, the merchant (assuming the merchant used o=
wn funds) can simply recover the locked funds, with the potential to reinves=
t them elsewhere.
>>> This allows some time-based hedging for the merchant (they may be willin=
g to wait indefinitely for the stock to be sold, but once the stock is sold,=
they can immediately reap the rewards of not having their funds locked anym=
ore).
>>=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 n=
ot use them elsewhere until then.=E2=80=9D
>=20
> Possibly.
> In a way, this is giving up control of the coin, until he no longer needs t=
he advertisement, i.e. dynamically select the maturity age needed.
>=20
>>> Similarly, an entity renting out a UTXO for an advertisement might allow=
for early reclamation of the UTXO in exchange for partial refund of fee; as=
the value in the UTXO is now freed to be spent elsewhere, the lessor can le=
ase it to another advertiser.
>>=20
>> You appear to be proposing a design whereby either the owner or the rente=
r (not entirely clear to me which) can spend the =E2=80=9Clocked up=E2=80=9D=
coin 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 o=
f cost), as the owner retains full control of the coin.
>>=20
>=20
> Obviously this will require a 2-of-2 multisig, with an timelocked transact=
ion that lets the owner recover at a futuredate, so that it is the agreement=
of *both* that is needed to perform any actions before the timelock.
> I already described this in the link I provided.
>=20
>=20
>> If you mean that the age of the encumbrance is the proof of cost, this re=
quires no covenant. I don=E2=80=99t believe this is what you intended, just c=
overing all bases.
>=20
> Not age of encumbrance, quite.
> Instead, it is the simple fact that the UTXO is a UTXO (and not yet spent)=
, that validates the advertisement.
Not any UTXO then, one that with sufficient time-locked coin.
> No, it does not *require* a covenant.
> However, covenants do make it easier to use, in the sense that the renter c=
an repurpose the UTXO (e.g. change details of advertisement) without having t=
o contact the owner.
So how does one get the owner to sign off on the multisig release? Presumabl=
y the renter cares because he wants to recover the remaining value of rental=
. So he not only needs to contact the owner, he also needs to negotiate with=
the owner for a pro-rated refund. In other words, he must sell the remainin=
g portion of the rental return - essentially how I described it previously. H=
e might as well just sell the marketable ad space that he controls through t=
he remainder of the term (the same value).
Certainly the owner could given him a partially-signed transaction, returnin=
g the coin, allowing the renter to exit at any time, but the renter has no r=
eason to sign it without a refund, which must be pro-rated in some way, impl=
ying later contact/negotiation with the owner.
But it=E2=80=99s worth noting that early recovery of the UTXO entirely elimi=
nates the value of the time lock cost to the ad market. The most obvious exa=
mple is one encumbering the coin to himself, then releasing it with his own t=
wo signatures whenever he wants. In other words, there is no encumbrance at a=
ll, just a bunch of pointless obscurantion.
>>> 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
> You have shown no such thing, merely shown that you have not understood th=
e proposal.
I think I understand the implications of it clearly. Feel free to point out w=
hat I=E2=80=99m missing. But I don=E2=80=99t spend any time in implementatio=
n details until I can justify those implications.
A multisig doesn=E2=80=99t fix the central economic issue, which it is not c=
lear that you understand. If so it hasn=E2=80=99t been demonstrated. A cost c=
reated by making coin unusable for a term is not an actual cost if that lock=
can be released at any time before maturity of that term. Furthermore, cost=
is most easily demonstrated by simply spending.=20
By analogy, proof of work is simply proof of a spend (incurred cost). Imagin=
e if one demonstrated that cost by =E2=80=9Clocking up=E2=80=9D coin for a y=
ear, and then after the block was accepted, he unlocked that coin after just=
one day.
Best,
Eric
> Regards,
> ZmnSCPxj
|
