How to set up an ucoin node?

Hello,
now with Sakia running I want to try the next step to setup an node on unbuntu/ mint in an orcale virtual machine:

$ wget -qO- https://raw.githubusercontent.com/ucoin-io/ucoin/master/install.sh | bash
$ ucoind init
$ ucoind sync metab.ucoin.io 9201
$ ucoind start

First of all I am new in the gnu linux world but I try my best to find out how it functions, so please be patient with me :smile:
so now to ucoin first of all is this still the recommended way of installing ucoin? because i also found this instruction here:
https://github.com/ucoin-io/ucoin/issues/205#issuecomment-154417286

But now back to the work:
wget -qO- https://raw.githubusercontent.com/ucoin-io/ucoin/master/install.sh | bash
was functioning fine
after that i restarted the terminal as I was asked to.
now I wanted to start: ucoind init
but he could not find it: ucoind: command not found
so i was searching for it and found it in ~/.ucoin/bin
that looked strange, because it is marked invisible and only in my local users home folder, so i guess it was only installed for the current user :confused:
nevertheless i tried it manually but this error comes:
/usr/bin/env: node: No such file or directory

so I guess the paths are missing, but why?
Must be some very easy I think, but as said I am currently not much used to installing stuff on gnome linux but want to learn!

Thx for your patience,
Arcurus

P.s.: also installing nvm was not functioning as expected, it also could not find the command. so i guess also the paths are missing and it is only installed in the current user folder…

Yes install.sh is the recommanded way, both uCoin or NVM are installed in user space. uCoin will be installed in ~/.ucoin/ folder.

If your installation went well, you should have the following lines in your ~/.bashrc file:

export UCOIN_DIR="/home/cgeek/.ucoin"
[ -s "$UCOIN_DIR/ucoin.sh" ] && . "$UCOIN_DIR/ucoin.sh"  # This loads ucoin.sh

You should not have “cgeek” but your own user name instead.

Also, what user do you use to launch above commands? And which one for ucoind init?

1 « J'aime »

UPDATE: ok I created the bash file now manually. now i can start ucoind… lot of questions coming… lets see

UPDATE: lol, answered now a lot of questions, dont now if answered right… now its downloading the blockchain i guess :slight_smile: 10%…

UPDATE: Status: Peer J78bPUvLjxmjaEkdjxWLeENQtcfXm7iobqB49uT1Bgp3
All done.

UDATE: JUHUUU he seems to do something:
[PM2] Starting /home/arcurus/.ucoin/bin/ucoind in fork_mode (1 instance)
[PM2] Done.

UPDATE:
Yea J78bP in Sakias Network stats seems to be me or? :smiley:
But now its time to sleep…

thx for your help!


sorry, i cannot find any file called .bashrc not in the home, nowhere
i have only one user. and as far as I remember i did not have do give any sudo rights…

this is the user home:
arcurus@arcurus-VirtualBox ~ $

Ucoin is here:
arcurus@arcurus-VirtualBox ~/.ucoin $
or here:
/home/arcurus/.ucoin/

DISTRIB_ID=LinuxMint
DISTRIB_RELEASE=17.1
DISTRIB_CODENAME=rebecca
DISTRIB_DESCRIPTION="Linux Mint 17.1 Rebecca"
NAME="Ubuntu"
VERSION="14.04.1 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.1 LTS"
VERSION_ID=“14.04”

yea just mined my first ucoin block :smiley:

Done: 000001CCC857EB3D96BCAF924F3C610805CAF76C in 202.12s (32915 tests

By the way, it looks like ucoin is attack-able by something similar to coin age attack in POS coins that work with coin age. but in ucoins case with user ¨hashing¨ age.
But I have to look closer at the algorithm first…

I don’t see your node in Sakia, do you know your public address/port?

Currently the node ist just runnung to test on my laptop, so its currently not there all the time :smile:
But for me it is listed in Sakia as Arcurus.

127.0.0.1 8999
I guess I have chosen the wrong public address, in the configuration step, maybe i can reconfigure it, so that it takes the internet ip, but im not sure if i have then to enable some kind of port forwarding on the rooter, so that other nodes can connect to me both way?

at least two blocks from my node seem to have reached the network…

Do you host your node on an VPS, or how do you do it?

By the way 455 tests/s for the hashing sounds very very slow, how much tests per seconds does your node have?

Arcurus, is 455 tests/s the max or the proof ? More you run faster, more the difficulty increase (0000xxxx -> 00000xxxx…) and finally your node had to wait the others…
That’s the rule !

My node run at 70 tests/s (max 700, I limit the CPU to 10%).

lol, then [quote=“urodelus, post:7, topic:619”]
My node run at 70 tests/s (max 700, I limit the CPU to 10%).
[/quote]

lol then my node is really fast with 425 tests/s max and Proof will ~383 tests/s :smile:

On which computer do you run your node? local or on an server?
virtual machine or direct?

And do you know if there is an more detailed description about the proof algorithm? I want to think though if the current algorithm could be attacked through an ¨user age¨ attack, something similar to an coin age attack in proof of stake coins (pos) that use coin age for pos.

It is written here: https://github.com/ucoin-io/ucoin/blob/master/doc/Protocol.md#proof-of-work

Don’t expect an explanation in this document, it is a technical specification without much details for easing interpretation.

It is the only document we have currently.

Now I found the formula:
PERCENTROT: 2 / 3
BLOCKSROT: 20,
// So we can have nbPreviousIssuers = 0 & nbBlocksSince = 0 for someone who has never written any block
otherwise: nbPreviousIssuers = dao.getIssuersBetween(last.number - 1 - conf.blocksRot, last.number - 1, next);
that means by default the unique issuers from around the last 20 blocks counted from *the users last written block

var nbZeros = Math.max(powMin, powMin * Math.floor(percentRot * (1 + nbPreviousIssuers) / (1 + nbBlocksSince)));

do I understand this right: if I never minded a block
nbZeros required = Math.max(powMin, powMin * Math.floor(percentRot * (1 + 0) / (1 + 0)));
= Math.max(powMin, powMin * Math.floor(percentRot * 1));
so I guess powMin?

(1 + nbPreviousIssuers) / (1 + nbBlocksSince))
that means the more blocks are minded since i last mined the block the more easy it is for me?
and the more different issuer are there in the last 20 blocks by default before i mined my last block the more difficult is it for me?

