Jump to content

Search the Community

Showing results for tags 'rippled'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Ripple
    • Please Read Before Posting
    • Press
    • General Discussion
    • Technical Discussion
    • Marketplace
  • Interledger Protocol
    • Interledger Protocol Discussion
  • Other Technology
    • Alt-Coins and Non-Ripple Fintech
  • More
    • Off-Topic
    • Meta
    • Languages
  • Canadian Zerpers's Topics
  • Vegemite Ripplers's Topics
  • 2 the Moon! For Real. The Club's Topics
  • NY Zerpers - aka bitlicense island's Topics
  • Brackish Waters Club's Topics
  • Trading Places's Topics
  • Anti-Club Club's Topics
  • The Irish Brigade's Topics
  • Blue Martini Saloon's Request
  • XRP Trading And Price Speculation's Topics
  • Alt-Coin Trading And Price Speculation's Topics
  • Super serious Ripple club's Topics
  • Making Millions!'s Topics
  • Ripple - India's Topics
  • SWELL's Topics
  • Gospel Hour's Topics
  • Korean XRP Holders's Topics

Calendars

  • Ripple Events
  • Vegemite Ripplers's Events
  • 2 the Moon! For Real. The Club's Timeline
  • NY Zerpers - aka bitlicense island's Events
  • Brackish Waters Club's Events
  • Trading Places's Events
  • Anti-Club Club's Events
  • The Irish Brigade's Events
  • Blue Martini Saloon's Calendar
  • XRP Trading And Price Speculation's Events
  • Alt-Coin Trading And Price Speculation's Events
  • Super serious Ripple club's Events
  • Making Millions!'s Events
  • Ripple - India's Events
  • SWELL's Events
  • Gospel Hour's Events
  • Korean XRP Holders's Events

