0

I'm kinda new to smart contracts, searched a lot, but hope someone here can help me out.

I'll try to explain as good as I can. I'm mining Ethereum with a couple of rigs.

Each individual rig auto-sends the ETH to a specific ETH address via pool. So now I have multiple (30+) ETH addresses that are receiving ETH. Very frustrating to check every address and send the ETH to my main account by hand.

Is there a way that I can auto-send ETH from each account to my MAIN account with a smart contract (solidity)?

Let's say; Address 1 receives 0.1 ETH, auto send (immediately after transaction comes in) 0.1 ETH to MAIN ETH address.

The addresses are receiving different amounts of ETH, some 0.1 ETH some 0.05 ETH, etc. No matter what amount is send to the mining address, it must be transferred to the main account.

I hope someone can help me out with this.

Edit: Example

0x0000ADRESS1: 0.1ETH

0x0000ADRESS2: 0.3ETH

0x0000ADRESS3: 0.2ETH

0x0000ADRESS4: 0.1ETH

(Write an smart contract for each address above, when ETH is in above addresses, transfer ETH to MAIN)

0x0000MAINADRESS: 0.7ETH

2
  • function () public payable { mainAccount.transfer(msg.value); }
    – user19510
    Apr 13, 2018 at 12:41
  • Thanks @smarx for your responds. But could you explain a little bit more what you mean by the above line? Like I said, im kinda new to smart contracts. Apr 13, 2018 at 13:02

2 Answers 2

0

it doesn't work quite like you seem to think and that makes it sort of challenging to answer directly with some advice that won't lead to long learning curve.

In Ethereum, you have externally owned accounts (EOA) (wallets) and contracts, both of which are represented by addresses and are barely distinguishable in the smart contract language. Nothing ever happens on the chain unless someone signs a transaction from an EOA. Contracts run code when they receive a message.

In particular, no EOA or contract can spend money from someone else's account. Contracts receive money and send it just like a wallet. So, we can't really make a contract that sucks the money out of the addresses. We could, conversely, deploy contracts under the control of the various accounts and the various accounts could sign transactions to kick things off, but how would that address your goal? See the issue?

Your goal can be achieved with a reasonably simple Hub and Spoke design with the Pool payments going to contracts that are Spokes. Spokes forward all funds received to a Hub. Hub lets a privileged user (you) withdraw funds, and Hub let's you generate new Spokes, inspect the list of spokes, and so on.

I feel that example code might just be leading you into a project of unexpected complexity because you would have to get accustomed to something a little foreign compared to how things work presently.

Hope it helps.

2
  • Hi Rob, thank you so much for your very detailed information. This explains a lot. I understand now that this is not the way. Is there a possibility that I can get a work-around by creating some kind of script directly on to the mining rig, Let say, that I create a script that, when a payment comes in, the script automaticaly signs a transaction to my main account? (without the use of a smart contract i mean) Apr 15, 2018 at 7:51
  • Thet's not infeasible. You could probably rig up something to run periodically and check if the coinbase account has a balance > 0 and forward the funds. You could also consider copying the keys from the keystore folder (if using geth) and just importing all those accounts into a wallet on one workstation. That might be even better - no code. Apr 15, 2018 at 8:15
0

I understand we cannot simply forward ethers received in a contract:

To receive ethers in a contract you will need a function in it with no params and return value, i.e. a fallback function marked as payable. But (as documentation http://solidity.readthedocs.io/en/v0.4.21/contracts.html states) when ethers are being sent, such fallback function is limited by 2300 units of gas, and the operation of sending ethers just consumes more gas (ibid).

Thus, sent ethers will have to stay in contracts that receive them. You'll need a supervisory contract which contains a list of the receiving contracts. You'll need a function (like transferEthersUp()) in the receiving contracts which will transfer ethers to the supervisory contract. Also you'll need a function in supervisory contract (like collectEthers()) which would iterate all the receiving contracts and call the transferEthersUp() function.

To collect ethers you just periodically call collectEthers().

Of course, there will be some important security issues to implement: to check that only the supervisory contract may call transferEthersUp(), to check that only the contract owner may call the collectEthers().

And unfortunately, this collection service will cost you some additional gas.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.