so for example if 2 blockes are mined since my last block, and three different members mined the last 20 blocks before my last block then it would be 3/2 (not counting the +1s for the moment)
so multiplied with default PERCENTROT 2/3 it would be 2/3 * 3/2=1 so the same if i never mined a block

hmm quite tricky.

I don’t get your sentence :grin: but it means the unique issuers around the last 20 blocks for a particular user. Indeed for someone who has never written any block this means $nbPreviousIssuers = 0$ & $nbBlocksSince = 0$.[quote=“Arcurus, post:10, topic:619”]
do I understand this right: […] so I guess powMin?
[/quote]

Good!

Yes.

The more different issuers are there in the last 20 blocks before your last written block, the more difficult it is. So just after you wrote a block, you cannot immediately write another one if other users wrote blocks before you.

Your example with 3/2 is exact.

The goal of this rule is simply to penalize people who just wrote a block, letting others to also write blocks.

@cgeek thx for your answer :smile:
yea try to get used to java script, was my first study of codefiles written in javascript… It seemed that it happen to confuse me a little bit. so please apologize for the messed up sentence above :smile:

especially this, I guess asynchronous function calls, look funny in java script :smile:

For the blockchain security… I just though about an attack scenario

With the default settings it would need round about 1/6 of the members to make a double spend attack, because the other 2/3, have higher difficulty if they mined blocks before or?

If then an user miner uses also asic or gpu with lets say 10 times or 100 times the speed he would need 1/600 of the members for making double spends?

Another question. Now after getting two universal dividends, the money base happen to be increased… So shouldn’t my sakia client calculate that in an reduce the display value counted in UDs.so my last UD with currently 10% inflation per day should be displayed now as 0.9 UDs or? so in total i should have 1.9 uds now and not 2?

And wouldnt it better to display / give in daily uds instead of yearly? Ok currently one day simulates one year, but for the future? By default i would set also the display value to daily UDs, or even better 1/100 of an daily UD and give this unit an nice default name, because it would be there for hopefully long long time :smile:

You can have two UD if UD(N)=UD(N+1). This happens when we have big members fluctuations, which happens often in our small community.

I made the choice to not display UD by default because accountability in this referential can be disturbing, with the same transaction not worthing the same value from day to day.

how is the exact formula for the UD? I just thought that UD per member is increasing 10% per year?

In sakia, open the tab “Information” :wink:

1 « J'aime »

ah that means, that the value of UD is not increasing if enough new members join :smile:

Do not worry too much about this, uCoin code has begun to switch to ES6 JavaScript, which allows for classical synchronous code-like (but under the hood we still are with async code) and is much simpler to understand.

Example of ES6 code: https://github.com/ucoin-io/ucoin/blob/master/app/service/BlockchainService.js#L250

Double spending is absolutely impossible at a valid blockchain level. You might be talking about double writing, which is something different and does not invole money.

Let’s say you talk about double writing. In such a case, let’s consider we have:

  • 3 members (A, B, C), 1 of them is ASIC+GPU user ©
  • last blocks are issued like this: ABC (A wrote bloc n - 2, B wrote n - 1 and C worte n the current bloc)
  • common difficulty is powMin = 4 (this is the most probable, even with only 1 writer alone)

So here, for user C:

NB_ZEROS = MAX [ PoWMin ; PoWMin * FLOOR (percentRot * (1 + nbPreviousIssuers ) / (1 + nbBlocksSince)) ]
NB_ZEROS = MAX [ 4 ; 4 * FLOOR (2/3 * (1 + 2 ) / (1 + 0 )) ]
NB_ZEROS = MAX [ 4 ; 4 * FLOOR (2/3 * (3) / (1)) ]
NB_ZEROS = MAX [ 4 ; 4 * 2 ]
NB_ZEROS = MAX [ 4 ; 8 ]
NB_ZEROS = 8

