Return-Path: <eric@voskuil.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1A567AE0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Thu,  4 Jul 2019 16:54:22 +0000 (UTC)
Received: by mail-io1-f53.google.com with SMTP id s7so13960544iob.11
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <eric@voskuil.org>
Mime-Version: 1.0 (1.0)
Date: Thu, 4 Jul 2019 11:43:45 -0500
Message-Id: <F17F2E86-BFA4-456E-85F9-0D6583692AEC@voskuil.org>
References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com>
	<BF027CD0-FE29-4DD1-AB96-DE92B597AD18@gmail.com>
	<3F46CDD5-DA80-49C8-A51F-8066680EF347@voskuil.org>
	<A4A6099F-F115-4CBF-B7D5-F16581476126@gmail.com>
	<063D7C06-F5D8-425B-80CE-CAE03A1AAD0C@voskuil.org>
	<0AA10217-E1CC-46D1-9B43-038CEEF942CD@gmail.com>
	<E72C4A8E-F850-400B-B19B-7D06B8A169EC@voskuil.org>
	<A64C3DCB-10CE-45EA-9A1B-7E3D13DF90EA@gmail.com>
	<6B9A04E2-8EEE-40A0-8B39-64AA0F478CAB@voskuil.org>
	<SEQmsx6ck79biVthBbBk1b9r9-R45sBwqWrv3FewQIBl4J18sOlwAPRt8sbTIbrBB8DX538GfwQkU40lyODmEkGSwah_VmbXT8iOr2Jcjlw=@protonmail.com>
In-Reply-To: <SEQmsx6ck79biVthBbBk1b9r9-R45sBwqWrv3FewQIBl4J18sOlwAPRt8sbTIbrBB8DX538GfwQkU40lyODmEkGSwah_VmbXT8iOr2Jcjlw=@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <ZmnSCPxj@protonmail.com> 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