📅 Original date posted:2020-09-22
📝 Original message:Hi,
I think the topic of how to improve transaction relay policy and fee
bumping is an important one that needs to be worked on, so I'm glad
this is a topic of discussion. However I am pretty skeptical of this
consensus change proposal:
The Sponsor Vector TXIDs must also be in the block the transaction is
> validated in, with no restriction on order or on specifying a TXID more
> than once.
That means that if a transaction is confirmed in a block without its
sponsor, the sponsor is no longer valid. This breaks a design principle
that has been discussed many times over the years, which is that once a
valid transaction is created, it should not become invalid later on unless
the inputs are double-spent. This principle has some logical consequences
that we've come to accept, such as transaction chains being valid across
small reorgs in the absence of malicious (double-spend) behavior.
I think that this principle is a useful one and that there should be a high
bar for doing away with it. And it seems to me that this proposal doesn't
clear that bar -- the fee bumping improvement that this proposal aims at is
really coming from the policy change, rather than the consensus change. But
if policy changes are the direction we're going to solve these problems, we
could instead just propose new policy rules for the existing types of
transaction chaining that we have, rather than couple them to a new
transaction type.
My understanding of the main benefit of this approach is that this allows
3rd parties to participate in fee bumping. But that behavior strikes me as
also problematic, because it introduces the possibility of 3rd party
griefing, to the extent that sponsor transactions in any way limit chains
of transactions that would be otherwise permitted. If Alice sends Bob some
coins, and Alice and Bob are both honest and cooperating, Mallory shouldn't
be able to interfere with their low-feerate transaction by (eg) pinning it
with a large transaction that "sponsors" it (ie a large transaction that is
just above the feerate of the parent, which prevents additional child
transactions and makes it more expensive to RBF).
This last issue of pinning could be improved in this proposal by requiring
that a sponsor transaction bring the effective feerate of its package up to
something which should be confirmed soon (rather than just being a higher
feerate than the tx it is sponsoring). However, we could also carve out a
policy rule just like that today, without any consensus changes needed, to
help with pinning (which is probably a good idea! I think this would be
useful work). So I don't think that approaches in that direction would be
unique to this proposal.
We allow one Sponsor to replace another subject to normal replacement
> policies, they are treated as conflicts.
This policy rule of allowing sponsor transactions to RBF each other also
seems problematic; that means that if Alice is paying Bob in a transaction
that is also sponsoring some other transaction (perhaps from Alice to
someone else), then Mallory can cause the transaction going to Bob to
become invalid by RBF bumping it and sponsoring the parent transaction
herself? Allowing 3rd parties to interfere with transactions between
others seems like a complex and undesirable design to introduce.
In summary: this proposal seems like a CPFP replacement, requiring many
policy rules along with a consensus change to be worked out to get right; I
think we could achieve largely the same effect by improving the current
policy rules to make CPFP work better without a consensus change. And
while what is unique about this proposal is that it allows for 3rd parties
to attach themselves to the transaction graph of other parties, I think
that is a complex interaction to introduce and has negative side effects as
well.
On Mon, Sep 21, 2020 at 12:27 PM Jeremy via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Responses Inline:
>
> Would it make sense that, instead of sponsor vectors
>> pointing to txids, they point to input outpoints? E.g.:
>>
>> 1. Alice and Bob open a channel with funding transaction 0123...cdef,
>> output 0.
>>
>> 2. After a bunch of state updates, Alice unilaterally broadcasts a
>> commitment transaction, which has a minimal fee.
>>
>> 3. Bob doesn't immediately care whether or not Alice tried to close the
>> channel in the latest state---he just wants the commitment
>> transaction confirmed so that he either gets his money directly or he
>> can send any necessary penalty transactions. So Bob broadcasts a
>> sponsor transaction with a vector of 0123...cdef:0
>>
>> 4. Miners can include that sponsor transaction in any block that has a
>> transaction with an input of 0123...cdef:0. Otherwise the sponsor
>> transaction is consensus invalid.
>>
>> (Note: alternatively, sponsor vectors could point to either txids OR
>> input outpoints. This complicates the serialization of the vector but
>> seems otherwise fine to me.)
>>
>
> *This seems like a fine suggestion and I think addresses Antoine's issue.*
>
>
> *I think there are likely some cases where you do want TXID and not Output
> (e.g., if you *
>
> *are sponsoring a payment to your locktime'd cold storage wallet (no CPFP)
> from an untrusted third party (no RBF), they can grift you into paying for
> an unrelated payment). This isn't a concern when the root utxo is multisig
> & you are a participant.*
>
> *The serialization to support both, while slightly more complicated, can
> be done in a manner that permits future extensibility as well if there are
> other modes people require.*
>
>
>
>>
>> > If we want to solve the hard cases of pinning, I still think mempool
>> > acceptance of a whole package only on the merits of feerate is the
>> easiest
>> > solution to reason on.
>>
>> I don't think package relay based only on feerate solves RBF transaction
>> pinning (and maybe also doesn't solve ancestor/dependent limit pinning).
>> Though, certainly, package relay has the major advantage over this
>> proposal (IMO) in that it doesn't require any consensus changes.
>> Package relay is also very nice for fixing other protocol rough edges
>> that are needed anyway.
>>
>> -Dave
>>
>
> *I think it's important to keep in mind this is not a rival to package
> relay; I think you also want package relay in addition to this, as they
> solve different but related problems.*
>
>
> *Where you might be able to simplify package relay with sponsors is by
> doing a sponsor-only package relay, which is always limited to 2
> transactions, 1 sponsor, 1 sponsoree. This would not have some of the
> challenges with arbitrary-package package-relay, and would (at least from a
> ux perspective) allow users to successfully get parents with insufficient
> fee into the mempool.*
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200922/56a6fd2c/attachment-0001.html>;
Suhas Daftuar [ARCHIVE] /
npub1ss…e0am4
2023-06-07 18:26:58
in reply to nevent1q…j3tz
Author Public Key
npub1ss2s89s938xfh3zzz0j2mhp25tlrlcrj0duljr0ne0t8v2r4cv0q5e0am4Published at
2023-06-07 18:26:58Event JSON
{
"id": "6299b6a37aa0abdb3e6035a64bc91720b83031c0f26eb6d773a8f6d3ec8f3a40",
"pubkey": "841503960589cc9bc44213e4addc2aa2fe3fe0727b79f90df3cbd6762875c31e",
"created_at": 1686162418,
"kind": 1,
"tags": [
[
"e",
"1b4df37278c7c2a4fee5a73c5a031392dece7559564b05e4a74d333e2954add3",
"",
"root"
],
[
"e",
"0f861a8a0d673e8c334eafae9a5f3e3b6831aa67ab38d89355d927747391ac90",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "📅 Original date posted:2020-09-22\n📝 Original message:Hi,\n\nI think the topic of how to improve transaction relay policy and fee\nbumping is an important one that needs to be worked on, so I'm glad\nthis is a topic of discussion. However I am pretty skeptical of this\nconsensus change proposal:\n\nThe Sponsor Vector TXIDs must also be in the block the transaction is\n\u003e validated in, with no restriction on order or on specifying a TXID more\n\u003e than once.\n\n\nThat means that if a transaction is confirmed in a block without its\nsponsor, the sponsor is no longer valid. This breaks a design principle\nthat has been discussed many times over the years, which is that once a\nvalid transaction is created, it should not become invalid later on unless\nthe inputs are double-spent. This principle has some logical consequences\nthat we've come to accept, such as transaction chains being valid across\nsmall reorgs in the absence of malicious (double-spend) behavior.\n\nI think that this principle is a useful one and that there should be a high\nbar for doing away with it. And it seems to me that this proposal doesn't\nclear that bar -- the fee bumping improvement that this proposal aims at is\nreally coming from the policy change, rather than the consensus change. But\nif policy changes are the direction we're going to solve these problems, we\ncould instead just propose new policy rules for the existing types of\ntransaction chaining that we have, rather than couple them to a new\ntransaction type.\n\nMy understanding of the main benefit of this approach is that this allows\n3rd parties to participate in fee bumping. But that behavior strikes me as\nalso problematic, because it introduces the possibility of 3rd party\ngriefing, to the extent that sponsor transactions in any way limit chains\nof transactions that would be otherwise permitted. If Alice sends Bob some\ncoins, and Alice and Bob are both honest and cooperating, Mallory shouldn't\nbe able to interfere with their low-feerate transaction by (eg) pinning it\nwith a large transaction that \"sponsors\" it (ie a large transaction that is\njust above the feerate of the parent, which prevents additional child\ntransactions and makes it more expensive to RBF).\n\nThis last issue of pinning could be improved in this proposal by requiring\nthat a sponsor transaction bring the effective feerate of its package up to\nsomething which should be confirmed soon (rather than just being a higher\nfeerate than the tx it is sponsoring). However, we could also carve out a\npolicy rule just like that today, without any consensus changes needed, to\nhelp with pinning (which is probably a good idea! I think this would be\nuseful work). So I don't think that approaches in that direction would be\nunique to this proposal.\n\nWe allow one Sponsor to replace another subject to normal replacement\n\u003e policies, they are treated as conflicts.\n\n\nThis policy rule of allowing sponsor transactions to RBF each other also\nseems problematic; that means that if Alice is paying Bob in a transaction\nthat is also sponsoring some other transaction (perhaps from Alice to\nsomeone else), then Mallory can cause the transaction going to Bob to\nbecome invalid by RBF bumping it and sponsoring the parent transaction\nherself? Allowing 3rd parties to interfere with transactions between\nothers seems like a complex and undesirable design to introduce.\n\nIn summary: this proposal seems like a CPFP replacement, requiring many\npolicy rules along with a consensus change to be worked out to get right; I\nthink we could achieve largely the same effect by improving the current\npolicy rules to make CPFP work better without a consensus change. And\nwhile what is unique about this proposal is that it allows for 3rd parties\nto attach themselves to the transaction graph of other parties, I think\nthat is a complex interaction to introduce and has negative side effects as\nwell.\n\n\n\nOn Mon, Sep 21, 2020 at 12:27 PM Jeremy via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Responses Inline:\n\u003e\n\u003e Would it make sense that, instead of sponsor vectors\n\u003e\u003e pointing to txids, they point to input outpoints? E.g.:\n\u003e\u003e\n\u003e\u003e 1. Alice and Bob open a channel with funding transaction 0123...cdef,\n\u003e\u003e output 0.\n\u003e\u003e\n\u003e\u003e 2. After a bunch of state updates, Alice unilaterally broadcasts a\n\u003e\u003e commitment transaction, which has a minimal fee.\n\u003e\u003e\n\u003e\u003e 3. Bob doesn't immediately care whether or not Alice tried to close the\n\u003e\u003e channel in the latest state---he just wants the commitment\n\u003e\u003e transaction confirmed so that he either gets his money directly or he\n\u003e\u003e can send any necessary penalty transactions. So Bob broadcasts a\n\u003e\u003e sponsor transaction with a vector of 0123...cdef:0\n\u003e\u003e\n\u003e\u003e 4. Miners can include that sponsor transaction in any block that has a\n\u003e\u003e transaction with an input of 0123...cdef:0. Otherwise the sponsor\n\u003e\u003e transaction is consensus invalid.\n\u003e\u003e\n\u003e\u003e (Note: alternatively, sponsor vectors could point to either txids OR\n\u003e\u003e input outpoints. This complicates the serialization of the vector but\n\u003e\u003e seems otherwise fine to me.)\n\u003e\u003e\n\u003e\n\u003e *This seems like a fine suggestion and I think addresses Antoine's issue.*\n\u003e\n\u003e\n\u003e *I think there are likely some cases where you do want TXID and not Output\n\u003e (e.g., if you *\n\u003e\n\u003e *are sponsoring a payment to your locktime'd cold storage wallet (no CPFP)\n\u003e from an untrusted third party (no RBF), they can grift you into paying for\n\u003e an unrelated payment). This isn't a concern when the root utxo is multisig\n\u003e \u0026 you are a participant.*\n\u003e\n\u003e *The serialization to support both, while slightly more complicated, can\n\u003e be done in a manner that permits future extensibility as well if there are\n\u003e other modes people require.*\n\u003e\n\u003e\n\u003e\n\u003e\u003e\n\u003e\u003e \u003e If we want to solve the hard cases of pinning, I still think mempool\n\u003e\u003e \u003e acceptance of a whole package only on the merits of feerate is the\n\u003e\u003e easiest\n\u003e\u003e \u003e solution to reason on.\n\u003e\u003e\n\u003e\u003e I don't think package relay based only on feerate solves RBF transaction\n\u003e\u003e pinning (and maybe also doesn't solve ancestor/dependent limit pinning).\n\u003e\u003e Though, certainly, package relay has the major advantage over this\n\u003e\u003e proposal (IMO) in that it doesn't require any consensus changes.\n\u003e\u003e Package relay is also very nice for fixing other protocol rough edges\n\u003e\u003e that are needed anyway.\n\u003e\u003e\n\u003e\u003e -Dave\n\u003e\u003e\n\u003e\n\u003e *I think it's important to keep in mind this is not a rival to package\n\u003e relay; I think you also want package relay in addition to this, as they\n\u003e solve different but related problems.*\n\u003e\n\u003e\n\u003e *Where you might be able to simplify package relay with sponsors is by\n\u003e doing a sponsor-only package relay, which is always limited to 2\n\u003e transactions, 1 sponsor, 1 sponsoree. This would not have some of the\n\u003e challenges with arbitrary-package package-relay, and would (at least from a\n\u003e ux perspective) allow users to successfully get parents with insufficient\n\u003e fee into the mempool.*\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200922/56a6fd2c/attachment-0001.html\u003e",
"sig": "5ed042744192c64f96220fd6ce751ea0b34bf19ceeffde2b1cf48531405260412e151119a756d5cdf93c6197bce0c85603bbed0c6d94bc6c60aed812e1f171f0"
}