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
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
