From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 289D1C000E for ; Sun, 4 Jul 2021 20:33:38 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 172F160772 for ; Sun, 4 Jul 2021 20:33:38 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_XBL=0.375, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=dtrt.org Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-gKkMKtCOYP for ; Sun, 4 Jul 2021 20:33:34 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from newmail.dtrt.org (newmail.dtrt.org [IPv6:2600:3c03::f03c:91ff:fe7b:78d1]) by smtp3.osuosl.org (Postfix) with ESMTPS id 42C6F606B3 for ; Sun, 4 Jul 2021 20:33:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dtrt.org; s=20201208; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=jM2jaZtq06h3hlzNOWVW9m0rY1O/HE6qdOz3L8KDBC8=; b=ykKryiJoQvypGU56vcKN7xtkso tI1Dc90pbFAwCa8pR7PmAiU5O86kZBOzKwn/AlYt4o8V/edbM0/DhqsVXBnwwAUj0/mIHRj1LynRH 2SNkMOXXivTZfLs2FhqlaGcfbkq3S2tYY4gqXW6CfNLE1YL0x7fRLczuvndJyKKCuHLQ=; Received: from harding by newmail.dtrt.org with local (Exim 4.92) (envelope-from ) id 1m08nz-00082d-VY; Sun, 04 Jul 2021 10:33:31 -1000 Date: Sun, 4 Jul 2021 10:32:30 -1000 From: "David A. Harding" To: Jeremy Message-ID: <20210704203230.37hlpdyzr4aijiet@ganymede> References: <20210704011341.ddbiruuomqovrjn6@ganymede> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="h447b6zg7llrlobu" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Cc: Bitcoin Protocol Discussion Subject: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Jul 2021 20:33:38 -0000 --h447b6zg7llrlobu Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 04, 2021 at 11:39:44AM -0700, Jeremy wrote: > However, I think the broader community is unconvinced by the cost benefit > of arbitrary covenants. See > https://medium.com/block-digest-mempool/my-worries-about-too-generalized-= covenants-5eff33affbb6 > as a recent example. Therefore as a critical part of building consensus on > various techniques I've worked to emphasize that specific additions do not > entail risk of accidentally introducing more than was bargained for to > respect the concerns of others. Respecting the concerns of others doesn't require lobotomizing useful tools. Being respectful can also be accomplished by politely showing that their concerns are unfounded (or at least less severe than they thought). This is almost always the better course IMO---it takes much more effort to satisfy additional engineering constraints (and prove to reviewers that you've done so!) than it does to simply discuss those concerns with reasonable stakeholders. As a demonstration, let's look at the concerns from Shinobi's post linked above: They seem to be worried that some Bitcoin users will choose to accept coins that can't subsequently be fungibily mixed with other bitcoins. But that's already been the case for a decade: users can accept altcoins that are non-fungible with bitcoins. They talk about covenants where spending is controlled by governments, but that seems to me exactly like China's CBDC trial. They talk about exchanges depositing users' BTC into a covenant, but=20 that's just a variation on the classic not-your-keys-not-your-bitcoins problem. For all you know, your local exchange is keeping most of its BTC balance commitments in ETH or USDT. To me, it seems like the worst-case problems Shinobi describes with covenants are some of the same problems that already exist with altcoins. I don't see how recursive covenants could make any of those problems worse, and so I don't see any point in limiting Bitcoin's flexibility to avoid those problems when there are so many interesting and useful things that unlimited covenants could do. -Dave --h447b6zg7llrlobu Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAmDiGt4ACgkQ2dtBqWwi adN2sA//Tthdw29Al05YUOdEHO+rN6FSOTefixFiNqyoEY3Xr9uAm+fixgisySTG wriSOA1tBwsDW8S0ImOAQD4/SO5UjCWlcDT2m5/w4wAeesb7FbOf7JzB2L30iT2D FICXRIVjumdjMC5q4abYcBgZvTHoq+6EXjKxz3lRy+MZLzeTxaC2JxjGefPVXroU 4KuKoC59F7d7LnghV//WHjXFNnTGNB/PvmCj8eFMvsfphnhZ2GYD7HMSmcvF1IEw vuWASlFUJ9bPDyBs/vHtGtkeHcHVFdoF2IaKz4yHZKUwC/pG9gT6wx9RkHmRRcfJ 5AzNvox5LGq+6MNWu1pNWQNa/n3h57t7h9oz7pDvBymOw17Cb2/yXk4lpQiBF01p 9Cj1K/WD1CClvIwPW/egY9kyMlt1zSqoBatm5fDOPR7PuCcGJfPXuqW8oFSTKxyq OFvtupHSeMK90s2OdBWwC0eww2ypmI9zA6mICDUcnnN7P2twoK4Dy4RcBAB4SUx7 EXhptp5UQIQgZhVGc/supbj8s3gs/P77oXOai6s5L5gopuYfA+g3ptkk70tuHLkj kJ98W/Kn3sx1XWAUhlpwJbXrCrxWqFO5FAx6nMBPcoI4/uHQZUvqfKwe8K/GX5x1 kqTBx2IUKgQbGqysiUspAe5+URJVulNL4yfttgc8dTxMx1JNcVs= =ycKN -----END PGP SIGNATURE----- --h447b6zg7llrlobu--