Show Posts - mthcl singapore
Please login or register.

Login with username, password and session length
Advanced search  


Latest Stable Nxt Client: Nxt 1.12.2

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - mthcl

Pages: [1]
Nxt Improvement Proposals / Fixing the blocktimes
« on: August 29, 2015, 10:37:07 pm »
Well, I think it's really time to solve this problem. What I propose, is to adopt a (strongly) modified version of the algorithm described here: https://nxtforum.org/proof-of-stake-algorithm/basetarget-adjustment-algorithm/. Namely:

1. Introduce the interval of values the BaseTarget may assume. Say, [90%; 3000%].

2. BaseTarget changes only at blocks that are multiple of 10.

3. Let T be the mean blocktime of last 10 blocks (in minutes). Then

 3.1 If T<0.9, set New_BaseTarget=Old_BaseTarget*0.93
 3.2 If T>1.1, set New_BaseTarget=Old_BaseTarget*1.1
 3.3 If 1<T<1.1, set New_BaseTarget=Old_BaseTarget*T
 3.4 If 0.9<T<1, New_BaseTarget=Old_BaseTarget*(1-0.7*(1-T))

Of course, if the New_BaseTarget tries to go out of the above interval, just set it to the limiting value.

The above values can be changed, of course, but I think it should be along these lines: we shouldn't allow the BaseTarget to change very quickly, while still allowing it to be adjusted. When doing the hard fork, set Initial_BaseTarget = 300%, say.

An algorithm like this should solve the problem of large blocktimes for good.  Also, it is more secure than the current one, exactly since the blocktime will become more "concentrated" (i.e., the variance will decrease) with it.

Goods / NXT bracelet
« on: August 17, 2015, 09:51:02 pm »
Let me show you what my wife just made:

Anybody can have it for, say, 2500 NXT.

In general, she is very good at beading, making jewellery, etc. See http://www.ataridel.com/ and also http://www.asasdebeleza.com.br/home.html. She (and her friends) can basically make whatever you want (as long as you can describe it sufficiently precisely) in the spirit of things you see on those sites. So, customized orders are accepted   :)

General / what did he find?..
« on: June 22, 2014, 06:39:08 pm »

Quote from: cunicula
Did some more analysis. Nxt is vulnerable to a type of sibyl attack.
Will post the math later. Sorry I missed this earlier. Can we get the developer to rise from the dead so we can fix the mining algorithm?

Waiting for the math.

Nxt Asset Exchange / Total market capitalisation of all assets
« on: June 06, 2014, 08:29:14 pm »
Is it possible to see it somewhere?  It would be interesting to know the total size of the Nxt economy. Maybe, we surpassed the LTC already?..

Transparent Forging / A recent (May 08) chat on PoS forging
« on: May 09, 2014, 11:05:33 pm »
between Sunny King (Peercoin) and Daniel Larimer (Bitshares), http://www.peercointalk.org/index.php?topic=2794.msg24993#msg24993. Nxt mentioned several times, e.g.:

bytemaster (Daniel Larimer): Have you read our DPOS white paper?

bytemaster: I think what we share in common is proof of stake

Sunny King: no

Sunny King: but feel free to give a quick summary for me

bytemaster: In summary, the shareholders continuously elect keys to deterministically sign blocks on a fixed schedule.

bytemaster: clients automatically vote for or against these 'delegates' based upon their performance

bytemaster: blocks can be produced at high speeds

bytemaster: with high reliability

bytemaster: and 100% of shareholder opinion is reflected

bytemaster: but it is automatic in most cases

bytemaster: similar to Nxt transparent forging but instead of random shareholders, a consensus group of professionals that can be fired at will

bytemaster: NXT is soon to implement Transparent Forging

bytemaster: documentation on it is thin

bytemaster: but from what I can gather it allows people to delegate their forging power to other keys

bytemaster: they then 'transparently' select the next address to forge a block

bytemaster: if they do not forge a block, the address is removed from the set of potential addresses for 24 hours

fuznuts: as opposed to delegating based on defined parameters in transparent code

bytemaster: they do not use it today

bytemaster: (from what I can gather... I would love an opportunity to pick their brains for a bit)

fuznuts: DPOS would effectively take out the potentially corrupting "human element" correct?

bytemaster: NXT does too

bytemaster: With NXT every address is a delegate

fuznuts: but I can choose to delegate you

bytemaster: that gets to produce a block proportional to their stake.

fuznuts: which means 51% of the network could do the same and thus achieve a 51% attack?

bytemaster: it would be like having no vote limit on delegates in our system, nor any negative votes

fuznuts: if 51% of the assets are owned by just a few people, that is an issue...or am I missing something?

bytemaster: and then randomly selecting a delegate to vote based upon their total delegated balance

bytemaster: the weakness is of course the randomization process

fuznuts: true

bytemaster: Sunny, Nxt, etc all have bright people

