you idiot
how can you guarantee that to 2MB nodes, the 1MB chain will always be the longest chain? you can't.
guarantee? always? i never said that.. stop exaggerating to try convincing yourself its ok to stick your head in the sand and you do realise that making bigger blocks=processing more data. and then sending them out = a bit slower.. which is another reason all in itself to not push forward too soon, as it makes small blockers have more chance of getting a solution first because small blockers have less to process. which is why i said many posts ago.. smart mining pools wont push forward as soon as the trigger is active. as thats just too risky. in short.. we know the suggestion is 750 of 1000 for things to start changing.. so thats 7 days of data. if people notice in 2 days that there are atleast 50%-75% of blocks 144-216 of 288 then thats a clear sign even in the first 2 days that there is a chance that things will change.. giving you 5 days to think and/or prepare.. then you have 28days grace period to prepair if that 750-1000 is actually hit.. then after that, when the setting is in place.. its not a nuclear bomb.. as its still risky.. but to accept the fact that if miners are stupid to push foward while it is risky.. there can be orphans.. but with all thats said. if you have stuck your head in the sand. ignored the early signs.. ignored the time the stats hit where it kicks in. doing nothing for the nxt 28 days.. then still crying like a little baby having a tantrum and refusing to move with the change.. then you have yourself to blame |
|
|
|
then i suggest you re-read what you said. because it's painfully obvious, yet again, that you don't understand how bitcoin works.
again, please explain why 2MB consensus nodes would be orphaning 2MB blocks from the longest valid chain. (it may not be the longest valid chain for 1MB consensus nodes, but that is irrelevant to 2MB nodes)
longest chain?? hello read it again it may not be the instant a >1mb is created. but after a few confirmations(new blocks) when the minority get its turn for blockheight..read the large words.. blockheight = longest chain. hello do you understand.. when small blockers get longest chain AKA blockheight.. the orpans happen new rule nodes do not have to be astronomically unlucky, its not like a 0.00001% chance.. its a 25% chance. and then when you add in factors of small blockers process less data, which increases the chances above 25%. and also the smaller data can be sent around the internet miliseconds faster increases the chances again, its not astronomically small at all.. it would be maybe 33% chance.. screw it.. lets keep it to 25% chance.. out of 4 blocks.. one of them will be the small blockers gaining blockheight.. and so every 4th block... the 2 chains rejoin and the 3 blocks on the bigblock chain gets orphaned as they are not in the small block chain.. thus voiding off 75btc (3x25btc) income of big blockers.. so that is why they wont push forward at 75%... because there is a 25% risk that they could lose EVERYTHING mined over 1mb.. thus even with the trigger date and grace period passed. miners wont risk pushing the boundaries. and that setting will just sit there as a buffer, ready for when they decide to push forward when the risks are ALOT less than 25% |
|
|
|
it sounds like you are assuming that 1MB miners will always and immediately find multiple blocks before 2MB miners will, forcing a miracle orphaning that prevents a hard fork always and forever. I.E. you think if a 2MB block is mined, that two 1MB blocks will be found, forcing the 2MB block to be orphaned. or if two 2MB blocks are mined, three 1MB blocks will be immediately found. in other words, your plan assumes that 2MB miners are astronomically unlucky and are a very small minority of hashing power. this is a really foolish assumption that you are making.
now you are exaggerating and misunderstanding it... let me remind you exactly what i said it may not be the instant a >1mb is created. but after a few confirmations(new blocks) when the minority get its turn for blockheight.. it will cause the new rule miners to orphan off the larger blocks and resync the chains as if the bigger blocks didnt happen.. because they are now following the chain of small blocks.
thats what orphaning is about.
im guessing even when there are very clear signs that things are going to change.. that when the trigger hits and the grace period starts.. even during that 28 day period, you will stick your head in the sand and vow to never change.. admit it. as i feel that you wont change no matter what and your just finding excuses to excuse yourself for not moving with change. i will be shocked if you reply and say that if there was clear sign of change that you would change too, but i know you wont |
|
|
|
at 75% orphans will happen.. it may not be the instant a >1mb is created. but after a few confirmations(new blocks) when the minority get its turn for blockheight.. it will orphan off the larger blocks that dont fit minority rules and rejoin the chains as if the bigger blocks didnt happen.. thats what orphaning is about.
orphaning is part of consensus... 75% is just a trigger, its not enough to form complete consensus and so orphans will still happen. thats why miners will most likely wait until 90%.. even if they have the setting triggered, they would still wait it out to avoid the risk of orphans.. no. you clearly do not understand what orphaned blocks are. the fact that you are comparing an orphaned block to a contentious hard fork is insane. you really should stop acting so condescending, telling people to "learn more" when virtually everything you claim about bitcoin is completely wrong. you clearly do not understand how bitcoin works. please explain why "larger blocks that dont fit minority rules" would be orphaned off. nodes enforce the longest valid chain -- that's it. they don't go back and reconcile with other nodes that are enforcing different rules. why would they? once 2MB consensus nodes start accepting bigger blocks onto the longest valid chain, 1MB consensus nodes will ignore them and continue enforcing the 1MB limit. but for 2MB consensus nodes, nothing is invalid...these are valid blocks being built on the longest valid chain, per their rule set. they have no reason to orphan said blocks, and they won't.
orphans (stale blocks) are valid blocks. a 2MB block under 1MB consensus is not a valid block. if a miner publishes a 2MB block and there is a network of nodes (Classic) enforcing a 2MB limit, the 1MB consensus chain will ignore the block; it's invalid. the 2MB consensus chain will not; it's valid. that block will fork bitcoin into two networks. this isn't about the risk of orphans. it's about the risk of 2 or more blockchains, permanently. thats the point.. 75% is not good enough consensus.
as for why 75%..
well even at any time. anyone can change 1000000 to 2000000.. it dont matter.. the 75% is more of a warning to people to get their act together, its a wakeup call that they should not ignore the possibility
"get your act together ASAP or we're going to break bitcoin!" right.... lesson 1. stales are not orphans. stales are when you give up mid way because someone has found a block before you. orphans are when there are 2 block solves with the previous block(s) being different. and whoever loses. that previous block is orphaned (loses its confirmations and disapears) lesson 2. you are right. small blockers will ignore big blocks, but wont stale their attempt, they would continue and make a small block. lesson 3. if the miners with the new rules see a block under 1mb get solved first. it wont reject it. because the rules are 0 to 2000000.. not 1000000 to 2000000. so a 1mb block is still valid even in the new rules. and because the header data of the 1mb block does not contain any data related to bigger blocks. then the new rule client will say ok 1mb has hit block height by solving first. we need to orphan off the bigger blocks because they dont match the current winning blockheight (small blocker) data chain. remember small blockers have less data to process so they have a chance of making their own chain of small blocks and getting height to make the big blockers orphan off the big block attempts. and thats why 75% is not enough to make big blockers feel safe to even make big blocks. because of the risk of orphans. lesson 4. the trigger would have been set. a month would have passed. and the maority are aing they want to go with the new rules.. so if the minority dont wake up even with all the warnings, hints, and even triggers and graceperiods to get their act together and move over.. then by sticking thir head in the sand and not upgrading even with 75% trigger active, then they only have their selves to blame for forking. if everyone woke up and said, oh look 75% of the network is changing, lets change too to avoid issues.. then there would be no problem. but sticking your head in the sand and shouting to your puppet masters that you will stay below 1mb no matter what, is causing yourself to be a victim |
|
|
|
and IF they see 75% of blocks display the desire to upgrade the buffer before the trigger.. then they really need to get their act together.
if after trigger day, and if after 28 days grace period,, core dev's have not released a public available version with the buffer.. then they will be the cause of the fork by not allowing the public to prepare
remember 2000000 max block size limit. is NOT a nuclear button to force miners into only making blocks over 1mb
remember 2000000 max block size limit. is NOT a nuclear button to force miners into ignoring blocks under 1mb
remember 2000000 max block size limit. is NOT a nuclear button to force miners into making blocks 1.999mb here's the important one: 2MB max block size limit is a nuclear button to force 1MB nodes to fork off any blocks > 1MB. we're trying to prevent the breakdown of bitcoin as a single ledger of 21 million coins. and youre here musing about the freedom of miners to cause that, while telling us to trust them not to. what a joke your not getting it.. try spending a couple days learning more and putting things into scenario's and testing a few theories out. run some simulations.. at 75% orphans will happen.. it may not be the instant a >1mb is created. but after a few confirmations(new blocks) when the minority get its turn for blockheight.. it will cause the new rule miners to orphan off the larger blocks and resync the chains as if the bigger blocks didnt happen.. because they are now following the chain of small blocks. thats what orphaning is about. that is where damage is done as double spends can occur where a business accepts 1confirm.. then several blocks later.. that transaction in the block, disappears.(if the small blockers didnt include it yet, which normally they have similar transactions so it would be included eventually,maybe already, maybe later..) remember transactions dont vanish. they sit in all mempools of all miners. so it eventually tallies it would require 90%+ for the minority to never have enough hash power to keep up. and by that point the minority should have woken up and moved across. |
|
|
|
Bear in mind that it is this consensus mechanism that is maintaining the the Bitcoin core view of what the validation rules are. Arguing that 75% is needed to change is like saying that only 25% can veto the current situation. Which is patently ridiculous and why the rules were made like thy were.
Q. What's more "hostile" than trying to change blocksize limit?
A. Trying to change the consensus mechanism.
you're saying that a 75% threshold is trying to change the consensus mechanism, right? i believe that's true. with a hard fork, it's especially dangerous, as nodes by and large often don't update their software. the 75% just puts the buffer in place.. nothing FORCES a miner to start building blocks bigger than one mb.. it just allows for the opertunity to make them when they are ready, most smart pool owners wont risk it until the level is way higher, to ensure their attempts dont get orphaned. lol wat this buffer talk is complete nonsense. youve got it completely wrong. it doesn't matter if miners are not "forced" to do anything. what matters is that a miner can build bigger blocks after the rules are activated. don't you get it? we don't give a fuck what miners want to do "when they are ready." that's their prerogative. we have our own interests to worry about, like avoiding 2 or more blockchains. youre saying that we should trust 100% of miners to act rationally for the good of the system (without good info on how to do that), even though a 75% threshold has created a situation where a single block mined can fork bitcoin into 2 or more blockchains. not orphaned blocks. more than one "valid" blockchain. literally, your argument is that "smart pool owners" won't risk forking at 75%. if that were true, why the hell are the new rules taking effect after 75%? so we can put trust in all miners not to screw it up before 100% have switched? what if a "dumb miner" builds a 2MB block when only 70-80% are running the new software? 2 or more blockchains, that's what. it's not a buffer at all. that's total bullshit yet you keep saying it over and over in every thread. but i suspect you already knew that. and please don't post that retarded orphaning gif that shows zero understanding of consensus rules orphaning is part of consensus... 75% is just a trigger, its not enough to form complete consensus and so orphans will still happen. thats why miners will most likely wait until 90%+.. even if they have the setting triggered, they would still wait it out to avoid the risk of orphans.. thats the point.. 75% is not good enough consensus. as for why 75%.. well even at any time. anyone can change 1000000 to 2000000.. it dont matter.. the 75% is more of a warning to people to get their act together, its a wakeup call that they should not ignore the possibility |
|
|
|
Nice chart. The stream blocking 1MB-PWC-Coin shows impressive momentum.
based on todays results.. the yellow line is now at 849 |
|
|
|
Bear in mind that it is this consensus mechanism that is maintaining the the Bitcoin core view of what the validation rules are. Arguing that 75% is needed to change is like saying that only 25% can veto the current situation. Which is patently ridiculous and why the rules were made like thy were.
Q. What's more "hostile" than trying to change blocksize limit?
A. Trying to change the consensus mechanism.
you're saying that a 75% threshold is trying to change the consensus mechanism, right? i believe that's true. with a hard fork, it's especially dangerous, as nodes by and large often don't update their software. the 75% just puts the buffer in place.. nothing FORCES a miner to start building blocks bigger than one mb.. it just allows for the opertunity to make them when they are ready, most smart pool owners wont risk it until the level is way higher, to ensure their attempts dont get orphaned. personally i wish the trigger was not based on just 7 days worth of data followed by the grace period, and was instead maybe 70 days worth of data(7500 out of 10,000 blocks), followed by a grace period. but either way, its easy to view the stats way before it even hits the 1000th block of 75% 2mb desire indication, so people can prepare.. but either way.. even now: IF 3 out of 6 blocks show the desire for the new buffer.. people can start thinking that it might be possible because thats about 50% so they have to atleast start thinking its a possibility even without waiting for that 1000th block.. IF 72 out of 144 blocks show the desire for the new buffer.. people can start thinking that it might be possible because thats about 50% and is based on 1 days data instead of one hour, so they have to atleast start thinking its a possibility and not a fluke even without waiting for that 1000th block.. IF 216 out of 432 blocks show the desire for the new buffer.. people can start thinking that it might be possible because thats about 50% and is based on 3 days data instead of one day or hour, so they have to atleast start thinking its a possibility and not a fluke even without waiting for that 1000th block.. IF 4 out of 6 blocks show the desire for the new buffer.. people can start thinking that it might be possible because thats about 66% so they have to atleast start thinking they should probably start coding a version with the new buffer setting even without waiting for that 1000th block.. IF 96 out of 144 blocks show the desire for the new buffer.. people can start thinking that it might be possible because thats about 66% and is based on 1 days data instead of one hour, so they have to atleast start thinking its maybe not a fluke and they should probably start coding a version with the new buffer setting even without waiting for that 1000th block.. IF 216 out of 432 blocks show the desire for the new buffer.. people can start thinking that it might be possible because thats about 66% and is based on 3 days data instead of one day or hour, so they have to atleast start thinking they should probably get they act together and code a version with the new buffer setting even without waiting for that 1000th block.. and IF they see 75% of blocks display the desire to upgrade the buffer before the trigger.. then they really need to get their act together. if after trigger day, and if after 28 days grace period,, core dev's have not released a public available version with the buffer.. then they will be the cause of the fork by not allowing the public to prepare remember 2000000 max block size limit. is NOT a nuclear button to force miners into only making blocks over 1mb remember 2000000 max block size limit. is NOT a nuclear button to force miners into ignoring blocks under 1mb remember 2000000 max block size limit. is NOT a nuclear button to force miners into making blocks 1.999mb |
|
|
|
|
likes is meaningless.
if it was a group that had 5000 members/followers. then that would yield a little more
|
|
|
|
Nothing here indicates that the node consensus mechanism is trivial or easy to bypass. Pseudonodes aren't even operating with the new fork's consensus rules. What we're saying is that the numbers can give the appearance that Classic has significant node support even if it doesn't.
This is why node centralization is relevant. What used to be over 10,000 nodes is now closer to 5,000. The more bandwidth pressure we put on nodes, the less nodes we have, and the easier it is to mount a Sybil attack, such as the one Classic backers are currently mounting.
segwit 'no witness mode' takes a full node away from being a fullnode and into being just a compatible node. centralization is where there is only one source of code. so blockstream wanting to be the only source of a fullnode. is them centralizing and then lowering the distribution of fullnodes by allowing a non-witness mode and wrongfully telling them its ok to not accept witness data as for saying that everyone that wants 2mb is a "classic backer" shows your narrowmindedness.. oh and if you think that blockstream is winning the debate.. ill use lauda's data from an earlier post (grey and yellow show recent decisions on direction)  |
|
|
|
Are you suggesting that segwit does not serve to optimize the increased throughput of multi-sig transactions? I suspect my comment went completely over your head.
it didnt go over my head, i just think that YOU have not thought deeply enough about all the factors and that your point has not even grown enough to be above your ankle.. so i stepped over it because you wont understand it |
|
|
|
Ahh... well feels like deja vu again...
Your math doesn't add up , and you are incorrectly speculating on manners you have already been corrected on. You simply don't care about the facts when you are repeatedly corrected thus can be ignored.
my maths does not assume the average of 4000 transactions is 1.7mb with segwit.(because i know its more than 1.7mb) i just used the 1.7mb as it was a number you assumed so i was just playing on your mindset to get to the mainpoint, because you would have knit picked more if i argued that 1.7mb was wrong the reason i have said that 1mb of current style transactions is 2000 average. because that is based on the average transaction count of the blocks that actually bother to fill blocks. and before you knit pick ill clear the matter up.. ITS AN AVERAGE, NOT A HARD RULE |
|
|
|
Why would you frame it this way ? If you are to ignore all the other differences in proposals the difference in capacity is 1.7-2MB for Core vs 2MB for classic.... In other words shouldn't you revise your statements to discuss other differences because we clearly are supporting segwit with 1.7-2 MB? You really are losing a lot of credibility.
nah. segwit PROPOSES 1.7 equivelent worth of transactions... and then 2 months later bloat up transactions with more opcodes and features. bringing transactions per second back down.. EG imagine that there are 2000 transactions potential for 1mb, thats 4000 potential for 2mb with segwit its 3400 for 2 months and then 2000 once all their fiddly additions are added. if you dont believe me. ask the dev's on IRC how many bytes are needed to add things like payment codes. how many bytes the ID is in the witness merkle to link back into the main merkle. (hint, its not less than 70 bytes) however a 2mb+segwit is 4000 transactions + all the features |
|
|
|
what bitcoin digital currency dosent have an official fb page i think it is
does the dollar have its own facebook page? does the Pound? no but BUSINESSES that use FIAT currency do. EG bank of america, paypal, bank of england. barclays pingit and so do BUSINESSES that use bitcoin https://www.facebook.com/Coinbasehttps://www.facebook.com/Bitstampand by the way, facebook isnt great. it can be abused. take bitstamps message posted just yesterday Dear customers,
we were notified that there are phishing messages posing as Bitstamp being sent on Facebook. Please do not click on links or open attachments!
Best regards,
Bitstamp team
|
|
|
|
centralization is one central point.. bitcoin will be decentralized by its very definition. but its DISTRIBUTION of that decentralization can be reduced even segwit can cause a reduction in distribution of fullnodes. by allowing the 5000 nodes to think its ok to not be fullnodes(archival mode) and instead be just compatible (no witness mode). 1=centralize 2(unrelated not coluding)= limited distribution decentralized 10,000= wide distribution decentralized decentralization is not a true or false question.  its a sliding scale  |
|
|
|
|
there are only about 20 that have any interest or prospect to last. the rest are just pump and dumps.
so if you concentrate on 20 currencies, and then compare it to the fiat legal tender world. which has 180 currencies.. then i think that there is room for all of the 20 main crypto's to prosper and work along side each other and work along side fiat without issue.
|
|
|
|
this will never happen.. there is no reason to believe the price of bitcoin will stay proportional to the block reward.
its not how it works.. miners dont just set the price of bitcoin.
many people think that $1k is possibly in a year. $2k in 2 years. $4k in 3 years time.. $8k in 4 years time (EG 2000% in 4 years. just like the $20 high average($6-$32) of 2011-2012 became $400 in 4 years) so i did not state aspeculative rise that could be alot higher(spitballing a speculative price of $100k) in 20 years.. i stayed at a modest and lowball figure of $6400 in 20 years $6400 is very achievable in 20 years.. no two.. but .. 20 |
|
|
|
Bullshit. My home internet broadband could handle 150MB+ blocks.
I know that it's not the case for most users, but 1MB is a joke.
You're the one spreading who's full of "bullshit". Your connection has nothing to do with what the networks capabilities. Good luck validating 150 MB blocks right now. It is even possible to create a block that would take more than 10 minutes to validate at 2 MB because of the quadratic scaling.
Off topic: What degree do you have? Are you another economist, art teacher, or something else irrelevant trying to spread your "wisdom" on technology? lauda fails to show statistics that show that the internet is still at dialup speeds. or home computers are not powerful enough.. and instead resorts to character assassination. so here are some details its 2016 not 2001.. people can play online games in HD(upload data for character movements, directions of fire and bullet tragectory on a constant bases (not a 1scond webpage analogy that gavin stupidly made)), while on teamspeak(voice upload), while also streaming it to twitch in HD (large upload).. simultaneously.. so that debunks bandwith.. also bitcoin runs on a raspberry pi right now. so a intel celeron laptop is twice as powerful. and a intel i7 standard desktop is twice the power again.. so that means standard desktops are atleast 4x more powerful and able to handle bitcoin at 4x the scale.. so 2x the scale is no issues |
|
|
|
Let's say that 700 million people use Bitcoin (that's ~10% of the World population, even less), and that they all make only 1 transaction per day. Transaction size is averaging half a kilobyte today (source Bitcoin Wiki).
700 million transactions * 0.5 = 350 million Kilobyte = ~350 GB/ 144 (blocks per day) = ~2.4 Gigabyte per block. This is only if they make a single transaction per day (which is unlikely, as the average would be much higher with adoption on this scale).
350x365 = 127 750 GB per year (i.e. 127 TB). This can be avoided with the second layer.
pulling random numbers out of your ass,,(700mill users, 1 tx a day) where did you even get these numbers from your putting a utopian dream of 20+ years time, to try defending blockstreams greed of 2016 decisions.. really! your numbers have nothing to do with any possible reality of 2016-2018, get a grip the debate for the next 2 years is basically 2mb+segwit (approx 4mb capacity emulation) currently 1mb allows 2000 tx(average) a block. 144 blocks a day. thats basically acting as if 288,000 transactions a day.. you can interpret it as only 288,000 doing 1 transaction a day or 2million people making a transaction every 7 days. with 2mb. thats upto 576,000 tx a day potential. with 2mb segwit. its initially 1million tx a day, and then downplayed to 500,000 once things like payment codes and other added variables/constants added to the tx. with 1mb segwit its initially 500,000 tx a day and then downplayed to 250,000 once things like payment codes and other added variables/constants added to the tx. |
|
|
|
1. There is no issue right now. Transactions are going through and the network is functioning properly. Is this not the case?
transactions are not going through in 10 minutes.. some are waiting an hour are you that blind
2. Saying "agree to disagree" doesn't invalidate my claim, it just tells me that you have no arguments. A 2 MB block size proposal is not a solution, it is kick of the can down the road.
segwit is not a scalability solution. it is just a temporary gimmick.. removing 70bytes of signature one day and later adding more bytes later with the other features. its like going on a diet for a week and then going to an all-you-can-eat for a month 3. You do realize that the development is not solely focused on the scaleability? Their announcement states the following:
yep they are more interested in making their premined sidechains be instantly worth the same price as bitcoin (greedy BStards). their aim is a firesale, bait and switching people over to their premines. they dont care about bitcoin scaleability.. they want their billion dollar premine profits, by making bitcoin unscalable and costly to use to switch people over lauda is still on the mindset that its a core vs classic.. he needs to learn that CORE can, should and eventually need to move to 2mb.. even if its a 2mb+segwit. that the only real debate is WHEN.. |
|
|
|
|
Show Posts
