Topic: Lightning Network over mempool using Replace By Fee (Read 241 times)

There's no such risk if you only act as sender, few wallet such as Eclair already adapt such method for mobile users who can't online 24/7.


I don't follow much about watchtower, but the idea of trust-less 3rd party watchtower seems interesting.

Depending on the usage, LN could be more efficient. LN isn't that complicated if you user-friendly software.


No, you could either :
1. Use watch tower (as mentioned by OP)
2. Only act as sender, so there's no risks of losing Bitcoin if another party broadcast earlier state of channel

What about the time window for penalty transactions though? Shouldn't the time window of one week for broadcasting a penalty transaction in case of a would-be attack be enough for someone who isn't online 24/7? Or has this been proven unreliable?

Just curious since with all the talk about Watchtowers this part of the protocol has been spoken less and less about.

Is it really necessary to be online 24/7?

OP, why don't you remove all the complicated stuff, and simply accept zero-confirm transactions? "Less risk", more simple, and I believe more effective for what you want.

Is OP trying to implement tx cut-through? It is closer to that idea than to LN...

1000 sat per kb is standart and not cheap depending on BTC price and on amound send

Yep. Timelocking a transaction only ensures that the timelocked transaction itself won't be accepted before the end of the timelock. You can still spend the very same coins in other transactions. That's why you can use them as part of a Dead Man's switch setup, for example.

Also, I wouldn't rely on the mempool alone to prevent double-spending. If that's all it took we wouldn't need a blockchain.

Also, mempools don't stick around forever. A timelocked transaction that's not being added to the blockchain, will get removed eventually. To make matters worse each mempool keeps transactions around for different timeframes. So the "channel state" will quicky diverge over time as mempools diverge.

Come to think of it, I'm not even sure whether a not-yet-spendable timelocked transaction is guarantueed to stick around the mempool in the first place.

I don't think so. As far as I know, you can invalidate a timelock transaction if you spend one of its inputs before the timelock. It shouldn't be considered as a double-spend attempt.


I still don't get why you would need Bob as an intermediary to prove it. The only comparison that comes to my mind is a payment processor but you still didn't mention any reward for him.

It is possible right now. You can send any transaction using 1 satoshi per byte fee and no one will stop you from spamming the network with such transactions right now. Sooner or later, mempool will reach maximum capacity and then we should have some kind of mechanism to decrease this load. If we have RBF transactions in such overloaded mempool, we can provably replace two or more transactions with one equivalent transaction without worrying about possible double spending.

The network will see Alice->Bob transaction earlier than Alice->Daniel transaction and reject the second one as a double-spending attempt. A node should know all replaced transactions before doing a replacement, because it is needed to prove that it is not a double-spending attempt.

It is needed as a proof that Alice->Charlie transaction is not a double-spending attempt, because Alice->Bob transaction was transmitted earlier.

Instead of decreasing the load on the blockchain, you are increasing the load on the nodes and the network.


Imagine tens of thousands of such or longer chains in the mempool. Who's going to have enough memory to store all of them to ensure that none of them is dropped?


Let's say Alice wants to buy something from Charlie. Once Charlie receives the timelocked transaction from Bob, he sends Alice what she ordered. What prevents Alice from spending one of the inputs of the timelocked transaction before it is included in any block?


What about Bob's transaction and what's the point of including him in the chain if Alice in the end sends the payment directly to Charlie? Since you got rid of the concept of channels then there shouldn't be any need of third-parties for payment routing.

Now we need two transactions: first to open a channel and second to close it. We can get rid of it if all transactions will be transmitted to the network. These transactions will have low sequence number (RBF enabled) and will have lock time in the future. Instead of opening the channel, Alice will send her transaction to Bob. She will be sure that no miner will include it before locktime. When Bob will see a transaction from Alice in mempool, he can send it to Charlie in the same way. Then, we will see a chain of such transactions in mempool: Alice->Bob->Charlie. All of these transactions will have RBF enabled, so Alice can create transaction sending her coins directly to Charlie (given these two transactions as a proof any miner can see it is not a double-spending attempt and accept such replacement). She has incentive to do that, because all such transactions have to contain at least minimal fee 1 satoshi/byte to be relayed over the network. One combined transaction always will be smaller than two separate transactions, so Alice can set a bit higher fee and still get some satoshi as a reward. Miners will also have incentive to accept that, because in this way they can include more transactions in the same block getting a bit higher satoshi per byte reward.

As a result, we can reduce everything into one transaction, sending all funds to all parties. I also thought about reducing it to zero transactions, but miners probably would still want to get some fee for accepting transaction replacements and that is why at least one transaction would be necessary. This idea also eliminates the need for being online 24/7 and creating watchtowers, as all channels' state will be publicly available.