Could proof of Blockchain (PoBC) be the solution to ASIC industrial mining?

[StuffOfInterest]

Several things going on in Cryptocurrency and Bitcoin in particular have been bothering me.  First, mining is becoming increasingly centralized into industrial operations.  Second, there is no incentive for people to operate a full node with blockchain history.  Third, specialized hardware (ASIC) is causing a runaway in difficulty and removing any possible RoI for small miners.

I have an idea which could address all three issues to at least some degree. 

Most coins out there today use proof of work (PoW), proof of stake (PoS), or a combination of the two.  Proof of work has led to the runaway difficulty out there as the only way to make more is to add more hashing power.  We are far beyond the amount of hashing power needed simply to keep the network secure.  Some of the estimates of power useage for mining claim enough wattage to run a city.  Proof of stake has its own issue.  Sitting on a stake means that there is a counter incentive to using the currency for transactions.  This leads to hoarding rather than economic activity.

What if we tried a proof of blockchain (PoBC) model?  In order to generate a valid hash you need access to the entire blockchain or at least information from every block in the blockchain.

Currently, in Bitcoin, a hash is generated as follows:
   sha256(sha256(block_header))

I’d like to see a hash generation done this way instead:
   sha256(sha256(block_header)+history_block_hash))

1. Start with the header of the block being worked. 
2. Generate the first sha256 checksum.
3. Use the last 32 bits of that checksum as an index into the blockchain history which could return anywhere from the first block up to the last block generated before the one being worked.
4. Use the selected history block to generate another hash (more on that later).
5. Append the history hash to the first header hash.
6. Generate the outer hash over the header and history hashes.

As for how to generate the history hash I can see three methods of doing it.  Each requires a different amount of information to be available and the technique selected can be determined if you want to give the miner a chance of keeping the entire working set in memory or if you want to ensure frequent trips back to disk (unless the miner has terabytes of RAM).

1. Use the hash of the selected block (smallest amount with only 32 bytes per block needed).
2. Use the header of the selected block with the current block inner hash appended and then generate a hash on this (80 bytes per block needed).
3. (my favorite) Take the entire selected block with the current block inner hash appended and then generate a hash on this (requires the entire blockchain to be available).

So, why would we want to do this? 

First, it should stop the ASIC miners in their tracks.  For even the smallest history dataset above you would need to have 16MB of working data per year of blockchain if the block generation time is set at one minute.  The ASIC can’t store this much information internally so it will be going back to an external store for every computation.

Next, it promotes having more copies of the entire blockchain on more computers.  If you want to mine, you will have to dedicate more hardware and storage.  This will make it much harder for the industrial size miners to scale up as they can’t just add racks of ASIC chips.  There are ways of scaling but they will require high speed networks or lots of storage per mining node.  I’m not even sure a GPU miner will work under this model.  It may be better to go back to the old days of CPU mining.

I’m curious if anyone has explored a concept like this for an altcoin.  I see this as being a way to force a coin to scale out since anyone wanting to mine will need to operate a full node containing the entire blockchain.

I’d also like to come up with a way to prevent too much hashing power from being concentrated on one copy of the history.  If anyone has an idea for how this could be achieved I’d really like to hear it.  This would be another way of preventing the industrial miners from sucking all the air out of the room.  I’d much rather see 100,000 small miners (and full network nodes) than 10 giants.

Hope this can spark some discussion.  I decided to post it under the altcoin area since I don't think the existing Bitcoin could be modified to incorporate such a concept.  Plus, it would be so disruptive to the status quo in Bitcoin that it would never be accepted if it could be done.

StuffOfInterest (hobby miner, programmer, and what if idea speculator)

[MarketNeutral]

ASICs are good for bitcoin. They do not lead to centralization any more than GPUs do. Pre-ASIC bitcoin had more threats to its network and was less secure than post-ASIC bitcoin. Remember the days when GPU-based pools had over 51% of the hashing power? ASICs make the network stronger. Centralization is indeed a problem, but it is not a function of ASIC technology any more than marketing, pool features, trends, etc. Moreover, Bitcoin is a payment system designed to be used for transactions of buying and selling goods and services in a secure, trustless manner. Bitcoin is not designed to enrich new adopters or make things "more fair" for the latecomers. I'm not averse to innovation, but I am skeptical of proposals that reinvent a system that seems no more secure than Satoshi's. Perhaps some more details would persuade me?

