pull down to refresh

then I miss the point of this all. why chain two transactions A->B->C if in the end you just pay a higher total fee that paying directly from A to C?
It's for use in protocols where you have to create a transaction at time A but it might not be broadcasted til time B, and you don't know what fees will be at time B
These feeless transactions allow you to set a fee of 0 on the transaction at time A and then select the appropriate fee at time B by making a child transaction
You might wonder "why not just wait til time B to make your transaction and give it an appropriate fee then, i.e. when you actually want to broadcast it, instead of making a second transaction that pays the real fee"
But this isn't always feasible. For example, watchtowers on the lightning network don't have the private keys necessary to write the transaction for you -- they can just hang onto a transaction you wrote weeks or months ago and broadcast it if it becomes necessary.
But perhaps the transaction you wrote weeks or months ago used a feerate that is too low to get mined when the watchtower broadcasts it. This new protocol allows you to set a fee of 0 and then the watchtower can pay the fees for you by pairing your 0 fee transaction with a transaction of their own. (And they'd presumably charge you a monthly fee to cover the cost of doing so.)
So this helps with any protocol that makes use of watchtowers (lightning and statechains come to mind) but it also helps with any protocol where (1) you create a transaction at time A (2) you can't predict what fees will be at time B (3) you can't rewrite the transaction at time B (4) but you, or someone else, can "bump" the fee with a child transaction
reply
ok, thanks. maybe some idea along these lines will help avoid FCs due to disagreements about the commitment fee between different implementations. will keep an eye.
reply