NXT :: descendant of Bitcoin - Updated Information

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

[1714241709]

1714241709

[1714241709]

1714241709

[1714241709]

1714241709

[1714241709]

1714241709

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

[jl777]

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

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.

I thought you said NXTplugins wont work because we cant verify that Evil bob didnt make a version that is lying.
Are you saying we can ignore this possibility and NXTplugins will work?

[jl777]

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

What if each plugin had two parts, the action part and verification part.
For example for bitcoin operations, the action would actually issue bitcoind and verification looks at blockchain.info

forging node does the action, all nodes do the verification

[CIYAM]

I thought you said NXTplugins wont work because we cant verify that Evil bob didnt make a version that is lying.
Are you saying we can ignore this possibility and NXTplugins will work?

This is probably because you are too busy "posting" to spend any time "reading" things properly.  

Treat the VM script the same as a normal transaction script - you wouldn't allow an invalid tx and nor would you allow an invalid script result (we are not trying to stop people from "creating invalid tx's or script results" though).

[Eadeqa]

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?

The article you yourself posted says it's not ready for commercial applications:

"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. It has, however, already withstood the first attempts to break it."


BCNext from what I understand isn't even cryptographer. I doubt he would have any clue how to approach this.  

[CIYAM]

What if each plugin had two parts, the action part and verification part.
For example for bitcoin operations, the action would actually issue bitcoind and verification looks at blockchain.info

forging node does the action, all nodes do the verification

You can't do that as explained before - *every node* has to do the action otherwise it might never occur.

If you are going to keep questioning simple logic then I think I'll just take the break that you should and let you talk to yourself for a while.

[jl777]

What if each plugin had two parts, the action part and verification part.
For example for bitcoin operations, the action would actually issue bitcoind and verification looks at blockchain.info

forging node does the action, all nodes do the verification

You can't do that as explained before - *every node* has to do the action otherwise it might never occur.

If you are going to keep questioning simple logic then I think I'll just take the break that you should and let you talk to yourself for a while.

You keep talking about scripts having to run on every node. I am agreeing with that. I am talking about the code that processes the output of the script in a future block. Are we talking about the same thing?

[gimre]

You keep talking about scripts having to run on every node. I am agreeing with that. I am talking about the code that processes the output of the script in a future block. Are we talking about the same thing?

You haven't answered to that:

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?

(or any other plugin)

[CIYAM]

You keep talking about scripts having to run on every node. I am agreeing with that. I am talking about the code that processes the output of the script in a future block. Are we talking about the same thing?

It is the same script or it is another script - so of course it would be treated no differently (nor could it).

There are only "scripts" - don't complicate things unnecessarily by trying to now have "different types of scripts".

If you think you are going to get "better answers" from someone else then by all means ask someone else - but it is starting to come across a bit like a kid asking their mother for something after their father has said no.

[jl777]

You keep talking about scripts having to run on every node. I am agreeing with that. I am talking about the code that processes the output of the script in a future block. Are we talking about the same thing?

You haven't answered to that:

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?

(or any other plugin)

My assumption is that NXT VM script will do process its inputs, do math, etc and then create and could create output data which would be stored in an AM.

Then the forging block would scan the AM and check to see if it is asking to invoke a plugin. If it is the forging block, it would call the action function. If it is not the forging block, then at some future block, it calls the verification function.

Easy to get confused without a concrete example, that is why I selected email just to illustrate data flow.
NXT VM script decides to generate email and encodes it into an output AM
NXT core scans AM validates plugin and:

if forging block actually sends it
then for email we can't verify, but for examples sake, lets just say all nodes can check to see if the email came in, so the verification step would be to checksum the email and compare it to the expected data.

[jl777]

You keep talking about scripts having to run on every node. I am agreeing with that. I am talking about the code that processes the output of the script in a future block. Are we talking about the same thing?

It is the same script or it is another script - so of course it would be treated no differently (nor could it).

There are only "scripts" - don't complicate things unnecessarily by trying to now have "different types of scripts".

But CfB said only simple opcodes in scripts. He rejected SHA256, I doubt he will allow bitcoin ops inside VM!
I didnt complicate this.

[jl777]

You keep talking about scripts having to run on every node. I am agreeing with that. I am talking about the code that processes the output of the script in a future block. Are we talking about the same thing?

It is the same script or it is another script - so of course it would be treated no differently (nor could it).

There are only "scripts" - don't complicate things unnecessarily by trying to now have "different types of scripts".

If you think you are going to get "better answers" from someone else then by all means ask someone else - but it is starting to come across a bit like a kid asking their mother for something after their father has said no.

I apologize for being so slow. I do not want "better answers", I want to figure this out or understand why I am so confused about this.

[CIYAM]

I am just too tired to keep at this - every time I give you an answer to A your reply is:  "but that's not the answer to B".

I suggested you might want to try and slow down a bit but it seems you are either unable or unwilling to do that so I will simply stop replying and go watch some TV instead (btw - I am not angry - but I do need a bit of a break from this topic).

[gimre]

But CfB said only simple opcodes in scripts. He rejected SHA256, I doubt he will allow bitcoin ops inside VM!
I didnt complicate this.

He said he doesn't want it as an *opcode* but it could be added as a system call...
(and there should be system calls, without that VM will be pretty much useless)

My assumption is that NXT VM script will do process its inputs, do math, etc and then create and could create output data which would be stored in an AM

"When you assume you make ASS out of U and ME"

Regarding mail, I think you understand it was dumb example, so give some concrete example.

PS going out for a while

[Passion_ltc]

Introducing tipNXT.com

With tipNXT.com you can tip any Nxt user worldwide!

- It's possible to create a link which will redirect you to a tipping formular.
- You can also click on the button "Quick tip" to open the blank tipping formular.
- On the front page you see the last 15 tips, you can click on the NXT ID's or the amount to get to the Blockchain Explorer.


How is this service funded?

100% through donations towards us. This is implemented in the tipping formular.


Can I trust you?

This is the biggest issue. Of course you can trust me! The domain is registered with my original name. On the contact page you can see a photo of me. I will stay for a long time in the Nxt community. Maybe my other services created a little trust towards me.


Can I send only a tip to another person, or only a tip towards tipNXT.com?

Yes! Just set one slider to zero for this.




I hope that this service will be used often! Thank you very much.

[marcus03]

Introducing tipNXT.com

With tipNXT.com you can tip any Nxt user worldwide!

- It's possible to create a link which will redirect you to a tipping formular.
- You can also click on the button "Quick tip" to open the blank tipping formular.
- On the front page you see the last 15 tips, you can click on the NXT ID's or the amount to get to the Blockchain Explorer.


How is this service funded?

100% through donations towards us. This is implemented in the tipping formular.


Can I trust you?

This is the biggest issue. Of course you can trust me! The domain is registered with my original name. On the contact page you can see a photo of me. I will stay for a long time in the Nxt community. Maybe my other services created a little trust towards me.


Can I send only a tip to another person, or only a tip towards tipNXT.com?

Yes! Just set one slider to zero for this.

I hope that this service will be used often! Thank you very much.

I don't get it. Why would I want to use this, enter my account secret via non-SSL, when I can tip an account with any client?