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: Sat, 6 Jul 2019 15:21:59 -0700	[thread overview]
Message-ID: <16B94409-AB0A-49E3-8B0D-C52A4B1C6ACA@voskuil.org> (raw)
In-Reply-To: <8D68DC86-1173-43AC-BC84-FE2834741C13@gmail.com>


> On Jul 6, 2019, at 06:34, Tamas Blummer <tamas.blummer@gmail•com> wrote:
> 
> Hi Eric,
> 
>> On Jul 6, 2019, at 03:28, Eric Voskuil <eric@voskuil•org> wrote:
>> 
>> 
>> 
>>> On Jul 5, 2019, at 17:17, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
>>> 
>>> Good morning Eric,
>>> 
>>>> 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.
>>> 
>>> You still do not understand.
>>> I strongly suggest actually reading the post instead of skimming it.
>> 
>> I am responding to the cryptoeconomic principles, not the implementation details. Based on your comments here I am not misrepresenting those principles.
>> 
>> For example, I have shown that the multisig unlock implementation reduces the presumably-encumbered UTXO to simply a UTXO. You have not disputed that. In fact below you have accepted it (more below).
>> 
>>> The advertisement is broadcast to new nodes on the ad network if and only if its backing UTXO remains unspent.
>>> Once the UTXO is spent, then the advertisement is considered no longer valid and will be outright deleted by existing nodes, and new nodes will not learn of them (and would consider it spam if it is forced to them when the UTXO is already spent, possibly banning the node that pushes the advertisement at them).
>>> 
>>> Thus the locked-ness of the UTXO is the lifetime of the advertisement.
>> 
>> The term “locked” here is misused. A unspent output that can be spent at any time is just an unspent output. The fact that you can “unencumber” your own coins should make this exceedingly obvious:
>> 
>>> Once you disencumber the coins (whether your own, or rented) then your advertisement is gone; forever.
>> 
>> As I have shown, there is no *actual* encumbrance.
>> 
> If you have to forgo using your money while using a service that encumbers you. You incur opportunity cost proportional to time you use the service and the amount you waived to use elsewhere.
> No crypto is needed to understand this.

My use of “encumbrance” in this thread has been consistently a reference to a covenant. When the covenant can be released at any time it serves no purpose whatsoever, being an encumbrance in name only.

I gave a detailed explanation of opportunity cost, and gave you a scenario where that opportunity cost could actually be used - to purchase a tracking output (i.e., a fixed term asset tracked for that term). And I have discussed at length the use of opportunity cost in the hash-cash-like anti-spam ad scenario.

So it’s not clear to me why you continue to imply that the nature of either covenants or opportunity cost is the point at issue, and by implying I don’t understand them.

**The central issue in your proposal is that constrained coins can neither be used as borrowed money nor the tracking of perpetual assets.** This conclusion is not based on a failure to understand the nature of covenants or the concept of opportunity cost. It is the necessary consequence of attempting to trade something today that will provably disappear tomorrow. The sole possible value of such an instrument is to scam the eventual bag-holders.

A secondary issue, in the valid fixed-term asset tracking scenario, is that the cost of tracking is dust (and at least one transfer fee). The cost of such tracking is a function only of the market price of a satoshi. The financial value of renting one dust output is also limited in time by economic  interest (i.e., at 10% it is cheaper to buy than rent if the fixed term exceeds 7.2 years). So while valid, is not likely to be demanded until one satoshi becomes worth the overhead of renting it.

The opportunity of interest represents opportunity cost when forgone. This can be used to show proof-of-cost (ad scenario), and that level can float as a price on the anti-spam market. This is a perfectly valid scenario, as I have said.

The issue with that specific proposal is that it uses covenants in an irrational manner. The ability to release the covenant at any time eliminates the cost it would otherwise represent. One could either simply burn or spend coin outright, or use an actual encumbrance (as you propose) to “burn” (provably destroy) the opportunity, but a non-encumbrance adds nothing except complexity.

>>> Your advertisement exists only as long as the UTXO is unspent.
>> 
>> Exactly, which implies *any* UTXO is sufficient. All that the ad network requires is proof of ownership of any UTXO.
>> 
> Not any, but one with significant value, so a service with limited bandwith can prioritize by that.

Not significant, which is arbitrary, but sufficient - a result of supply and demand. Clearly my intent here is that no covenant on the UTXO is required in the scenario. As the preceding discussions conclude, without disagreement, all that is required is that the (sufficient) output remains unspent, not that it be encumbered.

>> Best,
>> Eric
>> 
>>> Regards.
>>> ZmnSCPxj
> 
> Best,
> 
> Tamas Blummer


  reply	other threads:[~2019-07-06 22:22 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
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 [this message]
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=16B94409-AB0A-49E3-8B0D-C52A4B1C6ACA@voskuil.org \
    --to=eric@voskuil$(echo .)org \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=tamas.blummer@gmail$(echo .)com \
    /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