Bitcoin XT - Officially #REKT (also goes for BIP101 fraud)

[brg444]

Here is my constructive comment: unless a hard cap limiting the increase over a certain period of time is coupled to this proposal, any such scheme is utterly broken and can be trivially gamed by miners intent on controlling the blocksize.

Any such proposition is not viable given that it provides no consideration for the externalization of the cost to the nodes and our focus on keeping Bitcoin decentralized.

The consideration given is that, unlike the original proposal, this one doesn't double the blocksize.  It's a measured and more conservative increase, which will allow nodes to keep pace, which is what you want.  I've even stated that the 12.5% part is open to negotiation, but it is a hard cap.  It means precisely that the blocksize can't increase (or decrease) by more than that amount over a period of time.  The period of time in question is also negotiable.  This gives you everything you're asking for, we just need to decide what the limit should be and over how long a timeframe.

12.5% YOY sounds on par with Pieter Wuille proposal. I honestly wouldn't mind it 

[Lauda]

The consideration given is that, unlike the original proposal, this one doesn't double the blocksize.  It's a measured and more conservative increase, which will allow nodes to keep pace, which is what you want.  I've even stated that the 12.5% part is open to negotiation, but it is a hard cap.  It means precisely that the blocksize can't increase (or decrease) by more than that amount over a period of time.  The period of time in question is also negotiable.  This gives you everything you're asking for, we just need to decide what the limit should be and over how long a timeframe.

12.5% YOY sounds on par with Pieter Wuille proposal. I honestly wouldn't mind it  

I'm pretty sure that we would be much better off if we had a dynamic block size limit (with the correct parameters). BIP101 is probably too big, and 12.5% YOY might be too low, both of these would eventually cause issues. As DooMAD said, it is still a hard cap which can't be changed without another fork. If we had a dynamic block size then we would not need to worry about this (unless someone tries to game the system).
I've always been against making pointless predictions as we can not know what is going to happen in the future. We can't expect any fixed solution to be the right call.
Update:

Not sure where the YOY part came from, heh.  That's a little too conservative for my tastes.  

No idea either. I just responded to his post. I do concur.

[brg444]

The consideration given is that, unlike the original proposal, this one doesn't double the blocksize.  It's a measured and more conservative increase, which will allow nodes to keep pace, which is what you want.  I've even stated that the 12.5% part is open to negotiation, but it is a hard cap.  It means precisely that the blocksize can't increase (or decrease) by more than that amount over a period of time.  The period of time in question is also negotiable.  This gives you everything you're asking for, we just need to decide what the limit should be and over how long a timeframe.

12.5% YOY sounds on par with Pieter Wuille proposal. I honestly wouldn't mind it  

I'm pretty sure that we would be much better off if we had a dynamic block size limit (with the correct parameters). BIP101 is probably too big, and 12.5% YOY might be too low, both of these would eventually cause issues. As DooMAD said, it is still a hard cap which can't be changed without another fork. If we had a dynamic block size then we would not need to worry about this (unless someone tries to game the system).
I've always been against making pointless predictions as we can not know what is going to happen in the future. We can't expect any fixed solution to be the right call.

The purpose here is not to make predictions based on demand, which would indeed be pointless, but to make block size growth a function of the most conservative estimate of technological advances (mainly bandwidth). This is more manageable and a 10-15% increase would be in line with that.

[Carlton Banks]

As for BIP101, I honestly don't think it was the catastrophic, apocalyptic doomsday scenario you portray it to be.  

Again (actual real life head shake), who's the extremist?

Never said it, or anything like it. Total exaggeration of my actual position.

Fine, I'm embellishing, but your position was still that you disagree with it, ergo it cannot be.  With a few tweaks and a less aggressive increase, this discussion could have been resolved by now.

So.... you completely invented my position for your own purposes, and somehow your point still stands? What?

Thought it was clear.  Rather than working with the community to try to improve the proposal, you joined in with the group hellbent on burying it.  Not constructive.

