NXT :: descendant of Bitcoin - Updated Information

[Come-from-Beyond]

Ethereum: A Turing-Complete Cryptocurrency

This part might create problems. We don't need blockchain viruses, do we?

[1715650699]

1715650699

[1715650699]

1715650699

[1715650699]

1715650699

[1715650699]

1715650699

[coolfish]

Transaction exchange earnings, will be the most effective way to promote!

Trading platform may charge transaction fees, but deposit and withdraw cash fee should not be charged.

[jl777]

CfB,

How many mistakes did I make with the following?

*****
In order to understand Transparent Forging, we must first understand the forging process itself. The goal of NXT forging is to give a chance to each account proportional to the amount of NXT in the account. A small amount of randomness is required to eliminate the possibility of attacks based on knowing the far future forgers, but the near future should be as close to deterministic as possible to allow significant reduction in network bandwidth usage. These apparently contradictory requirements are satisfied by the following code from the Jan 3rd, 2014 source code release:

    Account account = unlockedAccountEntry.getKey();
    User user = unlockedAccountEntry.getValue();
    Block lastBlock = Block.getLastBlock();
    if ( lastBlocks.get(account) != lastBlock )
    {
        byte[] generationSignature = Crypto.sign(lastBlock.generationSignature, user.secretPhrase);
        byte[] generationSignatureHash = MessageDigest.getInstance("SHA-256").digest(generationSignature);
        BigInteger hit = new BigInteger(1, new byte[] {generationSignatureHash[7], generationSignatureHash[6], generationSignatureHash[5], generationSignatureHash[4], generationSignatureHash[3], generationSignatureHash[2], generationSignatureHash[1], generationSignatureHash[0]});
        lastBlocks.put(account, lastBlock);
        hits.put(account, hit);    // jl777: hit now contains a deterministic but pseudo-random number
        JSONObject response = new JSONObject();
        response.put("response", "setBlockGenerationDeadline");
        response.put("deadline", hit.divide(BigInteger.valueOf(Block.getBaseTarget()).multiply(BigInteger.valueOf(account.getEffectiveBalance()))).longValue() - (getEpochTime(System.currentTimeMillis()) - lastBlock.timestamp));
        user.send(response);
    }
    int elapsedTime = getEpochTime(System.currentTimeMillis()) - lastBlock.timestamp;
    if ( elapsedTime > 0 )
    {
        BigInteger target = BigInteger.valueOf(Block.getBaseTarget()).multiply(BigInteger.valueOf(account.getEffectiveBalance())).multiply(BigInteger.valueOf(elapsedTime));   // jl777: chance proportional to effective balance
        if ( hits.get(account).compareTo(target) < 0 ) {    // jl777: as time elapses the target gets larger, eventually triggering the acct closest to target.
            account.generateBlock(user.secretPhrase);
        }
    }

Due to the deterministic way the chances are calculated, it is possible to predict which acct will forge the next block and also when it will be forged. Since the hit value is deterministic, a person with multiple accounts can calculate which one has the best chance of forging the next block and transfer all the NXT to that acct. This is why the effective balance is used instead of the actual balance. A time delay from when an account is funded and also a time delay from when funds are transferred reduces the effective amount to eliminate NXT shuffling attacks.

By storing all of the hit values from all the accounts, if each node also knew which accounts are also actively forging, it will be possible for all nodes to predict which acct will forge the near future blocks. Due to variations in clocks and changing of active forging accts, it is not 100% accurate, but this is by design. There needs to be some error factor to prevent an attacker from calculating who will forge blocks in the far future to avoid the NXT shuffling attacks. As long as the prediction rate is close to 100%, the network traffic is reduced dramatically allowing for near realtime processing of thousands of transactions.

Transparent forging allows for a centralized action in a decentralized network. This is the fundamental breakthrough that NXT incorporates.
******

James

[salsacz]

I am looking at some real world PR opportunities - i think Kaiser is nobody in real world. In shitcoin/bitcoin world every teenager cares only about mining... But we need to get to Jimmy Kimmel, Ellen or Letterman. But to get there we should probably climb throught Kaiser... or not?

Does anyone have better connections with Winklevoss brothers?

This is one awesome citation:

Do you think the unequal distribution of bitcoin / big gains of early adopters will be a deterrent in a more widespread adoption of bitcoins?

Cameron Winklevoss

No. Early adopters get bigger gains (as they should) because they take on bigger risk. A bitcoin can be divided into 100 million pieces, so I don't see divisibility or distribution as a problem.

It is simple to contact them by twitter/reddit so we just need a wait a little for better timing.

another citations:

I view BTC more as an alternative to fiat currencies than a replacement.
I have not invested in any altcoins because I don't believe that any of the "problems" or issues that they address can't be addressed by Bitcoin itself

