Topic: Stop fuckin' around, fork the son-of-a-bitch already. - page 4. (Read 9367 times)

It's not a matter of 'could' or 'could not', but rather a matter of "should" or "should not". I disagree with those limitations.

We're talking about Bitcoin, not a mutable shitcoin.

This argument has no relevance to what I said. You don't know how long it takes for those "intermediaries" to upgrade and test their custom implementations (hint: 28 days is ridiculous).

A minimum of 2x increase is "marginal"?

You can't know this. Example: I have to upgrade my node soon due to inadequate amount of storage on it.

---

Oh, and I forgot to mention that in case something goes wrong with your datadir (if you use Core as a wallet for example), you will spend a ridiculous amount of time fixing it with absurd block size proposals.

1) You could limit the transaction size while still increasing the blocksize.
2) ETH did fine.
3) Few shops actually directly accept bitcoin without an intermediary. Those intermediaries should be bitcoin-savvy enough to prevent damage to the merchants. Those merchants that do accept bitcoin directly probably know enough about it as well.
4 & 5) The increased costs is only marginal. Most people already have internet that can easily support much bigger blocks than 1MB, both upload and download, without even affecting regular browsing behavior. And most people have plenty of room on their hard disks, even if they don't a 1TB hard disk will go a long way (lasts for 19 years with 1MB blocksizes assuming they are all full and are never once pruned in those 19 years). So obviously there is room for significant improvement without being cost-prohibitive to most people. In fact, a vast majorty of people wouldn't even notice the effect.

lets put it into a scenario you may understand.

town rules.. the town shouldnt have more than a 32bedroom house because outside of town it can cause highway congestion(internet packet loss/delay), aswell as inside the town(bitcoin network) by logical default

now there are several neighbourhood councils(implementations) within the town(bitcoin network) with their own rules below the town rules.

old satoshi QT 1 bedroom houses but only half the room can be used due to a db bug infestation
old core council 1 bedroom houses
new core council 1 bedroom houses with a 3 bed mobile-home on the drive for parents(signatures) to sleep, possibility of 2 bedroom houses next year
BU council want people to choose but are highlighting the town rules by lowering the town rule threshold. while still allowing preference below it
other council want 2 bedroom houses, with hope that later the rule can be consensually changed again (in years, like an oliver twist' please sir can i have some more')

all council rules are WAY way way below the town rules, because although the town rules are in regards to outside town issues, the neighbourhood council are worried about immigrants over population (spam), local road delays (transaction bottlenecking within bitcoin), costs of maintaining the house ($200 hard drives)

im not talking about node operators (the human) im talking about the demographic/category of nodes.. mining nodes vs user nodes
but atleast now your admitting that the distribution of non-mining nodes has an important job as part of the network.

and it seems you have failed to understand BU.
the 16mb safetly number, is the same as cores 32mb safety number..

then below those safety numbers:
BU has a dynamic mechanism for preferential buffer
core has a fixed preferential buffer of 1mb for 0.12 and 1mb base 4mbweight for 0.13

oops did you forget cores 32mb limit, well then
 
but have a nice day,

P.S
the 16mb explicit cap and cores 32mb explicit cap. have nothing to do with the preferential blocksizes the consensus should work at, but to do with a secondary safeguard in relation to issues with data packet sizes and other issues regarding the internet as a whole (beyond bitcoins control)

 i laugh at your mindset
'big blockers want 2mb'  ........ (core wants 4mb)
'big blockers have a secondary barrier of 16mb'     (core has 32mb)

easy maths question.
2 and 16.... or 4 and 32. which is perceived as the real big blockers?

That's not the definition of a user. It's one thing to be a user, and another one to be a node operator.

You don't say?

You've guessed wrong, yet again. If I thought that decentralization didn't matter, then I'd be proposing ridiculous block sizes like those BU lunatics.

"users" refers to nodes that are not mining. not the physically breathing and eating and pooping human at the computer
also its the nodes that do the validating, that could lose a miner alot of income if the miner jumped first and made blocks that other pools reject and users full nodes reject.. so they do care about users nodes.
EG imagine if no merchant/exchange was using the same rules as the miner.. the miner cant then spend their income.
think about it. in a waking reality.

