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 7ACDB13BA for ; Tue, 2 Jul 2019 06:38:54 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com [209.85.221.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9012870D for ; Tue, 2 Jul 2019 06:38:53 +0000 (UTC) Received: by mail-wr1-f54.google.com with SMTP id n4so16306057wrw.13 for ; Mon, 01 Jul 2019 23:38:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=kNm9ls9vMNThL6Bh+8tZEyzxZRv/gwQPGyjKWe9goog=; b=LR+7hEpjLchf+ZTOu+ccrLnMCaNDs+63B5qLe0qRyBM2HboHBsboPz4NVS1rtA+YLs Z5f4sa4lutbU537rWvHPmyrtXpK0QRcQwqon+F9NG2/pVUhqm4QV3toTAKT/R9grWKEj nSqsdZ3i+dP9hQSgz9swzuZYaH3sfl0ugRdkeX7rvkv4wKtBJz8vx8pnghfEYtznQKpt rW7Mrt9DvPY5kWjzA7GzBts4d8l0OGI3d12PMt8QG/D9mRjH+1ao+UFfYa3p6Dep9zJt tQve8orkPtD2GKVwM2O3a+V5rBY4FUV74FeCztId59ew7eoqHJbj5C2TkbVbPxizDWh5 fdZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=kNm9ls9vMNThL6Bh+8tZEyzxZRv/gwQPGyjKWe9goog=; b=IBHKqX19/IlxtSvwfRHuZy8Vbum+SEPIW/ZW04aQmDYjh0eUXdLQn6uf+GtsCxbrQA cUQFWXBH8qNmVw9o9KJPSrzkNLhhb5nicaVmTbC4LUUG5aq+Nw4bvZms45xhR9bLafuS bOzvhwe73TwcNKDatdkilKQngrZjk3Y5doEZecqOekz5f4qoYEeqqCiDkAKWBc+5bTlc voBv71QIK1BV4L4fHbuFnZ9aShLMKLu5acBGM6RJVdBxtyxkn2/7s6Z3JLReENAYUyvt HCHIPfwGfIyfk2uS2ZGEbuteAvucbREM4rgbjzHbrJ3rtNdHg+vSRBEmpvz0UbR2leh6 IQLQ== X-Gm-Message-State: APjAAAUgFf6ysZ5sv1rE9+X8GgLeGMDtd75x0cJRpbrZ6paIjV4vacgJ hvnhk8miuMq68J7+fceOyls= X-Google-Smtp-Source: APXvYqzAXfLGNGn6cJ1npmeanHTjua9epznXKhy2Hyo1JKuTa/ppQm41FrguAgLVAz591hlJ1QMQlQ== X-Received: by 2002:adf:b64b:: with SMTP id i11mr22032428wre.205.1562049532100; Mon, 01 Jul 2019 23:38:52 -0700 (PDT) Received: from p200300dd6712642569ab198ddd49c683.dip0.t-ipconnect.de (p200300DD6712642569AB198DDD49C683.dip0.t-ipconnect.de. [2003:dd:6712:6425:69ab:198d:dd49:c683]) by smtp.gmail.com with ESMTPSA id c6sm1636405wma.25.2019.07.01.23.38.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 Jul 2019 23:38:50 -0700 (PDT) From: Tamas Blummer Message-Id: <0190F226-7133-4B6D-8750-25CAB5C73D17@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_8F195431-A21F-4909-B848-77B2A195A26B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 2 Jul 2019 08:38:55 +0200 In-Reply-To: <0Bwi2ejRw4BgoABZ0X0kBdwLAkIKEv1svoyi0zqGQPeqV1g8xR43tBMgYoS52Vcxkgj7DndmNLIje40au51trIGTvrpcet8GivTgqysVC8w=@protonmail.com> To: ZmnSCPxj References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com> <1A808C88-63FD-4F45-8C95-2B8B4D99EDF5@gmail.com> <83705370-79FC-4006-BA04-4782AD5BE70B@voskuil.org> <3F46CDD5-DA80-49C8-A51F-8066680EF347@voskuil.org> <063D7C06-F5D8-425B-80CE-CAE03A1AAD0C@voskuil.org> <0AA10217-E1CC-46D1-9B43-038CEEF942CD@gmail.com> <0Bwi2ejRw4BgoABZ0X0kBdwLAkIKEv1svoyi0zqGQPeqV1g8xR43tBMgYoS52Vcxkgj7DndmNLIje40au51trIGTvrpcet8GivTgqysVC8w=@protonmail.com> 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: Tue, 02 Jul 2019 08:59:10 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve 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: Tue, 02 Jul 2019 06:38:54 -0000 --Apple-Mail=_8F195431-A21F-4909-B848-77B2A195A26B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good morning Eric and ZmnSCPxj, > On Jul 2, 2019, at 05:45, ZmnSCPxj wrote: >=20 > Good morning Eric, and Tamas, >=20 >> In the case of tracking an asset that becomes worthless at a specific = time, one could value a record of ownership, and the ability to trade = ownership of the asset during the period. Consider colored coin type = tracking of a theater ticket for a specific show, where the ticket is = worthless by the end of the show. >=20 > As it happens, I was playing around with another idea I am developing. > And it involves something very much similar, but distinct. >=20 > In particular, currencies are worthless unless exchanged for things of = value to existent beings. > And the discovery of things of value is enabled by advertising. > The idea I am developing, is that of a "Bitcoin Classified Ads = Network", wherein ordinary P2PKH UTXOs (or P2WPKH equivalents) embed a = commitment to an advertisement. > A secondary network of nodes (separate from the Bitcoin network) = transmits the actual advertisements, as well as the UTXOs being used to = commit to them. > This secondary network would then reject/purge advertisements once the = UTXO is spent on the Bitcoin blockchain. > This makes advertising costly (for the opportunity cost of locking = some money in a UTXO until one has acquired actual paying custom) while = reducing impact on Bitcoin blockchain space (commitment to the = advertisment is in the same space as the ownership of the coin). > Changing the advertisement one makes is possible, at the cost of = paying for a transaction in the Bitcoin blockchain to spend the old UTXO = and publish a new UTXO now committing to the new advertisement. >=20 > Of note is that I also derived that it would be beneficial, for some = HODLers to offer their funds for the purpose of making these = advertisements. All above aligns with my intuition that: on one side giving up temporary = control of UTXOs represent opportunity cost and on the receiver side = having temporary control can unlock utility they would pay for. If the techical setup is trustless and return of control to those who = gave it up temporarilty is certain, then this in combination means that = HODLer are able to earn riskless interest by giving up control of their = UTXOs temporarily. > Some service or product provider would agree with an advertiser to = lock some coins of the advertiser for a limited amount of time, in = exchange for payment upfront, with the coin address committing to the = indicate advertisement of the service or product provider. > This can be done by paying to a 2p-ECDSA (or with Schnorr, MuSig) = public key, with the service/product provider embedding a commitment to = its advertisement to its own key, and a pre-signed `nLockTime` = transaction that lets the advertiser recover the money. >=20 > This is in fact a similar use to the "theater ticket" case you = mentioned, yet distinct. > In the case of the Bitcoin Classified Ads Network, it is the = intermediate addresses used before reclamation by the advertiser that is = valuable, as they also serve as commitments to advertisements, attesting = to the (probable) validity of the advertisement and making spam have a = cost. > Given that nodes of the Bitcoin Classified Ads Network will have = memory limits, advertisements whose "lockup-rate" (i.e. the amount of = value of the backing UTXO, divided by the size of the advertisement) are = low could be evicted from memory before advertisements with high = lockup-rate, and thus be less likely to propagate across the network. > Thus service/product providers would want to increase their "marketing = budget" to be less likely to be evicted from nodes of the Bitcoin = Classified Ads Network, which is beneficial as it increases the minimum = practical lockup-rate needed to spam the network, thus making spam = costly. >=20 > My current plan is that the provider can contact the advertiser in = order to effect changes to their advertisement. > Then the provider and the advertiser sign a new timelocked reclamation = transaction, then sign a transaction moving from the old advertisement = to the new advertisement (presumably there is some protocol for ensuring = the advertiser gets paid for this, such as an HTLC that can be triggered = by an onchain payment or by an LN payment; I have the details in my = processing space but require some time to serialize to human-readabe = format). >=20 > Arguably, this example seems to show that generalized covenants are = not needed in fact, if transfers of coin require paying to the = issuer/lender of the coin. > Generalized covenants allows the provider (or ticket-holder in your = example) to effect transfers from one advertisement to another (or one = ticket-holder to another in your example) without cooperation with the = advertiser (or ticket-issuer in your example). > This would be otherwise needed if we lock using a 2-of-2 address that = has a timelocked transaction to reclaim the funds. Yes, your example does not need the covenant as the one who gave up = temporary control is still involved in any motion of the UTXO, therefore = able to enforce own interest that reclaiming the UTXOs remains possible. A covenant is needed only if it is against the interest of all parties = involved in transfers of the UTXO, in which case consensus must enforce = that it is carried forward. The added strength of the covenant is that the one who gives up = temporary control does not have to be involved in using the UTXO until = it is given back. Note that the advertizing service provider would need temporary access = to UTXOs of signficant value, so opportunity cost and thereby cost of = advertizing becomes significant. Covenants would allow the separation of the advertizing service from = HODLer funding it with significant UTXOs. HODLer could give temporary control to the service and the service could = broker those to others, but the original HODLer was sure to receive the = UTXOs back and the HODLer would not be bothered with the operation of = the service. The covenant I proposed would add an alternate taproot validation path = stacked onto previously existing ones. This means that one could give others temporary access for a shorter = time period than one=E2=80=99s own temporary access. One could however not override the delayed access secured for the = HODLer. Does this remind you of something? Yes, the service provider would act = like a bank, matching depositor, the HODLer, with those who need = temporary control of UTXO for advertizing purposes. This shows why temporary control with covenant can be understood as loan = in a full reserve banking, which started my exploration of this topic. Current technical means do not allow trustless and hands-off = coordination of provider of UTXOs (that is capital) with provider of = arbitary services that monetize the use of Bitcoin=E2=80=99s unforgable = registry. In other words we need covenants to enable Bitcoin applications to = trustlessly and flexibly deal with foreign capital. One other thing the consensus would have to ensure is that inputs with = covenants are merged only into outputs with same covenant. Which makes UTXOs with a particular covenants obey rules earlier known = for colored coins and transactions moving it form a distinct embedded = chain. Adding same covenant establishes fungible coinbases of same embedded = chain and dropping the covenant makes them again fungible with common = UTXOs. I could not be more excited of what boost this could give to the Bitcoin = economy, unlocking the use of its unforgeable registry to track any = asset with the same security guarantees it offers for its own cash = token. Best to you, Tamas Blummer >=20 > Regards, > ZmnSCPxj --Apple-Mail=_8F195431-A21F-4909-B848-77B2A195A26B 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----- iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAl0a/AAACgkQ9nKRxRdx ORx1lggAx5OIjv9yGMl3CLVVcwOQLSpu8ikEHyk3OGyGCfQek9nw3qTsHPplGS0j 5ifs2ERyffycw3NRh+1i0ATGdQt9wehj5dVMIAGmk6BRRlW2b1jMERLoLYv1yyGQ /0USdNHE0JpKQ1lZCCWRQYO+yMXd6DabciKZod6r8/FEUtlxpKK+yFOAjJ1h9oJ1 tmO8k+WUuTL6HnY8CYFNIWjyrT5cnKTIlxO0kPI1IGCA2+pPJaFCxZIgrWudxl8a KR/9hFXLO3c9Lsb765PNigAHJqylrbPggFhGIZNXqHR2am2ljEPiTlctHCuii+Sv IM9myGvAPGIxxB5B2aMlohMYWGMEJA== =qB3c -----END PGP SIGNATURE----- --Apple-Mail=_8F195431-A21F-4909-B848-77B2A195A26B--