NXT :: descendant of Bitcoin - Updated Information

[VanBreuk]

NXT Newsletter #3  

http://nxter.org/nxt-newsletter-3/

Thanks! reading it now and looking good as usual.

-----

And just a thought I wanted to leave here. With the last debacle in MtGox, twitter is seething with references to P2P, decentralized exchanges. I'm seeing links to http://www.coinffeine.com/ all the time. We have a wave to ride there now. I understand people is upset with mintpal (a damn fine exchange site, imo) and any swarm efforts are good and getting into new exchanges is always good and all, but right now it does not seem a priority when we have assets of our own, pun intended, that will return much more.

Regarding implementation of asset exchange, new tests and developments, what news do we have to show? Statements, screenshots, articles... we should keep producing materials around it. Translate for the crowd the progress being made. Other than "tests keep coming nicely and neurons keep sparking" what can we show? We have a great momentum out there.

I think we should try to get off BTC and start trading Nxt for FIAT. If the price of BTC goes down, so goes the price of Nxt, although the whole MtGox-stor has nothing to do with Nxt.

Get asset exchange online and working and both the fiat price and the link between Nxt and gox will stop being a concern.

AE is only a tool, not a gateway.

Correct. Excuse the wording. I was just discussing with someone the gateway james has in progress and I could see their hard-on.

[opticalcarrier]

How I can stop the server 0.8.x safely?
pkill -9 java? :S





http://www.youtube.com/watch?v=Jw-E3gCl1b4   <3

Code:

 kill -9 #ID PROCESS

#ID PROCESS = top .. and search on java process , take the id of the process and type it in the shell.

I wouldnt use the -9 unless it just refused to die.  I think just regular kill allows nxt to properly close the DB before quitting.  the -9 may make DB puke on itself

ETA:  apparently the signal required is 15, so use kill -15 javaprocessID

[mthcl]

OK, but, if we want to be able to calculate probabilities, there must be a good math model of how these weights can be simulated (i.e., something like this: "one can assume that weights of accounts are independent Exponential random variables with expectations equal (or proportional?) to their balances"). Without such a model, it would be difficult to proceed...

So for each account we take the first 8 bytes of an SHA256 hash of the "previous block sig + your account #" to get a "base target" (so an unpredictable 8 byte value that changes with every block). We then multiply this by your account's balance and the time (in seconds) since the last block to come up with your "current target".

There is also a "minimum target" value set in order to prevent spam (i.e. we don't want the network clogged up with people broadcasting "losing tickets"). This value is not overly important so I wouldn't worry too much about including it in the model (or just pretend it is a constant maybe).

Note that the time multiplication is really just to "widen" everyone's chance so that it won't take more than 60 seconds for "someone" to have a "current target" > "minimum target" and then broadcast their block.

When considering what is a "better block" time would be removed from the equation (so best "block target" is always the "base target" multiplied by "account balance") so the whole "time" thing could be left out of the model (just want you to be clear how the system works).

OK, so, let's assume that you take a collection of i.i.d. Uniform random variables in {0,...,2⁶⁴-1}, multiply them to account balances, and get the base targets this way (I'm assuming that we are already in "1 block per minute" regime; also, one can take i.i.d. Uniforms(0,1) instead, since it's just scaling).

Now, let me think how (within this model) the bad guy grows a fork of depth 2...

[mcjavar]

NXT Newsletter #3  

http://nxter.org/nxt-newsletter-3/

Thanks! reading it now and looking good as usual.

-----

And just a thought I wanted to leave here. With the last debacle in MtGox, twitter is seething with references to P2P, decentralized exchanges. I'm seeing links to http://www.coinffeine.com/ all the time. We have a wave to ride there now. I understand people is upset with mintpal (a damn fine exchange site, imo) and any swarm efforts are good and getting into new exchanges is always good and all, but right now it does not seem a priority when we have assets of our own, pun intended, that will return much more.

Regarding implementation of asset exchange, new tests and developments, what news do we have to show? Statements, screenshots, articles... we should keep producing materials around it. Translate for the crowd the progress being made. Other than "tests keep coming nicely and neurons keep sparking" what can we show? We have a great momentum out there.

I think we should try to get off BTC and start trading Nxt for FIAT. If the price of BTC goes down, so goes the price of Nxt, although the whole MtGox-stor has nothing to do with Nxt.

Get asset exchange online and working and both the fiat price and the link between Nxt and gox will stop being a concern.

AE is only a tool, not a gateway.

Correct. Excuse the wording. I was just discussing with someone the gateway james has in progress and I could see their hard-on.

I am also in discussion about a gateway, but I am still looking for someone to cooperate with.

[CIYAM]

Now, let me think how (within this model) the bad guy grows a fork of depth 2...

Great - we are all very keen to see the results!

[Come-from-Beyond]

We need to focus. I need to focus. Thoughts.


BCNext's idea was, speaking of forging incentives, to get rid of transaction fees. The idea is that companies, who use Nxt (as a platform, as their payment provider, as what ever), earn money with their services, and thereby have an interest in running nxt nodes to provide stability for it.

But BCNext doesn't live in fairy land (well, sometimes he does, i think) and knows that thousands of companies will not get built on top of nxt or use nxt right now but in the future. First, we need to provide a stable and secure network to (potential new) businesses before they use it. That's why the first plan is building Nxt as a currency to get a wide adoption. I don't think we are there yet. Only because we know the 2nd plan doesn't mean we have to jump on it. Or should we? And, of course, trust no one, we don't need to follow his ideas, yada yada yada. Well, he is a smart guy. Let's think about it:

We need fees right now to have an incentive for forging (and maybe a better fees structure, like the hallmark idea) and we don't know for how long. But we should also get rid of fees to make it possible for companies to use Nxt. This chicken and egg problem can only be solved with a gradually decrease of fees and give Nxt a kickstart with paid infrastructure for the next months (years, we don't know). Or is there another solution?