Wrong. I batted off the shills and the trolls, and I will continue to do so. I speak constructively with people extend the same courtesy to me; you descended into personal attacks when all I did was criticize your argument (exactly like the shills and the trolls behave, so have some sympathy for me; it's difficult to tell the difference between forum accounts deliberately posting misinformation and someone who just gets things tragically wrong whose ego is too fragile to admit it)

[DooMAD]

The consideration given is that, unlike the original proposal, this one doesn't double the blocksize.  It's a measured and more conservative increase, which will allow nodes to keep pace, which is what you want.  I've even stated that the 12.5% part is open to negotiation, but it is a hard cap.  It means precisely that the blocksize can't increase (or decrease) by more than that amount over a period of time.  The period of time in question is also negotiable.  This gives you everything you're asking for, we just need to decide what the limit should be and over how long a timeframe.

12.5% YOY sounds on par with Pieter Wuille proposal. I honestly wouldn't mind it  

I'm pretty sure that we would be much better off if we had a dynamic block size limit (with the correct parameters). BIP101 is probably too big, and 12.5% YOY might be too low, both of these would eventually cause issues. As DooMAD said, it is still a hard cap which can't be changed without another fork. If we had a dynamic block size then we would not need to worry about this (unless someone tries to game the system).
I've always been against making pointless predictions as we can not know what is going to happen in the future. We can't expect any fixed solution to be the right call.

Not sure where the YOY part came from, heh.  That's a little too conservative for my tastes.  12.5% per month at a stretch, maybe.  But again, the increase/decrease would only occur if
a) the miners agree
and
b) the traffic is actually there (or not there as the case may be)

If anything, the blocksize limit would likely reduce at first if we aren't currently filling 1MB blocks.  But the important part is we don't suddenly hit a wall where a backlog of transactions can't be cleared and we preserve decentralisation by not making it prohibitively expensive to run a full node.  Happy compromise all round.

[Carlton Banks]

Here is my constructive comment: unless a hard cap limiting the increase over a certain period of time is coupled to this proposal, any such scheme is utterly broken and can be trivially gamed by miners intent on controlling the blocksize.

Any such proposition is not viable given that it provides no consideration for the externalization of the cost to the nodes and our focus on keeping Bitcoin decentralized.

The consideration given is that, unlike the original proposal, this one doesn't double the blocksize.  It's a measured and more conservative increase, which will allow nodes to keep pace, which is what you want.  

This is what cuts to the heart of your misunderstanding; no-one knows which rate of blocksize increase "will allow nodes to keep pace", there are too many variables and too many unknown events yet to take place. If your approach is based on faulty modeling/assumptions, I don't know why you would expect people to take it any more seriously than the most egregious other examples of the same mistake (including BIP100, 101, and 103).

[brg444]

The consideration given is that, unlike the original proposal, this one doesn't double the blocksize.  It's a measured and more conservative increase, which will allow nodes to keep pace, which is what you want.  I've even stated that the 12.5% part is open to negotiation, but it is a hard cap.  It means precisely that the blocksize can't increase (or decrease) by more than that amount over a period of time.  The period of time in question is also negotiable.  This gives you everything you're asking for, we just need to decide what the limit should be and over how long a timeframe.

12.5% YOY sounds on par with Pieter Wuille proposal. I honestly wouldn't mind it  

I'm pretty sure that we would be much better off if we had a dynamic block size limit (with the correct parameters). BIP101 is probably too big, and 12.5% YOY might be too low, both of these would eventually cause issues. As DooMAD said, it is still a hard cap which can't be changed without another fork. If we had a dynamic block size then we would not need to worry about this (unless someone tries to game the system).
I've always been against making pointless predictions as we can not know what is going to happen in the future. We can't expect any fixed solution to be the right call.

Not sure where the YOY part came from, heh.  That's a little too conservative for my tastes.  12.5% per month at a stretch, maybe.  But again, the increase/decrease would only occur if
a) the miners agree
and
b) the traffic is actually there (or not there as the case may be)

If anything, the blocksize limit would likely reduce at first if we aren't currently filling 1MB blocks.  But the important part is we don't suddenly hit a wall where a backlog of transactions can't be cleared and we preserve decentralisation by not making it prohibitively expensive to run a full node.  Happy compromise all round.

That's a little naive  

Large miners could trivially spam transactions to force system to reach threshold they are comfortable with knowing it would eliminate a certain portion of their competition.

You may not have read this piece yet so allow me to insist: by preserving decentralization we mean that one should be able to run his node through tor if he chooses too. Therefore, any increase that would effectively surpass the bandwidth growth of anonymous internet access should not be considered.

http://www.truthcoin.info/blog/measuring-decentralization/

[Carlton Banks]

It should be clear by now that even considering some kind of flexible cap scheme is implemented, it will also come with a solid hard cap it cannot surpass before a certain length of time.

That's an interesting line of reasoning, what's the basis for it? Do you mean "hard cap for a given level of infrastructural capabilities" or an actual, "absolute-for-all-time" hard cap? Shouldn't the maximum limit be a function of the demands on the network for space in blocks?

Absolutely not.

Unless I misunderstand this would effectively amount to leaving the transactional capacity up to "the free market" while ignoring the externalization of cost to the node.

The maximum limit should be a function of "the cost of the option to create a full node" : http://www.truthcoin.info/blog/measuring-decentralization/

I will make time for that, as the function just stated in words sounds more convincing than how I understood it previously. I'm not sure what the metric for measuring current/past and/or estimating the future "cost of the option to create a full node", but no doubt it's explained in the piece you linked to. TBC

[brg444]

Here is my constructive comment: unless a hard cap limiting the increase over a certain period of time is coupled to this proposal, any such scheme is utterly broken and can be trivially gamed by miners intent on controlling the blocksize.

Any such proposition is not viable given that it provides no consideration for the externalization of the cost to the nodes and our focus on keeping Bitcoin decentralized.

The consideration given is that, unlike the original proposal, this one doesn't double the blocksize.  It's a measured and more conservative increase, which will allow nodes to keep pace, which is what you want.  

This is what cuts to the heart of your misunderstanding; no-one knows which rate of blocksize increase "will allow nodes to keep pace", there are too many variables and too many unknown events yet to take place. If your approach is based on faulty modeling/assumptions, I don't know why you would expect people to take it any more seriously than the most egregious other examples of the same mistake (including BIP100, 101, and 103).

I think the misunderstanding is even deeper than this.

Flexcap proposal in general are an attempt to accommodate demand and optimize fees for miners. This to me is a non-starter when attempting to design the system with security and decentralization as our main focus.

[DooMAD]

Here is my constructive comment: unless a hard cap limiting the increase over a certain period of time is coupled to this proposal, any such scheme is utterly broken and can be trivially gamed by miners intent on controlling the blocksize.

Any such proposition is not viable given that it provides no consideration for the externalization of the cost to the nodes and our focus on keeping Bitcoin decentralized.

The consideration given is that, unlike the original proposal, this one doesn't double the blocksize.  It's a measured and more conservative increase, which will allow nodes to keep pace, which is what you want.  

This is what cuts to the heart of your misunderstanding; no-one knows which rate of blocksize increase "will allow nodes to keep pace", there are too many variables and too many unknown events yet to take place. If your approach is based on faulty modeling/assumptions, I don't know why you would expect people to take it any more seriously than the most egregious other examples of the same mistake (including BIP100, 101, and 103).

I agree that no one knows.  That's why a fixed limit can't be taken seriously either.  So the question becomes, how do we allow for increases in the safest possible way?  You've said yourself in the BIP106 thread that:

Dynamic resizing is the obvious compromise between the camps. Everyone can get what they claim to want from it, without having to compromise either.

If the market chooses bigger blocks, then the market can test whether or not that works out in practice. If yes, then Gavin's design solution actually was the best idea after all. If not, then the market retreating will cause the blocksize to retreat also (which wouldn't be possible under BIP100).

The market could even try out bigger blocks, decide it doesn't work, try the alternative, dislike that more than bigger blocks, and then revert to some compromoise blocksize. Y'know, it's almost as if the free market works better than central planning...

And I very much agree with that.  We're on the same page.  So why is it suddenly the heart of my misunderstanding and not yours?  This amendment to BIP106 is far more moderate than the original and yet you're still taking issue with it when you claimed to like the original?  Please start making sense soon.

[Carlton Banks]

I agree that no one knows.  That's why a fixed limit can't be taken seriously either.  So the question becomes, how do we allow for increases in the safest possible way?  You've said yourself in the BIP106 thread that:

Dynamic resizing is the obvious compromise between the camps. Everyone can get what they claim to want from it, without having to compromise either.

If the market chooses bigger blocks, then the market can test whether or not that works out in practice. If yes, then Gavin's design solution actually was the best idea after all. If not, then the market retreating will cause the blocksize to retreat also (which wouldn't be possible under BIP100).

The market could even try out bigger blocks, decide it doesn't work, try the alternative, dislike that more than bigger blocks, and then revert to some compromoise blocksize. Y'know, it's almost as if the free market works better than central planning...

And I very much agree with that.  So why is it suddenly the heart of my misunderstanding and not yours?  This amendment to BIP106 is far more moderate than the original and yet you're still taking issue with it when you claimed to like the original?  Please start making sense soon.

I liked the original BIP106 for it's direction, I never stated I preferred it absolutely (and was careful to express myself that way, you should know that if you've been researching my post history thoroughly).

You're just relaying things I did not say, yet again, in order to "win". I'm not arguing with you, or anyone else for that matter. That's why I'm not making personal attacks or misrepresenting people's views as a strategy (which appears to be all you are capable of). It works to soothe the ego, but anyone observing will recognise what I am saying.



I am arguing about the actual issues, but if you attempt use subversive tactics, I will call you out. And it will do your reputation no good to continue trying to use these underhanded arguments. May I suggest that you stop doing it.

[DooMAD]

I agree that no one knows.  That's why a fixed limit can't be taken seriously either.  So the question becomes, how do we allow for increases in the safest possible way?  You've said yourself in the BIP106 thread that:

Dynamic resizing is the obvious compromise between the camps. Everyone can get what they claim to want from it, without having to compromise either.

If the market chooses bigger blocks, then the market can test whether or not that works out in practice. If yes, then Gavin's design solution actually was the best idea after all. If not, then the market retreating will cause the blocksize to retreat also (which wouldn't be possible under BIP100).

The market could even try out bigger blocks, decide it doesn't work, try the alternative, dislike that more than bigger blocks, and then revert to some compromoise blocksize. Y'know, it's almost as if the free market works better than central planning...

And I very much agree with that.  So why is it suddenly the heart of my misunderstanding and not yours?  This amendment to BIP106 is far more moderate than the original and yet you're still taking issue with it when you claimed to like the original?  Please start making sense soon.

I liked the original BIP106 for it's direction, I never stated I preferred it absolutely (and was careful to express myself that way, you should know that if you've been researching my post history thoroughly).

You're just relaying things I did not say, yet again, in order to "win". I'm not arguing with you, or anyone else for that matter. That's why I'm not making personal attacks or misrepresenting people's views as a strategy (which appears to be all you are capable of). It works to soothe the ego, but anyone observing will recognise what I am saying.



I am arguing about the actual issues, but if you attempt use subversive tactics, I will call you out. And it will do your reputation no good to continue trying to use these underhanded arguments. May I suggest that you stop doing it.

Fair enough.  So back to the issue, is this amendment an improvement over the original or not?  That's all I'm really looking for out of all this.  Is it at least a step in the right direction?

[marthas]

interesting discussion, but stick to the topic.

[Carlton Banks]

I liked the original BIP106 for it's direction, I never stated I preferred it absolutely (and was careful to express myself that way, you should know that if you've been researching my post history thoroughly).

You're just relaying things I did not say, yet again, in order to "win". I'm not arguing with you, or anyone else for that matter. That's why I'm not making personal attacks or misrepresenting people's views as a strategy (which appears to be all you are capable of). It works to soothe the ego, but anyone observing will recognise what I am saying.



I am arguing about the actual issues, but if you attempt use subversive tactics, I will call you out. And it will do your reputation no good to continue trying to use these underhanded arguments. May I suggest that you stop doing it.

Fair enough.  So back to the issue, is this amendment an improvement over the original or not?  That's all I'm really looking for out of all this.  Is it at least a step in the right direction?

You're being conciliatory, so I will read your idea through. When I said I didn't have time though, I actually meant that, so I can't answer you meaningfully right now, but I will take a look at it and respond.

[iCEBREAKER]

12.5% YOY sounds on par with Pieter Wuille proposal. I honestly wouldn't mind it 

Many Gavinblock fans won't agree to such a tiny increase, because they know it eats into their XT coalition's raison d'être.

Those Gavinistas and 1MBers will unite to stop the Wuilleblockers.

Alliances shift, deadlock continues.   

[VeritasSapere]

I would support a yearly 12.5% increase, even if I think it might be to small. I would also support a dynamic blocksize increase. I just want the blocksize to be increased to be honest. Not increasing the blocksize at all is what concerns me the most. This article explains well why I think that not increasing the blocksize at all would not be good for Bitcoin.

https://bitcointalk.org/index.php?topic=946236.0

[Carlton Banks]

Re: 12.5% yearly.

