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 --]
next prev parent 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 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$(echo .)com \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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