mirror of
https://github.com/Qortal/qortal.git
synced 2025-03-30 09:05:52 +00:00
2c51a0362b
ATData no longer needs deploySignature as a link back to DeployATTransaction, but does need creator and creation [timestamp]. "creation" is critical for ordering ATs when creating/validating blocks. Similar changes to ATStateData, adding creation, stateHash (for quicker comparison with blocks received over the network), and fees incurred by running AT on that block. Also added more explicit constructors for different scenarios. BlockData upgraded from simplistic "atBytes" to use ATStateData (above) which has details on ATs run for that block, fees incurred, and a hash of the AT's state. atCount added to keep track of how many ATs ran. ATTransactions essentially reuse the GenesisAccount's publickey as creator/sender as they're brought into existence by the Qora code rather than an end user. ATTransactionData updated to reflect this and the AT's address used as a "sender" field. Account tidied up with respect to CIYAM ATs and setConfirmedBalance ensures there is a corresponding record in Accounts (DB table). Account, and subclasses, don't need "throws DataException" on constructor any more. Fixed bug in Asset Order matching where the matching engine would give up after first potential match instead of trying others. Lots more work on CIYAM AT, albeit mainly blind importing of old v1 ATs from static JSON file as they're all dead and new v2 implementation is not backwards compatible. More work on Blocks, mostly AT stuff, but also fork-based corruption prevention using fix from Qora v1. Payment-related transactions (multipayment, etc.) always expect/use non-null (albeit maybe empty) list of PaymentData when validating, processing or orphaning. Mainly a change in HSQLDBTransactionRepository.getPayments() Payment.isValid(byte[], PaymentData, BigDecimal, boolean isZeroAmountValid) didn't pass on isZeroAmountValid to called method - whoops! Lots of work on ATTransactions themselves. MessageTransactions incorrectly assumed the optional payment was always in Qora. Now fixed to use the transaction's provided assetId. Mass of fixes/additions to HSQLDBATRepository, especially fixing incorrect reference to Assets DB table! In HSQLDBDatabaseUpdates, bump QoraAmount type from DECIMAL(19,8) to DECIMAL(27,8) to allow for huge asset quantities. You WILL have to rebuild your database!
41 lines
863 B
Java
41 lines
863 B
Java
package qora.account;
|
|
|
|
import qora.crypto.Crypto;
|
|
import qora.crypto.Ed25519;
|
|
import repository.Repository;
|
|
|
|
public class PublicKeyAccount extends Account {
|
|
|
|
protected byte[] publicKey;
|
|
|
|
public PublicKeyAccount(Repository repository, byte[] publicKey) {
|
|
super(repository, Crypto.toAddress(publicKey));
|
|
|
|
this.publicKey = publicKey;
|
|
}
|
|
|
|
protected PublicKeyAccount() {
|
|
}
|
|
|
|
public byte[] getPublicKey() {
|
|
return publicKey;
|
|
}
|
|
|
|
public boolean verify(byte[] signature, byte[] message) {
|
|
return PublicKeyAccount.verify(this.publicKey, signature, message);
|
|
}
|
|
|
|
public static boolean verify(byte[] publicKey, byte[] signature, byte[] message) {
|
|
try {
|
|
return Ed25519.verify(signature, message, publicKey);
|
|
} catch (Exception e) {
|
|
return false;
|
|
}
|
|
}
|
|
|
|
public static String getAddress(byte[] publicKey) {
|
|
return Crypto.toAddress(publicKey);
|
|
}
|
|
|
|
}
|