Topic: Bitcoin 20MB Fork - page 108. (Read 154790 times)

Who are you to chose where microtransaction happen? I thought Bitcoin is all about decentralization and free market. Why are you trying to impose your point?

or both! maybe they all want Bitcoin to die so an alt can take its holy place

If you want an one world currency for everything you are in the wrong club, I heard they are meeting in a caribbean island soon.

Mpcoin supporters have announced that they will sell their gavincoins and buy mpcoins instead. Gavincoin supporters have not announced anything. So one can suppose that, at the beginning, the price of gavincoin will tank.

I'd rather just have one hard fork to set a dynamic block size limit, and get it over with, then have these debates, and risky hard forks, every four years.

Anyone who claim that transaction volume moving to another blockchain won't destroy the value of Bitcoin is either delusional or lying.

Bitcoin's status as digital gold is backed by the demand for it as a transactional currency. All of the speculative demand for Bitcoin right now is based on the potential it has to carry on it a substantial portion of global finance. Bitcoin won't survive as an expensive to use competitor to SWIFT. It needs to be extremely cheap, and have space for millions of people.

...

certainly don't deny people to use crypto for micro stuff, but maybe the bitcoin chain isn't the right place for that. Reddcoin or dogecoin comes to mind ...
...

Mpcoin supporters have announced that they will sell their gavincoins and buy mpcoins instead. Gavincoin supporters have not announced anything. So one can suppose that, at the beginning, the price of gavincoin will tank.
This will attract more people who had no opinion but who want to earn easy money, especially if at least one Bitcoin/fiat exchange exists on both chains.
This will also send a signal to miners : if Mpcoin has more value than Gavincoin, some miners will have an incentive to switch back to Mpcoin.
During the whole time of the operation, the chain with the lower hashrate will be vulnerable to 51% attacks.
The fiat price of both will probably tank also, because people will not know if any of them will survive.

In the end, if MP wins, there will probably never be another hard fork proposal.

Hello all,

Recently I just posted on another thread to express my concern about this subject, but I thought it might deserve a topic of its own.

This block size rule is something really "dangerous" to the protocol. Rules like that are almost impossible to change once there are many clients implementing the protocol. Take SMTP as an example. Several improvements could be done to it, but how? It's impractical to synchronize the change.

And, well, if we ever want to scale, such limit will have to grow. I really think we should address this problem while there is only one client used by everyone, and changes in the protocol are still feasible, because in the future we may not be able to.

As far as I understand, one of the purposes of this block size limit was to avoid flooding. Another purpose as well, as mentioned here, is to keep the transaction fees not "too small" in order to create an incentive for block generation once the coin production isn't that interesting anymore. (if only a limited number of transactions can enter a block, those with the smallest fees won't be quickly processed...)

So, if we really need a block size limit, and if we also need it to scale, why not making such limit so that it adjusts itself to the transaction rate, as the difficulty of generation adjust itself to the generation rate?

Some of the smart guys in this forum could come up with an adjustment formula, taking in consideration the total size of all transactions in the latest X blocks, and calculating which should be the block size limit for the next X blocks. Just like the difficulty factor.This way we avoid this "dangerous" constant in the protocol.
One of the things the smart guys would have to decide is how rigorous will the adjustment be. Should the adjustment be done in order to always leave enough room to all transactions in the next block, or should blocks be "tight" enough to make sure that some transactions will have to wait, thus pushing up the transaction fees?

Okay, I do realize that it would allow flooders to slowly increase the limit, but, what for? As long as generators aren't accepting 0-fee transactions, a flooder would have to pay to perform his attack.

So, what do you think?

microtransactions can happen offchain. Why would they need to be on chain? What percentage of txs are micro? I guess most.

Gavins' approach is:
-alienating
-wasteful with recouces (storage)
-inefficient
-lowers security
-brings in more centralisation
-causes trouble because it's very controversal

i have no idea how anyone in their right minds can vote for this without even demanding alternative proposals

It's not your storage but the storage of the people on their systems. Maybe that's why you like to waste it?

It's actually about 16.8 MB, and it's very unlikely the block size will grow to anywhere near 16 MB immediately. Consider that it took 6 years for Bitcoin to go from 0 to 0.5 MB, despite the fact that the block size limit has allowed 1 MB blocks for the entire time.

Bitcoin will not change the world by being conservative. Bitcoin will change the world by being bold. I vote 'pro'.

You can save peer storage only if the microtransactions are done in some centralized service, but why you deny people to use cryptocurrency for their microtransactions?

If you cant afford to dedicate the harddisk space for blockchain, well you can run some lite client instead...

I voted pro because I am for increasing max block size. But IMO it's too early to jump to 20MB. Maybe less?

I think this is a good idea but slightly too conservative. Have all the changes implemented in Bitcoin core but have them set to initiate at some future block to scale up more naturally.

What I support most strongly is that we do substantially-delayed hard forks with conservative values. Then doing hard forks regularly isn't such a big issue.

For example, Bitcoin Core can be immediately modified to increase the max block size to 2 MB on a specific date 2 years from now. I think that pretty much everyone would be basically OK with this max block size (and even higher values might be widely acceptable). By the time the change actually takes effect in 2 years, everyone will already have upgraded because very few people use 2-year-old software. Businesses and users won't have to go out of their way to choose one fork over another, and so there will be less room for messiness.

Then if a really nice academic study convincingly arguing that 5 MB blocks are safe is published 1 week after the 2-year-delayed change is added, another 2-year-delayed change can be added right away with very little extra cost. After ~2 years, the max block size will increase to 2 MB, and then a week later change to 5 MB.

Yes, 2 years is a long time. But I'm confident that Bitcoin will survive that long with 1 MB blocks.

Bitcoin will not change the world by being conservative. Bitcoin will change the world by being bold. I vote 'pro'.

At first, most users would run network nodes, but as the
network grows beyond a certain point, it would be left more and more to
specialists with server farms of specialized hardware. A server farm would
only need to have one node on the network and the rest of the LAN connects with
that one node.

The bandwidth might not be as prohibitive as you think. A typical transaction
would be about 400 bytes (ECC is nicely compact). Each transaction has to be
broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion
transactions in FY2008, or an average of 100 million transactions per day.
That many transactions would take 100GB of bandwidth, or the size of 12 DVD or
2 HD quality movies, or about $18 worth of bandwidth at current prices.

If the network were to get that big, it would take several years, and by then,
sending 2 HD movies over the Internet would probably not seem like a big deal.

microtransactions can happen offchain. Why would they need to be on chain?
...
It's not your storage but the storage of the people on their systems. Maybe that's why you like to waste it?

No, they'd end up as two different coins, both rewarding miners with 25 coins every 10 min. Balances would be the same on both chains, if you have 100btc now you'd have both 100 gavincoin and 100 mpcoin.

Worth has no direct reference to a fork, that's fiat and so a dubious representation of value at the best of times but mining costs come into it so if both sides of the fork can continue to run smoothly the argument whether more transactions or less transactions get more in fees would play out for all to see.