NXT :: descendant of Bitcoin - Updated Information

[jl777]

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

I don't see how running the "right plugin" is going to help if the plugin deals with any 3rd party software or protocol at all as Evil Bob doesn't need to *change the plugin* he will make his changes to the 3rd party software or intercept and modify the protocol commands.

The problem of using blockchain.info is that it is a website and that opens it up to all the problems of websites being hacked. It seemed a lot more secure to be able to verify that bitcoind running matches the bitcoind source code.

It simply isn't relevant if you are going to have other servers "check the script execution" which you will *have* to do in order for it to be correctly verified (which is why sending an email would be silly).

I am not thinking that there are ANY third party softwares. The NXTplugin needs to incorporate some or all of the third party software into itself. Otherwise there is no way it can be trusted.

The peer servers will verify the output of the plugin. We rely on the source code to know what the plugin did. So all the peers can verify that Evil Bob made no changes to the plugin and the plugin ran and output the result. How can Evil Bob modify the plugin if NXT core is verifying checksum/hash of the executing code in memory? Any changes would change the checksum/hash of the in memory copy of the plugin.

If I am wrong in that, THAT is the feedback I am looking for. How can Evil Bob change the plugin without changing the checksum/hash of the in memory copy that is being called by NXTcore?

The peers dont have to send the email, they just need to verify that the checksum/hash + result/errorcode matches what would have been expected given the input data to the plugin, which is the output data from NXT VM script

James

Edit: Ideally we would have an externally verifiable action, eg. unmodified bitcoind issued command and it is verified on blockchain.info as an example

[1714225824]

1714225824

[1714225824]

1714225824

[1714225824]

1714225824

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

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

https://bitcointalk.org/index.php?topic=364218.msg5007726#msg5007726 has the original post about NXTplugins. Probably lost on this thread.

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.

A node does not have to have any NXTplugins, however if a NXTplugin is not on the servers that are forging most of the time, it could be a long time before it will get called. TF can be used to find the node that will actually call the plugin and so all the other nodes will know when to look for the result and error code.

NXTsmtp is to flesh out the details of the NXTplugin architecture, eg. is it the right way to expand NXT VM power? How to implement it? What sorts of requirements will we need to constrain the actual production NXTplugins, etc.

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

James

[CIYAM]

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 which would really just be like a "version check" - it doesn't help the "script" itself in any way at all).

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

[jl777]

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?

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