Pages:
Author

Topic: Elastic block cap with rollover penalties - page 2. (Read 24092 times)

member
Activity: 129
Merit: 14
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.

I apologize for making this even more academic, however this is a complex proposal and there will always be games and ways of analyzing this which are analogous to the prisoner's dilemma.  For example a large miner (A) could consider that producing a smaller block leaves more transactions in the meme pool, such that another miner (B) would be incentivised to produce a larger block and pay a larger penalty and this would increase the rollover pool, which large miner A could collect.

Miners want to maximize their (tx fees - X * penalty) + collection +-  X * impact the decision has on other miners block sizes and the associated penalty's

X = projected share of the network hashing power

That's not the point. What prevents the competition from pulling from the pool without contributing to it? I understand that it's in the interest of a massive node or cartel of nodes to mine large blocks, but only if they aren't undermined by their competitors, which can pull from the pool without paying any penalty themselves.

Nothing prevents miners leaving pools.  Is that not desirable?  This could potentially be a great characteristic of Meni's proposal.  Undermining a large cartel of miners in favor of smaller miners seems great.  (I don't know if Meni thought of this when he made the proposal, or it was kind of luck?)

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

I think this potentially sounds like a good idea.
sr. member
Activity: 433
Merit: 267
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...
That's not the point. What prevents the competition from pulling from the pool without contributing to it? I understand that it's in the interest of a massive node or cartel of nodes to mine large blocks, but only if they aren't undermined by their competitors, which can pull from the pool without paying any penalty themselves.

The nodes can't have their cake and eat it too... But they can eat it. Ultimately, there would be no pool.

If there are several big miners, they should all create supersized blocks, and then every miner will enjoy the supersized blocks of the others.
Yes, they should, and this would be a cartel; where each is cooperating with each-other for greater profits, and it would break up in the same fashion as other cartels; Any member of the cartel profits more by not contributing to the penalty pool.
donator
Activity: 2058
Merit: 1054
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.
legendary
Activity: 1204
Merit: 1002
Gresham's Lawyer
Anyway, this requires more research.

Start a block chain and try it out.
sr. member
Activity: 433
Merit: 267
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. Why wouldn't the bigger miner mine smaller blocks and get the higher BTC per block, like your example was showing?

On the other hand, if it really is more profitable to mine larger blocks, then why wouldn't the smaller hashpower nodes do it? If they do, then the same problems I mentioned before would apply (The penalty would give a competitive advantage to the higher hashpower nodes).


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?


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.

This is actually analogous to cartelization; Big companies cooperating to achieve greater profits. However.. Cartels, absent the power of the State, always break down, because the first one that does can achieve greater profits at the expense of the cartel as a whole.

Quote
Weaknesses of cartels
Analysis demonstrates that a cartel is an inherently unstable form of operation:
If pooling resources is more profitable, then the cartel will merge into one company.
If it proves to be less profitable, the individual members of the cartel will break off.
If it doesn’t break from within, an outsider, noticing the enormous profitability, will enter the market, and this dooms the cartel.
Particularly likely to be restive under the imposed joint action will be the more efficient producers, who will be eager to expand their business rather than be fettered by shackles and quotas to provide shelter for their less efficient competitors. If the cartel does not break up from within, it is even more likely to do so from without. To the extent that it has earned unusual monopoly profits, outside firms and outside producers will enter the same field of production.
http://wiki.mises.org/wiki/Cartel
donator
Activity: 2058
Merit: 1054
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:
Code:
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.
donator
Activity: 2058
Merit: 1054
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.
member
Activity: 78
Merit: 11
Chris Chua
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:
Code:
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
sr. member
Activity: 433
Merit: 267
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.
legendary
Activity: 1204
Merit: 1002
Gresham's Lawyer
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.
This is simultaneously the best feature of the proposal, and the one most likely to prevent it from becoming part of Bitcoin.

Ok. I was primarily refuting the implied claim that this formula would make sense when applied to Bitcoin.
There was no such claim, implied or otherwise.
The coins are fundamentally different, but the similarity of this feature would have provided a good place to have started, if you had known of it.
Better late than never though.
donator
Activity: 2058
Merit: 1054
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 graph1, 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.png

Edit: T was defined as the target block size.
See a worked example at https://bitcointalksearch.org/topic/m.11557115. 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.
legendary
Activity: 1484
Merit: 1005
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.
sr. member
Activity: 433
Merit: 267
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 graph1, 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.png

Edit: T was defined as the target block size.
donator
Activity: 2058
Merit: 1054
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.
legendary
Activity: 1204
Merit: 1002
Gresham's Lawyer
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.
donator
Activity: 2058
Merit: 1054
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.
legendary
Activity: 1484
Merit: 1005
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.
legendary
Activity: 3794
Merit: 1375
Armory Developer
I'm getting slammed at work so I won't be able to come up with a properly crafted response to your new model this week.
donator
Activity: 2058
Merit: 1054
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.
donator
Activity: 2772
Merit: 1019
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.
Pages:
Jump to: