NXT :: descendant of Bitcoin - Updated Information

[jl777]

It turns out the transition to fractional amounts, which is required for reducing the minimum fee, will not be that simple. It would require adding a new transaction type, because the current ordinary payment transaction stores amounts and fees with 1 NXT precision, not multiplied by 100 as in the account balance. So it will take longer to implement and test. The positive side is that while doing that we can make the fractional part allow amounts much lower than 0.01, so we will achieve much higher divisibility.

We don't really need too much divisibility. Perhaps 1.00000 at max?

Sorry to disagree Eadeqa, we always seem at odds...
We need as much precision as possible. I am already seeing some issues with pricing things in AE. BCNext's vision is to run an entire economy on top of NXT. Assets are the key, that is why it is the only thing that costs more than minimum transaction, eg. 1000 NXT

We will need milliNXT and microNXT and maybe even nanoNXT so people can transact for things without quantization problems

James

P.S. I am trying to make sure that even after NXT goes above $1000 we can still buy a lollipop at a precise price.

[opticalcarrier]

It turns out the transition to fractional amounts, which is required for reducing the minimum fee, will not be that simple. It would require adding a new transaction type, because the current ordinary payment transaction stores amounts and fees with 1 NXT precision, not multiplied by 100 as in the account balance. So it will take longer to implement and test. The positive side is that while doing that we can make the fractional part allow amounts much lower than 0.01, so we will achieve much higher divisibility.

well I guess now we have more time for discussion of number of decimal places and also more on fees.  Maybe we want to start with 4 decimal places and allow us options to 'split' in the future (something that hasnt been done in crypto before, they just go with eight and done) or we could just go 8 and done.

Im  still torn on using percentage-based fees on ordinary transfers, or for  my other suggestion for fees based on byte-size of each transaction.  if you do a %, then what about AM/alias?  Do we hard-set fees for aliases/AM? or just leave that for future debate, as fee-changing is apt to take a lot of work/testing anyways.

[l8orre]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Release 0.7.5

http://download.nxtcrypto.org/nxt-client-0.7.5.zip

sha256: 66adc8379a8f6e3fba7797fbc94b8b62f3e486ea5b6e9877f064c4b0d1f2584d

@JL

Code:

[2014-02-14 18:23:55.255] Database is at level 13
[2014-02-14 18:23:55.267] DEBUG: Will apply sql:
ALTER TABLE block DROP COLUMN IF EXISTS index
[2014-02-14 18:26:26.984] DEBUG: Will apply sql:
ALTER TABLE transaction DROP COLUMN IF EXISTS index
[2014-02-14 18:33:32.807] Updated database is at level 15

Didn't the additional indexes help?

Question: Is it possible to re-use the nxt_db directory when upgrading from 0.7.4 to 0.7.5  without downloading the whole blockchain again?

Raspis do have a tough time doing that, crashes 1-3 each time, must be restarted, takes severla hours in total...

No, no. It does not. Just overclock it at medium level. Works like a charm for me.

And yes, you can re-use the db of 0.7.4.

In fact the nxt.log above shows the migration from 0.7.4 to 0.7.5.

Thanks! I am reluctant about the overclocking, but I run it with -856xmx ...

[ChuckOne]

It turns out the transition to fractional amounts, which is required for reducing the minimum fee, will not be that simple. It would require adding a new transaction type, because the current ordinary payment transaction stores amounts and fees with 1 NXT precision, not multiplied by 100 as in the account balance. So it will take longer to implement and test. The positive side is that while doing that we can make the fractional part allow amounts much lower than 0.01, so we will achieve much higher divisibility.

We don't really need too much divisibility. Perhaps 1.00000 at max?

Sorry to disagree Eadeqa, we always seem at odds...
We need as much precision as possible. I am already seeing some issues with pricing things in AE. BCNext's vision is to run an entire economy on top of NXT. Assets are the key, that is why it is the only thing that costs more than minimum transaction, eg. 1000 NXT

