Topic: [Ultracoin] [Est. Feb 2014] ~ ASIC Resistant & Ultrafast 6 Second Transactions! - page 100. (Read 381063 times)
February 22, 2016, 01:51:49 PM
February 22, 2016, 01:25:40 PM
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
Lets start an open and nice discussion here .....
Thanks very much,
Paul.
February 22, 2016, 01:21:42 PM
@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).
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.
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.
February 22, 2016, 04:25:27 AM
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
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]
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
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?
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?
February 21, 2016, 04:45:47 PM
February 20, 2016, 08:50:40 PM
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
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?
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
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?
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?
February 20, 2016, 08:12:41 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
February 20, 2016, 06:44:23 PM
Where now UTC can be sold? I knew only Cryptsy but now it doesn't work.
February 20, 2016, 06:40:04 PM
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?
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?
February 20, 2016, 06:33:15 PM
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!
Year of production of UTC was gone for nothing.
The coin is dead, developers left.
Why you so arrive with us? We trusted you!
February 18, 2016, 08:22:58 PM
Get someone who unlike me actually knows what he's doing to confirm;
Convince/pay said someone to help create a fork with the proposition of changing the difficutly retarget at block X;
Compile wallets and distribute them before we hit block X.
Convince/pay said someone to help create a fork with the proposition of changing the difficutly retarget at block X;
Compile wallets and distribute them before we hit block X.
February 18, 2016, 07:33:15 PM
Sounds logical to me, but what can we do about it?
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?
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?
February 17, 2016, 06:10:00 PM
Can I get an active node list or getpeerinfo please?
"addr" : "31.220.1.58:44100",
"services" : "00000000",
"lastsend" : 1455662856,
"lastrecv" : 1455662856,
"conntime" : 1455662856,
"version" : 0,
"subver" : "",
"inbound" : false,
"releasetime" : 0,
"startingheight" : -1,
"banscore" : 0
}
]
interesting that crypto-trade.com/koddos is still running their UTC wallet, after the vanishing act, but left users waiting for their UTC over a year now from when the blockchain was stuck
February 17, 2016, 12:17:24 AM
and
18:13:51

getpeerinfo
18:13:51

