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

Carlton Banks

legendary

Activity: 3430

Merit: 3083

Quote from: DooMAD on September 21, 2015, 05:54:25 AM

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:

Quote from: Carlton Banks on August 17, 2015, 12:41:20 PM

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

legendary

Activity: 3948

Merit: 3191

Leave no FUD unchallenged

Quote from: Carlton Banks on September 21, 2015, 05:00:27 AM

Quote from: DooMAD on September 21, 2015, 04:32:58 AM

Quote from: brg444 on September 21, 2015, 04:03:48 AM

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:

Quote from: Carlton Banks on August 17, 2015, 12:41:20 PM

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.

brg444

hero member

Activity: 644

Merit: 504

Bitcoin replaces central, not commercial, banks

Quote from: Carlton Banks on September 21, 2015, 05:00:27 AM

Quote from: DooMAD on September 21, 2015, 04:32:58 AM

Quote from: brg444 on September 21, 2015, 04:03:48 AM

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.

Carlton Banks

legendary

Activity: 3430

Merit: 3083

Quote from: brg444 on September 21, 2015, 03:19:45 AM

Quote from: Carlton Banks on September 21, 2015, 02:06:37 AM

Quote from: brg444 on September 20, 2015, 09:29:16 PM

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

hero member

Activity: 644

Merit: 504

Bitcoin replaces central, not commercial, banks

Quote from: DooMAD on September 21, 2015, 04:56:22 AM

Quote from: Lauda on September 21, 2015, 04:45:37 AM

Quote from: brg444 on September 21, 2015, 04:37:38 AM

Quote from: DooMAD on September 21, 2015, 04:32:58 AM

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 Undecided

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

legendary

Activity: 3430

Merit: 3083

Quote from: DooMAD on September 21, 2015, 04:32:58 AM

Quote from: brg444 on September 21, 2015, 04:03:48 AM

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).

DooMAD

legendary

Activity: 3948

Merit: 3191

Leave no FUD unchallenged

Quote from: Lauda on September 21, 2015, 04:45:37 AM

Quote from: brg444 on September 21, 2015, 04:37:38 AM

Quote from: DooMAD on September 21, 2015, 04:32:58 AM

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

legendary

Activity: 3430

Merit: 3083

Quote from: DooMAD on September 21, 2015, 03:46:56 AM

Quote from: Carlton Banks on September 20, 2015, 09:01:59 PM

Quote from: DooMAD on September 20, 2015, 04:15:50 PM

Quote from: Carlton Banks on September 20, 2015, 01:17:50 PM

Quote from: DooMAD on September 20, 2015, 04:59:46 AM

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)

brg444

hero member

Activity: 644

Merit: 504

Bitcoin replaces central, not commercial, banks

Quote from: Lauda on September 21, 2015, 04:45:37 AM

Quote from: brg444 on September 21, 2015, 04:37:38 AM

Quote from: DooMAD on September 21, 2015, 04:32:58 AM

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.

Lauda

legendary

Activity: 2674

Merit: 3000

Terminated.

Quote from: brg444 on September 21, 2015, 04:37:38 AM

Quote from: DooMAD on September 21, 2015, 04:32:58 AM

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:

Quote from: DooMAD on September 21, 2015, 04:56:22 AM

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

hero member

Activity: 644

Merit: 504

Bitcoin replaces central, not commercial, banks

Quote from: DooMAD on September 21, 2015, 04:32:58 AM

Quote from: brg444 on September 21, 2015, 04:03:48 AM

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

DooMAD

legendary

Activity: 3948

Merit: 3191

Leave no FUD unchallenged

Quote from: brg444 on September 21, 2015, 04:03:48 AM

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.

brg444

hero member

Activity: 644

Merit: 504

Bitcoin replaces central, not commercial, banks

Quote from: DooMAD on September 21, 2015, 03:46:56 AM

Quote from: Carlton Banks on September 20, 2015, 09:01:59 PM

Quote from: DooMAD on September 20, 2015, 04:15:50 PM

Quote from: Carlton Banks on September 20, 2015, 01:17:50 PM

Quote from: DooMAD on September 20, 2015, 04:59:46 AM

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.

Quote from: Carlton Banks on September 20, 2015, 09:01:59 PM

Quote from: DooMAD on September 20, 2015, 04:15:50 PM

So if we're quite finished exchanging pleasantries, let's move on. You shouldn't need much time to read it, as it's basically just upal's excellent proposal with some tweaks from juiceayres later in that same thread and now me combining it with a hint of BIP100-style voting to balance it out a smidgen.

