Topic: Oh god, I see a chance for lifting the 1M block size limit !!! (Read 3674 times)

If I ever find myself owning things claiming to be bitcoins but that allow blocksizes over 1MB, I will be selling them all, and keeping the official bitcoins,,,!

This discussion is kind of like arguing about the number of angels on the head of a pin, since the effects you're concerned about are greatly overshadowed by 1) miner block reward subsidies that have created an overly-strong network, 2) historically low transaction volume, and 3) massive speculative investment.

Ok but that doesn't address money/currency velocity at all.

-MarkM-

This is the best idea.

Full block space will always be occupied by spam. See http://en.wikipedia.org/wiki/Tragedy_of_the_commons. Network RAM/HDD/CPU is a limited and expensive resource, but miners have every incentive to deplete it (personal gain, costs shared by others). Bitcoin can survive the tragedy of the commons by scheduling how fast the limited resources are being depleted and keeping it lower than technology advancement.

There is currently no mechanism to force miners to pay for the network resources, they have to be limited through the block size limit.

Ah, okay, got you. If that tourist had wanted to buy all the services all the villagers had managed to sell to each other with his money while his back was turned, it would have cost him a heck of a lot more money than just that one "coin" they used for a few minutes behind his back and returned to him.

-MarkM-

The value of Bitcoin is the value represented by the Bitcoin economy.  The Bitcoin economy creates value just like any other economy, by voluntary specialization and trade.  Higher velocity means more specialization and trade, and thus higher value.

Just ignore exchange rates.  It has nothing to do with exchange.

Upgrading the block size because of a bug doesnt show forward planning and should have been scheduled 6 months ago to avoid a fork.

Having a fork everytime the network bumps against the max block size isnt a good idea either.

Whoa, explain how velocity increases exchange rates?

Surely velocity means the same coin can be used by more people in less time?

So more people manage to get their greek village parable circle of trade to go round with less coins.

So they don't need to buy as many coins per village.

How does that increase exchange rates?

-MarkM-

Thank you retep for thinking about bitcoin scalability and sustainability long term! Everyone should read this.

Thanks for bring all these up, you should not demonstrate how to abuse the system  

I'm bit more confident that the community will solve such kind of problem given their fast and professional reaction this time

Please explain how you reach that conclusion?

I thought velocity of money/currency is how fast it gets spent again and again and again, so that the more times per [span of time] the same coin can be spent again the less coins in total the system needs.

For example, if velocity was 21 million per day, so that one coin was being re-spent over and over 21 million times per day, then one coin could do the job that would have taken 21 million coins to do if velocity had been only one spend per day?

How does that cause deflation?

On the other hand if adoption increases while velocity does not increase as fast as adoption does, then there would be more need for coins / need for more coins, which sounds like it could be deflationary.

-MarkM-

It's a lot more ugly than that. If there is spare capacity you can use it for something quite different than just cheap transactions; unfortunately fundamentally transactions are just data, and there is nothing we can do to prevent people from stuffing data that has nothing to do with finance at all into transactions, and thus blocks.

Thus with large blocks and cheap blockchain space you can offer a really useful service, lets call it "Google Chain Storage", the only backup service in the world that comes with the guarantee that you know you data is safe, every time you perform a successful transaction.


Technically speaking, what you do is you create a transaction with the following scriptPubKey:


In theory it can be spent by providing the data that when hashed has the 20 byte digest provided, so nodes can never prune the transaction from their databases. Of course, in reality you would just generate the digests randomly. The data payload can be up to 9974 bytes long for every transaction. At 0.1 cents per KB fees - what people were paying a few months ago - putting 1MB of junk into the blockchain forever would only cost a dollar. There are lots of people with data valuable enough that paying $1000/GB to be absolutely sure it is backed up makes sense.

Even if you try to combat the horridly abusive stuff like the above with a hard-fork that changes the rules to disable anything but the small set of standard transactions, there's still timestamping. Again the easiest way to do it is to just send a tiny amount of funds to an address that's actually a digest of the data you want to timestamp, and again the demand for time-stamping is more than enough to fill any blocksize you want.

No.  simple soln: one or more of those services starts a miner.  After all it is in their interest.  Otoh, competing for blockspace opens the door for an altchain to service the market that cant afford the space.  Maybe someday, but btc is still so small we should not turn away svcs.

Transactions increase block size, not height. 

If a rogue miner includes, for instance, dust transactions (i.e. <0.0001 BTC) then any block they find can delayed by some nodes not relaying it.  This will allow time for "nice" miners to find a block and slip it in before the "bad" block makes it permanently into the chain.  The would create lots of orphans, but if done sparingly then it might create enough pressure for miners to play nice.  Forks are really bad so that is why I suggested that any valid block that is followed by 2 other blocks are automatically accepted.

This method could be used for both good and evil.  If most miners decided to block SD transactions then the nodes could ignore blocks that didn't include their transactions.  But, worse, nodes could refuse to relay blocks that did have SD transactions. 

What would happen if I patched my node to accept only "noble" blocks or ones that are deeper than, say, 3 from my current height?  Miners might not have incentive to keep the blockchain reasonable, but as a node I do.  What if nodes propagated some blocks faster?

It's sometimes said that one of the impressive things about the Bitcoin design is the synthesis between several fields: it displays expertness in computer programming and cryptography, but also in economics.  It's pretty clear that no one currently at the helm gets the economics.

Rational self-interest.  No one would exchange Bitcoins if they didn't end up better off because of it.


Perhaps "discarded" was a hasty way to put it, if you're going to argue about what happens far in the future.  Remember that, at that point, simply running a node will be an expensive proposition.  So there will always be some scarcity.  But, yes, you're right.  Some limit will be necessary in order to protect the incentives to secure the network.  I'm just saying, that's what it's there for.  It will be increased as necessary to accommodate growth in transactions without sacrificing network security.  It's not there to prevent price inflation.

No it wouldn't. People find the same block all the time, whoever pushes it through the fastest wins. Including more transactions means you will be slower and may lose.

...and his block promptly gets orphaned because most of the network is only including the transactions that make economic sense so theirs propagate faster. The single rogue miner doesn't find blocks fast enough to make a significant impact on the network unless he controls 50% of the hashing power, in which case it's game over anyway regardless of the block size limit.

Deepbit are still running 0.3 nodes, they have never upgraded for almost 2 years and never had any problem so far.

Vista killed windows, so windows 7 falled back to windows XP architecture. The longer you are in software business, the more you will be uncertain that upgrade is a good thing. When a system has reached certain level of functionality, complexity and acceptance, any major change will impact existing users in an unforseeable way, and will result in much higher resistance than you originally expected

In my work that weekly delivery is a norm, there are many occasions that we have to call back upgrades and roll back to previous version. And there are many customers who don't like upgrade at all, they are still running some software we delivered 5 years ago and they are happy with it since that give them peace of mind

Anyway, this BDB bug created some consensus that a hard fork is needed even with today's block size limit. Before, this consensus is just not there, and many people include me do not think a hard fork is a good idea unless it is absolutely necessary and absolutely coordinated