I just say that they still follow/use their "Articles of Federation of BU", but with some loophole inside it  Obviously, i know closed source software such as bitcoin is bad thing and i don't support BU. how many people do you think actually read every line of cores code and then compile it themselves. or just rely on "trust" that the binary is ok because other people supposedly have read every line |
|
|
|
Bitcoin unlimited using hard fork in its code is having many troubles and will experience many bugs and that is why many are staying with the core developers.
so you admit the core developers are not independent. because if they were independent they would not be "staying" with core. they would happily peer review other implementations. bu problem is kind of like an infinity loop implementation A not independently peer reviewed. independent peers wont peer review A, because they are staying with central Tier group B implementation A not peer reviewed. do you see the problem of where the centralisation actually is core refuse to get out of their cabin fever box and be diverse to be on the same level playing ground with other implementations they don't want to be independent peers. they love the dependant Tier model much better |
|
|
|
When you say "block chain protocol hard fork", you likely mean "bitcoin consensus protocol changes". Which is exactly what happened in 2013, on an emergency basis. The errant code (due to levelDB vs. BerkeleyDB locking differences) validated malformed transactions and blocks, using 60% of the global hashpower. The 60% was overwhelming the correct blocks, and people noticed a large deviation in broadcasted blocks.
As a fix, the blockchain was voluntarily rolled back in time by 12 hours, new blocks were built on top of it with a patched miner, and a ton of broken blocks were discarded and invalidated. (These blocks incidentally could be considered orphaned)
Also interesting as you point out, that the block size was limited to 512K during this bugfix.
My question is: was any aspect of the block chain itself modified ? I have the impression (didn't look into the details) that this was an internal bug to core code not respecting the correct construction of BLOCKS and accepting them as valid *while in fact they weren't*. So one just found out somewhat late that one had been building *an invalid chain*, but discarding (even late) an invalid chain is not the same thing as *modifying how a chain should be build* (THAT is a hard fork in protocol). the block structure and chain was fine. non of the bitcoin consensus rules were broken. the bug was how the blocks got saved to peoples hard drives in their local databases. people using (at the time) leveldb could save the blockchain.. but if using berekly by not upgrading they were having issues saving the blockchain because it was using up all the locks of their berkelydb as the blocks grew beyond 500k (even when consensus had 1mb limit).. so it was not about consensus rules. but bad database issues devs didnt peer review what would happen in such cases because. For instance, suppose that because of a bug in core software, the coinbase of a block jumps to 200 coins per block, and that this goes on for a month. During this month, in fact, these blocks are simply *wrong* but are nevertheless, erroneously, accepted. In fact, the error made a hard fork. When the bug is *repaired*, suddenly, all these blocks are correctly seen as invalid, and the chain is seen as stalled a month ago. So now, people can start building blocks upon the stalled, correct chain. If that happens, I don't call it a hard fork, because the true protocol is still valid on the rebuilt chain. (while in fact it wasn't on the erroneous chain for more than a month).
coinbase jumping to 200 coins for a month?? well if everyone (your utopia) was running the exact same core software.. then it would go on for months. but if nodes were diverse. then they would orphan off the block because it breaks the real consensus rule of 12.5btc right now. and so if the network was diverse enough to not have a majority running the buggy core. those blocks would get orphaned and the pools running non core wont be making 200coin blocks. so the network wont be running for a month of 200 coins. but in your utopia of everyone running core then yea expect more issues where after a month, those 4032 blocks of 200coins each block would eventually get orphaned and anyone making transactions during that month will see their transactions of that month disappear. causing merchants who accepted them 4032 blocks and thought they got paid, find out they no longer got paid because their customers transactions of the month no longer exist. this is why diversity matters |
|
|
|
franky1: "ill pretend the newest BUcoin bug is core's fault"
^ logic problem exposed (error code: BUcoin is dogshit)
BU was actually just a fork of core 0.12 (all core 0.12 bugs included) bu just tweaked a few lines of code to allow dynamics and left it out there for the community of independent devs it wasnt until fixes were done that people spotted some nodes hadnt upgraded post-fix. so exploited such. funny part is assert(0) was actually a exploit that was able to harm core 0.12 too also funny part is that BU devs didnt create it, and people didnt exploit it ntil it was patched.. which then made exploiters realsie that some users were not yet patched against it.. P.S having BU screw up is actually a good promotion of why diverse brands SHOULD exist on bitcoins main net. imagine however if EVERYONE was just running core and only core. then imagine there was a issue with the db locks of the blockchain data.. oh wait.. no need to imagine it.. 2013's leveldb update which didnt factor in something when moving forward .. causing several hour stall and orphan event. ... but now imagine if bitcoin remained diverse with many different implementations . if one codebase goes down.. only a few nodes go offline and everything else continues as normal. so all you crybabies that want core centralisation .. imagine future events like the 2013 leveldb event anyone who wants diversity. imagine this months 'oh well a few nodes went offline' no big deal diversity is good. not bad. keep bitcoin diverse and decentralised and independent. dont advocate for centralised power house |
|
|
|
Exchanges have already stated they'll list a contentious fork, no doubt they'll be delighted to list something that isn't the child of strife. If it really is superior to its daddy then the market will naturally migrate with no risks to anyone or anything.
emphasis contentious fork. but what if BU has consensus.. .. remember BU has been around for 2 years and has set no agenda to split or do things contentiously. otherwise they would have. also even when being offered by cores overlord and CTO gmaxwell to split officially, the community that want diverse opn dcentralsied onchain base block growth said no to him. so although the core fanatics keep screaming about contentious forks, the only way it will happen is if core trigger it... which they seem to be planning on (UASF + PoW algo change) which if there was a CONTENTIOUS FORK (meaning controversial which then triggers core to open up their ban hammer) bu would be treated as the alt by not having majority.. but if consensus occurs (the thing BU have in mind all along..) with BU having majority.. core actually becomes the altcoin. bitfinex actually went into deeper detail core having minority core = BCC BU having minority bu=BCU https://twitter.com/bitfinex/status/843226656940679170 devil is in the details of the announcement... "contentious" |
|
|
|
|
BU is just a code implementation,
there are MANY
core, knots, fibre, bitcoinj, bitcoin ruby, BTCd, nbitcoin, statoshi, bitcoinxt, bitcoin classic, bitcoinunlimited... and so on.
bitcoin unlimited has set no deadlines, set no schedule of activation. has no zealous banscore tricks, no intention to cause a split.
bitcoin unlimiited wants consensus of many diverse nodes all on one PEER network. (bitcoin remaining diverse open and decentralisation)
however core feel its a threat to their segwit plans of a TIER network of core being the upstream filters, in control of validation and changes in future direction. so core are on the rampage fearing their loss of control..
(there should be no control anyway so anyone arguing core deserve control doesnt understand bitcoin. and is obviously involves in centralising bitcoin)
core first intentionally avoid hard(node+pool) consensus(vote) and went only for soft(pool) vote
then core uses bip9 that has some intentional banning pool/block features to turn their majority to 100% by killing off the opposition.soft(pool) contraversial
core next realised that pools were still unofficially(but a good reasoned safeguard) waited to see what node counts suggested before deciding.
so now core are going heavy. UASF and even as far as PoW algo changes hard(node+pool) bilateral split. to threaten the pools to vote for core or be struck off the network.
and now core see BU as a threat, because its giving the community another option. and risking cores dictatorship.
funny parts to remember.
1. core gave pools the vote so dont blame pools for saying no to core
2. core failed at bribing the community with fee discounts. while cunningly pushing fee's up to counter the discount
3. core will be the ones triggering the splitting of the network rather than accepting a no answer,
4. core are ignoring community views of wanting something else. because it doesnt follow the core corporate roadmap of centralised LN services to repay their $70m+ debt
meanwhile BU will keep on plodding along with no intention to do anything unless there is majority consent
|
|
|
|
i hope the subtle hint is not too subtle here...(i did write the hint in more codified manner but then chose to make it more layman understandable) core developers: "ill pretend to be independent"
core developers: "i'm not going to help the community, only core"
core developers: "ill pretend to be independant"
core developers: "i'm not going to help the community, i refuse to help BU"
core developers: "BU is not getting support by independent developers."
core developers: "lets abuse BU and say they are centralist because WE refuse to help them as independent devs"
^ logic problem exposed (error code: core is not independent, please contact core vendors @blockstream for solution)
|
|
|
|
1. jihan has actual control of less than 16% 2. BU work with NODE and POOL consensus, the only group wanting bilateral splits is the core group should BU get a majority. 3. if it could be triggered at any % it would have already 4. bu has not made threats, has no bip9 orphan block code, no UASF ban node/orphan block code and no chang mining algo code.. thats all core crap 5. bu has been running for 2 years with no deadlines. no threatsand will continue waiting for bitcoin hard(node and pool) consensus to limit orphan risk 6. all i see is that jihan said "accelerate".. no threat. just maybe something like make a official date of some official voting event period many people dont grasp the terms hard vs soft very well.. this is because the sheep script writers have only mentioned best case scenario of the umbrella term soft and worse case for hard. and falsely make it seem that those are the only two options clarity
soft and hard is simply:
soft: pool only vote
hard: nodes and pools vote
below these umbrella terms is what could happen.. in both hard and soft it can either continue as one chain. or bilateral split
softfork: consensus - >94% pools no banning/ignoring of minority. result: small 5% orphan drama then one chain. minority unsynced and dead
softfork: controversial - >50% pools no banning/ignoring of minority. result: long big% orphan drama then one chain. minority unsynced and dead
softfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains
hardfork: consensus - >94% nodes, then >94% pools no banning/ignoring of minority. result: 5% orphan drama then one chain. minority unsynced / dead
hardfork: controversial - >50% nodes, then >50% pools no banning/ignoring of minority. result: big% orphan drama then one chain. minority unsynced / dead
hardfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains
the 20 exchange announcement was if there was a CONTENTIOUS FORK (meaning controversial which then triggers core to open up their ban hammer) bu would be treated as the alt by not having majority.. but if consensus occurs (the thing BU have in mind all along..) with BU having majority core actually becomes the altcoin. bitfinex actually went into deeper detail core having minority core = BCC BU having minority bu=BCU devil is in the details of the announcement... "contentious" https://twitter.com/bitfinex/status/843226656940679170once you get past the softbest:hardworse fatal flaw of FUD.. and realise that there are consensus options for both and split options for both.. things get clearer |
|
|
|
The Core proposal is: Let the "node network" be centralization, but allow centralization at the "payment system" level.
The BU proposal is: Let the "payment system" be decentralized, but allow decentralization at the "node network" level.
FTFY CORE want core to own bitcoin and be the upper controlling tier of upstream filters and all code requiring core(blockstream) approval.. and have the better ln hubs, and controlling the base block to FORCE people to use LN non-core want diverse nodes of many brands on one single PEER network. and LN being voluntary side services that anyone can make |
|
|
|
post removed
post made by btc_broker not roger
= roger not even making a bet
im guessing in 2 minutes the reddit trolls will make some big deal about how roger made a bet and the renigged
or how roger instigated a bet
or how roger asked for a bet
any troll can make a post asking for a free house and a asian wife.. doesnt mean they will get it.
making this topic pointless
i thought it was made by loaded. the origin (reddit post) @RogerVer lets make a deal, 1 for 1 trade. At least 60k, possibly up to 130k, my BTU for your BTC. (self.Bitcoin)
submitted 2 hours ago by btc_brokerredditor
[removed]
comment
share |
|
|
|
|
post removed
post made by btc_broker not roger
= roger not even making a bet
im guessing in 2 minutes the reddit trolls will make some big deal about how roger made a bet and the renigged
or how roger instigated a bet
or how roger asked for a bet
any troll can make a post asking for a free house and a asian wife.. doesnt mean they will get it.
making this topic pointless
|
|
|
|
Again, you are wrong. ETH/ETC was/is a hard fork. There is no more perfect example of a hard fork. One group of people wanted to "change the rules" the other group did not. So they went their separate ways on separate block chains. That is the definition of a hard fork.
hard BILATERAL SPLIT fork google: --oppose-dao-fork lets even quote cores immortal lord and master What you are describing is what I and others call a bilateral 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-- too many people think that soft = 1 thing and hard =1 thing. but infact you can have splits done by going soft or hard. but infact you can have controversy done by going soft or hard. but infact you can have concensus done by going soft or hard. but the propaganda machine just talks and wants to think of soft best case scenario and hards worse case, to fit a scenario of the narrator but this should clear it up clarity
soft and hard is simply:
soft: pool only vote
hard: nodes and pools vote
below these umbrella terms is what could happen.. in both hard and soft it can either continue as one chain. or bilateral split
softfork: consensus - >94% pools no banning/ignoring of minority. result: small 5% orphan drama then one chain. minority unsynced and dead
softfork: controversial - >50% pools no banning/ignoring of minority. result: long big% orphan drama then one chain. minority unsynced and dead
softfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains
hardfork: consensus - >94% nodes, then >94% pools no banning/ignoring of minority. result: 5% orphan drama then one chain. minority unsynced / dead
hardfork: controversial - >50% nodes, then >50% pools no banning/ignoring of minority. result: big% orphan drama then one chain. minority unsynced / dead
hardfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains
|
|
|
|
|
BU (and other non-core implentations) have been running for 2 years
made no threats, no demands, have no over zealous banning mechanisms.. it is just plodding along allowing the network to rmain diverse and have a choice of independence that is not core dictated.
several other implementations are compatible too. making it not a threat to bitcoin because these independent implementations are not going to activate unless they know that both pools and nodes want it.
hence why so far they have not activated anything contentiously... (because they have already been offered a split, but refused)
so there are no user threats, no blackmails no deadlines due to bu or other non-core implementations. just open choice. if it doesnt activate, it doesnt activate.. if it does its because the majority chose it.
simple
however its core with the zealous banscores, the bip9 orphan triggers and tier topology of upstream filters, the UASF threat the change of PoW threat. the actively pushing the fee war up by removing reactive fee estimate to average fee.. removing priority. all to then bribe users with discounts
so while core get sh*t scared that they could lose their tier network control and have to possibly join consensus of an equal playing field of consensus. or.. their preference trigger their own split.
core just hope to scream doomsdays and poke the bear/rock the boat to make it seem like core are the victims of their own splitting away..
much like core gave pools the vote and now playing victim card of "the pools control the vote" and now "we must starve the pools by taking their PoW lunch from them unless they vote for us"(blackmail)
all while dynamic implementations are just plodding along allowing the network to rmain diverse and have a choice of independence that is not core dictated.
|
|
|
|
I will take my chances and say no, because If they did, they would've find out about the crashing nodes bug[1] before someone use it to take all nodes down.
a few nodes went down but the network went on.. .. no bad isses of causing orphan drama or destroying transactions or double spends. cant say the same thing about the leveldb bug of 2013 
is core perfect: https://github.com/bitcoin/bitcoin/issues^ seems not |
|
|
|
|
core concept: be a sheep because rich people are jumping in fields.
if your only choosing core because another person said so. then your just sheep following richer sheep.
instead:
read code, learn consensus look at what is happening behind the sheep scripts.
look at the desperate motives of getting "big names" with money to wave their asses for kisses..
core want a corporate TIER network not a diverse open decentralised PEER network.
so bas what core should be based on bitcoins ethos of NOT being fiat. and instead remaining open and decentralised using consensus.
by choosing just because Rich guy said so. then you have failed to grasp what bitcoin is about and you might as well just go play with fiat
|
|
|
|
IMO it's a problem for the community as a whole, while anyone can be a node so normal users can still have a vote in things, the possibility of "fake" nodes being hosted by sides of the fork to skew numbers is increasingly higher
and nodes can ban obvious sybil nodes by ip banning certain 'servers' |
|
|
|
What you just stated is incorrect in response to my statement.
You are talking about signaling for proposed protocol changes and then
after that change, how that "new protocol" chain is built upon.
What you have failed to address, which is my statement, is that in order for
miners to get a new protocol change, they need a node network that supports
their protocol change. Miners without a decentralized validator node network is
not a blockchain nor a cryptocurrency. What you described is like a OneCoin scam.
Nakamoto Consensus as it was envisioned in the Whitepaper stopped being true
when ASICs forced the separation between Mining and Validating. Today, Miners
if they wanted to, do not need to validate to mine. The Validator Node network
currently holds them to some semi-validation. Without them, miners can build
invalid blocks without recourse.
Nakamoto Consensus was based on 1 CPU = 1 Vote. When 1 CPU = 1 Vote stopped
being applicable, Nakamoto Consensus either ended, or morphed into what I am
saying, depending on your viewpoint. Today, we call it simply "Consensus" (since
"Nakamoto Consensus" essentially failed).
node consensus still exists. nodes can still orphan blocks. this is why core INTENTIONALLY decided to avoid node consensus. do not confuse CORES intentions of giving only pools the vote. with how the 3 dimensional symbiotic secure of consensus works. nodes can still block and ban off anything segwit if they wanted to. this is why segwit has their segwit pstream tier network to strip blocks to 'fake it' to appear as a block that follows old rules to fake it passed nodes. but nodes can ip ban segwit filter nodes if they so wish to. much like segwit can ban and orphan non segwit nodes and blocks. |
|
|
|
dymanics has the hard consensus of nodes and pools. which means NODES can vote against pools.
Here you go again. If pools want A, and they have a serious $$$ stake in A, and the currently active nodes want B, what stops pools to fire up 3 times more nodes voting A for a tiny fraction of $$$ ? because that centralised mindset is just handing a hotpotato around nodes itself own... not the nodes of merchants who have orphaned that block. not the nodes of users who have orphaned that block. pools can sybil themselves all they like.. end result is they are just playing with themselves in their own room.. while the rest of the network are getting good blocks from the other 19 pools that are following rules acceptable to the community. Did you still not understand that proof of work was invented to avoid vote by node, because the above Sybil attack is far too easy ?
bitcoin doesnt just have one layer of protection. it has atleast 10. nodes, coin holders that dont run nodes, and pools.. work in unison of consensus (symbiotic relationship of consent) to agree on a set of rules. EG a low node count cannot change what pools accept EG a low pool count cannot change what node accept a low node or low pool count cannot change what coin holders accept real consensus is about majority of the community your thinking too 2 dimensionally about 1 security feature and expressing its flaw. but your not seeing the bigger 3 dimensional overview of the other security features And don't confuse users (people exchanging coins for value in the market) with nodes again...
P.S stop thinking that nodes are not users. because your missing the big picture |
|
|
|
you argue Nonsense. Mining is centralized by "do this, or else meet my hashrate".
but then slap your own argument down with Ultimately they are easily replaceable,
so which is it.
dynamics has the hard consensus of nodes and pools. which means NODES can vote against pools. its CORE that have bypassed nodes consent(going soft). i think your more angry at pools because of something that core actually caused. but not willing to admit a choice core made by going soft that backfired. you wont admit core went wrong by going soft and giving pools the only vote because you want to remain ademant that core are kings and gods. your also thinking that devs are immortal and will be around for the next 100 years and bitcoin cannot survive without your special immortant team of kings. wake up to your own fairy tale your clinging onto devs do come and go, devs do switch teams. dvs move onto different projects all the time.. so devoting your desire towards a dev, instead of the longevity of whats right for bitcoin and the community is your own failure |
|
|
|
The small blockers have already failed.
If they were right, the community would not be divided or talk serious about a hard fork.
segwit = core(blockstream) job security of their Tier network they want. and able to slide in trojans more easily(going "soft will be easier") without node/pool votes due to use of bribes(fee discount) and blackmails(PoW algo changes) to try getting them to that point. where as dynamics, with simple lines of code changes which many implementations (bar core hesitant group) have already got, allows diverse peers to work with consensus so that they are all on the same playing field where both node and pools have to come to an agreement else it wont change. |
|
|
|
|
Show Posts
