NXT :: descendant of Bitcoin - Updated Information

[ChuckOne]

Can you describe the algorithm of determining the next forgers in terms of the math model? In particular, how exactly this list is updated?

If I read the source correctly, that function will return a sorted list of limit accounts that are able to forge the next block.

In math model:

it is like having not only k₀ but also k₁ and k₂ and ... and k_limit-1 representing the next in the what I would call forging queue.

k₀ is the best, followed by k₁ and so on.

[1714107443]

1714107443

[1714107443]

1714107443

[1714107443]

1714107443

[bitcoinpaul]

But maybe since then it became more clear?..

Do u have any ideas how it's better to implement Transparent Forging? The goal is to find an optimum where we can predict few blocks in advance but noone could game the system by preparing such accounts that he would be able to forge a lot of blocks in the row.

there is 1 really solid solution that you arnt going to want to hear

And that was what again?

[bitcoinpaul]

Nxt Blockchain Explorer is not showing transactions. Does someone know why?
The total balance is correct, but the last three incoming transactions are not showen in the list. http://87.230.14.1/nxt/nxt.cgi?action=3000&acc=14467166339972892265

Often faulty, our old 87.230.14.1

[CIYAM]

If I read the source correctly, that function will return a sorted list of limit accounts that are able to forge the next block.

I think that the idea for TF (maybe not as so far currently has been implemented) is that at least 2 or 3 accounts should have "the same value" (so there isn't a *best* one).

The purpose of that idea is to *inject randomness* that might otherwise mean you could predict too many blocks ahead (it of course results in more forks with latency and network topology being the final "deciding" factors).

[mthcl]

But still, an attacker could create raw transactions at will to create new accounts that might lead to a block that he has the highest cummulativeDifficulty of. He could include these txs into blocks that favor him most. So, it will be self-inducing.

Can you explain the last sentence to me, having in mind that I wrote my last program 20 years ago?  In particular, how this cummulativeDifficulty is computed in the math model?

Sure.

raw = to-be-verified aka to-be-agreed-on

The problem with raw transactions are: they are the things we need to find consensus about. That is why we need blocks. Blocks represent the consensus on which transactions occured.

But: since we have not found any consensus about these raw transactions they can be added or removed at will. Why? Because we have not agree on them yet, because there is no block verifying them. I hope that is clear.

So, an attacker could add raw transactions into his pool of available raw transactions and therefore increase his probability of bundling them into a block that one of his accounts can forge.

A new forging account F is created by at least two transactions (3 NXT need in total):
1) funding (2 NXT to F)
2) public key creation (1 NXT form F to somewhere else)
=> F still holds 1 NXT and is able to forge in 1440 block from 2)

Because of that, an attacker could carefully design transactions that create accounts that will forge in the future.

So, this attacker could design raw transactions and shuffling existing ones and his artificial ones until he can a row of blocks that is long enough for his purpose.

But I still don't understand, what advantage the attacker obtains by creating these smaller accounts? Why not just sit on his big account and wait?

[ChuckOne]

But I still don't understand, what advantage the attacker obtains by creating these smaller accounts? Why not just sit on his big account and wait?

Creating blocks in a row is the major threat, if I understand it correctly.

[ChuckOne]

If I read the source correctly, that function will return a sorted list of limit accounts that are able to forge the next block.

I think that the idea for TF (maybe not as so far currently has been implemented) is that at least 2 or 3 accounts should have "the same value" (so there isn't a *best* one).

The purpose of that idea is to *inject randomness* that might otherwise mean you could predict too many blocks ahead (it of course results in more forks with latency and network topology being the final "deciding" factors).

Yes, I know.
Nevertheless, you could use the implemented function for both scenarios.

[L5Society]

Nxt Blockchain Explorer is not showing transactions. Does someone know why?
The total balance is correct, but the last three incoming transactions are not showen in the list. http://87.230.14.1/nxt/nxt.cgi?action=3000&acc=14467166339972892265

use this instead http://www.mynxt.info/blockexplorer/

[Come-from-Beyond]

So, that attack would go this way:

1) attacker creates N accounts

2) attacker receives M raw transactions

3) attacker tries to find a row of blocks by:

 3.0) do until no raw transactions are available
 3.1) choose X raw transactions
 3.2) is the account forging this block one of the N accounts?
 3.3) if yes, go to 3.1) and remove X transactions
 3.4) if no, go to 3.1) and choose another selection of raw transactions

