Wait.. are you actually really trying to justify yourself by saying your wallet did at least encrypt the seed before sending it over to google??
Like.. are you serious?

A closed source wallet sending the seed via google API to check the spelling.. and then you come here and say "..well at least it was encrypted via https"... are you kidding?!
I rarely encounter such incompetence, ignorance and arrogance in one person. Congratulations.

Such statements are a really good reason to absolutely discourage the use of your wallet.

He indeed decided to increase the fee of the transaction stealing all of his coins..

OP, if you want to save your coins, do what i have posted.
But replace the transaction id in the 3rd step with the actual one you now want to double-spend (a219bb1983c1dea6a00360fa830e5961deaf5a1dccbafd0578c81087db3b50e5).

People receive phishing mails all the time.
What is the big deal with this one?

Just because you bought a ledger and receive a ledger phishing mail?
Customers of coinbase also receive phishing mails "from coinbase". Customers of the bank of america also receive phishing mails.

Checking an email for authenticity is not too hard.
Already the senders address ledgersupport.io is enough to expose that mail as a phishing attempt.
If people don't even check the senders address, then they can be bribed into doing anything via email. They would fall for the classical nigerian prince. Nothing you can do to help those people. They got to learn it the hard way.

Because with closed source software (this doesn't only apply to wallets, but also your operating system for example), you can't be sure of what the software is doing.
It might be malicious, might have serious bugs/vulnerabilities or might use outdated libraries which are known to be exploitable.

With open source software on the other hand, you can check which libraries are used as well as check every new update being performed.

While you are right that the majority isn't able to read the code (and even if, they probably wouldn't), a few technically versed people did look at it. Some bugs or malicious backdoors are found way faster in open source software than in closed source.
If there was a malicious backdoor in electrum/wasabi/core, you can be sure that you would have already heard about it. This does not apply to closed source wallets.

If you are not satisfied by their wallet, why not switching to a different one?

