Nope, still working on other projects to insure integration. Also, I have been brought on by SuperNet to work on turning a very complex price pegging algorithm into code. I plan to use the bounty for this to bring on some additional help to Stag and the anonymity network. (It is a very big bounty I am working towards).

Also looking into blockchain integrated wallet files for other coins. The idea is that, something like a Bitcoin wallet, could be stored on the Stag blockchain if it is encrypted well enough and allow a user to make Bitcoin transactions from within the Stag platform without depending on a pegged asset or MSCoin. Also looking into account pruning to increase the amount of time accounts can remain disposable given a particular key size. It would work by deleting accounts that have been inactive for very long periods of time (say 100 years) and allowing that account's public key to he reused.

Because a Stag user's balance is split into multiple disposable accounts (as is the new plan), it is considered highly improbable that anyone would hold onto a private key for 100+ years to steal an account's balance. Further, someone trying to steal this way would have to constantly monitor the blockchain to see if that account is deleted and reactivated, then log into the account AFTER it is created again but BEFORE the account's balance is spent.

Assuming this does happen, chances are that the account has very little Stag in it making all the key saving and patience near worthless. Further, the theft is only good once as the account will not be used again for another 50 years. This makes the gain from the theft worth less than the storage space and time spent storing the key and transferring it between computers. In the mean time, the stored key is likely to get lost or corrupted before the attacker can use it.

Finally, I am investigating possible methods of interpreting statistical data automatically to help with the price stability function. This would likely require a secondary proof of work block to be done every so many blocks. This PoW would be the work of building an equation to match statistical data from cryptocurrency exchanges to determine the ideal amount of STAG per account by comparing the purchasing power of the previous ideal amount of STAG per person in LPPI (Local Purchasing Power Index) to the average cost of living in first world countries in LPPI doubled. This way there is enough STAG  per person to support 2 adults.

These are mostly just thoughts at this point. Let me know what you guys think!

Just wanted to let everyone know that I am still alive and haven't given up yet. Production is on hold for a little bit though. I am working on developing the anonymity network with ZenSage first because Stag will involve heavy integration into his combined i2p/Tor network. I cannot do much with Stag until this is complete and I have the proper API. That is why you haven't heard much from me lately

Further, sStag will go through a sort of rollback in the code once I do pick up production. The Devs at NXT have been busy releasing a lot of new features and optimizing their code. I want to include the latest features in Stag (such as regex transaction message parsing verifying the sender of a message and issuing Monetary System coins on top of Stag). This will, of course happen when the anonymity network is ready to be integrated.

Thank you all in advance for your patience and understanding!

Hey everyone! Just wanted everyone to know that I am still around! I have been in contact with a nameless dev working on an advanced anonymity network combining Tor, i2p, and advanced encryption techniques to make it really difficult to track users. He/she has been giving me information and code for it so I have been considering integrating Stag into it to protect Stag users from unwanted spying.

Does this sound like a good idea to people?

Just got this link from a friend: http://gas.dia.unisa.it/projects/jlbc/schemes/bgv11.html

It is based on RLWE encryption angorythms. If I can somehow get the code to go open source, I can use it in Stag so that it will continue to be safe even after the release of quantum computing...

EDIT: Ah ha! It is open source... Just found the repository. Will be implementing it instead of sha256.

EDIT 2: Hmmm.. This encryption algorythm seems to take an awful long time to execute even with the most basic settings. In other words... Public/private key generation will take a while. I wonder if there is any way to speed up the process by providing fixed numbers rather than relying on a generator to come up with a prime number for me...

Edit 3: it took some searching, but I finally found a list of prime numbers that contains a large number of 64 bit primes. This is promising. It contains the first  1.4 billion prime numbers.

I wanted to release before the new year but if I chose to implement a Sending/Recieving address system to up privacy, it will take longer...

Sorry guys... Beta is down right now. I have some more debugging to do for the new beta. There was trouble verifying transactions from other nodes and I have been particularly busy so I haven't gotten a chance to work on it much. I will have plenty of free time soon though.

Thank you all for your patience!

EDIT: I will be making a new system for transaction storage to minimize the amount of space every transaction takes up in the database. It will implement alias transactions and all new accounts will get one free alias upon creation. The free aliases will start as purely numeric and will be made to be as short as possible so that they are easier to remember.

Transactions sent to an alias will take on three forms...

• Numeric: transactions sent to these aliases will be stored using the alias rather than the account ID. They will store the data as the smallest MYSQL data type possible. Values 0, or 1 will be stored as a BIT and -1 will be stored as a null BIT. Values less than -1 and greater than 1 between -128 and 127 will be saved as a TINYINT with 128 being a null TINYINT. So on and so forth for each data type. This type of transaction will be indicated by a null BIT.
• String Aliases shorter than than the length of an account ID or longer/equal ending with a number between -128 and 127: these will be saved as a character array that makes up the string alias and a byte or null if it is shorter than the length of an account ID. This will be indicated by a BIT equal to 0 In the database.
• For String Aliases that do not match the requirements of the above specification: these will be converted into the standard RS account ID saved as a BIT array which encodes to the RS account ID.

