Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 30B7B1624 for ; Fri, 5 Jul 2019 23:44:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf1-f196.google.com (mail-pf1-f196.google.com [209.85.210.196]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 613DF70D for ; Fri, 5 Jul 2019 23:44:48 +0000 (UTC) Received: by mail-pf1-f196.google.com with SMTP id b13so292406pfo.1 for ; Fri, 05 Jul 2019 16:44:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=voskuil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MORgeyH2rFbANrL4IkDnriesnvdkRdC1BBLXEzOqPGE=; b=lCUWoJter6QhaEUEm1O1SyxKKPduq9Dju2ofrjBGQEFS+/9jnbayaPRZy6LK1emKMu InB3njQvjpGE6fqQPafNsmtv5O/4QbkJTVmDRwjueZXhENp6xfGgIyQM/Meym/nYVmpV 5XxdrRGUuz02OlT7BQiwVN7fXrVqUHwm378jBLgHIRkQkcKULR4m5oaRiLiJ9T7bmf6q XZ47qGaWD6d+vh75kQ+ahKYovYcY+hWKuNv74NU5THnnU9X4wQ6FbmLUNCDoqvR6/aVG TKjPlDbBABcWhkIrv6HrI+cD8RS1G+jyJB9lsDYw3UEasorty+Z9ts+zRtc2guhdBkz3 jhPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MORgeyH2rFbANrL4IkDnriesnvdkRdC1BBLXEzOqPGE=; b=E7IO3caZKDCuYSpTt2DT2Nt4e0ogdUeErBdqGflLXNJ7HZzegwah7oiho/kEAUtIq9 oTcTB4aaVrui1FWvBxmOJwtv3Tr6mn7Poj5gPRxxoUBN6H09tTJ3PmDyrBt159IvQgYv e5n40JX5TCnl5jFYXXX8FMpXfUnD20nSu5gB+BDFXxATg6JiQ9H+7xZVs1pxfasStBdw w8LDXMTj4Mc2wNmskyGd2/4zQAQph6X+hxHcMzQzzBSto8RCYsGggXQAVK4Z3HDqyicJ yDQ9dg2QuVcul1NgYSG+jDw4QWlmAT1Jd9O0y3Z+IiW9Xx1HHCcBiWG8v9RL8HFYN68H n4/g== X-Gm-Message-State: APjAAAWjVogF9oL0In+42M8SMpenwIxqq5mjaN0V4/sJu1rH5/LfGwdt 1TXGdzkqeVlzjH2Q90sEQq5/dw== X-Google-Smtp-Source: APXvYqzT4N99TrRpq3aVJLiH37QAqMKJwy/WRMmFFF5LGSrkj/6zXVZtcOa+DH74MN0/d+UD4+ignw== X-Received: by 2002:a63:e250:: with SMTP id y16mr7861413pgj.392.1562370287857; Fri, 05 Jul 2019 16:44:47 -0700 (PDT) Received: from ?IPv6:2601:600:a080:16bb:c899:e1f8:fb96:3f43? ([2601:600:a080:16bb:c899:e1f8:fb96:3f43]) by smtp.gmail.com with ESMTPSA id 65sm10637884pff.148.2019.07.05.16.44.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jul 2019 16:44:47 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Eric Voskuil X-Mailer: iPhone Mail (16F203) In-Reply-To: <4mT6iC4Va7Afg15a5NLbddAnF2a_vAcQSXYr_jg_5IyEK2ezblJff7EJZakoqvp4BJlLitt9Zlq1_l5JadR0nVss7VDPW-pv8jXGh7lkFC4=@protonmail.com> Date: Fri, 5 Jul 2019 16:44:45 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com> <0AA10217-E1CC-46D1-9B43-038CEEF942CD@gmail.com> <6B9A04E2-8EEE-40A0-8B39-64AA0F478CAB@voskuil.org> <4mT6iC4Va7Afg15a5NLbddAnF2a_vAcQSXYr_jg_5IyEK2ezblJff7EJZakoqvp4BJlLitt9Zlq1_l5JadR0nVss7VDPW-pv8jXGh7lkFC4=@protonmail.com> To: ZmnSCPxj X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, MIME_QP_LONG_LINE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sat, 06 Jul 2019 01:34:57 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jul 2019 23:44:49 -0000 > On Jul 5, 2019, at 16:16, ZmnSCPxj wrote: >=20 > Good morning Eric, >=20 >=20 > Sent with ProtonMail Secure Email. >=20 > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 > On Saturday, July 6, 2019 3:27 AM, Eric Voskuil wrote: >=20 >>> On Jul 4, 2019, at 21:05, ZmnSCPxj ZmnSCPxj@protonmail.com wrote: >>> Good morning Eric, >>>=20 >>>> As with Bitcoin mining, it is the consumed cost that matters in this sc= enario, (i.e., not the hash rate, or in this case the encumbered coin face v= alue). Why would the advertiser not simply be required to burn .1 coin for t= he same privilege, just as miners burn energy? Why would it not make more se= nse to spend that coin in support of the secondary network (e.g. paying for c= onfirmation security), just as with the burning of energy in Bitcoin mining?= >>=20 >> Good morning ZmnSCPxj, >>=20 >>> Using the unspentness-time of a UTXO allows for someone advertising a se= rvice 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 goo= ds, once the stock has been sold, the merchant (assuming the merchant used o= wn funds) can simply recover the locked funds, with the potential to reinves= t them elsewhere. >>> This allows some time-based hedging for the merchant (they may be willin= g 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 anym= ore). >>=20 >> This is a materially different concept than proposed by Tamas. >>=20 >> =E2=80=9C...he gives up his control of the coins until maturity, he can n= ot use them elsewhere until then.=E2=80=9D >=20 > Possibly. > In a way, this is giving up control of the coin, until he no longer needs t= he advertisement, i.e. dynamically select the maturity age needed. >=20 >>> 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 le= ase it to another advertiser. >>=20 >> You appear to be proposing a design whereby either the owner or the rente= r (not entirely clear to me which) can spend the =E2=80=9Clocked up=E2=80=9D= coin at any time (no maturity constraint), by dropping the covenant. >>=20 >> If the renter can do this he can simply steal the coin from the owner. >>=20 >> If the owner can do this there is no value to the renter (or as a proof o= f cost), as the owner retains full control of the coin. >>=20 >=20 > Obviously this will require a 2-of-2 multisig, with an timelocked transact= ion 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. >=20 >=20 >> If you mean that the age of the encumbrance is the proof of cost, this re= quires no covenant. I don=E2=80=99t believe this is what you intended, just c= overing all bases. >=20 > 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 c= an repurpose the UTXO (e.g. change details of advertisement) without having t= o contact the owner. So how does one get the owner to sign off on the multisig release? Presumabl= y 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 remainin= g portion of the rental return - essentially how I described it previously. H= e might as well just sell the marketable ad space that he controls through t= he remainder of the term (the same value). Certainly the owner could given him a partially-signed transaction, returnin= g the coin, allowing the renter to exit at any time, but the renter has no r= eason to sign it without a refund, which must be pro-rated in some way, impl= ying later contact/negotiation with the owner. But it=E2=80=99s worth noting that early recovery of the UTXO entirely elimi= nates the value of the time lock cost to the ad market. The most obvious exa= mple is one encumbering the coin to himself, then releasing it with his own t= wo signatures whenever he wants. In other words, there is no encumbrance at a= ll, just a bunch of pointless obscurantion. >>> Burnt funds cannot be "un-burnt" to easily signal the end of a term for a= n advertisement. >>=20 >> And as I have shown above, nor can a =E2=80=9Clocked-up=E2=80=9D coin be u= nlocked to do the same. >=20 > You have shown no such thing, merely shown that you have not understood th= e proposal. I think I understand the implications of it clearly. Feel free to point out w= hat I=E2=80=99m missing. But I don=E2=80=99t spend any time in implementatio= n details until I can justify those implications. A multisig doesn=E2=80=99t fix the central economic issue, which it is not c= lear that you understand. If so it hasn=E2=80=99t been demonstrated. A cost c= reated 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.=20 By analogy, proof of work is simply proof of a spend (incurred cost). Imagin= e if one demonstrated that cost by =E2=80=9Clocking up=E2=80=9D coin for a y= ear, and then after the block was accepted, he unlocked that coin after just= one day. Best, Eric > Regards, > ZmnSCPxj