Personally, I trust sending large amounts of bitcoin over the bitcoin network precisely because it is has ASICs securing it. I would have less trust in the bitcoin network if it used another means to secure my bitcoin transactions.

[MarketNeutral]

Despite my devils'-advocate post, I really would like to see some discussion about this idea. It seems far more interesting than cobbling random algos together and mistakenly claiming it's ASIC-proof.

[BitJohn]

Several things going on in Cryptocurrency and Bitcoin in particular have been bothering me.  First, mining is becoming increasingly centralized into industrial operations.  Second, there is no incentive for people to operate a full node with blockchain history.  Third, specialized hardware (ASIC) is causing a runaway in difficulty and removing any possible RoI for small miners.

I have an idea which could address all three issues to at least some degree. 

Most coins out there today use proof of work (PoW), proof of stake (PoS), or a combination of the two.  Proof of work has led to the runaway difficulty out there as the only way to make more is to add more hashing power.  We are far beyond the amount of hashing power needed simply to keep the network secure.  Some of the estimates of power useage for mining claim enough wattage to run a city.  Proof of stake has its own issue.  Sitting on a stake means that there is a counter incentive to using the currency for transactions.  This leads to hoarding rather than economic activity.

What if we tried a proof of blockchain (PoBC) model?  In order to generate a valid hash you need access to the entire blockchain or at least information from every block in the blockchain.

Currently, in Bitcoin, a hash is generated as follows:
sha256(sha256(block_header))

I’d like to see a hash generation done this way instead:
   sha256(sha256(block_header)+history_block_hash))

1. Start with the header of the block being worked. 
2. Generate the first sha256 checksum.
3. Use the last 32 bits of that checksum as an index into the blockchain history which could return anywhere from the first block up to the last block generated before the one being worked.
4. Use the selected history block to generate another hash (more on that later).
5. Append the history hash to the first header hash.
6. Generate the outer hash over the header and history hashes.

As for how to generate the history hash I can see three methods of doing it.  Each requires a different amount of information to be available and the technique selected can be determined if you want to give the miner a chance of keeping the entire working set in memory or if you want to ensure frequent trips back to disk (unless the miner has terabytes of RAM).

1. Use the hash of the selected block (smallest amount with only 32 bytes per block needed).
2. Use the header of the selected block with the current block inner hash appended and then generate a hash on this (80 bytes per block needed).
3. (my favorite) Take the entire selected block with the current block inner hash appended and then generate a hash on this (requires the entire blockchain to be available).

So, why would we want to do this? 

First, it should stop the ASIC miners in their tracks.  For even the smallest history dataset above you would need to have 16MB of working data per year of blockchain if the block generation time is set at one minute.  The ASIC can’t store this much information internally so it will be going back to an external store for every computation.

Next, it promotes having more copies of the entire blockchain on more computers.  If you want to mine, you will have to dedicate more hardware and storage.  This will make it much harder for the industrial size miners to scale up as they can’t just add racks of ASIC chips.  There are ways of scaling but they will require high speed networks or lots of storage per mining node.  I’m not even sure a GPU miner will work under this model.  It may be better to go back to the old days of CPU mining.

I’m curious if anyone has explored a concept like this for an altcoin.  I see this as being a way to force a coin to scale out since anyone wanting to mine will need to operate a full node containing the entire blockchain.

I’d also like to come up with a way to prevent too much hashing power from being concentrated on one copy of the history.  If anyone has an idea for how this could be achieved I’d really like to hear it.  This would be another way of preventing the industrial miners from sucking all the air out of the room.  I’d much rather see 100,000 small miners (and full network nodes) than 10 giants.

Hope this can spark some discussion.  I decided to post it under the altcoin area since I don't think the existing Bitcoin could be modified to incorporate such a concept.  Plus, it would be so disruptive to the status quo in Bitcoin that it would never be accepted if it could be done.

