Search the Community

Noob question hour #6 Recent ledgers have ~2.2 k trading pairs. I wonder if there is any limit for the length of the path a payment may take. If one were to supply a custom path of 50, 100, 500 "hops", when does rippled outright refuses such payments. Or will it just freeze, if VM lacks memory to process such path? Also, https://ripple.com/build/paths/ has an interesting illustration regarding likelihood of success of certain paths. Why is rippling through two issuers unlikely to work?

I'm trying to send Gatehub USD from my account to another. The other party has more USD trust lines including USD:Gatehub, USD:Bitstamp etc. I tried with gatehub.net and a desktop wallet, both try to automatically convert Gatehub USD to Bitstamp's because it's currently "profitable" (e.g. the USD/USD ratio is far from 1). I guess this is ripple's feature of pathfinding. Is there any way of bypassing this? The other party really wants USD:Gatehub and if they get USD:Bitstamp, they'll need to convert it back which will likely be loss.

I am falling down the rabbit hole, trying to build a complete traversable map of all relationships that exist on RCL. Disclaimer: am not a techy person. Expect misnomers and facepalms down the way. Hence it is in Off-topic subforum and not in Technical discussion. I was trying to build a list of Gateway<-wallets->gateway to be able to query the wallets that satisfy certain criteria. And after many sleepless nights of digging into ripple-lib and nodejs I finally managed to get a complete lists of wallets that trust chosen gateway and all their trustlines. For ~4k of those wallets, it took a nice dozen of MBs in a json file. Traversing through the contents is an adventure of its own. And since a similar list of gatehub or bistamp would probably take GBs and the power my poor PC can't sustain, I decided to look elsewhere. So I found a concept of graph database, which seems perfect for the task. But me being me - I may have completely miscalculated this one as well. Maybe you have been dealing with the same problem, or are knowledgeable in neo4j and willing to help. So here are my questions. RippleCharts (when you put the address in account explorer) represents each address as a node and trustlines appear to be a relationship between the nodes. So is relationship/trustline a place that stores all details re: currency and balances. How will the pathfinding work then? Neo4j has a tutorial for currency arbitrage, but they represent the currencies as nodes, and relationships are rates (albeit without order size). But if wallets are nodes in case of RCL, where does it live the trustlines? I was thinking to represent each IOU as a subnodes of the issuing wallet. While it may seem to be closer to neo4j's tutorial, I still have no idea how to represent the orderbook of RCL. The raw data indicates that standing offers are Offer.Nodes of the maker-account. So should I make them subnodes too? Ripple has 300k+ wallets as of now. If I choose to spawn subnodes per issuing wallet node, it will take the total node count into tens of millions - and there is no way my laptop could churn the query in under 3.5 seconds... Then there is a completely separate case of Rippling flag and the whole mechanic. I honestly have no idea how to make that work, especially in case of IOU.noRippleflagOn-IOU.noRippleflagUndefined pair, where Rippling itself can happen only in one direction (from noRipple to Ripple), provided the balances are lower than the limits in trustline. TL;DR How would you represent RCL data in a graph database? 1. Are wallets - nodes; trustlines - edges (or relationships in neo4j terms)? 2.Are wallets' offers - edges or nodes as well? 3.What is Rippling - an edge, a node, an edge/node property? How can it be represented to mimic the behaviour it has on RCL? How can I specify path block, or that path is only available in one direction? 4. Where would you put the fee associated with transferring IOUs? Where would you put the order-size constraint (i.e. only a set_amount can traverse through this edge/node)? ... I guess XRP will be in upper two digits by the time I manage to find an answer at least to one of the questions above. Thank you, whoever is reading this now. And I'm sorry if I have wasted your time.