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:20:17 -0700	[thread overview]
Message-ID: <F9B77954-7F2A-4A8D-8ABF-502A9F48F503@voskuil.org> (raw)
In-Reply-To: <B853EDF2-8A8A-44B0-A66E-F86175E61EDA@voskuil.org>



> On Jul 5, 2019, at 12:27, 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.”
> 
>> 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.
> 
> 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.
> 
>> 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.
> 
>> Similarly for miner fees.
> 
> Well that’s the point, money spent is no longer under one’s control. The provable cost of this surrender was your stated objective. Renting at a fractional cost of coin face value is a non-recoverable spend by the renter to the owner. Burning or spending the same amount in a way that is provably not to one’s self achieves the exact same result.
> 
>> The best that can be done would be to have the nodes of the classified ads network automatically decay the spent value of older advertisements to let them be dropped from their advertisements pool.
> 
> The advertiser can presumably trade control of as space on the ad network. It’s not clear to me why this is not simply an independent chain of limited ad space ownership. It might as well be namecoin.
> 
>> Less importantly, burning currently has bad resource usage for practical applications.
>> Practical burning requires spending to a provably-unspendable P2PKH or P2SH or similar output.
>> This adds UTXO entries to the UTXO database that will never be removed.

I forgot to add that it is certainly possible to burn using a nonstandard script, such as the non-zero OP_RETURN you suggested, without a consensus change. This can be, as you say, made more practical with a policy change. But such changes are up to individual node operators as they require no deviation from consensus. Yet ultimately this is a miner preference, and anyone can mine. Finally, as I pointed out, burning is not necessary. Simply spending the coin as a fee is sufficient.

> If an output is provably unspendable (burned) it is not a UTXO.
> 
> It is worth noting that not all full node implementations require a store of UTXOs, this is an implementation detail. For example, libbitcoin uses a flag on each output to indicate its spentness on the strong branch. As such the store size is linear by height.
> 
>> This will of course be remedied by compact UTXO representations later, but not today.
>> Similarly, it would be very nice to have non-0-amount `OP_RETURN` outputs, as `OP_RETURN` outputs are never stored in the UTXO database.
>> However, this will require a change in node relay policy, which again will take time to make possible, and would not be practical today.
>> 
>> Thus I think use of UTXO is better than burning or mining-fee-spending.
> 
> I don’t believe you have shown this.
> 
> Best,
> Eric
> 
>> Also, mostly trivia:
>> The use of UTXOs to advertise services is not original to me --- I found the LN channel gossip to be the inspiration for this.
>> Publicly-announced channels indicate the backing UTXO that funds the channel.
>> The purpose of publicly announcing the channels is to be able to provide the service, of forwarding across the Lightning Network; thus the public announcement serves as an advertisement for the service.
>> Channel closure immediately spends the UTXO, and also doubles to "revoke" the existing "advertisement".
>> I found this ability to "revoke" the advertisement appealing, and thereby designed the Bitcoin Classified Ads Network around the UTXO spentness mechanism.
>> 
>> Regards,
>> ZmnSCPxj


  parent reply	other threads:[~2019-07-05 23:20 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
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 [this message]
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=F9B77954-7F2A-4A8D-8ABF-502A9F48F503@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