Topic: NXT :: descendant of Bitcoin - Updated Information - page 585. (Read 2761626 times)

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.

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

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!!!!

Please do.


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).


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.

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?


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.

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

   Thanks .

Use this :

- if you are on Windows use the command:

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



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

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).


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).

Problems starting the 0.8.3...

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

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

Any ideas?


EDIT: is Linux, not Windows!

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?

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

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.

This will complicate things. Do we need it?

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

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

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.

And that's why I mentioned the different Assets of same underlying Asset idea. Then 'the market' can decide.

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