StuffOfInterest (hobby miner, programmer, and what if idea speculator)

I love the idea now about the implementation.

[r0ach]

We will need the Sunny King batphone for this.

[r0ach]

I’d also like to come up with a way to prevent too much hashing power from being concentrated on one copy of the history.  If anyone has an idea for how this could be achieved I’d really like to hear it.  This would be another way of preventing the industrial miners from sucking all the air out of the room.  

I talked about that in this post:  http://bitcointalk.org/index.php?topic=395769.0

The only thing I could come up with is ditching Bitcoin's "infinite" wallet address solution and making it so each user only has one wallet, which makes it much easier to assign global variables to the system to cap people's possible mining rewards per day.

So basically, the "fairer" the coin, the less privacy you get unless it also implements native coinjoin or something like that.

[mek300]

Several things going on in Cryptocurrency and Bitcoin in particular have been bothering me.  First, mining is becoming increasingly centralized into industrial operations.  Second, there is no incentive for people to operate a full node with blockchain history.  Third, specialized hardware (ASIC) is causing a runaway in difficulty and removing any possible RoI for small miners.

I have an idea which could address all three issues to at least some degree. 

Most coins out there today use proof of work (PoW), proof of stake (PoS), or a combination of the two.  Proof of work has led to the runaway difficulty out there as the only way to make more is to add more hashing power.  We are far beyond the amount of hashing power needed simply to keep the network secure.  Some of the estimates of power useage for mining claim enough wattage to run a city.  Proof of stake has its own issue.  Sitting on a stake means that there is a counter incentive to using the currency for transactions.  This leads to hoarding rather than economic activity.

What if we tried a proof of blockchain (PoBC) model?  In order to generate a valid hash you need access to the entire blockchain or at least information from every block in the blockchain.

Currently, in Bitcoin, a hash is generated as follows:
sha256(sha256(block_header))

I’d like to see a hash generation done this way instead:
   sha256(sha256(block_header)+history_block_hash))

1. Start with the header of the block being worked. 
2. Generate the first sha256 checksum.
3. Use the last 32 bits of that checksum as an index into the blockchain history which could return anywhere from the first block up to the last block generated before the one being worked.
4. Use the selected history block to generate another hash (more on that later).
5. Append the history hash to the first header hash.
6. Generate the outer hash over the header and history hashes.

As for how to generate the history hash I can see three methods of doing it.  Each requires a different amount of information to be available and the technique selected can be determined if you want to give the miner a chance of keeping the entire working set in memory or if you want to ensure frequent trips back to disk (unless the miner has terabytes of RAM).

1. Use the hash of the selected block (smallest amount with only 32 bytes per block needed).
2. Use the header of the selected block with the current block inner hash appended and then generate a hash on this (80 bytes per block needed).
3. (my favorite) Take the entire selected block with the current block inner hash appended and then generate a hash on this (requires the entire blockchain to be available).

So, why would we want to do this? 

First, it should stop the ASIC miners in their tracks.  For even the smallest history dataset above you would need to have 16MB of working data per year of blockchain if the block generation time is set at one minute.  The ASIC can’t store this much information internally so it will be going back to an external store for every computation.

Next, it promotes having more copies of the entire blockchain on more computers.  If you want to mine, you will have to dedicate more hardware and storage.  This will make it much harder for the industrial size miners to scale up as they can’t just add racks of ASIC chips.  There are ways of scaling but they will require high speed networks or lots of storage per mining node.  I’m not even sure a GPU miner will work under this model.  It may be better to go back to the old days of CPU mining.

I’m curious if anyone has explored a concept like this for an altcoin.  I see this as being a way to force a coin to scale out since anyone wanting to mine will need to operate a full node containing the entire blockchain.

I’d also like to come up with a way to prevent too much hashing power from being concentrated on one copy of the history.  If anyone has an idea for how this could be achieved I’d really like to hear it.  This would be another way of preventing the industrial miners from sucking all the air out of the room.  I’d much rather see 100,000 small miners (and full network nodes) than 10 giants.

Hope this can spark some discussion.  I decided to post it under the altcoin area since I don't think the existing Bitcoin could be modified to incorporate such a concept.  Plus, it would be so disruptive to the status quo in Bitcoin that it would never be accepted if it could be done.

