Topic: deleted - page 31. (Read 68074 times)

8.2 has been released.

We have migrated completely to the new network ID.

A new feature is being worked on....

Thank you for the pool!

Hi,

Here is a pool: http://coinspool.cu.cc/info_bigcoin

Feel free to use it

Elbandi

Follow on twitter.

@bigcoin_huge

Announced in reddit --

http://www.reddit.com/r/CryptoCurrency/comments/2n52mz/huge_bigcoin_abf_edrv2_scalable_most_responsive/

Version 8.1 of the wallet has been released.

There's a 4X block rewards between blocks 310160 and 311160.

Few more advantages added --

Less orphans

Responsive difficulty retarget algorithm means there are less orphans and so less chances of an accidental fork.

Changing block reward/plans

After releasing a coin, devs usually realize the mistakes they have made when it comes to block rewards and other things. They cannot act on it frequently cause the changes require a hardfork, but we can.

After the main mining is finished, we can change inflation rates depending on situation (prices, network hash rate etc...).

Cause of response from allcrypt, we've introduced policies for hardfork schedule.

A new wallet will be released minimum of 14 days (41000 blocks) before the expiry of the current wallet. This way notices can be issued to servers running BIGcoin.
Minimum life of the wallet will be 22 days or 64000 blocks.

WRONG.

You just need to rename .HardForkCoin to .BIGcoin before stating BIGcoind.

And also rename. .HardForkCoin.conf to BIGcoin.conf

Any user that has HardForkCoin (HFC) deposited on AllCrypt - you have 2 days to withdraw it or your coins will be lost. We were just notified we have 2 days to not only upgrade the code, but to rename the coin, change the symbol, change the data directory, re-download the blockchain, and completely revamp our database to accommodate it.

Two days is nowhere near enough time to get all that done for a coin that's been hosted on AllCrypt for almost 3 weeks with absolutely zero trade volume or interest.

A total removal of all HFC, and then just adding BIGCoin as a new coin is infinitely less work and does not put our dev team under pressure to get all this work done with next to no notice.

This has been renamed to BIGcoin (HUGE).

There is no longest chain here.

The blocks from the old wallet are not broadcasted by the new client using the pchmessagestart as stored in those blocks.

I still don't get your 80% rule. If there's a forked chain, the total difficulty is used to calculate the score of each chain.


There is no problem reindexing, except the fact that the old blocks will not considered by the client. They'll be redownloaded.


How did you do that? (I'm an admin, so I deserve the answer).


There's a bug in the wallet where there are too many transactions. The devs say they'll fix it someday. I'll backport the patch to the blake wallet.


But they wont function. So no chance of fork. Besides on a unix like systems, there's no way you can update the binary code automatically as per program specifications unless Windows-like insecure ways are incorporated.


That's pointless. Visa/Mastercard is better.


Yes, we got ideas. That'll be in the far future cause it's rather complex to implement.

Thanks for the discussion.

I did announce and people switched to new wallet was all done in less than 2 hours lol  

in fact most of us spent more time backing up and preparing for the change that when it was released was quite a let down as nothing much changed reorg was about 10-15 mins (longest chain 80% rule)

there was no problem either reindexing or starting a fresh wallet or clearing the chain data it did not make any difference(as far as I remember this was last year) it was only important on the seed nodes to keep chain data as that is still the block source, pchMessageStart is in the sending e.g messages over the network  

when the seed nodes with old chain data sent the chain data to new nodes it used the new pchMessageStart not the old one its like a handshake id between the clients to establish which network the following message belongs to

in such small networks like BLC/HFC you still have seed nodes so you may think its decentralized but the fact is that without a good set of dedicated nodes people have issues getting block source so its not entirely decentralized after scanning your network a few days ago could only find 11 nodes total!

the best way for a corrupt wallet rebuilding is pywallet as all wallets can and do get corrupted at some point even on bitcoin and -salvagewallet does not always work Fact!

getting in contact with pool ops was not easy even when the pools are down for days so my guess is that you will get pools still not updating on time even with ABF, only way to get exactly what you want from a pool was to roll your own  

with ABF there would not be "billion wallets online" as when you reach that arbitrary block height they shutdown "automatically" besides even bitcoin does not have "billion wallets online" last time I checked it was about 6k ~ 8k nodes online!

I am not saying ABF is a bad idea its good to try new things but it is going to make it interesting when you start working on other types of wallets as I have seen with the changes made in BLC, there is a push in recent times for HDW as some platforms cant store full blockchain data anyways, so dedicated nodes are still more important than most people realize even on the bitcoin network

whichever way you change pchMessageStart its a good thing to use a unique value for HFC

best of luck hope it all works out  

I did clarify that --

That looks so exciting. Why not do the same kind of stuff with Bitcoin?  Change the protocol unannounced and just relax about the consequences?



Sorry, but we don't believe in luck much. We got plans.


The wallet is not designed for this. The code has something else, database has something else. Not good.

Besides you cant reindex the blocks from the old wallet in the new wallet, cause in the process pchMessageStart is checked.

The devs concern here was that in case everyone's wallet gets corrupt (we got less of it up anyway), it'll result in an un-indexable blockchain which'll contain mixed pchMessageStart which wont re-index in any of the wallets unless it's butchered; since this's a decentralized currency, we don't believe in the only ones holding the correct blockchain.

And best off all, even if there were a billion wallets online, we would've migrated without a fluke even when pools didn't migrate. All thanks to ABF.

err Blakecoin changed it magic and I did not need to support both magic values or ABF for it to work nor did the block chain get stuck, reason for change was crosstalk between networks!
https://github.com/BlueDragon747/Blakecoin/commit/959e04b2bfdaf21d15d43790a01d794e16ad8245



once enough switched(your wallet stops at an arbitrary block height anyway) the chain reorged and it continued also people did not need to clear the blockchain data as you needed a source for the chain the pchMessageStart as I said before is in the header and is used for announcement/broadcast of what chain the block belongs too but the merkle is the final check so your blockchain data that you have already sync'ed is already past the pchMessageStart check

so for your understanding as I have tried to explain pchMessageStart is used for the Broadcast of blocks and the chain identity hence why I said about crosstalk between networks only thing that stops the crosstalk is you are using a different p2p port but also as explained this is user definable which is an issue imho

Hi, you might want to clarify for the logo contest what the name is you want the coin to have, HFC or HUGE.

To ensure backwards compatibility, version 8 of the wallet will use the old pchMessageStart by default. However it'll be designed to accept the new pchMessageStart also.

Version 8.1 of the wallet will by default use the new pchMessageStart but accept connections using the old pchMessageStart also so it can connect with version 8 of the wallet (in situations where version 8 connects to version 8.1) which does accepts the new (and default) pchMessageStart but connects using the old pchMessageStart.

Version 8.2 of the wallet will only work with the new pchMessageStart.

Notice regardless of what pchMessageStart of the receiving block is, when writing the DB, the internal hardcoded pchMessageStart is used.

When people upgrade from version 8 of the wallet to version 8.1, it's suggested that they delete the blockchain cause version 8.1 uses the new pchMessageStart. If users fail to do this, the blockchain will contain mixed old pchMessageStart and new pchMessageStart blocks. Thus reindexing will fail. If no one deleted the old blockchain, it'll result in a situation where everyone will have a non-working non-reindexable blockchain. In case everyone's blockchain goes corrupt, no one will have a working blockchain.

However cause version 8.1 of the wallet will be up, and the admin's node will contain a blockchain synced completely from the start using version 8.1 of the wallet (i.e. will contain only 1 pchMessageStart) a copy of the correct blockchain will always exist.

Key point to note is that version 8.1 of the wallet will have to be released after version 7 expires so there are no situations where the correct nodes are not able to connect to each other and there are chances of a fork.

The next 3 wallet releases will be dedicated to migrating the network ID and there won't be a single fork cause of this.

Doing such a thing is like changing the protocol which's otherwise an impossible task for most coins.

But ABF makes it possible and it's fool proof.

There are attempts to instamine this with 5x the hashing power, but it doesn't work.

http://explorer.hardforkcoin.org/?248056
http://explorer.hardforkcoin.org/?248059

The diff retarget is just too responsive to allow for that. Opposite of KGW.