Nice - I think we could indeed create an AT to do this. Because the code is open and unable to be changed after the AT creation tx is confirmed then it can actually be "trusted" to do things like this.

The tricky part is going to be able to make sure that people know a trustworthy AT from an "evil" AT (that requires being able to understand the code which is why that code needs to be as simple as possible).

I've been in China more than 7 years now and actually access to numerous overseas websites (even non-https) has got *slower* over that time (and I not talking about anything that would be considered "controversial" here).

At the moment most certainly (there is a hard-coded limit to 250 txs per block).

How many transactions you can fit in a block doesn't necessary equal TPS (you could work out some sort of average figure I guess but again there is simply no guarantee about such things).

A lot of figures people like to use are not to do with "reality" but instead to do with "marketing".

Agreed.

And once again - James goes of into "fantasy land" where real things like "network latency" don't exist.

You were told the reasons - if you just want to ignore them that's fine - but you can't change facts with statements.

When being the key word here - it isn't fast enough at the moment unless you think the internet is just your own country.

Basically if you are using "localhost" then I think using "http" rather than "https" is fine (there is a much greater chance of a key-logger stealing your password).

If you are using your web server remotely then you will need to read up on creating a self-signed SSL certificate in order to use "https".

I think you'll need to replace the forward slashes with backslashes.

Hard to say - but quite likely that it would - it tends to also do things like "ban you for 30 minutes" randomly.

That depends upon the network topology which isn't even known - basically you'd have to measure these things "in the wild" to even roughly work this out.


Our TV has WiFi and we can watch high quality movies here (many for free) so inside of China it is very fast (am only using 2M standard home connection).

That GCF is mostly automated now btw and does detect encrypted traffic (which is generally when it "slams on the brakes") and it gets "smarter" every year (most standard VPS services don't work here now).

What you are working against is a thing called "network latency" - and the problem is that you would need to "own the physical network" to be able to make "super fast guarantees" which isn't going to happen unless we are somehow able to replace the world's physical infrastructure with something better.

Understand that when I "ping" ciyam.org from here in China it takes over 300ms on average but when I do it from the US it takes a fraction of that time.

There is no software that can improve the hardware infrastructure it sits upon (and countries like China make it all the more difficult by putting software layers above the hardware to purposely slow it down).

There are "no magic bullets" here apart from trying to have major hubs (as CfB mentioned) that end up doing most of the forging and have super fast internet connections. Even then you are going to have troubles with putting hubs in China or numerous other countries (weakening the network itself due to centralisation).

You are likely to end up with many more forks making those earlier confirmations less useful (meaning you will quite likely require 6x as many confirmations to be "secure" thus not actually be achieving anything).

I see no point in re-creating 1990's speeds for our "platform for the future" - people will be using smart cards that sign txs in an instant and it will be up to retailers to decide their own risk levels.

Amalgamation?

or perhaps Alloy?

I do agree that the code that I've seen is very readable (I am not a fan of writing many comments myself - good code should make sense on its own. Comments are best reserved for special notes or kludges rather than telling you what the code does itself better).

It would suit the pattern better (that's why we have AT).

All AT txs come "from the AT" (as it has it's own account).

I created CIYAM Open (https://ciyam.org/open) for doing Project Management (and I hope to create its decentralised Nxt replacement via ATs in the future) and will most likely end up managing the Nxt AT project listed on it.

You are welcome to use that platform for other Nxt projects if you are interested to (I won't charge anything for that but you'll need to let me know what account to create a Project for as only an "admin" account can create Projects). Understand that it does things in BTC (although tasks for 0 BTC are not in any way being prevented and there is a USD field that can be used). If that is not deemed suitable I understand (I don't have the time to change it to work with NXT at the moment although I would be happy to add a NXT field before the USD field if that would be of benefit in the short term).

It also has a functioning (although not wonderful) Forum which gets very little use currently that you would also be welcome to use (although I won't tolerate personal insults, bullying, trolling or spamming).

All data in the VM would be expected to be zeroed prior to it being called and I've also specified that the start of the data area (for constants) could be provided with the AT creation tx.

Also I have now added "indirect assignment" and "indexed indirect assignment" op codes so that if such initialisation was required then it would not take many op codes to do it.