Interesting... that is essentially the same problem I just mentioned, and my solution was the same... to count the voices and use the majority mini-blockchain. But it's certainly not as safe as it could be, a fake mini-blockchain could still potentially propagate if the attacker controlled enough nodes.

It's an interesting concept, assign a weight to nodes... perhaps in this case the weight could be determined by how many blocks or units the node has solved. But then this would give a lot of power to the mining pools, if they wished to create a fake mini-blockchain it might be a fairly easy task.

Hmmm... how exactly does a new node on the bitcoin network determine which of the first blocks it receives are valid and which aren't? Or is it just assumed that the blockchain is too long to fake and eventually the longest chain will win out... I would assume that is the answer based on what I've read.

I definitely need to think a bit more about this but it seems there is no simple answer to solving this problem. The solution above doesn't seem fool proof to me and it would only add another layer of complexity to an already complex idea with many layers. I'll sleep on it and check back later.

Ok I think I understand what you're trying to say now. You're saying, how can one be sure the mini-blockchain they receive is even valid, since we can't start at the very beginning and work our way up to the latest point, correct? Well since each block in the chain must be a solution connected to the last solution, the longer the chain is, the harder it becomes for the attacker to form a fake chain which corresponds to the correct solution rules... if I understand it correctly. Changing one block on the end wont achieve anything because it must correspond to the one before it. The attacker must create a whole new mini-blockchain from the starting block, because before that first block we have no history of what happened. It seems to me like the mini-blockchain must be fully formed by trusted parties before the network goes live, because clients would require the full mini-blockchain and not a small portion of it to be safe.

edit: actually now that I think about it, you may have a point. An attacker could take as much time as he needed to form a fully valid mini-blockchain, just like the parties who created the initial one. He could then start broadcasting that mini-blockchain but I'm not exactly sure what would happen, if it would propagate enough to impose a risk of becoming the main mini-blockchain. I think perhaps if you used several different nodes to retrieve your mini-blockchain data and cross-reference the data the risk of building a fake mini-blockchain would be pretty much nothing, I assume that's what bitcoin does too. But again I'm no expert.

Ok, so lets break this down a bit more. The new node would first download the mini-blockchain. Then they would request the latest master hash and other hashes. Then they would check to make sure the hashes they received correspond to the latest master hash in the mini-blockchain, if not they keep trying until they receive valid data. The mini-blockchain is formed in the same sort of group consensus method used by bitcoin, and the more blocks that get put into it, the more integrity it has (obviously we are limiting that integrity though). So the newest master hash in the blockchain has the integrity associated with the size of the blockchain and we can build our address database based in this assumption.

So basically an attacker would need to dismantle the entire mini-blockchain before they could inflict permanent damage to the address database.

The mini-blockchain would provide consensus about which of the current master hashes is correct because the master hashes would be also be saved into the blocks, it seems like an obvious thing to do since each time a block is solved and accepted by the network the master hash will change when the transactions in the block are used to alter the database. So in this way new nodes can see a recent history of the blocks and also the master hashes, and they can easily compute the validity of the blocks along with the validity of the hashes they receive, and thus safely build a copy of the database with help from the mini-blockchain.

edit: just want to add that it's the record of recent history, the nature of how each block hash goes into the next one causes a quick increase in the integrity of that record. This is why it becomes exponentially harder to alter blocks the further back you go. You don't need to go back to the start to get this integrity. By cross-referencing the retrieved data and hashes with the historic data one can be fairly certain they are building the correct version of the address database.

Ask anyone why it's impossible to trim the blockchain and they'll tell you it's because it cuts off data about the location of some coins. A small portion of the blockchain can still be useful in verification, but wont help much unless you have another way to save information about the location of coins.

Good question. Obviously the main problem with this idea is that because we don't have a record of each transaction we can't look back and make sure things happened the way we expected them to happen. What we have is a database which summarizes the current location of all the coins in circulation, and if this can be altered via a 51% attack it may be impossible look back and confirm it was altered in a non-valid way. I think maybe a solution to this is to have a "mini-blockchain". Since we are solving transaction blocks like bitcoin we may as well save some of them into a small blockchain. It could hold maybe the past months activity or something, that wouldn't add much of a burden to the network. So when nodes are building or updating their address database they can refer to the mini-blockchain and make sure nothing suspicious is going on. The mini-blockchain wouldn't be quite as secure as bitcoins huge blockchain but it would provide some of the security bitcoin gets by having a series of interlocking blocks, without putting too much extra strain on the network.

