Why I support BIP101 - page 2. | Bitcointalksearch.org

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: VeritasSapere on October 06, 2015, 10:31:23 AM

Quote from: Carlton Banks on October 06, 2015, 05:02:19 AM

Quote from: VeritasSapere on October 05, 2015, 07:59:39 PM

I have always said that I would most likely support a third alternative implementation especially if it strikes a middle ground between these two extreme choices we have today.

Quote from: Carlton Banks on October 05, 2015, 08:14:23 PM

No you haven't, but I don't have time to perform such unrewarding tasks as looking through your post history to prove it.

What you have indulged in is the same dishonest tactics as your fellow acolytes (straw man to open this exchange, stay classy), and the clear intent is to behave appallingly while feigning ignorance. You've constantly twisted logic, invented incoherent consequences, and just straight up saying things that are 100% contrary to observable, empirical facts. You literally just make it all up sometimes.

Yet you are the one presently using ad hominem against me. I did actually say this in the OP.

What, the OP that you wrote the day before yesterday? (did you actually expect me to read it Roll Eyes

)

More distortion only proves my point:

your claim: "I have always said..."

the reality: "I changed my position to suit my argument (again) a day or two ago"

Well, I hate to have to argue with you, but there is a grand total of 1 post in amongst your submission that is not from either yesterday, or the day before that, so you're laying it on a little too thick.

However, I can concede that you did say you favoured a compromise, once, six weeks ago (in bold). Bearing in mind the sheer mass volume of pro-BIP101 bias you've been raining on the forum since then, is it any wonder that I forgot?

And the reality is still vastly different from "I have always said...", exactly as I claimed.

VeritasSapere

hero member

Activity: 546

Merit: 500

Quote from: Carlton Banks on October 06, 2015, 05:02:19 AM

Quote from: VeritasSapere on October 05, 2015, 07:59:39 PM

I have always said that I would most likely support a third alternative implementation especially if it strikes a middle ground between these two extreme choices we have today.

Quote from: Carlton Banks on October 05, 2015, 08:14:23 PM

No you haven't, but I don't have time to perform such unrewarding tasks as looking through your post history to prove it.

What you have indulged in is the same dishonest tactics as your fellow acolytes (straw man to open this exchange, stay classy), and the clear intent is to behave appallingly while feigning ignorance. You've constantly twisted logic, invented incoherent consequences, and just straight up saying things that are 100% contrary to observable, empirical facts. You literally just make it all up sometimes.

Yet you are the one presently using ad hominem against me. I did actually say this in the OP.

What, the OP that you wrote the day before yesterday? (did you actually expect me to read it Roll Eyes

)

More distortion only proves my point:

your claim: "I have always said..."

the reality: "I changed my position to suit my argument (again) a day or two ago"

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: VeritasSapere on October 05, 2015, 07:59:39 PM

I have always said that I would most likely support a third alternative implementation especially if it strikes a middle ground between these two extreme choices we have today.

Quote from: Carlton Banks on October 05, 2015, 08:14:23 PM

No you haven't, but I don't have time to perform such unrewarding tasks as looking through your post history to prove it.

What you have indulged in is the same dishonest tactics as your fellow acolytes (straw man to open this exchange, stay classy), and the clear intent is to behave appallingly while feigning ignorance. You've constantly twisted logic, invented incoherent consequences, and just straight up saying things that are 100% contrary to observable, empirical facts. You literally just make it all up sometimes.

Yet you are the one presently using ad hominem against me. I did actually say this in the OP.

What, the OP that you wrote the day before yesterday? (did you actually expect me to read it Roll Eyes

)

More distortion only proves my point:

your claim: "I have always said..."

the reality: "I changed my position to suit my argument (again) a day or two ago"

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: DooMAD on October 06, 2015, 04:39:11 AM

Quote from: Carlton Banks on October 05, 2015, 07:19:33 PM

Quote from: DooMAD on October 05, 2015, 06:51:56 PM

Quote from: Carlton Banks on October 05, 2015, 05:52:24 PM

Or that 2-4-8 is a vastly different proposition (being as it stops at 8MB)

Surely the more pragmatic approach would be to see what the average connection and bandwidth availability is later when we're approaching 8MB and have the option to keep going if it's safe to do so?

I agree, but that's baked into a 2-4-8 cake anyway. If 8MB was reached as you say, then the option still exists via hard forking again. Except if you're running a post-fork XT network; the hard forking mechanism can't be used once Mike's proposed blockchain checkpoints get introduced.

