Here is a thread I started a while ago seeing if it would be feasible to heat your house with GPU's. To see if the heat created and coins generated could outweigh the cost of heating a home normally.

https://bitcointalk.org/index.php?topic=320984

Anyone want to convert the math for the current bitcoin ASIC's see how many you might need to fully heat a house?

 

If you're intention is to get the chips hashing as fast as possible, ignoring power costs, then a TEC (Thermo electric cooler) plus a massive heatsink (even better a water cooled head on the back of the TEC) is the way to go. You can get the temperature of the chip well below ambient, which means you can get it colder, while still moving heat away just as air or water. Next option is an oil bath, which unless you can get the oil temperature well below ambient, then it can only move the heat but not cool the chip to super lower levels because you can only cool it to ambient; unless of course you refrigerate the oil, or have some cascade of heat pumps.
 You can buy water-cooled TEC plates there!
 Oil cooled pc in a fish tank

If along with electricity you have free time on your hands you could build a ASIC dry ice pot. This is a large thick copper cylinder with one closed and one open end, the closed end sits on top of the chips and into the cylinder you very carefully place acetone and dry ice chunks and make a "slurry" and its super super cold! But you have to feed it dry ice for 24/7 so it doesn't overheat from evaporating the dry ice off. Some people even use liquid nitrogen in the pot.
Good picture of a dry ice pot

If you have a lot of free electricity, time, or money you could buy an entire AC unit for you asics, or build your own. This uses a "head" akin to a water cooling "head" that is placed on the chip, but instead of water, freon or some suitable chemical is ran through it. It is compressed and held at some pressure at a liquid, it is then pumped onto the hot chip, and evaporates taking heat with it, then it is compressed with a compressor and cycled back through. These can get below ambient too.
A phase change system for a computer with one head

The coolest thing you could do if you have a lot of all of that stuff we all want a lot of. Then you could build or buy a thermo-acoustic cooler. This thing is bad-ass, it can get within a few degrees of 0 kelvin, but I don't think it moves much heat at that point. But you could find one suitable for the chips heat output, and not have to feed it dry ice, or freon, or air, or water. It uses sound pressure waves to cool a "stack" of straw like cylinders, it works super well and its super cool. Ben and Jerry's actually started using them in all of their freezers for ice cream and to make it because they are so easy, cheap, environmentally friends, and super cool.
Thermo-acoustic cooler article/link

But way before any of those become useful, i think you'd reach the chips physical limits. I have no idea about your specific hardware, but first run the chips and measure their temperature at increasing clock speeds and voltages, see if cooling is necessary.

What do you mean by "to game the ranking algorithm"?

---------

I am saying this on the assumption that this network would require a huge amount of data to be stored between all of the nodes, if that is true I think it might be more feasible for each node to have only a subset of the entire rank list. There would be many copies of the list stored by many nodes, when a search is done a consensus is taken from the nodes that respond to the search request as to what the results should be.

The required amount of copies of information about a page in the rank list is the amount of other pages linking to that page. So if there are 10,000 links to a site, then there should be ~10,000 nodes with that sites(and its into links) information. Every time a node responds to a search results and returns a set of nodes, it "releases" that pages information to a new node which then takes in the links, crawls the web and checks them, and then "waits" for searches to them and the cycle continues.

I think this would provide a very small probability that one entity could control all of (or most of) the nodes that contain the current link information for a page. Thus assuming everyone works together to creates good links and page ranks, then it should work out that an attacker would have to control the entire network or a very large amount to effect search results.

What do these kernels represent? (CubeHash_2W.cl, Echo_8W.cl, Luffa_1W.cl, SHAvite3_1W.cl, SIMD_16W.cl) I recognize SHA-3, but what are the others? SIMD, single instruction multiple data.? I'm not familiar with any of the mining algorithms yet, I know the names just not their implementations.

For a parallel programming class at my university I need to implement some sort of parallel computation. It is a broad as that. I was thinking to do something involving crypto-coin mining. I would really like to try to optimize a current algorithm or try to implement something new in parallel. Obviously people are already trying stuff like this and I am trying to get a good understanding of where everything is currently at some I might find something I could contribute to for my project.

I was wondering if anyone might have any ideas that would be interesting and useful to the community. I will have about 6 weeks to devote to it so it can't be a massive under taking.

 

How long has it been since you started mining on the pool, you need to give it some time to "stabilize". It needs time to create a good running average of your workers performance.

Looking at the mining instance it says your best share is 4.71K, so I figure you haven't been mining very long on the pool.

