From: Tamas Blummer <tamas.blummer@gmail.com>
Message-Id: <BFC25438-CA9F-4F95-A79C-089EE3C52917@gmail.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_1C744C09-FE87-4ECA-8B9F-33DE9453B2B4";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Thu, 4 Jul 2019 19:10:31 +0200
In-Reply-To: <F17F2E86-BFA4-456E-85F9-0D6583692AEC@voskuil.org>
To: Eric Voskuil <eric@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>
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


--Apple-Mail=_1C744C09-FE87-4ECA-8B9F-33DE9453B2B4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi Eric,

there are some other ways to impose cost on use without direct billing, =
e.g.:

- Burn Bitcoins to use the service, as you mentioned. This could work =
and would benefit remaining Bitcoin owner, but is unsustainable.

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

- Time lock own Bitcoins. This is forgoing control of an UTXO for a time =
period, 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 might not have substantial UTXO to  imply high enough opportunity =
cost.

- Pay someone else to time lock. This is paying someone to lock an UTXO =
for a time span. Payment and time lock could be combined in the same =
transaction.

- Transferable borrowed Bitcoin.  This needs the covenant. This benefits =
those who consciously give up control for a time span. Its advantage is =
that since 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 period.

Tamas Blummer


> 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 =
amount of encumbered coin is relevant to an external observer. Of course =
the effective dust limit is the maximum necessary encumbrance otherwise.
>=20
> 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 tracking. In your scenario the objective is to establish a =
meaningful cost for the output.
>=20
> A community of people using this as a sort of hashcash spam protection =
can raise the amount of encumbered coin (i.e. advertising threshold =
price) required in that context. The cost of this encumberance includes =
not only at least 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 encumbered coin, the same is achieved by burning .1 coin. In other =
words the renter (advertiser) has actually paid to the coin owner .1 =
coin to rent 1 coin for one year.
>=20
> As with Bitcoin mining, it is the consumed cost that matters in this =
scenario, (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 same privilege, just as miners burn energy? Why would it =
not make more sense to spend that coin in support of the secondary =
network (e.g. paying for confirmation 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 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 presented. The others I have shown to be invalid (apart from =
scamming) and no additional information to demonstrate errors in my =
conclusions have been offered.
>>=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 will preferentially keep advertisements that are backed by =
higher UTXO values divided by advertisement size, and drop those with =
too low UTXO value divided 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 methods.
>> Thus I think I have presented a use-case that is viable for this and =
does not simply devolve to "just burn a 1-satoshi output".
>>=20
>> I still do not quite support generalized covenants as the use-case is =
already possible on current Bitcoin (and given that with just a little =
more transaction introspection this enables Turing-completeness), but =
the basic concept of "renting a UTXO of substantial value" appears sound =
to me.
>>=20
>>=20
>> Regards,
>> ZmnSCPxj


--Apple-Mail=_1C744C09-FE87-4ECA-8B9F-33DE9453B2B4
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAl0eMwcACgkQ9nKRxRdx
ORyWQQf+MAc8plWrBW3s9aIko1UBre8YbfS3KDyTPNxWXRNLpOQoqopVv7PzSJwJ
tIpocYQW4xVBHWfAwP+FKAfaNwn++5PsOgl0Qeh4IdfQKSsjSFZpSiCdxhj9OPHy
/OcFieMb0uPENqawljAGJULZ1KeJsUWz8waSB1IVZ4grZg/6W/Lm2+SS2hyLXK9h
0mU8XwpFN5WybhpTbC8t8d7DoKWeaJYK97Rn84SyWKUne15caRgr6CKNmgq28tmY
uKMxlxeeoTF040t9EO/gRY9GBMvMlR6oppUluu//aLeZJi9+oJ3GG/IvPHaqKW3G
hDx3ivmTlkdZmKxTFRsirwG9JBI7VQ==
=Sh+N
-----END PGP SIGNATURE-----

--Apple-Mail=_1C744C09-FE87-4ECA-8B9F-33DE9453B2B4--