(another mindless XT argument debunked; they constantly claim that hard forks are possible using the proposed XT codebase, when XT has been re-designed to prevent any further hard forks)

Just so I'm clear on how this 2-4-8 works, obviously we need a hard fork to get the ball rolling. Then going from 2 to 4 and from 4 to 8 doesn't require a hard fork, but going beyond 8 means we've made a guess about the future now and have drawn a line in the sand based on nothing more than a hunch?

I'm not either, it's an assumption. But people don't use expressions like 2-4-8 when they actually mean doubling without limit, so it's a safe assumption.

Quote from: DooMAD on October 06, 2015, 04:39:11 AM

From the very start of this discussion, people have repeatedly stated that we can't make assumptions about the future, so why are we assuming that 8 is as far as we should go? People argued that "kicking the can down the road" is the wrong approach, but taking a guess at a future limit and carving it in stone now is precisely that.

You're correct: these are arbitrary numbers to some extent. Guesstimate increases that are "not-too-big" and "not-too-small", so not based on any kind of attempt to solve the problem permanently. I take a similar view, which is why I prefer a dynamic limit, but there aren't any proposals like that have attracted any significant consensus so far.

Quote from: DooMAD on October 06, 2015, 04:39:11 AM

And the checkpoints thing was an idea. A bad one, granted, but never implemented (or did I miss something?), so I don't see why it's still being picked at.

You can choose that chracterisation if you want, but seeing as it's just one more dangerous idea out of many to come from one man, I think the point deserves reiterating. What makes you think that Mike won't bring the idea back (as he does with so many of his ideas that others previously rejected)? Post-fork perhaps?

DooMAD

legendary

Activity: 3948

Merit: 3191

Leave no FUD unchallenged

Quote from: Carlton Banks on October 05, 2015, 07:19:33 PM

Quote from: DooMAD on October 05, 2015, 06:51:56 PM

Quote from: Carlton Banks on October 05, 2015, 05:52:24 PM

Or that 2-4-8 is a vastly different proposition (being as it stops at 8MB)

Surely the more pragmatic approach would be to see what the average connection and bandwidth availability is later when we're approaching 8MB and have the option to keep going if it's safe to do so?

I agree, but that's baked into a 2-4-8 cake anyway. If 8MB was reached as you say, then the option still exists via hard forking again. Except if you're running a post-fork XT network; the hard forking mechanism can't be used once Mike's proposed blockchain checkpoints get introduced.

(another mindless XT argument debunked; they constantly claim that hard forks are possible using the proposed XT codebase, when XT has been re-designed to prevent any further hard forks)

Just so I'm clear on how this 2-4-8 works, obviously we need a hard fork to get the ball rolling. Then going from 2 to 4 and from 4 to 8 doesn't require a hard fork, but going beyond 8 means we've made a guess about the future now and have drawn a line in the sand based on nothing more than a hunch?

From the very start of this discussion, people have repeatedly stated that we can't make assumptions about the future, so why are we assuming that 8 is as far as we should go? People argued that "kicking the can down the road" is the wrong approach, but taking a guess at a future limit and carving it in stone now is precisely that. We shouldn't view this as a temporary kludge, just in case the other predictions people are making about alternative methods of scaling don't pan out as planned. There's no sense in creating hurdles for the future when we don't need to. We should try to keep subsequent hard forks to an absolute minimum where possible.

And the checkpoints thing was an idea. A bad one, granted, but never implemented (or did I miss something?), so I don't see why it's still being picked at.

VeritasSapere

hero member

Activity: 546

Merit: 500

Quote from: Carlton Banks on October 05, 2015, 08:14:23 PM

Quote from: VeritasSapere on October 05, 2015, 07:59:39 PM

My arguments have been completely consistent.

Quote from: VeritasSapere on October 05, 2015, 07:59:39 PM

If you can find contradiction in what I have said please point it out to me and I will thank you for it.

Quote from: VeritasSapere on October 05, 2015, 07:59:39 PM

I have always said that I would most likely support a third alternative implementation especially if it strikes a middle ground between these two extreme choices we have today.

No you haven't, but I don't have time to perform such unrewarding tasks as looking through your post history to prove it.

What you have indulged in is the same dishonest tactics as your fellow acolytes (straw man to open this exchange, stay classy), and the clear intent is to behave appallingly while feigning ignorance. You've constantly twisted logic, invented incoherent consequences, and just straight up saying things that are 100% contrary to observable, empirical facts. You literally just make it all up sometimes.

