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
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
|
Return-Path: <tamas.blummer@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E1ACCCCE
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Aug 2019 02:32:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f52.google.com (mail-wm1-f52.google.com
[209.85.128.52])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9DBA58D
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 14 Aug 2019 02:32:45 +0000 (UTC)
Received: by mail-wm1-f52.google.com with SMTP id z23so3071629wmf.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 13 Aug 2019 19:32:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=from:mime-version:subject:message-id:date:cc:to;
bh=SdnmnsfOx18QQDnrWAx4deakxPA4Le3hdVth+eQ7iJs=;
b=RE/8N7P1Zk6tLHN7n3/f9b9xKnbPoX17jZqffNQe9RMuouIR4XqhzHFet19Z8wJnir
iIjw6aWC+kiu7Hg1e2sUmo2DwilK8XTjunKgblLxd5FsrWYAgT7FeA7yErJyBUvPTLUD
ejuBjJWaBECydv918ZK6bz0DSlPENn3a/DV1G29FcNBo0sc8GCk7nDw7rPGOnAGZcqLo
0rrhWnKphhUasaKvQc5VKgH1Bps0Rv98eJkgRfdKMGrJBoa4uRlNOeopTluz8A+4fN2n
UCzl0d4x6W3GfIaVmC3frJc4YgZiZri1yCDPzEecCKunoUc0ZySe9kqMpbwpDbidLS4a
A8JA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to;
bh=SdnmnsfOx18QQDnrWAx4deakxPA4Le3hdVth+eQ7iJs=;
b=H3q4qn7f+ctlyFeCJvZ35jAmyledDgL3Gn5+JEfCLwfi+WBR99aBJLZUxQvieChcc4
i6d+DeEOBRp5PbHiAI5lJzcJVNyMgC4vOePRkNb6xCOYgU42GkdBhNOWnVdbWX5/k3WP
DIVTUuX5E/29j6kRZ3nc6l+ByMAuKTdH04SJHPnJaXvE8OhCwAXs/TRx3k3nrHawRtT2
HzALfqhsi7pqgcoCLn3s7njkF+0Fm1Ei9YHo1b4sPKKR4BYGSn2G9HfV+xd23jF/V4bF
QBYGhVBGv6+J1NQhu3FiawZMDLb6Ff/2r+4fZPyk1kekIj7q/H8FkortqhYjMqT39wHt
66bQ==
X-Gm-Message-State: APjAAAXgQ04omDzw0GCuyrhuzeezn0iQHdcVVz9GKN//iQt/Uq5nWW1r
++Bc8QcCKQhw/4wlNcqiERY5QaEP8Oo=
X-Google-Smtp-Source: APXvYqyFELzg9t67S2N9ayZYDKDpEFsZM4WfRiWBfYIMzMZCFeFef0QidBIcwg5WZUhqJgKZb4lDVA==
X-Received: by 2002:a1c:7014:: with SMTP id l20mr5750126wmc.45.1565749963881;
Tue, 13 Aug 2019 19:32:43 -0700 (PDT)
Received: from p200300dd67126444d86c36bd7e63cc58.dip0.t-ipconnect.de
(p200300DD67126444D86C36BD7E63CC58.dip0.t-ipconnect.de.
[2003:dd:6712:6444:d86c:36bd:7e63:cc58])
by smtp.gmail.com with ESMTPSA id
i66sm5401026wmi.11.2019.08.13.19.32.43
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
Tue, 13 Aug 2019 19:32:43 -0700 (PDT)
From: Tamas Blummer <tamas.blummer@gmail.com>
Content-Type: multipart/signed;
boundary="Apple-Mail=_B34B3C04-3B73-484C-987F-19245E1ED1FB";
protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Message-Id: <56030D8B-0EF4-4BE1-9CA0-EEDC2CF1B235@gmail.com>
Date: Wed, 14 Aug 2019 04:32:40 +0200
To: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
RCVD_IN_DNSWL_NONE 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: Wed, 14 Aug 2019 02:53:47 +0000
Cc: tyzbit@gmail.com
Subject: [bitcoin-dev] side memory - Transient memory of an other peer to
peer network controlled through the bitcoin utxo set
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: Wed, 14 Aug 2019 02:32:47 -0000
--Apple-Mail=_B34B3C04-3B73-484C-987F-19245E1ED1FB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=utf-8
It appears to me that there is a generic design pattern for peer to peer =
networks,
that we might call side memory.
The name is justified with some similarity to side chains. Side memory =
is however
not about a persistent store, but some transient memory of an other peer =
to peer network.
The UTXO set is the shared transient memory of the bitcoin network.
Just like we can link the bitcoin block chain with a side chain, we can =
link
the transient memory of an other network with the UTXO set of bitcoin.
The other network=E2=80=99s transient memory would hold an item until a =
uniquelly associated
a coin in the UTXO set is unspent. There are many ways to associate data =
with
an UTXO. How this is done is not a concern here. The method must however =
allow
the coin to be spent again, so the UTXO set can also trigger eviction of =
the associated
data from the other network=E2=80=99s memory.
The utility of such association is to impose control and the scarcity of =
bitcoin to
some other network=E2=80=99s transient memory.
Since the number of possible UTXOs is huge (21 million * 100million) an
associated peer to peer network will want to raise the bar for UTXOs =
eligible
to enter its store.
An obvious choice for raising the bar is requiring more satoshis to be =
committed.
The other network may dynamically tailor this requirement or let users =
compete
for a fixed capacity by committing higher amounts.
Observing the UTXO set is however not a cheap operation. Nodes of the =
other
network would have to also run a bitcoin node to be sure they do not =
miss
changes of the UTXO.
There is however a way to significantly simplify this task by using time =
locks and
SPV validation as follows:
The UTXO committing to associated data would have a relative timelock, =
such that
it can not be spent within n blocks after it entered the UTXO set. (with =
OP_CSV)
A network node that originally publishes the data would also send an SPV =
proof
of the inclusion of associated commitment into the bitcoin blockchain to =
its peers.
Other network nodes would therefore only need to observe the progress of
bitcoin=E2=80=99s header chain to validate the proof, which is the =
commitment transaction
and the path to merkle root, before accepting data into their transient =
store.
The commitment transaction also tells them how long the output can not =
be spent,
therefore they are relived the burden of watching for UTXO spends. =
Instead they
can evict the associated data from their transient store as soon as the =
header
chain they oberve is progressed past the relative locktime.
Nodes that publish new data would have to listen to all blocks after =
they
broadcast the commitment, until they see it confirmed and can extract =
the proof.
This could be further optimized if BIP158 filters were available and =
committed.
The network nodes could use IBLTs (Invertible Bloom Lookup Tables) to =
distribute
associated data.
Such an associated network would be lightweight since only observing and
storing bitcoin=E2=80=99s header chain and its own peer to peer network.
I will soon release the code of a network that implements this design =
pattern,
with the SPV optimization and IBLTs, and am looking for help to test it =
in a
limited deployment, before letting it out into the wild.
Please drop me a mail if you=E2=80=99d like to help there.
Prior art that I summed up as side memory:
The idea of linking names with UTXO goes back to the first fork of =
Bitcoin and
was significantly upgraded in the numerifides proposal[1] of tyzbit
ZmnSCPxj proposed an advertizement network in which the network's =
content
is controlled by associated UTXOs in [2].
I observed that time locked commitments would uncover to bitcoin=E2=80=99s=
internal
riskless interest rate [3].
The pattern is useful as sybill attack protection of coinjoin networks =
as time locked
commitments can act as fidelity bonds [4]
Regards,
Tamas Blummer
[1] =
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-April/00120=
7.html
[2] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083.h=
tml
[3] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017059.h=
tml
[4] =
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017169.h=
tml
--Apple-Mail=_B34B3C04-3B73-484C-987F-19245E1ED1FB
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP
-----BEGIN PGP SIGNATURE-----
iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAl1TcsgACgkQ9nKRxRdx
ORw+lQgAxZ7iuPhxOJqg6NLKZ1Ks6qK960uV0MTyN7IC6Cs9uzjc+FDIOL3l71Yh
0XAM9RxMDxxmUEjo4cZPp8DUFKPf/W6qOl2+0wpiytUHsSkdDj1t0K74FNhgkxtU
C9Q46E/qYfJmyFgS2FejR+lxAWmo3wTX4MTffSDDyKy8h1wdZ9GOABLrDtN8uKdm
Pl50BxjJzXSg7XimFR68gYW71EkXHBMtgZhmYd4q5DDR5/n/xIdfrpkx8UkFfQf9
DHmtUQ28jILHMilbN5VTlBmNCF3hkGgjK46xd7wVaf1wBhxXlBDFPnur7EHH8+H/
ZBz3q7cPnlxVfDJtmZ+qsegX89Q0Ew==
=z0bA
-----END PGP SIGNATURE-----
--Apple-Mail=_B34B3C04-3B73-484C-987F-19245E1ED1FB--
|