If this is correct, we should talk about how we will come to a consensus about decreasing fees in the future. And our infrastructure committee (not in place yet) should go to work on nerdy things for stability, 1000TPS, .. as soon as possible.

Also, how do we prevent spamming when there are no fees? Maybe we should have different fees on different parallel blockchains.


Penalties. At least it was part of BCNext's idea that we should penalize accounts who don't forge. I don't see a problem here as long as we talk about proper penalty. Not allowed to forge for the next 1440 blocks seems fair.


I want to know where I'm wrong and I want to hear CfB on both topics.

Pump. CfB has no answer.

https://bitcointalk.org/index.php?topic=345619.msg5361024#msg5361024

[freedomfighter]

what if we were to come to the forging issue from a different angle:

The problem as defined here is HOW to keep a small NXT holder (whose motivation is financial and not ideological) interested in maintaining the network?

Another problem (for some at least) was the holding size of larger stakeholders which means that the rich will get richer and the small guy will not make enough.

How do we tackle this? we need to find a solution that will consider both issues: give a chance to the low balance guy to make enough from forging and be motivated while also allowing a chance for a higher balance holder or pool to enjoy suitable returns. we also need enough machines... hence the pool idea.

We also need to remember that high balance individuals have a vesting interest that the network will prosper which means that their equity is worth more. so the motivation there is not only forging rights.

------------------------

The conceptual solution is to create a completely random, lottery like, naturally decentralized algorithm that will assign fees randomly per transaction to any 1NXT in the system without consideration to any holder's NXT balance

Naturally- if you have more NXT you will gravitate toward having better chances to win the transaction fee

However, if you are a low balance guy you KNOW that you can win more fees than your relative holding size.

This will both provide motivation to the low balance holders that at any given moment can win a larger fee than the relative size of their account, and they will stay on and open for that extra chance---  while also take care (statistically) of the higher balance people but from a decentralized perspective- i.e. the system wouldnt care who has more NXT because it will randomly divide fees between all NXT in the system, 1 fraction at a time and not in any particular order-- which will allow for someone to win more than his "natural" share at any given time

Maybe the system can also be programmed to automatically reduce/increase fees above/below  a given number of transactions per hour or 24 hours to naturally attract more forging if number of network points decline. However, When there are enough transactions in the system and the network is both lucrative and stable everyone will be happy.

