ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-09-12 📝 Original message: Good morning Giovanni, > ...
📅 Original date posted:2018-09-12
📝 Original message:
Good morning Giovanni,
> I agree with you, Cezary, and was in tears of joy when read about that
> "plan to implement possibility of both-side funding channels", as it
> would be immensely beneficial for the growth of network.
>
> I think ZmnSCPxj is misreading that as something mandatory, or
> something that would be integrated into the protocol and performed
> automatically by all nodes. Only interpreting it in that way his
> concerns about privacy and locked funds would make sense.
If it is not integrated into the protocol as an optional extension at least, then it would be difficult to coordinate between the 4 or 5 extant implementations. Interoperability is a bit iffy already as-is for functionality that is already in the protocol (e.g. onchain fee disagreements when fees change rapidly on mainnet, unrecognized gossip types, etc).
Further, if not supported by default on most nodes, it runs the risk that only a few nodes will enable incoming requests for outgoing capacity, potentially creating a centralization risk (although I believe laolu (and possibly others?) considers centralization in LN to be benign; I have not investigated this argument in detail, and can only provide a knee-jerk reaction to centralization).
> As as I
> could understand it, however, it would be something that nodes would
> negotiate beforehand and only materialize if they decided it was
> mutually beneficial.
You may imagine negotiation between sapient intelligences, but it is often better to have this automated and supported at a much lower intelligence level, in much the same way that channel construction is often best left to autopilots. If so, then it is best to support it widely to ease the job of autopilots who have been instructed by sapient-level policy to find X BTC incoming capacity for up to N% in fees.
I imagine an extension to `node_announcement` would advertise that a node supports dual-funding, and also contain the limits to that dual-funding.
Thus I still see the potential privacy leak as a concern, since ideally every node should eventually support incoming dual-funding requests if it happens to have onchain capacity, to homogenize the network (improving decentralization and privacy).
Regards,
ZmnSCPxj
📝 Original message:
Good morning Giovanni,
> I agree with you, Cezary, and was in tears of joy when read about that
> "plan to implement possibility of both-side funding channels", as it
> would be immensely beneficial for the growth of network.
>
> I think ZmnSCPxj is misreading that as something mandatory, or
> something that would be integrated into the protocol and performed
> automatically by all nodes. Only interpreting it in that way his
> concerns about privacy and locked funds would make sense.
If it is not integrated into the protocol as an optional extension at least, then it would be difficult to coordinate between the 4 or 5 extant implementations. Interoperability is a bit iffy already as-is for functionality that is already in the protocol (e.g. onchain fee disagreements when fees change rapidly on mainnet, unrecognized gossip types, etc).
Further, if not supported by default on most nodes, it runs the risk that only a few nodes will enable incoming requests for outgoing capacity, potentially creating a centralization risk (although I believe laolu (and possibly others?) considers centralization in LN to be benign; I have not investigated this argument in detail, and can only provide a knee-jerk reaction to centralization).
> As as I
> could understand it, however, it would be something that nodes would
> negotiate beforehand and only materialize if they decided it was
> mutually beneficial.
You may imagine negotiation between sapient intelligences, but it is often better to have this automated and supported at a much lower intelligence level, in much the same way that channel construction is often best left to autopilots. If so, then it is best to support it widely to ease the job of autopilots who have been instructed by sapient-level policy to find X BTC incoming capacity for up to N% in fees.
I imagine an extension to `node_announcement` would advertise that a node supports dual-funding, and also contain the limits to that dual-funding.
Thus I still see the potential privacy leak as a concern, since ideally every node should eventually support incoming dual-funding requests if it happens to have onchain capacity, to homogenize the network (improving decentralization and privacy).
Regards,
ZmnSCPxj