Topic: Nxt source code flaw reports - page 51. (Read 113359 times)

I checked several accounts and they all showed that unconfirmedBalance equal to the balance. Is unconfirmed balance always the same as the balance? Of course, as the balance decreases, the unconfirmed balance become lower. Is it possible that unconfirmed balance is lower than the balance?

BTW, from my experience, I found that Nxt terminologies are not so straight, and are usually opposite from the general understanding.

"unconfirmedBalance" seems to be the code internal variable and parameter for some important functions, and it may be not so important for the average joe, so is it necessary to list out in the API for the end user? Another example is the "token" concept. It's introduced for web application and the user need to fill in the website. So I'm not interested in it at the early stage a month ago. Later on, I wondered whether I can sign a message in Nxt system. Of course, in the end I leaned "token" is just the same as bitcoin message signing, but Nxt changed its terminology.

No. int works faster.

Line 2414:


Should be "short hostLength"?

Maybe

Maybe this is the reason why in Novacoin inputs that generates PoS block became frozen for 3 day?

If u sent a transaction ur unconfirmed balance would become lower.

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.

That case is OK. So my understanding of unconfirmedBalance was wrong, so why the unconfirmedBalance is equal to the balance and effective balance from the API I just got from my account?

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.

Valid point, let's change that part a little:
There is a small chance that you'll loose 100,000 NXT for setting up the small accounts and another 100,000 is bound to those, and of course the 1 NXT for the big transfer.
This reduces your forging chance to ~0.99 %. (~0.98 % for the budget used in attempting the increased forging chance)
And the cost for any further attempt on doing the same is just 1NXT at a small chance.
That doesn't change a lot in the methodology, actually, it's statistically irrelevant.


Ok, let's start with the 25% part:
You transfered NXT into some account. This account has a forging probability of 0.98%. Nothing changes, all is well. (I really don't know, what more I can say for this situation as that one is the trivial one)

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 %.

If we used balance instead of unconfirmed balance then an adversary could spam a lot of transactions that would never be confirmed and just consumed bandwidth of other peers.

Sorry, too hard to understand it for me.

+1

Fiat is irrelevant and prone to lose value over time! Gimme those precious nxt decimals!

UNTIE THE FEE FROM FIAT!!!

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

To do 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

Edit: No flaws found yet.

I've tried to follow this full thread this morning but, just in case I missed something, has anyone found any of the lesser flaws?

It looks like this exercise is serving it's purpose.  Injected bugs aside, there's been a fair amount of constructive QA.

CfB-- I know what you are doing.  This is psychologically manipulative, crowd-sourced, bug hunting at its finest!

At first I was quite turned off by the fact that this is a coin written in Java.  However, what Java has provided is for you to be able to bring a 1-page "specification" in the form of easily compilable and executable code.  Also, I think that not providing unit tests is smart, too.  If you have to roll your own testing, you will do it from your unique perspective of how it should be done.

The software will be analyzed on a MUCH more thorough bases if 5-10 advanced developers take their time to hammer the code the way that they uniquely test code.

Kudos devs!  If I find some time this afternoon, there are few operations I want to look at.  They are areas where I, personally, would inject bugs if I were to develop such a public exercise.  (Hint: They would be in the most critical, but theoretical/unproven portions of code because that's where you would want your testers to spend the bulk of their time.)

Will see. Just have to wait for Voting System launch.

I would guess $0.2-0.4 USD because that seems to be the average TX fee for bitcoin over the months.  See https://blockchain.info

Maybe 1 cent?