Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 7F75CC002D for ; Sun, 11 Dec 2022 20:24:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 4460E60BDA for ; Sun, 11 Dec 2022 20:24:13 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 4460E60BDA Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=gap600.com header.i=@gap600.com header.a=rsa-sha256 header.s=google header.b=L0ybJAoW X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, 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 8EFzLn5QdB6D for ; Sun, 11 Dec 2022 20:24:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 2D73A60A93 Received: from mail-il1-x130.google.com (mail-il1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) by smtp3.osuosl.org (Postfix) with ESMTPS id 2D73A60A93 for ; Sun, 11 Dec 2022 20:24:12 +0000 (UTC) Received: by mail-il1-x130.google.com with SMTP id y2so2493622ily.5 for ; Sun, 11 Dec 2022 12:24:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gap600.com; s=google; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=It7p3XJfIUfUObx/iQINgMhs1gzLGC+bMf3IYmWRL8A=; b=L0ybJAoWxGBF1CFFSuJueRNoqUydPT64ZLMMOc5ZIVRus1b/bxtQVV5Hp3DJ4J/xVn J7mlG/CqzcWL/WtkqtQxnlGqe5BlpDjTzEZIYNPZzme5pOuuLOoVNg/Ac+utK/eMWwiw a+cw5g66U/KV3W9AeA6ZdEJZlckUrbjwq9KCAwE2UUxZyb2T0DtZZHNfti4EIyks0m/O vp8d6mGG0K6U8T48tkXsXxyovut5xsgMHvpm1dkE2ftsCsFjxPz1oma0viUbYM3A3oDg sBVdlJSaSQsu7jrgi22yB9fi0d5aFa93tMXpKy4sVlFKziU2zehGlhM1r3haYbePEJTg KClw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=It7p3XJfIUfUObx/iQINgMhs1gzLGC+bMf3IYmWRL8A=; b=aj66N7ToRDpoXD3WknZzNbywYgJ2Lnx8EdPH7GP5K5tmprtoQQk7i2c894YyC8vDA3 lcf8VSXbwcN1FX/Jp+I0XZaj+3PiJ0hQhK9woJqg9sZgKrkwiyRRts5Hqc4QDoK24Qox RYCv4usjkHlCdVcJv1HEkl3zFkzdm07GVm+J1EfGf7m/PG82u5kMmzpt+runEHaO1e5G QxZrG/X0w4jpOpyWHygvrrMq0ccYKpSM5IqibKtgmM0sgA4NP8d5pA7ChoE0t0woJPf8 iO0mr0PWMvQAlyo7BBEzTo+efEPGj8iXBiItnxmPe5Ja59fpEXWO5btJNfGYsRqz2mwC Q7qA== X-Gm-Message-State: ANoB5pkMKqYiEkNz5AxZA4ej0TzQxPWpRJHiiJTIImilQjKxEHuB07oq W4uezguxALzAOrmavew+CmcJmTfFW/l6OnuZ85hQeE2Cj/u8XbDQ X-Google-Smtp-Source: AA0mqf5FzsYFOep8vf5YX9K+1LWWptr8sDAIy7SUy4vQ6eYB/dkTWywVEoiP5YeOUsiCBf8STKlqESnHbvo5WXdrZ2w= X-Received: by 2002:a92:c68a:0:b0:304:b728:fe19 with SMTP id o10-20020a92c68a000000b00304b728fe19mr131909ilg.204.1670790250826; Sun, 11 Dec 2022 12:24:10 -0800 (PST) MIME-Version: 1.0 From: Daniel Lipshitz Date: Sun, 11 Dec 2022 22:24:00 +0200 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000065295005ef932b89" X-Mailman-Approved-At: Mon, 12 Dec 2022 22:58:35 +0000 Subject: [bitcoin-dev] A proposal for Full RBF to not exclude Zero Conf use case 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, 11 Dec 2022 20:24:13 -0000 --00000000000065295005ef932b89 Content-Type: text/plain; charset="UTF-8" Intro Currently there is a significant use case of 0-Conf acceptance of transactions. Merchants and service providers are fully aware of the risks related to 0-conf. Full RBF if it would be significantly enabled would most likely make 0-conf not possible and significantly limit this current use case. A primary motivation for full RBF is to enable an increase of fee of trxs and enable faster acceptance in Block should it be required. Motivation To enable full RBF adoption without this impeding the 0-conf use case. This can be done by enabling the primary use of case full RBF i.e increase the fee, while keeping the outputs of TRX1 to be included within TRX2. Method TRX1 is the trx first published and held in Mempool, TRX2 is the trx which comes to replace TRX1. In order for a TRX2 to replace TRX1 in the Mempool it will require the following - 1. Outputs (addresses and amounts) are the same TRX1 and TRX2 Or - 2. TRX2 Outputs include Outputs of TRX1 i.e TRX2 has additional Outputs to TRX1 Both cases would require the addition of at least one Input in order to increase the fee. In such a case 0-conf acceptance of TRX1 will result in a harmless double spend since TRX1 will not be included in the valid UTXO set; however the address beneficiaries of TRX1 will still be credited by TRX2. This rule would enable the increasing of network fees post publication of trx without the loss of 0-conf use case. Drawbacks Does require access to another Input inorder to take advantage of Full RBF. Summary Access to OptinRBF and FullRBF(with above limitation) would give actors full access to increasing fees as an option. The 0-conf whose risks are very much understood in the market can continue to exist as is, with the 0-conf ongoing choices being continuing to be available to actors. ________________________________ Daniel Lipshitz GAP600| www.gap600.com Phone: +44 113 4900 117 Skype: daniellipshitz123 Twitter: @daniellipshitz --00000000000065295005ef932b89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Intro
Currently there is a significant=C2= =A0use case of 0-Conf acceptance of transactions. Merchants and service pro= viders are fully aware of the risks related to 0-conf. Full RBF if it would= be significantly enabled would most likely make 0-conf not possible and si= gnificantly=C2=A0limit this current=C2=A0use case. A primary motivation for= full RBF is to enable an increase of fee of trxs and enable faster=C2=A0ac= ceptance in Block should it be required.

