NXT :: descendant of Bitcoin - Updated Information

[bizz]

Is there any user friendly wallet?

http://nxtra.org/nxt-wallet/

They should add a linux version. As it is Java, that shouldn't be a problem.

+1 Where can I donate for this?

[IveBeenBit]

I need lots of textNXT, it seems testnet has gone back in time

18232225178877143084

James

The latest NRS that was released today nuked testnet. Jean Luc announced this. We need to start from scratch.

I need test nxt also: 4PZP-Z76P-BKPR-DV4LL

(that's the new address format)

Old format: 13351022221574887413

[jl777]

I need lots of textNXT, it seems testnet has gone back in time

18232225178877143084

James

The latest NRS that was released today nuked testnet. Jean Luc announced this. We need to start from scratch.

I need test nxt also: 4PZP-Z76P-BKPR-DV4LL

(that's the new address format)

Old format: 13351022221574887413

Its acting all wonky.
It shows I have assets, then it disappears, then reappears.
I will just code and check back later, hopefully the network will have settled down by then

[coin-table]

Hi,

I'm running http://crypto-coins-table.com

If you have additional information NXT please update here:

http://crypto-coins-table.com/index.php?var_action=coin_details&coin_id=NXT

thanks

[Patel]

Anyone know if BCNext will give a contract to another great developer after April 5?

[msin]

Anyone know if BCNext will give a contract to another great developer after April 5?

We have the greatest developer, for a little while longer
https://bitcointalk.org/index.php?topic=553205.msg6024236#msg6024236

[xyzzyx]

Anyone know if BCNext will give a contract to another great developer after April 5?

We have the greatest developer, for a little while longer
https://bitcointalk.org/index.php?topic=553205.msg6024236#msg6024236

[rdanneskjoldr]

Anyone know if BCNext will give a contract to another great developer after April 5?

https://bitcointalk.org/index.php?topic=553205.0

I guess BCNext just left Nxt in our hands.If we want to do something,we just do it.He wont hire anyone.

[allwelder]

I am getting close to release candidate for multigateway
I would like somebody that is fluent in C and familiar with bitcoind to do a code review

James

great.

[bahamapascal]

Amazing to see how Nxt is progressing! Good job every one that is responsible for the success!

I do have a question about the decentralized exchange. As the day draws closer that its getting released, its time to learn the exact details how it works.
As a big fan of Nxt and of CryptogenicBullion ( CGB),  I am highly interested to get CGB to be one of the first assets trading on the Nxt system
Is there any documentation available on how to create and maintain an asset, or  how the whole process works?
Any help would be greatly appreciated!

If CGB is a bitcoind fork and supports multisig, I could add it to multigateway

Then there would be a seamless way of depositing and withdrawing CGB into NXT AE and back out to CGB wallets

The deposited CGB would be kept in multisig accts that no single server can unlock, all three need to reach consensus on all withdraws and all balances are publicly viewable so there is no guessing as to the solvency.

James

Did a quick look-see and it appears to be a fork of Peercoin.  Also, from https://github.com/cryptogenicbonds/CGB/blob/master/src/script.h

enum txnouttype
{
    TX_NONSTANDARD,
    // 'standard' transaction types:
    TX_PUBKEY,
    TX_PUBKEYHASH,
    TX_SCRIPTHASH,
    TX_MULTISIG,
};

That would be awesome James! And as  xyzzyx already pointed out, CGB is a fork of Peercoin (though with some exceptional features aimed at investors ) and to my knowledge supports multisig.
If you could add it to your multigateway, that would be marvelous! In case you need any tech info/support, you can PM "Artiface" the lead coder or just drop in on the official CGB thread here .
Is there already any ETA when your gateway will be ready to use?
Once CGB is exchangeable on the gateway, I would be more then happy to make a donation to show my appreciation

I am hoping to get a decent beta release out by the weekend, but not sure how long it will take to find and fix all the bugs

https://nxtforum.org/multigateway-(third-party)/multigateway-beta-test-signup/ is the signup for beta testers
https://nxtforum.org/multigateway-(third-party)/multigateway-status-reports/ is where I post regular status updates

James

Just want to give you a heads up, I spoke with the lead coder of CryptogenicBullion and he is currently reviewing the CGB code and evaluating what can be done in regards with multisig. He will contact you sometime soon for discussion.

Again, thanks for your support!

[CIYAM]

Floating point for "scientific calculations" is and always has been *perfectly fine*.

Money is not "scientific calculations" and *everyone in the money business* knows that you don't use binary floating point.

Again my simple example:

Code:

#define test( v1, op, v2 ) if( v1 op v2 ) printf( #v1 " " #op " " #v2 "\n" )

#include <stdio.h>
#include <math.h>

int main( )
{
   volatile double a, b, c;
   char buf[ 50 ];

   a = 13.06;
   b = 0.54;
   sprintf( buf, "%lf", a + b );
   c = atof( buf );

   printf( "a = %lf, b = %lf, c = %lf\n", a, b, c );

   test( c, >, 13.60 );
   test( c, ==, 13.60 );
   test( c, <, 13.60 );
   test( a + b, >, 13.60 );
   test( a + b, ==, 13.60 );
   test( a + b, <, 13.60 );

   return 0;
}

Basically it shows that 13.06 + 0.54 != 13.60 and this is because 0.1 (and 0.01) *cannot* be represented in binary floating point (same as 1/3 cannot be represented in decimal).

The problems are *not just rounding issues* but actually are *logic issues* (and therefore not obvious to "math" people who are only thinking about things like rounding).

It means that code which say says is A > 0 might *fail* because of a simple addition or subtraction.

[jl777]

Floating point for "scientific calculations" is and always has been *perfectly fine*.

Money is not "scientific calculations" and *everyone in the money business* knows that you don't use binary floating point.

Again my simple example:

Code:

#define test( v1, op, v2 ) if( v1 op v2 ) printf( #v1 " " #op " " #v2 "\n" )

#include <stdio.h>
#include <math.h>

int main( )
{
   volatile double a, b, c;
   char buf[ 50 ];

   a = 13.06;
   b = 0.54;
   sprintf( buf, "%lf", a + b );
   c = atof( buf );

   printf( "a = %lf, b = %lf, c = %lf\n", a, b, c );

   test( c, >, 13.60 );
   test( c, ==, 13.60 );
   test( c, <, 13.60 );
   test( a + b, >, 13.60 );
   test( a + b, ==, 13.60 );
   test( a + b, <, 13.60 );

   return 0;
}

Basically it shows that 13.06 + 0.54 != 13.60 and this is because 0.1 (and 0.01) *cannot* be represented in binary floating point (same as 1/3 cannot be represented in decimal).

The problems are *not just rounding issues* but actually are *logic issues*.

It means that code which say says is A > 0 might *fail* because of a simple addition or subtraction.

Your example is shocking and makes people want to forbid using floating point.

Not comparing against epsilons or doing things like
if ( fabs(x) < SMALLVALL ) for comparing to zero is not a logic issue, that is a coding bug that a code review would find.

In any case, if summing nodecoin allocations ends up going above the payout threshold (or not) one block ahead (or behind), the world wont end.

If you feel so strongly about this, you are free to rewrite the nodecoin pool allocation however you want as I prefer to use the CPU's built in floating point vs. software libraries to get better approx than 64 bit floats gets.

I just dont see the horrible things that could happen due to:

                    nxtacct->dnodecoins += nxtacct->dcurrent_nodecoins;
                    nxtacct->dcurrent_nodecoins = ((blockrate * ip->nodeshares) / sum);
                    ip->nodeshares = 0;
                    dsum += nxtacct->dcurrent_nodecoins;
                    if ( nxtacct->dnodecoins >= NODECOIN_MINPAYOUT )
                    {
                        satoshis = (int64_t)nxtacct->dnodecoins * SATOSHIDEN;
                        transfer_txid = issue_transferAsset(mp->NXTACCTSECRET,nxtacct->NXTaddr,NODECOIN,satoshis/SATOSHIDEN,MIN_NXTFEE,1440,0);
                        if ( transfer_txid != 0 )
                        {
                            printf("PAYOUT txid.%lx NXT.%s <- %.8f nodecoins\n",(long)transfer_txid,nxtacct->NXTaddr,(double)satoshis/SATOSHIDEN);
                            nxtacct->nodecoins_sent += satoshis;
                            nxtacct->dnodecoins -= (int64_t)nxtacct->dnodecoins;
                        }
                    }

The variables starting with "d" are doubles. The super dangerous usage of floating point adds each blocks earned nodecoins to "dnodecoins". If it compares as above the NODECOIN_MINPAYOUT threshold, it pays out and deducts what was paid out. If it miscompares, then it will payout the next block

Also, using data from my use case, using doubles was more accurate than using ints, but maybe I just dont know how to program. Please tell me what is wrong with my usage and please do not bring up hardcat or demo programs that dont apply to this use case

James

[jl777]

Floating point for "scientific calculations" is and always has been *perfectly fine*.

Money is not "scientific calculations" and *everyone in the money business* knows that you don't use binary floating point.

Again my simple example:

Code:

#define test( v1, op, v2 ) if( v1 op v2 ) printf( #v1 " " #op " " #v2 "\n" )

#include <stdio.h>
#include <math.h>

int main( )
{
   volatile double a, b, c;
   char buf[ 50 ];

   a = 13.06;
   b = 0.54;
   sprintf( buf, "%lf", a + b );
   c = atof( buf );

   printf( "a = %lf, b = %lf, c = %lf\n", a, b, c );

   test( c, >, 13.60 );
   test( c, ==, 13.60 );
   test( c, <, 13.60 );
   test( a + b, >, 13.60 );
   test( a + b, ==, 13.60 );
   test( a + b, <, 13.60 );

   return 0;
}

Basically it shows that 13.06 + 0.54 != 13.60 and this is because 0.1 (and 0.01) *cannot* be represented in binary floating point (same as 1/3 cannot be represented in decimal).

The problems are *not just rounding issues* but actually are *logic issues* (and therefore not obvious to "math" people who are only thinking about things like rounding).

It means that code which say says is A > 0 might *fail* because of a simple addition or subtraction.

Q1 What is the error rate of representing 1/3 with int64_t vs double?
Q2 Is nodecoin a financial money application?

[CIYAM]

Q1 What is the error rate of representing 1/3 with int64_t vs double?
Q2 Is nodecoin a financial money application?

James - rounding is rounding - the accuracy is the "size of the mantissa" and the problem with a double is it has a smaller mantissa than a 64 bit integer (as it holds both mantissa and exponent in the same 64 bit space).

So for *accuracy* an "integer" is always going to be *better* than a "floating point" of the same "size".

I really don't care about nodecoin at all - so if you've used binary floating point in that code only then that is good.

[jl777]

Q1 What is the error rate of representing 1/3 with int64_t vs double?
Q2 Is nodecoin a financial money application?

James - rounding is rounding - the accuracy is the "size of the mantissa" and the problem with a double is it has a smaller mantissa than a 64 bit integer (as it holds both mantissa and exponent in the same 64 bit space).

So for *accuracy* an "integer" is always going to be *better* than a "floating point" of the same "size".

I really don't care about nodecoin at all - so if you've used binary floating point in that code only then that is good.

Yes, 53 bits is less than 64 (or 63) bits, but the extra dynamic range gained by floating point can compensate in some cases. Otherwise, why would anybody use floating point.

Your statement that

So for *accuracy* an "integer" is always going to be *better* than a "floating point" of the same "size".

would be true if you had assurance on the dynamic range of the input numbers. However, if you have to deal with some really small values and also some relatively much larger values, then floating point wins in the average error case.

Basically, if the smallest to biggest has a ratio of less than 10 or 11 bits (1024 to 2048), then using integers will make sense. however if the dynamic range is a lot bigger, say a million to 1, then that is 20 bits. In that case, you risk creating an overflow using integers or have to accept a higher error rate.

Maybe you have a way of using dynamic multipliers depending on the scale of the number, but talk about overcomplicating things and the chance for bugs. With floating point you can just go x += y, and not have to worry about scaling and the error rate is decent.

There should not be a ban on using floating point. I would never dream of telling you that you had to use floating point for everything. why the need to tell me what parts of the CPU I am not allowed to use?

James

Edit: Using satoshi as least common denominator: 1/3 -> .33333333 so, error rate using integer is .000000003333333...
that is much worse than errors with doubles, which goes out to around 14 digits +/- .000000000000001

[r0ach]

I would be able to take this currency much more serious if it at least had a decimal place.  Forget "decentralized exchange", "decentralized crack houses", "whatever", where is the god damn decimal place???

[achimsmile]

I would be able to take this currency much more serious if it at least had a decimal place.  Forget "decentralized exchange", "decentralized crack houses", "whatever", where is the god damn decimal place???

Captain Picard is implementing it as we speak.... god damn it

https://bitbucket.org/JeanLucPicard/nxt/commits/branch/feature/nqt

NQT means Nxt Quant, it allows 8 decimal places

[Eadeqa]

I would be able to take this currency much more serious if it at least had a decimal place.  Forget "decentralized exchange", "decentralized crack houses", "whatever", where is the god damn decimal place???

It's here https://nxtforum.org/general-discussion/name-for-10-8-nxt/

[Fatih87SK]

I would be able to take this currency much more serious if it at least had a decimal place.  Forget "decentralized exchange", "decentralized crack houses", "whatever", where is the god damn decimal place???

You mean like 0.0005 NXT?

Developers are working on that right now.

[bitcoinpaul]

I would never dream of telling you that you had to use floating point for everything. why the need to tell me what parts of the CPU I am not allowed to use?

Don't get emotional, please.