Topic: Mining pools as payment processors? (Read 1534 times)

Note though, I'm not sure myself it could actually work as I've layed it out. 

I'm about to reread the TOR idea thread now and I see you were one of the more prominent advocates of paying with mining hashes there. With a service like this, TOR users could choose for themself wether they wanted to mine with their own computer in real time or pay for the hashes, thus allowing people with lesser hardware to buy bandwith as well.

I see. That's an interesting exchange. I'll have to think about that some more.

The point is that paying with mining hashes have some advantages and some disadvantages over paying with bitcoins. The problem I'm trying to solve is any situation where the advantages outweigh the disadvantages. Right now though, I'm just trying to wrap my head around how valuable the advantages are and how you can minimize the disadvantages.

Some advantages:
Mining hashes can be instantly verified. You don't need to wait for a confirmation.
It will leave no public link between payer and payee in the block chain. Most hashes won't be of a valid block. It's just proof-of-work of a specified value. Those hashes that do create a valid block will be hidden among all regular mined blocks.
It allows microtransactions to a bigger degree than bitcoin itself.

One example where all of these properties could be useful is to pay for bandwith in an anonymous network in real time.

There are also some disadvantages.
The most prominent as far as I can see is that the payer needs to trust the payment processor to make good on their promise. However, the payee still does not. This could possibly be solved through smart contracts somehow.
If the pool server gets compromised, payment information could become public, but no more than what would normally have been in the block chain. This risk could also be minimized by making mining hash payments between multiple pools before sending to the true destination as I mentioned in my previous post. Then all of the pools need to be compromised to link payer to payee.

The point is you're not getting any coins back. You are getting mining hashes back directed towards an adress of your choice at a time of you choice, that may or may not create a valid block. Say I have an account at "the deepbit payment processor pool" and I want to make a payment to you. You give me an adress. I give the adress to deepbit who diverts the mining power of the pool to create hashes of the expected value of the payment. I get the hashes and give them to you. You can check that they represent real proof-of-work the same way a pool operator does.

The point I wanted to make was that the money availible for mining is not fixed. It can be increased if the standard method to deposit at pools where to make it through mining fees. If you wanted to deposit at a pool and I wanted to make a payment of the same sum, then the miners that gets to create my hashes could be compensated by your fee to the pool.

Then you're just getting your and other people's coins back, same as a regular mixer.

What problem are you trying to solve with this?

Couldn't you "deposit" money at the pool by giving them a transaction with a fee of the amount you want to deposit? That would solve the problem of the limited supply of "hash coins". The pool operator rewards himself with the "deposited" coins and saves them to reward his miners when he needs to divert their hashing power. You could even hide your deposit by creating "regular" transactions to yourself with fees to the miner that looks normal.

Yes, the centralized server is a disadvantage. Matching payments will be a lot harder than with mixing pools though, if not impossible, since you will be hiding among all the regular miners. The biggest problem of many mixer schemes is that there are too few users, which will not be the case here.

If you are really cautious I guess you could actually use mining hashes to transfer money from one pool payment processor to another. The first pool would only have the bitcoin adress of your original deposit and of the second pool, but not of the end destination. The second pool would only have some mining hashes that it accepted for payments and the end destination of those coins, but not your original deposit adress. If you do this thrice you would actually have a scheme that is pretty similar to how TOR works, but for bitcoin payments. The pool in the middle would actually not have a single one of your bitcoin adresses. It would only serve to seperate the first and third pool who respectively has your deposit adress and destination adress.

If you take the right precautions, the worst case scenario, if all the pools you use collude or get compromised, the information they would get would be no more than what would have been found in the block chain if you had made direct bitcoin transactions instead.

It would need to go down similar to the p2p-pool method too I guess:

From a TOR user side:
You choose an arbitrary fresh address.
You transfer bitcoins to that address.
You run the payment client, that generates transactions to the TOR nodes based on their price policy published in the alternate sharechain and sends these transactions along with the TOR packets.

From a TOR node side:
You choose an arbitrary fresh address.
You publish a price policy (like "0.01 Bitcent per MB, offering at least 1 MB/s speed per node") + payment address + IP address to the alternative sharechain.
You publish any transaction you receive from your TOR packets to the alternate sharechain (or not, if you feel charitable)
You run a small miner (can run on FPGA, GPU, maybe even CPU?) to make sure that price + IP information gets republished at least every 24 hours, as you might need to inclde this information personally (you can't trust other miners, and why should they include your competitive prices?), also as proof that you are still online.

For developers:
You create an alternate "sharechain" where you show via proofs of work as a TOR node that you are still online + what's your current payment address and via transactions as a user that you are able/willing to pay for the bandwidth you already consumed.
Once the pool pops a bitcoin block, the generation transaction goes to the miners, paying for their work and the bandwidth transaction(s) are sent to the TOR-nodes. TOR publishing information gets stripped out (via merged mining) to not bloat the BTC blockchain.

This might even be possible on top of the existing p2p-pool, as it would not really impact miners anyways or run independently, which however might take longer until TOR operators are being paid. Double spending is only possible until the pool finds it's next block and would be easily detectable as soon as it pops up in the BTC sharechain. I'm sure it will be done, however I doubt that it would be done to a great extent.


The idea is not fully fleshed out, but I already published a similar idea ("using mining shares as microtransactions") a few months ago...

The weak link is similar to most mixer schemes: it relies on a central server to receive your coins and control the pool.  If that server is compromised or if the payments in are too easily matched to the payments out, your anonymity is broken.

It has the advantage that you're guaranteed that the new coins aren't associated with any other prior activity which may draw unwanted attention to yourself.

It has the disadvantage that there is only a limited supply of coins available through mining.  Widespread use of such a service would drive difficulty up, increasing the cost of the service (and generally making mining less profitable).

The idea came to me when I read the TOR thread about trading mining hashes rather than actual bitcoins to incentivize TOR nodes in a more anonymous way. I'm not sure it's entirely feasible though so I need some input on the idea. But lets say a pool started an internet wallet service where you can deposit bitcoins. You deposit 10 BTC, and the pool credits you with future proof of work worth of 10 BTC. When you want to spend your bitcoins to someone else you get a bitcoin adress, give this to the pool, who then diverts 10 BTC worth of hashing power towards this adress (minus an arbitrary fee). The 10 BTC you initially deposited would be used to reward the miners so they don't lose anything from diverting the hashing power. Once you get the hashes, you give these to the person you wanted to pay who can check their integrity to know their value. (and that person may actually be part of a pool himself and relay the hashes to it so he gets bitcoins without variance).

I have no idea if this is actually a good idea or even technically reasonable, but it seems to me like this would be a way to remove the block chain link between payer and payee. The payer would only be linked to the pool he deposited at. The pool wouldn't even know who it is contributing hashing power to. And the payee would get newly minted bitcoins straight from a block reward, or from another pool.

Now is the time you rip this suggestion to pieces.