Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest
Good morning Bastien, > Thanks for the detailed write-up on how it affects incentives and > centralization, > these are good points. I need to spend more time thinking about them. > > > This is one reason I suggested using independent pay-to-preimage > > transactions[1] > > While this works as a technical solution, I think it has some incentives > issues too. > In this attack, I believe the miners that hide the preimage tx in their > mempool have > to be accomplice with the attacker, otherwise they would share that tx with > some of > their peers, and some non-miner nodes would get that preimage tx and be able > to > gossip them off-chain (and even relay them to other mempools). I believe this is technically possible with current mempool rules, without miners cooperating with the attacker. Basically, the attacker releases two transactions with near-equal fees, so that neither can RBF the other. It releases the preimage tx near miners, and the timelock tx near non-miners. Nodes at the boundaries between those that receive the preimage tx and the timelock tx will receive both. However, they will receive one or the other first. Which one they receive first will be what they keep, and they will reject the other (and *not* propagate the other), because the difference in fees is not enough to get past the RBF rules (which requires not just a feerate increase, but also an increase in absolute fee, of at least the minimum relay feerate times transaction size). Because they reject the other tx, they do not propagate the other tx, so the boundary between the two txes is inviolate, neither can get past that boundary, this occurs even if everyone is running 100% unmodified Bitcoin Core code. I am not a mempool expert and my understanding may be incorrect. Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest
Thanks for the detailed write-up on how it affects incentives and centralization, these are good points. I need to spend more time thinking about them. This is one reason I suggested using independent pay-to-preimage > transactions[1] > While this works as a technical solution, I think it has some incentives issues too. In this attack, I believe the miners that hide the preimage tx in their mempool have to be accomplice with the attacker, otherwise they would share that tx with some of their peers, and some non-miner nodes would get that preimage tx and be able to gossip them off-chain (and even relay them to other mempools). If they are actively helping the attacker, they wouldn't spend the pay-to-preimage tx, unless they gain more from it than the share the attacker gives them. This becomes a simple bidding war, and the honest user will always be the losing party here (the attacker has nothing to lose). For this reason I'm afraid it wouldn't work out in practice as well as we'd hope...what do you think? And even if the honest user wins the bidding war, the attack still steals money from that user; it just goes into the miner's pocket. But from the perspective of a single LN node, it > might make more sense to get the information and *not* share it > I think it depends. If this attack becomes doable in practice and we see it happening, LN routing nodes and service providers have a very high incentive to thwart these attacks, because otherwise they'd lose their business as people would leave the lightning network. As long as enough nodes think that way (with "enough" being a very hard to define quantity), this should mitigate the attack. The only risk would be a big "exit scam" scenario, but the coordination cost between all these nodes makes that scenario unlikely (IMHO). Thanks, Bastien Le sam. 20 juin 2020 à 12:37, David A. Harding a écrit : > On Sat, Jun 20, 2020 at 10:54:03AM +0200, Bastien TEINTURIER wrote: > > We're simply missing information, so it looks like the only good > > solution is to avoid being in that situation by having a foot in > > miners' mempools. > > The problem I have with that approach is that the incentive is to > connect to the highest hashrate pools and ignore the long tail of > smaller pools and solo miners. If miners realize people are doing this, > they may begin to charge for information about their mempool and the > largest miners will likely be able to charge more money per hashrate > than smaller miners, creating a centralization force by increasing > existing economies of scale. > > Worse, information about a node's mempool is partly trusted. A node can > easily prove what transactions it has, but it can't prove that it > doesn't have a certain transaction. This implies incumbent pools with a > long record of trustworthy behavior may be able to charge more per > hashrate than a newer pools, creating a reputation-based centralizing > force that pushes individual miners towards well-established pools. > > This is one reason I suggested using independent pay-to-preimage > transactions[1]. Anyone who knows the preimage can mine the > transaction, so it doesn't provide reputational advantage or direct > economies of scale---pay-to-preimage is incentive equivalent to paying > normal onchain transaction fees. There is an indirect economy of > scale---attackers are most likely to send the low-feerate > preimage-containing transaction to just the largest pools, so small > miners are unlikely to learn the preimage and thus unlikely to be able > to claim the payment. However, if the defense is effective, the attack > should rarely happen and so this should not have a significant effect on > mining profitability---unlike monitoring miner mempools which would have > to be done continuously and forever. > > ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was > hoping one of Bitcoin's several inventive cryptographers would come > along and describe how someone with an adaptor signature could use that > information to create a pubkey that could be put into a transaction with > a second output that OP_RETURN included the serialized adaptor > signature. The pubkey would be designed to be spendable by anyone with > the final signature in a way that revealed the hidden value to the > pubkey's creator, allowing them to resolve the PTLC. But if that's > fundamentally not possible, I think we could advocate for making > pay-to-revealed-adaptor-signature possible using something like > OP_CHECKSIGFROMSTACK.[3] > > [1] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html > [2] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002667.html > [3] https://bitcoinops.org/en/topics/op_checksigfromstack/ > > > Do you think it's unreasonable to expect at least some LN nodes to > > also invest in running nodes in mining pools, ensuring that they learn > > about attackers' txs and can potentially share discovered prei
Re: [bitcoin-dev] [Lightning-dev] RBF Pinning with Counterparties and Competing Interest
Hey ZmnSCPxj, I agree that in theory this looks possible, but doing it in practice with accurate control of what parts of the network get what tx feels impractical to me (but maybe I'm wrong!). It feels to me that an attacker who would be able to do this would break *any* off-chain construction that relies on absolute timeouts, so I'm hoping this is insanely hard to achieve without cooperation from a miners subset. Let me know if I'm too optimistic on this! Cheers, Bastien Le lun. 22 juin 2020 à 10:15, ZmnSCPxj a écrit : > Good morning Bastien, > > > Thanks for the detailed write-up on how it affects incentives and > centralization, > > these are good points. I need to spend more time thinking about them. > > > > > This is one reason I suggested using independent pay-to-preimage > > > transactions[1] > > > > While this works as a technical solution, I think it has some incentives > issues too. > > In this attack, I believe the miners that hide the preimage tx in their > mempool have > > to be accomplice with the attacker, otherwise they would share that tx > with some of > > their peers, and some non-miner nodes would get that preimage tx and be > able to > > gossip them off-chain (and even relay them to other mempools). > > I believe this is technically possible with current mempool rules, without > miners cooperating with the attacker. > > Basically, the attacker releases two transactions with near-equal fees, so > that neither can RBF the other. > It releases the preimage tx near miners, and the timelock tx near > non-miners. > > Nodes at the boundaries between those that receive the preimage tx and the > timelock tx will receive both. > However, they will receive one or the other first. > Which one they receive first will be what they keep, and they will reject > the other (and *not* propagate the other), because the difference in fees > is not enough to get past the RBF rules (which requires not just a feerate > increase, but also an increase in absolute fee, of at least the minimum > relay feerate times transaction size). > > Because they reject the other tx, they do not propagate the other tx, so > the boundary between the two txes is inviolate, neither can get past that > boundary, this occurs even if everyone is running 100% unmodified Bitcoin > Core code. > > I am not a mempool expert and my understanding may be incorrect. > > Regards, > ZmnSCPxj > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Distributed Delegated Pre-Signed Transactions (DDPST)
I am building a solution for distributed, delegated pre-signed transactions (DDPST). This post introduces what DDPST are and why I think they are relevant for multiple applications. If you are working on application that can benefit from such a construction and want me to use your application in the proof of concept code, please reach out. All feedback is welcome on the concept in general. Pre-signed transactions (PSTs) are utilized in numerous off-chain protocols including Lightning Network, non-custodial trading, Statechains, and custody protocols. PSTs are useful because they enable restricted access to funds and their custody can be *delegated* with limited risk. Compare this with the arbitrary control over funds that comes with access to the private keys. It is conceivable then that a broad class of applications would benefit from a mechanism to securely delegate PSTs. A mechanism to *distribute* custody of PSTs across multiple entities can act as a practical countermeasure for numerous attacks (e.g. denial-of-service, bribery, blackmail, etc.). Moreover, systems of accountability among the custodians, with proofs of correct and incorrect behaviour, form a foundation for engineering incentive structures that align with the objectives of the application at hand. Finally, distributed custody of PSTs could enable new trust models for the privacy of delegated PSTs using multi-party computation. # Examples Consider first the example of vault-custody protocols [1], where there is a requirement for a distributed network monitoring and response system to detect breeches and trigger a recovery process. It is critical to protect against denial-of-service (DoS) attacks that seek to compromise a monitoring node in order to force the custody operation into a recovery process. In this attack the adversary broadcasts the recovery transaction and reduces the accessibility of the wallet owner's funds. A method for distributing custody of the recovery transaction offers defence-in-depth, and a method for delegating custody enables outsourcing the monitor and response service (see Watchtower implementations currently under development [2,3]). A further improvement for the protection of PSTs, that comes from distributing custody, is that *proactive* security models can be instanciated such that successful attacks must occur in a limited time-frame [4]. Consider next the example of justice transactions in the current Lightning Network model. Here, it is critical that justice transactions are broadcast in a timely manner in response to detecting that either party is attempting to close the channel with a prior state. Attacks rely on disrupting the broadcast of the justice transaction through, for example, bribing the watchtower to wait. The watchtower can broadcast late and claim that it was an honest failure due to network issues. The victim has no recourse to punish the watchtower nor the malicious channel participant. If instead the justice transaction was distributed among a set of independent watchtowers, and an accountability system was in-place for their actions, a more robust incentive structure could be engineered. Moreover, distributing custody of the justice transaction can provide a new privacy mechanism for both operational security of a business but also to mitigate targeted attacks such as bribery. Best regards, Jacob # References [1] Jacob Swambo, Spencer Hommel, Bob McElrath, and Bryan Bishop. Custody Protocols Using Bitcoin Vaults. 2020. https://arxiv.org/abs/2005.11776 [2] The eye of satoshi - lightning watchtower. https://github.com/talaia-labs/python-teos [3] Private altruist watchtowers. https://github.com/lightningnetwork/lnd/blob/master/docs/watchtower.md [4] Ran Canetti, Rosario Gennaro, and Amir Herzberg. Proactive security: Long-term protection against break-ins. CryptoBytes, 3:1–8, 1997. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
