variable sourcePrivateKey is not define

[Relect]

https://github.com/XRPLF/xrpl4j/blob/eabbafeb8db092fff845b7f3a5c86a348b14e57c/README.md?plain=1#L210 senderPrivateKey ?

Why Seed seed = Seed.ed25519Seed(); // <-- Generates a random seed. Transactions signed with a randomly generated key? What nonsense?

// Construct a Payment
Payment payment = ...; // See V3 ITs for examples.

where to watch it?

[sappenin]

Hi @Relect - thanks for your post.

Transactions signed with a randomly generated key? What nonsense?

It's unclear what you're asking here -- in the example you're referencing, a Seed is generated with random entropy, but this is simply for example purposes. Once you have a Seed, you can then construct an in-memory private key deterministically (You can read more about Seeds here).

There are a variety of ways to construct a Seed. You can construct one randomly (as you point out), though that's typically used for testing or examples. You can also construct one from a passphrase, or even from a base58-encoded "secret", such as what you'll get from a testnet faucet. For example, see fromBase58EncodedSecret or ed25519SeedFromPassphrase/secp256k1SeedFromPassphrase.

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.

where to watch it?

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?

[Relect]

In general, it's best to not use in-memory private keys this is obvious, but in the example given, you might think that transactions are signed each time with a different randomly created private key.

It is not clear where to get the index value for ledger_entry method ; the index != ledger hash. And how can I get all transactions one block using method ledger_entry?

[sappenin]

this is obvious, but in the example given, you might think that transactions are signed each time with a different randomly created private key.

Hmmm... I'm not sure I agree. In each example (i.e., In the README and in the ITs) only one Seed is generated per account, and used consistently for each signer.

Happy to entertain change suggestions though if you think it might help clarify something.

It is not clear where to get the index value for ledger_entry method ;

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 ledger_index in that response. Another way is to maybe get the transactions for an account, and inspect each transaction to see which ledger each tx was validated in. Another way is to subscribe to a live transaction stream like the explorer does (more info here for how to subscribe to a ledger stream. Also note that xrpl4j does not support WebSockets very well at present). You could also make a ledger_entry request with a ledger shortcut, like validated, which will return the most recently validated ledger.

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.

[Relect]

Tell me, here I am generating an address and a private key in xrp4j, adding 10 xrp to this address. What are the guarantees that someone else will not generate a similar address with a different private key and will not be able to manage this address? Generating addresses is just a matter of having the appropriate power.

[sappenin]

What are the guarantees that someone else will not generate a similar address with a different private key and will not be able to manage 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 Seed or (2) rely upon a poor Entropy generator/instance to then construct a new Seed.

For clarity, this is the chain of data needed for an XRPL address (in xrpl4j, but this roughly mirrors other language libraries):

Randomness --> Entropy.java -> Seed.java -> PrivateKey.java -> PublicKey.java -> AccountId -> rAddress

(The rippled/generic version is described well here).

In the case of xrpl4j, in order to create a new ranomly generated Entropy (to create a random private key), we rely on SecureRandom to ensure good entropy/randomness, and then rely upon that to create a Seed. There are caveats here, so google around for things to consider with SecureRandom and if you don't like what xrpl4j is doing, you can implement your own solution that conforms to the Seed interface).

Keep in mind that Seeds deterministically yield a key-pair, which then yields an address -- so if you create a Seed with poor randomness (e.g., via a Passphrase or poor JVM/system entropy or whatever) then you might have problems.