Topic: [ANN] Stag! | Stagflation crypto based on NXT! | OPEN BETA (Down for testing)! - page 3. (Read 49381 times)

I think it's good idea. Takes your time and Merry christmas stag.

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?

Don't stress guys !

i want to be part of the initial pre-registration.
Thanks.

I was in that list too. i hope i still are in it!!

This look very promising when you check how much time and work the dev has put in this.

I signed up for initial distribution at the very start, there was a list and now it seems to be gone... Please honor the Original list when STAG release comes about 

I think dev is preparing the list or so. Till now everything testing went as normal as to be.

No for the moment.Wait for the list.

initial distribution soon?

Hello stag some news ?

Add me to the pre-register list as well.

I want to pre-register.
It looks to be a nice project

Had to check it thru after your post, but you are right: not much fudders around!

thread looks so clean

Nice to see that there are still devs that really put work in to their projects.

Good job!

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.

Thanks for updates. We will wait to have some whenever it goes live.

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...

Thanks for the update, Dev!

Can't wait this to launch. Do you have any launch date on your mind?

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.