Found 26 results
Minimum search term is 4 characters long. Can't find what you want? Click here for the custom google search instead.

  1. Wow guys, what a horrible day. It only seems like its going to get worse. Looks like there is absolutely no buy support as the bears are demolishing the price of XRP. It may even end up cheaper than when the AMEX partnership was announced. Crazy right? I really don't get it. What I do get is that lots of people are probably losing money at this point on this trade if they bought on the way up. This is another pump and dump. Sickening. I'm tired of Ripple doing this every single time. I have made so much more money with Stellar Lumens. I'll keepp Holding because you don't realize a loss until you sell, but my God this is frustrating. Not to mention the opportunity cost since you are basically stuck in a trade. Will we ever catch a real break with XRP? God help us!
  2. Routing attacks

    I have been reading about Bitcoin routing attacks and I'm wondering how things differ with Ripple. Quick summary of what I read: Bitcoin uses a general gossip protocol which broadcasts all transactions to the network. Internet routing infrastructure is insecure and can easily be manipulated by attackers to intercept Bitcoin traffic. Bitcoin messages are exchanged in clear text and without integrity checks, any (malicious) third-party on the forwarding path can eavesdrop, drop, modify, inject, or delay Bitcoin messages. Bitcoin is extremely centralized from an Internet routing perspective. (Only 13 ASes host 30% of the entire network, while 50 ASes host 50% of the Bitcoin network.) Any malicious ISP with access to the Internet routing infrastructure can perform a routing attack by partitioning the Bitcoin network and isolating 50% of its mining power. Any ISP transiting Bitcoin traffic can delay the propagation of mined blocks (for up to 20 minutes), in a stealth way. Many examples of actual routing attacks that ended up diverting Bitcoin traffic have been found. So, how does Ripple differ? How are transactions broadcast? I'm assuming end-to-end encryption isn't used, because then validators wouldn't be able to see what they're validating?
  3. Hi, I am running two servers locally (ledger fork), it seems to be working. So far I've created two new accounts and sent XRP to both from the genesis acct. I then created trust-lines from the new accounts to the genesis acct and issued IOU currency from the genesis to the other two accounts. I've preformed multiple transfer operations via API and sent IOU back and forth. Rippling worked well, all transfers were completed and I was able to verify balances via API. Now I'd like to view the transaction details for each account, but not getting the desired result. to view account_lines on the genesis account: /opt/ripple/bin/rippled account_lines rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh { "id" : 1, "result" : { "account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "ledger_current_index" : 158533, "lines" : [ { "account" : "rhBwgZf5dA5HbWJKnrztePviUQmWTf4kwh", "balance" : "-1120", "currency" : "USD", "limit" : "0", "limit_peer" : "91500", "quality_in" : 0, "quality_out" : 0 }, { "account" : "rHfx7bE1USYJE5Vmh9VbVFrJbc4a76tu4s", "balance" : "-10000", "currency" : "USD", "limit" : "0", "limit_peer" : "86500", "quality_in" : 0, "quality_out" : 0 } ], "status" : "success", "validated" : false } } seems to be correct. The same information is displayed after I stop both servers, meaning they are in sync and persistence is working? /opt/ripple/bin/rippled account_info rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh validated: { "id" : 1, "result" : { "account_data" : { "Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "Balance" : "99997649999448428", "Flags" : 8388608, "LedgerEntryType" : "AccountRoot", "OwnerCount" : 0, "PreviousTxnID" : "C86538FAED7912EFE185B322907B0FEED47C870ED612D6519F726E98AAFEA8F7", "PreviousTxnLgrSeq" : 128917, "Sequence" : 132, "index" : "2B6AC232AA4C4BE41BF49D2459FA4A0347E1B543A4C92FCEE0821C0201E2E9A8" }, "ledger_hash" : "9B697B5B93794270C837464A5ABA757066B9646D5DB1BF588BC7DE548A051E60", "ledger_index" : 158492, "status" : "success", "validated" : true } } I'd like to see transaction details for the PreviousTxnID: /opt/ripple/bin/rippled tx C86538FAED7912EFE185B322907B0FEED47C870ED612D6519F726E98AAFEA8F7 { "id" : 1, "result" : { "error" : "txnNotFound", "error_code" : 28, "error_message" : "Transaction not found.", "request" : { "command" : "tx", "transaction" : "C86538FAED7912EFE185B322907B0FEED47C870ED612D6519F726E98AAFEA8F7" }, "status" : "error" } } Transaction not found, why? I've read this article about this error but not sure what to do to fix this: https://ripple.com/build/reliable-transaction-submission/ how can I check/test both cases? also not getting any luck if I try to view all transactions for the genesis account: /opt/ripple/bin/rippled account_tx rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh { "id" : 1, "result" : { "error" : "lgrNotValidated", "error_code" : 21, "error_message" : "Ledger not validated.", "request" : { "account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "command" : "account_tx" }, "status" : "error" } } further troubleshooting, viewing account_object, not sure what to pay attention to here: /opt/ripple/bin/rippled account_objects rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh { "id" : 1, "result" : { "account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "account_objects" : [ { "Balance" : { "currency" : "USD", "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", "value" : "1120" }, "Flags" : 65536, "HighLimit" : { "currency" : "USD", "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "value" : "0" }, "HighNode" : "0000000000000000", "LedgerEntryType" : "RippleState", "LowLimit" : { "currency" : "USD", "issuer" : "rhBwgZf5dA5HbWJKnrztePviUQmWTf4kwh", "value" : "91500" }, "LowNode" : "0000000000000000", "PreviousTxnID" : "4409963786C92939C3220E9C2E0D46A418D9D4E14C88969F0A132130173BF411", "PreviousTxnLgrSeq" : 151601, "index" : "B13A9EC73431FC0B319389ABA44DE1FBBFD849FFBE27816C7A4B9DD826B503C0" }, { "Balance" : { "currency" : "USD", "issuer" : "rrrrrrrrrrrrrrrrrrrrBZbvji", "value" : "10000" }, "Flags" : 65536, "HighLimit" : { "currency" : "USD", "issuer" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "value" : "0" }, "HighNode" : "0000000000000000", "LedgerEntryType" : "RippleState", "LowLimit" : { "currency" : "USD", "issuer" : "rHfx7bE1USYJE5Vmh9VbVFrJbc4a76tu4s", "value" : "86500" }, "LowNode" : "0000000000000000", "PreviousTxnID" : "4409963786C92939C3220E9C2E0D46A418D9D4E14C88969F0A132130173BF411", "PreviousTxnLgrSeq" : 151601, "index" : "C29A2B914AF8B5B5C1C18235AC96D22B090D02E1F593ABC7DD537C2BE8D8A398" } ], "ledger_current_index" : 158646, "status" : "success", "validated" : false } } here's my server_state: { "id" : 1, "result" : { "state" : { "build_version" : "0.70.1", "complete_ledgers" : "156002-158575", "io_latency_ms" : 1, "last_close" : { "converge_time" : 2000, "proposers" : 1 }, "load" : { "job_types" : [ { "in_progress" : 1, "job_type" : "clientCommand" }, { "job_type" : "peerCommand", "per_second" : 1 } ], "threads" : 8 }, "load_base" : 256, "load_factor" : 256, "peers" : 1, "pubkey_node" : "n9KHec9cJXXgaHT4nYCQQgCq3Miaz4tXab9HPNAVPUfCkZiThmfy", "pubkey_validator" : "none", "server_state" : "full", "state_accounting" : { "connected" : { "duration_us" : "3003948", "transitions" : 1 }, "disconnected" : { "duration_us" : "1238259", "transitions" : 1 }, "full" : { "duration_us" : "2191436885", "transitions" : 1 }, "syncing" : { "duration_us" : "2001013", "transitions" : 1 }, "tracking" : { "duration_us" : "7", "transitions" : 1 } }, "uptime" : 2198, "validated_ledger" : { "base_fee" : 10, "close_time" : 556986221, "hash" : "3F8EB07A93F31F8E83589E7377819C559D85EAFD2568F87ABB574F95C1A452B1", "reserve_base" : 20000000, "reserve_inc" : 5000000, "seq" : 158575 }, "validation_quorum" : 1 }, "status" : "success" } } and server_info: { "id" : 1, "result" : { "info" : { "build_version" : "0.70.1", "complete_ledgers" : "156002-158582", "hostid" : "osboxes", "io_latency_ms" : 1, "last_close" : { "converge_time_s" : 1.999, "proposers" : 1 }, "load" : { "job_types" : [ { "in_progress" : 1, "job_type" : "clientCommand" } ], "threads" : 8 }, "load_factor" : 1, "peers" : 1, "pubkey_node" : "n9KHec9cJXXgaHT4nYCQQgCq3Miaz4tXab9HPNAVPUfCkZiThmfy", "pubkey_validator" : "none", "server_state" : "full", "state_accounting" : { "connected" : { "duration_us" : "3003948", "transitions" : 1 }, "disconnected" : { "duration_us" : "1238259", "transitions" : 1 }, "full" : { "duration_us" : "2211203188", "transitions" : 1 }, "syncing" : { "duration_us" : "2001013", "transitions" : 1 }, "tracking" : { "duration_us" : "7", "transitions" : 1 } }, "uptime" : 2218, "validated_ledger" : { "age" : 2, "base_fee_xrp" : 1e-05, "hash" : "FFFEFFE38B65DE96DD5E4108114B5B68306574D97D3C082B8234D985F42C6028", "reserve_base_xrp" : 20, "reserve_inc_xrp" : 5, "seq" : 158582 }, "validation_quorum" : 1 }, "status" : "success" } } any help would be greatly appreciated!
  4. I am trying to send a payment using ripple-lib, and I am getting this error: Here is my code: Thanks so much!
  5. I am wondering about the implications of opening port 51235 on a rippled validator or node (running in front of a validator). I assume doing so would carry a risk of DDoS attacks, however, it also provides other nodes with access to the ledger. In other words, it seems like there is a minor security risk and a reasonable benefit for the community. From what I understand, rippled nodes will connect to any peer to get the ledger. Is this so, or do they only connect to trusted peers? Finally, is there any reason to include my IP in the [ips] section on my ripple.txt, if port 51235 is closed? Thanks so much!
  6. Hi, I am running two VMs with rippled servers, one as stock and another as validator. I started the stock server with -a, then I stopped and restarted it with --start. The config of the stock server is pointing to the validator. Then I started validator and both servers seem to be connected. I then submitted a transaction to send XRP from genesis address to a newly generated address. The transaction went through and XRP balances got updated. I can confirm this on both servers with "rippled account_info #ADDR#" for each account. Great, however then I stop the validator and restart it, expecting to see the same balances as they were prior to restart, however the ledger gets reset. The genesis account has an original amount in it and the newly created account to which I've transferred XRP in the previous session is no longer found. How come this is happening and what am I doing wrong with my setup? stock server log: 2017-Aug-16 13:13:16 NetworkOPs:NFO Consensus time for #1664 with LCL 7C6899F29DEABCC62AC4E85DD131AEC85F6EE1F058631B13412296C7C5B2C236 2017-Aug-16 13:13:16 LedgerConsensus:NFO Entering consensus process, watching 2017-Aug-16 13:13:18 Peer:WRN [022] onReadMessage: short read 2017-Aug-16 13:13:19 LedgerConsensus:NFO Proposers:1 nw:50 thrV:1 thrC:1 2017-Aug-16 13:13:19 LedgerConsensus:NFO Converge cutoff (1 participants) 2017-Aug-16 13:13:19 LedgerConsensus:NFO CNF buildLCL F6C117EC8731DC304A4B8DC7143D557840EA82B2B44F23DED11216F3882C2372 2017-Aug-16 13:13:19 LedgerConsensus:NFO We closed at 556204397 2017-Aug-16 13:13:19 LedgerConsensus:NFO 1 time votes for 556204397 2017-Aug-16 13:13:19 LedgerConsensus:NFO Our close offset is estimated at 0 (2) 2017-Aug-16 13:13:19 NetworkOPs:NFO Consensus time for #1665 with LCL F6C117EC8731DC304A4B8DC7143D557840EA82B2B44F23DED11216F3882C2372 2017-Aug-16 13:13:19 LedgerConsensus:NFO Entering consensus process, watching 2017-Aug-16 13:13:42 LedgerConsensus:NFO Converge cutoff (0 participants) 2017-Aug-16 13:13:42 LedgerConsensus:NFO CNF buildLCL 7F988A5EDDF16EBB0202FB879295DB3A2C8BCC722685F04162813841EFECCC17 2017-Aug-16 13:13:42 LedgerConsensus:NFO We closed at 556204420 2017-Aug-16 13:13:42 LedgerConsensus:NFO Our close offset is estimated at 0 (1) 2017-Aug-16 13:13:42 NetworkOPs:WRN We are not running on the consensus ledger 2017-Aug-16 13:13:42 NetworkOPs:NFO Our LCL: { "accepted" : true, "account_hash" : "1ECEF6EA6F3959C7A9A55A848F0D176261722E1009360965A5D00A5A3953D1A2", "close_flags" : 0, "close_time" : 556204420, "close_time_human" : "2017-Aug-16 13:13:40", "close_time_resolution" : 10, "closed" : true, "hash" : "7F988A5EDDF16EBB0202FB879295DB3A2C8BCC722685F04162813841EFECCC17", "ledger_hash" : "7F988A5EDDF16EBB0202FB879295DB3A2C8BCC722685F04162813841EFECCC17", "ledger_index" : "1665", "parent_close_time" : 556204400, "parent_hash" : "F6C117EC8731DC304A4B8DC7143D557840EA82B2B44F23DED11216F3882C2372", "seqNum" : "1665", "totalCoins" : "99999999999999988", "total_coins" : "99999999999999988", "transaction_hash" : "0000000000000000000000000000000000000000000000000000000000000000" } 2017-Aug-16 13:13:42 NetworkOPs:NFO Net LCL 7C6899F29DEABCC62AC4E85DD131AEC85F6EE1F058631B13412296C7C5B2C236 2017-Aug-16 13:13:42 NetworkOPs:NFO STATE->syncing 2017-Aug-16 13:13:42 NetworkOPs:ERR JUMP last closed ledger to 7C6899F29DEABCC62AC4E85DD131AEC85F6EE1F058631B13412296C7C5B2C236 2017-Aug-16 13:13:42 NetworkOPs:NFO Consensus time for #1664 with LCL 7C6899F29DEABCC62AC4E85DD131AEC85F6EE1F058631B13412296C7C5B2C236 2017-Aug-16 13:13:42 LedgerConsensus:NFO Entering consensus process, watching 2017-Aug-16 13:13:44 LedgerConsensus:WRN Removing stale proposal from BABF6A89E9113E8298A959982C186000CA11AB7F 2017-Aug-16 13:13:44 LedgerConsensus:NFO Converge cutoff (0 participants) 2017-Aug-16 13:13:44 LedgerConsensus:NFO CNF buildLCL 40F90A131285E06DCE0735A409C231E33300B02E806BC4FCBACB938109B541F4 2017-Aug-16 13:13:44 LedgerConsensus:NFO We closed at 556204422 2017-Aug-16 13:13:44 LedgerConsensus:NFO 1 time votes for 556204397 2017-Aug-16 13:13:44 LedgerConsensus:NFO Our close offset is estimated at -12 (2) 2017-Aug-16 13:13:44 TimeKeeper:NFO TimeKeeper: Close time offset now -3 2017-Aug-16 13:13:44 NetworkOPs:NFO STATE->tracking 2017-Aug-16 13:13:44 NetworkOPs:NFO STATE->full 2017-Aug-16 13:13:44 NetworkOPs:NFO Consensus time for #1665 with LCL 40F90A131285E06DCE0735A409C231E33300B02E806BC4FCBACB938109B541F4 2017-Aug-16 13:13:44 LedgerConsensus:NFO Entering consensus process, watching 2017-Aug-16 13:14:05 LedgerConsensus:NFO Converge cutoff (0 participants) 2017-Aug-16 13:14:05 LedgerConsensus:NFO CNF buildLCL 7E23BB3A1B11B01F223AEAB5553D3891673730A840509814DF607B4848C6EF32 2017-Aug-16 13:14:05 LedgerConsensus:NFO We closed at 556204440 2017-Aug-16 13:14:05 LedgerConsensus:NFO Our close offset is estimated at 0 (1) 2017-Aug-16 13:14:05 TimeKeeper:NFO TimeKeeper: Close time offset now -2 2017-Aug-16 13:14:05 NetworkOPs:WRN We are not running on the consensus ledger validator log: 2017-Aug-16 13:13:06 Resource:DBG Inactive "127.0.0.1" 2017-Aug-16 13:13:07 LedgerConsensus:DBG Checking for TX consensus: agree=0, disagree=0 2017-Aug-16 13:13:07 LedgerConsensus:DBG normal consensus 2017-Aug-16 13:13:07 LedgerConsensus:NFO Converge cutoff (0 participants) 2017-Aug-16 13:13:07 LedgerConsensus:DBG Report: Prop=yes val=yes corLCL=yes fail=no 2017-Aug-16 13:13:07 LedgerConsensus:DBG Report: Prev = 05111C39A3B43A640F9945C32633CBD5FC3A49556E000C3EF9DDE8F504AFD9E1:1659 2017-Aug-16 13:13:07 LedgerConsensus:DBG Report: TxSt = 0000000000000000000000000000000000000000000000000000000000000000, close 556204390 2017-Aug-16 13:13:07 LedgerConsensus:DBG Applying consensus set transactions to the last closed ledger 2017-Aug-16 13:13:07 LedgerConsensus:DBG Pass: 0 Txns: 0 retriable 2017-Aug-16 13:13:07 LedgerConsensus:DBG Pass: 0 finished 0 changes 2017-Aug-16 13:13:07 LedgerConsensus:DBG Pass: 1 Txns: 0 final 2017-Aug-16 13:13:07 LedgerConsensus:DBG Pass: 1 finished 0 changes 2017-Aug-16 13:13:07 LedgerConsensus:DBG Flushed 2 accounts and 1 transaction nodes 2017-Aug-16 13:13:07 LedgerConsensus:DBG Consensus built new ledger 2017-Aug-16 13:13:07 LedgerConsensus:DBG Report: NewL = 9B7DDDE79742F17F777AF38B050A482EB4BEAD43BB5AEC3E226D7934784E8F39:1660 2017-Aug-16 13:13:07 Validations:DBG Val for 9B7DDDE79742F17F777AF38B050A482EB4BEAD43BB5AEC3E226D7934784E8F39 from n9MX1GQr8jaH99jD5efJVQ8MaEbYrNxtwdE8opufGYd9Ww4GaMxK added trusted/current 2017-Aug-16 13:13:07 LedgerConsensus:NFO CNF Val 9B7DDDE79742F17F777AF38B050A482EB4BEAD43BB5AEC3E226D7934784E8F39 2017-Aug-16 13:13:07 LedgerMaster:NFO Advancing accepted ledger to 1660 with >= 1 validations 2017-Aug-16 13:13:07 LedgerHistory:DBG MATCH: seq=1660 2017-Aug-16 13:13:07 LedgerConsensus:DBG Consensus ledger fully validated 2017-Aug-16 13:13:07 LedgerConsensus:NFO We closed at 556204385 2017-Aug-16 13:13:07 LedgerConsensus:NFO Our close offset is estimated at 0 (1) 2017-Aug-16 13:13:07 NetworkOPs:DBG L: 9B7DDDE79742F17F777AF38B050A482EB4BEAD43BB5AEC3E226D7934784E8F39 t=1, n=1 2017-Aug-16 13:13:07 NetworkOPs:NFO Consensus time for #1661 with LCL 9B7DDDE79742F17F777AF38B050A482EB4BEAD43BB5AEC3E226D7934784E8F39 2017-Aug-16 13:13:07 ValidatorList:DBG 1 of 1 listed validators eligible for inclusion in the trusted set 2017-Aug-16 13:13:07 ValidatorList:DBG Using quorum of 1 for new set of 1 trusted validators 2017-Aug-16 13:13:07 LedgerConsensus:NFO Entering consensus process, validating 2017-Aug-16 13:13:07 LedgerMaster:DBG tryAdvance publishing seq 1660 2017-Aug-16 13:13:07 LedgerMaster:DBG Ledger 1660 accepted :9B7DDDE79742F17F777AF38B050A482EB4BEAD43BB5AEC3E226D7934784E8F39 2017-Aug-16 13:13:07 PathRequest:DBG updateAll complete: 0 processed and 0 removed 2017-Aug-16 13:13:07 NetworkOPs:DBG Initiating consensus engine 2017-Aug-16 13:13:07 NetworkOPs:DBG recvValidation 9B7DDDE79742F17F777AF38B050A482EB4BEAD43BB5AEC3E226D7934784E8F39 from 2 2017-Aug-16 13:13:07 Resource:DBG Expired "127.0.0.1" 2017-Aug-16 13:13:10 LedgerConsensus:DBG Checking for TX consensus: agree=0, disagree=0 2017-Aug-16 13:13:10 LedgerConsensus:DBG normal consensus 2017-Aug-16 13:13:10 LedgerConsensus:NFO Converge cutoff (0 participants) 2017-Aug-16 13:13:10 LedgerConsensus:DBG Report: Prop=yes val=yes corLCL=yes fail=no 2017-Aug-16 13:13:10 LedgerConsensus:DBG Report: Prev = 9B7DDDE79742F17F777AF38B050A482EB4BEAD43BB5AEC3E226D7934784E8F39:1660 2017-Aug-16 13:13:10 LedgerConsensus:DBG Report: TxSt = 0000000000000000000000000000000000000000000000000000000000000000, close 556204391 2017-Aug-16 13:13:10 LedgerConsensus:DBG Applying consensus set transactions to the last closed ledger 2017-Aug-16 13:13:10 LedgerConsensus:DBG Pass: 0 Txns: 0 retriable 2017-Aug-16 13:13:10 LedgerConsensus:DBG Pass: 0 finished 0 changes 2017-Aug-16 13:13:10 LedgerConsensus:DBG Pass: 1 Txns: 0 final 2017-Aug-16 13:13:10 LedgerConsensus:DBG Pass: 1 finished 0 changes 2017-Aug-16 13:13:10 LedgerConsensus:DBG Flushed 2 accounts and 1 transaction nodes 2017-Aug-16 13:13:10 LedgerConsensus:DBG Consensus built new ledger 2017-Aug-16 13:13:10 LedgerConsensus:DBG Report: NewL = 2384B44945FAD5E0C9929484C1FDCF699B3FC1AA63124434DA77E5D32AB29ABE:1661 2017-Aug-16 13:13:10 Validations:DBG Val for 2384B44945FAD5E0C9929484C1FDCF699B3FC1AA63124434DA77E5D32AB29ABE from n9MX1GQr8jaH99jD5efJVQ8MaEbYrNxtwdE8opufGYd9Ww4GaMxK added trusted/current 2017-Aug-16 13:13:10 LedgerConsensus:NFO CNF Val 2384B44945FAD5E0C9929484C1FDCF699B3FC1AA63124434DA77E5D32AB29ABE 2017-Aug-16 13:13:10 LedgerMaster:NFO Advancing accepted ledger to 1661 with >= 1 validations 2017-Aug-16 13:13:10 LedgerHistory:DBG MATCH: seq=1661 2017-Aug-16 13:13:10 LedgerConsensus:DBG Consensus ledger fully validated 2017-Aug-16 13:13:10 LedgerConsensus:NFO We closed at 556204388 2017-Aug-16 13:13:10 LedgerConsensus:NFO Our close offset is estimated at 0 (1) 2017-Aug-16 13:13:10 LedgerMaster:DBG tryAdvance publishing seq 1661 2017-Aug-16 13:13:10 LedgerMaster:DBG Ledger 1661 accepted :2384B44945FAD5E0C9929484C1FDCF699B3FC1AA63124434DA77E5D32AB29ABE 2017-Aug-16 13:13:10 NetworkOPs:DBG L: 2384B44945FAD5E0C9929484C1FDCF699B3FC1AA63124434DA77E5D32AB29ABE t=1, n=1 2017-Aug-16 13:13:10 NetworkOPs:NFO Consensus time for #1662 with LCL 2384B44945FAD5E0C9929484C1FDCF699B3FC1AA63124434DA77E5D32AB29ABE 2017-Aug-16 13:13:10 ValidatorList:DBG 1 of 1 listed validators eligible for inclusion in the trusted set 2017-Aug-16 13:13:10 ValidatorList:DBG Using quorum of 1 for new set of 1 trusted validators 2017-Aug-16 13:13:10 LedgerConsensus:NFO Entering consensus process, validating 2017-Aug-16 13:13:10 NetworkOPs:DBG Initiating consensus engine 2017-Aug-16 13:13:10 PathRequest:DBG updateAll complete: 0 processed and 0 removed 2017-Aug-16 13:13:10 NetworkOPs:DBG recvValidation 2384B44945FAD5E0C9929484C1FDCF699B3FC1AA63124434DA77E5D32AB29ABE from 2 2017-Aug-16 13:13:13 LedgerConsensus:DBG Checking for TX consensus: agree=0, disagree=0 2017-Aug-16 13:13:13 LedgerConsensus:DBG normal consensus 2017-Aug-16 13:13:13 LedgerConsensus:NFO Converge cutoff (0 participants) 2017-Aug-16 13:13:13 LedgerConsensus:DBG Report: Prop=yes val=yes corLCL=yes fail=no 2017-Aug-16 13:13:13 LedgerConsensus:DBG Report: Prev = 2384B44945FAD5E0C9929484C1FDCF699B3FC1AA63124434DA77E5D32AB29ABE:1661 2017-Aug-16 13:13:13 LedgerConsensus:DBG Report: TxSt = 0000000000000000000000000000000000000000000000000000000000000000, close 556204392 2017-Aug-16 13:13:13 LedgerConsensus:DBG Applying consensus set transactions to the last closed ledger 2017-Aug-16 13:13:13 LedgerConsensus:DBG Pass: 0 Txns: 0 retriable 2017-Aug-16 13:13:13 LedgerConsensus:DBG Pass: 0 finished 0 changes 2017-Aug-16 13:13:13 LedgerConsensus:DBG Pass: 1 Txns: 0 final 2017-Aug-16 13:13:13 LedgerConsensus:DBG Pass: 1 finished 0 changes 2017-Aug-16 13:13:13 LedgerConsensus:DBG Flushed 2 accounts and 1 transaction nodes 2017-Aug-16 13:13:13 LedgerConsensus:DBG Consensus built new ledger 2017-Aug-16 13:13:13 LedgerConsensus:DBG Report: NewL = 1CB109D4BF0933B7A6AC6E59D51CF910D3601AE5D1964C580609153A7663363D:1662 2017-Aug-16 13:13:13 Validations:DBG Val for 1CB109D4BF0933B7A6AC6E59D51CF910D3601AE5D1964C580609153A7663363D from n9MX1GQr8jaH99jD5efJVQ8MaEbYrNxtwdE8opufGYd9Ww4GaMxK added trusted/current 2017-Aug-16 13:13:13 LedgerConsensus:NFO CNF Val 1CB109D4BF0933B7A6AC6E59D51CF910D3601AE5D1964C580609153A7663363D 2017-Aug-16 13:13:13 LedgerMaster:NFO Advancing accepted ledger to 1662 with >= 1 validations 2017-Aug-16 13:13:13 LedgerHistory:DBG MATCH: seq=1662 2017-Aug-16 13:13:13 LedgerConsensus:DBG Consensus ledger fully validated 2017-Aug-16 13:13:13 LedgerConsensus:NFO We closed at 556204391 2017-Aug-16 13:13:13 LedgerConsensus:NFO Our close offset is estimated at 0 (1) 2017-Aug-16 13:13:13 NetworkOPs:DBG L: 1CB109D4BF0933B7A6AC6E59D51CF910D3601AE5D1964C580609153A7663363D t=1, n=1 2017-Aug-16 13:13:13 NetworkOPs:NFO Consensus time for #1663 with LCL 1CB109D4BF0933B7A6AC6E59D51CF910D3601AE5D1964C580609153A7663363D 2017-Aug-16 13:13:13 ValidatorList:DBG 1 of 1 listed validators eligible for inclusion in the trusted set 2017-Aug-16 13:13:13 ValidatorList:DBG Using quorum of 1 for new set of 1 trusted validators 2017-Aug-16 13:13:13 LedgerConsensus:NFO Entering consensus process, validating 2017-Aug-16 13:13:13 NetworkOPs:DBG Initiating consensus engine 2017-Aug-16 13:13:13 LedgerMaster:DBG tryAdvance publishing seq 1662 2017-Aug-16 13:13:13 LedgerMaster:DBG Ledger 1662 accepted :1CB109D4BF0933B7A6AC6E59D51CF910D3601AE5D1964C580609153A7663363D 2017-Aug-16 13:13:13 PathRequest:DBG updateAll complete: 0 processed and 0 removed 2017-Aug-16 13:13:13 NetworkOPs:DBG recvValidation 1CB109D4BF0933B7A6AC6E59D51CF910D3601AE5D1964C580609153A7663363D from 2 2017-Aug-16 13:13:14 InboundLedger:DBG Swept 0 out of 0 inbound ledgers. 2017-Aug-16 13:13:16 LedgerConsensus:DBG Checking for TX consensus: agree=0, disagree=0 2017-Aug-16 13:13:16 LedgerConsensus:DBG normal consensus 2017-Aug-16 13:13:16 LedgerConsensus:NFO Converge cutoff (0 participants) 2017-Aug-16 13:13:16 LedgerConsensus:DBG Report: Prop=yes val=yes corLCL=yes fail=no 2017-Aug-16 13:13:16 LedgerConsensus:DBG Report: Prev = 1CB109D4BF0933B7A6AC6E59D51CF910D3601AE5D1964C580609153A7663363D:1662 2017-Aug-16 13:13:16 LedgerConsensus:DBG Report: TxSt = 0000000000000000000000000000000000000000000000000000000000000000, close 556204393 2017-Aug-16 13:13:16 LedgerConsensus:DBG Applying consensus set transactions to the last closed ledger 2017-Aug-16 13:13:16 LedgerConsensus:DBG Pass: 0 Txns: 0 retriable 2017-Aug-16 13:13:16 LedgerConsensus:DBG Pass: 0 finished 0 changes 2017-Aug-16 13:13:16 LedgerConsensus:DBG Pass: 1 Txns: 0 final 2017-Aug-16 13:13:16 LedgerConsensus:DBG Pass: 1 finished 0 changes 2017-Aug-16 13:13:16 LedgerConsensus:DBG Flushed 2 accounts and 1 transaction nodes 2017-Aug-16 13:13:16 LedgerConsensus:DBG Consensus built new ledger 2017-Aug-16 13:13:16 LedgerConsensus:DBG Report: NewL = 7C6899F29DEABCC62AC4E85DD131AEC85F6EE1F058631B13412296C7C5B2C236:1663 2017-Aug-16 13:13:16 Validations:DBG Val for 7C6899F29DEABCC62AC4E85DD131AEC85F6EE1F058631B13412296C7C5B2C236 from n9MX1GQr8jaH99jD5efJVQ8MaEbYrNxtwdE8opufGYd9Ww4GaMxK added trusted/current 2017-Aug-16 13:13:16 LedgerConsensus:NFO CNF Val 7C6899F29DEABCC62AC4E85DD131AEC85F6EE1F058631B13412296C7C5B2C236 2017-Aug-16 13:13:16 LedgerMaster:NFO Advancing accepted ledger to 1663 with >= 1 validations 2017-Aug-16 13:13:16 LedgerHistory:DBG MATCH: seq=1663 2017-Aug-16 13:13:16 LedgerConsensus:DBG Consensus ledger fully validated 2017-Aug-16 13:13:16 LedgerConsensus:NFO We closed at 556204394 2017-Aug-16 13:13:16 LedgerConsensus:NFO Our close offset is estimated at 0 (1) 2017-Aug-16 13:13:16 NetworkOPs:DBG L: 7C6899F29DEABCC62AC4E85DD131AEC85F6EE1F058631B13412296C7C5B2C236 t=1, n=1 2017-Aug-16 13:13:16 LedgerMaster:DBG tryAdvance publishing seq 1663 2017-Aug-16 13:13:16 LedgerMaster:DBG Ledger 1663 accepted :7C6899F29DEABCC62AC4E85DD131AEC85F6EE1F058631B13412296C7C5B2C236 2017-Aug-16 13:13:16 NetworkOPs:NFO Consensus time for #1664 with LCL 7C6899F29DEABCC62AC4E85DD131AEC85F6EE1F058631B13412296C7C5B2C236 2017-Aug-16 13:13:16 ValidatorList:DBG 1 of 1 listed validators eligible for inclusion in the trusted set 2017-Aug-16 13:13:16 ValidatorList:DBG Using quorum of 1 for new set of 1 trusted validators 2017-Aug-16 13:13:16 LedgerConsensus:NFO Entering consensus process, validating 2017-Aug-16 13:13:16 NetworkOPs:DBG Initiating consensus engine 2017-Aug-16 13:13:16 PathRequest:DBG updateAll complete: 0 processed and 0 removed 2017-Aug-16 13:13:16 NetworkOPs:DBG recvValidation 7C6899F29DEABCC62AC4E85DD131AEC85F6EE1F058631B13412296C7C5B2C236 from 2 2017-Aug-16 13:13:18 Resource:DBG New unlimited endpoint "127.0.0.1" Thanks
  7. Hello all, I am trying to learn how Ripple works by setting up a local stock and validator servers. It seems that the communication has been established. At first I started 1st server with "-a" to generate genesis transaction and later started the same server pointing to the validator. These are my "server_info" responses, first the stock server: /opt/ripple/bin/rippled server_info Loading: "/etc/opt/ripple/rippled.cfg" 2017-Aug-14 08:41:56 HTTPClient:NFO Connecting to 127.0.0.1:5005 { "id" : 1, "result" : { "info" : { "build_version" : "0.70.1", "complete_ledgers" : "76002-78765", "hostid" : "xx1", "io_latency_ms" : 1, "last_close" : { "converge_time_s" : 2, "proposers" : 1 }, "load" : { "job_types" : [ { "in_progress" : 1, "job_type" : "clientCommand" }, { "job_type" : "peerCommand", "per_second" : 1 } ], "threads" : 8 }, "load_factor" : 1, "peers" : 1, "pubkey_node" : "n94UTpr9W4p5aakm8ZipXsrwm5MUgonNk45wWXs2w3DNMvqKGzHh", "pubkey_validator" : "none", "server_state" : "full", "state_accounting" : { "connected" : { "duration_us" : "1000491", "transitions" : 1 }, "disconnected" : { "duration_us" : "1150974", "transitions" : 1 }, "full" : { "duration_us" : "235832998577", "transitions" : 1 }, "syncing" : { "duration_us" : "2001010", "transitions" : 1 }, "tracking" : { "duration_us" : "6", "transitions" : 1 } }, "uptime" : 235837, "validated_ledger" : { "age" : 4, "base_fee_xrp" : 1e-05, "hash" : "80943FEE03E58456BCAFF97A4E294AE8EEA2AE04C0AF78EE50EFB868B39BE25E", "reserve_base_xrp" : 20, "reserve_inc_xrp" : 5, "seq" : 78765 }, "validation_quorum" : 1 }, "status" : "success" } } validator: /opt/ripple/bin/rippled server_info Loading: "/etc/opt/ripple/rippled.cfg" 2017-Aug-14 08:43:40 HTTPClient:NFO Connecting to 127.0.0.1:5005 { "id" : 1, "result" : { "info" : { "build_version" : "0.70.1", "complete_ledgers" : "76010-78800", "hostid" : "xx2", "io_latency_ms" : 1, "last_close" : { "converge_time_s" : 1.999, "proposers" : 0 }, "load" : { "job_types" : [ { "in_progress" : 1, "job_type" : "clientCommand" }, { "job_type" : "writeObjects", "per_second" : 1 }, { "job_type" : "peerCommand", "per_second" : 1 }, { "job_type" : "WriteNode", "per_second" : 1 } ], "threads" : 6 }, "load_factor" : 1, "peers" : 1, "pubkey_node" : "n9Mv6Ci6rVt3Ka47i2Z5YNpy4qLGs4f1PCG1qeZfsF6FF7mtDwdj", "pubkey_validator" : "nHUuVACwNCYzKPUTE6V5VYab76aqP7gWN8sDuLWwSSUUdbB2w6Xc", "server_state" : "proposing", "state_accounting" : { "connected" : { "duration_us" : "58039595", "transitions" : 1 }, "disconnected" : { "duration_us" : "1060053", "transitions" : 1 }, "full" : { "duration_us" : "236587737319", "transitions" : 1 }, "syncing" : { "duration_us" : "0", "transitions" : 0 }, "tracking" : { "duration_us" : "5", "transitions" : 1 } }, "uptime" : 236647, "validated_ledger" : { "base_fee_xrp" : 1e-05, "hash" : "62E7AD5CEDA13589969A2F04F50949C53E512DE6EA569608ECECBFCCD9A29763", "reserve_base_xrp" : 20, "reserve_inc_xrp" : 5, "seq" : 78800 }, "validation_quorum" : 1 }, "status" : "success" } } I created a new address and used RippleAPI JS to send XRP from genesis acct to the new account. The payment JS has the following code: const instructions = {maxLedgerVersionOffset: 5}; const payment = { source: { address: 'rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh', maxAmount: { value: '1000.55', currency: 'XRP' } }, destination: { address: 'rPTHuXH4ZMwXu4oHw8YUWAX7gqr7phfCfv', amount: { value: '1000.55', currency: 'XRP' } } }; Transaction went through and balances got updated: /opt/ripple/bin/rippled account_info rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh Loading: "/etc/opt/ripple/rippled.cfg" 2017-Aug-14 08:32:56 HTTPClient:NFO Connecting to 127.0.0.1:5005 { "id" : 1, "result" : { "account_data" : { "Account" : "rHb9CJAWyB4rj91VRWn96DkukG4bwdtyTh", "Balance" : "99999998999449988", "Flags" : 0, "LedgerEntryType" : "AccountRoot", "OwnerCount" : 0, "PreviousTxnID" : "DB733040C1D76163C9765CC40CB7DBCA78D4F0A7D426F75F381D51C347F34DF6", "PreviousTxnLgrSeq" : 18, "Sequence" : 2, "index" : "2B6AC232AA4C4BE41BF49D2459FA4A0347E1B543A4C92FCEE0821C0201E2E9A8" }, "ledger_current_index" : 78586, "status" : "success", "validated" : false } } 2nd wallet: /opt/ripple/bin/rippled account_info rPTHuXH4ZMwXu4oHw8YUWAX7gqr7phfCfv Loading: "/etc/opt/ripple/rippled.cfg" 2017-Aug-14 08:33:56 HTTPClient:NFO Connecting to 127.0.0.1:5005 { "id" : 1, "result" : { "account_data" : { "Account" : "rPTHuXH4ZMwXu4oHw8YUWAX7gqr7phfCfv", "Balance" : "1000550000", "Flags" : 0, "LedgerEntryType" : "AccountRoot", "OwnerCount" : 0, "PreviousTxnID" : "DB733040C1D76163C9765CC40CB7DBCA78D4F0A7D426F75F381D51C347F34DF6", "PreviousTxnLgrSeq" : 18, "Sequence" : 1, "index" : "2CBCDEC9A21E72F1D30D90B5D504307044B7BF03C2EAF2740CCA896705AD3E97" }, "ledger_current_index" : 78606, "status" : "success", "validated" : false } } Are these results normal and is there a way to verify that my setup is running correctly? How come both of them have "validated" set to false? I've attempted to install ripplecharts but when I follow instructions and start the app, it's not connecting. What are the settings that need to be added to "deployment.environments.json"? The example file contains this: { "development": { "ga_account" : "", "ga_id" : "", "api" : "REPLACEME", "maintenance" : false }, "staging": { "ga_account" : "", "ga_id" : "", "api" : "REPLACEME", "maintenance" : false }, "production": { "ga_account" : "", "ga_id" : "", "api" : "REPLACEME", "maintenance" : false } } what should I enter for the ga_account, ga_id and API settings?
  8. i am trying to start an private ripple blockchain with one validator but when i check the status it gives me error root@admin1-OptiPlex-9020:~# sudo systemctl status rippled.service ● rippled.service - Ripple Daemon Loaded: loaded (/usr/lib/systemd/system/rippled.service; enabled; vendor preset: enabled) Drop-In: /etc/systemd/system/rippled.service.d └─nofile_limit.conf Active: inactive (dead) since Wed 2017-07-19 13:58:15 IST; 3min 36s ago Process: 4254 ExecStart=/opt/ripple/bin/rippled --net --silent --conf /etc/opt/ripple/rippled.cfg (code=exited, status=0/SUCCESS) Main PID: 4254 (code=exited, status=0/SUCCESS) Jul 19 13:57:25 admin1-OptiPlex-9020 rippled[4254]: Watchdog: Launching child 1 Jul 19 13:57:25 admin1-OptiPlex-9020 rippled[4254]: Terminating thread rippled: main: unhandled N4soci18sqlite3_soci_errorE 'Cannot establish c Jul 19 13:57:35 admin1-OptiPlex-9020 rippled[4254]: Watchdog: Launching child 2 Jul 19 13:57:35 admin1-OptiPlex-9020 rippled[4254]: Terminating thread rippled: main: unhandled N4soci18sqlite3_soci_errorE 'Cannot establish c Jul 19 13:57:45 admin1-OptiPlex-9020 rippled[4254]: Watchdog: Launching child 3 Jul 19 13:57:45 admin1-OptiPlex-9020 rippled[4254]: Terminating thread rippled: main: unhandled N4soci18sqlite3_soci_errorE 'Cannot establish c Jul 19 13:57:55 admin1-OptiPlex-9020 rippled[4254]: Watchdog: Launching child 4 Jul 19 13:57:55 admin1-OptiPlex-9020 rippled[4254]: Terminating thread rippled: main: unhandled N4soci18sqlite3_soci_errorE 'Cannot establish c Jul 19 13:58:05 admin1-OptiPlex-9020 rippled[4254]: Watchdog: Launching child 5 My rippled.cfg -- [server] port_rpc_admin_local port_peer port_ws_admin_local #port_ws_public #ssl_key = /etc/ssl/private/server.key #ssl_cert = /etc/ssl/certs/server.crt [port_rpc_admin_local] port = 5005 ip = 127.0.0.1 admin = 127.0.0.1 protocol = http [port_peer] port = 51235 ip = 0.0.0.0 protocol = peer [port_ws_admin_local] port = 6006 ip = 127.0.0.1 admin = 127.0.0.1 protocol = ws #[port_ws_public] #port = 5005 #ip = 127.0.0.1 #protocol = wss #------------------------------------------------------------------------------- [node_db] type=RocksDB path=/var/lib/rippled/db/rocksdb open_files=2000 filter_bits=12 cache_mb=256 file_size_mb=8 file_size_mult=2 online_delete=2000 advisory_delete=0 [database_path] /var/lib/rippled/db # This needs to be an absolute directory reference, not a relative one. # Modify this value as required. [debug_logfile] /var/log/rippled/debug.log [sntp_servers] time.windows.com time.apple.com time.nist.gov pool.ntp.org # Where to find some other servers speaking the Ripple protocol. # [ips] #r.ripple.com 51235 [validator_token] ey-------------------------------------token # File containing trusted validator keys or validator list publishers. # Unless an absolute path is specified, it will be considered relative to the # folder in which the rippled.cfg file is located. [validators_file] validators.txt # Turn down default logging to save disk space in the long run. # Valid values here are trace, debug, info, warning, error, and fatal [rpc_startup] { "command": "log_level", "severity": "warning" } # If ssl_verify is 1, certificates will be validated. # To allow the use of self-signed certificates for development or internal use, # set to ssl_verify to 0. [ssl_verify] 1 Please help me to resolve it
  9. Hello , I try to make the trustline between two account using this JSON-rpc api { "method": "submit", "params": [ { "secret": "Secret-key", "tx_json": { "Account": "rcWB6PobWkr2hAWRAFGxpAxPUpxnWNtiA", "Fee": "15000", "TransactionType": "TrustSet", "LimitAmount": { "currency": "SOM", "issuer": "rUfWPdSpQVHkAxarYTPU3uHX47n6L78guM", "value": 0 }, "Flags": 65536, "Sequence": 9 } } ] } but when i check tx_blob in return using request { "method": "submit", "params": [ { "tx_blob": "120014220001000024000000036380000000000000000000000000000000000000004442530000000000E1F55708CB67B2DB45E8A7E06FDEE81D88F02B01684000000000003A987321022CBD94ACD2BCAD62720AFD1AE0462B917CA6CA6F8503F52053ACEB3B6F0C3A92744730450221009BDF94DEE456B792B717636B0AB9B0F671456101FBEF95719BEAE923C8B70FF80220333C86E0EF845F863CDF12376B00F780E469A620407B3D051AF2A82823B352588114119ED18567D6A1045821AF158EB10FC4B1676B26" } ] } Response - { "result": { "engine_result": "tefALREADY", "engine_result_code": -198, "engine_result_message": "The exact transaction was already in this ledger.", "status": "success", "tx_blob": "120014220001000024000000036380000000000000000000000000000000000000004442530000000000E1F55708CB67B2DB45E8A7E06FDEE81D88F02B01684000000000003A987321022CBD94ACD2BCAD62720AFD1AE0462B917CA6CA6F8503F52053ACEB3B6F0C3A92744730450221009BDF94DEE456B792B717636B0AB9B0F671456101FBEF95719BEAE923C8B70FF80220333C86E0EF845F863CDF12376B00F780E469A620407B3D051AF2A82823B352588114119ED18567D6A1045821AF158EB10FC4B1676B26", "tx_json": { "Account": "rpcwkwGA8u8k2nxEGc1837tGeH7QWvi4qQ", "Fee": "15000", "Flags": 65536, "LimitAmount": { "currency": "DBS", "issuer": "rMbkAg2T9biQ1Ax7r2juNGXRfTeN8j6wLk", "value": "0" }, "Sequence": 3, "SigningPubKey": "022CBD94ACD2BCAD62720AFD1AE0462B917CA6CA6F8503F52053ACEB3B6F0C3A92", "TransactionType": "TrustSet", "TxnSignature": "30450221009BDF94DEE456B792B717636B0AB9B0F671456101FBEF95719BEAE923C8B70FF80220333C86E0EF845F863CDF12376B00F780E469A620407B3D051AF2A82823B35258", "hash": "CDEC1C858F20A2E046031743904AEF86C9DFAC6391E46891072E82F9CB2A5F11" } } } And when i check the gatway_balance request - { "method": "gateway_balances", "params": [ { "account": "rpcwkwGA8u8k2nxEGc1837tGeH7QWvi4qQ", "hotwallet": [ "rMbkAg2T9biQ1Ax7r2juNGXRfTeN8j6wLk" ] } ] } Response - { "result": { "account": "rpcwkwGA8u8k2nxEGc1837tGeH7QWvi4qQ", "ledger_current_index": 3, "status": "success", "validated": false } } Please help me to solve it .
  10. Hi, I am stuck at one Problem when trying to setup a simple Docker-rippled + ripple-lib app, I have rippled installed in a docker conainer with the following Config (irrelevant parts omited) : http://paste.ubuntu.com/25075264/ This Forum removes all my newlines from code i copy from my IDE for some reason, have to use pastebin, sorry. and i try to connect to the deamon with the ripple-lib javascript library and the following code: 'use strict'; const {RippleAPI} = require('ripple-lib') const api = new RippleAPI({ server: 'wss://172.17.0.7:51235', // docker ip authorization: 'username:password' }); and i always get the response: [NotConnectedError(unexpected server response (401))] no idea why, cant find any logs, someone has any ideas?
  11. Looking at ripple network topology, one can see that there are some nodes whose IPs are not know (i.e. location not know). How did they manage to hide their IP and how to go about doing this for myself? Tried setting peer_private=1 in rippled.cfg file but what it did is made the server respond with "InsufficientNetworkMode", perhaps suggesting that it is not syncing up any more. It would be nice to be able to hide IP from topology page, since there is no need for that if it's only for you. Noticed that straight after setting up a rippled server, there where almost immediately failed attempts to ssh log in from China. Do not have to be a genius to deduce where they got my server IP from...
  12. Which type of AWS instance is suitable for rippled (only home research purpose) - getting mixed opinions: 1. t2.2xlarge (Variable ECUs, 8 vCPUs, 2.4 GHz, Intel Xeon Family, 32 GiB memory, EBS only) 2. m4.2xlarge (26 ECUs, 8 vCPUs, 2.4 GHz, Intel Xeon E5-2676v3, 32 GiB memory, EBS only) 3. m3.large (6.5 ECUs, 2 vCPUs, 2.5 GHz, Intel Xeon E5-2670v2, 7.5 GiB memory, 1 x 32 GiB Storage Capacity) 4. g2.2xlarge (26 ECUs, 8 vCPUs, 2.6 GHz, Intel Xeon E5-2670, 15 GiB memory, 1 x 60 GiB Storage Capacity) Thanks folks.
  13. Rippled Commands

    Hi Folks. I have installed Rippled on my Ubuntu distro AWS m3.2xlarge (26 ECUs, 8 vCPUs, 2.5 GHz, Intel Xeon E5-2670v2, 30 GiB memory, 2 x SSD 80 GiB Storage Capacity) instances. I am just experimenting with Rippled and have limited experience with node.js and C++. What I am doing now is testing the basic rippled commands using $ /opt/ripple/bin/rippled <COMMAND> After I executed the first command using $ /opt/ripple/bin/rippled account_currencies I got the following message "Loading: "/home/ubuntu/rippled.cfg" and nothing happens. I have also updated the rippled.cfg (using vim) with the following command: { "command": "account_currencies", "account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59", "strict": true, "ledger_index": "validated" } - source: https://ripple.com/build/rippled-apis/#account-currencies No results. Am I doing something wrong? Any help would be greatly appreciated. PS: anyone has a the source code to generate public and secret keys for paper wallet storage? Thanks guys, Closingbell2012
  14. Hello guys, looks like the orderbooks are not being built with offer autobridging. I just validated it at https://ripple.com/build/websocket-tool/# REQUEST: { "id": 4, "command": "book_offers", "taker": "rDb6qVhDdAybg9ARF2Yy64AAdk17Bi4M2q", "taker_gets": { "currency": "BTC", "issuer": "rKxKhXZCeSDsbkyB8DVgxpjy5AHubFkMFe" }, "taker_pays": { "currency": "BRL", "issuer": "rfNZPxoZ5Uaamdp339U9dCLWz2T73nZJZH" }, "limit": 3 } RESPONSE { "id": 4, "status": "success", "type": "response", "result": { "ledger_current_index": 29005704, "offers": [ { "Account": "rwSrs1WCfRZPaPx7tqHToQFqyjobMPrgkJ", "BookDirectory": "A183825144B5D679B197CDCDA3E44DDF14F55F3591AF0C58580DBB55D3F68000", "BookNode": "0000000000000000", "Flags": 131072, "LedgerEntryType": "Offer", "OwnerNode": "0000000000000001", "PreviousTxnID": "9744DED4BB1833AAC463D8CC3BD29D028097A7738AE4F925A416186F6660D743", "PreviousTxnLgrSeq": 29005673, "Sequence": 34535, "TakerGets": { "currency": "BTC", "issuer": "rKxKhXZCeSDsbkyB8DVgxpjy5AHubFkMFe", "value": "0.512" }, "TakerPays": { "currency": "BRL", "issuer": "rfNZPxoZ5Uaamdp339U9dCLWz2T73nZJZH", "value": "1978.957824" }, "index": "0D60320194196138FC5D16723DF35AD1628ECA57B9C99C8051502DB39FE36C14", "owner_funds": "1.327867740457333", "quality": "3865.152" } ], "validated": false } } Charts:
  15. HI there! I'm trying to build a stock RippleD Server on CentOs 7 and I'm facing some issues. RippleD is up and running as a Linux Service, but strangely I'm unable to connect via the WSS interface... I receive a 403 error! Please note that when using WS it works perfectly but I would like to use WSS for security reasons. RippleD Config: validators.txt RippleD Log: NodeJS program that is trying to connect to RippleD: NodeJS Log: Do you guys have any clue what I'm doing wrong? Why the hell am I receiving a 403? Thanks a lot for your help!!!
  16. https://ripple.com/dev-blog/rippled-0-50-0/ And we're planning on voting for TickSize and SusPay so that both get enabled on Feb 21.
  17. When running rippled on Centos 6 using the yum package, you may encounter this error: Or something to the effect that 1024 file descriptors are available and 4096 were requested from rippled, so it shut down. To fix this error, open /etc/security/limits.conf and at the bottom of the file add: Next, open /etc/sysctl.conf and at the bottom of the file add: Run ulimit -Ha to check if open files has been updated to 10240, such as: Execute service rippled start and it should operate correctly.
  18. I overlaid the RCL validator map from https://charts.ripple.com/#/topology to a map of the US showing major cities and thought it might be fun for everyone to do some speculation. It got more interesting than I anticipated. I know IP mapping isn't 100% accurate but I think this gives some insights and I'm sure others can come up with more. Also, keep in mind the size of the dot indicates the number of connections for that validator. Using Ripple as a control you can see a few validators in the SF area that would represent their connections. The giant dot in Southern Kansas seems to be due to this: http://fusion.net/story/287592/internet-mapping-glitch-kansas-farm/ The giant dots in southern WA are maybe another IP mapping issue, but I believe there are server farms in that area. The small validator in Boston seems to offer another control as it seems that would be MIT. Seems to be a bit of dedicated processing power near Seattle. Microsoft maybe? Curious about all the power in Dallas/Houston. Look at Washington DC. If there are any positive indicators that Ripple may be the first crypto approved for interbank settlement in addition to the tweets, extensive compliance team, Faster Payments situation, etc. @papa Pointed out that Washington DC has the most connections. I count 6 validators with what looks like more than 2x the connections in the Silicon Valley area. This is obviously the headquarters for the Federal Reserve (I only mention that because of #8). The validators in Dallas/Houston are what sparked my interest in this, but as I fell down the rabbit hole the most interesting thing I've found as I've dug in a bit is that of the 12 Federal Reserve Banks throughout the country, seven of them have validators (SF, KC, DAL, NY, CHI, ATL, BOS). The exceptions are Minneapolis, Philadelphia, Richmond, Cleveland, and St. Louis. Philadelphia does have a validator in PA not too far away, but it wasn't right on the dot. Not trying to make outlandish assertions, but that's interesting! #8 makes me believe there is a decent chance the fed is already watching these tests. How would banks have the confidence to use XRP in live trials if the Fed wasn't watching. Seems to make sense. Also make sense that they would run a validator so they can audit the transactions. You know they want that kind of control and visibility. Also makes sense as to why DC would have more connections by far than any other city. Still curious about Houston, Southern WA and those validators defaulting to Kansas. Any Ripple partners in Houston? That's all I got. Didn't expect to go so crazy, but hopefully you guys enjoy.
  19. Background Originally, the FlowV2 amendment was planned to replace rippled’s payment processing engine with a more robust and efficient implementation. It was previously expected to become active on Wednesday, 2016-08-24. FlowV2 Was Vetoed The rippled team found a flaw in FlowV2 while testing. As a result, the Ripple network has vetoed the new payment engine amendment. A corrected version of the payment processing engine has been created and is now undergoing further testing. It is scheduled to be included in a future version of rippled as an amendment called Flow. This demonstrates the robustness of Ripple’s amendment process. The review period and governance code with vetoing work as intended. Action Recommended No action is currently required. However, Ripple recommends that validator operators also veto the FlowV2 amendment to ensure it does not regain a majority. To veto the amendment, add the following, single line, under the [veto_amendments] stanza to the rippled.cfg file on validators: 5CC22CFF2864B020BD79E0E1F048F63EF3594F95E650E43B3F837EF1DF5F4B26 FlowV2 Learn, Ask Questions, and Discuss Related documentation is available in the Ripple Developer Portal, including detailed example API calls and web tools for API testing: https://ripple.com/build/ Other resources: The Ripple Forum: https://forum.ripple.com/ The Ripple Dev Blog: https://ripple.com/category/dev-blog/ Ripple Technical Services: support@ripple.com
  20. The FlowV2 Amendment is now open for voting. This amendment replaces the payment processing engine with a more robust and efficient rewrite called the FlowV2 engine. The new version of the payment processing engine is intended to follow the same rules as the old engine. However, the new engine occasionally produces different results due to floating point rounding. The FlowV2 Engine also makes it easier to improve and expand the payment engine with further Amendments. Ripple’s validators will vote in favor of the FlowV2 amendment. We expect the new feature to become active on Wednesday, 2016-08-24. Actions Required If you operate a `rippled` server, you should upgrade to version 0.32.1 by Wednesday, 2016-08-24 for the best performance. Note: A previous version of this post incorrectly stated that backend software must be updated to construct transactions for the new payment processing engine. The process of creating and submitting transactions for the FlowV2 payment engine is the same as for the previous payment engine. Impact of Not Upgrading If you operate a `rippled` server but don’t upgrade to version 0.32.1 by Wednesday, 2016-08-24 (when FlowV2 is expected to become available via Amendment) then: Your server will become "amendment blocked" and unable to process transactions or evaluate the validity of ledgers. For instruction on updating `rippled` on supported platforms, see: https://ripple.com/build/rippled-setup/#updating-rippled For other platforms, please compile version 0.32.1 from source. For details, see https://wiki.ripple.com/Rippled_build_instructions Learn, Ask Questions, and Discuss Related documentation is available in the Ripple Developer Portal, including detailed example API calls and web tools for API testing: https://ripple.com/build/ Other Resources * The Ripple Forum: https://forum.ripple.com/ * The Ripple Dev Blog: https://ripple.com/category/dev-blog/ * Ripple Technical Services: support@ripple.com
  21. rippled version 0.32.1 Ripple is proud to announce the release of rippled version 0.32.1, which introduces several enhancements that improve the reliability and scalability of the Ripple Consensus Ledger. Ripple recommends that all server operators upgrade to version 0.32.1 by Wednesday, 2016-08-24, for the best performance. Highlights of this release include: A new, optional WebSocket implementation based on Beast. See below for details. An improved version of the payment code, which we expect to be available via an Amendment named "FlowV2" on Wednesday, 2016-08-24. See below for details. Actions Required If you operate a rippled server, you should upgrade to version 0.32.1 by Wednesday, 2016-08-24, for the best performance. If you have backend software which constructs and submits transactions to the Ripple network, you need to adapt it to correctly use the network’s new payment engine. Impact of Not Upgrading If you operate a rippled server but don’t upgrade to version 0.32.1 by Wednesday, 2016-08-24, when FlowV2 is expected to become available via Amendment, then your server might lose synchronization with the rest of the upgraded network for brief periods of time. That is, the local view of ledgers may be slightly behind the rest of the network. Any rippled server operator running versions prior to 0.32.1, will also become amendment blocked. For supported platforms, see Updating rippled on supported platforms. The md5sum for the rpm is: 5dcdcef01f3cfc452b0b503eaaeb07bb The md5sum for the source rpm is: 3180fca1e83001307346f85628823a9c For other platforms, please compile version 0.32.1 from source. The first log entry should be the change setting the version: commit 1ff972fbd3b82f0f7062f05f64f1abd5e274a7bc Author: Nik Bougalis <nikb@bougalis.net> Date: Fri Jul 29 12:52:26 2016 -0700 Set version to 0.32.1 Network Update The Ripple operations team plans to deploy version 0.32.1 to all rippled servers under its operational control, including private clusters, starting at 1:00 PM PDT on Thursday, 2016-08-04. The deployment is expected to complete within 4 hours. The network will continue operating during deployment and no outage is expected. Learn, ask questions, and discuss Related documentation is available in the Ripple Developer Portal, including detailed example API calls and web tools for API testing. Other resources: The Ripple Forum The Ripple Dev Blog Ripple Technical Services: support@ripple.com XRP Chat Full Release Notes The rippled 0.32.1 release includes an improved version of the payment code, which we expect to be available via Amendment on Wednesday, 2016-08-24 with the name FlowV2, and a completely new implementation of the WebSocket protocol for serving clients. You can update to the new version on Red Hat Enterprise Linux 7 or CentOS 7 using yum. For other platforms, please compile the new version from source. New and Updated Features An improved version of the payment processing engine, which we expect to be available via Amendment on Wednesday, 2016-08-24 with the name “FlowV2”. The new payments code adds no new features, but improves efficiency and robustness in payment handling. The FlowV2 code may occasionally produce slightly different results than the old payment processing engine due to the effects of floating point rounding. Once FlowV2 is enabled on the network then old servers without the FlowV2 amendment will lose sync more frequently because of these differences. Beast WebSocket A completely new implementation of the WebSocket protocol for serving clients is available as a configurable option for rippled administrators. To enable this new implementation, change the “protocol” field in rippled.cfg from “ws” to “ws2” (or from “wss” to “wss2” for Secure WebSockets), as illustrated in this example: [port_ws_public] port = 5006 ip = 0.0.0.0 protocol = wss2 The new implementation paves the way for increased reliability and future performance when submitting commands over WebSocket. The behavior and syntax of commands should be identical to the previous implementation. Please report any issues to support@ripple.com. A future version of rippled will remove the old WebSocket implementation, and use only the new one. Bug fixes Fix a non-exploitable, intermittent crash in some client pathfinding requests (RIPD-1219) Fix a non-exploitable crash caused by a race condition in the HTTP server. (RIPD-1251) Fix bug that could cause a previously fee queued transaction to not be relayed after being in the open ledger for an extended time without being included in a validated ledger. Fix bug that would allow an account to have more than the allowed limit of transactions in the fee queue. Fix bug that could crash debug builds in rare cases when replacing a dropped transaction. (RIPD-1200) Remove incompatible OS X switches in Test.py (RIPD-1250) Autofilling a transaction fee (sign / submit) with the experimental x-queue-okay parameter will use the user’s maximum fee if the open ledger fee is higher, improving queue position, and giving the tx more chance to succeed. (RIPD-1194)
  22. This notice is for all validator operators, and may be relevant to gateways that utilize the Authorized Account feature. The new TrustSetAuth amendment is open for voting now. This amendment allows pre-authorization of accounting relationships (zero-balance trust lines) when using Authorized Accounts. With this amendment enabled, currency issuers can authorize other addresses to hold their issued currencies without waiting for the other addresses to take action. Without the amendment, currency holders must first create the accounting relationship with the issuer by setting a limit with a TrustSet transaction. Ripple’s validators will vote in favor of the TrustSetAuth amendment, and we expect the new feature to become active by 2016-07-19. For more information, see the following articles in the Ripple Developer Center: Authorized Accounts: https://ripple.com/build/gateway-guide/#authorized-accounts Amendments: https://ripple.com/build/amendments/ To continue receiving updates about the rippled server, please subscribe to the Ripple Server Google Group: https://groups.google.com/forum/#!forum/ripple-server
  23. https://ripple.com/dev-blog/rippled-0-32-0-released/ Ripple is proud to announce the release of rippled version 0.32.0. This release introduces several enhancements that improve the reliability and scalability of the Ripple Consensus Ledger. Ripple recommends that all server operators upgrade to the new version. Highlights of this release include: The transaction queue now supports batching and can hold up to 10 transactions per account, allowing users to queue multiple transactions for processing when the network load is high. This encourages liquidity for XRP since important transactions now have a more reliable way of getting into the ledger. For more information, see Queued Transactions in the Ripple Developer Portal. The server_info and server_state commands now include information on transaction cost multipliers. Customers who want to robustly submit transactions now have additional tools for accurately setting the fee based on changing network conditions. Furthermore, the fee command is now available to unprivileged users. For more information, see the rippled API Method Reference in the Ripple Developer Portal. There’s a new WebSocket implementation based on Beast. Use of this implementation is optional. A future version of rippled will make this WebSocket implementation the default, with the old implementation removed. Read the complete release notes in GitHub. Actions Required If you operate a rippled server, you should upgrade to version 0.32.0 for the best performance. If you have backend software which constructs and submits transactions to the Ripple network, you may need to adapt it to correctly use the network’s new transaction queue mechanism. Impact of Not Upgrading If you operate a rippled server but don’t upgrade to version 0.32.0, your server might lose synchronization with the rest of the upgraded network for brief periods of time. That is, the local view of ledgers may be slightly behind the rest of the network. For instruction on updating rippled on supported platforms, please see Updating rippled in the Ripple Developer Center. The md5sum for the rpm is: 1b37fd80fd869e42a715f17a9e30c81a. The md5sum for the source rpm is: d43f4d371416b213d6197fb1c630cf44. For other platforms, please compile version 0.32.0 from source. See rippled Build Instructions in the Ripple Wiki for details. The first log entry should be the change setting the version: commit d22eb0caa25ecfbd373cc9af0347e56031a23646 Author: seelabs <scott.determan@yahoo.com> Date: Fri Jun 24 11:30:09 2016 -0400 Set version to 0.32.0 Network Update The Ripple operations team plans to deploy version 0.32.0 to all rippled servers under its operational control, including private clusters, starting at 1:00 PM PDT on Wednesday, 2016-06-29. The deployment is expected to complete within 4 hours. Learn, ask questions, and discuss Ripple supported documentation including detailed example API calls and web tools for API testing are located on the Ripple Developer Portal: https://ripple.com/build/ Other Resources: Ripple Official Forum: https://forum.ripple.com/ Ripple Dev Blog: https://ripple.com/category/dev-blog/ Ripple Technical Services: support@ripple.com XRPChat (This forum)
  24. https://ripple.com/dev-blog/multi-signing-will-soon-available/ The multi-signing amendment is currently supported by the majority of voting validators on Ripple, and is scheduled to become active on the protocol on Monday, 2016-06-27. For more information, please see the multi-signing documentation in the Ripple Developer Portal: How to Multi-Sign MultiSign Amendment Information To continue receiving updates about the rippled server, please subscribe to the Ripple Server Google Group: https://groups.google.com/forum/#!forum/ripple-server UPDATE: As of 2016-06-27T11:34:41Z (ledger 22178817), multi-signing is now enabled!
  25. Rather than continue to derail TWarden's UNL security blanket thread, I decided it would be a good idea to share knowledge and collect information on people's experiences with running rippled. We can see what kinds of specs and settings people have had success or problems with, and go from there. I'll start with my own experience: I have a home desktop PC which I use for my daily computing needs. I built the computer in 2009 and have upgraded it slightly over the years. Since late January 2016, I've been running rippled as a validator more or less continuously. System specs: CPU: 2.66GHz Intel Core i7 "Bloomfield" CPU RAM: 16GB Corsair XMS3 (what can I say, it was a Black Friday sale!) Disks: System partition is on a 80GB Intel X-25M SSD. My rippled's database is on my 2x3TB 7200 RPM disks in software RAID1 using mdadm. I think they're Hitachi-branded? OS: Arch Linux x86_64 (latest Linux kernel, which I've updated a few times in the time I've been running the validator) Network: I'm wired to a cheapo 10/100MBit Netgear ethernet switch and use my house's residential broadband. Settings: I'm using the default settings from the rippled-example.cfg, except for adding my validation seed. The automatic online delete seems to work just fine. Maintenance: Basically, the only maintenance I do is to upgrade to a new version of rippled when one comes out. So far I haven't had any problems with disk space: rippled seems to purge old ledgers often enough to stay within a reasonable amount of disk usage. Usage patterns: I occasionally run RPC commands against rippled for testing / work purposes, but by and large the daemon is dedicated to validating. I do use the machine for my daily computing and I've noticed that the process tends to use up as much RAM as it can when my computer is idle, but it quickly yields it to other programs when I'm actively using the computer. There hasn't been any major adverse effect on my general computing performance. Meanwhile, my validation agreement percentage has been hovering around 98% with few exceptions during that time.
×