Nxt source code flaw reports

[ImmortAlex]

Including any transaction hash into the signature would be quite messy and opens exploits that leave out or generate additinal transactions to influence the signature in their favor.

Yes, if we simple allow to include payload hash to gen sig, we effectively return PoW to Nxt.

[1714699755]

1714699755

[1714699755]

1714699755

[1714699755]

1714699755

[1714699755]

1714699755

[Come-from-Beyond]

Could someone please confirm whether either of my two solutions work and whether they are already, in fact, implemented in the latest source code?

Ur approach would transform Nxt into a PoW coin.

[Anon136]

Now for the interesting 75% part:
You can calculate in advance, which nonce each of your accounts would have and then choose the best one. So statistically speaking, all your accounts are behaving like accounts with your 0.98% stake in them. And you can freely choose between any of the 100.000 accounts in advance, already knowing the nonce. The chance that one of them has a nonce so good that it's better than all the others is extremely high: If you'd (theoretically speaking) combine all of those 100,000 accounts with 0.98% stake each, you have a stake of 98,000 % (yes, I know, that's more than 100%, but that's the whole point of having the prior knowledge ). So the total stake of the currency for that next block becomes 98,000 % (you) + 99.02 % (others) = 98,099.02 %. Which means, you suddenly own nearly 99.9 % of the stake and have the respective chance of forging that block.

So with that methodology, we have a forging chance of 25%*0.98%+75%*99.9% = 75.17 %.

Good catch. Looks like this trick will work if u r the only one who uses this strategy. Will freezing recently moved coins for 1440 blocks solve the issue?

PS: It's not the injected flaw, but still post ur Nxt account for 10K reward plz.

Wait a minute.... another possibly better solution could be for the generation signature to include a hash of the transactions contained in the block.

1) Suppose you've forged the current block B1 with account a1, but have not broadcast it.
2) Next, you compute corresponding generating signature sig(B1).
3) From this, you calculate the subordinate account a2 (one of your 100 pre-generated accounts) that generates the next block B2.
4) However, the transaction to move your NXT stake from a1 -> a2 (so you are able to solve B2) must to be part of B1.
5) So, you need to update the current block C with transaction a1 -> a2 and re-generate the generating sig(B1).
6) However, you've now changed B1, so you need to goto step (3) and repeat the process.

Thus, we have thwarted the adversary with a chicken-or-egg/halting-problem kind of puzzle.

Does this work as a solution?

Maybe a hash of the transactions is already included in the generation signature, in which case there was no issue in the first place.

Also, https://bitcointalk.org/index.php?topic=397183.msg4307553#msg4307553 seems to indicate that my earlier recollection that there is a 1440 block forging penalty for transferred coins is true.

In essence it works by having the author of the next block be selected by comparing the public key that he is using to hold his stake to the public key of the author of the previous block. In-order to prevent the new block author from simply creating a public key that would win and loading that public key with his stake BTCNext introduced the idea of effective stake. Only stake that has remained stationary for 1440 blocks (24 hours) has the right to author a block. Would be attackers can not calculate 1440 blocks into the future because they have no idea who is going to author the very next block, let alone the next 1440 blocks. Inorder to prevent an attacker from creating a "trap" where if he manages to become lucky enough to author one block in the future than he has prepared a set of funded addresses which would "catch" the subsequent blocks, we don't only rely on the previous block authors signature alone, but build an entirely separate "block chain" which is the result of hashing every public key ever used to author a block.

However, the source code defines getEffectiveBlance() with

...
         if (Block.getLastBlock().height - height < 1440) {

            return 0;

         }
...

which seems to imply the 1440 penalty is on the account, rather than on the NXT balance.

Could someone please confirm whether either of my two solutions work and whether they are already, in fact, implemented in the latest source code?

I'm not entirely sure that i understand exactly what you are proposing, but while you are quoting my work anyway, i think it may be important to point out this particularly important part

You see, you can't just hash the previous block and use the digest as the parameter for selecting the winner of the right to author the next block because, the block authors would contrive transactions in that block that digested into a hash that gave him the the right to author the next block. In-fact you cant base it off of a digest of any part of the block that the author has free reign over or you will run into the same problem.

This would include transactions because the block author has the choice of which transactions to include and which not to include.

[xibeijan]

Ok people... take a break from all the advanced thoughts... and help us coding-challenged people for a sec.!    


Can someone please point to the exact lines in the code where it is established that empty accounts cannot forge?

Is the Genesis account is excluded from forging?  What is the condition set for accounts with negative balance?


Just wondering what happens if someone unlocks the Genesis account... in respect to the code under examination, of course.


thnx  

The genesis account has a negative balance (because it created the currency supply from a zero balance I suppose).  Peers do not allow accounts with negative balances to transmit NXT.  Makes sense to me.

[xibeijan]

Could someone please confirm whether either of my two solutions work and whether they are already, in fact, implemented in the latest source code?

