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
|
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 87AA21281
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 2 Jul 2019 03:45:37 +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 890D870D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 2 Jul 2019 03:45:36 +0000 (UTC)
Date: Tue, 02 Jul 2019 03:45:31 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1562039134;
bh=v0TjgFDDOxLB7036abWG3FjP8+wPjmhF4U8VW9lyBKk=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=fWfAhjJ6JyqtjHKwjfZg8QqtwhQnfyNwyltAJFAVtIv+zNu9wpA5kZmHME8WpEaZm
YUnYe2MJZLmJL4q/rmct35XaLuFZa65k7yyuMvoizM/lIy10NYX5Dan8/27fn67MW0
NuvjdvX8Yjq6VZpo1HQVti9wIm5JnRxOpi1ltjhU=
To: Eric Voskuil <eric@voskuil.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <0Bwi2ejRw4BgoABZ0X0kBdwLAkIKEv1svoyi0zqGQPeqV1g8xR43tBMgYoS52Vcxkgj7DndmNLIje40au51trIGTvrpcet8GivTgqysVC8w=@protonmail.com>
In-Reply-To: <E72C4A8E-F850-400B-B19B-7D06B8A169EC@voskuil.org>
References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com>
<1A808C88-63FD-4F45-8C95-2B8B4D99EDF5@gmail.com>
<83705370-79FC-4006-BA04-4782AD5BE70B@voskuil.org>
<BF027CD0-FE29-4DD1-AB96-DE92B597AD18@gmail.com>
<3F46CDD5-DA80-49C8-A51F-8066680EF347@voskuil.org>
<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>
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, 02 Jul 2019 08:59:10 +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, 02 Jul 2019 03:45:37 -0000
Good morning Eric, and Tamas,
> In the case of tracking an asset that becomes worthless at a specific tim=
e, one could value a record of ownership, and the ability to trade ownershi=
p of the asset during the period. Consider colored coin type tracking of a =
theater ticket for a specific show, where the ticket is worthless by the en=
d of the show.
As it happens, I was playing around with another idea I am developing.
And it involves something very much similar, but distinct.
In particular, currencies are worthless unless exchanged for things of valu=
e to existent beings.
And the discovery of things of value is enabled by advertising.
The idea I am developing, is that of a "Bitcoin Classified Ads Network", wh=
erein ordinary P2PKH UTXOs (or P2WPKH equivalents) embed a commitment to an=
advertisement.
A secondary network of nodes (separate from the Bitcoin network) transmits =
the actual advertisements, as well as the UTXOs being used to commit to the=
m.
This secondary network would then reject/purge advertisements once the UTXO=
is spent on the Bitcoin blockchain.
This makes advertising costly (for the opportunity cost of locking some mon=
ey in a UTXO until one has acquired actual paying custom) while reducing im=
pact on Bitcoin blockchain space (commitment to the advertisment is in the =
same space as the ownership of the coin).
Changing the advertisement one makes is possible, at the cost of paying for=
a transaction in the Bitcoin blockchain to spend the old UTXO and publish =
a new UTXO now committing to the new advertisement.
Of note is that I also derived that it would be beneficial, for some HODLer=
s to offer their funds for the purpose of making these advertisements.
Some service or product provider would agree with an advertiser to lock som=
e coins of the advertiser for a limited amount of time, in exchange for pay=
ment upfront, with the coin address committing to the indicate advertisemen=
t of the service or product provider.
This can be done by paying to a 2p-ECDSA (or with Schnorr, MuSig) public ke=
y, with the service/product provider embedding a commitment to its advertis=
ement to its own key, and a pre-signed `nLockTime` transaction that lets th=
e advertiser recover the money.
This is in fact a similar use to the "theater ticket" case you mentioned, y=
et distinct.
In the case of the Bitcoin Classified Ads Network, it is the intermediate a=
ddresses used before reclamation by the advertiser that is valuable, as the=
y also serve as commitments to advertisements, attesting to the (probable) =
validity of the advertisement and making spam have a cost.
Given that nodes of the Bitcoin Classified Ads Network will have memory lim=
its, advertisements whose "lockup-rate" (i.e. the amount of value of the ba=
cking UTXO, divided by the size of the advertisement) are low could be evic=
ted from memory before advertisements with high lockup-rate, and thus be le=
ss likely to propagate across the network.
Thus service/product providers would want to increase their "marketing budg=
et" to be less likely to be evicted from nodes of the Bitcoin Classified Ad=
s Network, which is beneficial as it increases the minimum practical lockup=
-rate needed to spam the network, thus making spam costly.
My current plan is that the provider can contact the advertiser in order to=
effect changes to their advertisement.
Then the provider and the advertiser sign a new timelocked reclamation tran=
saction, then sign a transaction moving from the old advertisement to the n=
ew advertisement (presumably there is some protocol for ensuring the advert=
iser gets paid for this, such as an HTLC that can be triggered by an onchai=
n payment or by an LN payment; I have the details in my processing space bu=
t require some time to serialize to human-readabe format).
Arguably, this example seems to show that generalized covenants are not nee=
ded in fact, if transfers of coin require paying to the issuer/lender of th=
e coin.
Generalized covenants allows the provider (or ticket-holder in your example=
) to effect transfers from one advertisement to another (or one ticket-hold=
er to another in your example) without cooperation with the advertiser (or =
ticket-issuer in your example).
This would be otherwise needed if we lock using a 2-of-2 address that has a=
timelocked transaction to reclaim the funds.
Regards,
ZmnSCPxj
|
