NXT :: descendant of Bitcoin - Updated Information

[CIYAM]

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

Understand that the *best* way to protect the blockchain is always going to be having forging power divided up into roughly equal smaller pieces (whether or not the software tries to enforce that or not).

[1713435596]

1713435596

[1713435596]

1713435596

[1713435596]

1713435596

[CIYAM]

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

[chanc3r]

I think different Nxt-Assets from the same underlying Asset from different Gateways would be interesting. Different Gateways will naturally emerge, so we shouldn't fight it but instead maybe pave the way for proper implementations by providing guidance, papers, how-tos?

In simpler terms, you might think of trading different assets of the same underlying asset from different gateways like trading on different exchanges (New York, Frankfurt, Tokio, ...). I know, this is not a 100% accurate analogy, but you get the point.

So the gateways would have to trust each other...? 

For transaction processing clusters - which aka the 3 gateways are - normally there is an audit node which does not process any transactions but verifies the integrity of what the 3 nodes are doing.
As the nodes already verify each other then perhaps the audit node verifies the cluster of nodes as a whole to ensure as a system they are behaving properly - there could be the ability for external nodes to verify the operation of the cluster by reconciling all inputs/outputs.
The quality of what is bought/sold e.g. crap-subprime-derivative-coin i am not sure we can control nor shares from Scamscrypt.com
But would an external audit function should be able to highlight whether the 3 nodes are cheating?

This could be a service like 'coinmarketcap' e.g. NXTGateWayTrust.com publishing a 'trust' level for services based on the auditing of the many gateways that people publish to NXT, and people who are not open and allow this auditing to happen would not get a trust rating.

Yes I know then the operators of the Trust Audit System/Website could be compromised and must not run a gateway themselves, but we can never completely eliminate risk but we can reduce it by increasing the number of parties that have to be compromised in order to allow a fraud to take place and ensuring suspicious data that indicates a potential fraud is highlighted early to allow investigation.

Most financial TX platforms have a formal separate AML or Transaction Monitoring / Fraud system, NXT itself doesn't need this but maybe the gateway(s) can be monitored for suspicious patterns, as the data is public such transactions would simply be published as reasons why a trust level had reduced and this would be available for community inspection - this kind of TX visibility with send/receive addresses shown would deter a lot of people from trying things and hopefully would alert early to any innovative scams that were being perpetrated.

[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

[CIYAM]

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

[ChuckOne]

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.

[CIYAM]

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.

True - and presumably you should also be able to choose from 1 of x such 3 server gateways.

[Come-from-Beyond]

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.

[bitcoinpaul]

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.

True - and presumably you should also be able to choose from 1 of x such 3 server gateways.

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

[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