Content-Type: text/plain;
	charset=utf-8
Mime-Version: 1.0 (1.0)
From: Eric Voskuil <eric@voskuil.org>
In-Reply-To: <BFC25438-CA9F-4F95-A79C-089EE3C52917@gmail.com>
Date: Thu, 4 Jul 2019 13:31:03 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <DDDE70C5-8C81-4513-8554-4363C995B302@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>
	<F17F2E86-BFA4-456E-85F9-0D6583692AEC@voskuil.org>
	<BFC25438-CA9F-4F95-A79C-089EE3C52917@gmail.com>
To: Tamas Blummer <tamas.blummer@gmail.com>
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
Precedence: list


> On Jul 4, 2019, at 12:10, Tamas Blummer <tamas.blummer@gmail.com> wrote:
>=20
> Hi Eric,
>=20
> there are some other ways to impose cost on use without direct billing, e.=
g.:
>=20
> - Burn Bitcoins to use the service, as you mentioned. This could work and w=
ould benefit remaining Bitcoin owner, but is unsustainable.

Burning is not an economic concern and cannot be prevented. As there are few=
er coins, all things being equal, the cost of each increases, and thus fewer=
 must be burned to achieve the same cost. So assuming sufficient divisibilit=
y (an existing Bitcoin assumption) it is sustainable. But as I demonstrated,=
 it=E2=80=99s not necessary.

> - Pay high fees in self dealing transactions. This could work and would be=
nefit miner.

This is essentially what I suggested, though presumably you mean Bitcoin fee=
s not secondary network.

> - Time lock own Bitcoins. This is forgoing control of an UTXO for a time p=
eriod, which implies opportunity cost. This could be done with CLTV (OP_HODL=
). It damages the current owner but benefits no one. The problem is one migh=
t not have substantial UTXO to  imply high enough opportunity cost.

Another reason why simply spending or burning them is preferential.

> - Pay someone else to time lock. This is paying someone to lock an UTXO fo=
r a time span. Payment and time lock could be combined in the same transacti=
on.

This implies additional complexity with no benefit to anyone required by the=
 scenario, which was my implication.

> - Transferable borrowed Bitcoin.  This needs the covenant. This benefits t=
hose who consciously give up control for a time span. Its advantage is that s=
ince transferable it can be sold if no longer needed, thereby shortening the=
 term of the original arrangement. It coul be re-rented for a shorter time p=
eriod.

The terms lend/borrow are misleading here, as I have previously shown. The c=
oin is neither spendable nor consumable. This is why I have used the terms o=
wner/renter. Yes, the renter can sell the remaining rental expense to anothe=
r.

Yes, the potential incremental value over the other scenarios is transferabi=
lity of the output, but this accrues to both to the advertiser/renter and th=
e owner (trade always benefits both parties trading). This transfer incurs a=
 fee if on chain, and in the tracking scenario may easily overwhelm the effe=
ctive benefit (fraction of the rental, no higher than dust, not yet expired)=
, making it economically non-transferrable.

In the advertising scenario this transfer can be achieved independent of Bit=
coin, by simply changing the advertisement (e.g. publish a provably-supersed=
ing ad for the same output), avoiding the material on-chain fee. Recall that=
 the value of the coin cannot be captured by the advertiser through transfer=
, just the tracking cost.

e

> Tamas Blummer
>=20
>=20
>> On Jul 4, 2019, at 18:43, Eric Voskuil <eric@voskuil.org> wrote:
>>=20
>> Hi ZmnSCPxj,
>>=20
>> Generalizing a bit this appears to be the same with one exception. The am=
ount of encumbered coin is relevant to an external observer. Of course the e=
ffective dust limit is the maximum necessary encumbrance otherwise.
>>=20
>> In the case of simple tracking, the market value of the coin is not relev=
ant, all that is required is a valid output. Hence the devolution to 1 sat t=
racking. In your scenario the objective is to establish a meaningful cost fo=
r the output.
>>=20
>> A community of people using this as a sort of hashcash spam protection ca=
n raise the amount of encumbered coin (i.e. advertising threshold price) req=
uired in that context. The cost of this encumberance includes not only at le=
ast one tx fee but market cost of the coin rental.
>>=20
>> At a 1 year advertisement term, 10% APR capital cost, and threshold of 1 e=
ncumbered coin, the same is achieved by burning .1 coin. In other words the r=
enter (advertiser) has actually paid to the coin owner .1 coin to rent 1 coi=
n for one year.
>>=20
>> 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 val=
ue). Why would the advertiser not simply be required to burn .1 coin for the=
 same privilege, just as miners burn energy? Why would it not make more sens=
e to spend that coin in support of the secondary network (e.g. paying for co=
nfirmation security), just as with the burning of energy in Bitcoin mining?
>>=20
>> e
>>=20
>>> 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 f=
or UTXOs that are only temporarily accessible to their current owner.
>>>>=20
>>>> Actually you have a single potentially-valid use case, the one I have p=
resented. The others I have shown to be invalid (apart from scamming) and no=
 additional information to demonstrate errors in my conclusions have been of=
fered.
>>>=20
>>> I presented another use case, that of the "Bitcoin Classified Ads Networ=
k".
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083=
.html
>>>=20
>>> Advertisements are "backed" by an unspent TXO.
>>> In order to limit their local resource consumption, nodes of this networ=
k will preferentially keep advertisements that are backed by higher UTXO val=
ues divided by advertisement size, and drop those with too low UTXO value di=
vided by advertisement size.
>>>=20
>>> Thus, spammers will either need to rent larger UTXO values for their spa=
m, paying for the higher rent involved, or fall back to pre-Bitcoin spamming=
 methods.
>>> Thus I think I have presented a use-case that is viable for this and doe=
s not simply devolve to "just burn a 1-satoshi output".
>>>=20
>>> I still do not quite support generalized covenants as the use-case is al=
ready possible on current Bitcoin (and given that with just a little more tr=
ansaction introspection this enables Turing-completeness), but the basic con=
cept of "renting a UTXO of substantial value" appears sound to me.
>>>=20
>>>=20
>>> Regards,
>>> ZmnSCPxj
>=20