I'm interested to know different solutions to prevent people "cheating" on block time in PoS.

PoS generates a hash using various things including time, it is time that limits the hash power of PoS as if you stake too far into the future or past you generate a block that is rejected by the network.  For example the following shows a simplified version of how Peercoin generates a hash to check against the target difficulty. blockFrom.GetBlockTime() is the block time.


When mining you create a block with the current time and see if using it you generate a valid hash. To increase your chances of finding a valid hash you would also try generating blocks up to the past and future block time limits. This poses an advantage over those who do not if this behaviour is not built into the coin itself.

The result of baking this into your code to level the playing field is that the block time will start jumping around and after generating a block you'll likely see several more blocks at once, a new block will change the stake modifier giving all stakers full range of time to stake in again. After the flood of blocks there will be a period to wait while no one was able to generate a block in the next time window and has to wait a second a time on the future time limit. That flood of blocks is normally empty as only the first block was the one that took time to stake.

Networks appear to behave more sanely when "super staking" is not built into the code but this gives an advantage to those who know how to exploit it.

Solutions to this seem to be limiting the future and past time windows.

Does anyone know of any other savvy solutions to this?

This is not a new problem and I'm sure that there must have been attempts to solve this over time.

Thanks, that makes sense, otherwise a block on the edge could start being rejected during propagation.

New blocks that are more than 2 hours ahead of the local time are rejected. For backwards time blocks cannot be less than than the median time of the last eleven blocks. Why not use a fixed time going backwards like the forwards time? The longer we go without a block the larger the backwards time range becomes, a fixed time provides a fixed range from past to future blocks.

You are missing an include, fix is in Bitcoin.

https://github.com/bitcoin/bitcoin/commit/a5929130223973636f3fd25fbfaf2953f2ec96a9#diff-63c8cb9c9dd61d50d59afd5c39914e1c259f8743030b637a7896a0746c851ef1

Peter Bushnell here. All exchanges have been asked to restore deposits again. I asked exchanges to disable deposits while they upgrade all upgrade their wallets to the latest version and we upgrade the 51% attack protection to a new version. There was a period where the protection was disabled and we did not want exchanges to be attacked during that period.

Apologies for the inconvenience.

Please update your client to 0.18.2 or pull the latest source from GitHub and compile. Some clients got stuck yesterday and an updated client has now been released and source updated to resolve the problem.

BitcoinPlus is not a fork of Bitcoin like the ones outlined below, they are hard forks or airdrops on the Bitcoin blockchain. BitcoinPlus are an entirely separate chain with our own genesis block and do not include any subset of the Bitcoin UTXO set.

https://forkdrop.io/how-many-bitcoin-forks-are-there

I paid for the FatBTC and Graviex listing, not keen to do the same for Crex24 so will turn down their offer. There's some news that Cryptopia will return to trading during this month so the requirement for some more backup exchanges may well be moot.

Cryptopia might reopen in February NZ police says

Crex24 have replied with the following.


I'm going through the listing process of setting up an account and topping up the balance to 0.5 BTC, also considering a USD listing. If anyone is interested in contributing please PM me.

Mercatox are asking for 3.4 Bitcoin which is too much. I've made another application to Crex24 offering 0.4 Bitcoin this time.

BitcoinPlus is now listed at Graviex.

https://graviex.net/markets/xbcbtc?pinned=true

I've replied to your PM with instructions on how to restore your balance with the zapwallettxes option.


Graviex has been paid for, currently waiting to hear back from Crex24. Emailed Mercatox and will find out how much they want.

I'll take you up on that offer and will pursue Crex24 to get a quote, in this depressed market you can often strike a better deal. I've spoken to Graviex and am getting us listed there, we could do with some back up exchanges after our run of bad luck.

We've finished the BTCPay integration but have had to leave it disabled due to Cryptopia going down, a fair amount of time has been lost, I'm hoping they will come back up but after reading the external analysis from Elementus it seems unlikely.

Jeez, the responses on the first page of this thread are mostly "buy when ICO" with the same level of bad grammar. There's analysis to show that the ICO boom took billions of dollars straight out of crypto into fiat, the whole ICO rush undermined the wider crypto market.

Let's leave ICOs in 2018.

As to when is the right time to buy no one can say with total confidence, so only get into a coin if you can stand to lose what you invested.

There's several soft forks happening on BitcoinPlus, the first one will allow atomic swaps and participation on Decentralised Exchanges. Once the feature is active and locked in then BitcoinPlus will join a DEX (Decentralised Exchange).

Upgrade to 2.7, available from the link below, to start staking and help BIP65 activate.

https://github.com/bitcoinplusorg/xbcwalletsource/releases

Soft fork tracker

You can follow the soft fork status on the web page below, the new feature becomes active when 75% of the network has upgraded, the feature locked in completely once 95% of the network has upgraded.

https://www.bitcoinplus.org/status

Here's the coinbase transaction created in the hard fork on block 3,030,000 which has two additional outputs to create an additional 631,842 CANN. The inflation model has been changed to not go over the total coins to be mined of 420 million.

https://chainz.cryptoid.info/cann/tx.dws?3721652.htm

451,896 CANN minted to reimburse Bittrex for the coins lost in a 51% attack. Automatic Checkpointing has been enabled on the network to prevent future 51% attacks. Once Bittrex has been reimbursed the CANN/BTC pair will be re-opened.