4) if no combination will lead to the desired output => attacker creates his own raw transactions, go back to 3)

5) choose longest row and submit it to the network

Is that the attack vector you have in mind?

Something like that. Different variations r possible.

[mthcl]

Can you describe the algorithm of determining the next forgers in terms of the math model? In particular, how exactly this list is updated?

If I read the source correctly, that function will return a sorted list of limit accounts that are able to forge the next block.

In math model:

it is like having not only k₀ but also k₁ and k₂ and ... and k_limit-1 representing the next in the what I would call forging queue.

k₀ is the best, followed by k₁ and so on.

But at the next moment (when the next block is forged) you decide on only one new entry to the queue? Or you wait until the queue is empty and decide on the whole queue then again?

[CIYAM]

Yes, I know.
Nevertheless, you could use the implemented function for both scenarios.

But I think whether we treat that list as "ordered" or not *could* make a difference (so that needs to be considered).

This ends up being important to the "lottery" AT (and others that might follow it) as we need to be confident of the "randomness" of "tickets".

[2gen]

suddenly much buying power wazup?

why is nxt going up so much on bter, is there something comming up, NEWS?

NXT will break 0.7 soon.?? Huge lift of

[Come-from-Beyond]

there is 1 really solid solution that you arnt going to want to hear

What is it?

[ChuckOne]

Can you describe the algorithm of determining the next forgers in terms of the math model? In particular, how exactly this list is updated?

If I read the source correctly, that function will return a sorted list of limit accounts that are able to forge the next block.

In math model:

it is like having not only k₀ but also k₁ and k₂ and ... and k_limit-1 representing the next in the what I would call forging queue.

k₀ is the best, followed by k₁ and so on.

But at the next moment (when the next block is forged) you decide on only one new entry to the queue? Or you wait until the queue is empty and decide on the whole queue then again?

That is yet to be decided.

EDIT:
possibilities if could come up with:

1) each block has its own forging queue
2) the network draws from the queue until it is depleted and creates a new one
3) the network considers all accounts of the queue as equally good

EDIT 2:
Why do we it at all?
Because not every account will forge, so we need a buffer I a forger is absent.

[mthcl]

But I still don't understand, what advantage the attacker obtains by creating these smaller accounts? Why not just sit on his big account and wait?

Creating blocks in a row is the major threat, if I understand it correctly.

Then there is no point in creating new accounts.

[punkrock]

Nxt Blockchain Explorer is not showing transactions. Does someone know why?
The total balance is correct, but the last three incoming transactions are not showen in the list. http://87.230.14.1/nxt/nxt.cgi?action=3000&acc=14467166339972892265

use this instead http://www.mynxt.info/blockexplorer/

Thanks!

[CIYAM]

Then there is no point in creating new accounts.

Yes - that was my understanding from my own modelling.

Still the issue of "randomness" is a key point that I would like to have checked (i.e. how "random" is the block # 1440 blocks in the future).

[ChuckOne]

But I still don't understand, what advantage the attacker obtains by creating these smaller accounts? Why not just sit on his big account and wait?

Creating blocks in a row is the major threat, if I understand it correctly.

Then there is no point in creating new accounts.

Creating blocks in a row that YOU as an attacker control.

[CIYAM]

Creating blocks in a row that YOU as an attacker controls.

Yes - this is basically what I modeled in code and mthcl in math (not considering the proposed TF but just the existing approach).

Of course any *model* is just that (so it may not be "good enough" to reflect the *reality*).

[mthcl]

Can you describe the algorithm of determining the next forgers in terms of the math model? In particular, how exactly this list is updated?

If I read the source correctly, that function will return a sorted list of limit accounts that are able to forge the next block.

In math model:

it is like having not only k₀ but also k₁ and k₂ and ... and k_limit-1 representing the next in the what I would call forging queue.

k₀ is the best, followed by k₁ and so on.

But at the next moment (when the next block is forged) you decide on only one new entry to the queue? Or you wait until the queue is empty and decide on the whole queue then again?

That is yet to be decided.

EDIT:
possibilities if could come up with:

1) each block has its own forging queue
2) the network draws from the queue until it is depleted and creates a new one
3) the network considers all accounts of the queue as equally good

Then, if we decide on all queue at once, the algorithm should be changed, because this way you'll not obtain the "correct" forging probabilities (all k_i's are different, right?). Think of a situation when there is an account with 50% of all NXT, and limit=100.  Normally this account would forge every second block, but under this approach, it will only forge every 100th.