927 people own half of the bitcoins. Do you consider this a hindrance to its future market cap?

No. Bitcoins can be divided into 100 million pieces so its not important whether half of the bitcoins are held by 927 people or 9,270,000 people, etc.

[landomata]

Ethereum: A Turing-Complete Cryptocurrency

This part might create problems. We don't need blockchain viruses, do we?

I don;t know anything about this whole set-up.....my main takeaway was that article is Mastercoin is basically dead.....Ethereum kills Mastercoin.

[landomata]

If NXT is going to succeed, it is going to succeed because the average person worldwide starts using NXT via their cellphone.  

Let me say that again.

So - metal NXT medallions sold in blisterpacks to the 50-90% of the world with a cellphone who will never sit down at a computer and create their own 50 character passcode securely and randomly.  That's my concept.  If you think it's unworkable, then I ask you:

How can people with cellphones buy a candy bar with NXT?

I am in full agreement with you but I think this would be step 2 or 3.....right now we are just trying to get them to download Nxt for the 1st time on their phones.

The Nxt Mobile Applications Company wants 50% of the world who uses cellphones to just have Nxt on their phones.

To do this we have targeted messaging which is a basis function of cellphones....after a time we can unlock other features such as payment.

[coolfish]

I just posted a proposal to fix the account number typo-problem over at the official forums:
https://forums.nxtcrypto.org/viewtopic.php?f=17&t=524 <- making NXT account numbers awesome!

What do you think about that?

Looks cool. I would like to see some comment from CFB to make sure we don't interfere with some unrevealed feature, but then, I'll add it to Solaris.

Other client developers checking in?

I absolutely cast my vote for using a standardized Reed Solomon NXT account number all beginning with N containing the characters 2-9, A-Z while dropping the use of 0 and O and 1 and I. Adding just an N in front to denote "NXT" is a half measure. I think we should go for bold branding and have the first three characters of every address always be "NXT" so non-users recognize it and eventually become converts. This would bring the total length to exactly 20 characters, which can be either four groups of five separated by dashes, or five groups of four. I personally prefer the latter.  It isolates the RS correction data as the last block.

As far as I can see, we need a 64 characters alphabet, so if we drop 0, O, l and 1, we need 4 others. Let's do the further discussion in the OP's thread:

https://forums.nxtcrypto.org/viewtopic.php?f=17&t=524

nxt system should have a validation function to verify the account is available.

e.g:
acct: 209832084023840384023
MD5 & SHA Checksum: DfwSgeH

so the new account: DfwSgeH-209832084023840384023

Check the MD5 or SHA to verify the account available..

[stealthx]

.... The last thing a person with a cellphone is going to do is sit there and type in a 50 digit uppercase-lowercase password to buy a candy bar with NXT. ...

A lot of good thoughts from rickyjames. Everybody should read it.

[nexern]

nxt system should have a validation function to verify the account is available.

e.g:
acct: 209832084023840384023
MD5 & SHA Checksum: DfwSgeH

so the new account: DfwSgeH-209832084023840384023

Check the MD5 or SHA to verify the account available..

thanks for this example coolfish,
could you explain further please how this checksum approach can verify account available?

[newsilike]

.... The last thing a person with a cellphone is going to do is sit there and type in a 50 digit uppercase-lowercase password to buy a candy bar with NXT. ...

A lot of good thoughts from rickyjames. Everybody should read it.