Find someone willing to code it (you won't)

Also not what I'd call constructive. Maybe some actual feedback would get us somewhere? Which parts need work? What potential pitfalls might arise? You know, something helpful maybe. Genuine discussion about the pros and cons.

Or should I read your reply as "it's so perfect that I want to see it implemented right away"? Roll Eyes

Yeah, okay, I'm guessing it's not that.

Fact is, I'm not a coder or an engineer, so it seems prudent for me to make sure it's at least theoretically sound before I try to get it built.

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.

DooMAD

legendary

Activity: 3948

Merit: 3191

Leave no FUD unchallenged

Quote from: Carlton Banks on September 20, 2015, 09:01:59 PM

Quote from: DooMAD on September 20, 2015, 04:15:50 PM

Quote from: Carlton Banks on September 20, 2015, 01:17:50 PM

Quote from: DooMAD on September 20, 2015, 04:59:46 AM

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.

Quote from: Carlton Banks on September 20, 2015, 09:01:59 PM

Quote from: DooMAD on September 20, 2015, 04:15:50 PM

So if we're quite finished exchanging pleasantries, let's move on. You shouldn't need much time to read it, as it's basically just upal's excellent proposal with some tweaks from juiceayres later in that same thread and now me combining it with a hint of BIP100-style voting to balance it out a smidgen.

Find someone willing to code it (you won't)

Also not what I'd call constructive. Maybe some actual feedback would get us somewhere? Which parts need work? What potential pitfalls might arise? You know, something helpful maybe. Genuine discussion about the pros and cons.

Or should I read your reply as "it's so perfect that I want to see it implemented right away"? Roll Eyes

Yeah, okay, I'm guessing it's not that.

Fact is, I'm not a coder or an engineer, so it seems prudent for me to make sure it's at least theoretically sound before I try to get it built.

brg444

hero member

Activity: 644

Merit: 504

Bitcoin replaces central, not commercial, banks

Quote from: Carlton Banks on September 21, 2015, 02:06:37 AM

Quote from: brg444 on September 20, 2015, 09:29:16 PM

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/

Carlton Banks

legendary

Activity: 3430

Merit: 3083

Quote from: brg444 on September 20, 2015, 09:29:16 PM

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?

brg444

hero member

Activity: 644

Merit: 504

Bitcoin replaces central, not commercial, 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.

Carlton Banks

legendary

Activity: 3430

Merit: 3083

Quote from: DooMAD on September 20, 2015, 04:15:50 PM

Quote from: Carlton Banks on September 20, 2015, 01:17:50 PM

Quote from: DooMAD on September 20, 2015, 04:59:46 AM

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?

Quote from: DooMAD on September 20, 2015, 04:15:50 PM

So if we're quite finished exchanging pleasantries, let's move on. You shouldn't need much time to read it, as it's basically just upal's excellent proposal with some tweaks from juiceayres later in that same thread and now me combining it with a hint of BIP100-style voting to balance it out a smidgen.

Find someone willing to code it (you won't)

DooMAD

legendary

Activity: 3948

Merit: 3191

Leave no FUD unchallenged

Quote from: Carlton Banks on September 20, 2015, 01:17:50 PM

Quote from: DooMAD on September 20, 2015, 04:59:46 AM

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.

Quote from: Carlton Banks on September 20, 2015, 01:17:50 PM

No time to read it now, but yeah, welcome to 1 month ago with your "My preference is leaning more towards a dynamic limit" Roll Eyes

If you think I've only caught on to the idea of a dynamic blocksize just now, then apparently you're still too busy blindly labeling me a militant XT supporter to recognise that people aren't just looking at one possible solution. Roll Eyes

Hell, if you were really paying close attention, you might notice I made the post immediately after your post in upal's thread (pre-BIP-number-allocation at the time). Cheers for the slightly late welcome anyway, though, you sarcastic prick. Wink

So if we're quite finished exchanging pleasantries, let's move on. You shouldn't need much time to read it, as it's basically just upal's excellent proposal with some tweaks from juiceayres later in that same thread and now me combining it with a hint of BIP100-style voting to balance it out a smidgen.

jonald_fyookball

legendary

Activity: 1302

Merit: 1008

Core dev leaves me neg feedback #abuse #political

Not sure what forum you're looking at Carlton.

People absolutely have been arguing those "oxymoron" points.
Obviously not stated in such stark contradictory sentences,
but the implications are there.

Topic: Bitcoin XT - Officially #REKT (also goes for BIP101 fraud) - page 179. (Read 379003 times)