[Ultracoin] [Est. Feb 2014] ~ ASIC Resistant & Ultrafast 6 Second Transactions! - page 100.

usukan

legendary

Activity: 1590

Merit: 1002

Kumusta and welcome to the UTC community Mr JM Erestain.

Thank you for your offer to assist this community - I am sure we are open to serious discussion of your offer.

It might be a good idea if you could give us a quick summary of your qualifications and experience in crypto and related areas. I have had a quick look through your history here and you have certainly been doing some interesting things.

Checked your FB https://www.facebook.com/GMdpinoy13?fref=ts
How old are you? About the same age as Vitalik Buterin - a plus in my books - look what he did.

Your site http://ph.newsbtc.com/ looks pretty good - is this really you?
https://www.facebook.com/newsbtcph/?pnref=lhc (note the link on your FB to NewsBTC needs the www deleted)

Do you know the guys from Coins.ph and Rebit? Both great companies in your country, revolutionising BTC and I deal with them a lot (mainly Coins.ph).

You seem to be a straight up honest guy - with lots of energy. This means a lot to me as we have a lot of scumbags in crypto.

Please get back to us with a few details and we can all discuss things here.

Maraming salamat po - usukan

Quote from: Emerge on February 23, 2016, 03:47:37 PM

If you are still in need of a marketing manager or a project head, I can fill in any of these roles.

Emerge

legendary

Activity: 854

Merit: 1000

If you are still in need of a marketing manager or a project head, I can fill in any of these roles.

Marnie1976

sr. member

Activity: 275

Merit: 250

Quote from: Uggle on February 23, 2016, 01:51:55 PM

Anyone in 'merica who has tried to contact Steven?

Let us all keep trying. We need answers Sad

.

Quote from: Marnie1976 on February 21, 2016, 04:45:47 PM

STEVEN J. NEKHAILA was born 8 March 1994 and he lives (or lived) at 125 MILANO DR in ISLAMORADA /P.K., Monroe County, Florida, U.S.A.

His voter ID number is 119520232.
His telephone number is (or was) 1-305-393-6412.
He registered to vote 9 March 2012 and he is registered in the Libertarian Party of Florida.
He is listed as White, not Hispanic.

https://lpf.org/our-party/lpf-leadership/

STEVAN NEKHAILA is DISTRICT MANAGER OF WENDY'S FASTFOOD AND HAMBURGERS .
Location Islamorada, Florida

https://twitter.com/stevennekhaila

https://www.facebook.com/steven.nekhaila

Uggle

full member

Activity: 228

Merit: 100

Anyone in 'merica who has tried to contact Steven?

whortonda

newbie

Activity: 24

Merit: 0

@bathrobehero: Good call.

I think reverting to the V3 retargeting would work fine and may save some effort. It's still simple averaging as in V4 and V5, but back then the averaging interval was 10 minutes (10 blocks). That makes it much more responsive to what's currently happening with the network. Makes me wonder why they ever decided to change the averaging interval at all. The max adjustment was also different (was 16% down and 8% up in V3, changed to 16% down and 12% up in V4-V5) but that's somewhat arbitrary.

funsponge

hero member

Activity: 776

Merit: 557

great to hear from you Paul. I also don't know anything about coding and am just an investor. I have been here from the start and was attracted by the speed of UTC and the cha-cha tech, which is only used by a few altcoins.

There are thousands of people interested in Altcoins and im sure there will be many suitors willing to take the reins. Maybe post something on Reddit or somewhere where many people read about Altcoins?

im interested how come you have all the user accounts for the UTC twitter/facebook/website etc if you havent heard from Steven as he dealt with all that side of things?

PaulR1

sr. member

Activity: 320

Merit: 250

Dear UTC community members,

Please let me explain a bit more so there can be no misunderstandings.

As a metaphor: The ship is “slightly” damaged sailing around, carrying a precious cargo.

Because the “current” captain and his mate gives no signals at all, for a longer period, we have to assume that they have left the ship. So the ship is sailing without any crew, captain or mate.

For me was this the moment I had to take action and explain to the community the situation how I see it is.

Unfortunately, I have no possibility at all to lead or do jobs for UTC because of my business commitments.

The only thing I can do for now is helping to find a new dev team for UTC and share or handover the “UTC infrastructure” (as mentioned before), this so the new team members can make a fresh re-boot.

Bottom-line: If the “old” dev-team doesn’t come back and starts leading again or there are no volunteers found for a new dev-team then the UTC ship will continue to sail damaged in circles without a crew and therefore without a mate and captain.

Anyone who is serious interested and have some special capability’s or is willing to be the new dev-team manager, please step in this forum or pm me.

Thanks,
Paul.

thispanda

newbie

Activity: 40

Merit: 0

Quote from: bathrobehero on February 22, 2016, 07:53:14 PM

@whortonda

I'm not a coder by any means, I just know how the difficulty of this coin behaves and looking at the code those things stood out to me.

I'm glad to see some discussion from people who actually know what they are doing.

Quote from: bret on February 20, 2016, 06:40:04 PM

I'll take a look and see what I can do. When I do get a new wallet built, how do we get people to use it?

Nice, thanks! Sign me up for testing it and if it works we should pretty much just set a block for the changes to go live and contact people/pools/exchanges/etc before then to make the upgrade.

I'm also glad Paul came back to clear the air.

Nice work on getting this going. I believe there are several difficulty adjustment algorithms out there, and one that might be interesting is Digishield (by Digibyte), also used by Dogecoin and several other coins - I think this is designed to handle large and sudden changes in hashrate, but I'm no expert.

Edit: on second thought - why not use the old difficulty adjustment? I suppose that worked fine, and might be easier to implement and require less testnet testing etc..?

bathrobehero

legendary

Activity: 2002

Merit: 1051

ICO? Not even once.

@whortonda

I'm not a coder by any means, I just know how the difficulty of this coin behaves and looking at the code those things stood out to me.

I'm glad to see some discussion from people who actually know what they are doing.

Quote from: bret on February 20, 2016, 06:40:04 PM

I'll take a look and see what I can do. When I do get a new wallet built, how do we get people to use it?

Nice, thanks! Sign me up for testing it and if it works we should pretty much just set a block for the changes to go live and contact people/pools/exchanges/etc before then to make the upgrade.

I'm also glad Paul came back to clear the air.

usukan

legendary

Activity: 1590

Merit: 1002

Hi Paul - thanks for dropping in and opening up a potential path for rejuvenating UTC.

Official Ultracoin Team

member

Activity: 66

Merit: 10

Welcome to the future !

PaulR1

sr. member

Activity: 320

Merit: 250

Dear All,

I was a long time in to the back ground but did see what happens the last two years in the Wild West of Crypto world and I also see the last few months what happens to UTC.

I can and I will not judge what are the causes at our precious UTC. There are too much possible causes too point at.

As for Steven, he has been a person who has done his utmost best for UTC in the last year. At this point Steven deserves absolute 200% credits.

The reasons why Steven has been absent for longer time now is unclear. Because I don’t know the reasons I will not judge or condemn. It is just how it is at this moment.
For now i can only understand, because of the 100% absence of Steven for a longer time, that he is unable or unwilling to take the lead of UTC.

But the fact does exist that UTC is still a "living" coin and is a coin whit a future if the right people can lead this pad for UTC. At this moment we are in need of those people seriously.

So there are still serious possibilities and big opportunities for UTC. Serious chances !

But those possibilities and chances are only possible if there will be a serious reboot take place soon. Quickly and smoothly.

If there would be any possibility for me to take (again) the lead in the background I would accept that job with all my love, but unfortunately this is not possible for me due to other commitments.

So what is needed now to get back Ultracoin up and running soon;

- UTC needs a new General Leader of the Dev-team ;
- UTC needs a new Coin Developer ;
- UTC needs one or two Pool Operators ;
- UTC needs a new Marketing Manager ;

If it's up to me, the new team will be 100% dicision free as team and get full authorithy about UTC.

Unfortunately, for now, these all are voluntary tasks and only persons that have UTC deep in their hearts can be serious candidates.

Next to that, every candidate needs to realize that the voluntary tasks will ask a lot of (private) time without having any kind of financial compensation.

Oke !
And then ?
What now ?

Hopefully we find some serious and capable volunteers who want to lead UTC in to the future and make it big again !

What is available for "infrastructure" for the new Dev-Team ;

Available are (with login and passwords) :

- The existing UTC Bitcoin Forum Tread
- The existing UTC Twitter account
- The existing UTC website address (possible with website content and layout)
- The existing UTC Facebook account

I would love too hear any comments and thoughts Huh

Lets start an open and nice discussion here .....

Thanks very much,
Paul.

whortonda

newbie

Activity: 24

Merit: 0

@bathrobehero

I am by no means an expert, so take all this with a grain of salt.

I think you're on the right track, but the problem isn't with the frequency of the retarget or the percent increase/decrease limits-- it's with the averaging method not taking into account large fluctuations in network hashrate.

The retargeting method uses a simple average of the time it took to mine each of the past 240 PoW blocks. With a simple average, all the data points are treated with the same weight, so blocks that were mined hours ago at absolute minimum difficulty have as much influence as the last block which perhaps was mined at a very high difficulty and took far too long.

Super-simplified example: if there were 120 blocks mined over 10 minutes at low difficulty followed by 120 blocks mined over 3 hours 50 minutes at high difficulty, then a simple average would think that's right on target because hey, that's 240 blocks in 4 hours.

