Add Bitkubchain Mainnet #1629
Add Bitkubchain Mainnet #1629
Conversation
|
@ligi sorry, I want to know what the average time for pull request review or any progress? |
|
This PR has no activity in a while - it will be closed soon. |
|
@ligi can you provide some assistance toward this request? |
There was a problem hiding this comment.
tl;dr: it is now required to put the binary icon into iconDownload
why: it was a PITA to always ipfs get in the review process - sometimes it takes really long or even fails (especially with pinata) - this took significant time (which adds up with the amount of chains added) and slowed down the review process. Also sometimes CIDs become unavailable after - big mess. Hence it is now required to put them in iconDownload (still named via CID)
|
Chain Id 96 is already in use for next smart chain, it will conflict. You can use another chain id for the mainnet. |
|
Before next smart chain we run on another blockchain which is even older. I will send proof of this genesis block. |
this would help - then this is likely not to be merged here - except for the Testnet - @ppanya - please split in this case |
|
would like @dcnl1980 to share the proof of genesis block here so thats can be right for @ligi to consider in this case. Some of my opinion: if there is another blockchain with older genesis block using chain id 96, isn't it need to change into that name of the blockchain? tbh if chain id 96 will be submitted as a NEXT Smart Chain, Bitkub Chain has the right to claim this due to the older genesis block. |
|
on top of that, next smart chain currently have around 25.9K blocks with 5,342 transactions while Bitkub Chain exceeded 10M blocks with total transaction of 339M as of now. Isn't it suitable for NEXT Smart Chain to be the one who change the chain ID? for comparison: |
|
@ligi gentle follow-up for your consideration to this case |
|
@dcnl1980 plese send the proof - otherwise I need to merge this one (but it for sure needs |
|
@ligi Proof will be send later today. |
In the attachment you find the proof of the old blockchain, which we run before NEXT Smart Chain and which have the same Chain ID 96. The genesis block was mined with timestamp 1555502400, which is Wed Apr 17 2019 12:00:00 GMT+0000. NEXT itself has been active in the market since October 2017.
Regarding the above I want to object that the amount of blocks or transactions per blockchain can be different, the old NEXT Chain had over 1,8M blocks, but the new NEXT Smart Chain (more efficient) only creates blocks when transactions are actually performed and not every few seconds like BitKub does. Thinking in solutions. I have no problem with both names being listed under Chain ID 96 (if possible). It would solve both problems. Changing a chain ID for a running public and operative blockchain is almost impossible without starting a new one.
|
|
I'm not quite sure if the proof you provide is valid or not, is it right to use this proof of old blockchain (inactive or currently active?) as an authority to chain id 96 is not suitable at all as I mentioned in my thought above. Also speaking of the discussion on the genesis block on the current NEXT Smart Chain, we didn't ask for NSC to change your chain ID as you said before but we only need the right the be presenting as the only blockchain on chain ID 96 user's search @ligi please considerately suggest in this case whether it's right to use the old blockchain genesis block (which is unknown for the current status) to claim the authority to represent the new chain which is younger than Bitkub Chain. |
|
@ppanya please add |
|
@ligi why this should not be a proof, this block chain is still active and much older than Bitkub, so we should overrule them. We even did not know the existence of Bitkub when we choose the chain is, why we should if we have older rights? We checked your website and 96 was available. We could also turn it around, why Bitkub did not register it 2 years ago? Anyway we are not agreeing, where can we make objection about this? |
|
I do not think it is enough proof yet - this screenshot is trivial to create. Doing a chain with blockexplorer is at least a bit harder - but yea I know it can also easily be faked (at least for non PoW chains) - but so could the other chain be. But to not be in the situation again I now changing the policy: |
|
I think it's good to change the policy, to first come, first serve, like domain names. We did our research but it's impossible to find another blockchain which was using chain id 96. Now it appears that somebody else is using it also and this is making big issues. I also understand that you don't think it's enough proof yet, but if we put our block explorer online, it will be a total different story. If needed we will do, since we refuse that somebody else is claiming chain ID 96. We deployed this old chain years ago. If we need to overrule BitKub, we will, but it don't need to end up into a fight. Also they are using NEXT in their Bitkub NEXT, which we already release in 2017. I see them as a copycat in this case. So can you agree with it, if we proof and launch our blockchain explorer, a serious issue will appear? In this case, are you agree that we will takeover chain ID 96 again? |
|
After Explorer and RPC stand the trial of some tests I will close this PR |
|
Got it, but this was the previous blockchain after it was merged to another one. So we need time to put the old explorer online (since we take it offline). Anyway you can push Bitkub further. In a later stage I will come back to overrule them by this older blockchain. In that case I want to make sure that it will not make any issue. This change will be just temporary. |
|
May I ask for the estimate time of merging this PR? Still disagree from the very start that using the old blockchain to claim the authority while the actual use is the new one while comparing to ours are older, with current state of situation is totally unacceptable to bring that up. Also just want to clarify that the performance and reliability stays in the blockchain, its all provable whether for total wallet address, numbers of project, and numerous partners with bitkub. |
|
@macvts make it clear. We have all the right to bring the old blockchain up. You had to register it a long time ago. You awake after 2 years to claim chain id 96, while we are in the market since 2017, that is a fact. You also called it Bitkub NEXT, so it can be also a trade mark issue as well. Our blockchain will overrule the one which you have if we put the explorer online. You have no right to take chain 96 at all. You are trying to suggest that your blockchain have more transactions, but that is also not a valid proof. Reject this Bitkub thing, on the first serve, first come. We are already in the market since 2017. It is not our mistake that Bitkub comes with a claim after several years. |
on the other side of your fact, NSC is the one who starts splitting into new blockchain to restart the whole structure (younger genesis block) which you should be aware of the collision policy that the oldest genesis block will have the authority toward the chain ID 96 and now you resisting while trying to use your no-use blockchain (or maybe unknown) to claim the authority instead. FYI @ligi currently to the case, we're considering while the policy with the oldest to win and some info that might be useful before any slander to anyone with a trademark issue @dcnl1980 |
|
@macvts we have the rights to upgrade our blockchain, I don’t see any issues in that. Even with our older blockchain (which is still operational and in use) we are much older than BitKub. |
|
any upgrade (or hardfork) while shifting the data from the old blockchain ≠ splitting to the new blockchain where you choose to start a new one (with the same Chain ID) I'd rather not debate to make ligi feel more suffer to this situation and will looking forward to the decision and willing to accept this with the policy (oldest genesis win) that we'd been starting on the discussion here. I and Bitkub Chain Team hope this PR will be considered to be merged since we also quietly wait for NSC to prove themselves for a week and they're not responding until we follow things up and to finish off this policy afterward. 🙇🏻♂️ |
|
I am very much leaning this way after thinking about it for a while:
|
|
will totally respect your decision, I also hope somehow that this could be work for Bitkub Chain since we never go against any rule or cause any issue from the very beginning. |
Gentle follow-up for the direction of the case, I genuinely provide a total of 3 weeks for NSC to provide proof to support their authority. probably want this to be fairly considered from the beginning of the discussion with the past policy that just recently changed due to the confliction of this case. @ligi |
|
Not sure what the issue is. We are still the oldest chain for over a few years. It is not our issue that BitKub did not register their ChainID on time. We check your website and it was available. Secondary we are still the old blockchain which can overrule BitKub by being the oldest. This chain is still online and if needed we will release the explorer to prove it, but it will take some time, since the old chain is depreciated. So I would like to make sure and agree with you that we can claim this id, if we are the oldest chain, not that you are changing the rules in between. At all we will not change our id at all and keep running on chain id 96. |
|
@dcnl1980 so far you did not provide proof - you where asked to provide provide explorer and RPC multiple times - and you did not. |
as already stated, the current blockchain is an update of a much older blockchain (older than BitKub) which is set to chain id 96, however this old blockchain is still operational. As mentioned by you I will reserve the right to claim chain id 96 in a later stage, when the RPC and explorer are online. |
|
Wondering how the old chain is still operational when you cannot provide me with an RPC. If the chain is still operational it should not take long to just expose an RPC of a node. |
We disable the public RPC and explorer, but there are still miners active on this network which are directly connected on their own RPC node interface. A reply attack is not possible, each blockchain have another consensus protocol. We choose to continue with the chain id since we defined it before in the genesis file and it is most logical since our customers are connected to it with their clients. Anyway we hoped we did not had to open the public rpc and explorer again, but we are forced to do so. I asked the devs to put it back, after that is done, I will come back to claim chain id 96. |
how exactly does the consensus protocol change prevent replay attacks? |
|
will this PR be considered in any scenario in the future? or @ligi will only wait for their answer to re-add or no one get this chain ID? |
|
yea - will likely be merged as @dcnl1980 is not answering anymore - so seems the case is leaning on your side now. But u need to rebase or merge to master |
Added Bitkub Chain, Replace Next Smart Chain (Old chain same chain id: 96)
Detail Genesis Block Next Smart chain: Block 0