You're pushing a CLEARLY sub-standard version of Bitcoin, that has MAJOR ramifications for security and decentralisation.
and then i want 3 miners to control the [core] network and that's all! ( Because that's how many miners will be left [with core] once BU kicks in[with 17] )
sparta is happy with a more centralised mining network and cores more centralised TIER network hypocrisy at its best. core only want core nodes to be the upstream TIER of full validation nodes. leaving other implementations in a cess pool of down stream filtered, prunned, no witness, stripped block, half relay network. where by people need to move funds to new keypairs that are incompatible and not validate to the cesspool of second tier nodes but blindly accepted due to a loophole. dynamics can move the blocksize and bu, xt, classic bitcoinec and many other implementations can all work side by side as PEERS (core too if they just change a few lines of code) all on the same level playing field (the actual definition of decentralised) of full validation. no need to strip data out or move users to new keypairs to achieve anything. things just move on bu for instance has not been well peer reviewed because the cough independent cough devs are too far up gmaxwells ass that they wont independently review BU's tweaks to CORES original 0.12 code. they would rather attack it and say "no one spotted a bug that used to be in core but was patched in 0.13) its funny when an cough independent cough dev prefers to shout its not been independently peer reviewed, rather than review it himself and help.. just makes himself look bad by admitting he is not independent will everyone put ego's aside, forget which kings ass you wish to kiss and everyone actually start thinking about the network fundamentals. |
|
|
|
now would pools jump to 2mb where there might be hit by that bug AND say 5 other propagation issues aswell all in one swoop of mega F*ck-ups and then have to tear up and remake a 1mb block with half as many tx's to try again..
or wrongly guess that it must be an issue at 2mb so try 1.9mb and have that block too throwing a tantrum in the orphanage, then try 1.8 and so on all creating orphan tantrums trying to find a new 'sweetspot' that is acceptable(to potential knitpicker: yes i know bitcoin doesnt have an actual 'orphanage' place, im just entertaining wordplay of 'orphan drama' to entertain the imaginations of people with short attention span)
Are you saying that the network participants should put *trust* into the miners in hopes that they don't centralize in order to reduce orphans, but rather produce smaller blocks?  what are you even on about "centralize" the pools earn more by competing. 1. jumping to 2mb instantly makes propagation delays and loses the competitive advantage. so pools will move in small increments to keep their competitive advantage 2. no point jumping to 2mb because there may be several bugs and if going to 2mb then down hoping to find a sweet spot can cost them multiple blocks of wasted time.. can cause many orphans.. due to bugs and propagation. 3. going up from 1mb in small amounts reduces orphan risks and keeps a good grasp of acceptable propagation times. oh and if you think that going from 1mb to 2mb in small increments of 250bytes would take years.. and thats your real argument im betting. your wrong. it can take a month of safe testing the water with least orphan risks and least cost to pools and their competitive edge. increments of 1kb can get to 2mb in a week and increments of 0.25mb can get to 2mb in under an hour so relax. its best to be safe.. rather then have been waiting years just to get a chance and then try to rush things in 1 block or 1 hour. 1 extra month of good practice safe increments isnt gonna kill bitcoin. but jumping straight to 2mb could cause another 2013 event. pools are smart enough to know this |
|
|
|
This thing might have been answered several times but still I cannot understand why do we need a hardfork when softfork is available, aside from that, is it really necessary that a hardfork is needed In order to upgrade bitcoin features? Sorry for being so noob about this but I do believe that there is a strong reason why these exchanges are so against the hardfork.
though soft methods are available. where by the pools get to vote. nodes matter. if there are not a good amount of nodes validating the data diversely than data could be corrupted by one party saying "follow me" and non validators blindly accept them. this is a risk nodes are important. and we should not aimlessly let the node count be turned into a TIER network of one brand setting the rules and other brands playing pass the parcel of data its not checking. some soft methods are acceptable because its not changing anything fundamental and still allows the PEER network to check the data and strike off blocks it doesnt approve of. however in a TIER network some nodes are nothing more then unreliable data stores. so worthless as a security measure and thus no point being a node. when something rule changing occurs its always best to have good node acceptability first for security purposes of avoiding corruption and to give pools confidence that what pools build will be accepted with full validation. core however bypassed letting full nodes have a vote on what should be valid. by implying a TIER network where core implementations validate the block that core set new rules to. and then core will strip that block and twist the data to blindly pass other nodes.. not as valid or invalid.. just out of scope of other nodes tests would pass or fail, so blindly kept not due to being fully validated but by not triggering certain old alerts. this is dangerous. also by making it easier to do soft patches. is a network security risk because thats where trojan horse attacks can happen even more easily.. by simply not triggering the rules due to finding the hole in the defence to continue unnoticed core think its good because it allows them an easier life.. but it makes it an easier life for attackers too |
|
|
|
|
im just addressing your comment about you and other peoples bad maths of block times
EG
imagine a room
4 tables and groups of people sat at each table.
they are all given a set of 6dice
they have to roll them until someone gets 1,1,1,1,1,1
the red table could get it in 10 minutes.
it does not mean that because red get it in 10 minutes that the brown table would take 20 minutes or the purple table would take 30 minutes or the blue table would take 40 minutes
they could all be seconds apart but because red won, that round only red counts so no one cares about the other 3 tables times.
next round, starts again, this time the brown and blue table both get it but based on how many shakes to get it was just one extra shake in favour of brown. they are shown as doing the slightly miniscule extra amount of work so they win.. other 3 table are not counted.
now then.. if you evict the red and blue from the room.. this does not suddenly make the groups any slower. infact it helps them as there is less competition to beat them by seconds. so now brown and purple can get more blocks more often because there are less competitors to lose against by seconds
..
also a note
the difficulty is not set by "network hashrate" nor is the speed of say red table or blue tables shakes/dice helping brown or purple.
they all have different dice and doing their own work
infact the faster red and blue shake the less chance brown and purple get because red and blue could beat them by seconds.
its not the faster red and blue shake the more thy help brown and purple. (increase of network does not help the work of a single team)
in short
when antpool wins a block. its because of the work done by antpool and antpool only... the other hashrates of the other pools did not jump into their pool to help antpool. antpool alone made a bloke with thir own 600peta. not the networks many exa..
when red wins a diceround. its because of the work done by red and red only the other shakes of the other tables did not jump into the red table to help the red table. the red table alone shook the correct dice combination first with their own teams hands not all the hands of the room.
its a competition of different pools/tables doing their OWN work. competing against each other.. not a collusion of a single pool/room all shaking/hashing one thing
|
|
|
|
|
dynamic nodes and pools wont trigger unless there is safe majority of three things
1. node acceptance
2. merchant acceptance
3. pools keeping the data secure by high chainwork (laymens combination of hashrate and height)
however
core could release their rage (BIP9 at lower than 95%, UASF or change of algo) and make a contentious attack against dynamic implementations
this is why all the brands which have the ability to accept blocks over 1mb have refused gmaxwells invitation to split away. because the dynamic block implementations will only trigger when there is consensus.
this is why all the brands that have the ability to accept blocks over 1mb have not set any deadlines. not bribed the community with txdata twisting code using new keypairs and blockdata structures to offer discounts, not included nuclear banhammer code to make threats.
they have instead for the last couple years just plodded along allowing the community to freely choose or not choose the many diverse implementations that allow over 1mb base block.
and thats what scares core the most to feel so threatened by the community that they needed to avoid community consensus by going soft and avoid a node vote.. but also shooting themselves in the foot by giving just pools the vote. but pools are smart enough to wait to see (unofficially) what the nodes want to do.(pools wont vote unless clear high node/merchant flags are being waved)
|
|
|
|
they may even once say the first few blocks above 1mb havnt caused issues. increment it in 0.25mb increments. taking possibly a day or less to get to 2mb... but one thing is for sure they wont just jump to 2mb -straight off. they will see if there are unknown bugs/orphan risks etc
-snip-
Slow increments will not reveal all possible exploits. They will be revealed once someone attempts to use them, at which time damage has already started occuring. lets say there was another Leveldb 2013 episode, but this time at 1.2mb the pools dont know its 1.2 yet though now would pools jump to 2mb where there might be hit by that bug AND say 5 other propagation issues aswell all in one swoop of mega F*ck-ups and then have to tear up and remake a 1mb block with half as many tx's to try again.. or wrongly guess that it must be an issue at 2mb so try 1.9mb and have that block too throwing a tantrum in the orphanage, then try 1.8 and so on all creating orphan tantrums trying to find a new 'sweetspot' that is acceptable (to potential knitpicker: yes i know bitcoin doesnt have an actual 'orphanage' place, im just entertaining wordplay of 'orphan drama' to entertain the imaginations of people with short attention span)or logically start in small increments. and when hitting 1.200250mb.. the block causes orphans. so they just take 1tx (250bytes) out of their list and try again. knowing to not pass 1.2mb while things get sorted. then later when sorted they go again. safely knowing at most its only going to cause minimal disruption... rather then several orphans of going straight to 2mb and haviing to work its way down trying to find a sweet spot. without instantly knowing whats a good or bad size to run with(apart from 1mb again) |
|
|
|
Doesn't make any sense TBH. We should've seen it starting to replace conventional currencies by now.
Revolutions happen not at the speed we like but at the speed they can, bitcoin is gaining ground slowly, I think almost everyone in the forum would like this to be faster but it is what it is and we don't have too much of a choice but to wait for it. wait for who/what oh for bitcoin to grow legs and a voicebox and walk into your local store and have a word with the manager.. remember YOU being here having bitcoin makes YOU part of bitcoin. if YOU want YOUR local store to accept bitcoin YOU and people near YOU and YOUR local store need to be the arms and legs and voicebox for bitcoin. bitcoin protocol is just code. not a sentient being. i done my part i can buy food pay bills etc and helped a few businesses and individuals with bitcoin. i havnt needed to look at my fiat bank balance since 2012-2013 if everyone done something in their area the butterfly effect would see faster results. if everyone sat on their hand waiting for bitcoin sentient protocol to do it all....... well.. you can wait as long as you like |
|
|
|
Well, no, it does not make it clearer. However, it is peripheral to my point. Which is that it is unlikely that BU miners will creep up initially. They will likely go straight to 2MB. For as long as it takes to clear the transaction backlog. For such would deliver a demonstrably better user experience (faster cheaper transaction processing) relative to the other chain.
Yes, further increases may be likely to be more incremental in nature.
they would actually creep up in increments, thats the smart thing. (as the 500k berkely locks/levelbdb upgrade drama has taught the community) they done so in the past.(policy.h v0.7 0.5mb, policy.h v0.8 0.75mb, now 0.999mb) but here is where your missing a few idea's moving at say 250byte a block increments, means they can reasonably safely get to 2mb in about a month. so it wont be 2mb activation day .. and it wont be 2mb by 2020 by being slow about the increments. 250byte per block increments = 4 weeks-ish 500byte per block increments = 2 weeks-ish 1kb per block increments = a week-ish they may even once say the first few blocks above 1mb havnt caused issues. increment it in 0.25mb increments. taking possibly a day or less to get to 2mb... but one thing is for sure they wont just jump to 2mb straight off. they will see if there are unknown bugs/orphan risks etc so not that long when you think about it |
|
|
|
in the post from like an hour ago which u revised
I posted and ran to the store, returned, and revised. When it posted, I noticed you answered even though before I started your comment was not there. Very high consensus can't make two surviving chains. actually it can. an altcoin can be made by just 1 node deciding it wll do its own thing if it wanted to. an altcoin can be made by majority banning and splitting that last 5% minority. but then that minority have to ask themselves is there a good enough reason to try keeping it going. (so many scenarios running through my mind.. kinda hard to summarise it all) a few things we are sure of 1. BU wont trigger unless safe majority of node and pool (no threats, no time bombs, no blackmails. just plod along and let nature handle it) 2, core will have the triggers, time bombs and threats and could trigger while things are contentious, forcing the issue still too early to tell If a handful of non-mining nodes are still active, that does not count toward chain status. In the event we are talking about, there must be some miners. If there is 1 miner/pool with a "reasonable" amount of hash power, where that single miner has the ability to mine till a difficultly adjustment within the next year or so, then it is still alive. The question then comes down to whether they can afford to do so. The answer is very likely that they can not and as such, the minority chain will die. If it takes that single miner 500 years to get to the difficultly adjustment, even though the whole community likely left them behind, that chain survives and will work its way out of the "difficulty snare". Bitcoin versus Altcoin status can not be determined on "longest chain/most work" because one day that could be used against the community in an obviously malicious way, IMO. i think im going to drive your mind crazy now.. sorry in advance 5% of pool consensus of blocks does not mean 5% hashpower. 5% of pool consensus of blocks does not mean 20x longer to make a block once going at it with 95% less competition... save re-writing it the maths does not work that linearly. EG if there are 4 pools of equal hash. it does not mean take one away and the time moves to 20 minutes. because the competition may have only been only seconds behind getting their own solution. bitcoins are not mined based on the combined hashpower of the network. each pool makes their own effort. and the "75%" [others] mentioned [as threshold] is not 1 pools. here this image will make it a bit clearer  as you can see 75% of blocks is just HALF the network hashrate in this example,(top half of image) but the block timings still are reasonable whichever way you play it(bottom half when they have split) ok im gonna take a break.. (brain switched off in 3.2.1) |
|
|
|
in the post from like an hour ago which u revised Very high consensus can't make two surviving chains. actually it can. an altcoin can be made by just 1 node deciding it wll do its own thing if it wanted to. an altcoin can be made by majority banning and splitting that last 5% minority will do its own thing if it wanted to. an altcoin can be made by the last 5% minority banning and splitting themselves do its own thing if it wanted to. but then that minority have to ask themselves is there a good enough reason to try keeping it going. (so many scenarios running through my mind.. kinda hard to summarise it all) a few things we are sure of 1. BU and other lik minded peers wont trigger unless safe majority of node and pool (no threats, no time bombs, no blackmails. just plod along and let nature handle it) 2, core will have the triggers, time bombs and threats and could trigger while things are contentious, forcing the issue or at consensus. but its core rocking the boat more than anything else still too early to tell I do not agree. I think an altcoin is always an altcoin until there is one chain.
If there is a bilateral split, the spiting chain will always be an altcoin since that
breaks the Consensus Mechanisms.
So, if both chains survive in a non-bilateral situation, the determination of altcoin
status can not be determined. I think one must die to truly determine who is
the "Bitcoin". If an implementation wishes to be the "new protocol" the old must
die, it can not be "the most hash currently". It must be finalized in general and
for the economies.
its not a simpl "hash wins" it is about nodes, network confidence of majority nodes and also which merchants allow deposits of it. funny part is.. by the exchanges saying they will accept bu (and if controversially call it BTU/BCU or consensus call it bitcoin and segwit BCC/SWcoin) they are actually helping BU and other dynamics to be accepted as "the bitcoin" in a majority event remember BU wont trigger itself unless it it has the 3.. hash, nodes and merchants. other matter is. BU is just one implementation. if a base blocksize limit movement trigger does occur. many implementations(classlic xt) would work with it. core is just one implementation. if a segwit block trigger does occur. many implementations(btcc, knots) would work with it. so its not strictly a BU event or a BU chain.. its more of a dynamic peer vs segwit tier rather than bu vs core but thats just confusing the matters more. |
|
|
|
So back to the OP, I should have stated this:
Altcoins, in the OPs intention, are only created by hardforks. Softforks can't make altcoins two surviving chains.
SegWit would only be an "altcoin" if there was a hardfork with two surviving chains. and segwit was minority
whereby BU and a flock of other implementations of consensus (classic, xt, and other adjustable blocksize PEER imps) become bitcoin
due to having majority of hash, nodes and merchant acceptance
core could kill off its minority chain and then just add a few lines to be dynamic and join the PEER network of many implementation
BU would only be an "altcoin" if there was a hardfork with two surviving chains. and BU was minority
whereby segwit and a flock of other implementations of consensus (classic, xt, and other imps running as downstream second TIER) become bitcoin
due to having majority of hash, nodes and merchant acceptance
BU could kill off its minority chain without any code changes can just join segwit as a downstream second tier of many implementations
BU could kill off its minority chain and can with segwit code additions join segwit as a upstream first tier with core
i removed this line: If BU survives and the minority chain dies off, BU transforms from altcoin into "Bitcoin".because if BU had majority. its already bitcoin along with the other implementations (where segwit is the altcoin or just dead) theres still some irregularities even with the FTFY summary. due to when/if core triggers their bip9/UASF/PoW change, and which markets treat it as such. and as highlighted if there remained 2 chains or not. or the opposing implementations give in to join the peer or tier network but its close enough |
|
|
|
|
a fork is a different path.
it does not mean it has to survive more than on block. it does not mean it has to live on forever. it just means a different path has opened up
orphans are where forks are killed
|
|
|
|
|
lol by the time an announcement to get people to revv up their own GPU's occur. the big companies will already have new blueprints of a next-gen ASIC that will dominate any new algo.
they can be back in business at the top again before a PoW change activates.
i do laugh though
"blame china"
"blame jihan"
...
nah. blame core for intentionally going soft and giving pools the vote where by 58% are not even jihan
if core went hard(node then pool) by actually involving the nodes the confidence boost of nodes being ready would make more of the 58%-74% vote towards it.
pools simply wont vote for anything to any high degree unless they know nodes will accept that change. core shot themselves in the foot by avoiding that confidence logic.
|
|
|
|
Now that BU promoters have begun to promote yet more alternative hard-forks, well, it's possible that the BU camp is in disarray.
Which might not stop Bitmain from just forking anyway,
bitmain forking off at 16%.. im laughing plase learn consensus.. strangely in the last 48 hours i thought you were starting to grasp it.. now your talking about controversial and bilateral splits why would a pool do that at just 16%. hell while we are at it.. why would/wouldnt BTCC/bitfury do the exact same thing... (putting shoe on other foot) but I'm not quite seeing that happening. I predict they will do the same thing as the last 2 failed coups; abandon the latest failure, and start pushing for the new hard-fork, which will of course will also be much better than Core (and will also die a death). or just do a core. and not listen to the community. and instead bribe(fee discount), blackmail(BIP9/UASF) and threaten(PoW along change) to get what only core desire.. and stand their ground point fingers at everyone else playing a victim card if core actually took a step back and thought.. hmmm voting isnt going well. lets try something that the community might accept. then things could move forward. having different implementations actually can help increase the odds of something happening |
|
|
|
Edit: You added more to your post: So you are saying there is a chain split and the nodes
are bouncing between the two chains with two different rules depending on "most work"?
your trying to ask a question about chain of events, but its not a 2 answer question. also we can speculate all day long about will core actually pull the trigger to their bip9 early(possible) if they would UASF or even PoW banish. without knowing if core will trigger it at say dynamic vote of under 50%... or wait for things to get very threatening for core by waiting for majority on dynamics side of 75%-95% the chain of events can alter |
|
|
|
Ok, I understand all that.
Are you saying that when Miners/Pools "activate" the softfork, there is literally a new chain?
no.. im saying there are 3 possibilities.. well 6 in total of what happens. depending if its consensual (one chain all agree, opposer's just left dead in the water unsynced) or controversial they dont agree but they fight it out with orphans and swapping chains drama and headaches and double spend risks etc or bilateral, by ignoring and thats when there is 2 linear nonfighting chains as i said too many people just take soft and only mention softs best case.. then take hard and only mention hards worse case From what you provided, if there was a new chain, the nodes wouldn't be able to see the miners
anymore since they are not participating, they are literally blind and still on the same chain.
it all depends on circumstance there are 6 possible results.. not 2 If a softfork chain split is possible, why do old nodes still read the same blockchain?
This is what I don't understand. If it was a new chain, they are lost since they didn't upgrade.
A sfoftfork "tricks" the nodes with new rules without an upgrade or a chain split.
Where as I wrong here?
dependant on whats been changed. yes while the POOLS(soft) are either endlessly fighting or going separate ways the non-mining nodes could also be in the orphan drama or just not getting relayed anything.. leaving them stuck and unsynced. like i said for months.. its not a simple yes no answer multiple things can occur. but based on BU refusing to bilateral split and only want consensus. if BU got consensus.. nodes such as BU,classic, xt and other including some core nodes that did tweak their blocklimit will carry on. the blockstream(core) that refuses dynamics or shifting to a higher base block would be left stuck and not syncing. dead in th water however core are threatening soft bilateral. which then can allow corefanboy pools(soft) to build on by ignoring dynamic pools. and then that leads the nodes(hard) are in controversy because of orphan drama.. because there are 2 chains(but core would orphan the dynamic one) eventually leading to nodes(hard) doing a bilateral, to avoid seeing the dynamic block just to stop auto orphaning them by just being blind to them.. meaning it becomes a hard bilateral split. excuse the pun... its not a trigger.. its a CHAIN of events |
|
|
|
well you did add the "non-contentious".. rather than just ask about soft.. but here goes. for 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 in short PoolA simply ignore and automatically reject blocks of certain version. and they just build on their own. 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-- by pools doing this. they can keep building their own without halting just by looking at the version and declining it. without even validating its tx contents what you will find it that there are 2 chains. growing forever.. but because its soft. the non-minin nodes(hard) will get confused be and swapping between the two dependant on height (non-mining node mega orphan drama(causing hard controversy) which then forces the nodes to pick a side just so the nodes dont see the orphan drama causing a hard bilatral split.. or remain with the orphan controversy mega orphan drama of endlessly swapping but with or without non-mining nodes the pools are building 2 chains and not fighting, just ignoring each other |
|
|
|
SegWit would only be an "altcoin" if there was a hardfork with two surviving chains.
Altcoins, in the OPs intention, are only created by hardforks. Softforks can't make altcoins.
yes they can and thats where the fake sales pitch of the reddit script writers have fooled you by only talking about the best case scenario of soft and worse case of hard.. but not mentioning all the options I don't go on reddit. Can you explain to me how two surviving chains could exist in a non-contentious softfork? see now your twisting things soft can be consensus meaning no split.. or contentious possibly split or bilateral guaranteed by you intentionally saying non-contentious.. your baiting... try "Can you explain to me how two surviving chains could exist in a non-consenus softfork? and your answer is bip9 has code in it to trigger banning and orphaning.. oh and UASF does too.. i think you can guess what the S stands for |
|
|
|
SegWit would only be an "altcoin" if there was a hardfork with two surviving chains.
Altcoins, in the OPs intention, are only created by hardforks. Softforks can't make altcoins.
yes they can and thats where the fake sales pitch of the reddit script writers have fooled you by only talking about the best case scenario of soft and worse case of hard.. but not mentioning all the options |
|
|
|
Becouse Bitcoin is the legit one, not like this BU that is a joke with lot of bugs and issues.. I am an amateur talking here but history shown that people want the safe side not the bug side..
you think core is perfect.. hmmm 8 years of orphans - https://blockchain.info/orphaned-blocks (if perfect there should never be a orphan) major orphan event in 2013 even now https://github.com/bitcoin/bitcoin/issuesoh and need we forget. if core is soo perfect then segwit is not needed because there is nothing to "fix" 20 billion dollar and say: Go have fun I don't care what you do with my money..
you do know there is not actually 20 billion in fiat sat around in bank accounts with bitcoins name on it |
|
|
|
|
Show Posts
