[Dev] Hard fork to change retarget, averages and block time
-
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 -
Here’s some more about “Time Travel” attack.
https://bitcointalk.org/index.php?topic=114751.0
With the time warp bug, a 51% attacker can create value out of thin air by lowering the difficulty to 1 and generating the remaining 11 million BTC of block rewards for himself. Time warp keeps rewinding time to fit unlimited blocks before the current time. (I think ArtForz actually demonstrated the attack on one of the altcoins) etc
Time Warp Test, in Testnet3
https://bitcointalk.org/index.php?topic=114751.msg1237900#msg1237900Re: ArtForz
Re: Other Attack solutions
http://gldcoin.com/documents/GoldCoin_0.7_51percent_defense_october_11_2013.pdfThe resulting discussion …
https://bitcointalk.org/index.php?topic=309629.0 -
The shorter the blocks the more effect the time warp has. Being able to shift the time 30 minutes on Bitcoin with their 10 minute blocks has much less effect than on our proposed changes of 1 minute. Ghostlander has proposed some increased restrictions to time manipulation which are already in the hard fork code. one minute offers convenience to merchants and reduces the risk of double spend without becoming an orphan generator. Extremely fast blocks see many more orphan block for each one accepted into the blockchain. One minute proves to be a popular block target for new coins. If there are further steps to limit the effect of time manipulation please share them.
I am not worried about time attacks as the manipulation seems to be much less serious as they cannot orphan blocks at the same time. When there was no automatic checkpointing time attacks came to toy with our difficulty, with one attack over the course of 24 hours, orphaned all the blocks to replace them with blocks that totalled an hours worth of time. This was a one off, and the effect was to make our difficulty drop when it should have gone up. An attack of this magnitude should not be possible, and if they did try to do such a thing, we can increase the protection of automatic checkpointing to fully remove the ability to orphan any blocks.
Difficulty solutions seem to be getting more complex in general with KGW becoming popular and more complex itself with the additional newly required time warp prevention code. Taking a look at KGW it seems to be more complex than Wrapper’s solution and coins using KGW have a different difficulty on each block so must trigger every time. Perhaps we can look at the effects of KGW on coins that uses one minute targets.
-
Interesting discussion re: What is a Hard or Soft Fork?
-
Just post right here whenever you need more mining power :)
I have 3 R9 280x and a water cooled i5… not really doing much mining on GPU now, its getting less profitable as the days goes by.
Still waiting for my 2 – 600GHs Butterfly Labs ASIC :(
-
earvax, thanks for the offer, the testing needs to be “relative” so we can check the specific figures.
The devs have discussed how we can bring more members in to help and Wellenreiter is working on a way we can run the “Test pool” but switch between the test and normal coins, so a normal miner can help us test, but still be earning.
Don’t throw your rig away yet, we are doing this update for “you”…
-
Testing - Update
The Testnet has moved to http://188.226.166.44:19328
We need a small number of CPU miners ~ 50 KHash and you can use the test p2pool so there is no extra configuration.
minerd -o http://188.226.166.44:19328 -u Address+0.000011 -p -x
You can replace Address with a real Test address. I have updated the guide to compiling a test wallet in a VirualBox, to include the new test version git link.
If you do compile in a test box, it is then a good place to get used to Coin Control, by sending some test coins about. Warning: At this stage it must be kept isolated and DON’T update your normal wallet to the test version.
Here is the github link, for test wallet: WARNING, it is under development, so recompiles will be required, do not use as your normal wallet!
-
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,
Because of your concerns, we are doing some extra work looking into GetNextWorkRequired(). So far it would seem that confirmations are not based on looping back through the all blocks in the chain so your fears are unfounded.
We also don’t look back 500 blocks in any of the simulated difficulty adjustment solutions that were tested.
-
Testing - Update
The Testnet has moved to http://188.226.166.44:19328
For those of you that are used to have a redundant configuration, or in case the above pool is not available due to upgrades or new setups, you can add the second testnet pool:
If we need to modify the software on the pool, we will do it one server after the other, so if you have the second server configured changes will be transparent to you.
We need a small number of CPU miners ~ 50 KHash and you can use the test p2pool so there is no extra configuration.
minerd -o http://188.226.166.44:19328 -u Address+0.000011 -p -x
You can replace Address with a real Test address. I have updated the guide to compiling a test wallet in a VirualBox, to include the new test version git link.
If you do compile in a test box, it is then a good place to get used to Coin Control, by sending some test coins about. Warning: At this stage it must be kept isolated and DON’T update your normal wallet to the test version.
Here is the github link, for test wallet: WARNING, it is under development, so recompiles will be required, do not use as your normal wallet!
For those not wanting to complile the wallet themself I can provide precomiled binaries and also installation packages for a couple of Linux distributions and a short instruction how to install the testnet wallet.
If you don’t want to install any new software on your system, you still can help with the tests, by just providing hashing power.
You can use a wallet address from your normal wallet to login to the pool server, but of course you will not receive any coins from the testnet.
-
Interesting discussion re: What is a Hard or Soft Fork?
A soft fork introduces a new protocol functionality without a threat to split the network. For example, PXC will do a soft fork tomorrow with a block limiter. This feature requires a hard fork usually, but we can force the old clients to accept results of the block limiter through the ACP. Those new blocks which violate the block limiter will never be checkpointed. The updated nodes will reject them simply and the outdated nodes will re-organise according to the ACP.
