|
Title: SegWit2MB does nothing at all to fix the real problem Post by: DGulari on April 01, 2017, 08:35:58 AM Now those clever fuckers at Blockstream seem to want to concede somewhat. However, SegWit with 2MB does NOTHING to get rid of the real problem. The real problem is a private takeover of the blockchain to support Blockstream's view of the future where they charge you money to use their private 'side chains' to the disadvantage of the network's miners. This is a wholesale diversion of funds away from network participants into the private pockets of big investors.
SegWit with 2MB will be marketed as an improvement in capacity. However, it will only serve to let the boys at Core continue to build toward a private 'off chain' system owned and controlled by Blockstream. Fuck Core/Blockstream and their SegWit2MB Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: Xester on April 01, 2017, 08:49:05 AM Now those clever fuckers at Blockstream seem to want to concede somewhat. However, SegWit with 2MB does NOTHING to get rid of the real problem. The real problem is a private takeover of the blockchain to support Blockstream's view of the future where they charge you money to use their private 'side chains' to the disadvantage of the network's miners. This is a wholesale diversion of funds away from network participants into the private pockets of big investors. SegWit with 2MB will be marketed as an improvement in capacity. However, it will only serve to let the boys at Core continue to build toward a private 'off chain' system owned and controlled by Blockstream. Fuck Core/Blockstream and their SegWit2MB That is the big disadvantage of using segwit, we cannot guarantee to decrease the miners fee and other fees perhaps. There are many rumors spreading around such as an increased in the fees much higher than what we are paying now. It sounds discouraging but what we can do we are only holders that hopes when segwit will take over the fees will reduced. Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: franky1 on April 01, 2017, 08:58:30 AM new priority fee formulae needs to be introduced that cannot be easily countered by just using more btc VALUE as your change back to yourself per tx like the old formulae did..
soo.. so lets think about a priority fee thats not about rich vs poor but about respend spam and bloat. lets imagine we actually use the tx age combined with CLTV to signal the network that a user is willing to add some maturity time if their tx age is under a day, to signal they want it confirmed but allowing themselves to be locked out of spending for an average of 24 hours. and where the bloat of the tx vs the blocksize has some impact too... rather than the old formulae which was more about the value of the tx where if they want to spend more then once a day, then obviously things like LN would be of benefit https://i.imgur.com/WnGb05Q.png as you can see its not about tx value. its about bloat and age. this way those not wanting to spend more than once a day and dont bloat the blocks get preferential treatment onchain. if you are willing to wait a day but your taking up 1% of the blockspace. you pay more if you want to be a spammer spending every block. you pay the price and if you want to be a total ass-hat and be both bloated and respending often you pay the ultimate price Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: Conasse on April 01, 2017, 12:09:35 PM SegWit has no chance to be activated (it does only 5% of incompatible blocks to activate while the camp Bitcoin Unlimited and Bitcoin Classic is very strongly opposed and mine already 40% of the blocks). Second, SegWit introduces a step backward it multiplies the size of blocks by 4 for only double the throughput of transactions-chain. It creates greater centralisation because being rich allow to create a hub of major transaction (more on deposits, more you can have links). This will make banks, exchanges and States the new masters of the money
Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: ImHash on April 01, 2017, 01:57:02 PM So BU is the answer? where only a big mining farm owning almost half the hash power wants to increase the block size as long as there are transactions in the mempool, but would they just and only change the blocksize without changing anything else?
Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: jonald_fyookball on April 01, 2017, 03:23:14 PM So BU is the answer? where only a big mining farm owning almost half the hash power wants to increase the block size as long as there are transactions in the mempool, but would they just and only change the blocksize without changing anything else? It doesn't necessarily have to be the miners in charge, but it shouldn't be developers either. Quote to remove long term moral hazard, core block size limit should be made dynamic, put in the realm of software, outside of human hands. - Jeff GarzikQuote implement a permanent block size solution once and for all, that will keep the block size limit above market demand. There are several options, such as Stephen Pair’s flexcap proposal. - Olivier JanssensTitle: Re: SegWit2MB does nothing at all to fix the real problem Post by: franky1 on April 01, 2017, 03:49:36 PM So BU is the answer? where only a big mining farm owning almost half the hash power wants to increase the block size as long as there are transactions in the mempool, but would they just and only change the blocksize without changing anything else? pool can only make something the nodes will accept.. it might help if you understood dynamics... so here goes imagine a case where there were 2 limits.(4 overal 2 for nodes 2 for pools) hard technical limit that everyone agree's on. and below that a preference limit (adjustable to demand of dynamics). now imagine we call the hard technical limit (like old consensus.h) that only moves when the NETWORK as a whole has done speed tests to say what is technically possible and come to a consensus. EG 8mb has been seen as acceptable today by all speed tests. the entire network agrees to stay below this, pools and nodes as a safety measure its split up as 4mb for next 2 years then 8mb 2 years after that.. thus allowing for upto 2-4 years to tweak and make things leaner and more efficient and allow time for real world tech to enhance. (fibre obtic internet adoption and 5G mobile internet) before stepping forward the consensus.h again then the preferential limit(further safety measure) that is adjustable and dynamic (policy.h) and keeps pools and nodes inline in a more fluid temporary adjustable agreement. to stop things moving too fast. but fluid if demand occurs now then, nodes can flag the policy.h whereby if the majority of nodes preferences are at 2mb. pools consensus.h only goes to 1.999 however if under 5-25% of nodes are at 2mb and over 75% of nodes are above 2mb. then POOLS can decide on the orphan risk of raising their pools consensus.h above 2mb but below the majority node policy also note: pools actual block making is below their(pools) consensus.h lets make it easier to imagine.. with a picture black line.. consensus.h. whole network RULE. changed by speed tests and real world tech / internet growth over time (the ultimate consensus) red line.. node policy.h. node dynamic preference agreement. changed by dynamics or personal preference purple line.. pools consensus.H. below network RULE. but affected by mempool demand vs nodes overall preference policy.h vs (orphan)risk orange line.. pools policy.h below pools consensus.h https://i.imgur.com/CPISuXV.png so imagine 2010 32mb too much, lets go for 1mb 2015 pools are moving thier limit up from 0.75mb to 0.999mb mid 2017 everyone agree's 2 years of 4mb network capability (then 2 years of 8mb network capability) everyone agree's to 2mb preference pools agree their max capability will be below everyones network capability but steps up due to demand and node preference MAJORITY pools preference(actual blocks built). below other limits but can affect the node minority to shift(EB) mid 2019 everyone agree's 2 years of 8mb network capability then 2 years of 16mb network capability some move preference to 4mb, some move under 3mb some dont move late 2019 MINORITY of nodes have their preference shifted by dynamics of (EB) 2020 MINORITY nodes manually change their preference to not be controlled by dynamics of (EB) late 2020 MINORITY of nodes have their preference shifted by dynamics of (EB) 2021 MINORITY nodes manually change their preference to not be controlled by dynamics of (EB) mid 2021 a decision is made whereby nodes preference and pools preference are safe to control blocks at X% scaling per difficulty adjustment period pools preference(actual blocks built). below other limits but can shift the MINORITY nodes preference via (EB) should they lag behind p.s its just a brainfart. no point knit picking the numbers or dates. just read the concept. i even made a picture to keep peoples attention span entertained. and remember all of these 'dynamic' fluid agreements are all extra safety limits BELOW the black network consensus limit Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: Ayers on April 01, 2017, 03:53:35 PM new priority fee formulae needs to be introduced that cannot be easily countered by just using more btc VALUE as your change back to yourself per tx like the old formulae did.. soo.. so lets think about a priority fee thats not about rich vs poor but about respend spam and bloat. lets imagine we actually use the tx age combined with CLTV to signal the network that a user is willing to add some maturity time if their tx age is under a day, to signal they want it confirmed but allowing themselves to be locked out of spending for an average of 24 hours. and where the bloat of the tx vs the blocksize has some impact too... rather than the old formulae which was more about the value of the tx where if they want to spend more then once a day, then obviously things like LN would be of benefit https://i.imgur.com/WnGb05Q.png as you can see its not about tx value. its about bloat and age. this way those not wanting to spend more than once a day and dont bloat the blocks get preferential treatment onchain. if you are willing to wait a day but your taking up 1% of the blockspace. you pay more if you want to be a spammer spending every block. you pay the price and if you want to be a total ass-hat and be both bloated and respending often you pay the ultimate price this is looking good and all, but it's even feasible, no other dev talk about this possibility, did you test it in testnet? and it work? also this remind me of the solution for the longest chain in case of a 51% attack, and the logest chain should not be the one that count as the longest Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: franky1 on April 01, 2017, 03:58:06 PM this is looking good and all, but it's even feasible, no other dev talk about this possibility, did you test it in testnet? and it work? also this remind me of the solution for the longest chain in case of a 51% attack, and the logest chain should not be the one that count longest ?? your quoting about transaction FEE's but responding about longest chains?? Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: d5000 on April 04, 2017, 08:56:59 PM The real problem is a private takeover of the blockchain to support Blockstream's view of the future where they charge you money to use their private 'side chains' to the disadvantage of the network's miners. This is a wholesale diversion of funds away from network participants into the private pockets of big investors. Incorrect. Nobody can force you to use their "private sidechains". There are a LOT of 2nd layer proposals, not only the centralized ones. I'm also against centralized sidechains and a centralized LN. But the possibilities of 2nd layers go far beyond that. Read, for example, the "Drivechain (http://www.truthcoin.info/blog/drivechain/)" proposal - it would give the additional income to miners. The same is true for "extension blocks" (a form of "sharding" where a second type of blocks is introduced that must not be processed by all nodes/miners). Only problem is that there is an opcode missing. For me, 2 MB with segwit is enough for now - it would be a maximal 8 MB (base + weight) block size. Realistically, it would be a 3x to 4x increase of the actual capacity - and that would be enough for the coming 3-4 years. Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: andrew24p on April 04, 2017, 08:58:46 PM Now those clever fuckers at Blockstream seem to want to concede somewhat. However, SegWit with 2MB does NOTHING to get rid of the real problem. The real problem is a private takeover of the blockchain to support Blockstream's view of the future where they charge you money to use their private 'side chains' to the disadvantage of the network's miners. This is a wholesale diversion of funds away from network participants into the private pockets of big investors. SegWit with 2MB will be marketed as an improvement in capacity. However, it will only serve to let the boys at Core continue to build toward a private 'off chain' system owned and controlled by Blockstream. Fuck Core/Blockstream and their SegWit2MB Get out of here with your crazy theories. If you re so worried just FORK ALREADY. Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: Qartada on April 04, 2017, 09:35:05 PM So BU is the answer? where only a big mining farm owning almost half the hash power wants to increase the block size as long as there are transactions in the mempool, but would they just and only change the blocksize without changing anything else? If you're talking about Antpool, it's more like 15% than 50%. Not even close. Giant pools supporting BU do show what BU would actually do though.Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: arklan on April 04, 2017, 10:31:00 PM So BU is the answer? where only a big mining farm owning almost half the hash power wants to increase the block size as long as there are transactions in the mempool, but would they just and only change the blocksize without changing anything else? It doesn't necessarily have to be the miners in charge, but it shouldn't be developers either. Quote to remove long term moral hazard, core block size limit should be made dynamic, put in the realm of software, outside of human hands. - Jeff GarzikQuote implement a permanent block size solution once and for all, that will keep the block size limit above market demand. There are several options, such as Stephen Pair’s flexcap proposal. - Olivier Janssensyup. should have been done that way from day -1. never should have released the software without it. now we'll never even get the consensus needed to implement this, because it would still be a fork. Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: Yakamoto on April 04, 2017, 10:53:43 PM This is something I've been saying and worried about, while Segwit looks like it is becoming the only option for really changing the blocksize due to some of the plans BU has in mind, they also aren't doing well in their own way and it just holes up more power for those that design the system. I have said we need more devs coming forward with their own solutions. The question becomes whether or not we'll see any of those.
Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: ImHash on April 05, 2017, 12:22:12 AM What is changed in BU software besides removing the block size limit? how could someone attack BU nodes and not Core nodes while the Core rules were in place and obeyed? that shows BU software is something different than what it should be, they've tailored the code to their liking, made it seem exclusive aka closed source.
Anyways as long as the majority (nodes/miners/pools) agrees on any change ( consensus) we should follow the majority as minority always doomed. Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: jonald_fyookball on April 05, 2017, 01:30:23 AM So BU is the answer? where only a big mining farm owning almost half the hash power wants to increase the block size as long as there are transactions in the mempool, but would they just and only change the blocksize without changing anything else? It doesn't necessarily have to be the miners in charge, but it shouldn't be developers either. Quote to remove long term moral hazard, core block size limit should be made dynamic, put in the realm of software, outside of human hands. - Jeff GarzikQuote implement a permanent block size solution once and for all, that will keep the block size limit above market demand. There are several options, such as Stephen Pair’s flexcap proposal. - Olivier Janssensyup. should have been done that way from day -1. never should have released the software without it. now we'll never even get the consensus needed to implement this, because it would still be a fork. Honestly I feel this "HF are bad" stuff is propaganda. Other cryptos have done hard forks where everyone agrees and knows whats going on and there hasn't been any fall out afaik.... Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: Wind_FURY on April 05, 2017, 01:52:15 AM Now those clever fuckers at Blockstream seem to want to concede somewhat. However, SegWit with 2MB does NOTHING to get rid of the real problem. The real problem is a private takeover of the blockchain to support Blockstream's view of the future where they charge you money to use their private 'side chains' to the disadvantage of the network's miners. This is a wholesale diversion of funds away from network participants into the private pockets of big investors. SegWit with 2MB will be marketed as an improvement in capacity. However, it will only serve to let the boys at Core continue to build toward a private 'off chain' system owned and controlled by Blockstream. Fuck Core/Blockstream and their SegWit2MB But who do you propose take over as the stewards of the Bitcoin network? I hope it is not Roger Ver and his cohorts at Bitcoin Unlimited. I would prefer to keep the status quo than let incompetent developers take over that might hurt the stability and security of the protocol. It is good that you are expressing the truth now. This is not an argument about block sizes but a movement to take the Core developers out and let the BU developers take over. Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: Sadlife on April 05, 2017, 02:03:54 AM So BU has a buggy code and Segwit is just a power grab owned by cores ?
I guess nothing will be implemented this year again and many years to come. Cause they're many speculation and conspiracy theories about Segwit without hearing their side first. This is like an endless loop of debate. Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: Paashaas on April 05, 2017, 02:30:32 AM Bitcoin cannot go mainstream with only bigger blocks, this shoud be basic knowlegde by now.
I want to see Bitcoin beeing used by many as possible in many possible ways. All those side-chains are beeing build around Segwit for obvious reasons. LN is not the only off-chain project out there, even if someone doesn't like it he isn't forced to use it. Segwit isn't perfect but it is the best possible update Bitcoin can have. BU is just a cheap rip-off/ hostile take over, Jihans and Rogers business model is more focused on a lame HF which is not needed. Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: Wind_FURY on April 05, 2017, 02:40:23 AM So BU has a buggy code and Segwit is just a power grab owned by cores ? I guess nothing will be implemented this year again and many years to come. Cause they're many speculation and conspiracy theories about Segwit without hearing their side first. This is like an endless loop of debate. Please do your research before making posts about any issue in Bitcoin. It is very unfair that many of you make clueless comments while some of us have tirelessly made the research and still keep making the research about what is happening in the Bitcoin. I want ask you, what power grab? The miners have the final say if Segwit will activate or not and the Core developers are the accepted stewards of the network right now. Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: iamTom123 on April 05, 2017, 04:05:23 AM In my view, it is becoming clear that SegWit and BU have their advantages as well as equal disadvantages. This continuing debate is exposing a great weakness in the Bitcoin community. Instead of opposing each other, why it is so hard for both camps to sit down, calm down and talk to and with each other like people who are working for the same interest? Unless there can be an acceptable and reliable solution to this challenge, we are putting a cap to the growth potential of Bitcoin all in all not helping any of us whether you are for SegWit or BU. Unfortunately, there is no authoritative figure in Bitcoin who can bring these opposing camps in one table.
Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: franky1 on April 05, 2017, 05:25:06 AM But who do you propose take over as the stewards of the Bitcoin network? stewards of bitcoin?? get that centralist hat off your head right now! there should be no stewards/kings core want to control bitcoin and fear an open decentralised diverse peer network. other implementations dont want control. set no deadlines demanded nothing and not making PoW nuke threats. core is adement that they wont want to join many different brands on a dynamic peer network. where nods of different brands set the rules by independent consensus. core want their controlled TIER network core want their back door exploit to slide in changes(by going soft) without nodes vetoing the changes seriously get that "stewardship" hat off your head and think of the big picture P.S blockstream(core) have admitted that going soft is using a backdoor exploit. and admitted they want to add more exploits to make it easier to go soft. what becomes 'easier' for core.. is actually bad for the network as other can then use that exploit for more nefarious purposes Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: arklan on April 05, 2017, 06:42:48 AM So BU is the answer? where only a big mining farm owning almost half the hash power wants to increase the block size as long as there are transactions in the mempool, but would they just and only change the blocksize without changing anything else? It doesn't necessarily have to be the miners in charge, but it shouldn't be developers either. Quote to remove long term moral hazard, core block size limit should be made dynamic, put in the realm of software, outside of human hands. - Jeff GarzikQuote implement a permanent block size solution once and for all, that will keep the block size limit above market demand. There are several options, such as Stephen Pair’s flexcap proposal. - Olivier Janssensyup. should have been done that way from day -1. never should have released the software without it. now we'll never even get the consensus needed to implement this, because it would still be a fork. Honestly I feel this "HF are bad" stuff is propaganda. Other cryptos have done hard forks where everyone agrees and knows whats going on and there hasn't been any fall out afaik.... but that's the point. we don't HAVE consensus. everyone doesn't agree. and they never WILL. therefore, any fork, under such a case as we have, will result in chaos. Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: andrew24p on April 05, 2017, 06:47:05 AM So BU is the answer? where only a big mining farm owning almost half the hash power wants to increase the block size as long as there are transactions in the mempool, but would they just and only change the blocksize without changing anything else? It doesn't necessarily have to be the miners in charge, but it shouldn't be developers either. Quote to remove long term moral hazard, core block size limit should be made dynamic, put in the realm of software, outside of human hands. - Jeff GarzikQuote implement a permanent block size solution once and for all, that will keep the block size limit above market demand. There are several options, such as Stephen Pair’s flexcap proposal. - Olivier JanssensIf blocks are too large they will get stuck behind China's great firewall. Thats the beauty of all the god damn miners being located and centralized in one place. You are all worried about centralization in core, well all the Chinese miners know eachother, most of them are friends, and they all have some sort of government connections or they would not be able to get the electricity contracts they are getting. Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: Ayers on April 05, 2017, 10:04:40 AM this is looking good and all, but it's even feasible, no other dev talk about this possibility, did you test it in testnet? and it work? also this remind me of the solution for the longest chain in case of a 51% attack, and the logest chain should not be the one that count longest ?? your quoting about transaction FEE's but responding about longest chains?? you didn't understand, i was making a comparison between your argument, and what it look like with an example of the longest chain, their look like they are based on the same principle, isn't it? Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: franky1 on April 05, 2017, 02:08:50 PM this is looking good and all, but it's even feasible, no other dev talk about this possibility, did you test it in testnet? and it work? also this remind me of the solution for the longest chain in case of a 51% attack, and the logest chain should not be the one that count longest ?? your quoting about transaction FEE's but responding about longest chains?? you didn't understand, i was making a comparison between your argument, and what it look like with an example of the longest chain, their look like they are based on the same principle, isn't it? in tests it works. the fee gets expensive for spammers with large bloat spending every block... but in reality of bitcoin mainnet.. if BTCC for instance, inject their own bloated tx every 10minutes into their own mempool. although it appears they are paying say $60 for their own spam tx, when their block gets added to the chain.. they are actually paying $60 to themselves, so BTCC created spam costs are zero. so it can help reduce outsider malicious spammers from spamming per block. but would require other node rules such as not allowing tx's of 20% of a whole block to even exist, to reduce the chance of self-paying pools from internally spamming their own block the fee priority mechanism isnt the end solution by itself, but with other things like maxTXsigops of 2000 when a maxBLOCKsigops is 80,000.... instead of maxTXsigops of 16000 when a maxBLOCKsigops is 80,000 and some other tweaks. does a hell of alot better job than cores highschool economics of 'just pay more' even for lean tx's that only spend once a month/year Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: uchalkql on April 05, 2017, 02:14:41 PM Via @VitalikButerin: Soft forks are coercive, anti-market:
https://www.reddit.com/r/ethereum/comments/5llba3/do_any_of_yall_ethereumers_support_the_current/dbwk1bb/ Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: classicsucks on April 05, 2017, 07:42:59 PM new priority fee formulae needs to be introduced that cannot be easily countered by just using more btc VALUE as your change back to yourself per tx like the old formulae did.. soo.. so lets think about a priority fee thats not about rich vs poor but about respend spam and bloat. lets imagine we actually use the tx age combined with CLTV to signal the network that a user is willing to add some maturity time if their tx age is under a day, to signal they want it confirmed but allowing themselves to be locked out of spending for an average of 24 hours. and where the bloat of the tx vs the blocksize has some impact too... rather than the old formulae which was more about the value of the tx where if they want to spend more then once a day, then obviously things like LN would be of benefit https://i.imgur.com/WnGb05Q.png as you can see its not about tx value. its about bloat and age. this way those not wanting to spend more than once a day and dont bloat the blocks get preferential treatment onchain. if you are willing to wait a day but your taking up 1% of the blockspace. you pay more if you want to be a spammer spending every block. you pay the price and if you want to be a total ass-hat and be both bloated and respending often you pay the ultimate price +1 franky - thanks for putting together the numbers on this solution. Placing a higher cost on the spam transactions certainly will help cut them down. As you point out, exchanges can still spam transactions to themselves. I also believe that the FUD around these giant transactions that trigger quadratic hashing issues is being overplayed. What better way to sell Segfault and LN? Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: jonald_fyookball on April 05, 2017, 07:47:41 PM So BU is the answer? where only a big mining farm owning almost half the hash power wants to increase the block size as long as there are transactions in the mempool, but would they just and only change the blocksize without changing anything else? It doesn't necessarily have to be the miners in charge, but it shouldn't be developers either. Quote to remove long term moral hazard, core block size limit should be made dynamic, put in the realm of software, outside of human hands. - Jeff GarzikQuote implement a permanent block size solution once and for all, that will keep the block size limit above market demand. There are several options, such as Stephen Pair’s flexcap proposal. - Olivier JanssensIf blocks are too large they will get stuck behind China's great firewall. Thats the beauty of all the god damn miners being located and centralized in one place. You are all worried about centralization in core, well all the Chinese miners know eachother, most of them are friends, and they all have some sort of government connections or they would not be able to get the electricity contracts they are getting. You can't have it both ways... Either China is a threat because they are centralized... or they are weak because they are slow (blocks get orphaned/stuck). Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: Wind_FURY on April 06, 2017, 04:25:13 AM But who do you propose take over as the stewards of the Bitcoin network? stewards of bitcoin?? get that centralist hat off your head right now! there should be no stewards/kings core want to control bitcoin and fear an open decentralised diverse peer network. other implementations dont want control. set no deadlines demanded nothing and not making PoW nuke threats. core is adement that they wont want to join many different brands on a dynamic peer network. where nods of different brands set the rules by independent consensus. core want their controlled TIER network core want their back door exploit to slide in changes(by going soft) without nodes vetoing the changes seriously get that "stewardship" hat off your head and think of the big picture P.S blockstream(core) have admitted that going soft is using a backdoor exploit. and admitted they want to add more exploits to make it easier to go soft. what becomes 'easier' for core.. is actually bad for the network as other can then use that exploit for more nefarious purposes Yes they are the stewards because it has not been hard forked away from them yet. If someday the Bitcoin Unlimited developers gain all the hashing power they need then they, for better or worse, become the new stewards of the Bitcoin network. Via @VitalikButerin: Soft forks are coercive, anti-market: https://www.reddit.com/r/ethereum/comments/5llba3/do_any_of_yall_ethereumers_support_the_current/dbwk1bb/ Is he trying to justify his decision to do a hard fork that brought forth to Ethereum Classic? Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: franky1 on April 06, 2017, 04:29:19 AM Yes they are the stewards because it has not been hard forked away from them yet. If someday the Bitcoin Unlimited developers gain all the hashing power they need then they, for better or worse, become the new stewards of the Bitcoin network. wake the hell up there have been many implementations running on the network for years core only came into existence in 2013 core want to be the stewards. and are playing social politics to try getting that. but core nor anyone else should be. other implementations want a diverse decentralised network. AKA PEER network of many 'brands' all on the same level playing field.. and yes if core was dynamic then core can be on that same level too.. its core refusing to do what the community want. and while core refuse.. the other brands are happy to just plod along WITHOUT setting deadlines or agenda's or PoW nuke threats.. of any dynamic implementation wanted to do anything forcefully outide of consensus.. they would have done so already. but look at core.. wanting their control in a month with their "hope its active by christmas" and now just 6 months in throwing all the weapons to force they way to the top. if you cant see how desperate blockstream are to get what they want then atleast look at the $70m debt they have to repay soon and atleast ask HOW they intend to repay it to then question their rash motives. wake up and stop thinking that a core controlled TIER network is good are you even a bitcoiner? or a fiat loving blockstream partnered guy.. seems you are becoming more engrossed in getting blockstream defended then bitcoins peer network defended EG everyone should be a steward to prevent anyone from claiming outright steward control. this may not sound clear to grasp, but then so is ' you are unique, ....... just like everyone else" nodes themselves should be choosing the rules based on what rules logically make sense and what the community want. there should be free and open choice. not a blockstream or get nuked mandatory slavery Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: Wind_FURY on April 06, 2017, 02:38:23 PM franky1, I am sorry to say that Roger Ver, the Bitcoin Unlimited developers and the Chinese miners are playing the same game too. They are all colluding to push their own agenda and take the Core developers out by hard forking Bitcoin away from them. Do I think anything is wrong with that? No, it is what it is. But I do not think the developers behind BU should be supported because they are incompetent.
Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: DGulari on April 06, 2017, 02:40:26 PM franky1, I am sorry to say that Roger Ver, the Bitcoin Unlimited developers and the Chinese miners are playing the same game too. They are all colluding to push their own agenda and take the Core developers out by hard forking Bitcoin away from them. Do I think anything is wrong with that? No, it is what it is. But I do not think the developers behind BU should be supported because they are incompetent. BU devs are fine. Besides, many of the core devs will join BU after the fork because they love bitcoin. We just have to get rid of the ownership of the core devs by Blockstream and Adam Back. That much is bullshit. Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: jonald_fyookball on April 06, 2017, 03:20:25 PM franky1, I am sorry to say that Roger Ver, the Bitcoin Unlimited developers and the Chinese miners are playing the same game too. They are all colluding to push their own agenda and take the Core developers out by hard forking Bitcoin away from them. Do I think anything is wrong with that? No, it is what it is. But I do not think the developers behind BU should be supported because they are incompetent. why not have core, xt, classic, BU all running implementations -- as long as they agree on the consensus rules, let people run what they want. Title: Re: SegWit2MB does nothing at all to fix the real problem Post by: franky1 on April 06, 2017, 03:25:04 PM They are all colluding to push their own agenda and take the Core developers out by hard forking Bitcoin away from them. Do I think anything is wrong with that? No, it is what it is. But I do not think the developers behind BU should be supported because they are incompetent. lol 1. the assert bug was existant in CORE 0.12. and core didnt go back and correct 0.12 they just made a new version number 0.13 so BU didnt cause a bug, they actually went and fixed a core bug but didnt get time to let the community download the fix. so those few days core went on propaganda war to take advantage. real funny part is. it proves a diverse decentralised PEER network works.. yea one implementation got shutdown temporarily but didnt cause network wide disruption.. however in 2013 when it was core dominant.. the leveldb bug did cause network wide disruption. we should not return to the days of just 1 or 2 codebases.. DIVERSITY is important 2. if core are so perfect there should be nothing to fix.. yet even cores "fixes" via the altcoin elements:segwit brand are not 100% guaranteed. 3. there is nothing stopping core making their implementation dynamic and join MANY implementations that are running for years so that core is on the same playing field. but no, core want to own bitcoin with a TIER network and do soft(non-peer) backdoor upgrades. funny thing is they even admit going soft was using a backdoor. and segwit opens more backdoors "making it even easier to go soft" 4. if core are so perfect why need deadlines, bribery, blackmails, algo nukes and mandatory activations. if core actually got rid of their snobbery and done what the community want there would be no debate 5. if you think that BU want to 'own bitcoin' then please get your head out of the scripts posted on reddit and start looking at bitcoin.. not the words of blockstreamists |
