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

[usukan]

Thanks fabietech - your contribution received.

almost there

Cheers - usukan

Thanks everyone for your strong and prompt support on this project.

Current contributions are from the following:

wtfc360
PaulR1
Valpe
Roister01
usukan

The UTC Dev Fund holds 1.95319198 BTC
https://blockchain.info/address/1LpFmfieMBH63ivFA1Us5ju1jnH9CSccKZ


Just confirming final details now with PressTab on exactly how we want to proceed and payments.

I will hopefully report back later today - with payment details for Stage 1 (Diff re-target fix) and confirm that PressTab is "on the job".

Note we have 1.26 BTC approx to go - to raise the full funds for all 3 stages.

If anyone else in the Community wishes to support this work - we are very happy to hear from you now.

Any contributions large or small will be gratefully received and put to good use with PressTab.

We need to reach at least 2.4 BTC Total in a weeks time (an additional 0.45 approx.) to move on to Stage 2 (Tidy up the Ultracoin code).

GREAT WORK EVERYONE  


Cheers - usukan

Count me in Usukan great Job! 0,312BTC will be transferred

[1714830299]

1714830299

[1714830299]

1714830299

[1714830299]

1714830299

[rapture333]

Hello everyone,

I just want everybody to know that I do view the thread at least once a day, or several times a day in most cases. The ball has been set in motion and Usukan has been operating at full force. Usukan and I have agreed to let him finish through with current developments and then I will take the lead from there, especially during the hard fork process when we are ready to move on to the next update. . I will also be stepping back up in big ways in the marketing department, I am currently working on an automated system for Facebook and Twitter updates, and a written newsletter which will be sent out on a consistent basis. My current task list also include making some changes to the website and OP and scouting out possible marketing opportunities for low cost/ high impact exposure.

Beave, I truly appreciate your dissent, you have been one of the biggest (respectfully) dissenting voices on this thread and I wouldn't want it any other way. First off, I would disagree that the conventions were ineffective, Ultracoin raised to 23rd on the marketcap at $1,000,000 total value right after convention time; not to mention the reach and recognition of being included on the convention floor. The bear market unfolded immediately during the failed fork with the update that was supposed to improve difficultly fluctuations but ended up causing it to swing so high no one could find a block for days. That was a heart wrenching time, the second largest downturn coincided with the mistimed NAT server that was connected to ultrablockparty.com resulting in a second network failure and the multiple hard forks that followed. All of these things happened under my watch, and I take responsibility for that, but I am no developer and I could do in my power was co-ordinate a recovery as quickly as possible. I am hoping with Presstab's help and the future update we should have a rock solid platform to move forward with things like marketing, infrastructure and acceptance. Future updates to come.

As for NFactor and block reward, I would not recommend changing block reward as this was a heavily meditated issue that involved a lot of thought and historical sampling. Too low and you discourage miners, too high and you create inflation and reach your coin ceiling sooner. It is no secret that 90% of all BTC will be mined by 2022, the consolidation of currency is still largely help by tech savvy users, large mining operations and the grey and black market. Although the 90% mark is 8 years away, cryptocurrency has yet to go mainstream in a meaningful way that it could compete with central bank backed currencies. Bitcoin of course does have the option to increase the money base, but that would require a hard fork, which for Bitcoin would mean a completely separate creation of a new coin. I have personally debated Bitcoin core developers (as I had the opportunity at the North American Bitcoin Conference whilst I personally defended the existence of alt-coins), I can say that these developers are fantastic at their jobs, but know next to nothing about economics. As far as NFactor, both NF14 and NF15 are worthy options; as the next generation of GPU's and CPU's are released I believe mining technology will advance significantly and become more affordable allowing more and more average computer users to be able to mine Ultracoin. Not to mention the more future proof, the less likelihood of a hard fork needed in the future.

Sincerely,

Steven "Rapture" Nekhaila
Ultracoin Development Team
Steven@Ultracoin.net
Ultracoin

[usukan]

Hi Steven - Welcome back.

Everything is coming together rather well now in UTC so the Ultracoin Community is in for some exciting times.

Cheers - usukan

[usukan]

PressTab Update

PressTab is making great progress - it can be summarised as the following:

-------------------------------------------------------------------------------------
He has thus far placed the standard pos/pow difficulty adjustment code into the codebase, cleaned up the former difficulty adjustment code as well as certain aspects of main.cpp, and also reduced the update threshold on QT from .5 seconds (he's never seen a client use such a small amount) to 10 seconds. The QT change should reduce a lot of lag, most clients are using 5 seconds, and bigger chains using up to 30 seconds. Each time this is queried it will do a variety of things such as iterate through each one of the unspent outputs you hold and calculate its weight, update network weights, etc. It all takes precious resources. Typically the wallet is running idly in the background so a half a second update time is a bit bizzare in this case.

Moving forward PressTab will be scanning through the codebase to see if the common memory leaks have been patched yet, make sure the key code has been updated to accept the newest SSL build and also prevent the transaction malleation problem that can occur (this is a malicious attack that can shut down the client if someone wants to do it), and also a few other tidying items.

He will also be placing the actual code to handle the fork, which is not yet done.

He will look into the problems Alenevaa mentioned about the balances. Concerning net hashrate, this is something that is not an exact science and is actually an estimate based on statistics and the rate that the blocks are coming in for PoW. So a weird difficulty adjustment code can definitely throw this statistic off. For the unconfirmed transaction problem, he's not totally sure how to handle this other than maybe restricting tx to only used confirmed inputs.

Basically he is tag teaming Stage 1 and 2 right now.

He will have a good crack at things this weekend and be close to finished apart from the liteStake code additions.
------------------------------------------------------------------------------------

I have sent payment for Stage 2 to PressTab - from the UTC Dev Fund

as advised by PressTab 1.199501 BTC

https://blockchain.info/tx/1a69c05a33d4d3e65f034de74b4b6d5bc0dae74d32d39391b566705059e9e430


Cheers - usukan

[usukan]

Stage 3 - addition of "liteStake" code to improve UTC staking


Unnecessary delays make me anxious - so I always try to avoid them.

Accordingly - I have topped up the UTC Dev Fund with an additional 0.3 UTC

As it stands - we have enough now to pay for the 3rd and final stage of this work with PressTab (with a little surplus).

PressTab will advise exact cost shortly and I will pay him for this final stage of the work.


Sometime next week PressTab will likely be finished - He will hand over the work and then work with Steven to implement the fork.

I will leave the timing of the fork up to the Community and Steven to decide - but its likely a couple of weeks after PressTab is finished so all stakeholders can update.

Stakeholders = miners, pool, Bittrex and general users etc.


ALMOST DONE





Cheers - usukan

[usukan]

In case anyone wonders

The balance of the UTC Dev Fund DEPOSIT ADDRESS (1LpFmfieMBH63ivFA1Us5ju1jnH9CSccKZ) reports
0.612 BTC
https://blockchain.info/address/1LpFmfieMBH63ivFA1Us5ju1jnH9CSccKZ

This deposit address is only really useful for looking at incoming and outgoing transactions - it does not accurately reflect the BALANCE.


Its not this single address (1LpFmfieMBH63ivFA1Us5ju1jnH9CSccKZ) that now holds all the funds.  All the UTC Dev Funds are actually in an ACCOUNT - with many addresses all in the UTC Dev Account.

This is because - Every time I spend to pay PressTab - the transaction "change" is returned to a new address which is also held within the UTC Dev Fund ACCOUNT.
Here is the "change" part of the last transaction to PressTab.
https://blockchain.info/address/112zzg99aTM6zKDbawGXqHz7rE5TicSuaN



So - just for everyone's info
This is the balance in the UTC Dev Account

Account #3 - UTC DevFund
0.89370098 BTC

Cheers - usukan

[fabietech]

Stage 3 - addition of "liteStake" code to improve UTC staking


Unnecessary delays make me anxious - so I always try to avoid them.

Accordingly - I have topped up the UTC Dev Fund with an additional 0.3 UTC

As it stands - we have enough now to pay for the 3rd and final stage of this work with PressTab (with a little surplus).

PressTab will advise exact cost shortly and I will pay him for this final stage of the work.


Sometime next week PressTab will likely be finished - He will hand over the work and then work with Steven to implement the fork.

I will leave the timing of the fork up to the Community and Steven to decide - but its likely a couple of weeks after PressTab is finished so all stakeholders can update.

Stakeholders = miners, pool, Bittrex and general users etc.


ALMOST DONE

Great work usukan keep it going!




Cheers - usukan

[usukan]

Update

There is nothing to update

PressTab just has his head down working on UTC.

There will be action next week.

Cheers - usukan

[presstab]

Update

There is nothing to update

PressTab just has his head down working on UTC.

There will be action next week.

Cheers - usukan

Can confirm that this is the case

[usukan]

Cheers - thanks PressTab

Update

There is nothing to update

PressTab just has his head down working on UTC.

There will be action next week.

Cheers - usukan

Can confirm that this is the case

[alenevaa]

As far as I can remember I faced with several type of errors/bugs while using ultracoin wallet on the pool...

3. When wallet makes the transaction gathered from many inputs it can include as one input the PoS TX not fully confirmed yet.

 As a result TX is not sending immediately because wallet gets the RPC error.
 This TX sends after a while (from several hours to one day) or it can be stuck completely and it needs manual resend.

I don't have examples but I've seen this anomaly several times.

The fresh example.

TX f0d3a4e0b8a520ed5a2685283db5b4f89c6866fd4bdcde39467d9073f64b2487 was not sent immediately because it has CoinStake input b22216d1d85bcc14f5d8fd6ca693be9b7eefc83fa12e1efd9efa9ab604f5cc4d

[presstab]

As far as I can remember I faced with several type of errors/bugs while using ultracoin wallet on the pool...

3. When wallet makes the transaction gathered from many inputs it can include as one input the PoS TX not fully confirmed yet.

 As a result TX is not sending immediately because wallet gets the RPC error.
 This TX sends after a while (from several hours to one day) or it can be stuck completely and it needs manual resend.

I don't have examples but I've seen this anomaly several times.

The fresh example.

TX f0d3a4e0b8a520ed5a2685283db5b4f89c6866fd4bdcde39467d9073f64b2487 was not sent immediately because it has CoinStake input b22216d1d85bcc14f5d8fd6ca693be9b7eefc83fa12e1efd9efa9ab604f5cc4d

Search your debug.log file for this txid and see if there are any interesting logs about it.

[Official Ultracoin Team]

Update on PressTab - New and improved Ultracoin - wallets and hardfork to the future - COMING VERY SOON!



Cheers - usukan

[usukan]

UPDATE

PressTab reports that things are going well and UTC is coming along great.

He is hoping to have most of the code incl. liteStake polished up this weekend for next week.

Taking a bit longer than he expected but to be honest I was expecting exactly that.  The UTC code was a mess and he has had to do a lot to straighten it all out.

Please remember - that in all my discussions with PressTab I have emphasised the importance of getting everything right - rather than rushing things through just to get finished.  I want to get this right first time and for it to be a solid step into the future - not a return to square one for another try.

The timing for the hardfork (depending on Steven's availability) will be 1-8 May OR 15-21 May OR  22 - 28 May.
I will leave this up to Steven and PressTab to arrange and communicate to the Community.
PressTab is busy 8-14th May.

We will need at least 2 weeks to give all stakeholders (Pool/Alenevaa, Bittrex, miners and general users) time to update wallets before the fork.

I have paid PressTab for the liteStake implementation which he will add shortly to UltraCoin.
https://blockchain.info/tx/ed940fd1ecd9c01f38585679ad660b7f51a839a0815ec5df6cca18864c5200db
There is a small surplus in the UTC DEv Fund (0.18084298 BTC)


Thats all for now - will update again in a few days when there is more news and I have had some more discussions with Steven.

Basically - we can look fwd to a nice hardfork next month - and a fresh clean Ultracoin to take us into the future with style.

Everyone on the correct path please.


Cheers - usukan

[alenevaa]

As far as I can remember I faced with several type of errors/bugs while using ultracoin wallet on the pool...

3. When wallet makes the transaction gathered from many inputs it can include as one input the PoS TX not fully confirmed yet.

 As a result TX is not sending immediately because wallet gets the RPC error.
 This TX sends after a while (from several hours to one day) or it can be stuck completely and it needs manual resend.

I don't have examples but I've seen this anomaly several times.

The fresh example.

TX f0d3a4e0b8a520ed5a2685283db5b4f89c6866fd4bdcde39467d9073f64b2487 was not sent immediately because it has CoinStake input b22216d1d85bcc14f5d8fd6ca693be9b7eefc83fa12e1efd9efa9ab604f5cc4d

Search your debug.log file for this txid and see if there are any interesting logs about it.

I've searched through debug.log but this TX ID occurs only once. I think when it's successfully included in the blockchain.

Code:

SetBestChain: new best=00000fb47adfe5a4a0ee  height=1698322  trust=121968257  date=04/13/16 12:43:20
ProcessBlock: ACCEPTED
  nActualTimespan = 45318 before bounds
GetNextWorkRequiredV5 RETARGET
nTargetTimespan = 14400    nActualTimespan = 16704
Before: 1e0fffff  00000fffff000000000000000000000000000000000000000000000000000000
After:  1e0fffff  00000fffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ThreadRPCServer method=sendtoaddress
CommitTransaction:
CTransaction(hash=34396b710c, nTime=1460551404, ver=1, vin.size=3, vout.size=2, nLockTime=0)
    CTxIn(COutPoint(f0d3a4e0b8, 0), scriptSig=3044022050f757cbcc959373)
    CTxIn(COutPoint(aa97eae6f1, 0), scriptSig=3044022054b6660bf2c5a9da)
    CTxIn(COutPoint(3ef39fa1d5, 0), scriptSig=3045022100c6a1d8c743ee95)
    CTxOut(nValue=0.00508127, scriptPubKey=OP_DUP OP_HASH160 a429847fce7c70658a4599b2045ca6d9fd745f98 OP_EQUALVERIFY OP_CHECKSIG)
    CTxOut(nValue=289.00743799, scriptPubKey=OP_DUP OP_HASH160 57591825327f2543be95b82d831ccb151911a784 OP_EQUALVERIFY OP_CHECKSIG)
keypool keep 3160
AddToWallet 34396b710c  new
WalletUpdateSpent found spent coin 281.00015807utc f0d3a4e0b8a520ed5a2685283db5b4f89c6866fd4bdcde39467d9073f64b2487
WalletUpdateSpent found spent coin 6.00363832utc aa97eae6f1ae333d17d6892d7082cb1ed79ed8a5cb56d06ef2f9ee0accdf50b7
WalletUpdateSpent found spent coin 2.00872297utc 3ef39fa1d576ef929af6817c8c4a0a03f77317aa36637e15ae9ade0592983e90
CTxMemPool::accept() : accepted 34396b710c (poolsz 1)
Relaying wtx 34396b710c
received block 0000062077efaf78fa69

[presstab]

I've searched through debug.log but this TX ID occurs only once. I think when it's successfully included in the blockchain.

Code:

SetBestChain: new best=00000fb47adfe5a4a0ee  height=1698322  trust=121968257  date=04/13/16 12:43:20
ProcessBlock: ACCEPTED
  nActualTimespan = 45318 before bounds
GetNextWorkRequiredV5 RETARGET
nTargetTimespan = 14400    nActualTimespan = 16704
Before: 1e0fffff  00000fffff000000000000000000000000000000000000000000000000000000
After:  1e0fffff  00000fffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
ThreadRPCServer method=sendtoaddress
CommitTransaction:
CTransaction(hash=34396b710c, nTime=1460551404, ver=1, vin.size=3, vout.size=2, nLockTime=0)
    CTxIn(COutPoint(f0d3a4e0b8, 0), scriptSig=3044022050f757cbcc959373)
    CTxIn(COutPoint(aa97eae6f1, 0), scriptSig=3044022054b6660bf2c5a9da)
    CTxIn(COutPoint(3ef39fa1d5, 0), scriptSig=3045022100c6a1d8c743ee95)
    CTxOut(nValue=0.00508127, scriptPubKey=OP_DUP OP_HASH160 a429847fce7c70658a4599b2045ca6d9fd745f98 OP_EQUALVERIFY OP_CHECKSIG)
    CTxOut(nValue=289.00743799, scriptPubKey=OP_DUP OP_HASH160 57591825327f2543be95b82d831ccb151911a784 OP_EQUALVERIFY OP_CHECKSIG)
keypool keep 3160
AddToWallet 34396b710c  new
WalletUpdateSpent found spent coin 281.00015807utc f0d3a4e0b8a520ed5a2685283db5b4f89c6866fd4bdcde39467d9073f64b2487
WalletUpdateSpent found spent coin 6.00363832utc aa97eae6f1ae333d17d6892d7082cb1ed79ed8a5cb56d06ef2f9ee0accdf50b7
WalletUpdateSpent found spent coin 2.00872297utc 3ef39fa1d576ef929af6817c8c4a0a03f77317aa36637e15ae9ade0592983e90
CTxMemPool::accept() : accepted 34396b710c (poolsz 1)
Relaying wtx 34396b710c
received block 0000062077efaf78fa69

Thanks. As I am going through the staking code, I am wondering if this is from the non standard code here. From what I see the actual commit transaction code is fairly standard (except for a caching mechanism that was added). Will keep my eyes out for anything that could be causing this.

As I begin to finalize the wallet code, I will need a few volunteers to test a beta version of the wallet. Those volunteers would need to have a regular amount of staking, and be able to confirm that the new wallets staking mechanism works well.

Edit - I would like to also remove the irc peer discovery, which is seen by many to be a security vulnerability, and is quite frankly not needed. I can throw my block explorer client in as a seed node, does anyone else have a node that they would like added as a seed node?

[usukan]

As I begin to finalize the wallet code, I will need a few volunteers to test a beta version of the wallet. Those volunteers would need to have a regular amount of staking, and be able to confirm that the new wallets staking mechanism works well.

Sure - I will try it out.

Cheers

[usukan]

This was the most comprehensive list of nodes - supplied by bathrobehero 1 March 2016.

addnode=210.246.3.33:49485
addnode=198.27.82.163:44100
addnode=200.168.43.203:58640
addnode=68.193.58.112:57200
addnode=142.161.136.169:56136
addnode=87.98.166.129:39673
addnode=75.167.180.100:53533
addnode=37.24.144.104:51561
addnode=118.90.0.168:64076
addnode=104.172.24.79:63225
addnode=80.68.200.6:3271
addnode=94.192.63.70:49918
addnode=108.44.192.182:53762
addnode=118.90.0.168:56233
addnode=95.24.65.253:60059
addnode=14.162.144.163:50096
addnode=83.251.171.80:60192
addnode=72.211.200.160:41982
addnode=72.181.81.245:54775
addnode=216.19.181.63:46433
addnode=82.140.75.120:60158
addnode=187.126.179.183:50210
addnode=108.193.211.156:56354
addnode=77.121.161.7:57829
addnode=213.24.134.237:25689
addnode=122.168.7.78:51974
addnode=89.101.225.26:64292
addnode=167.114.156.87:48363

This node seems to be quite reliable?

addnode=198.27.82.163:44100

Edit - I would like to also remove the irc peer discovery, which is seen by many to be a security vulnerability, and is quite frankly not needed. I can throw my block explorer client in as a seed node, does anyone else have a node that they would like added as a seed node?

[alenevaa]

On the block reward - the current plan can be summarised:

Change notes:

Change to 10 UTC per block pending new update
10 UTC per block - 4,000,000
5 UTC per block - 6,000,000
2.5 UTC per block - 8,000,000
1.25 UTC per block - 20,000,000
1 UTC per block - 25,000,000
.5 UTC per block - 30,000,000
.25 UTC per block - 40,000,000
.125 UTC per block - 50,000,000
.01 UTC per block - 208,145,600

Change to 2% pending new update
1.5% per year at block 4,000,000
1% per year at block 8,000,000


Community - Please discuss.

Thanks - usukan

As I can understand Stake (PoS) is 2% per year right now.
And holder will get 2% only in theory. It'll be less in real life.
Is it worth to accumulate ultracoin with so low stake rate?

Why not to revert to 5.2%/year as it was before fork? It'll not increase inflation but incetivezed people to hold and not to dump.

In fact I don't have much UTCs. I'm just curious!

What do you think guys?

[usukan]

Rolled this one around - conclusion is that I support actually.

Thanks for your ideas here Alenevaa.

Will have an effect on inflation but IMO the holding incentive is more significant.

more opinions please.

Cheers - usukan

On the block reward - the current plan can be summarised:

Change notes:

Change to 10 UTC per block pending new update
10 UTC per block - 4,000,000
5 UTC per block - 6,000,000
2.5 UTC per block - 8,000,000
1.25 UTC per block - 20,000,000
1 UTC per block - 25,000,000
.5 UTC per block - 30,000,000
.25 UTC per block - 40,000,000
.125 UTC per block - 50,000,000
.01 UTC per block - 208,145,600

Change to 2% pending new update
1.5% per year at block 4,000,000
1% per year at block 8,000,000


Community - Please discuss.

Thanks - usukan

As I can understand Stake (PoS) is 2% per year right now.
And holder will get 2% only in theory. It'll be less in real life.
Is it worth to accumulate ultracoin with so low stake rate?

Why not to revert to 5.2%/year as it was before fork? It'll not increase inflation but incetivezed people to hold and not to dump.

In fact I don't have much UTCs. I'm just curious!

What do you think guys?