Hi, Thanks for your comments!
(I'm less convinced about the unconditional fee as it changes a core > principle of the network which means that we'll never reach consensus on > it). > I think this is a core principle that opens the network to several attacks and should be changed. Furthermore, there will be nothing stopping nodes from setting their unconditional fee to zero, if they wish to take the risk. > However if we change the protocol, we may as well make it a continuous > risk score instead of a binary low/high-risk. Also, having only two classes > (high and low-risk) protects the the low-risk class but makes the high-risk > class even easier to attack, having a continuous policy should mitigate > this problem. > Could you elaborate on how having more than two classes help? It seems to me that if you have a limit on the resources, you are easier to jam anyway. The main advantage of having two classes is that it's simpler. > And while I agree with the general idea of throttling based on a local > reputation, I think we need more work to find a good formula to compute > this reputation. I don't have a good formula myself but relying on "A > satoshis per second" doesn't seem wise. There are huge disparities between > nodes and even for a given node, traffic is fluctuating a lot. I think a > more reliable indicator would be the proportion of successful payments. > It is important that gaining a good reputation would be difficult. For example, if I only need a high proportion of successful payments, I can just send a single one and gain a 100% success rate. Maybe a better wording would be "X satoshis in fees during a time period of Y" > The beauty of this solution is that we don't need a standardized formula > for reputation, everyone can use its own. However getting a good one is > hard so we need a default recommandation. > As different nodes have different needs and different risk preferences, I'm slightly hesitant to give a general default. We can think about different profiles and offer several options. Thanks again, Clara
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
