From: Tamas Blummer <tamas.blummer@gmail•com>
To: Eric Voskuil <eric@voskuil•org>
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: Sun, 30 Jun 2019 21:55:41 +0200 [thread overview]
Message-ID: <A4A6099F-F115-4CBF-B7D5-F16581476126@gmail.com> (raw)
In-Reply-To: <3F46CDD5-DA80-49C8-A51F-8066680EF347@voskuil.org>
[-- Attachment #1: Type: text/plain, Size: 5779 bytes --]
> On Jun 30, 2019, at 20:54, Eric Voskuil <eric@voskuil•org> wrote:
>
> Could you please explain the meaning and utility of “unforgeable register” as it pertains to such encumbered coins?
I guess we agree that some way of keeping track of ownership is prerequisite for something to aquire value.
We likely also agree that the security of that ownership register has great influence to the value.
The question remains if a register as utility in itself gives value to the thing needed to use that register.
I think it does, if people are interested in what it keeps track of, for whatever reason, even for reasons you find bogus.
It was not intentional, but I think I just explained why Ethereum aquired higher market value by being register of ICO tokens.
Now back to the coins encumbered with the debt covenant:
Transactions moving them constitute a register of covered debt and you need them to update that register.
Should some people find such a register useful then those coins needed to update this register will aquire value.
Does not matter if you think the concept of covered debt is just as bogus as ICOs.
Here some good news: If they aquire value then they offer a way to generate income for hodler by temporarily giving up control.
Tamas Blummer
>
> The meaning in terms of Bitcoin is clear - the “owner” of outputs that represent value (i.e. in the ability to trade them for something else) is recorded publicly and, given Bitcoin security assumptions, cannot be faked. What is not clear is the utility of a record of outputs that cannot be traded for something else. You seem to imply that a record is valuable simply because it’s a record.
>
> e
>
>> On Jun 30, 2019, at 11:35, Tamas Blummer <tamas.blummer@gmail•com> wrote:
>>
>>
>>> On Jun 30, 2019, at 19:41, Eric Voskuil <eric@voskuil•org> wrote:
>>>
>>>
>>>> On Jun 30, 2019, at 03:56, Tamas Blummer <tamas.blummer@gmail•com> wrote:
>>>>
>>>> Hi Eric,
>>>>
>>>>> On Jun 29, 2019, at 23:21, Eric Voskuil <eric@voskuil•org> wrote:
>>>>>
>>>>> What loan? Alice has paid Bob for something of no possible utility to her, or anyone else.
>>>>>
>>>>
>>>> Coins encumbered with the described covenant represent temporary control of a scarce resource.
>>>>
>>>> Can this obtain value? That depends on the availability of final control and ability to deal with temporary control.
>>>
>>> For something to become property (and therefore have marketable value) requires that it be both scarce and useful. Bitcoin is useful only to the extent that it can be traded for something else that is useful. Above you are only dealing with scarcity, ignoring utility.
>>
>> There is a deeper utility of Bitcoin than it can be traded for something else. That utility is to use its unforgeable register.
>> We have only one kind of units in this register and by having covenants we would create other kinds that are while encumbered not fungible with the common ones.
>>
>> Units are certainly less desirable if encumbered with a debt covenant. You say no one would assign them any value.
>>
>> I am not that sure as they still offer the utility of using the unforgeable register, in this case a register of debt covered by reserves.
>> You also doubt forcing debt to be covered by reserves is a good idea, I got that, but suppose we do not discuss this here.
>> If there are people who think it is a good idea, then they would find having an unforgeable register of it useful and therefore units needed to maintain that register valuable to some extent.
>>
>>>
>>>> I think you do not show the neccesary respect of the market.
>>>
>>> I’m not sure what is meant here by respect, or how much of it is necessary. I am merely explaining the market.
>>>
>>
>> You are not explaining an existing market but claim that market that is not yet there will follow your arguments.
>>
>>>> Your rant reminds me of renowed economists who still argue final control Bitcoin can not have value, you do the same proclaiming that temporary control of Bitcoin can not have value.
>>>
>>> It seems to me you have reversed the meaning of temporary and final. Bitcoin is useful because of the presumption that there is no finality of control. One presumes an ability to trade control of it for something else. This is temporary control. Final control would be the case in which, at some point, it can no longer be traded, making it worthless at that point. If this is known to be the case it implies that it it worthless at all prior points as well.
>>>
>>> These are distinct scenarios. The fact that temporary (in my usage) control implies the possibility of value does not imply that finality of control does as well. The fact that (renowned or otherwise) people have made errors does not imply that I am making an error. These are both non-sequiturs.
>>>
>>>> I say, that temporary control does not have value until means dealing with it are offered, and that is I work on. Thereafter might obtain value if final control is deemed too expensive or not attainable, we shall see.
>>>
>>> The analogy to rental of a consumable good does not apply to the case of a non-consumable good. If it cannot be traded and cannot be consumed it cannot obtain marketable value. To this point it matters not whether it exists.
>>>
>>
>> I meant with control the control of entries in the register which I think is the deeper utility of Bitcoin. Final control is meant to be the opposite of temporary which is the time limited control with some expiry.
>>
>> Thank you for your thoughts as they help to sharpen my arguments.
>>
>> Best,
>>
>> Tamas Blummer
>>
>>> Best,
>>> Eric
>>>
>>>> Tamas Blummer
>>>>
>>>>
>>
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2019-06-30 19:55 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 [this message]
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
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=A4A6099F-F115-4CBF-B7D5-F16581476126@gmail.com \
--to=tamas.blummer@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=eric@voskuil$(echo .)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