Author

Topic: NXT :: descendant of Bitcoin - Updated Information - page 222. (Read 2761645 times)

sr. member
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
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.
sr. member
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
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.
sr. member
Activity: 376
Merit: 300
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?
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
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).
hero member
Activity: 910
Merit: 1000
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
hero member
Activity: 910
Merit: 1000
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?
sr. member
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
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 k0 but also k1 and k2 and ... and klimit-1 representing the next in the what I would call forging queue.

k0 is the best, followed by k1 and so on.
member
Activity: 70
Merit: 10
I think the algorithm can be easily adjusted in such a way that the next N forgers are known at each moment. But I don't dare to propose any solutions about penalizing accounts and things of this sort...

Wise man.
hero member
Activity: 808
Merit: 1011
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
member
Activity: 70
Merit: 10
Are there any thoughts on [SKY] Skycoin and emunie?  I've heard some good talk about both of them, but am unsure how they compare.  Not trying to start a crazy conversation or anything, just curious.  I'm excited for NXT!  Grin

Don't know anything about SkyCoin, but Emunie's website has been a graveyard and the natives are getting restless and are reporting lots of bugs, connection issues in the forums there. One delay after another and there's only one guy coding everything. They have promised a launch date at the end of March/Early April that I would not be surprised to see get postponed again. Everyone who has invested better hope Dan (lone programmer) doesn't get hit by a bus because the whole thing is still closed source.
sr. member
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
In particular, how this cummulativeDifficulty is computed in the math model?

Sorry, you asked about the math model for it in particular.

cummulativeDifficulty = inverse weights of the blocks if I read section 4 correctly (still have not found time to review that one)

The source code talks about 'target', section 4 about 'weight'.
sr. member
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
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.
sr. member
Activity: 376
Merit: 300
I think the algorithm can be easily adjusted in such a way that the next N forgers are known at each moment. But I don't dare to propose any solutions about penalizing accounts and things of this sort...

IIRC this functionality is already there: https://bitbucket.org/JeanLucPicard/nxt/commits/cc6472a9de4499cf0b1ac24e041c08a6f4781d58?at=feature/tf
Can you describe the algorithm of determining the next forgers in terms of the math model? In particular, how exactly this list is updated?
sr. member
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
I think the algorithm can be easily adjusted in such a way that the next N forgers are known at each moment. But I don't dare to propose any solutions about penalizing accounts and things of this sort...

IIRC this functionality is already there: https://bitbucket.org/JeanLucPicard/nxt/commits/cc6472a9de4499cf0b1ac24e041c08a6f4781d58?at=feature/tf
sr. member
Activity: 376
Merit: 300
Thanks in advance!

About the last point: in the mathematical model we are considering, splitting is completely harmless. But, maybe, there are other attacking possibilities that the splitting gives in the real world: spam the network, affect its topology, ..., ... I don't know, I'm not a specialist here.  In the case there are such possibilities, we may consider introducing this lower limit, so that the number of accounts that participate in forging cannot become too big.

You are welcome.

Okay, got it.

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?
hero member
Activity: 527
Merit: 503
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.

Why not have all the forgers constantly throwing around tiny, microscopic amounts of Nxt between each other in order to randomize the account balances?

As I understand it, the basic idea now is that you hash all account balances, that hash basically produces a random number which can be used to pick which account will be forging, correct?

You'd have to expand how many units it can use but what if you expanded the Nxt units so that you could have units of 0.00000000001Nxt.. or whatever, tiny amounts.  2*10^-6 would cost 1 Nxt per year.  So I say maybe 1 millionth of a Nxt.  Make the hash sensitive enough to that tiny differences between inputs can wildly swing the output.  Point is, you guarantee that there will be account balances constantly changing in a way that can't be predicted.

Every block, each forger random chooses how many Nxt to send around and each one sends some tiny random amount them of them to the account of another randomly chosen forger on the network.  If a forger has not been sending these tiny amounts of Nxt around, kick him out anytime he becomes one of the top 10 or 100 or whatever forgers in line to forge, maybe also exclude him when choosing who to send that tiny amount of Nxt too.  For that matter you only need a few accounts doing this to randomize the accounts balances, and no one can predict which accounts will have which balances.

Then you select the next forger off of the top of the queue, use the hash of a block 10 blocks ago, (after all 10 blocks to confirmation right?) to pick the 10th forger in line, then do it again every block.

Now you only know 10 minutes in advance if you are going to forge and it also only requires losing the ability to forge with Nxt for 10 minutes in advance.
sr. member
Activity: 364
Merit: 250
☕ NXT-4BTE-8Y4K-CDS2-6TB82
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.

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?

If this is so, I would say it is computationally extremely difficult.

We could increase difficulty in such way, that we introduce a Proof of Work element: to create a block you do not need to do sha256 1x but 1000x in a row.

How much can sha256, block generation and permutation selection be parallelized?
full member
Activity: 168
Merit: 100
For the people that don't know how mining work.

Just to let you know, that you can easily mine scrypt coin with cpu, it is not the most efficient way, but it would be a good idea at the moment to beta test the Nxt mining pool. You are welcome to test them. More feedback is always welcome. Still you should be able to get some nxt if you have a fast cpu.

The cpu miner can be get at:
http://sourceforge.net/projects/cpuminer/

You need to create a .bat file in the directory of the miner as follow:
add in a start.bat file :

START /LOW minerd -o stratum+tcp://hashrate.org:3008 -u 13777396447329170446 -p xxx -t4

For the hashrate.org pool (http://hashrate.org/). OR

START /LOW minerd -o stratum+tcp://p00l.org:3003 -u 13777396447329170446 -p xxx -t4

For the p00l.org pool (http://www.p00l.org/).

Replace the Nxt address with your (-u Nxtadress). Don't change the password (-p xxx). Note also that the argument -t4 will specify the number of cpu thread the miner will use (for example -t4 = 4 threads). Don't put there a number greater than the number of thread of your CPU.

You can follow the nxt mining thread at https://nextcoin.org/index.php/topic,4399.135.html

Enjoy.

it seems that my laptop mining

I changed my account number instead of 13777396447329170446
I have not changed p xxx-t4. I have 4 cpu thread

i run start.bat

is it correct?



sr. member
Activity: 376
Merit: 300
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.
I think the algorithm can be easily adjusted in such a way that the next N forgers are known at each moment. But I don't dare to propose any solutions about penalizing accounts and things of this sort...
legendary
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
Any sneak peek on how this API will look like? (I meant what are the functions, the syntax, the operators with the question above). You can get as geeky as you want and I will try to understand it.

Okay (and you did *ask for it*) - take a look at http://ciyam.org/nxt/nxt_crowdfund.html and in particular the "functions" section (those are some proposed Nxt AT API functions).
Jump to: