Bitcoin Forum
May 23, 2019, 02:32:32 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: « 1 ... 1508 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 ... 2567 »
  Print  
Author Topic: NXT :: descendant of Bitcoin - Updated Information  (Read 2750637 times)
bitcoinpaul
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
February 08, 2014, 09:22:40 AM
 #31141


The problem is that I see all of the things I am posting about as connected. Like the elephant described by different people. All sounds very different, but it is all the same elephant. If I described the elephant in its entirety, it wouldnt fit in posts. I feel a great sense of urgency due to competitive pressures.

Could you say some words about the "same elephant" and give some context within this post please (especially target audience and feature list)?

https://bitcointalk.org/index.php?topic=345619.msg4959522#msg4959522
1558578752
Hero Member
*
Offline Offline

Posts: 1558578752

View Profile Personal Message (Offline)

Ignore
1558578752
Reply with quote  #2

1558578752
Report to moderator
1558578752
Hero Member
*
Offline Offline

Posts: 1558578752

View Profile Personal Message (Offline)

Ignore
1558578752
Reply with quote  #2

1558578752
Report to moderator
PLAY OVER 3000 GAMES
LIGHTNING FAST WITHDRAWALS
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2086
Merit: 1007

Newbie


View Profile
February 08, 2014, 09:23:37 AM
 #31142

For the people with less knowledge: Clarify exactly with more than 3 words what's your definition of "service providers" is.

Off-chain service using Nxt to accept subscription payments.
bitcoinpaul
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
February 08, 2014, 09:26:23 AM
 #31143

James,

First of all thank you for all your great ideas, but ...

My background is IT project manager and I am going crazy by you.

You throw 10 projects on the table but have not one worked out.

Please for starters pick on project, work it out from start to finish, than pick another.

As of now your way of working getting us nowhere.

You are ddossing us.


I'm no IT project manager but right now, brainstorming some ideas and projects could actually be quite healthy. The problem is maybe that notevery idea (and the interaction/interference) gets discusses here. We have no overview right now of projects, ideas, developments, developers right now.

I had thought there was a cry to make sure NXT handles 1000TPS, that we add new tech features, etc. After CfB's set of posts the other day, I have worked very hard to come up with a technical roadmap for after April. If

Did I miss your roadmap?
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1089


View Profile WWW
February 08, 2014, 09:26:39 AM
 #31144


Here is my idea for avoiding blockchain bloat while doing 1000TPS. I am surprised nobody mentioned this, so it is either because it is a really bad idea for some reason, or too obvious nobody bothered??

From my understanding, it will be possible to have regular snapshots of the entire state of the NXT blockchain so that you wont need to parse all the blocks from genesis.

Secondly, very little of this "entire state of NXT" data has a life beyond 1440 blocks.

So, my proposal is to generate a daily snapshot, peer reviewed by nodes, checksummed, fingerprinted, signatured, whatever we need to make sure it is a valid unmolested snapshot. We actually dont even need these snapshots, but while we are doing this, might as well avoid having to download the entire blockchain. Bandwidth savings alone makes it worthwhile.

OK, so one way or another, let us assume the node is current. Now the problem is keeping up with 1000TPS (lets make the overall network adaptive so we can handle bursts of 1000TPS, sustained 250 TPS) and that requires bandwidth, though with binary data, 250 TPS should be around what 100TPS will be now. So 100kbps would be enough to handle bursts of 1000TPS and sustained 250TPS

But where does all that data go?

Actually, I say just throw it away! Why can't we use a FIFO that stores the most recent 1441 blocks for all the blockchains (when we go parallel). Since we synced the the full blockchain with the last days checkpoint, then as long as we are properly updating the "entire state of NXT network" at any given block, we are able to forge a valid block.

Unless I totally missed some reason why we need to locally store more than the last 1441 blocks, this should work. We can then specify that any NXT VM (Turing scripts) will need to be designed to use only data from prior 1440 blocks. This I do not see as a big limitation as if it is really important the client issuing script can just get data it needs and put it into AM. So, the NXTcore would need to implement the FIFO, preferably based on a web.xml parameter. That would allow people who run NXT VM generating clients to have access to exactly the window of time they need.

I hope this puts useful forging back on the table for raspis. 100kbps to fully support 1000TPS (peak output) NXT network

James

