Show Posts - petko
Please login or register.

Login with username, password and session length
Advanced search  


Latest Stable Nxt Client: Nxt 1.12.2

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - petko

Pages: 1 [2] 3 4 5
Official Nxt Releases / Re: NRS v1.10.0e
« on: August 01, 2016, 09:02:13 pm »
Someting wrong here: ::)

Should be fixed in next version. Thanks

Official Nxt Releases / Re: NRS v1.10.0e
« on: July 31, 2016, 04:21:23 pm »
This message should be different with isLightClient=true

The blockchain is busy downloading, you cannot forge during this time. Please try again when the blockchain is fully synced.

Fixed in next version. Thanks!

Official Nxt Releases / Re: NRS v1.10.0e
« on: July 31, 2016, 02:08:23 pm »

Would it be possible to start a brand new installation up (for a new user) and have the question "Do you want to download the blockchain and run a full node or run lite client? Click "Full node" or "Lite client"?

Then the startup script could apply nxt.isLightClient=true automatically and the user would always be running a lite client.

I really think there would be enough of us geeks running a full node to be able to cope with lots of lite clients. It would be great for adoption: "the crypto you don't need a blockchain for!".

Like most people, I don't have a copy of the Bitcoin blockchain but I still use Bitcoin with a lite wallet.

The load on the full nodes is not the only problem. The NXT light client does not provide guarantee that a payment was received (like the Bitcoin SPV clients do).
E.g. if you are selling your car for NXT, don't trust the light client that you have received the payment - the info it displays is served by the remote node and is not verified. (This must be clearly understood by the users)

Yet, the light client is good enough if you are the buyer of the car.

So please don't compare the NXT light client to the Bitcoin SPV - you may get a lot of hate by the bitcoiners :)

Guys, please concentrate:
When nodes download the blockchain they greedily process all chains they see. If there is a fork at height N, they choose the chain that has better difficulty at height N+720, and abandon the other chain. They don't care about the final difficulty of each chain, they only care about the difficulty 720 blocks after the fork.

The attacker's chain still has low difficulty at N+720 because he needs 1440 blocks for his unfairly acquired stake to mature before being able to forge.

As I already said, the attacker must hide the rest of the network from the downloading node in order to succeed. And this is the main part of the attack. If the attacker manage to eclipse the honest nodes during the download, the downloading node won't anyways catch up with the real chain. The deposits/withdrawals "attack" can only be used in addition to the eclipse attack to alter the final difficulty (which is supposed to be manually checked by the user after the download by observing the base target)

Core Development Discussion / Re: PoS Algorithm
« on: March 08, 2016, 02:30:36 pm »
Perhaps the difference is that Ethereum fear is that the load on solving blocks becomes, one day, too high
Ethereum guys fear N@S.

In NXT there is of course the limit on the maximum reorg depth, so is it the only security layer against this type of attack?

The max reorg depth of 720 blocks combined with the 1440 blocks time for the stake to mature before being able to forge. So the attacker's chain will still have low difficulty 720 blocks after the fork (which is what the downloading node checks). Hence, the attacker must also eclipse the downloading node from the rest of the network in order to succeed.

You are right that in this scenario the output-styled transaction system seem more secure.

Core Development Discussion / Re: Nxt 2.0 child chain tokens pegged to fNXT
« on: February 26, 2016, 09:55:55 pm »
This is true, but indeed depends on the amount of locked NXT as percentage of the total. If it is low, the attacker still has plenty of unlocked NXT available for fake locking, to get a good base target without raising suspicion whether we are on a fork or just the percentage of locked NXT has increased for economic reasons. And we can only guess what the normal percentage of locked NXT will be, and it can vary a lot depending on the total economic activity in the system.
So your argument against the pruning of the lock transactions depends on the consequences of the second problem you see. In other words, if the locked NXT doesn't drop, my alternative to the base target is viable.

I cannot argue a lot about your second problem. It's mostly economic issue. Indeed the lock/unlock transactions create friction which doesn't exist in NXT 1.0. And indeed if fNXT is not convertible, there is no reason to own it without forging, hence we should have close to 100% active forging in NXT 2.0 without peg.

