Longer paths?

[Michiel de Jong]

Hi all,

SettleNetwork is a super exciting project! I'm trying to look into the pathfinding  mechanics a bit more now, and ran into some seemingly open issues. Maybe we can make some progress on that...

For multi-hop payments over SettleNetwork, it seems there are two processes involved: offer propagation and client-side transaction planning.

A number of situations can occur when Alice wants to pay Bob:

* Alice -> Bob. If Bob trusts Alice, this means that Alice has a balance at Bob's minted asset, and can just use that. Alice's mint will have a propagated copy of Bob's offer of trust, and a propagated copy of Alice's remaining balance.

* Alice -> Charlle -> Bob. Alice can use her balance at Charlie's minted asset, and Charlie's mint will know about Bob's offer to Charllie. IIUC, Bob's offer will canonically live at Bob's mint, and only be propagated to Charlie's mint, so if this second case will only work if Alice and Charlie are at the same mint, right?

* Alice -> Charlie -> Dennis -> Bob. https://github.com/spolu/settle/blob/ef2d828/cli/command/pay.go#L91-L92 states this is not supported (although some commented-out code  exists for length=2), but that longer paths can be used in payments if you use the mint api directly.

So two questions occurred to me:

1) what about the privacy implications of https://github.com/spolu/settle/blob/master/mint/endpoint/list_asset_offers.go - IUC, if Alice and Charlie both have an account at the same mint, but Bob is on a different one, then Alice can ask her&Charlie's mint to disclose offers from Bob to Charlie, even if Bob's mint would not allow her to such API requests without credentials?

2) how would you discover n-hop paths? If offers are only propagated one hop, then the information needed to create a longer transaction path will not be in one place, right?

Maybe something we could explore would be if an offer propagation would not only list the asset offered, but also all assets that can be reached from there. I guess such lists could become quite long, but at least it could make longer transaction paths possible? Also, saying that a path exists from Charlie to Bob  is less sensitive information than disclosing that a direct offfer from Bob to Charlie exists. Have you thought of such an approach?

Cheers,

Michiel

[Stanislas Polu]

Hi Michiel!

So there is no offer propagation. The offer stays at the mint it was
minted at which is the only source of truth when it comes to its
validity. The original idea was indeed to solely rely on client-side
planning (adjunct with third-party services if needed that could crawl
the mints and infer path).

> * Alice -> Charlle -> Bob. Alice can use her balance at Charlie's minted asset, and Charlie's mint will know about Bob's offer to Charllie. IIUC, Bob's offer will canonically live at Bob's mint, and only be propagated to Charlie's mint, so if this second case will only work if Alice and Charlie are at the same mint, right?

This works even if they are not at the same mint assuming both Charlie
and Bob's mint display publicly these offers.

> * Alice -> Charlie -> Dennis -> Bob. https://github.com/spolu/settle/blob/ef2d828/cli/command/pay.go#L91-L92 states this is not supported (although some commented-out code exists for length=2), but that longer paths can be used in payments if you use the mint api directly.

That's accurate.

> 1) what about the privacy implications of https://github.com/spolu/settle/blob/master/mint/endpoint/list_asset_offers.go - IUC, if Alice and Charlie both have an account at the same mint, but Bob is on a different one, then Alice can ask her&Charlie's mint to disclose offers from Bob to Charlie, even if Bob's mint would not allow her to such API requests without credentials?

By default offers are publicly listed on mint servers. Then everything
degenerates gracefully if some mints limit access to some of their
offers to some users through authentication protocol that are left out
of the scope of the system. Does that make sense?

> 2) how would you discover n-hop paths? If offers are only propagated one hop, then the information needed to create a longer transaction path will not be in one place, right?

Ideally I think I would rely on third-party maintaining up-to-date
graphs of offers. What they broadcast does not need to be trusted as
the client will go verify the existence of each offers directly with
each mint. Also if they're not perfectly up to date that's not a big
deal as each client can check if the path still exists on its own as
well.

> Maybe something we could explore would be if an offer propagation would not only list the asset offered, but also all assets that can be reached from there. I guess such lists could become quite long, but at least it could make longer transaction paths possible? Also, saying that a path exists from Charlie to Bob is less sensitive information than disclosing that a direct offfer from Bob to Charlie exists. Have you thought of such an approach?

I thiiink that's an overkill given the suggestion above as it can be
kept out of the core system? I agree that we could consider exposing
paths which could trigger better privacy guarantees but I would have
to think again about the trust implications to make sure this would
not create attack surfaces.

Hope this is useful! Let me know if I can do anything to help!

-stan

> --
> You received this message because you are subscribed to the Google Groups "Settle" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to settle-publi...@googlegroups.com.
> To post to this group, send email to settle...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/settle-public/CA%2BaD3u1pRkOC3jx5Uvg6gOMuO14t-KTeFatcC2PyVKSk13fcYQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Michiel de Jong]

Ah great, yes that makes a lot of sense. So how would these third parties become aware of new mints being added to the network, and how would they become aware of a new  offer being created? Would they crawl the network periodically, using the list asset offers endpoint? Or would a mint submit new offers proactively?

Cheers,

Michiel.

To view this discussion on the web visit https://groups.google.com/d/msgid/settle-public/CAPbbfNh6se5JwO7gMofmcyUN%2BUKREdX2HNiNOXMtSghGB3y0%2BA%40mail.gmail.com.

[Stanislas Polu]

That's unspecified for now, and not really a problem :) But it could
definitely be any of that, through a separate protocol as well if
needed.

-stan