Quote from: jojkaart on October 15, 2012, 05:40:03 PM

I think you're missing a key point about how this system would work. There's no contracting, just proof of work done. You receive proof that someone mined for you and you add them to the next coinbase with equal expected value, then you mine until you find a share and send that share over as a proof of the returned work you did. Then you remve them from the coinbase you're mining. If you receive another share from them, you add them again. This forms a chain reaction that continues until one side defects.

I understood that but I don't see how it will work in practice: who will decide to make the first share for free? What happens during network disconnects or miner downtimes ? If you allow them how do you protect yourself from leechers that will simulate these events.

Quote from: jojkaart on October 15, 2012, 05:40:03 PM

The cost of getting this started, even assuming 99% leech ratio is a very minimal investment. If someone doesn't reciprocate, no problem, you just ignore them for the rest of the session. Once you've found enough reciprocating partners, even the minimal losses stop.

This needs to be modeled and computed. As I said there's not only bootstrap but error recovery to do.

Quote from: jojkaart on October 15, 2012, 05:40:03 PM

Pool hopping is a very specific way to benefit from a pool that uses the proportional payment method. Redefining it in the way you have does not really serve any useful purpose. If you wish to discuss ways miners could realistically cheat on each other in this system, that could be quite productive in getting this system fleshed out better though. I highly doubt there are many ways to do that though.

I mentioned 2 above: bootstrap leeches and share ignoring masquerading as error or downtime. If a node has more network errorr or downtime than yours do you blacklist it? If you do and everyone does nobody can participate. If you don't you accept to work for others for free even if it's only for a small amount. Imagine you protect yourself from say any 5% leech (some node that doesn't reciprocate for 5% of your shares) by dropping any node with such a behaviour, what do you expect will happen if someone decides to bombard each of the participating nodes with a DoS attack (a simple SyN flood for example) in turns? Every node will start to blacklist DoSed nodes and you will end up with a fully disconnected setup where you'll have to rebuild the trusts between every node from scratch.

Quote from: jojkaart on October 15, 2012, 05:40:03 PM

Quote from: gyverlb on October 15, 2012, 03:50:52 PM

When you say there is no "promise of a cut" you are playing with semantics again: a share with a coinbase giving a percentage to one address must be a promise of a cut: it means that its miner was using a coinbase that will give this address a cut if a block is found. The miner who owns the address wouldn't start working on a coinbase giving back the same amount of work if it didn't consider that the other miner will continue working with a cut to it in the coinbase so these shares are indeed a "promise of a cut". If you don't agree with the share being a promise of a cut, the alternative is pretty bleak: there's no way for a miner to check that reciprocity is met and so the system is wide open for cheating.

The crucial difference to promises here is that the main method of operation is not promises. It's proof of work done. No proof, no more cooperation. Nothing this algorithm does is based on trusting promises. It's very cheap to to try if another miner is willing to reciprocate, it can be with a miniscule fraction of the share's value (which is, at this moment around 1636 satoshi per difficulty 1 share). If they don't reciprocate, no problem, just forget about them. After a short startup period, the miner will have a list of other reciprocating miners and can stop looking for new ones.

The problem is that your proof can be missed for perfectly innocuous reasons that happen regularly to all participants: the cooperation will thus eventually stop between them all. If you allow for a margin of error, you give a way to cheat. Any way you look at it, the problem is that by eliminating something like the sharechain you eliminate any way for participants to verify reliably that a proof of work really exists and agree on this. So you break anything that would rely on this missing agreement.

Quote from: jojkaart on October 15, 2012, 05:40:03 PM

Quote from: gyverlb on October 15, 2012, 03:50:52 PM

Sorry but this protocol seems full of big holes and I really don't see the advantage: I'm not even sure what the "needlessly strict pool boundaries" are. Would you advocate a system where there is no pool at all and everyone should look for individual partners with a local "reciprocity daemon" finding/maintaining partners and checking that everything is going on nicely? That would be a mess: with p2pool we have ~200 users (and it's arguably high variance), should I contact them all to setup the thing? What about small miners, who would bother contact them (they don't help your variance much, so why bother)?

This is still an unrefined idea that I'm slowly fleshing out. Yes, a "reciprocity daemon" is pretty close to what I'm planning. However, I don't understand your criticism. Are you trying to say that because no-one is using this, no-one will use this? There are lots of different options to use for peer discovery. Are you trying to say that none of them work?

I'm just saying that there are problems popping everywhere in my mind when I look at this. Maybe the easiest to understand is the one I just wrote above: this is a system based on trust but you don't have a way to reliably determine the trust you can have in another node.

Quote from: jojkaart on October 15, 2012, 05:40:03 PM

This could be done in a p2p way or in a centralized way. The centralized option could mean that a server, much like a pool server, would function as a switch connecting different miners to each other. The main difference to a pool would be that you wouldn't need to trust the switch, the worst it could do to you is to not relay your data.

I'm not sure what a centralized option would bring vs p2pool for example (it is trivial to setup a separate p2pool pool if you want to mine amongst friends). Any central server would be a SPOF so why not just use p2pool?

Quote from: jojkaart on October 15, 2012, 05:40:03 PM

The other difference to a regular pool would be that you could use several different switch servers at the same time. I'm also thinking it'd make sense for the miners to use this connectivity to exchange new transactions with the nodes they're cooperating with.

The p2p way would resemble the switch server in that every node would do the tasks of a switch but only for a few nodes. a Bitcoin-style broadcast network could work. I've been toying with the idea of having nodes relay shares to others but only when the share contains both it's own address and the address of the one relayed to in the coinbase. There would only be a few connections per node, so useless connections would be replaced until useful ones were found. I expect this would naturally cluster the network so that once you find a reciprocating node, you find tons of them at the same time.

If you select based on addresses as you will try to have the most addresses in a single share (if I understand correctly it's a direct consequence of wanting to have the less variance thus the most other participants) a single share will be broadcast by all nodes owning one address in a share to all other nodes this is O(n^2) traffic. You want to fine-tune this by only forwarding shares if you are its miner (or delegate this work to someone else which means accepting to forward shares for others too: same traffic in the end) but even then it's still O(n) traffic. This is not good, "network collapse"-level not good (if you see this project used by more than small loosely-connected teams of 10 nodes).

To make it usable, you want O(1) network traffic if you can and worst case scenario O(log(n)). So here you have another show-stopper until you find a way to reduce this traffic to something not linearly dependent on the number of miners you want to reciprocate with (note: small miners are the most impacted by this as they want more links with others than large miners in order to achieve the same variance).

I know I sound overly negative but all my dev instincts tell me the direction you want to go is a dead end and all common questions you ask yourself when designing P2P networks (error handling, network scaling, robustness to attacks, partitioning events handling, ...) don't have clear answers, only difficult or arguably impossible problems to solve. This isn't even taking into account the acceptance factor : miners cringe when you mention a potential single digit percent loss of revenue and giving work for free to be accepted in such a scheme will simply make them run away.