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 8880E15B3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 2 Jul 2019 08:12:37 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40136.protonmail.ch (mail-40136.protonmail.ch
[185.70.40.136])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9741D70D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 2 Jul 2019 08:12:36 +0000 (UTC)
Date: Tue, 02 Jul 2019 08:12:26 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1562055154;
bh=Wu5tSzH5n0psvWYZ66y5ZUpOvwRS7jNGBJt0ZeHdacI=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=Qb4dTv5cOpJBzYDBHci+UFjLjSglpXtewcU50rcng9sYTFZVRDcUyONqCbVtuT3xj
SUFVInlWv+wV/9aEr6rY0g5xCOZ9tq8Keo/jtfp+89jb8aHWjoa2V9IVLyFJR4GgW7
Da1MzTYPR0TkElb22vKro6A1o0Z5p2yydKejJ5xM=
To: Tamas Blummer <tamas.blummer@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <7E8yyDSqmXEfFtcZRx2vdmPuovamf67X6aDHrokgaYScm01zPivVKpI3Br2PrzBdVdvKBqECP96EFB5ebT8sPfMWU8npJwS_wujFs00bcqU=@protonmail.com>
In-Reply-To: <0190F226-7133-4B6D-8750-25CAB5C73D17@gmail.com>
References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com>
<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>
<0Bwi2ejRw4BgoABZ0X0kBdwLAkIKEv1svoyi0zqGQPeqV1g8xR43tBMgYoS52Vcxkgj7DndmNLIje40au51trIGTvrpcet8GivTgqysVC8w=@protonmail.com>
<0190F226-7133-4B6D-8750-25CAB5C73D17@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, 02 Jul 2019 08:59:10 +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: Tue, 02 Jul 2019 08:12:37 -0000
Good morning Tamas,
> Note that the advertizing service provider would need temporary access to=
UTXOs of signficant value, so opportunity cost and thereby cost of adverti=
zing becomes significant.
> Covenants would allow the separation of the advertizing service from HODL=
er funding it with significant UTXOs.
> HODLer could give temporary control to the service and the service could =
broker those to others, but the original HODLer was sure to receive the UTX=
Os back and the HODLer would not be bothered with the operation of the serv=
ice.
Thank you for this thought.
It has challenged me to consider how to bring this capability out of the Bi=
tcoin blockchain.
As a counterargument, I observe that committing to the advertisement on the=
UTXO is similar to committing to a SCRIPT on a UTXO.
And I observe the Graftroot idea, wherein we commit to a public key on the =
UTXO, and admit a SCRIPT that is signed by the public key as a SCRIPT that =
unlocks the UTXO for spending.
By analogy, in my "advertising" scheme, instead of committing the advertise=
ment on the UTXO, I can instead commit a public key (for example, the hash =
of the "advertiser pubkey" is used to tweak the onchain public key).
Then we use this advertiser pubkey to admit advertisements on the advertisi=
ng network.
This advertiser pubkey is used to sign an "advertisement chain", which is a=
merklized singly-linked list whose contents are the actual advertisements,=
each node being signed using the advertiser pubkey.
To ensure that the advertiser does not sign multiple versions of this chain=
, we can have the signing nonce be derived from the height of the advertcha=
in, such that signing the same height multiple times leads to private key r=
evelation.
Each header of the advertchain also includes a `CLTV`-like construct, which=
is the Bitcoin blockheight that must be reached first before another adver=
tchain header can be added, containing a new advertisement that replaces th=
e previous one.
This lets an advertising broker pay for some onchain UTXO to a HODLer, prov=
iding a `nLockTime`d onchain transaction returning the funds to the HODLer,=
with the UTXO paying to a 2-of-2 with a commitment to the advertiser pubke=
y.
Then the advertising broker can rent out the UTXO to providers who wish to =
advertise, though I have to figure out how to make this atomic (i.e. paying=
the advertiser onchain or on Lightning, would be enough for the provider t=
o derive the advertchain header and its signature, for its own advertisemen=
t --- perhaps some minimal SCRIPT-like language on the advertchain can be d=
one).
This lets the advertising broker case to work even without generalized cove=
nants on the Bitcoin blockchain, while providing the same benefit of not bo=
thering the HODLer who ultimately owns the funds each time advertisements n=
eed to be changed.
This gives the advantage that changes to the advertisement that is attested=
by a UTXO do not have any activity on the Bitcoin blockchain itself, only =
on the advertchain; at the cost that the advertising network now takes on t=
he added bandwidth of handling several tiny blockchains of limited lifetime=
, instead of keeping the data on "which advertisement is valid" on the Bitc=
oin blockchain.
Regards,
ZmnSCPxj
|