179,946 CANN minted to pay for two bits of work, the first to create this hard fork for the Core/Android wallet and fix the sync issues on Android at the same time and the second part to update CANN to the 0.13 codebase and implement all the latest Bitcoin soft forks currently missing from CANN which are BIP66, CLTV, CSV and SegWit.

CANN is currently on the 0.8 codebase which is very slow to sync and hard to work with in general compared to newer Bitcoin codebases. For example it can take weeks to sync where it should only take a few hours.

Feathercoin 0.13.0.0 has been released. It is a mandatory update for anyone on a version prior to 0.9.6.2 as on block 2,120,000 it will start minting Version Bit blocks which will be rejected by old version of Feathercoin. Please make sure you have updated to 0.13 before block 2,120,000 which will be minted roughly in 17 days on the 8th March.

Download the Feathercoin 0.13 from the first page of this thread, the homepage of the official website or from the GitHub release page.

BitcoinTalk
https://bitcointalk.org/index.php?topic=178286.3480

feathercoin.com
https://www.feathercoin.com/

GitHub
https://github.com/FeatherCoin/Feathercoin/releases/tag/v0.13.0.0

Major changes in 0.13.

- BIP9 Version Bits which starts on block 2120000
- Segregated Witness BIP9 Soft Fork
  - Elimination of unwanted transaction malleability
  - Capacity increase
  - Weighting data based on how it affects node performance
  - Signature covers value
  - Linear scaling of sighash operations
  - Increased security for multisig
  - More efficient almost-full-node security
  - Script versioning
- CHECKSEQUENCEVERIFY BIP9 Soft Fork
- CHECKLOCKTIMEVERIFY Legacy Soft Fork
- Faster synchronization
- Compact Block support
- Hierarchical Deterministic Key Generation
- Dynamic transaction fee
- RPC Access Control Changes
  - `-rpcallowip=192.168.1.*` becomes `-rpcallowip=192.168.1.0/24`
  - `-rpcallowip=*` becomes `-rpcallowip=::/0`
- REST interface with `-rest` flag
- Watch-only wallet support
- Block file pruning
- Memory usage optimization
- Reduce upload traffic
- Direct headers announcement
- Notifications through ZMQ

Just install 1.3 and run it, the wallet.dat location is the same for all versions so no need to import anything, just leave it where it is.

About mining, I should have mentioned that with getblocktemplate and solo mining you need to provide a coinbase address for the first transaction in the block, that's the one with your reward for minting it.

For example:


guncoin.conf would look like the following.

Your post says the following.

Block Reward 15 GBX decreasing by 12% every year

In the source code it shows the deflation as...


Please correct me if I['m wrong but the above will reduce the subsidy by a 12th of the total subsidy but not by 12% as stated.

For example...

100 / 12 = 8.33 which is a 12th of 100 and not 12% of 100 which would be 12 and not 8.33.

For your subsidy after the first year it works out as...

15 / 12 = 1.25 so subsidy after first year will be 15 - 1.25 = 13.75 coins

To reduce by 12% it should be...

15 * 0.12 = 1.8 so the subsidy according to your info should be 15 - 1.8 = 13.2 coins

GuncoinInfo is away at the moment with limited Internet but has told me to release the v1.3.0.0 client when it is ready, when he gets back he will update the original post.

Guncoin 1.3 is ready, this release is based on the Bitcoin 0.10 codebase and brings many updates to the coin, the most notable of which I have put on the Guncoin v1.3.0.0 release page linked below.

https://github.com/guncoin/guncoin/releases/tag/v1.3.0.0

There is going to be a block version change on block 840,000 which is in roughly three weeks time, the 1.1 client only accepts version 2 blocks so will end up hard forking on that block. If you are on Guncoin 1.1 then you must upgrade to 1.3 before block 840,000 or you will end up on a different chain and be unable to send coins to the 1.2/1.3 network. Currently 64% of people have upgraded to 1.2 and will be unaffected by the change in block version.

Block version 4 brings in BIP66 Strict DER Encoding and the more interesting BIP65 OP_CHECKLOCKTIMEVERIFY. BIP66 was back ported to the Guncoin 1.2 release but to make use of BIP65 you will need to update. These BIPs only become active once 75% of the last 1,000 blocks are version 4, at 95% version 2 blocks will be rejected by the network.

Solo miners please note that getwork has been removed from Guncoin 1.3 and that NeoScrypt miners with getblocktemplate support need to be used instead, for AMD cards please update NSGminer to 0.9.4.

https://github.com/ghostlander/nsgminer/releases/tag/nsgminer-v0.9.4

nVidia miners can no longer use ccminer as it does not have getblocktemplate support and need to use hsrminer instead though I'm waiting on confirmation from people as to how well it works, please give feedback here.

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

Pool miners can carry on as normal.

Also note the following RPC access control changes

0.9.x and before	0.10.x
-rpcallowip=192.168.1.1	-rpcallowip=192.168.1.1 (unchanged)
-rpcallowip=192.168.1.*	-rpcallowip=192.168.1.0/24
-rpcallowip=192.168.*	-rpcallowip=192.168.0.0/16
-rpcallowip=* (dangerous!)	-rpcallowip=::/0 (still dangerous!)