public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Tamas Blummer <tamas.blummer@gmail.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.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
Date: Tue, 2 Jul 2019 14:51:31 +0200	[thread overview]
Message-ID: <E1E29AAE-1E54-44B3-A256-4707F2733DD4@gmail.com> (raw)
In-Reply-To: <za891lsGkbAxQjS4ppao6-qhV7yjCLp0uKglEuyBRFwk2p09jSvWJP1WD9MMt_DE82KPOx90UhiwS-zAp_zbgrLyTmBBQvcux61ENTDhDBA=@protonmail.com>


[-- Attachment #1.1: Type: text/plain, Size: 2345 bytes --]


Hello ZmnSCPxj,

> On Jul 2, 2019, at 12:33, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> 
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Tuesday, July 2, 2019 5:30 PM, Tamas Blummer <tamas.blummer@gmail.com <mailto:tamas.blummer@gmail.com>> wrote:
> 
>> The advertiser would thereby put the funds of the HODLer on risk of his misbehavior, which means the HODLer would have to trust the advertizing service.
> 
> No it would not :)


You are right. I noticed after sending my reply and then I sent two other. I apologize for being noisy.

Let me consolidate my thinking, here.

If there is a use for UTXOs with temporary control, then those who want that use will pay for it.

A user of a service that requires temporary control UTXOs would need to cover:

1. fees required by the service
2. the opportunity cost of temporary ownership paid to the original holder who gave up control.

If the service is operated by an entity billing user then it can use UTXOs of minimal value for its operation and practically ignore opportunity interest.
This is the case with theater tickets just and other simple colored coin like use of Bitcoin. Also in case of the unchained advertizement, if the service bills its user
for its internal re-allocation of an UTXO, then why would it need to use significant value temorary control UTXOs? Actually why not use plain UTXOs, to start with?

If however the service is a common good, a network without owner and therefore not billing on behalf of someone, but wants to protect itself from spam, then it is could require temporary access to significant value UTXOs and thereby induce opportunity cost to user. Alternatively it could require burning ordinary UTXOs. Burning indirectly benefits all HODLer, temporary control benefits those who consciously gave up control. I dislike burning as it is unsustainable.

If the implementation of temporary use is enforced by consenus such that it is transitive, then temporary use could be re-rented or sold to recover opportunity cost for no longer needed temporary access, making it useable for an other service.

Temporary access UTXOs with covenants allows us to build spam limited public services that are not owned by an operator and financially benefit HODLer offering them riskless interest.

Tamas Blummer

[-- Attachment #1.2: Type: text/html, Size: 6848 bytes --]

[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2019-07-02 12:51 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
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 [this message]
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=E1E29AAE-1E54-44B3-A256-4707F2733DD4@gmail.com \
    --to=tamas.blummer@gmail.com \
    --cc=ZmnSCPxj@protonmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.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