Indeed good thoughts.
What I also think is that smart-watches will become more and more popular.
And if you are about too loose your phone you will be alarmed when a certain distance between your smart-phone and your smart-watch is reached.
(If you don't like smart-watches you can use bracelets or something casual)

The security measure I have with my phone is that I can erase it's memory from my computer (if a internet-connection is available)

[Come-from-Beyond]

CfB,

How many mistakes did I make with the following?

*****
In order to understand Transparent Forging, we must first understand the forging process itself. The goal of NXT forging is to give a chance to each account proportional to the amount of NXT in the account. A small amount of randomness is required to eliminate the possibility of attacks based on knowing the far future forgers, but the near future should be as close to deterministic as possible to allow significant reduction in network bandwidth usage. These apparently contradictory requirements are satisfied by the following code from the Jan 3rd, 2014 source code release:

    Account account = unlockedAccountEntry.getKey();
    User user = unlockedAccountEntry.getValue();
    Block lastBlock = Block.getLastBlock();
    if ( lastBlocks.get(account) != lastBlock )
    {
        byte[] generationSignature = Crypto.sign(lastBlock.generationSignature, user.secretPhrase);
        byte[] generationSignatureHash = MessageDigest.getInstance("SHA-256").digest(generationSignature);
        BigInteger hit = new BigInteger(1, new byte[] {generationSignatureHash[7], generationSignatureHash[6], generationSignatureHash[5], generationSignatureHash[4], generationSignatureHash[3], generationSignatureHash[2], generationSignatureHash[1], generationSignatureHash[0]});
        lastBlocks.put(account, lastBlock);
        hits.put(account, hit);    // jl777: hit now contains a deterministic but pseudo-random number
        JSONObject response = new JSONObject();
        response.put("response", "setBlockGenerationDeadline");
        response.put("deadline", hit.divide(BigInteger.valueOf(Block.getBaseTarget()).multiply(BigInteger.valueOf(account.getEffectiveBalance()))).longValue() - (getEpochTime(System.currentTimeMillis()) - lastBlock.timestamp));
        user.send(response);
    }
    int elapsedTime = getEpochTime(System.currentTimeMillis()) - lastBlock.timestamp;
    if ( elapsedTime > 0 )
    {
        BigInteger target = BigInteger.valueOf(Block.getBaseTarget()).multiply(BigInteger.valueOf(account.getEffectiveBalance())).multiply(BigInteger.valueOf(elapsedTime));   // jl777: chance proportional to effective balance
        if ( hits.get(account).compareTo(target) < 0 ) {    // jl777: as time elapses the target gets larger, eventually triggering the acct closest to target.
            account.generateBlock(user.secretPhrase);
        }
    }

Due to the deterministic way the chances are calculated, it is possible to predict which acct will forge the next block and also when it will be forged. Since the hit value is deterministic, a person with multiple accounts can calculate which one has the best chance of forging the next block and transfer all the NXT to that acct. This is why the effective balance is used instead of the actual balance. A time delay from when an account is funded and also a time delay from when funds are transferred reduces the effective amount to eliminate NXT shuffling attacks.

By storing all of the hit values from all the accounts, if each node also knew which accounts are also actively forging, it will be possible for all nodes to predict which acct will forge the near future blocks. Due to variations in clocks and changing of active forging accts, it is not 100% accurate, but this is by design. There needs to be some error factor to prevent an attacker from calculating who will forge blocks in the far future to avoid the NXT shuffling attacks. As long as the prediction rate is close to 100%, the network traffic is reduced dramatically allowing for near realtime processing of thousands of transactions.

Transparent forging allows for a centralized action in a decentralized network. This is the fundamental breakthrough that NXT incorporates.
******

James

I marked with red an incorrect statement. Also u should add that network topology is a major factor that makes far predictions impossible.

[Come-from-Beyond]

An interesting thread about hardware Nxt wallet - https://nextcoin.org/index.php/topic,728.msg27895.html#msg27895

[coolfish]

nxt system should have a validation function to verify the account is available.

e.g:
acct: 209832084023840384023
MD5 & SHA Checksum: DfwSgeH

so the new account: DfwSgeH-209832084023840384023

Check the MD5 or SHA to verify the account available..

thanks for this example coolfish,
could you explain further please how this checksum approach can verify account available?

it just a simple example.

acct: 209832084023840384023
MD5 & SHA Checksum: DfwSgeH    // from MD5("accountid")

so the new account: DfwSgeH-209832084023840384023  // from  substr(MD5("accountid"),6)+ "- accountid"

//substr(MD5("209832084023840384023"),6)=="DfwSgeH"
if( substr(MD5("209832084023840384023"),6)==substr("DfwSgeH-209832084023840384023",6) ) it is available..
else unavailable.

Each new account is password and userid combination : password-userid

[vanea84]

I have an idea to add a feature to copy the number NXT of the purse to the clipboard. Will be very convenient

[nexern]

nxt system should have a validation function to verify the account is available.

e.g:
acct: 209832084023840384023
MD5 & SHA Checksum: DfwSgeH

so the new account: DfwSgeH-209832084023840384023

Check the MD5 or SHA to verify the account available..

thanks for this example coolfish,
could you explain further please how this checksum approach can verify account available?

it just a simple example.

acct: 209832084023840384023
MD5 & SHA Checksum: DfwSgeH    // from MD5("accountid")

so the new account: DfwSgeH-209832084023840384023  // from  MD5("accountid")+ "- accountid"

if( MD5("209832084023840384023")=="DfwSgeH"  ) it is available..
else unavailable.

yes, so far so good but how will this prevent from sending funds to a unknown account (hiberNXT)?
really, i don't get it (well, my had is full with gui & code atm) but the only way to reduce
the risk is to make a realtime check in front of each transfer but even this is not solid
because the account you intend to send funds could be a just unlocked one without any transaction
history and therefore unknown to the bc. at least this approach could give the user a feedback
to decide if the transfer should make or not.

how does a checksum fit's into this scenario or do i oversee something here?

[NxtChoice]

I need a little advice: How can we calculate a daily cost of Nxt web?

Something like:
number of peers x watts of the average computer? and transfer kW in Dollars?

Do we know a number of forging computers?

I do a simple calculation for you as following:

Say 10, 000 nodes in the network for Nxt, as you know there are about 10,000 accounts.

Say each node is a Pi, say each pi consumes 10Watts, so total 100kW, it's 2400 kWh, which is just $600 a day with $0.25 per kWh.

Say each node is a server with 500 Watts, that's 50 times of the above calculation, so it is about $30,000 a day.

So I predict a total power consumption is in the range of $600 ~ $30,000 a day, and most probably below $10000.

Wow, that's the most efficient system in the crypto currency world.


Edit: go on a simple calculation of the price for Nxt. Presently a day's tx fee is ~ 5000 Nxt, if it should cover the power consumption, that is, $600/5000 ~ $30,000/5000, so the Nxt price in the range $0.12 ~ $6.

Yeah, my pricing for Nxt is $0.12 ~ $6.

But there are 300 nodes, not 10k:

http://peerexplorer.com/

donate(1), 22k(3), 22k.io(66), BEER(1), CentOS(2), FreeBSD(1), linux(6), NCC-1701-D(1), NCC-1864(1), nxt.now.im(12), nxt86(2), PC(121), PC BaiMang...(2), PC-2212(1), Raspberry(1), RaspNXT(1), Rpi(1), RPi Solari...(1), SPARC(1), strawberry(1), Unknown(43), VPS(17), xrp.pw/nxt(1):

(4+66+1+1+12+2+43+17+1)x20W = 3kW
+
(2+6+1+1+121+2+1+1+1+1+1+1+1)x5W = 0.7kW

= 4kW

24(hours)x4(kW)x0.15/kWh = 14 USD

That just provides a rough calculation, and I don't think there is only 300 nodes, which should be ~ 300 public nodes, but there are many private nodes in the network.

[vanea84]

An interesting thread about hardware Nxt wallet - https://nextcoin.org/index.php/topic,728.msg27895.html#msg27895

+1

[ricot]

nxt system should have a validation function to verify the account is available.

e.g:
acct: 209832084023840384023
MD5 & SHA Checksum: DfwSgeH

so the new account: DfwSgeH-209832084023840384023

Check the MD5 or SHA to verify the account available..

thanks for this example coolfish,
could you explain further please how this checksum approach can verify account available?

it just a simple example.

acct: 209832084023840384023
MD5 & SHA Checksum: DfwSgeH    // from MD5("accountid")

so the new account: DfwSgeH-209832084023840384023  // from  substr(MD5("accountid"),6)+ "- accountid"

//substr(MD5("209832084023840384023"),6)=="DfwSgeH"
if( substr(MD5("209832084023840384023"),6)==substr("DfwSgeH-209832084023840384023",6) ) it is available..
else unavailable.

Each new account is password and userid combination : password-userid

Please see my thread about that in the other forum: https://forums.nxtcrypto.org/viewtopic.php?f=17&t=524
We can do a lot better than merely detecting if the user made an error. With the method presented there, we can correct what the user typed. - That's 2nd gen. :p

[NxtChoice]

Gang,

Would appreciate Chinese speakers looking this over for errors. Also, I know nothing about leading/kerning/spacing with Chinese characters and what's appropriate.



Also, full-size PDF is here

EDIT: sorry, forgot to credit Miramare from the nextcoin.org forum for supplying Chinese text.

There are more features without mention, for example, arbitrary message, voting system and so on.

[nexern]

nxt system should have a validation function to verify the account is available.

e.g:
acct: 209832084023840384023
MD5 & SHA Checksum: DfwSgeH

so the new account: DfwSgeH-209832084023840384023

Check the MD5 or SHA to verify the account available..

thanks for this example coolfish,
could you explain further please how this checksum approach can verify account available?

it just a simple example.

acct: 209832084023840384023
MD5 & SHA Checksum: DfwSgeH    // from MD5("accountid")

so the new account: DfwSgeH-209832084023840384023  // from  substr(MD5("accountid"),6)+ "- accountid"

//substr(MD5("209832084023840384023"),6)=="DfwSgeH"
if( substr(MD5("209832084023840384023"),6)==substr("DfwSgeH-209832084023840384023",6) ) it is available..
else unavailable.

Each new account is password and userid combination : password-userid

Please see my thread about that in the other forum: https://forums.nxtcrypto.org/viewtopic.php?f=17&t=524
We can do a lot better than merely detecting if the user made an error. With the method presented there, we can correct what the user typed. - That's 2nd gen. :p

thx, ricot,

ok, understood. usefull for users typing in account numbers but this doesn't answer my question.
this doesn't help to prevent sending funds to hiberNXT, or does it and if, could you please explain how?

as said, i am currently on this, therefore i would like to understand the whole procedure.
from what i see the main problem is to copy or even type a number to send funds to
which is not the intended number and therefore the funds are lost in hiberNXT.

is this what we are talking about?