SegWit vs Bitcoin unlimited

[JayJuanGee]

SegWit is far more progressive solution and it solves several problems not just scalability. Besides SegWit is softfork and Unlimited is hardfork. Remember what happened with Etherium after hardfork?

Yeah, hardfork means not decentralized any more, look ETH dumled hard in recent months, ETH will be killed IMO. Softfork is much better than hardfork.

I don't think that there is anything wrong with the concept of a hardfork, as long as the change is not contentious, and that is one of the problems in hardforking with amounts that are much below 95%...

There are certainly advantages to the cleanliness of a hardfork, but many of these hardfork nutjobs (including Ver) are just throwing out those dumb ideas in their own sense of insecurity and desire for influence - and without really appreciating the value of consensus and compromise.

You are correct about Ethereum, they were quasi-centralized before implementing the hardfork, but their subsequent numerous hardforks continued to demonstrate the considerable degree of their centralization.. and also the fact that they miscalculated the level of consensus that they had with the DAO hardfork (which resulted in ETC and really the apparent beginning of their end, seems so, anyhow). 

[1713908779]

1713908779

[1713908779]

1713908779

[franky1]

The main difference lies in the fact that SegWit aims to restructure the block space to allow more transactions per block, while Unlimited aims simply to raise the blocksize to allow more transaction.

CORE aims to split Bitcoin. There was a hint from gmaxwell that it'd be good

corrected this guy due to his lack of research. seems he is a script reader. not a fact seeker

What you are describing is what I and others call a bilaterial hardfork-- where both sides reject the other.

I tried to convince the authors of BIP101 to make their proposal bilateral by requiring the sign bit be set in the version in their blocks (existing nodes require it to be unset). Sadly, the proposals authors were aggressively against this.

The ethereum hardfork was bilateral, probably the only thing they did right--

[franky1]

SegWit is far more progressive solution and it solves several problems not just scalability. Besides SegWit is softfork and Unlimited is hardfork. Remember what happened with Etherium after hardfork?

Yeah, hardfork means not decentralized any more, look ETH dumled hard in recent months, ETH will be killed IMO. Softfork is much better than hardfork.

I don't think that there is anything wrong with the concept of a hardfork, as long as the change is not contentious, and that is one of the problems in hardforking with amounts that are much below 95%...

There are certainly advantages to the cleanliness of a hardfork, but many of these hardfork nutjobs (including Ver) are just throwing out those dumb ideas in their own sense of insecurity and desire for influence - and without really appreciating the value of consensus and compromise.

You are correct about Ethereum, they were quasi-centralized before implementing the hardfork, but their subsequent numerous hardforks continued to demonstrate the considerable degree of their centralization.. and also the fact that they miscalculated the level of consensus that they had with the DAO hardfork (which resulted in ETC and really the apparent beginning of their end, seems so, anyhow). 

DAO was a 'bilateral hard fork'
google --oppose-dao-fork

also the difference between soft and hard is simply who gets to vote.
there are still orphan risks and split risks of doing both hard and soft
core however only want to talk about base case scenario of soft and worse case scenario of hard.. rather than the rational best case of both and worse case of both

softfork: consensus - >94% pools no banning/intent of minority. result: small 5% orphan drama then one chain. minority unsynced and dead
softfork: controversial - >50% pools no banning/intent of minority. result: long big% orphan drama then one chain. minority unsynced and dead
softfork: bilateral - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

hardfork: consensus - >94% nodes, then >94% pools no banning/intent of minority. result: 5% orphan drama then one chain. minority unsynced / dead
hardfork: controversial - >50% nodes, then >50% pools no banning/intent of minority. result: big% orphan drama then one chain. minority unsynced / dead
hardfork: bilateral - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

[Lauda]

CORE aims to split Bitcoin. There was a hint from Roger Ver that it'd be good

corrected this guy due to his lack of research. seems he is a script reader. not a fact seeker

-snip

Maxwell can not, and does not represent Core. Therefore, your statement is invalid. My statement is backed up by the very post that you're quoting.

[franky1]

Maxwell can not, and does not represent Core. Therefore, your statement is invalid. My statement is backed up by the very post that you're quoting.

lol,

please return to the logical open mind you retained for a few months. seems you are wearing the core/blockstream defender cap again.
your suggesting gmaxwell is not part of core?

what are you saying, he done a hearn? and no longer coding any bitcoin code, nor acts as a CTO of devs programming bitcoin implementations?
is that your suggestion that he is totally gone and no longer involved with bitcoin?

[DooMAD]

The burden of persuasion would be showing that the proposed solution adequately addresses the problems without creating new problems.

And yet conveniently that can't be shown at all if a larger blocksize is never put on the testnet.  An easy way to delay a proposal indefinitely is for the developers to simply never test it.  

That's not the argument at all.  The concern is that while optimisations like SegWit are welcome, that's not going to be enough over the long term.  

You are trying to frame the argument into something that is convenient for you about some hypothetical long term that is pie in the sky.

The fact of the matter is that we have what we have now, and then we have various proposals.  When seg wit was publically proposed in December 2015, it largely had no opposition, and even various XT and classic supporters, such as Gavin Andressen and Jeff Garzik were largely in agreement that seg wit was a good path forward, and accordingly, seg wit continued to be vetted and tested and got to various levels of going live, including going live for the purpose of signaling in mid November 2016.

So yeah, we don't know what the fuck seg wit is going to bring until it actually becomes a practice, and there are a lot of scaling issues that it addresses that may cause no need for further changes for a considerable time into the future.

Seg wit is actually on the table and those other various hardlimit increases are merely points of whinery  - that have not been officially tested and implemented... apparently BU is being tested in a live way, rather than being put on the test net first.

And again, whose fault is it that larger blocks aren't being put on the testnet by the devs themselves?  I want to see SegWit implemented, but I don't want to see it used as a smokescreen to deny or block other ideas.  Why is that such a difficult concept for you (and others) to grasp?  If the end goal is to force a significant proportion of transactions into payment channels like Lightning, or off-chain altogether, that would be a serious concern.  It's not "merely whinery" if you understood the potential for abuse.  So kindly check your tone, before your condescension leads me to call you arrogant.

People calling SegWit a scaling "solution" are completely overselling its potential.  

It is currently on the table, and would likely bring bitcoin forward in a variety of ways, including some addressing of scaling... good enough and largely noncontroversial... except whiners seeming to want to sabatoge it without any real good reasons.

Not interested in sabotaging it, just being realistic.

It will help, but the problem doesn't magically go away after it gets implemented.

Who is arguing that all the problems are going to go away?  Let's get seg wit implemented, and then go from there.. rather than saying there is something better out there without actually having anything on the table.

As long as we do "go from there", that's fine.  But it needs to be something more than optimisations, that also doesn't involve forcing transactions off-chain.  It has to remain open and permissionless.  Those qualities will be under threat if transactions on the main chain become a privileged or exclusive domain.

It's merely the first step among many to address the scaling issue.  Eventually, we'll need SegWit, Lightning, sidechains, atomic cross-chain transactions, a larger (preferably adaptive) blocksize and whatever else proves effective at easing the mempool load whilst not sacrificing node decentralisation or the open and permissionless nature of the network.  

"eventually"?  O.k.... so you are conceding that nothing is really needed?  

Why throw the baby out with the bathwater?  You want to wait with seg wit for some reason?  What is your proposal?  Seg wit is already there. and  already ready to make bitcoin more robust.  You have something against making bitcoin more robust?

Where are you getting that notion from?  Again, happy to see what SegWit can do, but it's evident that more needs to be done afterwards.  It's probable we're going to be waiting quite a while for some of the proposals like Lightning, sidechains and atomic cross-chain transactions.  So, sooner or later, like it or not, we're going to be looking at blocksize again.  My guess is "sooner".

Who is myopic?  

some hypothetical long term that is pie in the sky.

Erm... apparently you, right there.  We need to consider the long term.  Bollocks to your pie in the sky.  Focusing on the short term at the expense of the long term is myopic.

[JayJuanGee]

SegWit is far more progressive solution and it solves several problems not just scalability. Besides SegWit is softfork and Unlimited is hardfork. Remember what happened with Etherium after hardfork?

Yeah, hardfork means not decentralized any more, look ETH dumled hard in recent months, ETH will be killed IMO. Softfork is much better than hardfork.

I don't think that there is anything wrong with the concept of a hardfork, as long as the change is not contentious, and that is one of the problems in hardforking with amounts that are much below 95%...

There are certainly advantages to the cleanliness of a hardfork, but many of these hardfork nutjobs (including Ver) are just throwing out those dumb ideas in their own sense of insecurity and desire for influence - and without really appreciating the value of consensus and compromise.

You are correct about Ethereum, they were quasi-centralized before implementing the hardfork, but their subsequent numerous hardforks continued to demonstrate the considerable degree of their centralization.. and also the fact that they miscalculated the level of consensus that they had with the DAO hardfork (which resulted in ETC and really the apparent beginning of their end, seems so, anyhow). 

