Topic: How to notice occuring forks in an altcoin? (Read 454 times)
Pay attention to their bitcointalk thread, their slack and their website for the latest updates.
exactly, latency is a big issue i found. Maybe the cause of most forks. I've seen alts with 3 or 4 different chains going on at the same time, forks you could send coins between chains back and forth, blockexplorers on different chains and whatnot. I've seen coins break in many ways. I think it's due to latency very often.
Attacks do happen too. Look at megacoin. Its network was crippled for whatever reason. It never recovered because of that.
Knowing early when the coin you are holding starts to be defunct (mostly more problems occure after first problems show) could give you a decent edge imo.
Personally i think most altcoin blockchains have hickups at one point or anther.
Possible we've seen KGW fail too, i don't know.
Let's not even talk about POS, they fork all the time ... clams forked to death, PPC forked to death and so on ...
knowing in realtime when forks occure will be valuable info to a trader.
If someone of you coder-guys would write a good software for such detection i think that software could potentially sell for good prices around here... or host a website which shows data for many alts. You could earn a lot via advertisement on such a site imo.
Just an idea for you coders ... if you can deliver a working product for that you should be able to earn some money on that imo.
Traders are hungry for easily accessible realtime data. There is money in providing those services.
Attacks do happen too. Look at megacoin. Its network was crippled for whatever reason. It never recovered because of that.
Knowing early when the coin you are holding starts to be defunct (mostly more problems occure after first problems show) could give you a decent edge imo.
Personally i think most altcoin blockchains have hickups at one point or anther.
Possible we've seen KGW fail too, i don't know.
Let's not even talk about POS, they fork all the time ... clams forked to death, PPC forked to death and so on ...
knowing in realtime when forks occure will be valuable info to a trader.
If someone of you coder-guys would write a good software for such detection i think that software could potentially sell for good prices around here... or host a website which shows data for many alts. You could earn a lot via advertisement on such a site imo.
Just an idea for you coders ... if you can deliver a working product for that you should be able to earn some money on that imo.
Traders are hungry for easily accessible realtime data. There is money in providing those services.
There are no accidental forks mate, software doesn't accidentally update itself on different machines to create such forks, who would attack a blockchain
Unfortunately that isn't true, otherwise cryptocurrencies would be a much simpler technology than they are now. We would have no 51% attacks and no "Nothing at Stake" problem, so we could rely on the blockchain principle alone and would not need even "Proof(s) of Work" or "Proof(s) of Stake". It is a consequence (or better: an example) of the CAP theorem.
Accidental forks can happen if, for example, a region has higher latency with respect to nodes from other regions for a prolonged time. The "Great Firewall of China", for example, can lead to such situations. Or let's say we have a cryptocurrency with several users in Norway and others in Australia and nobody in-between. That would mean that nodes in one region can follow a certain fork for several blocks. If more hashpower is on the other chain, then, when the irregular situation ceases, there will be a reorganization and the whole fork will be orphaned.
This is more likely in Proof of Stake currencies because these have no objective "longest chain rule". Although even in these currencies, it is unlikely that a fork lasts for a long time if there is no ongoing attack.
@gustav: A correction to my previous post: -printblocktree only works in currencies based on older (<0.10) Bitcoin versions. There is however a RPC command called "getchaintips" that should show all chains. It does not even need debug.log. I however don't know in what Bitcoin version it was introduced and in what alt-currencies it is available.
There are no accidental forks mate, software doesn't accidentally update itself on different machines to create such forks, who would attack a blockchain
By forking it? they would achieve nothing because any chain small or big will always stay the same, attacks are by changing transactions in a block or
Doing a charge back of a large amount, if there is any coin that allows a miner or a pool to betray it's users like that you should avoid it. if a pool does
Attack the blockchain in a hostile manner all the honest pools must immediately fork and implement the necessary codes to stop the attacker from
Repeating the same attacks. moreover as 2 other misfits mentioned, when a chain forks the other chain becomes irrelevant to the main chain since
It's not the same coin with the same name. if you are worried about others cheating somehow by forking then clearly you still don't understand how
Blockchain technology works.
By forking it? they would achieve nothing because any chain small or big will always stay the same, attacks are by changing transactions in a block or
Doing a charge back of a large amount, if there is any coin that allows a miner or a pool to betray it's users like that you should avoid it. if a pool does
Attack the blockchain in a hostile manner all the honest pools must immediately fork and implement the necessary codes to stop the attacker from
Repeating the same attacks. moreover as 2 other misfits mentioned, when a chain forks the other chain becomes irrelevant to the main chain since
It's not the same coin with the same name. if you are worried about others cheating somehow by forking then clearly you still don't understand how
Blockchain technology works.
I'm not an expert, but that's how it should work:
Clients - at least those that are based on the Bitcoin design - detect all blocks (if the network is not partitioned) that are propagated in the network. Every block received should be announced in the debug.log file. So in the debug.log you would see if blocks are accepted on the chain where your client is "residing" or not.
So you can conclude that all blocks that are not accepted by your client belong to other chains (or are invalid because of other reasons). You should be able to collect their hashes from debug.log and follow the chain to its origin following the "hashPrevBlock" values. If you do that for all "not accepted" blocks, you should be able to detect all chains.
Maybe there is a script that could do that. It shouldn't be hard to code it.
(I just read here about the -printblocktree option. Haven't tried it, but that should do the trick - you would have to observe the debug.log then.)
Clients - at least those that are based on the Bitcoin design - detect all blocks (if the network is not partitioned) that are propagated in the network. Every block received should be announced in the debug.log file. So in the debug.log you would see if blocks are accepted on the chain where your client is "residing" or not.
So you can conclude that all blocks that are not accepted by your client belong to other chains (or are invalid because of other reasons). You should be able to collect their hashes from debug.log and follow the chain to its origin following the "hashPrevBlock" values. If you do that for all "not accepted" blocks, you should be able to detect all chains.
Maybe there is a script that could do that. It shouldn't be hard to code it.
(I just read here about the -printblocktree option. Haven't tried it, but that should do the trick - you would have to observe the debug.log then.)
This helps a lot. Thanks for pointing this out.
Maybe i didn't make it clear enough in the OP. I put in an edit.
I'm not an expert, but that's how it should work:
Clients - at least those that are based on the Bitcoin design - detect all blocks (if the network is not partitioned) that are propagated in the network. Every block received should be announced in the debug.log file. So in the debug.log you would see if blocks are accepted on the chain where your client is "residing" or not.
So you can conclude that all blocks that are not accepted by your client belong to other chains (or are invalid because of other reasons). You should be able to collect their hashes from debug.log and follow the chain to its origin following the "hashPrevBlock" values. If you do that for all "not accepted" blocks, you should be able to detect all chains.
Maybe there is a script that could do that. It shouldn't be hard to code it.
(I just read here about the -printblocktree option. Haven't tried it, but that should do the trick - you would have to observe the debug.log then.)
Clients - at least those that are based on the Bitcoin design - detect all blocks (if the network is not partitioned) that are propagated in the network. Every block received should be announced in the debug.log file. So in the debug.log you would see if blocks are accepted on the chain where your client is "residing" or not.
So you can conclude that all blocks that are not accepted by your client belong to other chains (or are invalid because of other reasons). You should be able to collect their hashes from debug.log and follow the chain to its origin following the "hashPrevBlock" values. If you do that for all "not accepted" blocks, you should be able to detect all chains.
Maybe there is a script that could do that. It shouldn't be hard to code it.
(I just read here about the -printblocktree option. Haven't tried it, but that should do the trick - you would have to observe the debug.log then.)
Why is an invisible fork interesting? Seems to me that would make it a private blockchain
Yes, go to GitHub and check if a coin had been forked, and if the said coin is not available on GitHub then why would you bother to even care about a centralized coin mate?
Specially a coin with a closed source. GitHub is the only trusted source to know such things.
Specially a coin with a closed source. GitHub is the only trusted source to know such things.
Altcoins fork sometimes due to various reasons.
I was wondering if there's a reliable method to detect how many chains for a coin are actively mined at a given moment in time? Anyone know of a good method of detecting this?
I was wondering if there's a reliable method to detect how many chains for a coin are actively mined at a given moment in time? Anyone know of a good method of detecting this?
it becomes apparent when people on one chain can suddenly not get transactions confirmed into the dominant chain.
To be honest, there is not so much forking these days, unless you do it to spawn bcc.
Altcoins fork sometimes due to various reasons.
I was wondering if there's a reliable method to detect how many chains for a coin are actively mined at a given moment in time? Anyone know of a good method of detecting this?
I was wondering if there's a reliable method to detect how many chains for a coin are actively mined at a given moment in time? Anyone know of a good method of detecting this?
They generally announce about the fork on the forum and their website.
There are no multiple chains for coin actively mined as when a chain is forked, it becomes a completely different coin.
Altcoins fork sometimes due to various reasons.
I was wondering if there's a reliable method to detect how many chains for a coin are actively mined at a given moment in time? Anyone know of a good method of detecting this?
edit for clarification: we're talking about unwanted forks not forks by the dev. The kind of forks that happen from attacks, code issues, hashrate fluctuation and whatnot. So not regular and announced forks but accidental forks.
I was wondering if there's a reliable method to detect how many chains for a coin are actively mined at a given moment in time? Anyone know of a good method of detecting this?
edit for clarification: we're talking about unwanted forks not forks by the dev. The kind of forks that happen from attacks, code issues, hashrate fluctuation and whatnot. So not regular and announced forks but accidental forks.
Jump to: