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 30B7B1624
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  5 Jul 2019 23:44:49 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com
	[209.85.210.196])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 613DF70D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri,  5 Jul 2019 23:44:48 +0000 (UTC)
Received: by mail-pf1-f196.google.com with SMTP id b13so292406pfo.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 05 Jul 2019 16:44:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=voskuil-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=MORgeyH2rFbANrL4IkDnriesnvdkRdC1BBLXEzOqPGE=;
	b=lCUWoJter6QhaEUEm1O1SyxKKPduq9Dju2ofrjBGQEFS+/9jnbayaPRZy6LK1emKMu
	InB3njQvjpGE6fqQPafNsmtv5O/4QbkJTVmDRwjueZXhENp6xfGgIyQM/Meym/nYVmpV
	5XxdrRGUuz02OlT7BQiwVN7fXrVqUHwm378jBLgHIRkQkcKULR4m5oaRiLiJ9T7bmf6q
	XZ47qGaWD6d+vh75kQ+ahKYovYcY+hWKuNv74NU5THnnU9X4wQ6FbmLUNCDoqvR6/aVG
	TKjPlDbBABcWhkIrv6HrI+cD8RS1G+jyJB9lsDYw3UEasorty+Z9ts+zRtc2guhdBkz3
	jhPw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=MORgeyH2rFbANrL4IkDnriesnvdkRdC1BBLXEzOqPGE=;
	b=E7IO3caZKDCuYSpTt2DT2Nt4e0ogdUeErBdqGflLXNJ7HZzegwah7oiho/kEAUtIq9
	oTcTB4aaVrui1FWvBxmOJwtv3Tr6mn7Poj5gPRxxoUBN6H09tTJ3PmDyrBt159IvQgYv
	e5n40JX5TCnl5jFYXXX8FMpXfUnD20nSu5gB+BDFXxATg6JiQ9H+7xZVs1pxfasStBdw
	w8LDXMTj4Mc2wNmskyGd2/4zQAQph6X+hxHcMzQzzBSto8RCYsGggXQAVK4Z3HDqyicJ
	yDQ9dg2QuVcul1NgYSG+jDw4QWlmAT1Jd9O0y3Z+IiW9Xx1HHCcBiWG8v9RL8HFYN68H
	n4/g==
X-Gm-Message-State: APjAAAWjVogF9oL0In+42M8SMpenwIxqq5mjaN0V4/sJu1rH5/LfGwdt
	1TXGdzkqeVlzjH2Q90sEQq5/dw==
X-Google-Smtp-Source: APXvYqzT4N99TrRpq3aVJLiH37QAqMKJwy/WRMmFFF5LGSrkj/6zXVZtcOa+DH74MN0/d+UD4+ignw==
X-Received: by 2002:a63:e250:: with SMTP id y16mr7861413pgj.392.1562370287857; 
	Fri, 05 Jul 2019 16:44:47 -0700 (PDT)
Received: from ?IPv6:2601:600:a080:16bb:c899:e1f8:fb96:3f43?
	([2601:600:a080:16bb:c899:e1f8:fb96:3f43])
	by smtp.gmail.com with ESMTPSA id
	65sm10637884pff.148.2019.07.05.16.44.46
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Fri, 05 Jul 2019 16:44:47 -0700 (PDT)
Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
X-Mailer: iPhone Mail (16F203)
In-Reply-To: <4mT6iC4Va7Afg15a5NLbddAnF2a_vAcQSXYr_jg_5IyEK2ezblJff7EJZakoqvp4BJlLitt9Zlq1_l5JadR0nVss7VDPW-pv8jXGh7lkFC4=@protonmail.com>
Date: Fri, 5 Jul 2019 16:44:45 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <A1ADD0BB-F62F-47AF-B043-53BDF3A88CC3@voskuil.org>
References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com>
	<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>
	<F17F2E86-BFA4-456E-85F9-0D6583692AEC@voskuil.org>
	<kSCa9KUmpJox2_aglqhel-WdGlXf14mfKNZ95T4xqsrkQJ2Zh5zFA-Llq-j9cXX87iEPP5_aCkO9oR5kfQGKMBK9ds3Jct1V1FAawwa4CyE=@protonmail.com>
	<B853EDF2-8A8A-44B0-A66E-F86175E61EDA@voskuil.org>
	<4mT6iC4Va7Afg15a5NLbddAnF2a_vAcQSXYr_jg_5IyEK2ezblJff7EJZakoqvp4BJlLitt9Zlq1_l5JadR0nVss7VDPW-pv8jXGh7lkFC4=@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
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: Sat, 06 Jul 2019 01:34:57 +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: Fri, 05 Jul 2019 23:44:49 -0000



