deleted

[samspaces]

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.

What blockheight will this kick in? Thanks.

[1715660564]

1715660564

[1715660564]

1715660564

[1715660564]

1715660564

[1715660564]

1715660564

[1715660564]

1715660564

[1715660564]

1715660564

[hardforkcoin]

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.

What blockheight will this kick in? Thanks.

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.

[hardforkcoin]

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

[hardforkcoin]

In the mean time, version 6 wallets are offline.

[hardforkcoin]

Link to logo contest --

https://bitcointalk.org/index.php?topic=841986

[hardforkcoin]

See eDRv2 in action.

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

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

[hardforkcoin]

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

[hardforkcoin]

More of eDRv2 in action

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

[BlueDragon747]

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 

 

[djm34]

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  

 

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

[BlueDragon747]

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  

 

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

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  

[hardforkcoin]

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 

 

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.

[BlueDragon747]

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  

 

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.

Code:

//  Major version change means a hard fork which's required or incompatible protocol
#define CLIENT_VERSION_MAJOR       7

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?

[hardforkcoin]

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  

 

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.

Code:

//  Major version change means a hard fork which's required or incompatible protocol
#define CLIENT_VERSION_MAJOR       7

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?

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.

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

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.

[BlueDragon747]

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.

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

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.

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

[hardforkcoin]

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  

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

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!

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

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

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

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

How can a 51% attack make the blockheight reach great heights suddenly so as to shutdown wallets abruptly? Besides if genuine wallets do shutdown, the only thing remaining online will be the attacker's wallet, so people will not be able to do transaction via a bad block chain which's a kind of protection.

Besides later on, the wallet expiry height will be set to a high value like every 4 to 6 months or so. We'll release the new wallets 3 months before with the hope that at least 50% nodes will upgrade.

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

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.

[BlueDragon747]

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  

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

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!

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

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

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

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

How can a 51% attack make the blockheight reach great heights suddenly so as to shutdown wallets abruptly? Besides if genuine wallets do shutdown, the only thing remaining online will be the attacker's wallet, so people will not be able to do transaction via a bad block chain which's a kind of protection.

Besides later on, the wallet expiry height will be set to a high value like every 4 to 6 months or so. We'll release the new wallets 3 months before with the hope that at least 50% nodes will upgrade.

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

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.

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 

[hardforkcoin]

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

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.

[hardforkcoin]

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

Code:

    {
        "account" : "",
        "address" : "BZuh2LnvFazZUoGPK6ogfVpssQhwfUhqkU",
        "category" : "receive",
        "amount" : 50000.00000000,
        "confirmations" : 9334,
        "blockhash" : "000000002925d9ef6dc505ed2eb55bba7430d42132adbde6baf15eb00edaa220",
        "blockindex" : 1,
        "blocktime" : 1414950088,
        "txid" : "9247b2cb41b2ee816c3f6596c92a4a783dc7da073662a4f754ac7c88da39118f",
        "time" : 1414950088,
        "timereceived" : 1415283522
    }

Thank you!!

[hardforkcoin]

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.