Indeed - no time when James is "whizzing past at 1000+ miles per hour" to think about anything other than just trying to wave some sort of a "stop sign" at him.

You might think that you could try to guarantee than an email has actually been sent if the "receiver" indicated that they had received it through another AM, however, just because they didn't receive it doesn't mean that it was sent - again - "there is simply NO WAY to do this - so please stop trying now" (you are wasting time just as much as you would trying to solve "the halting problem").

Understand that this is why you don't want to mix up stuff from "within the blockchain" to stuff that is "outside the blockchain" as only the former can ever "be proven by the blockchain".

I don't see why you would want a Nxt VM script to "output an email" (or do anything else outside of the blockchain for that matter) - you do understand that whether such email was actually even really sent simply *cannot be proven* (as you are dealing with SMTP rather than a blockchain)?

Also SMTP is going to require accounts that need to be signed into and you don't want to end up with people effectively running "relay servers" or they'll end up on email blacklists.

Wouldn't it make more sense for such things to be services instead?

About walking vs. running - you are getting far too excited jl777 - can you just take something to slow down to a pace that we can keep up with (by the time we've tried to discuss one of your ideas you typically have posted 3 others).

Why the rush?  Oh - let me take a guess - a bunch of new accounts praising another new account that is trying to get "investment".

Hmm... well wasn't HAL 9000's role to basically manage the spaceship (and that was written in the 1960's)?

One interesting quote from the Wikipedia entry on HAL 9000 is "For example, AI pioneer Herbert A. Simon at Carnegie Mellon University, had predicted in 1965 that "machines will be capable, within twenty years, of doing any work a man can do",[19] the overarching premise being that the issue was one of computational speed (which was predicted to increase) rather than principle."

Well - we still don't have a HAL 9000 even 50 years since it was thought of (and I don't see one about to appear in the next 10 years either) so this is why I find some of this DAC stuff a little bit like the whole AI stuff of the past.

Although the Nxt Asset Exchange will be a useful addition I think that we are missing something that could be much more useful (and perhaps a "killer" addition) and that is "atomic cross-chain crypto-currency transfers" (some of you would recall I've already mentioned it).

As far as I can tell no-one has actually built such a system and also so far I can't even tell if such a transfer using TierNolan's approach (https://en.bitcoin.it/wiki/Atomic_cross-chain_trading) has ever actually been tested (if anyone has a link that shows such a transaction having taken place then I'd be very interested to see it).

IMO this would really be a "game changer" as it could allow people to trade crypto's directly without an exchange and without risk (beyond having to wait for the "refund" problem that is necessary for TierNolan's solution in case the trade doesn't get finalised).

It wouldn't work fast enough to do "day trading" but for those not in a huge rush the promise of 100% secure transactions with only minimal blockchain fees would be pretty appealing.

What do you guys think?

It is without doubt an interesting concept but...


the question is when it will move from the world of fiction to the world of reality (am hoping sooner rather than later myself but still think it will take quite a while and if it needs to be an AI then that "quite a while" could easily be another 50 years away).

Very interested to see how this "parallel chain" stuff is going to work - and yes I guess it could be the safest way to do the "smart contracts".

Am guessing that if we approach it that way then the 100+ TPS should not be affected by this or other ideas that could also be put into "parallel chains".

Maybe this is the "real ace" that Nxt has up its sleeve?

After reading some of the potential problems with implementing a "Turing complete" scripting language I wonder if it might not be better to "wait and see" how things go with Ethereum before "jumping on board".

(at least IMO the concerns are enough to perhaps bump this feature down a step or two below other features being either considered or currently developed)

FYI - https://bitcointalk.org/index.php?topic=431513.msg3049193;topicseen#new (some important reading wrt having a "Turing complete" scripting language by some of the better known names in this forum).

(btw - good to see CfB posting in that topic)

Perhaps we aren't all as keen on the puzzles (generally I am - but perhaps like some others am just getting "tired" trying to keep up with this topic).

Personally I think that 100 TPS, a max. size limited blockchain and being able to do atomic cross-chain transfers (i.e. a trust-less P2P crypto-currency market) would be about the most relevant features to differentiate against other competitors.

Atomic-cross chain transactions and the like will require a hash function (I would assume SHA256 would be the most likely to include).

If we can't get atomic-cross chain transactions to work then I think the idea of being able to have a trust-less P2P "coin" exchange simply won't work (not that we have to use a "smart contract" to do this of course but it would seem like something reasonable to support as other such "use cases" undoubtedly will arise).

I am guessing so too - although I think it would make things rather complicated (as you would have to keep a "count" of how many accounts have that balance and then "remove" that balance when that count goes to zero, etc.).

To my thinking a simple B+Tree keyed on "account id" is much easier to picture and to work with (even if it takes a lot more storage).

Guess a trade-off between simplicity and size will have to be made in order to come up with an "optimal" solution.

Yup - but if when you go to create a new account you can include the public key it must use (this will require a fee to stop spamming) then it wouldn't matter if the same account with a different public key had existed before (and no way to "drain" that account).

If it is possible to create a "new" account *with* a public key (as an atomic operation) then this shouldn't be a problem (isn't that coming?).

Sorry - my mistake in wording - so in your approach the account id is effectively a "transient" determined when you load an index node into memory?

I still think you need to sort by account id not public key (as you send Nxt to an account # not to a public key) and of course there are Nxt accounts that actually don't have a public key associated with them (I think in terms of efficient DB structures as I've done a lot of work with that over the years).


Agreed - it would make sense to limit such things to the last 1440 blocks.

Okay - I sort of get it now - but I'm not sure if that's going to be so useful for data storage as you will need to index on "account" not on "balance".

Am not quite getting this - is your figure of 44721 based upon a "current snapshot" - as I am talking about the theoretical maximum storage required for either 1M accounts or 1B accounts.

I am also not sure where the size estimates are coming from.

At a minimum you would need to store the account # (64 bits) plus the public key (256 bits) plus the balance (64 bits?) which would be 384 bits or 48 bytes per account.

If this were being stored in a "flat file" then 1M accounts would requre 48 MB (and 1B would require 48GB).

Assuming only a "flat file" was used (i.e. no index file) then a map (stored in RAM) to identify where to find each account (64 bit file offset) would be required (if we had 1B accounts then that map would easily be at least 2GB and although that isn't too unreasonable it would make starting up the node very slow as it would need to create that map by scanning a 48GB file).

More likely you'd use an index file then (so add 2-4GB extra) requiring a node that is handling 1B NXT accounts to allow for approximately 50-52GB (actually not too bad IMO) for the "last checkpoint".

Assuming that the "blockchain" between checkpoints is no greater than say 50GB then it would look as though 100GB would probably be enough (although this last calculation would need some more analysis).