NXT :: descendant of Bitcoin - Updated Information

[chanc3r]

Not sure how one guy would be in charge of three INDEPENDENT gateways. This is what I have been saying. We need to find three different, independent, separate, not the same guy, gateway operators.

That is not possible. You cannot formally prove that.

In addition to my post about implementing a public audit website for gateways (don't know if that's useful)

Can we limit risk also by limiting the volume of assets traded per gateway cluster - forcing the addition of gateways to process more (a risk based limit rather than a technical CPU/Network based limit) ?
e.g. each gateway can provide trust for up to X million of an asset so the trading volume for that asset is NGateways*X, if the volume is higher then you would not be able to deposit though the gateway to AE

This also means that someone knows if they run a gateway the volume is such that their node has to be involved and they will get some income and the existing gateway owners will want the additional node and will sign it into the cluster because they need the capacity.

You still have 3 way voting but then its 3 way voting between N gateways, the voting should be pseudorandom as all gateways should trust all others and we can similarly monitor signing behaviour - each gateway block should be identifying which nodes sign. One suspicious pattern would be if there is a locked pattern of signing between 3 colluding nodes this would be picked up.

The gateway block chain can be picked up from any of the nodes as it has to be common across all gateways doesn't it so they could not hide this signing patter which would be necessary to collude...

So if you have 4,5,10 gateway operators the only way a fraud could be totally hidden would be if more and more people colluded unless of course someone acquires or is secretly all of these operators.

[salsacz]

I just sent a message to l8orrie, but still - we need a German guy with technical knowledge to proofread one text, very fast, but only for tech info, grammar will be checked by editor. So please send me PM

Ich suche deutsche man fur correctieren ein technischen Text

[bitcoinpaul]

Can we limit risk also by limiting the volume of assets traded per gateway cluster - forcing the addition of gateways to process more (a risk based limit rather than a technical CPU/Network based limit) ?

This will complicate things. Do we need it?

Nxt works without trust, but we cannot force the same idea for service providers.

[igmaca]

I was reviewing BCNext's plan as told by CfB here (http://wiki.nxtcrypto.org/wiki/BCNext%27s_Plan), and again was pulled up short by this line.


I am not certain that it's over. The selfish-mining problem is still present in the current implementation and we have two different approaches to tackle it:
 - penalty
 - limiting forging power of an account

three

share fee group (share fee pool or Hubs)

Instead of leasing forge power, you commit with your account to share fees among others in the same "share fee group" if you forge a node. You still try to forge a block on your own, but you commit to share the incentive with others if you are successful (with special conditions like committing to run the node for some time, ...)

Perhaps creating nodes coins proposed by jl777 implementing shared  fees pool  would be technically easier.

Could distribute node coins to the participants in the pool at all times proportion to the funds of each participant if any member had success in forging

Then there would logically be a market between NXT Coins VS node coins

O perhaps and hybrid

share fee group (share fee pool or share fee Hubs) and limiting forging power of an account to 1.000.000 Nxt coin maximum . this means 1.000 nodes to ensure minimum network

1,000,000 Nxt coins pools (share fee group)

1.000.000.000 Nxt Coin
1.000.000 Nxt Coin per pool (share fee group)

10 accounts  90.000 Nxt 10 Node participate in forging
10 accounts  9.900 Nxt 10 Node participate in forging
10 accounts  100 Nxt 10 Node participate in forging

Total pool (share fee group) 1.000.000 Nxt
Total 30 Nodes participate in forging

Chance to forge 0,001
rate forging 1440 blocs per day
526 Blocs per year
aprox 1,44 Blocs per day. 100 Nxt account is forging every day. receives fees in proportion to their funds every day!!!

1.000.000.000 Nxt Coin
1.000.000 Nxt Coin per pool (share fee group)
30.000 Nodes participate in forging. if there are only 30 accounts linked per pool (share fee group)

this means;

Extremely decentralized network (in the exemple 30.000 Nodes) and therefore very secure network
Small accounts motivated to participate in forging (In the exemple 100 Nxt account is forging every day not every 10 year)
rich and poor have the same chance to forge because everybody forge everyday!!!!

[ChuckOne]

What happens if the URI becomes unavailable?

AMs are not intended to hang around forever anyway (they are expected to be removed when a pruning occurs) so I don't see that as being an issue.

The point is that layers on top of the basic Nxt platform will need to use AMs (especially things like ATs) so we need to make it easier for "clients" to know how to handle different "message types".

I wasn't aware that AM are intended to be removed.

My idea was to use the alias system to provide an URL that can be changed later if necessary.

I like the idea of PIPs which stick around for people to understand the evolution of Python.

[chanc3r]