If an attacker in 2.0 could create a fork with equally good base target, then you need to download the full blockchain, pruned transactions included, and reprocess them, to find out which site was on a fork.
The pruned transactions are not necessary - checking the difficulty 720 blocks after the fork is enough to distinguish the real chain. This doesn't matter for the security - this processing is anyways impractical (compared to checking only 2 values) - it's just a note.

Core Development Discussion / Re: Nxt 2.0 child chain tokens pegged to fNXT
« on: February 25, 2016, 09:58:22 pm »
Now that I spent some more time contemplating, maybe I don't understand this part

It is not just about protecting new nodes from getting into the wrong fork, any outside observer will have no way of telling which one is the "real" Nxt blockchain, without having to trust a central authority such as a block explorer (which itself might be on a fork).

The way to tell the "real" chain from the fake is to check the difficulties 720 blocks after the fork. This is done by the software. The only "outside observer" I can think of is the user watching his client complete the download. So maybe I don't understand what you mean.

What I agreed upon is that once we sacrifice the base target, there is no other "weakly subjective" value for the user to check in scenario 1. The attacker can include all user's transactions in the fake chain, peerexplorer may be on fork, or may be controlled by the attacker, etc.

It is arguable whether the base target is (and will be) checked by the users, but anyways, this is indeed a security weakness in the current proposal versus the pure Nxt 2.0.

A solution, that was anyways discussed in order to prevent the attack from scenario 2, is to include the hash of a previous block in each (persistent) transaction. So any transactions the owner of the node received or sent will not be included in the fake chain - something to notice after the download complete

On top of this, I can suggest one more weakly subjective value to substitute the base target - the active forging stake versus the total locked stake ratio. Indeed the attacker can lock additional NXT he doesn't own, but cannot unlock the NXT locked by others. The locked NXT that belongs to others is not forging in the fake chain. In a normally functioning system, the forging NXT should be close to the total locked NXT (since there is no reason to lock the NXT unless to forge with it). The locked NXT at the time of the fork cannot be unlocked by the attacker since, even if the owner unlocked in the "real" chain, the attacker cannot copy that transaction to the fake chain. So assuming that around 40% is locked and forging like today, in the fake chain there will be 80-100% of the stake locked but only 40% forging.

Core Development Discussion / Re: Nxt 2.0 child chain tokens pegged to fNXT
« on: February 25, 2016, 11:25:30 am »
Let's say we create such a system, based on a forced peg and reduced security. And a clone is created, with a fresh new genesis block and a fairly conducted IPO, with no such peg. Why would a new user prefer to join a platform where the security of the whole system has been crippled to make one of the child chains "more equal than others"?
I agree no one is interested in a system with compromised security.

Generally, if the peg was not sacrificing security, the reason for a user to choose the system with peg is that the root token can be used in prunable transactions. The root token has more value than in a system where this mechanism doesn't exist (it can be used in cheap transactions, hence it has more value). This is my rationale.

Core Development Discussion / Re: Nxt 2.0 child chain tokens pegged to fNXT
« on: February 25, 2016, 09:48:13 am »
I understand now. Today if an attacker has stake equal to the active forging stake, he must sell it (or buy private keys from someone else who sold their stake) and then launch the attack you describe. Selling such huge amounts cannot be done quickly and won't be a cheap operation. The regular checkpoints are saving us today. While with my design the actual sell is not necessary. I knew there must be something wrong with this idea, I just couldn't figure out what it is.

Core Development Discussion / Re: Nxt 2.0 child chain tokens pegged to fNXT
« on: February 24, 2016, 08:42:23 pm »
Okay, there are 2 scenarios I think:

1. The attacker flooded with so many nodes, or somehow managed to disconnect the user from the honest nodes, so that the user's node missed the better chain 720 blocks after the fork. In this case indeed in NXT 1.0 and 2.0 the final base target will be a lot higher than usually. (While in NXT 2.0 + peg the attacker can "fix" that)

