Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3198AC0029 for ; Mon, 5 Jun 2023 07:58:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id EB76D60C03 for ; Mon, 5 Jun 2023 07:58:24 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org EB76D60C03 Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.a=rsa-sha256 header.s=20221208 header.b=LWlwUitw X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DIET_1=0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 EEWH_a51Sx_d for ; Mon, 5 Jun 2023 07:58:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 0B3EC6079E Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) by smtp3.osuosl.org (Postfix) with ESMTPS id 0B3EC6079E for ; Mon, 5 Jun 2023 07:58:23 +0000 (UTC) Received: by mail-ej1-x630.google.com with SMTP id a640c23a62f3a-9700219be87so706445766b.1 for ; Mon, 05 Jun 2023 00:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685951902; x=1688543902; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=adglgTbPJsCjazExnLMNRDMzQnLCq3fzGpiBCBDZOxE=; b=LWlwUitwIYglAHlar7P7fHaqLXc0fpxoQT3mcySZ4ddfUa+enPmnpGgc1ehYK6osaD ebNkvA5OCqM0Om1rggiBpIs0494d9VwlEB7fFXRimJQzJp1KTO2YMLjU/PNTQzAToxe9 IRYx5hQjQMrnpn3i5ahd4geJR5zwi4qUNHkYI00B2QyJaCdh+qRDbUNlE1gGbrCZJ2sx qevv0o1R6JZ236It1oosNuaMwIdT3Sh2IM41zgz0Vj8lqFcZRqo8SoPCRvDwDM1U+SUn FxBZX77YnNqtMr8lksDAUo4QHYJ5oy4czmNhCv4MD+sQI11ZtKMagZkrEmdwvUonsn14 V4xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685951902; x=1688543902; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=adglgTbPJsCjazExnLMNRDMzQnLCq3fzGpiBCBDZOxE=; b=Y6zm7nyfiASBnXLbTQfJnd2BZKM3GOR9smi2QbBLedx5CSZRnugxJZ7D1Y7uL9WkAK C1EqDFgWem47xReZRoNA5JVZr2og+qSUjzEGNix6eDG1o8US3nbKAY8iOjM0OHfIckr/ 2QtGC8l2cubipIzuBF1jBnAKRG7x/cwwvGeFtT2P8ziC1eQvVKN0zjmr0Kgwf2iMshJq 3S4qsIfuaJiPzVBmQu72DsEBiBIuEBfgeGnFVDvpbUWz2KKxIU3+8Pg2A+hJODeeQAX5 T2COYczh/VjW1qbM614QOomyzdRTDL4mVr3or2Ox8jFXArooQakICsVSQxxuFteyUoPn plYg== X-Gm-Message-State: AC+VfDxTaitHPQ+1pzGeCULVOQDbZvEZ+mybxBl03b4EpRAQLowDKw9B DyTfb/FwCK5msqCupF1Ox/P13iyANlMJm0CMKoYG5Ld3ENI= X-Google-Smtp-Source: ACHHUZ7MQGo8eX2lTN8PUi/VHyFyFp0U1AUxUy6povjvN8L0YaE7N6ldweFbqKOxBphlBCy79SdqnwQK/Ep2F2EKU3o= X-Received: by 2002:a17:907:97d3:b0:96a:928c:d391 with SMTP id js19-20020a17090797d300b0096a928cd391mr6508719ejc.4.1685951902075; Mon, 05 Jun 2023 00:58:22 -0700 (PDT) MIME-Version: 1.0 From: Joost Jager Date: Mon, 5 Jun 2023 09:57:46 +0200 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000003b506a05fd5d44c9" X-Mailman-Approved-At: Mon, 05 Jun 2023 09:46:44 +0000 Subject: [bitcoin-dev] Conceptual package relay using taproot annex 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, 05 Jun 2023 07:58:25 -0000 --0000000000003b506a05fd5d44c9 Content-Type: text/plain; charset="UTF-8" Hi, Before starting, I would like to state that I do not necessarily support the implementation of the idea I'm about to present, but I think it's worth mentioning as it might inspire different use cases or provoke some debate. I believe that out-of-band relay is a more preferable and efficient way to get transaction packages to miners while p2p package relay is under development. Let's consider the situation where we have a parent transaction A that pays 0 sat/b (for example a lightning commitment transaction), and a fee bumping child transaction B. These transactions currently cannot reach miners. We can, however, conceive a workaround. Let's introduce a third transaction C, crafted to contain the raw transactions A and B in a taproot annex. A commit/reveal style inscription could also be used instead, but I think it would be more complicated and less efficient. To ensure propagation, transaction C would pay sufficient fees. Also it would use at least one of the same fee contributing inputs as transaction B, but obviously not any inputs from A. Miners, upon receiving transaction C, could detect the embedded transactions A and B in the annex and immediately submit them to their mempool as a transaction package. This transaction package (A+B) would then replace transaction C and could be included in a block for mining. It's of course important to ensure that the combined package of A+B is more attractive to miners than the C transaction. The extra weight of the embedded transactions in C helps with this. Also it is worth noting that the fees for C will never be paid because it has been replaced. Thus there are no extra costs for using this package relay scheme, unless perhaps the weight of A+B is very low and B needs to pay a higher fee rate than necessary to ensure replacement of C. If not all miners adopt this incentive-compatible replacement, there's a chance transaction C ends up being mined. This is likely less probable if the fee rate for C is kept to a minimum. If transaction C is indeed mined, the operation can be retried with a modified B and C, though the fees paid for the initial transaction C would be forfeited. Joost --0000000000003b506a05fd5d44c9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Before starting, I would like to state that I d= o not necessarily support the implementation of the idea I'm about to p= resent, but I think it's worth mentioning as it might inspire different= use cases or provoke some debate. I believe that out-of-band relay is a mo= re preferable and efficient way to get transaction packages to miners while= p2p package relay is under development.

Let's consider the situ= ation where we have a parent transaction A that pays 0 sat/b (for example a= lightning commitment transaction), and a fee bumping child transaction B. = These transactions currently cannot reach miners.

We can, however, c= onceive a workaround. Let's introduce a third transaction C, crafted to= contain the raw transactions A and B in a taproot annex. A commit/reveal s= tyle inscription could also be used instead, but I think it would be more c= omplicated and less efficient.

To ensure propagation, transaction C = would pay sufficient fees. Also it would use at least one of the same fee c= ontributing inputs as transaction B, but obviously not any inputs from A.
Miners, upon receiving transaction C, could detect the embedded trans= actions A and B in the annex and immediately submit them to their mempool a= s a transaction package. This transaction package (A+B) would then replace = transaction C and could be included in a block for mining.

It's of course important to ensure that the combined package of A+B = is more attractive to miners than the C transaction. The extra weight of th= e embedded transactions in C helps with this. Also it is worth noting that = the fees for C will never be paid because it has been replaced. Thus there = are no extra costs for using this package relay scheme, unless perhaps the = weight of A+B is very low and B needs to pay a higher fee rate than necessa= ry to ensure replacement of C.

If not all miners adopt this incentiv= e-compatible replacement, there's a chance transaction C ends up being = mined. This is likely less probable if the fee rate for C is kept to a mini= mum. If transaction C is indeed mined, the operation can be retried with a = modified B and C, though the fees paid for the initial transaction C would = be forfeited.

Joost
--0000000000003b506a05fd5d44c9--