Your only way to 'cancel' it (in terms of the BTC stay where they are) is to double spend them.

Unfortunately that's not that easy. But if you have the RBF (Replace by fee) tag set (depends on the settings of electrum; it is set by default), you can simply create a second transaction spending the same outputs to one of your addresses, with a higher fee to have them 'stay at your wallet'.

However, a real 'cancellation' is not possible.


Do you explicitly want to cancel it or do you want to make it go trough ? Or doesn't it matter at all ?
Because, if you wait a few hours/days, your transaction (most probably) will go trough.

You can either use pywallet (but please ONLY on a copy of your wallet file) or simply download/install core and export the private keys.

Then import these private keys into a lightweight client (e.g. electrum).

Or, if you only want to check the balance: Import your wallet into core and look all the addresses up in a block explorer (e.g. https://blockchair.com/ or https://www.blockchain.com/).

Electrum (as any other desktop wallet) is as safe as your computer is.

If you are browsing shady sites, downloading cracked software or running a cracked OS, chances are VERY high that your computer is infected.
Any (non-hardware) wallet would be not safe on your PC then.

However, if you have everything up-to-date, a good AV and use lot of common sense, your PC is probably clean and relatively(!) safe.


Electrum is free. And this is the ONLY official site to download it from: https://electrum.org/#home.
Make sure to verify the signature (or AT LEAST verify the hashsum of the file) to make sure you have downloaded the original version. There are quite a lot guides on the internet about verifying electrum downloads.
The process heavily depends on the OS you are using.

IF sha256 would be broken (that's a very big IF), someone would either publish a paper stating that (for the public appreciation and/or a bounty).

Note that 'broken' means that a collision has been found. There are 2 types of collisions.

One where the final hash is given and you need to find a second input which generates the same hash (severe) and
one where you randomly take 2 inputs and find the same hash (more probable, way less severe).

Yet not a single collision has been found. Also, a collision of the 2nd type wouldn't mean shit since this can't be abused.

A lot more technologies / protocols / applications would have a big problem if a collision of the 1st type would be possible. Not only bitcoin.


In such a case, BTC would have to fork off to another algorithm (e.g. sha512).




Yes, double sha256 will be still safer than single sha256 but would become 'broken' too.

Are you in control of the 'withdrawal address' ?

What wallet do you use? Who did choose this 'withdrawal address' ?

If this address does NOT belong to you, you can't access to these BTC.
If this address IS yours, you can access it by using the wallet it belongs to (which wallet(s) are/were you using ?).

I believe changing the current email to another one, then creating a new account with the old email should work.

But don't quote me on this. I am not completely sure about this.

Transaction malleability doesn't influence the scenario and the outcome of the transaction.

What transaction malleability basically is, is that you can take a broadcasted transaction and change a 'value' (not possible to change receipent/amount/fee) to generate a new hash ('basically same' transaction, just a different hash).

This is a problem for not-that-good coded exchanges which rely on the transaction hashes when withdrawing funds.


But this doesn't have any influence in this scenario since it doesn't change anything important.

You already have received replies in your other thread (which is an exact copy).

Did you read the replies ?


Even though the other thread is in the wrong sub, there is no need to create a new one. You can simply move your old thread into the correct sub (bottom left corner -> move topic).

This mostly depends on the wallet you are using.

Most wallets do have a 'send' field for the exact amount the recipient should get and an additional field called 'fee', where you can set the fee (either total in BTC or fee rate in sat/B).
The wallet should calculate the rest itself.

What wallet are you using ?

You can't lose coins in electrum.

Start with some basic information:

• Electrum version?
• Operating System?
• What EXACTLY happened?
• What should have happened?

Without this information AT LEAST we can't help you at all.

Why don't you simply use a mixer yourself for a few transaction?

That's probably the best way to have full control over the whole process.

Different mixers use different techniques to tumble the coins. ChipMixer for example has a very unique system where you get 'preloaded' private keys.
This basically gives you outputs which are older than your transaction. This means that the UTXO's you get are older than the UTXO's you create when sending your coins to the mixer.

Then you are free to redeem them whenever you want.
I am not sure if that's what you are looking for, since you won't be able to really 'trace' them (because there is no link between those transactions).

You should educate yourself a bit more.

The fee of a transaction is dependent on the size of the transaction, period.
The size of a transaction IS SMALLER with segwit transactions, period.

The only logic consequence is that segwit transactions are lower in fees (about 30%-40% with bech32).

---

You should read the whole thread before replying:

This itself is not possible IF you trust the developer.

1) PIP is using https. This already elminates some attack vectors (e.g. MITM).

2) PIP is using checksums (MD5 i believe) provided by the author (in this case ThomasV) to be sure it has not been tampered with.
This is not necessarily safe since MD5 is quite broken. But it at least is SOME security.