Both mycelium and samourai allow you to send transactions with a 1 sat/vB fee.
Mycelium is using a priority model with a pretty large span (i'd say roughly 20-30 to choose from) and samourai allows you to choose from a few priorities and further allows you to customize your fee completely.


Further, the fee is dependent on the size of the transaction and not the FIAT value. You would have paid the same fee if your UTXO's would have been worth 100.000$ instead of 10$.

I think someone is moving BTC's around because that's exactly what is happening.
Not that unusual that a currency gets moved around.




Vulnerability? Where?
In windows, definitely. Adobe PDF reader? Well imaginable. Bitcoin network? Unlikely.

Don't interpret too much into a few transactions.. Could be someone selling the coins or just moving them to a new wallet etc..

It is MiB per day (24 hours).
If you need to make sure that core never exceeds a specific upload rate, you need to limit it using external software (e.g. trickle).




The first message might indicate an error, but did you check your bandwidth?
This message often appears without any error. You might want to double check this.

Besides using the built in function as mentioned by mocacinno, you can use trickle to limit the bandwith of a specific application:

You obviously need to replace UPLOAD_BANDWIDTH with the maximum allowed upload bandwidth, DOWNLOAD_BANDWIDTH with the maximum allowed download bandwidth and APPLICATION with the name of the application you want to limit.


You might want to try the method mentioned by mocacinno (editing the core config file) first and afterwards trickle.
If nothing works, feel free to report back and we can further debug your problem.

No, this would just increase the fee and would result in the transaction getting confirmed faster.
You need to create a new transaction spending the same input.

To do so, do the following:

• Disconnect Electrum from the Network
• Open the console (View -> Show Console -> Then the "Console" tab)
• Enter: wallet.remove_transaction("a219bb1983c1dea6a00360fa830e5961deaf5a1dccbafd0578c81087db3b50e5")
• Close and restart Electrum
• Create a new transaction sending your funds with a pretty high fee (definitely more than the 16 sat/vB from the first transaction) -> sign it and save/export it
• Connect electrum to the network again
• Import the just created transaction (Tools -> Load transaction -> from text/file (depending on what you have chosen in the last step))
• Broadcast it

---

Please do not comment on topics you don't know anything about.
Such useless and wrong information is just clogging up the thread making it more difficult to find valuable information.

Electrum had a (admittedly not severe at all) vulnerability.

But there is no new ledger hardware wallet vulnerability. The only risk lies in getting phishing mails, which people receive anyways.

I don't get why a forum should warn its user about phishing mails from a completely different company.
In fact, it could even lead to a perceived security, in times where there is no such warning. But those phishing mails are still being sent. 24 hours a day, 7 days a week and 52 weeks a year.


IMO unnecessary.

Then your balance didn't reduce by 0.07.

This most likely is just a displaying issue. ledger live is a horrible software.
I'd definitely also recommend you to use a better interface to access your hardware wallet. Both electrum and wasabi are recommendable.



Since the input used is 0.94x BTC, he would be missing more than just 0.07 if this address wasn't part of his wallet.

Most likely just ledger live being ledger live 

Ja, wenn es recht flott gehen soll dann sind die Gebühren schon relativ hoch. Kombiniert mit einem hohen €-Wechselkurs, ergibt das eine GEbühr von ~6.50€.
Ob du dabei 10€ oder 10.000€ kaufst, spielt keine Rolle. Die Gebühr ist von der Transaktionsgröße (Bytes) abhängig und daher unabhängig vom €-Betrag.




In der Regel ist es so, dass du einen Betrag an eine Empfangsadresse sendest (z.B. 1 BTC) und dafür eine Gebühr zahlst (Gesamt: 1 BTC + Fee).
Wenn du bei Core dort den Haken setzt, dann wird die Gebühr von dem zu sendenen Betrag abgezogen. Beim Empfänger kommen also 1 BTC - Fee an.

Wenn jemand (Person oder Service) möchte, dass du exakt X BTC sendest, dann kannst du nicht X - Fee senden. Solltest diese Option daher immer ausgeschaltet lassen.

Hmm.. dann zahlst du aber bei Services ein, die eine Zahlung mit 0 Bestätigungen akzeptieren und dir quasi sofort was "gutschreiben" (wie manche Online Casinos etc.), oder?
Ansonsten, wenn auf eine Bestätigung gewartet wird, macht das absolut keinen Sinn.

Wenns dringlich ist, macht das Sinn (sofern man mit 0 Bestätigungen etwas bekommt), in allen anderen Fällen würde ich aber RBF schon aktiviert lassen. Schon allein für das bessere Gefühl die Zahlung "beschleunigen" zu können, falls es denn mal sein muss.




Ich schätze mal spätestens Sonntag Nacht sollte es klappen, sofern nicht nochmal ein großer Preisanstieg oder -sturz von BTC kommt.

As far as i know, blockchain.com does not set the RBF flag, which would be absolutely mandatory to be able to replace the transaction with electrum.
You might want to post the TX ID, so we can check that for you tho.

Hallo, ja alles gut  




Das bedeutet, dass ein Input, den du verwendet hast, noch nicht bestätigt ist.




Du hast nichts falsch gemacht.

Deine Transaktion nutzt einen Input, der noch nicht bestätigt ist: TX mit 10 sat/vB

Der aktuelle Stand ist also folgendes:

• Deine Transaktion zahlt eine Gebühr von 50 sat/vB
• Die Transaktion deines Inputs (vorherige Transaktion, also) zahlt eine Gebühr von 10 sat/vB

Es muss zuerst die Parent Transaktion bestätigt werden, bis deine ausgehende TX bestätigt werden kann.
Da beide TX in einem Block landen können und Miner die möglichst hohe Gebühr haben möchten, müsstest du warten bis die aktuelle Gebühr um in einen Block zu kommen bei ca. 30 sat/vB liegt. Denn dann lohn es sich als Miner beide Transaktionen in einen Block aufzunehmen.
Derzeit liegen wir bei mehr als 200-250 sat/vB, der Mempool ist ziemlich voll.

Das heißt, es wird schon noch etwas dauern, vermutlich sogar ein paar Tage.

Bezüglich RBF / CPFP:
Am besten ist es natürlich wenn man RBF immer gesetzt hat. Das schadet nie. Kann man jetzt natürlich nicht ändern, aber fürs nächste mal.
CPFP ist theoretisch natürlich möglich, dafür müsstest du aber die Kontrolle über eine Wechselgeldadresse haben (existiert in der Transaktion nicht) oder über die Empfängeradresse (coinbase). CPFP kann in dem Fall also leider nur coinbase durchführen.


Du hast aktuell 2 Möglichkeiten:

• Transaction Accelerator verwenden: Es existiert nur einer (alle anderen sind Betrug) und dieser akzeptiert 100 Transaktionen pro Stunde. Du müsstest also in den ersten Sekunden deine Transaktion (Hash) dort "einreichen". Dann wird deine TX im nächsten von viabtc generierten Block inkludiert.
• Warten.

Leider bleibt dir nichts anders übrig.

Since the transaction propagated already, the only way to successfully double spend the transaction is to make use of the RBF-flag.

But unfortunately, since your friend does not use a proper wallet, this flag is not set.

If he would have used a standard desktop- or mobile wallet, the RBF most likely would have been set. All modern wallets offer that option and most do that automatically.
Blockchain.com as a web wallet with outdated functionality, unfortunately doesn't.


Your only way to get the BTC back would be either to 1) ask a miner to include your double-spend transaction (unlikely if the amount isn't high enough for them) or 2) ask the recipient to pay it back.

Recommend your friend to use a proper wallet which offers that functionality and to double or even triple check everything before hitting send.

Since your fee is relatively high, the transaction should confirm in the early hours (europe time).
But a small pump/dump of the BTC/USD price could definitely add more transactions to the mempool.

For the future, you might want to consider using a proper wallet. Not only will you have the ability to replace transactions / increasing the fee, but you'll have a more secure storage of your keys.
Web wallets should be avoided whenever possible.

Irgendwann müssen Personen ja auch erwachsen werden.

Wenn ein riesiger Banner mit "Achtung, möglicherweise Betrug" und weitere Warnungen von Nutzern diese nicht abhalten.. dann sei dem so  
Einige Leute müssen Lektionen selber erfahren, um schlauer zu werden.


Da fällt mir ein passendes Zitat ein, von dem ich leider nicht weiß woher es stammt:

Hab gerade nochmal drüber gelesen und entdeckt, dass du ja anscheinend den Private Key hast.

Also wenn du tatsächlich den Private Key von der richtigen Adresse (die mit den BTC) hast, dann kannst du den natürlich in entweder Core oder ein anderes Wallet (z.B. Electrum) importieren.
Beim importieren in Electrum musst du halt darauf achten den korrekten Adresstypen zu wählen: Legacy für Adressen die mit 1.. beginnen, P2SH für 3.. und bech32 für Adressen mit bc1..


Wenn die BTC aber auf einer anderen Adresse liegen (weil du z.B. eine Transaktion durchgeführt hast), dann ist das was in meinem 1. Post steht die einzige Möglichkeit.

And since the ANT catalog got leaked, we know that the NSA has more than a handful ways to extract data from air-gapped devices.




Not necessarily.

With hardware access to the cold storage, tampering attacks are possible.
And this means that without verifying the hardware each time, you run the (admittedly low) chance of leaking private keys by simply just decrypting them.

With a HW wallet, a malicious actor would not only need to manipulate the hardware of the HW wallet (since the software on the air-gapped device can verify the integrity of it), but also the air-gapped device.

This obviously is based on the premise, that it is not possible to simply extract the private keys from the HW wallet. Further my first assumption was an evil maid scenario with repeatedly short access to the hardware.


Spending more time thinking about this, i'd say a 2-of-2 multisig would be the best option here.