Bitcoin Forum

Videos
Short introductory video (https://www.youtube.com/watch?v=_6ugwS6_DDU), and another one (https://www.youtube.com/watch?v=fC9qVrlKXRs)
10 Minutes Presentation from InsideBTC conference (http://youtu.be/MTARBWPRmxk?list=PLiOFfTVghPYjKbkjeYo2LOYEgUgNbIh9t)
Detailed introduction to Zennet (https://www.youtube.com/watch?v=6G8mTCtv8d8)
Presentation Video on Crowd Computing conference at Almere (http://vimeo.com/111871002)

Papers
About Zennet article (newer) (http://zennet.sc/about)
RFC (old) (https://github.com/Xennet/xennetdocs)
Software Detailed Design (https://docs.google.com/document/d/1Y-JKJtJrnGpEISgpEpGKqwmW-atg0_Uk2rJAH5YpaLc/edit#heading=h.8llwmxkra3of)
Pricing algo (http://zennet.sc/zennetpricing.pdf)
Auctions draft (http://zennet.sc/vickery_draft.pdf)
Tau-Chain Paper (http://tauchain.org/tauchain0.2.pdf)

Presentations
Almere Conference (http://crowdcomputing.eu/documents/10508/844563/Asor.pdf/4dfc70a0-2427-4377-9734-f8bed2ebb5fb)
Inside Bitcoin Conference (https://docs.google.com/presentation/d/1ap_lbkomeTGGCBz7HANofVhl6osqhepnWYOUPNAQgy4/edit#slide=id.p)

UI Mockup can be found at http://www.zennet.sc/xennet-ui/#/

Updates and important information posted here
Economical Aspects (https://bitcointalk.org/index.php?topic=736447.msg9424435#msg9424435)
Number of coins (https://bitcointalk.org/index.php?topic=736447.msg10119561#msg10119561)
Main design assumption and generation of coins (https://bitcointalk.org/index.php?topic=736447.msg9430958#msg9430958)
Draft of pre-sale terms (https://bitcointalk.org/index.php?topic=736447.msg9382952#msg9382952)
First pre-sale terms (https://bitcointalk.org/index.php?topic=736447.msg10403838#msg10403838)
Moving to a generalized Blockchain (https://bitcointalk.org/index.php?topic=736447.msg10317240#msg10317240)

Join our IRC channel #zennet @freenode (http://webchat.freenode.net/?channels=%23zennet&uio=d4)

Pre-buying coins (currently only privately) by emailing Ohad at ohadasor@gmail.com




Zennet initiative is a public, distributed, and decentralized Supercomputer. It lives in the world of distributed and decentralized Blockchain applications, and in the huge field of Big Data and High Performance Computing. The latter has captured the most attention and investments in the software market over the last few years, experiencing huge growth. HPC and Big Data are used in countless industries, including medicine, government, and marketing. Big Data alone is at least a $30 billion industry this year.

http://zennet.sc/images/infogr/p1.PNG (http://zennet.sc/about/index.html)http://zennet.sc/images/infogr/p2.jpg (http://zennet.sc/about/index.html)


Zennet is here to power this expansion with everyone's computational resources around the globe. Its most significant impacts on this market are drastically reducing costs and bringing new magnitudes of speed to HPC consumers.

http://zennet.sc/images/infogr/p3.PNG (http://zennet.sc/about/index.html)http://zennet.sc/images/infogr/p4.PNG (http://zennet.sc/about/index.html)

Computation power is traded on Zennet's open market platform. Anyone can rent computation power and use it to run arbitrary tasks. Anyone can monetize their hardware by offering unused computation power for sale.    
Zennet allows Publishers who need computation power to run arbitrary computational tasks. Computation power is supplied by Providers for a negotiated fee. A free-market infrastructure brings Publishers and Providers together. Publishers can hire many computers and run whatever they want on them safely, thanks to cutting-edge virtualization technology. Payment is continuous and frictionless, thanks to Blockchain technology, among other technologies that shall be discussed later on.    

http://zennet.sc/images/infogr/p5.jpg (http://zennet.sc/about/index.html)http://zennet.sc/images/infogr/p6.jpg (http://zennet.sc/about/index.html)

The network is 100% distributed and decentralized: there is no central entity of any kind, just like Bitcoin. All software will be open source. Publishers pay Providers directly, there is no middleman. Accordingly, there are no payable commissions, except for regular transaction fees which are paid to ZenCoin miners.       
It is a totally free market: all participants are free to pay or charge any rate they want. There are no restrictions. Hence, we put additional focus on customizability. We allow advanced participants to control all parameters and conditions of their nodes in a versatile way. On the other hand, simplicity and automation are made possible by making the client software implement automatic risk-reward considerations by default. In addition, we present a novel pricing model.       
Following is a sketch summarizing the general idea of the communication protocol between publisher A and provider B:        

Zennet presents new economic aspects, both to the traditional economy and to the world of cryptocurrencies. ZenCoin has a real intrinsic value, as it is fully backed by the right to use a certain amount of computation power. Most of the power-calculating resources are in the hands of the common people, and most of the time they are free.

Many questions may naturally arise. The above description is extremely summarized. Please take some time to read the About Xennet article at http://zennet.sc/ (http://zennet.sc/) It contains an interesting table presenting Xennet's benefits over Amazon Web Services, the largest computational resources rental firm.

Please stay tuned, share your thoughts and check Xennet Bug Bounty Announcement (https://bitcointalk.org/index.php?topic=736447.msg8597527#msg8597527).

In the press (note that we renamed from Xennet due to this (https://www.dropbox.com/s/am2g3jk5jo60itz/XENNET%20Ltr.pdf?dl=0)):

https://i.imgur.com/0UmDvzL.png (http://insidehpc.com/2014/08/new-xennet-hpc-cloud-free-market-alternative-aws/) https://i.imgur.com/rvpfJoR.png (http://www.theregister.co.uk/2014/08/20/xennet_wants_your_machines_for_tradable_supercomputer_cloud/) https://i.imgur.com/sgCNbS1.png (http://www.hpcwire.com/2014/08/18/free-market-hpc-cloud-development/) https://i.imgur.com/QdPKPRS.png (http://insidehpc.com/2014/08/radio-free-hpc-looks-xennet-initiative/) https://i.imgur.com/a6WgrFR.png (http://thecoinfront.com/the-worlds-largest-decentralized-supercomputer-is-coming-soon/)

https://i.imgur.com/1GqZqPc.png (http://cryptobizmagazine.com/zennet-decentralized-cloud-network-releases-details-of-zencoin-presale/) https://i.imgur.com/Pzerf7s.png (http://www.cryptoarticles.com/press-releases/zennet-decentralized-cloud-network-releases-details-of-zencoin-presale) https://i.imgur.com/qMVLT0F.png (http://anarchistreport.com/zennet-decentralized-cloud-network-releases-details-of-zencoin-presale/) https://i.imgur.com/wmPwMda.png (http://bitcoinmagazine.com/18262/zennet-decentralized-cloud-network-releases-details-of-zencoin-presale/) https://i.imgur.com/3SyUdP2.png (http://www.altcointoday.com/zennet-decentralized-cloud-network-releases-details-of-zencoin-presale-3/)

https://i.imgur.com/tfTkELZ.png (http://hpctechasia.com/crowd-sourced-supercomputing-next-frontier/) https://i.imgur.com/xpck9B2.png (http://www.de-centralize.com/decentralize-media-story-40251) https://i.imgur.com/Z6Gstx7.png (http://btcnews.jp/bitcoin-decentralized-supercomputer-zennet/) https://i.imgur.com/X1nIg3R.png (http://coin-network.com/zennet-the-new-decentralized-supercomputer-using-zencoin/)

Please note that above releases were organic, and did not co-ordinate with us, hence contain some inaccuracies. This thread clarifies most of them.

Partial list of team's LinkedIn profiles (in lexicographic order):
Ohad Asor (CEO/CTO) (http://www.linkedin.com/in/ohadasor)
 Gil Bahr (Creative) (http://www.linkedin.com/profile/view?id=7095477)
Gil Erlich (R&D) (https://www.linkedin.com/pub/gil-erlich/5/b41/7b6)
Ariel Formanovski (R&D) (https://www.linkedin.com/pub/ariel-f/31/a73/730)
Ravit Halmut (R&D) (https://www.linkedin.com/in/ravithalmut)
Assaf Kerstin (CFO) (https://www.linkedin.com/pub/assaf-kerstin/11/99a/7a7)
Alon Muroch (R&D) (https://www.linkedin.com/pub/alon-muroch/48/983/91)
Lukáš Nový (R&D) (https://www.linkedin.com/in/lukasnovy)
Daniel Peled (Legal) (https://www.linkedin.com/pub/daniel-peled/21/833/734)
Yonatan Omer (R&D) (https://www.linkedin.com/pub/yonatan-omer/45/548/725)
Felicity Perry (Marketing) (https://www.linkedin.com/in/felicityperry)
Ofer Rotem (Capital) (https://www.linkedin.com/in/oferrotem)

Special credit to HunterMinerCrafter for advising widely to the project and for showing us new paths toward verifiable computing. His contribution is very appreciated.

Sincerely,
The Zennet Team.

Had a quick read.... Interested, let's take on the big boys in their own back yard!

Interesting ideas  :)

I really like this idea

dude awesome

will check this later. :)

looks great

Maybe another thousands of btc presale??

Sounds good

keep watching

Looks good,
Decentralized Supercomputer OMG :o

What's the difference between Amazon EC2 Clouding service?

Great question. Please see the detailed table at http://xennet.io which compares Xennet to AWS.

Guessing Windows Server OS won't able to work in this right but maybe in a few years when computers are much more powerful?

It will work on Windows and even on mobiles!
Docker will be executed inside a virtual machine (Virtualbox, QEMU etc.).
The VM will run Xennet-OS that will split containers to each publisher.
Therefore, cross-platform.

Note that since QEMU is a fully user-space hypervisor, it is compatible with any os and architecture able to compile C.

This is by far one of the most interesting projects i saw lately and i will keep my eye out for this one for sure!

I do have a question: What determines the precedence order when several equal entities wish to hire computational resources at the same instance?
If 2 different people for example both offer to pay the exact same price for the exact same resources, put their offer at the exact same time in the system, which one gets the computational power first? (assuming there is a limitation in the available computational power in total and its not enough for both tasks at the same time). How is it decided in a case of a complete tie in demands?
Hope my question makes sense... :)

Very good question!

The ultimate theoretical answer is that it's up to the providers and publishers choice. But of course Xennet will be predefined with settings so non-technical users will still be able to rent their computers and get paid, in (probably almost) one click. Yet, the client will be highly customizable. My current plan is to let a JS scripting ability on the client for inputting complex user-defined filters and preferences.

The practical answer for when users do not handle this situation manually and relies on the client's defaults, requires me to highlight several points:

1. As you stated correctly, publishers publish (over the blockchain) a request for providers to connect, including their IP address, and providers connect to them.

2. Some not-very-necessary-for-this-answer background: The publisher do not state a price for a unit of CPU/RAM/etc or time. They state how much they would pay for standard programs, i.e. some common phoronix-test-suite benchmarks. The providers also state their price in terms of canonical benchmarks. Then, the linear-algebra algorithm determines how to decompose those prices into the prices per CPU instruction, RAM fetching etc., and determines the bill at runtime. The algorithm knows how to (optimally!) compensate over the variance between the different kinds of hardware. It's a bit sophisticated and advanced-math mechanism, see our docs for more details. For our case, what needs to be concluded is that not only the publisher's requirements determine a match, but also the performance of each provider, while each having various models of hardware.

3. Each provider will tend to serve several publishers in parallel. If each provider serves 10 publishers, then the risk of both provider and publishers decreases by about x10, since if a publisher do not pay, the provider lost only 10% (note that payments occur every few seconds in a frictionless manner thanks to the Micropayments algorithm, so there will never be a big loss by all means), and if the provider is gone, the publisher loses only the work of 10% of a PC, not 100%. Hence, back to your question, the desired behaviour is to serve both publishers in parallel.

4. Your question still remains if we have many (say 100) publishers with the very same parameters. It is indeed a realistic case: for example, many researchers use Gromacs for molecular dynamics simulation, and they can even work on the same institute with the same terms. So how will Xennet handle this?

5. Same rationale of 3, i.e. reducing risk, points to another risk-decreasing behaviour: say I do have 100 identical publishers. On such case the client will just pick publishers randomly. This is a risk-reducer since it spreads the risks among all nodes.

6. Note that if from that identical publishers, some of them either have richer history than others (seen at the ledger), or, if my specific node served one of them in the past and kept some reputation measurement for this publisher (will be done automatically by the client), it will prefer the one with more reputation.

I hope I addressed your question.
Please (you and everyone) do not hesitate to ask any kind of question about Xennet.


P.S.
"one of the most interesting projects i saw lately" just one? show me another with the same magnitude of redemption :)

Thank you for the detailed answer!
It gives a lot of confidence in this project to see that you really gave much thought to all the fine details.
If i have further questions i will definitely ask away.
Oh, and I stand corrected - this is the most interesting project i have seen lately! it's a keeper!  ;)
Will surely keep an eye out for more info on development and hope to participate in your scheduled pre-sale!

always nice to see innovation!
@Dev: can you explain more about the XenCoin?  

Keep my eye on this. ;)

Me too. Extremely interesting proposal here.

Is there any IPO/ICO or pre-sale for this coin, I want to invest in it.

From xennet.io:

Sure,

On Xennet, people will trade computational resources for XenCoins.

Its purpose and design goal are to be a token for activating computational machines. It's interesting to note that XenCoin has a real intrinsic value, as it is fully backed by the right to use a certain amount of computation power.
The best candidate for now for the coin technology is Delegated Proof of Stake (http://bitshares.org/delegated-proof-of-stake/) by Dan Larimer.
On the pre-sale XenCoins will be sold, and delivered after the product is ready.
People naturally ask why we don't make it over Bitcoin. The reason is that for the Micropayment process to initiate, provider has to wait for confirmations for the multisig deposit by the publisher. Hence, publishers might have to wait 45mins until the work begins, which is unacceptalble.

Interesting, but for now just a synopsis.

synopsis?!?
have you even read all of it?

- http://xennet.io
- https://docs.google.com/document/d/1Y-JKJtJrnGpEISgpEpGKqwmW-atg0_Uk2rJAH5YpaLc/edit#heading=h.8llwmxkra3of
- https://github.com/Xennet/xennetdocs

- http://insidehpc.com/2014/08/new-xennet-hpc-cloud-free-market-alternative-aws/ (just found this  :))

refreshing to see a cryptocoin with real intrinsic value, that aims to solve an actual problem.

@Dev can you explain more about the Micropayment protocol? (to a non technical person please  ;))

Now this is a very interesting idea. Just wondering are you part of the team?

This should take months to develop, please take your time. Perfect it, make it air tight. Bookmarked will for sure following this.

good no IPO  ::)

Yes, I'm Ohad Asor


The Micropayments protocol is described here (https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party).

tl;dr version:

Denote our publisher by A and provider by B. Then A has to continuously pay to B.
A transfers some coins to a 2/2 multisig address with A's and B's addresses, but only after B signs (offline) and sends to A a refund transaction, with some nLockTime, so if B runs away, A can redeem this refund transaction after a certain period of time.
After coins were locked, i.e. the transfer to the multisig address got enough confirmations (on Bitcoin it might take very long, that's why we can't make it over Bitcoin), they begin the work and continuously sign each other a transaction where the refund amount is reduced, and the amount paid directly to B is increased. Those transaction are sent offline and not being sent, hence the continuous update is frictionsless.

when do we get details of the pre sale. its best to have the coins on a exchange where we can buy them straight away. bittrex wouldn't mind supporting this

The pre-sale will take place before the software is ready. As mentioned above, it's a lot of work. Hence using an exchange is not an option.
I can't promise now exact date for pre-sale details, but it shouldn't take too long.

how would a exchange not be good just make pre sale available when software is ready. having it on a exchange makes life easier as it won't need to be individually distributed

The pre-sale will take place long before the software is ready. We need it to fund the dev.

thats awesome but im just saying put it on a exchange so we can buy it from there

Have a look on two organic press releases:
http://www.hpcwire.com/2014/08/18/free-market-hpc-cloud-development/
http://insidehpc.com/2014/08/new-xennet-hpc-cloud-free-market-alternative-aws/
We will also mention that some worried supercomputing companies have contacted us.

how much are you looking to raise hope its not a crazy ipo like ether

Well the market will tell.
The market size of Xennet (HPC, Big Data, Worldwide computing resources) is so much bigger than the market of cryptocoins (in which we're huge fans of), especially in terms of demand and being a bottleneck for so many (good and wealthy) organizations. Moreover, XenCoin is by no means a coin that is designed to be useful for generic value transfer. It is optimized for use over Xennet and to rent computational resources.
So we have many people that need XenCoin (HPC consumers), and on the other hand, we do need to invest a lot on the product itself, it's audience, and build more applications on top of Xennet, like XenFS and XenTube as in the RFC (https://github.com/Xennet/xennetdocs), or a distributed and decentralized search engine.. God knows. Endless work towards us.
Anyway it's going to be a very fair sale. Details aren't closed yet, but will of course be announced here.

Note that the RFC is a bit outdated, and http://xennet.io contains a newer design of Xennet implementation.

Note that the mining, or transaction approvals etc., is *not* done by the computational work. This work is unable to be proven. What goes between the publisher and the provider, cannot be proved to a third party to be true. Trustless network is implemented by other means. Xennet is a layer on top of the coin layer, which will use a common algorithm such as POW, or maybe Delegated Proof of Stake.

So as for the coin safety, you can feel safe.

We still didn't decide whether there will or will not be a test client, this is a possibility that depends on several considerations.

We're in contact with companies having very massive computing resources so we can test it all well. We also hired a qualified QA manager. Intensive tests will be done and nothing premature will be released. Our developers are from the top of the industry with very large expertise in bringing high quality products to the market, for example, life critical products for the medical market, software for banks, and many more.

Quality is definitely one of our main guidelines, and we shall invest as much resources as needed (yet available) to deliver a top quality product.

When for ICO?

ould appreciate it if someone could briefly summarise:
1) the strengths of this coin?
2) the weaknesses of this coin?
3) promises made? kept? any FUD?

To the dev(s), what will be the key original code/feature(s) in this coin? And are you going to provide "Proof of Developer" certification from cryptoasian:
http://cryptoasian.com/

And are the devs here real developers, or copy-paste devs or middlemen, like the SYS guys?

will watch what happens later.

That's so much more than just a coin. It's not even meant to be a coin. Please read some more here and on the links. The devs are from the top industry of software, as can be seen in our documents.

an article about Xennet Supercomputer that was publish in the insideHPC:
http://insidehpc.com/2014/08/new-xennet-hpc-cloud-free-market-alternative-aws
"Today we caught wind of something coming out of stealth mode called the Xennet initiative, a “public, distributed, and decentralized Supercomputer.” As the brainchild of Israeli computer scientist Ohad Asor, Xennet is essentially a free-market alternative to AWS that sounds a lot like the marriage of BitCoin and SETI@Home."

I will try to answer your questions:

Strengths - (1) XenCoins have real intrinsic value (fully backed by the right to use a certain amount of computation power)  (2) the project aims to solve an actual problem, there is a very big demand in the High-Performance Computing (HPC) for computation power. (3) The HPC is hundreds billions market with rapid growth.
            
Weaknesses - very innovative project, there will be hurdles along the way.

Promises made? kept? any FUD? - I don't know of any yet, this thread is just a PRE-ANN to get the community involved.

Original code/feature? - they are using industry's most solid technologies. The originality will be to bring everything together to achieve the xennet goal - Creating a public decentralized Supercomputer with frictionless reward mechanism using blockchain technology.

Are the devs here real developers? you can check Ohad Asor linkedin here: https://www.linkedin.com/in/ohadasor

This looks to me much like the Cloak story: promise a 'holistic' idea but not deliver.
That's the difference with Bitcoin, when it was introduced it was already there only to develop further upon. Todays new coin launches are more like a businessplan or ideas that need to be developed but if it ever comes to full launch remains uncertain. A very risky investment that is mainly driven by new investors entering the market with  the same high hopes.
In the real world only 1 out of 1,000 ideas will be successfully developed if at all.

That being said I'm not saying this coin can't be that 1 successfull launch. So goodluck if you're serious in achieving the goal.

Note that we published a detailed software design document which explains how to implement the product. We haven't published the current code yet.
We also have the right personnel.
Using the funds from the crowdsale we will be able to finish the development and deliver the product.

keep an eye on it.

Dude,

please

stop posting this on every single thread.

Too many new coins, threads, posts to track. These are discussion threads to discuss the coins, no?
No interest in informing newcomers about the coin?

Just read the info available and make up your own mind.  Every thread I go.on you copy and paste the same thing. Even if it's only 1 or 2 pages

The idea is simply brilliant. The question how unused resources could be used in a (semi-) trustless and distributed way was asked many times, but using micropayment channels might be the missing piece and part of the solution.

After a quick read I have a few questions and excuse me, if I missed the general concept:

xennet.io (http://xennet.io/) describes the idea of decrentralized supercomputing where access via SSH to VMs can be rented or sold. Contracts are negotiated over a P2P network and payments are done via payment channels for actual work which, according to the description, can be measured. This seems pretty straight forward.

xennetdocs (https://github.com/Xennet/xennetdocs) in contrast mentiones elements like XenFS and XenTube, proof of storage and much more. So what's the plan? Distributed HPC or MaidSafe 2.0?

This particular statement made me wonder:


I'd like to quote Satoshi (https://bitcoin.org/bitcoin.pdf):


The blockchain is basically a ledger where data is published in an ordered structure and it provides an answer to the question which piece of data came in first.

Peer discovery and contract negotiation doesn't seem like something that requires such properties and might as well be satisfied by other communication networks. Once two peers are matched, they can furthermore communicate in an isolated channel. I don't really see the benefit of using a blockchain here and the BitTorrent Mainline DHT with likely over 25 million participants is probably a prime example how it could be done, too -- without any delay based on "block confirmations" or whatsoever. You may take a look at the colored coins projects or bitsquare (https://www.youtube.com/watch?v=upENHwHzqZM&list=PLXvC3iNe_di9bL1A5xyAKI2PzNg8jU092&index=1) (to name a another concrete example), as well, which intend to use an overlay network for order publishing.

I assume this is directly linked to my third note or question:

Why do you want to create a new coin at all? Despite that this would be a huge and complex task on it's own, not even looking at all the implications and security risks, I seem to miss the underlying need in the first place.

To quote:


I'm not sure, if this is indeed linked to my previous comment (with something like: tx with "announcement" -> block confirmation -> tx with "accept" -> confirmation -> tx to "open channel" -> ...), but let's assume for a moment this is only about opening the payment channel: I would humbly disagree here and wonder: how do you come up with a delay of 30-90 minutes? When I look at Gavin's chart which shows the relation between fees and delay of a and inclusion within a block (http://bitcoincore.org/smartfee/fee_graph.html) it seems that you can be pretty sure a transaction can be confirmed within one block at a cost of 0.0005-0.0007 BTC/1000 byte or two blocks at a cost of about 0.00045 BTC/1000 byte transaction size. Given that opening the micropayment channel equals funding the multisig wallet via a standard pay-to-hash transaction with a size of usually about 230 byte, then it comes down to a cost of about 0.0001-0.0002 BTC to ensure at a high probability the channel is opened within one or two blocks.

With a block confirmation time of usually 10 minutes, but due to the increasing total computation power of the network, of usually even less then 10 minutes, this is far away from 30-90 minutes.

This timeframe, depending on the level of trust in the other party, could be used to begin with the work (probably not wise), but also to setup everything that's needed in general and especially to run the benchmark (let's call this proof-of-benchmark ;) to measure the system's capabilities. The inceives during this periode seem sort of balanced, given that one party at least pays the transaction fee to open the channel and the other party which spends computitional resources to run the benchmark.

Another question I'd like to throw in: is an almost instant start even required here? I'm not familiar with HPC and what is usually computed at all, but I would assume tasks that require heavy resources usually run over longer periods of time and say (totally out of thin air) there is a lab which wants to run some kind of simulation over the next 7 days, then I'd say it doesn't really matter, if the work begins within 5 or 30 minutes.

My last question derives from my lack of knowledge in this field, too, but would it be possible to game the system or even produce bogus data? Related to Bitcoin mining it's pretty simple: there is a heavy task of finding a nonce which produces a hash with some specific properties. The task can easily take quite some time to be solved, but the solution can be verified almost instantaneously.

If the "usual work" done in HPC environments has similar properties, then I see a golden future. If this is not the case and if results may not even be verifiable at all, then this could be a significant problem.

Looking forward for your answers. Cheers! :)

Thanks Dex!

It is important to bear in mind that Xennet is only IaaS (Infrastructure as a Service) and not PaaS (Platform) or SaaS (Software as a Service). Xennet brings you access to hardware. It need not help you manage your workers and their up/downtime, or latency and so on, or to divide the distributed work between them - Xennet won't do it just because there are plenty of wonderful tools out there (e.g. Hadoop). We do not aim to innovate on this field. All we do is bringing more metals to existing distributed applications.

Even though Xennet is an infrastructure, it's a strong and versatile one. Any native code can be executed, hence more applications can be built on top of Xennet. One of then is XenFS. Xennet+XenFS will provide both computational power and storage, but they're different layers, one on top of another. So we'll have HPC, Big Data, Cloud, Storage, and all decentralized and open for applications on top of it.

Xennet does not implement algorithms to verify the correctness of the execution. Such algorithms are a very hot topic in academic research nowadays, and once there will be a good way to do it, we will probably use it. But, Xennet can still be a fair market even without such verifications. We cannot totally eliminate the probability of incorrect computation, but we can make this probability as small as we want.
For example, if we make each work twice, it'll cost twice, but the probability of mistake will be squared. Linear growth in the cost gives exponential decrease in the risk. But that's not the only mechanism. The micropayments protocol bounds the time that a fraud affect to several seconds. As for storage in XenFS, the mechanism of bounding the probability is totally different, as described in the RFC.

Maliciously misleading measurements will be taken care by calculating normally distributed fluctuations from the pseudo-inverse. See the linear algebra part. The errors of the least squares problem are known to distribute normally (Gauss proved that) so one can configure the distribution tails' when they disconnect the from their party due to high enough probability of misleading measurements. It's a bit complex, I know, but the user will only config % of probability to reject.

Moreover, a publisher can rent, say, 10K hosts, and after a few seconds drop the less-efficient 50%.

Another risk-decreasing behavior is that each provider works simultanously for several publishers. Say each work for 10 publishers in parallel, so the risk to both sides decreses 10 fold. See my answers earlier on this thread.

You claim that the time for confirmation (for the micropayment initialtion via the multisig deposit) may be much less than 30-90  (I stated those numbers while thinking about 6 confirmations. DPOS gives you more security with less confirmations). You mentioned that high fees may help. Note that this deposit should be for each provider separately, and on the total, they don't get much coins since usually small amounts are transferred, also for risk management. So the fee cannot be high. In addition, even if the confirmation would take 5 minutes, that's still a lot. Look: the world's fastest supercomputer is about like 8,000 AMD 280X GPU, in terms of TFLOPS. So a full day of fastest supercomputer work should be done in minutes or even seconds, without Xennet having even 1% of all GPUs. Moreover, Xennet is an infrastructure for more applications, like XenFS and XenTube. If someone wants to publish an encoding and streaming task over XenTune, will they have to wait 5 mins before they begin watching?

So 5 min are too much time. In addition, POW is pretty obsolete. It's also centralized, de-facto. I tend to find DPOS much better. What is your opinion?

As for the benchmark, the publisher does not run a benchmark each time it connects to a provider (otherwise huge waste will take place). The provider's client does benchmarks from time to time, and the linear algebra algorithm is smart enough to compensate over different hardwares showind same measurements but still one is more efficient, or fluctuations of other tasks in the background, and so on.

Why publish the ann over the Blockchain? It will be up to the user's choice whether to make the ann prunable or not. We might even support propagating it between the nodes without getting into the blockchain (but we have to think about cases if nodes don't have incentive to pass anns). Some users will want their ann to be public and persistant, for the sake of reputation.

I hope I touched every point and didn't forget more related strengths to present on this scope.

Thanks again,
Ohad.

Some more words about it: as mentioned, risk can be controlled. Also verifications can take place, when verifiable algorithms are in question. Many of the common algorithms are efficiently verifiable, such as root finding, matrix inversion, eigenvalue problems, all NP-Complete problems and so on, all cover many many applications.
If the work is totally unprovable, then do it twice and square the risk.
Yet, Xennet cannot help you on proving your specific algorithm. This is task-dependant. Xennet assumes that you already have a software that manages endless hosts, some more stable than others. It just gives you the hosts.

EDIT
Another point which I think worth mentioning is that the pricing units are much more noise-resistant than common.
Explanation:
Naturally one would suggest negotiating a price for a unit of time of usage, as in all server hosting services. But this is not very fair: what if I used only 20% of the CPU overall? On Xennet, we measure how many CPU instructions were made, how many sequential RAM reads, how many random disk writes and so on. Hence, even if the computer was loaded and did the job several times slower, on our scope of distributed computing which doesn't matter about the speed of each specific node, it will still get paid for a single job like everyone else.
This way we allow to reduce the risk to both sides by serving many publishers in parallel, yet the billing remains accurate, and even more accurate (and fair) than AWS for example.
Now since the publisher has all the information from all nodes, like the expected CPU instructions for a work item to complete and its variance, it can easily identify outliers.

Ah, thanks for the answers!

The numbers you used in your example ("rents 10k hosts") hint that this is about a much larger scale than I initially assumed.

The magical number of 6 confirmations has actually not all that much meaning in reality and is derived from the fact that a miner with 10 % hashing power has a chance of less than 0.1 % to double-spend a transaction with 6 confirmations, if I recall correctly. Anyway, this number was probably mentioned once and has been repeated since. Meni Rosenfeld wrote an interesting paper (https://bitcoil.co.il/Doublespend.pdf) about this topic and came up with the conclusion that one should rather look at the transacted amounts in relation to the probability that a malicious party might attempt to double-spend a payment instead of sticking to some fixed numbers ("it's no gain to double-spend 20 BTC, if this comes at the cost of losing one block reward of 25 BTC").

A delay based on channel initialization is given at the very beginning, but can be hidden, if leaving clients are replaced early enough. Furthermore there might not be the need of closing a channel between honest parties right after the work contract ended at all, since both parties seem to benefit from a faster setup. At best a network with many nodes and many open channels is established over time. This of course doesn't imply each channel must be active, in the sense of transacting value.

This likely holds true for whatever underlying payment network is used and I think it's probably best to seperate as you already did: there is the service layer (Xennet) and a payment layer (XenCoin, Bitcoin, ...), as well as another layer for the applications (such as XenTube).

My main question sort of remains, but I can phrase it with different words now: do you want to focus on building another payment layer or a service? Do you intend to do both?



Actually I'm not sure. I'm heavily biased in favor of Bitcoin, but I have a high level knowledge about other approaches and acknowledge the potenial of alternatives, still I feel like this is not enough to answer this question properly. One of the main difficulties I see in the whole context is that you can be certain that a system failed, once it failed, but you can only guess that it won't fail in the future, based on assumptions derived from the information that is available at the very moment. Calling POW obsolete seems a bit premature, given it's track record of more than 5 years and a pretty solid understanding that has been established during this time. Simply put, it works. And without a doubt I consider Bitcoin as the most solid basis to build upon.

A different topic however is the context and which properties you need or consider as valuable, whether that is network security, transaction cost, block confirmation delay, the user base, ...

Sure, 6 confirmations is just a common number and does not represent a fixed risk. But as I wrote, even 1 confirmation can take too much (sometimes it does take 30mins without even one block!!). Mean, average, expected, but variance is very high.

As for keeping open channels etc., see the XenFS's "circuits" mechanism on the RFC. But it'll work for closed jobs like XenFS, not for arbitrary computation. Still, note that those frequent money locks have financial consequences. If it'll always seek for more clients just because the coin is slow, it'll have to have a larger initial amount of coins, which not all will be used. They also have to be split more times to many small accounts (the multisig ones), which costs fees.

You asked "do you want to focus on building another payment layer or a service?" and the answer is that I don't really feel unstoppable desire doing this, but I must to. I need a secure(!!) coin with max 1min block time (1min is also too much). I managed to come up with two solutions: either DPOS, or the blockchain modifications I listed on xennet.io (some of them might be novel).

As for Bitcoin being obsolete, let's face it bro: we're counting in dog years when we talk about tech, 5 years are a long time for a technology! And it's only the first one. No surprise at all that no one imagines a new coin which is the same as Bitcoin is, and not just because Bitcoin already exists. The mining is problematic. Also, POW is making the network centralized by the largest pools. And, again, it's slow.

Will be glad to continue this professional discussion with you, and get new advice and insights. You certainly know what you're talking about.

can't wait to use my computers as a part of the cloud

if we had good internet connection at our homes
we could give up centralized hosting

it seems like most of the world isn't far from there in terms of internet connection speed

I was just wondering what are the security measures that would be set to prevent abuse? DDos attacks for example?

If a client is looking for say 1000 computers worth of computational power, would the client and each "Seller" have to follow these steps:

Do the 1000 computers form a cluster acting like one supercomputer?

The provider will able to block (or limit) any network connections outside the publisher's box (we might block it by default to avoid such concerns). Providers may block data persistence as well. They will also be able to work with specific trusted publishers (such as a University). That's where the beauty lies - it's an open and free market. It's all up to participant's decisions and preferences, including the pricing.

As for security on the provider's PC itself, it all runs in a restricted VM and the publisher does not gain elevated access even inside the Docker box, not to mention elevated or non-elevated access to the VM containing the boxes, not to mention access to the OS running the VM.


Yes, each step is required for any single pair of publisher and provider, and this points to why we need a dedicated coin.


Yes.

Let us tell something about supercomputers: the fastest one in the world does 33 Petaflops. Like 8000 AMD 280X GPU, which exist maybe in every average western city. They hired 1300 engineers to build this giant computer. And still, not every researcher gets instant access to it..

im confused...is this a coin or what? if it is whats the details. sorry for the noob questions, just very unfamiliar with this.

Maybe listening to the podcast (see on bottom of the main post) will give you some introduction.

We at Xennet are committed to top quality. That’s one of the reasons why Xennet article (http://www.xennet.sc/about/index.html), RFC (https://github.com/Xennet/xennetdocs) and SDD (https://docs.google.com/document/d/1Y-JKJtJrnGpEISgpEpGKqwmW-atg0_Uk2rJAH5YpaLc/edit#heading=h.8llwmxkra3of) are publicly available; but merely making them public, doesn’t accomplish anything if people don’t read them.
 
For this reason, Xennet bug bounty provide an opportunity for people who find a serious flaw in our plan to be compensated.

We offer 1 BTC to the first person that points out a serious flaw in our plan to build xennet supercomputer, that will cause us to make a change accordingly.

Note: The RFC and SDD documents still describe the traditional VM design. The current design as described here at BTT and in Xennet article (http://www.xennet.sc/about/index.html) was written after we have moved to OS virtualization, among some other changes.

Guys you need first to do POD for this ICO. Many investors want it today

when can we start mining / buying ? ^^

Quite detailed information given on your website , it was a long read  :D . When is the pre-sale btw ?

Thank you for your interest about Xennet.
Full details about the presale will soon be given (~1 month).

Sounds cool, keeping my eye on this one!

Tons of coding though.....can you elaborate on the status of development?? any Roadmap?

My participation depends only on the amount of BTC looking to be raised. If your looking to raise in the area of 600, than I'm all in and even sends respected BTC amount....Nevertheless if its going to be another SYS, SWARM or other monstrous ICO than I'm out of here.....please seriously consider an Investment Cap of the total amount raised...too much mega ICOs lately and practically all of them very disapointing

+1

Gentlemen,
As YNWA2806 wrote, "tons of code". If you can make this product with only 600BTC, please come to work with us. You must be top devs.
Please take some time to understand the size of the project (Xennet, XenFS, Xentube and some more). Also note the various expertises needed. Personally I have them all but this project is too big to finish it by myself within a reasonable time.

only IPO,no freeaway?  ??? ???

Will you make this open source?

Not only open source, but fully decentralized, no middleman, we can't earn a penny once the system is out.

Looks epic!  :o

so when do you think the ico will be released and abouth how high will be the mcap ?

Full details will be given in a few weeks (or even days).
As the the mcap, recall that this is a much larger market than known so far in the world of crypto (I'm speaking about the market of distributed arbitrary native computation of course). So I expect it to begin with billions. We also thought much about a fair coin distribution.
As said, very soon details will be released.

Did you do tech feasibility research of this coin, sometimes theory is good but it is not realistic, and how can we know you or your team has the ability to complete this project, can you share some information?

Feasibility research was done intensively and is reflected from the public technical documents, which are deep and wide far more than common in new crypto projects.
Up to now, even with media exposure and a bounty, no one found a flaw.
You're welcome to check our dev's LinkedIn and get some impression about the ability, this in addition to the professional documents.
We will gladly get into any public technical questions, questionings, discussion, suggestions etc.
So take some time to read the docs, and you might find a flaw and win the bounty!

No flaw has been disclosed.  There is a subtle difference.  (Presumably anyone finding a significant flaw would stand to gain more by not disclosing it, no?)

Not really. Think of the HPC and Big Data giants. They have a great interest to find a flaw. Many of them contact us to see how they will be able to keep their business with Xennet. Mentioning Xennet, let me say that we'll modify its name soon, cause of https://www.dropbox.com/s/am2g3jk5jo60itz/XENNET%20Ltr.pdf?dl=0

Thanks for the explanation,where is your team Linkedin, can you post the Linkedin link in OP?

They also probably have the greatest interest not to disclose it to you.


I have trouble believing any major players are really threatened.  Xennet isn't the first attempt at a decentralized resource exchange.  Heck, many of them even do their own "decentralized" resource exchange, already.  ;)


Interesting.  I'm sure some other coins have gotten similar C&D notices lately, but you're the first I've seen who has said such publicly.

Partial LinkedIn profiles list now appears on bottom of OP.
Note that we began making the transition from Xennet to Zennet.

Depends. There are many talented people who will be happy to get 1BTC, but not really into ruining networks.


I never heard of any such successful attempt. Please let me know if you heard of one. Yes, they are threatened, they say it themselves. We indeed solved old problems who many have thought of, thanks for new cutting edge technology.


How come you're so sure we're just like everyone else? ;)

I don't know about this one yet, but I'll keep an eye on for sure.

let's take on the big boys in their own back yard! ;D  ;D

These would be mostly or entirely disjoint sets, no?  I'm not sure what the one statement really says about the other.


Seccomp is in the linux kernel largely because of CPUShare and related projects.  You are correct that none were largely "successful" in the sense that none have gained broad mass-market adoption.  There were many attempts of various sorts.  None survived, unless you count Globus style initiatives, and I don't.

As far as I can tell, you have not presented solutions to any of the "old problems" that kept these sorts of projects from taking off in the past.  Your model actually seems largely reiterative of them, with the exception of the introduction of crypto for payment. (Though CPUShare markets did use escrow models to achieve the same goals.)

Your model seems to suffer from all of the same problems of lacking convenience, security and data privacy, authentication, rich service discovery, and adaptability.

How does this really intend to compete with the "semi-private" overflow trade commonly practiced by this market already?  How are you going to take market share from this without some advantage, and with so many potential disadvantages?


Huh?  Who said anything about anyone being just like everyone else?

That's exactly the point bro. Go over the literature and see how we actually solved the real underlying problems, which were pending for a long time. See also Q&A on this thread. I began working on it ~1yr ago. It's far from being only virtualization plus blockchain, and there are several very significant proprietary innovations. All can be seen from the docs.

I've read over all of the materials that you've made available, "bro."

I've re-read them.

I still don't see where the problems get solved.


Where?  Maybe I'm missing something, but what is the actual innovation, here?  How is this preferable over spot priced surplus resource from any of the big players?  What is the competitive advantage?  Why will XZennet "make it" when every prior attempt didn't, and failed?

The workflow is inconvenient.  Reliably executing a batch of jobs will carry a lot of overhead in launching additional jobs, continually monitoring your service quality, managing reputation scores, etc.  If you don't expend this overhead (in time, money, and effort) you will pay for service you don't receive or, worse, will end up with incorrect results.

By launching jobs, you're trusting in the security of a lot of random people.  As you've said, you have to assume many of these people will be downright malicious.  Sure, you can cut off computation with them, but by then they may already be selling off your data and/or code to a third party.  Even if the service provided is entirely altruistic the security on the host system might be lax, exposing your processes to third parties anyway, and in a way that you couldn't even detect as the sandbox environment precludes any audit trail over it.  Worse yet, your only recourse after the fact is a ding on the provider's reputation score.

Since authenticity of service can't be validated beyond a pseudonym and a reputation score, you can't assume computation to be done correctly from any given provider.  You are only partly correct that this can be exponentially mitigated by simply running the computation multiple times and comparing outputs - for some types of process the output would never be expected to match and you could never know if discrepancy was due to platform differences, context, or foul play.  At best this makes for extra cost in redundant computations, but in most cases it will go far beyond that.

Service discovery (or "grid" facilities) is a commonly leveraged feature in this market, particularly among the big resource consumers.  Your network doesn't appear to be capable of matching up buyer and seller, and carrying our price discovery, on anything more than basic infrastructural criteria.  Considering the problem of authenticity, I'm skeptical that the network can succeed in price discovery even on just these "low level" resource allocations, since any two instances of the same resource are not likely to be of an equivalent utility, and certainly can't be assumed as such.  (How can you price an asset that you can't meaningfully or reliably qualify (or even quantify) until after you have already transacted for it?)

How can this model stay competitive with such a rigid structure?  You briefly/vaguely mention GPUs in part of some hand waving, but demonstrate no real plan for dealing with any other infrastructure resource, in general.  The technologies employed in HPC are very much a moving target, more so than most other data-center housed applications.  Your network offers a very prescriptive "one size fits all" solution which is not likely to be ideal for anyone, and is likely to be sub-optimal for almost everyone.

Where is the literature that I've missed that "actually solved" any of these problems?  Where is this significant innovation that suddenly makes CPUShare market "work" just because we've thrown in a blockchain and PoW puzzles around identity?

(I just use CPUShare as the example, because it is so very close to your model.  They even had focus on a video streaming service too!  Wait, are you secretly Arcangeli just trying to resurrect CPUShare?)

What is the "elevator pitch" for why someone should use this technology over the easier, safer, (likely) cheaper, and more flexible option of purchasing overflow capacity on open markets from established players?  Buying from amazon services (the canonical example, ofc) takes seconds, requires no thought, doesn't rely on the security practices of many anonymous people, doesn't carry redundant costs and overheads (ok AWS isn't the best example of this, but at least I don't have to buy 2+ instances to be able to have any faith in any 1) and offers whatever trendy new infrastructure tech comes along to optimize your application.

Don't misunderstand, I certainly believe these problems are all solvable for a decentralized resource exchange.  My only confusion is over your assertions that the problems are solved.  There is nothing in the materials that is a solution.  There are only expensive and partial mitigation for specific cases, that aren't actually the cases people will pragmatically care about.

ok np, let's go step by step:


For example, the pricing model is totally innovative. It measures the consumption much more fairly than common services. It also optimally mitigates the difference between different hardware. The crunch here is to make assumptions that are relevant only for distributed applications. Then comes the novel algorithm (which is an economic innovation by itself) of how to price with respect to unknown variables under a linearity assumption (which surprisingly occur on Zennet's case when talking about accumulated resource consumption metrics).


I don't understand what's the difference between this situation or any other cloud service.
Also note that Zennet is a totally free market. All parties set their own desired price.


I cannot totally cut this risk, but I can give you control over the probability and expectation of loss, which come to reasonable values when massively distributed applications are in mind, together with the free market principle.
Examples of risk reducing behaviors:
1. Each worker serves many (say 10) publishers at once, hence the reducing the risk 10 fold to both parties.
2. Micropayment protocol is taking place every few seconds.
3. Since the system is for massive distributed applications, the publisher can rent say 10K hosts, and after a few seconds dump the worst 5K.
4. One may only serve known publishers such as universities.
5. One may offer extra-reliability (like existing hosting firms) and charge appropriately. (for the last two points, all they have to do is to config their price/publishers on the client, and put their address on their website so people will know which address to trust).
6. If one computes the same job several times with different hosts, they can reduce the probability of miscalculation. As the required invested amount grows linearly, the risk vanishes exponentially. (now I see you wrote it -- recall this is a free market. so if "acceptable" risk probability is say "do the calc 4 times", the price will be adjusted accordingly)
7. User can filter spammers by requiring work to be invested on the pubkey generation (identity mining).
I definitely forgot several more and they appear on the docs.


See above regarding the pricing algorithm which addresses exactly those issues.
As for matching buyers and sellers, we don't do that, the publisher announces they want to rent computers, while publishing their ip address, then interested clients connect to them and a negotiation begins without any 3rd party interference.


The structure is not rigid at all - the contrary, it allows full control to the user.
The algorithm is also agnostic to all kinds of resources -- it even covers the unknown ones!! That's a really cool mathematical result.


As for Zennet vs AWS, see detailed (yet partial) table on the "About Zennet" article.
If you haven't seen above, we renamed from Xennet cause of this (https://www.dropbox.com/s/am2g3jk5jo60itz/XENNET%20Ltr.pdf?dl=0).

I think that what I wrote till now shows that many issues were thought and answers were given.
Please rethink about it and please do share further thoughts.

If its possible for people to run this thing on a fairly normal home computer then these extra overheads are not a problem, because compared to a commercial operation the 'miner' will have substantial cost savings due to not having paid for dedicated hardware, facilities, staff etc which should more than make up for the additional computational costs.

Ohad Asor was invited to present Zennet on a Big Data & Crowd Computing Conference (http://crowdcomputing.eu/workshop-2014) in Amsterdam

What is the innovation?  What new contribution are you making?  I hear you saying over and over again "it's innovative, it's innovative, no really it's TOTALLY innovative" but you haven't yet come out and said what the innovation is.

Averaging some procfs samples is hardly innovative.  Many providers (at least the ones that don't charge based on straight wall-clock time) do this.  What are you doing in this pricing model that is new?


Except that it doesn't, and this is somewhat central to my point.  It measures consumption in (more or less) the same way as everyone else, but instead of having a company to complain to or sue if they lie about their stats the user only has a pseudonym to leave a comment on.  The system removes the actual accountability and replaces it with a trust metric, and further makes it exceedingly easy to lie about stats.


How?  This is certainly not explained, or not explained well, in your materials.  I see some hand waving about risk analysis in the client, but nothing that actually does anything about it.


Ok, what assumptions are we talking?  You say these things, but never complete your thoughts.  It gets tedious to try to draw details out of you like this.


Aside from the novelty claim (RE my first point, I don't see the novelty)  I see two issues, here.  First, the linearity assumption is a big part of the rigidity.  It applies fine for a traditional Harvard architecture CPU, but breaks down on any "real" tech.  How does your pricing model price a neuromorphic architecture? How does your pricing model measure a recombinant fpga array?  How do you account for hardware that literally changes (non-linearly!) as the process runs?  (The answer is self evident from your own statement - right now you can't.)

Second the pricing model only prices against the micro-benchmarks (indicating, right there, that the performance profile indicated in the pricing model will differ from the applied application!) and doesn't account for environmental context.  With modern distributed systems most of the performance profile comes down to I/O wait states (crossing para-virtualization thresholds) and bursting semantics.  I don't see either of these actually being accounted for.  (Maybe you should spend some time with engineers and A.E.s from AWS, Google, Rackspace, MediaFire, Joyent, DigitalOcean, etc and find out what your future users are actually going to be concerned about in their pricing considerations.)


With any other cloud service I can spin up only one instance and be fairly confident that it will perform "as advertised" and if it doesn't I can sue them for a refund.

With your service I can't spin up one instance and be confident about anything.  If it turns out that one instance is not as advertised - all well, too late - there is no recourse for compensation, no jurisdictional court to go to, no company to boycott, nothing but a ding on a trust rating.  (Again if you think trust rating works in a vacuum like this you should just look around at some of the trust rating behavior on these forums.  It doesn't.)


I've been ignoring this catch-22 statement up to now.  Either the pricing model is a free market, or the pricing model is controlled by your formula and magical risk-averse client.  It can't be both free and regulated by protocol, this is a contradiction.  Either your users manage the pricing or the software manages the pricing for them, which is it?  (I'm not sure either is sustainable, without changes elsewhere in the model.)


Now we get to why I'm actually "all riled up" here.  You could totally cut that risk.  Over the past decade, real solutions to these problems have been found.  You aren't applying them.

Why the heck not?!?!?!

Also, this is another of your contradictory statement.  You simultaneously claim some innovative new solutions to the problems at hand, and that you cannot solve them.


Again setting aside the catch-22 assumption that the market is free (and not re-iterating that these are not solutions but costly partial mitigation) this statement still doesn't stand to scrutiny.  The values actually converge to *less* reasonable sums as you scale up distribution!


This reduces risk on the part of the worker, but increases risk on the part of the publisher by adding to statistical variance of the delta between measured performance and applied performance on the part of the worker.  In other words, this behavior makes it safer (though not 10 fold, as you claim) for the worker as they diversify some, but their act of diversification introduces inaccuracy into the micro-benchmark.  Now my application's performance profile is being influenced by the behaviors of 9 other applications moment to moment.


Another point that you keep reiterating but not expounding.  The problem here is the same problem as any speculative investment - past performance does not guarantee (or even meaningfully predict) future results  As a publisher I spin up 10K instances and then dump half.  Now I've paid for twice as much work over those "few" seconds (a few seconds on 10K CPUs is an awfully long time, and gets expensive fast) and dumped half of my providers without knowing which in that half were malicious or which just had some unlucky bout of extra cache misses.  Further, I have no reason to believe that the 5K I'm left with won't suddenly start under-performing relative to the 5K that I've just ditched.

You could induce a counter-argument here by saying "well just spin up 5K replacement nodes after you drop the first set, and then re-sort and drop the 5K lowest, rinse, repeat" but this actually only exacerbates all of the other problems related to this facet of the model!  Now I'm *continuously* paying for those "few" wasted seconds over and over, I have to structure my application in such a way to handle this sort of consistent soft failure (So doing anything like MRM coordination in a useful way becomes both very difficult and laden with even more overheads!) and I still have no reason to believe that my system will ever converge onto an optimal set of providers.  (Maybe there simply aren't 5K non-malicious workers up at the moment, or maybe some of the malicious nodes are preventing my reaching that set!)


Again, this is a behavior that only mitigates risk for the worker.  The worker doesn't need much risk mitigation - they are largely in control of the whole transaction - the buy side needs the assurances.


Wait, now you're proposing the sort of solution of "just re-sell AWS" as a compensatory control?!?!  This isn't exactly what I meant by competition, and precludes reliable service from ever becoming priced competitively.  (Why wouldn't the buy side just skip the middleman and go straight to the established hosting firm?)


Did you miss the part where I pointed out that this behavior is only applicable to a subset of useful computations?  Here's a "real world hypothetical" related to an actual HPC initiative I was once involved with - ranking page-rank implementations by performance over time.  In other words, systematically and automatically comparing search engine result quality over time.

There are two places where this behavior directly fails to meet it's goal.  First, there's the obvious problem of floating point precision.  The numbers spit out from two identical software runs on two different architectures will not be the same, and the vm layer specifically precludes me from necessarily knowing the specifics of the semantics applied at the hardware.  Second, even if the architectures are identical as well meaning float semantics are identical, the algorithm itself lacks the necessary referential transparency to be able to make the assumption of consistency!  Instance A performing the query against the service might (usually WILL, in my experience!) alter the results issued to instance B for the same query!  (Unfortunately, most useful processes will fall into this category of side-effecting.)


This does nothing to "filter spammers" it only enforces a (somewhat arguably) fair distribution of identities.  All this does is establish a small cost to minting a new identity and give identity itself some base value.  In other words, you'll inevitably have some miners who never do a single job, and only mine new identities with which to attempt to claim announcements without ever fulfilling anything more than the micro-benchmark step and claiming their "few seconds worth" of payments.  (They don't even have to actually expend resource to run the micro-benchmarks, they can just make up some numbers to fill in.)

(Rationally, I don't see why any worker would ever bother to actually work when they simply "don't have to" and still get paid a bit for doing effectively nothing.)


What doesn't appear in the docs, or your subsequent explanations, are these solutions that you keep talking about.  I see a lot of mitigation (almost none of which are even novel) but no resolutions.  Where have you solved even a single previously unsolved problem?  Which problem, and what is that solution?

Can you really not sum up your claimed invention?  If you can't, I'm suspect of the claim.  (Does anyone else out there feel like they've met this obligation?  Is it just me, missing something obvious?  I'm doubtful.)


EH?  Maybe you misunderstood what I meant by service discovery and pricing.  Pricing raw resources is one thing, but the big consumers are less interested in shopping based on low level hardware metrics, and more interested in shopping based on specific service definitions.  (If current trends continue this will only become increasingly true.)  Your system offers a publisher nothing to base a query for a particularly structured SOA on.


Again, this (like much of your writing, it seems) is contradictory.  Either the market is free and the system does nothing to pair a publisher with a worker, or the market is partially controlled and the system attempts to match an appropriate worker to a publisher.  You've made several references to the client being risk averse implying that the system is actually partially regulated.  You can't subsequently go on to claim that the system does nothing to match buyers and sellers and is entirely free.

In any case, I'm not sure what that statement has to do with the service discovery concern.


I've already touched on this above, so I won't reiterate.

Can you show this "really cool mathematical result" somehow?  I'd be interested to see such a proof, and even more interested in throwing such a proof past a few category theorist friends.  I'm highly skeptical that such a result can be reasonably had, as it is difficult to form meaningful morphisms over unknown sets.  Surely such a mathematical result would be of great interest in the philosophical community!  :D

I'm putting this on my "big list of unfounded claims made in the crypto-currency space that I personally believe to be intractable and won't hold my breath to be shown."

(Seems like that list is getting bigger every day, now!  :-\)


Another reply that doesn't match, at all, what it is replying to.  I'm seeing some persistent themes to your writing.


This one really baffled me.

I did see this.  We even discussed it.

Did you just forget?  Bad short term memory?  Substance (ab)use?

It is going to be difficult to carry out an appropriate discourse if you're not aware of what we talked about less than 10 posts ago.  As a potential investor, this would be particularly troubling to me.


It shows that many issues were thought about.  (It also shows that a few more were not.)

It doesn't show any answers, just tries to explain how it'll all somehow just work out if the publisher just does these expensive and painful things to mitigate.  The reality is that even if the publisher does the expensive and painful things there is no rational reason to believe anything might work out.


I've thought and re-thought about it quite a bit.  Anyone who knows me can tell you that this (thinking about, analysing, and assessing systems) is pretty much the only thing I do.

You have not really addressed many of my points, such as general convenience/usability as compared to traditional providers, or how the system can expect to take away market share from established "decentralized" private trade that already occurs.

I've shared my pertinent thoughts, and now re-shared them.  I do have some further thoughts, but I won't share those because I have very little interest in claiming your 1BTC.  I have three such further thoughts now. :-X

(As someone who is involved, intimately, with that set that you earlier referred to as "HPC and Big Data giants" I think maybe I will see if they would offer more for my further thoughts.  I really hope you're right, and that these players do feel threatened, because then they would give me lots of money for these thoughts, yah?  If they're not threatened then all well, I can make lots of money from naive publishers instead, right?)

HunterMinerCrafter, you indeed touch the real points. Lots of misunderstanding though, but I do take into account that the deep stuff are very brief at the docs. Also recall that I know nothing about the background of each BTT member.
Those issues are indeed more delicate. I can write emphasis here, but let me suggest we make a recorded video chat where you ask all questions and I give all small details, so the rest of the community will be able to enjoy this info.
I think that'll be really cool. But if for some reason you don't want to do it, I'll write my answers in detail here.

In order to make the pricing algorithm clearer, I wrote and uploaded this detailed explanation (http://zennet.sc/zennetpricing.pdf).

All I am asking of you (and of pretty much any coin developer I speak with, if you look over my post history outside of the MOTO thread) is to make me understand.


Your team has only one job right now - deepen it!  (Don't broaden it, that will work against you.)

A very simple way to do this would, of course, simply be to release working source code.  If you do have actual solutions to these problems, it will become self evident quite quickly.


Ok, let me give you some quick background.  I'm a "seasoned" professional in the field of computer science who also has just about 5.5 years of experience in working with logical formalism around crypto currency.  (The number of us (surviving) who can make this claim, aside from perhaps Satoshi, can fit in a small elevator comfortably, and we pretty much all know each other.  A moment of silence, please, for those who can no longer attend our elevator.)




Interestingly, I also have just over a decade of experience with HPC applications and, more generally, data-center operations.  (This would need to be a very large elevator.)  I like critiquing coins' claims in general, but yours is particularly appealing to my razor because it is very much "in my world."

If you'd like some more detailed background on my qualifications as a critic of your claims we can discuss that privately.

Again, I am only trying to fully understand the value proposition.  If you can't make me understand then you might have some trouble making average Joe understand.  If you can't make average Joe understand, your project doesn't have to worry about the protocol actually working anyway because it will fail just from lack of any traction.


Just write them down and publish them.  Posts on a forum or a proper whitepaper, either will do the trick as long as it makes a full (and not self-contradictory) treatment of the subject.

Even better, write it all down encoded in the form of a program that we can run.  You surely have to be doing that already anyway, right?  ;)


For a lot of reasons, I do not want to do that.

How about the three R&D folks just set up a tech oriented IRC to hang out in, open to anyone interested in protocol detail?  I think this would better align with the actual goals of such a meeting.

I hope the doc (http://zennet.sc/zennetpricing.pdf) I just put here will give you a better understanding what is the innovative pricing model.


I'm really glad to have you here. I was waiting long for deep criticism and showing how we solved all main issues. I'm 100% sure, and I put all my professional dignity on it, that I have reasonably practical answers to all your doubts. Let's keep going here. Tell me what you think of the pricing algo.

I'm convinced that you don't have reasonably practical answers to all of my doubts, as you've already explicitly admitted that you lack answers to the biggest of them, in big letters on your github.

"No POW"

If you can't authenticate the computation then you have no reasonable *or* practical answer to some specific doubts.

As long as the workers don't have to prove that they do the work, I doubt they will.


On my second read now.  I think you've quite nicely elided some of the specific problems for me.  ;)

P.S. I like that the new site is up on the new domain, but don't like that it still has all the self-contradictory gobbledygook on the "documentation" page.  I really don't like that when I clicked the link in your OP to get to that page again, it took me to the old domain.  Just a heads up that you might want to check your back-links.  ;)

The solution is sufficient without POW. Since the risk is low and can be controlled to be much lower. I agree that there are a lot of advantages on real computation POW, some with some innovative mathematical or cryptographic ideas, some hardware implemented, but their cost in additional computation or by sending VM snapshorts etc. is high. Nevertheless, I don't rule out implementing such an algo one day. Moreover, nothing on the current Zennet's design blocks such an implementation by the publisher, or by backward compatibility.

Note that the RFC is significantly older than the "About Zennet" doc.


I didn't understand (you obviously noted I'm not a native English speaker).


Thanks.  And yes, we didn't fully finish the migration yet.

Few more points:

1. When you said that the free market idea contradicts the pricing idea, recall that it's all about Zencoins in which their value can fluctuate, in addition to the fact that the user sets the price for canonical benchmarks, and this (together with procfs measurements during the benchmark) deterministically sets the price.

2. Since we're solving a least squares problem, Gauss promises us that the errors are normally distributed with zero mean. Hence, publisher can easily (and of course automatically) identify outliers.

3. More than the above local statistics, the publisher knows to compare a provider to many more. The comparison is the number of finished small jobs w.r.t. paid coins. This can happen in seconds, and by no means, renting a PC for seconds should exceed not-too-much-satoshis.

First, I love a good multi-objective optimization as much as the next guy, so I don't really have any problem with the overall goal in the abstract.  I do agree that this approach to pricing optimization will "fairly" price computational resources.

My problem is that it prices entirely the wrong resources, in several ways.


Why?  This is what has me most baffled.  Why is this your only metric considered?  You say yourself that this approach is intuitive, and I agree, but is it sound?  Why should one believe it to be?


Beautifully put.

One of my three hypothetical attacks on your hypothetical network is based directly on this (bad) assumption.

You seem to have a grasp on the notion that the overall problem is one of measurable linear increments, but fail to realize that "projected procfs" does not represent this linearity, and that linearity can only ever be assumed, not enforced.  Here we get to one of the technical details of the matter, your UVs can only be correctly measured (and as such your formula can only hold as rational) as a metric over a rank one construction!!!!!!!  In other words, unless your UV is derived starting from some "gate count" you can't safely assume that any potential attack is constrained, relatively speaking, to linearity.  Woops.

(For more detail on this you should read up on recent works following from Yao's garbled circuits, and the work of folks like Gentry et al, Huang, etc.  In particular, I suggest reading the work specifically being done on objective cost models (done the "right" way, heh, no offense) by Kerschbaum et al.  I also suggest spending some hands-on time with the JustGarble toolkit, or similar, and proving to yourself what sort of things do/don't violate linearity assumptions under different transforms.  (It probably isn't what you'd expect!  Bleeding edge work is showing that a garbled circuit can even be side-effecting and perform interactive I/O without necessarily violating linearity or increasing rank order of the netlist!  Fascinating stuff going on, there.))

It is as if your attacker can arbitrarily change the cost of any given operation at will.  (Measurement over the whole netlist becomes meaningless/worthless.)  It is like this because it is precisely the case.

Your model only holds if your linear projection is actually a linear projection.  Your measurement of procfs is not, so the rest does not follow.

If procfs offered some rank one representation of system state (like some SSA form of a closure over the last instruction executed) this would be a different story.  I'm not sure this would even be possible without some sort of magical self-introspecting CPU, and suspect that it would certainly preclude any microcode optimizations in such a CPU.

This should be "plain and simple" enough, but I'll go on.



Love all of this.  Apply this over a properly represented process and you're almost on to something.  Authenticate the structure and it's gold!


Here we see the rigidity that I alluded to, and our second big problem.  We are pricing the xn circuits in order to decide on a cost for an entirely different circuit.

In other words, what we're measuring our UVs over is not necessarily meaningfully representative (in any way) of what we are actually attempting to price.

Of course the argument would be made that the only way we can price the algorithm we are "actually shopping for" with this sort of approach involves the worker running a part of it at no cost, leading to a situation where publishers could "leach" computation by only requesting quotes, which is obviously no good.

This tells us that either our UVs have to be taken in situ over the algorithm being shopped, without running it (again "gate count" metrics) or that we need a mechanism to assert functional extensional projections from the algorithm.  What I mean by this alternative is that the system could require the publisher to offer up, in their RFQ, the algorithm they intend to run, the input they intend to run it on, an extraction of (bounded?) portions of the algorithm that they intend to use for price shopping, and a generator function for a second set of input.  Doing it this way would be some awesome work, but would also be a bit of the-moon-on-a-stick probably.


O HAI!  Now I has FOUR ideas!

If we consider that an attacker can "change gate cost at will" he can also "game" your decomposition, right?  Woops.


As far as I can tell, paravirt boundary I/O cost and bursting semantics are not exercise-able as UVs.

As such this basically enforces that regardless of how you measure the circuit, your associated cost function will be incorrect, pragmatically.  Even parallel, these still break the linearity over any one measure, and add skew to the net pricing.

This is actually a huuuuuuuuge open problem in the HPC community.  Most of your "big player"s would kill for a way to model cost with parameters over IO quantification and bursting semantics.  Such a model would be worth a fortune, since it is the only place where they get slippage in their profit margin.  (Academically, there's probably a lot of application for related open problems with fair schedulers, etc.)

Solve this and you've got more than gold, you've got the future of computing.  I don't expect you to be able to solve this.


Yup.  Bad assumption number two.  Effed on the way in and the way back out.  It's got fail coming out both ends, so to speak.   ;D

As I said, I don't expect a solution applied here, as I understand that it is an unavoidable assumption without constraining the IO and bursting semantics of the worker.

I think it would be best to just go ahead and constrain the IO and bursting semantics of the worker, myself.


The canonical benchmarks define the rigidity of the system.  How are you going to execute your phoronix suite on my recombinant FPGA chip?  How is your canonical benchmark going to tell you anything about the performance of my nascent memristor array?  (I'm not even kidding, here.)

How do those benchmarks apply when this classical hardware of today gets swept under by the new computing models of tomorrow?  (It is already happening!)  It seems like the canonical benchmarks will need to be a moving target, and thus not very canonical.  ;)

As I see it, any actual solution to these problems will begin with either an authenticated circuit construction, or some measure of cost of alpha/beta reductions and pi/sigma type construction.  In other words you're going to have to start from something well behaved, like Turing's machine or Church-Rosser and Barendregt's cube, not from something "wild" like procfs under paravirt.

?!

This used to be true, but isn't anymore.  Recent advances have brought the tradtionally associated computational cost down significantly.


The problem is in lack of authentication not over the jobs themselves, but over the benchmark.  Combine this with a lack of association between the benchmark metrics and the job.

I understand that authentication and/or privacy preserving mechanism can be layered on top of the job.  This would just further distance the job's performance profile from what the benchmark metrics would imply.


Both contain significant amounts of what appears to be superseded information.  A cleanup of these materials is badly needed.


I mean that you summed up your bad assumptions so nicely that I pretty much didn't need to formulate the statements myself.

Your English is very good.

got it. if you call it multi-objective optimization, you just didn't understand the math. sorry.
go over "least squares" again.


It's not about the metric, it's about the information I have.
When I say procfs I mean any measurements that the OS gives you (we could get into the kernel level but that's not needed given my algo).


true. procfs doesn't have this linearity. that's exactly what my algo comes to fix.
but *any* n-dim vector can be written as a linear combination of n linearly independent vectors.
those latter n vectors are the unknowns (their number might be different than n, yet supported by the algo).
note that I never measure the UVs, nor give any approximation of them. I only estimate their product with a vector.


sure, wonderful works out there. we have different goals, different assumptions, different results, yet of course i can learn a lot from the cs literature, and i do some.
you claim my model is invalid but all you show till now is misunderstanding. once you get the picture you'll see the model is valid. i have a lot of patience and will explain more and more again and again.


sure. see my previous comment about normal distribution and mitigating such cases.


you're not even in the right direction. as above, of course procfs aren't linear. and of course they're still n-dim vectors no matter what.


that follows from the definition of the UVs you're looking for.
even though I wrote detailed doc, as any good math, you'll still have to use good imagination.
just think of what you're really looking for, and see that procfs is projected linearly from them. even the most nonlinear function is linear in some higher dimensional space. and there is no reason to assume that the dim of the UVs is infinite.. and we'd get along even if it was infinite.


why different circuit? the very same one. the provider tells the publisher what is their pricing, based on benchmarks. yes, it can be tampered, but it can be recognized soon, loss is negligible, reputation going down (the publisher won't work with this address again, and with the ID POW they can block users who generate many new addresses), and all other mechanisms mentioned on the docs.
on the same way, the publisher can tell how much they are willing to pay, in terms of these benchmarks. therefore both sides can negotiate over some known objective variables.


again, we're not measuring the UVs, but taking the best estimator to their inner product with another vector. this reduces the error (error at the final price calculation, not in the UVs which are not interesting for themselves) in order of magnitude.


Local history & ID POW as above


it is possible to take the algorithm which the publisher wants to run, and decompose its procfs measurements into linear combination of canonical benchmarks. that's another formula but it's very similar to the main algo. but such measurements will have some distribution of values and not fixed one per each job (even something standard like 1000 FFT take different time if you have more zeros on your data). that's one of the strengths of the system: it's fully customizable. you'll be able to insert arbitrary JS code to the client which contains your decisions regarding who to work with. of course, non-techs won't need to mess with this, but the system and the protocol are open for full customizability since there is no middleman between the two parties, while the product and the network will defenitely develop with time.


answered above


that's exactly what i'm saying. we don't care about bursts on such massive distributed apps.


as above, that's an open problem, which i'm happy i don't need to solve in zennet. that's why zennet is not adequate for really-real-time apps.
but it'll fold your protein amazingly fast.


as above


they are not called canonical from the historical point of view, but from the fact all participants at a given time know which benchmark you're talking about. it doesn't must be phoronix (but it's a great system to create new benchmarks). all the programs have to do is to make the HW work hard. if you have a new HW, we (or the community) will have to write a program that utilizes it in order to be able to trade its resources over zennet, and participants will have to adopt it as a canonical benchmark.

flexibility.

the last thing the system is, is "rigid".

will be glad to discuss it with you and maybe implement it on zennet


answered in post that posted after this

This is another case where the reply doesn't seem to match up to the critical statement.  My problem was not with any association between the price of a resource and the price of the coin.  The contradiction is in that you say the users set all of the pricing, but also say that the algorithm handles pricing determination for the users!  Either the users control the pricing or the system controls the pricing, but you seem to somehow want it both ways.


Sure, but it can't infer anything else as to why it is marginal.  I refer back to my notion of "why is there any reason to think a publisher will ever converge (or potentially be able to converge) on an optimal set of workers?"


Again, I see this is a problem in and of itself, not a useful solution.  At best it is a misguided mitigation.


It goes a little beyond this.  The jobs must not only be finished, but correct.


The problem is it is not "a PC for seconds" in anything but toy cases.  If I want one node, I really need at least two.  If I want 100 nodes I really need at least 200.  If I want 10000 I really need at least 20000.  This quickly becomes costly.

Unlike the problem of weeding out sub-optimal (but correct) workers, I can't just "drop the under-performing half" either.  I need to run each task to completion on each replica in order to compare results.

Really, I should expect to need much more than just a doubling of effort, as well.  My ability to infer correctness of the result increases asymptotically. I can be twice as confident with four workers per instance, and twice as confident as that with eight.

I can never fully infer correctness, regardless of how much I spend.

let's make some order:
1. market decides on how much $ worth 1 zencoin
2. users set the price for benchmarks
3. system translates procfs to zencoins using terms of benchmarks
4. users may set not only price but any arbitrary behavior in form of JS code given the zennet's envorinment variables.

number 3 may be tampered. and here you have all other means i mentioned.
the control on the price and logic is all the user's. the system just helps them translate procfs to zencoin.


yeah, i forgot to mention that Gauss also promised they're uncorrelated and with equal variances. so it's not marginal only. see gauss-markov theorem


it is a well guided mitigation. with parameters promised to normally distribute while being uncorrelated.



right, but correctness is a whole different story than alomst everything i talked about.
as for correctness:
1. as said, risk can be decreased exponentially with linearly growing investments
2. many problems are very easy to verify, so the investment is far from doubling itself. example for such problems are matrix inversion, eigenvalues problems, svd, al NP-Complete problems, numerically solving (mainly-time-dependent-)PDEs, root finding and many more.
3. also in real life, you don't have real promises, just probabilities
4. we both know that most of the users won't tamper the code, so the risk probability to lower even more, isn't so high at the first place. they have nothing to earn from miscomputation.

How is it not?  You have multiple candidates each with unique feature-sets and are trying to find a best fit subset of candidates along all feature dimensions.  Sounds like a textbook example to me!


...


Of course it is about the metric.  This metric is the only thing we have, so far.  ;)

The most relevant piece of information available, the job algorithm itself, gets ignored.  As long as this remains the case there is no meaningful association between the benchmark and the application.


Sure, but that doesn't magically make the measure linearly constrained.  You're still assuming that the measurements are actually done at all, which is a mistake.  We can't assume the semi-honest model for this step.  We have to assume the attacker just makes up whatever numbers he wants, here.


Er, of course you are measuring the UVs.  The performance of {xk} constitutes the measurement of all UVs, together.  Just because you measure them through indirect observation doesn't mean you aren't measuring them.  In any case I'm not sure what this has to do with anything?  (Or were you just stating this in case I had missed the implication?)


Your goals don't seem to align with market demands, your assumptions can't be safely assumed, and where they get great results I'm skeptical of what your results really are, let alone their merit.

This is the core of the problem.  If your coin were based on these established works that meet lofty goals under sound assumptions and show practical results, I'd have no trouble seeing the value proposition.  Since your coin is based on "known to fail" goals (which we'll just generally call the CPUShare model, for simplicity) and makes what appear to be some really bad assumptions, I don't expect comparable results.  Why should I?


Please do.


Again, mitigation is not solution.  You've claimed solutions, but still aren't presenting them.  (In this case I'm not even really sure that the assumption around the mitigation actually holds.  Gauss only assumes natural error, and not induced error.  Can we assume any particular distribution when an attacker can introduce skew at will?  ;))


And of course this doesn't magically repair our violated linearity constraint in any way, does it?  Maybe this is what I'm missing....?

Of course it seems that I will be somewhat "doomed" to be missing this, as filling that hole requires establishing a reduction from arbitrary rank N circuits to rank 1 circuits.  I'm pretty sure this is impossible, in general.


Being careful not to tread too far into the metaphysical I'll approach this delicately.  You are closest to seeing the root of this particular problem with this statement, I feel.

If I say being linear in a higher dimension does not resolve the violation of the linearity constraint in the lower dimension, would you agree?  If so, you must in turn admit that the linearity constraint is still violated.

It is fine to "patch over the hole" in this way if we can assume correctness of the higher dimensional representation.... unfortunately the attacker gets to construct both, and therein lies the rub.  He gets to break the linearity, and hide from us that he has even done so.

(This is precisely the premise for the attack I mentioned based on the "main assumption.")

If attackers can violate the linearity constraint at all, even if they can make it look like they haven't... well, they get to violate the constraint. :-)  I say again, linearity can not be enforced, only assumed.  (Well, without some crypto primitive "magic" involved, anyway.)


No, the benchmarks are canonical and are not the circuit representative of my job's algorithm.


Except they're subjective, not objective.  They're potentially even a total fantasy.  Worse yet, they have no real relation, in either case, to the transaction being negotiated.  


Again this is only true assuming a semi-honest model, which we can't, for reasons already enumerated. (Are you understanding, yet, that the critical failure of the model is not in any one of these problems, but in the combination?)


We're running in circles, now.  ID POW does nothing to filter spammers, only discourages them by effectively charging a small fee.  The post requires stamps and I still get plenty of junk mail.

Given that once one owns an identity one can get at least one issuance of some payment for no work, why would anyone bother running actual computations and building up a positive reputation instead of mining IDs to burn by not providing service?

The ID POW can only have any effect if the cost to generate an ID is significantly higher than the gain from burning it, the cost the publisher pays for utilizing the attacker's non-working worker.  In other words, it has to be enforced somewhere/somehow that the cost of an ID is more than the "first round" cost of a job.  I don't see how/where this can be enforced, but I'm not precluding it just yet.  If you would enforce this somehow, it would solve at least the "trust model in a vacuum" part of the problem by relating the value of the trust entity to the value of its resource.


Is it?  (In a way aside from my proposed functional extension mechanism, that also doesn't give the publisher some free ride?)
If so, this might be a useful approach.  If anything, this should be explored further and considered.



We do, because we can't price the distribution as a whole we can only price the individual instances.  The concern is not that one node does 1000/sec and another node does 1/sec, it is that the 1000/sec node might suddenly start doing 1/sec - and might even do so through neither malicious intent or any fault!


Or it'll tell you it is folding your protein, take your money, spit some garbage data at you (that probably even looks like a correct result, but is not) and then run off.

Or it tell you it can fold your protein really fast, take your money, actually fold your protein really slowly, and you'll have to walk away and start over instead of giving it more money to continue to be slow.

We can't know which it will do until we hand it our money and find out!  No refunds.  Caveat emptor!


Sure, my point is that the benchmarks are presented as "one size fits all" and they aren't.  It's ultimately the same problem as the benchmark having nothing to do with the job, in a way.  How are you going to maintain and distribute useful benchmarks for every new computing kit and model that comes out?  (At least that problem is not so bad as trying to maintain a benchmark for any job algorithm used.  There can be only finite technologies.  ;))

Further, how are you going to benchmark some nonlinear, progressive circuit "at all?"  How can you benchmark something that only does unsupervised classification learning?  How can you meaningfully benchmark a system with "online LTO" where the very act of running the benchmark will result in the worker re-configuring into a different performance profile, partly or totally invalidating your benchmark results? (Likely further separating the bench-marked performance profile from that of the eventual job, too!)


Being continuously re-coded and added to in order to support change does not really fit my definition of flexible.  That is kind of like saying a brick is flexible because you can stack more bricks on top of it.

before i answer in detail,
since you mentioned the coin,
let me just make sure that you noticed that the computational work has nothing to do with mining, coin generation, transaction approval etc., and it all happens only between two parties with no implications at all to any 3rd party, not to mention the whole network.

accumulated procfs readings are taking place every few seconds, then updating the micropayments transactions accordingly.
see my list in prev comments about miscalculations


note that measuring a vector vs measuring its inner product with another vector, is estimating 1 number vs estimating n numbers, while variance goes down by 1/n (since it's all normal, since my estimator's errors are normal, uncorrelated, and with zero mean, *even if the system is nonlinear and not-normal*)

as for mitigation, that's the very part of zennet's solution. we come from a recognition that we can't promise 100% and we don't need to promise 100%, cause all you have in real life is probabilities.

I fully understand this.  It is not relevant.

Again this comment doesn't match up.  The attacker can just as well lie every few seconds.


Sure, an attacker can only slope the vector normal, not outright violate the normality constraint.  This says nothing of the violation of the linear assumption, though?


Cool, so now you are starting to accept and admit that you actually do not offer solution.  I consider this progress!  Now the challenge will just be in getting you to try for some solutions instead of just making a fancy new CPUShare. XD

yeah but then he'll get blocked, and if ID POW is in use by the publisher, it'll be difficult for him to cheat again.

an attacker can do *anything* to the measurements. but the mitigation makes the expectation of the risk negligible. at least on wide enough cases.
the linear estimator gives me normally distributed errors so i can easily identify outliers. this property exists thanks to the linear estimator, and does not depend on the UVs linearity assumption (which, and partially answering a question you raised, is more accurately "low-enough-dimension assumption"). how low is low enough? order of magnitude of the number of different benchmarks i can afford to run.


and again: i'm not looking for the kind of solution you're looking for. i'm looking for a working solution, which from economic (and performance!!) point of view, is preferred over existing alternatives. it doesnt necessarily have to be cryptographically proven work etc.

Is this like the Amazon service where you can rent processing power, but on the blockchain instead?

it is a free market alternative to AWS aimed for massive computations. it consists also from blockchain technology.

I misquoted a comment so I deleted it and writing again:


now if i get to explain you this, i think you'll understand much more of the broader picture.

that's trivial! let me convince you that's trivial:

i have a program which i want to decompose into a linear combination of benchmarks w.r.t. procfs measurements (abbrev. msmts).

i.e., i want to describe the vector x of procfs msmts of a given program as a linear combination of procfs msmts vectors of another n programs.

assume the dimension of the vectors is k.

all i need to do is have n>=k and have the matrix having n rows which are our vectors be of rank k.
i will get it for almost surely if i just pick programs "different enough", or even if they're just "a bit different", i may increase n.


of course, only small tasks are considered.

very easy: each client picks any amount of ID POW to require from its parties.

it's not about "one size fits all". it's about describing how much has to be invested in a job. like saying "each task of mine is as about 1000 fft of random numbers" or a linear combination of many such tasks.
again, such task decomposition is not mandatory, only the ongoing procfs msmts
another crucial point is that we don't have to have accurate benchmarks at all. just many of them, as different as possible.


it is *able* to be customized and coded, hence flexible.
it has to be done only for totally new creatures of hardware.

Precisely the contradiction, restated yet again.  "Translate procfs to zencoin" is the exact same problem as "price procfs" so this statement is precisely restated as "The control on the price is the user's. The system just helps them by doing pricing."

We collectively decide what the coin is worth.  A user decides how many coins one "proc unit" is worth.  The system decides how many "proc units" one execution is worth.

The system has priced the resource, not the user.  The user priced the token in which that resource pricing is denominated, and the market priced the token in which that token is denominated, but the resource itself was valuated systematically by some code, not by the user or the broader market.

(Or do you only consider things priced if they are priced denominated in fiat dollars?   ???)


My last reply to this still stands, Gauss was "wrong" about our model since he wasn't considering intentionally introduced fault.  Gauss-Markov (which I love, being ML guy) ends up being double wrong, because the Markov side of things assumes the errors are uncorrelated.  An attacker introducing error may certainly introduce correlated error, and may even have reason to explicitly do so!  ;)


I'm becoming really quite convinced that where you've "gone all wrong" is in this repeated assumption of semi-honest participation.

Much of what you're saying, but particularly this, simply doesn't hold in the explicit presence of an attacker.


Sure, but again I suspect that most useful jobs will not be "pure" and so will not fall into any of these.


The one exception to this, of course, being formal proof.  We can actually offer real promises, and this is the even central to the "seemingly magic" novelty of bitcoin and altcoins.  Bitcoin really does promise that no-one successfully double spends with any probability as long as hashing is not excessively centralized and the receiver waits an appropriate number of confirms.  (Both seemingly reasonable assumptions.)

Why you're so readily eschewing approaches that can offer any real promises, even go so far as to deny they exist "in real life," despite our Bitcoin itself being a great counterexample, is confusing to me.


I assume most users will be rational and will do whatever maximizes their own profit.

I actually go a bit further to assume that users will actually behave irrationally (at their own expense) if necessary to maximize their own profit.  (There's some fun modal logic!)

(I further have always suspected this is the root cause behind the failure of many corporations.)


This caries a similar flavor as your HPC giants being motivated to turn in your bugs for your 1BTC bounty.

Miners have everything to earn from violating correctness.

If I can sell you on some resource contract, deliver some alternate and cheaper resource, and have you walk away none the wiser, I profit.

If I can sell you on some resource contract, convince you to make a deposit, and then abscond with almost no cost, I profit.

If I can sell you on some resource contract, actually perform the work and get paid, then turn around and sell your data and software to the highest bidder, I profit.

People *will* do these things at any given opportunity, and people will use any *other* vulnerability of the system to carry out these practices.  Even if you do everything possible to mitigate these concerns, it will all come down to people bulk mining identities to burn.

How exactly is this not just like CPUShare again, and why exactly shouldn't we expect it to fail for the exact same reasons, again?

man stop mixing miscalculation with procfs spoofing

I still don't see how the n programs have any assumable relation to the program that I'm actually trying to get quoted.  How is the behavior of any of the runs of the n programs indicative of anything about my future run of my job?  How is what is being priced over serving to price the thing that I want priced?

Eeep, it just keeps getting more scary!  :D

Who decides how much work is sufficient?  How does any given publisher have any indication about any given providers ability to perform the identity work?

There kind of has to be some continual consensus on a difficulty here, doesn't there?

 ???  If benchmarks don't have to be accurate than why do them at all?


By this measure all software is flexible.  Of course you must have known what I meant, here, as a measure of flexibility relative to alternatives.


Totally new creatures of hardware show up every day.  Anyway this is neither here nor there.  I said I wasn't going to hold my breath on that result, and I didn't.  We can move on from it without prejudice.  :)

at least we now understand who influences who, and that the user may change his numbers at any time with or without looking at the market. hence no contradiction or something like that. you may argue about terminology.


draw me a detailed scenario for a publisher hiring say 10K nodes and lets see where it fails


in theory. in practice, power can shut down and so on. probability for a computer to give you a correct answer is never really 1. how much uptime AWS guarantee? i think 99.999%


since after the convergence of the network toward more-or-less stable market, spammers and scammers will earn so little. they'd rather do decent work and get paid more. even if they don't, other mentioned mitigations are taking place.


i totally agree. i do not agree that the network is not able to mitigate them and converge to reasonable values. since the costs are so lower than big cloud firm operational costs, we have a large margin to allow some considerable financial risk.


let me mention that i know nothing about cpushare so i can't refer this question

Man stop thinking they are not exactly the same thing.   ;)

If you can get over that hangup I think we can make better progress.

The attacker's arbitrary control over the execution, without being held to any scrutiny of authentication, is the same problem regardless of if we are looking at the implications to the pricing or the implications to the execution itself.

The attacker recomposing the execution context is the same behavior in either case.  This is the good ol' red/blue pill problems, just reiterated under a utility function and cost model.

forget about probrams.
think of arbitrary vectors.
every k-dim vector can be written as a linear combination of k linearly independent vectors.
you can take much more vectors, and increasing the probability that they'll contain k independent ones.
if the benchmarks are different, k will be enough. but the more the better.

won't you agree that detecting miscalculation and detecting procfs spoofing are two different things?
maybe there is a similarity if our goal is to eliminate them both.
but all we want is to decrease the risk expectation.

it's not like btc difficulty, where all the network has to agree. it's only local. each participant may choose their own value.

that's the very point: i dont need accurate benchmarks. i just need them to be different and to keep the system busy. that's all!! then i get my data from reading procfs of the benchmark's running. if you understand the linear independence point, you'll understand this.


oh well
so you know how to write software that applies to all future hw?

as i wrote, i'll be glad to discuss with you methods for proving computation. not even discuss but maybe even work on it.

I don't disagree with any of this except the notion that it is acceptable to forget about programs.   ;)

What you propose is fine other than the fact that there is no relation between the end result and the program that you conveniently want to just "forget about."

(Such a relation is not easily established, generally.  Functional extension is hard.  Proving lack of divergence in the general case is even known to be impossible.  However, you can't just "punt" like this, forgetting about programs, and assume everything else will just work out soundly.)

it's true for ANY vectors. calling them "procfs msmts" doesnt change the picture.
i can linearly span the last 100 chars you just typed on your pc by using say 200 weather readings each from 200 different cities.
of course, only once, otherwise the variance will be too high to make it somehow informative.
but for a given program, the variance over several runnings is negligible (and in any case can be calculated, and taken into account on the least squares algo).

also note that those UVs are actually "atomic operations".
running one FLOP requires X atomic operations of various types.
we just add their amounts linearly!
but summing consequent FLOPS will end up correlated.

No!  This is central to my point.  Authentication is authentication, and anything else is not.

(Authentication encompasses both concerns.)


There is more than a similarity, there is a total equivalence.  To assume they are in any way different is a mistake.  They both just constitute a change in reduction semantics within the execution context.


I am actually interested in a goal of eliminating both, of course.

However, all I really want is at least a rational explanation of where risk expectation is decreased, assuming rational behavior (and not assuming honest or even semi-honest behavior of participants beyond what is enforced by blockchain semantics) by participants.

It still seems to me like rational behavior of participants is to default to attack, and it seems that they have little discouraging them from doing so.

By what criteria? As a publisher, how should I estimate what a sufficient difficulty should be to counter incentive for absconding at some point, considering I can't know the capacity of the worker?

again, all matter of approximations and probabilities.

it is clear that:
1. you want the computational work to be proven
2. i want to control the risk expectation and decrease it to practical values

i claim that your method is less practical, but i'm open to hear more.
you claim that my method won't work.
now let's focus on either ways:
if we want to talk about my approach, then miscalc and procfs spoof are indeed different.

 ??? Another response that didn't match the statement.  How is the system not doing the pricing?  If you think the market is doing the pricing, this would imply that the pricing only occurs at the fiat denomination.  I don't think this is a notion that would be well accepted.  If you think the user is doing the pricing, why?  How does the user setting the relation between the procfs token and the coin token say anything abut the valuation of the actual computation, which is denominated in that procfs token?  I would hope you do understand the difference between valuation and denomination.


I've already detailed where it can fail.  This is all I've been doing for hours now.


Eh, I'm going to avoid getting back into this discussion for the hundredth-or-so time.  The whole model of bitcoin *doesn't* actually fall over when the EMPs go off.  The theory remains just as sound.  The protocol can still be enacted, and work, albeit probably with adjusted parameters that account for the (massively) increased network latency caused by lack of electronic communication.

Bitcoin would've literally solved the actual Byzantine Generals' problem, even at the time!


It is when the process the computer employs to derive that answer is proof carrying!  Either you get out the correct answer or you get no output at all.


How much uptime does bitcoin guarantee? 100%.  Anti-fragile and all that jazz.  It really is deterministic "immortal" modulo the 51% attack or some hypothetical eventual exhaustion of the hash space.

Six sigma has it all wrong.  We should be building systems that are "forever."  (Particularly being "Bitcoiners.")


Again, why do we think this model will converge in such a direction?  What makes them actually "earn so little?"  What is going to prompt the network participants to behave altruistically when they have both incentive and opportunity not to?


I never said that I don't think it could.  In fact I explicitly stated the opposite several times.  What I'm saying here is that your network, as described so far, doesn't even seem to mitigate correctly.


Eh?  How can we know the relative cost a priori?  Why shouldn't we believe the cost of this service will actually average higher, given the need for excess redundancy etc.  We've already brought into the discussion the notion that people might even just re-sell AWS, and they certainly wouldn't do so at a loss.

I don't think you've made a safe assumption on this.


I'll rephrase.  How exactly is this not reiterative of any other attempts at a p2p resource market, which have all failed?

They've all failed for the same reasons I'm assuming your model fails, btw.  No authentication over quote or work.  Inadequately constrained execution context.  Disassociated cost models.  Providers absconding mid-computation.  Providers attacking each-other and the network for any possible advantage.  Providers burning through identities to perpetuate their unfair trades. Requirement for substantial overheads in any attempts at "mitigation" of these problems.

Those who do not learn from history, they say, are doomed.

More "and then some magic happens."

So a provider who makes some technological leap in solving the puzzle gets to violate the constraint at will until the network just "wisens up on it's own?"  By what means should it become wise to the fact?

If you remove the difficulty scale it can't really be called PoW anymore, since it no longer manages to prove anything.  The "hash lottery" has to be kept relatively fair by some explicit mechanism, or else anyone who finds a way to buy their "hash tickets" very cheaply breaks any assumption of fairness otherwise!

Ideally, yes.


As I've said I'd accept this as compromise, but have yet to see the mechanic by which it is decreased to practical values.


Excellent.  Why, specifically, do you claim that my method is less practical?  Also what, specifically, would you like to hear more about?


I only claim that they "shouldn't work, as described."


GAH how are they at all different? :-)

In either case the attacker claims to execute one reduction but actually executes another related reduction.  Where is the difference?  Either I am executing a different algorithm than specified for the job itself (miscalc) or I am executing a different algorithm than specified for the consumption sampling (procfs spoof) but either way I'm doing the same thing - a different reduction from what the publisher thinks I am doing.

Again, I don't disagree, but how does any of this have any bearing on "my arbitrary program?"  How do you get around the lack of functional extension?  How do you make the vectors, in any way, relate back to the job program?

Wha?  I guess I don't understand the linear independence point. Oh, wait, I already knew that I didn't understand that.  ;)

If the benchmarks don't need to be accurate then why are they in the model at all?  If everyone can just reply 3.141 for every benchmark result and that is somehow "just ok" then what purpose does the benchmark serve?

My only conclusion is that it isn't actually "just ok."


Sure, that is precisely what the full lambda cube is for!

What I don't know how to do is devise any scheme to meaningfully benchmark all future hw.  You briefly claimed you had.  I didn't hold my breath.  Good thing.

 I have this marked for reading later.

what you say point to many misunderstandings of what i said. i dont blame you. the higher probability is me not being clear enough, plus i do have a language barrier when it comes to english:

1. those benchmarks has nothing to do with benchmarking. i don't even read their result. it's just i need programs that extensively use various system components, and such programs i'll typically find under the shelve of "benchmarks". but that's all.

1.1 the info i do gather from the benchmark running is the procfs readings of the running itself.

1.2 now let's go on with the simple case (on the pdf it's where s=t1), when the user just sets one number: "i want 1 zencoin for every hour of full load". so the client will blow his pc with "benchmarks", take procfs measurements, and compute the pricing vector. call this latter vector g. this vector plays the main role.

1.3 at every few seconds, the client takes procfs measurements vector. this is a vector of n components. the first component is CPU User Time. the second is CPU Kernel time. the third is RAM Sequential Bytes Read, and so on many procfs vars. then we take the inner product of g with the procfs msmts vector, and that's the amount to be paid.

1.4 the location of the vars as components in the vector also answers your misunderstanding regarding the decomposition of a procfs msmts of a given program to a linear combination of procfs msmts of k>>n programs.

2. all the publisher wants is to fold his protein in 10 minutes over zennet rather than 2 weeks in the univerty's lab. he does not need uptime guarantees such as bitcoin. even if he's folding various proteins 24/7.

3. as for the id pow, just common sense. one estimates a confidence bound of the reward of a spoof/spam/scam and determines a POW which is significantly more expensive that it.


4. they're equivalent from the attacker's/provider's point of view, but not from the publisher's one who wants to detect them, as i stated.

5. what do you mean by functional extension? like feature mapping, rkhs etc.?

6. you're both a scientist and an engineer, right? but when you wrote it, you were only a scientist. we'll get back to this point ;)

7. the methods i've encountered in the literature were seemed to me less practical. i do not rule out that you found or read about good enough methods. and of course i'd like to hear more about such technologies, and even more than hear, depends on the specific ideas.

more answers to give but let's first establish a wider basis of agreement and understanding.

I'm not sure there is much to work on.  Just replace the VM with something authenticating, and that's that, right?  There's a good list of options at http://outsourcedbits.org/coding-list/ covering everything from basic two-party garbling (you don't need more then two) to full multi-party morphisms.

There is also the work of SCIPR labs, but nothing so "drop in" yet.  I hear M$ and IBM both have some really nice tech for it, too, but I doubt they'd share.

One of the other folks who fits in my small elevator is Socrates1024, aka AMiller.  He has something I've come to call "Miller's Merkle Trees" which he calls generalized authenticated data structures.  This work started from his now-infamous model to reduce block chain bloat.  He has recently extended this into a reduction model for general authenticated computing without requiring Yao's garbling step and the overhead that comes with the logic table rewrite.  Verification happens in reduced complexity from the prover challenge itself.  This seems almost perfectly suited to your goals.  I'm sure he'd love to see practical application, and almost everything you'd need is in his github in "some form" or another, hehe.

Many of us have suspected for some time now that there is some middle ground between the approaches, with a preservation of privacy over data but not over the circuit construction itself and without the overheads of it.  I tend to believe this is probably the case, but as far as I'm aware it is still an open question.

I'm probably not the best to explain, since I'm only standing on the shoulders of the giants with this stuff.  You probably want to talk to the giants directly.  ;)  I can try to make a few introductions if you'd like.

thanks much for the info. will go over it.
will be delighted for introductions, of course. also if you want to be a part of zennet, let's consider it

after a quick look on the link:
1. recall that on zennet we speak about native code only. no jvms or so.
2. data privacy is nice to have. much of the data is not private (just numbers), and on any case, homeomorphic encryptions etc. can take place over zennet using the any existing implementation. all zennet does is giving you ssh. if your verification tool gives you suspicious info, then just disconnect. that's part of your distributed app, which i do nothing to help you distribute it, rather than giving you passwordless ssh access to remote machines.
3. we're speaking about arbitrary native code (rules out projects for specific calcs). verifiable calcs are well and economically mitigated, as above.
but that's only after a quick look

Sure, this is what I meant by the output/result of the benchmarking.  No confusion there.


The procfs measurements in 1.2 and in 1.3 are entirely unrelated.  The load that any given benchmarking algorithm, B, puts on the system will not be representative of the load the job algorithm, P, puts on the system.  No combination of any algorithms B2, B3, ... BN will decompose onto a meaningful relation with P's load.  This is the fundamental problem.  No measurement of any other algorithm tells us anything about P unless that algorithm is isomorphic to P.  Even then it doesn't tell us anything about our particular run of P, the performance profile of which will likely be dominated by external factors.


?

Other than the well ordering making the subsequent decomposition consistent with the original g vector, I fail to see how it relates.  Is there something more and special to this?


Sure, I've never disputed this, nor do I see it as any problem.  (With the exception of the absconder cases, which I consider a separate concern anyway.)  You brought in uptimes into the discussion, in an unrelated context.  Let's move on.


But how do they make the determination?  How am I supposed to pick a target without knowing anything about any participants capacity?  How can I have any reason the believe that my target is not way too low, creating no incentive not to abscond.  I can just set the target unreasonably high, but then I significantly reduce my possible workers.

How can we say the puzzle is sufficiently difficult if we can't quantify difficulty?


Only in that, without authentication, they have separate mitigation to the fact that they are not actually detectable.  (Even this is arguable, as in both cases mitigation can only really be performed by way of comparison to a third party result!)


I mean http://ncatlab.org/nlab/show/function+extensionality as in proving two algorithms equivalent, or proving a morphism path as continuous from one to the other under homotopy.  If you can't show that the benchmark work is a functional extension from the job work than any measurements over the benchmark work have no relation to the job work.  In other words, if you can't assert any relation between the algorithms then you can't assert any relation between the workloads of executing the algorithms!


I've been both, at various points.  I try to avoid ever being both simultaneously, I find it tends to just cause problems.



Until the past few years, they have been almost entirely impractical.  Times have changed rapidly, here.


It concerns me that you wouldn't have been aware of these developments, considering the market you're about to try to penetrate.  Know your competition, and all that.


I've sent you a PM wrt this.


Sure.  Which of our disagreements and/or misunderstandings should we focus on?

Then what you want, certainly, is Miller's work, and not Yao.

I'd consider it.  However demands on my time are already pretty extreme.   :-\

it agrees with the ordering of all procfs measurements vectors.
say it's a two dimensional vector: [<UserTime>, <KernelTime>], like [5,3.6].
now say I run your small task with various inputs many times. I get some average vector of procfs, of the form [<UserTime>, <KernelTime>], plus some noise with some variance.
this vector can be written as a*[<B1.UserTime>, <B1.KernelTime>]+b*[<B2.UserTime>, <B2.KernelTime>] plus some noises with covariances.
of course, this is only if B1.UserTime*B2.KernelTime-B1.KernelTime*B2.UserTime does not equal zero (this is just the determinant). if it's zero, we need B3, B4 and so on until we get rank 2.
this is how to decompose a procfs vector of a program into of several given (rank-n) procfs vector programs.


i did that research, just didn't find something good enough. the best i found involved transmitting vm snapshots.
no human being is able to read all papers regarding distributed computing.


just dont give too much work to a single provider. that's a good practice for many reasons.
in addition, begin slowly. hash some strings, see you get correct answers etc., fell your provider before massive computation (all automatically of course).

Right, so the ordering only matters to keep the decomposition consistent with the g values, not more. This is what I suspected.


I'm just quite surprised you didn't catch it.  The service industry has been "abuzz" about the post-Gentry work.


This doesn't answer the question at all.  There really does need to be a global difficulty, as far as I can tell.  I've been mulling this one over for awhile now, and just don't see a way around it.  For an arbitrary worker, I can't know if he is doing his id pow with cpu, gpu, pen and paper, asic, pocket calculator, or some super specialized super efficient worker that outperforms all the rest.  What is an appropriate difficulty target to set on his puzzle?

true, they're unrelated.
as for load decomposition,
why on earth the programs should be identical/homomorphic/isomorphic?
programs that performs 1000 FLOPs will take about 1/2 than programs that perform 2000 similar FLOPs, even if they're two entirely different algos. i'm not counting on that anywhere, just pointing to the fact that i'm apparently not interested at all in such functional equivalence.
how any kind of such equivalence is related to resource consumption?

again, how come you tie so closely between workloads and specific algo's operation?
maybe it's needed for proven comps, but for my approach estimating consumption and risk reducing?


?

Other than the well ordering making the subsequent decomposition consistent with the original g vector, I fail to see how it relates.  Is there something more and special to this?
[/quote]
where are we stuck on agreeing over the procfs vector decomposition?
maybe you're looking for something deep like functional extension, but those vectors can be spanned by almost any enough random vectors. like all vectors.

I still don't understand which flaw you claim have found.
You claim that people will just create many addresses, make jobs for a few seconds, and this way fool the whole world and get rich until zennet is doomed?
So many mechanisms were offered to prevent this. Such as:
1. Easy outlier detection cause of [large population and] normal estimators.
2. Keeping local history and building a list of trusted addresses, by exposuring yourself to risk slowly, not counting on an address fully right from the first second.
3. You can always ask it to hash something and verify the result! Moreover, you can spend the your first new seconds with your new provider with just proving his work. Yes, they can became malicious a moment after, but: you'll find out pretty quickly and never work with that address, while requiring more POW than this address has.
4. i'll be glad of a detailed scenario of an attacker trying to earn. i dont claim he won't make a penny. but show me how he'll make more than a penny a day. Can you pinpoint the problem? for miscalc and procfs spoofing, we may assume we dont have the fancy pricing model, and we can discuss it as we were pricing according to raw procfs.

Super interesting conversation between ohad and HMC   :)

First, homomorphism is an entirely seperate thing. I only want the isomorphism.

Second, they "should" be isomorphic because the performance profile of any given algorithm has to be assumed as potentially unique to that algorithm.  No benchmark you could throw at the system will necessarily "load" that system in the same way(s) that my program P will "load" that system.  What we ultimately want to get to is a measure of "how hard is the system working on P" and we can't formulate this beginning from some baseline that has nothing to do with P!


Sure, but this reasoning is only really valid if we look at a single measure in isolation - which is not what we intend, per your decomposition!  If we run your benchmarks and generate our g values across all metrics, and then use a spin loop for P, we will see 100% processor usage, but no other load.  Does this mean that we are loading the system with 100% of "P work?"  YES, but your model will initially decide that the usage is actually lower!


If we can formulate our g in relation to P then our measures relate, too.  If we take our g measure using a variety of spin loops (potentially "extended" from P in some way) and then perform our decomposition against our P spin loop your decomposition will "know" from g that the only meaningful dimension of the performance profile is the cpu, and will correctly measure P as loading the system to 100%.

Obviously this is a contrived example to illustrate the point, no-one will want to pay to run a busy loop P.  However taking the point to an extreme like this makes it simple to illustrate.


Because every algorithm combined with a particular reduction of that algorithm has a unique performance profile criteria!  A performance is unique to a particular run.  We can never know how our particular run will behave, but we can't measure it against the baseline of some other algorithm(s) in a meaningful way.  Disk usage or page faults or etc in our benchmarks have NO bearing on our measure of our busy loop P!


It is necessary in either case to derive meaningful measure in the decomposition.

Also, this notion should actually be turned the other way round - proven comps should be considered needed for estimating consumption, as AMiller pointed out on IRC.

" 12:21 < amiller> imo it's not a bad idea to have some pricing structure like that, i'm not sure whether it's novel or not, i feel like the biggest challenge (the one that draws all my attention) is how to verify that the resources used are actually used, and this doens't address that" [SIC]



The problem is that such a span is not meaningful relative to subsequent measure unless some functional extension exists.  Unless our benchmarks are "similar" to our P busy loop, they only introduce noise to our decomposition of our measures over P.



Again, I'm assuming most computations will not have referential transparency, will not be pure, precluding this.


Again, I'd rather find solutions than defer to (potentially costly) mitigation.


Among other behaviors.  I basically assume that people will do "all the same crap they did with CPUShare et al that made those endeavors fail miserably."


Except as offered, they don't prevent anything at all.  They presume to probabilistic avoid the concern, except that there is no formalism, yet, around why we should believe they will serve to avoid any of them to any reasonable probable degree.  Again, I defer to AMiller who always puts things so much better than I ever could:

"12:25 < amiller> there are no assumptions stated there that have anything to do with failure probability, malicious/greedy hosts, etc. that would let you talk about risk and expectation"


Again, how is the challenge difficulty to be set?  This is still unanswered!


How much he stands to make largely depends on his motive and behavior.  Some attackers might make 0 illegitimate profit, but prevent anyone *else* from being able to accept jobs, for example.  Some attackers might burn addresses, and just make whatever "deposit" payments he can take.  Some attackers might fake their computation, and make the difference in energy cost between his fake work and the legitimate work.  Whether or not he'll make more than a penny a day depends on how capable his approach is, how naive/lax his victims are, and how much traction the network itself has gained.

My concern is not that some attacker will get rich, my concern is that the attackers leeching their "pennies a day" will preclude the network from being able to gain any traction at all, and will send it the way of CPUShare et al.

It is very important to remember that, for some attackers, a dollar a day would be a fortune.  Starving people are starving.  Some of those starving people are smart and own computers, too.


The root of the problem is just the combination of everything I've already described.  ;)  It is all predicated from lack of authentication over the g values, and made worse by the lack of cost for identity.

But the big question: Who is wrong?  ;)

Is there anyone out there in internetland who wants to jump in with a new perspective?

Easily: requirind ID POW is like requiring your BTC pubkey to begin with a certain amount of zeros.
When I connect to you, I give you some challange to sign with your privkey, to make sure you own that pubkey with tons of POW.
So with this approach, "good people" will use one addr and not gen new one every time, both for the id pow, and for keeping history with good name on the publisher's local data.

As for AMiller's, see the following chat (he didn't answer yet):

amiller:
so the conditions for gauss markov theorem are weaker than IID, but they're still have to be independent and the distributions have to have the same variance
i don't know what you mean by as for lying, connected to actual outcome
if many other nodes perform the same job,
then you have to assume that those nodes failing are all independent
but on the other hand if *all* the nodes know they can cheat and get away with it, they might all cheat
so it's not justified to assume that the probability of any individual node cheating is uncorrelated with any of the others
this is kind of the difference between adversarial reasoning and, i dunno what to call the alternative, "optimistic" reasoning

me: the issue you raise is simpler than the linear model: say i have 10^9 work items to distribute. i begin dividing them among client. after one job is done by a worker (the smaller job, the better) i can tell if they cheated or not, or, i can tell how much they charged me for that work item. if i don't like the numbers i see, i can always disconnect. it will all happen automatically, by the publisher specifying their prices and margins.
the publisher may also begin slowly, giving at the beginning some hashing commands just to see the correct result. they won't pay more for working slow. they pay according to stationary resource consumptions.

The main point is that the exposure is short (few secs), while the publisher can perform any risk-decreasing behavior. Even running a small background task just for sanity verification. Of course, the attacker can modify rare random calculations, and lowering this risk (the miscalc risk) can be done at either:
1. have an easily proven jobs. you claim that they are rare cause of impurity. I claim that for many if not most common problems, one can formalize them and pick a method of solution that'd be distributed and with main massive pure task such as huge eigenvalue problem.
2. increase the number of times each work item is calculated (exp. decrease risk)
3. selected known or trusted providers.
4. require high ID POW, so high such that there is no incentive to lose it, just for the price of a few seconds of calculations.

note again: even if the provider has computing monsters, the publisher doesn't must use all resources. he can run, at first, simple cheap tasks. so the potentially lost several seconds can contain minimal amount of work to be paid.
-- this latter solution of course does not really help you identify scammers, but it does help you slowly gain experience with the good guys.
will be back later with more answers.

How do we know what constitutes "tons" for any given puzzle solver?!?!?!?!  Without a global difficulty how do we know what is sufficiently difficult?  How do we know that our "tons" is not too little to fail to avoid the scammers and not too much to disqualify the non-scammers?  How should we pick an number that we can be confident falls in the middle, here, without knowing anything about the worker and how he will perform his hashing?


How do we know how high is high enough?  How do we know how high is too high?  How do we pick the target?  You keep dodging this question, somehow.  ;)

I'll let AMiller respond to the rest, since it is intended for him.  I don't want to interject there and just muddy things further.  ;D

I have the expertise to jump right in, but your discussion has got too long. Is it possible to summarize the points of dispute so other people can join ?

I like the idea, but I'm getting paranoid about the QoS and the verifiability of pieces of work. Also I don't get the need for introduction of a new currency. I'm sure you've discussed these as I've read the first 5/6 posts, but couldn't quite follow you guys.

Hi,

Our discussion follows two main approaches:
1. Verifiable computing, and
2. Risk reduction

Zennet does not aim to verify the correctness if the computation, but offer risk reducing and controlling mechanisms. HMC's opinion is that we should stick to path 1, towards verifiable computing, and we're discussing this option also off this board. HMC also suggests that Zennet's risk reduction model is incorrect, and gives scammers an opportunity to ruin the network. I disagree.
I think that'd be enough for you to read only the last comments, since many of them are only clarifications, so you can get right into the clear ones :)
More information about Zennet at http://zennet.sc/about, and more details on the math part of the pricing algo available here http://zennet.sc/zennetpricing.pdf

I'll try, but the key points have been shifting a bit rapidly.  (I consider this a good thing, progress.)

Socrates1024 jumping in moved the goal posts a bit, too, in ways that are probably not obvious from the thread, now.  :-\

Perhaps we need that dedicated IRC channel sooner?

1. Identity.  We agree that a PoW mining to claim identity should be used.  I say that identity should be pre-claimed, based on a global difficulty target.  Ohad says that identity should be claimed when the worker client connects to the publisher for initiation, with an arbitrary target set by the publisher.
  My key concern: Publisher has no way to know what an appropriate difficulty should be set at for any given worker.

2. Verification of execution.  We agree that it would be ideal to have authenticated processes, where the publisher can verify that the worker is well behaved.  Ohad says there doesn't need to be any, and the cost of any approach would be too high.  I say the cost can be made low and that there is a likely critical need.
  My key concern: Without a verification over at least some aspects of the job work the publisher can have far too little faith in the results of any one computation, and particularly in the results of a combination of computations.  In particular, lack of verification may lead to rational collusion by workers and added incentive to attack each-other.

3. System benchmarking.  We agree that it would be ideal to have an appropriate system resource model presented to publishers, on which to make their determination about how dispatch and price their work.  I say the benchmark must represent that same algorithm to take baseline measurements.  Ohad says the baseline can be established with any algorithm.
  My key concern:  Many attacks based on a combined "gaming" of benchmarks and work performance might be possible if the benchmarks are not representative of the actual work to be performed.

4. Pricing mechanism.  We agree that the presented linear decomposition utility pricing objective is probably "just about right."  Ohad says his approach is entirely sound.  I say that the overall model leads to an opportunity, particularly because of prior points taken in conjunction, for an attacker to introduce relevant non-linearity by lying about results.
  My key concern: the fundamental assumption of the system, which ends up "joining together" the entire economic model, actually ends up working in reverse of what was intended, ultimately giving particular incentive to the "sell side" worker side participants to misrepresent their resources and process.

Did I miss any of the major issues?


I also like the idea, but even if the model is fixed it still has some dangerous flaws "as given."  It will be a prime target for hackers, data theft, espionage, and even just general "griefing" by some participants.  In some respects, this is easily resolved, but in other respects it may become very difficult and/or costly.  This will, in any case, have to be a bit of a "wait and see" situation.

I do agree, that's just misunderstanding. I meant that when the client connects, the publisher can't know which address this ip owns, unless they challange it with some string to sign.
Yes, the POW should be invested as identity creation. Like in Keyhotee project.

if we go on the new idea of "slim" paravirt provability, we might prove the running of the benchmarks themselves.

Yes, but these are related-but-distinct concerns.  Related because of #4 there.  Distinct because even with authentication to verify the correct benchmarks are run I still see a potential problem if we lack that "functional extension" from the benchmark to the job itself.  Our baseline would still be the wrong baseline, we'd just have a proof of it being the correct wrong baseline, heh.

I do agree too and seems like it was a misunderstanding based on Ohad's post.


Many processes don't have the properties necessary to be authenticated. For example, you can verify the work of a miner by a simple hash function, but you can't verify the work of a neural network that simply. If the publisher has 1000 hosts on his VM, and wants to verify their works one by one, it would take a lot of computational power on his side. Also, I assume by 'work' we don't mean running a mathematical operation across hosts. I don't know the infrastructure for the VM, but the system may assume all hosts are online and cooperating in a non-malicious way, so it can build and operate an entire OS across them. If one host acts maliciously, it would endanger the integrity of the whole VM. In this perspective, assuming 1 in a 1000 defective host endangers the entire system, not just 1/1000 of work.


I agree with HMC here. Any kind of benchmarking used must be run alongside the process. Any host can benchmark high and detach resources after the process has begun. The host can even do this by the network itself. Consider renting 1000 hosts to just benchmark high for a publisher and then release them. So, you either have to benchmark and process at the same time, decreasing the effective resources available, or your work supplied must be 'benchmarkable' itself. In the perspective I introduced in the last question, this does not necessarily mean every publisher should change his work, but would mean running an OS across hosts that can effectively calculate the help of each host in terms of resources. This may introduce another problem aside, any open source OS selected must be heavily changed.


I think if point 3 and 2 are solved, this won't rise. If we can identify well behaved nodes that give verifiable results with verifiable resources used, this incentive wouldn't exist. Any pricing model based on this would be sound.

Here is an interesting blog post about the project

http://data-science-radio.com/is-zennet-or-any-other-decentralized-computing-real/

Interesting article. I disagree with the premise that "Most" DC users need that level of security for their proprietary tasks. The need for such massive computational power is in itself a determent to theft as the use of the resulting data is specialized to the entity seeking it.

we just cleared another misunderstanding (off-board), whether the mentioned contract is some futuristic promise (no) or just the agreed rate per cpu/disk/mem etc. (yes). this brought a confusion in how to avoid consumption spoofing. short answer - if publisher trusts procfs, no problem exists. if he doesn't trust it, he will be able to perform the various multivariate-linear-outlier-detection methods raised.
i think HMC now agrees that the ongoing measurements can be decomposed of past-benchmark-runnings measurements.

i hope the blogger from http://data-science-radio.com/is-zennet-or-any-other-decentralized-computing-real/ will now understand how wrong he was ;)

Please joins us on #zennet at freenode

During the Patriots game? Are you Insane! :P


http://www.ifeed2all.eu/type/american-football.html

I think we do still have some "fine point" details to work out, but yet we at least agree on the actual goal here, now.


Really, you can!  An ANN is really just a composition of sigmoids in a graph and you can certainly authenticate over sigmoid functions, graphs, and the composition.  You can't assert something like "it hit a correct error rate" because you can't define what would be a correct meeting of any arbitrary objective, there, but you can certainly assert "evaluation and backprop/annealing were applied correctly" and infer from that the error rate hit was the same as what you would've gotten to running locally, which is all we desire.


This is pretty central to the debate.  While this is historically true, what we are finding in contemporary work in this field is that most of these overheads actually stem from the combination of authentication for correctness and privacy preservation.  One of the key insights that the work of Socrates1024 brings to the table is that if you remove the privacy preservation criteria (and, as a side effect of the change, remove a particular type of termination criteria - though one that I think doesn't apply to the Zennet case anyway) that the overhead of authentication is greatly reduced.

What we are mostly discussing now in our "side-band" IRC debate is if introducing a scale on the "granularity" of authenticated big step reductions creates, or can create, enough of an inflection point to control the overhead to within some acceptable bounds without sacrificing the utility of the authentication.  We think that, at least for the "resource measure authentication, only" goals of Zennet, we can.

You can think of our approach (greatly simplified) as something like this:  Authenticating (hashing over and signing a receipt for) each individual opcode (or, worse, micro-coded state transition) create a huuuuuuge overhead.  Authenticating over every stack scope (function call) state requires only hashing over call operations, creating far less overhead.  Authenticating over "an entire system run" starting from some confimed-correct hardware loaded with some confirmed-correct software requires only one hash over a certification that you did turn the power on, in the correct state, and run the thing from there.  It becomes pretty self evident that we have a clean gradient of overheads, here.

Our goal is, in a nutshell, to make the granularity of the "authenticated step" naturally large enough to be efficient but small enough to still be meaningful.  We're attempting to do this by, basically, a model of authenticating not over the entire computations but only over "each step involving a resource access."  The key realization is that we don't care if the actual math done between these resource accesses is correct - that is not what we are trying to certify!  What we are trying to certify is that resource access is done with a correct ordering, accounted for correctly in the "billing receipt" created by the worker, and that if any tampering is being done it cannot be done in a way that can be hidden from the publisher, i.e. with no evidence of the tampering included on the receipt.  We think that, under our new approach, for the worker to "get away with something" he will either have to provide visible evidence of his shenanigans to the publisher or else will have to expend significantly more resource than just running the computation correctly in order to generate a "believable" lie that will not stand out to the publisher on the receipt.

We are sketching out some details of a "toy proof of concept" (literally an adaptation of "hello world") to help confirm our theory.


Well, of course we do!  What we don't mean is running some specific prescribed operation, but any general operation we please. The work function can be summarized as "run our authenticated hypervisor and give us IO to the inside" basically.


HEH, neither do we, yet!  It will probably not stray too very far from what was originally proposed, just with a small peice of the VM either added or removed, depending upon how you look at it.  We've tossed around a few ideas for different approaches, but decided to defer many of those details until after we can prove the basic premise with a "hello world" type example being authenticated.


This is also somewhat central to our debate.  I think at this point we have about 5 to 7 opinions between the three of us, hehe.  I think pretty much all we *do* agree on so far about this particular aspect is that we need a much more formal treatment of this particular aspect in the specification!  :D


I think you missed something key, here.  Benchmarking is continuous, and ongoing, in any case.  In other words, your job is benchmarked "alongside the process" so if you start out benchmarking high and then go about removing applied resource, you will not be able to (assuming we can get the ancillary issues sorted out) continue billing without also reducing your billing rate correspondingly.  We all agree that this will work fine and that rates will converge appropriately.

What we don't agree on is the meaningfulness of the initial "baseline" benchmark that you start from, to do your initial rounds of billing before this convergence starts to "settle into" the correct values via the linear decomposition.  I don't dispute the validity of the linear solve, itself, only the applicability of a single "cannonical" or general benchmark to any initial billing for an arbitrary process.

The details on this are a bit too deep and maths-y to get into here, I think.  Join #zennet and we can wade into it if you'd like. :-)


Yes, this has come up as well.  We'd obviously like to avoid something as (insanely) effort-intensive as authenticating an entire kernel and/or VM.  Although Ohad briefly considered it as an option, I discouraged such a "moon shot" goal, favoring instead an approach more like a special purpose vm layer.


I agree!  If we can solve 2 and 3 then any "lower dimension" non-linearity introduced into the pricing model by an "attacking" worker becomes immediately quite visible, and the publisher can reliably abort.


Exactly.  The conclusion we do all solidly agree on is that if we can verify enough such that a "big lie" becomes very self-evident and "creating lots of continuous small lies over time" becomes very computationally expensive, then the rest of the model follows soundly from that.  (Assuming ID cost is correct, i.e. my point #1 is solidly addressed as well.)

We'll still be around after, I'm sure.

I don't have the time to follow your discussion on IRC, but feel free to post any results here. I will check on this thread.

I'm sure we will continue to relay any pertinent conclusions here.

below when I mention "we" I mean HMC and myself:


as above, this description of this issue is based on misunderstanding. we continue working together on this mechanism.


we are making promising advancements on that area.


I think we now agree after clarifying that the contract does not contain any futuristic promise.

PS
To anyone who didn't note, I've credited HMC on OP.

I have found your first customers. :D

http://thehackernews.com/2014/09/the-pirate-bay-runs-on-21-raid-proof.html

And I have found 100+ customers. Unfortunately they are botnet owners.

yeah heard of it, cool stuff :)

that's why we plan to deliver the client configured by default to block internet connection to the publishers.
providers will be able to change this setting, and moreover, they'll be able to allow this for publishers they trust only (such as universities). all the publisher has to do is to publish their zennet address on their website, and providers can trust it.

when can I buy this? tomorrow, next week, next year?

a very few weeks i'd guess

https://i.imgur.com/06H71TY.png
InsideBitcoin TLV conference was a great success. Thank you to all the people that came to our booth and expressed interest in zennet.
We made a promotional video for the conference which can be seen here:

https://i.imgur.com/JKUrih1.png (https://www.youtube.com/watch?v=fC9qVrlKXRs&feature=youtu.be)
                  link to youtube video!

http://youtu.be/fC9qVrlKXRs

We need more info On ZenCoin.

I would prefer to be able to invest before all those information is out there and everybody is jumping in...

you can't wait to buy this  ？ guys you should be careful

This sounds great.

We need someone to take the power of our GPUs into real computing.

How are going to price the IPO ?

Take a look at GRIDCOIN http://www.gridcoin.us which uses the BOINC infrastructure to use your CPU & GPU power for scientific projects. Already at position 24 in the world ranking of number crunching. Established for over one year and you can buy these coins.
http://us.allprojectstats.com/top.php?type=2&o=1&projekt=0&s=0&desc=y&hl=24

This sounds like a very interesting technology.
Looking forward to the IPO.

@DEV, what's the difference between this coin and GRIDCOIN, can you brief it?

The main difference is that on Zennet, anyone can be a publisher (rent computers), at any time, for any purpose. World Community Grid indeed helps the academic society, but it's not open for everyone, has specific uses only, and does not pay according to actual resources consumes. The variety of resources to be offered is also a major difference.
Gridcoin, as far as I understood, is about making the mining useful.
On Zennet, computation has nothing to do with mining or coin generation.

I didn't forget about the pre-sale details, it's a matter of ~1 day until we post the info.

Hi All,
Following are the pre-sale details.
The date isn't 100% final yet, and maybe not only the date. We keep the right to make some minor modifications till the final date announcement.

Launching the Zencoin Pre-Sale


First of all, we would like to thank the community for their interest in Zennet and for their patience regarding the launch of the Zencoin pre-sale.

Zencoins will be pre-sold by sending Bitcoins to a fixed address that will be given on our website http://zennet.sc. Bitcoins will have to be sent from an address that you own, for example Bitcoin Core or Bitcoin-QT wallet, or from Blockchain.info. Future address verification, for the sake of Zencoins distribution, will be done safely via the Sign Message mechanism, with a fallback option to other methods of verification.

This pre-sale focuses on the Bitcoin community, of which Zennet's founders are proud members. We believe that this community understands the future of decentralization better than anyone else.

In this pre-sale we will sell 10% of all future Zencoins that will exist. The community will set the price. The coins will be distributed proportionate to the amount each buyer bought in BTC/USD (average) value (in order to be fair to all buyers disregarding BTC ups and downs. It doesn't matter from our side), and not according to a fixed price.

This price-discovery sale will precede other sales that are intended mainly for the global crowd (via cryptocurrencies or fiat money), such as corporations, academia, research centers, etc. Any future selling of Zencoins (by the Team) will only occur at a price higher than the price set during this initial pre-sale. This is to ensure that the early adopters are rewarded by having purchased zencoins at the cheapest possible price point.

The following is our high-level roadmap:
    Q4'14: Pre-sale campaign launch. Core development.
    Q1'15: Core development. Worldwide corporate and academic marketing.
    Q2'15: Functional beta.
    Q3'15: Zennet release.
    Q4'15: ZenFS beta.
    Q1'16: ZenTube beta, ZenFS release.


Additional documents providing further details on the sale as:
- Terms and Conditions of the Zencoin Genesis Sale
- Zencoin Product Purchase Agreement
(To be published soon)

Additional terms:

- Zencoin will NOT be usable or transferable until the launch of the genesis block with the official Zennet platform release.

- Ongoing Zencoin generation, similar to mining, is not planned for Zennet. Upon the launch of the genesis block, all coins will be distributed to their owners, except for 8 percent of the Zencoins that will be retained for the Zennet Team, and another 8 percent of the Zencoins that will be retained for community applications and bounties.

- An additional 4 percent of the Zencoins will be retained for supporting initial network growth. These coins will be spent on the network to create resource demand and incentivize the joining of new nodes during the early stages of the network. These coins will be fairly distributed to the network participants as they will be used to continuously rent computing resources until the coins are exhausted, in order to bootstrap fast network growth and early adoption.

- All other unsold coins will be destroyed when the official Zennet network launches.

- The estimated launch date for the genesis block is Q3 2015.  Up till then we will be working hard on developing the product. We have already recruited a full development staff, and have began development months ago.

- The tentative date of the pre-sale is mid-November, exact date will be published ahead of time.

- Zencoin is a token being used only for a certain commodity (namely computational resources). It is NOT a security, a currency or an investment offering. Zencoin is simply a token useful for renting computational resources on the Zennet platform after its development is complete; it does not give you voting rights over anything nor shares in some kind of profit, and we make no guarantees of its future value. Also, we do not and will not make any plans to make Zencoin a general purpose currency. It's solely intended to be used within the Zennet network as an in-application computational resource credit.

I don't quite understand the need for the token. Why not just sell shares that generate a percentage of the network profit to the initial investors and have the network power purchasable in BTC (or any coin for that matter)?

Because there are no future profits.
The payment on Zennet is directly between the provider and the publisher (bidder).
No middleman at all. No fees. We (nor others) don't make a dime after the Genesis block is out.
In addition, using existing coins is impossible due to technichal reasons (also discussed on this thread).

I'm not that bright these days so can you link me the post that explains why a renter cannot purchase with a btc address and when confirmed the contract is provided and when fulfilled the address that was paid then pays the recipients and also the share holders?

The main reason that BTC is inadequate is that the Micropayments protocol might require an initial time of  even 30-60 mins until the computational job will begin. This is of course unacceptable (even 5mins aren't).

hmm what ?

10% will be sold to "investors" , 8% for you, 8% apps&bounties , 4% some initial network growth (what ever that is).
That's 30% of an unknown amount. and you destroy the 70%?

I.. don't.. what? how..?


People that rent their power getting paid in zen or btc?
If it's in zen then where do I get zen after the IPO ? off the exchange?

80% will be sold. 10% now for price discovery. but the plan is to sell them all before the genesis block. if we won't be able to sell them all, we'll destroy what remains. the dedicated 4% will be spread to the people. the remaining 16% will be used for building and maintaining the products etc.
people rent their power are getting paid in Zencoin.
There will never be an IPO since it's not shares we're talking about. We sell a commodity.
The tokens will be distributed to their owners when the network begins working. We might consider a slow distribution in order not to flood the market.

I'm not going to spend the time to pick this apart, but I will say these arguments you just made are beyond thin. I no longer have any faith this will exist at all and it will be a money grab. To bad it's a great Idea. Hope I'm wrong.

If you find a problem, please tell and I might learn something new. I cannot figure out anything from what you said. If you want a deeper understanding of the mentioned subject, there is more info here on this thread.

+1

We need a benefit balance between developer with investor, developer works hard to deliver a good product, investor invests it to get some profit, win-win is real win.

Please explain, why too small? According to my math, if we sell more, it will cut the buyer's profits.
If the community will put X BTC for %10, so each coin will worth twice than if it was X BTC for %20.
In addition, recall that this is only the first sale. On the other sales, the price will be >=  from this price-discovery sell.
If I missed something, please explain.

On this point, you're both crazy.  :P

Ohad you should know better! 

The numbers don't matter a priori.  Any ratio of coins sold to coins destroyed is irrelevant.  You could work your system with an initial distribution of just one coin or a million, and the system as a whole functions just the same.  (Denomination is not value.)

To further assume that price discovery sets a floor is a bit unlike you.  Of course we should hope that this is the case, under an assumption that resource demand being initially high and resource supply being initially zero coupled with an assumption that, post launch, demand by publishers will continually outpace supply by providers (both growing proportionally) creating a natural scarcity of the representative token, such that market rates would never fall below the initial pricing.  Wouldn't it be great if that could be assumed to hold?  Of course it cannot be, as any number of factors could crash demand, skewing the proportional growth.  If this happens at a time where the ratio of oversupply subsequently becomes greater than the initial amount of demand at launch (relative to the zero initial supply) then it is only rational that the value of the token would cross below this floor.

This reminds me of an interesting model that I worked a few years ago about general asset pricing.  It seems to be commonly believed (particularly around these parts, heh) that any given asset has a lower bound on price at zero, and a non-finite upper bound.  This turns out to be logically backwards.  Under any rational model, an arbitrary asset actually has a finite upper bound on price (as there is only so much of value that is not the asset, to be traded for it) and a finite but *negative* lower bound, as any asset could eventually become toxic by way of an external interaction.  (Arguably there are hypothetical assets which might have an effectively unbounded low price.  For an example, a device which randomly and suddenly (in uncontrolled fashion) creates a black hole of any random size could be perceived has having a potentially infinitely negative value as it could come to "cost" the entirety of the universe to hold.  Of course this is a bit absurd, and no practical asset has such a pricing model, but the model is sound despite.)

Anyway, with all of that aside, how are the technical details coming?  I've been meaning to check in with you on the irc for quite some time now, but have been very busy.  Is there any progress on the verification of receipts?

I'm still on the fence about your "not an IPO" IPO.  If everything lives up to our ideals then I'm all in, but our ideals are set quite loftily.  I still see dozens of ways that this whole project goes the way of CPUShare et al.

If the verification doesn't work to sufficiently secure publishers, I'm out.  If the GPU is available as a resource but not adequately secured, I'm out.  If the identity model is insufficiently restrictive, or sees too much early gaming, I'm out.  If the reputation model isn't capable enough to handle all of the various concerns, I'm out.  If there is not sufficient protection to providers to preclude illegal/immoral uses, I'm out.  If this whole thing just evokes some 0day in the hypervisory layer, I'm out.

There are a lot of ways that this whole thing falls over.  If it doesn't, it will be awesome.

I'll catch you on IRC again soon.

Delighted to see you here again.
Nothing compares to an honest discussion.
I left you a message on IRC regarding the sale and I wanted to discuss it with you, but somehow we didn't get into it.


Please recall that while and after the price-discovery sale, we will continue the development and have more funds for the dev, so naturally the value should go up. That's without all the market size considerations you mentioned correctly.


That's why I don't set any bounds. But, I have to protect the early buyers. See, if I was thinking of myself only, I wouldn't restrict the price to be higher. I'd just sell at the price I'll be able to get at the same moment. The proposed obligation bounds the team in order to compensate the buyers. If the community will see this as more an obstacle than protection, we might reconsider it.


The verification reciepts will be included in the final product. We will have to know our budget in order to plan it. Up till now, before the sale, we made UI infrastructures (I can show it to you privately) with some good UI engineers, and we make progress with the pricing algorithm, benchmarks, procfs etc. with some good software engineers, who had to study the subject thoroghly and they're already hands on and building the client. We also recruited a respected cryptocurrencies developer who began working on the wallet and DPOS. Of course my time is invested with our devs and other team's work. For the verification we will further need Linux kernel guy and a PLT guy, both talented enough and free enough. We need a budget, a more rigid organizational structure, and time, to find the right people and get them deep into the design. It's a serious work done here. I have no plans releasing a novel cutting edge verification algo implementation that will turn out a joke. I need to take this part of the project not less seriously (and even more) than all others.
So, there is a limit to what to do without a successful pre-sale. And this pre-sale is intended to build the product to our alls requirements and satisfaction.


You cannot avoid the fact that the worth of a currency is mainly over non-tangible belief, but computing resources are a tabgible asset. Zencoin should be treated differently. Even though it's a commodity of a potentially huge market, we of course don't plan to sell coins for billions or trillions. So at any case, the coins will be sold at a ridiculus price, given the tech is usable. And it is usable and I'll convince again if needed.


You're definitely a man of ideals which I appreciate and tend towards. Bringing good and efficiency to the world is a different matter.


We are planning to go with the direction you have suggested. 'Authenticating the procfs' to summarize it in 3 words. Nevertheless, the original design, mitigation only without verification, does meet industrial standards for security and everything. We both might argue whether industrial standards are good enough or not. But the big money doesn't argue and follows the industrial standard.


A publisher will be able to run e.g. gromacs, and utilize the GPU safely for both sides. There will be no freeway to the provider's GPU, but the provider will have to trust certain applications (via plugins or so).


I didn't understand that. Do you see any issue with Zennet's identity model?

There is no reputation model. There are some other parameters that a node can measure that may be used to increase confidence. It's not that there is a public DB of each address' reputation or something.

The default client will block network access and persistent storage. So you're safe by default. If you want to turn it on, it's your choice. Publishers will typically offer more for such, so it will pose a problem from their side as well (it'll be more costly).

AWS didn't get any 0day hypervisory layer. In any case, what else can I do other than take some best known hypervisors? They are considered very safe, and they are. Let's say that on 0day hypervisory, Zennet might not be the world's biggest problem. Like breaking SHA or ECDSA, will not make Bitcoin's unsafety #1 world's crisis...

I'm looking forward to seeing the progress!  Hopefully my suggestions and reference materials have been helpful in those efforts.  Our direction on the design was sound (obv modulo my outstanding concerns like the GPU IOMMU, etc) so if the implementation follows suit then there should be few concerns!


GL!  Most people are not like me, in my experience.  Finding people with solid background in both the low level details and the high level theories has always been a challenge for me in my hires in the past.  Most people don't understand both ends of the spectrum, it seems.  If they can grok a pci enumeration they will probably be lost in the lambda calculus, and if they can explain type theory they probably won't know the first thing about a crossbar DMA.  Those of us who run the gauntlet between the gate/sub-gate level semantics that the OS developers care about and the syntactic concerns of PLT that the application developers care about are (increasingly) a very rare breed.  Your best bet is to find someone who has been working in "high level synthesis" tools for IC design, since that is the one area where you're forced to constantly bridge the gaps.

I know very few people talented enough, and none of those would be nearly free enough.  Myself included.  :-\  If I did know of someone to point you toward I'd probably be grabbing them up for my own endeavors anyway, heh.


I've said before and I'll say again that I think the less novel and cutting edge the verification is, the better.  KISS.  Draw as much as possible from prior art, here, with things like lambda-hist and the klee gaming work.  (Hopefully this is "preaching to the choir" by now?)


Cool.


This will need to be handled very delicately in any case.  The special considerations for any peripheral hardware will need to be very clearly enumerated for both providers and publishers.  It will need to be made very clear how providing GPU resource (or anything with side-band IO facility) is potentially very dangerous, and requires strict isolation.  It will need to be made very clear how utilizing GPU resource (or, again, anything side-band) can not be as precisely accounted for in receipt validation, and requires strict secondary verification.

I see this as one of the biggest possible Achille's heels for the project.  If providers get hacked because they offered GPU resource without understanding the ramifications they will certainly blame your software instead of themselves.  If publishers have excess spend because they utilized GPU resource without understanding the ramifications they will certainly blame your software instead of themselves.

This could easily turn into an image/PR problem.


Only the concerns I had brought up previously.  This seems to be the inflection point for "balancing out" fraud, so the specifics will be delicate.  I still hold that the easiest way to "attack" this network would be to simply mine a mass of identities early to burn through later.


There is no explicit reputation model, like a WoT or anything, but there is an implicit reputation model in the histories of the publisher/provider transactions, as you've pointed out to me at least a dozen times now.  If this implicit reputation model is easily gamed it is just as bad as having a weak explicit reputation model, no?


This is really more of a question of liabilities, and is something we briefly touched on before at one point.  I think, IIRC, that we decided that there was "little to be done" about it from the network perspective, and the onus would be on the participants to monitor their own transactions as much as possible.  Of course with added security layers (encrypted computations, etc) there is always some risk that your resources could be being applied toward naughty things without you ever having any way to know, but the assumption is that in such a case the provider is also absolved of the liability by the same reasoning.  It is a difficulty subject, and one that is much more political than technical.  You know my feelings on politics: blech.  I'll leave this one to the various jurisdictions to sort out on their own, and won't even think of it much further.  (Again.)


Weeelllllll, not publicly anyway.   ;)

Other VPS providers have not always been so lucky.


Nothing!  This is the one big "potential point of failure" that you can do absolutely nothing to mitigate systematically.  It either happens or it doesn't, plain and simple.  Unfortunately, on a long enough timeline it probably does happen, so it's more a question of response times and impact than anything.  All you can do is "be prepared" and demonstrate well that preparedness to your users.


Everything is safe until the 0day becomes public.  The OpenSSL was "very safe" for many years, and now I've had my bitcointalk account snooped on twice in under a year. WOOPS.  All well, we patch up and are "very safe" again until the next time that we discover that we actually weren't.

This vicious cycle is one of the primary motivations for my general interest in formal methods.  We have the technology to break the cycle and actually "be" safe, through combinations of isolation and verification.  Soon these technologies will even be widely practical, and maybe we can even start to look forward to a day where our software systems aren't Swiss cheese earning millions of people free credit monitoring every month.  I hope I live long enough to see that day.


For sure.  However, more to the point, it is a potential problem on a frighteningly long list of potential problems.  I have the advantage (that many others here who are skeptical of your project lack) of first-hand knowledge of your attempts to mitigate all of these problems, and I can say that you are doing a great job of covering all of the bases.  However, it is a LOT of bases to cover, and you are no superman.  You're good, I hold you in high regard, but with so many and so varied concerns something is bound to be missed.  Again, this will just be a question of response times and impacts.

This "not IPO" IPO is a big gamble, one of the biggest in the crypto space to date, but not for the same reasons as most IMO.

I don't share the same concerns as others that you might abscond without producing results, particularly given how open you are about both your initiatives and yourself.  I don't see many fraudster devs appearing at conferences to discuss their efforts, or giving up precise personal details in discourse.  (They usually go to great lengths to do just the opposite of these two things, so if you are going to defraud everyone then you've just made a lot of work for yourself in not just getting your arse kicked once you do!)

This IPO gamble is not a gamble because you might be some pump&dump fraudster, this IPO gamble is a gamble for precisely the "right reason" for an IPO to be a gamble - what is being attempted is huuuuuuuge and either fails spectacularly or changes the whole landscape of the marketplace.  Those are precisely the sort of IPO gambles an investor wants to make, even though in this case the vegas odds might actually be better with the scam possibility offerings just because of the scope of this undertaking and the very long list of negative outcome potentialities, however well mitigated or accounted for.

I'm rooting for you, particularly considering how much I've helped to lay out the implementation direction, but the analyst in me is still very very afraid that this will be another CPUShare all over again.  ;)

(Work faster, I can't wait for the resolution to present itself!)

+1

Great in-depth discussion between HunterMinerCrafter and Ohad as always.
HunterMinerCrafter come back more often please  :)

Definitely! I'm going to do exactly what you told me to do. With the exact paper you referenced me to. This will answer the 'novel cutting edge' vefirication below - you had a novel idea (well with some insignificant help from me) and I'm going to implement it as-is. That's, at least, the plan. BTW, I've pretty much kept in secret the details of this verification idea. I didn't even publish the name of the article you referenced me to.
Defraging the discussion, sure, the right personnel is very difficult to find. Yet, Zennet have myself dedicated (and I can cover even all of this by myself, only a matter of time), and I can find a PLT guy and a Kernel guy. It's not an impossible mission here in Israel and with our connections. I know how to get such people to successfully attack such missions. Also I'm pretty sure that worldwide interest of professionals will also come with time, and the open source community have all great minds there. Of course, I wish you or Socrates1024 would get more involved, but I totally understand the lack of time. Like I lack time for projects other than Zennet.


Our agreements and understandings are stone-standing like you know my word.

I'll take your advice for it. I even have one in mind.


Safe GPU computing isn't far. Recall that there are many models they can borrow with CPU. Combine with it the integrated LLVM that can identify many "innocent" say OpenCL kernels. That's for the near future. That's without mentioning the progress in HW-side verifyable processors.
For the present, only closed and trusted applications. Give me your gromacs job desc file and I'll execute it for you by myself -- that's roughly the idea with a few more tweaks.
Add to this the fact that VT-d isn't fully out there yet.


What do you suggest?


Address' public history is one (untrusted) aspect. There is something like a dozen more parameters which I mentioned endless times, like local history (you don't have to find the bad ones, all you need is enough good and trusted ones), altogether letting you control the risk's expectation.


All agreed. To rephrase it in my words, something like Zennet would become sooner or later without Zennet. It's almost a fact and people will have to learn how to live in the new world which is much more powerful than the old one. And that's not my fault even if I wrote Zennet. Zennet is just another piece of software. It's not like discovering how to split the atom.



On Zennet you have 3 layers of protection. Hypervisor is only the first. cgroups is the second. And even inside the cgroups container, you don't get root. So it's a third layer.


And yet the development, widespread and funding of OpenSSL is justified.

I have thoughts about it too. Building a contract editor that will let you design any contract, but lambda calculus will vefiry that this contract is safe. You may also replace "contract" by "protocol". This is also a step towards generic programming. Life is long, we'll have time for all.


tx. i quoted this just to mention that giants x1000 and more than me will probably get involved with time. it's just good for everyone. who doesn't want such a system?

Probably, but precisely none of the commodity configurations today offer it.  Not one.  :(


Yes, IIRC this is pretty much where our last discussions got to leave off as well, either enforcing semantics with some higher level wrapper or asserting semantics with some static analysis.  Both are, pragmatically, even more substantial an undertaking than zennet itself!


I think I said this before, but if not I at least thought it really hard:  Figure out what the absolute minimum acceptable adoption rate would be and set the difficulty for identity mining to constrain as closely to this as possible.  If you can accept a growth rate of not less than one new user per day make the identity mining find not more than one new identity per day.

It is one heck of a tightrope to walk, in any case.  Too little identity generation will frustrate users and too much identity generation will put them at increased risk.  Unpleasant trade-off is unpleasant.


Sure, and again I don't ultimately see much problem with this in premise.  Getting it right in practice is another story.  This is also another case where it will need to be made explicitly clear to the user what the risk details are, and the onus of responsibility that they hold in making their own assurances.  Software criteria can only assist them so much, they will still always need to actually come to their own decision about reasonableness of each provider/publisher they deal with.


We call this dependently typed lambda calculus.  It really is the ultimate contract mechanism, as I'd hope you've begun to come to realize after reading the other materials that I threw at you.  Funny that we've had the basics for "the total solution" since 1991 and yet still almost zero application of it today.

Speaking of lambdas for resource contracts I just this week read a recent work that you might be interested in: http://arxiv.org/pdf/1312.2334.pdf

It is about algebraically inferring side effect.  It touches on some of what we'd discussed about type systems for resource access, but unlike most of the other work we discussed it does so in a simpler, polymorphic setting which allows for a more comprehensible inference method.  They also make a much broader and more complete treatment of the subject, in general, than most of the other papers, which was nice to see.

Also of related note, did you see Facebook's OSQuery?

It may definitely be one of Zennet's future areas of R&D.


I will emphasize on this a bit later.


All so interesting. I cant wait for the days of diving into it. It also draws parallels to my main area of research (machine learning).


Seems too heavy. https://github.com/google/cadvisor seems better and suited to our needs though. I tested it, works like magic.

Some dilemma with real world service that is currently valued by the dollar.. You can't provide real world existing service and assign it to the bitcoin value (not in this era anyway), just like with Storj ( cloud storage) , the second the bitcoin price goes up its btc value will go down and the other way around (in some way it supports bitcoin value since if the btc drops in value the will be more demand for bitcoin to use to pay for storj service, but that's a story for another day).

Am I the only one thinks that the base price should be evaluated by electricity costs+hardware costs/profitability+real world market price of these resources+whatever  ?

Lets say you manage to sell the 80% zencoin for 8000BTC (At its current price of 350$)  and the next year the bitcoin costs 1000$ , do you think that demand will overcome the supply and people will pay X3 times more for Zennet resources instead of google's supercomputer ?


And I still don't know how one gets zencoin / pays for the work.

So we fixed the BTC/USD value problem.
Now this problem is only one-time. Once all buyers get their Zencoins, Zennet has nothing to do with BTC, USD or DOGE - Zennet runs on Zencoin only.

Let's make some order about the ID POW. I'm including new ideas here, tell me what you think.

Background:

1. When publisher and provider agree, the publisher may now utilize and pay, or not utilize and not pay the provider.
2. Publisher may even only add 3 integers for a whole hour, so after 1hr the payment might even be < 1 Satoshi.
3. If a publisher does not trust a certain address, they should not give a lot of work to that address.
4. We have two ECDSA keys on the system, call them SSH and ZEN. ZEN ECDSA is just like BTC priv/pub key, or: address. SSH is equivalent, for the sake of secure shell connection.

ID POW:

5. If an address begins with 10 zeros, one can quite easily calculate a lower bound for the amount of Zencoins needed to create such address. Say it costs X Zencoins.
6. Now I connect to such a provider and give it work X/4 Zencoin worth. This work should be easily provable (like hashing, matrix eigenvalue problem etc.).
7. Note that I can securely tell my publisher friends that this address is bad, if they miscalculated. How?
7.1. When I began talking with the provider, they proved they own the ZEN key by challenging them to sign a message.
7.2. This proof was done over SSH, signed with the SSH key.
7.3. So I have in my hands a signed conversation, proving its Zencoin origin, and proving that the eigenvalue returned is incorrect.
8. Now, after the provider invested X Zencoin worth of POW on their ID, I have a proof in my hand, which costed me X/4 (at the worst case, if I couldn't run away without paying after I realized I got scammed), and I can prove to the whole world that this X worth addr is malicious.

Zennet truly looks like the next HUGE thing and the presale sounds like a solid opportunity to take a small part in it
The more i am exposed to the thread and contents the more i am asured that this project has serious thought and work put into it, and unlike so many shit/scam initiatives - this one has real usability and value in the real world!
A huge thumbs up for Zennet!!  hope it lives up to the big promises and potential it holds!

That actually doesn't fix the problem for the btc holder.. you miss my point.

A BTC holder that believes the btc price would go up he would not spend his btc on a service that is currently being valued in dollars.
There is no reason of investing using btc, it's just like selling btc to dollars to invest in a start up, and that there's a good chance that if the btc goes up you probably won't get your btc back.
If you buy with 350$ now and the btc goes to 1000$ your 350$ will still be worth 350$, it's actually a waste of btc.

So, if an investor believes that zennet is a better investment than btc then he would invest his *dollars* in zennet.

I see your point now. Maybe we'll think about giving both options.
Yet, not every BTC/USD bullish is necessarily BTC/ZEN bullish.
On a second thought, Zencoin is a commodity, and the sale is not intended for assets speculations. So maybe we'll keep it fiat.

By this reasoning alone, if you believe that the btc price will go up then you should never do anything with a bitcoin except hoard.  While I often see this reasoning I don't think it is sound.  I won't step into the holy war and debate this, it is already a well beaten dead horse.

In any case, why is the denomination relevant at all?  Any argument that you could make for a bitcoin you could also make for any asset, like a dollar or an apple or a share of Apple.  If I invest my apples in zencoin and apples go up I probably wont get my apples back.  I give $350 worth of apples for some zencoin and then those apples become worth $1000 I'll still only have $350 worth of zencoin.  By this logic I should never invest any asset in zencoin if I believe that asset will increase in value, because I might be right and the value of that other asset "might" go up.

Of course this is flawed reasoning.  One really needs to account for potential movement of *both* assets in *both* directions.  One needs to consider not just if apples are going to go up or down, but by what percentage they are going to go up or down relative to the percentage that zencoin will go up or down.

The specific underlying assets are not of actual concern, nor their particular spot prices, only their relative appreciation/depreciation while held.  If I think that there will be more new interest opened in zencoin over some time span than will be opened into bitcoin, relative to their market caps, then it is rational to exchange my bitcoin (some or all) for zencoin over that time period, and then to incrementally re-balance between the two as that new interest enters the market and the price gaps relative to market caps closes.  This is pretty basic economic theory.  If "done correctly" one ends up with a larger valued pile of both bitcoin and zencoin than they had of bitcoin originally.  Of course this is simplified, a real investment house will also have to consider things like the "market sensitivity" or how much their own entry to and exit from both markets will skew the curves.

(I think that if Ohad meets his goals then this will probably be the case over at least a 6 to 12month timeframe, btw!!  Yah, I'm that optimistic about this project - if he does what he intends I firmly believe that new adoption of the technology will (briefly) outpace new adoption of bitcoin.  No joke.  If this thing works or even just "works" there will almost certainly be a mad rush of both publishers and providers.  I don't see people flocking away from AWS or anything (the projects cover different use cases and concerns) but I do see this having the potential of very quickly becoming a dominant technology in the space.)

Someone might be tempted to say "but this is an IPO so it is different from general investment of an open asset" but the fact is that the only real difference is that there is no prior historical trade.  Otherwise the market "functions the same" at the moment of the IPO and forward.


If an investor believes that asset X is a better investment than asset Y he will trade asset Y for asset X proportional to how much better they believe it to be, possibly adjusted relative to some risk profile.  (Note this says nothing of asset Z.  In your example X=zennet, Y=btc, Z=usd.  You can't cross-relate value comparisons like that unless you start talking about arbitrage.  If you do want to talk about three or more assets then you are looking at hedging between the three *relative* interests, but the premise remains more or less the same from there.)

If they are smart, they will also write out put/call contract pairs to bracket return above a risk free rate to within some acceptable bound of probability.  This is slightly less basic economic theory, but still pretty much "first principles."

All of this is rather off topic discussion, though.  It is not any concern specific to zennet, and is something that is well covered elsewhere.  This isn't an appropriate thread for discussing general economics or investment strategy, IMO.

I see the point too, I just think it is an absurd notion particularly as applied here.   ;)


^^ THIS.  If we are really concerned with some triangular arbitrage then we need to consider all three edges of the triangle!


I think this would mostly come down to constraints of the "IPO" itself, such as how escrow would be handled etc.  Ideally you should offer as broad a base of denomination as possible while still remaining convenient to everyone.  ("I'll send you some apples for zencoins." is probably not logistically viable, but "btc, usd, ltc" should be trivial enough.)

Good answer  :)

http://www.reactiongifs.com/wp-content/uploads/2013/07/thats-good.gif

Thanks!  ;D

I'm not sure I understood you. If you meant trusting someone else to keep on the BTC of the sale, it's problematic. If it's regarding the Zencoins themselves, they won't come into existence until the network is ready, and at that moment they'll be distributed to their owners.
Add to that the fact that many constrains are arised from legal point of view. Zennet will function as a regular company, offering to buy its products in presale (in ridiculus prices of course), while obligating to supply those products.
Of course, no one (including me nor the company) have any kind of control or income from Zennet after releasing it.

I love these Gems.

Well that's a master in Gems theory we're talking about

I'll go back and re-read the irc logs related to this and respond in more detail later.

Regardless of the implementation detail the core philosophy remains the same, identity needs to be scarce/difficult enough to discourage new identity attacks, and yet available enough not to frustrate legitimate new users.  IIRC I concluded that any scheme can work as long as these two (conflicting) concerns are well addressed, but I'll need to review the particulars.

Good luck. I will be backing you at 11/11.

99% of the crypto projects (invested with bitcoin) are not traded with dollars nor related to any real world service that is being valued with dollars. (http://coinmarketcap.com/currencies/views/all/#BTC) that is why I gave the Storj  (http://storj.io/)example, so in most cases where I invest in bitcoins I don't need to worry that I lose my bitcoin if it goes up (true that I don't lost my dollar, but I might lose the bitcoin)

If you spend your bitcoins on storj or zencoin then probably the only way you'll end up getting more bitcoins is if bitcoin itself crashes.

Apples or shmapples, nothing changes the fact that spending bitcoins buying dollars is not the way to go for a bitcoin believer.

It should be a limit for that 10%.

Anything higher than 100 btc invested will be really risky to all investors.

I'm not going to invest in the coini if there is not a limit. Becauseif you invest without a limit you don't know at what price you are buying, thats not really fair for early investors.

As an investor you should also be happy (at least partially) if they sell for much more than a limit sum as you suggest (and a limit of 100 btc total is ridiculously low anyway for a project in this scope...) because more money will mean more available resources for development and growth in your investment (facilitating your initial agenda).  

What is the difference between Storj and zennet?

Roughly:

Computational resources are many: CPU, RAM, Disk, Network....
Storj distributes the Disk part.
Zennet distributes them all.

watching

Zennet seems like one of the most innovative projects in the crypto sphere

Storj core dev here.

From what I've read so far about Zennet, it's possible you could run DriveShare farming software inside a container (e.g. instead of a traditional VPS) if you wanted to run an instance remotely instead of on your own computer. I'm also working on an autonomous agents system now that could plug into Zennet's distributed infrastructure nicely too. Can reach out when that whitepaper is done.

One question I have though, how would you be able to prevent someone from tampering with the VM on the host machine, or tweaking it so it feeds you back bad data? It would be nice if there were a system in place so everything inside the container is completely opaque to the host and the communication back-and-forth was entirely encrypted. You could even send some 'tests' once in a while to ensure the host isn't messing with the VM.

Great to see you here


Sounds absolutly possible


This topic was well-discussed here. There are many mechanisms for controlling the risk. There is also R&D towards verifiable computing. Just pick an arbitrary comment on this thread, and at least 30% chance it's dealing with those concerns :)

O.K. let me try to put it in simple numbers for simple people like myself

1. how many coins are 100% ?
so far there is no number and some say it is not really important, which I think is a true statement


2. If I buy coins for 1000$ in the pre-sale, I will not know how many coins I have bought until after the sale, even if by then the total number has been set which it will to my understandings

3. So lets say that the total coin number is 10,000,000. 1M is going for pre-sale , the sell ended up with 5,000,000$ in the vault. this means that each coin price has been set on 5/1 that is 5$ each which means that I am entitled for 1000/5 = 200 coins. If however there are only few interested investors and only 1000$ have been invested then I can got with my 100$ 10% of the coins. (less the percentage to developers and such). these coins worth much less but as an early investor I actually had a great deal. So I would actually try to keep people off the sell, but this will hurt the developers and thus the product I am investing in. This is a dilemma pre-sale buyers would have to deal with. should I try to get as many people on now or not.

4. Now that the price has been set. is it good for me as an investor, that it is high, or is it better that it is low? For a speculation it is better low until it hits the markets and can be sold by early investors. So once again I am better off having the price of the coin stay low.

This all together is a problem for the developers who need to get the coins sell for the highest price possible in order to have the funds for further development .

So is this how it is or am totally wrong?

So let me try and answer some of the problem I have presented here:

first and most important, we are redefining many economics basic assumptions: Introducing a token coin into the equation is like having an equation with two variables rather than one.
The value of the token is a product of both the demand for the service one get using the coin and the supply of both service and token, . This means that one can have piles of cash in their hands but no excess to the service unless having a token in their hands.
Assuming then, that I have all the dollars in the world, the price of the service will be set by the supply of tokens only while having a limited amount of both create a new relationship.

Now if, like in the case of most Altcoins, the coin itself was not a gateway to any service and I can use any other currency to get my product or service, then the value of the coin is driven only by community expectation to draw a user community which will use the currency as a medium of exchange and store of value.

 BTC for example did act as a token for a" none banking" wire  transaction. The value that bitcoin drew was due to it being a token for a service one could not get without it.
 Zennet coin is just like that, only that the service you get is computing, which you can get elsewhere but not sell ellsewhere.
 The service have many other qualities that makes it desirable. unless it get too expensive.
 But here again  the market mechanism is very direct and make  the coin price match demand.

Investors that choose to keep the token as store of value or for speculations can evaluate their investment in real terms as far as demand for service and supply of coins.

Now let me take you back to our pre-sell.
The tokens that we are buying are the  parts of that future supercomputer. It can not work without that essential component. Our coins are the actual part that operate that "machine", but unlike most essential parts of a machine, these you can transfer from one to the other. The tokens a a full representation for the value of the "machine" or rather that future computing  decentralized corporation.
But our tokens are even more than that' they are also the actual contract. some of the things that one day Ethereum will allow to do. are already here as zennet coins

We as first investors still may want to keep the crowd from coming, but our machine is not going to be that developed if the developers dont make enough profit. thus we as investors in a product wants to get as much money invested in the product development. And when I say two variables that is what I mean.

As a pre-sale investor I would solve that paradocs by asking the developers to keep more coins in their possession so they can capitalize on it after the "machine" is in the market and so are the coins. Even if they eventually dump some coins they are going to loose future profit from the product they have created,

"Believing" in bitcoin is not a legitimate reason for trading irrationally.

If you see a trade of zencoin for bitcoin (or vice versa) as having anything at all to do with dollars then you are missing the whole point of relative valuation to begin with, and no argument will be likely to convince you of your mistake.

Pretend USD and other fiat currencies never did exist.  Does your reasoning still hold?  There is no reason that it shouldn't, if it is sound.

I've explained it twice already.

You either get my point and agree, or get my point and disagree. The bottom line is if the btc gonna cost 1000$ next year then I could buy X3 times the amount of process power / service on Zennet than I am now with the same btc.

Of course no one stops you from investing your dollars and I didn't say it is a bad idea, what I said is that spending btc now could cost you in the long term..

I "get" your point, but I neither agree nor disagree because your point doesn't even apply to the question, here.


Or BTC "could" crash back to $100 in which case spending btc now could save you in the long term.  My crystal ball is on the fritz, so I can't say for sure which of us is right on this point.

It doesn't matter, though....

Again, the USD value of BTC doesn't actually even factor into the consideration.  The concern is not what BTC does relative to USD, but what BTC and ZEN do relative to EACH OTHER.  Nothing more.

Fiat money only comes into the picture if our intended trade somehow involves an exchange of it.  Buying ZEN with BTC has nothing at all to do with USD or anything else at all but ZEN and BTC.

You didn't answer the question!  If fiat currency never existed at all does your reasoning still hold?

The price of milk in Ireland says nothing about the rationality of a decision to trade Btc for Zen.  By your logic if I think that the price of milk in Ireland is going to go down then spending BTC for ZEN could cost me in the long run, because the value of BTC relative to the value of milk in Ireland will go up.

This is obviously absurd.

Why should it be any less absurd if we replace "milk in Ireland" with USD?

The main reason to buy Zen with your BTC is to diversify your investment portfolio. holding everything in bitcoins is just stupid in terms of every investment model.
 
Now the question is why Zen and not Darkcoin or a share of google.
The choice to invest in crypto is a combination of risk factor and  belief in the crypto  decentralized social/economic revolution.

Short sighted people would say that involving "moral" standards in an investment is stupid, well it is just like any risk factor. When looking at the big picture, I would do much better for my children's future investing in improving a system that will guarantee a better chance for them to buy a home, than to investing in making enough money that will be able to buy them a home 20 years from now.

But since we are a short sighted creature and more so since we haven't been able to device an economic system that incentives in the short term, the long term goals like nature do,  I will focus on the short term benefit of investing in zen coin.

Zen coin s a product, not merely a coin. it is the key to a contract between someone who have computing power and someone who need computing power. It is a powerful key for something almost every person in the civilized world can use, and it is a product no one has created before.

If  diversify your BTC  investments is the thing then Zent  would be that thing. It is the first crypto-product that is reaching the heights of bitcoin. It offers a decentralized revolution to one of the most important resource of our time. Computation.

THIS!

I'm all for believing in the future of bitcoin.  I'm even all for (currently) considering btc the most valued thing!  However to consider it as the *only* thing of value is irrational.

Mishax's base premise only holds soundly if we consider BTC to be the only thing of value.  His reasoning falters, however, when he suggests as his secondary premise that one should invest USD into Zen instead of bitcoin.  By his own logic, one should not buy Zen at all, they should spend all of their USD on Bitcoin.  They should also trade their house, their possessions, their wife and kids, and their own body for bitcoins.

This is as all at least as absurd as considering the price of milk in Ireland.

Now can we get off of this silly valuation talk and get back to Zennet discussions, please?  ;D

Some economical aspects on Zennet (will slowly make this list longer):

1. If you hire 10 or 100 computers for the same task, the latter option will indeed run ~10 times faster, yet you will pay exactly the same thanks to the stationarity of the pricing algo.
2. Entities who buy a lot of Zencoins, usually do it in order to calculate something, hence spread them back to the people right away.
3. Hoarding coins by the providers is bounded, unlike other coins. Bitcoin has no apparent 'upper limit'. But Zencoin cannot worth 'too much': roughly saying, it cannot make the home pc cost more than aws, since the competition will balance such a situation. (leaving aside that zennet being more expensive than aws is hypothetically possible, if zennet gives more speed etc. and actually worths more).
4. Zencoin less depends on variables exogenic to the computation market, since it should not be used for other cases like buying coffee or car.
5. The growth of the amount of hardware is maybe the world's most craziest thing over the last decades.
6. Zennet presents a novel pricing formula, which can be used to price other assets as well, even when the underlying components of value are totally unknown. http://zennet.sc/zennetpricing.pdf
7. The amount of fortune being wasted by idle computers is unimaginable.
8. The micropayments algorithm assures a frictionless (no fee, off-chain) transfer of coins every few seconds or even less.
9. The waste of thrown out old computers turns out to be huge and toxic. Once they'll be able to generate income, less PCs will be damped.
10. Zennet is about 30% more efficient than AWS because of new-generation virtualization technology.
11. It's a totally free market. Anyone can set their price freely, while the payment is p2p with no middle fees at all (except standard tx fees).
12. Zennet breaks big monopolies and spreads a lot of fortune to the people.
13. One of the pricing algorithm advantages is ability to optimally take into account variances between hardwares, or between different times over the same hardware.

interesting, but if people put their computational resources for hire, then those won't be available for securing the network (ie calculating POW), and vice versa. So there may be a conflict that jeopardizes the security of the network....

what? did you say delegated pos?   get out...c'mon... really?

will be happy to discuss the coin infrastructure.
so, why not dpos?

in addition, this contradiction is 'virtual' in case where tx fees are most (or all) of the incentive

Published the pre-sale press release here :

http://www.cryptoarticles.com/press-releases/zennet-decentralized-cloud-network-releases-details-of-zencoin-presale

Writeup for Bitcoinist will follow over the next few days :)

Appreciated

Assuming that the providers are evenly priced and reliable, of course.

I'm not sure that it really bounds in this way, because both spot price of the coin itself and provider rates can change.  If hoarders drive the price of the coin up the pricing of the resources will simply go down correspondingly, no?  I'm actually very interested to see how this dynamic plays out in the end.  There are a few different potentialities and I'm not sure if there is a meaningful parallel that could be studied first.

People likely will anyway.  I suspect that speculative traders will be the largest externally influencing factor.  This is just a hunch.

No, the craziest thing is probably the amount of wasted energy this mass of hardware has burned through while sitting idle!   ;)

Is the intent still to have this pricing model be just a "helpful tool" and not a mandate?  I still think this would be very important, and being able to script alternative pricing models would be very nice to have in addition.

what's nice is that you get this speed for free. currently no pricing model supports that. and Zennet's one is still the most fair around. all thanks to the usage assumptions (heavy distributed computations), which I plan to write a more detailed comment about here, later.


yet it's bounded, isn't it?


The coin is degined for micropayments. I'm not sure (yet don't know) if it'll be economic or convenient or safe for other uses.


that's crazy and that's the craziest, indeed.

planned from day 1

https://i.imgur.com/O49JIWT.png] (http://cryptobizmagazine.com/zennet-decentralized-cloud-network-releases-details-of-zencoin-presale/)

"Zennet has the potential to drastically reduce the cost of computational power and bring new magnitudes of speed to HPC consumers": http://cryptobizmagazine.com/zennet-decentralized-cloud-network-releases-details-of-zencoin-presale/

I'd like to point out two subjects that answer many FAQ:


Why fixed amount of Zencoins?

I came into understanding that generating new coins is a fiction, if we want to keep the market non-skewed and fair. Since, if new coins are generated, the optimal fairness strategy will be to spread them proportionally between all coin holders. But then, we actually did nothing. It's like adding a zero to all accounts on a certain currency. Hence, without making skewed distribution, coin generation is meaningless.

Zennet Design's Main Assumption

Zennet's design relies on a main assumption, which states that Zennet is intended only for massive distributed computational jobs. We assume that publishers (bidders) are aware of this assumption and do not rent computers unless they:

1. Need 'a lot of' computers (say at least dozens, of course it depends).

2. The work is divided into many small parts, where we anticipate from each computer to finish one job in a reasonably short (say < 5sec) time. This is partially like saying "your algorithm should be well-distributed rather than only artificially 'distributed', not to mention parallel".

This might sound restrictive, but in fact, even nowadays most of the money spent on the software world, is for such huge and distributed jobs. Just read about Apache Hadoop (http://en.wikipedia.org/wiki/Apache_Hadoop) which is only part of what Zennet can support. World Community Grid is another example.

The assumption may also sound innocent, but it has strong implications. Let me state some:

1. We may assume that the time until a single small job finishes is not interesting, but the number of small jobs finished. This leads to the pricing model, in which we can get a unique and optimal solutions from linear operators (which are always preferred because of normality, generalization ability and more), while taking into account even totally unknown variables. for more information see this doc (http://zennet.sc/zennetpricing.pdf).
Without the main assumption, linearity would be lost, and we come to a yet unanswered difficult question in economy and computer science. Nevertheless, our linear algorithm is novel.

2. If a computer suddenly shuts down, or somehow not functioning as well, the loss is small by all means. People frequently ask me "what if it's a full night of computation, and the computer turned down in the middle of the night? All the data will be lost.". The answer is that such distributed application is not really distributed, and for sure - not well distributed. Distributed computations should be broken into small enough parts, as a mainstream and important practice in this world.

3. Say we have 1000 small jobs. If we distribute them among 10 or 20 computers, the latter will be as twice as faster, of course, yet we will pay the same amount of coins on both cases. Speed comes for free. This is due to the ability to price the usage in time independent units, which is justified only if the main assumption is satisfied.

4. The main assumption opens many possibilities to reduce the expectation of the risks' costs.  For example, a publisher can rent, say, 10K hosts, and after a few seconds drop the less-efficient 50%. Another risk-decreasing behavior is that each provider works simultaneously for several publishers. Say each work for 10 publishers in parallel, so the risk to both sides decreases 10 fold.



PS
I've added some more to the 'economical aspects' comment (https://bitcointalk.org/index.php?topic=736447.msg9424435#msg9424435) above, and will continue adding.

I think DPoS is a nice choice of consensus algorithms. It is very fast and efficient, and would be perfect for a project like this. You should look into using the "Bitshares toolkit" to see if it might give you a head start on what you are trying to accomplish.

This is a very ambitious and interesting project.. I will be following along and I wish you luck!

Here is more info on the Bitshares Toolkit:

Wiki: https://github.com/BitShares/bitshares/wiki
Github Repo: https://github.com/BitShares/bitshares

dpos has the drawbacks of pos while adding centralization.

If you had PoW, I see many cool forms of arbitrage happening: being a provider and "outsourcing" to cheaper providers, using coins to pay a provider to mine coins for you, etc.

what does this mean? I can't think of any design decision that would be influenced by that, because... aren't micropayments handled off-chain?
You may want a fast block generation rate, but, what else?

HI GATRA!


I agree, and am/will-be trying to deter Ohad from going dpos over the course of our irc discussions.  I'm personally not as concerned with the "drawbacks of POS" (particularly in this case) as I am with the "adding centralization" but I understand that both concerns are quite valid.


Possibly, but it is likely that the system will be self-balancing such that the arbitrage smiles are very rare and short lived.  If a publisher could profitably mine with some providers' resource then rationally that provider would pull that resource from the network and instead apply it to the same mining process themselves for even greater profit - as they will not need to be paying some provider's fee on top.  In fact, this briefly came up in discussion just yesterday, after someone out there (and "out there", heh) mistakenly inferred that people might rent resource to mine bitcoins - in something of a decentralized cloud mining style - which is ofc highly irrational.


No, the micropayments will be on-chain!  Precisely the reason that this system uses zencoin instead of bitcoin or othercoin is because it will require a chain specifically oriented toward facilitating continual micro-payments for accounted resource.

This was one of the most difficult points for Ohad to get across to me, but since he has I now agree with him... the particular nature of this coin/network likely makes it of lesser utility for general purpose use.  I'm sure it will still see general purpose use, especially for things like services/add-ons related to zennet itself but the architecture is being assembled explicitly without this being a design goal, unlike most coins.

do you have a github with some code?

If I may, I just dont get why do you think that the coin will not have a general use  Yes it is design specifically for a servicing a particular system' but if it is traded on the exchange markets, even P2P and  there is a demand for the service which that coin mediate, my corner store may have a difficult time accepting it but maybe as payment in the university it will be accepted with much joy. and if all universities and student take it' the corner store will too. All services and related applications of accessibility will follow as well as hoarders.
Basically other than say it for the sake of laws and out of respect for paid lawyers',there is absolutely no reason to consider that not to be a good desirable means of exchange, store of value' and so very important' a unit of account that is related to a real basic commodity. (back to bean coins basically)

Hi HunterMinerCrafter!
Your connection to this coin makes me have more confidence on it, however I see lots of aspects that are not yet clear and still undefined. I still wouldn't put my money on it.

See this:


Another concern is how would the reputation system work.

Best regards!
Gatra

Of course I do think it will!  I was just pointing out that where most coins treat this as a primary design goal, zennet treats this more as just a secondary concern and doesn't sacrifice other goals for it, which *might* end up making it less suitable for such purposes, for the reasons Ohad pointed out.

Note the following fact: assume we're using regular POW based blockchain. since we use rapid payments for small amounts, we can use short block time (say 1min), which will of course increase the probability of the risk of double spending, but the expectation of the risk is low since we talk about small amounts. hence, buying a car with zencoins might not be as safe as people regular to.

it's one point where taking care of the certain use might make the coin inadequate for other uses.

say the coin is working just like Bitcoin, just with short block time, and an attacker could tamper the network for one hour.  the loss for home pc will be no more than a few dollars worth, if not less than one dollar. This is an extreme case, of course, and might be even too extremely simplified to be possible.

That means a lot to me, particularly coming from someone like yourself!


I was extremely skeptical as well, at first, particularly considering the early design iterations were so rough around the edges.

However, having now spent many cumulative hours discussing (both zennet and a few other subjects) with Ohad both here and on IRC, pointing him toward materials on both the failed historical projects along these lines ("don't become another CPUShare" has become something of a mantra) as well as more contemporary research on how to overcome the problems they faced, reviewing videos and the slide decks from his various presentations on the project, and personally "half redesigning" his model myself along the way, I currently have very little skepticism left.

As his implementation work solidifies, my few remaining reservations should inevitably be addressed in due time, as well.

I pointed out earlier that even if he just runs off with initial investments we know well who and where he is.  People could just track him down and bring charges or beat him up or something.  So, if that is his intent, he has already made his work of a potential absconding very difficult for himself!  :D


Yes, my last response was probably a little too vague.  The payment model is a somewhat unique combination of on and off chain transactions.  What I should have said, to avoid ambiguity, is that there is no "off-chain accounting" involved, no centralized database of transaction, and all of the micropayments eventually (and intermittently) will end up on-chain.  In order to keep this convenient, the chain needs to be designed with a few particular considerations in mind (relatively fast block times, some specialized transactions, etc) which might potentially end up being at odds with the normal goals of an alt. (Wide adoption as a general payment vehicle, etc.)  Maybe these concerns can all be handled in a way that doesn't interfere with general purpose use, but this is not an explicit goal and if the model ends up not being suitable for broader use we shouldn't consider that any sort of failure or deficit of the implementation.


There is not really any explicit reputation system, only an implicit disincentive to not maintaining a good reputation.  There is no recorded WoT or direct positive/negative feedback rating or anything of that sort.  The system only provides a means for something that you might call "proof of cheats" which can serve to devalue a particular identity.  Ohad has already described one part of this, providers can intermittently be given deterministic challenge work.  As providers have to attest (by signed communication channels) that their identity performed the service, simply disclosing a signing of such an invalid deterministic work session (wrong results or resource applications for the given problem) can prove to third parties that the provider has behaved maliciously by interfering with processes.

Secondarily, publishers will receive from providers something of a "signed and authenticated receipt" corresponding to each resource and correlated billing.  These receipts can trace each individual resource billing to the specific resource access "expected" in the work algorithms provided by the publisher.  If these receipts show unreasonable charges from a provider, that do not follow the constraints of the work, the particular work unit and receipt can be disclosed together which can similarly prove to third parties that the provider has behaved maliciously by attempting unreasonable billing that cannot be justified by the work published.  I'd probably say that the planning of the mechanisms for these authenticated receipts has been my primary contribution to the design, so far.  These mechanisms, themselves, are all prior art published by others, I just pointed Ohad toward approximately the right combination of technologies to make it happen.  (I originally called for the processes themselves to be authenticated in such a way that the providers never even *could* perform incorrect billing at all.  We decided that the overhead involved in doing so would be far too prohibitive so the design that is going to be employed is something of a compromise albeit a very good one.)

Similarly if a publisher succeeds to avoid payment on a service agreement this becomes visible as a traditional double spend.

(There might be cases where both events occur, too!  A provider might cheat and get flagged, and a publisher might divert their payment in response, and the provider might announce this act as a non-payment. In fact, this might even be the common scenario of disputes.  It would be up to the third party to decide how to interpret this.  Likely they would look at additional context to "pick a side" or if there is no such additional context they would simply proceed with both parties considered to be suspect until some more context is formed around one or both identities.)

Although it took quite awhile for me to see it, this sort of implicit reputation model actually seems to mirror "real world" service billing transactions much more closely than any explicit reputation metric ever could.

My concerns there are much less to do with the reputation model itself (which seems to be minimalist but sufficient, which I consider to be a great thing though some might consider to be a weakness) and more to do with the initial identity generation process.  If identity generation cost is too low then there is little disincentive to just "cheating anyway" despite knowing full well that your identity will get burned.  If identity generation cost is too high it impacts usability and adoption rate.

@gatra - Can you describe what you consider to be "the drawbacks of PoS", because all PoS systems are different and have a different set of pros or cons. One drawback in one PoS algorithm may not be applicable to others.

@both of you - DPoS works under the realization that all forms of PoW tend towards centralization anyways, and it gives a way for stakeholders to manage that centralization. I see it as being better than PoW in terms of centralization.

PoW centralizes around centralized mining pools where users aggregate their hash power. For instance, with Bitcoin about 50% of the hash power is centralized to 3 Bitcoin pools. I would venture to say DPoS is less centralized than this, seeing as though there are 101 delegates that thus control less than 1% of the network's processing power. Furthermore, centralization is mitigated by being able to vote in and out delegates... stake holders choose who secures the block chain and if they are doing a poor job of it then they can be removed. This also provides another benefit as with PoW you cannot decide who profits off of securing the blockchain, but with DPoS you can vote in delegates that are developing code for the project, marketing, or building 3rd party services. It is a form of funding development for the cryptocurrency that uses DPoS.

If the PoW algorithm you choose, or you make a new one an Zennet is wildly successful, is a popular one then ASICs are sure to be made eventually as soon as it is economically feasible. This centralizes mining power to big mines which are setup in places where power is cheap and cold environments where the equipment can be cooled cheaply. Furthermore, people with deep pockets get advantages by developing their own hardware for a fraction of the cost consumers can purchase it and via bulk discounts. With DPoS this type of centralization will not occur.

You guys bring up a good point here and this (although you don't seem to realize it) is another reason against PoW. Zennet will be renting out people's processing power, and it is foolish to think that the people renting out this processing power will not act in their best interests. The Zennet supercomputer could become unusable during times when mining is more profitable than renting out the processing power, rendering the service useless for a matter of time. With DPoS this would not be cause for concern.

It is ironic that all of these topics can be tied into DPoS... DPoS is more suited for micro payments than Bitcoin... as I said it is a fast and efficient consensus algorithm. Block times can be reduced to as fast as 10 seconds with an average confirmation time of 5 seconds, and each confirmation is more secure than one Bitcoin confirmation (or any other coin that is based off of Bitcoin's PoW). In the time it takes Bitcoin to produce a single block a DPOS system can have your transaction verified by 20% of the shareholders and by the time Bitcoin claims the transaction is almost irreversible (6 blocks, 1 hour) your transaction under DPOS has been verified by 100% of the shareholders through their delegates.

I don't think DPoS should be written off as a valid option until all of the details are discussed. There is a lot of misinformation that exists about it and some are "set in their ways" so to speak around these forums as to PoW being the only answer for consensus. I know there are a lot of other people that disagree with this sentiment, although they might not be here posting in this needle in the haystack.

Well, there is Spreadcoin but I consider the "jury still out" on it.  Possibly some "hardened spreadcoin" might work some day.  I might even try implementing such a thing before long.


My main concerns with DPoS (as distinct from PoS) are primarily that any centralization becomes a point of weakness so intentionally re-introducing it seems misguided to me, and that people tend to be lazy and often don't delegate in a way that will serve their own best interests.  Otherwise my concerns about general PoS are pretty well eumerated elsewhere (nothing at stake attacks, retroactive 51% attacks, etc) so I won't speak much to those.


I consider these to be separate concerns, and conflating them may be downright dangerous.  In recent history of alt-coins the ones doing the developments are also usually the ones with the least interest in the well-being of the network!  In most cases it is the developers, themselves, who attack and destroy.  Why should we promote a model that just affords them even more facility to do so?


This is just a trade off, with PoS instead providing incentive to hoard.  I'm not sure we can reasonably call one or the other the "lesser or two evils" and should strive to avoid both problems.

Furthermore, there is some theory that PoS is actually not different from PoW, and one could imagine a "stake grinding" ASIC.  I don't know of any such hardware, but it wouldn't surprise me much to see.  From what I understand of DPoS it does solve the problem of stake grinding in general, but does so in a way that re-introduces both incentive for collusion and potential for Sybil.  (I have my own theories that this may end up putting DPoS back at the "wrong security threshold" of 30% (like any traditional consensus mechanism) as well!)


Understand that the only monetary reward for providing the work would be tx fees, no new coin-base subsidies, so it is unlikely that there would ever be a time where mining work would be more profitable than providing service.  I think we can assume that providers (rational providers, acting in their best interests as you say) would apply only excess resource, that they are not renting out, toward mining.  As such, I think all that we can infer is that a PoW hash-rate might be of higher natural variance because of this, and little more can be said.


There is no real reason that block times in PoW couldn't be similarly reduced.  (Misconceptions about this abound, though, so perhaps I will need to say more?)


How do you figure?  This sounds a lot like rhetoric to me, can you please expand upon your reasoning?


I'm not sure if this is a meaningful comparison.  These relative numbers seem rather arbitrary to me.... shouldn't any meaningful comparison account for relative network size?  Isn't any measure of security derived from a metric of participation?  (Can it be otherwise?)


I think this sentiment arises mostly out of comparison of the "self evident" security of PoW versus the "implied" security of PoS.  We have now solid formal models around the relationship between PoW incentives and the relative security it provides.  We lack comparable formal treatment of PoS, though I understand there are those attempting to rectify this.  In other words, I think this is largely born out of "fear of the unknown" which may actually be a legitimate fear for Zennet to carry.

Finally, a simple argument can be made that PoS models are relatively new and not well "battle tested" where PoW has been attacked from pretty much every possible angle and has held strong.

Anyway, while this is all intellectually interesting I think it is possibly largely out of context.  Much of what we are discussing here has nothing at all to do with Zennet itself, and is just general discussion about PoS versus PoW.  I think this is a holy war that should perhaps be fought elsewhere.

It's still private. We don't publish it because of competition considerations and willing to protect buyers. Yet, we have published a lot of technological data, namely the whole design up to small details, which is quite rare. Hence we have to keep of some reasonable amount of protection against early competition.
Of course, all code will be GNU GPL or something like that, eventually.

HunterMinerCrafter and myself are at #zennet on freenode
all welcome to discuss Zennet

Using micro payment actually increase security in means of payment. Yha each payment can be tempered more easily but if I use that  technology you develop  with the internet of things in the future' or just my car's computer in the present, my car manufacturer release  the car computer capability in increments as the payment process progress. Once the entire sum has been transferred the key in you hand get the activation code and you may drive away.  To secure the process of payments it can be spread on a longer period of time and in smaller increments which is not a problem for large purchases. You can even let the person take the car and deactivate the key if he never ended up paying...... Hey I may just crafted my idea for the future  TOYOTA Coin 

The Micropayments protocol is of course not Zennet's invention, but taken from here (https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adjusted_.28micro.29payments_to_a_pre-determined_party).

The presentation (https://docs.google.com/presentation/d/1ap_lbkomeTGGCBz7HANofVhl6osqhepnWYOUPNAQgy4/edit?usp=sharing) from InsideBTC conference.
This one (http://crowdcomputing.eu/documents/10508/844563/Asor.pdf/4dfc70a0-2427-4377-9734-f8bed2ebb5fb) is from Crowd Computing conference a while before.

Did you get a cleaned up copy of the talk video uploaded somewhere, too?  I'm sure people here would love to see it!

well if one could sync the vid (which is currently way async) and cut from the screen irrelavant parts (it show some of my skype friends etc.) i'll be glad. will try to find one.
nevertheless, i can put audio only.
we also plan a public google hangout with me on video for people to come and ask questions.

EDIT: here's the video http://vimeo.com/111871002

Public Google Hangouts, with me answering Q&A, will take place at 11/11 21:00 GMT.
Soon a link will be published here so people will be able to submit questions before we go on air.

As your project proceeds, you will likely need more support with your English: economic == the discipline, economical == thrifty. Fortunately, mangled syntax English robust against is. Except for 2. (below) where the tense makes a crucial difference in this particular context ...


That statement makes an implicit assumption that the task is always amenable to parallel processing. Have you examined the range and depth of that assumption in terms of how much of the anticipated business depends upon it? Is it intended that the solution space be limited to such tasks --- or at least those tasks which are amenable to a parallel solution and can be identified as such, characterised and quantified in some reliable and accurate fashion?

FWIW, you don't mean "~10". The most favourable statement that you can truthfully make is "up to 10 times" and I suspect that you'd be hard-pressed to provide solid support that ~10 is the general case and not, in fact, some difficult-to-quantify smaller subset.


Can I just check (in case it's not merely a trivial issue of EFL) --- this is actually a forward-looking statement, a prediction of a future state rather than a description of an existing state? Because if it is a forward-looking statement, I'd really like to know how you got to “usually”.


Cheers

Graham

Definitely right. I apologized for my English several times here, and also pointed that some misunderstandings are because of my English. Yet, it's not that a disaster, since it's a discussion, and I guess the situation isn't that bad. One even answered that I have a good English. I disagree :)
At any case, the formal documents (like the About Zennet article) went through talented native English speakers.


That's of course correct. Sure there are limits for how a job can scale and with which efficiency. Zennet is indeed designed for distributed tasks only (both types you mentioned, if I got you correctly), as on my assumptions comment above. I might needed to put a few more ~~ and <<. It is indeed a rough estimation, just to draw the meaning for people not necessarily know much about distributed computing.


Yes, forward-looking, but less a prediction, more like a tendencies compared to currencies, stock etc.
English corrections accepted :)

I do like to spent a bit more time on that though the real importance of Zenet is in it being the first token-coin attached to  a service platform which operates soley on the token. Again, Ethereum present that same prospect but as a less advanced mechanism. The triumph of Zennet is that it actually managed to facilitate an almost direct connection between payment and service received. In other word it is like swapping service for a comedy without a third party involvement.Thus it cut the need to a contract carried out and enforced  by that third party. This type of direct contract, is the thing that has been achieved by the bitcoin  protocol. But so far had been applied only to direct transaction of the coin itself, not any attached service or commodity. Micropayment is in did not Zennet's invention' but linking it to a service that allow the exchange of a  commodity per time unit with a coin micro units and both being controlled by an algorithm secured and powered by the user community. that is the breakthrough to my understanding. (This which i came across and understand very little of, is some what similar in nature I think http://en.wikipedia.org/wiki/Distributed_transaction )

As I have said before, This evolution of the crypto-currency ecosystem will allow very soon to transfer information of all kind in quanta upon payment without involving a third centralized patry and that is a big step to humanity This allow for a true free market mechanism to set the price and facilitate  risk mitigation like in future commodity trade.

Now, since most people can not comprehend this in terms of the breakthrough that it is, or just dont understand enough like myself , you guys in Zennet have to device a better reward system which will encourage early investors.
The way you have constructed that is not offering early investors great enough returns on their investment. and thus might not be the best way to determine  the value of the coin. So I will suggest two option which are probably too complex to actually be perceived and execute. but I would ask you again to reconsider keeping more coin for yourselves after the sell ends. The community investors should not fear a Mastercoin event recurrence. Since your platform need the token for its operation, unlike Mastercoin for example.  Thus coins will regain value if the product is sound.

Option one:
Set the minimum price value of a coin ( say one coin is 8 cent) and have investor determine the number of coins rather the value of it. So if we had only $1000 invested then the number of coins will be only 80,000. It may sound dumb but this way you can assure that early investor in did have 10% of all coins, if having 10% of the coins is attractive to investors, which I think it's not.
(The "gambling" prospect you offer in you present model by not setting up the price is a turnoff point to serious investors, though would work for your benefit assuming you can create a good buzz, since most investors are gamblers.)

Option two
Since I dont think that letting the community set up the value the of coins is sustainable for you and definitely can leave you streaped out of good profit for your hard work, I would think that a coin reward system that  grant investors with more benefit the earlier they come in is the best strategy. Regardless of market price these investors should benefit in zennet coin on early investment  Thus for each coin sold on pre-sell, the investor is practically given a one time "present" of  one other coin once the genesis block is launched . All these pre-sell tokens can be issued on counterparty wallet and be transferable and traded before the genesis block issue. On counterparty you can issue these pre sell units in instalments such that the first Issued instalment is  grand the buyers with 2 real zennt per one tokent and the second instalment grant the buyer with 1.5 real zennet per token unit (each instalment will have to be  issued as a different token but this have no bearing on the real Zennt, For easy use you can name it something like pre-zennte-1, pre-zennte-2 and so forth )


 
   

Please recall that this is only the first sale of only 10% of all coins. The sales after will be at a (much) higher price. So early buyers do have an opportunity for a significant discount now.
I think that the amount of coins kept for the team is enough, even after taking some margins.

BTW: http://thecoinfront.com/the-worlds-largest-decentralized-supercomputer-is-coming-soon/

Join the Presentation today:
https://www.youtube.com/watch?v=6G8mTCtv8d8

Please ask your questions during or before the event at our IRC channel: #Zennet at Freenode. Quick link (http://webchat.freenode.net?channels=%23zennet&uio=d4)

I lost the video. Mai ve we Have a date for the IPO?
Thanks

There will be no IPO but pre-sale. Pre-sale of a commodity, not a currency :)
Our lawyers are finishing the last steps. Give it a few days more. We will announce here the exact date.

Please let me know when I can give you money. Take it just take it. This is amazing.

Looking forward for the presale!! FINALLY a chance to join the ship before it leaves the harbor! 
A year or so from now many people are gonna eat their hat for not participating earlier, I'M IN guys! :)

The project is really cool. I will partecipate too with some chip :-)

For interested investors, since this is a pre-sale, What currency/s will be accepted for tokens?

For this first presale, Bitcoin only.

Has the presale started? if so how much BTC were raised so far?

Didn't start yet. Legal people need more time.
You won't miss it when it'll begin, it'll be very clear here :)

 I can use this to 51% attack other coins. Has this been discussed?

Considering the target market place it should level to that price. So find a discussion on 51% with AWS and you will find what you are looking for. :P

I did not see this when I made my last post. This is another reason to lean towards DPoS. If there is no inflation, how will you be able to pay PoW miners to secure the block chain? All coins currently do this in the form of inflation as a block reward.

I will repeat huntercrafterminers wishes not to turn this into a Dpos vs PoW debate, although I disagree with him on a few things. A NaS attack is pretty much impossible on DPoS among other things, but I digress.. I hope you are still considering some form of PoS. Here is a really good write up describing possible attack vectors of DPoS and comparing it to PoW.. I will just leave the link here. https://bitsharestalk.org/index.php?topic=6638.0

We will read here when the pre sale start?
Plz write in op too!

The official launch date will be published ahead of time.
it will be in the OP and on major website in order for everyone to have a fair opportunity to participate. 

I'm sure it's to late as of now but just in case this OS may provide some help in development.

http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs

Nice!
Note that such a mesh can be implemented over Zennet.
Zennet gives you almost nothing but bare metals.

BTW, are you still questioning why not BTC?

I'll be very glad for a deep discussion on the coin's algo. In particular, I'd like to see you fighting with the anti-DPoS guys :)
I didn't find yet alternative to DPoS that is 'less worse'.

Now I recall that HMC found some kind of vulnerability in DPoS. He calls it the "kill switch": an ability of the genesis block generator to erase the whole chain and restart it.

another storj?

Not at all.
https://bitcointalk.org/index.php?topic=736447.msg9415127#msg9415127

Hi Ohad

I am very pleased that you have a project like this. As a firm believer of DPOS. It is well fitted for the project to use the technology Dan and the rest of Invictus have developed. The transaction time itself is blazingly fast and its confirmation. I'll be watching this project and to whatever you guys chose to adapt as to what blockchain technology is concerned, anything goes. As long as I would be happy to be part of this.

Thank you for your kind offer.
I will get our crypto developer involved in it.