From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 1D3D1E19 for ; Thu, 4 Jul 2019 18:31:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io1-f67.google.com (mail-io1-f67.google.com [209.85.166.67]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EE7D787C for ; Thu, 4 Jul 2019 18:31:05 +0000 (UTC) Received: by mail-io1-f67.google.com with SMTP id k8so14505385iot.1 for ; Thu, 04 Jul 2019 11:31:05 -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=RCaI4LunHChNQb+kh1n9Yu+yA0B+smufloSPglMmpiY=; b=xWh4XAhjHoIIz/bvlkw/CrOdvcKhIrzW4N3GF+T4Kdcnj53wY9MJ1eU8smHokKSmJg bb7evP0Uk+ixL7v1MRHJ51CjbHeoD3SzgNUxavv6RNBSm+nGplzLElIcnazrWZylAOFY EXUjfCvul6MHznOEJ/TTNYmOkPpjcIkA4qM1lJPsyOow3ClJv6Ov5JegsaZ4A8su4No2 v6MVOTNc1f5Z/BNPsc0j39ZnWCvi2rkx4Ve0soKxxHTM8Vm61D2+lXmyryeG1ltMYQFX 5HefcXJK4bptJHBWCB19+WgmPQh6UcYGPiEJ3iOiDMt4URQc3eICLw0huE7e882AOih8 vPDg== 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=RCaI4LunHChNQb+kh1n9Yu+yA0B+smufloSPglMmpiY=; b=ogDoSqUSDwf39ZKd8F/tqtoNgrmS62WjBzEnoKMUS5u2t0LYHh92DyTVkBDID0qQqi nwGVzDbGzqIlF46IIA5Sm6A44OC2lp23/xmptjjvZF3cW7ZfSzVzhMXEwa9e/FICfGH+ oDV07AAbZrXyt+kt9EMlt/KDaPxEXbTeUT6arxo9e+m4Xe/Uj8WJHMbleQ7x4NjOv4Nt 8cVCF5LACC4nAz/wvgJL49UDwK1WNwoGjJczgiI654mwuCf6BObWDKjvXn3z/E1ZhP1x qJTbopHTYUSUXYRsv7g0OKzrh+aAMYQRUkVyxyr89GhJP/cbBclq4gEM/ujK5ut/+50G bFCA== X-Gm-Message-State: APjAAAUm7LIrkgWbiSaHbsff46NQN6o4xx/Zgc+GVZEroaOBOs9c75z2 lf0siR+eCYDfB6/95THo8gz6kA== X-Google-Smtp-Source: APXvYqzTPuBoBIZkVOZaHz94xkIiQ3TJlMCare3W98CitN97ILRCYA8HcfZYRNQQJXgb8Trwr8VDNA== X-Received: by 2002:a6b:7d49:: with SMTP id d9mr4116497ioq.50.1562265065187; Thu, 04 Jul 2019 11:31:05 -0700 (PDT) Received: from ?IPv6:2600:380:c458:7e3a:5803:ef0e:5551:2919? ([2600:380:c458:7e3a:5803:ef0e:5551:2919]) by smtp.gmail.com with ESMTPSA id c81sm11831893iof.28.2019.07.04.11.31.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jul 2019 11:31:04 -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: Date: Thu, 4 Jul 2019 13:31:03 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com> <3F46CDD5-DA80-49C8-A51F-8066680EF347@voskuil.org> <063D7C06-F5D8-425B-80CE-CAE03A1AAD0C@voskuil.org> <0AA10217-E1CC-46D1-9B43-038CEEF942CD@gmail.com> <6B9A04E2-8EEE-40A0-8B39-64AA0F478CAB@voskuil.org> To: Tamas Blummer 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: Fri, 05 Jul 2019 13:54:09 +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: Thu, 04 Jul 2019 18:31:07 -0000 > On Jul 4, 2019, at 12:10, Tamas Blummer wrote: >=20 > Hi Eric, >=20 > there are some other ways to impose cost on use without direct billing, e.= g.: >=20 > - Burn Bitcoins to use the service, as you mentioned. This could work and w= ould benefit remaining Bitcoin owner, but is unsustainable. Burning is not an economic concern and cannot be prevented. As there are few= er coins, all things being equal, the cost of each increases, and thus fewer= must be burned to achieve the same cost. So assuming sufficient divisibilit= y (an existing Bitcoin assumption) it is sustainable. But as I demonstrated,= it=E2=80=99s not necessary. > - Pay high fees in self dealing transactions. This could work and would be= nefit miner. This is essentially what I suggested, though presumably you mean Bitcoin fee= s not secondary network. > - Time lock own Bitcoins. This is forgoing control of an UTXO for a time p= eriod, which implies opportunity cost. This could be done with CLTV (OP_HODL= ). It damages the current owner but benefits no one. The problem is one migh= t not have substantial UTXO to imply high enough opportunity cost. Another reason why simply spending or burning them is preferential. > - Pay someone else to time lock. This is paying someone to lock an UTXO fo= r a time span. Payment and time lock could be combined in the same transacti= on. This implies additional complexity with no benefit to anyone required by the= scenario, which was my implication. > - Transferable borrowed Bitcoin. This needs the covenant. This benefits t= hose who consciously give up control for a time span. Its advantage is that s= ince transferable it can be sold if no longer needed, thereby shortening the= term of the original arrangement. It coul be re-rented for a shorter time p= eriod. The terms lend/borrow are misleading here, as I have previously shown. The c= oin is neither spendable nor consumable. This is why I have used the terms o= wner/renter. Yes, the renter can sell the remaining rental expense to anothe= r. Yes, the potential incremental value over the other scenarios is transferabi= lity of the output, but this accrues to both to the advertiser/renter and th= e owner (trade always benefits both parties trading). This transfer incurs a= fee if on chain, and in the tracking scenario may easily overwhelm the effe= ctive benefit (fraction of the rental, no higher than dust, not yet expired)= , making it economically non-transferrable. In the advertising scenario this transfer can be achieved independent of Bit= coin, by simply changing the advertisement (e.g. publish a provably-supersed= ing ad for the same output), avoiding the material on-chain fee. Recall that= the value of the coin cannot be captured by the advertiser through transfer= , just the tracking cost. e > Tamas Blummer >=20 >=20 >> On Jul 4, 2019, at 18:43, Eric Voskuil wrote: >>=20 >> Hi ZmnSCPxj, >>=20 >> Generalizing a bit this appears to be the same with one exception. The am= ount of encumbered coin is relevant to an external observer. Of course the e= ffective dust limit is the maximum necessary encumbrance otherwise. >>=20 >> In the case of simple tracking, the market value of the coin is not relev= ant, all that is required is a valid output. Hence the devolution to 1 sat t= racking. In your scenario the objective is to establish a meaningful cost fo= r the output. >>=20 >> A community of people using this as a sort of hashcash spam protection ca= n raise the amount of encumbered coin (i.e. advertising threshold price) req= uired in that context. The cost of this encumberance includes not only at le= ast one tx fee but market cost of the coin rental. >>=20 >> At a 1 year advertisement term, 10% APR capital cost, and threshold of 1 e= ncumbered coin, the same is achieved by burning .1 coin. In other words the r= enter (advertiser) has actually paid to the coin owner .1 coin to rent 1 coi= n for one year. >>=20 >> As with Bitcoin mining, it is the consumed cost that matters in this scen= ario, (i.e., not the hash rate, or in this case the encumbered coin face val= ue). 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 sens= e to spend that coin in support of the secondary network (e.g. paying for co= nfirmation security), just as with the burning of energy in Bitcoin mining? >>=20 >> e >>=20 >>> On Jul 3, 2019, at 23:57, ZmnSCPxj wrote: >>>=20 >>> Good morning Eric, >>>=20 >>>=20 >>>>> and thanks to you and ZmnSCPxj we now have two additional uses cases f= or UTXOs that are only temporarily accessible to their current owner. >>>>=20 >>>> Actually you have a single potentially-valid use case, the one I have p= resented. The others I have shown to be invalid (apart from scamming) and no= additional information to demonstrate errors in my conclusions have been of= fered. >>>=20 >>> I presented another use case, that of the "Bitcoin Classified Ads Networ= k". >>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083= .html >>>=20 >>> Advertisements are "backed" by an unspent TXO. >>> In order to limit their local resource consumption, nodes of this networ= k will preferentially keep advertisements that are backed by higher UTXO val= ues divided by advertisement size, and drop those with too low UTXO value di= vided by advertisement size. >>>=20 >>> Thus, spammers will either need to rent larger UTXO values for their spa= m, paying for the higher rent involved, or fall back to pre-Bitcoin spamming= methods. >>> Thus I think I have presented a use-case that is viable for this and doe= s not simply devolve to "just burn a 1-satoshi output". >>>=20 >>> I still do not quite support generalized covenants as the use-case is al= ready possible on current Bitcoin (and given that with just a little more tr= ansaction introspection this enables Turing-completeness), but the basic con= cept of "renting a UTXO of substantial value" appears sound to me. >>>=20 >>>=20 >>> Regards, >>> ZmnSCPxj >=20