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 C9B41C58 for ; Thu, 4 Jul 2019 17:10:34 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f46.google.com (mail-wr1-f46.google.com [209.85.221.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F039487E for ; Thu, 4 Jul 2019 17:10:33 +0000 (UTC) Received: by mail-wr1-f46.google.com with SMTP id r1so1006710wrl.7 for ; Thu, 04 Jul 2019 10:10:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Xz8QpDw/QhVwgfcPamoCMsuoUHCgP4XxUuf5ML52PgE=; b=RUXusQNhMohVeOTifCTOsHJk6pIVbVtitYubrP4cWaLKtWl9ubVf8FWTlLjcnmoL97 ARoMoZQe9kmt8pQF9AedJfj9OuYvKhW6bljeMohLhMhyFy7UUvdv2yxOGrveuUTWgzNI y0DI2F5YGSprTUaU5S9rWqwZKMJu3S7pjHtP1Vauo+oSrE5RhMDfLX7Cb+L5A53tuTDS JuS13CoNeaFQYZYUS60hRpwixY5WsxnfKTK5vu0u9jqGmK5H/Yd4bHh9U0qQPztwH+SA qE4XruloLROvjhnscH8ibjDQuJEJns7P8YwJJ7EcGvbbR6jnjp7cVqTl1VYyTNVeOjPY uqsg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Xz8QpDw/QhVwgfcPamoCMsuoUHCgP4XxUuf5ML52PgE=; b=RjHDle8NW6GwLs54aGPFE+ZQZH5jQIPx22sOpJ1o2+GGggDXiGoEfDOIwtNxvDNq1X noifswsQ7qsWTBf8hG1CdamNAp0L7tn67BQi6zE2Mo5MHvUeAdWzdtKkvCMVDUNpWYg4 2NIg0xFy4v7JWx/D9MIwYvaOiHRlXCZxe0D42k6p3qgao1HS9H5wtwu/t3la8T6ej966 IUxSNJoD/R84MwjvdZqfDYWGwY6HhgnbN5Hdk4Ym37IfDqPWpd5vWLYo+wWWRCEkkdLH RdUlD2pb3+Xl893dIDrpGW9F5u/cNBpn1jqHHJXV4WYgDJ8/3q3+Wyx9iDvngq825RCu FMRw== X-Gm-Message-State: APjAAAX+CXODR5PYzb5d+hvCeEQFfs0l6VJDA/+CPleWcILafL6+K6Ww FU4NyHH9WKs2f8HULiyiEgU= X-Google-Smtp-Source: APXvYqyJW6x7wOV4BMlbDu8R2m7tM1MD3XHxULD3XrXtWWUTC/UL1LOa3y1QUuQqJb0ylBVqoqmkLQ== X-Received: by 2002:adf:f186:: with SMTP id h6mr17035303wro.274.1562260232499; Thu, 04 Jul 2019 10:10:32 -0700 (PDT) Received: from p200300dd67126444742440456c913622.dip0.t-ipconnect.de (p200300DD67126444742440456C913622.dip0.t-ipconnect.de. [2003:dd:6712:6444:7424:4045:6c91:3622]) by smtp.gmail.com with ESMTPSA id o6sm10744968wra.27.2019.07.04.10.10.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Jul 2019 10:10:31 -0700 (PDT) From: Tamas Blummer Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1C744C09-FE87-4ECA-8B9F-33DE9453B2B4"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Thu, 4 Jul 2019 19:10:31 +0200 In-Reply-To: To: Eric Voskuil 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> 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: Fri, 05 Jul 2019 13:53:35 +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 17:10:34 -0000 --Apple-Mail=_1C744C09-FE87-4ECA-8B9F-33DE9453B2B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Eric, there are some other ways to impose cost on use without direct billing, = e.g.: - Burn Bitcoins to use the service, as you mentioned. This could work = and would benefit remaining Bitcoin owner, but is unsustainable. - Pay high fees in self dealing transactions. This could work and would = benefit miner. - Time lock own Bitcoins. This is forgoing control of an UTXO for a time = period, 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 might not have substantial UTXO to imply high enough opportunity = cost. - Pay someone else to time lock. This is paying someone to lock an UTXO = for a time span. Payment and time lock could be combined in the same = transaction. - Transferable borrowed Bitcoin. This needs the covenant. This benefits = those who consciously give up control for a time span. Its advantage is = that since 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 period. Tamas Blummer > 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 = amount of encumbered coin is relevant to an external observer. Of course = the effective dust limit is the maximum necessary encumbrance otherwise. >=20 > In the case of simple tracking, the market value of the coin is not = relevant, all that is required is a valid output. Hence the devolution = to 1 sat tracking. In your scenario the objective is to establish a = meaningful cost for the output. >=20 > A community of people using this as a sort of hashcash spam protection = can raise the amount of encumbered coin (i.e. advertising threshold = price) required in that context. The cost of this encumberance includes = not only at least 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 encumbered coin, the same is achieved by burning .1 coin. In other = words the renter (advertiser) has actually paid to the coin owner .1 = coin to rent 1 coin for one year. >=20 > As with Bitcoin mining, it is the consumed cost that matters in this = scenario, (i.e., not the hash rate, or in this case the encumbered coin = face value). 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 sense to spend that coin in support of the secondary = network (e.g. paying for confirmation 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 for UTXOs that are only temporarily accessible to their current = owner. >>>=20 >>> Actually you have a single potentially-valid use case, the one I = have presented. The others I have shown to be invalid (apart from = scamming) and no additional information to demonstrate errors in my = conclusions have been offered. >>=20 >> I presented another use case, that of the "Bitcoin Classified Ads = Network". >> = https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-July/017083.h= tml >>=20 >> Advertisements are "backed" by an unspent TXO. >> In order to limit their local resource consumption, nodes of this = network will preferentially keep advertisements that are backed by = higher UTXO values divided by advertisement size, and drop those with = too low UTXO value divided by advertisement size. >>=20 >> Thus, spammers will either need to rent larger UTXO values for their = spam, 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 = does not simply devolve to "just burn a 1-satoshi output". >>=20 >> I still do not quite support generalized covenants as the use-case is = already possible on current Bitcoin (and given that with just a little = more transaction introspection this enables Turing-completeness), but = the basic concept of "renting a UTXO of substantial value" appears sound = to me. >>=20 >>=20 >> Regards, >> ZmnSCPxj --Apple-Mail=_1C744C09-FE87-4ECA-8B9F-33DE9453B2B4 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----- iQEzBAEBCgAdFiEE6YNJViYMM6Iv5f9e9nKRxRdxORwFAl0eMwcACgkQ9nKRxRdx ORyWQQf+MAc8plWrBW3s9aIko1UBre8YbfS3KDyTPNxWXRNLpOQoqopVv7PzSJwJ tIpocYQW4xVBHWfAwP+FKAfaNwn++5PsOgl0Qeh4IdfQKSsjSFZpSiCdxhj9OPHy /OcFieMb0uPENqawljAGJULZ1KeJsUWz8waSB1IVZ4grZg/6W/Lm2+SS2hyLXK9h 0mU8XwpFN5WybhpTbC8t8d7DoKWeaJYK97Rn84SyWKUne15caRgr6CKNmgq28tmY uKMxlxeeoTF040t9EO/gRY9GBMvMlR6oppUluu//aLeZJi9+oJ3GG/IvPHaqKW3G hDx3ivmTlkdZmKxTFRsirwG9JBI7VQ== =Sh+N -----END PGP SIGNATURE----- --Apple-Mail=_1C744C09-FE87-4ECA-8B9F-33DE9453B2B4--