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: Sat, 6 Jul 2019 12:12:44 +0200 [thread overview]
Message-ID: <16B09501-7AE3-4F8E-A1A4-3E5F6B12D127@gmail.com> (raw)
In-Reply-To: <4mT6iC4Va7Afg15a5NLbddAnF2a_vAcQSXYr_jg_5IyEK2ezblJff7EJZakoqvp4BJlLitt9Zlq1_l5JadR0nVss7VDPW-pv8jXGh7lkFC4=@protonmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4197 bytes --]
> On Jul 6, 2019, at 01:16, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>
> Good morning Eric,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Saturday, July 6, 2019 3:27 AM, Eric Voskuil <eric@voskuil.org <mailto:eric@voskuil.org>> wrote:
>
>>> On Jul 4, 2019, at 21:05, ZmnSCPxj ZmnSCPxj@protonmail.com wrote:
>>> Good morning Eric,
>>>
>>>> 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?
>>
>> Good morning ZmnSCPxj,
>>
>>> Using the unspentness-time of a UTXO allows for someone advertising a service or producer to "close up shop" by simply spending the advertising UTXO.
>>> For instance, if the advertisement is for sale of a limited stock of goods, once the stock has been sold, the merchant (assuming the merchant used own funds) can simply recover the locked funds, with the potential to reinvest them elsewhere.
>>> This allows some time-based hedging for the merchant (they may be willing to wait indefinitely for the stock to be sold, but once the stock is sold, they can immediately reap the rewards of not having their funds locked anymore).
>>
>> This is a materially different concept than proposed by Tamas.
>>
>> “...he gives up his control of the coins until maturity, he can not use them elsewhere until then.”
>
> Possibly.
> In a way, this is giving up control of the coin, until he no longer needs the advertisement, i.e. dynamically select the maturity age needed.
>
My proposal would separate the owner of the funds from the one using the advertizement service. Yes, the owner lock up until maturity. But those using the UTXO for the advertizement service could transfer (sell) the UTXO to someone else as soon as they do not need it, so it is dynamic maturity for them The new owner could use them for an other advertizement or for an entirely different purpose.
Regarding burning: I think burning is unsustainable as usage of services is unlimited while coin suply is limited.
>>
>> And as I have shown above, nor can a “locked-up” coin be unlocked to do the same.
>
> You have shown no such thing, merely shown that you have not understood the proposal.
>
> Regards,
> ZmnSCPxj
I also struggle to communicate to Eric and likely many other reader the generic utility of temporary control of an UTXO. Let me try again:
Bitcoin offers a memory with remarkable properties:
- it can be read by anyone anywhere
- anyone anywhere who knows a key controlling an UTXO, and only them, can initiate an update to the memory
- global replicas guaranteed to apply updates of the memory within a short time period.
This is a utility that is sufficient to implement money.
Such a reliable shared memory could have however more uses than tracking money, It could keep track of, and thereby make scarce, arbitary other things.
We can unlock these uses by separating the money use of memory from other uses.
The covenant achives this separation temporarily. A UTXO with a covenant that guarantees that current owner re-gains control at a later time means,
that the current owner temporarily forgoes the UTXOs use as money and thereby allows its temporary use to keep track of something else.
UTXOs with different covenants or without covenant are not fungible.
Why use UTXOs of significant value to track something that is not money? Because the reason the registry is used is to create scarcity and scarcity can be tailored to more or
less severe by requiring more or less satoshis to track something.
The current owner of a regular UTXO will want to be paid for temporarily giving up control, and that payment represents interest. Riskless, since it is certain to re-gain control.
Regards,
Tamas Blummer
[-- Attachment #1.2: Type: text/html, Size: 14796 bytes --]
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-07-06 10:12 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
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 [this message]
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=16B09501-7AE3-4F8E-A1A4-3E5F6B12D127@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