From: Dmitry Petukhov <dp@simplexum•com>
To: Jeremy via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY
Date: Mon, 8 Jun 2020 11:05:45 +0500 [thread overview]
Message-ID: <20200608110545.078f8e81@simplexum.com> (raw)
In-Reply-To: <CAD5xwhhZyAkQE3DpLku_xrOnixL344AqkWB=+a=fOBbekobY6g@mail.gmail.com>
В 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.
next prev parent reply other threads:[~2020-06-08 6:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-26 1:50 Jeremy
2019-11-27 21:32 ` Russell O'Connor
2019-11-28 19:59 ` Jeremy
2019-12-11 0:37 ` Jeremy
2019-12-13 23:06 ` Jeremy
2019-12-19 20:08 ` Jeremy
[not found] ` <20191214122546.5e72eb93@simplexum.com>
[not found] ` <CAD5xwhgwhOwuPjKz-0_y7HP=jTi=6wJo8uH6HqCvOndr6wo0+Q@mail.gmail.com>
2020-02-14 11:18 ` Dmitry Petukhov
2020-02-14 19:16 ` Jeremy
2020-09-03 14:42 ` Dmitry Petukhov
2020-09-03 17:34 ` Jeremy
2020-09-03 17:47 ` Jeremy
2020-02-15 0:24 ` ZmnSCPxj
2020-06-07 16:51 ` Joachim Strömbergson
2020-06-07 22:45 ` Jeremy
2020-06-08 6:05 ` Dmitry Petukhov [this message]
2020-06-08 6:43 ` [bitcoin-dev] [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping Operation Jeremy
2020-06-08 7:15 ` Dmitry Petukhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200608110545.078f8e81@simplexum.com \
--to=dp@simplexum$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox