Go start your own fork you stupid fuck -

[jbreher]

Holliday, I lurves ya, man. But reducito al absurdium is unbecoming.

Look at some of the responses in this thread. You are calling me out as unbecoming because I made a joke?

Naah. My mistake. I thought you were stating that you thought such was a real risk.

[franky1]

I can't wait for Bitcoin Unlimited Take Two, where the block reward is dynamically determined by the free market...

actually those that love core were coming up with an option where dynamic blocks are possible, but with a penalty of reducing the blockreward if its implemented. and greg actually liked it

Elastic block cap
The heart of the suggestion is - instead of forbidding large blocks, penalize them. The miner of a large block must pay a penalty that depends on the block's size. The penalty will be deducted from the funds he collects in the generation transaction, and paid into the rollover pool, to be distributed among future miners. If the penalty exceeds the miner's income of tx fees + minted coins + his share of the current rollover pool, the block is invalid.

This requires choosing a function f that returns the penalty for a given block size. There is great flexibility and there's little that can go wrong if we choose a "wrong" function. The main requirements are that it is convex, and has significant curvature around the size we think blocks should be. My suggestion: Choose a target block size T. Then for any given block size x, set f(x) = Max(x-T,0)^2 / (T*(2T-x)). (graph)

This will mean that there are no penalties for blocks up to size T. As the block size increases, there is a penalty for each additional transaction - negligible at first, but eventually sharply rising. Blocks bigger than 2T are forbidden.

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.

Thanks for posting, Meni-- I'm looking forward to thinking more about what you've written.

silly people wanting to play with bitcoins mining rewards output as a appendix to allowing bitcoin onchain scaling

its like saying "yea you can have more capacity but we will destroy bitcoins 21m coin cap mechanism if you do"

ofcourse messing with mining rewards is stupid and no one should even try messing with it. anyone seeing positives of messing with the blockreward mechanism should be watched, we should be careful of their other idea's. you never know what is hidden as a appendix to their concepts hidden between the lines of code

[Holliday]

Holliday, I lurves ya, man. But reducito al absurdium is unbecoming.

Look at some of the responses in this thread. You are calling me out as unbecoming because I made a joke?

Naah. My mistake. I thought you were stating that you thought such was a real risk.

I assumed naming it BUTT was sufficient to let everyone know it was a joke.

Apparently it wasn't that funny. Of course, Blockstream isn't really paying me enough to actually be funny. (That's another joke, BTW!)

[Holliday]

I can't wait for Bitcoin Unlimited Take Two, where the block reward is dynamically determined by the free market...

actually those that love core were coming up with an option where dynamic blocks are possible, but with a penalty of reducing the blockreward if its implemented. and greg actually liked it

Elastic block cap
The heart of the suggestion is - instead of forbidding large blocks, penalize them. The miner of a large block must pay a penalty that depends on the block's size. The penalty will be deducted from the funds he collects in the generation transaction, and paid into the rollover pool, to be distributed among future miners. If the penalty exceeds the miner's income of tx fees + minted coins + his share of the current rollover pool, the block is invalid.

This requires choosing a function f that returns the penalty for a given block size. There is great flexibility and there's little that can go wrong if we choose a "wrong" function. The main requirements are that it is convex, and has significant curvature around the size we think blocks should be. My suggestion: Choose a target block size T. Then for any given block size x, set f(x) = Max(x-T,0)^2 / (T*(2T-x)). (graph)

This will mean that there are no penalties for blocks up to size T. As the block size increases, there is a penalty for each additional transaction - negligible at first, but eventually sharply rising. Blocks bigger than 2T are forbidden.

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.

Thanks for posting, Meni-- I'm looking forward to thinking more about what you've written.

silly people wanting to play with bitcoins mining rewards output as a appendix to allowing bitcoin onchain scaling

its like saying "yea you can have more capacity but we will destroy bitcoins 21m coin cap mechanism if you do"

ofcourse messing with mining rewards is stupid and no one should even try messing with it. anyone seeing positives of messing with the blockreward mechanism should be watched, we should be careful of their other idea's. you never know what is hidden as a appendix to their concepts hidden between the lines of code

While there may have been actual proposals to toy with the block reward, what you've quoted is not that. Meni's proposal involves adjusting transaction fees in relation to the block size, and your quoted bit says as much.

I don't think there have been any serious proposals where the 21 million cap was brought into question, but go ahead and prove me wrong.

[franky1]

I can't wait for Bitcoin Unlimited Take Two, where the block reward is dynamically determined by the free market...

actually those that love core were coming up with an option where dynamic blocks are possible, but with a penalty of reducing the blockreward if its implemented. and greg actually liked it

Elastic block cap
The heart of the suggestion is - instead of forbidding large blocks, penalize them. The miner of a large block must pay a penalty that depends on the block's size. The penalty will be deducted from the funds he collects in the generation transaction, and paid into the rollover pool, to be distributed among future miners. If the penalty exceeds the miner's income of tx fees + minted coins + his share of the current rollover pool, the block is invalid.

This requires choosing a function f that returns the penalty for a given block size. There is great flexibility and there's little that can go wrong if we choose a "wrong" function. The main requirements are that it is convex, and has significant curvature around the size we think blocks should be. My suggestion: Choose a target block size T. Then for any given block size x, set f(x) = Max(x-T,0)^2 / (T*(2T-x)). (graph)

This will mean that there are no penalties for blocks up to size T. As the block size increases, there is a penalty for each additional transaction - negligible at first, but eventually sharply rising. Blocks bigger than 2T are forbidden.

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.

Thanks for posting, Meni-- I'm looking forward to thinking more about what you've written.

silly people wanting to play with bitcoins mining rewards output as a appendix to allowing bitcoin onchain scaling

its like saying "yea you can have more capacity but we will destroy bitcoins 21m coin cap mechanism if you do"

ofcourse messing with mining rewards is stupid and no one should even try messing with it. anyone seeing positives of messing with the blockreward mechanism should be watched, we should be careful of their other idea's. you never know what is hidden as a appendix to their concepts hidden between the lines of code

While there may have been actual proposals to toy with the block reward, what you've quoted is not that. Meni's proposal involves adjusting transaction fees in relation to the block size, and your quoted bit says as much.

minted coins

yes transaction fee is also mentioned but so is minted coin. so dont downplay the cores crappy thoughts and then make up thoughts about others.

many times people have protected gmaxwell, but then used his negative idea's and pretended other people opposing maxwells dominance as wanting what maxwell wants.

as shown in the OP of f*rking off.. only core and maxwell want to avoid true consensus and want there to be a network split.. not the other way round.

but it is very cute how you downplay cores mentions of messing with minted coins. but i would guess if you seen the exact same posts wrote by anyone not fanboying core. you would jump on them and scream like a sex addict with his first prostitute

[Holliday]

minted coin
minted coin

Yes, the proposal has those words included in the description of what happens. But it doesn't say a single thing about changing it in a way that affects the 21 million cap, which is what your previous post suggested.

so dont downplay the cores crappy thoughts and then make up thoughts about others.

I didn't downplay or make up anything. I made a joke and you took it seriously. Then I pointed out that you misrepresented something someone, who has nothing to do with Core, suggested.

Geeze man...

[jbreher]

I assumed naming it BUTT was sufficient to let everyone know it was a joke.

But... but... BUTT is a useful tool: https://sourceforge.net/projects/butt/

Blockstream isn't really paying me enough to actually be funny. (That's another joke, BTW!)

zing!

[Wind_FURY]

In Bitcoin, the miners have the last say

Then I ask, why is there a need for all the drama from the Bitcoin Unlimited supporters since the miners will decide what is final anyway?

Maybe, they are just sowing the seeds of discord between miners?

Whatever they mean to do, it is not working. Right from the beginning the miners already know which "side" to support. To what reasons why they decided to pick a "side" is arguable. It may be politics, their earn or the safety and the well being of Bitcoin as a whole. So I do think in the end they will be supporting core all the way.

[deisik]

In Bitcoin, the miners have the last say

Then I ask, why is there a need for all the drama from the Bitcoin Unlimited supporters since the miners will decide what is final anyway?

Maybe, they are just sowing the seeds of discord between miners?

Whatever they mean to do, it is not working. Right from the beginning the miners already know which "side" to support. To what reasons why they decided to pick a "side" is arguable. It may be politics, their earn or the safety and the well being of Bitcoin as a whole. So I do think in the end they will be supporting core all the way.

This is highly debatable

What you say basically comes down to claiming that people are stubborn in their choice and won't change their mind no matter what arguments and reasons are put forward. Yes, there are a lot of such people around us. But I'm still inclined to think that miners, just like other businessmen, are more oriented on maximizing their profits (and that's good) than on defending their views or choice even if it is proven to be wrong or just less profitable. Consequently, I see no reason why they might not want to change their stance if they see more profits ahead thanks to a competing approach