Date: Thu, 9 Dec 2021 08:50:33 -0500
From: Peter Todd <pete@petertodd.org>
To: darosior <darosior@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <YbIJqX+oK6hio4C3@petertodd.org>
References: <hBx6OYA5Mv9C_anoMQ-s-9l_XNwNFPfDVmOND9pXBJEBi7qsULF3bgPGpagtqjOsKDTXu8iOTVzvOjflz-M6EfnfwVH81Cu-nnai0kakouo=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="gTOQlUl3d0imVUeI"
Content-Disposition: inline
In-Reply-To: <hBx6OYA5Mv9C_anoMQ-s-9l_XNwNFPfDVmOND9pXBJEBi7qsULF3bgPGpagtqjOsKDTXu8iOTVzvOjflz-M6EfnfwVH81Cu-nnai0kakouo=@protonmail.com>
Subject: Re: [bitcoin-dev] A fee-bumping model
Precedence: list


--gTOQlUl3d0imVUeI
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Nov 29, 2021 at 02:27:23PM +0000, darosior via bitcoin-dev wrote:
> ## 2. Problem statement
>=20
> For any delegated vault, ensure the confirmation of a Cancel transaction =
in a configured number of
> blocks at any point. In so doing, minimize the overpayments and the UTxO =
set footprint. Overpayments
> increase the burden on the watchtower operator by increasing the required=
 frequency of refills of the
> fee-bumping wallet, which is already the worst user experience. You are l=
ikely to manage a number of
> UTxOs with your number of vaults, which comes at a cost for you as well a=
s everyone running a full
> node.
>=20
> Note that this assumes miners are economically rationale, are incentivize=
d by *public* fees and that
> you have a way to propagate your fee-bumped transaction to them. We also =
don't consider the block
> space bounds.
>=20
> In the previous paragraph and the following text, "vault" can generally b=
e replaced with "offchain
> contract".

For this section I think it'd help if you re-wrote it mathematically in ter=
ms
of probabilities, variance, and costs. It's impossible to ensure confirmati=
on
with 100% probability, so obviously we can start by asking what is the cost=
 of
failing to get a confirmation by the deadline?

Now suppose that cost is X. Note how the lowest _variance_ approach would b=
e to
pay a fee of X immediately: that would get us the highest possible probabil=
ity
of securing a confirmation prior to the deadline, without paying more than =
that
confirmation is worth.

Of course, this is silly! So the next step is to trade off some variance -
higher probability of failure - for lower expected cost. A trivial way to do
that could be to just bump the fee linearly between now and that deadline. =
That
lowers expected cost. But does increase the probability of failure. We can =
of
course account for this in an expected cost.


One final nuance here is if this whole process is visible in the UI we might
want to take into account user discomfort: if I know the process could fail,
the user will probably be happier if it succeeds quickly, even if the
probability of success in the future is still very high.


FWIW the approach taken by the OpenTimestamps calendars is a trivial linear
increase. While they don't have deadlines in the same sense as your
application, there is a trade-off between cost and confirmation time. So our
strategy is to spend money at a constant rate by simply bumping the fee by =
the
same amount at every new block. I could improve this by using knowledge of =
the
mempool. But so far I haven't bothered.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--gTOQlUl3d0imVUeI
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmGyCacACgkQLly11TVR
LzfgpA//Um5FKs6Oath2qfE4xjLc3DSVietzZ/EgmorZMtB6wHqiKbrxdGzMibks
c1t0MdOccd5eg01AsiMv5Ms0CL6HIAN1O2J8OmBORb9vcvz9DvL1gzwnQWYhhsCD
OSPeSq5TCjw9J6HwR02KPspvFlIfYdjU+S3gydQt740DgfKJ5jHLdMvr847G+ChQ
782aeH/jrRic7WLsEQ8BHxTWGNICqAui/7tQFugu1jCt+p2O8Gg/advksQ6dao0o
i63UHdMZsElr8DcNQgglQ8x47Yu/2DfVpjKRRkWILWbG4PrE7RtFIhANHgwgREGE
7R8XfNy9aL/9vd9UgmrAKvDIp9lxyU3Sk0RpmkFcng8t7DvwwOI0NSMq4WiBTYHA
8emwgiFZHajK4lqh7sGdT5FkChn9gOJlAbLDF3+txiWyob9pVq20Be7JapXhmuxd
UlH4lp+xD0SUa+xQExnxF2BTKFwGIS26RWUtoPIZxKWHVB5bXXT43iHJdvCzLJMw
oRoHH7J6UEWJe9DStt9/iXXgZ4iI3G0IaMpkuYi9zxmxA57NE3RGLt2nZNkINNY8
Um/pC3JlLdwAwMZkcqB2wuKwRF0r4CR3Cw1Y1bFMbB9x2XC66RgTHkOdc5Bc1WYV
jVpmKdb5w8F2aPFuepfd7aIDw7f5BgJAvssFhj7+88COXwAYLAk=
=tdsx
-----END PGP SIGNATURE-----

--gTOQlUl3d0imVUeI--