What I would suggest is using some sort of weighted average to calculate the average block time. This method gives recent data points more weight than data points further in the past, so the block time of the last few blocks would have much greater influence on the next difficulty than the block time of blocks mined hours ago. It complicates the calculation a bit because you have to get the block time of each block over the averaging period and apply the weighting factors, but it's not that difficult. I think you could even reduce the period significantly, like perhaps the last 60 blocks (theoretically the last hour), without adverse effect.

Here's how you would calculate a linear weighted average block time (pseudocode).

Code:

averagingPeriod = 60;				//60 blocks, one hour
weightedAverageBlockTime = 0;
i = 0;

while(i < averagingPeriod) {
	weight = (averagingPeriod - i) / ((averagingPeriod * (averagingPeriod + 1)) / 2);
	weightedAverageBlockTime += weight * (BlockTimestamp(blocks[thisBlock-i]) - BlockTimestamp(blocks[thisBlock-i-1]));
	i++;
}

//it looks like from the source code that higher targets represent lower difficulty
//because the goal is to find a hash below the difficulty target
//so scaling is actually the mathematical inverse -- I think this is correct

scalingFactor = weightedAverageBlockTime / targetBlockTime;
nextDifficulty = Min(lastDifficulty * scalingFactor, proofOfWorkDifficultyLimit);

You could of course still apply the max increase/decrease limits, but I think the weighted average itself would handle that for you in all but the most extreme cases.

Hope that's helpful and more power to you.

Valpe

full member

Activity: 307

Merit: 100

I can support this and if this works I will send you Bret a stash of UTC from the new wallet.

Valpe

quote author=usukan link=topic=727023.msg13956089#msg13956089 date=1456019440]
Bret - thanks for your idea and offer of help.

How to get people to use it?

See what support you get here from active community members - if there is support move to next stage.

Ask yourself if you are really willing to take this on and go the distance - it will be a lot of work with often criticism from some here.
Ask yourself - do I really know how to do this - cos if you screw it up it could be the end of UTC.
Do you have colleagues to support you in this? Do you have a network of experienced people to call on for advice?

If so - (just a brainstorm)

Redo the code

First test it to make sure it works - including staking.

Publish on your Github

Get consensus here for a fork via votes from active members. Maybe time to start a new BitcoinTalk thread that is owned/moderated by the now active community.

Don't forget that the miners have to agree to mine it - or nothing will happen. If the miners and the pool don't want to change nothing will happen - unless there is a new pool for the forked UTC-2 version and miners willing to follow here.

Announce a fork here (or on new forum)

Make sure Alenevaa has his one and only pool ready with new code - and that he will let miners know that its going to fork. - there are only 2-6 miners as far as I can tell?
http://utc14.yacoin.club/index.php?page=statistics&action=pool

Make sure Bittrex has the new wallet (and anywhere else its traded)

Release the wallet for download at least 2 weeks before fork so everyone has time to swap over.

Fork it and cross your fingers.

Not my area of expertise but I support your endeavours and will respect other opinion from community - and if it works I will send you a stash of UTC from the new wallet. Others may wish to do the same.

What are the thoughts from other ACTIVE members?

Cheers - usukan

Quote from: bret on February 20, 2016, 06:40:04 PM

Quote from: bathrobehero on February 18, 2016, 08:06:08 AM

I was just looking at the latest (current) retarget changes on github and I believe I found the issue with the retarget.

Firstly, there's

static const int64 nMaxAdjustDownV5 = 16; // 16% adjustment down
static const int64 nMaxAdjustUpV5 = 12; // 12% adjustment up

which means the diff can change as much as 16% down and 12% up which would be fine (I guess) but one problem is that this 16%/12% retarget happens every single block and it's always the maximum amount of change as far as I can see, not small changes.

Second problem is that once it overshots the difficulty and the blockchain stalls for like half a day and then finally a block is found, the difficulty won't decrease right away.

If I had to guess it's caused by this:

static const int64 nAveragingInterval5 = 240; // 240 blocks, 4 hours

which I'd guess means the difficulty average is based on the last 240 blocks meaning a bunch of super high (or super low) difficulty blocks has to be mined before the difficulty retarget starts adjusting - and when it does it overcompensates.

I might be completely wrong but I believe if the difficulty retarget wouldn't happen every single block, but maybe every 10 blocks or so then everything should be fine. Thoughts?

I'll take a look and see what I can do. When I do get a new wallet built, how do we get people to use it?

[/quote]

Marnie1976

sr. member

Activity: 275

Merit: 250

usukan

legendary

Activity: 1590

Merit: 1002

Bret - thanks for your idea and offer of help.

How to get people to use it?