We will need milliNXT and microNXT and maybe even nanoNXT so people can transact for things without quantization problems

James

P.S. I am trying to make sure that even after NXT goes above $1000 we can still buy a lollipop at a precise price.

I partly agree with you.

Still want to add something: we should be able to increase the precision step by step.

However, higher precision goes with lower fees possible.

If we lower the fees possible too fast, many forgers would certainly stop to forge. This would make the NXT network extremely insecure. We need time until the first services are build on top of NXT.

[Eadeqa]

P.S. I am trying to make sure that even after NXT goes above $1000 we can still buy a lollipop at a precise price.

even if Nxt goes to $1000, 0.00001 would be 1 cent

Too many decimal points bring confusion.

[ChuckOne]

Thanks! I am reluctant about the overclocking, but I run it with -856xmx ...

What does -856xmx do?

[ChuckOne]

P.S. I am trying to make sure that even after NXT goes above $1000 we can still buy a lollipop at a precise price.

even if Nxt goes to $1000, 0.00001 would be 1 cent

Too many decimal points bring confusion.

What do you mean exactly? Where will the confusion come from?

[jl777]

I've heard that NXT is working on a zerocoin implementation.

If so, how do you plan to address these limitations?

Zerocoin has a number of serious limitations:
- It uses cutting-edge cryptography which may turn out to be insecure, and which is understood by relatively few people (compared to ECDSA, for example).
- It produces large (20kbyte) signatures that would bloat the blockchain (or create risk if stuffed in external storage).
- It requires a trusted party to initiate its accumulator. If that party cheats, they can steal coin. (Perhaps fixable with more cutting-edge crypto.)
- Validation is very slow (can process about 2tx per second on a fast CPU), which is a major barrier to deployment in Bitcoin as each full node must validate every transaction.
- The large transactions and slow validation also means costly transactions, which will reduce the anonymity set size and potentially make ZC usage unavailable to random members of the public who are merely casually concerned about their privacy.
- Uses an accumulator which grows forever and has no pruning. In practice this means we'd need to switch accumulators periodically to reduce the working set size, reducing the anonymity set size. And potentially creating big UTXO bloat problems if the horizon on an accumulator isn't set in advance.

I prefer to trust a peer reviewed algo by Matt Green than any ad hoc mixing technique. We dont have to run faster than the bear, we just have to run faster than the slowest guy.

What I mean is that currently everything is totally open and correlatable. ANYTHING is better than that. That being said, we might as well go with the theoretically best solution and that in my opinion and many others is zerocoin's approach. Also, if it does get cracked, then it becomes the same as it is now.

All of the performance and storage issues are said to be solved with zerocoin2, which we will incorporate as soon as it is available to us. Hopefully in a prerelease. Validation times are ~10 milliseconds, size is 288 bytes

The trusted party is a onetime thing. My plan was to ask Anon to be videoed creating the initial dataset on a totally isolated computer. Then we copy the data onto portable storage put it in a faraday cage and detonate an EMP to erase everything on the computer that generated the initial data. Just dont tell Anon about this plan!

As far as issues with accumulators, that is part of the blackbox maths. I will have to defer to Matt Green to address such issues. We have a very talented community, if there comes a time that we need to take corrective action for issues like you are talking about I am confident that we will solve them

James

[Come-from-Beyond]

Not, if the runtime for calculating a sig is dependent on the number of bits of the payload.

It is a common misconception that basic operations are in O(1), but that's wrong. Even addition and multiplication of larger numbers take longer than of smaller numbers. The same hodls for sig function.

I like the conceptual idea of having set-based transactions because set-based thinking is one of the principle of modern computer science.

What I was trying to explain to you was that you should not make not unproven statements.
Show me the runtime complexity of the sig function in terms of payload length and we'll see.

NRS signs SHA256 of a message.

