Topic: ToominCoin aka "Bitcoin_Classic" #R3KT - page 98. (Read 157137 times)

Let me tell you a piece of friendly advice, put him on your ignore list. He's very stubborn and ignorant. Even though he does not even understand the basic concepts, he thinks that he is always right (which, hilariously, is exactly the opposite of what is happening). It does not matter how many times you explain it to him, he will not admit to being wrong. I've wasted more than enough time on him and I hope that you don't.

It does not matter that much, and that is enough for now. If you want to get even more accurate readings then spread the word and ask people to vote. If not, don't complain.

No matter how many times you say it, it won't make 75% any sort of consensus. 75:25 is a network split.

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. a 2MB block under 2MB consensus is 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.


"get your act together ASAP or we're going to break bitcoin!" right....

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.

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

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

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

based on todays results.. the yellow line is now at 849

Nice chart. The stream blocking 1MB-PWC-Coin shows impressive momentum.

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

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 number of coins voting on even the most controversial topic represent around 1% of Bitcoin holdings and at most 60 individuals. Then there is the case that all those big ass block size increase votes are from linked addresses.

Whilst there is no way to count individual users, this is not really important. As there is a really good way to establish consensus. It's in the whitepaper. Everyone that is trying to reinvent the wheel probably ought to listen more and speak less.

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.

I always thought that Veritas was paid, but this has gone to a whole new level now. Dash had no pre-mine and there was "some" controversy with the launch? This is too much.

---

---

Interestingly as soon as their proposals get denied, and their controversial power grab gets rejected they start talking about doomsday scenarios.

A better investment would be send Bitcoins to dead addresses.

I.  Just.  Can't.

Ah, so we're talking about two different things. Sybil attacks don't imply incompatible consensus rules. I was talking about the lack of incentive a miner has to enforce a contentious hard fork because it would erode all trust in the system by creating multiple valid ledgers.

You're referring to specific double-spend attacks. Of course a miner will double-spend if he can profit by doing so. That's basic incentive. That's very different than miners intentionally running multiple incompatible versions to provoke a chain fork.


Non-mining nodes reflect the interests of non-mining users, serving as a check on the power of miners. By not trusting mining nodes and enforcing the protocol they are integral to the integrity of the p2p system. Without them, miners have simply replaced central banks -- they may be competing against each other, but they can also collude against the userbase. And if nodes are sufficiently centralized, miners are not the only concern; it becomes much easier for other actors to coordinate Sybil attacks (tx censorship, etc).


Sure, I don't rule out a bit of that. You could have said the same thing after the XT release -- fast jump in XT nodes, which quickly fizzled out to nothing. "Thermos is such a dictator, of course people are firing up Classic nodes!" isn't a measurable phenomenon, nor is it provable. Probably better to keep other possibilities in mind, especially considering this is basically a replay of the XT release.

Why?
Because:
"--The attacker can relay only blocks that he creates, putting you on a separate network. You're then open to double-spending attacks.
--If you rely on transactions with 0 confirmations, the attacker can just filter out certain transactions to execute a double-spending attack"
Sorry for retarded passive -> active voice jump, but that's the cringe factor of teh Bitcoin wiki 4U

Didn't you yourself suggest that the nodes are there as a means of stopping the miners from doing bullshit? Or was that Lauda?
How about *you* tell me why they're important to Bitcoin's security?


Sure, it matters how long attacking nodes stay up, because attackers are spending resources to do it. Like everything else in bitcoin, the system depends on incentives. The nature of an attack is to expend resources in the short term to realize bigger gains in the long term. That's why 5000-8000 Core nodes operating over the past two years are unlikely to be Sybils, and 800 Classic nodes spun up over the past week are more likely to be Sybils. The latter is bolstered by the fact that the majority of Classic nodes are "new" nodes, not existing nodes that switched from Core to Classic.