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 8C309155F for ; Fri, 5 Jul 2019 23:20:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-pf1-f169.google.com (mail-pf1-f169.google.com [209.85.210.169]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D943A87B for ; Fri, 5 Jul 2019 23:20:18 +0000 (UTC) Received: by mail-pf1-f169.google.com with SMTP id i189so4870195pfg.10 for ; Fri, 05 Jul 2019 16:20:18 -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=Jr9FxKbaSSn7iRc/2swytjR6lJ2vb/TKX3jfJPRi3mg=; b=0L16nl/BM9mNQdBJk66shOeKhvZIDRPKc4//MQ6esf1JuRtRxiPGzkh6YLMR7+65Xl LiQnkpkrtJKxQETbRdV71bFs1sBF7Gi7rKPp9LdxZH7u6Nz4P9b/e1fJYuCak8dS93jS o2ZrfjWRYtLkzEtt3iWuhT+sI7xBkWxIa0tXwG8lHUTyOqe3bwedBfFge8il/Gv/q1Zn u3NdYMiurZU281iGtotQ/UlWaR0sGKzFXvoS+lxsMUhjHZ5OBrXBiaUjKT3RlSaOyC/R 4d66byEsyknV8rEX94ZFw6pTrOkuOp1zPgKuRO7Y52Yw7/Sku4o/0rNRB6v+gmQx/AKM c0vQ== 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=Jr9FxKbaSSn7iRc/2swytjR6lJ2vb/TKX3jfJPRi3mg=; b=h5lYw9JsARkJv48EMK9oHCwn2cLd0R7SF+EQrNGhENTir1BI2MG4DTa/I/stfZFUXG lCeUsE7OtilsAE8Qi0g+53LGkXp0BkmMtk1veTdSWqS3uTyPXDzP/r6qDk4eRzijWtQg c9ww2FAql9gMYJvqqqdXZCf8eKHSW+l8tmzrn5pebA9EP9iiwUv5Xv7hPTy+S1xpIVq0 T5fEXqq2FmYiOwr0ZVZJWcQ7v/GrBV7Dne+A5aR9WofO/XmtAgK7mDsSgon/fyeOnP8n RSqCxk+vyvIQGuSIBIKYCz7HVAY3YFnWROZshoQot3FoWkE+OqYPiYnSwQGOmOSZnoyT HHhA== X-Gm-Message-State: APjAAAWl3aaFccIvREwQ6DqKrPRar3vgyBeEg2sCf3zaFyTfERlw0dHp iHVSG93JhXuaQDzumnNmtyiBMQ== X-Google-Smtp-Source: APXvYqxC3ejHbgSy3ayoosEN/ko5A9totZwpFasNpM4bO/OHXwyGfPnEESdafp4SUE7eUafrSdacng== X-Received: by 2002:a17:90a:f488:: with SMTP id bx8mr8302870pjb.91.1562368818303; Fri, 05 Jul 2019 16:20:18 -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 j6sm9693040pjd.19.2019.07.05.16.20.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jul 2019 16:20:17 -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: Fri, 5 Jul 2019 16:20:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com> <063D7C06-F5D8-425B-80CE-CAE03A1AAD0C@voskuil.org> <0AA10217-E1CC-46D1-9B43-038CEEF942CD@gmail.com> <6B9A04E2-8EEE-40A0-8B39-64AA0F478CAB@voskuil.org> 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:20:19 -0000 > On Jul 5, 2019, at 12:27, Eric Voskuil wrote: >=20 >=20 >> On Jul 4, 2019, at 21:05, ZmnSCPxj wrote: >>=20 >> Good morning Eric, >>=20 >>> As with Bitcoin mining, it is the consumed cost that matters in this sce= nario, (i.e., not the hash rate, or in this case the encumbered coin face va= lue). Why would the advertiser not simply be required to burn .1 coin for th= e same privilege, just as miners burn energy? Why would it not make more sen= se 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 ser= vice 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 good= s, once the stock has been sold, the merchant (assuming the merchant used ow= n 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, t= hey can immediately reap the rewards of not having their funds locked anymor= e). >=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 no= t use them elsewhere until then.=E2=80=9D >=20 >> Similarly, an entity renting out a UTXO for an advertisement might allow f= or early reclamation of the UTXO in exchange for partial refund of fee; as t= he value in the UTXO is now freed to be spent elsewhere, the lessor can leas= e it to another advertiser. >=20 > You appear to be proposing a design whereby either the owner or the renter= (not entirely clear to me which) can spend the =E2=80=9Clocked up=E2=80=9D c= oin 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 of= cost), as the owner retains full control of the coin. >=20 > If you mean that the age of the encumbrance is the proof of cost, this req= uires no covenant. I don=E2=80=99t believe this is what you intended, just c= overing all bases. >=20 >> 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 >> Similarly for miner fees. >=20 > Well that=E2=80=99s the point, money spent is no longer under one=E2=80=99= s control. The provable cost of this surrender was your stated objective. Re= nting at a fractional cost of coin face value is a non-recoverable spend by t= he renter to the owner. Burning or spending the same amount in a way that is= provably not to one=E2=80=99s self achieves the exact same result. >=20 >> The best that can be done would be to have the nodes of the classified ad= s network automatically decay the spent value of older advertisements to let= them be dropped from their advertisements pool. >=20 > The advertiser can presumably trade control of as space on the ad network.= It=E2=80=99s not clear to me why this is not simply an independent chain of= limited ad space ownership. It might as well be namecoin. >=20 >> Less importantly, burning currently has bad resource usage for practical a= pplications. >> Practical burning requires spending to a provably-unspendable P2PKH or P2= SH 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 sc= ript, such as the non-zero OP_RETURN you suggested, without a consensus chan= ge. This can be, as you say, made more practical with a policy change. But s= uch changes are up to individual node operators as they require no deviation= from consensus. Yet ultimately this is a miner preference, and anyone can m= ine. Finally, as I pointed out, burning is not necessary. Simply spending th= e coin as a fee is sufficient. > If an output is provably unspendable (burned) it is not a UTXO. >=20 > It is worth noting that not all full node implementations require a store o= f UTXOs, this is an implementation detail. For example, libbitcoin uses a fl= ag on each output to indicate its spentness on the strong branch. As such th= e store size is linear by height. >=20 >> This will of course be remedied by compact UTXO representations later, bu= t 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 wil= l take time to make possible, and would not be practical today. >>=20 >> Thus I think use of UTXO is better than burning or mining-fee-spending. >=20 > I don=E2=80=99t believe you have shown this. >=20 > Best, > Eric >=20 >> Also, mostly trivia: >> The use of UTXOs to advertise services is not original to me --- I found t= he LN channel gossip to be the inspiration for this. >> Publicly-announced channels indicate the backing UTXO that funds the chan= nel. >> The purpose of publicly announcing the channels is to be able to provide t= he service, of forwarding across the Lightning Network; thus the public anno= uncement 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 mecha= nism. >>=20 >> Regards, >> ZmnSCPxj