Quote from: Zangelbert Bingledack on June 03, 2015, 07:36:29 AM

Quote from: Meni Rosenfeld on June 02, 2015, 08:16:17 PM

But short-term, if I have a transaction I'm set on sending right now (e.g. a restaurant tab), I'll be willing to pay very high fees for it if I must. So fees are not effective in controlling the deluge of transactions.

This part seems a bit off. At any given time, some people will have an urgent need for settlement, but many/most won't. So we get smooth scaling for quite a while from a purely economic perspective. Now once we reach a point in adoption where there are so many urgent transactions that they fill the blocks on their own, that kicks up the frustration to unacceptable levels, but even then some will be willing to outbid others and again it's a gradual increase in pain, not a deluge.

Insofar as the prices miners charge do rise properly and users have an easy way of getting their transactions in at some price, fees will limit transactions even in the short term. All you're really describing here is reaching a point that is pretty far along that smooth pain curve, after all the less important transactions have been priced out of the market.

Overall this is a great idea, though!

It's difficult to know exactly how the quantitative factors will play out exactly. The inelasticity is not total, but I believe it is significant, and contributes to the phenomenon. Even if things will not be as catastrophic as Mike describes, I believe they can get rather ugly, so any change that alleviates it is welcome.

Quote from: HCLivess on June 03, 2015, 12:07:14 PM

are you suggesting we drop btc and pick up vtc?

Not familiar with it.

Quote from: thezerg on June 03, 2015, 12:48:09 PM

An elastic supply is very important, but I think it can be accomplished more simply, without a pool.

Allow blocks to be expanded beyond their "nominal" size with high fee transactions. The higher the fee, the further it can appear in the block. Formally, define a function fee = T(x), where x is the location in the block. If a transaction's fee is >= T(x), it can be placed in the block at location x. T(x) = 0 for all x < 8MB (say) and increases super-linearly from there.

This could work, but:

1. I'm not convinced it's actually simpler. If I understand it correctly, it requires, among other things, sorting the transactions by fee. Verification also requires examining each individual transaction in a rather elaborate way.
2. I think it's much harder to analyze how it will play out economically; and my initial thought is that it will be less stable. In my suggestion, the fee will be more or less consistent over txs, for any given load level. Here, some txs will be accepted with 0 fee and some will require very high fees; it will be difficult for each transaction to decide where it wants to go, and they can oscillate wildly between states.

Quote from: thezerg on June 03, 2015, 12:48:09 PM

EDIT: the biggest problem with this class of proposal is sizing the fee. Especially given bitcoin's volatility. However, if the fee function chosen starts at 1 satoshi, a high bitcoin price will tighten the elasticity of supply (in practice) but not entirely remove it. At the same time, we STILL need to grow the "nominal" block size: i.e. 8MB + 20% per year, or risk pricing out personal transactions as adoption increases. However, this class of proposal allows the network to react in a classic supply/demand fashion. This reduces the pain when supply is exceeded, meaning that a "last-minute" hard fork as proposed by many of Gavin's opponents would be a lot less damaging to the network (block size increases could trail adoption rather than precede it).

This is the reason I chose a hyperbolic function rather than a polynomial one. Being hyperbolic means a wide range of marginal costs is covered with a relatively small span of block sizes. So whatever the reasonable fee should be, the system will find a block size that matches it.