Date: Tue, 18 May 2021 13:10:12 +0000
To: Prayank <prayank@tutanota.de>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <0e_yUTTdaV57Dxzome846NEUsmp2MmrY19-7OWHGyNw0g5IKwkfTR3jN4xLLYNgy_PMya1BkutZLmfZEdsYyARFHM3zp5qZ_eH1DvefS8uw=@protonmail.com>
In-Reply-To: <M_eKbLz--N-2@tutanota.de>
References: <M_eKbLz--N-2@tutanota.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fee estimates and RBF
Precedence: list

Good morning Prayank,

>  But it will involve lot of exception handling.


Yes, that is precisely the problem here.

If you select a fixed feerate and then just broadcast-and-forget, you have =
no real exceptions you have to handle --- but that means not using RBF at a=
ll.


Testing the handling of reorgs in particular is important, as a reorg might=
 use an older version of an RBFed transaction rather than a newer version.
This also implies that further follow-up transactions might need to be recr=
eated in such a case.

As this is financial code, we need a lot of testing, and code that has a lo=
t of branches due to having to handle a lot of possible exceptions and so f=
orth is a headache to completely cover in testing.


C-lightning supposedly supports RBF, in the sense that every transaction it=
 makes always signals RBF, but I am almost certain there are edge cases whe=
re it might mishandle a replaced transaction and lose track of onchain fund=
s, and it is difficult to support both "we can spend unconfirmed change out=
puts" (a very common feature of nearly every onchain wallet) with "we can c=
hange the feerate of unconfirmed transactions" (which changes the txid and =
therefore the UTXO id of the change output spent by use of the previous fea=
ture).

Regards,
ZmnSCPxj