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
|
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 29F6E3447
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 Jul 2019 10:31:21 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch
[185.70.40.133])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 04F58148
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 9 Jul 2019 10:31:19 +0000 (UTC)
Date: Tue, 09 Jul 2019 10:31:12 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1562668277;
bh=Dk9HlRu2wMLIyJxRPKzj0/wH70Wd3FEA/5bwWhDIhdw=;
h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID:
From;
b=ZXNf8dL1Z5O4xL3M+orOqtJV5h43Zzv/O4XJ+Xnbd55PuJt0rq9rA5FqEvXHcdcFe
Rzjp/OymGivMFXKmRLbaDFCPaZzGgQM+1q+B+wQ5ByC95WaJ4Dh8WIDCrILF1Qd1rb
ukelfmUZdIV0G5ruXkW1ieXhglrxhxH2Ix8XS/NM=
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <gq9nEV2JWJaezWYf1OL_vXbqxrhmAKECd4fJ6vCHnXs-VAzK7fNIEJ5Ezd6LhzrxjZA3BdgWC3xZAEJY7ebNQ-QBF6URu29IdAXYgUOZhCM=@protonmail.com>
In-Reply-To: <501EFBBA-8A14-4B64-BD77-1ED5119154EA@gmail.com>
References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com>
<B853EDF2-8A8A-44B0-A66E-F86175E61EDA@voskuil.org>
<4mT6iC4Va7Afg15a5NLbddAnF2a_vAcQSXYr_jg_5IyEK2ezblJff7EJZakoqvp4BJlLitt9Zlq1_l5JadR0nVss7VDPW-pv8jXGh7lkFC4=@protonmail.com>
<A1ADD0BB-F62F-47AF-B043-53BDF3A88CC3@voskuil.org>
<UyUISFwgh_-KtxpCJonltkqTvVbI9-NBukizE8tKSjB2V12otZiCWQ64sn8oqYk5NDftNHxW3koT9EPOWwVrOkXTP8Dqc-0W0wPGRK-wT34=@protonmail.com>
<0851B842-34A1-427F-95DC-A1D6AB416FB9@voskuil.org>
<8D68DC86-1173-43AC-BC84-FE2834741C13@gmail.com>
<B23C4FC6-2991-4C1B-8B8E-AAA06E9E578F@voskuil.org>
<501EFBBA-8A14-4B64-BD77-1ED5119154EA@gmail.com>
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: Tue, 09 Jul 2019 18:49:26 +0000
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: Tue, 09 Jul 2019 10:31:21 -0000
Good morning all,
I will attempt to restart my thinking from initial principles regarding my =
proposed "Bitcoin Classified Ads Network".
Nodes behave this way:
* Nodes in this network gossip advertisements.
* These advertisements refer to a UTXO that must be unspent at the chain ti=
p considered by each node, else they would be rejected.
* The referred UTXO must contain a commitment to the text of the advertisem=
ent, else the advertisement is rejected.
* Nodes have a maximum limit on the total size of all advertisements they r=
etain and propagate to new nodes, or gossip to their peers.
This is a deliberate design decision.
* If nodes exceed the above limit, they will sort advertisements according =
to a value-rate, the value of the UTXO divided by the storage size of the a=
dvertisement, and prune advertisements with low value-rate until they are w=
ithin the limit again.
* Once the backing UTXO is spent, the advertisement is removed by nodes tha=
t follow that chaintip.
* As the name ***Classified Ads*** suggests, each advertisement also indica=
tes a "class" in which they belong to.
Then, from the above, we derive how a seller might behave.
* Sellers will attempt to put the minimum possible value into a UTXO commit=
ting to an advertisement, to reduce the opportunity cost of using the value=
elsewhere.
* Thus the rent of the advertisement in this case is paid to joinmarket mak=
ers and LN forwarding nodes, as the value used in a UTXO backing an adverti=
sement is not useable in joinmarket/LN.
* Sellers remain in full control of their advertising UTXO, and can spend i=
t at any time.
* Sellers may spend part of the UTXO and put the remaining funds into a cha=
nge address that is a new advertising UTXO, and re-transmit the advertiseme=
nt, this time pointing to the new change UTXO.
* However, if the remaining change becomes too low, then its value-rate may=
drop below the lowest value-rate that BCAN nodes will retain in their (del=
iberately limited) storage, thus also deleting their advertisement from the=
BCAN.
* Presumably, the reason for advertising at all, is that the seller conside=
rs the cost of advertising to be less than the expected gain of actually se=
lling their product.
* Thus, even if the seller has the ability to spend the UTXO at any time, t=
hey run the risk of spending too much and thus removing their advertisement=
from the BCAN, and losing the expected gain of having the advertisement ex=
ist on the BCAN.
* A utility-maximizing seller would therefore not spend a minimal-value UTX=
O backing the advertisement until it has gained the advantage of actually s=
elling the product, even if it has the option to do so: it is a forced move=
.
* The cost of keeping the minimal-value UTXO unspent is the opportunity cos=
t in that the value may have been used in joinmarket or LN instead.
* The minimum value will largely be dependent on how much the BCAN is used;=
more sellers advertising over BCAN will increase the minimum value.
* If the minimum value that is viable to keep its advertisement alive goes =
higher, then the opportunity cost of the seller using the same value elsewh=
ere might exceed the expected gain from selling the product.
However, this is expected of *any* advertising scheme: if the gains from =
selling is too small to justify the advertisement price, advertising does n=
ot happen; this is expected utility-maximizing behavior.
* If competitors of the seller exist and the BCAN node storage is already f=
illed, competitors can increase the minimum value of a UTXO that can keep a=
n advertisement alive on BCAN by simply adding more of their advertisements=
to BCAN.
* Thus we expect that, once the BCAN node storage is at or near the maximum=
value, the minimum value of a UTXO that can back an advertisement will app=
roach the expected gain from selling the product.
Thus the system of simply committing UTXOs to particular advertisement text=
s seems sufficient to extract value from a seller wishing to advertise.
The purpose of this extraction of value is to ensure that spam does not ove=
rload the BCAN.
Let us now consider some kind of specialization, where a HODLer specializes=
in owning UTXOs, while an advertiser specializes in trading products that =
need advertising of some kind.
* We assume that the specialization means that the HODLer cannot feasibly m=
ake and sell products on its own, while the advertiser cannot own and contr=
ol UTXOs of the minimum value needed to keep their advertisement alive on t=
he BCAN.
* We assume that the specialization means that the advertiser can make and =
sell products for cheaper than the HODLer can, while the HODLer can own and=
control (and secure) UTXOs of the minimum value needed for advertisements =
to be kept alive, for cheaper than the advertiser can.
Then:
* A HODLer may offer to provide a UTXO locked by a 2-of-2 with a commitment=
to an advertisement of the advertiser's choosing, in exchange for rent of =
the value, plus an unbreakable promise to return the rented UTXO value back=
to the HODLer (represented by a `nLockTime` pre-signed transaction that re=
turns the 2-of-2 back to the HODLer control).
* The HODLer is effectively lending the UTXO out to the advertiser, for the=
time frame agreed upon by the advertiser.
* The rent at which the HODLer lends out the UTXO must be between the oppor=
tunity cost of instead securely utilizing the UTXO in LN or joinmarket, and=
the expected gain the advertiser expects from having its product advertise=
d.
* The HODLer is assumed to have the ability to secure the UTXO and retain=
all data it needs to recover the UTXO; this is part of the assumption that=
the HODLer specializes in such.
* The advertiser is assumed to have positive gains from creating, adverti=
sing, and selling its product; this is part of the assumption that the adve=
rtiser specializes in such.
* The HODLer and advertiser can agree to refund part of the rent, if the ad=
vertiser signs a transaction that immediately returns control of the value =
to the HODLer, before the agreed `nLockTime`.
* The above constructions can be done in current Bitcoin.
* However, the same constructions could be done with a covenant as proposed=
by Tamas, possibly with reduced communication/coordination costs between t=
he advertiser and HODLer.
Now, there remains the question as to whether users will actually patronize=
the BCAN instead of existing advertising systems.
* We assume that privacy is valuable to users.
* We assume that users of BCAN will run BCAN nodes.
This leaks them as users of BCAN, a small loss of privacy.
Then:
* Users can look for advertisements of specific classes by simply querying =
their own BCAN node.
This does not leak privacy ata all as long as the communication channel o=
f the user with their own BCAN node is private.
* Compare this to alternatives, which involve some entity observing the b=
ehavior of users and thus invading their privacy.
* Advertisers that misclassify their advertisements will be unable to reach=
their target audience.
* Utility-maximizing advertisers will correctly indicate the class of their=
advertisements, as otherwise they would be paying the advertising cost wit=
hout gaining the benefit of the advertisement.
Regards,
ZmnSCPxj
|
