Jump to content

Kakoyla

Member
  • Content Count

    270
  • Joined

  • Last visited

11 Followers

About Kakoyla

  • Rank
    Regular

Recent Profile Visitors

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

  1. You can use the binary codec to decode the blob. const binary = require('ripple-binary-codec') const signedTX = '' var decoded = (binary.decode(signedTX)) console.log(decoded) If you just have a one off transaction you want to look at, I made a quick decoder tool for myself at Padanaram.digital then click quick tool's then decode tx blob. It's not perfect but works for basic transactions
  2. I don't see the need for Ripple to buy any of the previously mentioned companies(r3, swift etc). I do think buying or merging with a bank would be very beneficial. Cross River, and Silvergate are just two examples of banking institutions I would like a piece of, if I was doing the buying. Not saying they could afford a complete takeover but a piece like we saw with mgi.
  3. 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 nHUKp8XUkaFN6GzQ3o4qTE1w9aAD5u
  4. 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.
  5. @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 valid
  6. 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
  7. 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 tim
  8. 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:/
  9. { "TransactionType": "AccountSet", "Account" : "rABCDEF... ", "Fee": "12", "Sequence": 5, "ClearFlag": 4, }
  10. 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.
  11. 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.
  12. @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
  13. 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
  14. 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.
  15. 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.
×
×
  • 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.