So difficulty of C is 8 zeros for his next proof, since he is the last block’s issuer. What does this mean in technical terms?

If we have a difficulty powMin = 4 for an average generation of 1 block every 10 minutes, a difficulty of 8 is $16^{8 - 4} = 65536$ times more difficult than 4.

If we have a difficulty powMin = 5 for an average generation of 1 block every 10 minutes (it is the case today with MB with 7 computing members), we have:

NB_ZEROS = MAX [ PoWMin ; PoWMin * FLOOR (percentRot * (1 + nbPreviousIssuers ) / (1 + nbBlocksSince)) ]
NB_ZEROS = MAX [ 5 ; 5 * FLOOR (2/3 * (1 + 6 ) / (1 + 0 )) ]
NB_ZEROS = MAX [ 5 ; 5 * FLOOR (2/3 * (6) / (1)) ]
NB_ZEROS = MAX [ 5 ; 5 * 4 ]
NB_ZEROS = MAX [ 4 ; 20 ]
NB_ZEROS = 20

a difficulty of 20 is $16^{20 - 5} = 1,152,921,505,000,000,000$ times more difficult than 5. This probably makes a lot of energy to deploy for only 7 members writing the blockchain :smile:

Also you cannot use ASICs out-of-the-box, since uCoin PoW is not just hash(doc + nonce), it is hash(sign(doc + nonce). This is a completely different computation if I understood right crypto and ASICs. Maybe you can delegue computation to GPU however, I don’t know.

But the order of magnitude of the difficulty for just 7 members was enough to convince me, anyway!

what you mean with absolutely impossible? I meant you spend the coins, the transaction gets lets say in a chain with 3 blocks since the transaction and then you spent it again and create a longer chain with using the outlined attack. the classical double spent in an blockchain chain based scenario :smile:

yea one user alone with asic has no chance, but he could use his asic power for multiple user accounts in the attack.

the attack scenario was more about how many users you need to attack.

in the above outlined attack scenario the attackers did not participate in the mining in the last block.

so their difficulty would be still the mindifficulty

but the other members minded blockes with the current formula these honest members would have a higher difficulty, then the attackers.

but ok, as long as the default for BLOCKSROT only counts 20 blocks for issuers this attack would only be possible if current users are not much bigger then 20. so it seems to be save as long as BLOCKSROT stays much lower then the current active mining users.

but still the asic / gpu attack could be made through using more user accounts.

another topic: where can i find more about the current implementation of the web of trust / which parameters must be met that someone is becoming an member? and which parameters must be met that someone looses his member status? wouldnt it be more secure to use something like a trust level for each user?

I meant impossible at a single blockchain level, but you are talking at fork level. OK it’s more clear to me now :smile:

This would imply the accounts (members) to share their private key, so their ability to certify people, spend their UD and so on. It is very costly, but I admit that is still possible.

Yes you are right in the sense that, if Np (Number of writing participants) > BLOCKSROT, then we have Np - BlocksROT members with the minimal difficulty (= PowMin, the common base of difficulty).

But in the same time, the higher BLOCKSROT the higher the number of required attackers for a successful attack. We could imagine to have BLOCKSROT >> Np, for example 1000 >> 10. In such a case, we would have 10 members with each a difficulty higher than the previous. The problem is: if member1 stops mining, the next block will be hard to mine because member1 had the easiest difficulty, and member2’s difficulty = 16 times harder than member1’s.

That’s why I introduced PercentRot: the difficulty applies only to the fraction PercentRot of the users below BLOCKSROT.

This is typically the case today with MetaBrouzouf: we are 7 writers, and BLOCKSROT = 20. So we have 20 > 7. So today, we have ony 2/3 of 7 which have the lowest difficulty: 4 members, while the 3 others have a difficulty > powMin.

To conclude, a successful attack may occur:

  • for Np < BLOCKSROT: if at least Np * PERCENTROT attackers are computing blocks. For MetabBrouzouf, this currently means 7 * 2/3 = 4 attackers.
  • for Np >= BLOCKSROT: if at least BLOCKSROT * PERCENTROT attackers are computing blocks. For MetaBrouzouf, this means 20 * 2/3 = 14 attackers.

In any case, this suppose the attackers to have a computing power >> to any honest user, otherwise some honest users could still write blocks (because they would compete with attackers and may sometimes win).

Again in the Protocol. This is not an easy read, but you have all the current rules there. You should notably read sections:

  • Member
  • Joiners, Actives, Leavers (block fingerprint based memberships)
  • Joiners, Actives (Web of Trust distance constraint)
  • Joiners
  • Actives
  • Leavers
  • Excluded
1 « J'aime »

Yes you can use:

$ ucoind wizard network