В 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. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev