What is Stag?Stag is a a new cryptocurrency in the works which utilizes the source code for NXT with a few modifications. It is intended to be as stagflationary as possible, meaning that there is little-to-no inflation or deflation of value. A usable currency needs to have stable value. People need to be confident that it will be as valuable one day as it will the next. If people expect the price to drop, they will try and get rid of it because it wont be as valuable tomorrow as it was today like fiat currencies. If they expect the value to go up, they will hoard it and it won't be used as a currency, rather, as an investment, like a stock, and the price will fluctuate wildly as people buy and sell it. With Stagflation, a currency can be a stable store of value that people have confidence in.
How can stagflation be maintained in a cryptocurrency?Simple, currency can be introduced and taken out of a system so that there is roughly a constant ratio of people to the amount currency in circulation. So how can a cryptocurrency do that?
In Stag, for every new active account on a block, there will be 100,000 Stag introduced into the economy via a reward given to the accounts that forge the following few blocks. For every account that goes inactive on a block (this happens when an account has not been forging or made any transactions for over a month) 100,000 Stag will be taken out of the economy via a destruction of 50% of the transaction fees that go into a block reward.
The amount of Stag to be added or subtracted from the economy is called Phantom Stag. If there is a positive balance of Phantom Stag on a block, 10% of it will be given to the account that forges the block. If there is a negative balance of Phantom Stag on a block, 50% of the transaction fees will be taken from the block and destroyed, the other 50% will go to the forger of the block. The equations are as follows:
- phantomStag = 100,000 * (newlyActiveAccounts - (amountOfStagInInactiveAccounts / 100,000))
- blockRewardIfPhantomStagIsPositive = 0.1 * phantomStag + transactionFeesForBlock
- blockRewardIfPhantomStagIsNegative = 0.5 * transactionFeesForBlock
As you can see, the amount of Stag in circulation will stay relatively the same. It may fluctuate a little bit, but won't fluctuate much unless there are a large number of accounts that go inactive on a single block or a large number of accounts that go active on a single block which in unlikely.
What is to stop people with large amounts of Stag from gaming the system by creating and maintaining as many active accounts as possible?Excellent question... The answer is Brother Trees!
As we know, new NXT accounts must use a public key for their first transaction. In Stag, the sender of that first transaction becomes linked to the new account. There will be many original Stag accounts, referred to as "Root Accounts." There will be one Brother Tree for every Root Account. Each time a Root Account sends a transaction to a brand new account (let's call it a Branch Account), that Branch Account then becomes part of that Root Account's Brother Tree. Each time that Branch Account sends a transaction to a brand new account (a new Branch Account) it becomes connected to the first Branch Account and, by proxy, the Root Account and any other accounts in that Root Account's Brother Tree.
If an account of a particular Brother Tree forges a block in which there in Stag introduced due to new branches on its' own Brother Tree, then the new funds because of accounts on that Brother Tree will be given to a random account that is at as close or closer to the root on a different Brother Tree chosen with a probability based on the number of new accounts a Brother Tree gets. This is called the Brother Award.
So, what stops people from making and maintaining a bunch of new accounts of different Brother Trees than their own? Well, if someone creates an account on a different Brother Tree, they decrease their own chance of getting a Brother Reward if they don't get the block.
Don't Brother Trees and Brother Rewards benefit Root Accounts more because they are more likely to get a Brother Reward than Branch Accounts?Yes and no. The more and more branches there are, the less likely they are to get a Brother Reward because they have an equal chance as every account up the tree until the level of the new account. The only way they can benefit is if an account close to the Root on another Brother Tree activates a lot of accounts thus increasing their chance at getting the next Brother Reward but decreasing the chance that their tree will receive future Brother Rewards.
What stops a particular Brother Tree from becoming "better" than other Brother Trees?Simple! The larger the Brother Tree, the more likely it is going to receive a Brother Reward but the less likely any individual in the tree is to receive the Brother Reward. For a smaller tree, the opposite is true. Therefore, there is a balance in the way Brother Trees grow and in the motivations for a individual to create an account on one Brother Tree as opposed to another.
The beauty of this system is that everyone is motivated to spark as many new accounts as possible both on their own Brother Tree and on other Brother Trees. They get a new account on their own Brother Tree and they increase their chance of getting a Brother Reward in the future but if there are too many new accounts created too fast, then that Brother Tree is the one giving the reward instead of getting it.
The Bottom LineSteady, equal growth of each Brother Tree is combined with stagflationary economics to create an economy in which use of the currency is encouraged and the people have confidence in the currency's stable value. This currency is Stag.
Initial DistributionThe goal is to get as many Root Accounts as possible. The more people that are using Stag, the stronger Stag will be! It is for this reason that I am giving away shares in the initial distribution of Stag for free!
How much Stag will there be when Stag begins?This number will be determined by the number of people who pre-register for Stag. The equation is thus:
amountOfStagAtInitialDistribution=100,000*numberOfPreRegisteredAccounts
The number of pre-registered accounts includes one for myself. The limit is one account per person.
To enforce this, ONLY Sr. Members and Hero Members of NXT Forum and of BitcoinTalk will be allowed to claim shares!How much Stag will I get for pre-registering?95,000 Stag... Details below.
What percentage of the initial distribution will I get for pre-registering?Again, this depends on how many people pre-register. I am practically broke, so I will be taking an additional 2% of the initial distribution (unless somebody talks me out of it). After all, this was my idea! An additional 3% of the share will be given away as a bounties. So, your percentage can be found via this equation:
percentageOfInitialDistribution = (95 / numberOfAccounts) + bountyPercentageReceived
Is this fair? You tell me!Because so many people are free to pre-register (at no cost) and those who put work into the creation of this economy are the only ones given more than others (Devs, designers, exchanges, etc.), I see this as fair.
If you disagree, PLEASE tell me! I want this to be as fair as possible!Pre-Registration DetailsSimply
PM me here or post on the equivalent NXTForum thread (link coming soon) stating your interest! If you claim to be someone from NXT, I will double check with the NXT Forum account to make sure you haven't lied. If I catch you lying, you will be banned from the initial release, so be HONEST!
Bounties!!!Bounties will be given out in forms of percentages of initial share distribution which will be added to the 95,000 Stag given to every pre-registered account.
What is needed!- 1 Core Dev will be hired: +0.8%
1 Vector Logo. Something related to an actual stag (here is a picture if you don't know what a stag looks like http://funkman.org/animal/mammal/reddeerstag.jpg: +0.2% CLAIMED BY logocreator!- Founders Faucet: a faucet website that takes funds from Root Accounts that opt in to the faucet: +0.3%
- 7 operational public Stag nodes (from different users): +0.1% each
- 1 Stag Website Dev: +0.5%
- Stag Forums Dev: +0.5%
OPEN BETA IS HERE!Stag open beta is here! I have a public node with an open UI as well as a public node with a closed UI for it to exchange data with. So far, they have been sufficiently exchanging blocks and transactions with each-other so I am opening up the beta testing phase for public use.
What to do!Go to the URL listed in the "Where to go" section and create an account. Write down your password somewhere or save it to your computer. There is no need to worry about security as this is only beta and upon official release, all coins from beta WILL DISAPPEAR! Once you log in for the first time, you will be given a public key. Post your public key here along with the amount of STAG you want to use for testing. I will then send you some STAG using your public key! After that, play around and goof off! If you find a bug, please post it here!
What NOT to do!Don't use the password you used for beta for a real account when Stag is finally released as the server is set up for debugging and
I WILL see the passwords you used in beta! So please, don't tempt me by using a password you used for something else or using the same password for beta as you do for the initial release!
Also, don't report typos (yet)! This includes instances where something says "NXT" instead of "STAG." I will get to these later.
What to expect!Likely the biggest existing bug is the fact that when you try to make a transaction, you will see an error stating "Could not verify signature (Server Side)." Despite the error, the transaction IS excepted and will go through in the next block. This has something to do with the fact that you are logging in remotely (i.e. you are logging into Stag through something other than localhost). I am aware of this bug and will fix it, but it is not my highest priority as every day use of Stag will be done through localhost.
Another major bug is that forging crashes after 31 blocks due to too many data base connections. Until then, I will periodically reset Stag and will send out transactions to beta testers who have given me their information every reset.
Where to go!To help with Beta Testing, go here:
http://104.131.29.158:7826Known Bugs- "Could not verify signature (Server Side)"
- Number of confirmations don't update in on Dashboard
- "No blocks found" on Block page.
- Forging crashes after 31 blocks.
Stag and AnonymityI would like users of Stag to have as much privacy and freedom as possible. It is for that reason I have taken a break from development to investigate internet privacy techniques. After some thought, I have come up with some ways of increasing privacy for Stag users.
Key Pair ShiftingThis is something of my own design. I figured it would be much harder to track a user if their public and private keys change on a regular basis. So I came up with a design for doing just that.
The Stag wallet file will contain a set of private keys rather than just one. Each user will be allowed as many addresses as they want. They must, however, be aware that this takes up space on their computer's hardrive. These addresses are disposable much like Bitcoin addresses.
A transaction, rather then being made by sending coins from one account to another, is made by adding a 2 dimensional array to the address in question which contains a set of address and amount pairs. So the contents of that address are transferred to other addresses. In this way, an address almost works like a transaction. Once it is declared where the coins are going, the address becomes locked and no further changes to it can be made. It is because of this, the full amount of Stag associated with the address MUST be transfered to somewhere.
Now let's say someone's address contains 10 Stag and they only want to send 5 Stag to someone. The program will generate a public/private key pair (which means a new address) for the user. When the contents of the old Address are transfered, funds will be split between the address they are sending funds to and the new address they generated.
To prevent overlap of addresses and key pairs and to simplify the sending process, addresses will be assigned categories. The first category is the "Open Address" an Open Address can hold as much funds as it wants. There is no limit to how much it can hold. The remaining catgories are called "Locked" or "Fixed" Addresses. They can only contain one set amount or nothing at all. They will be split in binary fashion. There will be 1's Addresses, 2's addresses, 4's addresses, 8's addresses and so on and so forth. This limits the number of fixed addresses a person needs. Either they need 1 of a particular category or they don't need that category at all.
Another benefit of this is that it makes Stag divisible an infinate number of times because each address contains only a true false value (full or empty). It also allows for a near-infinate number of Stag to exist as it is not limited to the max size of a Big Integer or a Long but rather by 2 to the power of the max size of a BigInteger or a Long.
ZenSage's i2p + Tor + Encryption Server IntegrationI have been in contact with someone I only know as ZenSage. I met him through a NXT user. ZenSage is working on an advanced anonymity preservation method for browsing the net. Here is the basics of how it works:
The user requests a website. Their machine first sends out a request to a Database Server Eepsite through i2p and tells it the website the user wants, what encryption algorithm is to be used, and a unique request identifier. The website data and the encryption algorithm are both encrypted so that only a particular Encryption Server can decrypt them. This way the Database Server Eepsite doesn't even know what was requested. The request is sent through a pseudo unidirectional connection so the server doesn't even know who made the request.
Next, the user's machine builds a Tor cell with a randomly chosen Tor path. It sends this Tor cell and the first Tor node in the path through i2p to a specialized outproxy. A Tor cell is wrapped in layers of encryption so the outproxy doesn't know anything that could identify the requested website. The outproxy forwards this cell to the first node on the chosen path.
That node decrypts one layer which reveals the next node. The next node decrypts a layer which reveals the node after that, and so on until the cell reaches the exit node which decrypts the final layer that reveals the a web address and the IP of the outproxy.
The web address that the final node receives, rather than containing the website that the user requested, gets a web address to an Encryption Server containing an encrypted version of the unique request identifier. The exit node then opens up a stream to this web address.
The encryption server then makes a request through i2p to the Database Server Eepsite asking for the Unique Request Identifier it recieved from the Tor Exit Node. The Database Server Eepsite sends the requested url and encryption algorithm (which are encrypted) to the Encryption Server which decrypts the requests.
The Encryption Server then optionally opens a stream to the URL through i2p and Tor if they want to avoid harassment due to the potentially unsavory nature of the url's it retrieves for the user. Otherwise, it opens the stream directly to the URL (which would be faster).
The Encryption Server takes the data packets it receives from the URL as they come in and encrypts them so that only the user can decrypt them. It then returns this encrypted stream to the Tor Exit Node.
The Tor Exit Node receives the encrypted data stream and forwards it to the Outproxy. The Outproxy forwards the encrypted stream through i2p to the user's machine. The user's machine decrypts the stream and feeds it to the user.
Who Knows What In This System?- The user and their machine almost everything. Enough to compromise the user if their machine is hacked.
- The Encryption Server only knows the Unique Request Identifier. The URL and encryption algorithm the user requested are encrypted to they can't read the data.
- The Outproxy only knows something (ip address or i2p identifier?) which tells it how to send the data back to the user. If this is compromised, the User is possibly identified but what web address and what contents are still unknown. The user is still safe.
- The Tor Exit Node only knows the the IP address of the outproxy and the IP address of the Encryption Server. If it is compromised, a spy might know where to start looking for data on the user. This only lasts as long as the user is accessing the website, however; so, it would be very hard to identify the user with this as a starting point.
- The Encryption Server knows the IP Address of the Tor Exit Node, what url is being accessed, what exactly the url contains, and the Unique Request Identifier. If this is compromised, a spy would have potentially dangerous information about what the user is doing and have a starting point for where to look to find who the user is. However, like the Tor Exit Node, the ability to track the user only lasts as long as the user is connected.
Because of all this, it is safe to say that a potential spy would need to compromise the Encryption Server, the Tor Exit Node, the Outproxy, and anything inbetween the final connection the user has to the Outproxy (if there are indeed inbetweens) all within the time frame the user is connected. Add to this the fact that there are over 1000 possible Tor Exit Nodes currently in existence and that there may, potentially, be multiple encryption servers that the user could connect to. In short, things look pretty bad for a spy trying to get information on a user.
Why Integrate Stag With This System?The main reason is because with NXT, it is very possible for someone to identify the IP address of a particular account by collecting a large database of public nodes. From there, someone could identify what IP address is connected to what set of nodes. If they listen to all the public nodes, they can gather the NXT address associated with that IP address by determining which set of nodes they recieve the transaction from first. Doing this multiple times could result in the determination of the exact IP address a particular account is being accessed from.
Simply adding Tor to that doesn't help much either because someone could determine the source could still be bad because someone could monitor whenever a Tor Exit Node connects to a NXT public node and trace the connection back to the user's IP address.
Just i2p integration with Stag is better than just Tor but still not very good because within i2p, it is possible to identify which lease set is associated with a particular Stag account. i2p has yet to recieve much peer review and it may be possible to identify the IP of someone through their lease set.
Using the method described above, no one who knows anything that could possibly identfy the user can even know that the user is running Stag let alone associate their IP address with a particular Stag account/ID.
