elective-stereophonic
elective-stereophonic
Show Posts - petko singapore
Please login or register.

Login with username, password and session length
Advanced search  

News:

Latest Stable Nxt Client: Nxt 1.11.15 | Latest Experimental Nxt Client: Nxt 1.12.0e

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.

Topics - petko

Pages: [1]
1
Ardor General Discussion / Burn Account
« on: March 18, 2019, 07:51:09 pm »
In Nxt, burning tokens was done by sending them to the Genesis account. The Genesis account was removed in Ardor and now we are facing the problem of how to provably burn tokens. For this we (obviously) need to send the tokens to an account for which it is guaranteed that no one in the World will ever be able to unlock it. So how to get such account?

Since public keys are 256-bit numbers, the simplest approach is to choose a public key in such way that it is obvious for everyone that the person who chose the number, couldn't possibly know the matching private key.

So now I choose the number 618debcd12fe01a90559b1501f27969ea5ac7675bcf7454bf015b685059e3f49, which is the SHA256 hash of the word "Burn Account". You can check that by running

Code: [Select]
echo Burn Account|sha256sum
I obviously chose to hash (with the algorithm which is most commonly used in the project) a combination of two words, which makes sense in the context of burn account. Does anyone think that I could possibly know the private key matching this public key? I.e. does anyone think that I could have possibly iterated so many private keys that I found a public key which makes sense in the current context?

This is kind of social experiment which aims to clarify how much controversy will this approach gather. I.e. if I cannot persuade everyone that it is not possible for me to know the private key, we better not use this approach in the first place.

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

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

3
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?

4
Account Control / Two Factor Authorization (2FA)
« on: September 03, 2015, 04:11:51 pm »
I'm writing this quick memo in order to clarify what 2FA is and how is it going to work from the user's point of view.

The two factor authorization (2FA) adds a second authorization with hash chain. The second factor is a hash value that changes with every transaction. This is not a second password (a second password the user can set with the two-phased AC and account voting). 2FA is similar to the transaction authentication number in banking.

Firstly the user must generate a hash chain (preferably on a secured machine). I'll write a tool for that (since I anyways need it to test), but generally this is not part of NRS. I hope to see a more integrated and user-friendly solution for smartphones (actually I may work on that afterwards). The hash chain starts with a cryptographically-secure random secret which is afterwards hashed N times with SHA-256 to receive the last chain value hN(secret) (N is the length of the hash chain). The last value of the chain is provided when creating the account control in NRS. The secret must be stored on the device from where the chain values will be read (this will most probably be the same device where the chain was generated).

When creating the 2FA account control, the user specifies
  • hN(secret)
  • Recovery account - where all funds are transferred in case the account password is compromised (what is specified here is actually SHA-256 of its public key)

Once the account control is created, every subsequent transaction is not applied until a special, hash-revealing transaction is received. The hash-revealing transaction reveals the previous hash in the chain - hN-1(secret), hN-2(secret), etc. These values are read from the secured device which contains the initial secret. A tool will display them one-by-one and the user will re-write them or scan them from there.

It is not a problem to have several pending transactions waiting for hash-revealing transaction, but that number must be limited to a reasonable number (else an attacker who knows the account password can waste all account funds in fees).

It is also not a problem to skip one or several hashes from the chain, but up to a reasonable number, else we may end up doing too many calculations.

It is essential the UI to clearly show which transaction will be applied with the revealed hash (i.e. which is the oldest pending transaction).

What should the user do if in the blockchain appears a transaction that he/she does not recognize? At this point new transactions cannot be created because the network cannot know which is created by whom. So we must have set preemptively the recovery data - thus the recovery account when creating the control. Now the user can issue a special Transfer Everything transaction which does not require hash-revealing transaction. It transfers everything to the preemptively specified account.

The recovery account should be specified by a hash of its public key only, not by the actual public key or account number. Only the transfer everything transaction, when submitted, should reveal the real public key of the account to transfer everything to (which should be checked to match this hash).

5
Nxt Improvement Proposals / NXT social network
« on: July 09, 2014, 05:27:42 pm »
Parts of this idea were already discussed, but I don’t find it summarized…

I propose a system built on top of NXT, which allows the users to connect, share content, and generally communicate without a central authority. It has several advantages over the classic social networks (like Facebook, Twitter, etc.), most important are that it cannot be blocked, the users’ content is harder to be manipulated or monitored; the system will scale better and will be less dependent on server technologies. Let’s name the system with the working title NXTNet.

Most features are well known from the already existing social networks:
1. Every user can create content (text, image, video) and share it publicly, or with a limited set of other users. A post could be “in reply to” another post, which effectively realizes a discussion tree.
2. A news feed is presented to the user with the content created by other users.
3. The user maintains lists of other users’ accounts in order to manage the information that appears in her feed, and the permissions to the content created by herself.

