Exactly what I want is this:
I'm transferring money to a contract. The money coming into this contract will be forwarded to the destination address without creating any TXN (that is, anonymously).
I created a contract and the money sent to this contract is sent to the target wallet. In this way, information does not appear in Transaction transactions of the target wallet.
the code i use
receive() external payable {
payable(0x8162Ac860EF729d60C0f3683bfaA0334A3499956).send(msg.value);
}
As pictured (see Transactions)
https://i.stack.imgur.com/OPxH5.png
So far everything is ok. But there is one problem. Transaction appears in Internal TXNs. I want to hide this.
https://i.stack.imgur.com/39nCh.png
What should happen: Money will be transferred to the contract and it will transfer money anonymously without generating any TX belonging to the target wallet.
REQUIRE --->> When the money sent to the contract is sent to the counter wallet, no information will appear in the Transactions and Internal TXNs tab of the counter wallet.
Is it possible to do this? Please tell me what should I do if
possible.
No, this is not possible. Any transfer of a native chain token (BNB in your case of Binance Smart Chain) will appear on an explorer like Etherscan (Bscscan) as an "internal transaction".
Related
am am learning about transfer and send in solidity, and the fallback function. To my understanding, when you send ether to a smart contract, you also send some gas to the fallback function as well. Why is this mechanism in place? I thought gas was used to pay validators, how come there is gas now stored in the contract + what is this gas in the contract used for now? Thanks
Each operation costs some predefined amount of gas. The combined amount - no matter how many internal transactions are performed within the main transaction - is always paid by the main transaction sender.
The transfer() function (in the current Solidity version 0.8) allows the called address to spend only 2300 gas, preventing the reentrancy attack.
This amount is enough to emit an event but it's not sufficient to perform another call - for example back to the caller contract, that would allow for the reentrancy attack.
So to answer your original question:
what can you do with the gas that is sent to a fall back function
From the called contract perspective: You can only spend it to perform few basic operations such as to emit an event. But you cannot sell it back to ETH and store it in the called contract, nor call another contract (including the sender).
contract Called {
event Received(uint256 amount);
fallback() external payable {
// ok
emit Received(msg.value);
// fail - costs more than the 2300 limit
msg.sender.call("");
}
}
I follow this instruction to call smart contracts from DeBot using the message argument in the Surf URI:
https://tonlabs.notion.site/For-developers-f347bd4095f74c9d9e2bd313c666905d
It works ok, but it produces external messages. My guess is that the difference is in headers. How should I modify them to send an internal message using the same scheme?
DeBot cannot send internal message.
DeBot have 3 special features:
calling — get-methods of target smart contracts;
calling — external functions of target smart contracts onchain;
invoking — other DeBot in a local environment.
See DeBot Special Features for more details.
Yes, DeBots themselves cannot do it, so people do the following trick:
Pack debot method arguments into payload:
https://github.com/tonlabs/debots/blob/d8111db9eb5d8c42a362a0d34a4dea38f6789eec/accman/AccMan.sol#L257
Run sendTransction with the address of the current DeBot (to) and the address of a wallet (from). The wallet aka smart contract must obviously have sendTransction.
The external message is received by the wallet, and the multisig sends an internal message to the method in payload.
Once the DeBot receives this internal message, it can tunnel them to other smart contracts.
The step can be simplified, so that sendTransction is sent directly to the smart contract which requires internal message by providing the correct payload parameters (method name and params).
I think previous answers are indeed "best practice", but still incorrect. Of course, you CAN make internal messages without any additional Msig. DeBot is a smart-contract too. You just have to do the call like this:
address myDebotAddr = address(this);
IMyDebot(myDebotAddr).myFunction{...}( ... );
DeBot will call his own contract that lies in blockchain. Then in the function myFunction() you should:
have tvm.accept();
do the internal call that you need
Thus the execution of myFunction() will happen in blockchain, not locally.
Still, you will have to add funds to debot balance. So, it's not a "best practice" for widely used DeBots.
i have the code in solidity, i'm wondering something: I deploy code for the 0x583... first, i send 1 eth to another account. Before i click withdrawAllMoney, i click destroySmartContract, 1 eth 's automatically send to receiver (this is okie!). But after that, i keep going send the 1 eth from 0x583.. to another account, it still take out eth from 0x583.. but the orther can't receive it.
I'm wondering: when i call the selfdistruct, is the contract real deleted (can't send or recieved...)
Thank you!
when i call the selfdistruct, is the contract real deleted (can't send or recieved...)
selfdestruct() effectively removes the deployed bytecode from the contract address.
In the next block, this (former contract) address will act as a regular address without a smart contract, so it is able to receive tokens and ETH.
But, since it doesn't hold any bytecode anymore, you won't be able to interact with the contract (it's not there anymore).
I have changed the contract from the drop down menu whether I deploy wrong contract unfortunately its still not showing. I also increased the gas fees. I have tried severally by using different browser and I also used http and https all to no avail
This is one of the transaction hash of the token I created below:
0xbe8e45ca80fae1de52f60addeae7dbdf0ae75778a3e29f185aa628b7faa0bd7f
The transaction shows up correctly on the testnet BSCScan: https://testnet.bscscan.com/tx/0xbe8e45ca80fae1de52f60addeae7dbdf0ae75778a3e29f185aa628b7faa0bd7f
BSCScan distinguishes between the testnet and the mainnet. So a transaction that exists only on testnet, will not show on the mainnet explorer.
I'm working on a project which we need to handle iso8583 messages, I'm not much sure about the difference between authorization request and authorization advice request why these are implemented and what are the use cases of these messages, thank you
Both messages are very similar over the wire, but represent different things. The authorization is a request from the client (POS, ATM, etc.) to authorize a transaction and lock funds. The advice is a notification sent by the client about something that already happened.
In the old days where a POS might not have a proper connection to the host, the operator could for instance call an authorization center by phone in order to get an approval number and then enter an OFFLINE transaction in the POS. That transaction is later sent by the POS as an "advice" to the host so that it gets included in the transaction batch.
In a gas pump transaction, you may send an authorization for say USD 100, then after the user fills its tank, the pump will send an "advice" for say USD 25 (the actual amount), releasing USD 75 from the locked funds.
Hope those examples helps.