2. The attacker was actually able to hold the better difficulty for 720 blocks. Consequently he is supposed to have had a forging stake with the magnitude of the honest forging power at the time of the fork. I don't have the math about what percent of the honest forging power is necessary to generate a chain of 720 blocks with better difficulty. Naively, it should converge to 100%. Is that wrong?
The attacker will of course hide the transactions with which they spent their stake on the real chain so in this case, even without the peg, the final base target won't be much different than the real chain (it should be close to the minimal active forging power in history). The base target anyways varies a lot between blocks, so not sure the user can notice any difference. I'm also not sure we can add an alert in this case, or it will be triggered when the active forging power naturally fall again. Please correct me if I'm wrong.

Anyways you are right that the peg sacrifices one of the ways for the user to orientate in the first case of attack (and the respective automatic alert).

Core Development Discussion / Re: Nxt 2.0 design
« on: February 24, 2016, 06:40:41 pm »
I just modified the OP of the pegging proposal to make it more clear: https://nxtforum.org/core-development-discussion/nxt-2-0-child-chain-tokens-pegged-to-fnxt

Core Development Discussion / Re: Aternate NXT 2.0 design.
« on: February 22, 2016, 05:42:02 pm »
If e.g. 1000 nxt is forging the child chain, this means someone with say 100 000 nxt can reorganize the chain 100 blocks back in average.

That's totally wrong! Of course with 50% of the forging power an attacker can reorganize all the 720 blocks. Don't know what was I thinking when I wrote that.

Core Development Discussion / Re: Aternate NXT 2.0 design.
« on: February 13, 2016, 03:49:32 pm »
Thanks, Brangdon. Indeed I missed to explain what the chain reorganization causes.

@CoinWizard, maybe the security in your proposal could be improved via proof of burn of NXT. It imitates POW where burning NXT is like buying a mining rig. Yet, as Brangdon mentioned, POW itself is not secure for young chains, and consequently proof of burn won't be either.

Anyways, it would be much more secure if the child chain uses its own stake when forging. I don't understand the benefit from using the NXT distribution versus simply starting NXT clone.

Core Development Discussion / Re: Aternate NXT 2.0 design.
« on: February 12, 2016, 10:54:07 pm »
Why would I as a forger try to hurt or sabotage a childchain that respects gives forging rights to nxt holders???? It is as illogical as a nxt-forger trying to hurt nxt coins or a MS currency...
I mean that since the majority of nxt holders don't have the incentive to forge the childchain, this will make it a lot cheaper for an adversary to attack it.

The situation with the asset and MS currency transactions is slightly different - indeed some forgers may modify the code to not validate these transactions and safe a little CPU. But this way they risk their block to be rejected by other forgers and consequently lose the fees.

Core Development Discussion / Re: Aternate NXT 2.0 design.
« on: February 12, 2016, 08:47:07 pm »
Aha, now I got it. Sorry.

It is dangerous to use the NXT distribution when forging the child chain. If e.g. 1000 nxt is forging the child chain, this means someone with say 100 000 nxt can reorganize the chain 100 blocks back in average.
Edit: Wrong! No need to have 100 000 nxt, 1000 is enough for 51% attack

Same would happen if today the nxt chain was itself forged by only 1000 nxt. It doesn't happen because the majority of nxt stakeholders have the incentive to protect their token. While they don't have the incentive to protect a child chain token.

Core Development Discussion / Re: Nxt 2.0 child chain tokens pegged to fNXT
« on: February 12, 2016, 07:53:16 pm »
I am not convinced. The locking creates coupling between the two chains, with the locked supply of either fNXT or NXT being able to vary all the way between 0 and 1B, in order to maintain the peg, because there must always be some locked amount of the other currency available for unlocking.

Yes, this is how it works.

What are the consequences of total forging power being able to vary that wildly, and in response to forces external to the blockchain?
It's the active forging power that secures the network. The consequence of the total forging power being able to go below 1B fNXT is only that we can be sure the locked fNXT is not forging a hidden fork.

