NXT :: descendant of Bitcoin - Updated Information

[punkrock]

If someone has an invite code for Bittrex.com, please PM me.

P.S.: Got a tweet from Mintpal

[Jean-Luc]

Jean-Luc

Please finally confirm, that messages "DEBUG: Block XXXXXXXXXXXXXXXXXXX not accepted. Previous block id doesn't match" are not a problem. I get these messages on 90% blocks of blockchain on my Android TV stick public node. Nobody explained what does it mean and I don't want be a problem on the whole network with my public node.

If you check the block id and the latest blocks in your client, you will almost always see that this same block was actually accepted. Especially when you are running a public node, when a new block appears on the network many of your peers will submit it to you at the same time. Obviously, only one of those submissions gets included in the blockchain, and just after that happens for all the others the previous block id is no longer the same, so they get rejected.

[rickyjames]

At this writing, NXT costs under 0.1 satoshi each.

should be "under 10000 satoshi", right?

And you could mention the "solved" 51%-attack-problem, by POS-coins in general and especially with NXT and TF

Thank you.  I confused mBTC and satoshi.  And good point about 51% attack, that is definitely another meme to put in there.

[bitcoinpaul]

NXT Vs. Bitcoin

Brainwallet Accessability
Bitcoin requires storing a large digital file (the “wallet”) for use on only one computer. NXT allows knowing a short, ultrastrong password (35+ truly random characters) to access NXT funds from anywhere on Earth.

Properly speaking, Bitcoin doesn't require storing a large digital file. This is the wallet implementation, but not the bitcoin protocol. Nxt Protocol has no wallet, but who knows what the client devs will do with it in the future.

Active Community
5000+ NXTers from 50+ countries are united in a vibrant online community.  We don’t just talk, we act.  We’re growing. Come join us!

This is so true!

NXT First 100 Days – WOW!

So much wow

[Jean-Luc]

Maybe I should just disable debug logging by default, it only makes people think something is wrong. The intention was to make it easier to follow what is going on with the block and transaction processing, in the cases where something does go wrong.

[martismartis]

Jean-Luc

Please finally confirm, that messages "DEBUG: Block XXXXXXXXXXXXXXXXXXX not accepted. Previous block id doesn't match" are not a problem. I get these messages on 90% blocks of blockchain on my Android TV stick public node. Nobody explained what does it mean and I don't want be a problem on the whole network with my public node.

If you check the block id and the latest blocks in your client, you will almost always see that this same block was actually accepted. Especially when you are running a public node, when a new block appears on the network many of your peers will submit it to you at the same time. Obviously, only one of those submissions gets included in the blockchain, and just after that happens for all the others the previous block id is no longer the same, so they get rejected.

OK, thank you for explanation for simple Joe. Now I can go to sleep and leave my node running

[martismartis]

Maybe I should just disable debug logging by default, it only makes people think something is wrong. The intention was to make it easier to follow what is going on with the block and transaction processing, in the cases where something does go wrong.

Leave it, just simple Joe wants to know, that everything is OK with these messages.

[^[GS]^]

0.7.6 debugs...

Code:

