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
Core Development Discussion / Re: Nxt 2.0 child chain tokens pegged to fNXT
« on: February 12, 2016, 04:44:47 pm »

I'm not fully understanding this. Are you implying that there could be any number of locked tokens across all chains, but only 1 billion active (unlocked) tokens?
The number of locked tokens is always equal to number_of_created_side_chains * 1B

Consider the locked tokens as if they do not exist - they are not owned by anyone, cannot forge, etc.

I'm also interested to understand any overlap with the possibility of forging on a shadow NXT balance of people's regular NXT accounts.

If sNXT reflects the state of NXT, then to verify that certain account has the right to forge certain block, one must have also processed the NXT chain. I don't understand the purpose of your idea.

Core Development Discussion / Re: Aternate NXT 2.0 design.
« on: February 12, 2016, 03:37:47 pm »
If only some forgers are validating the child chain transactions, they will quickly be left on a fork when an invalid child chain transaction appears.

What you describe here can be done today with a message transaction holding the child block hash.

Core Development Discussion / Re: Nxt 2.0 design
« on: February 12, 2016, 03:17:42 pm »
i dont see anyone panicking, people are just voicing concerns. i don't know why you push those into the panic corner immediately.

im starting to like the ideas more and more. however i think i asked a legitimate question in my previous post, which has not been adressed by anyone. so again: it has been talked about full blocks. solving bloat alone doesn't solve scalability. given that this is all about solving scalability, i would like to hear ideas on how to solve TPS.
i think it makes sense to talk about it now, rather than to say lets solve it later. this is all about a vision isn't it?

Currently the TPS is limited mostly because of the blockchain bloat. Apart from the TPS limit, we have another limit - the minimal fees - again aiming to handle the blockchain bloat.

And speaking about the future, I think we can build a sub-sub-chain that uses a child chain stake in its Proof-of-stake

Core Development Discussion / Re: Nxt 2.0 design
« on: February 12, 2016, 03:00:42 pm »
How is NXT 2.0 different from mini blockchain cryptonite.info apart from NXT would have POS and child chains?
Yes, a child chains in Nxt 2.0 is something like the cryptonite chain, while fNXT is the POW. Ethereum is a more popular adopter of this approach

Core Development Discussion / Re: Nxt 2.0 design
« on: February 12, 2016, 02:38:03 pm »
I started a new thread about the pegged tokens opportunity - https://nxtforum.org/core-development-discussion/nxt-2-0-child-chain-tokens-pegged-to-fnxt/

(Since I don't see anyone replaying to my post - not that I read all 14 pages since then)

I think it is worth to be discussed first instead of arguing about the fNXT/nNXT distribution

Core Development Discussion / Nxt 2.0 child chain tokens pegged to fNXT
« on: February 12, 2016, 02:33:32 pm »

After talking with durerus and James in chat, they made me realize I don't clearly explain this mechanism. So here is another way to look at it:

The proposed Nxt 2.0 design can be modified so that there is no new fNXT token introduced. The current NXT stays distributed as is and the user has 2 opportunities
  • Lock the NXT and use it for forging (and maybe to send it to another account)
  • Unlock the NXT and spend it for whatever it can be spent today

Locking and unlocking can be done any time. The lock/unlock transaction is persisted forever (its fee will be higher than the usual prunable transactions, but not higher than today's transactions or any other persisted transactions). After locking there is the standard 1440 blocks time until the stake can be used for forging.

Initially after the hardfork, either all NXT will be locked, or we can think for other distributions. The distribution is not that essential since anytime anyone can lock or unlock their NXT.

The original post below contains more details about how and why this works. I talk there about multiple child chains. It is actually possible the unlocked NXT to go to one chain or another (but not both in the same time). This might appear useful for a lightweight client which processes the root chain and only one child chain. But for now disregard the several child chains and consider there is only one child chain. (BTW for the lightweight client to work, we must introduce a new limitation that the locked NXT to not be transferred or unlocked again for next 1440 blocks)

[Edit2 ends]

In Nxt 2.0, I think we can peg the child chain tokens (NXT) to the root token (fNXT in JLP's design).

How does it work
 - A notion of locked tokens is introduced - maybe by a transfer to a special purpose account, or some other mechanism.
 - All child chains have 1B tokens (equal to the total fNXT amount). When a new child chain is created, all its tokens are locked.
 - At any time, owners of fNXT can issue a transaction that locks some of their fNXT and unlocks (transfers to the issuer's account) the same amount of child tokens in a child chain specified in the transaction.
 - Again at any time, owners of child chain tokens can issue a transaction to the fNXT chain (they need some fNXT for that) that locks the NXT and unlocks the same amount fNXT. Since all nodes process all chains, the nodes have the necessary information to validate this transaction. New node downloading the blockchain will assume the transaction must have been valid at the time it was processed similarly to the ChildchainBlock transactions.

Pretty naive, huh?

Why does it work
Intuitively this gives one more opportunity to the attacker in case of a successful long-range attack - they can steal the locked tokens and this way increase even further their forging power. I argue that this doesn't matter:
 - There are no full long-range attacks in NXT because nodes will not switch to forks with common block older than 720 blocks ago. If an attacker manage to generate a chain with length > 720 (at any moment in the past), that has better difficulty than the main chain, they can only fool the new nodes downloading the blockchain (this, of course, is in no way underestimated as a threat).
 - Forging balance becomes active 1440 blocks after it was received.
 - Nodes are greedily choosing the best chain they see - once trapped in the attacker's chain they will never step back to the true chain.

 => So the two-way peg presented here does not increase the opportunities for a new node to get trapped in a fork.

If a new node is trapped in an attacker's fork for more than 720 blocks, the attacker can
 - Fool the node that a payment was made, while it wasn't on the main chain (already possible in Nxt 1)
 - Change balances and everything in child chains (Nxt 2.0)
 - Increase his total fNXT with locked fNXT (Nxt 2.0 + peg). My point is that this doesn't matter - nodes must anyways not get trapped

Edit: I missed to explain what the two-way peg gives (in case it is not obvious):
Finally, in the described system, there are exactly 1B non-locked tokens. I.e. all chains share the same currency, while benefit from the pruning capabilities in Nxt 2.0

Core Development Discussion / Re: Nxt 2.0 design
« on: February 09, 2016, 12:36:40 pm »
I see an opportunity for simple payment verification of payments in the child chains. It's pretty much similar to SPV in Bitcoin with the difference that the POW is substituted with fNXT POS.

The verifier has the whole fNXT chain processed, and the SPV proof is the child block that contained the respective transaction (if the transactions were organized in Merkle tree, the Merkle path would have been enough). So having the child (NXT) block, the verifier checks that the block has indeed a corresponding ChildcoinBlocks transaction in the fNXT chain, and can (similarly to Bitcoin) safely assume that the child payment was correctly verified by the full nodes.

With this, the SPV client software doesn't need to download the whole child chain state - only to process the fNXT chain. (Yeah, JLP just explained how important it is everyone to run full node, but anyways we cannot prevent the development of alternative clients, and SPV clients are essential for the Bitcoin adoption IMO)

Another application is a two-way peg similar to the one proposed by the blockstream guys - https://blockstream.com/sidechains.pdf
In fact, since every node processes the fNXT chain, converting fNXT to child tokens is pretty strait-forward - a transaction that specifies the amount and to which child chain are the tokens converted.
The SPV proof comes in use for the opposite conversion: in order to claim the fNXT tokens, the converter includes in the fNXT transaction an SPV proof that the child tokens were locked at least 720 blocks ago.
Of course the problem is the fNXT blockchain bloating. Even with Merkle path, the size of the NXT to fNXT conversion transaction would be log(size_of_the_sidechain_block). And it must be stored forever in the fNXT chain.

Edit: there might be a more economical approach to NXT->fNXT conversion - instead of providing a proof for the lock, the converter can directly lock the child tokens with a transaction in fNXT chain. But have to think further about how is this possible... maybe I'm wrong from the very beginning.

Pub crawl / Re: Would you enter a Star Trek transporter :)
« on: January 23, 2016, 07:01:14 pm »
Yeah, if there is cookies on the other side...  :D
You decide what cookies mean.
There are cookies of course :). The questions are
 - Is it you who eats the cookies
 - If not, would you die to allow someone else eat the cookies

Nxt General Discussion / Re: NXT forging Q&A
« on: January 23, 2016, 05:43:20 pm »

You are right of course, I tried to over simplify the explanation not strictly following the code.


And speaking about beaming: https://nxtforum.org/pub-crawl/would-you-enter-a-star-trek-transporter-)/

Pub crawl / Would you enter a Star Trek transporter :)
« on: January 23, 2016, 05:42:02 pm »
I challenge you to enter a slightly modified version of the Star Trek transporter. The modification is not essential (or is it?), it only emphasizes the ethical dilemma.

Transporters in Star Trek "convert a person or object into an energy pattern, then "beam" it to a target, where it is reconverted into matter". In my version, the person is scanned at (sub-)atomic level, his/her data is transferred to the destination where an absolutely similar person appears. Then the original person is killed (painfully or not - does it matter?).

So would you enter?

Nxt General Discussion / Re: NXT forging Q&A
« on: January 23, 2016, 04:39:07 pm »

... This unique string is then hashed using sha256 and the result is multiplied by the account effective balance. ...
- its not quite so judging by wite paper:
target = baseTarget * effectiveBalance * timeSinceLastBlock

I also don't understand. "The unique string hashed using sha256" is called "hit" (actually only it's first 8 bytes). The hit is not multiplied by the account effective balance. It is divided by baseTarget * effectiveBalance in order to get the minimal time since the last block when the respective account can generate a block (A.K.A. the hitTime)

