Someone sold this old ERC20 Theta Tokens (on 0x3883f5e181fccaF8410FA61e12b59BAd963fb645) to me on Ethereum so I transferred the Bitcoin value to the sender. I then checked the value on Etherscan it was ok but when I tried to swap at Uniswap or SushiSwap, the error I got was: "Insufficient liquidity for this trade.".
What can I do now or just conclude it's worthless?
Related
I am reading bep 5 and trying to understand how a token value is generated. As I understand the token value is a randomly generated value that is used in a get_peers query for safety. This same token value would then be used in an announced_peers query to see if the same IP previously requested the same Infohash.
My question is how is this value generated exactly? It says something about an unspecified implementation - does this mean I can implement it myself (for example by using the SHA-1 value)?
I tried looking at other beps but couldn't find anything about specific rules for generating a token value, found nothing.
The token represents a write permission so that the other node may follow up with an announce request carrying that write permission.
Since the write permission is specific to an individual node providing the token it is not necessary to specify how it keeps track of valid write permissions, as there needs to be no agreement between nodes how the implementation works. For everyone else the token is just an opaque sequence of bytes, essentially a key.
Possible implementations are
(stateful) keep a hashmap mapping from supplied tokens to their expiration time and which remote IP it is valid for.
(stateless) hash a secret the remote ip, remote id and a validity-time-window-counter. then truncate the hash. bump the counter on a timer. when verifying check with the current and the previous counter.
Since a token is only valid for a few minutes and a node should also have a spam throttle it doesn't need to be high strength, just enough bits to make it impossible to brute-force. 6-8 bytes is generally enough for that purpose.
The underlying goal is to hand out a space-efficient, time-limited write permission to individual nodes in a way that other nodes can't forge.
IF, someone was able to retrieve the intentionally lost information from the SHA function by finding a vulnerability in the loose compression of data & able to get the input of every SHA256 output & verify a block that does not belong in the main BTC network, can't it be used to create a fake dust transaction and manually verify that transaction? - Ultimately creating an unlimited BTC in seconds?
Be aware that for a given SHA256 output there may be several inputs that result to the given SHA256 output.
AFAIK Bitcoin strongly relies on not being able to reverse SHA256 function. So without talking about faking blocks or making dust transactions, if you are able to reverse the SHA256, then you can instantly mine Bitcoin blocks making you reward all the remaining bitcoins not yet mined. However if such an extreme miner appeared, he would be spotted by the whole network and so the value of bitcoins would be lost as the network isn't working as it was designed.
I am trying to find out how to allow multiple transactions on ethereum block chain by simply approving once on meta mask.
My use case is to make a portfolio management system.
for example consider:
token ------------ before ---- after
eth 10$ 20$
usdt 20$ 10$
btc 20$ 50$
old_coin 50$ 0$
new_coin 0$ 20$
result ============> |after-before== |result
------------------------------------
eth |20-10 |+10 (buy)
usdt |10-20 |-10 (sell)
btc |50-20 |+30 (buy)
old_coin |00-50 |-50 (sell)
new_coin |20-00 |+20 (buy)
Now i want to send all this transactions:
buy eth worth 10$,
sell usdt worth 10$,
buy btc worth 30$,
sell old_coin worth 50$,
buy new_coin worth 50$.
If any one can help me please let me know,
Thank You for your time...
First, you need to write your smart contract into one function call you mentioned above and deploy it. Then approve all tokens for max allowance (or upper limit) that you will be using to your smart contract address. Finally, call your smart contract function (you can do it thru REMIX IDE after you successfully deployed)
I'm a beginner Rust/Solana Developer and wanted to ask if someone knows how to send a spl-token from an account when the account receives a SOL?
I read the https://docs.solana.com/ but i could not find anything about SPL transfers.
Example of Smart Contract: https://github.com/solana-labs/example-helloworld
Example:
Acc1 sends 0.1 SOL to a address and for that Acc1 receives 1 SPL-TOKEN from that address.
Simple explanation: I need a minting website for a token.
I would really appreciate some help, thanks!
You can send SPL-Tokens by using CPI on the token program's transfer instruction.
For example:
spl_token::instruction::transfer(
token_program.key,
source.key,
destination.key,
authority.key,
&[],
amount,
)?;
invoke_signed(
&ix,
&[source, destination, authority, token_program],
signers,
)
You can find a more in depth example by looking at how the token-swap program uses CPI to transfer spl-tokens
I'm developing own protocol for secure message exchanging.
Each message contains the following fields: HMAC, time, salt, and message itself. HMAC is computed over all other fields using known secret key.
Protocol should protect against reply attack. On large time interval "time" record protects against replay attack (both sides should have synchronized clocks). But for protection against replay attack on short time intervals (clocks are not too accurate) I'm planning replace "salt" field with counter increasing every time, when new message is send. Receiving party will throw away messages with counter value less or equal to the previous message counter.
What I'm doing wrong?
Initial counter value can be different (I can use party identifier as initial value), but it will be known to the attacker (party identifier transmitted in unencrypted form).
(https://security.stackexchange.com/questions/8246/what-is-a-good-enough-salt-for-a-saltedhash)
But attacker can precompute rainbow tables for counter+1, counter+2, counter+3... if I will not use really random salt?
I'm not certain of your design and requirements, so some of this may be off base; hopefully some of it is also useful.
First, I'm having a little trouble understanding the attack; I'm probably just missing something. Alice sends a message to Bob that includes a counter, a payload, and an HMAC of (counter||payload). Eve intercepts and replays the message. Bob has seen that one, so he throws it away. Eve tries to compute a new message with counter+1, but she is unable to compute the HMAC for this message (since the counter is different), so Bob throws it away. As long as there is a secret available, Eve should never be able to forge a message, and replaying a message does nothing.
So what is the "known secret key?" Is this key known to the attacker? (And if it is, then he can trivially forge messages, so the HMAC isn't helpful.) Since you note that you have DH, are you using that to negotiate a key?
Assuming I'm missing the attack, thinking through the rest of your question: If you have a shared secret, why not use that to encrypt the message, or at least the time+counter? By encrypting the time and counter together, a rainbow table should be impractical.
If there is some shared secret, but you don't have the processor available to encrypt, you could still do something like MD5(secret+counter) to prevent an attacker guessing ahead (you must already have MD5 available for your HMAC-MD5).
I have attacked this problem before with no shared secret and no DH. In that case, the embedded device needed a per-device public/private keypair (ideally installed during manufacturing, but it can be computed during first power-on and stored in nonvolatile memory; randomness is hard, one option is to let the server provide a random number service; if you have any piece of unique non-public information on the chip, like a serial number, that can be used to seed your key, too. Worst case, you can use your MAC plus the time plus as much entropy as you can scrounge from the network.)
With a public/private key in place, rather than using HMAC, the device just signs its messages, sending its public key to the server in its first message. The public key becomes the identifier of the device. The nice thing about this approach is that there is no negotiation phase. The device can just start talking, and if the server has never heard of this public key, it creates a new record.
There's a small denial-of-service problem here, because attackers could fill your database with junk. The best solution to that is to generate the keys during manufacturing, and immediately insert the public keys into your database. That's impractical for some contract manufacturers. So you can resort to including a shared secret that the device can use to authenticate itself to the server the first time. That's weak, but probably sufficient for the vast majority of cases.