Joost Jager [ARCHIVE] on Nostr: 📅 Original date posted:2023-06-05 🗒️ Summary of this message: The author ...
📅 Original date posted:2023-06-05
🗒️ Summary of this message: The author suggests using out-of-band relay as a more efficient way to get transaction packages to miners while p2p package relay is under development.
📝 Original message:
Hi,
Before starting, I would like to state that I do not necessarily support
the implementation of the idea I'm about to present, but I think it's worth
mentioning as it might inspire different use cases or provoke some debate.
I believe that out-of-band relay is a more preferable and efficient way to
get transaction packages to miners while p2p package relay is under
development.
Let's consider the situation where we have a parent transaction A that pays
0 sat/b (for example a lightning commitment transaction), and a fee bumping
child transaction B. These transactions currently cannot reach miners.
We can, however, conceive a workaround. Let's introduce a third transaction
C, crafted to contain the raw transactions A and B in a taproot annex. A
commit/reveal style inscription could also be used instead, but I think it
would be more complicated and less efficient.
To ensure propagation, transaction C would pay sufficient fees. Also it
would use at least one of the same fee contributing inputs as transaction
B, but obviously not any inputs from A.
Miners, upon receiving transaction C, could detect the embedded
transactions A and B in the annex and immediately submit them to their
mempool as a transaction package. This transaction package (A+B) would then
replace transaction C and could be included in a block for mining.
It's of course important to ensure that the combined package of A+B is more
attractive to miners than the C transaction. The extra weight of the
embedded transactions in C helps with this. Also it is worth noting that
the fees for C will never be paid because it has been replaced. Thus there
are no extra costs for using this package relay scheme, unless perhaps the
weight of A+B is very low and B needs to pay a higher fee rate than
necessary to ensure replacement of C.
If not all miners adopt this incentive-compatible replacement, there's a
chance transaction C ends up being mined. This is likely less probable if
the fee rate for C is kept to a minimum. If transaction C is indeed mined,
the operation can be retried with a modified B and C, though the fees paid
for the initial transaction C would be forfeited.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230605/0468684e/attachment.html>;
🗒️ Summary of this message: The author suggests using out-of-band relay as a more efficient way to get transaction packages to miners while p2p package relay is under development.
📝 Original message:
Hi,
Before starting, I would like to state that I do not necessarily support
the implementation of the idea I'm about to present, but I think it's worth
mentioning as it might inspire different use cases or provoke some debate.
I believe that out-of-band relay is a more preferable and efficient way to
get transaction packages to miners while p2p package relay is under
development.
Let's consider the situation where we have a parent transaction A that pays
0 sat/b (for example a lightning commitment transaction), and a fee bumping
child transaction B. These transactions currently cannot reach miners.
We can, however, conceive a workaround. Let's introduce a third transaction
C, crafted to contain the raw transactions A and B in a taproot annex. A
commit/reveal style inscription could also be used instead, but I think it
would be more complicated and less efficient.
To ensure propagation, transaction C would pay sufficient fees. Also it
would use at least one of the same fee contributing inputs as transaction
B, but obviously not any inputs from A.
Miners, upon receiving transaction C, could detect the embedded
transactions A and B in the annex and immediately submit them to their
mempool as a transaction package. This transaction package (A+B) would then
replace transaction C and could be included in a block for mining.
It's of course important to ensure that the combined package of A+B is more
attractive to miners than the C transaction. The extra weight of the
embedded transactions in C helps with this. Also it is worth noting that
the fees for C will never be paid because it has been replaced. Thus there
are no extra costs for using this package relay scheme, unless perhaps the
weight of A+B is very low and B needs to pay a higher fee rate than
necessary to ensure replacement of C.
If not all miners adopt this incentive-compatible replacement, there's a
chance transaction C ends up being mined. This is likely less probable if
the fee rate for C is kept to a minimum. If transaction C is indeed mined,
the operation can be retried with a modified B and C, though the fees paid
for the initial transaction C would be forfeited.
Joost
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230605/0468684e/attachment.html>;