DAO was a 'bilateral hard fork'
google --oppose-dao-fork

also the difference between soft and hard is simply who gets to vote.
there are still orphan risks and split risks of doing both hard and soft
core however only want to talk about base case scenario of soft and worse case scenario of hard.. rather than the rational best case of both and worse case of both

softfork: consensus - >94% pools no banning/intent of minority. result: small 5% orphan drama then one chain. minority unsynced and dead
softfork: controversial - >50% pools no banning/intent of minority. result: long big% orphan drama then one chain. minority unsynced and dead
softfork: bilateral - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

hardfork: consensus - >94% nodes, then >94% pools no banning/intent of minority. result: 5% orphan drama then one chain. minority unsynced / dead
hardfork: controversial - >50% nodes, then >50% pools no banning/intent of minority. result: big% orphan drama then one chain. minority unsynced / dead
hardfork: bilateral - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

Without really get into your lack of a differentiation between a hardfork and a softfork, I think that many of us agree that no matter what kind of fork you implement, the results are going to be much better the closer you are to getting widespread consensus - and therefore largely non contentious.

So in that regard, it seems willy nilly to attempt some kind of contentious fork... and sure, if seg wit starts to get close to 95% but does not quite reach 95%, there could be a new implementation that will weight the costs and benefits and decide to implement with less than a 95% consensus.. sure that is risky, but at some point, it may be more risky to not implement and not get the many improvements of seg wit.  Accordingly, if seg wit still has not implemented by late 2017, then I'm sure there is going to be some deliberate discussions about weighing risks regarding differing paths forward.


By the way, maybe I should circle back to your definitions a bit... my understanding is that soft forks do allow for a bit more backwards compatibility and a bit more tolerance in transitioning to the new software.. but I understand that at a certain point, the transition becomes "over" and everyone has to upgrade.  Yet, with a hardfork, the transition is more immediate.. so there is a difference, but it may not matter too much about whether something is a hardfork or a softfork as compared with figuring out what is a tolerable and acceptable level of consensus in order to make sure that a sufficient number of folks are on board and that those who do not want to go along with the majority would not have any significant impact on bitcoin whether they went to form their own coin or if they failed/refused to update... and maybe 5% is an acceptable level, but maybe 10% may be o.k... too, but it does seem like a good idea to attempt getting 95% first before weighing whether attempting to implement another possible lower level might be a decent alternative plan or maybe instead some other tweak might allow for achieving the 95% preferred consensus level.

[Foxpup]

And yet conveniently that can't be shown at all if a larger blocksize is never put on the testnet.  An easy way to delay a proposal indefinitely is for the developers to simply never test it.  

I think in the near future we're going to see a compromise solution, where BU puts it on the testnet and never tests it, like Classic did 6 months ago with BIP109. For those who don't remember, an invalid BIP109 block mined on testnet (by bitcoin.com, if anyone's surprised by that fact) was rejected by Classic but accepted by Core (which doesn't care about BIP109), causing Classic to reject the majority chain. This would have been an unmitigated disaster had it occurred on mainnet, but since it was on testnet, it went completely unnoticed for nearly a month because apparently nobody was running Classic on testnet.

[JayJuanGee]

The burden of persuasion would be showing that the proposed solution adequately addresses the problems without creating new problems.

And yet conveniently that can't be shown at all if a larger blocksize is never put on the testnet.  An easy way to delay a proposal indefinitely is for the developers to simply never test it.  

That is a fair enough comment, yet my understanding is that a BIP is submitted, and then voted on and then if it is approved it can go to the next stage (such as coding and testing).  Of course there could be provisional approvals or there could be denials.

If a BIP is not approved, then the person who submitted the proposal needs to fix it to address any concerns that were raised and to resubmit it.  If s/he does not know the reason that the BIP was not approved then s/he needs to proactively attempt to figure that out by asking questions and interacting.

My understanding is that none of the BIPs related to XT, Classic and/or BU  had gotten past the initial stages of approval.. in order to even get to the testnet and there had been some laziness in follow-up and tweaking and/or making various arguments in order to get them to testnet, and therefore, proponents of those big block changes did not back up their claims with either sufficient evidence of a problem or sufficient logic in order to get some kind of agreement to go to the testnet stage. 

Are you saying that there was some kind of disallowance of BIPS to get to the testnet level (whether intentional or inadvertent).  My understanding is that they complain and go to other systems rather than attempting to go through the proper procedures for submitting BIPs... Part of their reasons for not going through the process remains unclear, but it could be that they are just engaging in shit stirring, rather than seriously going through a vetting process to actually have their proposals implemented.

Furthermore, if your proposals, include language that attempts to radically change governance (rather than merely focusing on technical issues and possible problems), then it becomes a lot harder to get others to agree to changes in the governance when those proposed governance changes could cause precedence that completely undermine bitcoin (by making bitcoin too malleable and too easy to change by any tom, dick or harry - including status quo anti-bitcoin folks).

That's not the argument at all.  The concern is that while optimisations like SegWit are welcome, that's not going to be enough over the long term.  

You are trying to frame the argument into something that is convenient for you about some hypothetical long term that is pie in the sky.

The fact of the matter is that we have what we have now, and then we have various proposals.  When seg wit was publically proposed in December 2015, it largely had no opposition, and even various XT and classic supporters, such as Gavin Andressen and Jeff Garzik were largely in agreement that seg wit was a good path forward, and accordingly, seg wit continued to be vetted and tested and got to various levels of going live, including going live for the purpose of signaling in mid November 2016.

So yeah, we don't know what the fuck seg wit is going to bring until it actually becomes a practice, and there are a lot of scaling issues that it addresses that may cause no need for further changes for a considerable time into the future.

Seg wit is actually on the table and those other various hardlimit increases are merely points of whinery  - that have not been officially tested and implemented... apparently BU is being tested in a live way, rather than being put on the test net first.

And again, whose fault is it that larger blocks aren't being put on the testnet by the devs themselves?  

I don't know?  You tell me?  Who?  I am sure if someone wanted to write the code and test it, then it would be put on the testnet, unless the criticism and concerns about the larger blocks are something other than testing it?

Part of the concern might be that it does not even matter if bigger blocks test out, if they are not necessary, then why go through the testing, when they can be tested and implemented at some time when they are actually needed (for example if fees go up or if transaction times become negatively affected)...

I want to see SegWit implemented, but I don't want to see it used as a smokescreen to deny or block other ideas.  

I am glad that you are interested in seg wit being implemented, and I don't know why you need to have so much skepticism about supposed ulterior motives...

If seg wit ends up solving all problems (but I doubt it), then why not accept that.. instead of wanting to make up a problem that does not exist.  If there is a problem, then the prudent thing to do would be to look at what is the problem exactly and then figure out various possible solutions and then to implement the better of the possible solutions (or even the best solution, if that is possible), but if there are shortcomings in some potential solutions, then there might be disagreement about what is better and what is the better way forward.  At this point, it still seems that seg wit is the best intermediate step forward, but there is no denial that at some point an actual hard increase in the block limit may be a good and better next step forward.. but that does not seem to be the case at the moment, so why just make a block limit increase when it is not necessary (as seemed to be your initial suggestion to just go to 1.25mb as a kind of compromise - which just seems ridiculous, if it is not really solving anything except for maybe temporarily appeasing unjustifiable and unsubstatiated whiners).

Why is that such a difficult concept for you (and others) to grasp?  

I am not sure about what I am supposedly having a hard time grasping.  I don't claim to be any kind of expert, but you have not really pointed out anything that is beyond my grasp, have you?  Maybe if we assume that the blocksize limit needs to be increased, then I cannot grasp that assumption because it does not seem to have a basis beyond a bunch of folks claiming that it needs to be increased without providing either sufficient evidence or logic for such ongoing baseless and whining claims?

If the end goal is to force a significant proportion of transactions into payment channels like Lightning, or off-chain altogether, that would be a serious concern.  

I doubt that there is any one set of end goals.  Seg wit allows for all kinds of builds, including the ones that you listed, but it also addresses other issues including but not limited to scaling, better sidechains, maleability and quadradic calculations (whatever the fuck that means)... There are a lot of folks that build on bitcoin in its present state and in its future state, but some of the future is unclear, so there is risk involved.. and sometimes, we are not really going to know whether some other fix needs to be undertaken in order to address something that comes up with seg wit or if it does not end up performing as anticipated or if there are changes in adoption or attacks by governments and/or financial institutions.  I doubt that there is exactly any kind of end goal because these kinds of matters are decentralized and people have all kinds of ideas about how they might build on something or use it or even not use it.  You seem to be assuming much more conspiracy than likely exists in any kind of going along with or approving of seg wit.

It's not "merely whinery" if you understood the potential for abuse.  So kindly check your tone, before your condescension leads me to call you arrogant.

