NXT :: descendant of Bitcoin - Updated Information

[allwelder]

Nxt introduction video with Cantonese
http://v.youku.com/v_show/id_XNjcwNTEyMzAw.html

Nice!

TKS.

[1713928902]

1713928902

[1713928902]

1713928902

[1713928902]

1713928902

[1713928902]

1713928902

[CIYAM]

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".

[tman10]

NxtChg left us, withdraw from the exchange. He had another of his emotional breakdowns caused by his Obsessive–compulsive disorder and left, althought we asked him to stay

a) I am a programmer with OCD, most of you here know what I mean: we obsess about tiniest details and double, triple check everything, especially something as important as sending a big chunk of money.

Thanks salsacz...That doesn't help me with my issue but that's not your concern...Thanks again

[Eadeqa]

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).

NXTsmtp is just for proof of concept that incorporates something everybody is familiar with. I want to verify the peer verifiability of hardcoded NXTplugin followed by external NXTplugin. I am not worried about NXTsmtp for anything other than proving that NXTplugins work and are peer verified. At first I couldnt understand how on earth a DAC could be implemented. When I started thinking about email plugin, it became not as hard.

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.

The problem is that I see all of the things I am posting about as connected. Like the elephant described by different people. All sounds very different, but it is all the same elephant. If I described the elephant in its entirety, it wouldnt fit in posts. I feel a great sense of urgency due to competitive pressures.

James

P.S. I usually dont post when I am sleeping or flying

James,

First of all thank you for all your great ideas, but ...

My background is IT project manager and I am going crazy by you.

You throw 10 projects on the table but have not one worked out.

exactly. it's like everyday there is something new. zerocoin, then turing complete language, then decentralized cross-chain exchanges, then plugins, then emails ... Why on earth would I want to use Nxt for emails? There are zillions of better email services, and Nxt already has  private messages.

[nxtru]

SMTP not SNMP

Sorry, I always confuse them. 

[Eadeqa]

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").

Besides, there are many other problems. Most of these emails would end up in spam folders anyway

Sender Policy Framework

http://en.wikipedia.org/wiki/Sender_Policy_Framework

[martismartis]

Why target % is so high in the last blocks?

[pinarello]

Why target % is so high in the last blocks?

how high?

[CIYAM]

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.

[martismartis]

from 900 to 2000

[jl777]

I am a bit concerned that there has been very little feedback on my recent proposals, blockchain FIFO and NXT plugin architecture.

I've been reading your posts with interest and trying to digest them.  Much of it sounds good, but is mostly over my head so it's hard to give good feedback.  My biggest concern is security right now especially after the recent scare.  New features often bring new security holes, so I'd rather not be in too much of a rush to beat the competition for every little thing.  Nxt already has a strong niche (zero inflation, proof-of-stake) and just needs steady, but not rushed, development to bring in the new features which may or may not be embraced by the market.

Has Dr. Evil been hired to continue to looking for exploits and weaknesses and consult?  I saw a couple posts requesting this, but it should be a priority.  He's proven himself by brute forcing something like 3% of Nxt accounts (including genesis) and discovering an x-spend attack.  If we have community funds available then I think we should try to keep him on board as long as we can.

What part of what I am doing is rushed? I am offering relatively small bounties for relatively small projects that are all doable by people who are not currently working on any mission critical parts of NXT. Also, it is pretty clear that first mover in DAC space will be a very positive thing. At least it is clear to me.

Think of NXT as a large company with 5000 people that work for it. Is it wise for everyone to wait for a few people to finish what they are doing before they even start thinking about what they will do in the future? Especially if what they will do has nothing to do with any of the mission critical areas?

Multitasking by one person is probably not so efficient, but if we have 5000 people in NXT community, then we can have up to 5000 things going on at once before we get hit with that sort of problem. I am able to handle about a dozen projects in my head if I am not doing the coding. This is because I used to manage a couple dozen programmers, but I also had responsibility for over 100 other people. I certainly didnt tell the non-programmers they didnt have to do any work because the programmers were a bit late with their project.

I had thought there was a cry to make sure NXT handles 1000TPS, that we add new tech features, etc. After CfB's set of posts the other day, I have worked very hard to come up with a technical roadmap for after April. If everybody just wants tech dev to stop after April, then I will stop. To get features delivered in June, when do you think we need to start conceptualizing it? When do we start developing it?

James

P.S. Dr Evil said he was only available to consult occasionally. Clearly we would all be better off if he was the one working on NXT as much as I am.

[jl777]

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).

NXTsmtp is just for proof of concept that incorporates something everybody is familiar with. I want to verify the peer verifiability of hardcoded NXTplugin followed by external NXTplugin. I am not worried about NXTsmtp for anything other than proving that NXTplugins work and are peer verified. At first I couldnt understand how on earth a DAC could be implemented. When I started thinking about email plugin, it became not as hard.

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.

The problem is that I see all of the things I am posting about as connected. Like the elephant described by different people. All sounds very different, but it is all the same elephant. If I described the elephant in its entirety, it wouldnt fit in posts. I feel a great sense of urgency due to competitive pressures.

James

P.S. I usually dont post when I am sleeping or flying

James,

First of all thank you for all your great ideas, but ...

My background is IT project manager and I am going crazy by you.

You throw 10 projects on the table but have not one worked out.

exactly. it's like everyday there is something new. zerocoin, then turing complete language, then decentralized cross-chain exchanges, then plugins, then emails ... Why on earth would I want to use Nxt for emails? There are zillions of better email services, and Nxt already has  private messages.

