ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-22 🗒️ Summary of this message: A claim that a ...
📅 Original date posted:2023-05-22
🗒️ Summary of this message: A claim that a pool transaction can be double-spent by the Ark service provider while it remains in the mempool is causing confusion.
📝 Original message:Good morning Burak,
I have not gone through the deep dive fully yet, but I find myself confused about this particular claim:
> A pool transaction can be double-spent by the Ark service provider while it remains in the mempool. However, in the meantime, the recipient can pay a lightning invoice with their incoming zero-conf vTXOs, so it’s a footgun for the service operator to double-spend in this case.
Given that you make this claim:
> ASPs on Ark are both (1) liquidity providers, (2) blinded coinjoin coordinators, and (3) Lightning service providers. ASPs main job is to create rapid, blinded coinjoin sessions every five seconds, also known as pools.
As the access to Lightning is also by the (same?) ASP, it seems to me that the ASP will simply fail to forward the payment on the broader Lightning network after it has replaced the in-mempool transaction, preventing recipients from actually being able to rely on any received funds existing until the next pool transaction is confirmed.
Even if the Lightning access is somehow different from the ASP you are receiving funds on, one ASP cannot prove that another ASP is not its sockpuppet except via some expensive process (i.e. locking funds or doing proof-of-work).
Regards,
ZmnSCPxj
🗒️ Summary of this message: A claim that a pool transaction can be double-spent by the Ark service provider while it remains in the mempool is causing confusion.
📝 Original message:Good morning Burak,
I have not gone through the deep dive fully yet, but I find myself confused about this particular claim:
> A pool transaction can be double-spent by the Ark service provider while it remains in the mempool. However, in the meantime, the recipient can pay a lightning invoice with their incoming zero-conf vTXOs, so it’s a footgun for the service operator to double-spend in this case.
Given that you make this claim:
> ASPs on Ark are both (1) liquidity providers, (2) blinded coinjoin coordinators, and (3) Lightning service providers. ASPs main job is to create rapid, blinded coinjoin sessions every five seconds, also known as pools.
As the access to Lightning is also by the (same?) ASP, it seems to me that the ASP will simply fail to forward the payment on the broader Lightning network after it has replaced the in-mempool transaction, preventing recipients from actually being able to rely on any received funds existing until the next pool transaction is confirmed.
Even if the Lightning access is somehow different from the ASP you are receiving funds on, one ASP cannot prove that another ASP is not its sockpuppet except via some expensive process (i.e. locking funds or doing proof-of-work).
Regards,
ZmnSCPxj