What if something or other suddenly starts driving bitcoin adoption wildly? It doesn't leave the market open to a dev team hashrate coup like XT (as the miners roundly disfavoured that much disruption/uncertainty), but a competing cryptocoin that can handle the spike might try to make an opportunity out of that kind of situation.

[VeritasSapere]

Re: 12.5% yearly.

What if something or other suddenly starts driving bitcoin adoption wildly? It doesn't leave the market open to a dev team hashrate coup like XT (as the miners roundly disfavoured that much disruption/uncertainty), but a competing cryptocoin that can handle the spike might try to make an opportunity out of that kind of situation.

I agree that it might not be enough of an increase, which is why a dynamic block size or a greater increase would be better. However I would consider both options far better then just keeping the one megabyte block size in place, which I know you do not advocate. That however I see as the greatest threat even if it is a result of disagreement of how and when to increase the blocksize.

So I am personally happy to compromise so that we can reach consensus sooner. You already know that I disagree with considering XT to be a coup, so lets not go over that again we have both made our arguments already.

The possibility exists however that in order to bring about a dynamic block size we would still need to hard fork away from the Core development team if they can not all agree with each other internally, since as far as I understand it, there are five Core developers that essentially have the ability to veto each other, such a system could lead to a stalemate. Though I suppose we can cross that bridge once and if we come to it.

[Carlton Banks]

Re: 12.5% yearly.

What if something or other suddenly starts driving bitcoin adoption wildly? It doesn't leave the market open to a dev team hashrate coup like XT (as the miners roundly disfavoured that much disruption/uncertainty), but a competing cryptocoin that can handle the spike might try to make an opportunity out of that kind of situation.

I agree that it might not be enough of an increase, which is why a dynamic block size or a greater increase would be better. However I would consider both options far better then just keeping the one megabyte block size in place, which I know you do not advocate. That however I see as the greatest threat even if it is a result of disagreement of how and when to increase the blocksize.

So I am personally happy to compromise so that we can reach consensus sooner. You already know that I disagree with considering XT to be a coup, so lets not go over that again we have both made our arguments already.

Although you're representing my views almost accurately (which is a strange experience, don't expect too much effort from me before I regret replying to you), you're still not getting it quite right.

Remember how differently this could have happened; Gavin Andresen used to be the lead developer for Bitcoin Core. He voluntarily handed control over to Wladimir van der Laan to work at the Bitcoin Foundation. If that didn't happen, the entire course of the block limit contention might have played out quite differently. I can imagine various plausible scenarios where I would have backed a fork away from Andresen's control of the Core client, especially when you bear in mind how ill-considered his approach to the scaling issue retrospectively.

So, the main reason to either support or reject a blockchain fork proposal can be made for good reasons. Your reasoning suggests that no-one could ever be so callous as to propose a fork in order to screw with the design philosophy, but that's totally naive. Hearn represents the incumbent banking system in every way except admission; every proposal of his (including his philosophising about 8 nodes running the whole network etc) pushes centralisation while cheerfully inviting the audience to believe that 8 nodes is as decentralised as is needed. What would you expect an erstwhile coup progenitor to do, announce it unspun in advance?

[MarketNeutral]

A friendly reminder that scalability is not the same as throughput.

If you go from one megabyte to eight megabytes, you have eight times more transactions maybe, but as somebody on Reddit said, model demand is infinite.  If you actually want to pile on transactions, there is no plausible block size that you can choose that would make that possible.  So let's not play around.  Let's actually scale bitcoin algorithmically in a way that can make sense....Moving from one megabyte to eight megabytes is a kind of a constant factor change.  It doesn't change the game and there's also confusion about what scaling means....So scaling means how do the system resources change as you put more demands on it.  So, you know, this ON squared factor.  That's what scaling is about, the characteristics as it grows.  What people really mean when they talk about scale in a kind of colloquial sense is they mean what's the throughput of the system.  So changing the block size constant from one megabyte to eight megabytes -- okay, that changes the throughput, but it hasn't improved the scalability and, in fact, presumably the scalability went up by a factor sixty-four very loosely to get an eight times throughput increase, which is a very inefficient way to go about getting more scale and will sooner or later hit some just implied bottlenecks....I think many of the more technical people involved in bitcoin understand that is just increasing throughput technology kicking the can down the road, but the real scalability and high throughput comes from algorithmic improvements that reduce network resource utilization and add other advantages.

-Dr. Adam Back, https://www.weusecoins.com/adam-back-lightning-network/