Please try to understand I am using email as a proof of concept for a NXTplugin. I have stated repeatedly that it is not intended for actual usage, but rather to work out the issues of having NXTplugins.

zerocoin project is i progress. So are the other things. First everyone complains there is not enough tech, now the complaint is too much tech

[l8orre]

Do we have a thread for those who deserve Dev Bounties from unclaimed Nxt?  I recommend the following allocation for dev:

l8oore (asset exchange) - 200k

We can add to these amounts in the future for ongoing projects.

I would like to see an asset exchange in action... cause i was going to implement it.
Since it is already done not sure if i will have to do so.

Yes, to be clear, these are for finished product, in the case of QBTC, it's more of a maintenance fee.

Hey that is good news in the Morning!

I will be scrambling to release it with the start of the AE on the mainNet.

The babies name will be nxtFreeRider

Anyone googling for images of freerider will have to know what they'll be using.

Also, it won't compete with the other full feature clients- because it won't be one.

On the other hand, it has the potential to become a reference implentation for the NXT API,
and it can be extended by anybody easily by modifying existing stuff in there.

[2Kool4Skewl]

Updates - 07/02/2014
- Shows multiple balances.
- Shows node status (Green = ON, Blue = OFF)

Now effective balance 136'722.00 NXT!!!

NXTCoin first automated forging platform!
Website: http://www.nxtio.org/

Is that really what we want? Centralization?

+1

I thank the pool operators for trying to provide a service for the community, but I think forging should remain individual.  Granted, Nxt is resistant to up to 90% concentration attacks, but I don't think this is a path we want to follow for multiple reasons.  Sooner or later, someone will open a pool and run off with everyone's Nxt.  I'm not saying the current ops will do this, but it's bound to happen.

You don't get any more using a pool, you just get more consistent payouts.

[jl777]

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".

Maybe proving that reviewed source code was invoked is useless in the case of email. Its advantages are that it is easy to verify, easy to understand what it does. Its purpose is NOT to send emails, but to work out architecture issues for plugins

A txid in the blockchain only means that the plugin code was executed. That is probably not enough, without error handling, etc., but this is first proof of concept version that is meant to be evolved with more and more robust solutions. Of course, we wont use it for actual sending of email

What I am looking for in the blockchain is that code was executed without error. For example, if the code that was executed is code that verified the existence of a transaction in the bitcoin blockchain, this mechanism can be used to step through the cross chain algos.

[CIYAM]

Please try to understand I am using email as a proof of concept for a NXTplugin. I have stated repeatedly that it is not intended for actual usage, but rather to work out the issues of having NXTplugins.

I am not even quite sure what a NXTplugin *is* but if it does has anything to do with the Nxt VM and its "scripts" then an email plugin would only be a "proof of what NOT to do".

[jl777]

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").

Besides, there are many other problems. Most of these emails would end up in spam folders anyway

Sender Policy Framework

http://en.wikipedia.org/wiki/Sender_Policy_Framework

As long as the people testing it can get the emails, it would have served its purpose. The purpose is not to send emails but to verify that a plugin has executed. Think of it as a poor mans SNARK

[ChuckOne]

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).

NXTsmtp is just for proof of concept that incorporates something everybody is familiar with. I want to verify the peer verifiability of hardcoded NXTplugin followed by external NXTplugin. I am not worried about NXTsmtp for anything other than proving that NXTplugins work and are peer verified. At first I couldnt understand how on earth a DAC could be implemented. When I started thinking about email plugin, it became not as hard.

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.

The problem is that I see all of the things I am posting about as connected. Like the elephant described by different people. All sounds very different, but it is all the same elephant. If I described the elephant in its entirety, it wouldnt fit in posts. I feel a great sense of urgency due to competitive pressures.

James

P.S. I usually dont post when I am sleeping or flying

I could think of useful ideas for onchain plugins. But offchain?

It's the same as with other offchain activities like crosschain exchange, fiat exchange. Nxt has no control of process outside of it.

Anyway, what I wanted to add is: we should reserve a branch for each plugin on the blockchain. That is nodes that do not want to contribute to that chain does not need to download the data.

[CIYAM]

What I am looking for in the blockchain is that code was executed without error. For example, if the code that was executed is code that verified the existence of a transaction in the bitcoin blockchain, this mechanism can be used to step through the cross chain algos.

Okay - well in that case why not make your "prototype" plugin check for the existence of a Bitcoin transaction instead (that has at least x confirmations)?

The "script" will have "state" so any "plugin calls" it makes would presumably have some sort of "return value" that could be checked and/or kept in the script's state.

[jl777]

Please try to understand I am using email as a proof of concept for a NXTplugin. I have stated repeatedly that it is not intended for actual usage, but rather to work out the issues of having NXTplugins.

I am not even quite sure what a NXTplugin *is* but if it does has anything to do with the Nxt VM and its "scripts" then an email plugin would only be a "proof of what NOT to do".

I want to find out what changes need to be made to NXT core to support plugins
My constraint is to not utilizing CfB or jean-luc or anybody else on mission critical development

I wanted to think through how to implement DAC in the real world. I have asked for but received ZERO help other than from Alias, so I pushed forward on my own. I am open to suggestions on how to implement DAC's especially under NXT framework. All of this helps with solving the issue of adding zerocoin and other cool features.

What good is NXT VM if all it can do is create an AM for output? The true value add would be for that output to directly do things outside the NXT blockchain.

Please dont get bogged down on the unreliability of email. The important thing is if we can actually verify whether code external to current Java core has actually be executed. If we can do this, then a whole new world opens up

James