New answers tagged security
1
Many bad things may happen, here is incomplete list of them:
Anybody may sign transactions/messages with your private keys as long as you unlock them
Anybody may use resources of your node to query blockchain state (some queries could be very CPU and HDD intensive)
Anybody may use resources of your node to publish large amounts of transactions, i.e. when ...
0
eth-crypto provides cryptographic JavaScript functions, such as encrypting data with the public key and decrypting it with the private key.
0
Since solidity v0.5.0 it is not necessary anymore. From the changelog:
Code Generator: Revert at runtime if calldata is too short or points out of bounds. This is done inside the ABI decoder and therefore also applies to abi.decode().
Executing a function with less than required makes the transaction fail. Although you can send more data and it work, the ...
0
Thank you both for your answers and sorry for my late answer.
What I have done are two security measurements.
1. Double Password
The first measurement/change I have added is not relying on one single cleartext password function. When I or a bad actor enter the password for phase 1, the entering of the cleartext password will be blocked for 2 hours and the ...
0
If I'm reading the question right, you're concerned with the clear password getting grabbed before it's mined, then used by an attacker with more gas. If so, this is a rephrasing of the frontrunning problem (here's a link to how it's described on Ethereum's wiki). Zero-Knowledge proofs are an option, but may be overkill. Let's explore some other options.
...
0
"known transaction" means that both transaction are exactly the same. You might try changing value so they are different.
If all your nodes are running on the same lan and all of them are connected between them it is very likely they will propagate the transactions quickly. An quick and dirty way to test this is to keep the nodes isolated, for example by ...
0
In your case if you run the execution multiple times you'll get different results depending on which node receives and processes your transaction faster.
That being said, nodes are supposed to be prepared to reach consensus, which implies discarding those transactions that would produce a double spend, which is definitely positive.
If you think that's ...
0
does anyone have any suggestions of how to build in user logins and security
One of the hard paradigm-shifts for newcomers to get over is the idea that users don't register at all, at least they shouldn't.
The most secure thing you can do is rely upon msg.sender to authenticate the user who has signed with a private key. You can collect and record ...
1
Transactions don't have any knowledge about which block they will end up in. A transaction is basically valid forever. Of course there are reasons why it might not be valid anymore when it gets broadcast but that is only noticed when nodes try to execute it, such as:
1) The sending account has too little Ether
2) The contract you try to interact with has ...
Top 50 recent answers are included