[2014-02-19 17:28:39.840] NRS 0.7.6 starting...
[2014-02-19 17:28:39.841] DEBUG logging enabled
[2014-02-19 17:28:39.841] logging of exception stack traces enabled
[2014-02-19 17:28:39.841] ........
[2014-02-19 17:28:40.383] DEBUG: Database cache size set to 237568 kB
[2014-02-19 17:28:40.807] Database is at level 15
[2014-02-19 17:28:40.809] Updated database is at level 15
[2014-02-19 17:28:40.819] Scanning blockchain...
[2014-02-19 17:28:42.007] DEBUG: block 0
[2014-02-19 17:28:42.922] DEBUG: block 5000
[2014-02-19 17:28:43.678] DEBUG: block 10000
[2014-02-19 17:28:44.097] DEBUG: block 15000
[2014-02-19 17:28:44.593] DEBUG: block 20000
[2014-02-19 17:28:48.421] DEBUG: block 25000
[2014-02-19 17:28:49.910] DEBUG: block 30000
[2014-02-19 17:28:51.258] DEBUG: block 35000
[2014-02-19 17:28:52.525] DEBUG: block 40000
[2014-02-19 17:28:53.694] DEBUG: block 45000
[2014-02-19 17:28:54.623] DEBUG: block 50000
[2014-02-19 17:28:55.214] DEBUG: block 55000
[2014-02-19 17:28:55.701] DEBUG: block 60000
[2014-02-19 17:28:56.142] DEBUG: block 65000
[2014-02-19 17:28:56.637] DEBUG: block 70000
[2014-02-19 17:28:56.681] ...Done
[2014-02-19 17:28:56.684] NRS 0.7.6 started successfully.
[2014-02-19 17:33:54.964] DEBUG: Block 1751335814936283531 not accepted: Previous block id doesn't match
[2014-02-19 17:42:28.250] DEBUG: Block 2649705403541714306 not accepted: Invalid timestamp: 7548170 current time is 7548148, previous block timestamp is 7548143
[2014-02-19 17:42:28.316] DEBUG: Block 2649705403541714306 not accepted: Invalid timestamp: 7548170 current time is 7548148, previous block timestamp is 7548143
[2014-02-19 17:42:31.923] DEBUG: Failed to accept block 2649705403541714306 at height 70360 received from node7.nxtbase.com, blacklisting
[2014-02-19 17:42:31.971] DEBUG: Block 2649705403541714306 not accepted: Invalid timestamp: 7548170 current time is 7548152, previous block timestamp is 7548143
[2014-02-19 17:54:44.978] DEBUG: Block 4249081491518140600 not accepted: Invalid timestamp: 7548903 current time is 7548885, previous block timestamp is 7548886
[2014-02-19 17:54:46.579] DEBUG: Block 4249081491518140600 not accepted: Invalid timestamp: 7548903 current time is 7548887, previous block timestamp is 7548886
[2014-02-19 17:54:47.024] DEBUG: Failed to accept block 4249081491518140600 at height 70362 received from node31.nxtbase.com, blacklisting
[2014-02-19 17:54:47.429] DEBUG: Block 4249081491518140600 not accepted: Invalid timestamp: 7548903 current time is 7548887, previous block timestamp is 7548886
[2014-02-19 17:55:15.470] DEBUG: Block 12932083039183251200 not accepted: Invalid timestamp: 7548933 current time is 7548915, previous block timestamp is 7548903
[2014-02-19 17:55:17.047] DEBUG: Block 12932083039183251200 not accepted: Invalid timestamp: 7548933 current time is 7548917, previous block timestamp is 7548903
[2014-02-19 17:55:17.068] DEBUG: Block 12932083039183251200 not accepted: Invalid timestamp: 7548933 current time is 7548917, previous block timestamp is 7548903
[2014-02-19 17:56:45.342] DEBUG: Block 4693893235962204857 not accepted: Invalid timestamp: 7549023 current time is 7549005, previous block timestamp is 7548933
[2014-02-19 17:56:46.907] DEBUG: Block 4693893235962204857 not accepted: Invalid timestamp: 7549023 current time is 7549007, previous block timestamp is 7548933
[2014-02-19 17:56:47.267] DEBUG: Block 4693893235962204857 not accepted: Invalid timestamp: 7549023 current time is 7549007, previous block timestamp is 7548933
[2014-02-19 18:25:35.111] DEBUG: Accepted new transaction 8092174745016833957
[2014-02-19 18:25:41.411] DEBUG: Block 150191789548926373 not accepted: Previous block id doesn't match
[2014-02-19 18:26:43.888] DEBUG: Block 648900156109476541 not accepted: Invalid timestamp: 7550822 current time is 7550804, previous block timestamp is 7550798
[2014-02-19 18:26:45.123] DEBUG: Block 648900156109476541 not accepted: Invalid timestamp: 7550822 current time is 7550805, previous block timestamp is 7550798
[2014-02-19 18:26:45.572] DEBUG: Block 648900156109476541 not accepted: Invalid timestamp: 7550822 current time is 7550806, previous block timestamp is 7550798
[2014-02-19 18:26:45.932] DEBUG: Block 648900156109476541 not accepted: Invalid timestamp: 7550822 current time is 7550806, previous block timestamp is 7550798
[2014-02-19 18:26:46.429] DEBUG: Block 648900156109476541 not accepted: Invalid timestamp: 7550822 current time is 7550806, previous block timestamp is 7550798
[2014-02-19 18:29:00.424] DEBUG: Block 2904091861119649370 not accepted: Invalid timestamp: 7550958 current time is 7550940, previous block timestamp is 7550873
[2014-02-19 18:39:20.581] DEBUG: Block 1067698495449495846 not accepted: Invalid timestamp: 7551582 current time is 7551561, previous block timestamp is 7551100
[2014-02-19 18:39:21.591] DEBUG: Failed to accept block 1067698495449495846 at height 70375 received from node7.nxtbase.com, blacklisting
[2014-02-19 18:39:22.829] DEBUG: Block 1067698495449495846 not accepted: Invalid timestamp: 7551582 current time is 7551563, previous block timestamp is 7551100
[2014-02-19 18:39:24.183] DEBUG: Block 1067698495449495846 not accepted: Invalid timestamp: 7551582 current time is 7551564, previous block timestamp is 7551100
[2014-02-19 18:39:26.460] DEBUG: Block 1067698495449495846 not accepted: Invalid timestamp: 7551582 current time is 7551566, previous block timestamp is 7551100
[2014-02-19 18:39:26.769] DEBUG: Block 1067698495449495846 not accepted: Previous block id doesn't match
[2014-02-19 18:40:04.993] DEBUG: Block 11219600682173441320 not accepted: Invalid timestamp: 7551623 current time is 7551605, previous block timestamp is 7551582
[2014-02-19 18:40:06.748] DEBUG: Block 11219600682173441320 not accepted: Invalid timestamp: 7551623 current time is 7551607, previous block timestamp is 7551582
[2014-02-19 18:50:28.161] DEBUG: Block 3535557087145314573 not accepted: Invalid timestamp: 7552246 current time is 7552228, previous block timestamp is 7552157

