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

I opened my wallet today and there's a BIG donation of 50,000 HFC/HUGE


Thank you!!

First, I still don't understand what kind of attack will take the wallets to an early expiry. So this situation we're talking about is hypothetical. But still...

The difficulty retarget algo is the most resilient and responsive ever made. Even if you mine from the genesis blocks, it retargets completely within 10 to 15 blocks.

On top of that once the genuine wallets are offline, in the new wallets we can do arrangements such that the difficulty will not be reset.

Can you provide links to the 80% consensus rule? We can also implement new checkpoints to invalidate the attacker's chain in case it's score is more than the genuine chain.

Speaking of 51% attacks, the devs may have found a way to prevent a 51% attack in the first place regardless of how much hashing power the attacker has. He will never be able to do a double spend at least.

problem with the genuine network being offline is that the attacker will continue to mint blocks guess you could just cut the blocks out which you would do via block height or block time checks but the downtime will effect the difficulty once it returns with your new client version

its 80% consensus for rules or main/longest chain and it can reorg the difference so you want 80% to upgrade

under some conditions the difficulty can be reset only ever seen this once during clock change but it can happen and about the only protection is to have good network hashrate as if an attacker has a good % of block minting they can mess with the block times and this has all sorts of issues with the base code of almost all coins pow or pos

yes blocks from HFC and BLC will fail the merkle check and get rejected but the first check is the magic value as its in the block header then it processes the block and does the other checks so it just creates extra load on the wallets as they think about it rather than just failing on header check and moving on, in the log file you will see failed merkle errors if this crosstalk happens

also as I said before your message signing is not right between the daemon and the qt you should also fix that

you did make a good choice picking the blake code base it is stable and has proven to have few issues shame you did not want to be a merged coin but I dont add coins with any premine anyways and you want to be open to algo change in the future good luck with that 

Yes. We cant migrate the vulnerability at the instance it's discovered. This's already well written on topic.


If we implemented automatic updates, it whouldn't have been decentralized. Besides semi-automated wasn't a good name.


Checkpointing? It's a completely different thing. We've added checkpoints here too.


We chose Blake cause of it's algo and the fact that it's up to date and maintained (thanks to you).

The devs will change the magic value (I've not talked to them yet), but as you know, the difficulty retarget algo is completely different from that of Blake and none of HFC's blocks will be accepted by BLC's network.

so you can get a fork between arbitrary check height but you are saying it will return once the arbitrary check height is reached as the old wallet will automatically shutdown best hope for no major exploits or issues between arbitrary check height's then  

"whole network will automatically switch" well from the code if the wallet is old it closes and thus leaves the network and does not automatically do any switching without the user updating the wallet!

this is not any different to even what bitcoin has done in the past as it has implemented new rules in the wallet with a block height checks only extra you are doing is to shutdown the wallet once the arbitrary check height is reached which could be an issue if the network was attacked with a 51% or a flaw in your retarget algo is exploited as the only wallets that may continue to run would be the attacker's as your wallets would have automatically shutdown assuming they could push the height above your arbitrary check height, and as you have so few nodes and due to the decentralized nature of all wallets it could be using the attackers wallets as the source e.g 80% rule

oh well you based it on Blakecoin even down to using same network magic value and Blakecoin has never had a fork problem so you should be alright although to avoid possible crosstalk you should use a unique network magic value as port can be changed by a user via the conf

*until you fix the magic value I will dump the node list and ban them from the Blakecoin network just to be on the safe side

No, we don't use CLIENT_VERSION_MAJOR for any kind of checking. The wallet does not check the version of the nodes which connect.

By Automated we mean we don't have to go head over heels to ensure that there won't be a fork. The wallet will automatically expire after a certain block, users will upgrade and the whole network will automatically switch to the new wallet and the new changes will be incorporated without a fork.

And all this is decentralized. The wallet has no nodes stored in it except the seed nodes.


The new bug fix will incorporated after the old wallet expires, like we did with the difficulty retarget algo.

I'll ask about the magic value with the devs.

not checking version number eh

so whats automated about it?

what stopping it forking between the current block height and the arbitrary check height?

if you had to release a new version due to some bug before the arbitrary check height the old wallet would continue and not warn thus would create a fork in the chain

I still think if enough bad nodes broadcast a bad value your check would shutdown the good nodes does that not just make it weaker to a 51% attack  

and why are you using same magic value as Blakecoin for your network?

Version number check? No it does not. The wallet checks the block count.

Yes, user needs to update manually. That's as per plan. Common users have to.

the check does close the wallet if it is reached its arbitrary check height so that could be considered "Automated" but what concerns me about that is its open to an exploit would make a 51% attack quite easy if the check value is exploited to shutdown most of the network wallets  

thanks  
Was looking at that coin and was wondering what was really new... so basically nothing  
now let me do an automated "previous page" so I can automatically look at something different...  

from the code you provide this is just a clone of Blakecoin you have not even changed the network magic value(pchMessageStart) like you should 

I do see some changes to the difficulty algorithm with a tweaked difficulty adjustment and period

'Automated blockchain forking'
hmm only thing I can see in the code is a check for version number and an alert for the user but not automated compatibility or update end user still needs to update the client for new rules so this seems the same as most other wallets to me 

also you dont seem to have fixed the message signing between the qt and daemon which was fixed in Blakecoin guess you have another client(Automated hardfork) due for release 

 

More of eDRv2 in action

http://explorer.hardforkcoin.org/?233103
http://explorer.hardforkcoin.org/?233115

If you can, please donate some HFC/HUGE to the premine address (BZuh2LnvFazZUoGPK6ogfVpssQhwfUhqkU).

See eDRv2 in action.

http://explorer.hardforkcoin.org/?230305

There's a sudden 200% increase in difficulty to prevent an instamine.

Link to logo contest --

https://bitcointalksearch.org/topic/bigcoin-logo-contest-841986

In the mean time, version 6 wallets are offline.

If you go through the block explorer, you can see eDRv1 in action. There'll be a sudden drop in difficulty to prevent the blockchain from hanging.

http://explorer.hardforkcoin.org/?227950

Version 7 of the wallet has been released which has eDRv2 code which'll start from 230,001. Version 6 wallets will stop at 230,000

The dev couldn't get it at 100x more effective. It was interfering with regular mining that way, so the criteria for an exception was relaxed.

What blockheight will this kick in? Thanks.

eDRv2 will be released with Version 7 of the wallet which's around 100x more effective than KGW to prevent an instamine.

Consequently it also prevent orphans or limits orphans.