Numeric account IDs will be completely done away with. The reasoning for this is that they are only 8 bytes (64 bits) in length so there is a relatively high possibility of two passwords making the same numeric account ID which is the whole reason for public keys and public key announcements in NXT.

Stag will do away with these in favor of simply using longer RS ids (I haven't decided on a size yet) and using aliases as addresses. It will work similar to Bitcoin. Public keys will exist but it is not necessary to share them on the blockchain.

Instead, there will be a wallet file created the first time Stag is run. The account RS ID will be derived from the wallet file bytes hashed with the user's password hashed with the private key. In order to get the funds from an account you need the wallet file, the password, and the private key of the account. This decreases the chance of two passwords leading to the same account and may increase privacy (I will have to do more research).

EDIT 2: OK. I think I have come up with an idea for increasing privacy through this method. The wallet file will contain a number of private passwords... These passwords are used to generate new addresses sort of the same way Bitcoin has multiple addresses.

There will be two types of addresses, sending addresses and recieving addresses. Sending addresses are used only when sending out a transaction, they are used as a way of identifying where a transaction came from. An account has only one of these, but it changes every block. This is where brother rewards go.

Recieving addresses are permenent and every account may have as many of these as they like. They forge and block rewards are sent to them...

In a transaction, a sending address claims a particular recieving address with a special code and forwards its funds to one or more recieving addresses. Brother rewards are handled differently. They first go to a sending address, that sending address which holds the Brother Reward and forges with it. It will be the last of the accounts claimed by a future sending address.

This is ONLY speculation though. I have to think more about the benefits and pitfalls of a system like this.

Oops, forgot about that in the big update. Fixed now. I also figured out what was going on with the nodes not connecting. I made a typo when adding their data to the database. It should be working well now.

And I forgot to change the peer requests in the blockchain processor so that new blocks don't go through. One more bug to fix today sigh.

It took some tweaking, but I finally got it working, there was an error processing peer transactions so the two nodes blacklisted each other. I fixed it now and spent most of my day doing something I said I wasn't going to do... That is, debugging the new version of Stag...

---

The latest version of Stag Beta is now on the public node you guys are used to by now! This Version utilizes NXT 1.3.4 at its core and offers new features such as searching the marketplace for tags, description text, and title. It also has a slicker design.

It also offers a modified version of transaction sorting/execution that won't be included until NXT 1.4.0.

This method sorts unconfirmed transactions first in ascending order of height where new blocks have a height on Integer.MAX_VALUE and blocks that have been attached to a block and popped off have the height of the last block they were attached to. Next, they are sorted by TX fee per TX byte in descending order. Next they are sorted by a Bit value in descending order where the value is 1 if the transaction sender is logged into that node and 0 if they are not. After that, they are sorted in ascending order of their arrival timestamp. This is a marker indicating when the unconfirmed transaction arrived at the node forging the block. Next, they are sorted in descending order by the amount of NXT being transfered in the transaction because I am assuming that the more NXT that is transfered, the more important the transaction is. Finally, it defaults to sorting the blocks by transaction ID.

Transactions are executed and stored in the block by the arrival timestamp at the forger's node in ascending order, the height of the transaction in ascending order, and finally by transaction ID in ascending order.

As I mentioned before, I don't have time to look for bugs today so I am counting on all of you to do a good job for me!

I have some good news and some not so good news. The good news is that the new update is forging just fine and I will update the node tomorrow with the latest version. The not so good news is that is all I will be able to accomplish tomorrow as I have other obligations to attend to.

Ah. So I am inches away from being able to send out the new version. With it will be another blockchain reset. Hopefully I can send it out by tomorrow.

That is weird, because I haven't sent out the update yet.

Working on overhauling Stag with the latest version of NXT.

Just updated the post above. It is another issue related to the remote client.

Hmmm, the could not verify signature server side is something I thought I fixed. Anyone else getting this error?

EDIT: I tested this on the local client and it worked fine. Must just be an issue with remote client access. Also, a minor announcement: I will be upgrading the UI to the latest NXT UI (mostly because it is nicer and allows you to search the marketplace easily). There will likely be new bugs after this update so be ready for a whole slew of new issues!

Yes, I have just been busy and haven't gotten a chance to update the list yet.  :/

---

A list of test accounts being used for this round of Beta. Provided for your convenience (and mine)!

• STAG-DNPP-7TLC-2N46-3YSAW
• STAG-9EEN-HNVB-CLEB-D7DAP
• STAG-U5AP-4LHD-N9VM-8HVZ7
• STAG-S89B-3V9C-GHV9-5KTGV
• STAG-EA2P-84PJ-PUWB-GC6DU
• STAG-K96U-N3NP-4ZWG-4R7YT
• STAG-YD9L-4REU-TRE9-DUSDZ
• GENESIS: STAG-GA2D-C6RL-JDEG-CW2RU

Wow! Lots of people still interested in beta! Looks like I have to send out some funds!

EDIT: Sent out funds for beta testing!

---

The Beta Update has happened! If you are still interested in helping me test, please send me a PM with your account ID and public key again. I don't want to do a bunch of transactions for people who aren't testing anymore.