Δ DeltaCredits - Trade-in ends in less than 24 hours

[drays]

Sure there are not enough staking wallets, but there may be another reason for network not staking well too.

If you look on block 22101, you could see a strange picture:  http://cryptobe.com/block/f4d0e725f0192d6a09aa9440b636de71a37b22147a140e319dc4d84a6dcd891c

It looks like 9 inputs were consolidated into one single input after the staking! It means next time instead of 9 blocks those coins could generate just 1 block.
Even worse is on block 22100 (http://cryptobe.com/block/54310354d8df0be1f957e03e4ad9a32fe9ed606d5a3488b356618314ad57c19d) - about 30 inputs were consolidated into one.

I am not sure why this happened, but if the wallet does it itself, then after some time there will be very few inputs to stake.

I have seen wallets dividing coins after the staking (that creates many small inputs, which could be inconvenient, but it definitely supports the network). For example CoinAid wallet does that. But here it looks we have the opposite, and this could be a problem.

These are just my observations and assumptions. They might be wrong, but if they are correct, then wallet code could need to be tweaked.

[Tortoise75]

Ah, good find, didn't notice this here but noticed similar behavior in STEPS staking though. There altcoinsteps answered with this:

to address the staking fuze/split

there are 2 lines in code that define this:

unsigned int nStakeSplitAge = 1 * 24 * 60 * 60;
int64_t nStakeCombineThreshold = 1000 * COIN;

the nStakeSplitAge = 1 * 24 * 60 * 60; means that the pos reward gets split into 2 outputs if the stake was younger than nStakeSplitAge(24 hours for STEPS)
the nStakeCombineThreshold = 1000 * COIN; means that if there are multiple sub-1000 STEPS coins at the staking address they should be recombined.

Given your find I assume these lines, or some with similar functionality, but perhaps different values are present for DeltaCredits as well. Since one of your examples fused inputs into one 1014 coins input I guess if you want smaller inputs these should be separated into different addresses to avoid fusing.

[drays]

Ah, good find, didn't notice this here but noticed similar behavior in STEPS staking though. There altcoinsteps answered with this:

to address the staking fuze/split

there are 2 lines in code that define this:

unsigned int nStakeSplitAge = 1 * 24 * 60 * 60;
int64_t nStakeCombineThreshold = 1000 * COIN;

the nStakeSplitAge = 1 * 24 * 60 * 60; means that the pos reward gets split into 2 outputs if the stake was younger than nStakeSplitAge(24 hours for STEPS)
the nStakeCombineThreshold = 1000 * COIN; means that if there are multiple sub-1000 STEPS coins at the staking address they should be recombined.

Given your find I assume these lines, or some with similar functionality, but perhaps different values are present for DeltaCredits as well. Since one of your examples fused inputs into one 1014 coins input I guess if you want smaller inputs these should be separated into different addresses to avoid fusing.

Those lines present in DeltaCredits source code too, exactly with the same values (https://github.com/Gladimor/DeltaCredits/search?utf8=%E2%9C%93&q=nStakeSplitAge), but I am not sure if this is the reason or not. In any case 1000 coins could be a small amount in case of Steps with their supply of 10M, but is a very big number for DCR with its supply of 100K.

[Tortoise75]

Those lines present in DeltaCredits source code too, exactly with the same values (https://github.com/Gladimor/DeltaCredits/search?utf8=%E2%9C%93&q=nStakeSplitAge), but I am not sure if this is the reason or not. In any case 1000 coins could be a small amount in case of Steps with their supply of 10M, but is a very big number for DCR with its supply of 100K.

Yes, especially since the amount of 100k coins is shrinking and 50 inputs are needed for the confirmations to unlock the frozen stake inputs. Well, a work around is separating the inputs into different addresses, fusing shouldn't happen across addresses as long there isn't some really weird thing going on.

OK, now seems to be the time to figure out how to move the chain far enough to get Gladimors transactions, and perhaps some of our own, confirmed.

[Zebedee23]

i just got my wallet online , got a hell of alot of coins and chain is moving good now, will try keep it on for forseable future.

[Gladimor]

Transferred DCR already, will leave wallet unlocked for the foreseeable future so the network will run smoother. If in the case the network gets stuck again, I will spin up hardware miners to get it moving again.

[Zebedee23]

shit i just looked at my blocks in coin control and yeah seems very soon they will all be staking, think its fused them all! shld have planned ahead and split into smaller blocks!

edit: yes thats definitely something that if we ever did fork shl;d be changed (block fusing/.spliting)

[AngelLox]

Ah, good find, didn't notice this here but noticed similar behavior in STEPS staking though. There altcoinsteps answered with this:

to address the staking fuze/split

there are 2 lines in code that define this:

unsigned int nStakeSplitAge = 1 * 24 * 60 * 60;
int64_t nStakeCombineThreshold = 1000 * COIN;

the nStakeSplitAge = 1 * 24 * 60 * 60; means that the pos reward gets split into 2 outputs if the stake was younger than nStakeSplitAge(24 hours for STEPS)
the nStakeCombineThreshold = 1000 * COIN; means that if there are multiple sub-1000 STEPS coins at the staking address they should be recombined.

Given your find I assume these lines, or some with similar functionality, but perhaps different values are present for DeltaCredits as well. Since one of your examples fused inputs into one 1014 coins input I guess if you want smaller inputs these should be separated into different addresses to avoid fusing.

Those lines present in DeltaCredits source code too, exactly with the same values (https://github.com/Gladimor/DeltaCredits/search?utf8=%E2%9C%93&q=nStakeSplitAge), but I am not sure if this is the reason or not. In any case 1000 coins could be a small amount in case of Steps with their supply of 10M, but is a very big number for DCR with its supply of 100K.

I'll try to tinker with that and compile it again, if i'm successful i'll make a commit.

shit i just looked at my blocks in coin control and yeah seems very soon they will all be staking, think its fused them all! shld have planned ahead and split into smaller blocks!

edit: yes thats definitely something that if we ever did fork shl;d be changed (block fusing/.spliting)

It doesn't require a fork, it's just a wallet functionality.

[ozboy2014]

What's happened to "Decreasing Supply"?

[AngelLox]

What's happened to "Decreasing Supply"?

He's doing weekly or bi-weekly buys. Like a big concentrated one.

[Gladimor]

Amount sent to burn address: 592.86636596 DCR

http://cryptobe.com/address/DBurnAddressDELTACreditsDCR1MHEkpR

[Abou Talha]

Cool! We are still here; keep the good work, dev!

[Zebedee23]

DCR is gonna be delisted from C=cex on 10/12 if it doesnt have enough vol. .

[ozboy2014]

DCR is gonna be delisted from C=cex on 10/12 if it doesnt have enough vol. .

trouble with a developer who's got too many things on his plate... bound to neglect some 

[Gladimor]

Amount sent to burn address: 609.14130195 DCR

http://cryptobe.com/address/DBurnAddressDELTACreditsDCR1MHEkpR

[drays]

Burn address is now number 6 in rich list Not bad

[Tortoise75]

Yes, and number 5 in the sights. 

[MissCrypto]

DCR is gonna be delisted from C=cex on 10/12 if it doesnt have enough vol. .

Got delisted, but I doubt it matters since there was 0 volume there anyway.

Anyhow, here goes: http://cryptobe.com/tx/11957f224921eca905cc7990db100b4b7f47e9ddaa4f8274f514970a1b74f873

[drays]

Anyhow, here goes: http://cryptobe.com/tx/11957f224921eca905cc7990db100b4b7f47e9ddaa4f8274f514970a1b74f873

WOW! *Speechless*

[Zebedee23]

Anyhow, here goes: http://cryptobe.com/tx/11957f224921eca905cc7990db100b4b7f47e9ddaa4f8274f514970a1b74f873

WOW! *Speechless*

if you are thinking that DCR is moving out of Burn address you are very wrong!! Look at the burn wallet on explorer and check every transaction where DCR was sent there, they are all listed as the burn address being the 'output;. Its fault of explorer, they got input & output the wrong way round!!!