Yet you are the one presently using ad hominem against me. I did actually say this in the OP.

Quote from: VeritasSapere on August 28, 2015, 11:41:24 AM

If there was a third option that would represent a compromise between these two extreme positions, I would support that instead.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: VeritasSapere on October 05, 2015, 07:59:39 PM

My arguments have been completely consistent.

If you can find an accusation of inconsistency in what I have said please point it out to me and I will thank you for it.

Quote from: VeritasSapere on October 05, 2015, 07:59:39 PM

I have always said that I would most likely support a third alternative implementation especially if it strikes a middle ground between these two extreme choices we have today.

No you haven't, but I don't have time to perform such unrewarding tasks as looking through your post history to prove it.

What you have indulged in is the same dishonest tactics as your fellow acolytes (straw man to open this exchange, stay classy), and the clear intent is to behave appallingly while feigning ignorance (and attempt to irirtate the hell out of your mark). You've constantly twisted logic, invented incoherent consequences, and just straight up saying things that are 100% contrary to observable, empirical facts. You literally just make it all up sometimes. How you can be happy behaving this way, I cannot tell.

VeritasSapere

hero member

Activity: 546

Merit: 500

Quote from: Carlton Banks on October 05, 2015, 05:52:24 PM

Quote from: VeritasSapere on October 05, 2015, 03:57:33 PM

Quote from: DooMAD on October 05, 2015, 01:22:26 PM

I agree with raising the blocksize, but not by such a large increment. If BIP101 was simply altered to curtail the increases it would be much more likely to gain support. Chances are, most people are going to get behind a 2-4-8 increase, which seems far more prudent than 8-16-32. Personally, I'd still like to see dynamic, smaller adjustments on a more frequent basis, like every week or two if required, but the idea doesn't seem to be gaining much momentum. If I could code, I'd start an altcoin to test this idea out. Would love to see it in action (with or without the voting part). I guess it's more complicated that way, so less appealing as a result. People seem to like whole numbers and simple concepts, so we'll probably end up with static limits. Such strict rigidity worries me a little, but being stable and predictable is important too.

I actually agree with you, I only support BIP101 until a better alternative is implemented. It would indeed be good to have BIP101 itself curtailed I would absolutely support such a change, I also think that this would help with gaining support overall.

How does that explain why you've been using dozens of demonstrably false arguments in favour of BIP101? Or that 2-4-8 is a vastly different proposition (being as it stops at 8MB), that will invoke highly significant changes in the characteristics of the network dynamics that you claim to be a student of?

My arguments have been completely consistent. If you can find contradiction in what I have said please point it out to me and I will thank you for it. I have always said that I would most likely support a third alternative implementation especially if it strikes a middle ground between these two extreme choices we have today.

Quote from: Carlton Banks on October 05, 2015, 07:19:33 PM

Quote from: DooMAD on October 05, 2015, 06:51:56 PM

Quote from: Carlton Banks on October 05, 2015, 05:52:24 PM

Or that 2-4-8 is a vastly different proposition (being as it stops at 8MB)

Surely the more pragmatic approach would be to see what the average connection and bandwidth availability is later when we're approaching 8MB and have the option to keep going if it's safe to do so?

I agree, but that's baked into a 2-4-8 cake anyway. If 8MB was reached as you say, then the option still exists via hard forking again. Except if you're running a post-fork XT network; the hard forking mechanism can't be used once Mike's proposed blockchain checkpoints get introduced.

(another mindless XT argument debunked; they constantly claim that hard forks are possible using the proposed XT codebase, when XT has been re-designed to prevent any further hard forks)

Saying that we can not hard fork again after XT is complete conjecture, it is absolutely just not true. If that was true I would instantly become an opponent of XT lol. I have listened to the interview where he discusses checkpoints, you are just completely taking what he said out of context.

knowhow

hero member

Activity: 560

Merit: 500

Well i didnt read all info about it ,those xt option feature all that had made till the moment were divide the community and the result is the value lost its bust off the 300 dollars mark and looks not going to raise or dump on the next days.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: DooMAD on October 05, 2015, 06:51:56 PM

Quote from: Carlton Banks on October 05, 2015, 05:52:24 PM

Or that 2-4-8 is a vastly different proposition (being as it stops at 8MB)

Surely the more pragmatic approach would be to see what the average connection and bandwidth availability is later when we're approaching 8MB and have the option to keep going if it's safe to do so?

