Quote from: souljah1h on November 09, 2016, 08:43:13 PM

Quote

if your definition of solid is forks and the "accidental" generation of 2million coins... then yeah the tech is solid.

Read the following to understand why this happend (forks and the stake of 1.7 million coins). It wasn't intentional if that is what you are implying. Network was just following protocol.

Quote

Background:

The VeriFund wallet was crashing every day due to a high number of inputs. Each address has a balance of coins made up of various inputs. If, for example, you sent 1000 VRC to address 1, and you staked, the 1000 VRC would be split into two new inputs of roughly 500 + 1/2 stake each. The reason input splitting is used in various forms of PoS is to distribute coins into roughly equal amounts. If someone holds 100,000 VRC and their VRC is split into 1000 different inputs of 100 VRC each, even a holder of 10,000 VRC with 100 inputs of 100 VRC will be competitive. This helps keep the flow of stake blocks steady with predictable block times and rewards.

Splitting is not enforced at the protocol level, and in fact, it is not necessary. However, a wallet without splitting enabled will stake unpredictably and total long-term interest will likely be lower.

Unfortunately, since the VeriFund Endowment wallet (VFEndownxxnHea9mv59kZx8c7TysGbndYx) held a large quantity of VRC, the stakes split into thousands of inputs. This caused a number of problems. One major issue is the abundance of inputs to send large quanties of coin (for example, if we wanted to use the endowment interest to fund a new block explorer) prevents sending without coin control. Instead, meticulous input selection is necessary to send coins without erroring due to transaction size. This high transaction size due to the many splits additionally bloats the blockchain. The bloat is insignificant for normal wallets with under several hundred thousand VRC, but for the VFEndow wallet with almost 2 million, it was detremental.

Not only did inputs cause issues with sends, but they also caused the wallet to crash due to high memory utilization. With the goal of running the endowment wallet on a low-power system such as a Raspberry Pi, it would never be possible. In fact, running on an Intel I7-3770k with 16 GB of ram was not enough after a month of staking and splitting without manually recombining inputs using coin control.

What happened:
After weeks of discussion between Doug and I, it was decided that we should attempt to improve the splitting system. Instead of targeting splitting according to the original code when the following condition was met:

if ((nWeight < nStakeSplitAge) || ((nCoinWeight/nAverageStakeWeight) < nStakeSplitWeightFraction))

where nWeight is the age weight of the coin, nStakeSplitAge is a constant of 2592000, representing the number of seconds in 30 days, nCoinWeight is nWeight (age weight) * nCredit (coins), nAverageStakeWeight is the average stake weight of the past 60 blocks (roughly 1 hour), and nStakeSplitWeightFraction is 0.35 or 35%

the new target in versions 1.6.5.2-1.6.5.4 was simply

if (nWeight > nStakeSplitAge)

According to the original conditions, if the coin weight was lower than 1 month's worth of age, it would split. Additionally, if your coins made up less than 35% of the network stake weight, they would split.

When splitting is not occuring, the coin attempts to collect inputs so that the minimum size is 5000+ per input. Unfortunately, since it was now much harder to split, many inputs from almost every staker instead combined to be greater than 5000. An example of this occuring is in block 1415038: https://chainz.cryptoid.info/vrc/block.dws?1415038.htm. In this case, 57 inputs that would normally be able to stake independently were combined to create one new input.

What immediately happened after the release of 1.6.5.2 was users on that version started combining inputs and burning massive coin-age due. Since both inputs were significantly reduced, especially among long-term stakers who have been continually staking and thus had the smallest inputs, suddenly there were not enough inputs to consistently stake. The block time started slowing considerably and due to the now-burned coin-age, interest rates shot up to ridiculous amounts.

As reference, the equations defining the inflation rate and interest rate are as follows:

inflationRate = (17*(log(nAverageWeight/20)))/100

where nAverageWeight is the average stake weight of the previous 60 blocks

interestRate = ((inflationRate*INITIAL_COIN_SUPPLY)/nAverageWeight)*100
where INITIAL_COIN_SUPPLY is the original PoW distribution of 26751452 VRC

Since both coin-age was burned in combining inputs as well as not enough inputs existing to have 60 second block times, the VRC chain had to accept blocks with low weight reducing the nAverageWeight down to very low amounts-- amounts unseen previously. Due to the log scale of the inflation rate calculation, this caused interest rates to exceed even 2000% APR in certain instances.

A quick series of patches was made by Doug to change the splitting formula to apply when nWeight < nStakeSplitAge with a new definition of 259200, or the number of seconds in 3 days (1.6.5.3), and trying to reduce combining inputs to 1000 VRC instead of 5000 VRC (1.6.5.4), but it was too little, too late.

In certain cases, splitting was occuring in the same block as the stake causing the coin-age to be insufficient after splitting to create that stake. In this case, nodes that accidentally staked a block improperly in this method were banned from other nodes. This caused forking to occur.

Another change was made in 1.6.5.2 in order to attempt to speed up syncing of new wallets. At startup, previously the last 500 blocks were checked. Now, only 10 were-- a change made in other coins that have been shown to work well. This change did not negatively impact VeriCoin and did indeed speed up startup times.

The other significant change unrelated to splitting was increasing the broadcast of blocks to new nodes. Previously, 2000 blocks were sent at a time. This value was increased to 40,000. In addition, 8000 block headers at a time were broadcast before, now 80,000. The added strain of attempting to seed nodes with many times more blocks at once caused 32-bit systems, and 64-bit systems with less than 8 GB of ram to crash due to the large number of blocks in memory for distribution.

Ultimately, both changes to block distribution and stake splitting were untested prior to release. This was a poor decision, but one made with the expectation that they would not cause any issues. Unfortunately, the fact that many clients were forking due to splitting issues, the reduced inputs able to stake, and crashing due to block distribution caused the network to break into many forks and catastrophically increasing interest rates during the splitting. Thankfully, the vast majority of high-interest stake was on the VeriFund Endowment wallet which we control and can determine the fate of. We will be seeking opinion on what to do with the funds with the most obvious options of destroying them, or staking them in perpetuity in the endowment.

The road ahead:
We have reverted 1.6.5.2+ splitting code back to 1.6.5.1 so users will have more small inputs to stake with rather than few 5000+ VRC inputs. The system worked well for most users before. We may need to create a specialized wallet for the VFEndow wallet in order to prevent crashing, but it should be a limited release just to handle splitting on that particular wallet.

In addition, we have also reduced block distribution back to 2000 blocks and down to 10,000 block headers (up from 8000 but down from 80,000 in 1.6.5.2). This wallet release is numbered 1.6.5.5.

The longest chain was found to be on an unupgraded 1.6.5.1 wallet and was used to bootstrap a new supernode (supernode.vericoin.info -- still without central checkpointing) to help users get on the main chain. In addition, new bootstraps will be created and made available on a regular basis to help reduce the number of forks in the wild.

Future patches will be tested first internally before release. Since Doug and I no longer work physically next to each other, and I have graduated and started working with less free time, our communication was sub-par and the release was not properly vetted before it was published. We will work extremely hard to ensure this does not happen again.

The faith of the large stake was brought to a Community vote and those coins got burned.

Burn addy here; https://chainz.cryptoid.info/vrc/address.dws?VRCBURNCNhMBcyVBiYB4znn61PfYy7gVCb.htm

Quote from: L.H. Mysterieux on November 07, 2016, 04:17:31 PM

now then...

fix this...
&
we'll go from there.
.014351 btc > 14T2Gy1iqcuRcne3nSoYDj9VGDBz5WzRF7

353.39034593 vrc > VLw5vPW7dY4NreFe61k4QHauMRe7rT4GfE

22aa5b04969d718c31366ea82d55612b3532c6e8fe727293f19e3747dd6397c7

Remember this?

Quote from: pnosker on November 07, 2016, 12:50:21 AM

Quote from: L.H. Mysterieux on November 07, 2016, 12:19:33 AM

Quote from: souljah1h on November 06, 2016, 11:57:58 PM

Veribit is working properly.

no.

it is not.

    VLw5vPW7dY4NreFe61k4QHauMRe7rT4GfE

   VJi67EtjTCbC1hcQ5X4FAkAEv3aLmgmc3L

   VDiUv4XHJWcKGZrCWweA5USfuq2vTao7yo

the list goes on...

Can you send an email to vericoin@vericoin.info with details including: 1. The address you sent VRC to, 2. The Bitcoin address destination, and 3. A VRC refund address if the transaction got stuck? David will check it out.

In addition, the addresses you posted aren't VeriBit addresses.

I have sent you 2 PMs on this forum, with no response from you. Also didn't recieve email from you on vericoin@vericoin.info seems like you don't want it to be fixed...

I ask you once again.

Quote

Can you send an email to vericoin@vericoin.info with details including: 1. The address you sent VRC to, 2. The Bitcoin address destination, and 3. A VRC refund address if the transaction got stuck? David will check it out.

Just another troll perhaps?