pull down to refresh
21 sats \ 0 replies \ @BallLightning OP 23 Mar \ parent \ on: Why is a sweep transaction needed when force closing lightning
WTF? This totally doesn't answer my question at all.
Well, it's as much a toll for self-defense as a tool for attack. I guess if you defend you want stronger tool than the attacker. And if you are an attacker you want a stronger tool than the defender. So it's kind of an arms race.
Predicting the future is kind of the function of intelligence itself. So im a sense everybody can somewhat "see" the future.
Just a note for everybody here who just finished their CS education and is afraid of floating point numbers. If you want to implement floating point transaction values as in 2., you need to make custom implementations that handle it appropriately by using integers. You shouldn't use the inbuilt float or double types.
The increase of divisibility causing increase in supply argument is completely factually WRONG. If hard fork is implemented, it is very easy to increase bitcoin divisibility by either
- Adding another 64 bit number for fractions of bitcoin, making bitcoin utxo values effectively 128 bit integers. This increases divisibility, not total amount!
- Adding an exponent portion to the utxo values. Since we don't need positive exponents here, we can dedicate the whole exponent to negative numbers, increasing divisibility enormously even with 8 bit exponent. This is at the cost of greatly complicating the calculations, but arithmetic with floating point is a solved problem
I don't know about the other points though...
Maybe a new blockchain is the more logical choice. And it won't be bitcoin, it will be some other name coin. Unfortunatelly since everybody knows the game now, I am not sure if it is possible to grow organically like bitcoin without early martian settlers capturing it.
I have a little problem with this statement you made:
"Sure, on occasion someone might lose a few sats from a counterparty closing a channel at the right moment to steal a dust HTLC".
I specifically wrote about the future where this amount may not be trivial.
But yeah, I can see many people actually knew that there is such a thing. I didn't know until today..
Hm... It is trusted because it can be enforced by force close. Payments above the dust limit can be enforced by the HTLC when force closing. The payments below this as far as I see are added to the miners fee in the commitment transaction so you can't really enforce it by force close. This may or may not be a real problem, but I haven't really seen it discussed.
The current implementation adds the funds in flight to the miner fees (so that the receiver is not incentivised to close the channel), but he can still make the other side lose money (the the reason can be nonmonetary). And multiple small payments can pass through a node.
Well, the output of the updated channel balance is exactly that. As I already stated that I am talking about the time when the payment is in flight.
You do know that without payments in flight there are two outputs in the commitment transaction, right? It goes without sating that these two outputs can be way bigger than any individual payment and way bigger than the dust limit. You also know that lightning updates the commitment transaction differently for payments above and below the dust limit, right?
Actually payments via lightning below the dust limit are enforced, but only when the lightning payment is completed and the preimage has traversed the path to the sender and the channel states are updated. It is while the HTLC is in flight when what I am describing can happen.
Well, today I found out that no HTLC on lightning is created for payments below the on-chain dust limit. The channel is updated so that the funds in flight go to the miner fees instead of a HTLC contract. The receiver/forwarder can't steal these money, but he can force the sender to lose them to the miner. So he doesn't have a monetary incentive to do so, but nevertheless he can force the sender to lose money.
What are you talking about? I was asking how submitting new invoice works with the coordinator since it will have a different preimage, not the reasons why it fails.