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 1A567AE0 for ; Thu, 4 Jul 2019 16:54:23 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io1-f53.google.com (mail-io1-f53.google.com [209.85.166.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6F09187B for ; Thu, 4 Jul 2019 16:54:22 +0000 (UTC) Received: by mail-io1-f53.google.com with SMTP id s7so13960544iob.11 for ; Thu, 04 Jul 2019 09:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=3Pz1Qsjmxje8Xvqo6/567SD0KYGjARo8LaCMkOiRTxs=; b=u1qibdjEvu+gbLTh0oO47bbv7TNogtcsOkjAncEJ2YXKsDsvTY46XWLlPF31Qxkizx x0oEsruIGIatTMMLQb6AIomvPq8tP3LYHWfsaNh/6nGHUutm7ABMdy6/rXdzGu9GGOaa qoitbpTQ+Ot8jcAeuV4a+LYJc303RLXMgVQpfDbtFhjPxOCR/NsJ/Km6564tU5Lu4dFm vlvYSUUfTMb+ER3etidHIWuikwy8nLo0kUOUscsqs2MK4gNNnqPmTrXMivR9pvOev+Pf Rr0K5bE+e+PLL1eBqwTRCKaGrvI4vq9aFrewiDXA0FN+ffOw3TYbc13yYYcaFNMjyb3r Njkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=3Pz1Qsjmxje8Xvqo6/567SD0KYGjARo8LaCMkOiRTxs=; b=ovmn+oo1vGsMYNU8QjfpbEkxBSFogKsHiFb3FI23IisKj9gsmm7r7Vm/hQXq/Itclf akF6yPiXeouX1l+aY0P/v+o5gOaesMUpAvMcMo6RfztKryUrOX+cUVi9geMXz7aDthCk bkHsRM9D5Oed35pq03nbEyQs/N/FQRONxFOphon9C5JOdqVkDrYmclrEFj78htHBOdFn he1zn+DAxBC0S8a7T/FfWwxz2llNH+XNcSlsyOyvCaCe+gonWevryfEm6LZy56hvvgf2 Y3oJw80y8zZdA+3LyVbhyOPPGgwUnM2c2eJdQpEvcirmFquxMWGDVCFeegsLufYxQ3nS fpNA== X-Gm-Message-State: APjAAAXzmK06INg7M7BZMTEe072KZS3LfN6Ro07+PXyXWTtLpa58F3JV nz2IfhxBfQcChXE9Ht/bqetJ/w== X-Google-Smtp-Source: APXvYqy1ikYfzBNfnNI2nmSpSqQrCUJ1Dyf8l7O+KJZIi2KianGhz1X48RNaikdDQyFMl0D0IUllBA== X-Received: by 2002:a5d:8ad0:: with SMTP id e16mr336467iot.262.1562259261672; Thu, 04 Jul 2019 09:54:21 -0700 (PDT) Received: from ?IPv6:2600:380:c458:7e3a:5803:ef0e:5551:2919? ([2600:380:c458:7e3a:5803:ef0e:5551:2919]) by smtp.gmail.com with ESMTPSA id h19sm4064993iol.65.2019.07.04.09.54.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jul 2019 09:54:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable From: Eric Voskuil Mime-Version: 1.0 (1.0) Date: Thu, 4 Jul 2019 11:43:45 -0500 Message-Id: References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com> <3F46CDD5-DA80-49C8-A51F-8066680EF347@voskuil.org> <063D7C06-F5D8-425B-80CE-CAE03A1AAD0C@voskuil.org> <0AA10217-E1CC-46D1-9B43-038CEEF942CD@gmail.com> <6B9A04E2-8EEE-40A0-8B39-64AA0F478CAB@voskuil.org> In-Reply-To: To: ZmnSCPxj X-Mailer: iPhone Mail (16F203) X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, MIME_QP_LONG_LINE, 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: Fri, 05 Jul 2019 13:53:56 +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: Thu, 04 Jul 2019 16:54:23 -0000 Hi ZmnSCPxj, Generalizing a bit this appears to be the same with one exception. The amoun= t of encumbered coin is relevant to an external observer. Of course the effe= ctive dust limit is the maximum necessary encumbrance otherwise. In the case of simple tracking, the market value of the coin is not relevant= , all that is required is a valid output. Hence the devolution to 1 sat trac= king. In your scenario the objective is to establish a meaningful cost for t= he output. A community of people using this as a sort of hashcash spam protection can r= aise the amount of encumbered coin (i.e. advertising threshold price) requir= ed in that context. The cost of this encumberance includes not only at least= one tx fee but market cost of the coin rental. At a 1 year advertisement term, 10% APR capital cost, and threshold of 1 enc= umbered coin, the same is achieved by burning .1 coin. In other words the re= nter (advertiser) has actually paid to the coin owner .1 coin to rent 1 coin= for one year. As with Bitcoin mining, it is the consumed cost that matters in this scenari= o, (i.e., not the hash rate, or in this case the encumbered coin face value)= . Why would the advertiser not simply be required to burn .1 coin for the sa= me privilege, just as miners burn energy? Why would it not make more sense t= o spend that coin in support of the secondary network (e.g. paying for confi= rmation security), just as with the burning of energy in Bitcoin mining? e > On Jul 3, 2019, at 23:57, ZmnSCPxj wrote: >=20 > Good morning Eric, >=20 >=20 >>> and thanks to you and ZmnSCPxj we now have two additional uses cases for= UTXOs that are only temporarily accessible to their current owner. >>=20 >> Actually you have a single potentially-valid use case, the one I have pre= sented. The others I have shown to be invalid (apart from scamming) and no a= dditional information to demonstrate errors in my conclusions have been offe= red. >=20 > I presented another use case, that of the "Bitcoin Classified Ads Network"= . > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083.h= tml >=20 > Advertisements are "backed" by an unspent TXO. > In order to limit their local resource consumption, nodes of this network w= ill preferentially keep advertisements that are backed by higher UTXO values= divided by advertisement size, and drop those with too low UTXO value divid= ed by advertisement size. >=20 > Thus, spammers will either need to rent larger UTXO values for their spam,= paying for the higher rent involved, or fall back to pre-Bitcoin spamming m= ethods. > Thus I think I have presented a use-case that is viable for this and does n= ot simply devolve to "just burn a 1-satoshi output". >=20 > I still do not quite support generalized covenants as the use-case is alre= ady possible on current Bitcoin (and given that with just a little more tran= saction introspection this enables Turing-completeness), but the basic conce= pt of "renting a UTXO of substantial value" appears sound to me. >=20 >=20 > Regards, > ZmnSCPxj