Return-Path: <0100017f0eab2640-c7be81bb-c1c5-4150-a65a-cadd78a8258f-000000@amazonses.com> Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1D464C000B for ; Fri, 18 Feb 2022 21:09:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id EB82A41D8A for ; Fri, 18 Feb 2022 21:09:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 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, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=dtrt.org header.b="dn89ITo1"; dkim=pass (1024-bit key) header.d=amazonses.com header.b="BchODUql" 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 zyqjJUmLFJly for ; Fri, 18 Feb 2022 21:09:33 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from a48-24.smtp-out.amazonses.com (a48-24.smtp-out.amazonses.com [54.240.48.24]) by smtp4.osuosl.org (Postfix) with ESMTPS id 72B71409C0 for ; Fri, 18 Feb 2022 21:09:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=smjumfhvj4y563qynmbhq4si3vd5r74k; d=dtrt.org; t=1645218572; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:In-Reply-To; bh=PSwuBKYYhJ+uyrmyu9cg8gpsShlD4K4uv18Jz5EsJyI=; b=dn89ITo1FlVoKnJ/1RLSYwOP7qEYwR42C6qDxcRtBGdI4JJW9/DqShuqOhXOlPT3 qurLk1T1f5COJj/BH5u54gKR2Tu4QTAkRwy4sdfPy22FIqs67PwIUOQ0dzMciwMy/7k R87/UXN5Qk/kOS60ycJCw4sypS9SOAbkMhbtFrCA= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1645218572; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version:Content-Type:In-Reply-To:Feedback-ID; bh=PSwuBKYYhJ+uyrmyu9cg8gpsShlD4K4uv18Jz5EsJyI=; b=BchODUqlFnyvE5mD60FRskzNeK+cVLGivrptP6A5dZxoAbceipZl/MR8RWfMHHIX WH81+NuffrhYHThIagJaG0Z7EHowaDzlLsuvkApjpxpgvRTsddIir/WwOEnEFybB9lo bXzstOP8w4+GWXNbN4n5EVXo/EXAetjHy/BXIz1Y= Date: Fri, 18 Feb 2022 21:09:31 +0000 From: "David A. Harding" To: Jeremy Rubin , Bitcoin Protocol Discussion Message-ID: <0100017f0eab2640-c7be81bb-c1c5-4150-a65a-cadd78a8258f-000000@email.amazonses.com> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="t26uudckv2vwsfdz" Content-Disposition: inline In-Reply-To: Feedback-ID: 1.us-east-1.n0oE+7mPCT3oYHRtIkpRsZClsaxS9eYOjymWOETvbbI=:AmazonSES X-SES-Outgoing: 2022.02.18-54.240.48.24 Subject: [bitcoin-dev] Sponsor transaction engineering, was Re: Thoughts on fee bumping 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: Fri, 18 Feb 2022 21:09:36 -0000 --t26uudckv2vwsfdz Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Feb 15, 2022 at 01:37:43PM -0800, Jeremy Rubin via bitcoin-dev wrote: > Unfortunately, there are technical reasons for sponsors to not be monotone. > Mostly that it requires the maintenance of an additional permanent > TX-Index Alternatively, you could allow a miner to include a sponsor transaction in a later block than the sponsored transaction by providing an (SPV) merkle inclusion proof that the sponsored transaction was a part of a previous block on the same chain.[1] This does raise the vbyte cost of including sponsor and sponsored transactions in different blocks compared to including them both in the same block, but I wonder if it mitigates the validity concern raised by Suhas Daftuar in the previous sponsor transaction thread. -Dave [1] Bitcoin Core stores the complete headers chain, so it already has the information necessary to validate such a proof (and the `verifytxoutproof` RPC already does this). Utreexo-style nodes might not store old headers to save space, but I presume they could store a merkle-like commitment to all headers they previously validated and then have utreexo proofs include the necessary headers and intermediate hashes necessary to validate subsequent-block sponsor transactions. --t26uudckv2vwsfdz Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAmIQCuEACgkQ2dtBqWwi adOCcBAAvyzCAnIV4AF2UBe2k2UTF/nqzxod/2CCCC7mrS6iHPoRpvNPs9KtF3qV /1M6KPtiLmvafiewu4fUevkhH6+x4D75wKYhr1/KG2SbCP0G7MVshn1zbJxvgHZ4 OEMPH4/Ro/eyg/yaSmEvfgpbnGYpn5ysbDc3UKv8UAi2Stsnj+b74hGfcL835OfM MRkcUPoyO8tXe1esYBxgzANs52J4klCNF8ALNRmT6Z5Ig/VIE47ZiLDr0S1ZEo2q K46ZRZkiH5LZuYW7GfR7fnR06G33DKYfqgaG+f2O/P2XIMdxLTxTTeS+M+unncDS SDhkv1+U4NAWpkUOo3VZTr/KymYRaRA4t8Wc9FxKo5oAxrXqVwJmI/V1gvOsrY3N LAxz9jHwVteDTRW4v2bUIJHS6dpYhTe0DCBGSo4H3MjkqQ7wcRr45WQFKcEqdeI7 jzm5tOp6/5PYPhmWQzCg2NyRxoI0kDjQ9KAamzL4sLqUQp6GmaewBfsMyN3HKGfT Bs+G1Iv1nzjl6TqoH+xYKs0k+24WTE8XDkeWrl7wfm8x33p1n70s4kzyysKUGwn+ Tb0hM7nFutbcsKxUmgTCMg2FlZJnE+K4vHIGx4Xnh+ZE152jyvvxbOmlZhdEDIQc Pq0jvBhceWA4c2oQ6ZWBw2kjqJj9jYOZk0rLbYj5QLkDbh4FDJY= =NZQL -----END PGP SIGNATURE----- --t26uudckv2vwsfdz--