However, downloading it manually and checking the signature is more secure and eliminates any risk of maliciously replaced packages (this still requires that you trust the developer).

In fact, segwit transactions are MORE secure than legacy transaction (e.g. https://en.bitcoin.it/wiki/Transaction_malleability).

Most exchanges are already using segwit and do also allow to withdraw to segwit addresses.

Nested P2SH segwit is accepted EVERYWHERE, simply since the address can't be distinguished from a legacy multisignature (both starting with 3...
Few softwares havn't been updated yet to accept bech32.


But it is definitely NOT LESS SECURE than legacy transactions.

But again.. this approach requires trust.

Yes, you could track the 'abuse' in terms of you'd know who spend these coins.
But you wouldn't be able to 'revert' it or anything else.

The coins would be gone in this scenario. The best approach is a trustless approach. And this does exclude the option of a 1of2 multisig with giving 1 key away.

This just reminds me of this:

You are asking how to be sure that token X is not a faked copy of token Y (from which you don't know the correct contract address) ?
Did i understand you correctly?

If this is the case, you can't. The only way to verify that the token is the original one is by knowing the contract address of the original one.


But to be honestly.. if you don't even know the contract address of the original token (and are not sure whether the one offered is fake or not), it probably is better to NOT accept it as collateral.
A token whose contract address can't be found out.. can't be worth much (if anything at all).



Regarding your 2 mentioned tokens:

URAllowance:
Seems to be a scam for me. They claim to give a '30% bonus' if you deposit ether to a given address. This address hasn't received anything at all.
Additionally there is no smart contract or anything. A simple money grab. Those tokens (if they have setup a smart contract at all) can't be worth anything.

eHealth First:
Doesn't have any link to their smart contract.
Tokens can be bought by contacting them via email. This sounds shady.
I can't imagine these tokens will be worth anything.

Broadcasting the second transaction won't work, since it is invalid.

It will be rejected by the network. So it would have to be stored on a server or something like that.




The whole thread is about creating such a 'switch'. Your 'solution' unfortunately isn't a solution. It is just a different approach which still needs the key element, the 'switch'.




And what if the phone gets stolen ?
Of what if it breaks ?

Or what if he gets ran over by a bus ?

This definitely has to be done automatically. Therefore the timelocked transaction. If the owner isn't intervening, the transaction will be valid (the 'switch').

One does not use a segwit 'wallet', but segwit address-/transaction- types.

Segwit is already pretty good adopted. The majority of services and block explorer (at least the good ones) have adopted using segwit (bech32).


When using segwit (either nested P2SH segwit (addresses starting with 3..) or native segwit (addresses starting with bc1..) your transactions are going to be smaller in size.
Therefore the fees are lower when choosing the same fee rate (sat/B) compared to a legacy transaction.

If you want to save on fees, i'd recommend to use bech32 since the size is notably smaller than nested segwit (which also already is clearly smaller in size than legacy).


But it might be worthy to note that not all services already accept bech32 addresses (e.g. as withdrawal addresses). This is due to the fact that they simply haven't updated their software yet.
The majority of services (exchanges) do already support withdrawals to bech32.


Long answer short:
Yes, it does reduce the fees. And it additionally helps to improve BTC's eco system.