1 signature takes 100 times more CPU ticks than SHA256(32_random_bytes). Signing of a transaction that is 100 times longer ~ 2 ordinary signatures.

[mcjavar]

What does this mean?


[2014-02-14 10:39:40.346] DEBUG: Will pop block 5073332198957728923 at height 66148
[2014-02-14 10:39:40.347] DEBUG: Will pop block 8348856438008341233 at height 66147
[2014-02-14 10:39:40.348] DEBUG: Reversal of alias assignment not supported
[2014-02-14 10:39:40.348] DEBUG: Popping off last block not possible, will do a rescan
[2014-02-14 10:39:40.349] Re-scanning blockchain...
[2014-02-14 10:39:54.734] ...Done
[2014-02-14 10:39:54.737] DEBUG: Generate block failed: Previous block id doesn't match

Jean-Luc?

[greyw00lf]

please, can i get some coin?  my nxt address is 1954727322887273577

thanks
im convinced in this currency

Hi ErosLp, you can use the faucet at http://nxtra.org/faucet to get your first Nxt
or take a look at http://mynxt.org/#nxt
or use exchanges to buy some Nxt: http://mynxt.org/#exchanges

[jl777]

Depends which cost function you take into consideration. The size of the block part occupied by a multi-transaction would still be O(n) as are n transaction. So, yes, it could be cheaper by a factor of 2 or so.

A key thing that Nxt *has* over its rivals is fast txs. If I have a tx with 100 outputs and 1 sig vs. 100 outputs and 100 sigs then the latter is going to be slower both in terms of data size and sig verification.

So I think that Nxt should allow such more compact txs in order to provide the "leanest and meanest" tx system in the crypto currency world.

Agreed. We might as well be the best in all areas.

[greyw00lf]

@JL

Code:

[2014-02-14 18:23:55.255] Database is at level 13
[2014-02-14 18:23:55.267] DEBUG: Will apply sql:
ALTER TABLE block DROP COLUMN IF EXISTS index
[2014-02-14 18:26:26.984] DEBUG: Will apply sql:
ALTER TABLE transaction DROP COLUMN IF EXISTS index
[2014-02-14 18:33:32.807] Updated database is at level 15

Didn't the additional indexes help?

Question: Is it possible to re-use the nxt_db directory when upgrading from 0.7.4 to 0.7.5  without downloading the whole blockchain again?

Raspis do have a tough time doing that, crashes 1-3 each time, must be restarted, takes severla hours in total...

I don't have problems downloading the whole blockchain with my RPi (not overclocked), no crashes, no restarts. It takes hours... hmm yes maybe 1-2 hours, but you don't have to do that on every update. The last time i did was when i switched to 0.7.2. From then i always copied the db to my new nxt-folder.

No, no. It does not. Just overclock it at medium level. Works like a charm for me.

And yes, you can re-use the db of 0.7.4.

In fact the nxt.log above shows the migration from 0.7.4 to 0.7.5.

I didn't overclock mine. To what CPU-rate did you overclock it? Do you use some kind of cooling? My RPi is just in an ordinary plastic-case, no cooling at all...

[jl777]

P.S. I am trying to make sure that even after NXT goes above $1000 we can still buy a lollipop at a precise price.

even if Nxt goes to $1000, 0.00001 would be 1 cent

Too many decimal points bring confusion.

How much does a single crypto cost? One that is .0000000013 BTC? I just want to be able to not have to worry about bundling very small valued things so we dont have the quantization problem.

The GUI can hide the extra precision. I am not talking about display. I am talking about what the low level protocol supports.

I am also not talking about reducing the fee to .00000001 NXT. The fee should be reduced an order of magnitude at a time as we find that it is a problem.

Reworking the code to add precision is the time where we can figure out how to add the most digits without adding too much overhead. We dont have to use or display that precision, but if we can get it essentially for free, why not?

James

[Jean-Luc]

Question: Is it possible to re-use the nxt_db directory when upgrading from 0.7.4 to 0.7.5  without downloading the whole blockchain again?

