From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id A646AC000B; Thu, 10 Feb 2022 06:59:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 8706C4091A; Thu, 10 Feb 2022 06:59:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=petertodd.org header.b="r4wtyNR2"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="d+Bl2g0C" Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ghfed-tnv1uA; Thu, 10 Feb 2022 06:59:03 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by smtp4.osuosl.org (Postfix) with ESMTPS id 52C7C40917; Thu, 10 Feb 2022 06:59:03 +0000 (UTC) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 9C2085C010D; Thu, 10 Feb 2022 01:58:59 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 10 Feb 2022 01:58:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petertodd.org; h=cc:cc:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; bh=rh+0Hp5tDd2iqKF3XzD0mvH9g0Pedc k6+gS1eMnX0tk=; b=r4wtyNR277mZyYqV18w2ZGFyTFew70N7Yw87FRgZxe4FGK RTemP7dw6SWINqzgaXfnIhMHkVtOxAu6telFejajIqBXSzNUNzRXv6ppDaB8h6Lt tuIolTlXxLcgBHQQeE0ofmz6DNpYfkMOcGqxyJWK8vLlKz92irCtSZ/fk5l4Vu7l vBouFH4snHk6S/4VW7GVgRrf/4t59f70aOqcsaBnkFBcnDq1yHPLbnPWCN3/u7Ku YqRdlYChybt381NnmObCtm86mh6xBwoc4JkKwc3YTHnlekVtCi6K6B00lkGO8iP3 sjffQx5NCcJ0o4bfCo5dJRqQjWn7LnIViIMDeehw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=rh+0Hp5tDd2iqKF3X zD0mvH9g0Pedck6+gS1eMnX0tk=; b=d+Bl2g0CTESbHbTtXPGGjZiyK4jwiw8k3 OujEo0qXQ1sxHeRoKlHiL9NF9l+F1JLAo9T9jXzGmkAvBCh4as3Mlq48qknNFpI4 27lFMEwT0idSue4NiTn29MPTtoe2nrtd5uz6L72Ya9xcuCMOCfCb+tcWsQSRXb+L A01t251sJfhmzTUUIOnDonqJkcCfLKvk1hVqwMZGWLNnpjFSBOSpE2wjb6vLP7Vs 1l4Z9x/iDZB/EPMTvahyyl7+PpWqBThiwQ9DhCFnZCvfRHArTgqoa1lnzT2K9egi nGl4oDJC+Y44BjmgFW65DJ/o5Lg9/kFGrUFs5NyX06KedAbzT2DxQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddriedtgddutddtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre ertddtvdenucfhrhhomheprfgvthgvrhcuvfhougguuceophgvthgvsehpvghtvghrthho uggurdhorhhgqeenucggtffrrghtthgvrhhnpeeivddvleeikeejueekgfdtleefgeehhe elffeuheetgefhleevjeefleegvefffeenucffohhmrghinhepphgvthgvrhhtohguugdr ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hushgvrhesphgvthgvrhhtohguugdrohhrgh X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 10 Feb 2022 01:58:59 -0500 (EST) Received: by localhost (Postfix, from userid 1000) id 360CE5FB03; Thu, 10 Feb 2022 01:58:56 -0500 (EST) Date: Thu, 10 Feb 2022 01:58:56 -0500 From: Peter Todd To: Jeremy , Bitcoin Protocol Discussion Message-ID: References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="4n2c0ZHw8MhhzNdK" Content-Disposition: inline In-Reply-To: Cc: lightning-dev Subject: Re: [bitcoin-dev] [Pre-BIP] Fee Accounts 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: Thu, 10 Feb 2022 06:59:04 -0000 --4n2c0ZHw8MhhzNdK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev wrote: > Happy new years devs, >=20 > I figured I would share some thoughts for conceptual review that have been > bouncing around my head as an opportunity to clean up the fee paying > semantics in bitcoin "for good". The design space is very wide on the > approach I'll share, so below is just a sketch of how it could work which > I'm sure could be improved greatly. >=20 > Transaction fees are an integral part of bitcoin. >=20 > However, due to quirks of Bitcoin's transaction design, fees are a part of > the transactions that they occur in. >=20 > While this works in a "Bitcoin 1.0" world, where all transactions are > simple on-chain transfers, real world use of Bitcoin requires support for > things like Fee Bumping stuck transactions, DoS resistant Payment Channel= s, > and other long lived Smart Contracts that can't predict future fee rates. > Having the fees paid in band makes writing these contracts much more > difficult as you can't merely express the logic you want for the > transaction, but also the fees. >=20 > Previously, I proposed a special type of transaction called a "Sponsor" > which has some special consensus + mempool rules to allow arbitrarily > appending fees to a transaction to bump it up in the mempool. >=20 > As an alternative, we could establish an account system in Bitcoin as an > "extension block". > This type of design works really well for channels because the addition of > fees to e.g. a channel state does not require any sort of pre-planning > (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of > design is naturally immune to pinning issues since you could offer to pay= a > fee for any TXID and the number of fee adding offers does not need to be > restricted in the same way the descendant transactions would need to be. So it's important to recognize that fee accounts introduce their own kind of transaction pinning attacks: third parties would be able to attach arbitrary fees to any transaction without permission. This isn't necessarily a good thing: I don't want third parties to be able to grief my transaction engine= s by getting obsolete transactions confirmed in liu of the replacments I actually want confirmed. Eg a third party could mess up OpenTimestamps calendars at relatively low cost by delaying the mining of timestamp txs. Of course, there's an obvious way to fix this: allow transactions to design= ate a pubkey allowed to add further transaction fees if required. Which Bitcoin already has in two forms: Replace-by-Fee and Child Pays for Parent. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --4n2c0ZHw8MhhzNdK Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmIEt6oACgkQLly11TVR Lzc3dA//dFCCJJh1t/XchnJlTXr4iQrmQAUOEajUnXL/2kUAlBqJ2jvE3tXUg4Lh SB5jvs4EnC6phhrbphpWxso1v6XL3RGJUf60tUz0h/bO41DyOMGbVX82NtSNNfne z4qDeVKNKv/Wo9/lHAoSQvH/CrK7AajMqWOZk4Rvok00FLkKAAAvOxBlL+KkZKhL PYLMfvSXLoTMeiV1EjZZep8qDMh82VB5cOQIWYYiMhB+q0ebx7jpy6A/Z/pqwZfe NBh2P+Ryw/kCo1e4c/JBI4Cr8Bybl3VgcYdymDgpCyGd2Uldz2X/K3bKCpVaHNQI Sg9yPf+d9+d02y2gQfAVAH1+2sP540fkitkXBmLuwNRKwDifLjGqseZUdajwndGK ggSqfcXiH/y0WSzRDOOLW37Jg09q8nNjogreJ9AsqbbCHlf0phCTqtothdpTAV3u C0+ug/A6sWmGQm28iqYroV03nGIz3vHiMwtfsCIWUMphAS19puZN/cUFqqzE7My0 h/7GT6glhDd4Ybh27/LelhkjKQgtV1hjSBbBRIS1uitr7QyX93gJxYN1FvZYrhdJ 4KW6Ix4cruHqk1p3s3wjRy2444sEDwMHFGj4shFJZEyuinG8yoyzSayF0wxfsPaC xQSMikGWDRptt3jTwBivmKodFYDMHI3WoJskhLV3fWA6I5Ghp8I= =2YOz -----END PGP SIGNATURE----- --4n2c0ZHw8MhhzNdK--