Topic: How a floating blocksize limit inevitably leads towards centralization - page 10. (Read 71521 times)

Silk Road can do this as well.  Track that, bitches!

Not only can they be but they already are!: Mtgox allows user to user transfer, so does BitStamp and most if not all other exchanges, then we have Coinbase, a platform who's main goal is to be the Paypal of Bitcoin, any eWallet service that has a shared wallet could offer this feature, any business that takes deposits and has a shared wallet like SealOfClubs could also offer this feature for their users, ect, ect, ect

After some thought, I want to discard my earlier proposal where the block size is adjusted to keep the sum of the subsidy and fees at 50BTC (or some constant). I think that over time, a rise in the value of Bitcoin will hurt demand for transactions, since they will be so expensive.

Here's some more elaboration on what I consider my best proposal, the voting method:


It occurs to me that a miner could easily code up a function to output the necessary yes or no vote, based on observable network parameters. Here's an outline:

1) Beforehand, the miner assigns a manual constant FIXED_COST which is the estimated additional expense priced in BTC of carrying blocks that are 1% larger.

2) Every time transactions are chosen for a block, the mining software puts together two candidate lists of transactions. One is the normal list which fills up to the current MAX_BLOCK_SIZE. Presumably, it is optimized to include the transactions paying the highest fees per kilobyte. The second list is put together in a similar fashion, but it filled up to MAX_BLOCK_SIZE plus the 1%. It is the first block which is hashed and mined.

3) To determine whether to vote yes or no, the mining software compares the sum of fees between the regular block and the larger block. If the fee increase afforded by the larger block is greater than the FIXED_COST, the mining software stores a yes vote into the block to be mined.


Using this technique, information about the transactions in the memory pool can leak into the blockchain in a way that doesn't require trust and cannot be gamed. The transaction memory pool will influence the decision of increasing block size, but only in a way that preserves the fees.

Since the block size never goes down, we are not vulnerable to the problem where Bitcoin appreciates so much that fees become prohibitive - users will simply send transactions with smaller fees. We also avoid the problem of killing demand for transactions from fees that are too high. Once the fees in filled blocks reaches the equilibrium point, miners benefit from including additional transactions with equal fees and therefore will vote yes (as long as it covers their FIXED_COST).

I believe this is the best proposal on the table. Have at it

+1

Sigh, they need to do more research.

Transaction rates can easily scale far beyond 7 tps, even with 1MB limit in place.

The current network is just the base settlement layer.

Many organizations will layer instant payment networks, settlement networks, credit layers and other things on top of the current layer.

Anybody who looks at the current technology and assumes "that's all there is" or "the whole world is limited to the current network" makes fatally flawed assumptions.

Satoshi openly acknowledged this by noting insuitability of microtransactions for the current network, and it is clear that digitally signed messages may be sent, exchanged, combined by a myriad different payment processors, aggregators etc.

I don't mean to spread doom and gloom. I'm sorry....

You said yourself though in a post a long time ago that it's a marketing issue. And who is most susceptible to that? the clueless .

edit: (and in case anyone was wondering what Justusranvier linked is what I was talking about. Just one case.)

That is the only condition which changes between your conditions for adaptive block size and your conditions for a new constant hard limit.

Why is that? Do you feel that it is a foregone conclusion that an autoadaptive block size precludes fulfillment of such a requirement?

-MarkM-

Not quite zero evidence:

https://bitcointalksearch.org/topic/m.1543934

"already controversy is brewing"  Wonderful zero-evidence hypothetical BS handwaving there.  Yes, controversy is brewing... among those teenagers clueless about bitcoin and economics.

Bitcoin value and press reports indicate new bitcoin users and businesses every day.  The exact opposite of "back away"

It's true that the Bitcoin protocol has no knowledge about the exchange rate against fiat currencies (and it shouldn't). I mentioned $1000 more like a rough estimate about the amount of value we should aim for. If Bitcoin grows to complete use by 1e9 people, there would be 0.021BTC/person. If current dollar amounts are available to the USD-using population at $30000/person, the equivalent value would be 1.4e6 USD/BTC, so my $1000 would be about 0.0007 BTC. If you say that 10% fees are the maximum to be called "reasonable", transaction fee would have to be at most 70e-6 BTC. But, as you see, this number heavily depends on the number of people using Bitcoin. Since currently the effective(*) number of Bitcoin users is much lower, we can make much smaller transactions with an acceptable fee rate.