Yes, it is designed to be possible to upgrade without having to delete the nxt_db directory, that's the reason I bother with applying those SQL statements.

If too slow for Raspberries, do whichever is faster, upgrade or download from scratch.

Did I manage to improve the Raspberry performance with the last release?

[Jean-Luc]

What does this mean?


[2014-02-14 10:39:40.346] DEBUG: Will pop block 5073332198957728923 at height 66148
[2014-02-14 10:39:40.347] DEBUG: Will pop block 8348856438008341233 at height 66147
[2014-02-14 10:39:40.348] DEBUG: Reversal of alias assignment not supported
[2014-02-14 10:39:40.348] DEBUG: Popping off last block not possible, will do a rescan
[2014-02-14 10:39:40.349] Re-scanning blockchain...
[2014-02-14 10:39:54.734] ...Done
[2014-02-14 10:39:54.737] DEBUG: Generate block failed: Previous block id doesn't match

This is all normal, works as intended. It is telling you exactly what is happening - popping off a block, doing a rescan because alias assignment cannot be simply undone in a pop-off. The block generation attempt failed because in the meantime another block arrived and was accepted.

[l8orre]

Thanks! I am reluctant about the overclocking, but I run it with -856xmx ...

What does -856xmx do?

It is the memory available to the jvm, I quoted it wrong:

ps -ax
 2040 ?        SNl   61:45 /usr/bin/java -Xms128m -Xmx856m -jar start.jar STOP.PORT=7873 STOP.KEY=0815


-Xms128m is the minimum that is reserved at the start, and -Xmx856m is the maximum it can have, in megabytes. I often had crashes with a maximum smaller 450MB, but with giving it almost all the memory, it runs quite good.

Except that dl'ing the whole blockcahin is quite some venture.

[l8orre]

Question: Is it possible to re-use the nxt_db directory when upgrading from 0.7.4 to 0.7.5  without downloading the whole blockchain again?

Yes, it is designed to be possible to upgrade without having to delete the nxt_db directory, that's the reason I bother with applying those SQL statements.

If too slow for Raspberries, do whichever is faster, upgrade or download from scratch.

Did I manage to improve the Raspberry performance with the last release?

once the blockchain is complete 0.7.4 is running quite smoothly at 1-3% cpu, and given lots of ram:

top
                                                              
 2040 pi        26   6  993m 385m 2768 S   1,0 88,0  61:54.85 java                                                                      
 3318 pi        20   0  4880 1324  976 R   1,0  0,3   0:01.18 top        

I think also the blockchain download was faster with 0.7.4, but I can't really tell, because I did not monitor the dl all the time ...

[ChuckOne]

Question: Is it possible to re-use the nxt_db directory when upgrading from 0.7.4 to 0.7.5  without downloading the whole blockchain again?

Yes, it is designed to be possible to upgrade without having to delete the nxt_db directory, that's the reason I bother with applying those SQL statements.

If too slow for Raspberries, do whichever is faster, upgrade or download from scratch.

Did I manage to improve the Raspberry performance with the last release?

What exactly do you mean by performance?

1) startup is slow as always. Especially these migrations

2) running is as good as always. Does not go above 5%.

3) RAM consumption is 1% lower. Still 87% of total memory.

[l8orre]

Question: Is it possible to re-use the nxt_db directory when upgrading from 0.7.4 to 0.7.5  without downloading the whole blockchain again?

Yes, it is designed to be possible to upgrade without having to delete the nxt_db directory, that's the reason I bother with applying those SQL statements.

If too slow for Raspberries, do whichever is faster, upgrade or download from scratch.

Did I manage to improve the Raspberry performance with the last release?

What exactly do you mean by performance?

1) startup is slow as always. Especially these migrations

2) running is as good as always. Does not go above 5%.

3) RAM consumption is 1% lower.

yes, which is why having the option of using the nxt_db is quite helpful