Closed karmacoma closed 7 years ago
I also can't vote.
Can you provide some more detail about this? Are you using login.lisk.io for this or your own server? is it behind an nginx node? @vrlc92
Root cause for this issue is related to the way we handle transactions and public keys
$http.post("/api/accounts/open/", { secret: pass })
.then(function (resp) {
if (resp.data.success) {
userService.setData(resp.data.account.address, resp.data.account.publicKey, resp.data.account.balance, resp.data.account.unconfirmedBalance, resp.data.account.effectiveBalance); <<<<<<<<<< We assign publicKey based on the return of /api/accounts/open - This is null on every new account
userService.setForging(resp.data.account.forging);
userService.setSecondPassphrase(resp.data.account.secondSignature || resp.data.account.unconfirmedSignature);
userService.unconfirmedPassphrase = resp.data.account.unconfirmedSignature;
if (remember) {
userService.setSessionPassphrase(pass);
}
$state.go('main.dashboard');
} else {
$scope.errorMessage = resp.data.error;
}
});
Wallets without a publickey assigned to them will have a null publickey
lisk_main=# select address,"publicKey", balance from mem_accounts where address = '10776522510235196105L';
address | publicKey | balance
-----------------------+-----------+-----------
10776522510235196105L | | 100000000
In order for these wallets to get a publickey a transaction needs to be signed and broadcast out to the block chain. The U_TX will cause a public key to be inserted into mem_accounts.
Now when logging in the wallet will have a public key after any transaction is made
lisk_main=# select address,"publicKey", balance from mem_accounts where address = '10776522510235196105L';
address | publicKey | balance
-----------------------+--------------------------------------------------------------------+----------
10776522510235196105L | \x0dc13eafe5c2d3e46c14faad4de8533a24ba9438afe404902bcfc812760e322b | 90000000
(1 row)
The roadblock comes in when all of our transations rely on having this data
evidence is on this line of publicKey requirement:
$scope.sendTransaction = function (secretPhrase, withSecond) {
if ($scope.secondPassphrase && !withSecond) {
$scope.checkSecondPass = true;
$scope.focus = 'secondPhrase';
return;
}
$scope.errorMessage = {};
var data = {
secret: secretPhrase,
amount: $scope.convertLISK($scope.amount),
recipientId: $scope.to,
publicKey: userService.publicKey <<<<<<<<<< Heres where we ask the userService for the public key that was assigned on login.
};
if ($scope.secondPassphrase) {
data.secondSecret = $scope.secondPhrase;
if ($scope.rememberedPassphrase) {
data.secret = $scope.rememberedPassphrase;
}
}
if (!$scope.sending) {
$scope.sending = true;
$http.put('/api/transactions', data).then(function (resp) { <<<<<<<<< Heres the troublesome API end point that relies on public key
$scope.sending = false;
if (resp.data.error) {
Materialize.toast('Transaction error', 3000, 'red white-text');
$scope.errorMessage.fromServer = resp.data.error;
} else {
if ($scope.destroy) {
$scope.destroy();
}
Materialize.toast('Transaction sent', 3000, 'green white-text');
sendTransactionModal.deactivate();
}
});
}
}
the reason being we have null data and our type checking is only looking for strings. We have a few options here:
@Isabello:
As the public key is an optional parameter, perhaps the best solution is just to remove it when it has a null value.
Lisk nano for example doesn't send the publicKey, so the same problem does not occur. https://github.com/LiskHQ/lisk-nano/blob/development/src/app/services/peers/peer.js#L122
@Isabello
My guess
An account is registered in blockchain when its address is the sender or recipient of a transaction.
When its address is: Sender: the publicKey is recorded Recipient: the publicKey isn't recorded
Publickeys are generated upon the first transaction sent by a secret key. The root cause is the way we pull data from api and the null value publickey has until this first sending transaction.
On Oct 27, 2016 18:31, "Victor" notifications@github.com wrote:
@Isabello https://github.com/Isabello
My guess
An account is registered in blockchain when its address is the sender or recipient of a transaction.
When its address is: Sender: the publicKey is recorded Recipient: the publicKey isn't recorded
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/LiskHQ/lisk-ui/issues/75#issuecomment-256798857, or mute the thread https://github.com/notifications/unsubscribe-auth/APzFsBBI49OJP_D7TBk9YhmXa7pmwKzQks5q4TRtgaJpZM4KVywG .
Thank you @Isabello. Closing here, and resolving in original issue: https://github.com/LiskHQ/lisk/issues/293, using your pull request.
Moved from: https://github.com/LiskHQ/lisk/issues/293.