Technical Development Applications / Transparent Forging algorithm
« on: April 23, 2014, 01:30:06 pm »
The following is our joint proposal with ChuckOne and mczarnek about the Transparent Forging.

Below, "the article" means this one: http://www.docdroid.net/bfwb/forging0-4-2.pdf.html

We are considering the future one-block-per-minute regime. The main changes to the current algorithm that we propose are:

(1) there should be an upper limit, i.e., an account with more than X NXT forges as if it had exactly X NXT (e.g., X=5M). Reason: see "conclusions" (the last one) in the end of Section 4 of the article.

(2) there should also be a lower limit, i.e., an account with less than Y NXT does not forge at all. This will make costly those games with non-forging discussed in Section 5 of the article. Also, this would encourage leasing the forging power (so that more people would become happy because they'll receive at least something).

Now, as for the value of Y, it need not be constant, it can actually change! In normal situation (there are not many non-forging events) it can be relatively low, say, 1000NXT. However, if someone is starting playing games (and so there are many non-forging events), then Y increases in order to protect the network.

(3) It would be indeed a good idea to introduce randomness to the TF. The reasons for this were discussed here: https://nxtforum.org/transparent-forging/jftr-randomness-without-cheating/msg11143/#msg11143. The algorithm we propose is in the end of Section 6 of the article, let me reproduce it here:

(a) each forging account must maintain a hashchain of some (large) length (actually, the nodes must maintain them for their accounts), and publish the last hash;
(b) at blocks Nm, m=1,2,3,..., the list of K richest accounts with respect to the effective balance is formed, and this list becomes valid  for blocks Nm+L,...,N(m+1)+L-1;
(c) special ``randomizing'' blocks are forged just in between of every two normal blocks (this can be adjusted, maybe does not need to be so frequent);
(d) randomizing blocks are forged by the accounts from the valid list, e.g., in the cyclic order; they contain the hash from the hashchain preceding to the one already published (so the forger cannot cheat);
(e) to determine the forger of the next block (number n), the random number we use is
sha256(what was there before, sum of hashes in L' last randomizing blocks published before the block n-L).

One may take e.g. N=1440,K=100,L=10, L'=50, but, of course, these constants may be adjusted. In particular, the value of K must be neither too small, nor too large. If it is small, the danger is that the bad guy controls all K top accounts. On the other hand, if it is too large, then some accounts among the top K would be (relatively) small (for a rich guy), so he can start thinking about playing non-forging games.

With this approach, by the way, we can predict the next L forgers (but not more!), which was also a desirable feature of TF, as far as the authors remember.

The point of having the richest accounts do the randomization job is the following: it is probably impossible for the attacker to control e.g. top 100 accounts, that is just too expensive.
And another point: since the accounts must be big, cheating by not publishing the random number now becomes very expensive as well (an account that does not forge the randomizing block when it must to, is banned and so unable to forge normal blocks for some period).

OK. Let the discussion begin.

Alternate Cryptocurrencies / NeXT Horizon
« on: April 01, 2014, 11:47:42 pm »
Here: https://bitcointalk.org/index.php?topic=551666.0.

Anybody understands, what did they do, just copied the code? Or added something too? Did they run into traps?

Transparent Forging / Math of Nxt forging
« on: March 26, 2014, 02:32:34 pm »
Version 0.4.1: http://www.docdroid.net/ahms/forging0-4-1.pdf.html

Added a new section on a "randomization" algorithm.

- The current forging algorithm is only pseudorandom (deterministic but unpredictable), and there is concern whether this situation could be potentially dangerous. I do think that this danger is not very serious, since  the real world will not hesitate in introducing  some ``real randomness'' to the system (because nodes go  online and offline, money are transferred, etc.).

- Nevertheless, it is possible to propose an extra randomization algorithm,  i.e., the network can achieve a consensus on a Uniform[0,1] random number  independent of the previously published data.

- The procedure for obtaining this random number can be roughly  described in the following way.  First k0 accounts (with respect to the inverse weights) choose some ``random"  numbers locally (e.g., take a local output of rand()),  and publish their hashes.  Then, they publish numbers themselves; if the published number does not correspond  to the hash or is not published at all, then the corresponding account is penalized.  If that happens for at least one account, the whole procedure is invalidated  (and we wait for the next try).

- One can then ``mix'' the k0 numbers (e.g., by summing them modulo 1); if  at least one of the best k0 accounts does not belong to the attacker, the result is ``truly random'' (it cannot be manipulated, even if we suppose that  the attacker controls the otherk0 accounts and cheats by choosing their numbers at will).

- The probability that the attacker controls the best k0  accounts can be bounded from above by bk0, where b is the attacker's stake.

- As noted in the last section, the best strategy for the attacker is to split his money  into many small accounts; so, it is good that the splitting is discouraged  (as shown in Section 2.1).

Please feel free to criticize the algorithm; I don't have any knowledge in cryptography, so I'll be glad to take the opportunity to learn something.   :)

Pages: [1]