Date: Mon, 8 Jun 2020 11:05:45 +0500
From: Dmitry Petukhov <dp@simplexum.com>
To: Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200608110545.078f8e81@simplexum.com>
In-Reply-To: <CAD5xwhhZyAkQE3DpLku_xrOnixL344AqkWB=+a=fOBbekobY6g@mail.gmail.com>
References: <CAD5xwhjXidpeLLUr4TO30t7U3z_zUxTpU9GBpLxu3MWX3ZFeTA@mail.gmail.com>
 <1cQUGt1pX0_lWPJm-tFDr9fQCvrPd5vqmCorgN89jy7gUF0m9wsouUosrFm1eal3jO9oB1BvMtORGE2htLdFjyDD5lno_QkXCFn971LQNZY=@protonmail.com>
 <CAD5xwhhZyAkQE3DpLku_xrOnixL344AqkWB=+a=fOBbekobY6g@mail.gmail.com>
Organization: simplexum.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY
Precedence: list

=D0=92 Sun, 7 Jun 2020 15:45:16 -0700
Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:

> What I think we'll eventually land on is a way of doing a tx
> that contributes fee to another tx chain as a passive observer to
> them. While this breaks one abstraction around how dependencies
> between transactions are processed, it also could help resolve some
> really difficult challenges we face with application-DoS (pinning and
> other attacks) in the mempool beyond CTV. I have a napkin design for
> how this could work, but nothing quite ready to share yet.

I had an idea of 'Pay for neighbor' transaction where a transaction
that is not directly a child of some other transaction can specify that
it wants to pay the fee for that other transaction(s). It can become
like 'ghost child' transaction for them, in what it cannot be mined
unless its 'ghost parents' are confirmed, too. It will be like CPFP,
but without direct dependency via inputs. Such 'PFN' transaction would
not spend any coins beside what it specifies in its own inputs, of
course.

The idea required a hardfork at first, but Anthony Towns suggested
a way to make it into a soft fork (past-taproot) by putting the txids of
'ghost parents' into taproot annex.

PFN transaction would still be valid if some of 'ghost parents' are
already confirmed, so the miners could have more fees than strictly
necessary. But this is the same as with CPFP.

Looking at the mempool code, it seems that only a way how parent/child
transactions relationships are established will need to be adjusted to
account for this 'ghost relationships', and once established, other
logic will work as with CPFP. There could be complications regarding
transaction package size. But I cannot claim that I understand that
code enough to say something about this with certainty.