path: root/de/495699298e7f61b7c9c722f4aab6cbec7bdd7c

Return-Path: <tamas.blummer@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 7ACDB13BA
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  2 Jul 2019 06:38:54 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wr1-f54.google.com (mail-wr1-f54.google.com
	[209.85.221.54])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9012870D
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue,  2 Jul 2019 06:38:53 +0000 (UTC)
Received: by mail-wr1-f54.google.com with SMTP id n4so16306057wrw.13
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 01 Jul 2019 23:38:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=from:message-id:mime-version:subject:date:in-reply-to:cc:to
	:references; bh=kNm9ls9vMNThL6Bh+8tZEyzxZRv/gwQPGyjKWe9goog=;
	b=LR+7hEpjLchf+ZTOu+ccrLnMCaNDs+63B5qLe0qRyBM2HboHBsboPz4NVS1rtA+YLs
	Z5f4sa4lutbU537rWvHPmyrtXpK0QRcQwqon+F9NG2/pVUhqm4QV3toTAKT/R9grWKEj
	nSqsdZ3i+dP9hQSgz9swzuZYaH3sfl0ugRdkeX7rvkv4wKtBJz8vx8pnghfEYtznQKpt
	rW7Mrt9DvPY5kWjzA7GzBts4d8l0OGI3d12PMt8QG/D9mRjH+1ao+UFfYa3p6Dep9zJt
	tQve8orkPtD2GKVwM2O3a+V5rBY4FUV74FeCztId59ew7eoqHJbj5C2TkbVbPxizDWh5
	fdZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:from:message-id:mime-version:subject:date
	:in-reply-to:cc:to:references;
	bh=kNm9ls9vMNThL6Bh+8tZEyzxZRv/gwQPGyjKWe9goog=;
	b=IBHKqX19/IlxtSvwfRHuZy8Vbum+SEPIW/ZW04aQmDYjh0eUXdLQn6uf+GtsCxbrQA
	cUQFWXBH8qNmVw9o9KJPSrzkNLhhb5nicaVmTbC4LUUG5aq+Nw4bvZms45xhR9bLafuS
	bOzvhwe73TwcNKDatdkilKQngrZjk3Y5doEZecqOekz5f4qoYEeqqCiDkAKWBc+5bTlc
	voBv71QIK1BV4L4fHbuFnZ9aShLMKLu5acBGM6RJVdBxtyxkn2/7s6Z3JLReENAYUyvt
	HCHIPfwGfIyfk2uS2ZGEbuteAvucbREM4rgbjzHbrJ3rtNdHg+vSRBEmpvz0UbR2leh6
	IQLQ==
X-Gm-Message-State: APjAAAUgFf6ysZ5sv1rE9+X8GgLeGMDtd75x0cJRpbrZ6paIjV4vacgJ
	hvnhk8miuMq68J7+fceOyls=
X-Google-Smtp-Source: APXvYqzAXfLGNGn6cJ1npmeanHTjua9epznXKhy2Hyo1JKuTa/ppQm41FrguAgLVAz591hlJ1QMQlQ==
X-Received: by 2002:adf:b64b:: with SMTP id i11mr22032428wre.205.1562049532100;
	Mon, 01 Jul 2019 23:38:52 -0700 (PDT)
Received: from p200300dd6712642569ab198ddd49c683.dip0.t-ipconnect.de
	(p200300DD6712642569AB198DDD49C683.dip0.t-ipconnect.de.
	[2003:dd:6712:6425:69ab:198d:dd49:c683])
	by smtp.gmail.com with ESMTPSA id c6sm1636405wma.25.2019.07.01.23.38.50
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Mon, 01 Jul 2019 23:38:50 -0700 (PDT)
From: Tamas Blummer <tamas.blummer@gmail.com>
Message-Id: <0190F226-7133-4B6D-8750-25CAB5C73D17@gmail.com>
Content-Type: multipart/signed;
	boundary="Apple-Mail=_8F195431-A21F-4909-B848-77B2A195A26B";
	protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Tue, 2 Jul 2019 08:38:55 +0200
