search

XRPLF / rippled

Decentralized cryptocurrency blockchain daemon implementing the XRP Ledger protocol in C++
https://xrpl.org
ISC License
4.52k stars 1.47k forks source link

path bug from forum #16

Closed jedmccaleb closed 11 years ago

jedmccaleb commented 11 years ago

Everything is failing just the same, I'm afraid.

So the workflow that is failing is, in a nutshell:

walletA trusts bitstamp for 1 BTC walletB trusts bitstamp for 1 BTC wallet A gets a 0.1 BTC transfer from bitstamp wallet A cannot send any BTC to wallet B - Paths are calculated but when sending one of partial path or fee insufficient will be thrown.

Are you able to run the workflow described yourself?

[edit] - above is the simplified workflow that is failing now, the original issue was slightly more complicated:

walletA trusts bitstamp for 1 BTC walletB trusts walletA for 1 BTC walletB trusts bitstamp for 1 BTC walletA gets a 0.1 BTC transfer from bitstamp walletA sends 0.05 BTC to walletB - it appears as walletA BTC IOU walletB cannot send any BTC to bitstamp - Paths are calculated but when sending one of partial path or fee insufficient will be thrown.

JoelKatz commented 11 years ago

I believe the "fee insufficient" issue should now be resolved. The fee was in fact insufficient because the pathfinding load raised the relay fee. This logic has been changed. The partial path isn't a pathfinding issue if the path found was valid. I'll try to replicate that.

nelisky commented 11 years ago

I am not sure if the paths are valid or not, but I can reproduce this problem in both reported cases on the ripple network and as such can provide the actual addresses and paths if you need me to.

JoelKatz commented 11 years ago

You can still get "fee insufficient"?

nelisky commented 11 years ago

No, I have tried with multiple values which used to trigger the fee issue and that seems to be resolved.

However I'm getting no response to confirming the transfer 3 out of 4 transfer attempts now. That is likely a client issue and not a server one, but I thought I'd just leave you a note regardless.

When I offered the paths and addresses I was referring to the partial path issue specifically.

JoelKatz commented 11 years ago

Okay, good. This is most likely the known issue that I'm working on now.

nelisky commented 11 years ago

The failing case on the top of the OP is still failing with tecPATH_PARTIAL when using the API, but when I try to send 0.01 BTC from walletA (rKLw2zHgA31nRZN3erfZkfR8uhAkQ8s95P) to walletB using the web client (rLDDq8ZGhCaVBP8MyYTifhCJzgWPQBjwpt ) I get a stranger "You have no trust line in this currency."

Joel, I'm not sure of anything anymore, can you please tell me if this flow of funds is supposed to work at all?

nelisky commented 11 years ago

I think I see why sending from the web client throws terNO_LINE now, as I can trigger the same error using the API if I set the issuer to be the source wallet address instead of bitstamp.

nelisky commented 11 years ago

ahbritto pointed out that my attempt to move bitstamp IOUs will fail without proper SendMax, and adding that made the transaction submission for the top case work. Exciting times!

I can't reproduce this success from the web client because of said terNO_LINE error.

nelisky commented 11 years ago

Again, with a lot of help from ahbritto I was able to deposit into bitstamp as per the second scenario using the RPC interface.

At this point it is safe to say that all of my problems are web client specific, in choosing which issuers to use. For this particular issue, I vote it closed and if you need me to I can open one specific for the web client.