Dont know if this is at all possible and maybe this is nonsense........... but conceptually it seems to be solving issues for all stakeholders by catering to both needs  

[bitcoinpaul]

I don't know if u wrong or not.

You talk about the fairy land thing?

[CIYAM]

The conceptual solution is to create a completely random, lottery like, naturally decentralized algorithm that will assign fees randomly per transaction to any 1NXT in the system without consideration to any holder's NXT balance

Similar to what I had suggested earlier - effectively we change the "stake" to the number of >x balance accounts that you have (where we would set x at some low value like 1 NXT).

So a large stake holder will have to divide up their holding into many (millions?) of accounts to achieve the same "power" they currently have.

This works best with pooling of course (rather inconvenient otherwise) but without penalty still gives small forgers "a reason to forge".

Also note that I am wanting to work with the math guy on determining the best solution before I propose any *actual change* from BCNext's plan (I am not convinced about the 90% thing anyway and would like to see some "hard evidence").

[Come-from-Beyond]

I don't know if u wrong or not.

You talk about the fairy land thing?

About the whole post.

[jl777]

automated multisig gateway status.

Deposits seem to be working pretty good, even multiple deposits at the same time to different addresses.

I have constructed multisig rawtransactions that have worked, except for the fact I can only get it to work on one server so far. probably due to system clock differences. The big problem now is that if I need to use more than one vout for a withdrawal, it doesnt fit into a tiny little AM. I either have to massively compress it or setup a point to point network for the signing of multisig. There could easily be half a dozen inputs required for a transaction and no amount of compression will make that fit into 1K. I could have each server calculate the rawtransaction independently and theoretically they should be identical. This might actually be a good way to build in peer verification. However, in case there is the smallest difference, it will probably not verify and tracking down reasons for small variations in a rawtransaction, well, not happy land.

Gotta rest for a bit before tackling this problem.

Oh, I also figured out a much easier way for people to be able to test this. When it is ready for testing, just post your DOGE address and I will send you some DOGE for testing along with a deposit address. I will set the withdrawal address to your DOGE address. I believe there is even an online DOGE wallet, so no need to install DOGE-qt. No need to compile any source code. Since the gateway uses the "sender" field in the AM to verify you are the owner of the NXT acct, I dont think it is so easy to spoof gateway_AM packets. Havent really bullet proofed that yet as we need to have basic functionality first.

Once the gateway has your deposit and withdrawal address, the DOGE wallet essentially becomes and extension of NXT AE. Send DOGE to deposit address and it appears in "My Assets". Transfer the DOGE asset back to the issuer and it appears in your DOGE wallet. Substitute any bitcoind fork for DOGE. Imagine them all at the same time!

I will be offline on Wed, not sure if I will have a stable release before then. The only thing I think I am relying on from the AM is the withdrawal address. If the security of this becomes an issue, we can always make it a manual process to update. I havent code reviewed for this yet, but I believe that I am basing all money transfer decisions based on fully confirmed bitcoind or NXT blockchain events. I am also drilling down to individual vouts to avoid any transaction malleability issues. At least I think I do. Most of the gateway_AM's are basically receipts of what has happened to create a distributed database of gateway transactions. I know I am not supposed to be able to make this automated cross chain stuff work, but I am not sure why I am not supposed to be able to, so I keep working toward what I believe is a cool solution.

James

[l8orre]

@AE devs: I seem to be having issues with the AE: When I call 'getAssets', I get these 6 assets, created today after CfB restarted the testnet:


getAssetIds

