|
VeritasSapere (OP)
|
 |
October 05, 2015, 04:28:28 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://bitcointalk.org/index.php?topic=946236.0 |
|
|
|
|
DooMAD
Legendary
 Offline
Activity: 3822
Merit: 3160
Leave no FUD unchallenged
|
|
October 05, 2015, 06: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. |
|
|
|
|
|
VeritasSapere (OP)
|
|
October 05, 2015, 08:57:33 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. |
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3074
|
|
October 05, 2015, 10:52:24 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? |
Vires in numeris
|
|
|
DooMAD
Legendary
Offline
Activity: 3822
Merit: 3160
Leave no FUD unchallenged
|
|
October 05, 2015, 11:51:56 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
Offline
Activity: 3430
Merit: 3074
|
|
October 06, 2015, 12:19:33 AM
Last edit: October 06, 2015, 12:35:24 AM by Carlton Banks |
|
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) |
Vires in numeris
|
|
|
|
knowhow
|
|
October 06, 2015, 12:26:17 AM |
|
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.
|
|
|
|
|
|
VeritasSapere (OP)
|
|
October 06, 2015, 12:59:39 AM |
|
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. 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. |
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3074
|
|
October 06, 2015, 01:14:23 AM |
|
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. 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. |
Vires in numeris
|
|
|
|
VeritasSapere (OP)
|
|
October 06, 2015, 01:19:18 AM |
|
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. 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.  If there was a third option that would represent a compromise between these two extreme positions, I would support that instead. |
|
|
|
|
DooMAD
Legendary
Offline
Activity: 3822
Merit: 3160
Leave no FUD unchallenged
|
|
October 06, 2015, 09:39:11 AM |
|
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. |
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3074
|
|
October 06, 2015, 09:57:54 AM |
|
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. 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. 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? |
Vires in numeris
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3074
|
|
October 06, 2015, 10:02:19 AM |
|
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. What, the OP that you wrote the day before yesterday? (did you actually expect me to read it  ) 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" |
Vires in numeris
|
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3074
|
|
October 06, 2015, 03:57:20 PM |
|
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. |
Vires in numeris
|
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3074
|
|
October 06, 2015, 05:43:52 PM |
|
Sorry, I read the September ones as all being October for some reason (looked like you posted 12 posts from October and 1 from August). Oh well, I only wasted about 30 seconds looking, so things could be worse  There's still a bit of a balance problem, even in those posts, if you want to actually maintain that a compromise is what you want or what you're promoting. The content of those posts suggests otherwise, and lets be fair, you've written one or two more posts than that in the last 6 weeks. |
Vires in numeris
|
|
|
|
VeritasSapere (OP)
|
|
October 06, 2015, 08:42:03 PM |
|
Sorry, I read the September ones as all being October for some reason (looked like you posted 12 posts from October and 1 from August). Oh well, I only wasted about 30 seconds looking, so things could be worse There's still a bit of a balance problem, even in those posts, if you want to actually maintain that a compromise is what you want or what you're promoting. The content of those posts suggests otherwise, and lets be fair, you've written one or two more posts than that in the last 6 weeks. I have said and I repeat that I will adopt a third alternative as soon as it is implemented. A third alternative has not been implemented yet, therefore my position is not contradictory. |
|
|
|
|
Carlton Banks
Legendary
Offline
Activity: 3430
Merit: 3074
|
|
October 06, 2015, 08:54:46 PM |
|
Sorry, I read the September ones as all being October for some reason (looked like you posted 12 posts from October and 1 from August). Oh well, I only wasted about 30 seconds looking, so things could be worse There's still a bit of a balance problem, even in those posts, if you want to actually maintain that a compromise is what you want or what you're promoting. The content of those posts suggests otherwise, and lets be fair, you've written one or two more posts than that in the last 6 weeks. I have said and I repeat that I will adopt a third alternative as soon as it is implemented. A third alternative has not been implemented yet, therefore my position is not contradictory. I don't think you mean just any third alternative? Not meaning to split hairs, but it explicates my criticism of what I recall about your position, which was that you thought BIP101 was an acceptable option, for the reason that it was the only alternative proposed at all. |
Vires in numeris
|
|
|
|
brg444
|
|
October 06, 2015, 09:00:46 PM |
|
Sorry, I read the September ones as all being October for some reason (looked like you posted 12 posts from October and 1 from August). Oh well, I only wasted about 30 seconds looking, so things could be worse There's still a bit of a balance problem, even in those posts, if you want to actually maintain that a compromise is what you want or what you're promoting. The content of those posts suggests otherwise, and lets be fair, you've written one or two more posts than that in the last 6 weeks. I have said and I repeat that I will adopt a third alternative as soon as it is implemented. A third alternative has not been implemented yet, therefore my position is not contradictory. I don't think you mean just any third alternative? Not meaning to split hairs, but it explicates my criticism of what I recall about your position, which was that you thought BIP101 was an acceptable option, for the reason that it was the only alternative proposed at all. "Political realism" he called it. |
"I believe this will be the ultimate fate of Bitcoin, to be the "high-powered money" that serves as a reserve currency for banks that issue their own digital cash." Hal Finney, Dec. 2010
|
|
|
|
