I dont get it? if I can buy 1 DYM with XRP's will that DYM not be backed with a dime, or if its is backed will the XRP value be added to the DYM balance sheet too?
I need to get hooked in to the DYM to see if I can understand it better. Can I add the currency to my drop down menu if I dont have any and what do I need to do past trusting the address you posted?
rsZvcvACPWoTN2Eazzb5radzQX18s3DuK8
Only 2000 TTBit/DYM exist, and they are all backed up by real dimes (you have to trust TTBit to be honest, of course). So when you buy with XRP you are buying one of those 2000 DYMs and thus one that is fully backed by real dimes. To trade on DYMs (and have them appear in the balance sheet and currency dropdown) you just need to trust TTBit's address for however many DYMs you trust him for. You can only receive as many as you trust. Enter his address in the trust add, write DYM in the currency and state how many to trust and you are good to go. |
|
|
|
|
Bump for previous post, the payout transactions will be changing soon!
|
|
|
|
We have a new feature creeping in, which is an attempt to mitigate the issue with blockchain bloating, at least to some extend. We're calling it the Bet Groups; wager payouts are going to be grouped by return address, and an attempt is made to join as many payouts as possible in a single transaction. This is the current plan: - Only transactions paying to the same address are grouped. This is to prevent issues with double spent transactions screwing everyone's payouts amongst other things.
- The connection between wager input transaction and payment is kept, so there will be one output for each input in order to make it easy to assert no cheating is being done. Note that there might be an extra input when payout is larger than received amount, and an extra output for collecting change and these may shift the inputs and outputs such that input 0 connects to output 1, etc.
- there is one exception, which is when using IRC proxy wallets the losing wagers don't pay anything as there's feedback in the IRC chat window, reducing the 'dust'. This means the input for these losing wagers is not present in the payout.
- Wagers are grouped for at most 5 minutes, meaning any payout in queue for an address will be immediately paid once the oldest queue entry is over 4 minutes old.
- When an address queue has 5 or more payouts, they are sent regardless of queue entry age.
Many of the bets we get on the site come from what I believe are betting bots, and these might be processing the payout transactions for feedback. If that's the case they'll probably be confused with this new system so we are only turning it on for IRC proxy wallets for now, but will make it global in a couple of days if there are no major concerns with this from players. The IRC version of DICEonCRACK is explained in https://bitcointalk.org/index.php?topic=147722.0As always, good luck! |
|
|
|
|
Looking at account_tx now, trying the full range of ledger indexes (0 to 323284 currently) I get 6 results back, all of them failed attempts at sending (the tecPARTIAL_PATH I've reported). There are 4 events in the account history (receiving XRP, receiving BTC and sending a custom currency) that aren't referenced at all in account_tx. Is this expected?
I assumed account_tx would be a filtered version of tx_history, but I may be confusing the command semantics.
|
|
|
|
|
Would you be interested in discussing the system with DICEonCRACK for eventually creating a new strategy there based on it or is it a "trade secret"?
|
|
|
|
I have been somewhat skeptical of ripple as it was taking me a long time to grasp what its basic usefulness was in the first place. I must say that playing with it with TTBit for a while I've had a proper AHA moment and while it is a great way of dealing with exchanges, and that is a fine thing to do, I believe the real feature behind it is the fact that having trust lines and public ledgers allows for applying the concept of credit outside the reality of simple currencies. While there are still some kinks to iron off we already have a bunch of ideas to leverage what appears to be an amazing system to operate services well outside the simple exchange reality. Took a lot of time, sure, but while developing these new ways of using ripple implies a deep understanding of the going-ons, using services based upon it should not. I am in no way affiliated to ripple but since yesterday I really wish I was  |
|
|
|
As for 2) that is pretty smart, I must say. It does not apply to the case where both sides of a trade trust a common exchange but not one another, right?
(I assume by "exchange" you mean an issuer, not a change in currencies.) Assuming the issuer hasn't issued the first one credit, then it cannot apply. (And gateways don't usually extend credit to anyone.) It can only apply when you are returning IOUs to someone who has extended you credit. At first you can give them their own IOUs and then you can issue your own IOUs. The network doesn't currently handle all of these cases quite as well as it could when finding paths. We are working on this now. Yes, issuer, still getting used to the semantics here. The cases that are failing for me (including the one I pasted the RPC call for) are all V shaped. Both ends trust one 3rd party issuer, none trust the other, so I am trying to move Bitstamp IOUs from walletA to walletB, where none of the wallets has extended credit to the other, but both have for Bitstamp. If walletB had extended credit to walletA, the transfer would succeed but instead of sending the Bitstamp IOUs walletA would issue its own IOUs to walletB. This is all fine, except that having done that I was then not capable redeeming walletA's IOU from walletB to Bitstamp. I am always working under the assumption that both the V shaped transfer and the latter paragraph example (full circle?) are legal and are only failing due to something wrong with the found paths. The specific error 'Path could not send full amount.' (tecPATH_PARTIAL) appears to say that there aren't enough IOUs in the path to move the full amount transfered, which could be easily solved by taking the shortest path of no hops other than the wallets involved + the issuer, but I haven't looked at the actual code, so this is just a wild guess. |
|
|
|
This is an expanded path showing things like currencies even when they don't change. It's a rippling path with no exchanges involved, all in the same currency. The first node is Bitstamp. So the sender is going to return Bitstamp IOUs to Bitstamp and in return Bitsamp will issue IOUs to rhR5j5LXsujSuwG2bcn1P39utdTA79ceaW. In exchange for the Bitstamp IOUs, rhR5j5LXsujSuwG2bcn1P39utdTA79ceaW will issue their own IOUs to rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E, who will in turn issue their own IOUs to the recipient.
So rKLw2zHgA31nRZN3erfZkfR8uhAkQ8s95P wants to send to rLDDq8ZGhCaVBP8MyYTifhCJzgWPQBjwpt. rKLw returns the IOUs it holds from Bitstamp and Bitstamp issues a new set of IOUs to rhR5j5LXsujSuwG2bcn1P39utdTA79ceaW. This in turn issues own IOUs to rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E which issues own IOUs to rLDDq8ZGhCaVBP8MyYTifhCJzgWPQBjwpt. Why the extra hops if rLDDq8ZGhCaVBP8MyYTifhCJzgWPQBjwpt trusts Bitstamp? And these IOUs from rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E, are they still Bitstamp IOUs as far as the recipient is concerned? It might just be late here, but I fail to understand why this "complicated" path would ever need to take place, unless there's already an outstanding balance between the multiple nodes that would get settled with this transaction. |
|
|
|
In this case, the paths are alternative ways of performing the transfer. In a more complex case, the paths may be needed together to accomplish the full transfer.
Supplying multiple paths also ensures that the transaction succeeds even if the state has changed between when the transaction is formed and when it is processed. When the final transaction is executed, the paths are taken incrementally to ensure the best rate (from those paths) is given. The rate can change as IOUs are pushed through a path for two reasons: 1) If the path includes an order book, you can exhaust the best offer and have to move to an inferior offer. 2) If the path switches from redeeming IOUs to issuing IOUs, the rate can change. (You have to accept your own IOUs at face value, but you can devalue someone else's.)
To explain 2 in a little more detail, say I hold your IOUs and payment path goes from me to you. So long as I hold your IOUs, I can give them to you and you must honor them at face value. However, when I run out of IOUs, if you have extended credit to me, the path can still work with you getting my IOUs instead of me giving you yours. This can result in a different rate because the issuer of the IOUs and the direction they move has changed.
In 1) will order books ever be used automatically, i.e. if I send USD but only have BTC, or is that limited to when dealing directly with orders? As for 2) that is pretty smart, I must say. It does not apply to the case where both sides of a trade trust a common exchange but not one another, right? |
|
|
|
|
So the 3 paths I see are actually 2 paths and are alternative ways of proceeding with the transfer? Could you take the first one and convert it to an english sentence?
|
|
|
|
{u'paths_computed':
[
[
{u'currency': u'BTC', u'account': u'rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B', u'type': 49,
u'type_hex': u'0000000000000031', u'issuer': u'rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B'},
{u'currency': u'BTC', u'account': u'rh7eAu9SrFsE2fVfc1PJTs1WYDHGAUde6V', u'type': 49,
u'type_hex': u'0000000000000031', u'issuer': u'rh7eAu9SrFsE2fVfc1PJTs1WYDHGAUde6V'},
{u'currency': u'BTC', u'account': u'rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E', u'type': 49,
u'type_hex': u'0000000000000031', u'issuer': u'rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E'}
],
[
{u'currency': u'BTC', u'account': u'rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B', u'type': 49,
u'type_hex': u'0000000000000031', u'issuer': u'rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B'},
{u'currency': u'BTC', u'account': u'rh7eAu9SrFsE2fVfc1PJTs1WYDHGAUde6V', u'type': 49,
u'type_hex': u'0000000000000031', u'issuer': u'rh7eAu9SrFsE2fVfc1PJTs1WYDHGAUde6V'},
{u'currency': u'BTC', u'account': u'rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E', u'type': 49,
u'type_hex': u'0000000000000031', u'issuer': u'rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E'}
],
[
{u'currency': u'BTC', u'account': u'rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B', u'type': 49,
u'type_hex': u'0000000000000031', u'issuer': u'rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B'},
{u'currency': u'BTC', u'account': u'rhR5j5LXsujSuwG2bcn1P39utdTA79ceaW', u'type': 49,
u'type_hex': u'0000000000000031', u'issuer': u'rhR5j5LXsujSuwG2bcn1P39utdTA79ceaW'},
{u'currency': u'BTC', u'account': u'rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E', u'type': 49,
u'type_hex': u'0000000000000031', u'issuer': u'rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E'}
]
],
u'source_amount': {u'currency': u'BTC', u'value': u'0.0501', u'issuer': u'rKLw2zHgA31nRZN3erfZkfR8uhAkQ8s95P'},
u'paths_canonical': []}
So I guess I'm getting 3 potential credit lines that could be used, but the first 2 are exactly the same, are they now? Can you help me understand what I'm looking at above (a pointer to the documentation is fine)? FYI this is one case where I would assume the transfer should be possible but it fails with the partial path error. |
|
|
|
Thank you, Joel. It works, so please note that the wiki is wrong here  No on to parsing the result... |
|
|
|
In trying to jump in to find out why I'm having issues and which paths are being involved, I tried calling the ripple_path_find RPC command, according to the instructions on the wiki https://ripple.com/wiki/RPC_API#ripple_path_find but it is failing complaining about invalid arguments: Request: {"destination_amount": "0.05", "source_currencies": [{"currency": "BTC"}], "command": "ripple_path_find", "source_account": "rKLw2zHgA31nRZN3erfZkfR8uhAkQ8s95P", "destination_account": "rLDDq8ZGhCaVBP8MyYTifhCJzgWPQBjwpt"} Response: {u'status': u'error', u'error_code': 23, u'error_message': u'Invalid parameters.', u'request': {u'destination_amount': u'0.05', u'source_currencies': [{u'currency': u'BTC'}], u'command': u'ripple_path_find', u'source_account': u'rKLw2zHgA31nRZN3erfZkfR8uhAkQ8s95P', u'destination_account': u'rLDDq8ZGhCaVBP8MyYTifhCJzgWPQBjwpt'}, u'error': u'invalidParams', u'type': u'response'} Any clues into what I'm doing wrong? |
|
|
|
|
I will gladly take this offer for the right price, but I can't really say what that is... Just taking BTC as reference, how is that rate currently? Last I checked it was roughly 1BTC/100k XRP. 1 ltc was 0.004 btc so 400 lyc/100k xrp?
|
|
|
|
|
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.
|
|
|
|
The only BTC funds that rKLw2zHgA31nRZN3erfZkfR8uhAkQ8s95P holds are 0.1 rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B IOUs. The issuer of those IOUs charges a .2% transfer fee when its IOUs are moved from one customer to another, so the most you can deliver is 0.0998003992015968 BTC.
Yes, 0.1, sorry for confusing things. 0.15 was on the other use case. Still, if you look at the transfer I'm attempting you'll see I only try to move 0.019960 BTC (that's 0.02 minus the 0.2%) and that fails. I try a second transfer for 0.08 minus 0.2% and that fails in exactly the same way. I never try to move more than 0.0998. I'll try everything from the start in a bit and will let you know if the result is somehow different. |
|
|
|
|
I'm one of the responsible parties for TAABL.
Thank you very much for reporting this, I have paused the Pipe Pick in question and will try to contact BitCoiner2012 regarding this issue.
|
|
|
|
|
It's pretty much the exact same, I'm afraid. Full amount (0.15) complains about partial amounts, less (0.1) complains about fees.
I created another wallet for holding funds for one of my services, and for playing with the RPC interface. I was trying to make payments in very much the same manner, i.e:
- Deposited BTC to Bitstamp
- Withdrawn from Bitstamp to Ripple
- Tried to send from Ripple to another account that trusts Bitstamp (but not the sender)
{'Account': 'rKLw2zHgA31nRZN3erfZkfR8uhAkQ8s95P', 'Destination': u'rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E', 'Amount': {'currency': u'BTC', 'value': '0.019960', 'issuer': u'rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B'}, 'TransactionType': 'Payment'}
{u'status': u'success', u'type': u'response', u'result': {u'tx_json': {u'status': u'invalid', u'Account': u'rKLw2zHgA31nRZN3erfZkfR8uhAkQ8s95P', u'Fee': u'10', u'hash': u'097BDC7AA77F3FDF7A73D850D69F70AEF8AC7705E2616D5BB6E287EB3886B183', u'Sequence': 10, u'SigningPubKey': u'02BCB4677183FD6B5654E10AED5AD04007480950C2652852DFAE4AE4C98A9D3EF0', u'Destination': u'rGwUWgN5BEg3QGNY3RX2HfYowjUTZdid3E', u'Amount': {u'currency': u'BTC', u'value': u'0.01996', u'issuer': u'rvYAfWj5gh67oV6fW32ZzP3Aw4Eubs59B'}, u'Flags': 0, u'TxnSignature': u'30450220395913ABE851C103E72C8F29531EFF745B82C35DCE6DB1A22E8B78D24B71032B0221009 89E7089D9A0D357908DDB78C9052F74B8FB81C7F2B847677B75F02CF80E4489', u'TransactionType': u'Payment'}, u'engine_result_message': u'Path could not send full amount.', u'engine_result_code': 101, u'tx_blob': u'1200002200000000240000000A61D4071759F6F8C00000000000000000000000000042544300000 000000A20B3C85F482532A9578DBB3950B85CA06594D168400000000000000A732102BCB4677183 FD6B5654E10AED5AD04007480950C2652852DFAE4AE4C98A9D3EF0744730450220395913ABE851C 103E72C8F29531EFF745B82C35DCE6DB1A22E8B78D24B71032B022100989E7089D9A0D357908DDB 78C9052F74B8FB81C7F2B847677B75F02CF80E44898114C9122B5BAFD0FF74863351B569DF2894B 6A011FE8314A6473D67D54E36ED960CC45526D78345C96FAE5A', u'engine_result': u'tecPATH_PARTIAL'}}
The rKLw account has 0.15 btc IOU from Bitstamp, the rGwU account trusts Bitstamp for 1 BTC, the rvYA account is Bitstamp. Am I doing something wrong or is this just another case of bad path resolve?
|
|
|
|
Thank you for the pointer. Turns out this initial request I made was right in front of my face and I just failed to see it; https://ripple.com/wiki/RPC_API#account_linesI still have to filter the currencies and there's no batching which may make things hard with huge ledgers, but it is there and is real easy. |
|
|
|
|
Ok, so I have been hard at understanding the whole ripple concept and it has spawned some neat ideas. As a coder I tend to try and understand frameworks in as much of a hands on approach as possible, so I thought I'd ask those who are in the know how to go about this.
The history and all transactions are public, so I could parse my way through said history to get to the information I need, but is there a simpler way? I want to know, for a specific currency and issuer, who is holding IOUs and how much each wallet has, say I want to know every wallet that has Bitstamp BTCs and how many of them they have.
|
|
|
|
|
Show Posts