I think that my tone was appropriate for whatever I was addressing.  Yeah, sure sometimes in writing, any of us might not go back and review our text or the way that we may have said something, but referring to some of the big blocker folks as unsubstantiated "whiners" is likely not going too far based on a lot of the unsubstantiated whining that I have seen and engaged with on the big blocker topic.

 I doubt that I was referring to you.. not yet, anyhow in respect to whining... hahahahaha.  I usually will only go on the attack if I feel that I was personally attacked without reason.. or if I think that you are purposefully engaging in a kind of conduct that is disingenuous... and I am not afraid to do it... On the other hand, I doubt that you should reasonably conclude that I have attempted to attack you on any kind of personal level, and I am not even really familiar with your posting history or anything like that. I am mostly merely attempting to stay substantive and respond specifically to points that you made.. maybe I don't do the greatest job in the world and maybe I add a bit too much flavor, here or there, but I am not attempting to avoid any substance that I might be able to attempt to address (and maybe learn something along the way, too?) 

People calling SegWit a scaling "solution" are completely overselling its potential.  

It is currently on the table, and would likely bring bitcoin forward in a variety of ways, including some addressing of scaling... good enough and largely noncontroversial... except whiners seeming to want to sabatoge it without any real good reasons.

Not interested in sabotaging it, just being realistic.

Fair enough.  I doubt that we can judge everyone in any particular camp as being locked in or even being the same as someone else in that camp.  Accordingly, there can be a lot of variability and sometimes any of us might evolve our positions to some extent when we engage in these thread dialogues or even disagree with folks who may mostly be in the same camp as us.

It will help, but the problem doesn't magically go away after it gets implemented.

Who is arguing that all the problems are going to go away?  Let's get seg wit implemented, and then go from there.. rather than saying there is something better out there without actually having anything on the table.

As long as we do "go from there", that's fine.  But it needs to be something more than optimisations, that also doesn't involve forcing transactions off-chain.  It has to remain open and permissionless.  Those qualities will be under threat if transactions on the main chain become a privileged or exclusive domain.

Aren't we too early to judge if privileged or exclusive is going to be any kind of meaningful outcome in a post seg wit world?  Sure, matters are going to evolve under the market, but if such an privileged and exclusive domain were to evolve, it seems that it would take several years for such to evolve (probably more than 5 years minimum, but I don't know).  Anyhow if such a privileged and exclusive system were to evolve on the bitcoin main chain over 5 years or so, then as individuals we can also adjust our behaviors and shop around or whatever.  I doubt that your scenario is very likely making bitcoin exclusive to the rich and elite.. I think that the exact opposite is what bitcoin is offering, and personal banking remains a considerably great threat to mainstream institutions, and I doubt that seg wit is really undermining any of that secure immutable decentralized value storage and transfer.. and the market will likely take a while to play out in terms of how much it costs to engage in various kinds of transactions.

It's merely the first step among many to address the scaling issue.  Eventually, we'll need SegWit, Lightning, sidechains, atomic cross-chain transactions, a larger (preferably adaptive) blocksize and whatever else proves effective at easing the mempool load whilst not sacrificing node decentralisation or the open and permissionless nature of the network.  

"eventually"?  O.k.... so you are conceding that nothing is really needed?  

Why throw the baby out with the bathwater?  You want to wait with seg wit for some reason?  What is your proposal?  Seg wit is already there. and  already ready to make bitcoin more robust.  You have something against making bitcoin more robust?

Where are you getting that notion from?  Again, happy to see what SegWit can do, but it's evident that more needs to be done afterwards.  

While maybe I had mistakenly pegged you (from your comments) as one of those who is saying block limit size increase first (and opposing seg wit until a blocksize limit increase is implemented)?

It's probable we're going to be waiting quite a while for some of the proposals like Lightning, sidechains and atomic cross-chain transactions.  

I understand that there are already quite a few companies and individuals looking at potential ways to monetize some of this and also just to attempt to make some of it work.. so some of the various second level solutions may be further along than we think.. but I am not really claiming to know too much about this and sometimes some of the companies and individuals will keep some of their ideas secret because they may want to be the first to market on their particular spin.

So, sooner or later, like it or not, we're going to be looking at blocksize again.  My guess is "sooner".

You may be correct.  I do kind of watch some of this stuff, and sometimes there are obvious spam attacks on the network, but I remain a bit unclear about whether an actual hard limit increase would actually fix the problem more than it causes additional problems.  I doubt that I am technical enough to really understand.. but I do make quite a few transactions on the blockchain, so I do have some personal and ongoing experiences with delayed transactions and fees.. and sometimes we may need to adjust our own personal systems in order to accommodate the sometimes delays (especially when we can identify spam attacks that seem to be occurring that could cause our transaction to take 2 days rather than 1 hour to go through).