[ChuckOne]

When a block is popped off, if it happened to contain a (necessarily valid) alias assignment transaction, this requires a blockchain scan. The block pop-off has nothing to do with the alias transaction in it, and cannot be forced by an invalid transaction.

Okay, I see. This was not what I meant. I meant, could it be possible to force popping off blocks containing alias transactions and therefore causing a rescan over and over again?

[gvans]

Say whaaat!

nxt monolith prototype is here 





More pics https://www.dropbox.com/sh/dgtssbde40wx4dt/x59vAKeILe

This was actually quite a bit of work. I had to polish the outer edges by hand with several grades of wet sandpaper and do the final touch with polishing paste. I also carved the outer edges of the logo to smooth the edges. 20mm acrylic seems to be a tough material even for a high power laser-cutter so it has to be finalised by hand. Which actually gives it more value imo, handmade in Finland

So this is very first prototype and it came out rather nice. I would be very willing to post this prototype anywhere for the guys/ladies taking part to bitcoin-conferences and other pr-events. So if there is a spare nxt in marketing funds I'm up for it.

See the original monolith post, more monoliths to come.
https://bitcointalk.org/index.php?topic=345619.msg5067143#msg5067143

Holy crap! That is cool. So awesome that it should be made illegal.

Any idea how much a Genesis or DarkNXT 'lith will cost?

I am SO tempted!
 

I have set the price 5000 nxt in this thread
https://forums.nxtcrypto.org/viewtopic.php?f=10&t=772

Was thinking if I should lower my ask but today when I finally finished polishing the prototype I really feel I have to keep the price around where it is now I'm waiting for a few more orders still before I can put the series in manufacture for genesis and darknxt.

Again this prototype is available for marketing and promotional purposes.

[ChuckOne]

Maybe I should just disable debug logging by default, it only makes people think something is wrong. The intention was to make it easier to follow what is going on with the block and transaction processing, in the cases where something does go wrong.

Thank you for adding that counter. It's great:

Code:

[2014-02-19 19:08:01.486] Updated database is at level 15
[2014-02-19 19:08:01.648] Scanning blockchain...
[2014-02-19 19:08:21.358] DEBUG: block 0
[2014-02-19 19:08:33.381] DEBUG: block 5000
[2014-02-19 19:08:41.579] DEBUG: block 10000
[2014-02-19 19:08:48.914] DEBUG: block 15000
[2014-02-19 19:08:55.748] DEBUG: block 20000
[2014-02-19 19:10:11.158] DEBUG: block 25000
[2014-02-19 19:11:25.838] DEBUG: block 30000
[2014-02-19 19:12:24.510] DEBUG: block 35000
[2014-02-19 19:13:19.703] DEBUG: block 40000
[2014-02-19 19:13:53.391] DEBUG: block 45000
[2014-02-19 19:14:46.136] DEBUG: block 50000
[2014-02-19 19:15:14.638] DEBUG: block 55000
[2014-02-19 19:15:40.221] DEBUG: block 60000
[2014-02-19 19:16:01.097] DEBUG: block 65000
[2014-02-19 19:16:24.891] DEBUG: block 70000
[2014-02-19 19:16:26.472] ...Done
[2014-02-19 19:16:26.550] NRS 0.7.6 started successfully.

[ChuckOne]

Maybe I should just disable debug logging by default, it only makes people think something is wrong. The intention was to make it easier to follow what is going on with the block and transaction processing, in the cases where something does go wrong.

These questions will disappear after they have familiarized themselves with nxt-core. It's a process. It takes time.

[Jean-Luc]

Okay, I see. This was not what I meant. I meant, could it be possible to force popping off blocks containing alias transactions and therefore causing a rescan over and over again?

No, to force a block pop-off you need to have a better block / longer chain, etc. This cannot be faked, and if a peer lies about its cumulative difficulty and causes a rescan because of that, it gets blacklisted, for 5 min by default. And when one day we keep more stuff in database instead of in memory, the need for rescans will also be reduced.

