[bitcoin-dev] side memory - Transient memory of an other peer to peer network controlled through the bitcoin utxo set

[Tamas Blummer <tamas.blummer@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4271 bytes --]

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’s 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’s memory.

The utility of such association is to impose control and the scarcity of bitcoin to
some other network’s 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’s 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’s 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’d 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’s 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/001207.html
[2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083.html
[3] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017059.html
[4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017169.html

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]