Quote from: CIYAM Open on February 08, 2014, 10:04:46 AM

Quote from: jl777 on February 08, 2014, 09:55:28 AM

I imagine trusting the plugins because they will be tested and source reviewed and realtime checksummed against tampering and peers will be able to validate that it actually ran and for mission critical plugins, we probably need an external verification, eg. blockchain.info for bitcoind operations

This is just wrong - it's like your trusting that other peers are running the correct NRS - of course they may not be and you have no way to know. The only thing you can do is verify results and compare them to what you know (and blacklist peers that disagree with you).

So your verification idea here is "ass about" (it would only be useful for a server to use to check that they are running the correct plugin themselves - it doesn't help the "script" owner in any way at all).

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.

So you are saying that Evil Bob will spoof that he is running the correct everything. I think the referenced article says that it is possible to do what I want, even though it is supposed to be impossible, even for Evil Bob

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

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.

James

Edit: ah, so we need to make sure that the forging node did the validation of the plugin. Couldnt we use zeroknowledge proof for that?