I agree, but that's baked into a 2-4-8 cake anyway. If 8MB was reached as you say, then the option still exists via hard forking again. Except if you're running a post-fork XT network; the hard forking mechanism can't be used once Mike's proposed blockchain checkpoints get introduced.

(another mindless XT argument debunked; they constantly claim that hard forks are possible using the proposed XT codebase, when XT has been re-designed to prevent any further hard forks)

DooMAD

legendary

Activity: 3948

Merit: 3191

Leave no FUD unchallenged

Quote from: Carlton Banks on October 05, 2015, 05:52:24 PM

Or that 2-4-8 is a vastly different proposition (being as it stops at 8MB)

Does it? I figured 12 or 16 came after 8 if it was deemed necessary (but obviously not anytime soon). Going through all this hard fork rigmarole again later if the LN or subchains plans don't materialise just doesn't strike me as sensible. Surely the more pragmatic approach would be to see what the average connection and bandwidth availability is later when we're approaching 8MB and have the option to keep going if it's safe to do so? If we don't hit 8MB for another 5-10 years (or possibly longer), home internet packages might be vastly different to now and full nodes might be able to handle much more activity. We might even have an "internet of things" where the toaster and the kettle have a full copy of the blockchain, heh. If raising the cap too quickly is irresponsible because no one knows what the future holds, then a permanent fixed cap, by the same logic, is equally irresponsible. Nothing should be set in stone. It'll only cause potential headaches later.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: VeritasSapere on October 05, 2015, 03:57:33 PM

Quote from: DooMAD on October 05, 2015, 01:22:26 PM

I agree with raising the blocksize, but not by such a large increment. If BIP101 was simply altered to curtail the increases it would be much more likely to gain support. Chances are, most people are going to get behind a 2-4-8 increase, which seems far more prudent than 8-16-32. Personally, I'd still like to see dynamic, smaller adjustments on a more frequent basis, like every week or two if required, but the idea doesn't seem to be gaining much momentum. If I could code, I'd start an altcoin to test this idea out. Would love to see it in action (with or without the voting part). I guess it's more complicated that way, so less appealing as a result. People seem to like whole numbers and simple concepts, so we'll probably end up with static limits. Such strict rigidity worries me a little, but being stable and predictable is important too.

I actually agree with you, I only support BIP101 until a better alternative is implemented. It would indeed be good to have BIP101 itself curtailed I would absolutely support such a change, I also think that this would help with gaining support overall.

How does that explain why you've been using dozens of demonstrably false arguments in favour of BIP101? Or that 2-4-8 is a vastly different proposition (being as it stops at 8MB), that will invoke highly significant changes in the characteristics of the network dynamics that you claim to be a student of?

VeritasSapere

hero member

Activity: 546

Merit: 500

Quote from: DooMAD on October 05, 2015, 01:22:26 PM

I agree with raising the blocksize, but not by such a large increment. If BIP101 was simply altered to curtail the increases it would be much more likely to gain support. Chances are, most people are going to get behind a 2-4-8 increase, which seems far more prudent than 8-16-32. Personally, I'd still like to see dynamic, smaller adjustments on a more frequent basis, like every week or two if required, but the idea doesn't seem to be gaining much momentum. If I could code, I'd start an altcoin to test this idea out. Would love to see it in action (with or without the voting part). I guess it's more complicated that way, so less appealing as a result. People seem to like whole numbers and simple concepts, so we'll probably end up with static limits. Such strict rigidity worries me a little, but being stable and predictable is important too.

I actually agree with you, I only support BIP101 until a better alternative is implemented. It would indeed be good to have BIP101 itself curtailed I would absolutely support such a change, I also think that this would help with gaining support overall.

DooMAD

legendary

Activity: 3948

Merit: 3191

Leave no FUD unchallenged

I agree with raising the blocksize, but not by such a large increment. If BIP101 was simply altered to curtail the increases it would be much more likely to gain support. Chances are, most people are going to get behind a 2-4-8 increase, which seems far more prudent than 8-16-32. Personally, I'd still like to see dynamic, smaller adjustments on a more frequent basis, like every week or two if required, but the idea doesn't seem to be gaining much momentum. If I could code, I'd start an altcoin to test this idea out. Would love to see it in action (with or without the voting part). I guess it's more complicated that way, so less appealing as a result. People seem to like whole numbers and simple concepts, so we'll probably end up with static limits. Such strict rigidity worries me a little, but being stable and predictable is important too.

VeritasSapere

hero member

Activity: 546