Who is myopic?  

some hypothetical long term that is pie in the sky.

Erm... apparently you, right there.  We need to consider the long term.  Bollocks to your pie in the sky.  Focusing on the short term at the expense of the long term is myopic.

hahahahahaha... I will have to take that as a kind of joke.  I doubt that I am saying to never focus on the long term, but some of your proclamations come off as the XT proposals.. remember?  There was kind of a timeline with set increments of increasing the blocksize limits.. and emphasizing that we must focus on the future.. blah blah blah...  Even if such proclamations sounded good upon first impression, it seem to have failed and refused to address some of the downsides to such exponential scaling.  Furthermore, both XT and classic (and the same is true with BU), framed issues as technical while having the additional goal of changing consensus thresholds.  Maybe any of those blocksize increase proposals would be more palatable if they actually were really focuses and fixes of technical issues rather than muddying the water with changes in consensus (and big blocker proponents have an ongoing tendency to refuse to clean up their proposals and to remove those low threshold consensus aspects).. so yeah, maybe I did overstate the who cares about the future aspect, but I do get folks who are sometimes seeming to focus on something that might occur 100 years from now, and I usually say.. so fucking what.. because it might occur and it might not because 100 years from now is a long time into the future and it is much less important than considering shorter term and more pressing circumstances.

[JayJuanGee]

And yet conveniently that can't be shown at all if a larger blocksize is never put on the testnet.  An easy way to delay a proposal indefinitely is for the developers to simply never test it.  

I think in the near future we're going to see a compromise solution, where BU puts it on the testnet and never tests it, like Classic did 6 months ago with BIP109. For those who don't remember, an invalid BIP109 block mined on testnet (by bitcoin.com, if anyone's surprised by that fact) was rejected by Classic but accepted by Core (which doesn't care about BIP109), causing Classic to reject the majority chain. This would have been an unmitigated disaster had it occurred on mainnet, but since it was on testnet, it went completely unnoticed for nearly a month because apparently nobody was running Classic on testnet.

Hahahahaha

Great point!!!

[franky1]

And yet conveniently that can't be shown at all if a larger blocksize is never put on the testnet.  An easy way to delay a proposal indefinitely is for the developers to simply never test it.  

I think in the near future we're going to see a compromise solution, where BU puts it on the testnet and never tests it, like Classic did 6 months ago with BIP109. For those who don't remember, an invalid BIP109 block mined on testnet (by bitcoin.com, if anyone's surprised by that fact) was rejected by Classic but accepted by Core (which doesn't care about BIP109), causing Classic to reject the majority chain. This would have been an unmitigated disaster had it occurred on mainnet, but since it was on testnet, it went completely unnoticed for nearly a month because apparently nobody was running Classic on testnet.

Hahahahaha

Great point!!!

you do know that testnet is supposed to be used to break a chain and find bugs..

if testnet is being biasedly closed off and only used by nodes that have been vetted to not break.. then ofcourse people wont use the main testnet.
those using the main testnet are instead treating breaks as bad, not looking for bugs and only looking for status quo no issues.

even core went to a separate "segnet" because they were too scared to break testnet..(facepalm)

the stupidity is that testnet is suppose to break.. to reveal bugs. its not suppose to be used as a proof of status quo.
its should be in a 'constant state of breaking/forking, until it breaks no more' paradigm.

those using testnet should be always looking for bugs.. always trying to break testnet, to fix the cause... not running with the safety training wheels on only looking for status quo/successes.

being blind to problems but over selling what works is a fools plan.

other nodes end up making their own testnets due to the vetting process of core not wanting random nodes trying to break the main testnet.
you just dont hear or see much chat about it

[JayJuanGee]

And yet conveniently that can't be shown at all if a larger blocksize is never put on the testnet.  An easy way to delay a proposal indefinitely is for the developers to simply never test it.  

I think in the near future we're going to see a compromise solution, where BU puts it on the testnet and never tests it, like Classic did 6 months ago with BIP109. For those who don't remember, an invalid BIP109 block mined on testnet (by bitcoin.com, if anyone's surprised by that fact) was rejected by Classic but accepted by Core (which doesn't care about BIP109), causing Classic to reject the majority chain. This would have been an unmitigated disaster had it occurred on mainnet, but since it was on testnet, it went completely unnoticed for nearly a month because apparently nobody was running Classic on testnet.

Hahahahaha

Great point!!!

