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>
Cc: tyzbit@gmail.com
Subject: [bitcoin-dev] side memory - Transient memory of an other peer to
 peer network controlled through the bitcoin utxo set
Precedence: list


--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--