So, the fee level needed for this requirement will change over time, because of the changing value of Bitcoin. I don't think you can adapt for this in the protocol, but you can choose appropriate values in the protocol in order to meet this requirement in a wide range of Bitcoin prices and popularity.

(*) I expect that currently most Bitcoin users only use Bitcoin for a small percentage of their finances.

I disagree with this assumption.  It is entirely within reason for 'bitcoin clearinghouses' to exist that process the majority of out-of-band transactions, while remaining functionally decentralized.  The most important part is that it remains forever possible for anyone with the resources to jump onto the network and compete.  It does not have to be a cheap endeavor. 

That said, I would say that it would be wise endeavor that the main network is capable of processing enough transactions that it's unlikley that any single out-of-band processor can capture more than 50% of all transactions.  Practially, I don't think that this is a real worry unless Bitcoin never really becomes a global currency; for it's unlikely that users in China or Russia are going to favor a processing agency in the United States for their mostly local and mostly daily purchasing needs.  Thus, whichever processor grows up to be the Bitcoin version of Paypal in the United States is at a disadvantage towards capturing the Chinese or Russian markets due to cultural differences and simply mistrust of Americans.

In this context, such distrust is both well founded and advantageous to limiting centralization.

Furthermore, it's important that competition to any of the market dominators in the out-of-band transaction processing never be 'locked-out' from access to the main bitcoin chain nor (hopefully) co-opted by government policy.  The real problem is that we can't predict how these things are going to go with any real certainty.  What we can predict is how large of a block must be possible to sustain a particular transaction rate at the current average transaction size.  Personally, I consider the rate that Paypal can process transactions to be a practical minimum for consideration of a hard code fork, so nothing less than a 10MB hard limit is worth the trouble.  Fortunately, we are still years away from this problem, and have plenty of time to hash out the details.  In the meantime, we can just agree to raise the soft limit, or agree to simply let the rest of the miners to comment it out at their own desires.  Even the occasional full block isn't really a problem, so long as we don't have full blocks for hours on end.

Off-the-chain transactions are not necessarily centralized, although centralized solutions are definitely the most simple type, and will the first type to be available.
There are decentralized "off-the-chain" transaction systems. As mentioned before, it is possible with alternative block chains. Another decentralized off-the-chain transaction system is the one I proposed in this thread:
https://bitcointalksearch.org/topic/combining-bitcoin-and-the-ripple-fast-scalable-decentralized-and-more-94674

I like it because it is mostly off-blockchain, and, unlike most Ripple systems, it does not allow fractional banking and requires only a minimum amount of trust (less trust than needed e.g. to trade goods or fiat currency online with Bitcoin). OTOH it is "unproven technology" and it will take some time to develop. I'll work on it as fast as I can in my spare time, so that I can demonstrate a prototype ASAP. I hope you see the importance of such systems.

Indeed. The centralization that comes from off-the-chain transactions is exactly the kind of centralization that our current world financial structure is based on. It will, for example, allow widespread use of fractional reserve banking, which is not possible with Bitcoin right now. Whatever happens, we must strive to keep most transactions in the blockchain (most, not necessarily all), otherwise the whole idea behind Bitcoin is more or less doomed.

Lets.

Already controversy is brewing... Already businesses are starting to back away from bitcoin because if the block limit isn't raised then one of three things will happen: 1. Bitcoin fails. 2. Bitcoin gets used only for moving large amounts of money and other cryptocurrencies take over eventually displacing bitcoin itself. 3. Bitcoin gets used for only moving large amounts of money and "bitcoin clearing houses" fill the gaps, which increase the risk of fraud/theft/unaccountability, add avenues of attack, and form REAL centralization. Not some hypothetical BS.

Let's not! If security needs to be paid markets will understand and self adjust. Why take it over limit and be sure small time merchant and miners can't keep up with bandwidth and storage requirements. It will be feasible in a few years though.