Consensus Research / Re: Interactive Proof-of-Stake
« on: January 16, 2016, 10:39:36 pm »
Anyhow, in a week or so the BT adjustment algorithm will change, and it will become virtually impossible to play games with it.

Hi, could you please clarify why the new adjustment algorithm makes grinding impossible? The only improvement I see is that BT is not adjusted every block. It is adjusted every 2 blocks, so indeed an improvement, but not really impossible I think. Most probably I don't understand something. Thanks.

Core Development Discussion / Re: NXT 2.0 what is it?
« on: January 05, 2016, 12:19:13 pm »
That may be, but it is not the original/main idea.

Please link to the original idea if possible. (Here is another paper on the topic by Peter Todd).

In a Bitcoin sidechain it does not need enforcing, it is just a consequence of the alternate chain having the same currency.

Actually, in the previous paper I linked to, the two-way peg practically makes the two chains have same currency (since anyone in any time can move tokens between the chains). I was wrong in my previous comment - if two-way pegged token is the only option for the side-chain, this indeed disallows creation of altcoins.

Unfortunately in both papers PoW is excessively used and I cannot think of a mechanism to support same currency on different chains with PoS.

You can do both at the same time, but some ways of doing the latter former don't help the former. It may be that the best way to bring cryptocurrencies to the masses is to abandon Nxt and work on clones instead. To me it sounds like child chains are trying to give the benefits of that - such as, a clean start, no legacy whales, and choice over features - without abandoning the original BCNext blockchain.

I'm not sure that altcoins help adoption. On one hand separate tokens bring incentivisation to create sidechains and competition between the token creators. On the other hand, coins appearing and disappearing every day creates uncertainty for the future. Anyways, I think sidechains are discussed for their technical values so far.

Core Development Discussion / Re: NXT 2.0 what is it?
« on: January 04, 2016, 09:49:19 am »
Well, some of this may depend on your philosophical goals. Do you want to use NXT to get rich personally? Or do you want to bring the benefits of cryptocurrencies to the masses? It sounds like child chains will be a trade-off between these goals.
I disagree there is a trade-off. Giving something valuable to others is a pre-requirement to getting rich. (In fact, not exactly a pre-requirement, but the only ethical way to do it. Unfortunately, there are other ways to get rich - like robbing people).

