Jump to content

mDuo13

Ripple Employee
  • Posts

    561
  • Joined

  • Last visited

  • Days Won

    18

mDuo13 last won the day on January 27 2017

mDuo13 had the most liked content!

Profile Information

  • Gender
    Not Telling
  • Ripple Address
    ra5nK24KXen9AHvsdFTKHSANinZseWnPcX

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

mDuo13's Achievements

  1. Sorry I'm a little late on this, but I just want to emphasize that doing it this way is insecure: The server now has the secret key, so anyone with access to the server has full access to the accounts of everyone using the client-side app If the connection between the client and server is not encrypted (http not https for example) or is compromised (using an outdated/broken encryption scheme for example) then people in the middle (on the same wifi, or in the same datacenter as your server, or running network gear, etc. etc.) could listen for secrets and gain access to those accounts The server logs could accidentally include secrets that users submitted, so anyone browsing or backing up the log files would be able to get access to any accounts whose secrets were leaked in this way You want to perform signing on the client side using a client library like ripple-lib. Either of the following flows would be fine: Send the address, receiving address, and amount to the server. Server sends back a filled-out transaction JSON with all the other details filled in except the signature. Client side signs the transaction using the user-input secret and sends the signed transaction back. Use the address, receiving address, and amount on the client-side to construct and sign a transaction. Send the signed transaction blob to the server for it to submit to the network and follow up on.
  2. Automatic transaction (re-)submission is the big one. Otherwise, it's just a bunch of sugar to simplify access to some things and rename stuff that has confusing names in the rippled APIs. And since Ripple-REST has been unmaintained for several years now, it's incapable of processing a bunch of new transaction types, and I think there was at least one unfixed bug that could cause it to (re-?)submit a transaction with a really high fee (>10 XRP, though I don't remember too well). You're better off using the rippled APIs directly or using a client library if your preferred language has one. Python and now Java libraries have come out just recently. I wonder if you could use https://github.com/ripple/xrpl-dev-portal/blob/master/assets/js/apitool-methods-ws.js as a basis for expanding or testing your postman collection. I haven't used modern Postman much but that file I linked is the one the WebSocket Tool uses to list the methods, and has a bunch of examples that pull up real data on mainnet. The JSON-RPC version would be very similar (just ignore the "id" field and skip the "subscribe"/"unsubscribe" and "path_find" methods).
  3. The XRPCharts list is not actively maintained and hasn't been for quite a while, so it's not the most reliable. But if you want the master list, it's here: https://github.com/ripple/rippled-historical-database/blob/d20ab42fc983cd394bc0dcca27a6ae3bdedaa891/api/gateways/gateways.json
  4. If you look at the account_tx (JSON-RPC/WebSocket) or getTransactions (ripple-lib aka RippleAPI) for the issuer's address, the results should include all transactions transferring the token from one address to another since those transactions ripple through the issuer.
  5. The response to the submit command includes information about whether the transaction was broadcast to the network. The details of that and a bunch of other stuff are on xrpl.org
  6. It's great that you've done this! I noticed a couple really minor inaccuracies—for example, the validators command is not exclusive to validators; you can run that on any server (as long as you're the server's admin) to get info about the validators it trusts. But overall, it's a nice walk through the steps to setting up a validator and it's great to have it all in a PDF form!
  7. I've opened a PR to add a note to that page about the same thing. https://github.com/ripple/xrpl-dev-portal/pull/989
  8. Not sure which explorers check for TOML-file account verification but that's also an option. (You set the Domain field of your account in the XRPL to a domain you own, then host a /.well-known/xrp-ledger.toml file with the account name at the domain and an optional description.)
  9. If you built it yourself from source it doesn't automatically set up the systemd unit files. You have to put those in the right place first and then do the systemctl commands as mentioned here
  10. The initial result from the submit command is preliminary. The transaction has to get propagated through the network to the validators to be incorporated in a validated ledger. (If the transaction has a LastLedgerSequence, then it has to make it before that ledger index gets validated. Otherwise it could potentially get validated at any time in the future as long as its Sequence number doesn't get used by another tx from the same sending address.) If you're getting a preliminary success but then the transaction doesn't make it into a validated ledger, then my best guess is that—at the time the error occurred—the server did not have any peers who could pass the transaction along to the network. It's not entirely clear why that was the case, but forwarding the port as I mentioned should help. It's also possible that your server had some mainnet servers occupying its peer slots, which is a waste since neither side gets anything useful from that. You could try adding an explicit network_id stanza to your config so your server & its peers more quickly realize if they're not following the same network and disconnect from each other: [network_id] testnet You could also check https://s.altnet.rippletest.net:51235/crawl and add some of the IPs there as explicit peers in the [ips] stanza. Those are just whichever peers are currently connected to one of Ripple's testnet public servers (whichever member of the cluster you happen to get) so I can't guarantee they're high-quality peers, but it's likely they're at least on Testnet. It's also possible you just had a temporary network outage that caused the server to lose its connection to its peers (who then filled up their slots with other peer connections). Again, forwarding the port can make a difference, since in general it seems a lot more servers are willing to make outbound than accept inbound connections.
  11. I am seeing a large number of transitions recorded between the full, syncing, and tracking states, which confirms that your server has been temporarily losing sync with the network for some reason (though it's currently synced at the time of this server_info response). Based on the ledger index, it looks like you're on Testnet? BTW, re: the warning that protocol amendments it doesn't understand have reached supermajority—you can safely ignore that for now. A few new amendments have temporarily gained a majority there (because Ripple upgraded Testnet validators to 1.7.0-rc1) but that shouldn't be a problem for now. It's not the reason for your desyncs at least. Under most other circumstances you should take that warning seriously; it means you have less than 2 weeks to upgrade before you become amendment blocked, unless the amendments don't hold the >80% supermajority. But like I said, in this case it's fine. 18 peer disconnects may or may not be the cause of your problem. The 10 peers suggests that you're behind a firewall or NAT which is preventing incoming peer-to-peer connections. Just forwarding TCP on port 51235 may help your server maintain more quality, stable peer-to-peer connections and thus better connectivity to the XRP Ledger network in general. Otherwise, I don't see any obvious clues or red flags in the data. You can always double check the usual suspects; maybe your network connection had a couple blips or something?
  12. As several other posters have stated, old accounts were "grandfathered" in; or, more accurately, it didn't bother to change stuff that was already recorded in the ledger. If your account was funded (received its first 20+ XRP payment) before deletable accounts went live, then its first sequence number was 1 (and still is, if it has never sent a transaction). If your account was funded after deletable accounts went live, its first sequence number was the ledger index at the time it was funded. And thereafter, no matter what, its sequence number went up by 1 each time you sent a transaction¹ and will continue to work that way. The only thing that matters for Sequence numbers is: what is your account's sequence number now? If you have the address, anyone can look it up with account_info. Then just use whatever your account's current Sequence number is when you construct the transaction. ¹ Since you mentioned Tickets, they are an upcoming exception to this rule; a single TicketCreate transaction can increase your account's Sequence number by as much as 250 all at once. Tickets are a way of setting aside Sequence numbers to be used by later transactions that can be sent at any time, out of the usual order. You can read the standards draft for more details. Slight correction on this point: Your Sequence number only goes up when you send a transaction, not when you receive anything. So if you've never sent a transaction and the account was funded pre-deletable accounts, the first transaction you send should have Sequence number 1, not 2. When constructing and signing transactions entirely offline, you need to explicitly provide the Sequence and Fee fields since they can't be added automatically, plus any other required fields of the transaction. And I'm not sure what tool you're using to sign the transaction, but it should probably point you towards the problem if there's something else wrong with the instructions you provided. Without seeing an error message, it's pretty hard to figure out what actually went wrong. (Do double-check to make sure to scrub out any secrets before you post anything like that publicly, though, just in case.)
  13. First off, if you want to create your own validator list site / publisher, be aware that doing so can create a situation where it is possible to unintentionally fork away from the main network. Your list must have >90% overlap with another person's list to completely eliminate the chances that you and that person end up following different chains. Second, the steps from many of your examples describe how to configure one validator, but then you're asking about setting up an entire list of validators. Keep in mind that one of the most important aspects of a validator list is that it has a diverse set of validators, not just a list of validators all run by one entity, because that's what makes the network decentralized and fault-resistant (protecting against both intentional fraud and accidental problems). If you're creating a validator list for anything other than a private test network, you should think long and hard about whether you can verify that the validators on your list are actually separate entities, that they're all reliable, and that you're going to keep updating it long enough to be better than the validator lists that already exist. And if you're only doing it for a private test network, it's much easier to explicitly list validators you trust in your config file and skip the validator list site thing. If you do want to provide a validator list site, the complete format of this list must match what the server expects. This is the same as the response format from the Validator List method, documented here: https://xrpl.org/validator-list.html . I'm not aware of any open-source tools that can quickly put everything together in this format, but it's made from a bunch of standard parts like JSON, base64, and hexadecimal—so if you're motivated enough, you should be able to figure it out. The manifest data involves serializing some things to binary in the XRP Ledger's standard format, and you need to be able to sign various data using a secp256k1 ECDSA key pair; the publisher should use a different key pair than any of the validators on the list, by the way. And be very careful with the publisher keypair, since that's the only thing that proves the integrity of your list. If that all sounds daunting, maybe you should reconsider whether you really want to be publishing a list site. Again, if all you want to do is stand up a test network or something, you can list the validator keys explicitly in the [validators] stanza of rippled.cfg or validators.txt. You'll have to remove/comment out any existing validator stanzas in those files, and you may want to delete the databases to remove any cached references to peers who aren't following your test network. You may want to add a unique [network_id] to discourage your servers and ones on different chains from accidentally talking to each other, since they mostly won't agree on what's happening so it's a waste of a peer-to-peer connection.
  14. The only difference between "amending the protocol" and "forking the network" is how many people go along with you. If it's (basically) everyone, you've amended it. If some people don't like your changes and refuse to go along with them, you've forked. Therefore, we can see that the most important power in amending the protocol is the power of persuasion. In fact, this thread is a case of @shekenahglory exercising grassroots power in an attempt to amend the protocol. Personally, I don't feel persuaded yet. I think there's the kernel of a good idea here, in that it would be nice if XRP holders could express a position on various governance functions, but I think practically speaking it has all the problems of direct ballot proposition / initiatives (if you don't live in a jurisdiction with these, there are plenty of pitfalls with the system) but with even more power for XRP whales to control the process. If you go by total XRP held (excluding escrows) that just a few wallets can exercise enough voting power to drown out the rest. (The top 100 accounts hold over 65% of non-escrowed XRP.) If you go by accounts, you're just incentivizing those rich accounts to spam the ledger with accounts so they can buy more votes (recouping their costs for a net of about 5 XRP per vote after deleting.) Another challenge that seems like it could prove problematic is that we don't know what percentage of XRP is held by accounts whose keys have been lost. If, say, 10% of all XRP is held by accounts that will never vote no matter how their supposed owners feel, then the supermajority threshold could be even more difficult to attain than intended.
  15. The pathfinding in rippled is not guaranteed to find all possible paths, but it's not strictly length-limited. Rather, it has several "templates" for paths that it checks depending on what you're asking for, who's asking (i.e. server admins can make more expensive pathfinding requests than public API users), and how busy the server is. In the code the templates have funny abbreviations like "sxd" (source → xrp → destination), "safad" (source → rippling to another account → use an order book to convert to the final output currency → rippling to another account → destination) and so on.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.