you do know that testnet is supposed to be used to break a chain and find bugs..

if testnet is being biasedly closed off and only used by nodes that have been vetted to not break.. then ofcourse people wont use the main testnet.

I did not know that testnet was being biasedly closed off .. I thought that it was open to use by folks who knew how to use it and had software that they wanted to run on it.  So, your representation would be news to me.

those using the main testnet are instead treating breaks as bad, not looking for bugs and only looking for status quo no issues.

seems like testnet would serve no purpose, if that were the case... again,... you are making a representation that I do not know about the underlying facts.

even core went to a separate "segnet" because they were too scared to break testnet..(facepalm)

I guess these topics are beyond my knowledge - because I do not know about this either.

the stupidity is that testnet is suppose to break.. to reveal bugs. its not suppose to be used as a proof of status quo.
its should be in a 'constant state of breaking/forking, until it breaks no more' paradigm.

those using testnet should be always looking for bugs.. always trying to break testnet, to fix the cause... not running with the safety training wheels on only looking for status quo/successes.

your logic seems to make sense.

being blind to problems but over selling what works is a fools plan.

are you talking about scaling or seg wit or something else?  Who is doing what that is foolish? 

 

other nodes end up making their own testnets due to the vetting process of core not wanting random nodes trying to break the main testnet.
you just dont hear or see much chat about it

It seems that there must be some other explanation besides what you are saying, regarding excluding folks from using testnet.  Maybe they only allow using testnet once a product has been vetted through the BIP process first?   You wouldn't just want random folks coming in to break the system, if they are not testing valid BIP items, right?

[franky1]

It seems that there must be some other explanation besides what you are saying, regarding excluding folks from using testnet.  Maybe they only allow using testnet once a product has been vetted through the BIP process first?   You wouldn't just want random folks coming in to break the system, if they are not testing valid BIP items, right?

and now you start the rabbit hole.

to get a bip, to then be able to testnet,...is like this... (note proposal/idea.. not actual final code, just a proposal)

to get a bip you need to first discuss it on the IRC/forum (moderated by theymos/gmaxwell)

then you need to submit the idea to the bitcoin mailing list. and have people revet/discuss it.
https://github.com/bitcoin/bips/blob/d9e890a8f27e46806238e298a346397871fd7e87/README.mediawiki

People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell . After copy-editing and acceptance, it will be published here.

then you can go to github and end up seeing this
https://github.com/bitcoin/bips/new/master

You’re creating a file in a project you don’t have write access to. Submitting a change will create the file in a new branch in your fork xxxxxxx/bips, so you can send a pull request.

where you are then required to be vetted again.. to get it submitted(pulled)

and this is just the process to even have a "proposal" listed, not final code, not working model, just a dang proposal!!

.
its like having to sit down for an interview, a reinterview. and then asking a womens father for the womans hand in marriage, purely to be allowed to ask a woman for a date.!!
and then only allowed to go on a date (main testnet) if you promise to not pass third base

[aarturka]

corrected this guy due to his lack of research. seems he is a script reader. not a fact seeker

Ugh, here we go again   ...
Ain't you supposed to be researching instead of making these childish tricks?

how old are you? it's not a kindergarded here and Ver is not your beloved father...
untill you mentally grow up and start some own researchin you never overcome your confined point of view...

you've shown yesterday some aspiration to research, dont lose it now, just get on it, chop chop!

[aarturka]

[franky1]

corrected this guy due to his lack of research. seems he is a script reader. not a fact seeker

Ugh, here we go again   ...
Ain't you supposed to be researching instead of making these childish tricks?

how old are you? it's not a kindergarded here and Ver is not your beloved father...
untill you mentally grow up and start some own researchin you never overcome your confined point of view...

you've shown yesterday some aspiration to research, dont lose it now, just get on it, chop chop!

review my post history vs your post history.

you troll.
i explain bitcoin
seems you need a new script.

[e-coinomist]

No, definitely no lesson learned from dillution of supply. Did not Bitcoin started as some form of self defense counter measure against paper bill printing presses?
If you "double the value" you just slice the idea into halfes. This is worse than "just introducing another Altcoin" since Alts at least appear on market as competition and invention (well sometimes, sighs! most are copycoins)

[JayJuanGee]

It seems that there must be some other explanation besides what you are saying, regarding excluding folks from using testnet.  Maybe they only allow using testnet once a product has been vetted through the BIP process first?   You wouldn't just want random folks coming in to break the system, if they are not testing valid BIP items, right?

and now you start the rabbit hole.