wait..
let me guess your subtly hinting that the node decentralization doesnt matter and you think that 6000 nodes is irrelevant and we should just have 1 node? or wil you backtrack and admit that the nodes do an important job.

Miners don't care about the situation with the node count and they should not be interested it. The number of nodes in a small period of time is a horrible metric as it can be easily manipulated.

Ad hominem & no argument once again.

Again, the "users" that run nodes are a small minority. There's no way to properly "wait for users" as there's no way to "measure these users".

no wonder you have your fingers in your ears.. its digging all the grit out from sticking your head in the sand.

seems you forget what happens after the grace period.
when miners see users are ready users are then happy to accept 2mb blocks, but still only receive 1mb blocks, because...

miners have to be satisfied their competitors dont disregard thieir blocks
so when miners are then satisfied that atleast OVER 95% of user nodes have the rules ready... then the miners do their own flagging and consensus mechanism over another block measure to show a 95% of miners are happy

seriously wake up to reality and join the conversation, get out of the fantasy doomsday nightmare that is not reality and start thinking rationally about how things will work in the real world.

miners wont jump first, they will wait for users.
even when users are ready, miners wont jump unless they see other miners also consent, that way the orphan risk is low (around 0-5%, same as any other day where we are seeing small % orphans a eachday)

No. You have no idea what you're talking about. The "95%" is regarding the hashrate supporting the proposal, not the number of nodes supporting it. If it were up to the number of nodes, one could easily disrupt this by creating a ton of AWS nodes using an older version. Once again, you have no idea what you're talking about.

let me guess you have on many times suggested consensual parameters that are acceptable... but you are now pretending that instead you imagine the parameters have to be some different and lower doomsday parameter and 28 day grace just to make your newest doomsday argument your creating plausible.


again.. the 95% does not trigger until 5700 have reviewed code, tested it and happy to run it..
this could take days-weeks-months before we start to see people using it. and longer before there is a clear 95% stable and constant use of it that meets a stable/constant use parameter of lets say 1000-10000 block measure of constant 95%.

then after that (which itself may take months to get to that point) there is also a further grace period.

this is not to say the 95% trigger is time locked to activate next week
this is not to say the 95% trigger is going to happen at any predictable time at all..
it will happen if and when 95% have done all the checks and tests and run the code for a length of time

The number of nodes has nothing to do with the size of the infrastructure of a singular business. They can be fine running 1 node, or even running none. In addition to that, just because Core has updated to 0.xx.xx that does not mean that a business, running a custom implementation can update within a particular time frame.

Pure ad hominem. While the first statement is correct, as I don't do "C++", the secondary is false. In addition to that, not knowing a programming language has nothing to do with the argument that I'm creating.

This is all completely false, and useless to read. The number of nodes updating has nothing to do with HF activation parameters.

Said the person attempting to undermine someone's argument with pure ad hominem, in addition to lacking the same knowledge yourself.

grand scale?
theres only 6000 nodes..not 600k, not 6mill, not 6 billion... just 6000 (which only ~ 5500 are active at any one time)

and by the way, you yourself dont even know C++* and a few other languages, you have been proven to lack understanding of programming on many occasions. and now you pretend to think you are an expert about the ability of just 300 people upgrading in 6 months

here is some lessons about the 6000 nodes
1. 5700 nodes would be upgraded just to trigger the 95% benchmark
this trigger wont occur tomorrow. it would occur AFTER 95% of the community get a chance to review the code, run the code, see its ok, and then be part of the consensus process.
which would require all 5700 to be running the vetted and checked software at the same point for a certain period.

2. 300 nodes (5%) then have 2-6months to move across, to give them a little more time to vet and check the software.
again its not some BIG billion different computers that need to be upgraded.. essentially the grace period is just waiting for 300 nodes..

but here is the funny part.
all 6000 full nodes are running as full nodes instead lite nodes for a reason. so its not like they dont care about bitcoin. they will want to stay relevant and part of the validation process, otherwise they would have stopped running their full node and just done something like setup a blockchain.info account. or downloaded multibit instead. and not be part of the network.

but because they are obviously a full node, they will obviously be more alert to things going on in bitcoin and so be a little bit more proactive then you presume people running nodes are.

*i refrained from embarrassing you by quoting your admissions of lack of programming knowledge. im sure you remember me quoting them before

No. The 3 people that you've listed have no connection to each other whatsoever.

Pretty much everyone reasonable, and non delusional is currently supporting Core.

Not an argument, but rather ad hominem.

Irrelevant.

That's because someone like you, who's knowledge is obviously limited, does not understand the deployment of new software on large scale businesses. You'd probably be fine with a 28d grace period.

seems like people are still confused and use ethereum as a domsday for bitcoin.

a consensual vote for changes to bitcoin can happen, it wont cause a second coin because orphans will take care of the minority that didnt upgrade.
things like a 1000 block voting period to get 95% of nodes ready.. and a 2-6month grace also helps the remaining 5% get ready
thus affecting well under 5% when finally activated

as for ethereums controversial split. this was not simply changing the rules.. because as i said orphans would sort out the minority after activation
ethereum INTENTIONALLY chose to make an altcoin
reference:
meaning orphans wouldnt ever have settled a winning chain and killing off the other.

this is because the reference literally blacklisted nodes apart depending on which chain they wanted and ensured they didnt orphan each other out by ensuring they didnt talk to each other.

in short: changing the rules creates orphans, blacklisting nodes creates alts.

remember in a consensual upgrade, it requires 95% to upgrade BEFORE the grace period rolls.
if it doesnt get 95% the grace period doesnt start meaning nothing changes.

changes only happen if the majority want it and then even at 95% vote extra time is given for those reluctant few to realise they will be left orphaning blocks. thus that 5% will upgrade too(eventually)

if you want to create a intentional bitcoin fork you need a blacklisting feature to ensure the two opposing rules dont orphan the minority, because they are not communicating to be able to

I suppose that is why I now support splitting the chain, the alternative chain would simply have alternative clients that support it, solving the replay attack on both networks. I think that you are correct in thinking that a non controversial hard fork is no longer possible unless it is done through Core, who seem unlikely to increase the blocksize limit anytime soon. Therefore the only solution for people like myself who prefer that Bitcoin stays true to the original vision of Satoshi, is splitting the chain, after all Satoshi was a big blockist as well.

---

Ethereum presently has the same consensus mechanism as Bitcoin, users can choose to use Ethereum Classic instead, this is what gives people the freedom of choice, that is part of the consensus mechanism of Bitcoin as well and soon this will happen to the Bitcoin network as well.

Exactly, a confused user base does not change the fact that investors are still protected under such a mechanism. Not everything is in the whitepaper, but the consequences and reality of the rules that exists are within the code and the world for all to see. Because this is possible, it should be considered as part of the design of Bitcoin itself and considered inevitable from happening, especially considering the nature of human behavior.

On the contrary, I think that's the whole point. A highly centralized community (perhaps a small community with a "benevolent dictator") could likely pull off a hard fork very easily. A highly decentralized network agrees on only one thing---the consensus rules that every node enforces. They demonstrate consent to those rules by joining the network and running nodes.

The idea that every user in a highly decentralized system is going to agree to change those rules---that's a long shot. The only context I see that working in is where there is a protocol flaw/failure.

I think ultimately, decentralising bitcoin has made it difficult to reach consensus. Bit ironic don't you think?

That's not true. If Classic merges an update to change transaction format (not just add a new transaction format), it will be true for Classic. XT and Unlimited offer no replay protection. This is actually not just a technical issue---many that believe that a clean hard fork (one network) is possible don't want explicit replay protection because it promotes the idea that multiple blockchains will emerge. This was partially why Ethereum did not include replay protection in their fork; they simply assumed the original chain would die. The very idea of including replay protection in a fork is to make both networks viable (i.e. to enforce a network split). In the past, Gavin became quite upset at the suggestion that a hard fork could split the network---I'm curious about his thoughts on this.

