Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 66EBD3176 for ; Tue, 9 Jul 2019 20:33:04 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f65.google.com (mail-wr1-f65.google.com [209.85.221.65]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5889F67F for ; Tue, 9 Jul 2019 20:33:03 +0000 (UTC) Received: by mail-wr1-f65.google.com with SMTP id n4so185644wrs.3 for ; Tue, 09 Jul 2019 13:33:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=3CjjAlACKrw9ybe59muv8SUy7BNldtwkKYNo6QFY5Gw=; b=OHOfnUXfd1JXpGQV150/UJ//WDb73HMmt7bjegzYoGfeogXktNZHIITh2orBlMSBCR MHqoZ7HyD3gKIsf60+jkEdUYt9Tduqgkcm0QukH+4EE8YHb19GaPUZNWSwawISJ5WYe3 ByA+BZspWNMdqYWFRZjGddpdxY575jCNui4kGG3Ldkj9PCr7ParfoEXl+aJVnq5Lsqjs g71eUwqUDRlTa/y0dhMaR3xT/85r6gb2FQKfAgofFvCwr2H6Y2bPRaF1YiPJsENWJbzR erUXLiOkhCQZYbzGXY5FNPVG7q+N4pqyshNSvkTgm+ZayuZD18wPhIhSVZlSMxv9S6gF oMpA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=3CjjAlACKrw9ybe59muv8SUy7BNldtwkKYNo6QFY5Gw=; b=DO+7RVuXOy/RV1Ic1rghstf2a7IBe1jyGt16w6dJGzV3LpcC0L8N6A7euvL70OJ9XV vvcwwwJMUIBRGihGqU/aMMBVGYUh2mIHPzTp/FuvYyTjaumzQyXXv6kMsXEtQNbNpTT4 BD7aNjiU85aZG4sCWtbhoybde9lUiR0eoRTMnbDAuYn+ppKVfK4CAXRfXAqH+SDTJOmI +wRhpPaXAbLh0uZD95DGitsBeLIJn4tTg03gnFlDmzvGPYwslY+gyB9TUKFJPRLyxWKz QxDwIevxNilYzxJtwmDpAq94G8scKWNms3AeauY9G0CRFbZ21CnYtWvmovCFHHn1XRKF mp+w== X-Gm-Message-State: APjAAAWaMnZVfZyM2ui2M7bJ5wNCvpWH435wZdKvzg/VusUvDkqDjd3j t3SQvH7J4mJgbdvnkhGKUcia8+3s X-Google-Smtp-Source: APXvYqwctG3eKL5hqtUatyTbmT4rrc9D5sX4HamJ5tNNZp/mTYnthe7zU8pGLvgKg+Gpu811OnTrCg== X-Received: by 2002:adf:f883:: with SMTP id u3mr5300989wrp.0.1562704381912; Tue, 09 Jul 2019 13:33:01 -0700 (PDT) Received: from p200300dd67126451ecb5bf565b40e961.dip0.t-ipconnect.de (p200300DD67126451ECB5BF565B40E961.dip0.t-ipconnect.de. [2003:dd:6712:6451:ecb5:bf56:5b40:e961]) by smtp.gmail.com with ESMTPSA id x129sm21337wmg.44.2019.07.09.13.32.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Jul 2019 13:32:59 -0700 (PDT) From: Tamas Blummer Content-Type: multipart/signed; boundary="Apple-Mail=_3072EE67-B4DF-410F-9F9B-2674EE30BEAA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 9 Jul 2019 22:32:53 +0200 References: <0DBC0DEA-C999-4AEE-B2E1-D5337ECD9405@gmail.com> <4mT6iC4Va7Afg15a5NLbddAnF2a_vAcQSXYr_jg_5IyEK2ezblJff7EJZakoqvp4BJlLitt9Zlq1_l5JadR0nVss7VDPW-pv8jXGh7lkFC4=@protonmail.com> <0851B842-34A1-427F-95DC-A1D6AB416FB9@voskuil.org> <8D68DC86-1173-43AC-BC84-FE2834741C13@gmail.com> <501EFBBA-8A14-4B64-BD77-1ED5119154EA@gmail.com> To: ZmnSCPxj , Bitcoin Protocol Discussion In-Reply-To: Message-Id: <084E6C0D-9F4D-4E7A-8098-6951186B0EAA@gmail.com> X-Mailer: Apple Mail (2.3273) X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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: Tue, 09 Jul 2019 22:06:28 +0000 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: Tue, 09 Jul 2019 20:33:04 -0000 --Apple-Mail=_3072EE67-B4DF-410F-9F9B-2674EE30BEAA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Good morning ZmnSCPxj, thank you very much for sharing your BCAN idea and thought process in = detail. I add some thoughs that very likely occured to you, but not formulated = explicitelly: 1. The unique feature of such advertisement network is that it has no = owner, just like the Bitcoin network. If it had an owner, that owner could simply bill for use, but would also = be forced to restrict access or apply some sort of censorship. This is why usage costs is imposed through opportunity cost and not = billed. 2. Since opportunity cost of one Bitcoin for a short time period is = magnitudes less than its face value, one would need significant Bitcoin amounts to impose meaningful costs so they have the chance to be = included into BCANs purposedly limited bandwidth. Those who would want to place an ad will often not have sufficient = amount of Bitcoin holdings which lets them borrow UTXOs. 3. If borrowed Bitcoin is certain to be returned (as in your = construction) then this offers riskless interest for HODLer. 4. Bitcoin=E2=80=99s most popular use is storing wealth whereby this use = currently completely relies on the assumption that =E2=80=9Cthe number = goes up=E2=80=9D. A service that delivers interest on HODLed coins without exposing the = HODLer to credit risk of the borrower is a huge game changer. 5.This scheme allows HODLer a concious decision whom or what project = they fund. For above reasons I think that this is a crucial design pattern to build = censorship resistant networks which also give rise to riskless interest = on Bitcoin. My finance examples where abstract and less interesting for this = audience but the BCAN should ring the bell for many. As you said BCAN is possible with current Bitcoin, therefore we should = no longer discuss it under the covenant topic. The idea of debt covenant will likely resurface as soon as this design = pattern proves to be useful in practice and one is looking for a more flexible solution. I am confident we will get there, but not as = fast as I initially thought. Regards, Tamas Blummer > On Jul 9, 2019, at 12:31, ZmnSCPxj via bitcoin-dev = wrote: >=20 > Good morning all, >=20 > I will attempt to restart my thinking from initial principles = regarding my proposed "Bitcoin Classified Ads Network". >=20 > Nodes behave this way: >=20 > * Nodes in this network gossip advertisements. > * These advertisements refer to a UTXO that must be unspent at the = chain tip considered by each node, else they would be rejected. > * The referred UTXO must contain a commitment to the text of the = advertisement, else the advertisement is rejected. > * Nodes have a maximum limit on the total size of all advertisements = they retain and propagate to new nodes, or gossip to their peers. > This is a deliberate design decision. > * If nodes exceed the above limit, they will sort advertisements = according to a value-rate, the value of the UTXO divided by the storage = size of the advertisement, and prune advertisements with low value-rate = until they are within the limit again. > * Once the backing UTXO is spent, the advertisement is removed by = nodes that follow that chaintip. > * As the name ***Classified Ads*** suggests, each advertisement also = indicates a "class" in which they belong to. >=20 > Then, from the above, we derive how a seller might behave. >=20 > * Sellers will attempt to put the minimum possible value into a UTXO = committing to an advertisement, to reduce the opportunity cost of using = the value elsewhere. > * Thus the rent of the advertisement in this case is paid to = joinmarket makers and LN forwarding nodes, as the value used in a UTXO = backing an advertisement is not useable in joinmarket/LN. > * Sellers remain in full control of their advertising UTXO, and can = spend it at any time. > * Sellers may spend part of the UTXO and put the remaining funds into = a change address that is a new advertising UTXO, and re-transmit the = advertisement, this time pointing to the new change UTXO. > * However, if the remaining change becomes too low, then its = value-rate may drop below the lowest value-rate that BCAN nodes will = retain in their (deliberately limited) storage, thus also deleting their = advertisement from the BCAN. > * Presumably, the reason for advertising at all, is that the seller = considers the cost of advertising to be less than the expected gain of = actually selling their product. > * Thus, even if the seller has the ability to spend the UTXO at any = time, they run the risk of spending too much and thus removing their = advertisement from the BCAN, and losing the expected gain of having the = advertisement exist on the BCAN. > * A utility-maximizing seller would therefore not spend a = minimal-value UTXO backing the advertisement until it has gained the = advantage of actually selling the product, even if it has the option to = do so: it is a forced move. > * The cost of keeping the minimal-value UTXO unspent is the = opportunity cost in that the value may have been used in joinmarket or = LN instead. > * The minimum value will largely be dependent on how much the BCAN is = used; more sellers advertising over BCAN will increase the minimum = value. > * If the minimum value that is viable to keep its advertisement alive = goes higher, then the opportunity cost of the seller using the same = value elsewhere might exceed the expected gain from selling the product. > However, this is expected of *any* advertising scheme: if the gains = from selling is too small to justify the advertisement price, = advertising does not happen; this is expected utility-maximizing = behavior. > * If competitors of the seller exist and the BCAN node storage is = already filled, competitors can increase the minimum value of a UTXO = that can keep an advertisement alive on BCAN by simply adding more of = their advertisements to BCAN. > * Thus we expect that, once the BCAN node storage is at or near the = maximum value, the minimum value of a UTXO that can back an = advertisement will approach the expected gain from selling the product. >=20 > Thus the system of simply committing UTXOs to particular advertisement = texts seems sufficient to extract value from a seller wishing to = advertise. > The purpose of this extraction of value is to ensure that spam does = not overload the BCAN. >=20 > Let us now consider some kind of specialization, where a HODLer = specializes in owning UTXOs, while an advertiser specializes in trading = products that need advertising of some kind. >=20 > * We assume that the specialization means that the HODLer cannot = feasibly make and sell products on its own, while the advertiser cannot = own and control UTXOs of the minimum value needed to keep their = advertisement alive on the BCAN. > * We assume that the specialization means that the advertiser can make = and sell products for cheaper than the HODLer can, while the HODLer can = own and control (and secure) UTXOs of the minimum value needed for = advertisements to be kept alive, for cheaper than the advertiser can. >=20 > Then: >=20 > * A HODLer may offer to provide a UTXO locked by a 2-of-2 with a = commitment to an advertisement of the advertiser's choosing, in exchange = for rent of the value, plus an unbreakable promise to return the rented = UTXO value back to the HODLer (represented by a `nLockTime` pre-signed = transaction that returns the 2-of-2 back to the HODLer control). > * The HODLer is effectively lending the UTXO out to the advertiser, = for the time frame agreed upon by the advertiser. > * The rent at which the HODLer lends out the UTXO must be between the = opportunity cost of instead securely utilizing the UTXO in LN or = joinmarket, and the expected gain the advertiser expects from having its = product advertised. > * The HODLer is assumed to have the ability to secure the UTXO and = retain all data it needs to recover the UTXO; this is part of the = assumption that the HODLer specializes in such. > * The advertiser is assumed to have positive gains from creating, = advertising, and selling its product; this is part of the assumption = that the advertiser specializes in such. > * The HODLer and advertiser can agree to refund part of the rent, if = the advertiser signs a transaction that immediately returns control of = the value to the HODLer, before the agreed `nLockTime`. > * The above constructions can be done in current Bitcoin. > * However, the same constructions could be done with a covenant as = proposed by Tamas, possibly with reduced communication/coordination = costs between the advertiser and HODLer. >=20 > Now, there remains the question as to whether users will actually = patronize the BCAN instead of existing advertising systems. >=20 > * We assume that privacy is valuable to users. > * We assume that users of BCAN will run BCAN nodes. > This leaks them as users of BCAN, a small loss of privacy. >=20 > Then: >=20 > * Users can look for advertisements of specific classes by simply = querying their own BCAN node. > This does not leak privacy ata all as long as the communication = channel of the user with their own BCAN node is private. > * Compare this to alternatives, which involve some entity observing = the behavior of users and thus invading their privacy. > * Advertisers that misclassify their advertisements will be unable to = reach their target audience. > * Utility-maximizing advertisers will correctly indicate the class of = their advertisements, as otherwise they would be paying the advertising = cost without gaining the benefit of the advertisement. >=20 >=20 > Regards, > ZmnSCPxj > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --Apple-Mail=_3072EE67-B4DF-410F-9F9B-2674EE30BEAA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAl0k+fUACgkQ9nKRxRdx ORwbhggAqa50BGZ7WWVMUcdn/ruweVhVYta3//B6cfwAWCpAADvJefwGD9d2Pehh ucEgvf9q4b+Xla/gZ/JkyU9xaR3i/hjnO6A+PoBWrNn40M2u98MSRqJLODWyhxe3 ghvjbHGEt+yPLQM+EXMUKIL9ngc5mwZbfdBv5k8niybPsFkNkVICTeZYTVQWDbw1 DG+JZmRM9gMz6PaMAVo6gUnXKcdARBTVL7EdYR9B5pTZrKhJxd47USClpo1DHCWx I6u7maAnCotgKkhZbqOpZCYim6OTfGuH6GzMaoJAxz1Iw3/ddzBquP0md7BRVtyA 1eSxblpDYyHGmrnGf7pEKRX5kQcb8w== =nAYj -----END PGP SIGNATURE----- --Apple-Mail=_3072EE67-B4DF-410F-9F9B-2674EE30BEAA--