StuffOfInterest (hobby miner, programmer, and what if idea speculator)

Make a coin out of your idea instead of discussing it any further.

[jrretirement]

Interesting, so tell me do you have the capacity to code such a novel idea into reality?

[StuffOfInterest]

I think I picked the wrong forum to post this on.  Too much junk coin pump and dump traffic drowning out threads.  Just since last night this dropped onto the second page, which is nearly a death sentence.  Can anyone suggest a more development oriented forum worth moving to?

Interesting to hear people saying just code it.  Not that easy.  I may have the ability but definitely not the capacity at this time.  Full time job and family see to that.  Besides, any successful coin is going to be developed by a team rather than an individual.  Implementing something like this is not trivial.  In particular, existing mining software would need considerable change to support history lookup.  This isn't just swapping in another algorithm.  The miner would need to use an outbound API to retrieve blockchain history blocks.  Either a wallet or the core node software would have to support incoming calls for this API.

Although the easiest route would be to just hack up the stock Bitcoin-QT client I'm really tired of seeing so many clones of the same software being developed.  Something needs to be built from the ground up.  I do like the plan floating in the Bitcoin development community to split the wallet function out from the core node software.  I operate a node on my PC but I have no interest in the wallet portion.  Having them separate removes some of the bloat.

Pools would be an interesting adaptation.  I haven't looked deep enough into the Stratum protocol to see if it will already work.  My gut says yes as all the miner software really needs is the header and a range of nonce values to work on.

Another benefit for this whole scheme came to mind last night.  Requiring access to the entire blockchain history makes malware miners difficult.  Too much data to push onto someone's PC and keeping the history updated would generate too much traffic.  If the coin was possible, I'm sure someone would try but detecting it should be a lot easier.

Another idea to consider if this were to turn into a coin.  Block reward halving acts as an incentive for miners to leave a coin just before the halving event.  Rather than halving at set intervals I'd suggest using a percentage decline over a long period.   If the drop was somewhere around 1% it wouldn't be as big of incentive for miners to jump.  As long as the new reward value is run through a floor function to avoid fractionals then the reward will eventually reach zero.  It all comes down to a function of desired final coin count, time per block, time to reach final count.

[StuffOfInterest]

Just throwing more ideas in here for the heck of it. 

Relating to my earlier musing on the rate of decrease in the block reward, perhaps a more elegant solution is possible.  There has been talk about inflation vs deflation of coins and what possible benefit and drawbacks that has.  What if the size of the reward for a block was related to the transaction activity of the currency?  In the beginning, the coin will need a set rate of generation (block reward) to build up a basic supply.  Once a certain threshold is reached the issue then becomes having sufficient currency to use in transactions.  If 1000 units of ?coin are changing hands per day then a smaller block reward is needed to keep sufficient currency in play than if 10,000 units of ?coin are changing hands. 

Doing something like this would require a transaction fee to act as a disincentive for people to move coins around just to simulate activity and boost the block rewards.

Any adjustment of the block reward should also be limited to a max percentage up or down to avoid runaway inflation or deflation.  Let each adjustment have the goal of the block reward being a set percentage of the total transaction activity over the last 'x' blocks but that adjustment can not exceed a change of 'y' percent from the current block reward.  If 'x' is kept low enough it should have a stabilizing effect on the overall amount of currency in circulation to account for lost wallets.  It will also help to keep the currency exchange rate more stable with fiat currency over time as those tend to have a slow inflationary trend as well.

I'm not throwing out specific values for 'x' and 'y' as I think some serious modeling would need to be done to establish sustainable behavior.

One guiding principal I've been keeping with my theorizing here is that the goal of a crypto currency should not be to make anyone rich.  It should have the goal of providing a stable, sustainable, efficient means of economic activity.

[dogechode]

This is a pretty cool idea though I don't know if it would be technically feasible. Is there some absolute rule that ASICs can't just modify their onboard memory?

[StuffOfInterest]

This is a pretty cool idea though I don't know if it would be technically feasible. Is there some absolute rule that ASICs can't just modify their onboard memory?

