Quote from: Stag on December 09, 2014, 08:04:54 PM

Quote from: MadCow on December 07, 2014, 06:04:50 AM

Quote from: romawi on December 06, 2014, 05:51:20 AM

Quote from: Stag on December 06, 2014, 01:43:44 AM

Quote from: romawi on December 05, 2014, 12:12:57 PM

Every action ends with "Could not verify signature (server side)".

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.

Failed to connect

http://104.131.29.158:7826

Same for me too

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.

Thanks for the update, Dev!

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