I had the idea of a P2P search engine. Its informal and I have no real plans to develop it (yet?), but I just wanted to share it and get opinions or ideas.

So the "search engine" would be miners/nodes on the network. There would be two jobs for the miners. They would need to crawl the web and produce the massive page rank array that is then used by the other miners to service search results. Miners would be paid in "coins", which could then be sold to users. The page rank array would be akin to the block chain, but it only evolve on a local level based on the miner crawling the web and adding to its part of the array.

So their is proof of work, namely crawling and adding to the web; there would have to be miners that "fight" the crawlers to verify that the crawlers are creating proper links otherwise the proof of would would easily be could by just submitting garbage data.

Also proof of work for the miners who search their local copy of the page rank table to produce search results for users, these would be correlated over the network (multiple "miners" would hold duplicate page rank data) to produce a final results with an "accuracy" rating based on which miners agree as to the results of the search.

There could also be proof of stake for "miners" who just hold part of the page rank array and "occasionally verify" with the network; they would hold "stronger" links in the web, basically pages that always link to each other and have for a long time. This would keep malicious miners from overtime slowly changing search results in their favor.

---------

Obviously that's a lot, not well thought out, missing logic, and I'm not sure if I understand proof of stake versus proof of work. But I just wanted to bring it up for discussion.

Could you rephrase that slightly? I am not sure if you mean it will work or,

There is no speed up over what is already implemented? or,
The Bitcoin Core already sneaks some code onto the GPU, and is already fully implemented? or,
The GPU would be of no advantage, the most parallel it can become can be ran on a 2+ Core CPU as fast as possible (High step complexity overall)?

Ahh I see. So I might launch a kernel to verify a block. I would have to pass the block data, along with a pointer to an array of unspent coins in device memory, so that it can do this referencing "[sic]up and down" the chain. The issue is though that the RW bandwidth to the device memory would be massive. You would have to do a lookup on it once per unique address in the blockchain, because at some point all coins are unspent.? (is that correct logic).

To get around this you propose to verify all blocks in parallel, and write any unspent coins for each block into memory. Then do a second pass and verify for each unspent coin that it has some link in the blockchain? Then remove that unspent coin from the list, and if the list is empty after the algorithm runs then the chain is verified?

// I read a lot of the wiki in the past, I need to get back to it. Thanks for the reminder!

Have you contacted ZenMiner?

I take it you don't have the txn id?

How long has it been since you withdrew the btc from the site?

Andrew,

I think a much better question I now have. What are the steps involved in verifying the block chain?

1. Verify each transaction (highly parallelizable? )
2. Verify each block hash.. ~300k hashes, could be done in serial
3. ... ?

So a big issue you have encountered is that transactions many blocks away from each other that reference each other mean a breakdown in the parallelizability? (that is an awesome word) Because if you wish to verify a single block you might have to look far up or down the chain to find if that specific address really does have x btc to send to another address in the current block?

I am taking a parallel computing course at my university and we are supposed to do a semester long project on anything related to the course material. I have decided that I wanted to do something with Bitcoin or cryptos.

My idea is to fork the current Bitcoin Core wallet. The fork will have a feature to verify the blockchain on a local GPU to offload the work of verifying blocks on the CPU. This is what miners do, though they are trying to find the hashes, I wish to verify.

This idea came about after watching my CPU sit at 100% for a few hours after doing a fresh install of the Core wallet on a new desktop and waiting for the blockchain to verify.

My questions,

So I want to know if this is a feasible idea, from everything I know it is, but I haven't dug into the code yet at all?

Would this be useful? I would assume as long as the chain is being downloaded fast enough to provide the GPU with work it would be. I think for testing I will just copy a blockchain data file to a new Core wallet install and see if my software or the original verifies faster to prove the idea.  

Any general ideas or concerns?

EDIT: I had another idea. I think it would be a lot easier to just write a standalone chain verifier... Give it a file path of the chain you want verified, set some GPU parameters, and let it rip through it.

Hello new to the thread but old to the pool. I was wondering I have always been paid out, but I just never understand when the payouts happen. Can anyone explain the scheduling of payouts?

I haven't been following along on the entire crypto scene lately and was looking for some information.

At one point I found a website just like http://coinmarketcap.com/ that had a column for the coins difficulty, algorithm, etc more mining stats. Could someone direct me to one?