Can we limit risk also by limiting the volume of assets traded per gateway cluster - forcing the addition of gateways to process more (a risk based limit rather than a technical CPU/Network based limit) ?

This will complicate things. Do we need it?

Technically - probably not.
but increasing the number of gateways 3+n where 'n' is 1,2,3,4

At 3+0 with 3providers colluding you risk not detecting
At 3+n you have more opportunity of detecting collusion.
Or accept the risk
Or find another way

[ChuckOne]

I am not certain that it's over. The selfish-mining problem is still present in the current implementation and we have two different approaches to tackle it:
 - penalty
 - limiting forging power of an account

I have been advocating for the latter (and for scrapping the idea of the former) and CfB came up with a great idea to stop the effectiveness of forgers trying to extend multiple chains of equal weight (each client will only build on the 1st chain of equal height that they see).

I still like the idea of penalty as it is the simplest solution.

Splitting accounts obfuscate the problem, I think, as it seams distributed over time but really isn't.

What about new nodes in CfB's solution? Which branch of the DAG should they choose?

[^[GS]^]

Problems starting the 0.8.3...

1) First... using "sh run.sh"

Error: Could not find or load main class nxt.Nxt

2) Second... using "java -cp /mnt/nxt/nxt.jar:/mnt/nxt/lib/*:conf nxt.Nxt"

Exception in thread "main" java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: nxt-default.properties not in classpath and system property nxt-default.properties not defined either
at nxt.Nxt.(Nxt.java:75)

Any ideas?


EDIT: is Linux, not Windows!

[CIYAM]

I still like the idea of penalty as it is the simplest solution.

Actually it's not the simplest and it is far from certain that is even a solution (all attempts to even "simulate" it have failed to show any benefit at all so far).

What about new nodes in CfB's solution? Which branch of the DAG should they choose?

New nodes will get their information from their peers (so whichever peer they got a branch from first is the one they will stick to in case of another equal weight branch appearing).

[l8orre]

@JL, CfB did you drop the 'numberOfUsers' field from the 'getState' request? It does not seem to appear there any more.. If not, what am I making wrong?

1 - numberOfPolls - 0<class 'int'>
2 - totalEffectiveBalance - 99482635500<class 'int'>
3 - maxMemory - 954728448<class 'int'>
4 - numberOfTrades - 0<class 'int'>
5 - version - 0.8.3<class 'str'>
6 - numberOfBlocks - 78803<class 'int'>
7 - availableProcessors - 4<class 'int'>
8 - freeMemory - 296162080<class 'int'>
9 - lastBlockchainFeeder - node1.nxtbase.com<class 'str'>
10 - numberOfOrders - 0<class 'int'>
11 - numberOfAssets - 0<class 'int'>
12 - cumulativeDifficulty - 2444760512653829<class 'str'>
13 - numberOfUnlockedAccounts - 0<class 'int'>
14 - numberOfAliases - 63141<class 'int'>
15 - numberOfVotes - 0<class 'int'>
16 - numberOfTransactions - 136664<class 'int'>
17 - totalMemory - 643301376<class 'int'>
18 - numberOfPeers - 180<class 'int'>
19 - time - 8463865<class 'int'>
20 - numberOfAccounts - 25927<class 'int'>
21 - lastBlock - 10042636691406560440<class 'str'>



Also,  - sorry to bother you with this - I am having a bit of a hard time switching over from GET to POST


On localhost - http://localhost:7876 - I can assemble the requests simply with POST instead of GET
 
        self.req = Request( method='GET', url = sessUrl, params = {"requestType" : "getState"  })

        self.req = Request( method='POST', url = sessUrl, params = {"requestType" : "getState"  })

And I get correct json() response object. On https://holms.cloudapp.net:6875/ I get the old javascript access, but I can't connect with python requests, because I haven't hit the proper port/scheme combe yet apparently.

Also, when I use POST, on localhost it does not seem to require 'auth', 'data', 'headers' - is this maybe needed when using a remote connection??

Please drop me a hint which scheme/port combo I have to use for the testnet and my raspi - I don't seem to be getting ahead there

what is running on what port

6874
6875
6876


thanks,
l8orre

[abctc]

Problems starting the 0.8.3...

- if you are on Windows use the command:

Code:

java -Xmx1024M -cp nxt.jar;lib\*;conf nxt.Nxt

[redsn0w]

Problems starting the 0.8.3...

1) First... using "sh run.sh"

Error: Could not find or load main class nxt.Nxt

2) Second... using "java -cp /mnt/nxt/nxt.jar:/mnt/nxt/lib/*:conf nxt.Nxt"

Exception in thread "main" java.lang.ExceptionInInitializerError
Caused by: java.lang.RuntimeException: nxt-default.properties not in classpath and system property nxt-default.properties not defined either
at nxt.Nxt.(Nxt.java:75)

