Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 624E1C000E for ; Mon, 26 Jul 2021 00:07:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 3CD0A6075A for ; Mon, 26 Jul 2021 00:07:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.325 X-Spam-Level: X-Spam-Status: No, score=-0.325 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 8upHRWfCjQ6Y for ; Mon, 26 Jul 2021 00:07:33 +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 64B2F60758 for ; Mon, 26 Jul 2021 00:07: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=3DMPkIZnqxzzK+d0lEzyRXKHQFgpptrCx/eXA8GT9+o=; b=xUWV7Lawje2zX0eb7Tn2t+6Mz0 nHg/UHow8DcIe6xLDJJmSgt9hMwOBLfhuoUrZ9V1vdyGUJLRdU5g0gm0J1z7DRSb0wR0O0jF2fqOo ViJQnJVMOayGBNifHRjnTg5j3W6rk7Fl1Tox8wjDHgRe32YKI0gJcX3/pir8gKa3cS94=; Received: from harding by newmail.dtrt.org with local (Exim 4.92) (envelope-from ) id 1m7o9b-0007Ky-5h; Sun, 25 Jul 2021 14:07:31 -1000 Date: Sun, 25 Jul 2021 14:05:53 -1000 From: "David A. Harding" To: Billy Tetrud Message-ID: <20210726000553.tetqypkqj34lcztt@ganymede> References: <20210725053803.fnmd6etv3f7x3u3p@ganymede> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="oyagbh26st2doxhg" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] Covenant opcode proposal OP_CONSTRAINDESTINATION (an alternative to OP_CTV) 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: Mon, 26 Jul 2021 00:07:36 -0000 --oyagbh26st2doxhg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Jul 25, 2021 at 12:49:38PM -0700, Billy Tetrud wrote: > find the median fee-rate for each block and store that, then calculate > the average of those stored per-block median numbers.=20 One datapoint per block seems fine to me and it works much nicer with pruned nodes. > So the only situations where miners would gain something > from raising the fee rate is for griefing situations, which should be so > rare as to be completely insignificant to miners.=20 I don't believe the problem scope can be reduced this way. Although we we often look at miners as separate from users, it's important to remember that every miner is also a user of Bitcoin and ever user of Bitcoin may also someday be a miner. Users may also employ miners directly via out-of-band payments. In your usecase of vaults, we can imagine Bob is attempting to store 100,000 BTC. He designs his vault to allow spending on fees up to 10x the 3,000 block median fee. Mallory steals Bob's encumbered spending key. Mallory could immediately go to a miner and offer them a 50/50 split on the 10x fees over the median (~10,000 sat?), or Mallory could take a bit more time and work with a cartel of miners to raise the median over a period of three weeks (3k blocks) to 10,000 BTC/transaction, allowing them to take all of Bob's coins in fees. > if OP_CD allowed spending the entire output as a fee then it wouldn't > be successful in constraining the destination to the listed addresses. The alternative is to never allow OP_CD to spend any of the UTXOs it encumbers to fees, requiring all fees be paid via another mechanism. Since satisfactory designs are going to provide those other mechanisms anyway, it seems to me that there's no need for OP_CD to manage fees. That said, I don't have a real strong opinion here. -Dave --oyagbh26st2doxhg Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAmD9/GEACgkQ2dtBqWwi adMwGhAAugZMKkBNombyZ9r988g3PAwTthR6Lim5ahPJLWw4w1NnfHtVMKGcXYTE hvR2YyNr0AkDyG/tV8z8mIDKprAJWyCYeXeLn3woQ8WNAKAOwatMPQWML9/PjhzI qriktmY6npuGSFAtzFWUGSyDxx3NArz5FyeHDDC9tmdBivlcVcyoNb2PZ31/P0U0 eLMuIHt983fZG98osiAEGSPg8DwbDa+YQKSY9HCXOC7yd4xoV/IpVdX8kXdMohKg 8q0Qslwi4OeUYKSQ6e6orVEhWBnzJ0f9qq/CDdBOfCAuQ/z1MD2dYqlk7lg7eq0K sMtG+L71yUJKni7hkaKgf74XdOUVG4Y9x0upHFTEIj3khHImbGRWlpyrRoh50uOH w87zzEi3M+qu5jaE4anGtzPHiKt5Xl+WPjKVnxdZSw6d5I57y26IEDuSudHleqgr O/X0FHz80++xQUknQNVbspMhDbZFz9+pXzAyAuYnGlEreVnXp0IuBxJG77AkcgPA LKDuS6/bgLLMBb7awUDEJN6bOUsi1JyofaX1G4ogktAHYZ1AhCK0hyp/QtgSXPxd do4Gy+bMK95lMWJpv5Kj3qbd2rnYltUby+X9c16Tn6HwRkLDFCZ/yO0mqLT4/fT4 4XziOAbS43M9CuHCQq5qGJ9sEvfirf8FPrTaCIle3BUQf3nY0Dg= =3CiL -----END PGP SIGNATURE----- --oyagbh26st2doxhg--