Merit: 500

Quote from: Quantus on October 02, 2015, 06:44:40 PM

'Orphaned blocks are stored in blkxxxx.dat files forever, though each node will know about different orphaned blocks.'

Is this not true?

That might be true, though as far as I understand it, old orphaned blocks are not stored in the main Bitcoin blockchain, so when a new node comes online the orphans will not be included when the blockchain is downloaded, someone please correct me if I am wrong. However pruning will be coming as well, though even without pruning, bandwidth is still the primary limitation of our technology that we need to consider in regards to the blocksize.

I found this article very insightful and valuable in explaining why keeping the blocksize at one megabyte would not be good for Bitcoin, I am tempted to include it in the OP: https://bitcointalksearch.org/topic/permanently-keeping-the-1mb-anti-spam-restriction-is-a-great-idea-946236

VeritasSapere

hero member

Activity: 546

Merit: 500

Quote from: BombaUcigasa on October 03, 2015, 09:34:59 AM

Quote from: BitcoinEXpress on October 02, 2015, 07:35:28 PM

Yes Bitcoin is indeed a trustless protocol.

... BIP101 are not.

That is retarded... it's just math equations, where's the trust issue?

https://github.com/bitcoin/bitcoin/pull/6341/files

This is correct. BIP101 does not compromise the trustless nature of the protocol whatsoever.

BombaUcigasa

legendary

Activity: 1442

Merit: 1005

Quote from: BitcoinEXpress on October 02, 2015, 07:35:28 PM

Yes Bitcoin is indeed a trustless protocol.

... BIP101 are not.

That is retarded... it's just math equations, where's the trust issue?

https://github.com/bitcoin/bitcoin/pull/6341/files

notthematrix

legendary

Activity: 980

Merit: 1000

CryptoTalk.Org - Get Paid for every Post!

Quote from: BitcoinEXpress on October 02, 2015, 07:53:58 PM

Quote from: notthematrix on October 02, 2015, 07:45:03 PM

Blacklisting bitcoins is useless why , every bitcoin blacklisted is one less to be never be replaced! so I cant see how you can effectively blacklist a BTC

, sorry!

Read up on Gavin and Hearn's philosophy and find out how.

It's in Bitcoin XT.

Also just because you can't see it, doesn't mean it's impossible.

~BCX~

You cant! why it will leave no bitcoin whitelisted since bitcoins cant be replaced , within 24 hours all bicoins will be blacklisted!
So be logical! it cant work! , if it is in XT nobody will use it anymore when active so this can only be bullshit its simple deduction!
because there will be no whitelisted BTC left!
It is simple it can not be done!
but if you inc the blocksite to 8MB or more you can build in privacy at extra cost!
as explained here https://www.youtube.com/watch?v=uHXfEJD6DUk then you can create plausible deniebility in the system , so parties Bitpay can saveley except all transactions under what ever law.
But Iam sure Blacklisting can not work , because whitin hours there will be no BTC left to blacklist!

BitcoinEXpress

legendary

Activity: 1210

Merit: 1024

Quote from: notthematrix on October 02, 2015, 07:45:03 PM

Blacklisting bitcoins is useless why , every bitcoin blacklisted is one less to be never be replaced! so I cant see how you can effectively blacklist a BTC

, sorry!

Read up on Gavin and Hearn's philosophy and find out how.

It's in Bitcoin XT.

Also just because you can't see it, doesn't mean it's impossible.

~BCX~

notthematrix

legendary

Activity: 980

Merit: 1000

CryptoTalk.Org - Get Paid for every Post!

Quote from: BitcoinEXpress on October 02, 2015, 07:35:28 PM

Quote from: VeritasSapere on August 28, 2015, 03:39:54 PM

You do not need to trust Mike, you do not need to trust any dictator. You do not need to trust anyone. Bitcoin is a trustless protocol.

Yes Bitcoin is indeed a trustless protocol.

Bitcoin XT and BIP101 are not.

I would love to see the mathematical equation that solves for blacklisting, enhanced tracking, reversible transactions and easily implemented central control as being "trustless".

Bitcoin XT is basically a crypto version of Paypal in which you must trust in Gavin and Mike.

Nice try for a rebound but Bitcoin XT is dead.

Time to move on.

~BCX~

Blacklisting bitcoins is useless why , every bitcoin blacklisted is one less to be never be replaced! so I cant see how you can effectively blacklist a BTC

, sorry!

Topic: Why I support BIP101 - page 2. (Read 4108 times)