See what support you get here from active community members - if there is support move to next stage.

Ask yourself if you are really willing to take this on and go the distance - it will be a lot of work with often criticism from some here.
Ask yourself - do I really know how to do this - cos if you screw it up it could be the end of UTC.
Do you have colleagues to support you in this? Do you have a network of experienced people to call on for advice?

If so - (just a brainstorm)

Redo the code

First test it to make sure it works - including staking.

Publish on your Github

Get consensus here for a fork via votes from active members. Maybe time to start a new BitcoinTalk thread that is owned/moderated by the now active community.

Don't forget that the miners have to agree to mine it - or nothing will happen. If the miners and the pool don't want to change nothing will happen - unless there is a new pool for the forked UTC-2 version and miners willing to follow here.

Announce a fork here (or on new forum)

Make sure Alenevaa has his one and only pool ready with new code - and that he will let miners know that its going to fork. - there are only 2-6 miners as far as I can tell?
http://utc14.yacoin.club/index.php?page=statistics&action=pool

Make sure Bittrex has the new wallet (and anywhere else its traded)

Release the wallet for download at least 2 weeks before fork so everyone has time to swap over.

Fork it and cross your fingers.

Not my area of expertise but I support your endeavours and will respect other opinion from community - and if it works I will send you a stash of UTC from the new wallet. Others may wish to do the same.

What are the thoughts from other ACTIVE members?

Cheers - usukan

Quote from: bret on February 20, 2016, 06:40:04 PM

Quote from: bathrobehero on February 18, 2016, 08:06:08 AM

I was just looking at the latest (current) retarget changes on github and I believe I found the issue with the retarget.

Firstly, there's

static const int64 nMaxAdjustDownV5 = 16; // 16% adjustment down
static const int64 nMaxAdjustUpV5 = 12; // 12% adjustment up

which means the diff can change as much as 16% down and 12% up which would be fine (I guess) but one problem is that this 16%/12% retarget happens every single block and it's always the maximum amount of change as far as I can see, not small changes.

Second problem is that once it overshots the difficulty and the blockchain stalls for like half a day and then finally a block is found, the difficulty won't decrease right away.

If I had to guess it's caused by this:

static const int64 nAveragingInterval5 = 240; // 240 blocks, 4 hours

which I'd guess means the difficulty average is based on the last 240 blocks meaning a bunch of super high (or super low) difficulty blocks has to be mined before the difficulty retarget starts adjusting - and when it does it overcompensates.

I might be completely wrong but I believe if the difficulty retarget wouldn't happen every single block, but maybe every 10 blocks or so then everything should be fine. Thoughts?

I'll take a look and see what I can do. When I do get a new wallet built, how do we get people to use it?

usukan

legendary

Activity: 1590

Merit: 1002

Quote from: barbados-fs on February 20, 2016, 06:44:23 PM

Where now UTC can be sold? I knew only Cryptsy but now it doesn't work.

you can trade UTC here

https://bittrex.com/Market/Index?MarketName=BTC-utc

barbados-fs

hero member

Activity: 837

Merit: 505

Where now UTC can be sold? I knew only Cryptsy but now it doesn't work.

bret

member

Activity: 99

Merit: 10

Quote from: bathrobehero on February 18, 2016, 08:06:08 AM

I was just looking at the latest (current) retarget changes on github and I believe I found the issue with the retarget.

Firstly, there's

static const int64 nMaxAdjustDownV5 = 16; // 16% adjustment down
static const int64 nMaxAdjustUpV5 = 12; // 12% adjustment up

which means the diff can change as much as 16% down and 12% up which would be fine (I guess) but one problem is that this 16%/12% retarget happens every single block and it's always the maximum amount of change as far as I can see, not small changes.

Second problem is that once it overshots the difficulty and the blockchain stalls for like half a day and then finally a block is found, the difficulty won't decrease right away.

If I had to guess it's caused by this:

static const int64 nAveragingInterval5 = 240; // 240 blocks, 4 hours

which I'd guess means the difficulty average is based on the last 240 blocks meaning a bunch of super high (or super low) difficulty blocks has to be mined before the difficulty retarget starts adjusting - and when it does it overcompensates.

I might be completely wrong but I believe if the difficulty retarget wouldn't happen every single block, but maybe every 10 blocks or so then everything should be fine. Thoughts?

I'll take a look and see what I can do. When I do get a new wallet built, how do we get people to use it?

barbados-fs

hero member

Activity: 837

Merit: 505

What a pity.
Year of production of UTC was gone for nothing.
The coin is dead, developers left.
Why you so arrive with us? We trusted you!

Topic: [Ultracoin] [Est. Feb 2014] ~ ASIC Resistant & Ultrafast 6 Second Transactions! - page 100. (Read 381018 times)