NXT :: descendant of Bitcoin - Updated Information

[jl777]

Understand that any "step in the script" to "verify a plugin" can *simply be ignored* by Evil Bob's script processor!

It is the NXT core that would be verifying the plugin. Not sure if that makes any difference. Evil Bob's script processor has to generate the same output or it will get ignored by peers since the AM data from the script is wrong if changed.

[CIYAM]

I know it is not perfect, that is why I am asking for feedback to make it right. I think it is at least closer and things like http://www.wired.com/wiredscience/2014/02/cryptography-breakthrough/ give me hope that a solution is possible.

Am pretty sure that the kind of complexity required for that kind of approach would make the whole VM thing far too expensive to consider running for probably many, many years (so "stop right there" unless you are planning years in advance now).

...then why cant all the peers conclude properly that the correct plugin was indeed run on the correct input data (which is the output of NXT VM script)?

What a peer would do is have to run the script itself (get used to the fact that the script will need to run on *every* peer except perhaps for some lightweight ones) and compare its result to that being suggested by another peer.

This is why the script's state must be "deterministic" if a peer tells you that the answer to running script A with state X results in state Y but you think it results in state Z then you ignore that block as being invalid and block the peer.

[CIYAM]

It is the NXT core that would be verifying the plugin. Not sure if that makes any difference. Evil Bob's script processor has to generate the same output or it will get ignored by peers since the AM data from the script is wrong if changed.

The Nxt core can be modified James - wake up (or perhaps instead "take a nap")!

You do realise that some nodes are running different versions of the NRS right now don't you?

And you do also realise that any reporting their version as x.x.x could simply be lying don't you?

[Eadeqa]

Also, I must be too tired to understand why if the forging node can verify they are running the correct plugin and it puts the result of running the plugin into the forged block and the forged block is verified cryptographically by the peers, then why cant all the peers conclude properly that the correct plugin was indeed run on the correct input data (which is the output of NXT VM script)?

Sounds totally voodoo nonsense.  There is no reason believe this is secure.  

[jl777]

What a peer would do is have to run the script itself (get used to the fact that the script will need to run on *every* peer except perhaps for some lightweight ones) and compare it's result to that being suggested by another peer.

This is why the script's state must be "deterministic" if a peer tells you that the answer to running script A with state X results in state Y but you think it results in state Z then you ignore that block as being invalid and block the peer.

I am agreeing with you here. The script is run on all non lightweight peers, output AM needs to be deterministic and the same across the entire network. that is the assumption I am working with.

Encoded in the output AM is the trigger to call a specific plugin with specific data, identical for all nodes.

So far I think we are on same page. Where is the flaw in my logic? Do we need super fancy zeroknowledge stuff or even more complicated obsfucation algos to make sure that the NXT core validated the plugin before it was called?

I think that is  the weakness you are pointing out. How to verify that plugin verification was run by forging node. I dont think all nodes need to be verified with proper plugin because only the forging node is responsible for "side effects" from NXT VM scripts. I am pretty sure we cant have more than one node doing side effects, especially if it involves transactions

[jl777]

Also, I must be too tired to understand why if the forging node can verify they are running the correct plugin and it puts the result of running the plugin into the forged block and the forged block is verified cryptographically by the peers, then why cant all the peers conclude properly that the correct plugin was indeed run on the correct input data (which is the output of NXT VM script)?

Sounds totally voodoo nonsense.  There is no reason believe this is secure.  

That is why I am discussing it. It clearly has holes now and we might need a indistinguishability obfuscator

[gimre]

I think we can verify the checksum of the running code for plugin matches the source code. Similar to signing of .jar files

Can you describe with details few things:

• what the plugins could do and why they should be used
• HOW they should be made? (that is should they operate on API or they should be REAL plugins)
• what about people who don't want plugins? how limiting it (lack of plugins) will be?
• How do you actually imagine this smtp plugin would work like (I'd like really detailed description along with use case description https://en.wikipedia.org/wiki/Use_case)
• How do you imagine TRUSTing the plugins?

To be clear, I'm asking those questions, as most likely I will criticize the idea, once you answer to those questions.

I use the term plugin just as a placeholder, I am beginning to think it means different specific things to different people and is not the best term. When I say NXTplugin, I mean the code that is invoked when the forging node scans the AM data and finds that it is input meant for a specific plugin.

I have a bounty out on how to make plugins, it depends on what is needed to be able to do realtime checksum/hash of its code space in memory.

So you want plugins to be written in NXT VM? Have you seen specs that CfB posted. ATM it seems VM will only be able to do math (and from what I understood VM was supposed to be used for contracts only).

Something like NXTsmtp done in such VM is just "no no".

Regarding securify, I agree with what CIYAM said, there's no way you could trust plugins.

[jl777]

It is the NXT core that would be verifying the plugin. Not sure if that makes any difference. Evil Bob's script processor has to generate the same output or it will get ignored by peers since the AM data from the script is wrong if changed.

The Nxt core can be modified James - wake up (or perhaps instead "take a nap")!

You do realise that some nodes are running different versions of the NRS right now don't you?

And you do also realise that any reporting their version as x.x.x could simply be lying don't you?

I agree about sleep.

I understand Evil bob could be everywhere.

Here is a hypthetical. Lets say there was a library that implemented indistinguishability obfuscator in a fast enough and compact enough way. With that as a given, would it be possible to verify the correct version is running?

[jl777]

I think we can verify the checksum of the running code for plugin matches the source code. Similar to signing of .jar files

Can you describe with details few things:

• what the plugins could do and why they should be used
• HOW they should be made? (that is should they operate on API or they should be REAL plugins)
• what about people who don't want plugins? how limiting it (lack of plugins) will be?
• How do you actually imagine this smtp plugin would work like (I'd like really detailed description along with use case description https://en.wikipedia.org/wiki/Use_case)
• How do you imagine TRUSTing the plugins?

To be clear, I'm asking those questions, as most likely I will criticize the idea, once you answer to those questions.

I use the term plugin just as a placeholder, I am beginning to think it means different specific things to different people and is not the best term. When I say NXTplugin, I mean the code that is invoked when the forging node scans the AM data and finds that it is input meant for a specific plugin.

I have a bounty out on how to make plugins, it depends on what is needed to be able to do realtime checksum/hash of its code space in memory.

So you want plugins to be written in NXT VM? Have you seen specs that CfB posted. ATM it seems VM will only be able to do math (and from what I understood VM was supposed to be used for contracts only).

Something like NXTsmtp done in such VM is just "no no".

Regarding securify, I agree with what CIYAM said, there's no way you could trust plugins.

VM's output -> AM
That AM -> plugin
verification via indistinguishability obfuscator or simpler method if we can find one

Edit: NXTsmtp is ONLY a PROOF OF CONCEPT, not for actually sending emails outside of test cycle

[gimre]

I know it is not perfect, that is why I am asking for feedback to make it right. I think it is at least closer and things like http://www.wired.com/wiredscience/2014/02/cryptography-breakthrough/ give me hope that a solution is possible.

I remember reading original paper some time ago, and it's seems it's way too computationally expensive to include it on the chain...

What am I missing? I am thinking that all script owners will be assured that the output of their script will be processed only by a validated NXTplugin.

what does validated mean? how the output can be verified without running the "code" again?

[CIYAM]

I think that is  the weakness you are pointing out. How to verify that plugin verification was run by forging node. I dont think all nodes need to be verified with proper plugin because only the forging node is responsible for "side effects" from NXT VM scripts. I am pretty sure we cant have more than one node doing side effects, especially if it involves transactions

Now we are perhaps getting to the core problem - basically you need to have operations that don't have harmful side effects (so sending emails or the like is a very bad idea).

So consider "sending a BTC transaction" (not that this is perhaps the best idea but at least it is fine to repeat) - one can send it without harm even if it has already been sent (in fact if you were using bitcoind then your own instance wouldn't even try sending it again if it has already seen it). These are really the only kind of operations you want to be performing.

[jl777]

I know it is not perfect, that is why I am asking for feedback to make it right. I think it is at least closer and things like http://www.wired.com/wiredscience/2014/02/cryptography-breakthrough/ give me hope that a solution is possible.

I remember reading original paper some time ago, and it's seems it's way too computationally expensive to include it on the chain...

What am I missing? I am thinking that all script owners will be assured that the output of their script will be processed only by a validated NXTplugin.

what does validated mean? how the output can be verified without running the "code" again?

the scripts are run on all nodes, so the output AM can be universally validated

Well, if the problem has now gone from "impossible" to "really really difficult", then I call that progress

[gimre]

So you want plugins to be written in NXT VM? Have you seen specs that CfB posted. ATM it seems VM will only be able to do math (and from what I understood VM was supposed to be used for contracts only).

Something like NXTsmtp done in such VM is just "no no".

VM's output -> AM
That AM -> plugin
verification via indistinguishability obfuscator or simpler method if we can find one

Edit: NXTsmtp is ONLY a PROOF OF CONCEPT, not for actually sending emails outside of test cycle

Now you got me lost, WHY do you think VM output will result in AM? Assuming that would be the case:
WHAT would that NXTsmtp plugin DO with that AM?

[greenbeans]

make room for noble coin  in the top 10, dont take my word for it, read noble coin thread and you will be convinced,

https://bitcointalk.org/index.php?topic=402667.0

[CIYAM]

VM's output -> AM
That AM -> plugin
verification via indistinguishability obfuscator or simpler method if we can find one

I don't think you read all of that article James:

However, the new obfuscation scheme is far from ready for commercial applications. The technique turns short, simple programs into giant, unwieldy albatrosses. And the scheme’s security rests on a new mathematical approach that has not yet been thoroughly vetted by the cryptography community.

As I said before *unless you are designing something for years down the track* then please forget about that - it is not practical nor is it even vetted.

[jl777]

I think that is  the weakness you are pointing out. How to verify that plugin verification was run by forging node. I dont think all nodes need to be verified with proper plugin because only the forging node is responsible for "side effects" from NXT VM scripts. I am pretty sure we cant have more than one node doing side effects, especially if it involves transactions

Now we are perhaps getting to the core problem - basically you need to have operations that don't have harmful side effects (so sending emails or the like is a very bad idea).

So consider "sending a BTC transaction" (not that this is perhaps the best idea) - one can send it without harm even if it has already been sent (in fact if you were using bitcoind then your own instance wouldn't even try sending it again if it has already seen it). These are really the only kind of operations you want to be performing.

Yes, I do not imagine we want to allow plugins to be able to do everything. We need to have constraints on what the plugins are allowed to do and source review will need to be the basis for trusting that the constraints are followed.

maybe just stipulating that the plugin works on a best efforts basis and there always needs to be an independent method for verification (presumably with automated retry and other error handling)

If we constrain the set of actions to an allowable set of things to do, that eliminates a large set of issues

for instance, we can have a plugin that queries a website and puts the JSON data into an AM, maybe it gets good data, maybe server error, but if we can be assured that it actually made the query then we can trust the data in the AM.

It seems we again come to needed zeroknowledge proof that code was executed. All of the cool features seem to revolve around this same zeroknowlege proofs.

[jl777]

VM's output -> AM
That AM -> plugin
verification via indistinguishability obfuscator or simpler method if we can find one

I don't think you read all of that article James:

However, the new obfuscation scheme is far from ready for commercial applications. The technique turns short, simple programs into giant, unwieldy albatrosses. And the scheme’s security rests on a new mathematical approach that has not yet been thoroughly vetted by the cryptography community.

As I said before *unless you are designing something for years down the track* then please forget about that - it is not practical nor is it even vetted.

I read it. IF we magically had that module, will NXTplugin architecture work?

James

P.S. My hope is that BCNext will take an interest and simply write an indistinguishability obfuscator

[gimre]

P.S. My hope is that BCNext will take an interest and simply write an indistinguishability obfuscator

I doubt that, and this is reason why:

I remember reading original paper some time ago, and it's seems it's way too computationally expensive to include it on the chain...

Think of slowing down the network from X TPS to something like X/20 TPS.

[jl777]

P.S. My hope is that BCNext will take an interest and simply write an indistinguishability obfuscator

I doubt that, and this is reason why:

I remember reading original paper some time ago, and it's seems it's way too computationally expensive to include it on the chain...

Think of slowing down the network from X TPS to something like X/20 TPS.

Well BCNext is far smarter than me, unless he says that he cant implement a practical indistinguishability obfuscator, who am I to say that he cant?

[CIYAM]

for instance, we can have a plugin that queries a website and puts the JSON data into an AM, maybe it gets good data, maybe server error, but if we can be assured that it actually made the query then we can trust the data in the AM.

Again *we can't know it made the query* all we can do is have peers check the results - but I don't see why we really care if one peer did or didn't honestly do what it was asked.

Basically it is the same problem that happens when peers decide to say accept a transaction that lets an account have a negative balance - the result is you'll end up with a "fork".

Well BCNext is far smarter than me, unless he says that he cant implement a practical indistinguishability obfuscator, who am I to say that he cant?

If you just treat the scripts the same as normal transactions in this way you'll see that there simply is no need to try and do "magical things" to verify them.

To make it even clearer: we don't need that (so no need to waste BCNext's or your own time on even thinking about it).