MotivationTo enable full RBF adoption without this impeding=C2=A0the 0-conf use case= . This can be done by enabling the primary use of case full RBF i.e increas= e the fee, while keeping the outputs of TRX1 to be included within TRX2.

Method
TRX1 is the trx first published and= held in Mempool, TRX2 is the trx which comes to replace TRX1.=C2=A0
<= div>
In order for a TRX2 to=C2=A0 replace TRX1 in the Mempool= it will require the following=C2=A0
  • 1. Outputs (addresse= s and amounts) are the same TRX1 and TRX2
Or
    =
  • 2. TRX2 Outputs include Outputs of TRX1 i.e TRX2 has additional Outputs= to TRX1
Both cases would r= equire the addition of at least one Input in order to increase the fee.=C2= =A0

In such a case 0-conf acceptance of TRX1 = will result in a harmless double spend since TRX1 will not be included in t= he valid UTXO set; however the=C2=A0address beneficiaries of TRX1 will stil= l be credited by TRX2.
This rule would enable= the increasing of network fees post publication of trx without the loss of= 0-conf use case.

Drawbacks=C2=A0
Does require access to another Input= inorder to take advantage of Full RBF.=C2=A0


Summary
A= ccess to OptinRBF and FullRBF(with above limitation) would give actors full= access to increasing fees as an option. The 0-conf whose risks are very mu= ch understood in the market can continue to exist as is, with the 0-conf on= going choices being continuing to be available to actors.
______________= __________________


Daniel Lipshitz
GAP600|=C2= =A0www.gap600.com<= /font>
Phone:=C2=A0+44 113 4900 117
Skype: dani= ellipshitz123
= Twitter: @daniellipshitz
--00000000000065295005ef932b89--