I don't understand how your algorithm will give the entity with higher hashpower more profit by mining blocks that give less BTC per block, that doesn't make any sense to me.
Because in so doing, the miner increases the penalty pool, and will reclaim it in his future blocks. Why wouldn't the bigger miner mine smaller blocks and get the higher BTC per block, like your example was showing?
Because if he does, the penalty pool will be smaller, and he will get less BTC per block. If nobody creates supersized blocks, we go back to scenario 1. The big miner, like all other miners, will get only about 4.50 BTC per block. When the big miner creates supersized blocks, he gets 4.68 BTC per block. On the other hand, if it really is more profitable to mine larger blocks, then why wouldn't the smaller hashpower nodes do it?
Because if a small miner creates a large block, the effect on the penalty pool is not as meaningful as the effect the big miner has. All miners want to maximize their (tx fees - penalty) + collection. Collection is equal to the average penalty paid by all miners. A small miner plays only a small part on this average, so collection is constant as far as he is concerned, so he more or less wants to maximize just (tx fees - penalty), which happens at around 6000 txs. If he goes further, he will decrease his (tx fees - penalty) with barely any effect on collection. A big miner has a big effect on the average. As he creates blocks larger than 6000, (tx fees - penalty) decreases but collection increases at a faster rate. Above 7250 txs, the gain in collection doesn't justify the drop in (tx fees - penalty). if this is true; Reward per block for 1% miner: 5943 * 0.0006885 + 3.2223 - 0.4589 = 6.8552 BTC (more than in scenario 1)
Reward per block for 90% miner: 7251 * 0.0006885 + 3.2223 - 3.5294 = 4.68521 BTC (less than 1% miners in this scenario; more than the miners in scenario 1). Why isn't the 90% miner simply including 5943 transactions like the 1% miner is, in order to get about 2 BTC more per block? Because if he starts creating 5943-tx blocks, the penalty pool will be smaller, and so will the amount he collects per block. See scenario 1 here - if the big miner behaves as the small miners do, it's the same as if they're all small miners. He will get just 4.50 BTC per block, instead of 4.68. He can't have the cake and eat it too - not pay a penalty, but expect to reclaim it... I'll say again - the default state is where everyone just maximizes their own (tx fees - penalty). A big miner can afford to build bigger blocks than that because he knows he can reclaim 90% of the penalty, so it doesn't bother him that much. In so doing, he increases his profit per block - but he increases the profit of the miners who don't do this even more. At some point, the increase in penalty outweighs the increase in tx fees + collection, so he stops there. Whether one or more of these summands is more than 2 BTC is irrelevant, it's their sum that counts. The problem is, regardless of what the collection is in the pool, the highest profit per block is always greater by simply mining at the target block size. If the major nodes have driven up the BTC in the collection pool to provide greater profits on the whole, then the first big miner that stops contributing to the pool will essentially drain the pool by mining blocks at the target block size. In the end, trying to maximize profits by relying your competitors to "play fair" won't work. I'm not making any assumptions about fair play, reciprocity, collaboration or any such thing. All miners are behaving selfishly and without regard to the other miners. However, I am assuming each miner expects to continue mining, at a similar hashrate portion to his current (or, alternatively, he bases his calculations on his future anticipated portion). The big miner will create supersized blocks simply because he know he'll be around to reclaim some of the penalty later. So he doesn't maximize (tx fees - penalty), he maximizes (tx fees - 0.1*penalty), which happens at larger blocks, with a steeper marginal penalty. If there are several big miners, they should all create supersized blocks, and then every miner will enjoy the supersized blocks of the others. But the reason for each individual miner to create supersized blocks is not that he hopes others will do the same. It's simply because it's more profitable for him to do so, regardless of what the others do. This is not the prisoner's dilemma, where there is a conflict between selfish desires and the greater good. Of course, it is possible to miners to try and band up in a cartel, creating blocks even larger than what is selfishly optimal for each of them individually. But such a structure will not be stable. |
|
|
|
1. Floating block limits have their own set of problems, and may result in a scenario where there is no effective limit at all.
2. Even if you do place a floating block limit, it doesn't really relieve of the need for an elastic system. Whatever the block limit is, tx demand can approach it and then we have a crash landing scenario. We need a system that gracefully degrades when approaching the limit, whatever it is.
Why not have both an elastic block cap and floating block limits? A common argument against floating block limits is "big miners will create super-sized blocks full of crap to artifically inflate the block limit". This attack is conveniently addressed by your rollover penalties, as the penalty is a function of block size (not of transaction fees), so miners cannot game the system by including self-mined transactions. Consider the following floating block limit function: T = k * median(block size of last N blocks) evaluated every N blocks. With k = 1.0 and N = something large like 8064, we have an equilibrium situation consisting of the status quo, where everyone stays under the soft cap of T. If a large mining cartel wishes to inflate block sizes against the will of smaller miners, they must begin creating larger blocks and paying penalties towards the smaller miners, for each block. With sufficiently large N, this is not sustainable. Let's say Bitcoin experiences sustained, long-term growth and the fee pool/demand increases. Now everyone, including smaller miners, is creating blocks larger than T. Everyone pays penalties, but in doing so, the "penalty" isn't really a penalty; everyone receives about as much from the rollover pool as they pay. After 8064 blocks, T increases to account for this genuine, long-term increase in demand. There are lots of parameters here, and they can be adjusted to disincentivize a mining cartel from artificially inflating block sizes. For example, increasing N and making the limit function f(x) "harder" will both increase the cost to artificially inflate block size limits. Another possibility is setting k < 1.0 (e.g. k = 0.98), which means that maintaining the status quo has a cost. If miners unanimously decide to maintain the status quo, then no-one is actually penalised because everyone receives as much from the penalty pool as they pay. However, if smaller miners feel that the status quo is unreasonable (because of past bloat from a large mining cartel), they can choose to make smaller blocks and "bleed" penalties from the larger miners. However, I am concerned that setting k < 1.0 might implicitly set an absolute minimum transaction fee. tl;dr version:With floating block limits + rollover penalties: mining cartel tries to artificially inflate blocks => they must subsidize smaller miners with penalties Bitcoin experiences genuine, long-term growth => miners unanimously include more transactions => block sizes will increase Sounds good. I tend to agree there is good synergy between the two modifications - the limit will float only after it is stretched and penalized, making sure there is an actual need for it. I agree the time scales need to be fairly large, to make it expensive to artificially inflate the limit. Anyway, this requires more research. |
|
|
|
2. Explain what is wrong with the example (the one with real numbers) that shows the reward per block is smaller for big miners. Right here; Reward per block for 1% miner: 5943 * 0.0006885 + 3.2223 - 0.4589 = 6.8552 BTC (more than in scenario 1)
Reward per block for 90% miner: 7251 * 0.0006885 + 3.2223 - 3.5294 = 4.68521 BTC (less than 1% miners in this scenario; more than the miners in scenario 1). No miner is going to mine a block that costs him more than 2 BTC to mine. Since it's not economically viable to mine larger blocks, you're right that there isn't an economic advantage given to the larger mining entity, and what I wrote earlier wouldn't apply. What I wrote would only apply to penalties that don't reduce the reward below the target block size reward. Why would a miner mine a block at a loss just to accept more transactions? Regardless, any market participant that engaged in this behavior would just get out-competed by another that didn't. I don't understand what you wrote here. These are the results for the optimal strategy for each miner, which maximizes his profit. Should I show the derivation? It's just a bunch of unwieldy equations that my silicon overlord took care of for me... Each miner wants to maximize tx fees + collection - penalty. The small miner can't hope to affect collection because it depends on what the other miners do. But the big miner does meaningfully affect collection as he makes bigger blocks. As he adds transactions to his blocks, all of tx fees, collection and penalty increase. At some point, the increase in penalty outweighs the increase in tx fees + collection, so he stops there. Whether one or more of these summands is more than 2 BTC is irrelevant, it's their sum that counts. In the part you quoted, no miner mines at a loss. The small miner has a profit of 6.8552 BTC per block, and the big miner has a profit of 4.68521 BTC per block. If the big miner built smaller blocks, his rewards per block would be smaller. If, for example, he included only 6000 txs/block, like the small miners, he would get only 4.50 BTC per block (instead of 4.68), just like the miners in scenario 1. If the big miner takes a longer-term view, he may notice that creating supersized blocks will give him a profit at first, but then attract more miners, who will increase the difficulty, which will reduce his profits, to the point where he is not competitive with the small miners - so he can give up the whole thing and just build normal blocks (ignoring reclaiming his own penalty in his optimality calculations). And then we go back to the situation where big and small miners are completely equivalent, and get the same reward per block. |
|
|
|
Ok, so my post was nuked again (My computers fault) so this will be short and sweet. I have been away, so I apologize for the delay; Suppose there is a big miner with 33% of the hashpower, and there are 67 small miners with 1% of the hashpower. Because of the Law of Big Numbers and simplicity, I'll assume that they all mine blocks in a predictable order; BigMiner, SmallMiner[1], SmallMiner[2], BigMiner, SmallMiner[3], SmallMiner[4], .. , BigMiner, SmallMiner[66], SmallMiner[67] I'll also assume that the rollover fee will be distributed over the next 100 blocks. BigMiner can assume that it can recover 33% of the lost reward on a future block. So if the BigMiner can mine a block that exceeds T while simultaneously getting a reward that is better than a block less than T, given that his reward is reward - penalty + .33*penalty, then it's at a net positive. Whereas a small miner could only do reward - penalty + 0.01*penalty. What is further problematic for the SmallMiner is that if they mine anything with a rollover fee, the BigMiner will get 33% of the reward whereas they will be lucky to get 1% (Not only is the reward less for himself, but any rolling over reward is more beneficial to his larger competitor(s)). In this way, the BigMiner has a competitive advantage over SmallMiners. I tried to come up with specific numbers that would show the attack on your algorithm, but I wasn't sure what values you were using to get your graph 1, so I think it would end up being a straw man anyway. The bottom line is that penalties or rewards rolling over hurts the SmallMiner more than the BigMiner. SmallMiners being less able to recover over future blocks. By "penalties or rewards" I mean that it doesn't make a difference whether you are rewarding the current larger block and rolling a bonus over to future blocks, or if you are penalizing a big block and then passing the difference to future blocks. I didn't see a response to that problem, sorry if I missed it. 1https://i.imgur.com/EZvlJq7.pngEdit: T was defined as the target block size. See a worked example at https://bitcointalk.org/index.php?topic=1078521.msg11557115#msg11557115. I use the penalty function described in the OP - f(x) = max(x-T,0)^2 / (T*(2T-x)). And an earlier one with made up numbers but additional analysis. You need to be thinking in terms of reward per block. Of course the 33% miner should get about x33 the rewards of a 1% miner, simply because he's bigger. What we don't want is that the big miner would have more than x33 the rewards (superlinear gain). What I've shown is that the big miner actually gets less than x33 the total rewards of a small miner, or in other words, that the reward per block is smaller for the big miner. Every miner gets, per block, (tx fees - penalty) + collection. The rollover pool is the same for all miners so collection is a roughly constant value. But (tx fees - penalty) differs per block, and is lower for the big miner. The big miner purposefully builds supersized blocks, because increasing the pool works to his advantage - but it works to the advantage of the small miners, too. Put another way, the small miners don't reclaim much of their own penalty, but they reclaim the penalty of the big miners. If you still disagree, please either 1. Explain why we shouldn't be looking at reward per block, or 2. Explain what is wrong with the example (the one with real numbers) that shows the reward per block is smaller for big miners. Furthermore, if the reward is (1 - penalty) * (minted coins) + tx fees, then in the future when the minted coins go down to 0, there is no penalty at all. That's the opposite of future-proof.
Monero is permanently inflationary, so there will always be an impact of the penalty. Ok. I was primarily refuting the implied claim that this formula would make sense when applied to Bitcoin. |
|
|
|
One difference with the Monero model is that the amount of the fee is not a factor of the penalty, nor is size of the coinbase reward. The penalty is not multiplied by the block reward. Additive, not multiplicative.
I'd missed that detail at first pass because it seemed impossible for anyone to advocate such a function, when on its face it seems to fail the 'future-proof' test.
Without knowing what the fees will be in the future, how can the penalty be the same for every transaction? Fee amount tends to adjust with how much milk and bread a bitcoin can purchase. The penalty may thus become overly burdensome (if bitcoin value increases) or meaningless (if it falls).
We can know the coinbase reward, but we should not always expect that to be 99% of the total as it is now. This will matter later.
The advantage of the Monero multiplicative method is that it does not have to guess, it works at all fee levels, block rewards, valuation, etc.
As I've explained multiple times, this is exactly the reason for choosing a hyperbolic function. The marginal penalty is the derivative of f, f'. f' ranges from 0 to infinity when the block size ranges from T to 2T. Whatever the current Bitcoin price etc., there is some x for which f'(x) is equal to the typical fee. So the block sizes stretch and expand to accommodate the changing fees. The same happens with the quadratic function in Monero, but much more slowly, giving us less control over the block sizes. Because of this, the quadratic function actually assumes more about the fees than the hyperbolic one. The penalty itself (as opposed to its derivative) is less important in my proposal, because it more or less cancels out with the collection from penalties of past blocks. But still, we prefer to keep the penalty as low as possible, meaning that we are interested in the ratio f'/f. A hyperbolic function, because it grows faster, achieves a better ratio - and we can improve it further with parameter choice. Furthermore, if the reward is (1 - penalty) * (minted coins) + tx fees, then in the future when the minted coins go down to 0, there is no penalty at all. That's the opposite of future-proof. |
|
|
|
Thanks for that, it was my reading also.
Thus TX fees that are not in the block but paid out of band are not subject to penalty...
It's an additive deduction, not multiplicative. You seem to be thinking the miner's reward is: (1 - penalty) * (minted coins + tx fees + collection from pool) Where it is really: minted coins + tx fees + collection from pool - penalty Having more fees in the txs included doesn't increase the penalty. There is no difference between adding 1 mBTC to the fee and paying 1 mBTC out-of-band. I don't see how this differs from in Monero? In Monero, addition of txs up to the median blocksize is free. As you surpass the median blocksize, a quadratic penalty is applied to the subsidy of the coinbase, but amounts obtained from tx fees are untouched. The subsidy of the coinbase is initially dependent of the number of coins in existence, and so takes into account the previous penalties to coinbases of any previously generated blocks (comparable to your "pool" method). Then, the miner is free to add transactions meeting some economic equilibrium that maximizes their overall income when taking into account the blocksize penalty to the coinbase subsidy. So, it's like this: (1 - penalty) * (minted coins) + tx fees where penalty is dependent on the size of the block above the median size according to the formulas found in the CN whitepaper. gmaxwell criticizes this as promoting out-of-band transactions, but the fact remains that to permanently and secure transfer money you must use the blockchain and have it included in a block somewhere. Thus, I never thought it was much of an issue. That's not the part that differs from Monero. In fact, that's the part that NewLiberty claimed was worse than Monero, and I claimed is the same. (See also context) Do you have a reference for Greg's criticism? It doesn't make sense to me. I've explained above why out-of-band is not a problem in my suggestion (as you said - inclusion in the blockchain is what you need to secure the tx, so you have to pay the penalty anyway, and it doesn't matter if you get payment in or out of band), and since Monero is similar in this regard, it shouldn't be a problem for Monero either. It's possible he means that miners will make an out-of-band commitment to include a tx at a later, less crowded block. But... That's a problem with any other system (e.g. the current hard cap in Bitcoin), and it's not a problem - we want txs to be taken out of big blocks and into smaller ones. I don't think the users will actually agree to such a contract, but if they do, it's perfectly fine. |
|
|
|
I think a better solution would be to require miners to do more work for larger block sizes. Instead of hashing just the header of a block, miners have to hash something more: perhaps something proportional to the block size. So if a header is 80 bytes, it takes up 80/1000000=8e-05 of the whole block. So for any block size x > 1 MB, require a miner to hash the first (8e-05)x of the block in order for it to be valid. This will make Bitcoin automatically scale to the power of computers in the future, as big blocks will only be plentiful if computers (ASICs) are fast enough that it is worth taking the extra transaction fees with bigger blocks. Any problems with this?
That's the basic idea behind Greg's proposal. I've yet to examine it in detail; I think it was actually what I thought about first, before eschewing it in favor of a deductive penalty. I think there are errors in your description of how to implement this. It's not about what you hash, it's about what your target hash is. Also, you need to carefully choose the function that maps block size to mining effort. Can you link Gregs proposal? I haven't seen it. Currently I have this link - http://sourceforge.net/p/bitcoin/mailman/message/34100485/. It's not the original proposal but some followup discussion. I still need to dig and trace it back to the source. |
|
|
|
I think a better solution would be to require miners to do more work for larger block sizes. Instead of hashing just the header of a block, miners have to hash something more: perhaps something proportional to the block size. So if a header is 80 bytes, it takes up 80/1000000=8e-05 of the whole block. So for any block size x > 1 MB, require a miner to hash the first (8e-05)x of the block in order for it to be valid. This will make Bitcoin automatically scale to the power of computers in the future, as big blocks will only be plentiful if computers (ASICs) are fast enough that it is worth taking the extra transaction fees with bigger blocks. Any problems with this?
That's the basic idea behind Greg's proposal. I've yet to examine it in detail; I think it was actually what I thought about first, before eschewing it in favor of a deductive penalty. I think there are errors in your description of how to implement this. It's not about what you hash, it's about what your target hash is. Also, you need to carefully choose the function that maps block size to mining effort. |
|
|
|
The key here is how is T set. If T is fixed then 2T becomes the hard limit and the problem remains. If T is set based on an some average of previously mined blocks then this may address the problem
thisactually, just use twice the average blocksize of the last two weeks. And you don't really need any of this complicated system. 1. Floating block limits have their own set of problems, and may result in a scenario where there is no effective limit at all. 2. Even if you do place a floating block limit, it doesn't really relieve of the need for an elastic system. Whatever the block limit is, tx demand can approach it and then we have a crash landing scenario. We need a system that gracefully degrades when approaching the limit, whatever it is. |
|
|
|
I'll try to repeat the calculations with a different demand curve, to demonstrate my point. But this will take some time and Shabbat is in soon, so that will have to wait.
Let's assume the demand curve - the number of transactions demanded as a function of the fee, per 10 minutes - is d(p) = 27/(8000p^2). It's safe to have d(p)->infinity as p->0 because supply is bounded (if there was no bound on supply, we'd need a more realistic bound on demand to have meaningful results). The behavior below is the same for other reasonable demand curves, as long as demand diminishes superlinearly with p (sublinear decay is less reasonable economically, and results in very different dynamics). We'll assume 4000 transactions go in a MB, and that T=1MB. So the penalty, as a function of the number n of transactions, is f(n) = max(n-4000,0)^2 / (4000*(8000-n)). We'll also assume that transactions are in no particular rush - users will pay the minimal fee that gives them a good guarantee to have the tx accepted in reasonable time (where this time is long enough to include blocks from the different miner groups). So there is a specific fee p for which the tx demand clears with the average number of txs per block (the number of txs can change between blocks). It would have been more interesting to analyze what happens when probabilistic urgency premiums enter the scene, but that's not relevant to the issue of mining centralization. Scenario 1: 100 1% miners. Each miner reclaims 1% of the penalty. If the optimal strategy is to have n txs per block, resulting in a fee of p, then n=d(p) and the marginal penalty (derivative of f) at n, corrected for the reclaiming, must equal p (so that adding another transaction generates no net profit). In other words, 0.99f'(d(p)) = p. Solving this gives p = 0.7496 mBTC, n = 6007. Penalty is 0.5053 BTC, so pool size is 50.53. Miners get 4.5027 BTC per block (6007 * 0.0007496 from txs + 0.5053 collection - 0.5053 penalty). 6007 txs are included per block. Scenario 2: One 90% miner and 10 1% miners. The market clears with a tx fee of p, with the 90% miner including n0 txs per block and the 1% miners including n1 txs per block. The average #txs/block must equal the demand, so 0.9n0 + 0.1n1 = d(p). Every miner must have 0 marginal profit per additional transaction, correcting for reclaiming. So 0.1 f'(n0) = p 0.99 f'(n1) = p Solving all of this results in: n0 = 7251 n1 = 5943 p = 0.6885 mBTC (lower than in scenario 1) Penalty paid by 1% miners: f(5943) = 0.4589 BTC Penalty paid by 90% miner: f(7251) = 3.5294 BTC Average penalty: 0.9*3.5294 + 0.1*0.4589 = 3.2223 BTC Pool size: 322.23 BTC Reward per block for 1% miner: 5943 * 0.0006885 + 3.2223 - 0.4589 = 6.8552 BTC (more than in scenario 1) Reward per block for 90% miner: 7251 * 0.0006885 + 3.2223 - 3.5294 = 4.68521 BTC (less than 1% miners in this scenario; more than the miners in scenario 1). Average number of txs per block: 0.9 * 7251 + 0.1 * 5943 = 7120, more than in scenario 1. Miners are happy - big or small, they gain more rewards. Users are happy - more of their transactions are included, at a lower fee. Nodes are not happy - they have to deal with bigger blocks. Exactly as with the previously discussed demand curve. Over time, difficulty will go up, nullifying the extra mining reward; and whoever is in charge of placing the checks and balances, will make the function tighter (or hold on with making it looser), to keep the block sizes at the desired level. There is another issue at play here - the ones who benefit the most from the big miner's supersized blocks, are the small miners. The big miner could threaten to stop creating supersized blocks if the small miners don't join and create supersized blocks themselves. Forming such a cartel is advantageous over not having supersized blocks at all - however, I think the big miner's bargaining position is weak, and small miners will prefer to call the bluff and mine small blocks, avoiding the penalty and enjoying the big miner's supersized blocks. This is classic tragedy of the commons, but in a sort of reverse way - usually, TotC is discussed in this context when the mining cartel wants to exclude txs, not include them. |
|
|
|
So more analysis is still in order, but overall, I don't think these dynamics encourage the formation of big miners.
This is encouraging... it sounded yesterday as if you had almost regretted making this thread and were about to pull your own support from the proposal because of this and now it looks like it might be less of a problem than initially thought. At the moment I'm confident that the claimed centralization issue does not invalidate the method - whatever effect there might be, it's nullified with a correct parameter choice. I'm not as confident in my ability to convince others of this, but I can try. Note, though, that superlinear mining rewards is a problem in general, I just don't see how this proposal contributes to it. - Do the 2 25% miners (or 2 of the 10% miners) have a higher-than-in-current-system incentive to collude?
- Is Menis proposal making it easier for the 2 25% miners to try to drive out small (as in bandwidth) miners by mining disproportionally large blocks?
Both questions boil down to - Does Menis proposal encourage centralization more than the current system?
Before I go on... am I asking the correct questions? To be honest, I'm not sure. There are different elements at play here with complex interplay at different timescales. The usual question I'd ask is "do big miners have a superlinear advantage over small miners?". I claim above that the answer is no, but I'm now sure that answering this question alone is sufficient. Obviously if you can find someone to work a PoC for your proposal, that would be fantastic.
That was one of the purposes of this thread. If the proposal finds enough support, I'm sure we can crowd-fund a PoC.
FWIW, I'll be happy to contribute to it. |
|
|
|
Here are example scenarios, with made up values for the penalty function. I assume for simplicity (not a necessary assumption) that there is endless demand for transactions paying 1mBTC fee, that typical blocks are around 2K txs, and that there are no minted coins. The pool clears at 1% per block.
Scenario 1: The network has 100 1% miners.
Every 1% miner knows he's not going to claim much of any penalty he pays, so he includes a number of transactions that maximize fees-penalty for the block. This happens to be 2K txs, with a total fee of 2 BTC and penalty of 1 BTC.
The equilibrium for the pool size is 100 BTC.
Miners get 2 BTC per block (2 fees + 1 pool collection - 1 penalty).
There are 2K txs per block.
Scenario 2: The network has 1 90% miner, and 10 1% miners.
The 1% miners build blocks with 2K txs, fee 2 BTC, penalty 1 BTC, like before.
The 90% miner knows that if he includes more txs, he'll be able to reclaim most of the penalty, so the marginal effective penalty exceeds the marginal fee only with larger blocks - say, which have 4K txs, 4 BTC fees, 4 BTC penalty.
The average penalty per block is 3.7 BTC. The equilibrium pool size is 370 BTC.
There are on average 3.8K txs per block.
A 1% miner gets, per block he finds, (2 + 3.7 - 1) = 4.7 BTC - more than in scenario 1!
The 90% miner gets, per block he finds, (4 + 3.7 - 4) = 3.7 BTC - less than small miners get in this scenario, but more than miners get in scenario 1!
Those examples do not stand. They hinge on the premise that there is endless demand for transactions paying 1mBTC fee. I understand the need to simplify these demonstrations but that defeats the underlying premise of this entire discussion. You example assumes there is no competition over fees, which is the premise of a "no block limit + hard fees" system. Your system sets both soft and hard caps to the block size, so there is no reason to believe people will sit at a 1mBTC fee when there is an endless demand for transactionsModel your demonstration with a fee structure using the Pareto principle i.e. 20% of the transactions pay for the 80% of the total fees available in the mempool (which is a lot closer to the current network's fee distribution than your examples), and the system falls apart. Anyone building blocks large enough to get penalized is just giving his rewards away to miners that prioritize big fee transactions and make a point of staying under the soft cap. The issue with your proposal is not the penalty per say, it's the reward: there is a point where it is more profitable to let others get penalized. The existence of this point creates a threat that keeps all miners functioning below the soft cap. The threat is that they lose profitability in comparison to other pools, and those pools start siphoning away their hash rate as miners migrate. I'm sorry, but I disagree. The scenarios don't "hinge" on this assumption, I just had to assume something in order to give concrete numbers. The effects I discussed should remain intact whatever the true transaction demand curve is. The assumption also does not defeat the premise of the discussion, either. There is some demand curve for txs which depends on the real-world usage of the system, and we're talking about matching a supply curve to it. It's completely legitimate (though of course grossly exaggerated) to assume the demand curve is - infinite demand for txs with fee <1mBTC, and 0 for higher fees. With this hypothetical demand curve, fees will remain at 1mBTC because no one is willing to pay a higher fee, and no tx with lower fee will be accepted. In other words, the supply curve must intersect demand at its vertical drop line. I'll try to repeat the calculations with a different demand curve, to demonstrate my point. But this will take some time and Shabbat is in soon, so that will have to wait. As for the analysis, I also disagree. You can't "let others get penalized", every miner chooses his own penalty. The best you can do is penalize yourself, knowing that you'll reclaim the penalty later - but in so doing, you also increase the rewards for others. The drawback is that since there is no reward, obviously the penalties are just destroyed. I'm not sure that's a drawback per say, for the following reasons:
1) It's trivial to blackhole bitcoins and it's been agreed that this is not damaging to the system. So this method isn't introducing some new DOS attacks on the system.
2) By destroying the penalty, the value of every other BTC just went up. As opposed to your system where you want to reward other miners from the penalties, this time everyone is getting rewarded, albeit in a much smaller magnitude. This means both miners, but everyone else holding coins is rewarded when a miner builds a block above the soft cap. Incidentally, that also means people running nodes (as long as they hold BTC, which is expectable).
Destroying coins in small amounts is not very harmful. But if done continuously as part of the system, it has negative macroeconomic implications. per say
Grammar Nazi regulations state that if you make the same error twice in a discussion, you must be corrected. We're already at 4. It's "per se". |
|
|
|
I'd be in his position I'd would too ask to see some code or at least some data analysis supporting the design. You can't just propose stuff and expect the people reviewing it to do all the leg work. An implementation at least proves your design is conceptually sound. It's easy to forget certain aspects when you theorycraft, and having to implement at least the PoC certainly motivates you to keep it as simple as possible.
Not sure to which extent this is criticism to me. But I believe everyone has a part to play in this world, and should be doing what he's best at. My comparative advantage is in coming up with ideas and discussing them; and in unrelated work (to those who don't know me, my day "job" is in promoting Bitcoin in Israel). It's not in coding and empirical analysis - I'll leave that to others. This methodology worked quite well at the time I helped mining pool operators with implementing DGM. Perhaps the discussion I've started will result in this or a similar idea being implemented and accepted. But if not, so be it. I'll clarify that I think Gavin's request is perfectly legitimate. I didn't exactly expect him to be so dazzled by the idea that he'd drop everything he was doing and start working on it. |
|
|
|
A longer time period over which the reward is given doesn't help, as the larger nodes or entities will still get a larger ratio of the rolling over fees, by definition.
While writing a response to this, I realized the situation is actually much more nuanced than I thought. Big miners don't have an advantage over small miners. Rather, the existence of big miners shifts the balance of the system as a whole, creating a situation where miners get more rewards, users pay less fees and/or get more of their transactions included, while nodes have to deal with larger blocks. Here are example scenarios, with made up values for the penalty function. I assume for simplicity (not a necessary assumption) that there is endless demand for transactions paying 1mBTC fee, that typical blocks are around 2K txs, and that there are no minted coins. The pool clears at 1% per block. Scenario 1: The network has 100 1% miners. Every 1% miner knows he's not going to claim much of any penalty he pays, so he includes a number of transactions that maximize fees-penalty for the block. This happens to be 2K txs, with a total fee of 2 BTC and penalty of 1 BTC. The equilibrium for the pool size is 100 BTC. Miners get 2 BTC per block (2 fees + 1 pool collection - 1 penalty). There are 2K txs per block. Scenario 2: The network has 1 90% miner, and 10 1% miners. The 1% miners build blocks with 2K txs, fee 2 BTC, penalty 1 BTC, like before. The 90% miner knows that if he includes more txs, he'll be able to reclaim most of the penalty, so the marginal effective penalty exceeds the marginal fee only with larger blocks - say, which have 4K txs, 4 BTC fees, 4 BTC penalty. The average penalty per block is 3.7 BTC. The equilibrium pool size is 370 BTC. There are on average 3.8K txs per block. A 1% miner gets, per block he finds, (2 + 3.7 - 1) = 4.7 BTC - more than in scenario 1! The 90% miner gets, per block he finds, (4 + 3.7 - 4) = 3.7 BTC - less than small miners get in this scenario, but more than miners get in scenario 1! To restate what goes on - the big miners create supersized blocks because it benefits them, but it benefits the small miners even more. Miners are happy. Users are happy. Nodes are not happy. But note the following: Big miners make the mining rewards bigger, but you don't have to be a big miner to enjoy it (small miners actually are at an advantage). So if a miner becomes big, he encourages more people to start mining, raising the difficulty and countering the effect. So more analysis is still in order, but overall, I don't think these dynamics encourage the formation of big miners. |
|
|
|
By miner has to pay it, we mean "not paid to miner but to rollover pool instead"? They miner is never paying anything, they are simply not given the reward, yes?
No, by "miner has to pay it", we mean he always has to pay it, even if he receives no on-chain fees. You're both correct, it's a matter of terminology. The miner has to pay it. But he's not paying by spending any of his previous coins, he's paying by having the payment deducted from the reward he collects. If the reward is not sufficient (negative reward after deduction), the block is invalid. So the miner will not include so many transactions that the penalty will make the block invalid. See my previous comment and I hope everything is clearer now. I apologize for not intervening sooner, I had a busy day, maybe this whole exchange could have been avoided... |
|
|
|
...
I'll try to examine your proposal in more detail later. There is a major shortcoming I can see in the rollover fee pool suggestion: miners are incentivized to accept fees out of band so they can obtain all the highest fees instantly, thus defeating the entire purpose of that feature.
This is only (potentially) a problem in my 2012 rollover fee proposal. Here, tx fees don't go into the pool - fees are paid to the miner instantly. It is only the miner's block size penalty that goes in to the pool, and he must pay it if he wants to include all these transactions. Just so I can understand properly, your penalty is related to a formula that excludes the transaction fees, therefore paying fees out of band won't reduce the penalty. Is that how the problem is solved? Looks correct, but I would say there was no problem to begin with. I think the current design already incentivize smaller blocks: Smaller blocks get broadcasted much faster and become less possible to be orphaned. If you consider that there are 25 coins to compete for, you would like to broadcast your block as fast as possible once you find it
This is correct but as far as I know, the magnitude of this effect is very small, and not enough to keep block size in check. That said, a problem with any kind of rollover fee is that it assumes that moving fees to future blocks is also moving fees to different nodes.
This is correct, and I hadn't given enough thought to this problem prior to posting. Now that I've given it more thought, I think it can be significantly alleviated by making collection from the pool span a longer period, on the time scale of years. Relative hashrate is likely to change over these period, so it may not be the best plan to publish excessively large blocks hoping to reclaim the fee (and publishing typical-sized blocks does not give big miners an advantage). Also, with a different function you can change the balance between the marginal and total penalty so that the actual penalty is small, nullifying the effect (it will require the cap to be a bit harder, but still more elastic than what we have now). I agree that this calls for more analysis. Can you explain a bit about the mechanism wherein the miner pays into the rollover pool
Not much to explain. The penalty is deducted from the amount of bitcoins he can credit himself in the generation transaction; The network keeps track of the total pool size, and allows miners to add a fraction of it to the bitcoins they credit themselves. Instead of total outputs = new coins + tx fees You have total outputs = new coins + tx fees + collection from pool - penalty It is not obvious why this dictinction makes a difference. It seems to still incentivize out of chain payments to miners for transaction inclusion regardless of whether it is paid by the miner, or deducted from the miner's reward, both are dependent on the fees in the block (which aren't there in out of block payments schemes).
The penalty doesn't depend on the fees of txs in the block. It depends on the size of txs in the block. Out-of-band payments are irrelevant - the miner must include the transaction to perform the service he would be paid for. If he includes it he pays a penalty for it, and expects a fee for it - it doesn't matter to either him or the user if the payment is out-of-band or not (except, of course, the extra friction of out-of-band). The rollover pool creates an incentive for the miner to not use the fee pooling, and instead contract directly with the TX creators.
If implemented as written, this could become a problem. Large TX creators and large miners would have an incentive to cartel because of the way this rollover pool works.
This is simply false, as explained above. It seems many people are confusing the current suggestion, with the suggestion I brought up back in 2012 and referenced here. Thanks for that, it was my reading also.
Thus TX fees that are not in the block but paid out of band are not subject to penalty...
It's an additive deduction, not multiplicative. You seem to be thinking the miner's reward is: (1 - penalty) * (minted coins + tx fees + collection from pool) Where it is really: minted coins + tx fees + collection from pool - penalty Having more fees in the txs included doesn't increase the penalty. There is no difference between adding 1 mBTC to the fee and paying 1 mBTC out-of-band. Another difference, is that in the Monero method, the penalty can not reduce the block reward to below zero and make the block invalid.
The miner chooses how many transactions to include. The penalty starts at 0 and stays there for a while (or alternatively, has a derivative starting at 0). He chooses the set of txs so that his profit is maximal, not so that it is negative... (PS I apologize for the multiple comments on the same issue, I'm trying to respond to all claims in the order I see them...) , and why that is different from the 'original proposal'?
I'll need to examine the Monero implementation in more detail to answer that intelligently. One difference is that Monero, apparently, already has a mechanism to defer rewards to future miners, so it has no need to introduce the extra concept of a rollover pool. Additionally, I suggest a different scaling function (hyperbolic rather than quadratic). It has a different set of tradeoffs (which I currently believe is better overall). I could suggest a different function based on the requirements - finding the best functions to manifest given intuitive concepts is what I'm good at. Monero avoids this problem, but most of the rest of this proposal has been implemented and running for quite a long time. Its not new, or novel, except in ways that it is not as good.
An examination of the prior art is warranted.
I agree with the last part. I, too, am upset when people try to reinvent the wheel. But it's difficult to know whether some feature exists in some system somewhere. I've read several discussions of block size and didn't see a mention it. I started with privately chatting with Gavin and Mike, and they seemed unaware of it either. I don't think it was reasonable for me to do anything but post about it and see what people think, which I did. If I had known about the situation in Monero I may not have made this post. I'm glad that I did, though. As we can see from the lively discussion here and on reddit, there are obviously many people who are interested in this kind of solution but who, like me, were not previously aware of Monero's system. I think wider awareness and discussion of these issues is a good thing. |
|
|
|
My email correspondence with Gavin so far:
lol he just called you an ideas man, your efforts are futile, Bitcoin is the Eldorado and has no flaws no dev will ever adopt something made by other coins, it would imply Satoshi was slight equivocated in his first attempt at blockchain  That's not really what he said. I am mostly an idea man though, and happy to be one. Holy Cow I was unaware of this thread, thanks I have some reading to do at work now. And the initial reason I commented on this post is because nobody else had and it would have been a shame to see it fall off the first page with no responses. Well, I think there is some policy about writing comments that don't add new content of their own and just support previous content, or something. I was happy to see your feedback. As I recall, you posted your comment quite early, before there was a real need for bumping, but I appreciate the intent. This is quite the idea... It has definitely some legs to run the long run.
What bothers me is really how to implement it... I'm also not knowledgeable in code, but the pool seems a pretty complex thing to setup. The funds would have to reside in an address. Who would hold such private key?
No, the funds don't reside in an address. That's like saying that the 6.8 million bitcoins that haven't been mined yet reside in an address. The funds just exist as a feature of the network, and the protocol defines how they are paid out to future miners (in the same way that the protocol dictates that each miner currently gets 25 BTC). I don't believe the implementation is that complicated, but people more familiar with the codebase are in a better position to comment on that. |
|
|
|
My email correspondence with Gavin so far: Hi Mike, As I was reading your posts about the block size limit, I came to the realization that the problem isn't really that the block size is too low. It's that the protocol lacks a mechanism for graceful degradation. People expect that as the size limit is approached, fees will elastically adapt. I agree with your arguments that it doesn't work this way, but I think that it should work this way; and if it doesn't now, we should solve that problem. Once we do, the worst that could happen with a block limit too low, is that fees will be too high. Of course, that could require some significant protocol changes. I've been thinking along the following lines: A miner can create a block of arbitrary size, however, he must pay a penalty for large blocks. This penalty will be deducted from his coinbase transaction, and added to a rollover fee pool, to be collected by future miners (as in https://bitcointalk.org/index.php?topic=80387.0). The penalty will be a hardcoded function of the block size. The function should be superlinear; it can optionally be 0 for block sizes up to a given threshold; and it could have a bend around some agreed upon value (1MB, 20MB, whatever) to encourage the size to be around this value. An optimal miner will include a transaction only if the marginal penalty is lower than the fee. As the block size increases, the marginal penalty per kB will be higher, requiring a higher fee. This is superior to a hard cap in several ways. First, it's always possible for all txs to clear, as long as users are willing to pony up; with a hard cap, even if all users agree to pay more, you still can't include all of their transactions, creating a backlog. Second, the overall behavior of the fees is smoother over time. Instead of the marginal cost per transaction being roughly 0 in low-traffic times and approaching infinity in high-traffic times, it varies continuously with the current traffic. This makes it easier to gather statistics, and to choose the fee to pay accordingly. And you still have a market that adapts to actual economic incentives. Of course there's more I can say about the analysis of this suggestion, but that's the basic idea. I might post about this somewhere more public, not sure exactly where though... Meni Mike's on vacation, don't expect a response (and Mike, you're on vacation, you shouldn't be thinking about this stuff....)
My knee-jerk reaction is: cool, write up a patch for Bitcoin Core (with tests, please) so we can see how extensive the changes would be. It is easy to have an idea, but there are so many ideas I need a filter to winnow down the number of possibilities or it is impossible to carefully consider them all. "Go write some code we can look at" is a very good filter.
Other people's knee-jerk reactions will be: this won't work when the subsidy goes away, so it is a non-starter. See Greg Maxwell's proposal for "require more mining (higher nBits) to produce bigger blocks" for a scheme that might work when the subsidy goes away.
On a higher level: I agree that graceful degradation is much better than a hard crash-- that is why I implemented 'smart fees' for Bitcoin Core.
Hi Gavin, 1. That's a fair request, unfortunately writing code is not where my comparative advantage is. I might be able to persuade others to write the code, though. There's never a shortage of ideas, of course - but not all ideas are born equal, some are bad, some are good; and some ideas are so obviously bad you don't even need to test them. 2. As I've argued in the past, and in an interview posted today ( http://bit-post.com/bitcoiners/interview-with-meni-rosenfeld-the-block-size-limit-and-mining-fee-structure-6105), funding miners when the subsidy goes away is a completely different problem which needs completely different solutions, which have nothing to do with block size. Anyway, I'm not sure what exactly you mean by "it won't work" - in case you meant that without subsidy there will be nowhere to take the penalty from, of course the penalty can be taken out of tx fees, and the block is illegal if the total penalty is higher than the total fee. So miners will still only accept txs with sufficiently high fees. Interesting. How do we decide what "T" should be ? My knee-jerk reaction: I bet a much simpler rule would work, like: max block size = 2 * average size of last 144 blocks. That would keep the network at about 50% utilization, which is enough to keep transaction fees falling from to zero just due to people having a time preference for having transactions confirmed in the next 1/2/3 blocks (see http://hashingit.com/analysis/34-bitcoin-traffic-bulletin ). I think this simple equation is very misleading: Bigger blocks -> Harder to run a node -> Less nodes -> More centralization People are mostly choosing to run SPV nodes or web-based wallets because: Fully validating -> Less convenience -> Less nodes -> More centralization Node count on the network started dropping as soon as good SPV wallets were available, I doubt the block size will have any significant effect. Also: Greg's proposal: http://sourceforge.net/p/bitcoin/mailman/message/34100485/Hi Gavin,
1. a. I don't believe in having a block limit calculated automatically based on past blocks. Because it really doesn't put a limit at all. Suppose I wanted to spam the network. Now there is a limit of 1MB/block so I create 1MB/block of junk. If I keep this up the rule will update the size to 2MB/block, and then I spam with 2MB/block. Then 4MB, ad infinitum. The effects of increasing demand for legitimate transaction is similar. There's no real limit and no real market for fees.
b. I'll clarify again my goal here is not to solve the problem of what the optimal block limit is - that's a separate problem. I want to prevent a scenario where a wrong block limit creates catastrophic failure. With a soft cap, any parameter choice creates a range of legitimate block sizes.
You could set now T = 3MB, and if in the future we see that tx fees are too high and there are enough blocks, increase it.
2. I have described one causal path. Of course SPV is a stronger causal path but it's also completely irrelevant, because SPV clients are already here and we don't want them to go away. They are a given. Block size, however, is something we can influence; and the primary drawback of bigger blocks is, as I described, the smaller number of nodes.
You can argue that the effect is insignificant - but it is still the case that
Many people currently do believe the effect is significant, and
This argument will be easier to discuss once we don't have to worry about crash landing.
3. Thanks, I'll try to examine Greg's proposal in more detail.
Meni
On Tue, Jun 2, 2015 at 5:37 PM, Meni Rosenfeld wrote: 1. a. I don't believe in having a block limit calculated automatically based on past blocks. Because it really doesn't put a limit at all. Suppose I wanted to spam the network. Who are "you" ? Are you a miner or an end-user? If you are a miner, then you can produce maximum-sized blocks and influence the average size based on your share of hash rate. But miners who want to keep blocks small have equal influence. If you are an end-user, how do you afford transaction fees to spam the network? ---------------------- If you are arguing that transaction fees may not give miners enough reward to secure the network in the future, I wrote about that here: http://gavinandresen.ninja/block-size-and-miner-fees-againand here: https://blog.bitcoinfoundation.org/blocksize-economics/And re: "there is no real limit and no real market for fees" : see http://gavinandresen.ninja/the-myth-of-not-full-blocksThere IS a market for fees, even now, because there is demand for "I want my transaction to confirm in the next block or three." 1. I'm an end user.
If there are hard coded rules for tx fees and spam prevention, then that is what is ultimately keeping the block size in check, not the block limit.
If there are none, and the only source of fees is competition over the limited block size, then there will be no real competition (for the reason I mentioned - the limit keeps increasing), and I will not have to pay any fees.
In both cases, the floating block limit doesn't do much.
2. I argue, as I always do, that funding miners for the hashing should not have anything to do with the data size of transactions and blocks.
In the current argument I'm not talking about the amortized cost of hashing. I'm talking about paying for the marginal cost of handling transactions (which does depend on size), and that the fees will make their way to the nodes bearing these costs. Under that assumption, I want to make sure people are actually paying fees for the resources consumed - and for that, I want to keep supply in check.
3. There is indeed a fee market, when the variability in the rates of clearing and adding txs exceeds the difference between the block limit and the global average tx rate. However, at low-traffic times, rational markets will not require significant fees. As a spammer I can use that time to create spam and trick the recalibration mechanism. As a legitimate user, I could use this time to send non-urgent txs. This reduces variability and works to stretch the limit.
Perhaps automatic calibration can work with a good enough mechanism, but I think it's more dangerous than occasionally updating a hardcoded value.
|
|
|
|
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. are you suggesting we drop btc and pick up vtc?
Not familiar with it. 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. 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. |
|
|
|
Unlike Meni's suggestion, the reduction in block subsidy is not given to a pool but rather deferred to future miners because the subsidy algorithm is based around the number of coins.
Well, the pool does have the ultimate effect of deferring rewards to future miners. Interesting. I argue that regardless of other issues, the particular function they suggest is not optimal, and the cap it creates is too soft. There is a major shortcoming I can see in the rollover fee pool suggestion: miners are incentivized to accept fees out of band so they can obtain all the highest fees instantly, thus defeating the entire purpose of that feature.
This is only (potentially) a problem in my 2012 rollover fee proposal. Here, tx fees don't go into the pool - fees are paid to the miner instantly. It is only the miner's block size penalty that goes in to the pool, and he must pay it if he wants to include all these transactions. Of course, if you'd like to post this criticism on that thread, I'll be happy to discuss it. Just a comment on the following: With a hard cap, the queue of transactions can only clear at a specific rate. Below this rate there is no fee tension, and above it there is instability. I don't think you can say that - that would be like saying, queues are never a problem as long as utilization is < 1 (which of course is required for stability). But long queues do in fact develop when utilization is < 1, due to variability in service / arrival times (re: bitcoin, the dominant source of variability is in inter-block times). As long as there are queues, fee tension will be present, as mempool transactions are largely prioritised by feerate. Empirically, we are observing periods of fee tension (i.e. busy periods, when pools' max block size is reached) quite often these days. Otherwise I like this perspective on the block size problem (even though I can't really comment on the proposed solution), in particular the observation that in the short term transaction demand is inelastic. (Upon further thought, however, proponents of increasing block size would say that the inelastic demand problem doesn't really apply if the block size cap is sufficiently higher than the average transaction rate.) That's true in general; however, for the specific time scales and fluctuations in queue fillrate we have here, I'd say that "no fee tension" may be an exaggeration, but captures the essence. Sure, if the block limit is high enough we can always clear transactions... But then there will be little incentive to give fees or conserve space on the blockchain. The post assumes that we agree that too low is bad, too high is bad, and we don't want to be walking a thin rope in between. (1) bypass vulnerability (where you pay fees, or the like, out of band to avoid the scheme)
I don't think this is an issue here. Transaction fees are paid instantly in full to miners, so users have no reason to pay fees out of band. Miners are forced by protocol to pay the penalty if they want to include the transactions (and if they don't include the transactions, they're not doing anything they could be paid for). You could talk about miners paying penalty into the pool hoping to only get it back in future blocks, but with a pool that clears slowly enough, that's not a problem. (2) scale invariance (the scheme should work regardless of Bitcoin's value).
In the space of block sizes, you do need to occasionally update the parameter to match the current situation. I think it's best this way - currently only humans can reliably figure out if the fees are too high or node count is too low. But if a good automatic size adjustment rule can be found, it can be combined with this method. In the space of Bitcoin value, transaction fees and hardware cost, the proposed function is multi-scaled and thus cares little about all of that. For any combination of the above, the function will find an equilibrium block size for which the penalty structure makes sense. I think this kind of proposal is a massive improvement on proposals without this kind of control; and while it does not address all of the issues around larger blocks-- e.g. they do not incentive align miners and non-mining users of the system-- it seems likely that proposals in this class would greatly improve a some of them of them; and as such is worth a lot more consideration.
I'm still hoping Red Balloons, or something like it, will solve that problem. Thanks for posting, Meni-- I'm looking forward to thinking more about what you've written.
Thanks, and likewise - I've only recently heard about your effort-penalty suggestion, I hope to be able to examine it and do a comparison. I expect a fee pool alone will increase block verification cost.
It would not, in any meaningful way. Right, the proposal here only adds a constant amount of calculations per block, taking a few microseconds. It doesn't even grow with the number of transactions. I would scrap the fee pool and use the function the opposite way: the total sum of fees paid in the block defines the maximum block size. The seeding constant for this function could itself be inversely tied to the block difficulty target, which is an acceptable measure of coin value: i.e. the stronger the network, the higher the BTC value, and reciprocally the lower the nominal fee to block size balance point.
With an exponential function in the fashion of Meni's own, we can keep a healthy cap on the cost of larger blocks, which impedes spam by design, while allowing miners to include transactions with larger fees without outright kicking lower fee transactions out of their blocks.
As Meni's proposal, this isn't perfect, but I believe it comes at the advantage of lower implementation cost and disturbance to the current model, while keeping the mechanics behind block size elasticity straight forward. Whichever the community favors, I would personally support a solution that ties block size limit to fees over any of the current proposals.
This is similar to the idea of eschewing a block limit and simply hardcoding a required fee per tx size. The main issue I have with this kind of ideas is that it doesn't give the market enough opportunity to make smart decisions, such as preferring to send txs when traffic is low, or to upgrade hardware to match demand for txs. Another issue with this is miner spam - A miner can create huge blocks with his own fee-paying txs, which he can easily do since he collects the fees. Using difficulty to determine the size/fee ratio is interesting. I wanted to say you have the problem that difficulty is affected not only by BTC rate, but also by hardware technology. But then I realized that the marginal resource costs of transactions also scales down with hardware. The two effects partially cancel out, so we can have a wide operational range without much need for tweaking parameters. |
|
|
|
|
Show Posts
