From: Eric Voskuil <eric@voskuil.org>
To: Tamas Blummer <tamas.blummer@gmail.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: Thu, 4 Jul 2019 14:31:12 -0500 [thread overview]
Message-ID: <5DC8D144-7376-4BAA-ABEC-9579D3B9F5D1@voskuil.org> (raw)
In-Reply-To: <BFC25438-CA9F-4F95-A79C-089EE3C52917@gmail.com>
> On Jul 4, 2019, at 12:10, Tamas Blummer <tamas.blummer@gmail.com> wrote:
>
> Hi Eric,
>
> there are some other ways to impose cost on use without direct billing, e.g.:
>
> - Burn Bitcoins to use the service, as you mentioned. This could work and would benefit remaining Bitcoin owner, but is unsustainable.
>
> - Pay high fees in self dealing transactions. This could work and would benefit miner.
>
> - Time lock own Bitcoins. This is forgoing control of an UTXO for a time period, which implies opportunity cost. This could be done with CLTV (OP_HODL). It damages the current owner but benefits no one.
I meant to point out that a voluntarily trade cannot represent “damage” to the person making it. The person chooses the action because it is preferred over alternatives (i.e. it is beneficial). Such choices are the only objective expression of preference, a fundamental principle of praxeology.
> The problem is one might not have substantial UTXO to imply high enough opportunity cost.
>
> - Pay someone else to time lock. This is paying someone to lock an UTXO for a time span. Payment and time lock could be combined in the same transaction.
>
> - Transferable borrowed Bitcoin. This needs the covenant. This benefits those who consciously give up control for a time span. Its advantage is that since transferable it can be sold if no longer needed, thereby shortening the term of the original arrangement. It coul be re-rented for a shorter time period.
>
> Tamas Blummer
>
>
>> On Jul 4, 2019, at 18:43, Eric Voskuil <eric@voskuil.org> wrote:
>>
>> Hi ZmnSCPxj,
>>
>> Generalizing a bit this appears to be the same with one exception. The amount of encumbered coin is relevant to an external observer. Of course the effective dust limit is the maximum necessary encumbrance otherwise.
>>
>> In the case of simple tracking, the market value of the coin is not relevant, all that is required is a valid output. Hence the devolution to 1 sat tracking. In your scenario the objective is to establish a meaningful cost for the output.
>>
>> A community of people using this as a sort of hashcash spam protection can raise the amount of encumbered coin (i.e. advertising threshold price) required in that context. The cost of this encumberance includes not only at least one tx fee but market cost of the coin rental.
>>
>> At a 1 year advertisement term, 10% APR capital cost, and threshold of 1 encumbered coin, the same is achieved by burning .1 coin. In other words the renter (advertiser) has actually paid to the coin owner .1 coin to rent 1 coin for one year.
>>
>> 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?
>>
>> e
>>
>>> On Jul 3, 2019, at 23:57, ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
>>>
>>> Good morning Eric,
>>>
>>>
>>>>> and thanks to you and ZmnSCPxj we now have two additional uses cases for UTXOs that are only temporarily accessible to their current owner.
>>>>
>>>> Actually you have a single potentially-valid use case, the one I have presented. The others I have shown to be invalid (apart from scamming) and no additional information to demonstrate errors in my conclusions have been offered.
>>>
>>> I presented another use case, that of the "Bitcoin Classified Ads Network".
>>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083.html
>>>
>>> Advertisements are "backed" by an unspent TXO.
>>> In order to limit their local resource consumption, nodes of this network will preferentially keep advertisements that are backed by higher UTXO values divided by advertisement size, and drop those with too low UTXO value divided by advertisement size.
>>>
>>> Thus, spammers will either need to rent larger UTXO values for their spam, paying for the higher rent involved, or fall back to pre-Bitcoin spamming methods.
>>> Thus I think I have presented a use-case that is viable for this and does not simply devolve to "just burn a 1-satoshi output".
>>>
>>> I still do not quite support generalized covenants as the use-case is already possible on current Bitcoin (and given that with just a little more transaction introspection this enables Turing-completeness), but the basic concept of "renting a UTXO of substantial value" appears sound to me.
>>>
>>>
>>> Regards,
>>> ZmnSCPxj
>
next prev parent reply other threads:[~2019-07-04 19:31 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 [this message]
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=5DC8D144-7376-4BAA-ABEC-9579D3B9F5D1@voskuil.org \
--to=eric@voskuil.org \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=tamas.blummer@gmail.com \
/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