NXT :: descendant of Bitcoin - Updated Information

[ChuckOne]

Do I understand correctly that there is concern about the fact that the "randomness" is actually pseudorandomness (i.e., it is deterministic, but not predictable)?

Yes. It is determistic and can be pre-computed till the end of the universe.

In this case, we can just put some "true randomness from the real world" in: take some parameter which is rapidly changing in time and is not controlled by one person or entity, and use it as an additional randomizer. For instance, total amount of all transactions (and/or fees) in the previous block could act as this randomizer.

Yes. As could network topology.

[dhit]

Do I understand correctly that there is concern about the fact that the "randomness" is actually pseudorandomness (i.e., it is deterministic, but not predictable)?

In this case, we can just put some "true randomness from the real world" in: take some parameter which is rapidly changing in time and is not controlled by one person or entity, and use it as an additional randomizer. For instance, total amount of all transactions (and/or fees) in the previous block could act as this randomizer.

I was wondering if in some cases the participants couldn't include a number that would be one of the factors contributing to the "randomness".  I've wondered about a decentralized heads up poker table, and if it could take some stats in the blockchain, combined with a number that each player may include before "shuffling".  I don't know if it would be necessary, but if each player could throw a factor in, I assume that could only help faith in it.


On a separate note, I am currently listening to the latest Sex & Science Hour on LTB!, and they mentioned how it seems there is nothing that can't be done on Nxt!  Just wanted to thank all you magicians hard at work here.  Your efforts are appreciated!

[NxtMinnow]

Hi mikesbmw, that is too bad Cryptsy is not promptly managing NXT deposits.  I have been emailing them for weeks (multiple attempts) to have them display correct NXT information at https://www.cryptsy.com/currencies/view/118 with no success. Maybe someone else here would like to follow up with Cryptsy regarding listed NXT information.

EDIT: Cryptsy changed most of the information, but still lists NXT as closed source on the third bullet point, referencing January 2014.

Hmmm, Cryptsy is at it again...

Deposited 7500 NXT, 22 hours ago and it is still not added to my balance.
It arrived, minutes after sending, at the correct address. After some e-mails back and forth this was their final response:

------
Thank you for providing the information needed.

NXT deposits and withdraws are delayed. NXT is a new coin that we have introduced. There will be some delays as our technical team along with the developers of this coin are working hard to make this new coin run smoothly. Please bear with us as we work to improve your trading experience.

Thank you for your patience and understanding.
------

 

[ChuckOne]

[...]

So, if there will every be a row of 1440 blocks, it is over.

Regarding the probability for that scenario:

P_n = 0.5^(1443)*0.5*n

n=number of blocks


Problem: my calculator says 0

0.5^14 ~ 0.000061
0.5^144 ~ 4.5^-44
0.5^-1440 ~ http://www.wolframalpha.com/input/?i=0.5%5E1440

[rero2]

This thread has so much information, I'm going to try and catch up to it all

[ChuckOne]

This thread has so much information, I'm going to try and catch up to it all

Good luck, my dear.

[L5Society]

we are trying to make 10 or so blocks reliably predictable and 1440 blocks reliably unpredictable at the same time.

So wouldn't a POW block break this? Say POW block is in 3 blocks, but we want the 10th block to be predictable?

[ChuckOne]

[...]

So, if there will every be a row of 1440 blocks, it is over.

Regarding the probability for that scenario:

P_n = 0.5^(1443)*0.5*n

n=number of blocks


Problem: my calculator says 0

0.5^14 ~ 0.000061
0.5^144 ~ 4.5^-44
0.5^1440 ~ http://www.wolframalpha.com/input/?i=0.5%5E1440

Maybe, somebody has a better attack scenario as this one is, well, almost impossible.

JFR: for our 90% attack freaks: http://www.wolframalpha.com/input/?i=0.9%5E1440

[ChuckOne]

Do I understand correctly that there is concern about the fact that the "randomness" is actually pseudorandomness (i.e., it is deterministic, but not predictable)?

In this case, we can just put some "true randomness from the real world" in: take some parameter which is rapidly changing in time and is not controlled by one person or entity, and use it as an additional randomizer. For instance, total amount of all transactions (and/or fees) in the previous block could act as this randomizer.

Btw. we already have such randomness in our system: the account balances.

[mczarnek]

Do I understand correctly that there is concern about the fact that the "randomness" is actually pseudorandomness (i.e., it is deterministic, but not predictable)?

In this case, we can just put some "true randomness from the real world" in: take some parameter which is rapidly changing in time and is not controlled by one person or entity, and use it as an additional randomizer. For instance, total amount of all transactions (and/or fees) in the previous block could act as this randomizer.

We can't coz an entity with a lot of computing power will be able to game the system.

K might see the issue.

How about this?

Normally when forging, you can't create false transactions, you can only hold back transactions so they don't get included or add your own transactions.  Every block is forged by 3 separate forgers, this ensures that they can't cheat by holding back transactions, since as long as at least one of them broadcasts every transaction, then the block-chain is intact.

Or use this idea of including the number of transactions/fees in order to randomize it.  But it's not the number of transactions/fees in the current block, it's the number of transactions in a future block which cannot be determined and/or manipulated in the current block.