I'm not an expert, but here is the concept: a Bitcoin sidechain is basically a way to move bitcoins from one chain to another. The chains work independently. One chain can even die without affecting others (coins in that chain would be lost). This allows for any kind of experimentation, but without creating new altcoins.
I guess this is the Bitcion sidechains paper you reference? The authors do not disallow creating new altcoins - see section 5.1.

The possibility to "peg" the sidechain token to the parent token is indeed useful feature. But I don't think this can be enforced. Even if we enforce locking some amount of the parent token, how much is the minimum? If I want to create an altcoin without pegging it, I will lock the minimum parent tokens and this way I get almost unpegged altcoin.

So, even though pegging will be useful for the credibility of the sidechain token, I think the most important feature to start with is a trustless exchange between the chains. Or at least between parent chain and child chains. This should be relatively easy since the nodes that verify the child chain anyways needs to verify the parent for the pruning to work.

Core Development Discussion / Re: NXT 2.0 what is it?
« on: December 22, 2015, 11:30:06 am »
The blockchain is a technology for building consensus in a trustless anonymous environment. If only selected parties are supposed to do the agreement, then the blockchain is an overkill.

If a company, or a community in general, wants to use the NXT technology, but not the NXT token, they can do it today. GPL is not preventing that in any ways, they only need to change 2-3 files, so nothing so secret to hide by closing their source code.

Indeed the sidechains idea appeared while we were discussing the whitelabel blockchains, but for me these are 2 completely different things.

Core Development Discussion / Re: NXT 2.0 what is it?
« on: December 21, 2015, 11:05:52 am »
Will the child blockchains use the POS of nxt to determine who gets to forge, or will it use their own currency to determine that?

If we want to scale to the whole world, each blockchain must be forged by its own nodes. This way forgers of a parent blockchain will need to validate transactions only of the direct children, but not the sub-children. (Again, this is still to be discussed)

Core Development Discussion / Re: NXT 2.0 what is it?
« on: December 20, 2015, 07:42:19 pm »

Interesting, do you envision that child chain would need to pay some money (periodic fees) to the mother chain in order to be active?

Yes, and that's the tricky part :)

Core Development Discussion / Re: NXT 2.0 what is it?
« on: December 20, 2015, 06:53:50 pm »
2.0 is about scalability. The idea is to spawn side-chains from the main blockchain. The side-chains will be checkpointed in the root chain and this way they can be pruned. It's special because it will be a huge change in the architecture - switching from single blockchain to a tree of blockchains.

Note that this is my personal PoV, we haven't discussed this with JL enough, not sure how much our visions intersect.

Typing the account number into the login screen and into a recipient account on the send money modal now works fine on LG-G3 with Chrome and iPad with both Chrome and Safari.
Good job !

I did find some problems:
On LG-G3, I cannot paste an account number into this field now. I think this used to work with some effort.
On my Windows workstation with Chrome, start typing the account text, ALT-TAB into another application and then ALT-TAB back. The value you entered disappears. This did not happen in 1.6.2

You can access the latest testnet code in this address

If anyone else would like to test using other devices and post your experience that would be great.

I fixed the ALT-TAB problem.

About the pasting problem, it works on my side everywhere I've tested (I know because I had to make some special tweaks when pasting an address starting with "NXT-"). Of course the devices I've tested are very little subset of all Android devices, so my tests mean almost nothing. I don't have LG-G3, I'll need your help. Firstly, how exactly does pasting fail on your side? And which Android version do you have?


Thanks Petko, please push this to the private repo and I'll test it. What was the main reason typing on Android did not work ?

In maskedinput 1.3.1 the reason is that the "input" event was not handled at all. As already noted, "keydown", "keyup", "keypress" may not be fired on Android, or if they are fired, this is probably some emulation done by the browser and will contain dummy data like keycode 229. The correct way to handle typing on Android is via the "input" event.

In maskedinput 1.4.1 the "input" event is handled, but the cursor position for some reason was set before the typed character. So I fixed this and also some more bugs (you can see the log for details).

Pushed to develop

Pages: 1 2 [3] 4 5