Bitcoin Forum
December 15, 2017, 08:50:19 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: How to notice occuring forks in an altcoin?  (Read 329 times)
gustav
Hero Member
*****
Offline Offline

Activity: 602


View Profile
August 24, 2017, 12:46:44 AM
 #1

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.
1513327819
Hero Member
*
Offline Offline

Posts: 1513327819

View Profile Personal Message (Offline)

Ignore
1513327819
Reply with quote  #2

1513327819
Report to moderator
1513327819
Hero Member
*
Offline Offline

Posts: 1513327819

View Profile Personal Message (Offline)

Ignore
1513327819
Reply with quote  #2

1513327819
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1513327819
Hero Member
*
Offline Offline

Posts: 1513327819

View Profile Personal Message (Offline)

Ignore
1513327819
Reply with quote  #2

1513327819
Report to moderator
1513327819
Hero Member
*
Offline Offline

Posts: 1513327819

View Profile Personal Message (Offline)

Ignore
1513327819
Reply with quote  #2

1513327819
Report to moderator
kingcolex
Legendary
*
Offline Offline

Activity: 1316



View Profile
August 24, 2017, 12:50:23 AM
 #2

You could always build a database and add announcements with which coin they are forking from. If you are asking if there is a way to actively know if a coin has been forked without the fork author telling you, then no.

Tipstar
Full Member
***
Offline Offline

Activity: 210


View Profile
August 24, 2017, 12:50:49 AM
 #3

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?


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.

▂▂▃▃  TRADE CRYPTOCURRENCIES | INDEXES | FUNDS ▃▃▂▂
●▬●▬●▬●▬●▬●▬●▬●▬●▬●▬●▬● BITOTAL.COM ●▬●▬●▬●▬●▬●▬●▬●▬●▬●▬●▬●
░▒▓█ DEPOSIT BONUS | 0% TRADE FEES | WIDE COIN OFFER | EXCLUSIVE ICO'S █▓▒░
veins11
Member
**
Offline Offline

Activity: 60


View Profile
August 24, 2017, 01:14:28 AM
 #4

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?


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.
freebutcaged
Hero Member
*****
Offline Offline

Activity: 490


View Profile
August 24, 2017, 01:14:58 AM
 #5

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.
satoshforever
Member
**
Offline Offline

Activity: 84


View Profile
August 24, 2017, 01:15:49 AM
 #6

Why is an invisible fork interesting? Seems to me that would make it a private blockchain
d5000
Legendary
*
Offline Offline

Activity: 1582



View Profile
August 24, 2017, 01:56:26 AM
 #7

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.)

       ▀
   ▄▄▄   ▄▀
   ███ ▄▄▄▄  ██
       ████
    ▄  ▀▀▀▀
▄▄
      ██    ▀▀
██▄█▄▄▄████████
▄▄▄▄▄▄▄▄▀▀███▀▀▀
██████████████████
████▄▀▄▀▄▀███▀▀▀▀▀
████▄▀▄▀▄▀███ ▀
████▄▀▄▀▄▀████████
▀█████████████████
]
,CoinPayments,
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
gustav
Hero Member
*****
Offline Offline

Activity: 602


View Profile
August 24, 2017, 02:50:49 AM
 #8

Maybe i didn't make it clear enough in the OP. I put in an edit.
gustav
Hero Member
*****
Offline Offline

Activity: 602


View Profile
August 24, 2017, 02:55:01 AM
 #9

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.)

This helps a lot. Thanks for pointing this out.
freebutcaged
Hero Member
*****
Offline Offline

Activity: 490


View Profile
August 24, 2017, 05:52:08 AM
 #10

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.
d5000
Legendary
*
Offline Offline

Activity: 1582



View Profile
August 24, 2017, 06:04:26 AM
 #11

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.

       ▀
   ▄▄▄   ▄▀
   ███ ▄▄▄▄  ██
       ████
    ▄  ▀▀▀▀
▄▄
      ██    ▀▀
██▄█▄▄▄████████
▄▄▄▄▄▄▄▄▀▀███▀▀▀
██████████████████
████▄▀▄▀▄▀███▀▀▀▀▀
████▄▀▄▀▄▀███ ▀
████▄▀▄▀▄▀████████
▀█████████████████
]
,CoinPayments,
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
█████
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████ ██
█████
gustav
Hero Member
*****
Offline Offline

Activity: 602


View Profile
August 24, 2017, 05:58:48 PM
 #12

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.
olliejjc16
Full Member
***
Offline Offline

Activity: 147


View Profile
August 24, 2017, 07:20:23 PM
 #13

Pay attention to their bitcointalk thread, their slack and their website for the latest updates.

████→→       ● DeepOnion                                                                       ✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯ 
████→→       ● Tor integrated, 100% anonymous!                                       Get Your FREE Coins NOW!     
████→→       ● Free Airdrop! (No ICO, No Crowdfund)                       ✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯✯
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!