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
|
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 2A223CAE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Jul 2019 04:05:18 +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 35EAD70D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 5 Jul 2019 04:05:16 +0000 (UTC)
Date: Fri, 05 Jul 2019 04:05:12 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1562299514;
bh=/Y3DxK69m3SI27oU9Ob171lQsX9/X0VKmaPRNfzSKH0=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=Mk1Hq9pvOmb4OjkXfzk25YqO4WFIOIYZdTTY9Y8oPATjC3Dz7MdTne7w5Mmz2eYId
N4Zb1WSAvhwvsWRq0Qy6cz1t3XKwIWCD4KLgwbRw285pmak9kKrh2hon/xCL3XjoZf
EoWcHZTJDJFRpyM5cToser2vJtexMyk9cH6K77T0=
To: Eric Voskuil <eric@voskuil.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <kSCa9KUmpJox2_aglqhel-WdGlXf14mfKNZ95T4xqsrkQJ2Zh5zFA-Llq-j9cXX87iEPP5_aCkO9oR5kfQGKMBK9ds3Jct1V1FAawwa4CyE=@protonmail.com>
In-Reply-To: <F17F2E86-BFA4-456E-85F9-0D6583692AEC@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>
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: Fri, 05 Jul 2019 13:53:16 +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 04:05:18 -0000
Good morning Eric,
> 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 va=
lue). 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 s=
ense to spend that coin in support of the secondary network (e.g. paying fo=
r confirmation security), just as with the burning of energy in Bitcoin min=
ing?
Using the unspentness-time of a UTXO allows for someone advertising a servi=
ce 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=
them 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, t=
hey can immediately reap the rewards of not having their funds locked anymo=
re).
Similarly, an entity renting out a UTXO for an advertisement might allow fo=
r 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 lea=
se it to another advertiser.
Burnt funds cannot be "un-burnt" to easily signal the end of a term for an =
advertisement.
Similarly for miner fees.
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 =
them be dropped from their advertisements pool.
Less importantly, burning currently has bad resource usage for practical ap=
plications.
Practical burning requires spending to a provably-unspendable P2PKH or P2SH=
or similar output.
This adds UTXO entries to the UTXO database that will never be removed.
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.
Thus I think use of UTXO is better than burning or mining-fee-spending.
Also, mostly trivia:
The use of UTXOs to advertise services is not original to me --- I found th=
e LN channel gossip to be the inspiration for this.
Publicly-announced channels indicate the backing UTXO that funds the channe=
l.
The purpose of publicly announcing the channels is to be able to provide th=
e 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 mechan=
ism.
Regards,
ZmnSCPxj
|