I think, snapshots were mentioned or spoken about a couple of times.
Yes, snapshots were, but not using a blockchain FIFO (other than xyzz's post that was ignored). That is what allows the raspi to keep up. Even without snapshots, a raspi would be able to keep up, as long as it ever could catch up. That is why I combined it with snapshots to make sure all raspis could catch up to the current block.

Using snapshots alone would require much more frequent snapshots to be made and created all sorts of issues with delays, etc. If the blockchain FIFO is implemented, we can get by with weekly snapshots. This is because the blockchain is not stored locally other than the most recent day.

Also, we dont need parallel blockchains because of HDD usage if we had blockchain FIFO. There could be other reasons like partitioning workload, etc., but it is a quick way to get to 1000TPS and beyond without any software magic.

I saw the post about this, but nobody else seemed to recognize the significance. I just felt that it solved the 1000TPS on raspis issue and so wanted feedback on it to make sure it would work. It just seems so simple an idea, I wonder why it wasnt already done

James

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, 09:31:32 AM
 #31145

I didnt think there was a chance to find bitcoind in Java form that jean-luc would consider adding to NXT core.

Why would you need/want that rather than just doing RPC commands to a "real bitcoind"?

It is MUCH simpler to solve the issues with a hardcoded NXTplugin since we dont have to deal with Evil Bob changing the executable. Not having to worry about Evil Bob seemed prudent for the first attempt at adding parsing of AM data to see what plugins to call, etc.

You are *always* going to have Evil Bob using the "wrong plugin" and *you will not be able to tell* especially if your plugin has no way to be verified (which was the point about an SMTP plugin).

If we cant solve the issue with simple hardcoded plugin, no chance for complex external plugin. That is why I chose email as the proof of concept.

Exactly my concern - a plugin that issues a "bitcoind" RPC command (hell - why not just use "blockchain.info" for that matter) is at least *verifiable* in that given x servers running the "supposedly same" plugin you would get the exact same result from all of them (if they are able to give a result at all that is).

If you want a "dead simple" plugin then how about one that just does this:

return "hello";

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

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.

I couldn't justify paying a bounty for a program that returned "hello"

We need more people familiar with the NXT core. I wanted simple enough project that had some utility that would get people to see how easy it is to add functionality to NXT

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, 09:33:13 AM
 #31146

James,

First of all thank you for all your great ideas, but ...

My background is IT project manager and I am going crazy by you.

You throw 10 projects on the table but have not one worked out.

Please for starters pick on project, work it out from start to finish, than pick another.

As of now your way of working getting us nowhere.

You are ddossing us.


I'm no IT project manager but right now, brainstorming some ideas and projects could actually be quite healthy. The problem is maybe that notevery idea (and the interaction/interference) gets discusses here. We have no overview right now of projects, ideas, developments, developers right now.

I had thought there was a cry to make sure NXT handles 1000TPS, that we add new tech features, etc. After CfB's set of posts the other day, I have worked very hard to come up with a technical roadmap for after April. If

Did I miss your roadmap?
NXTcash
NXTlayers
NXTplugins
cross chain
automated DAC gateway
probably more, getting tired I think it is already tomorrow

James

Edit: Where else are dev ideas being actively discussed. Only very small activity on nxtcrypto.

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, 09:37:53 AM
Last edit: February 08, 2014, 10:00:40 AM by CIYAM Open
 #31147

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.

Of course using "blockchain.info" would be a hack but it isn't that 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).

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

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
fmiboy
Full Member
***
Offline Offline

Activity: 189
Merit: 100


View Profile
February 08, 2014, 09:40:24 AM
Last edit: February 08, 2014, 09:51:47 AM by fmiboy
 #31148

I am a bit concerned that there has been very little feedback on my recent proposals, blockchain FIFO and NXT plugin architecture.

I've been reading your posts with interest and trying to digest them.  Much of it sounds good, but is mostly over my head so it's hard to give good feedback.  My biggest concern is security right now especially after the recent scare.  New features often bring new security holes, so I'd rather not be in too much of a rush to beat the competition for every little thing.  Nxt already has a strong niche (zero inflation, proof-of-stake) and just needs steady, but not rushed, development to bring in the new features which may or may not be embraced by the market.

Has Dr. Evil been hired to continue to looking for exploits and weaknesses and consult?  I saw a couple posts requesting this, but it should be a priority.  He's proven himself by brute forcing something like 3% of Nxt accounts (including genesis) and discovering an x-spend attack.  If we have community funds available then I think we should try to keep him on board as long as we can.

+1
edit: new features often bring security holes, but this brainstorming is just project ideas, doesn't mean all will be implemented, but it will be discussed and possibly will be considered.
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1089


View Profile WWW
February 08, 2014, 09:44:33 AM
 #31149

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

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, 09:47:43 AM
 #31150

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

Activity: 1176
Merit: 1089


View Profile WWW
February 08, 2014, 09:55:28 AM
 #31151

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

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:04:46 AM
 #31152

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!

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:14:46 AM
 #31153

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?

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:22:10 AM
 #31154

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.

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:26:39 AM
 #31155

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.

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

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1003


Ian Knowles - CIYAM Lead Developer


View Profile WWW
February 08, 2014, 10:28:22 AM
 #31156

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?

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, 10:31:55 AM
 #31157


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.  

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

Activity: 1176
Merit: 1089


View Profile WWW
February 08, 2014, 10:33:16 AM
 #31158


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

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:35:26 AM
 #31159


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

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:37:03 AM
 #31160

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.

Pages: « 1 ... 1508 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 ... 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!