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 2A223CAE for ; Fri, 5 Jul 2019 04:05:18 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 35EAD70D for ; Fri, 5 Jul 2019 04:05:16 +0000 (UTC) Date: Fri, 05 Jul 2019 04:05:12 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1562299514; bh=/Y3DxK69m3SI27oU9Ob171lQsX9/X0VKmaPRNfzSKH0=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=Mk1Hq9pvOmb4OjkXfzk25YqO4WFIOIYZdTTY9Y8oPATjC3Dz7MdTne7w5Mmz2eYId N4Zb1WSAvhwvsWRq0Qy6cz1t3XKwIWCD4KLgwbRw285pmak9kKrh2hon/xCL3XjoZf EoWcHZTJDJFRpyM5cToser2vJtexMyk9cH6K77T0= To: Eric Voskuil From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com> <063D7C06-F5D8-425B-80CE-CAE03A1AAD0C@voskuil.org> <0AA10217-E1CC-46D1-9B43-038CEEF942CD@gmail.com> <6B9A04E2-8EEE-40A0-8B39-64AA0F478CAB@voskuil.org> 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: Fri, 05 Jul 2019 13:53:16 +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: Fri, 05 Jul 2019 04:05:18 -0000 Good morning Eric, > As with Bitcoin mining, it is the consumed cost that matters in this scen= ario, (i.e., not the hash rate, or in this case the encumbered coin face va= lue). Why would the advertiser not simply be required to burn .1 coin for t= he same privilege, just as miners burn energy? Why would it not make more s= ense to spend that coin in support of the secondary network (e.g. paying fo= r confirmation security), just as with the burning of energy in Bitcoin min= ing? Using the unspentness-time of a UTXO allows for someone advertising a servi= ce or producer to "close up shop" by simply spending the advertising UTXO. For instance, if the advertisement is for sale of a limited stock of goods,= once the stock has been sold, the merchant (assuming the merchant used own= funds) can simply recover the locked funds, with the potential to reinvest= them elsewhere. This allows some time-based hedging for the merchant (they may be willing t= o wait indefinitely for the stock to be sold, but once the stock is sold, t= hey can immediately reap the rewards of not having their funds locked anymo= re). Similarly, an entity renting out a UTXO for an advertisement might allow fo= r early reclamation of the UTXO in exchange for partial refund of fee; as t= he value in the UTXO is now freed to be spent elsewhere, the lessor can lea= se it to another advertiser. Burnt funds cannot be "un-burnt" to easily signal the end of a term for an = advertisement. Similarly for miner fees. The best that can be done would be to have the nodes of the classified ads = network automatically decay the spent value of older advertisements to let = them be dropped from their advertisements pool. Less importantly, burning currently has bad resource usage for practical ap= plications. Practical burning requires spending to a provably-unspendable P2PKH or P2SH= or similar output. This adds UTXO entries to the UTXO database that will never be removed. This will of course be remedied by compact UTXO representations later, but = not today. Similarly, it would be very nice to have non-0-amount `OP_RETURN` outputs, = as `OP_RETURN` outputs are never stored in the UTXO database. However, this will require a change in node relay policy, which again will = take time to make possible, and would not be practical today. Thus I think use of UTXO is better than burning or mining-fee-spending. Also, mostly trivia: The use of UTXOs to advertise services is not original to me --- I found th= e LN channel gossip to be the inspiration for this. Publicly-announced channels indicate the backing UTXO that funds the channe= l. The purpose of publicly announcing the channels is to be able to provide th= e service, of forwarding across the Lightning Network; thus the public anno= uncement serves as an advertisement for the service. Channel closure immediately spends the UTXO, and also doubles to "revoke" t= he existing "advertisement". I found this ability to "revoke" the advertisement appealing, and thereby d= esigned the Bitcoin Classified Ads Network around the UTXO spentness mechan= ism. Regards, ZmnSCPxj