Any ideas?

Use this :

Code:

 "C:\Program Files (x86)\Java\jre7\bin\java.exe" -Xmx1024M -cp nxt.jar;lib\*;conf nxt.Nxt  

[hala]

   Looks great . I have joined in .
   But I have a question, can the investor transfer their shares with price to other people ?

1) Do you mean sell them on the ASSET EXCHANGE?

2) You could always transfer your assets to another account if you like.

   For example, we can sell our shares at some trade platform like other coin .
 
   I have send the buy confirmation message , please confirm .

   Thanks .

[ChuckOne]

I still like the idea of penalty as it is the simplest solution.

Actually it's not the simplest and it is far from certain that is even a solution (all attempts to even "simulate" it have failed to show any benefit at all so far).

I work on a model for that.

Have you posted results with the penalty model? I may have missed them. Could you point me to them?

What about new nodes in CfB's solution? Which branch of the DAG should they choose?

New nodes will get their information from their peers (so whichever peer they got a branch from first is the one they will stick to in case of another equal weight branch appearing).

So, it will lead to a split network and that might open doors for an even bigger attack. Splitting the network into smaller and smaller chunks. Until new nodes only become part of a little branch of the DAG.

I need to go now.

[CIYAM]

I work on a model for that.

Please do.

Have you posted results with the penalty model? I may have missed them. Could you point me to them?

I did not as the attempts to model this in my simulator all came out with "disastrous" results (which are likely just due to the simulator so would not be of any value at all).

So, it will lead to a split network and that might open doors for an even bigger attack. Splitting the network into smaller and smaller chunks. Until new nodes only become part of a little branch of the DAG.

Frequent forks are *expected* to occur in a system with (compared to Bitcoin) fast confirmation times (BCNext said that in his introductory post).

By "fragmenting" the forks all over the place it will actually reduce the effectiveness of such attacks.

[igmaca]

Addressing how TF will be implemented should be focused on protecting the blockchain (#1) and the network (#2).

Issues of "fairness" (perceived or otherwise) are at best a #3 priority (if even that).

"Fairness" issue can't be resolved while money exists, IMHO.

for me when I say fairness I mean this:

100 Nxt account is forging every day not every 10 year


aprox 1,44 Blocs per day. 100 Nxt account is forging every day. receives fees in proportion to their funds every day!!!

1.000.000.000 Nxt Coin
1.000.000 Nxt Coin per pool (share fee group)
30.000 Nodes participate in forging. if there are only 30 accounts linked per pool (share fee group)

this means;

Extremely decentralized network (in the exemple 30.000 Nodes) and therefore very secure network
Small accounts motivated to participate in forging (In the exemple 100 Nxt account is forging every day not every 10 year)
rich and poor have the same chance to forge because everybody forge everyday!!!!

[CIYAM]

for me when I say fairness I mean this:

100 Nxt account is forging every day not every 10 year

Again - the changes being proposed are for security not fairness (you are not focusing on the right thing).

[bitcoinpaul]

Addressing how TF will be implemented should be focused on protecting the blockchain (#1) and the network (#2).

Issues of "fairness" (perceived or otherwise) are at best a #3 priority (if even that).

"Fairness" issue can't be resolved while money exists, IMHO.

for me when I say fairness I mean this:

100 Nxt account is forging every day not every 10 year


aprox 1,44 Blocs per day. 100 Nxt account is forging every day. receives fees in proportion to their funds every day!!!

1.000.000.000 Nxt Coin
1.000.000 Nxt Coin per pool (share fee group)
30.000 Nodes participate in forging. if there are only 30 accounts linked per pool (share fee group)

this means;

Extremely decentralized network (in the exemple 30.000 Nodes) and therefore very secure network
Small accounts motivated to participate in forging (In the exemple 100 Nxt account is forging every day not every 10 year)
rich and poor have the same chance to forge because everybody forge everyday!!!!

igmaca, please. we talk about security of nxt. if you want to talk about fairness, ok. but that has nothing to do with the change and implementation of TF right now.

[igmaca]

for me when I say fairness I mean this:

100 Nxt account is forging every day not every 10 year

Again - the changes being proposed are for security not fairness (you are not focusing on the right thing).

but I think share fee group also maintains security in my humble opinion.

Maybe I missed something

[Jean-Luc]

@JL, CfB did you drop the 'numberOfUsers' field from the 'getState' request? It does not seem to appear there any more.. If not, what am I making wrong?

I dropped this field because it has nothing to do with the server state. It is very specific to the NRS client UI only and represents the number of its user sessions. But it does not reflect users using clients that connect through the http API, or through the Java API.

As for the status of testnet and holms.cloudapp.net, CfB should know, I don't work on that.