[PRE-ANN][ZEN][Pre-sale] Zennet: Decentralized Supercomputer - Official Thread

[XNext]

When for ICO?

[1713941531]

1713941531

[1713941531]

1713941531

[sdersdf2]

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?

[provenceday]

will watch what happens later.

[xenmaster]

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?

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.

[xenmaster]

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

[takayama]

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?

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

[BTCat]

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.

[xenmaster]

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.

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.

[seek4dream]

keep an eye on it.

[studio1one]

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?

Dude,

please

stop posting this on every single thread.

[sdersdf2]

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?

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?

[studio1one]

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?

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

[dexX7]

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 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 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:

1. Publisher A broadcasts an announcement (ann) to the blockchain, saying it is seeking providers. The ann contains information about the required systems in terms of hardware capabilities, and the publisher's IP address.

2. Provider B polls on the blockchain. Once an ann that matches its filter is found, it connects to A's IP address.

I'd like to quote Satoshi:

We define an electronic coin as a chain of digital signatures. (...) The problem of course is the payee can't verify that one of the owners did not double-spend the coin.

We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend.

In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions.

The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post [2-5]. The timestamp proves that the data must have existed at the time, ...

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 (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:

One would naturally ask: why isn't Xennet planned to be implemented over Bitcoin? The answer is mainly the following: in order to initiate a micropayment channel, it is necessary to deposit money in a multisig address, and the other party has to wait for confirmations of this deposit. This can make the waiting time for the beginning of work to last 30-90 minutes, which is definitely unacceptable.

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 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!

[ohad]

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 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 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:

1. Publisher A broadcasts an announcement (ann) to the blockchain, saying it is seeking providers. The ann contains information about the required systems in terms of hardware capabilities, and the publisher's IP address.

2. Provider B polls on the blockchain. Once an ann that matches its filter is found, it connects to A's IP address.

I'd like to quote Satoshi:

We define an electronic coin as a chain of digital signatures. (...) The problem of course is the payee can't verify that one of the owners did not double-spend the coin.

We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend.

In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions.

The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post [2-5]. The timestamp proves that the data must have existed at the time, ...

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 (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:

One would naturally ask: why isn't Xennet planned to be implemented over Bitcoin? The answer is mainly the following: in order to initiate a micropayment channel, it is necessary to deposit money in a multisig address, and the other party has to wait for confirmations of this deposit. This can make the waiting time for the beginning of work to last 30-90 minutes, which is definitely unacceptable.

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

[ohad]

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.

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.

[dexX7]

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 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?

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?

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

[ohad]

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 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?

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?

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.

[SalimNagamato]

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

[ohad]

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

[smokim87]

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:

-Publisher Alice puts her announcement into the blockchain, that she's seeking a defined hardware capacity.
-Provider Bob polls the blockchain looking for announcements within his capacity. Seeing Alice's announcement, Bob connects to Alice's IP address.
-Alice and Bob challenge each others' keys – the key pair of their blockchain addresses – to verify each others' identity.
-Bob tells Alice what hardware he has available, the two negotiate a price, and after payment is made Bob creates a virtual machine that Alice accesses over SSH.

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