Ur approach would transform Nxt into a PoW coin.

There are two solutions.  The first would not convert it to a PoW coin.

The second, again, would not, but it would do away with transparent forging; a sensible thing to do if it's insecure.  Maybe that's what you mean?

[theKnownUnknown]

I am new to cryptocurrencies, so please excuse my noob question:

What happens if two distinct nodes forge the same block at the same time (assume both are allowed to, though both blocks are valid)?

[Come-from-Beyond]

Could someone please confirm whether either of my two solutions work and whether they are already, in fact, implemented in the latest source code?

Ur approach would transform Nxt into a PoW coin.

There are two solutions.  The first would not convert it to a PoW coin.

The second, again, would not, but it would do away with transparent forging; a sensible thing to do if it's insecure.  Maybe that's what you mean?

Ah, I overlooked that u proposed 2 solutions.

[Come-from-Beyond]

I am new to cryptocurrencies, so please excuse my noob question:

What happens if two distinct nodes forge the same block at the same time (assume both are allowed to, though both blocks are valid)?

They'll create a fork in a chain of predictions, which is a good thing. This is why block timestamps r seconds, not milliseconds.

[theKnownUnknown]

I am new to cryptocurrencies, so please excuse my noob question:

What happens if two distinct nodes forge the same block at the same time (assume both are allowed to, though both blocks are valid)?

They'll create a fork in a chain of predictions, which is a good thing. This is why block timestamps r seconds, not milliseconds.

And who gets the fees?

[xibeijan]

Could someone please confirm whether either of my two solutions work and whether they are already, in fact, implemented in the latest source code?

I'm not entirely sure that i understand exactly what you are proposing, but while you are quoting my work anyway, i think it may be important to point out this particularly important part

I think the answer to your next question will make it clear.

You see, you can't just hash the previous block and use the digest as the parameter for selecting the winner of the right to author the next block because, the block authors would contrive transactions in that block that digested into a hash that gave him the the right to author the next block. In-fact you cant base it off of a digest of any part of the block that the author has free reign over or you will run into the same problem.

This would include transactions because the block author has the choice of which transactions to include and which not to include.

I don't say to base it only on the transactions, but to include the transactions as part of the input.  Including the transactions as part of the gen sig would help prevent the security issue proposed by dicot.

But maybe there's something I don't understand about it, which would not be surprising given there's no formal account or whitepaper.

[Come-from-Beyond]

And who gets the fees?

This will be determined by the next block.

[theKnownUnknown]

And who gets the fees?

This will be determined by the next block.

And how gets the forked chain joined together again?

[Come-from-Beyond]

And who gets the fees?

This will be determined by the next block.

And how gets the forked chain joined together again?

Nodes will see a longer branch and orphane one of the blocks.

[ricot]

And who gets the fees?

This will be determined by the next block.

And how gets the forked chain joined together again?

It doesn't.

One of the two blocks will have a better cumulative difficulty (comparable to a nonce in BTC) and will "win". So the worse block becomes an orphan and every client just builds on the better block.
This process hsould happen quite often because of network latency and such.

[xibeijan]

Peers do not allow accounts with negative balances to transmit NXT.  Makes sense to me.

Yes... but peers can transmit NXT to the Genesis account... thus destroying those NXT.

That would have been a nice flaw to plant for us!  

Allowing the Genesis to forge... destorying every single NXT when generating a block!!!  

I don't think the genesis account can ever forge, since it's max balance will be zero (if everyone sent their NXT there to be destroyed).

Generally, I think that keeping the genesis account around in this way is a good feature.  It's a way for NXT to be destroyed, decreasing the money supply, if desired.  It's completely up to users if they want to send they NXT there for destruction.  In contrast, I'm not sure forgetting/losing your brainwallet password counts as destroyed money.

[ricot]

I just found something else which is at least an inefficiency in the network and could potentially be exploited...

I looked at the cumulative difficulty checks.
When actively querying peers for blocks, the checks seem ok (except for that 720 block issue that we already discussed).
However, when I myself forged a block, I'll call the processBlock methods of my peers to get it into the network.
processBlock doesn't check cumulative difficulty, it just checks if it's the next block (i.e. newBlock.previousBlock == lastBlock).
So if it gets a worse block first, it will ignore the better block coming from me.
This, combined with the "we accept blocks that are 15 seconds into the future" can be exploited:
Say Anna can generate a block that is valid in 15 seconds. She immediately sends it to all peers, which accept that block, obviously.
Poor Bob can generate a block that is valid in 10 seconds, but waits until that time to send out that block.
Now all the peers that Bob sends his superior block to will just ignore it, if they have Anna's block and the only way for Bob to publish his block is to be asked by peers for blocks.
So sending blocks before there's time seems to increase forging chances... I think...

[edit]
Totally forgot to write the solution
Check the cumulative difficulty in a way similar to actively getting blocks from a peer in the passive case.