In-Reply-To: <0Bwi2ejRw4BgoABZ0X0kBdwLAkIKEv1svoyi0zqGQPeqV1g8xR43tBMgYoS52Vcxkgj7DndmNLIje40au51trIGTvrpcet8GivTgqysVC8w=@protonmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com>
	<1A808C88-63FD-4F45-8C95-2B8B4D99EDF5@gmail.com>
	<83705370-79FC-4006-BA04-4782AD5BE70B@voskuil.org>
	<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>
	<0Bwi2ejRw4BgoABZ0X0kBdwLAkIKEv1svoyi0zqGQPeqV1g8xR43tBMgYoS52Vcxkgj7DndmNLIje40au51trIGTvrpcet8GivTgqysVC8w=@protonmail.com>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM,
	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: Tue, 02 Jul 2019 08:59:10 +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: Tue, 02 Jul 2019 06:38:54 -0000


--Apple-Mail=_8F195431-A21F-4909-B848-77B2A195A26B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Good morning Eric and ZmnSCPxj,

> On Jul 2, 2019, at 05:45, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>=20
> Good morning Eric, and Tamas,
>=20
>> In the case of tracking an asset that becomes worthless at a specific =
time, one could value a record of ownership, and the ability to trade =
ownership of the asset during the period. Consider colored coin type =
tracking of a theater ticket for a specific show, where the ticket is =
worthless by the end of the show.
>=20
> As it happens, I was playing around with another idea I am developing.
> And it involves something very much similar, but distinct.
>=20
> In particular, currencies are worthless unless exchanged for things of =
value to existent beings.
> And the discovery of things of value is enabled by advertising.
> The idea I am developing, is that of a "Bitcoin Classified Ads =
Network", wherein ordinary P2PKH UTXOs (or P2WPKH equivalents) embed a =
commitment to an advertisement.
> A secondary network of nodes (separate from the Bitcoin network) =
transmits the actual advertisements, as well as the UTXOs being used to =
commit to them.
> This secondary network would then reject/purge advertisements once the =
UTXO is spent on the Bitcoin blockchain.
> This makes advertising costly (for the opportunity cost of locking =
some money in a UTXO until one has acquired actual paying custom) while =
reducing impact on Bitcoin blockchain space (commitment to the =
advertisment is in the same space as the ownership of the coin).
> Changing the advertisement one makes is possible, at the cost of =
paying for a transaction in the Bitcoin blockchain to spend the old UTXO =
and publish a new UTXO now committing to the new advertisement.
>=20
> Of note is that I also derived that it would be beneficial, for some =
HODLers to offer their funds for the purpose of making these =
advertisements.

All above aligns with my intuition that: on one side giving up temporary =
control of UTXOs represent opportunity cost and on the receiver side =
having temporary control can unlock utility they would pay for.
If the techical setup is trustless and return of control to those who =
gave it up temporarilty is certain, then this in combination means that =
HODLer are able to earn riskless interest by giving up control of their =
UTXOs temporarily.


> Some service or product provider would agree with an advertiser to =
lock some coins of the advertiser for a limited amount of time, in =
exchange for payment upfront, with the coin address committing to the =
indicate advertisement of the service or product provider.
> This can be done by paying to a 2p-ECDSA (or with Schnorr, MuSig) =
public key, with the service/product provider embedding a commitment to =
its advertisement to its own key, and a pre-signed `nLockTime` =
transaction that lets the advertiser recover the money.
>=20
> This is in fact a similar use to the "theater ticket" case you =
mentioned, yet distinct.
> In the case of the Bitcoin Classified Ads Network, it is the =
intermediate addresses used before reclamation by the advertiser that is =
valuable, as they also serve as commitments to advertisements, attesting =
to the (probable) validity of the advertisement and making spam have a =
cost.
> Given that nodes of the Bitcoin Classified Ads Network will have =
memory limits, advertisements whose "lockup-rate" (i.e. the amount of =
value of the backing UTXO, divided by the size of the advertisement) are =
low could be evicted from memory before advertisements with high =
lockup-rate, and thus be less likely to propagate across the network.
> Thus service/product providers would want to increase their "marketing =
budget" to be less likely to be evicted from nodes of the Bitcoin =
Classified Ads Network, which is beneficial as it increases the minimum =
practical lockup-rate needed to spam the network, thus making spam =
costly.
>=20
> My current plan is that the provider can contact the advertiser in =
order to effect changes to their advertisement.
> Then the provider and the advertiser sign a new timelocked reclamation =
transaction, then sign a transaction moving from the old advertisement =
to the new advertisement (presumably there is some protocol for ensuring =
the advertiser gets paid for this, such as an HTLC that can be triggered =
by an onchain payment or by an LN payment; I have the details in my =
processing space but require some time to serialize to human-readabe =
format).
>=20
> Arguably, this example seems to show that generalized covenants are =
not needed in fact, if transfers of coin require paying to the =
issuer/lender of the coin.
> Generalized covenants allows the provider (or ticket-holder in your =
example) to effect transfers from one advertisement to another (or one =
ticket-holder to another in your example) without cooperation with the =
advertiser (or ticket-issuer in your example).
> This would be otherwise needed if we lock using a 2-of-2 address that =
has a timelocked transaction to reclaim the funds.

