Topic: Offline mining? - page 2. (Read 16685 times)

Is this 2TH/s computing also "free" in... -i dont know- your tuition fee?

Not only you're stupid, you're lack of morals .... a great combo of failure

DeathandTexas and Sadpandatech - I admit I have some research and consulting with others to do to understand the importance of your advice.  I need to construct a working model in my head of exactly what this will entail.  Thanks for the help!

Plastic.Elastic - What do you do to relax?  Electricity is "free" as defined by my lease.  I don't need your definition.

aye, Poolservj has work caching, etc. Without using it I am guessing. But it appears it can be set to only send new works on block changes. It also forms the getwork request localy, freeing up resource use on the bitcoind itself.

for C it does have idle detection but I believe it is capable of being on or off.

Best way to find out is get a box setup with VM and run bitcoind/PSJ and break out the ol ethereal on it. Slap as many mining instances as you can pointing at it. You can run multiple miners on one GPU for example to help simulate multiple connections. Get a few hours run and observe your packet counts and system loads and multiply it up.



*takes his rabbies shot and offers Plastic.Elastic a hug*

Where did you see me saying you have access to 2TH in your basement? Did god forget to put a brain in your skull? or is it your parents?

Its the definition of "free" that you dont understand. Loser

IIRC PoolServerJ supports custom difficulty (difficulty >1 ) not sure if there is any upper limit.  PoolServerJ also support n-time-rolling but not sure if there is a max limit.  If anything the changes would be small.  To minimize LAN communication you would want to ensure PoolServerJ doesn't send updated work when new transactions are added and merkle tree changes. 

Essentially you would want
a) large difficulty (the difficulty reduces the amount of share traffic submitted).  2TH combined would find 456 shares per second.  A difficulty of 100 would make that ~5 shares found per second.

b) long n-time-rolling.  Not sure if there is a max limit or any bugs that would happen from  10 minut n-time-rolling period.  Likely just needs to be tested.

c) Ensure PoolServerJ only sends LP when block is detected on network.  Just need to check to make sure there are no "keep alive" code, updates for transaction pool changes, and "idle miner" detection code.

Thank you both DeathAndTexas and sadpandatech.  If you think of anything more, I really would appreciate it.  On the off chance that what I'm thinking of might actually come to fruition, both of you will be compensated heftily.

excellent points as always from you! =)  I do recall seeing some talk of such a feature in the mining software section. Do you recall if such a feature was already implemented into one of the pool server softwares?  *goes off to try and hunt it down*

cheers

If you needed to you could run a custom version of pool server designed to reduce LAN communication.  You could send one getwork to each machine w/ a 10 minute n-time-rolling.  Each local miner would hash the same block header and simply increment the time locally.  The pool server would simply issue a LP on each block change.  Using a larger difficulty for shares (since you don't care about share variance) could reduce the number of shares submitted by 90% or more. 

All together intra-LAN communication could be cut by at least 90%.  More is possible but the higher variance would prevent shares from being useful for monitoring on pool server.

Make sure your custom server rig has 2 network adaptors in it. As you will need one to bind to the VM and one for the server. It may even be ideal to run 3 net adapters and 2 pools to try and split some of that hash up. Depending on resource usage and handling. I am not real sure just how resource intensive poolserverj, for example, can be with so much processing going on.  And you will surely stress the net adapters with all of the getworks.  Might even have to go, 2 bitcoind's, 2-4 pools , with appropriate number of network cards. atleast those are cheap. ;p
If I think of anything else I will add it. ;p

cheers

This is beautiful.   

I quite like the possibility of solving around 30 blocks per day.

 

tl;dr solution; set in place 1 computer running a bitcoind daemon in VM. On same computer a server running pool server on a LAN IP that is capable of pointing to daemon on dif IP. The VM will have it's own net access via cell phone usb, etc. So isolated from the hashing network.  Simply point your hashers at the LAN pool. viola, they are isolated from the net and you are left with only a VM bitcoind communicating out.

Yeah.  Because, you know, I really want to attempt to squeeze out 2 T/hash using the free electricity I get from renting a room of a house that was built in the 1950's.

Got to 1 T/hash before my clothes started to melt into my skin.

Do you really need to ask?

Look up the fucker's thread history, you will see his thread about "free" electricity

I'm not suprised, he got another "free" computational power some where....

Was no-one else curious about how he would have access to 2 TH?

Thank you for this!

Well, statistically, you have about a .5% chance of being more intelligent than I according to 'g.' 

Do you know what projection is?

helluva nice explanation .  I think I may have understood that

If you can't connect the computing power to the internet (or some other method of updating the miners) it is useless for mining.  

Remember you need to be solving the next block.  Every 10 minutes "somebody' solves a block.   When that happens your data is stale and if you find a block it is useless as you are solving the wrong block.  A farm which could only connect to the internet once every minute would be horrible inefficient (stales) but would work.   On average you would lose 10% of your hashing power because the data has gone stale and you won't know it until the next update.  Still 2TH * 0.9 = 1.8TH effective.

Longer periods of time between updates will quickly make it impossible to work on the same blockchain as everyone else. Your only hope would be to build a longer chain in private and publish it all at once.  The problem is that for any extended period of time the odds you will have a longer chain is negligible.

As an example, say you have 25% of network capacity and decide to mine privately for x blocks and then publish them all at once if it is longer than the main chain.  

If x = 1 (connect to internet and publish block chain after finding one block) then you have a 25% chance of having longest chain.
If x = 2 (publish after finding two back to back blocks) then you have only a 0.25^2 = 6.25% chance.
If x = 3 0.25^3 = 1.56%
..
If x =6 0.25^6 = 0.02% (1 in 4096 chance).  Even 6 blocks is only on average 4 hours for a 2TH subnet.

So connecting to the network once every 6 blocks and checking to see if you are ahead would earn you (6 * 50 ) / 4096 = 0.08 BTC and it would take 4 hours.  Note you wouldn't earn 0.08 BTC each time.   You would earn 300 BTC 1/4096th of the time and 0 BTC 4095/4096th of the time.  On average despite having 2 TH you would only earn about 0.5 BTC per day (roughly the same as a 500 MH rig which is continually updated).

Now hypothetically if you have some constraint that you could RECEIVE data but only TRANSMIT every couple hours you could operate w/ full efficiency.  Variance would be astronomical (magnitudes higher than normal solo mining) but you could
1) send any block chain updates to the farm
2) if farm is more than 1 block behind it abandons the chain
4) if farm is ahead by 1 or more blocks and time greater than transmit threshold it transmits.

Since you are winning or losing multiple blocks per batch you are going to face very high variance but your expected return (EV) will be the same.

A true dumbass would never know why ppl call them a dumbass. You're a perfect example of that saying.

Not bad.  How is it running around the evolutionary cul-de-sac?

And in response to SadPandaTech, minimizing net exposure, yes.