Paid 0.7 btc fee! Any chance to return it?

[NotATether]

https://x.com/mononautical/status/1834196815786225822
Well, this is about my case. Based on that post, my transaction had SIGHASH_NONE, which means anyone could have spent the change. I reached out to the support channel for Sparrow Wallet on Telegram, and they explained that, because of this, bots were able to take control of the transaction.

On that post I see:

the original transaction looks like a simple spend of 0.21 BTC from a UTXO of ~0.79 with RBF enabled.

it was replaced almost instantly by the ultra-high-fee tx. so quickly that most of Mempool's servers didn't have time to even see the first tx.

It's for this reason I think SIGHASH_NONE should be disabled from being selected unless the user ticks an "Advanced mode option". And we can actually take this one step further, by hiding any such listbox for the sighash so that they always use SIGHASH_ALL.

Anyway, now that your case has gained traction on social media, I think Foundry USA will notice this and reach out to you.

[larry_vw_1955]

Anyway, now that your case has gained traction on social media, I think Foundry USA will notice this and reach out to you.

do you really think that? that's pretty naive if you really think that...

[CY4NiDE]

Hey OP, any updates from Foundry?

Keep us posted, I wanna know how this ends.

[philipma1957]

yeah i would love to see the op get a refund.

[JDXs]

I actually like it when you have powerful options available in a wallet, not that I need all of them, presuming you understand them and know what you're doing. I can't say for me that I'd have any use for such a Sighash option that Sparrow offers in its UI. I also can't say that I understand them confidently.

