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!