But since there is no central storage, we need few more features:
4. Every user can run a storage node and this way provide her resources to other users. The storage node will be rewarded by those who use it (either by those who create the content, or by those who read the content, or my both, or via ads).
5. Every user chooses which storage nodes to trust and use. The trust is only about the uptime and the general technical capabilities of the storage node. The storage node cannot read content which is not public. Via a storage node, the user may also sync between different devices personal data like the lists with connections.

NXTNet is built on top of NXT, but this does not mean that any content is saved in the blockchain. NXTNet will use NXT to handle any payments between the users, and, wherever necessary, to receive an estimation about the wealth of a user. But no data goes in the blockchain - we don’t need centralized storage for the users’ content. On the contrary - we need it distributed as much as possible.

A decentralized social network could be built without an underlying payment system. But there’s no such product developed yet (or at least not to my knowledge). Actually, there is Diaspora and similar projects, but no crypto-based social network.

Of course, I only scratch the surface with this post, there are many details to be clarified.

6
Alternate Cryptocurrencies / Credit Coin
« on: July 02, 2014, 01:28:03 pm »
This is a question, not an announcement. It's a long long story, I don't really know where to start from...

Naively, a bank is a centralized entity which collects deposits and provides loans, and its profit comes from the difference in the interest rates. Of course, what the bank does is a lot more complicated - the bank organizes all the mess, "absorbs" the risk when giving loans (or at least should be absorbing that risk), the bank owns the security interests of the loans (like mortgages), handles most payments, the bank may also be an investor.

So I'm wondering, could that system be decentralized somehow - the borrowers and the lenders to meet and organize their relations without the need of a central authority. For example, if I am a borrower who wants to buy an apartment for 100 000 Euro, I issue "credit coins" with certain interest rate and payment schedule. The lenders buy that CreditCoins for USD, EUR, BTC, NXT, etc. (or maybe there will be a purposive DebitCoin). The credit coins automatically increase with the interest rate (for example with 10% per year). When I'm paying back my loan, I'm effectively buying back the credit coins I've issued. If I do not follow the payment schedule, well, my creditors will have to sue me same way like the bank sues me.
Yes, I realize the whole thing is a lot more dependent on the legislation of particular country. For example, it will be very difficult for a creditor in the US to sue someone in Europe. Still, something like that might be of use for people of same country.
If a creditor wants to use his money, he can sell his CreditCoins to someone else.
Maybe with a little changes in the legislation, it will be even possible a mortgage to be held by anyone-who-holds-the-credit-coins.

I know this is a lot more dependent on legislation, but still I'm wondering if there is a cryptocurrency that aims to provide such mechanisms.

Thanks

7
Nxt General Discussion / What is the plan for the transaction fees?
« on: May 04, 2014, 08:02:55 pm »
So I read the FAQ section of the wiki:
Quote
Why are transaction fees so high?
Currently it costs a minimum of 1 nxt to perform any action, whether it's sending Nxt, registering an alias or sending an arbitrary message. No new nxt is ever created, so the fees earned by forgers come entirely from transactions. Forgers need to earn fees as an incentive to keep their nodes running and encode new transactions into the blockchain, thus securing the network.
Nxt is still in its infancy. There aren't a lot of users yet, and features are still being implemented. So the number of transactions per day is still low, but growing. As transactions, and the price of Nxt grows, transaction fees will be adjusted downwards to keep transaction costs reasonable while still sufficiently rewarding forgers and preventing the blockchain from being spammed with unnecessary transactions.

OK, I understand that Nxt is still in its infancy, but from this text I remain with the impression that there will always be a minimum fee constraint (which will be adjusted but still in effect). My general philosophy is against any constraints, laws and regulations, and that the free market regulates itself better than any authority. What is the position of the community about this?

8
Introduce Yourself / Greetings from Bulgaria!
« on: May 04, 2014, 09:20:42 am »
Hi!
I'm observing the evolution of the cryptocurrencies technology for around 1 year. But I didn't get evolved until now because I was neither willing to purchase and manage mining hardware, nor am I a gambling guy who can speculate with the exchange rates (I don't have the skills for that - I'm a programmer). And last but not least, I never had the opportunity to use a cryptocurrency to pay someone.
Nxt allows me to participate in the development of a cryptocurrency without spending my time on managing hardware or writing code. This is how I understand Nxt - by purchasing coins I'm becoming a stakeholder and I believe I'm funding the development of the payment system itself.

Good luck to all!

Pages: [1]
elective-stereophonic
elective-stereophonic
assembly
assembly