The reason I ask ifs because of a coin I seem to be being switched to whilst mining on http://clevermining.com/ servers. The coin is showing as having a difficulty of 1.59G, this just seems off to me and I was wondering what coin this is and why its difficulty is so high. PIC: http://imgur.com/SB8ymtJ. (Using SGMiner 4.0.0)

Also, I was looking into getting an ASIC (don't worry no impossible questions) specifically from http://gawminers.com/. From what I have found the website/company seems legit and are shipping. I don't care about profitability ROI etc, I just would like a simple $50 scrypt ASIC, is the site legit, no horror stories etc? Could someone give me a quick rundown of the companies/sites currently "in the game"?


EDIT: The coin is at 1.65G now, I changed the post title to match my picture though.

I am trying to follow through the steps in the link below to find the average generation time.
https://en.bitcoin.it/wiki/Generation_Calculator
 

• Get the current target.
• Divide by 115792089237316195423570985008687907853269984665640564039457584007913129639935, which is the maximum value of a 256-bit number. You now have the probability of a single hash solving a block.
• Take the reciprocal of the probability to get the average number of hashes to solve a block.
• Divide the average number of hashes by your hash/s (not khash/s) to get the average number of seconds required to solve a block.

So the current target is given here, http://blockexplorer.com/q/hextarget, in hexadecimal format. Converted to base ten it is

38110290672195532365762668664552282566878756832852091863040


If you use this number in the calculation above it comes out to be right, if you use the difficulty you get a number that is hugely off.

Why is this not the same value are the one reported in mining software, such as CGMiner, it reports 707M. All websites also list it as 707M and not the number above.

Is there a way to go from 707408283 (Bitcoin difficulty) to 38110290672195532365762668664552282566878756832852091863040 (Bitcoin target)? Are those the proper names for the two?

Ah. The hashing info is calculated taking into account the payout address?

Found this https://en.bitcoin.it/wiki/Block_hashing_algorithm So the block header is comprised on the following components

Component          Reason                                                                                            Updated
Version                Block version number                                                        You upgrade the software and it specifies a new version    
hashPrevBlock       256-bit hash of the previous block header                            A new block comes in    
hashMerkleRoot     256-bit hash based on all of the transactions in the block        A transaction is accepted    
Time                   Current timestamp as seconds since 1970-01-01T00:00 UTC    Every few seconds
Bits                     Current target in compact format                                        The difficulty is adjusted    
Nonce                 32-bit number (starts at 0)                                                 A hash is tried (increments)    

So a transaction is verified if it makes sense based on the nodes blockchain, it is then added to the blockchain and the merkle root is recalculated(?).

When someone is mining, do they add the transaction that pays them out to the blockchain they have, changing the merkleroot, and then hash it and broadcast it? This way someone can not change where the payout goes to without rehashing/doing a crapton of work.


--

Seeing as that fails, what if someone was still able to gain control to all of the nodes one person is connected to?

I guess the most they could be is an annoyance.
They could just not broadcast new blocks to the node, and send it random transactions (generate tons of transactions to and from themselves). If this is done to a node that holds a considerable portion of the networks computational power though, it would weaken the network making it easier to perform a legitimate 51% attack.

From my knowledge,

A mining pool works in the same way as solo mining. Software acting as node on the network calculates the current blockheader based on its blockchain, and passes this to mining software. This software continually hashes this blockheader looking for the target. For a pool, the pool owners software calculates the blockheader and passes it to its workers/members and they hash the pool owners blockheader.

A question I pose,

The pool owner, or node on the network, receives information from other nodes it is connected to about the current state of the bitcoin blockchain (new transactions, new blocks, longest blockchain). If someone were to control all of the nodes connect to the pool owner, couldn't they edit the block broadcasted from the pool and change the payout address to theirs?

I guess the larger problem I see is if someone were to control all of the connections to someone who has found a block, couldn't they broadcast it altered in their favor and have it accepted faster than the block finder themselves? One because the block finder cannot tell anyone about its block, and two by the time they might find a new connection the network has already accepted the altered one?

To put it differently, if the network is visualized as nodes with a certain weighting of computing power, if you were to control enough nodes around at least 51% of the computing power couldn't you alter the blockchain to your favor? So say the two biggest pools are 21% and 30% of the network collectively but only have 1% of the connection to them (not sure how large/small connection to overall network could be/is), if someone could obtain control of those nodes couldn't they broadcast the work done by the pools to more people than the pool can in the same time?

The second or third reply to the beginning of this thread is "Won't go above .022 ltc/btc anytime soon"

anytime soon = ~15days.