Or something along the lines of what I was suggesting where everyone sends tiny little transactions to another random person, except are special transactions that don't get included in the current block, they get included in the previous block and every account can only generate on such tiny fee, either they send it or they don't and they pick an address to send it to.  Also, this is not broadcast to the network until the next block so unless you forge two blocks in a row, you have absolutely no way of knowing what is about to happen, this could be extended to 2 or 3 blocks in the future. So you have to forge multiple blocks in a row in order to learn all the information early enough to manipulate it.  In fact you could purposely send these tiny little transaction fees to only 2 out of the 3 computers forging, and at the end of the block, they are shared by all.. or maybe only after all blocks that have forged that can affect this hash (so say 10 minutes), you share the information about these tiny special transactions to the rest of the network.

[Anon136]

we are trying to make 10 or so blocks reliably predictable and 1440 blocks reliably unpredictable at the same time.

So wouldn't a POW block break this? Say POW block is in 3 blocks, but we want the 10th block to be predictable?

i explained how that could be addressed a few posts back.

[brooklynbtc]

Hey guys, http://hashrate.org has had a bit of a facelift.
Yesterday we paid out 0.008 BTC/MH/day equivilent in NXT - why mine anywhere else?

 Just last week I was planning on getting rid of my noisy, power wasting milk crate, especially with warm weather coming soon.

 Now I'm having too much fun mining! (or no more fun than before but it is exciting again going right into my wallet)

[L5Society]

not necessarily. first you decide how many blocks into the future it is ideal for people to be able to predict. lets say 10 as an offhand example. once someone submits a valid pow block you could record it then but not have it effect the process of deduction until 10 blocks after its submission. so for example say it was submitted as block 100,000. you could make it so that that hashing this block isnt part of the generation sigature perramiter until block 100,010.

Dang, that is pretty slick.

[ChuckOne]

As my attack vector above makes no sense due to false assumptions I made, let me correct it:

1) pre-calculates generationSignatures until he founds that he has control over then next 1442 blocks, let's say that might be at block X

(he now tries to lengthen his row bit by bit by simulating the following steps)

2) he funds an account by transferring (a+1) NXT to it at block X+1
3) he creates the account's key by sending 1 NXT back to him at block X+2

(that account can now forge with balance of a NXT at block X+1443)

4) he calculates the hit for that very block X+1443 and determines how much a is needed to be the best forger
 4.1) if the hit is too big, he chooses a different account and start again at 2)
 4.2) if the hit is appropriately low, he really performs 2) and 3)

5) go back to 2) and create forging account for block X+1444

This way, the attacker can lengthen his row bit by bit.

So, if there will every be a row of 1440 blocks, it is over.

After thinking it further, even that attack might not work out.

Why?

Because the attacker cannot predict if he really is the one forging. As line 153 shows: https://bitbucket.org/JeanLucPicard/nxt/src/794f1393136c2482fa7bb48877fdbdc392336a7a/src/java/nxt/Generator.java?at=feature/tf#cl-153
The attacker would need to know the secret_phrases of all other accounts to predict his forging streak reliably.

So, best security measure against this type of attack would be: do not reveal your forging time until you really forge a block.

If you reveal your time, attackers will know if they are better or worse and can act accordingly.

[Sebastien256]

A part of NXT Block Explorer is not working correctly. I keep getting NXT, but I can't see the transactions. Compare these:

http://www.mynxt.info/blockexplorer/details.php?action=ac&ac=7582598942095085392 (good)

http://87.230.14.1/nxt/nxt.cgi?action=3000&acc=7582598942095085392 (not so good)

More people with this problem?

I do have this problem.

[CryptKeeper]

Well, I am lucky that my brain is quantum compatible.

What about yours?

After I started working on Nxt my IQ went from 68 to 83. I hope this will be enough.

I assume those numbers are hexadecimals... 

[Come-from-Beyond]

Well, I am lucky that my brain is quantum compatible.

What about yours?

After I started working on Nxt my IQ went from 68 to 83. I hope this will be enough.

I assume those numbers are hexadecimals... 

 

[ChuckOne]

A part of NXT Block Explorer is not working correctly. I keep getting NXT, but I can't see the transactions. Compare these:

http://www.mynxt.info/blockexplorer/details.php?action=ac&ac=7582598942095085392 (good)

http://87.230.14.1/nxt/nxt.cgi?action=3000&acc=7582598942095085392 (not so good)

More people with this problem?

I do have this problem.

Fork?

[L5Society]

I do have this problem.

Hey Daedelus (or any other wiki contributor),

Can we update the wiki to mention this issue with the old blockchain explorer, and provide the link to the mynxt explorer? Wouldn't want people accidentally resending transactions when they don't see them in the old blockchain explorer.

[joefox]

A part of NXT Block Explorer is not working correctly. I keep getting NXT, but I can't see the transactions. Compare these:

http://www.mynxt.info/blockexplorer/details.php?action=ac&ac=7582598942095085392 (good)

http://87.230.14.1/nxt/nxt.cgi?action=3000&acc=7582598942095085392 (not so good)

More people with this problem?

I do have this problem.

The 87.230... block explorer was built by nexern, who is also working on some RL projects in addition to his own Nxt client.  I doubt he's had time to keep his block explorer up-to-date OR fix errors with it.

I'm going to take I've taken nexern's block explorer off the wiki.