[edit2]
And here is the attack and the results:
Anna keeps spamming all the peers she knows with her blocks. She probably gets blacklisted by all her peers, but fortunately processBlock doesn't care about that. (slight hint at another thing you might want to fix: the blacklisting isn't checked in a lot of cases)
So Anna will get a block that shouldn't have belonged to her iff:
- her chance to forge that block is at most 15 seconds past the chance of the real block
- the forger of the real block (Bob) sits behind a firewall, so that he can't receive calls from his peers querying him for blocks
- Anna manages to send her block to all of Bob's peers before he does

So it definately increases Anna's chances and the methodology also spams the network. Neither is something you want to have.
To figure out by how much Anna's chances are increased, we'd need to estimate the ratio of blocks forged behind firewalls,
let's say, that's 30%. (I've got no clue about the real number, so feel free to replace it with anything you want)
Anna has a chance to forge 15 seconds longer, at an average 60 second forge duration. This means a 1.25x increase in chance of block generation. Combined with the 30% chance of the other block being forged behind a firewall, Anna can increase her forging chances by 7.5%.
Not much, but definately enough to start spamming the network.

[theKnownUnknown]

And who gets the fees?

This will be determined by the next block.

And how gets the forked chain joined together again?

It doesn't.

One of the two blocks will have a better cumulative difficulty (comparable to a nonce in BTC) and will "win". So the worse block becomes an orphan and every client just builds on the better block.
This process hsould happen quite often because of network latency and such.

Ah, now I found it in the code. cumulative difficulty was the buzzword I needed. Thanks a lot Come-from-Beyond and  ricot.

[gbeirn]

So, the fee is constant in USD.  What do you think the fee in USD should be?

Stakeholders decide.

UNTIE THE FEE FROM FIAT!!!

I think it should be done on a curve, starting with a base percentage of the NXT being transferred and curving down in percentage as the transaction amount increases.  As far as the specific curve, I dont know.  I dont like the fee being tied to any specific fiat at all.

Do to this we would have to reserve the very last few decimal places for fees though.

So for example,
And I am by no means proposing use of these particular numbers (I am just using these particular ones for ease of explanation) dividing NXT down to 8 decimal places, the last 3 would only be used for fees, meaning the smallest amount of NXT that can be transferred is to 5 decimal places, or .00001.
So now, to transfer .00001 NXT (which is the smallest amount that could be transferred in this particular scheme) would cost a fee of, lets say 0.005%  So the total transferred in this case would be .00001005 and I would also suggest a curve to be used to decrease the fee as the amount to be transferred is increased.  

This removes all ties to fiat, which I think should be the goal

In theory, this sounds like a good idea but the problem is transactional/account spam.  This makes it easy to buy 10 Nxt and send near 1,000,000 transactions to random accounts.  With a fee that is set at 1 Nxt, you're not going to be able to spam the network for long which is the current setup.

Instead, I recommend an analytical system implemented that monitors the amount and value of daily transactions and then sets a new minimum fee value that changes day-to-day (or on some other period.)  You can do this using some basic statistics AND you can also use statistics to trim odd, edge-cases on the rare days that "whales" move around 10,000,000 coins.

PS- I've been following/working with Microcash for years.  My last post regarding the development of Microcash was on scaling the amount of distributed, new coins that were generated each day.  

I know that this is about fees and not generating currency, but the concept of adjusting system metrics, based off daily transactional statistics is something I've looked at and thought about for a loooooong time.  I think we could do the same type of thing here.

I suggested a similar approach in the other main thread when people wanted to change the fee to a fiat based number. Basically a 'difficulty based' adjustment like in the other cryptocoins but for the transaction fee.

Edit: I would love to share ideas with you. Feel free to PM me if we shouldn't clutter up this thread with that. (Unless that's OK).

[opticalcarrier]

Ok people... take a break from all the advanced thoughts... and help us coding-challenged people for a sec.!    


Can someone please point to the exact lines in the code where it is established that empty accounts cannot forge.

Is the Genesis account excluded from forging?  What is the forging conditions set for an account with negative balance?


Just wondering what happens if someone unlocks the Genesis account... in respect to the code under examination, of course.


thnx  

  if someone unllocks genesis account, could they send negative NXT to everone to reduce everyone's balance to zero?

[ricot]

Ok people... take a break from all the advanced thoughts... and help us coding-challenged people for a sec.!    


Can someone please point to the exact lines in the code where it is established that empty accounts cannot forge.

Is the Genesis account excluded from forging?  What is the forging conditions set for an account with negative balance?


Just wondering what happens if someone unlocks the Genesis account... in respect to the code under examination, of course.


thnx  

  if someone unllocks genesis account, could they send negative NXT to everone to reduce everyone's balance to zero?

No, the transaction amount as well as the sender's balance have to be positive. Neither is the case in your apocalyptic scenario.