public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil.org>
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: Fri, 5 Jul 2019 16:44:45 -0700	[thread overview]
Message-ID: <A1ADD0BB-F62F-47AF-B043-53BDF3A88CC3@voskuil.org> (raw)
In-Reply-To: <4mT6iC4Va7Afg15a5NLbddAnF2a_vAcQSXYr_jg_5IyEK2ezblJff7EJZakoqvp4BJlLitt9Zlq1_l5JadR0nVss7VDPW-pv8jXGh7lkFC4=@protonmail.com>



> On Jul 5, 2019, at 16: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> 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.
> 
>>> Similarly, an entity renting out a UTXO for an advertisement might allow for early reclamation of the UTXO in exchange for partial refund of fee; as the value in the UTXO is now freed to be spent elsewhere, the lessor can lease it to another advertiser.
>> 
>> You appear to be proposing a design whereby either the owner or the renter (not entirely clear to me which) can spend the “locked up” coin at any time (no maturity constraint), by dropping the covenant.
>> 
>> If the renter can do this he can simply steal the coin from the owner.
>> 
>> If the owner can do this there is no value to the renter (or as a proof of cost), as the owner retains full control of the coin.
>> 
> 
> Obviously this will require a 2-of-2 multisig, with an timelocked transaction that lets the owner recover at a futuredate, so that it is the agreement of *both* that is needed to perform any actions before the timelock.
> I already described this in the link I provided.
> 
> 
>> If you mean that the age of the encumbrance is the proof of cost, this requires no covenant. I don’t believe this is what you intended, just covering all bases.
> 
> Not age of encumbrance, quite.
> Instead, it is the simple fact that the UTXO is a UTXO (and not yet spent), that validates the advertisement.

Not any UTXO then, one that with sufficient time-locked coin.

> No, it does not *require* a covenant.
> However, covenants do make it easier to use, in the sense that the renter can repurpose the UTXO (e.g. change details of advertisement) without having to contact the owner.

So how does one get the owner to sign off on the multisig release? Presumably the renter cares because he wants to recover the remaining value of rental. So he not only needs to contact the owner, he also needs to negotiate with the owner for a pro-rated refund. In other words, he must sell the remaining portion of the rental return - essentially how I described it previously. He might as well just sell the marketable ad space that he controls through the remainder of the term (the same value).

Certainly the owner could given him a partially-signed transaction, returning the coin, allowing the renter to exit at any time, but the renter has no reason to sign it without a refund, which must be pro-rated in some way, implying later contact/negotiation with the owner.

But it’s worth noting that early recovery of the UTXO entirely eliminates the value of the time lock cost to the ad market. The most obvious example is one encumbering the coin to himself, then releasing it with his own two signatures whenever he wants. In other words, there is no encumbrance at all, just a bunch of pointless obscurantion.

>>> Burnt funds cannot be "un-burnt" to easily signal the end of a term for an advertisement.
>> 
>> 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.

I think I understand the implications of it clearly. Feel free to point out what I’m missing. But I don’t spend any time in implementation details until I can justify those implications.

A multisig doesn’t fix the central economic issue, which it is not clear that you understand. If so it hasn’t been demonstrated. A cost created by making coin unusable for a term is not an actual cost if that lock can be released at any time before maturity of that term. Furthermore, cost is most easily demonstrated by simply spending. 

By analogy, proof of work is simply proof of a spend (incurred cost). Imagine if one demonstrated that cost by “locking up” coin for a year, and then after the block was accepted, he unlocked that coin after just one day.

Best,
Eric

> Regards,
> ZmnSCPxj


  reply	other threads:[~2019-07-05 23:44 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 [this message]
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=A1ADD0BB-F62F-47AF-B043-53BDF3A88CC3@voskuil.org \
    --to=eric@voskuil.org \
    --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