assetIds - ['

9076231045093640293', '
2952478044871531870', '
6525075746265167591', '
16739598998421896224', '
5788088280578443047', '
7761388364129412234', '
12806307819013617780']

I know thst these were created after testnet restart today, because earlier today there were zero assets, and I issued the first one.

Now I look at 'getTrades' for each of these assets, and I get  a total of three trades:

9076231045093640293
trades - []


2952478044871531870
trades - [{'timestamp': 8034990, 'askOrderId': '2306609193939033899', 'price': 46000, 'bidOrderId': '13607793337915669303', 'quantity': 1}]


6525075746265167591
trades - [{'timestamp': 8027556, 'askOrderId': '12546374603755785265', 'price': 5, 'bidOrderId': '234179978827995502', 'quantity': 33}]


16739598998421896224
trades - [{'timestamp': 8021490, 'askOrderId': '16804729641686889636', 'price': 13500, 'bidOrderId': '16894845653194739948', 'quantity': 5}]


5788088280578443047
trades - []


7761388364129412234
trades - []

12806307819013617780
trades - []



However, looking at 'getState', I see 12 trades.




getState

totalMemory - 259522560
time - 8045612
numberOfTrades - 12 <---------------------  



What is wrong there?
Also, there is the persistent issue with the Orders not appearing any longer, or 'not enough funds'

Can anyone of you confirm this, or is it my client messing up?


     



cumulativeDifficulty - 2309274722555977
numberOfPeers - 4
availableProcessors - 2
version - Test@0.7.6
numberOfUnlockedAccounts - 25
maxMemory - 259522560
freeMemory - 100166296
numberOfTransactions - 132339
numberOfVotes - 0
numberOfAccounts - 25102
lastBlockchainFeeder - holms.cloudapp.net
numberOfAssets - 7
numberOfOrders - 16
numberOfAliases - 61320
numberOfUsers - 32
numberOfPolls - 1
lastBlock - 3490252272406714692
numberOfBlocks - 74985
totalEffectiveBalance - 99823172900

[freedomfighter]

The conceptual solution is to create a completely random, lottery like, naturally decentralized algorithm that will assign fees randomly per transaction to any 1NXT in the system without consideration to any holder's NXT balance

Similar to what I had suggested earlier - effectively we change the "stake" to the number of >x balance accounts that you have (where we would set x at some low value like 1 NXT).

So a large stake holder will have to divide up their holding into many (millions?) of accounts to achieve the same "power" they currently have.

This works best with pooling of course (rather inconvenient otherwise) but without penalty still gives small forgers "a reason to forge".

Also note that I am wanting to work with the math guy on determining the best solution before I propose any *actual change* from BCNext's plan (I am not convinced about the 90% thing anyway and would like to see some "hard evidence").

actually if it is completely random it shouldnt matter if its a pool or a high balance person since the system will be blind to this. it will only relate to 1NXT at a time- so pulling or dividing an account will not give an advantage.

[rickyjames]

Am I forging right? I bought a BTC worth of NXT a few days ago, so I have around 11.5k. All I have to do is leave on my NXT client (NRS 0.7.6) and forging will happen by itself? The past few pages have been talking about how to change up forging to be more profitable... but my question is, how do I check on the progress of my forging?

Thanks! And happy NXTing!

If you leave your client on for 24 hours (1440 minutes) then you are forging.  Your client is broadcasting its availability to forge the next block, and there is a lottery system going on once a minute behind the scenes that your 11.5K NXT is participating in to win you the right to forge the next block.  Wait long enough, you will win that lottery at some particular minute, and you will forge a block.  As for monitoring your "progress" - I am not sure if you can really do that.

The two arrows represents "transactions in and out of your account".  The globe / peers is just an item of general interest - your client is not communicating with all the computers on the NXT network, only this subset.  The puzzle piece is data about the most recently forged blocks. 

[CIYAM]

actually if it is completely random it shouldnt matter if its a pool or a high balance person since the system will be blind to this. it will only relate to 1NXT at a time- so pulling or dividing an account will not give an advantage.

No - the pool controls x amount of accounts so has greater forging power (otherwise no point in being a "pool" - I don't think we should actually try and stop "pooling").

Also pools are necessary if we want to be able to create "interest bearing accounts" (which I think will be quite popular) and ramping up to 1000+ TPS will require some decent servers (which aren't free).

We are basically trying to work out if the "penalty" should even exist (IMO it should not) and try to make sure that small forgers still have a "reason" to forge (even if the rewards are not much).

[bitcoinpaul]

http://www.nxtcrypto.org/nxt-podcast/nxt-crypto-minute-6

4 plans? Damn, I always thought, there are 3.

[jl777]

what if we were to come to the forging issue from a different angle:

The problem as defined here is HOW to keep a small NXT holder (whose motivation is financial and not ideological) interested in maintaining the network?

Another problem (for some at least) was the holding size of larger stakeholders which means that the rich will get richer and the small guy will not make enough.

How do we tackle this? we need to find a solution that will consider both issues: give a chance to the low balance guy to make enough from forging and be motivated while also allowing a chance for a higher balance holder or pool to enjoy suitable returns. we also need enough machines... hence the pool idea.

We also need to remember that high balance individuals have a vesting interest that the network will prosper which means that their equity is worth more. so the motivation there is not only forging rights.

------------------------

The conceptual solution is to create a completely random, lottery like, naturally decentralized algorithm that will assign fees randomly per transaction to any 1NXT in the system without consideration to any holder's NXT balance

Naturally- if you have more NXT you will gravitate toward having better chances to win the transaction fee

However, if you are a low balance guy you KNOW that you can win more fees than your relative holding size.

This will both provide motivation to the low balance holders that at any given moment can win a larger fee than the relative size of their account, and they will stay on and open for that extra chance---  while also take care (statistically) of the higher balance people but from a decentralized perspective- i.e. the system wouldnt care who has more NXT because it will randomly divide fees between all NXT in the system, 1 fraction at a time and not in any particular order-- which will allow for someone to win more than his "natural" share at any given time

Maybe the system can also be programmed to automatically reduce/increase fees above/below  a given number of transactions per hour or 24 hours to naturally attract more forging if number of network points decline. However, When there are enough transactions in the system and the network is both lucrative and stable everyone will be happy.

Dont know if this is at all possible and maybe this is nonsense........... but conceptually it seems to be solving issues for all stakeholders by catering to both needs  

These are all very creative ideas, but there is no reason to change the NXT core for this. We can just create a rewards coin on top of NXT. Then whatever type of reward, lottery, etc. can be encapsulated in that coin. Messing with forging is VERY dangerous. Can anybody really guarantee than any change of the magnitude being discussed will actually be a stable network? It is working now, why fix it?
Add stuff on top, dont mess with fundamental forging process. I believe BCNext is the MOST capable person for making changes to forging algo. Until someone can convince me that they understand the ramifications of any changes to forging, I will not support changing forging. Especially just to make it more "fair", whatever that means.

Imagine a guy who is juggling while on ice skates, during an earthquake. Do you really want to mess with his balance to make him change his hat?

James

[CIYAM]

It is working now, why fix it?

Is it? Just because it hasn't been attacked yet doesn't mean it "won't" or "can't".

We have had no mathematical analysis (which we are hopefully soon going to have).

I suggest the decisions are made upon "math" rather than "gut feelings" or "loyalty" to BCNext (he did say "not to trust him").

[Come-from-Beyond]

Also, there is the persistent issue with the Orders not appearing any longer, or 'not enough funds'

Can anyone of you confirm this, or is it my client messing up?

It's a bug related to unconfirmed balance.

[Come-from-Beyond]

@AE devs: I seem to be having issues with the AE: When I call 'getAssets', I get these 6 assets, created today after CfB restarted the testnet:


getAssetIds

assetIds - ['

9076231045093640293', '
2952478044871531870', '
6525075746265167591', '
16739598998421896224', '
5788088280578443047', '
7761388364129412234', '
12806307819013617780']

I know thst these were created after testnet restart today, because earlier today there were zero assets, and I issued the first one.

Now I look at 'getTrades' for each of these assets, and I get  a total of three trades:

9076231045093640293
trades - []


2952478044871531870
trades - [{'timestamp': 8034990, 'askOrderId': '2306609193939033899', 'price': 46000, 'bidOrderId': '13607793337915669303', 'quantity': 1}]


6525075746265167591
trades - [{'timestamp': 8027556, 'askOrderId': '12546374603755785265', 'price': 5, 'bidOrderId': '234179978827995502', 'quantity': 33}]


16739598998421896224
trades - [{'timestamp': 8021490, 'askOrderId': '16804729641686889636', 'price': 13500, 'bidOrderId': '16894845653194739948', 'quantity': 5}]


5788088280578443047
trades - []


7761388364129412234
trades - []

12806307819013617780
trades - []



However, looking at 'getState', I see 12 trades.

There r indeed 12 trades. Check ur response parser for getTrades.