Bitcoin requires the entire blockchain because it doesn't have a database which tells it the location of each coin, but my scheme does so we can trim the blockchain down and still know exactly where each coin is and at the same time get the security provided by a blockchain.

I've been thinking a little bit about this topic lately because it seems to me like the main problem of any decentralized currency which is based on bitcoin, is the ever-increasing size of the blockchain. But there really is no way to replace the blockchain from bitcoin with something else, so another alternative currency would probably need to be created. I understand the basic details of how bitcoin works but there are many complex aspects of it which I don't fully grasp. I'm not certain this idea has the ability work, and I know that even if it could work it wouldn't be as secure as bitcoin, but transactions would be much faster and the data required to download in order to become up-to-date with the network would be set to a finite limit.

At first I considered ways that we might be able to use some sort of decentralized "coin database" which would keep track of the position of every single unit of currency in circulation by attaching public keys to each unit. The owner of the corresponding units would need the private key to confirm his status as the owner, just like in bitcoin. A transaction would simply require peers to shift around numbers in this database instead of adding new data to it. Leaving aside the problem of how mining and confirmations would happen under this scheme, the main problem with this idea is that even for a few billion units the database would still be rather large. Bitcoin has 2.1 quadrillion units in total to ensure sufficient granularity of the money supply.

My calculations indicate that anything past 100 billion units starts to become totally unmanageable if you wish to track every single unit. One trillion units could potentially supply enough granularity but it would be virtually impossible to manage a decentralized database of this size, it would be much bigger than the blockchain already is. So I started to consider other ways this problem might be solved. It seemed to me that there's no point tracking every single unit because many of the units are going to be attached to the same public key. This may be stating the obvious, but what we really need to do is keep track of all the addresses which claim ownership to any units. That is essentially what bitcoin does, but it does it by keeping track of every single transaction (the blockchain).