If I understand the ASIC miners correctly it would be difficult to give them enough memory or they would end up bandwidth constrained.  Most ASIC miners use multiple chips.  For one chip to work efficiently you would need the entire blockchain available on the ASIC.  I believe the Bitcoin blockchain is around 15GB and growing, so that is far more RAM than practical to build into one chip.  An ASIC board could have a shared pool with the blockchain that all chips use, but then you run into the bandwidth issue of all these chips trying to talk to a shared memory space.  I'm not even sure a GPU can be made efficient under these circumstances.  The card won't have enough RAM to hold the entire blockchain so there will be lot of traffic going up and down the PCIe bus as every hash computation will require a different history block.

Unrelated, I have a name idea for my hypothetical currency.  "Trade Units" or "Trade Unit Currency".  I'm sick to death of of everything ending in "coin" and I see this as a measurable unit used to facilitate economic activity, or trade.

[dogechode]

Well if it ends up creating a viable crytpo that actually thrives via CPU mining and can't be easily GPU or asic-mined that would be awesome.

I think I remember someone talking about a currency called trade units before but I could be wrong. You could call it "Barter."

[PereguineBerty]

The crypto scene needs more lateral thinkers like this i.e. people who can take a step back and see the bigger picture.

[StuffOfInterest]

The crypto scene needs more lateral thinkers like this i.e. people who can take a step back and see the bigger picture.

Thanks, I'm trying.  I just wish I had the spare cycles to work on the software aspects right now.  Ideally I'd prefer to not just clone Bitcoin-QT yet again but that may be the most expedient way.  I've been doing a little studying of the Bitcoin wire protocol and even started work on a wire traffic listener (in C# if you can believe it) but my spare time is so limited I'm not sure how far I'll be able to get.  My hope is really to inspire someone to take up some of these ideas and run.  In the long run, I don't care if my name is attached as long as something viable results out of the efforts.

[Spoetnik]

The crypto scene needs more lateral thinkers like this i.e. people who can take a step back and see the bigger picture.

or needs more little shit mouth piece trolls ?

[BombaUcigasa]

Second, there is no incentive for people to operate a full node with blockchain history.  
Third, specialized hardware (ASIC) is causing a runaway in difficulty and removing any possible RoI for small miners.
What if we tried a proof of blockchain (PoBC) model?  In order to generate a valid hash you need access to the entire blockchain or at least information from every block in the blockchain.
...
I’d like to see a hash generation done this way instead:
   sha256(sha256(block_header)+history_block_hash))
...
1. Use the hash of the selected block (smallest amount with only 32 bytes per block needed).
2. Use the header of the selected block with the current block inner hash appended and then generate a hash on this (80 bytes per block needed).
3. (my favorite) Take the entire selected block with the current block inner hash appended and then generate a hash on this (requires the entire blockchain to be available).

So, why would we want to do this?  

First, it should stop the ASIC miners in their tracks.

1. Store hashes of each block in the memory, no need to keep the blockchain. You can even have a full node and thin miners accessing it to bootstrap and update. There are 297838 blocks with 256 bits for each hash, requiring at least 4Mb of RAM... easily possible to store inside most ASIC miners.

2. Same as above.

3. This requires some extra latency and some variant of 1. You only need to request the block on demand, store it (less than 1Mb of RAM and hash it).

You should also consider this:

ASICs will always exist for EVERYTHING and ANYTHING. Building a computer with only the minimal components required for this job (no fancy CPU cache, no RAM slots, no fancy chipset, no audio or peripherals) will be possible at a lower cost than generic brand computers. There will be companies making these, and people buying them, and the same thing will happen as it does now, these computers will be single purpose (or hardly re-purposable and up-cyclable). It will be just more complex and less efficient.

As for efficiency, the same economic sunk cost into the security of the network will provide the same results no matter the method. But hashing slower than current methods, and involving extra steps will cause the clients to boostrap slower (they need extra database seeks to obtain and confirm blocks) and will cause more orphan blocks (as each node needs to seek the blockchain and confirm the block is correct).

Forcing more resources for a more wasteful and less eficient method of securing blockchains is just silly and won't have the results you want.

