How to set up an ucoin node?

[Arcurus]

@cgeek

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.

isnt it that with PERCENTROT = 2/3, 2/3 of the members must compute with higher then the min difficulty
so 1/3 would compute with the min difficulty
lets say, that only those with the min difficulty take part in computing
then it would need 51% of 1/3 of the members to attack the network to make an 51% attack. so round about 1/6 of the members to make an double spent. of course they would need it for at least some blocks, to have the longest chain, so they would in fact need little bit more.
in our example with 7 members it would theoretically only need little bit more then 7 * 1/6, of course they could only undo one block confirmation. but with lets say 60 members they would need little bit more then 7 members and could undo round about 6 block confirmations. (if BLOCKSROT > mining members)

of course these attack would only function for a short time period.

if lets say the attacker has on top of that 10 times the work speed then normal users and uses this speed for all his attacking accounts, then he would need 1/60 of the members to attack. with 100 times more speed he would need 1/600, but at least 100 mebers
therefore it looks that its good to have an BLOCKSROT that is far smaller then the current member count, so that still 90% or more of the members could take part in the mining with high efficiency.

of course an BLOCKSROT much smaller then the member count would allow 51% of the members to take over the complete blockchain. if BLOCKSROT > member count then it would need round about 2/3 of the members to take completely over.

just some thoughts

[Arcurus]

thx for the link to the doc:

the chapter Joiners, Actives, Leavers (block fingerprint based memberships I do not understand fully, what is it about?

another question,
so an member can only become a leaver, if he has less then 3 valid certifications?
so no distance rule applies here?
so if 4 people come together and certify each other, they can only become leavers if a big enough majority blocks the new certification transactions of these members?

another question to the web of trust:
if 4 members come together and make only outgoing certifcations to each other and not to the other members, then no new member could join or?

[Arcurus]

@cgeek

ucoind wizard network

yea thx! the problem just is, that i dont know yet, what parameter for the ip i have to choose, because the node is currently running in an local node in an virtual machine. so i dont know how to configer it, that it could receive connections from outside.

here is the current configuration:
? IPv4 interface: eth0 10.0.2.15
? IPv6 interface: eth0 fe80::a00:27ff:fe18:b67a
? Port: 8999
? Remote IPv4: eth0 10.0.2.15
? Remote IPv6: fe80::a00:27ff:fe18:b67a
? Remote port: 8999
? Does this server has a DNS name? No

the displayed alternatives also did not sound better

one more question: how can I send money to someone who is no member?

[cgeek]

OK I wanted to have a closer look, and here is what happens with PERCENTROT = 2/3:

We can see that we always have 1/3 of the members which have higher difficulty than the minimum.

This is not what I expected, so I wanted to better know the impact of PERCENTROT. Here are the results:

We can see that, with 100 writers (Np + 1 = 99 + 1):

PERCENTROT | Writers with non-minimal difficulty
---------- | -----------------------------------
0.50       | 24%
0.67       | 33%
1.00       | 49%
1.50       | 74%
2.00       | 99%

So if we wanted to have 90% of the writers to be able to compute at any time, we would need PERCENTROT = 1.80.

---

@Arcurus

wouldnt it be more secure to use something like a trust level for each user?

I’m note sure, I think someone can completely change between t and t+1. May he be trustable now, and one second after he may betray you. And the opposite is also true. Trusting people is a dangerous game

That’s why I insisted on WoT being a trust in identities, not in people behaviors.

I really prefer symmetric approach: people are equal towards block writing.

@Arcurus

the chapter Joiners, Actives, Leavers (block fingerprint based memberships I do not understand fully, what is it about?

It just says a membership (the document saying “I want to be a member, I am alive” to the system) must refer to a previous block (so a membership cannot be written now for a future use in 10 years, because it would need to refer to a recent enough block’s hash, which is not predictible).[quote=“Arcurus, post:22, topic:619”]
so an member can only become a leaver, if he has less then 3 valid certifications?so no distance rule applies here?
[/quote]

The rules have to be taken together:

Excluded

• Each PUBLIC_KEY with less than [sigQty] valid certifications or whose last membership is either in Joiners or Actives is outdated must be present in this field.
• Each PUBLIC_KEY whose last membership occurrence is either in Joiners or Actives and is outdated must be present in this field.

Joiners, Actives (Web of Trust distance constraint)

• A given PUBLIC_KEY cannot be in Joiners if it does not exist, for each WoT member with at least [sigWoT] valid certifications emitted (incoming block excluded), a path using certifications (this block included), leading to the key PUBLIC_KEY with a maximum count of [stepMax] hops. Thus, such a path uses maximum [stepMax] certifications to link a member to PUBLIC_KEY.

So, someone who do not renew its membership will see its status matching Excluded rule, and will be excluded. On the other side, if the member renews, he will have to face the WoT distance constraint: if he does not have the right certifications making distance acceptable toward concerned members, he won’t be able to renew.

The composition of these two rules makes what we usually call “WoT distance rule”.

From this, you understand that the WoT distance rule is not applied continuously. The rule is applied only when the member renews its membership. Yes, that is true. And normal! Imagine if it wasn’t the case and the WoT distance rule applied continuously: what if one member suddently becomes too distant from all the WoT, who is to be kicked? The member or the rest of the WoT?

From the relativity principle, we cannot answer this question. We don’t know who is better a member than another. Instead, we prefer to rely on the membership renewal mechanic: when the member renews, we consider he is the potential part to be kicked.

That’s why your example of the 4 individuals certifying each other won’t work, fortunately

@Arcurus

yea thx! the problem just is, that i dont know yet, what parameter for the ip i have to choose, because the node is currently running in an local node in an virtual machine. so i dont know how to configer it, that it could receive connections from outside.

@urodelus runs uCoin from a VM, maybe he can help you!

@Arcurus

how can I send money to someone who is no member?

Just paste its public key in Sakia:

[Arcurus]

@cgeek

So if we wanted to have 90% of the writers to be able to compute at any time, we would need PERCENTROT = 1.80.

you meant if we want to have 90% of the writers to not compute with min difficulty?

Lol, just came to the same conclusion for the distance rule, that it would be solved if members have to reapply, like it is done already. sometimes it is good to take a brake
only thing which is still there is, that 4 members could block new members until they must be renewed.
in worst case they just managed to renew their membership / or joined and then block the renew of all other accounts, not nice but possible or?

yea just past the the public seems very easy Maybe I was lost to much in thinking about membership stuff, so that I totally forgot for a moment that also non members can of course have accounts

[cgeek]

@Arcurus

you meant if we want to have 90% of the writers to not compute with min difficulty?

No no, I do mean 90% with the min difficulty, while 10% get a higher difficulty.

@Arcurus

only thing which is still there is, that 4 members could block new members until they must be renewed.

That’s why^TM the WoT distance rule says:

for each WoT member with at least [sigWoT] valid certifications emitted (incoming block excluded), a path using certifications

So members who stop certifying others won’t be checked for distance rule because of course, there could not possibly exist any path from them to newcoming/renewing members!

[Arcurus]

@cgeek

No no, I do mean 90% with the min difficulty, while 10% get a higher difficulty.

… now I got lost…

PERCENTROT	Writers with non-minimal difficulty
1.50	74%
2.00	99%

with 1.8 there should be around 90% Writers with non-minimal difficulty or do you mean 1.8%, i would ques that with round about 0.1 you would get round about 90% with the min difficult, or, at least without calculating the math.floor?
with math.floor it gets little bit more tricky. so or so, wouldt it be better to rewrite the formula to Math.floor(powMin * percentRot *…)? otherwise the difficulty would only increase in faculties of powMin or?

var nbZeros = Math.max(powMin, powMin * Math.floor(percentRot * (1 + nbPreviousIssuers) / (1 + nbBlocksSince)));
by the way, with percenRot >=2 I would not expect anybody to compute with powMin if the formula above is correct

@cgeek

So members who stop certifying others won’t be checked for distance rule because of course, there could not possibly exist any path from them to newcoming/renewing members!

hihi, therefore i said in my example 4 members because currently sigWot is 3 in our test currency
so in the outlined attack one member could certify 3 members and these three members do not certify other members, not fair but possible or?

another question, what is your plan for the next steps to do?

[Arcurus]

@Arcurus

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

after some thinking here some alternative suggestion:
set the initial difficulty for newcomers who never have written any block:
nbZeros = powMin +powExtraForNewcommers
with for example powExtraForNewcommers = 1
if the hash is hex then this increases the difficulty with 16X or is it binary?, then i would suggest 4

calculate the rounding with powMin, this would allow an not so jumping growth of needed work
var nbZeros = Math.max(powMin,Math.floor(powMin * (1 + nbPreviousIssuers) / (1 + nbBlocksSince)));

use this formula
if ((1 + nbPreviousIssuers) / (1 + nbBlocksSince))) < 1)
var nbZeros = Math.min(powMin + powExtraForNewcommers,Math.floor(powMin * (1 + nbBlocksSince)) / (1 + nbPreviousIssuers));
this would increase the difficulty if a member does not write his expected block at his expected time frame. it would at max increase to the newcommers difficulty.

by the way percentRot is not in the formula, but it could be directly included with using if statements if needed, but i dont think that we need it

of course BLOCKSROT in this case should always be bigger then currentwritingmembers

what do you think?

the difficulty with this formula should look something like that:

 powNewlyWrittenBlock             
 \                       
  \     
   \         ----------------------- powNewcommer     
     \     /
       \_/
      powMin

x=nbBlocksSince
y= powDifficulty

[cgeek]

@Arcurus

… now I got lost…

You are right, sorry, indeed 1.8 means 90% with a non-minimal difficulty. A 0.21 would give us 10%.

@Arcurus

by the way, with percenRot >=2 I would not expect anybody to compute with powMin if the formula above is correct

Yep.

@Arcurus

wouldt it be better to rewrite the formula to Math.floor(powMin * percentRot *…)?

At least it is possible, a v0.2 of the protocol is to be written. We can only change this formula during protocol evolution, which will be rare inside an existing currency.

Do not hesitate to add an issue for that

@Arcurus

so in the outlined attack one member could certify 3 members and these three members do not certify other members, not fair but possible or?

Yes absolutely possible. But they won’t be checked for WoT rules of future newcomers/renewers, so these last won’t bother about the 3 members not certifying anyone.

@Arcurus

another question, what is your plan for the next steps to do?

Which steps? In terms of development, I have roughly 2 main milestones today:

• ucoin v0.13
  This version will embed several fixes & improvements to current version

• protocol v0.2
  This will be a major release (probably 1.0), with a new testing currency for the occasion. This is where you can still make suggestions of improvement, deep changes.

[cgeek]

@Arcurus

if the hash is hex then this increases the difficulty with 16X or is it binary?, then i would suggest 4

I already have made an issue for that, and plan to have a 2X, but right now this is 16X. Anyway, we can scale this if we want.

@Arcurus

calculate the rounding with powMin, this would allow an not so jumping growth of needed work

Agreed. We would have this kind of difficulty then:

PERCENTROT | Writers with non-minimal difficulty
---------- | -----------------------------------
0.50       | 40%
0.67       | 53%
1.00       | 80%
1.25       | 100%

@Arcurus

what do you think?

Well I am not sure. Because, if I understand well your formula, this will add a handicap to newcomers, but this won’t prevent them to compute with this difficulty once, and then make their attack with powMin difficulty.

Or did I miss something?

[Arcurus]

@cgeek

Do not hesitate to add an issue for that

great, i will look into it for sure

@cgeek

Yes absolutely possible. But they won’t be checked for WoT rules of future newcomers/renewers, so these last won’t bother about the 3 members not certifying anyone.

but the one with the 3 certifications would bother or? and nobody could reach this one, so no newcommers anymore?

@cgeek

probably 1.0

when do you round about recommend to go to beta test like bitcoin is now? so one could start using the currency and what must be done until that

[quote=“cgeek, post:30, topic:619”]
to have a 2X
[/quote]?
+1

@cgeek

Or did I miss something?

hmm, this suggestion would create a kind of queue for the writing members.
if you reach your optimal position in the que you write with powMin
If you are too slow you write at worst with powNewcomer

SuperHighPow------------------ PowMin-------------------powNewcomer

this would have some benefits.
with the old formula, you can simply not write, with your attacking members and wait until the honest members have a higher difficulty.
so lets say you have percentrot of 1 that means that round about 80% have an non mininimal difficulty.
therefore you need only 51% of the remaining 20% to make an attack. with the alternate formula, this attack would not work because they would mine with powNewcomer.

of course he could try another attack. he could try to bring his attacking members in the que…
but with an high powNember the generated que would be very random, so its attacking members would most likely not be in an row.

So it would reduce attacks that are possible with an high percentRot.

second under the assumption that BLOCKSROT is bigger then currentwritingmembers (in fact BLOCKSROT should be the t-1 currentwritingmembers or something like that) and under the assumption that you use an high percentRot:
It could create an more equal creation of blocks among the members. And it would encourage members not to stay offline too long and of course an higher percentRot would lead to less power consumption because less use of pow.

[Arcurus]

for mathematicians I try to build a formula without an if
here my first try, its not fully ready yet, but looks already beautiful

n = nbPreviousIssuers min 1
b = nbBlocksSince min 1

que = (n+b)(n-b) / nb

var nbZeros = powMin + Math.floor(que^2);

if b > n then nbZeros = Math.Min(powMin + powExtraForNewcommers, nbZeros)

[Arcurus]

or even more easy:
n = nbPreviousIssuers min 1
b = nbBlocksSince min 1

var nbZeros = powMin + Math.floor((n-b)^2);

or more easy with if statements

var nbZeros = powMin + n - b

if b>n
var nbZeros = powMin + b - n

or with percentRot
var nbZeros = max(powMin, powMin + Math.floor( n * percentRot ) - b

[Arcurus]

or with target instead of zeros (hash < target)

n = nbPreviousIssuers
b = nbBlocksSince

var target = powTargetMin + powTargetMin * ((n-b)/(b+1))^4;

for b to infinity it would still be 1. that means powTarget would be then doubled

[Arcurus]

Hi, i created here now an discussion for the block writing stuff: Discussion of some alternative block writing method