[
{
"addr" : "73.197.232.209:44100",
"services" : "00000001",
"lastsend" : 1455686015,
"lastrecv" : 1455686016,
"conntime" : 1455660604,
"version" : 70058,
"subver" : "/Ultracoin:0.7.3/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 1659965,
"banscore" : 0
},
Cheers
do you mean this?
I only get 3 peers max on wallet
11:48:56

getpeerinfo
11:48:56

[
{
"addr" : "72.128.84.115:44100",
"services" : "00000001",
"lastsend" : 1455662820,
"lastrecv" : 1455662934,
"conntime" : 1455659957,
"version" : 70058,
"subver" : "/Ultracoin:0.7.3/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 1659958,
"banscore" : 0
},
{
"addr" : "95.24.68.194:44100",
"services" : "00000001",
"lastsend" : 1455662808,
"lastrecv" : 1455662820,
"conntime" : 1455661792,
"version" : 70058,
"subver" : "/Ultracoin:0.7.3/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 1659983,
"banscore" : 0
},
{
"addr" : "31.220.1.58:44100",
"services" : "00000000",
"lastsend" : 1455662856,
"lastrecv" : 1455662856,
"conntime" : 1455662856,
"version" : 0,
"subver" : "",
"inbound" : false,
"releasetime" : 0,
"startingheight" : -1,
"banscore" : 0
}
]
18:13:51

getpeerinfo
18:13:51

[
{
"addr" : "73.197.232.209:44100",
"services" : "00000001",
"lastsend" : 1455686015,
"lastrecv" : 1455686016,
"conntime" : 1455660604,
"version" : 70058,
"subver" : "/Ultracoin:0.7.3/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 1659965,
"banscore" : 0
},
Cheers
Can I get an active node list or getpeerinfo please?
do you mean this?
I only get 3 peers max on wallet
11:48:56

getpeerinfo
11:48:56

[
{
"addr" : "72.128.84.115:44100",
"services" : "00000001",
"lastsend" : 1455662820,
"lastrecv" : 1455662934,
"conntime" : 1455659957,
"version" : 70058,
"subver" : "/Ultracoin:0.7.3/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 1659958,
"banscore" : 0
},
{
"addr" : "95.24.68.194:44100",
"services" : "00000001",
"lastsend" : 1455662808,
"lastrecv" : 1455662820,
"conntime" : 1455661792,
"version" : 70058,
"subver" : "/Ultracoin:0.7.3/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 1659983,
"banscore" : 0
},
{
"addr" : "31.220.1.58:44100",
"services" : "00000000",
"lastsend" : 1455662856,
"lastrecv" : 1455662856,
"conntime" : 1455662856,
"version" : 0,
"subver" : "",
"inbound" : false,
"releasetime" : 0,
"startingheight" : -1,
"banscore" : 0
}
]
February 16, 2016, 08:13:03 PM
Can I get an active node list or getpeerinfo please?
do you mean this?
Yes, thank you.
February 16, 2016, 05:51:50 PM
Someone bought £100 worth. Wouldn't look much into it. Seems to have bottomed out so people are investing thinking they are buying at the bottom.
Steven if you are quiting at least have the courage/balls to tell us rather then just walking out on us leaving UTC in the lurch.
UTCwas around the 15-20 altcoins, one of the first of the second wave after the first wave of namecoin, peercoin, doge etc. It has stature and many investors hold a bit of UTC! It's a sleeping giant!
Steven if you are quiting at least have the courage/balls to tell us rather then just walking out on us leaving UTC in the lurch.
UTCwas around the 15-20 altcoins, one of the first of the second wave after the first wave of namecoin, peercoin, doge etc. It has stature and many investors hold a bit of UTC! It's a sleeping giant!
February 16, 2016, 05:50:28 PM
Can I get an active node list or getpeerinfo please?
do you mean this?
I only get 3 peers max on wallet
11:48:56

getpeerinfo
11:48:56

[
{
"addr" : "72.128.84.115:44100",
"services" : "00000001",
"lastsend" : 1455662820,
"lastrecv" : 1455662934,
"conntime" : 1455659957,
"version" : 70058,
"subver" : "/Ultracoin:0.7.3/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 1659958,
"banscore" : 0
},
{
"addr" : "95.24.68.194:44100",
"services" : "00000001",
"lastsend" : 1455662808,
"lastrecv" : 1455662820,
"conntime" : 1455661792,
"version" : 70058,
"subver" : "/Ultracoin:0.7.3/",
"inbound" : false,
"releasetime" : 0,
"startingheight" : 1659983,
"banscore" : 0
},
{
"addr" : "31.220.1.58:44100",
"services" : "00000000",
"lastsend" : 1455662856,
"lastrecv" : 1455662856,
"conntime" : 1455662856,
"version" : 0,
"subver" : "",
"inbound" : false,
"releasetime" : 0,
"startingheight" : -1,
"banscore" : 0
}
]
February 16, 2016, 05:48:27 PM
something up?
Maybe that horse is still alive?
Maybe that horse is still alive?
UltraCoin price is spiking right now.
Even with the broken difficulty, UTC is better off without Rapture or Kracko coming in and ruining things more. Those two are completely and utterly incompetent.
Perhaps, you should be praying that they stay away for good!
Even with the broken difficulty, UTC is better off without Rapture or Kracko coming in and ruining things more. Those two are completely and utterly incompetent.
Perhaps, you should be praying that they stay away for good!
February 16, 2016, 05:46:02 PM
OK - I know why there are still miners
Rank Donor User Name H/s UTC/Day BTC/Day
1 anonymous 66,628.27 54,900.141 0.1016
2 anonymous 12,888.75 10,620.027 0.0196
3 eel 9,175.04 7,560.019 0.0140
4 whortonda 3,276.80 2,700.007 0.0050
5 anonymous 1,310.72 1,080.003 0.0020
55k UTC per day? Well maybe only when diff low - but even so................
Rank Donor User Name H/s UTC/Day BTC/Day
1 anonymous 66,628.27 54,900.141 0.1016
2 anonymous 12,888.75 10,620.027 0.0196
3 eel 9,175.04 7,560.019 0.0140
4 whortonda 3,276.80 2,700.007 0.0050
5 anonymous 1,310.72 1,080.003 0.0020
55k UTC per day? Well maybe only when diff low - but even so................
Jump to: