pull down to refresh
14 sats \ 4 replies \ @SwapMarket 12 Dec \ on: Zero Fee Playground: A New Toy by Super Testnet bitcoin
How long do zero fee payments hang out in the waiting room? Is this mempool or some other place? If mempool and long, won't attacs bloat it?
How long do zero fee payments hang out in the waiting room?
They don't normally spend any time waiting at all. The transaction that takes them out of the waiting room must be broadcasted together with the transaction that puts them in there; by default, they are relayed together and mined together, so the moment a UTXO enters a waiting room, it also leaves it. This is enforced by a standardness rule, so you could only make a tx wait in the waiting room by bribing a miner to keep it there for longer than it's supposed to be, e.g. using an out-of-band payment.
Is [the waiting room] mempool or some other place?
The waiting room is not the mempool, it is not part of zero fee transactions generally, it is just something I made for this demo page. I chose to send money from address_1, which is the address displayed in step 1, to address_2, which is a random address generated by the demo software to show that the money can really go anywhere in a zero fee transaction, and then to address_3, which is an address chosen by the user during step 2. I decided to call address_2 "the waiting room" for purposes of the demo, just so it could have a name, but perhaps that was a mistake. Several people have expressed confusion about it, and in fact no time is spent waiting there. I don't know what else I shoulld call it. Suggestions welcome!
If mempool and long, won't attacs bloat it?
It's not mempool, it's there for no time at all, and it's just something I made up for use in this demo, it's not part of the zero fee transactions protocol (though it is one of the things devs can do with this protocol, because I did it).
reply
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?
reply
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