From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
To: Eric Voskuil <eric@voskuil.org>
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, 05 Jul 2019 23:16:17 +0000 [thread overview]
Message-ID: <4mT6iC4Va7Afg15a5NLbddAnF2a_vAcQSXYr_jg_5IyEK2ezblJff7EJZakoqvp4BJlLitt9Zlq1_l5JadR0nVss7VDPW-pv8jXGh7lkFC4=@protonmail.com> (raw)
In-Reply-To: <B853EDF2-8A8A-44B0-A66E-F86175E61EDA@voskuil.org>
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.
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.
>
> > 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.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2019-07-05 23:16 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 [this message]
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='4mT6iC4Va7Afg15a5NLbddAnF2a_vAcQSXYr_jg_5IyEK2ezblJff7EJZakoqvp4BJlLitt9Zlq1_l5JadR0nVss7VDPW-pv8jXGh7lkFC4=@protonmail.com' \
--to=zmnscpxj@protonmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=eric@voskuil.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