Bitcoin Forum
July 18, 2024, 03:04:55 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 [1972] 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 ... 2557 »
  Print  
Author Topic: NXT :: descendant of Bitcoin - Updated Information  (Read 2761546 times)
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1086


Ian Knowles - CIYAM Lead Developer


View Profile WWW
March 02, 2014, 10:24:25 AM
 #39421

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
CIYAM
Legendary
*
Offline Offline

Activity: 1890
Merit: 1086


Ian Knowles - CIYAM Lead Developer


View Profile WWW
March 02, 2014, 10:27:27 AM
 #39422

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
chanc3r
Sr. Member
****
Offline Offline

Activity: 952
Merit: 253



View Profile
March 02, 2014, 10:45:02 AM
 #39423

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
Full Member
***
Offline Offline

Activity: 168
Merit: 100


View Profile
March 02, 2014, 10:46:46 AM
 #39424

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
Legendary
*
Offline Offline

Activity: 1890
Merit: 1086


Ian Knowles - CIYAM Lead Developer


View Profile WWW
March 02, 2014, 10:50:31 AM
 #39425

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
ChuckOne
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

☕ NXT-4BTE-8Y4K-CDS2-6TB82


View Profile
March 02, 2014, 10:50:43 AM
 #39426

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
Legendary
*
Offline Offline

Activity: 1890
Merit: 1086


Ian Knowles - CIYAM Lead Developer


View Profile WWW
March 02, 2014, 10:53:20 AM
 #39427

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.

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
Come-from-Beyond
Legendary
*
Offline Offline

Activity: 2142
Merit: 1010

Newbie


View Profile
March 02, 2014, 10:58:06 AM
 #39428

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
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
March 02, 2014, 11:01:25 AM
 #39429

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
Sr. Member
****
Offline Offline

Activity: 952
Merit: 253



View Profile
March 02, 2014, 11:02:20 AM
 #39430

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
Hero Member
*****
Offline Offline

Activity: 490
Merit: 504


View Profile
March 02, 2014, 11:04:21 AM
Last edit: March 02, 2014, 12:36:46 PM by salsacz
 #39431

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
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000



View Profile
March 02, 2014, 11:04:56 AM
 #39432

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
Full Member
***
Offline Offline

Activity: 168
Merit: 100


View Profile
March 02, 2014, 11:08:39 AM
Last edit: March 07, 2014, 09:19:07 PM by igmaca
 #39433

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
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

☕ NXT-4BTE-8Y4K-CDS2-6TB82


View Profile
March 02, 2014, 11:08:49 AM
 #39434

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
Sr. Member
****
Offline Offline

Activity: 952
Merit: 253



View Profile
March 02, 2014, 11:17:41 AM
 #39435

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
Sr. Member
****
Offline Offline

Activity: 364
Merit: 250

☕ NXT-4BTE-8Y4K-CDS2-6TB82


View Profile
March 02, 2014, 11:18:24 AM
 #39436

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]^
Member
**
Offline Offline

Activity: 112
Merit: 10


View Profile
March 02, 2014, 11:20:19 AM
Last edit: March 02, 2014, 11:52:57 AM by ^[GS]^
 #39437

Problems starting the 0.8.3...

1) First... using "sh run.sh"
Quote
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"
Quote
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
Legendary
*
Offline Offline

Activity: 1890
Merit: 1086


Ian Knowles - CIYAM Lead Developer


View Profile WWW
March 02, 2014, 11:24:47 AM
 #39438

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

With CIYAM anyone can create 100% generated C++ web applications in literally minutes.

GPG Public Key | 1ciyam3htJit1feGa26p2wQ4aw6KFTejU
l8orre
Legendary
*
Offline Offline

Activity: 1181
Merit: 1018


View Profile
March 02, 2014, 11:24:55 AM
 #39439

@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
Huh

thanks,
l8orre

abctc
Legendary
*
Offline Offline

Activity: 1792
Merit: 1038



View Profile
March 02, 2014, 11:25:05 AM
 #39440

Problems starting the 0.8.3...
- if you are on Windows use the command:
Code:
java -Xmx1024M -cp nxt.jar;lib\*;conf nxt.Nxt

█████████████████████████████████████████████████
███████████████████████████████████████████████████
█████████████████████████████████████████████████████
█████████████████████████████████████████████████████
██████████████████████████████████████████████████████
█████
█████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████
███████████████████████████████████████████████████████
█████████████████████████████████████████████████████████████
███████████████████████████████████████████████████████████████
██████████████████████████████████████████████████████████████████
   
, the Next platform.  Magis quam Moneta (More than a Coin)
Pages: « 1 ... 1922 1923 1924 1925 1926 1927 1928 1929 1930 1931 1932 1933 1934 1935 1936 1937 1938 1939 1940 1941 1942 1943 1944 1945 1946 1947 1948 1949 1950 1951 1952 1953 1954 1955 1956 1957 1958 1959 1960 1961 1962 1963 1964 1965 1966 1967 1968 1969 1970 1971 [1972] 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 ... 2557 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!