Bitcoin Forum
June 17, 2019, 08:01:20 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 ... 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 [1559] 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 ... 2567 »
  Print  
Author Topic: NXT :: descendant of Bitcoin - Updated Information  (Read 2752710 times)
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1089


View Profile WWW
February 08, 2014, 10:38:03 AM
 #31161

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?


http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
1560758480
Hero Member
*
Offline Offline

Posts: 1560758480

View Profile Personal Message (Offline)

Ignore
1560758480
Reply with quote  #2

1560758480
Report to moderator
1560758480
Hero Member
*
Offline Offline

Posts: 1560758480

View Profile Personal Message (Offline)

Ignore
1560758480
Reply with quote  #2

1560758480
Report to moderator
1560758480
Hero Member
*
Offline Offline

Posts: 1560758480

View Profile Personal Message (Offline)

Ignore
1560758480
Reply with quote  #2

1560758480
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1560758480
Hero Member
*
Offline Offline

Posts: 1560758480

View Profile Personal Message (Offline)

Ignore
1560758480
Reply with quote  #2

1560758480
Report to moderator
1560758480
Hero Member
*
Offline Offline

Posts: 1560758480

View Profile Personal Message (Offline)

Ignore
1560758480
Reply with quote  #2

1560758480
Report to moderator
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1089


View Profile WWW
February 08, 2014, 10:39:13 AM
 #31162

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

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
gimre
Legendary
*
Offline Offline

Activity: 857
Merit: 1000



View Profile WWW
February 08, 2014, 10:40:13 AM
 #31163

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
Legendary
*
Offline Offline

Activity: 1890
Merit: 1003


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 08, 2014, 10:41:46 AM
 #31164

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.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1089


View Profile WWW
February 08, 2014, 10:42:37 AM
 #31165

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

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
gimre
Legendary
*
Offline Offline

Activity: 857
Merit: 1000



View Profile WWW
February 08, 2014, 10:43:03 AM
 #31166

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
Newbie
*
Offline Offline

Activity: 14
Merit: 0


View Profile
February 08, 2014, 10:43:55 AM
 #31167

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
Legendary
*
Offline Offline

Activity: 1890
Merit: 1003


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 08, 2014, 10:44:09 AM
 #31168

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:

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1089


View Profile WWW
February 08, 2014, 10:48:34 AM
 #31169

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.

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1089


View Profile WWW
February 08, 2014, 10:50:32 AM
 #31170

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:

Quote
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

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
gimre
Legendary
*
Offline Offline

Activity: 857
Merit: 1000



View Profile WWW
February 08, 2014, 10:53:39 AM
 #31171

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
Legendary
*
Offline Offline

Activity: 1176
Merit: 1089


View Profile WWW
February 08, 2014, 10:55:43 AM
 #31172

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?

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1003


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 08, 2014, 10:56:16 AM
 #31173

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

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1089


View Profile WWW
February 08, 2014, 10:58:07 AM
 #31174

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?

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1089


View Profile WWW
February 08, 2014, 11:00:51 AM
 #31175

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

Quote
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

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1003


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 08, 2014, 11:01:35 AM
 #31176

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

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
Eadeqa
Hero Member
*****
Offline Offline

Activity: 644
Merit: 500


View Profile
February 08, 2014, 11:02:52 AM
 #31177

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.  

NXT-GZYP-FMRT-FQ9K-3YQGS
https://nxtforum.org
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1003


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 08, 2014, 11:03:17 AM
 #31178

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.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1089


View Profile WWW
February 08, 2014, 11:05:46 AM
 #31179

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?

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
gimre
Legendary
*
Offline Offline

Activity: 857
Merit: 1000



View Profile WWW
February 08, 2014, 11:07:39 AM
 #31180

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)

Pages: « 1 ... 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 [1559] 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 ... 2567 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!