No there is no way to do it in a trustless manner. The 'script engine' used by bitcoin has no knowledge of the outside world and that includes any agreement you may have with the hashing provider, the terms, rates, or the network hashrate.
In general problems like this can only be solved through the use of trusted oracles. You could make a p2sh address (scripthash) produced from a script like this:
(You OR Provider) AND (m-of-n oracles)
This would give a reduced trust requirement but it wouldn't be trustless. Instead of it being will the provider defraud you it becomes will the provide be able to collude with m trusted oracles to defraud you. Still even if this could be done in a trustless manner it probably wouldn't. Most cloud mining are simply ponzi schemes. Those that are legit are using the acquired fees to purchase hardware and expand their operation. To have funds locked up for the duration of the contract would be expensive making them less attractive.
A better system would be one that uses payment channels:
a) the cloud operator allows you to direct hashrate where you wish
b) you and operator agree to use payment channel to handle micropayments worth of hashrate (i.e. x GH/s for 1 hour)
c) you and operator settle up periodically with a single on-chain transaction
That would truly be 'pay as you go'. The operator could never abscond with more than an hour's worth of prepaid computing power.
Topic: 2 questions re multisig transactions for cloud mining (Read 1091 times)
I proposed this in another thread but don't want to pollute it with an unrelated discussion.
"Would there be a way of making the fee to the hashing provider dependent on the completion of an agreed term with a multi sig transaction? eg I buy 1BTC's worth of agreed hash rate, which the mining pool pays out to the multisig address, then at the end of the term I get the mining output sent to me and the hash provider gets their fee?
If the hashing stops halfway through I get my fee refunded plus the mining output. That's also a way of betting on the network speed via the return of investment for the hash provider as I would hope to get more than my fee back. There may also need to be some kind of oracle involved in confirming the hash rate was as high as promised. I'm not sure if something like this has already been done before?"
So my 2 questions are:
1. Is there a viable way of making this work where both parties can trust each other via the blockchain, and potentially end up winning based on what they originally agreed on? - eg a slower network hash rate would mean the customer gets more BTC than their fee, faster hash rate means hash provider got more in fees than they would have made mining.
2. For ongoing expense payments is it possible for a multisig transaction script to include multiple payments to the hash provider over time? such as "for every day the contract is valid and hash rate is maintained, pay out a fixed portion of the fee to the hash provider?"
"Would there be a way of making the fee to the hashing provider dependent on the completion of an agreed term with a multi sig transaction? eg I buy 1BTC's worth of agreed hash rate, which the mining pool pays out to the multisig address, then at the end of the term I get the mining output sent to me and the hash provider gets their fee?
If the hashing stops halfway through I get my fee refunded plus the mining output. That's also a way of betting on the network speed via the return of investment for the hash provider as I would hope to get more than my fee back. There may also need to be some kind of oracle involved in confirming the hash rate was as high as promised. I'm not sure if something like this has already been done before?"
Cloudmining companies would have to cough all the investment, pay ongoing costs and not get a dime until the completion of the contract. No one would do that.
Maybe you could do something with smart contracts, that pay out automatically in function of difficulty, btc price and some agreed upon fee structure, but its hard for me to see how you can avoid having ~2x the money at stake in escrow some place or in the blockchain. After all, theoretically the contract could become worthless, so the seller must have a guarantee (your money in escrow) and the contract could pay out many times the purchase price over time, so the buyer would need a non trivial fraction of that in escrow as guarantee as well.
Maybe you could do something with smart contracts, that pay out automatically in function of difficulty, btc price and some agreed upon fee structure, but its hard for me to see how you can avoid having ~2x the money at stake in escrow some place or in the blockchain. After all, theoretically the contract could become worthless, so the seller must have a guarantee (your money in escrow) and the contract could pay out many times the purchase price over time, so the buyer would need a non trivial fraction of that in escrow as guarantee as well.
So my 2 questions are:
1. Is there a viable way of making this work where both parties can trust each other via the blockchain, and potentially end up winning based on what they originally agreed on? - eg a slower network hash rate would mean the customer gets more BTC than their fee, faster hash rate means hash provider got more in fees than they would have made mining.
2. For ongoing expense payments is it possible for a multisig transaction script to include multiple payments to the hash provider over time? such as "for every day the contract is valid and hash rate is maintained, pay out a fixed portion of the fee to the hash provider?"
Jump to: