Hi AJ, Prayank, > I think that's backwards: we're trying to discourage people from wasting > the network's bandwidth, which they would do by publishing transactions > that will never get confirmed -- if they were to eventually get confirmed > it wouldn't be a waste of bandwith, after all. But if the original > descendent txs were that sort of spam, then they may well not be > submitted again if the ancestor tx reaches a fee rate that's actually > likely to confirm.
But do you agree that descendants only matter for DoS resistance then, not for miner incentives? I'm asking this because I think a new set of policies should separate policies that address the miner incentives from policies that address the DoS issues. The two policies I proposed address miner incentives. I think they're insufficient to address DoS issues. But adding a 3rd policy to address DoS issues may be a good solution? I think that rate-limiting p2p as you suggest (and Gloria also mentioned it) is likely a better way of fixing the DoS concerns than a descendant rule like BIP 125 rule 5 (which as I mentioned earlier, is problematic because the descendent set varies from one mempool to another). I would like to add a small update to my policy suggestions. The X and Y percentage increase should be met for both the ancestor scores AND the transaction in isolation. Otherwise I could replace txA with txA' that uses a new ancestor txB that has a high fee and high feerate, while txA' has a low fee and low feerate. It's then possible for txB to confirm without txA', and what would remain then in the mempool would be worse than before the replacement. > All you need is for there to be *a* path that follows the new relay rules > and gets from your node/wallet to perhaps 10% of hashpower, which seems > like something wallet providers could construct relatively quickly? That's true, maybe we can be more optimistic about the timeline for using an updated set of policies ;) > Do you think such multi party contracts are vulnerable by design > considering they rely on policy that cannot be enforced? It's a good question. Even though these policies cannot be enforced, if they are rational to apply by nodes, I think it's ok to rely on them. Others may disagree with that, but I guess it's worth a separate thread. > Not sure I understand this part because if a transaction is on-chain > it can't be replaced. Sorry, that was a bit unclear. Suppose I have txA that I want to RBF, but I only have unconfirmed utxos and I can't simply lower its existing outputs to reach my desired feerate. I must make one of my unconfirmed utxos confirm asap just to be able to use it to RBF txA. That means I'll need to pay fees a first time just to convert one of my unconfirmed utxos to a confirmed one. Then I'll pay the fees to bump txA. I had to overpay fees compared to just using my unconfirmed utxo in the first place (and manage more complexity to track the confirmation of my unconfirmed utxo). Thanks for your feedback! Bastien Le mar. 1 févr. 2022 à 03:47, Prayank <pray...@tutanota.de> a écrit : > Hi Bastein, > > > This work will highly improve the security of any multi-party contract > trying to build on top of bitcoin > > Do you think such multi party contracts are vulnerable by design > considering they rely on policy that cannot be enforced? > > > For starters, let me quickly explain why the current rules are hard to > work with in the context of lightning > > Using the term 'rules' can be confusing sometimes because it's just a > policy and different from consensus rules. I wish we could change this in > the BIP with something else. > > > I'm actually paying a high fee twice instead of once (and needlessly > using on-chain space, our scarcest asset, because we could have avoided > that additional transaction > > Not sure I understand this part because if a transaction is on-chain it > can't be replaced. > > > The second biggest pain point is rule 3. It prevents me from efficiently > using my capital while it's unconfirmed > > > I'm curious to hear other people's thoughts on that. If it makes sense, > I would propose the following very simple rules > > Looks interesting however not sure about X and Y. > > > -- > Prayank > > A3B1 E430 2298 178F >
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
