From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E1ACCCCE for ; 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 ; Wed, 14 Aug 2019 02:32:45 +0000 (UTC) Received: by mail-wm1-f52.google.com with SMTP id z23so3071629wmf.2 for ; 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 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--