Correct me if I'm wrong (unsure) but the bitcoin network doesn't "care" how much money you are moving. What it cares about are the amount of inputs. So it's possible to have a large amount of money with fewer inputs.. and a small amount of money with more inputs. So these "acceptable levels" are going to be for small transactions too. Which would as I said earlier...... means that bitcoin will probably fail with a hard low limit. Because if you are designing the network to have acceptable fee levels for 1k then it will also apply to smaller transactions. And those transactions and people will seek a new cryptocurrency.

My brain bandwidth (averaged over the week) is low enough to make it difficult for me to mine a new comment in this forum chain 
Luckily, most comments I wanted to make were already made by others.

My current "big picture" opinion on this matter (subject to change):
The current limit should be considered an opportunity rather than a threat: we can observe the effect of a hard limit before Bitcoin becomes really big. I don't think we will hit it really hard: the soft limit and the existence of "frivolous" transactions act as a buffer. The best way to prepare for the hard limit in the short term is:

• Add functionality to Bitcoin clients to guide the user in navigating the "transaction market" (choosing an appropriate fee for his transaction). This can be based on recently observed transaction fees in the block chain.
• Inform people that this is going to happen, and what the effects might be. We were all informed of the reward halving, and because of that, the event itself didn't cause any panic.

Sure, the current limit will slow down the Bitcoin economy, but to be honest, it is currently quite over-heated: in mainstream economies, >10%/yr is considered overheated, but Bitcoin adoption is currently even faster than Moore's law! We need time to develop secure off-blockchain payment systems based on Bitcoin (I'm working on this), to wait for people to have faster Internet and bigger hard drives and to reach consensus about the best block size limit method. Once transaction fees become painfully high and bigger blocks are no longer a problem for "non-commercial" owners of full nodes, the "hard fork" needs to be performed. Naturally, the "hard fork" decision needs to take place before "real problems" occur.

I am in favor of automatically adjusting the block size limit, if the adjustment method meets the following conditions:

• The block size limit remains sufficiently low to allow funding of an "unbreakable" difficulty level through transaction fees. "Unbreakable" means at least that beating the difficulty level is more costly that it will be profitable, for any organization (incl. governments).
• The block size limit remains sufficiently low to allow an average person to set up a full node with affordable investments. "Affordable" is such that some people will do this out of altruism.
• The block size limit remains sufficiently high to allow "large" personal transactions (e.g. >$1000) to take place with acceptable fee levels.
• It is not possible for miners or pool operators to perform the type of attack as described by the OP, either deliberately or not deliberately
• The adjusting method provides a significant advantage over a (more simple) constant value, e.g. it auto-adjusts to average hardware improvements

If no such method is found, I am in favor of increasing the block size limit to a higher constant value, as long as it meets the following conditions:

• The block size limit is sufficiently low to allow funding of an "unbreakable" difficulty level through transaction fees. "Unbreakable" means at least that beating the difficulty level is more costly that it will be profitable, for any organization (incl. governments).
• The block size limit is sufficiently low to allow an average person to set up a full node with affordable investments. "Affordable" is such that some people will do this out of altruism.
• The block size limit is sufficiently low to make it impossible for miners or pool operators to perform the type of attack as described by the OP, either deliberately or not deliberately
• The block size limit is sufficiently high to allow "large" personal transactions (e.g. >$1000) to take place with acceptable fee levels.
• Mining is likely to remain decentralized to a high degree, to avoid a "single point of control"

If no such level is possible, I'm not sure what to do. I would mean having to decide between two different kinds of centralization: either mining centralization, or payment processor centralization. I think we'd have to choose the one which will be the most reversable one, so that it can be reversed once hardware capabilities improve.

Moore's Law predicts the performance of a single CPU.  In terms of bitcoin scalability, it doesn't matter how fast a single CPU  will be 10 years' form now.  

Rather, the crucial measure is cost per CPU calculation.  Transistors may be reaching physical limits, but in terms of producing CPUs more cheaply (and thus in greater quantity), and in terms of energy efficiency, there are still many orders of magnitude of growth potential.

There is no reason why a bitcoin node can't run on a multiprocessor machine.

If the block size limit is reached (for the average block), miners will implement algorithms to select transactions to include so as to maximize the fee collected. This will drive up the cost of fees as people compete to have their transactions included in a timely manner. Let's keep bitcoin the cheapest transaction processor around by avoiding such a scenario!

And that would be at the current minimum transaction fees and based on what current blocks look like.