to get a bip, to then be able to testnet,...is like this... (note proposal/idea.. not actual final code, just a proposal)

to get a bip you need to first discuss it on the IRC/forum (moderated by theymos/gmaxwell)

then you need to submit the idea to the bitcoin mailing list. and have people revet/discuss it.
https://github.com/bitcoin/bips/blob/d9e890a8f27e46806238e298a346397871fd7e87/README.mediawiki

People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Greg Maxwell . After copy-editing and acceptance, it will be published here.

then you can go to github and end up seeing this
https://github.com/bitcoin/bips/new/master

You’re creating a file in a project you don’t have write access to. Submitting a change will create the file in a new branch in your fork xxxxxxx/bips, so you can send a pull request.

where you are then required to be vetted again.. to get it submitted(pulled)

and this is just the process to even have a "proposal" listed, not final code, not working model, just a dang proposal!!

.
its like having to sit down for an interview, a reinterview. and then asking a womens father for the womans hand in marriage, purely to be allowed to ask a woman for a date.!!
and then only allowed to go on a date (main testnet) if you promise to not pass third base

Sure, sounds as if it takes a little bit of work, and if you go through the process a few times, you likely build some street cred and experience and even an ability to get approval. 

I am not in that line of work, so it is not for me, but it does not sound unreasonable - and sometimes there can be a bit of a learning curve with anything like this and also making sure that you are submitting solid code that is aimed at a particular issue that you believe needs to be addressed and try to get others to agree with you may take a little bit of persuasion.. not only submitting facts about the issue that is going to be addressed but also submitting logic regarding how your fix addresses the problem without bringing its own level of unnecessary problems.

[franky1]

the question the tweet asks should trigger peoples thoughts.. i see problems in the statement. but if you ask the deeper question


if an exchange only plays with lets say 20btc(usually 20k-200k but lets keep it simple). and only has $18,000 to get a bitcoin price of $900 each..

the market cap of say 16,100,000 btc is based on the exchange rate.
but the problem..
the exchange is only playing with smaller amounts of bitcoin.. not the whole 16.1m
so this 20btc being traded and $18,000 fiat holding..

FALSELY makes people think the entire market is worth $14.5billion
when the reality is that there is not $14.5billion sitting in bank accounts to counter the bitcoins in circulation..

hopefully that should wake people up

and then
split it to 2 networks
now there are
20 btcA on an exchange and 20btcB on an exchange
with 16,100,000btcA cap, with 16,100,000btcB cap

again price of btc WAS $900
meaning only $18,000 was ever traded

yep only $18,000 exists in an exchange... but now a total of 40 coins are held on the exchange now

after a split
that $18,000 can go anyway

$9,000 btcA $9,000 btcB or
$8,000 btcA $10,000 btcB or (pick any ratio you like)

maths would still total $18k for 40 coins... which when PROJECTED to the market caps and combining the market caps. still total $14.5bill combined cap

so splitting the coin does not make the coins more valuable or increase the cap... until........


however..
if you create a new market page
no longer just btc<->$
or just btcA<->$   and   btcB<->$
but now
btcA<->$  and   btcB<->$  and  btcA<->btcB

no coins are withdrawn coins in this scenario
no more or less $ are deposited.

the exchange still holds 40 coins and $18,000
but now

5btcB <-> $
5btcB<-> $
and 15 btcA<-> 15 btcB

now lets concentrate on
5 btcB <-> $
5btcB<-> $
$9,000 btcA $9,000 btcB or
$8,000 btcA $10,000 btcB or (pick any ratio you like)

ill use $9,000 btcA $9,000 btcB
now ill emphasis there are still just 40 coins and $18,000 in the exchange.

but because only 5btcA are trading against $9000. that makes each btcA worth $1800 each
16.1 market cap of btcA now= $29billion
but because only 5btcB are trading against $9000. that makes each btcB worth $1800 each
16.1 market cap of btcB now= $29billion

combined market cap price of btcA+btcB now = $58billion..
yet on the exchange. before,during and after a split.. only $18,000 was ever held

...
think long and hard about how market manipulations and how the market cap.. is not true value. not even a good estimate of value and obsurdly over valued the market, based on the movements of just a few coins held actually on the market.. it will wake you up

[franky1]

making sure that you are submitting solid code

this bip process.. is not about submitting solid code..
its the process just to submit an idea of something. a concept

which usually is one that opposes cores idea.. hense why people need to submit opposing bips to counter cores own bips.

but to submit the idea (proposal/concept... not code) you have to be vetted by them atleast 4 times.(passing through gregs thumb atleast twice)