> On Jul 5, 2019, at 16:16, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>=20
> Good morning Eric,
>=20
>=20
> Sent with ProtonMail Secure Email.
>=20
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M=
essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
> On Saturday, July 6, 2019 3:27 AM, Eric Voskuil <eric@voskuil.org> wrote:
>=20
>>> On Jul 4, 2019, at 21:05, ZmnSCPxj ZmnSCPxj@protonmail.com wrote:
>>> Good morning Eric,
>>>=20
>>>> As with Bitcoin mining, it is the consumed cost that matters in this sc=
enario, (i.e., not the hash rate, or in this case the encumbered coin face v=
alue). 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 se=
nse to spend that coin in support of the secondary network (e.g. paying for c=
onfirmation security), just as with the burning of energy in Bitcoin mining?=

>>=20
>> Good morning ZmnSCPxj,
>>=20
>>> Using the unspentness-time of a UTXO allows for someone advertising a se=
rvice 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 goo=
ds, once the stock has been sold, the merchant (assuming the merchant used o=
wn funds) can simply recover the locked funds, with the potential to reinves=
t them elsewhere.
>>> This allows some time-based hedging for the merchant (they may be willin=
g to wait indefinitely for the stock to be sold, but once the stock is sold,=
 they can immediately reap the rewards of not having their funds locked anym=
ore).
>>=20
>> This is a materially different concept than proposed by Tamas.
>>=20
>> =E2=80=9C...he gives up his control of the coins until maturity, he can n=
ot use them elsewhere until then.=E2=80=9D
>=20
> Possibly.
> In a way, this is giving up control of the coin, until he no longer needs t=
he advertisement, i.e. dynamically select the maturity age needed.
>=20
>>> Similarly, an entity renting out a UTXO for an advertisement might allow=
 for early reclamation of the UTXO in exchange for partial refund of fee; as=
 the value in the UTXO is now freed to be spent elsewhere, the lessor can le=
ase it to another advertiser.
>>=20
>> You appear to be proposing a design whereby either the owner or the rente=
r (not entirely clear to me which) can spend the =E2=80=9Clocked up=E2=80=9D=
 coin at any time (no maturity constraint), by dropping the covenant.
>>=20
>> If the renter can do this he can simply steal the coin from the owner.
>>=20
>> If the owner can do this there is no value to the renter (or as a proof o=
f cost), as the owner retains full control of the coin.
>>=20
>=20
> Obviously this will require a 2-of-2 multisig, with an timelocked transact=
ion that lets the owner recover at a futuredate, so that it is the agreement=
 of *both* that is needed to perform any actions before the timelock.
> I already described this in the link I provided.
>=20
>=20
>> If you mean that the age of the encumbrance is the proof of cost, this re=
quires no covenant. I don=E2=80=99t believe this is what you intended, just c=
overing all bases.
>=20
> Not age of encumbrance, quite.
> Instead, it is the simple fact that the UTXO is a UTXO (and not yet spent)=
, that validates the advertisement.

Not any UTXO then, one that with sufficient time-locked coin.

> No, it does not *require* a covenant.
> However, covenants do make it easier to use, in the sense that the renter c=
an repurpose the UTXO (e.g. change details of advertisement) without having t=
o contact the owner.

So how does one get the owner to sign off on the multisig release? Presumabl=
y the renter cares because he wants to recover the remaining value of rental=
. So he not only needs to contact the owner, he also needs to negotiate with=
 the owner for a pro-rated refund. In other words, he must sell the remainin=
g portion of the rental return - essentially how I described it previously. H=
e might as well just sell the marketable ad space that he controls through t=
he remainder of the term (the same value).

Certainly the owner could given him a partially-signed transaction, returnin=
g the coin, allowing the renter to exit at any time, but the renter has no r=
eason to sign it without a refund, which must be pro-rated in some way, impl=
ying later contact/negotiation with the owner.

But it=E2=80=99s worth noting that early recovery of the UTXO entirely elimi=
nates the value of the time lock cost to the ad market. The most obvious exa=
mple is one encumbering the coin to himself, then releasing it with his own t=
wo signatures whenever he wants. In other words, there is no encumbrance at a=
ll, just a bunch of pointless obscurantion.

>>> Burnt funds cannot be "un-burnt" to easily signal the end of a term for a=
n advertisement.
>>=20
>> And as I have shown above, nor can a =E2=80=9Clocked-up=E2=80=9D coin be u=
nlocked to do the same.
>=20
> You have shown no such thing, merely shown that you have not understood th=
e proposal.

I think I understand the implications of it clearly. Feel free to point out w=
hat I=E2=80=99m missing. But I don=E2=80=99t spend any time in implementatio=
n details until I can justify those implications.

A multisig doesn=E2=80=99t fix the central economic issue, which it is not c=
lear that you understand. If so it hasn=E2=80=99t been demonstrated. A cost c=
reated by making coin unusable for a term is not an actual cost if that lock=
 can be released at any time before maturity of that term. Furthermore, cost=
 is most easily demonstrated by simply spending.=20

By analogy, proof of work is simply proof of a spend (incurred cost). Imagin=
e if one demonstrated that cost by =E2=80=9Clocking up=E2=80=9D coin for a y=
ear, and then after the block was accepted, he unlocked that coin after just=
 one day.

Best,
Eric

> Regards,
> ZmnSCPxj