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 87AA21281 for ; Tue, 2 Jul 2019 03:45:37 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 890D870D for ; Tue, 2 Jul 2019 03:45:36 +0000 (UTC) Date: Tue, 02 Jul 2019 03:45:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1562039134; bh=v0TjgFDDOxLB7036abWG3FjP8+wPjmhF4U8VW9lyBKk=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=fWfAhjJ6JyqtjHKwjfZg8QqtwhQnfyNwyltAJFAVtIv+zNu9wpA5kZmHME8WpEaZm YUnYe2MJZLmJL4q/rmct35XaLuFZa65k7yyuMvoizM/lIy10NYX5Dan8/27fn67MW0 NuvjdvX8Yjq6VZpo1HQVti9wIm5JnRxOpi1ltjhU= To: Eric Voskuil , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <0Bwi2ejRw4BgoABZ0X0kBdwLAkIKEv1svoyi0zqGQPeqV1g8xR43tBMgYoS52Vcxkgj7DndmNLIje40au51trIGTvrpcet8GivTgqysVC8w=@protonmail.com> In-Reply-To: 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> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW 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 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 03:45:37 -0000 Good morning Eric, and Tamas, > In the case of tracking an asset that becomes worthless at a specific tim= e, one could value a record of ownership, and the ability to trade ownershi= p 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 en= d of the show. As it happens, I was playing around with another idea I am developing. And it involves something very much similar, but distinct. In particular, currencies are worthless unless exchanged for things of valu= e 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", wh= erein 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 the= m. 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 mon= ey in a UTXO until one has acquired actual paying custom) while reducing im= pact 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. Of note is that I also derived that it would be beneficial, for some HODLer= s to offer their funds for the purpose of making these advertisements. Some service or product provider would agree with an advertiser to lock som= e coins of the advertiser for a limited amount of time, in exchange for pay= ment upfront, with the coin address committing to the indicate advertisemen= t of the service or product provider. This can be done by paying to a 2p-ECDSA (or with Schnorr, MuSig) public ke= y, with the service/product provider embedding a commitment to its advertis= ement to its own key, and a pre-signed `nLockTime` transaction that lets th= e advertiser recover the money. This is in fact a similar use to the "theater ticket" case you mentioned, y= et distinct. In the case of the Bitcoin Classified Ads Network, it is the intermediate a= ddresses used before reclamation by the advertiser that is valuable, as the= y 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 lim= its, advertisements whose "lockup-rate" (i.e. the amount of value of the ba= cking UTXO, divided by the size of the advertisement) are low could be evic= ted from memory before advertisements with high lockup-rate, and thus be le= ss likely to propagate across the network. Thus service/product providers would want to increase their "marketing budg= et" to be less likely to be evicted from nodes of the Bitcoin Classified Ad= s Network, which is beneficial as it increases the minimum practical lockup= -rate needed to spam the network, thus making spam costly. 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 tran= saction, then sign a transaction moving from the old advertisement to the n= ew advertisement (presumably there is some protocol for ensuring the advert= iser gets paid for this, such as an HTLC that can be triggered by an onchai= n payment or by an LN payment; I have the details in my processing space bu= t require some time to serialize to human-readabe format). Arguably, this example seems to show that generalized covenants are not nee= ded in fact, if transfers of coin require paying to the issuer/lender of th= e coin. Generalized covenants allows the provider (or ticket-holder in your example= ) to effect transfers from one advertisement to another (or one ticket-hold= er 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. Regards, ZmnSCPxj