Even with a population of 10 billion people where each person had 10 different non-empty addresses, we would only need to keep track of 100 billion addresses, which brings us close to the limit before things start to get unmanageable. Under this scheme we can have about 1 quadrillion units which we assume will be spread among a maximum of a few hundred billion addresses. The database would begin empty and as new units were mined (I'll talk about that shortly), and as units were transfered to new addresses, new entries would be saved into the database. Since empty addresses would be forgotten and removed from the database we can keep track of a reasonable number of addresses with some sort of upper limit to what we need to track.

We know that we'll never need to keep track of the 1 quadrillion units because we'll never reach a point where every single unit is stored on a unique address. If you divide 1 quadrillion units by 100 billion (10 billion people with 10 unique addresses each) you get 1 million. So we still have good granularity even with 1 quadrillion units spread among 100 billion addresses and instead of having to manage 1 quadrillion units we only need to manage a max of about 100 billion or so addresses (each with a balance of 1 million units on average). It would also take a while before we started to get even a few billion addresses into the database so by the time we get close to 100 billion or more we will have much better computers capable of handling it.

The way mining would work under this scheme is quite odd. It's still a proof-of-work system, but the mining process would be completely separate from the transaction confirmation process. Each unit from 1 through to 1 quadrillion would be mined separately from every other unit. The proof of work would be finding a hash of the miners public key and the unit number (numbers from 1 to 1 quadrillion obviously) and the changing iteration number. So the miner would need to find a special hash using something like hash(PubKey+UnitNum+Iteration). Like bitcoin, each miner would be attempting to solve a different problem since their public keys will differ. Higher number units will be more difficult to solve. It will increase in steps, maybe in steps of 1 million.

Ideally the protocol would specify static per-determined difficulty levels which are calculated so that all the units aren't mined for at least 100 years, but we couldn't enforce an exact time. The difficulty should increase as some type of exponential function like bitcoin, but I don't think it should start too easy. So this would create a dynamic where the lower numbered units are mined first and as we get higher and higher it becomes exponentially harder and harder to mine new units. When a miner solves a unit he would broadcast the solution over the network and the address database will be updated by nodes who accept the solution. The newly mined unit would be added to the balance of the public key (the miners address) associated with the solution.

If the public key is not already in the database it will be added to the database and cause its size to increase. As normal, owners of an address would prove their ownership with the private key. Like bitcoin, transactions would be created as some sort of signed script thingy and would be broadcast over the network. Nodes who accept the transaction would update their own copy of the database by shifting around coins or doing what ever needed to be done. But how would nodes who go offline get updated when they come back online? They would need some way of discovering which address balances have changed and what new addresses exist. This is where my knowledge sort of hits its limit but I have some ideas about how it may work.

I'm not sure, but it may be possible to use some sort of time-stamping solution where we would attach a last modified field to every every row in our address-based-database. So nodes could search for changes in the database where the last modified value is newer than some specified value. This still doesn't ensure exact consistency between nodes however, and a more appropriate solution may be to group our database entries into "blocks" and attach a hash to every block in our database. So along with our address database we would have a list of hashes which correspond to a set of entries in our address database. And from these hashes could perhaps be made a master hash which indicates the current state of the entire address database.

So when the balance of an address changes, the "block" or group of addresses in which that address is located will get a different hash, and therefore the master hash will also change. So nodes could see changes to the database and discover the newest version of the database by requesting the master hash from peers and confirming its validity (read comments). By looking at the individual "block" hashes they can see the general area where the changes have occurred without having to analyze every single address for a change. Then once they gain the updated information for that "block" they can check it hashes correctly. So there is no need to download any historical transaction data, all that's relevant is the current balance of addresses which hold funds.

Removing emptied addresses will also provide an extra layer of privacy which bitcoin cannot provide. And while I think the system I just described for updating the database could potentially work, there's another problem we must deal with when the database is updated in this fashion. As I've described it, transactions don't need to be solved in groups of transactions as blocks (blocks used in the bitcoin sense now). But if we are basically going to keep track of our database with a set of hashes and a master hash, we can't allow every single separate transaction to alter the database on demand. We must break them up into groups of transactions which are inserted into the database in periodic intervals of time, 1 or 2 minutes seems ideal but I'm no expert.

But for this to happen in a coordinated fashion we still require the groups of transactions to be solved like blocks in bitcoin, so it would seemingly still require fees and miners to solve those blocks. But since units are mined separately from this transaction confirmation process, miners of these blocks would only be paid the transaction fees and miners of the units would only be rewarded with fresh units and not the added fees. This is what is supposed to happen with bitcoin once all the coins have been mined; miners will only receive transaction fees from the blocks they solve. So it should theoretically work if we separate the transaction confirmation process from the mining process. But will anyone even mine transaction fees if they can mine new units?

Lots of interesting questions to be examined here... I'm still not certain anything like this could work, but I think it's a plausible idea. I mean I don't want to destroy bitcoin or anything and I think bitcoin would still have many advantages over this system, they would both have their own niche. For example I don't think something like what I have described here is capable of providing all the advanced transaction features offered by bitcoin. But I mean with the rate at which bitcoin is growing we need some other good decentralized currencies to take the pressure off bitcoin. Bitcoin clones with small tweaks will never really compare to bitcoin but something like this could provide us with truly fresh and unique advantages over bitcoin.

edit: just want to add some more thoughts... when the "unit miners" broadcast their solution, that solution will probably need to be lumped in with the transaction blocks which are solved periodically to maintain consistency. The incentive for the "transaction miners" to include this solution into their block is that they could get a cut of the profit... but how is this possible if the units are mined individually. One single unit cannot be split up. So I'm thinking instead of having new units mined individually, they would be mined in groups of 1000 (or probably something much larger) to provide a big enough cut to the transaction miners. Instead of hashing every single unit number you would use the number of the first unit in the current group. So if the rewards come as 1000 units it would be 0, 1000, 2000, etc.

edit: read comments to see how this idea has been extended to incorporate a "mini-blockchain" for extra security.

No problem, the .htaccess file from HTML5 Boilerplate really seems to speed up any website a lot. It's probably also because the script doesn't use any complex PHP framework, it's basically just pure PHP coded as simple as it can be.

In your case you need to create a new database within cpanel and then log into phpmyadmin and select the database you created. Then click on the SQL tab and paste the text from the mysql_db.txt file into the text area and hit the Go button. Now your BitShop database has been created and you should be good to go once you save the database connection settings into the main config file.

Well I find it a bit odd that no one ever knew about this limit before. How can that be when we've always had people saying we need a larger block limit? How can that be when anyone can look at the blockchain and see there is a limit, and that anything past that limit gets rejected? Maybe I'm not understanding the problem correctly but this baffles me... how could the limit be unknown.

Not being aware of a certain property/feature of BDB does not make that feature a bug.

It's interesting to see the two different sides of this debate. Is 0.8 the problem because it doesn't conform to the established rules of the system or are the older clients the problem because they use a crappy database which can't handle large blocks?

From what I can gather it seems to me like the database used by 0.8 is much more superior, so it will be used. But in order to patch 0.8 it seems like an artificial cap will be placed on the block size so that 0.8.1 is compatible with older versions.

Obviously this was the best solution to apply and I'm glad the hard fork route was not taken. Such a route needs to be properly planned and even then it will be difficult to coordinate a change such as an increase in the max block size.

But do we really need to increase the max size of blocks? I don't know all the technical details behind bitcoin, but it seems to me that if 1 block is being saved into the blockchain every 10 minutes then the max size should be limited to something relatively small.

Will it ever be possible to upgrade to a client which can support these large blocks? Seems to me we're going to be stuck like this.

Nice work, even though I'm not entirely sure what a compressed key is.

But as I said most of that bitcoin.lib.php file wasn't made by me.

It is a very useful library though with the functions I added to it.

You can create a thread about it if you like, but I don't think it's necessary.

No it doesn't offer any type of auction or ebay-type functionality unfortunately.

Thanks for the very nice feedback Luke. It certainly is hard to find shopping cart software tailored for selling digital items and I think the merging with bitcoin really helps make it unique. Thanks for your help with the debugging too, it was very helpful.

EDIT: btw folks check out Luke's website, now powered with BitShop:
http://cdkey-hut.com/

New and far superior version of BitShop has now been released. If you saw this script before you will know just how far it has come now. See the second post in this thread for a list of changes. I have only just uploaded this new version to my server so if you experience any problems please let me know. Thanks guys.

If you looked it up properly you would know bitcoin is a fiat currency.

Thanks for response, I'll reply to your above points quickly but I need to get some sleep so I'll pick up the discussion later if you respond. The first thing I want to point out, is that if gold were used as the most common currency (whether it be in the form of gold certificates or real gold), the elite actually have a motive to keep a certain level of gold in circulation, because without that lower threshold in circulation economic activity would stutter and come to a halt, meaning their businesses would also suffer as a result and they would see their incomes dry up. There's an inherent point of stability.

Second of all, most of the money ends up in the hands of the rich even if we use fiat money, through the processes I explained. And in fact by trying to fix this problem by creating more fiat money to even out the waters, the long term end result is that they simply make the problem worse than it was to begin with because of the wealth funneling process that I described. That's exactly what is happening right now, the vast amount of the currency in circulation is not in active circulation, but rather in the bank accounts of the super rich; but they always leave us with just enough to conduct our business.

And as we continue to inject more and more money into circulation as a futile attempt to solve all our problems, the continual funneling process creates an ever growing gap between the rich and poor, rather than stopping at the inherent point of stability associated with sound money.

Well I respect the guy after watching some of his doco's, but his opinion on Bitcoin is obviously completely invalid because he appears to know nothing about how it works. Anyone who doesn't understand it is obviously going to be skeptical of the claims made. And also the concept of bitcoin undermines his basic premise that we "have two choices" for who controls the money; private banks or the Government.

Bitcoin relieves us of choices and makes the process entirely decentralized. Clearly this is more desirable than allowing the Government to control money. His trust in the Government is obviously naive, but I would still prefer a debt free currency issued by the state over a debt based currency controlled by central banks; and that's where he has a point.

I mean the Greenback was a good currency. It wasn't debt based (like bitcoin) so it removed power from the banks, and the Government back then was fairly trustworthy. Of course it was still a fiat currency, but in reality bitcoin is a fiat currency with nothing of intrinsic value backing it, although obviously it's quite different from any other fiat currency.

The reality of the situation today, is that even if we wanted a gold standard currency it simply cannot happen because the Government cannot afford the gold required. When it comes to official national currencies, the best option for our Governments is to use state issued fiat money which isn't created as debt. That's realistically the best option for the people.

However I wouldn't agree with him that fiat money is preferable over "sound" money. His dislike of gold is a bit misguided imo, in fact he states that any commodity would make a bad currency. We must also remember that bitcoin is a limited digital commodity. His reasoning seems to be that commodities are horded by the rich and useless as currencies because they are too scarce.

The problem with this logic is that gold is only stored away because we don't use it as a currency. If we dropped the dollar and started using a gold based currency then we would see gold circulating around everywhere. Furthermore, gold is interchangeable with fiat currency. Having a fiat currency isn't the huge disadvantage to the elite that he imagines it to be.

Think about bitcoin, some rich person could come in and buy up a huge portion of the market. Wealth will flow where wealth flows, regardless of the currency you use. Having paper as money doesn't magically make people richer compared to using precious metals as money. The only thing we can do is make the currency harder to manipulate.

But under even a state owned fiat paper money system, it's easy for the people who control the money supply to manipulate the currency and direct the flow of wealth via artificial means. Now in reality this is simply a ploy to offset the "natural" flow of wealth to the rich. And when I say "natural" I mean the wealth flows their way via their huge corporations and banks.

Now of course banks and huge corporations don't exactly play a fair game, they pay their employees slave wages and funnel most of the profits up to their major shareholders. But this is really a business issue concerning the nature of "capitalism" that we now operate under, it isn't a money issue and shouldn't be fixed with money via inflation.

If you don't understand what I'm saying yet, let me put it simply: with a state owned currency the government can create money out of thin air at no cost (right now they trade debt instruments to receive new money). By doing this they cause inflation and the value of the currency in question decreases, thus making the fortunes of the super rich worth less.

And at the same time the new money they create is generally spent on public services such as the building and repair of infrastructure, healthcare and social security spending, and so on. So the general populace, which is mostly the middle class, actually gains wealth overall because the money gets spent on these types of things.

Now of course this new money might often get funneled through to large companies directly (through lucrative gov contracts) or indirectly (via consumer spending etc), and what happens is that the wealth continues to flow to where it "naturally" wants to flow under this current version of capitalism we have. So then the Government rinses and repeats the process.

They keep creating more money regardless of demand and economic growth, it keeps getting sucked up to the super rich, and eventually the amount of money in active circulation is tiny compared to the amount of money which has been horded away by the super rich through this continual funneling process. And now they have extreme power over the market.

They could dump huge amounts of currency onto the market and cause all sorts of other problems. And of course this problem also occurs even when private banks control the issuance of currency, all the new money the central bank creates will undergo the same funneling process. But the point is you can't create a currency which magically makes people wealthy.

All we can do is make it harder to manipulate, as I already mentioned. We can make it more in our favor, by making it non-debt based and thus taking the advantage away from the banks. We can even make it limited in quantity and impossible to create from thin air at no cost, such as the case with bitcoin. But we will never create a currency incapable of flowing to the rich.

That's essentially attempting to build a currency with some sort of inherent self-regulating equality mechanism. It's completely absurd. We will only stop a disproportionate amount of wealth flowing into the hands of a few it we actually look at the system responsible for deciding how wealth is distributed, which is the business framework we use.

So it's not a bad thing to use a commodity as currency (as long as it has sufficient divisibility). We must remember that all our common mediums of exchange, whether a commodity or not, are interchangeable stores of value. The most important thing is making sure our currency is secure, predictable, and decentralized; since trying to centrally manage the distribution of wealth is redundant.

EDIT: also this article I wrote is extremely relevant to this discussion: Fiat Money

I watched about half of the first video. It's not bad but I found it to be a little over simplified and as someone else mentioned, he does take too long to get to the point.