Jump to content

tulo

Silver Member
  • Posts

    3,294
  • Joined

  • Last visited

  • Days Won

    3

Everything posted by tulo

  1. I did some quick tests. It seems the transactions are taking 8-10 seconds to go through. Way slower than AVAX or Solana. I don't know the technicalities of Songbird, but do you think there are some limitations in the current network?
  2. I didn't try it, but I believe the latest release (planned to be public before 27/09) will have that option.
  3. Any info on Bifrost team? Will the code be opensource?
  4. It peaked 400k TPS I'd like to see XRPL with 1500 TPS.
  5. I personally use both Solana and Avalance. And they are good, very good! They are fast, reliable (for now) and have a huge ecosystem. Both support smart contracts and EVM. Solana has already a DEX (Serum). The fees are okish on AVAX (1-2$ transactions for contract chain and 0.05$ for sending) and awesome on Solana. Solana is also supposed to scale linearly with hardware, i.e. double the power of the hardware and bandwidth, the double the TPS. Solala decentralization is not the perfect right now, but better than XRPL. It has around 1000 validators, but the top 20 validators could collude and have 33% of the power to halt the network. Still more than those needed to halt XRPL. Avalanche main net has around 1000 validators too. And most important they are both permissionless network, which is not completely true on XRPL.
  6. Some easy motivations: You submitted the transaction at "the end" of the 3-5 seconds of the Nth ledger and the transaction didn't have the time to spread to all validators and reach consensus. The fee wasn't enough because the network was loaded and the transaction is queued
  7. Yes. But remember that a transacion sent at ledger N is not always included in ledger N+1. There are multiple reasons for which a transaction can take multiple ledgers (blocks) to be considered final and included in a validated ledger.
  8. The only other project that was this hyped was EOS, and we all know how it ended. Let's hope it won't be the same for flare. BTW the goal of the canary network is to not be flawless, such that bugs and problems can be discovered also thanks to the community. If songbird is not being released I suspect we are well behind the planned scheduling.
  9. This latest build (1.7.2) is killing me. Now randomly I get: { "result" : { "error" : "noNetwork", "error_code" : 17, "error_message" : "InsufficientNetworkMode", "request" : { "account" : "XXX", "api_version" : 1, "command" : "account_info" }, "status" : "error" } } Also when connecting from another node via ripple-lib same error. This the server_info: { "result" : { "info" : { "build_version" : "1.7.2", "complete_ledgers" : "65938663-65944958,65945228-65945263", "fetch_pack" : 271, "hostid" : "XXX", "io_latency_ms" : 1, "jq_trans_overflow" : "186", "last_close" : { "converge_time_s" : 2, "proposers" : 0 }, "load" : { "job_types" : [ { "job_type" : "untrustedValidation", "per_second" : 19 }, { "in_progress" : 2, "job_type" : "ledgerData", "waiting" : 17 }, { "in_progress" : 1, "job_type" : "clientCommand" }, { "in_progress" : 1, "job_type" : "updatePaths" }, { "job_type" : "advanceLedger", "per_second" : 11 }, { "job_type" : "trustedValidation", "per_second" : 5 }, { "job_type" : "trustedProposal", "per_second" : 13 }, { "job_type" : "peerCommand", "per_second" : 516 }, { "avg_time" : 5, "job_type" : "SyncReadNode", "peak_time" : 63, "per_second" : 39 }, { "avg_time" : 2, "job_type" : "AsyncReadNode", "peak_time" : 61, "per_second" : 285 }, { "avg_time" : 7, "job_type" : "WriteNode", "peak_time" : 64, "per_second" : 137 } ], "threads" : 6 }, "load_factor" : 1, "peer_disconnects" : "14", "peer_disconnects_resources" : "0", "peers" : 10, "pubkey_node" : "XXX", "pubkey_validator" : "none", "server_state" : "full", "server_state_duration_us" : "5864304", "state_accounting" : { "connected" : { "duration_us" : "400848332", "transitions" : 139 }, "disconnected" : { "duration_us" : "1140693", "transitions" : 2 }, "full" : { "duration_us" : "4039734923", "transitions" : 152 }, "syncing" : { "duration_us" : "62764930", "transitions" : 15 }, "tracking" : { "duration_us" : "82578491", "transitions" : 152 } }, "time" : "2021-Aug-27 10:41:28.555228 UTC", "uptime" : 4587, "validated_ledger" : { "age" : 1343, "base_fee_xrp" : 1e-05, "hash" : "4E99CF2C7BF960C138C54E6A9B628AACDD346E788D961065F033D5E7047334C9", "reserve_base_xrp" : 20, "reserve_inc_xrp" : 5, "seq" : 65945263 }, "validation_quorum" : 33, "validator_list" : { "count" : 1, "expiration" : "2022-Jan-11 00:00:00.000000000 UTC", "status" : "active" } }, "status" : "success" } } It was working at first and then after a while this happens. There are peers, there is traffic. The internet bandwidth is more than ok. I don't understand what is wrong and I'm very bad in server mainteinance.
  10. It seems you have not completely clear what you want to do. Creating a Naira gateway and creating a stablecoin pegged to USD are two completely different things. You should clear this out first. It's too wide question. And I doubt we can answer this, because it depends on lots of factors also related to your hardware and software architecture and on your business idea. Probably yes?! Again it depends for what. You can easily create one to test it out how it works on the XRPL. It depends on: Custodian (as bitstamp) or non custodian (as gatehub) wallet? Manual or automatic deposit/withdrawal? Any other function other than deposit/withdrawal? Do you privide liquidity or use external market makers? Rebalancing market (because I suppose there will be a net flow in a direction only, probably USD or XRP to NGN)? Much more... Sorry, but if you are skeptical about the core function of your business then I suggest you don't do it yourself. You should focus on the business side and hire an XRPL developer as @Sukrim or @Wietse .
  11. I think you didn't check out well . Avax? Solana? Polkadot/Kusama?
  12. I think in this case the terminology is a bit bad. The exchanges in this case I THINK are historical trades, i.e. trades that happend already in that market. The "provider" is probably who placed the order. The "taker" is who has matched the order. Then the "buyer" and "seller" should be clear, but it's who actually bought and sold the currencies involved in the trade (in your case XRP and USD_bitstamp).
  13. so basiacally all the new stuff won't be there even in the testnet. My prediction is that the full flare network will be launched in 2022, if it will ever go live.
  14. Since I switched to rippled 1.7.2 the process randomly dies without any warning or error in the log. I really don't know what to check and what could be the causes.
  15. Cheaper in terms of what? Cost per transaction? Fees? Hardware to run the code? On XRPL each transaction (also placing orders) has an XRP cost, which is very low but it can adds up. Moreover trading XRP for IOUs (Bitstamp USD for example) has a transfer fee cost which is usually between 0% and 0.2% of the amount traded. On some exchanges this cost is between 0% and 0.75%. On binance it's 0.1% so it's more expensive than some IOUs on XRPL (for example CNY RippleFox which is 0%) but cheaper than other IOUs (for example Bitstamp USD which is 0.2%). Moreover to run a bot on XRPL it is SUGGESTED to have a XRPL node to have a more reliable node tu submit transactions, which increase hardware and mainteinance costs. So it really depends on the application.
  16. Where do you want to trade? Exchanges or XRPL?
  17. It's the "private key" you need to sign transactions. It can be derived from the 24 words with a particular algorithm. And BTW if you suppose that Ledger or someone else will release a wallet which supports Ledger hardware wallet then your crypto are safe. If they don't you won't be able to send or use the FLR. My concerns were related to having to obtain the private key for a wallet which requires it to "import" the wallet.
  18. And in case the FLR wallet requires the secret key to "import" the account what is your plan to get it?
  19. It depends on how you created the ETH-like address.
  20. There are of course people working on the core but it doesn't seem on revolutionary changes. For example implementing a different consensus since it was proven (https://arxiv.org/abs/2011.14816) to have limitations. I'd love to work on that if I had enough time and if I had the right skills, but I don't unfortunately.
  21. This! XRPL tech was awesome 7 years ago until a few years ago. Now there are way better tech (Avalanche, Solana, ...) which solve most of the problems. In both avalanche and solana they have high tps, possibility to run smart contracts on EVM, solana has a DEX exactly as XRPL but with a bridge to bring tokens from ETH and BSC. It seems there is none working on the innovation of the core of XRPL.
  22. I'd go for 5/1. 5$ for many people is already very high.
  23. Yes, in many "explorers" I wasn't able to get data because they were probably connected to SDF nodes, but the network was on. Also many major exchanges probably use public nodes and weren't able to do deposit and withdrawals.
×
×
  • 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.