NXT :: descendant of Bitcoin - Updated Information

[gs02xzz]

Berlin conf
Fantastic job!!! I know how tiring tradeshows are, without the naked women to look at it is just all work.

I only dreamed about an entire country using crypto as their national currency. It sounds like many smaller countries are ready now!

I propose a bounty for a coin development kit. It needs to make creating a new coin push button easy. I am not sure even how it should be implemented, but it needs to be something that can be used as a replacement currency for an entire country. I guess QR codes on mobile apps to do payments would work for a realworld economy. The more customization options the better.

I will start the bounty with 25000 NXT. If you also like the coin development kit idea, please make a directed donation. just post txid and amount sent to NXTcommunityfund 13776816462073143763

James

Why don't ask cfb how he will create Lak? He mentioned that it would only cost several hundreds of Nxt to create Lak.

[CIYAM]

Do not think that calculate 1 sig has constant runtime = O(1). It should be depend on the size of the to-be-verified payload.

Huh?

You've lost me - a sig is a sig - that is a one time function over data.

If you have a tx that outputs from X to 1000 other accounts it only requires 1 sig check at the end to verify. That will be basically 1000x faster than having a sig for each of the 1000 accounts.

Still not clear?

[jl777]

Firstly for this to work each maybe you need gateway relationship to be verified bi-laterally, i.e. a gateway to gateway trust relationship is pre-established, I am not sure this exists in the Ripple model which is why I think there is a problem - is this what you mean by federation.

this is precisely what i mean by federation.

Each buyer and seller legitimise the asset with each gateway involved e.g. deposit asset in escrow or reserve somehow.
The buyer sends the transaction request to the sellers gateway to buy the asset (with the relevant buy/sell asset ids from each gateway)
The sellers gateway initiates a transaction on the block chain which is seen by buyers gateway and this is validated by forging as legitimate (e.g. 10 confirms?)
The buyers gateway then confirms the transaction by re-submitting again to be validated by forging to confirm the buyer honours the contract.
The two gateways can then release the escrow asset to the buyer and seller respectively.
The transaction ledger could be the NXT blockchain, once the transaction is validated by forging the seller gateway releases the asset to the buyer and the buyer gateway releases the asset to the seller.
The buyer/seller gateways would get their fees from the buyer/seller respectively
There is a NXT fee for each of the transactions involved.

What  I am trying to achieve is the gateways are acting to ensure the safe transfer of an asset between two parties but maybe this is too hard complicated?
For widespread adoption there needed to be trust in the integrity of the transaction and that should be down to whether Anon, Bob or Sally tokens have a different trust level.
Without some level of transaction legitimacy validated by NXT itself I fear we would have a massive dispute resolution problem with scam buyers as much of a problem as scam sellers.

ok so for all of the gateways that want to federate create a multig address to hold the btc that acts as reserve for the FederatedBTCTokens. If bob issues 5 FederatedBTCTokens than he also deposits 5 btc in the multisig address. Lets say bob and betty are federated. The FederatedBTCToken that bob issued is claimed at betty's gateway. Betty signs the transaction and publishes her signed transaction on the NXT blockchain. Of course its a multisig account so 1 signature is not enough. Bob is monitoring the blockchain. He sees the signed transaction. He downloads the transaction from the blockchain, adds his signature, and then broadcasts the transaction.

bob feels safe because he knows betty can not steal his btc without his signature. the buyer feels safe because he knows the btc is in reserve and that if bob were to attempt to misbehave than betty would offer some protection against this. betty feels safe because she is not extending a line of credit to bob, there is 100% reserve in a shared address.

Do I have this right? I think its a great idea if i do.

yes thats it!
Also, all deposit and withdrawal requests are via AM, everything is transparent. All gateways and actually anybody can monitor the expected balance of the multisig acct and if there is ever a discrepancy, it is detected right away.

