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 18:46:45 -0700	[thread overview]
Message-ID: <91607BB7-B57E-4F28-9DDF-D22B8E98739B@voskuil.org> (raw)
In-Reply-To: <0851B842-34A1-427F-95DC-A1D6AB416FB9@voskuil.org>



> On Jul 5, 2019, at 18: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.
> 
>> 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.
> 
> Unspentness is not actually a necessary cost (expense). All coin is always represented as UTXOs. If one has a hoard of coin there is no necessary incremental cost of identifying those coins to “back” ads.This isn’t altered by the proposed design.
> 
> The only cost would be to have a hoard that one does not otherwise desire, representing an opportunity cost. Yet, as I have also pointed out, the amount of that opportunity cost can simply be spent (or burned) by the advertiser, representing the same cost. So covering the case where one cannot raise the capital to “back” one’s ad does not require rental, as the cost of the otherwise rental can just be spent outright.
> 
> Presumably it would be ideal to transfer the value of those spends to people who provably present the ads for effective viewing (i.e., the AdWords business model). It is of course this market-driven cost of presenting an ad that provides the spam protection/definition for AdWords.

It’s worth pointing out at this point that this implies Google, etc. would achieve the same result by simply accepting Bitcoin for ad placement. In your model the advertiser is paying only for access to people who wish to avoid spam, not for targeted and actual placement. In other words your ad system would be directly competing with others that provide material additional value for the advertiser beyond anti-spam. If nothing else this implies the return on coin “lock-up” would be exceeded by its opportunity cost.

> Best,
> Eric
> 
>> Regards.
>> ZmnSCPxj


  reply	other threads:[~2019-07-06  1:46 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
2019-07-06  0:17                                       ` ZmnSCPxj
2019-07-06  1:28                                         ` Eric Voskuil
2019-07-06  1:46                                           ` Eric Voskuil [this message]
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=91607BB7-B57E-4F28-9DDF-D22B8E98739B@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