Maybe it would be good to hide or disable them in UI, unless you turn on power-user mode in settings (makes life for programmer(s) less easy and surely there will be some to complain what is power-user worthy and what not.

So far presented details indicate to me that OP was in panic mode and didn't take the time to investigate the error messages and finally thoroughly check all settings before broadcasting transactions (the sloppiness involved likely due to perceived need to rush it).

It's not my intention to point fingers or blame him. Anybody interested in this particular issue should learn from the chain of bad events.

The mystery of the unknown target address remains that kicked OP out of smooth orbit.

I had a moment of panic, but it didn’t affect the outcome because it started after the second transaction was broadcasted. Nothing I did afterward could have influenced the outcome.
I made my first transaction of 0.2 BTC, and it went through fine. However, during my second transaction, after broadcasting it, I immediately realized the recipient address wasn’t mine, itwas replaced. Found log from mempool confirmed that the original address I used was correct, but was replaced very quickly. Also Sparrow wallet log posted in my previous post shows that I tried to cancel the transaction using replace-by-fee (RBF), but it didn’t work because the fee was set too high. Sparrow wallet does not allow to set that high fee. It proves that it was set this way by some third side bot. Obviously this happened due to a null sighash, which allowed to replace the transacton outputs.

Who would be interested in doing something like this? The idea that many bots were competing for the sum until the entire amount was consumed by fees seems incorrect. If that were the case, my Sparrow Wallet log wouldn’t report that I couldn’t replace the transaction due to the abnormally high fee. This proves that the high fee was set in a single action, not through thousands of small, incremental fees until the entire sum was used up.

Also, I’ve tried everything to reproduce this situation with the wallet, but I can’t replicate it. My spacebar is still malfunctioning, but there’s no way this would have caused a 'none' sighash to be selected. To choose that, I would have had to press the tab key several times and use the arrow keys to select the 'none' option, which I definitely didn’t do. I don’t think it was a keyboard issue. I’ve done similar transactions many times and have always used the default settings. This part is still unclear to me.

Regarding Foundry USA, I am still  waiting for a reply. I sent a message through their website, two emails - one to their general contact and another to their legal department email and also reached out via X (formerly Twitter). It’s been over a week with no reply.

As far as I can tell, there are no laws covering situations like this, especially since I’m not from the USA.

Well, what else could I do in this case?

[LoyceV]

Who would be interested in doing something like this? The idea that many bots were competing for the sum until the entire amount was consumed by fees seems incorrect. If that were the case, my Sparrow Wallet log wouldn’t report that I couldn’t replace the transaction due to the abnormally high fee. This proves that the high fee was set in a single action, not through thousands of small, incremental fees until the entire sum was used up.

Your Sparrow Wallet probably didn't see all "intermediate" fees. I assume the bots who competed to replace your transaction are all very fast, and this happened in a fraction of a second. You only saw the end result.

[JDXs]

Who would be interested in doing something like this? The idea that many bots were competing for the sum until the entire amount was consumed by fees seems incorrect. If that were the case, my Sparrow Wallet log wouldn’t report that I couldn’t replace the transaction due to the abnormally high fee. This proves that the high fee was set in a single action, not through thousands of small, incremental fees until the entire sum was used up.

Your Sparrow Wallet probably didn't see all "intermediate" fees. I assume the bots who competed to replace your transaction are all very fast, and this happened in a fraction of a second. You only saw the end result.

I thought when using RBF, the new transaction replaces the old one based on a higher fee, but the fees are not additive and new transaction should use "new coins". The new transaction should replace the previous one if the fee is higher. If the last fee was 0.789 BTC, the previous fee must have been around 0.78 or 0.77 BTC. With only 0.79 BTC available, it wouldn’t be possible for the fees to add up unless the new fee also used the amount from the previous transaction, which would mean double spending. Bitcoin is designed to prevent this. I'm not entirely sure if this rule holds while transactions are still in the mempool and not yet confirmed in a block.  Please correct me if someone knows how it works for sure.

By the way, I was able to find json data with original transaction in mempool https://gist.github.com/mononaut/c6b8b95903de1906facdfedf248d0445

Update. Ok, I got what you meant. RBF, the word replace speaks by itself. It replaces reusing the old UTXOs. I have seen the final fee.

[Cricktor]

I made my first transaction of 0.2 BTC, and it went through fine. However, during my second transaction, after broadcasting it, I immediately realized the recipient address wasn’t mine, itwas replaced. Found log from mempool confirmed that the original address I used was correct, but was replaced very quickly. Also Sparrow wallet log posted in my previous post shows that I tried to cancel the transaction using replace-by-fee (RBF), but it didn’t work because the fee was set too high.

My main wallet is Electrum. I "played" a bit with Sparrow in Testnet3 and liked it so far, but that's some time ago and I can't say I'm very familiar with Sparrow.

Before you broadcasted the second transaction to clear your not-cold-anymore wallet, are you sure that your destination address was your own? Or could it be, it was replaced there already? If it was replaced, some clipboard malware was in action.

If your second transaction was rather RBF-replaced due to SigHash None, then how was this dangerous option activated? It seems unlikely to me, you did this on purpose.

Well, what else could I do in this case?

At least, make it as public as possible. Stirr it up at X, Reddit, all the social media shit places available.

I don't know if it's wise to get in touch with a lawyer. Main question is if you have any handle to press at Foundry. As you're Germany based, I've no idea if there's anything available for you. So far you've lost a significant amount of value and you probably don't want to throw more money to a lawyer.

I've no idea if there are German lawyer who work on a success base. If they win and force Foundry to return your coins, they earn a motivating percentage of it; no success, no payment.

But if SigHash None was the culprit to the damage, Foundry could argue, the transaction was destined to be replaced. Your position seems worse than a fat-finger accident, unfortunately.


Not sure if this falls under conspiracy talk. What if pools have their own bots to look out for SigHash None transactions and replace them to benefit their own secret wallet or raise transaction's fee to max? In the latter case it's not guaranteed the pool wins the block and thus the fee, but it's a stealth gamble.

[nc50lc]

Also, I’ve tried everything to reproduce this situation with the wallet, but I can’t replicate it. My spacebar is still malfunctioning, but there’s no way this would have caused a 'none' sighash to be selected.

If not the keyboard or an accidental series of keystrokes.
There's also a possibility that the PSBT is altered/corrupted to prompt the signer wallet to sign with SIGHASH_NONE type flag before it's signed by Sparrow.
In that case, once the PSBT is loaded to Sparrow, it will automatically select and display SIGHASH_NONE during the signing process.

However, based from your description of what happened in page2, post #21 that you've "sent the transaction directly",
it shouldn't have been an altered PSBT since the transaction creation and signing processes are done in the same machine without the need of transaction export.

[LoyceV]

Not sure if this falls under conspiracy talk. What if pools have their own bots to look out for SigHash None transactions and replace them to benefit their own secret wallet or raise transaction's fee to max? In the latter case it's not guaranteed the pool wins the block and thus the fee, but it's a stealth gamble.

I don't think they have to do this, there must be enough bots out there doing it for them. Every deposit into an address with leaked private key gets emptied instantly, and they're quite literally fighting for it.

[larry_vw_1955]

But if SigHash None was the culprit to the damage, Foundry could argue, the transaction was destined to be replaced. Your position seems worse than a fat-finger accident, unfortunately.

i think any reasonable company would require it to be taken to court before they say a word about it. it's not a miners responsibility to make sure people don't make mistakes. if that was the case every person that ever got hacked would be taking bitcoin miners to court...

[stompix]

Well, what else could I do in this case?

At least, make it as public as possible. Stirr it up at X, Reddit, all the social media shit places available..

This would be the best approach, try to get attention, use Twitter and Reddit to ask for help, and be careful, don't make it look like you're accusing anyone of anything, just ask for help and views if you manage to get some interest from a guy with a few thousands followers you might speed it up, Foudnry would rather give it up than ending seen as taking profits from a bug, at the same time, they have distributed those so, it might get tricky.

i think any reasonable company would require it to be taken to court before they say a word about it. it's not a miners responsibility to make sure people don't make mistakes. if that was the case every person that ever got hacked would be taking bitcoin miners to court...

This is nothing like a hack!
In a usual hack, the miners just process a transaction and the hacker gets the funds, they have nothing they could return!
Here the Op just overpaid something, and the funds have not got anywhere, they were received by the miners themselves by accident.

We have a precedent with Antpool and F2pool so it's about willingness and greed.

[philipma1957]

Well, what else could I do in this case?

At least, make it as public as possible. Stirr it up at X, Reddit, all the social media shit places available..

This would be the best approach, try to get attention, use Twitter and Reddit to ask for help, and be careful, don't make it look like you're accusing anyone of anything, just ask for help and views if you manage to get some interest from a guy with a few thousands followers you might speed it up, Foudnry would rather give it up than ending seen as taking profits from a bug, at the same time, they have distributed those so, it might get tricky.

i think any reasonable company would require it to be taken to court before they say a word about it. it's not a miners responsibility to make sure people don't make mistakes. if that was the case every person that ever got hacked would be taking bitcoin miners to court...

This is nothing like a hack!
In a usual hack, the miners just process a transaction and the hacker gets the funds, they have nothing they could return!
Here the Op just overpaid something, and the funds have not got anywhere, they were received by the miners themselves by accident.

We have a precedent with Antpool and F2pool so it's about willingness and greed.

The op would win in court easy peasy if he was USA based.  But since he is located in Germany the cost of going to court is a lot and as I mentioned I am not sure if this is covered under USA law or German law.  It is a shame as this is a simple error which under USA law is required to be refunded.

FOUNDRY IS VERY BIG COMPANY and can afford to return the error.  Op should post links to this thread and state the facts.

Maybe on x maybe on Facebook. Maybe on YouTube.

[larry_vw_1955]

This is nothing like a hack!
In a usual hack, the miners just process a transaction and the hacker gets the funds, they have nothing they could return!
Here the Op just overpaid something, and the funds have not got anywhere, they were received by the miners themselves by accident.

if it's a mining pool then that money was already distributed out to a bunch of individual miners in the pool. the money is gone. so you can't get it back unless you go back to each miner in the pool and have them return it good luck with that.