We are also weakening the security by making more assumptions about transaction validity. While probably correct, it is always preferable to have multiple layers of security.
Yes, if there was a bug in the calculation of the effective balance, today an attacker will have to do some sha256 hashing + transfers between accounts in order to generate a better chain, while with the peg he can directly acquire and use the locked fNXT. Are these the multiple layers of security you talk about?

And we are adding code complexity, by adding lock and unlock transactions, and making the Nxt blockchain a special case, not quite like the other child chains.
I don't think the NXT token will be the only one pegged to fNXT

I thought people have a problem with the 1:1 fNXT:NXT initial distribution, not with what happens afterwards. The peg approach doesn't seem to change this, we still have to start with fixed amounts of fNXT and NXT even if some of it is locked.
I myself don't have a problem with the 1:1 distribution. The peg is a mechanism that gives value to fNXT by allowing it to be used in cheap transactions. Locked tokens do not have any value for the economy, so with my design we start with 1:0 (since all NXT is locked).

We already give preference to the NXT child chain by making it the default chain in the client, and by controlling, at least initially, who can create new child chains. But after that initial 1:1 start, I think it is better to let the market determine the relative price of fNXT to NXT.

Core Development Discussion / Re: Nxt 2.0 design
« on: February 12, 2016, 07:10:39 pm »
but there is no pruning on the mother chain. it sounds very vague without any numbers to go with it.
tps on the mother chain will not be increased (or may even be decreased). Transaction throughput of the whole system will

Core Development Discussion / Re: Nxt 2.0 design
« on: February 12, 2016, 06:28:23 pm »
how is tps limited by bloat? what does pruning do for tps? what i read from your post is solving tps will be aproached when and if it becomes a problem.

the last sentence i don't fully understand.

tps limitted because of the bloat. I mean that the reason for the limit is the bloat. If we solve the bloat, we could increase the limit and reduce the minimal fees.

the last sentence: i'll explain later

Core Development Discussion / Re: Nxt 2.0 child chain tokens pegged to fNXT
« on: February 12, 2016, 05:23:42 pm »
When an account locks some amount of fNXT, does it lose the ability to forge with it? If it does, the total forging power will change depending on how much fNXT is currently locked. Need to think through what consequences this may have. Somehow the forging power of the main chain will become related to the tokens unlocked in the child chain, so it is no longer true that security does not depend on what happens in a child chain.
Yes, it loses the ability to forge.

It is better to place both lock and unlock transactions on the forging chain, so that all transactions that change fNXT effective balances are always verifiable and that "trust others that they have verified them" is not needed for those.
Yes, both are on the fNXT chain, but a node downloading the blockchain anyways cannot validate that the respective account had the funds in the child chain at the time the unlock of fNXT happened.

What you are suggesting is in a way equivalent to allowing exchange of fNXT to NXT to only occur at 1:1 rate. Since we don't want to peg all child chain tokens to have 1:1 value in fNXT, otherwise they will not really be independent tokens and the whole system of child chains has no purpose
I disagree - the purpose is that any transactions occurring between the lock and the unlock of the fNXT are not included in the fNXT blockchain.

, we do need an exchange mechanism of child token to fNXT, similar to the current asset exchange, with bid and ask orders. If we need to implement such exchange anyway, can the peg of fNXT to NXT also be realized by only accepting ask or bid orders at price 1.0? This would be hardcoded for the NXT child chain, and we will not need a separate lock/unlock transaction mechanism.

But then, the problem is that an exchange of fNXT to NXT can be performed outside of the system, instead of going through the built-in AE, for example on a centralized exchange. If one of them is perceived as more valuable, its price will go up on such exchange, and nobody would be using the built-in exchange (there will be no ask or bid orders respectively). Does the lock mechanism have the same problem, or is it prevented by assuring there are always some locked tokens available for 1:1 exchange, because you start with all child tokens locked? But what happens when there are multiple child chains, some of them pegged, some not?
The lock/unlock mechanism is different from the decetralized exchange because the locker don't need a corresponing seller on the other side.

If non-pegged child chains are really so important, the pegged ones are not disallowing their existence - either exchange or peg.

Pages: 1 [2] 3 4 5