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
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 50C481088
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Jul 2019 23:16:27 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
[185.70.40.135])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5416970D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Jul 2019 23:16:26 +0000 (UTC)
Date: Fri, 05 Jul 2019 23:16:17 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1562368583;
bh=fyKs0pEw197396lameOwjT3f9jVdJhoPj1o6xb61LBI=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=GXsOMqgglIqrtQ67pfGO9zavVIItHiY13XUP7hSH5rqzE1L5FaET8sfP/79Ob15cz
X7XG7YPC+ezTqNoYHoCF/JTf0jvcSAkD97XpWChukGilDYFHCqOggGYp71cDEIk0/O
DQZ4chs6++Dt5AoG0dNMYm+eVvV1kOS2O4odXv3A=
To: Eric Voskuil <eric@voskuil.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <4mT6iC4Va7Afg15a5NLbddAnF2a_vAcQSXYr_jg_5IyEK2ezblJff7EJZakoqvp4BJlLitt9Zlq1_l5JadR0nVss7VDPW-pv8jXGh7lkFC4=@protonmail.com>
In-Reply-To: <B853EDF2-8A8A-44B0-A66E-F86175E61EDA@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>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL,
RCVD_IN_DNSWL_LOW 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:16:27 -0000
Good morning Eric,
Sent with ProtonMail Secure Email.
=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me=
ssage =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:
> > On Jul 4, 2019, at 21:05, ZmnSCPxj ZmnSCPxj@protonmail.com wrote:
> > Good morning Eric,
> >
> > > 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 fac=
e value). Why would the advertiser not simply be required to burn .1 coin f=
or the same privilege, just as miners burn energy? Why would it not make mo=
re sense to spend that coin in support of the secondary network (e.g. payin=
g for confirmation 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 s=
ervice or producer to "close up shop" by simply spending the advertising UT=
XO.
> > For instance, if the advertisement is for sale of a limited stock of go=
ods, once the stock has been sold, the merchant (assuming the merchant used=
own funds) can simply recover the locked funds, with the potential to rein=
vest them elsewhere.
> > This allows some time-based hedging for the merchant (they may be willi=
ng to wait indefinitely for the stock to be sold, but once the stock is sol=
d, they can immediately reap the rewards of not having their funds locked a=
nymore).
>
> 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 n=
ot use them elsewhere until then.=E2=80=9D
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.
> > Similarly, an entity renting out a UTXO for an advertisement might allo=
w 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=
lease it to another advertiser.
>
> 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 covena=
nt.
>
> 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 o=
f cost), as the owner retains full control of the coin.
>
Obviously this will require a 2-of-2 multisig, with an timelocked transacti=
on 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.
> 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=
covering all bases.
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.
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=
to contact the owner.
>
> > 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 =
unlocked to do the same.
You have shown no such thing, merely shown that you have not understood the=
proposal.
Regards,
ZmnSCPxj
|
