-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
variable sourcePrivateKey is not define #528
Comments
Hi @Relect - thanks for your post.
It's unclear what you're asking here -- in the example you're referencing, a There are a variety of ways to construct a In general, it's best to not use in-memory private keys, if possible (that functionality is intended to satisfy mobile use-cases). For backend usage, it's best to use something like an HSM or otherwise. For a simulated example of this, see DerivedKeySignatureServiceTest which mocks a service that would do actual signing.
Can you clarify this question, too? If you want to see an example in action, try running this integration test (SubmitPaymentIT.java) in your IDE and step-through it with a debugger so you can see what it's doing? |
In general, it's best to not use in-memory private keys It is not clear where to get the index value for ledger_entry method ; |
Hmmm... I'm not sure I agree. In each example (i.e., In the Happy to entertain change suggestions though if you think it might help clarify something.
For better or worse, there are a variety of ways to obtain this value. First, take a look here here so you have a good understanding of the options for what that value can mean. In terms of obtaining it, one way would be: you looked up a transaction by-hash, and saw the If you're just trying to understand how things work, then hopefully the above is helpful. But if you're trying to do something specific, let me know and maybe I can provide some more targeted pointers to get you sorted. |
Tell me, here I am generating an address and a private key in xrp4j, adding 10 xrp to this address. |
The XRPL rAddress is derived from hashing the public key that corresponds to an account's private key. So, there's almost no chance of two people generating the same address (in xrpl4j or otherwise) unless they (1) use the same For clarity, this is the chain of data needed for an XRPL address (in xrpl4j, but this roughly mirrors other language libraries):
(The rippled/generic version is described well here). In the case of xrpl4j, in order to create a new ranomly generated Keep in mind that Seeds deterministically yield a key-pair, which then yields an address -- so if you create a |
xrpl4j/README.md
Line 210 in eabbafe
senderPrivateKey ?
Why
Seed seed = Seed.ed25519Seed(); // <-- Generates a random seed.
Transactions signed with a randomly generated key? What nonsense?
where to watch it?
The text was updated successfully, but these errors were encountered: