[Dev] Hard fork to change retarget, averages and block time
-
Hi All,
Just thought you “guys” should know Bush has been working very very hard with Wellenreiter on getting “Enhanced hash rate compensation” coded and tested.
We are getting to the stage where some code review would really help. Particularly looking at “shed painting protocols” and for any other code traps.
I’m hopefully we can get a more public test up on line, again a few volunteers to do some testing would encourage Bush to take some time to open it out.
Remember, the more members that get involved the safer and quicker we can get this done.
-
Hi All,
Just thought you “guys” should know Bush has been working very very hard with Wellenreiter on getting “Enhanced hash rate compensation” coded and tested.
We are getting to the stage where some code review would really help. Particularly looking at “shed painting protocols” and for any other code traps.
I’m hopefully we can get a more public test up on line, again a few volunteers to do some testing would encourage Bush to take some time to open it out.
Remember, the more members that get involved the safer and quicker we can get this done.
What can those of us with more limited coding abilities do?, I can read through code but not well enough to be of use. What else needs doing?
-
Hi Ryan,
You can probably help downloading and testing the new wallet, a little latter on. When we get the first public beta out.
At this stage, we mainly need Devs and miners/pools to get involved. “Lookin around” the actual coding, which is pretty bleeding edge to catch up on. Mainly due to complexity of how the “Hard Forking” system in the Bitcoind protocol works.
I didn’t worry too much about being a hacker, the codes pretty straight forward, as far as readability.
If you learn Github or the Feathercoin Guide / instructions to compile the source code in a Virtualbox, means anyone (even windows) can get hold of the fresh code and see what’s happening. That’s why those compile guide instruction show how to view the code in Qt Creator IDE (open source development environment.)
Learn Github. Set up and learn to compile code ready to do alpha testing.
Another requirement is help setting up a test net, I did get a Digital Ocean droplet set up with a p2pool feathercoin testnet at one stage, but I had to take that down. With the test net extra CPU miners would be advantageous, and would be easy to do, with a few instructions (that need compiling).
We need to update miners and pools that a hard fork is coming, members could help by giving pools and miners some warning that developments are a foot …
The main Devs are very busy, - Without help the development will go on, but take longer.
.
-
Let me know where to point my miner and where to setup an instance of a p2pool feathercoin test net. How big does the droplet need to be? O0
-
We’ll let you know, soon.
Concentration is on completing our test spec.
We found out yesterday that, the Feathercoin p2pool software needs an update to add testnet compliance. Once that is done (we can help, but can’t do it now) we can point miners (CPU) using cgminer to a “Test pool”, and members could help test mine then.
At the moment, we would also have to apply a compiled Feathercoind, to get the test version working. I couldn’t “self compile” on a 1 GB droplet. There may be a way to do it then re size down. It will run p2pool on a 0.5 GByte Droplet.
Let us know if you have skill sets to get that (or something similar) going and not interrupt the Devs, (too much).
-
Wellenreiter has fixed the p2pool and we are awaiting that to be merged.
https://github.com/wellenreiter01/p2pool-feathercoin.git
Here is the link to any member who can help to set up a test p2pool, it will need the --testnet switch.
The idea a p2pool is, the software changes are on the server, so only one place needs up-dateing with fixes and we can get less technical members attached as say, cpu miners.
Again, we’re a bit busy, so some help would be appreciated and be very effective, so worth the effort…
-
Testnet p2pool
/minerd -o http://188.226.166.44:19328 -u mgY5xVMDccd1UQqPM6RiruNgX9q8eTYw3f+0.00000011 -p -x
Wellenreiter has set up p2pool on the test net. If you haven’t got an test address use
mmVjNeDvYKUsCZop8yGeZScdkeZm2pc1T2
It is testing so we may need to dump people off at some stage, I’ll sort some other addresses and when we are happier with initial tests we’ll open a test wallet download.
Test Addresses
miQBffwvtTYQ97K6jmxBYNgAQ8ckTJwmzf
mfyZwhyLBs75Scz2bCMdX3jMUC5X4wqACg
mvu7eFnmt9i1BgTuN4AEbh2M8iYV91dxWge.g. CPU miner
./minerd -o http://188.226.166.44:19328 -u mmVjNeDvYKUsCZop8yGeZScdkeZm2pc1T2+0.000022 -p -x -
OK, I run minerd -o http://188.226.166.44:19328 -u mmVjNeDvYKUsCZop8yGeZScdkeZm2pc1T2+0.000022 -p -x
-
Cheers Lizhi,
We’re got to update the p2pool (feathercoind). Can you stop the miner?. I will post back when we need to do some more testing (on the p2pool testnode).
-
If you are not so keen to get ‘funny money’ in your testnet wallet. you can use any name to login to the p2pool.
It then directs all coins mined under non-feathercoin-testnet addresses to the pools default address.
So minerd -o http://188.226.166.44:19328 -u Lizhis_miner+0.000022 -p -x would also work ;)
-
Guys, if you need free resource to keep the test net up let me know, I shift a couple of things around here and can give you access to the VM console by tomorrow afternoon.
I can shove my 700Mh miner at it for a bit as well if it helps out
UM
-
Cheers for the offer UM, we have some specific things to do first. Then we will be looking at some other senarios, we want some extra miners and wallet transfers etc…
We’ll post on here when the testnet is online and what you can do to help. It’s down at the moment awaiting some updates…
-
No worries, just give me a nudge. I’ll prep you some space on a VM host here so it’s ready when/should you need it. No point in paying for DO resource unless you really have to ;)
The miners is only a spare/test machine so it’s there as soon as you want it, just need some settings for it
UM
-
I Run it . minerd -o http://188.226.166.44:19328 -u Lizhis_miner+0.000022 -p -x
-
Hi Lizhi,
Can you switch off the test miner, urgently. We will ask when we need more miners.
-
I don’t think it’s a good idea to re-target every block. It results in much higher processor utilisation compared to retargets every 15 blocks. It may be a problem over time because GetNextWorkRequired() is called while verifying every block in the chain. This approach is also more vulnerable to time travel attacks. PPC retargets every block, but their retarget code is rather simple. They don’t look back 500 blocks or so on every retarget.
-
Hi Ghostlander, that doesn’t seem to be a problem GetNextWorkRequired().
Can you help us specify a test for additional vulnerability to Time Travel attack?. I’ve heard of Timewarp, which I don’t think we are more vulnerable to.
Plus ReTargeting every 15 Blocks opens up to the 14 Block attack, which is not theoretical.
-
Produce a series of blocks with their time stamps adjusted to the maximum possible, either to the past or to the future, and see what it does to the difficulty.
-
Cheers mate, were obviously busy at the moment with the normal tests to see if the code performs as specified. We’re just checking the hard fork changeover as our main priority. That doesn’t need a lot of testers.
We have set up a central pool so we can manipulate the hash rate and check the difficulty change performs in more realistic circumstances.
Things are actually going surprising well. I have devised some extra tests for other scenarios the changes will protect us from.
Obviously, I don’t want to post attack mechanisms directly on the forum, especially ones that could be used on other coins, but we will be taking your advice.
-
Re: Attack scenarios: -
https://bitcointalk.org/index.php?topic=122013.20;wap2
These are the current Bitcoin Satoshi client protections to deter DoS attacks, as of version 0.7.0:
Does not forward orphan transactions/blocks
Does not forward double-spend transactions
Restrict the maximum number of signature checks a transaction input may request
Continuous rate-limit of free transactions to mitigate ‘penny-flooding’
Keeping a DoS score of each connected peer and disconnects from a peer that send messages that fail to comply with the rules.
Permanently ban IP addresses that misbehave for a time lapse (24 hours default)
Limit the number of stored orphan transactions (10000 by default)
Use a signature cache to prevent attacks that try to continuously trigger the re-verification of stored orphan transactions
Limit the number of stored signature in the signature cache (50000 signatures by default)
Tries to catch errors in transactions before the time consuming signature verifications.
Penalize peers that send us lots of duplicate/expired/invalid-signature/whatever alerts, so they eventually get banned.
In orphan/signature caches: when removing an item, evict a random entry.
Data structures are specially chosen to avoid loops in which the number of iterations can be controlled by an attacker that result in exponential complexity.
Ignore big orphan transactions, to avoid a send-big-orphans memory exhaustion attack.
In RPC: Only send a HTTP 403 response if it’s not using SSL to prevent a DoS during the SSL handshake.
In RPC: Sleep some time if authorization fails to deter brute-forcing short passwords.
In GUI: Limit URI length to prevent a DoS against the QR-Code dialog
