Published on: 2020-06-24T08:32:52+00:00
The discussion on the Bitcoin-dev mailing list revolves around the possibility of a miner hiding a transaction from certain parts of the network. One participant acknowledges that it is theoretically possible but difficult in practice. They argue that an attacker capable of doing this would disrupt off-chain constructions relying on absolute timeouts, with the hope that achieving this without cooperation from miners would be challenging.Another participant suggests using independent pay-to-preimage transactions as a technical solution but highlights concerns about incentives. They propose releasing two transactions with near-equal fees, one near miners and the other near non-miners, creating an inviolate boundary between the two transactions.Matt observes that transaction relay delays and network topology make this attack practical with a double-digit success rate, suggesting it should be addressed in the medium term.In an email exchange, Bastien and ZmnSCPxj discuss the possibility of an attack on off-chain constructions relying on absolute timeouts. ZmnSCPxj suggests using independent pay-to-preimage transactions as a solution, but Bastien raises concerns about the incentives involved, as miners would have to cooperate with the attacker. ZmnSCPxj argues that it is technically possible to execute this attack without miner cooperation. The attacker can release two transactions with near-equal fees, one near miners and the other near non-miners, creating a boundary between the two transactions that neither can pass.ZmnSCPxj responds to Bastien's message regarding independent pay-to-preimage transactions, agreeing with the technical implementation but highlighting remaining incentive issues. They suggest that miners hiding the preimage transaction must collaborate with the attacker. However, they believe it is technically possible to execute the attack without miner cooperation. By releasing two transactions with near-equal fees, one near miners and the other near non-miners, a boundary is created where each node receives and rejects one of the transactions. This inviolate boundary prevents either transaction from passing, even with unmodified Bitcoin Core code.In a discussion on recent attacks on the Lightning Network (LN), Bastien suggests using independent pay-to-preimage transactions as a technical solution. However, David Harding raises concerns about incentives and centralization. Miners hiding the preimage transaction would have to collaborate with the attacker, potentially leading to bidding wars and loss of funds for honest users. Harding proposes incentive equivalents to normal on-chain transaction fees, eliminating reputational advantage and direct economies of scale.The conversation discusses the use of pay-for-signature construction in pointlocked timelock contracts (PTLCs) involving signing with MuSig(A, B). A proposes a fund that can only be claimed by leaking knowledge of 's' behind 's*G'. The proposal includes generating keypairs, revealing specific information publicly, and involving a third party to complete the signature. The discussion highlights privacy advantages.David A. Harding raises concerns about LN nodes investing in mining pools to gain information and reduce attacks, suggesting it could lead to centralization. He recommends using independent pay-to-preimage transactions as incentive equivalents to on-chain fees. ZmnSCPxj notes that pay-to-preimage doesn't work with PTLCs. Harding questions the need for off-chain nodes to heavily invest in on-chain operations and sees no benefits from eltoo. However, he considers investing in running nodes in mining pools to learn about attackers' transactions and potentially share preimages off-chain reasonable, ignoring concerns about mining centralization.The conversation involves a proposal to protect against an attack on lightning network channels involving broadcasting the latest state of a channel and redirecting funds to an attacker's address. It discusses the relay of blind child transactions and the limitations in practice. Bastien suggests having Lightning Network nodes invest in running nodes in mining pools to learn about attackers' transactions and share discovered preimages off-chain. The recent attacks highlight the importance of off-chain nodes being invested in on-chain operations.The context discusses various proposals and solutions related to the Bitcoin mempool, HTLC spends, pinning attacks, and potential vulnerabilities. One proposal suggests using a hashlock smart contract with an intermediary to facilitate payments. However, there are flaws in the current implementation, and alternative solutions are proposed.Matt Corallo suggests using a bribe system to incentivize miners to include transactions with specific preimages. This can be done through confirmed P2WPKH UTXOs and scriptPubKeys with OP_SHA256 OP_EQUAL. Non-miners can also create child transactions if they know the preimage. However, this solution requires additional software and complexity in LN clients.ZmnSCPxj proposes limiting the size of low fee-rate transaction packages to prevent denial-of-service attacks. By preventing incoming transactions from extending a low-fee-rate tree of transactions, it will be easier to evict such transactions without much impact. This solution aims to address the difficulty involved in evicting low fee-rate transactions.Jeremy Rubin suggests dedicating more development resources towards finishing the mempool project to solve the existing issues.
Updated on: 2023-07-31T22:50:13.549812+00:00