[BombaUcigasa]

The crypto scene needs more lateral thinkers like this i.e. people who can take a step back and see the bigger picture.

or needs more little shit mouth piece trolls ?

Someone has a case of the mads today. Here, fix it: https://www.youtube.com/watch?v=9uvIGrnA_3I

[qbits]

What if we tried a proof of blockchain (PoBC) model?  In order to generate a valid hash you need access to the entire blockchain or at least information from every block in the blockchain.

Currently, in Bitcoin, a hash is generated as follows:
   sha256(sha256(block_header))

I’d like to see a hash generation done this way instead:
   sha256(sha256(block_header)+history_block_hash))

1. If you require that hash(X) < Target, then one needs to iterate over parts of X in order to find suitable result thus proving certain amount of "work" has been done to find that solution and secure the transactions, making this a PoW coin.

2. There have been numerous discussions in this and litecointalk.org forum whether or not hash function should be memory hard and consequently deterring developments of asics. Although I'm personally on the anti ASIC side of the fence I believe there is more than one argument to consider here which is why I like your idea.

3. Allow me for a brief digression here: I'm not buying the argument that high hash rate makes network any more secure as for example I could develop a super machine that hashes at 100x the speed of all other miners in the network and by the logic of the hash rate=security network would be 100x more secure once I deploy it, however if I really did this I doubt anyone would consider the network (with one miner only) more secure.

4. So only a distributed network with lot's of users and miners makes the coin secure, assuming no such disruptive technology with potential 100x (or 1'000'000x) speed-up can be easily developed. (Which is a stretch I know)

5. ASICs clearly work against this principle as no one I know can tomorrow buy an ASIC device for mining bitcoin or other coins that would actually make a ROI. Just for the sake of example everyone I know can buy a PC with a GPU in any number of local stores tomorrow and mine some X coin with reasonable expectation of making a ROI. If I (and others) could buy an ASIC in a local store and use it to get my investment back I would sit on the ASIC side of the fence. ASIC developers over price their products making ASICs not friendly to miners.

6. Please note that mining pools also work against point #4 as due to economies of scale large pools are by definition: better funded thus more reliable and secure, better developed, probably offer better customer experience and offer lower variation when mining, so they attract more miners  creating a situation where top 5 pools by size control more or less most of the hash rate of a coin. So attacking say Litecoin would probably require taking out top 5 pools which is lot easier than developing "100x" machine from point #3.

7. So I think your idea would be perfect if it could solve both those problems. As someone on this thread correctly pointed our that adding a hash of some previous block to the header before hashing it would not do the trick as hashes of previous blocks could be precomputed I would go further to say that adding arbitrary memory requirement to the hash function would not work in the long term either as there is no real reason why ASIC developers could not bolt arbitrary amounts of memory (even DRAM or disk) to the ASIC as well still this makes development of such machines more difficult. I believe current term for such a coin is "ASIC resistant".

8. I propose (as you have) that the hash function only works efficiently when miner has access to the whole blockchain. For example sha256(block_chain_data(sha256(block_header))

9. I propose that hash function does not work efficiently in terms of forming pools (this may be impossible)

10. Thus miner variance should be made small by other mechanisms. Small block time does not work, but making the whole network act as a one giant p2p pool probably would. I was thinking something along the lines of allowing all miners to submit blocks with lower than network difficulty. Such blocks would not be considered as final as long as someone actually submits a block with lower than network difficulty. Then all miners would be paid proportionally to their contribution. This would open up problems with coinbase transaction which in an naive implementation could not be properly hashed, but this could be worked out by for example coinbase transaction would not be left to the arbitrary address generated by the miner but would rather be automatically generated to send coins to contributors of the previous round. Since all clients are aware of who these contributors are or rather what are their addresses everyone should be able to verify if coinbase transaction is correct at the time block is mined.

And yes this should be a new coin. Bitcoin will never accept change of this magnitude. Question is: can we put together a team to develop it? Personally I would join in. My suggestion would be that we spend a lot of time planning before we take on coding.

Name: BlockChainCoin or BCC
Any thoughts? Anyone?

[emontmon]

Is honeypenny Implementing this idea already