public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: Eric Voskuil <eric@voskuil.org>,
	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
Date: Tue, 02 Jul 2019 03:45:31 +0000	[thread overview]
Message-ID: <0Bwi2ejRw4BgoABZ0X0kBdwLAkIKEv1svoyi0zqGQPeqV1g8xR43tBMgYoS52Vcxkgj7DndmNLIje40au51trIGTvrpcet8GivTgqysVC8w=@protonmail.com> (raw)
In-Reply-To: <E72C4A8E-F850-400B-B19B-7D06B8A169EC@voskuil.org>

Good morning Eric, and Tamas,

> 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.

As it happens, I was playing around with another idea I am developing.
And it involves something very much similar, but distinct.

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.

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.
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.

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.

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).

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.

Regards,
ZmnSCPxj


  reply	other threads:[~2019-07-02  3:45 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-06-28  8:27 [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve Tamas Blummer
2019-06-28 17:25 ` Eric Voskuil
2019-06-28 19:21   ` Tamas Blummer
2019-06-29 21:21     ` Eric Voskuil
2019-06-30 10:56       ` Tamas Blummer
2019-06-30 17:41         ` Eric Voskuil
2019-06-30 18:35           ` Tamas Blummer
2019-06-30 18:54             ` Eric Voskuil
2019-06-30 19:55               ` Tamas Blummer
2019-06-30 20:13                 ` Eric Voskuil
2019-06-30 20:26                   ` Tamas Blummer
2019-07-01 18:52                     ` Eric Voskuil
2019-07-02  3:45                       ` ZmnSCPxj [this message]
2019-07-02  6:38                         ` Tamas Blummer
2019-07-02  8:12                           ` ZmnSCPxj
2019-07-02  9:30                             ` Tamas Blummer
2019-07-02  9:47                               ` Tamas Blummer
2019-07-02 10:14                               ` Tamas Blummer
2019-07-02 10:33                               ` ZmnSCPxj
2019-07-02 12:51                                 ` Tamas Blummer
2019-07-02  5:08                       ` Tamas Blummer
2019-07-03 22:30                         ` Eric Voskuil
2019-07-04  4:57                           ` ZmnSCPxj
2019-07-04 16:43                             ` Eric Voskuil
2019-07-04 17:10                               ` Tamas Blummer
2019-07-04 18:31                                 ` Eric Voskuil
2019-07-04 19:31                                 ` Eric Voskuil
2019-07-05  4:05                               ` ZmnSCPxj
2019-07-05 19:27                                 ` Eric Voskuil
2019-07-05 23:16                                   ` ZmnSCPxj
2019-07-05 23:44                                     ` Eric Voskuil
2019-07-06  0:17                                       ` ZmnSCPxj
2019-07-06  1:28                                         ` Eric Voskuil
2019-07-06  1:46                                           ` Eric Voskuil
2019-07-06 13:34                                           ` Tamas Blummer
2019-07-06 22:21                                             ` Eric Voskuil
2019-07-07  1:30                                             ` Eric Voskuil
2019-07-07  9:18                                               ` Tamas Blummer
2019-07-09 10:31                                                 ` ZmnSCPxj
2019-07-09 20:32                                                   ` Tamas Blummer
2019-07-06 10:12                                     ` Tamas Blummer
2019-07-06 22:37                                       ` Eric Voskuil
2019-07-05 23:20                                   ` Eric Voskuil
2019-06-29 18:21 ` David A. Harding

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='0Bwi2ejRw4BgoABZ0X0kBdwLAkIKEv1svoyi0zqGQPeqV1g8xR43tBMgYoS52Vcxkgj7DndmNLIje40au51trIGTvrpcet8GivTgqysVC8w=@protonmail.com' \
    --to=zmnscpxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=eric@voskuil.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox