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
|
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 852AC15D4
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 2 Jul 2019 10:33:49 +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 96000834
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 2 Jul 2019 10:33:48 +0000 (UTC)
Date: Tue, 02 Jul 2019 10:33:42 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=default; t=1562063626;
bh=BfZDF7gvi1134aslkxMfOvTXBpXNvwmckDy0Z1fSiV4=;
h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
Feedback-ID:From;
b=hqVv2MB7I6Ace0P9McG8Ru2WkYk9hPglpN/QyzeQ9JMhzlTKwH7Jbu/BpA/X/oXke
IAvaZdLdbnG2RqC6JIay8y7VqL76RSmz3HtuRT1b4/HdKuxY2tV6KAnuStk+hqZ655
gNtGpHbbHSLL70C8qVwtHN7EtbXDkHCscXWc2XDw=
To: Tamas Blummer <tamas.blummer@gmail.com>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <za891lsGkbAxQjS4ppao6-qhV7yjCLp0uKglEuyBRFwk2p09jSvWJP1WD9MMt_DE82KPOx90UhiwS-zAp_zbgrLyTmBBQvcux61ENTDhDBA=@protonmail.com>
In-Reply-To: <38FAD812-A764-49F5-BA80-ED10685A1714@gmail.com>
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>
<0Bwi2ejRw4BgoABZ0X0kBdwLAkIKEv1svoyi0zqGQPeqV1g8xR43tBMgYoS52Vcxkgj7DndmNLIje40au51trIGTvrpcet8GivTgqysVC8w=@protonmail.com>
<0190F226-7133-4B6D-8750-25CAB5C73D17@gmail.com>
<7E8yyDSqmXEfFtcZRx2vdmPuovamf67X6aDHrokgaYScm01zPivVKpI3Br2PrzBdVdvKBqECP96EFB5ebT8sPfMWU8npJwS_wujFs00bcqU=@protonmail.com>
<38FAD812-A764-49F5-BA80-ED10685A1714@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 13:00:30 +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 10:33:49 -0000
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 Tuesday, July 2, 2019 5:30 PM, Tamas Blummer <tamas.blummer@gmail.com> w=
rote:
> Hello ZmnSCPxj,
>
> > On Jul 2, 2019, at 10:12, ZmnSCPxj ZmnSCPxj@protonmail.com wrote:
> > 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 t=
hat unlocks the UTXO for spending.
> > By analogy, in my "advertising" scheme, instead of committing the adver=
tisement on the UTXO, I can instead commit a public key (for example, the h=
ash of the "advertiser pubkey" is used to tweak the onchain public key).
> > Then we use this advertiser pubkey to admit advertisements on the adver=
tising network.
> > This advertiser pubkey is used to sign an "advertisement chain", which =
is a merklized singly-linked list whose contents are the actual advertiseme=
nts, each node being signed using the advertiser pubkey.
> > To ensure that the advertiser does not sign multiple versions of this c=
hain, we can have the signing nonce be derived from the height of the adver=
tchain, such that signing the same height multiple times leads to private k=
ey revelation.
>
> The advertiser would thereby put the funds of the HODLer on risk of his m=
isbehavior, which means the HODLer would have to trust the advertizing serv=
ice.
No it would not :)
Onchain, the locked UTXO would be a 2-of-2 MuSig / 2p-ECDSA of the HODLer a=
nd the advertising broker.
The HODLer and advertising broker perform a (mostly-offchain) ritual that e=
nsures that the HODLer gets a `nLockTime` transaction spending from this UT=
XO and paying it back to the HODLer, and that the advertising broker pays f=
or rent of this UTXO, prior to the UTXO actually appearing onchain.
The UTXO requires both cooperation of HODLer and advertising broker in orde=
r to spend, and the HODLer only cares that it gets an `nLockTime` transacti=
on and will no longer cooperate / will permanently delete its share of the =
key after getting this.
The MuSig / 2p-ECDSA pubkey used will then be tweaked (by addition in MuSig=
, by multiplication in 2p-ECDSA; the HOLDer need not even learn it, the adv=
ertising broker can tweak its pubkey in the Bitcoin-level transaction befor=
ehand) to commit to a hash of the "Advertising pubkey".
Thus I say the UTXO "commits to the advertising pubkey", not "pays to the a=
dvertising pubkey".
Indeed, the pubkey of the advertising broker used on the Bitcoin blockchain=
can be very different from the advertising pubkey used on the advertchain.
This "Advertising pubkey" is the pubkey used in the advertchain.
The actual money on Bitcoin cannot be spent by the broker unilaterally.
However, what advertisement it will commit to on the advertchain, can be co=
ntrolled unilaterally by the advertising broker.
That is the entire point: the HODLer rents out the UTXO to the advertising =
broker, relinquishes control over the advertchain, but retaining (eventual)=
control over the actual Bitcoins.
The advertising broker then has sole control of the advertchain, and can re=
nt it out for smaller timeframes to actual service/product providers.
Regards,
ZmnSCPxj
|
