Jump to content

Kakoyla

Member
  • Content Count

    268
  • Joined

  • Last visited

About Kakoyla

  • Rank
    Regular

Recent Profile Visitors

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

  1. I am having a hell of a time staying on top of the validators, who they are and what keys they are using and I am hoping someone has a tip for an easy way to deal with this. I get the UNL from here: https://vl.ripple.com then decode using the code JR posted here, which references https://data.ripple.com/v2/network/validators/${validator} to pull the domain. As of today I get this list: 1 nHUzum747yqip3HWSgzSNHNMjmLUqhroNVWidSRTREswEVhKNQEM => validator.ripple.com 2 nHDDasc9BHNB99PW8KUduS8Phqg8NPUmjufzMU6HGGDMUH2xNpPh => validator.ripple.com 3 nHUKp8XUkaFN6GzQ3o4qTE1w9aAD5uFjZ8vDt6pwjBsTFRq5FWEb => validator.ripple.com 4 nHUUrjuEMtvzzTsiW2xKinUt7Jd83QFqYgfy3Feb7Hq1EJyoxoSz => validator.ripple.com 5 nHBtDzdRDykxiuv7uSMPTcGexNm879RUUz5GW4h1qgjbtyvWZ1LE => validator.ripple.com 6 nHUon2tpyJEHHYGmxqeGu37cvPYHzrMtUNQFVdCgGNvEkjmCpTqK => validator.ripple.com 7 nHU2Y1mLGDvTbc2dpvpkQ16qdeTKv2aJwGJHFySSB9U3jkTmj4CA => validator.ripple.com 8 nHUkp7WhouVMobBUKGrV5FNqjsdD9zKP5jpGnnLLnYxUQSGAwrZ6 => validator1.worldlink-us.com 9 nHU95JxeaHJoSdpE7R49Mxp4611Yk5yL9SGEc12UDJLr4oEUN4NT => flagshipsolutionsgroup.com 10 nHUFzgC9fDw2MEDaiv9JMdBFhtJ6DMKoUCpS8gPGi6tkfbqmTyis => www.bahnhof.se 11 nHUCCckfXVBdoounaU7JVnfdPdMXEeetwH8VdCBXD996BaVZ8WdJ => ripple.telinduscloud.lu 12 nHUcNC5ni7XjVYfCMe38Rm3KQaq27jw7wJpcUYdo4miWwpNePRTw => rabbitkick.club 13 nHBgiH2aih5JoaL3wbiiqSQfhrC21vJjxXoCoD2fuqcNbriXsfLm => www.attokyo.com 14 nHUpJSKQTZdB1TDkbCREMuf8vEqFkk84BcvZDhsQsDufFDQVajam => data443.com 15 nHDwHQGjKTz6R6pFigSSrNBrhNYyUGFPHA75HiTccTCQzuu9d7Za => coil.com 16 nHB8QMKGt9VB4Vg71VszjBVQnDW3v3QudM4DwFaJfy96bj4Pv9fA => bithomp.com 17 nHUd8g4DWm6HgjGTjKKSfYiRyf8qCvEN1PXR7YDJ5QTFyAnZHkbW => brex.io 18 nHBidG3pZK11zQD6kpNDoAhDxH6WLGui6ZxSbUx7LSqLHsgzMPec => bitso.com 19 nHUVPzAmAmQ2QSc4oE1iLfsGi17qN2ado8PhxvgEkou76FLxAz7C => ripple.ittc.ku.edu 20 nHULqGBkJtWeNFjhTzYeAsHA3qKKS7HoBh8CV3BAGTGMZuepEhWC => shadow.haas.berkeley.edu 21 nHUT6Xa588zawXVdP2xyYXc87LQFm8uV38CxsVzq2RoQJP8LXpJF => blockchain.korea.ac.kr 22 nHB5kpvUaEpvCtwu31fMf6dTuuCNnWRctWrV3UEZ9rbtPdpvbUvJ => ripple.ntt.com 23 nHBSUZJnqK5BRu3bWAmebfkETNeEFmU7sm3DXzCuEYzRkAEdxuTy => validator.xrpchat.com 24 nHUFCyRCrUjvtZmKiLeF8ReopzKuUoKeDeXo3wEUBVSaawzcSBpW => ripple.kenan-flagler.unc.edu 25 nHUfPizyJyhAJZzeq3duRVrZmsTZfcLn7yLF5s2adzHdcHMb9HmQ => xrp.unic.ac.cy 26 nHDH7bQJpVfDhVSqdui3Z8GPvKEBQpo6AKHcnXe21zoD4nABA6xj => ripplevalidator.uwaterloo.ca 27 nHUFE9prPXPrHcG3SkwP1UzAQbSphqyQkQK9ATXLZsfkezhhda3p => alloy.ee 28 nHDB2PAPYqF86j9j3c6w1F1ZqwvQfiWcFShZ9Pokg9q4ohNDSkAz => aloha.xrpscan.com 29 nHUpcmNsxAw47yt2ADDoNoQrzLyTJPgnyq16u6Qx2kRPA17oUNHz => isrdc.in 30 nHDDE4Y3z5EE2VDDYrzheYQ4xC3F29SJsKT4dqhX4iyTLhuWgZnp => xrp.coinfield.com 31 nHUED59jjpQ5QbNhesXMhqii9gA8UfbBmv3i5StgyxG98qjsT4yn => crcm-xrp.blockdaemon.com 32 nHUryiyDqEtyWVtFG24AAhaYjMf9FRLietbGzviF3piJsMm9qyDR => www.bitrue.com 33 nHUXeusfwk61c4xJPneb9Lgy7Ga6DVaVLEyB29ftUdt9k2KxD6Hw => validator.xrptipbot.com 34 nHUnhRJK3csknycNK5SXRFi8jvDp3sKoWvS9wKWLq1ATBBGgPBjp => peerisland.com I am watching the Validations stream, which shows info by signing key/ephemeral public key, so n9 instead of nH, the above list doesn't do me any good. I have been pulling the ephemeral_public_key from ripple data v2 off the validator manifests, but a few times that provides bad info or doesn't have the manifest. My next option is to run the rippled validators command, but since the validators command is admin only its also not my first choice. it includes the following info today: "signing_keys" : { "nHB5kpvUaEpvCtwu31fMf6dTuuCNnWRctWrV3UEZ9rbtPdpvbUvJ" : "n9MtAgMDVFxEgzYsmZKNBYS4vTx76xSSD78tFdZFcL27aeXeeECQ", "nHB8QMKGt9VB4Vg71VszjBVQnDW3v3QudM4DwFaJfy96bj4Pv9fA" : "n9J2hKPRZ9bUmsBD6d1j16G2P1arMxfASgSKYpoK9dRpJEuD3Joz", "nHBSUZJnqK5BRu3bWAmebfkETNeEFmU7sm3DXzCuEYzRkAEdxuTy" : "n9MUYTDQbd5BqxRiU8JuYoDAD9Trjzvd9VWfVYadgwqmxREjvRe5", "nHBgiH2aih5JoaL3wbiiqSQfhrC21vJjxXoCoD2fuqcNbriXsfLm" : "n9KhsMP6jKFQPpjJ9VwqyZSwrL4shdX9YknRwmsAVL1RNVrx4jLm", "nHBidG3pZK11zQD6kpNDoAhDxH6WLGui6ZxSbUx7LSqLHsgzMPec" : "n9KaxgJv69FucW5kkiaMhCqS6sAR1wUVxpZaZmLGVXxAcAse9YhR", "nHBtDzdRDykxiuv7uSMPTcGexNm879RUUz5GW4h1qgjbtyvWZ1LE" : "n9LCf7NtwcyXVc5fYB6UVByRoQZqJDhrMUoKnr3GQB6mFqpcmMzg", "nHDB2PAPYqF86j9j3c6w1F1ZqwvQfiWcFShZ9Pokg9q4ohNDSkAz" : "n94RJmUKMJHTmuXhNYsFUwje9a9hD3Rw3dESntBDeonJLCjAEbMZ", "nHDDE4Y3z5EE2VDDYrzheYQ4xC3F29SJsKT4dqhX4iyTLhuWgZnp" : "n9KXj6AkXsMiPKgTs6axKn93CVKDmLsPch8QFZNA9xsGkQo3w5bk", "nHDDasc9BHNB99PW8KUduS8Phqg8NPUmjufzMU6HGGDMUH2xNpPh" : "n9L2y9THhdubapafmt7b2TRuhRUfPf1anchmiFyFSKBiaK3BEAwY", "nHDH7bQJpVfDhVSqdui3Z8GPvKEBQpo6AKHcnXe21zoD4nABA6xj" : "n9MSTcx1fmfyKpaDTtpXucugcqM7yxpaggmwRxcyA3Nr4pE1pN3x", "nHDwHQGjKTz6R6pFigSSrNBrhNYyUGFPHA75HiTccTCQzuu9d7Za" : "n9KKQUgUwXAAh7LKKjQos85vr19EvWghM13oBXurpvmRgEPZJ7XE", "nHU2Y1mLGDvTbc2dpvpkQ16qdeTKv2aJwGJHFySSB9U3jkTmj4CA" : "n9K2FpCqZftM1xXXaWXFPVbEimLX6MEjrmQywfSutkdK1PRvqDb2", "nHU95JxeaHJoSdpE7R49Mxp4611Yk5yL9SGEc12UDJLr4oEUN4NT" : "n9JtY9MqUcwKWenHp8WoRobFRmB2mmBEJd1ruJmhKGKAwtFQkQjb", "nHUCCckfXVBdoounaU7JVnfdPdMXEeetwH8VdCBXD996BaVZ8WdJ" : "n9KiJP9wcJheTs6187LB8SP6Pw1UghKUQLgq4RmMKheTzvVhmesM", "nHUED59jjpQ5QbNhesXMhqii9gA8UfbBmv3i5StgyxG98qjsT4yn" : "n9KcVtcHZThHainPdHC7CkQKZMEVjAcRujV2CMKdKHk65Ewsawsu", "nHUFCyRCrUjvtZmKiLeF8ReopzKuUoKeDeXo3wEUBVSaawzcSBpW" : "n9Lqr4YZxk7WYRDTBZjjmoAraikLCjAgAswaPaZ6LaGW6Q4Y2eoo", "nHUFE9prPXPrHcG3SkwP1UzAQbSphqyQkQK9ATXLZsfkezhhda3p" : "n9J67zk4B7GpbQV5jRQntbgdKf7TW6894QuG7qq1rE5gvjCu6snA", "nHUFzgC9fDw2MEDaiv9JMdBFhtJ6DMKoUCpS8gPGi6tkfbqmTyis" : "n94RChC3yKSHyXUerLYE1sjm13eP7hucSNpoZZTVgq4UtAiZAcgP", "nHUKp8XUkaFN6GzQ3o4qTE1w9aAD5uFjZ8vDt6pwjBsTFRq5FWEb" : "n9M6V1wyi9qwU3CESTmta3ANQehmdqFFf8osuR1jkKQ7GBcV7746", "nHULqGBkJtWeNFjhTzYeAsHA3qKKS7HoBh8CV3BAGTGMZuepEhWC" : "n9MZ7EVGKypqdyNguP31xSqhFqDBF4V5FESLMmLiGrBJ3khP2AzQ", "nHUT6Xa588zawXVdP2xyYXc87LQFm8uV38CxsVzq2RoQJP8LXpJF" : "n9Lq9bekeVhCsW8dwqzfvKsqUiu9Qxvwk9YmF2hxkBJjNrGNL5Fw", "nHUUrjuEMtvzzTsiW2xKinUt7Jd83QFqYgfy3Feb7Hq1EJyoxoSz" : "n9LLqqH1cVFPjEnQYFQ6DooxuhHPQxwXgMjDGrpJ6pb1WGDoi76Q", "nHUVPzAmAmQ2QSc4oE1iLfsGi17qN2ado8PhxvgEkou76FLxAz7C" : "n9J1GJHtua77TBEzir3FvsgWX68xBFeC8os3s5TkCg97E1cwxKfH", "nHUXeusfwk61c4xJPneb9Lgy7Ga6DVaVLEyB29ftUdt9k2KxD6Hw" : "n9KHXifDfimGs2CREvbRrAfjnoWcwjMCC8u8KLRTtrRAYk1ktSxX", "nHUcNC5ni7XjVYfCMe38Rm3KQaq27jw7wJpcUYdo4miWwpNePRTw" : "n9LEDYRJMx23ikoZS6YefTPuvLzNh56nXqpsavakWi2FivUEAkaq", "nHUd8g4DWm6HgjGTjKKSfYiRyf8qCvEN1PXR7YDJ5QTFyAnZHkbW" : "n9KSXAVPy6ac8aX88fRsJN6eSrJ2gEfGrfskUVJJ7XkopGsKNg9X", "nHUfPizyJyhAJZzeq3duRVrZmsTZfcLn7yLF5s2adzHdcHMb9HmQ" : "n9M2anhK2HzFFiJZRoGKhyLpkh55ZdeWw8YyGgvkzY7AkBvz5Vyj", "nHUkp7WhouVMobBUKGrV5FNqjsdD9zKP5jpGnnLLnYxUQSGAwrZ6" : "n9MzwWa4dwdZkRzj6XmihBG4ymGtMPd12cLjfhKwx5Hoqeu6WEgy", "nHUnhRJK3csknycNK5SXRFi8jvDp3sKoWvS9wKWLq1ATBBGgPBjp" : "n9LbDLg9F7ExZCeMw1QZqsd1Ejs9uYpwd8bPUStF5hBJdd6B5aWj", "nHUon2tpyJEHHYGmxqeGu37cvPYHzrMtUNQFVdCgGNvEkjmCpTqK" : "n9JebyUXwBa5GoYJQ6AbupoMKyE2zaiR3FTfDTMkxpMMv1KPmQEn", "nHUpJSKQTZdB1TDkbCREMuf8vEqFkk84BcvZDhsQsDufFDQVajam" : "n9LFSE8fQ6Ljnc97ToHVtv1sYZ3GpzrXKpT94eFDk8jtdbfoBe7N", "nHUpcmNsxAw47yt2ADDoNoQrzLyTJPgnyq16u6Qx2kRPA17oUNHz" : "n94D6X6oFGyuvWpSjGwv3rmGSPSi5gNEVCDwnEc8arLC6HnqfEhn", "nHUryiyDqEtyWVtFG24AAhaYjMf9FRLietbGzviF3piJsMm9qyDR" : "n9KAE7DUEB62ZQ3yWzygKWWqsj7ZqchW5rXg63puZA46k7WzGfQu", "nHUzum747yqip3HWSgzSNHNMjmLUqhroNVWidSRTREswEVhKNQEM" : "n9KQRiTw9LnSsVN2tv4guAqQ2KKUYmxnhT48QU2bbx8KmFGaUxTd" }, My problem is I am getting signing keys in my validations stream that aren't showing up in ripple data v2 query and you can't search by signing key- that I know of, so I check via the validators command and they might be there or not. If they are there and I look back at the ripple data v2 using the newly found public key, sometimes the signing key on v2 is different from the rippled validators command results. For reference, these were issues for me today: 1. n9Lq9bekeVhCsW8dwqzfvKsqUiu9Qxvwk9YmF2hxkBJjNrGNL5Fw ..I was able to find the public key via validators command nHUT6Xa588zawXVdP2xyYXc87LQFm8uV38CxsVzq2RoQJP8LXpJF, it has no manifest on ripple data (https://data.ripple.com/v2/network/validators/nHUT6Xa588zawXVdP2xyYXc87LQFm8uV38CxsVzq2RoQJP8LXpJF/manifests) 2. n9LrAWWnL8QYJym4PsnjHeun5CsKJ4ZoBfqD5FrESuH5DwzRaZYH I don't see this at all in my validators command results.. I walked thru the unl list manually to see what i could be missing, and I see that shadow.haas.berkeley.edu is missing, so I assume that this is for Berkeley but its just an assumption. If its not, then I don't know why this is showing up if its not in my validator list. Does anyone have a tip to easily identifying validators by signing key or ephemeral public key?
  2. Re:Performance and Resource Consumption For me the memory requirements are the most expensive aspect of running a stock node. Assuming memory will get cheaper, keeping the requirement of ~16-32gb, no matter what the future average tps is would be very helpful to the average Joe's budgeting.
  3. @UmebaraY I made a lazy attempt at watching the votes of the default UNL. (https://padanaram.digital ->validator votes). You have to wait for the flag ledger in order to see them, which could be up to 16 minutes. I watch the validation stream, which after verifying the votes with a couple validator operators, seems to provide the correct amendment votes. It's a pain to stay on top of who the validators are when the public keys of some validators seem to change from time to time, so you might see validations that are not labeled. Looks like Ripple finally set some of their validators to vote for fixMasterKeyAsRegularKey, so it's over 80%, now we wait for the 2 weeks to pass.
  4. The first set regular key transaction per account is free, you don't have to pay the 10 drop fee. After you set one regular key this flag flips to spent, you used your free one. If you paid for your first set regular key, you do not get a free one next time. One chance only per account. Examples : spent with no fee paid for 1st- https://test.bithomp.com/explorer/r4jJwo1QNxvESLxQ5njTAcEsUGuM6rs2um Spent with fee paid for 1st- https://test.bithomp.com/explorer/rPmn6jRquyPjLPGKyyQzfpqvwpVqoa6fUr
  5. In case this helps the next person, I was struggling with this because when i submitted the trustset transaction, even though i was only using the 2147483648 (tfFullyCanonicalSig) flag, I could see the RippleState flag set to 131072 (tfSetNoRipple) on the ledger so i assumed it was OK, but i was wrong. When you submit the transaction with the flags set to 2147614720 ( tfFullyCanonicalSig and the tfSetNoRipple ) you will see the RippleState flag for that trustline set to 2228224 which is 131072 (tfSetNoRipple) AND 2097152 (tfClearFreeze). hopefully this saves someone wasted time down the road.
  6. You can try taking a shot at generating your own keypair, all you need to start is node and npm installed on your machine. If you are not afraid of node or text editors this will be a breeze, but TBH it does the same thing as bithomp generator (bithomp uses ripple-lib; below link uses ripple-keypairs which is included in ripple-lib). Plus, this guy in the linked post is as trustworthy as anyone involved with XRP: as mentioned above by AT3N you can use the 12 or even 10 (* your multisig multiplier), 90-99% of the time. You can see the current open ledger fee at the top right of https://padanaram.digital/ most of the time this will be 10 drops. You can check it during times of higher volatility and see it spike into 5000s. This is usually caused by the by bots fighting over an offer they want to grab before anyone else due to arbitrage opportunity. Even if you submit a tx with a 10 drop fee and the open ledger fee is elevated, if you do not include a LastLedgerSequence, your transaction will go thru when the fee drops back down, which could be as fast as the next ledger or a few minutes depending on the ledger activity. I have never had it take longer than 10 seconds but who knows what the future will bring.
  7. { "TransactionType": "AccountSet", "Account" : "rABCDEF... ", "Fee": "12", "Sequence": 5, "ClearFlag": 4, }
  8. Yep, by using either the regular key or multisig, both worked for me. This was on testnet but i can't see why this wouldn't work on live XRPL as well.
  9. You can re-enable the masterkey if you can gather the required number of signers for multisigning. Assuming you are able to submit a multisign transaction with the required signing weight, you would then submit a accountset transaction with the clearflag field set to 4.
  10. @zach There is an optional SourceTag field you could check for, (Optional) Arbitrary integer used to identify the reason for this payment, or a sender on whose behalf this transaction is made. Conventionally, a refund should specify the initial payment's SourceTag as the refund payment's DestinationTag. https://developers.ripple.com/transaction-common-fields.html
  11. I made a few minor updates ( added back buttons, fixed typos, fixed the deposit auth transaction, etc)... But also wanted to add I shared this for people to use on TESTNET to try out different transaction types. I will use on the live XRPL, BUT if you do PLEASE be sure to double check the signed transaction JSON prior to submitting, and make sure your amounts (fees or amount sent) are correct first. I am just a rookie and while everything seems to be working as intended, i do not have experience with the edge cases of dealing with large numbers and JS. Also, the part I really wanted to show was how much easier and less stressful it can be using qr codes rather than typing in the address/secret, the paper wallet is going to still take up the same amount of physical space, why not take a short cut and include the QR? If interested I added a testnet account option to Bithomp's awesome paperwallet, which includes qr codes so you can print out a few and play around. The modified paperwallet can be found here: https://kakoyla.github.io/xrp-paper-wallet/
  12. Everyone has been trained to doubt everything thanks to the bear market. This is incredible news, being totally undervalued by the community, wait until this spreads.
  13. This graphic is a little off, $98m direct is huge but the 2018 Q2 and Q3 are showing total sales while the rest of the list is showing direct.
  14. I will work on it, thanks for the input! yes, that's the only place i know where you can send the JSON without submitting it yourself via your own code. If you leave it as a tx_blob, you can submit it at any of these, there are probably more that I don't know about: https://kyteapp.co/ <-- click on send air gapped transaction https://bithomp.com/submit/ http://ripplerm.github.io/ripple-wallet/ <-- go click the tools tab, then submit sub-tab padanaram.digital <-- click XRPL then submit transaction for live xrpl or click testnet then submit transaction for testnet (I do not know of any other easy testnet submit sites) I was thinking this exact same thing. If you can see the tx_JSON matches what you expect, since this will never be run online, does the rest of the code even matter or is the end result all you need to worry about? If you want to see the tx_blob deconverted back to JSON you can drop the tx_blob into a decoder i made, padanaram.digital then click quick tools then decode tx_blob, it will give you the JSON. Assuming a simple payment....besides the destination and transaction type, I think the amount and fee are the most important fields to check. Amount is shown in drops so you would divide that by 1,000,000 to see it in XRP. Fee is also shown in drops but most people think of fees in drops already anyway, ie a fee of 12 would be 0.000012 XRP If the reason you want to check this is because of trust, you probably won't want to trust something else I provided, so you can do it yourself. deconvert the blob yourself: assuming you have node installed on your pc, install ripple binary codec (https://github.com/ripple/ripple-binary-codec) npm i ripple-binary-codec save this code as decodeTx.js: const binary = require('ripple-binary-codec') const signedTX ='ENTER YOUR tx_blob HERE' var decoded = (binary.decode(signedTX)) console.log(decoded) Then update const signedTX with your tx_blob and save Run it on the command line with node decodeTx.js The decoded tx_blob will be shown and you can now review to make sure the fields present match your expected transaction.
×
×
  • Create New...