Besides, there are many other problems. Most of these emails would end up in spam folders anyway
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. ![Grin](https://bitcointalk.org/Smileys/default/grin.gif)
|
|
|
If the source to SMTP server is reviewed that it does send the email (backed up with test results) and as part of the sending process it adds a hash value of email to the blockchain. I think that allows peer verification, please explain where I am wrong. I am certain I have made mistakes somewhere and I am still coming up to speed with this whole decentralized blockchain approach.
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". ![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
|
|
|
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?
|
|
|
The big innovation here is that the CEO himself can be replaced by an algorithm that is guaranteed to act objectively and in the best interest of whatever "charter" has been hard coded into the DAC.
It is without doubt an interesting concept but... PS. Daniel Suarez' novel Daemon from 2006 was the first place where I saw this idea explored in detail. Highly recommended!
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).
|
|
|
I think that we could run Scripting on a parallel chain. Main chain won't be hurt if something goes wrong.
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)
|
|
|
Not only general idea. I leaked a lot of hints, use them.
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.
|
|
|
Why would someone need SHA256 in a script?
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 think he means that there is only 447114 permutations of possible balances (at maximum). I assume this is so you can assign a certain index to a particular balance, to save space? I don't know ![Grin](https://bitcointalk.org/Smileys/default/grin.gif) 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.
|
|
|
That is, the public key would be discarded on an empty account. No?
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).
|
|
|
Obviously we would completely purge any public keys for accounts with zero balance and with no aliases.
Is there any way this could lead to a Sybil attack? 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?).
|
|
|
But that's what I wrote.
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?
|
|
|
The performance version would be a list of public keys sorted by their account id with their balance id, which would take 34.34GB. This would have search performance lg(number of accounts), very fast.
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). There's one big problem, a "referenced transaction". Currently you can send a transaction which is valid only if referenced transaction is valid. That's fundamentally incompatible with limited blockchain. So either the 'referenced transaction' is limited to 'transaction in the last n blocks' or it goes entirely.
Agreed - it would make sense to limit such things to the last 1440 blocks.
|
|
|
There are only 44720 different balances possible at the same time, for one billion coins, starting from 1, for integer balances. It's the sum of an arithmetic sequence summing to one billion.
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".
|
|
|
Since there are less balances (44721 max) than accounts its better to have balances with accounts, not accounts with balances.
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).
|
|
|
|