Yes, your example does not need the covenant as the one who gave up =
temporary control is still involved in any motion of the UTXO, therefore =
able to enforce own interest that reclaiming the UTXOs remains possible.

A covenant is needed only if it is against the interest of all parties =
involved in transfers of the UTXO, in which case consensus must enforce =
that it is carried forward.
The added strength of the covenant is that the one who gives up =
temporary control does not have to be involved in using the UTXO until =
it is given back.

Note that the advertizing service provider would need temporary access =
to UTXOs of signficant value, so opportunity cost and thereby cost of =
advertizing becomes significant.
Covenants would allow the separation of the advertizing service from =
HODLer funding it with significant UTXOs.
HODLer could give temporary control to the service and the service could =
broker those to others, but the original HODLer was sure to receive the =
UTXOs back and the HODLer would not be bothered with the operation of =
the service.

The covenant I proposed would add an alternate taproot validation path =
stacked onto previously existing ones.
This means that one could give others temporary access for a shorter =
time period than one=E2=80=99s own temporary access.
One could however not override the delayed access secured for the =
HODLer.

Does this remind you of something? Yes, the service provider would act =
like a bank, matching depositor, the HODLer, with those who need =
temporary control of UTXO for advertizing purposes.
This shows why temporary control with covenant can be understood as loan =
in a full reserve banking, which started my exploration of this topic.

Current technical means do not allow trustless and hands-off =
coordination of provider of UTXOs (that is capital) with provider of =
arbitary services that monetize the use of Bitcoin=E2=80=99s unforgable =
registry.
In other words we need covenants to enable Bitcoin applications to =
trustlessly and flexibly deal with foreign capital.

One other thing the consensus would have to ensure is that inputs with =
covenants are merged only into outputs with same covenant.
Which makes UTXOs with a particular covenants obey rules earlier known =
for colored coins and transactions moving it form a distinct embedded =
chain.
Adding same covenant establishes fungible coinbases of same embedded =
chain and dropping the covenant makes them again fungible with common =
UTXOs.

I could not be more excited of what boost this could give to the Bitcoin =
economy, unlocking the use of its unforgeable registry to track any =
asset with the same security guarantees it offers for its own cash =
token.

Best to you,

Tamas Blummer


>=20
> Regards,
> ZmnSCPxj


--Apple-Mail=_8F195431-A21F-4909-B848-77B2A195A26B
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-----

iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAl0a/AAACgkQ9nKRxRdx
ORx1lggAx5OIjv9yGMl3CLVVcwOQLSpu8ikEHyk3OGyGCfQek9nw3qTsHPplGS0j
5ifs2ERyffycw3NRh+1i0ATGdQt9wehj5dVMIAGmk6BRRlW2b1jMERLoLYv1yyGQ
/0USdNHE0JpKQ1lZCCWRQYO+yMXd6DabciKZod6r8/FEUtlxpKK+yFOAjJ1h9oJ1
tmO8k+WUuTL6HnY8CYFNIWjyrT5cnKTIlxO0kPI1IGCA2+pPJaFCxZIgrWudxl8a
KR/9hFXLO3c9Lsb765PNigAHJqylrbPggFhGIZNXqHR2am2ljEPiTlctHCuii+Sv
IM9myGvAPGIxxB5B2aMlohMYWGMEJA==
=qB3c
-----END PGP SIGNATURE-----

--Apple-Mail=_8F195431-A21F-4909-B848-77B2A195A26B--