Part of the problem in Ethereum is the heavily centralized development under the Ethereum Foundation, which has no public review/consensus mechanism. Vitalik said "let's fork" so mining pool admins ignored their miners, client developers forked their clients by default (no user choice whatsoever) and the fork came from the top-down. This makes user consent very difficult to gauge. Even in this context, Ethereum could not successfully hard fork.


Within a particular network, there has not been inflation, but you need to consider public perception and a confused userbase deciding among multiple networks, each with a supply of 21 million BTC. Again, I wonder if you could point to the protocol documentation or description from the whitepaper that suggests that breaking the consensus rules are "a crucial part of the governance mechanism"? Like I said, go ahead and fork....just don't be surprised when no one refers to your fork as Bitcoin.

Seems like mindless fear to me, the replay attack has been fixed on all of the proposed Bitcoin forks, it is rather trivial to fix actually. The ethereum foundation purposely decided not to fix this particular issue, I thought that was a mistake. Splitting Bitcoin as a minority would not cause such problems at all, custodians also need to be more responsible in such a situation and take it into account. Some of those custodians simply just did not believe ETC would survive, now we know better.

Splitting the network does not worsen Bitcoins value proposition, since the share of total Bitcoins remains the same across all chains for investors, which means it does not create any type of monetary inflation, it protects the value of investors. Furthermore because it is already relatively easy to do this with a small minority it should already be a part of Bitcoins value proposition, if you are not taking this feature into account you are not truly evaluating the value of Bitcoin, for me it actually improves the value proposition of Bitcoin since I perceive this feature as being a crucial part of the governance mechanism.

That you refer to us as "religious" shows how biased you are. I could say the very same of you---so obsessed with the idea of hard forking when there are far less risky and more ethical options.


If a fork is miner-activated, this is economic coercion to thwart user consent. Consensus (and breaking consensus, i.e. hard forking) concern ethical issues like this:


http://cointimes.tech/2016/08/hard-forks-and-consensus-networks-meta-questions-and-limitations/#comments

I don't think it is "mindless fear" to point to Ethereum's failed hard fork and point out that it permanently split the network. This caused significant losses for custodians---Coinbase lost ETC and still hasn't repaid their customers. BTC-E was replay attacked and lost all of their customers' ETC; they won't be repaying it. The results would have been disastrous if Kraken and Poloniex didn't have the foresight to ignore the Ethereum Foundation's advice to ignore ETC and not repay their customers their money. Replay attacks were commonplace, and many users lost money in trying to spend on only one chain or the other. Bitcoin is actually in a far worse position for this than Ethereum---no one uses Ethereum for virtually anything. It's a bloatchain full of "hello, world." It's hardly used for merchant payments, cross-border payments, and there is hardly an economy to speak of. The losses incurred by users and custodians in a failed Bitcoin hard fork could be far worse than in Ethereum. Further, Ethereum doesn't even have a finite supply limit (and is widely viewed not as a store of value). The effects of splitting the Bitcoin network and increasing the supply of "bitcoins" across multiple blockchains could be far worse for Bitcoin's value proposition than a network split in Ethereum.

The sigops issue is a DOS attack vector. For example, a malicious miner can essentially force the network to get collectively stuck validating a single block for many minutes. Here's the worst at 1MB: https://www.reddit.com/r/Bitcoin/comments/3cgft7/largest_transaction_ever_mined_999657_kb_consumes/csvahzn

Forcing increased throughput on nodes without backward compatibility is a node centralization issue: https://bitcointalksearch.org/topic/m.13915026

Forcing increased throughput on miners without effective latency mitigation is a miner centralization issue: https://www.reddit.com/r/bitcoin_devlist/comments/3bsvm9/mining_centralization_pressure_from_nonuniform/

More generally, I support demand for block space outpacing capacity, to prevent the worst-case scenarios concerning ineffective fee markets: https://botbot.me/freenode/bitcoin-wizards/2015-08-25/?msg=48126773&page=3

Storage costs are a concern as well in the context of unlimited block size, but a lesser one. But the general point is that increasing resource usage without scaling mechanisms makes nodes and miners drop off the network. So if we are dead set on increasing capacity, we should do it in a backward compatible way. This has the added benefit of not splitting the network.....