public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 13:31:03 -0500	[thread overview]
Message-ID: <DDDE70C5-8C81-4513-8554-4363C995B302@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.

Burning is not an economic concern and cannot be prevented. As there are fewer coins, all things being equal, the cost of each increases, and thus fewer must be burned to achieve the same cost. So assuming sufficient divisibility (an existing Bitcoin assumption) it is sustainable. But as I demonstrated, it’s not necessary.

> - Pay high fees in self dealing transactions. This could work and would benefit miner.

This is essentially what I suggested, though presumably you mean Bitcoin fees not secondary network.

> - 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. The problem is one might not have substantial UTXO to  imply high enough opportunity cost.

Another reason why simply spending or burning them is preferential.

> - 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.

This implies additional complexity with no benefit to anyone required by the scenario, which was my implication.

> - 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.

The terms lend/borrow are misleading here, as I have previously shown. The coin is neither spendable nor consumable. This is why I have used the terms owner/renter. Yes, the renter can sell the remaining rental expense to another.

Yes, the potential incremental value over the other scenarios is transferability of the output, but this accrues to both to the advertiser/renter and the owner (trade always benefits both parties trading). This transfer incurs a fee if on chain, and in the tracking scenario may easily overwhelm the effective benefit (fraction of the rental, no higher than dust, not yet expired), making it economically non-transferrable.

In the advertising scenario this transfer can be achieved independent of Bitcoin, by simply changing the advertisement (e.g. publish a provably-superseding ad for the same output), avoiding the material on-chain fee. Recall that the value of the coin cannot be captured by the advertiser through transfer, just the tracking cost.

e

> 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
> 


  reply	other threads:[~2019-07-04 18: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 [this message]
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=DDDE70C5-8C81-4513-8554-4363C995B302@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