Question about JPLSnapshot addon's specific functionality

in 'addons/JPLSnapshot' , the file reads: "the downloadJPLSnapshot API can be used to generate a genesis block JSON for a clone to satisfy the JPL 10% sharedrop."

So, I have created my own clone, for example. I have two nodes (I have not connected them but just gotten things ready, a bit busy with University stuff. anyways). So once they are running and find each others IP's and ports, will sync as peers - their syncing should start creating block heights, even with zero transactions, right, at a certain pace?

Prior to any forging (I should reread the whitepaper)? I am very "touchy" about (not) doing anything though as I would like to know what it is I am doing and not merely following instructions that I do not comprehend, or need help and affirming what I do or do not know...

I have also created new accounts for my new NXT blockchain clone, to have new genesisAccounts.json

My question really is, if the JPLSnapshot takes thus the block height from the current blockchain, and does not specifically refer to the NXT blockchain height (looking for it on the internet via specified ports and IP's, but that the snapshot is relative to the API within which it is running?, and so will refer to my new clone's current block height. Is my understanding of this JPLSnapshot correct? I am not sure? I have not gotten to the stage of forging coins for my new accounts and clone, but just don't want to hit a wall if I misunderstood what the JPLSnapshot does...

Because if I do not understand correctly I won't be able to forge, in order to provide 10% to Jelurida. However I would like to donate 20% of my blockchain to Jelurida.

I am very curious about this blockchain technology from you, and the fact its been so massively ignored. Did you hear about Vitalik Buterin recently mentioning his thoughts on POS But that he wants to implement it - I remember in 2014 that I did not buy ethereum because I was under the impression it was a scam premine type situation... How silly I was...

and

It seems very much a sad and rip off deal that NXT or Ardor are not mentioned. I wonder how you feel about this? Obviously these other currencies are more marketing and fad oriented...?! These are not the only articles ranting about the benefits of POS and having not the slightest representation of NXT or Ardor... it is something that should be of concern, but it appears this is not. It does not appear a political game to be no.1 for Jelurida, even though it appears you are no. 1 as NXT was created in 2013? I mean, first, and ethereum is no. 1.

I hope you can direct my thoughts around correctly understanding the JPLSnapshot's specific function in relation to the clone's blockchain. or again, if it searches for blockheight from the actual NXT's blockchain?

Is my assumption correct that it refers to the current clone blockchain's height in the API - it is not a snapshot of the actual NXT blockchain, is it? No? I hope my understanding is correct, sorry for obsessing.

No, the nodes per se don't create blocks. Forgers create blocks. You need to start forging with some account with enough NXT (or PET or the name of your token) to start creating blocks. You actually don't need two nodes for that.

I'm not sure to understand the question. About the height parameter of the snapshot add-on it's used to query the balances of NXT accounts in order to compute the airdrop, but the height itself has nothing to do with the new clone. You will start at height 0. Your clone will not connect to any NXT node, and if it does it won't work because the genesis block is different. That's why you must use different ports.

You don't donate anything to Jelurida. You are doing an airdrop to current NXT holders, which means that a 10% of your tokens will be distributed to NXT accounts proportionally to the balance they have on the NXT blockchain. About increasing that to 20% I guess it's fine with the license but I don't think the add-on has the option. You will need to do that manually.

Sergei,
"You should run the add-on on a regular NXT node just to generate the genesis parameters JSON file. Then you don't need the add-on on your clone."

How could the genesisparameters json file created on the NXT blockchain be used on another, even though the other is a "clone" - the clone is renamed with a different prefix to distinguish its separate identity from NXT, and uses different ports and has peer IP addresses not on the NXT blockchain.

How I will forge coins on this new independent chain remains a very interesting mystery to me - which is my worry that I do not understand this part of using a genesisparameters file from NXT blockchain on one that isn't connected to NXT at all (ports, name, or peer IP addresses)...

I have just looked into the genesisparameters json file, I am curious why does it need to be generated using the JPLSnapshot? Is this only in relation to the airdrop of 10%?
What if I use this genesisParameters.json file created using the JPLSnapshot on a NXT node and run it in my new renamed clone with its own ports and peer IPs, along with genesisAccounts.json of wallets created in and for the "new" (cloned) API?

What if, instead of being generated on a NXT node with the JPLSnapshot, the genesisParameters file contains the public key of a genesis account for forging, a public key and address generated on the new clone's API, without the JPLSnapshot?

So my problem is understanding why I should use which genesisParameters.json file (one created on a NXT node with the JPLSnapshot, and another genesisParameters.json file created on my new clone's API).

Of course I am assuming that the genesisAccounts.json file should include wallet addresses and balances and public keys which were created on the clone's API.

My apologies, but I will test now and compare my two problems, I'm just hoping someone can explain my misunderstanding "off the cuff / off the bat" / without preparation.

First of all I want to make sure you have read and understood these resources:

The genesisParameters.json file contains the epoch of your blockchain (time of the first block, the genesis block) as well as the public key of the genesis account. This file is manually edited.

The genesisAccounts.json is the file produced by the execution of the downloadJPLSnapshot API. That API requires a JSON file itself with your initial account balances as explained on the README for the clone kit project. The purpose of the add-on is to add the airdrop balance to existing NXT accounts, that's why it needs to run on an NXT instance.

Those files have nothing to do with the name of your token or product, the ports or anything like that. To change those you will need to edit the corresponding source files.

Once you have these two files you just place them on the conf/data directory replacing the ones from the repository and start your node.

I see. that was my understanding, thank you for clarifying. I have. however I do not understand how I will then forge coins on my new blockchain, say NFT (not NXT)?

Would I be able to create my own genesisAccounts.json file on my own chain's node, and forge coins without an airdrop?

What confuses me is that the airdrop drops NXT to existing NXT accounts, and is generated on a NXT node, however I am to use a file from that blockchain, on my new and unrelated blockchain? This is what confuses me.

The airdrop drops new clone coin to new clone coin addresses created which will use the same passphrase as the nxt address and the address will be the same except nxt- will be replaced with the new clone coin prefix. However, it will not do anything with the nxt blockchain, except extract the nxt addresses to create new clone coin addresses to distribute the 10% to.

If you do not do the airdrop, the 10% is not distributed and you are not abiding by the license agreement, so the airdrop is essential.

As Sergi said
Those files have nothing to do with the name of your token or product, the ports or anything like that.

Sounds like for nxt holders, it would be good to make it as easy as possible for people to increase the 10% up to 50% which was the rate for Ignis, rather than having to do it manually.

1 Like

Hi Timmy, thank you for the clarification. I believe I understand correctly now and will try and implement in the next 48 hours. I am very grateful for the help I have received.

Just to be certain.
So the wallets I specify in newGenesisAccounts.json, they are
NXT wallets with NXT prefixes, and I will then in the NXT API
using the JPL Snapshot, generate GenesistAccounts.json from this file.

Then, I compile my clone, and if I insert the wallet addresses (minus the NXT), they should contain the number of coins that was designated for the NXT address with the same sequence of numbers following the prefix.

In newGenesisaccounts.json
{
"balances": {
"my nxt address here": 90000000000000000
},
"publicKeys": [
"the public key of this nxt address"
]
}

These are NXT addresses that receive the currency. I then use the JPLSnapshot as menioned and the file is generated, genesisAccounts.json.

Let us assume the prefix has been altered to PET, I can now use the NXT-this-extension, and simply place -this-extension in my PET wallet address at login and use the NXT mirrored wallet's passphrase, and these accounts should contain the new currency's balance. I hope my reading of your explanation is correct, I have not tried but think I may understand correctly now.

I will try today and tomorrow patiently and see if I can manage, thank you for the clarification. I was finding it a bit confusing as of course the clone has its own blockchain and was not sure at all (I have not actually gotten so far as to trying it, but was concerned about the implications of not using the Snapshot...).

The prefix of the addresses (NXT, PET, whatever you use) it's purely cosmetic. The Reed-Solomon code after the prefix is what matters. Changing the prefix doesn't change the address, which is the account number (64 bits integer), which itself is derived from the public key (256 bits), which is ultimately derived from the private key (256 bits).

At the end the private key and public key are the same, so it's the same account.