I'm not convinced you are understanding what I am saying. Your description above may be the way things work today (is it?), but it is a stupid design.
i understand fully what your saying.. pools and others ..including myself are many steps ahead of your scenario. pools have mitigated the risk and found the best efficient ways to handle the problem your describing. i may have skipped ahead a few details which would have made what im saying more understandable. but in short. by pool B telling asics (separate location) to start a new 'empty block'. gains a pool a ~20% advantage rather than waiting the full couple minutes to download the full block A, validate block A's solution and then start a block B with transactions. there was a bit of drama about this in 2014-2015 scenarios thrown around. benefits/risks talked about at length, blah blah blah ultimately, where the orphan risk was only ~1-2%, so that 20% advantage is worth doing. now they found other ways to mitigate it too and the orphan rate is even lower than 1% these days. while still gaining the 20% advantage by starting a new block while simultaneously validating a previous block. remember a pool validates and relays blocks.. but asics (separate location and processors) do the hashing. hashing blocks is not what the pool does.. validating competing blocks is not what asics do.. just like cooking a steak(asic hashing) is not a restaurant manager(pool) does just like driving a taxi(asic hashing) is not a taxi company call centre(pool) does so its not like hashing a new block and validating old block is overpowering a pools CPU.. they are done by separate processors |
|
|
|
The project became to big for him, and he left the scene. He underestimated his support and wanted to come back, but he was not welcomed with open arms. He then started a competing fork, to take back the power. < hostile takeover > but this failed.
this is where lack of knowledge fails.. people start speculating non-core devs want consensus (one chain) agreement.. its actually blockstream employees that want dominance via intentional splits (bilateral fork). 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-- yep other implementations disagreed to a intentional split.. and only gmaxwell proposed intentional splits. you would have learned this if you read the code of non-core implementations and understood.. or if you looked at peoples real motives by researching them. but instead you followed the teenage drama of accusations about things unrelated to code. and then made your mind up from misinformation handed to you by the teenage drama creators as mentioning doing a talk with the CIA. there are video's of it, so there are no secrets of what was discussed. but what about blockstreams closed door roundtable events with the bankers this month... oh wait you will downplay that teenage drama.. |
|
|
|
very true, and i am willing to wait a day of two for a secure wallet for storage. and if i am intending to deposit coins into that wallet to keep them safe, i do not want to try to monkey around the download time at the risk of being any less than 100% secure
like i said.. by downloading red first instead of last. your getting that the wallet is local. the data is not coming from a central server but from the same diverse nodes. its just downloading the red color first instead of last. ok, let me say that i am not disagreeing with your idea, simply saying i personally do not need it. if the demand for such changes becomes great enough, you or someone else will make it happen. it is not a bad idea, simply one that i do not need to take advantage of. im not saying you personally need it. but you raised a point this is the only time is using bitcoin when there is a huge issue because the the size. i think it is just going to get to the point when fewer and fewer people choose that type of wallet. someone intentionally setting up a full node will have to deal with it
and i informed you that its not actually an issue that cannot be solved in a few lines of code.. because it can be solved with just a few lines of code |
|
|
|
very true, and i am willing to wait a day of two for a secure wallet for storage. and if i am intending to deposit coins into that wallet to keep them safe, i do not want to try to monkey around the download time at the risk of being any less than 100% secure
like i said.. by downloading red first instead of last. your getting that the wallet is local. the data is not coming from a central server but from the same diverse nodes. its just downloading the red color first instead of last. |
|
|
|
I'm not saying we shouldn't check the code before we run it, I assumed that was a given, heh. But clearly discussing the code and, more importantly, the effects of the code, would be a vast improvement over the current speculations and accusations about a person's supposed intent that seems to pervade most threads lately. Talk about good and bad code, not good and bad people or companies.
i agree about things like that. where talking about "is trumps hair real" having nothing to do with the politics and laws he may introduce where talking about "is trump a sexual harasser" having nothing to do with the if he will fix the world debt problem but when he introduces a new law.. reading it takes priority, understanding the law takes priority. but knowing why he introduced it and his intentions of using it reveals HOW it will be used. EG a law that allows tax offices to view peoples bank accounts. thats it. thats all a law code mentions.. reading the lawcode alone can cause speculation, exaggerations, doomsdays and hysterics. but knowing if it would be good by only being used to find the richguys screwing tax.. or the poor... also matters for instance personal attacks like "gmaxwell has a beard, ewww.. and he is fat" is just nonsense teenage drama that has no merit. and should not be the debate but... personal attacks like "gmaxwell wants to bilateral fork the network to get his commercial services accepted to repay his debt to bankers" has merit. because it impacts other people financially and intentionally |
|
|
|
i see no major problem that requires repair
this is the only time is using bitcoin when there is a huge issue because the the size. i think it is just going to get to the point when fewer and fewer people choose that type of wallet. someone intentionally setting up a full node will have to deal with it
|
|
|
|
for me, as a trader and wallet holder, several wallet types without the need for a download are fine. the reason for me ever setting up a wallet deeper than that is because i am going to do some major work in bitcoin. at a bare minimum, i am choosing the run a node and help the network, on the other end of the spectrum, I might be manually constructing transactions via cli. When i am going to work within the network, i am not just not bothered by the setup time, i want that full block chain. what you are talking about is great for many people, but to me it is like starting a painting with only red paint because i am too impatient to wait for all the colors to arrive. getting around a full block chain sync is bypassing some of the security of the ledger and i see no reason to do that. if i need an immediate solution and a full wallet, i will simply download electrum and the official bitcoin core and use electrum while the other syncs
what im saying is you get the cake and eat it.. imagine it as electrum and core combined.. a hybrid.. but the extra advantage of not neding electrums central server that way your still waiting for all the colors of the painting to download. but your not having to wait for red to download at the end because its given to you at the start. thus not needing 2 wallets thus not needing to copy and paste privkeys from one to the other. or spending the funds of one wallet to move it across.. its all one and the same it also wont rely on a electrum server.. it would download the color red from other full nodes on the network like it does with syncing. so it becomes better than electrum by not relying on electrums central server.. simply by downloading red first. rather than waiting to collate the data to get red last |
|
|
|
just a thought: someone who calls a non-consensus, centralized fork which was more like a dictatorship from the devs "a good thing" is obviously benefiting from it  The ethereum hardfork was bilateral, probably the only thing they did right--
Sadly, the proposals authors were aggressively against this.
|
|
|
|
I've seen people throw the quote around: "Great minds discuss ideas; average minds discuss events; small minds discuss people" when someone else starts using their chosen boogeymen as a punching bag in an attempt to make their point. So I suppose one possible solution to the issue is to create a hostile environment for the tribalist mindset to operate in.
Others have opted to take a more moderate stance and point out that "it's not about the people and what they might do, but about the code and what it does". You don't need to trust people, just trust consensus to enforce the code that provides the greatest benefit to the network as a whole. Vested minority interests can't prevail, because Bitcoin was specifically designed to prevent hostile takeovers.
Would these two approaches be things we can try? They should both keep the focus on ideas and not on the possible motives or agendas of certain individuals or groups.
the only issue is that the code does not create itself. devs create the code. so understanding the code they create is a priority. but understanding the motives of why they code that code instead of another code also has consequences. EG dont just sit on your hand accepting whatever code is put infront of you. find out why. and choose the code that doesnt end in everyone forced to use commercial hubs of permissioned contracts. or new features that bypass consensus. because thats just letting dominance occur by "trusting" code. thinking code is better than man, is blindly trusting the person that wrote it.. code is only as good as the person that wrote it |
|
|
|
It will, if people don't activate segwit, hard fork will be done, so soft fork like activating segwit is better than hard fork, hard fork will drive the price dump
People often worry about a dump in price before a hard fork, but if anything, people should be looking to secure as much coin as possible before a hard fork so that your coins are safely secured on both chains. Then, whichever chain is successful, you can't lose. Conversely, if you choose to buy coins immediately after a fork, you'll find many sellers would be looking to dump the coins on the chain they don't approve of, so it's unlikely they'll offer to sell you the coins on both chains. You'd have to carefully consider which chain to buy on. So people panic buying before the fork could offset anyone who doesn't understand this who might be panic selling out of fear. try not to use the umbrella term "hardfork" when you actually mean the subcategory of forks which is an intentional split.. because it confuses the sheep into thinking all hardforks=intentional splits even a soft fork can become an intentional split as gmaxwell himself explained with If there is some reason when the users of Bitcoin would rather have it activate at 90% ... then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.
|
|
|
|
i personnally am not bothered by the wait, i was just stating that, as of this moment, the only issue created by block chain size is the initial setup of full wallet, by this i am implying that there is no problem, as not many people need that full node on their pc. those that want to run the node should expect some time to be used. you want to start a new domain, you expect a possible 24 wait for DNS propagation. technical aspects to all project take longer than the standard use version
and my reply was that you can have the cake and eat it. rather than having the implementation useless until syncing. thus holding people up and the sync becomes not discrete and noticable enough to frustrate you can be a full node and not have to wait. simply by devs releasing a implementation that emulates a litenode instantly while it discretely syncs in the background, unnoticed because its no longer a hindrance to utility. |
|
|
|
It will, if people don't activate segwit, hard fork will be done, so soft fork like activating segwit is better than hard fork, hard fork will drive the price dump
consensus hardfork does not mean splitting the network. intentional split is not the default end result of a hardfork hardforks just leave the minority unsynced and stuck.. where by the sensible thing is to join the majority by upgrading with the majority and continue with the majority.. rather than be stuck in limbo.. however, opposers completely adamant to not join the majority.. can add additional code intentionally. additional code is then needed for the unsynced minority to ignore consensus, ignore the majority, ignore the orphans and start their own network. meaning they intentionally start their own chain and reboot their own syncing of new blocks from a different source than the majority. |
|
|
|
Ver wants Bitcoin to split by hardfork just like Etherium
that tweet was a question, not a statement. and it is actually gmaxwell that wants to split the network here i will spell it out for you. here is blockstream gmaxwell trying to get anyone not blockstream to fork away.. and they replied they wont be that dumb to intentionally split the network... and before you reply BullSh*t.. its from the horses mouth himself. 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-- even funnier.. gmaxwell also says he willing to intentionally split the chain just to implement the soft fork If there is some reason when the users of Bitcoin would rather have it activate at 90% ... then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.
|
|
|
|
|
as for the exponential vs linear.. its neither.
its not linear (straight diagonal line)
its not exponential (horizontal that curves vertically)
it IS an S-curve..
the issue is that we are still in the early days of bitcoin so we are still at the bottom section of the S-curve, so it appears like its exponential
only problem is that growth has been halted to not see the bigger picture
|
|
|
|
UPDATE ON YOUR REPLIES
1- BTC blockchain is not growing exponentially but linearly (but is still growing) This still can be discussed as blocksize increases by time.
2- BTC blockchain size shouldn't be an issue as storage capacity are high and will become even higher in future
3- The main issue is block size which if it become bigger and bigger, will not be able to be downloaded quickly enough by all nodes if the connection speed of those nodes is not high enough
referring to 3 the last time i installed a full wallet the download of the zipped block chain archive was a short download, but the amount of time it took the wallet to import the archive was nearly as long as it would have been to just let the wallet sync via linear download this is the only time is using bitcoin when there is a huge issue because the the size. i think it is just going to get to the point when fewer and fewer people choose that type of wallet. someone intentionally setting up a full node will have to deal with it referring to your frustration of setting up a full node. the reason your frustrated and many people are. is that while its setting up its not really 'usable' straight away, you cant see current balance and cant really spend anything until its synced.. right, thats the main frustration. this can be solved so easily. if the devs just got their implementation to not sync first then check unspents(utxo) second.. but instead grabbed some litewallet code that grabs unspent's data from other nodes first. and then done syncing second. the syncing then becomes just a background/unnoticeable thing. while the node is actually functional straight away. bam!. easy to code, lets users just get on with using bitcoin straight away. problem solved EG emulate electrum or other litewallets as soon as you open the node. then syncing is not a critical, thumb twiddling wait. its just a background function users dont realise is happening, because they are no longer forced to wait until synced before properly using it |
|
|
|
But he put himself in that position where he can be an easy target.
how? was it him saying he is happy to let blockstream do their LN(paypal2.0) if they let bitcoins mainnet dynamically grow. which then got lost in translating and fed to the wolves to vomit out as the opposite? |
|
|
|
update of my previous post which had graphical description of growth.. here is blockstreams Sheep (in red) impression of what they want to tell the world will happen if blockstream doesnt start its commercial service "1gb blocks by midnight" vs my opinion (in blue) of onchain natural dynamic scaling over the next 33 years  |
|
|
|
Perhaps because none of those things come even remotely close to 1 terabyte a month worth of uploading (which a stock Bitcoin node will happily do)?
If you are going to make comparisons to justify your position, at least make decent ones.
1tb a month lol ok.. uploading. 8gb/month to send live relay of tx's and new blocks. per connection for instance. 100 connections to fully synced node requires 800gb 10 connections to fully synced node requires 80gb as for helping other nodes sync. that is the killer data wise. 100 connections to 0 synced node(where your its only seed) requires 9.88tb (yea doom) 10 connections to 0 synced node(where your its only seed) requires 988gb (yea doom) 1 connections to 0 synced node(where your its only seed) requires 98.8gb (manageable) the solution.
dont have 100connections..
reduce the connections= reduce the data needed to upload.
especially dont connect to nodes that are not near/already synced.. thats the main trick.to emphasise this point.. if 75 nodes had 75 connections 5625nodes would get the data in 1 relay. so anything over 80 is overkill/not required. i can safely assume atleast 75 people have good internet. so not all 5600 nodes need to upload to that many. as the recipient probably already got the data via someone elses node. so if bandwidth is an issue.. bring your connections down. dont act like a 'supernode' if you are only an average node. this is also why blockstream are doing their 'fibre' (supernodes) so that they get the data out in one relay so that other nodes dont have to do all the work.. which means you can happily play '6 degrees of separation' with 6connections(48gb) just to relay tx data and blocks so the nod can get second opinions from other sources. |
|
|
|
But on the bitcoin side. I would support a hardfork now.
And a BTC hardfork would not split the network in 2 because BTC has a 2 week retarget, and no miner would mine on the minority chain for 2 weeks.
So the majority always wins. It could technically happen with 51%, but just for safety and less drama, let's say 70%.
So if 70% agrees to hardfork now, of a 2mb, then the other 30% will be outnumbered, and then they will later see that it was not a big deal.
It' will not split in 2 like Ethereum vs Eth classic.
to add to this point, (to help explain it) ethereum was NOT a consensus hard fork... it was a intentional split some call Ethereums split a controversial split hard fork some call Ethereums split an altcoin maker some call Ethereums split a bilateral fork.. but not a consensus hard fork.. because thats a different thing altogether (note: there's many forms of hard forks that have differing end results/goals/intentions. dont think harkfork=split. its an umbrella term for different possible results) but ethereum nodes intentionally avoided consensus by actually ignoring each others chain data (google: --oppose-dao-fork) thus causing an altcoin, by disconnecting opposing nodes. a consensus fork is ONE chain. where the minority dont create new blocks automatically. they are left orphaning what they dont like and never syncing. in the case of a 95% agreement. of say 5600 nodes... 5300 agree 300 dont... what then happens is pools then do a consensus vote of their own. which gives time for the 300 to upgrade... when pools get to their 95%. a grace period happens.. whereby both the 300nodes and 1pools not voting still have time to get onboard before being left unsynced and 'stuck'. ok.. you might be about to rebuttle that losing 1 pools and UNDER 300full nodes is bad,, but.. blockstreams soft fork can lose 1 pool too.. and, would currently have over 2000 nodes no longer at 'full validation status' and demoted to half validation status. |
|
|
|
When a miner is working on a block, it is trying to earn the block subsidy + transaction fees for its proposed block. It will abandon its attempt to find the hash for its proposed block if and only if it is provided with proof that another block spending some of the same transactions has been found. So when a potentially solved block is presented, it needs to validate that block. In the case of a block with excessive sig in a single transaction, this validation process will take an excessive amount of time (indeed, this is the supposed 'nightmare scenario' that makes quadratic hashing such a scary issue). So what is a miner to do? Stop everything, and devote all processing to validating the incoming potentially-solved block? Hell no. A rational miner will spawn off a single thread to validate the potentially-solved block, and devote the rest of its resources to trying to find the solution hash to its proposed block. Anything else would be self-defeating.
As all rational miners would engage in this process, it is likely that some miner will find an alternate block solution while is is still trying to validate the incoming possibly-good but large-sig-containing block solved by the first solving miner. It is free to propagate its solved block to the network at large.
Upon receiving such a block, rational miners will devote (e.g.) one thread to validating the new block - even as they are still trying to validate the first possibly-good but large-sig-containing block. Whichever is the first to be validated is the block which they will propagate and the block that they will build atop. This would be the second-arriving block that does not engender the quadratic hashing issue. The first solution block - containing the large sig transaction - gets orphaned. Problem goes away.
What, me worry?
i get what your thinking. and this has already been solved.. its the empty block concept, people still dont get. firstly. pool A solves a block hands it out.. lets say pool B receives it. immediately. pool B tells the asics. to start working on an empty block. (no tx apart from blockreward claim(coinbase tx)) because poolB does not know what tx's to add into blockB because its yet to validate blockA what happens is a pool can take upto 2 minutes to validate a block. (as long as its not got a super bloater 1mb tx) and so before validating a blockA to know what unconfirmed tx's remain in mempool to start adding to pool B's empty block, if blockB 'luckily' gets a solution then Block B looks 'empty'. obviously if BlockB is not solved after 2 minutes and if all is good with BlockA... poolB starts adding tx's from unconfirmed mempool to blockB and resending a hash to the ASICS to hash away at. this is why most 'empty' blocks are found within a couple minutes of the previous timestamp. because they are only mpty because they were luckily solved so quick .. now thats dealt with. instead of letting 1tx have 20,000sigops, letting it have say 500sigops max. means that we will never ever ever have a risk of it taking 10minutes to solve a block by someone having a 1mb tx. secondly pools can right now. in their own settings. without needing to get a consensus or an vote or permission. set their pool node to only allow tx's with < xxx sigops. and then those trying to send such clunky tx's will soon realise their tx's are not getting accepted. and will react accordingly (being more leaner with their tx's) thirdly making leaner tx's also helps more peoples tx get accepted. EG 2500tx's of 400bytes. instead of 1tx of 1mb leaving the sigops soo high, even when (lets say segwit activated) quadratics is not an issue. may save processing time.. but still allows a bloater to send a tx of 1mb. so reducing the sigop count of tx's should still be done anyway. so knowing it should be done anyway. we might aswell just do it. and solve the problem sooner. rather than waiting for segwit to not do a full job |
|
|
|
|
Show Posts