I am still worried about all the deposits getting lost in case two gateways disappear (assuming 4 of 5 multisig), but I think it might be possible to create an unpublished transaction that simply empties the account into a new emergency dead man switch acct. This would be set to happen at the beginning of every month. Then the worst case scenario is that we have to wait a month to recover from simultaneous disappearence of two gateways. Also, prior to the next month, all the gateways need to transfer all the funds into a new multisig to avoid the deadman switch.

Something like that, I just had that idea as I was typing so I am sure it can be improved. Since you are approving of multisig approach, I will start authorize starting the coding for the automated multisig gateway.

I am currently in contact with 2 groups who want to provide gateway services. I am looking for at least 3 more. There will not be much profit in being a gateway from deposits and withdrawal fees. I am hoping that it will be as close to 0 as possible. If you are planning on being rich from running a gateway, change plans. Having a path into NXT AE for all other cryptos without any fees will be the best solution. If anybody doubts this, I just mention one word: "dgex" I say no more about fees.

What incentive is there to be a gateway other than community appreciation?
Plenty! NXT is decentralized and there are no official contacts businesses (or countries) can make if they want to quickly get up to speed, eg. issue Assets, custom coins, etc. Who will they naturally turn to? The community gateway businesses, who else.

I will continue posting valuable business ideas for anybody to be able to make a nice living with, but the gateways will have an advantage for a lot of these ideas. The reason is that they are the ones that are the gatekeepers into the NXT economy. So, view being part of the multisig gateway as the foundation for many other ways to monetize. You probably all have a lot of NXT anyway, so making NXT worth 10 times more might even be sufficient motivation.

Anyway, I am calling for people who want to be a gateway. Oh, the community will make sure the automated software works and is reliable. Not sure if we will go as far as make a push button GUI to setup a gateway, so you probably need to know linux command line. The Amazon secure servers seem like a good place to run a gateway server on.

This is all coming together nicely.

James

[Sebastien256]

http://87.230.14.1/nxt/nxt.cgi?action=3000&acc=2584657662098653454

24 Million NXT? In one account. Holy crap.

yea 2.4% is too much of the stake. that person needs to sell for the sake of the security of the network.

ho well, if you think 24 millions is high... check this http://blocks.nxtcrypto.org/nxt/nxt.cgi?action=34
some people should sell a part of their NXT.

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

[ChuckOne]

Do not think that calculate 1 sig has constant runtime = O(1). It should be depend on the size of the to-be-verified payload.

Huh?

You've lost me - a sig is a sig - that is a one time function over data.

If you have a tx that outputs from X to 1000 other accounts it only requires 1 sig check at the end to verify. That will be basically 1000x faster than having a sig for each of the 1000 accounts.

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.

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

This is very good news actually. The reason is 1 NXT is clearly way too big for tipbot, but .1 or .01 is fine, so if it was easy it would have meant a long delay to get the added precision beyond the .01

My latest projections are showing that 1000TPS is most definitely a real possibility to happen, this year. Imagine if the entire economy of a country was run on top of NXT. Even a .0001 fee would generate 6 NXT for every block, which is a lot more than it is now. Those 6 NXT would also be worth a lot more at that stage.

Not sure where it is on the priority list of things, but I would rank it very high to get more precision to NXT.

James

[ChuckOne]

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

[jl777]

Not now, this will open another can of worms.

Okay - the Nxt Script stuff is probably going to open a few such nasty cans.

binary encoding and dynamic max TPS too

[erik__]

http://87.230.14.1/nxt/nxt.cgi?action=3000&acc=2584657662098653454

24 Million NXT? In one account. Holy crap.

yea 2.4% is too much of the stake. that person needs to sell for the sake of the security of the network.

Looking at their history they have done a lot of selling and probably would sell more if the price went back above a dime.

[ChuckOne]

Not now, this will open another can of worms.

Okay - the Nxt Script stuff is probably going to open a few such nasty cans.

binary encoding and dynamic max TPS too

Oh, yes. Therefore, compression is better for the first period until we need more.

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