related posts
3 sats \ 3 replies \ @nerd2ninja 1 Dec 2022
Oh no. Who's gonna tell them that zero conf is dead?
Wait, I see "Zeroconf requires the fundee to trust the funder. For this reason it is disabled by default, and you can only enable it on a peer-by-peer basis."
I would prefer it to say "The Bitcoin Protocol does not, and cannot, provide any assurance that the first version of an unconfirmed transaction seen by a particular node will be the version that gets confirmed. If there are multiple versions of the same unconfirmed transaction available, only the miner who includes one of those transactions in a block gets to decide which version of the transaction gets confirmed." but alright
reply
16 sats \ 2 replies \ @petertodd 2 Dec 2022
There's plenty of situations where you trust another party enough to use turbo channels. Eg any time you know who they are, and have some kind of recourse, such as channels between exchanges. A useful feature for that would be to allow you to set a per-peer limit for how much funds you're willing to put at risk at any one time; channels beyond that would be rejected.
No-one is trying to use turbo channels by relying on the dumb "first seen" rule (even Muun: they don't actually use lightning channels at all).
reply
1 sat \ 1 reply \ @nerd2ninja 2 Dec 2022
Oh, so turbo channels are zero-conf channels huh?
It just sounds like another risk that is not necessary for the normal operation of business. A risk mitigated by just chilling out for a minute and waiting a bit.
Seriously though, what happens if someone zero-confs a channel establishment, sends LN Bitcoin to me via the network, then gets a different tx confirmed that invalidates the channel establishment tx?
reply
16 sats \ 0 replies \ @petertodd 2 Dec 2022
You are unaffected by what happens in the middle of a Lightning route. If someone in the middle loses money, that's simply not your problem.
reply