[ChuckOne]

Maybe I should just disable debug logging by default, it only makes people think something is wrong. The intention was to make it easier to follow what is going on with the block and transaction processing, in the cases where something does go wrong.

These questions will disappear after they have familiarized themselves with nxt-core. It's a process. It takes time.

Another issue:

many folks have the fear that they are on a branch/fork.

If you could find a way to demonstrate otherwise in the nxt.log. That would be great. Something like that:

Code:

[date] INFO: ....
[date] INFO: ....
[date] INFO: Fork probability: 0.01%
[date] INFO: ....
[date] INFO: ....
[date] INFO: Fork probability: 0.1%
[date] INFO: ....
[date] INFO: Fork probability: 14.2% WARNING
[date] INFO: ....
[date] INFO: ....

But, I fear that would greatly increase overhead at least for Raspis.

[ChuckOne]

Maybe I should just disable debug logging by default, it only makes people think something is wrong. The intention was to make it easier to follow what is going on with the block and transaction processing, in the cases where something does go wrong.

Thank you for adding that counter. It's great:

Code:

[2014-02-19 19:08:01.486] Updated database is at level 15
[2014-02-19 19:08:01.648] Scanning blockchain...
[2014-02-19 19:08:21.358] DEBUG: block 0
[2014-02-19 19:08:33.381] DEBUG: block 5000
[2014-02-19 19:08:41.579] DEBUG: block 10000
[2014-02-19 19:08:48.914] DEBUG: block 15000
[2014-02-19 19:08:55.748] DEBUG: block 20000
[2014-02-19 19:10:11.158] DEBUG: block 25000
[2014-02-19 19:11:25.838] DEBUG: block 30000
[2014-02-19 19:12:24.510] DEBUG: block 35000
[2014-02-19 19:13:19.703] DEBUG: block 40000
[2014-02-19 19:13:53.391] DEBUG: block 45000
[2014-02-19 19:14:46.136] DEBUG: block 50000
[2014-02-19 19:15:14.638] DEBUG: block 55000
[2014-02-19 19:15:40.221] DEBUG: block 60000
[2014-02-19 19:16:01.097] DEBUG: block 65000
[2014-02-19 19:16:24.891] DEBUG: block 70000
[2014-02-19 19:16:26.472] ...Done
[2014-02-19 19:16:26.550] NRS 0.7.6 started successfully.

Just nitpicking:

Could you unify the log output?
INFO: for 'NRS 0.7.6 started successfully.' etc.?

Is there a difference between DEBUG and INFO currently?

[ChuckOne]

Okay, I see. This was not what I meant. I meant, could it be possible to force popping off blocks containing alias transactions and therefore causing a rescan over and over again?

No, to force a block pop-off you need to have a better block / longer chain, etc. This cannot be faked, and if a peer lies about its cumulative difficulty and causes a rescan because of that, it gets blacklisted, for 5 min by default. And when one day we keep more stuff in database instead of in memory, the need for rescans will also be reduced.

So, theoretically, if I would buy thousands of nodes, I could keep everybody busy by rescanning the blockchain?

[msin]

If someone has an invite code for Bittrex.com, please PM me.

P.S.: Got a tweet from Mintpal

Here is the Bittrex email if people want to send them an "Please Add Nxt" email; support@bittrex.com

[ebereon]

I have tested my raspi with a bruteforce script witch is checking account balances.

The raspi was able to answere ~400 requests per secound (web.xml ddos entry 30000). I don't know if this is an indicator of the resources of a raspi to get 1000tps done. The java process was consuming 95% CPU and the connection was 100Mbit.
Powerconsumption was ~3,5Watt (model B)

For comparison my i5 windows pc was able to answere 15000 requests per secound with 1Gbit connection.

Greets,
eb

PS.: Do we have a script or something to test tps? Would be nice to have to decide what hardware we need for the nodes someday.

[TwinWinNerD]

If someone has an invite code for Bittrex.com, please PM me.

P.S.: Got a tweet from Mintpal

Here is the Bittrex email if people want to send them an "Please Add Nxt" email; support@bittrex.com

i think they already decided to add NXT:
http://www.reddit.com/r/CryptoCurrency/comments/1ycym4/bittrex_supports_17_markets_today_are_there_any/cfjjvty

[msin]

If someone has an invite code for Bittrex.com, please PM me.

P.S.: Got a tweet from Mintpal

Here is the Bittrex email if people want to send them an "Please Add Nxt" email; support@bittrex.com

i think they already decided to add NXT:
http://www.reddit.com/r/CryptoCurrency/comments/1ycym4/bittrex_supports_17_markets_today_are_there_any/cfjjvty

Still worth emailing them, showing our continued support never hurts.