Anchor Outputs Are a Danger to Mining Decentralization
Since Anchor Outputs are so much less efficient than RBF — about 2x the cost — they pose a significant danger to mining decentralization because of out-of-band fee payment. The problem is that if you have an anchor-using transaction that you need to get mined, it costs twice as much blockspace to get the transaction mined via the intended mechanism — the anchor output — as it does by getting a miner to include the transaction without the anchor output spend.
Some large miners are already accepting out-of-band payments for transactions, allowing you to pay them directly to get your transaction mined; only large miners can reasonably offer this service, as only large miners find blocks sufficiently frequently to make out-of-band fee payments worthwhile. Decentralized mining pools such as P2Pool and Braidpool have absolutely no hope of being able to offer out-of-band fee payments at all.
Since a typical anchor-output using Lightning channel takes 2x more block space, a large miner could easily offer out-of-band fee payments at, say, a 25% discount, giving them a substantial 25% premium over their smaller competitors. Given that mining pool fees are highly competitive, on the order of 1% or 2%, being able to earn a 25% premium over your competitors is an enormous advantage. With Lightning, offering this as a service in an automated, convenient, way would be quite easy to implement.
We must not build protocols that put decentralized mining at a disadvantage. On this basis alone, there is a good argument that V3 transactions and ephemeral anchor outputs should not be implemented.
https://petertodd.org/2023/v3-transactions-review
halalmoney /
npub1vd…97rjz
2024-01-01 00:38:33
Author Public Key
npub1vdaz78d96t7pjakpfmqqlr4wgq26l6vmkf25782n05qgdgtfmk8s297rjzPublished at
2024-01-01 00:38:33Event JSON
{
"id": "3420dc79d1bd2f692ea6fb23179cae4767b34dc4c16cc89d4f12e4a19b145f3d",
"pubkey": "637a2f1da5d2fc1976c14ec00f8eae4015afe99bb2554f1d537d0086a169dd8f",
"created_at": 1704069513,
"kind": 1,
"tags": [
[
"client",
"Nostur",
"31990:9be0be0fc079548233231614e4e1efc9f28b0db398011efeecf05fe570e5dd33:1685868693432"
]
],
"content": "Anchor Outputs Are a Danger to Mining Decentralization\n\nSince Anchor Outputs are so much less efficient than RBF — about 2x the cost — they pose a significant danger to mining decentralization because of out-of-band fee payment. The problem is that if you have an anchor-using transaction that you need to get mined, it costs twice as much blockspace to get the transaction mined via the intended mechanism — the anchor output — as it does by getting a miner to include the transaction without the anchor output spend.\n\nSome large miners are already accepting out-of-band payments for transactions, allowing you to pay them directly to get your transaction mined; only large miners can reasonably offer this service, as only large miners find blocks sufficiently frequently to make out-of-band fee payments worthwhile. Decentralized mining pools such as P2Pool and Braidpool have absolutely no hope of being able to offer out-of-band fee payments at all.\n\nSince a typical anchor-output using Lightning channel takes 2x more block space, a large miner could easily offer out-of-band fee payments at, say, a 25% discount, giving them a substantial 25% premium over their smaller competitors. Given that mining pool fees are highly competitive, on the order of 1% or 2%, being able to earn a 25% premium over your competitors is an enormous advantage. With Lightning, offering this as a service in an automated, convenient, way would be quite easy to implement.\n\nWe must not build protocols that put decentralized mining at a disadvantage. On this basis alone, there is a good argument that V3 transactions and ephemeral anchor outputs should not be implemented.\n\nhttps://petertodd.org/2023/v3-transactions-review",
"sig": "d2ba2ae995b56fbdd48b51c0dcff71447cf2db520c04181c58b421080b302f810f1ce7934d129ad3c289e5fd69df5112d4272ceaaaa3cd08e9cec7731ea263a2"
}