diff options
| author | Tamas Blummer <tamas.blummer@gmail.com> | 2019-07-09 22:32:53 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-07-09 20:33:04 +0000 |
| commit | 26a4819a915a6982cfc58e3cb656b3f9f32c5972 (patch) | |
| tree | 7bf22398a5d4d5b0442f955f1400fd7162523bfb | |
| parent | c74838713e5803e8a41f8903cc17fab08a9d977a (diff) | |
| download | pi-bitcoindev-26a4819a915a6982cfc58e3cb656b3f9f32c5972.tar.gz pi-bitcoindev-26a4819a915a6982cfc58e3cb656b3f9f32c5972.zip | |
Re: [bitcoin-dev] Generalized covenants with taproot enable riskless or risky lending, prevent credit inflation through fractional reserve
| -rw-r--r-- | e1/5e469350e100cdd938fcb698a2b14e0ea2eb58 | 321 |
1 files changed, 321 insertions, 0 deletions
diff --git a/e1/5e469350e100cdd938fcb698a2b14e0ea2eb58 b/e1/5e469350e100cdd938fcb698a2b14e0ea2eb58 new file mode 100644 index 000000000..ecf2780f9 --- /dev/null +++ b/e1/5e469350e100cdd938fcb698a2b14e0ea2eb58 @@ -0,0 +1,321 @@ +Return-Path: <tamas.blummer@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 66EBD3176 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 9 Jul 2019 20:33:03 +0000 (UTC) +Received: by mail-wr1-f65.google.com with SMTP id n4so185644wrs.3 + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <tamas.blummer@gmail.com> +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> + <B853EDF2-8A8A-44B0-A66E-F86175E61EDA@voskuil.org> + <4mT6iC4Va7Afg15a5NLbddAnF2a_vAcQSXYr_jg_5IyEK2ezblJff7EJZakoqvp4BJlLitt9Zlq1_l5JadR0nVss7VDPW-pv8jXGh7lkFC4=@protonmail.com> + <A1ADD0BB-F62F-47AF-B043-53BDF3A88CC3@voskuil.org> + <UyUISFwgh_-KtxpCJonltkqTvVbI9-NBukizE8tKSjB2V12otZiCWQ64sn8oqYk5NDftNHxW3koT9EPOWwVrOkXTP8Dqc-0W0wPGRK-wT34=@protonmail.com> + <0851B842-34A1-427F-95DC-A1D6AB416FB9@voskuil.org> + <8D68DC86-1173-43AC-BC84-FE2834741C13@gmail.com> + <B23C4FC6-2991-4C1B-8B8E-AAA06E9E578F@voskuil.org> + <501EFBBA-8A14-4B64-BD77-1ED5119154EA@gmail.com> + <gq9nEV2JWJaezWYf1OL_vXbqxrhmAKECd4fJ6vCHnXs-VAzK7fNIEJ5Ezd6LhzrxjZA3BdgWC3xZAEJY7ebNQ-QBF6URu29IdAXYgUOZhCM=@protonmail.com> +To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +In-Reply-To: <gq9nEV2JWJaezWYf1OL_vXbqxrhmAKECd4fJ6vCHnXs-VAzK7fNIEJ5Ezd6LhzrxjZA3BdgWC3xZAEJY7ebNQ-QBF6URu29IdAXYgUOZhCM=@protonmail.com> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 = +<bitcoin-dev@lists.linuxfoundation.org> 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-- + |