I don't know this OWNR wallet but as hosemary confirmed to be able to restore Segwit address types from OWNR in Sparrow, I would assume that OP did something wrong with script type or derivation path for Segwit address types during restore in Sparrow.

If he managed to restore legacy addresses correctly then apparently the mnemonic recovery words were correct.

As ABCbits says, if your redeem transaction is valid but only non-standard, you could try to submit your transaction via slipstream.mara.com. They say they accept non-standard transactions with other nodes won't relay and thus hardly can reach any miners mempool.

The Slipstream service might impose other restrictions to non-standard transactions and I haven't used it to submit non-standard transactions because I don't need to. You pay a higher fee rate than normal, but it's quite reasonable and especially now when mempool isn't much full at all.

It would be the goto method for me if I had a non-standard transaction or a transaction that I don't want to be seen in public until it is actually confirmed and mined into a block.

Can you elaborate why you make it sound urgent?

I don't want to say, there's no need to do something, there's already discussions about this and that for potential upcoming threats. You may perceive such processes as too slow or whatnot, but rarely a single person oversees all details and their consequences.

I'm generally curious why you call it out like you did. What do you think to know that you left out in your post? Deliberately? You don't explain at all what could possibly become a real, not imagined, problem. So what's this all about?

Linux is mostly more secure because it's less on the radar of malware writers due to it's lower market share than Windows. This is oversimplified for sure, but imagine you're a malware developer: for which platform would you craft your malware, one with large user base or one with significantly smaller user base?

@OP: do you mind posting the transactions, I understand you that there should be two of them? How did you determine that your presumably stolen funds went to Binance?

Security comes with a price and usually not for free (not only in the sense of money).

A hot software-only wallet can't really secure itself from malware and will have a hard time to protect your private keys or your main secrets of your wallet on an infected computer or mobile.

Personally I wouldn't use Ledger crap but most other decent hardware wallets are highly recommended if used properly. In my opinion it's mandatory that a hardware wallet has an own independent display and the user has to carefully check every detail of a transaction before he signs it. There's no excuse to not do this with every transaction because this ensures that no malware can trick you with a manipulated transaction submitted to your hardware wallet to be signed from a potentially infected online device which is needed to broadcast your signed transaction.

I'd rather accept some additional steps with a good and recommended hardware wallet than fear if my computer is still clean or not. People can also aid to keep their device safe from which they do their crypto wallet stuff if you simply don't use your daily driver for it when you do all sorts of internet shit with your daily driver.

Use a dedicated Linux desktop for your crypto coin stuff and avoid browsing with it and doing email on that device. This eliminates a lot of attack surface.

An air-gapped offline laptop is for cold storage and signing is safe, too. But this isn't very comfortable and certainly nothing for someone who complains that Ledger crap is already uncomfortable.

I will wait a few weeks before I upgrade to 4.6.x to have it mature a bit as I do with most versions unless there's a very severe vulnerability or bug that needs immediate attention.

Submarine swaps communicated via Nostr sounds interesting and allows more decentralization of those, when anybody could become a submarine swap provider. I don't have read about the details yet, I picked it up from the release notes.

I also like the new way to add and use plugins from your Electrum wallet's datadir. I will have to take a closer look at the security measures to prevent malware from injecting malicious plugins and generally to evaluate or audit the security of third-party plugins. Closed-source plugins would be a no-go for me anyway.

Now that we have a glimpse that you're likely not the brightest candle on the cake, it's pretty much clear that there's no feasible way to find the HD wallet's master extended private key or even the mnemonic recovery words which encode the wallet's main secret very likely random entropy.

Bitcoin's cryptography has been safe for 16y and will be safe for longer. HD wallets are a few years younger and are safe too, unless the wallet owner is plain stupid and can't secure the mnemonic recovery words properly.

You may want to hop to https://learnmeabitcoin.com and learn a bit about Bitcoin before you talk about stuff you have no or little clue about. As many others with their questionable contributions here, it's just noise to this thread.


Puzzle #135 is the next available with a public key exposed. It's not impossible to solve, it only depends how much resources you're willing to throw at it. But you wrote "practically impossible", and well that might be the case when the resources to solve it cost you more than you could gain from finding a solution and successfully withdrawing it.

To withdraw puzzle #135 you don't need to use slipstream.mara.com because bots can't find a solution any fast. This is the case for all remaining pending puzzles with exposed public keys unless some new magic is invented which frankly I don't see. And please, don't start some blabbering about quantum computers when your knowledge about those comes basically from public clickbait news.

Of course, for puzzles #71+ you need slipstream.mara.com or similar non-public, non-fraudulent miner's mempool to withdraw without fear to loose your puzzle prize to bots.


What value has your post for this thread exactly?

You may want to have a look at which characters you find in your encoded string. As of https://en.wikipedia.org/wiki/Base64 Base64 uses all A-Z, a-z, 0-9 and two other characters, usually + and / and = for padding.

Base58check uses only a smaller subset and avoids symbols that could be ambigous in most type faces. Additionally it has a partial hash checksum embedded.

In some cases it might not be possible to distinguish Base64 from Base58 depending on the sample string size. Base58check should be distinguishable because it must pass the checksum test as long as it's not crippled.

A WIF private key is composed of a prefix byte, the private key bytes, optional compression indicator byte and finally a partial hash checksum of four bytes, then all encoded with Base58. See e.g. here for details: https://learnmeabitcoin.com/technical/keys/private-key/wif/

I haven't used Bitcoin-GUI as now Bitcoin Core was called in those early days of 2010. I used Bitcoin-GUI on Windows OS in 2011 earliest. In 2011 I didn't fiddle much around with it, just mined some coins and moved them around. I don't think the standard Bitcoin client software ever asked for a wallet encryption passphrase when it was opened. But I may not understood what you were writing about your early wallet.

I really don't know how some entities determine what fee to pay for transactions. In the block that LoyceV mentions the fee rate for transaction 1bceacc5...5b838bbf stands out as completely overpaid and unnecessarily high. Apparently the payer doesn't mind and care to waste coins.

The previous block wasn't full either, emptied the mempool and in a few seconds of mempool lifetime not so many new transactions poored in (a very brief check showed that basically all transactions were public and seen in mempools).

At that time there were regularly non-full blocks, so I would have paid a fee rate of 1.00 or max 1.10 sat/vB when I wouldn't need my transaction to be in the next block for sure.

Paying sub 1 sat/vB is a bit new (I know and transacted in the early days of Bitcoin where there wasn't a minimum relay fee rate of 1 sat/vB) and not all wallets will publish such a transaction. Exporting a signed transaction hex is a workaround, but extra steps.

I think I'm going to lower my node's minimum relay fee rate to something realy low (for fun) now that sub 1 sat/vB fee rates became sort of a trend.

It's better when you post code in [code]...[/code] tags, because it can happen that parts of your code get swallowed by the BBcode interpreter. (It doesn't look like it happened with your code example above, though, but it's simply good habit to use code tags.

Especially prone to be swallowed is the character sequence of [i] which occurs quite often in some code or code examples. If you have this in your posted code and don't use code tags, [i] gets removed from posted code and subsequent code text is seen in italic font style, because [i] starts italic text.

You don't want that to happen.


I've bookmarked your Github repo and will have a look what you offer there.

Du bleibst Antworten schuldig, aber es sei dir überlassen, ob du auf Fragen eingehst oder nicht. Hinterher nur nicht heulen...

Ich muss dich nicht beschuldigen, warum auch, klar ist nur, daß das wie eine bekannte Betrugsmasche klingt, was du eingangs in sehr dürftigen Details erzählt hast.

Trust Wallet ist Closed-Source, schon allein deswegen würde ich die nicht für mehr als Taschengeld verwenden.

Ernsthaft, erzähl' doch mal, wie genau es dazu gekommen ist, daß du glaubst, 8000 Taler gewonnen zu haben. Lass mich raten: du hast die 8000 noch nicht in deinen Händen, auf deinem Konto, wirklich wirklich in deiner Wallet, die nur du kontrollierst.

Falls du unverifizierte Software von den Giveaway-Veranstaltern heruntergeladen und auf deinem Rechner ausgeführt hast, solltest du deinen Rechner als kompromittiert betrachten. Falls da eine Screen-sharing Sitzung mit Anydesk oder so im Spiel war, solltest du deinen Rechner als kompromittiert betrachten.

Wenn du nur Screenshots von deinem Gewinn hast, tja dann kann ich dir nur sagen, Bits und Bytes sind geduldig und können dir alles vorgaukeln.

Wie schon jemand anderes schrieb, falls du zahlen sollst, um deinen Gewinn einzusammeln, dann ist das der Scam, der dir das Geld aus den Taschen leiern soll oder wird.

Aber erzähl' doch einfach mal, statt hier rumzutönen.

Da jedes einzelnen Situation und Anforderungen an eine Sicherung durchaus individuell sein können, würde ich jedem raten, eine Verlustrisikoanalyse zu machen. Listet die für euch relevantesten Verlustrisiken auf, die euch hoffentlich alle einfallen und dann macht man sich daran, sich zu überlegen, wie man möglichst alle Risiken mit einer geeigneten und nicht zu komplexen Sicherungsstrategie kompensiert.

Dabei gilt ggf. die Maxime, weniger ist mehr. Zu komplex ist ein eigenes, nicht zu unterschätzendes Verlustrisiko. Auch sollte man nicht unbedingt versuchen, Risiken zu vermeiden, die nur eine geringe Eintrittswahrscheinlichkeit haben.

Die für mich relevantesten Risiken sind (die Reihenfolge hat erstmal keine besondere Bedeutung):

• Feuer/Brand
• Einbruch/Diebstahl
• Malware/Hacking
• Schwere Krankheit, Gedächtnisverlust, eigener Tod

Die ersten zwei erzwingen eine redundante Sicherung an mindestens zwei verschiedenen Orten, so daß ein einzelner Ort nicht zu einem Totalverlustproblem werden kann.

Gegen Malware/Hacking benutze ich ein Hardware-Wallet mit stets strikter und sorgfältiger Kontrolle aller Transaktionsdetails, bevor eine Transaktion signiert und versendet wird. Ich habe praktische Erfahrungen mit Computersicherheit und habe auch große Neugier und Interesse an dem Thema, bin eh seit Jahrzehnten in der IT unterwegs. Das macht mich nicht immun, aber es hilft schon im Vergleich zu vielen anderen, die vergleichsweise unbedarft sind.

Aktuell favorisiere ich die Nutzung einer optionalen mnemonischen Passphrase als Absicherung gegen eine potentielle Kompromittierung meiner mnemonischen Wiederherstellungswörter. Die Wiederherstellungswörter teile ich nicht auf, die sind auf hochwertigem säurefreien Papier aufgeschrieben, zusätzlich habe ich die Wörter auf Edelstahlunterlegscheiben gestempelt, die einen Wohnungsbrand überstehen werden.

Die Wallet ohne mnemonische Passphrase dient als Opferwallet und "Kanarienvogel", um zu merken, wenn meine Wiederherstellungswörter kompromittiert wurden. Die mnemonische Passphrase wird natürlich separat von den Wörtern mehrfach redundant gesichert und zwar so, daß es unwahrscheinlich ist, sie a) komplett zu verlieren und b) jemand bemerkt, daß diese überhaupt gesichert wurde. Details dazu werde ich nicht öffentlich machen.

Eine andere Variante, die mir auch zusagt, sind Shamir Secret Shares (SSS). Dabei gefällt mir besonders, daß einzelne Teile keinerlei Informationen verraten, solange man unterhalb der Mindestzahl an benötigten Shares bleibt. Das ist meines Erachtens wesentlich smarter, als das simple Aufteilen von Wörtern in mehrere Teile.

Beim Thema Vergessen, Krankheit, eigener Tod, wie kommen Erben an die Coins, bleibt mir nur, alles so gut zu dokumentieren, daß ich selbst nichts vergessen kann und meine Erben eine Chance haben, die Wallet(s) wiederherzustellen.

Ich bin mir bewusst, daß die Dokumentation einige Sicherungsaspekte konterkariert, daher habe ich keinen Teil der Dokumentation in meinem Zuhause, sondern ausschließlich versiegelt woanders. Die Versiegelung erlaubt eine Kontrolle, ob sich jemand daran zu schaffen gemacht hat. In einem Teil der Dokumentation sind auch nicht alle Details enthalten, um die Wallet(s) wiederherstellen zu können. Man braucht zwei Teile der Dokumentation, um alles zusammen zu bekommen.

Der Dokumentationsteil ist das eigentlich nervigste und fast schon aufwendigste, auch was die redundante Sicherung anbelangt. Bei der ausführlichen Dokumentation für den Fall, daß ich nicht mehr da sein sollte oder handeln kann, setze ich auf SSS mit einer Mindestanzahl an drei benötigten unterschiedlichen Teilen (3-von-5). Dabei halte ich und z.B. meine bessere Hälfte und meine Kinder jeweils zwei Teile, hier alle die gleichen zwei. Weitere zwei andere Teile sind bei Vertrauten, noch eins im Bankschließfach.

Die Teile sind versiegelt, die Verwahrer wissen nicht, was der Inhalt ist, nur daß die Teile mir wichtig sind und sicher aufbewahrt werden sollten, falls mir etwas passieren sollte. Soviel Vertrauen muss sein und ich kontrolliere so einmal im Jahr oder so, ob die Teile noch da und unversehrt sind.

Eine Info, die alles unauffällig zusammenführt, was wo ist, liegt dann versiegelt bei meinem letzten Willen im Bankschließfach und noch an einem weiteren Ort, der für die Verwandten relativ offensichtlich ist.

Es hat vielleicht noch Macken, aber alles auszubügeln, erhöht die Komplexität und den Aufwand übergebührlich. Ich finde es auch so schon aufwändig genug und so viele Coins habe ich dann doch nicht und man kann auch die Kirche im Dorfe belassen.

Aber als Hodler und Shitcoin-Minimalist kann ja auch aus vergleichsweise wenigen Coins viel Fiat werden, wenn es mit Bitcoin weiter langfristig gesehen aufwärts geht. Und daran glaube ich...

It works for Bitcoin Core because for Core the wallet backup is the wallet file. For a descriptor wallet you could make a backup of all the descriptor details and you would be able to perfectly recreate the original wallet. But copying descriptors isn't exactly human-friendly and not something that Core offers as a backup solution.

Other HD wallets that don't allow any import of solitary private keys not related to the HD wallet tell you to backup the mnemonic recovery words, optional mnemonic passphrase if that was used too, because that together with the derivation path (if it differs from standard) is all you need to recover your HD wallet.

If you add unrelated private keys to such a HD wallet, you would need to backup the wallet file because the mnemonic recovery words can't recreate the added unrelated private keys and their individual address type derivation.

With file backups there are several issues, in particular if you don't have file backups that represent all your private key pool that may have changed over time if you have added private keys at different points in the past.

You make this claim based on what exactly? Your gutt fealing? Tin-foil hat conspiracy theories? Something more serious?

My intend is not to make fun of you, but really understand how you come to such a statement. What do you know that we or rather I don't? Please, elaborate!

I run Bitcoin Core node headless on one or sometimes two Raspi 4B with 8GiB RAM, depending on what I want to do. Usually I also run Electrs or Fulcrum as personal Electrum servers.

Bitcoin Core as full unpruned node and Electrs now barely fit on a 1TB SSD for the Raspi 4B. Fulcrum fully synced as noticeably faster Electrum server doesn't fit with unpruned Bitcoin Core anymore on a 1TB SSD but needs a 2TB SSD which is then comfortably big enough for quite some time in the future.

For me this is fast enough to use an Electrum or Sparrow wallet connected to my personal Electrum server (I care about address privacy of my wallets).

The Raspi 4B with 8GiB can run with no issues 24/7, consumes ~4-5W on average (or even little less than that) with a suitable USB3-SATA-adaptor for a low power SATA SSD (the Raspi 4B has a total power budget for all USB ports combined of ~6W, power hungry SSDs will eventually give you headaches and unstable operation).

If I had to buy a Raspi now, I'd take a Raspi 5 with 16GiB RAM and attach a 2TB NVMe M.2 SSD with a suitable daughter board. This setup is faster and should work fine 24/7 reliably. You could also run it with GUI if you need to.

Almost any Mini-PC should also work fine and you have more options for RAM size and how much processing umpf you want.

Yes, I've seen in the Sparrow import wallet options for descriptors that Sparrow wants then to import a Bitcoin Core file. I'm assuming that it reads descriptors from there, still haven't tried it.

I know that you can create a Bitcoin Core wallet based on whatever descriptors Core supports and that includes individual private key descriptors.

Sparrow can still fail with import of such a Bitcoin Core descriptor wallet same as it fails with import of an Electrum wallet when the latter is made up of imported individual private keys as nc50lc pointed out.

It's maybe worth mentioning why it's not possible to import a WIF private key into Sparrow (I'm not yet convinced it's not possible, see below) and in some cases also not in Electrum.

If a wallet already exists, newer ones are usually a HD wallet. You can't import an unrelated private key to such a HD wallet, because the unrelated private key won't be backed up by the wallet's mnemonic recovery words.

This is the reason why e.g. you can't import a WIF key to an already created Electrum HD wallet. You can only sweep a WIF key in such cases.


I haven't tried myself yet, but I think it should be possible to import a wallet based on descriptors in Sparrow. You would have to convert your WIF private key to a descriptor and the open question remains, if Sparrow accepts such single private key descriptors. I wil have to check this later when I find time for it.

The infection pathway is not so new. Publish an app of popular demand that's actually working well to gain a user base quickly. Publish an update to the app that has some download dropper malicious code that passed app store detection. This dropper code then downloads the main malicious code which does the main nasty malware things (the article speaks about, it installs a seperate malicious app on the target's Android mobile phone; I have questions to this).

I have a few points to highlight where possibly mobile phone users are a bit reckless and should question their opsec while using their phones for banking, crypto coin stuff and other important stuff.

You're reckless (less politely: stupid) if you install a file viewer app from a developer with name "Hybrid Cars Simulator, Drift & Racing" as shown by OP and taken from linked article. Well, this is an obviously suspicious name case. A less suspicious developer name wouldn't ring alarm bells.

The malicious actors who are well funded often buy existing developer accounts because those accounts likely have less trouble to publish new apps or updates to existing apps which in some cases are renamed to something that suits the malicious actor better for a new malware campaign.

Don't install apps that look fancy or are just trending because they're free. Do you really need a new app on your device where you basically can't really trust the developer. Be caucious if a developer publishes new apps in completely different app genres compared to its past app publishing history. App reviews don't help too much because most of them could be fake and bought.


Normally an app can't install another app without special permission that needs to be granted. Normal Android will ask you if you really want to allow this and/or that you need to change some permissions to allow an app to install other apps (e.g. F-Droid app store need such special permissions).

An Android mobile phone user shouldn't grant permissions that (s)he doesn't understand why they're necessary. Especially when the permissions don't seem appropriate to an app's primary purpose. Yes, I know, this is not easy to answer and distinguish.

The malicious dropper code could of course exploit some bugs in Android. But such bugs are precious, especially when they're so-called zero-days (yet unknown/non-published new exploits). Malware that uses zero-days, publishes those new attack vectors to the malware research community when they're caught in-the-wild.


As temporary final remark: do you really think it's wise to use your daily driver mobile phone, with all the app shit users commonly install on such daily use devices, for mobile banking, mobile crypto wallets, anything else of considerable value?

If you really need and want to do mobile banking and mobile crypto wallet or trading stuff, I would highly recommend to use a separate mobile device where you de-install anything that's not required for mobile banking and crypto wallets. Don't use this separate mobile for daily stuff, only for those narrowed special use cases.

Personally, I don't do banking stuff on my mobile phone, I do this from my Linux desktop. My mobile phone wallets only have pocket money amounts, rarely more than, say equiv. to 100-300 dollars worth of value.

For a wallet to be and remain cold on a Tails persistent partition, that Tails would need to remain offline as long as the wallet is stored in Tails. Such a cold wallet could only interact with an online watch-only version of it via PSBT files. This is more tediuous than using a hardware wallet where most of them don't have any network communication ability (they interact with an online piece of wallet software in a limited and secured way, never revealing private keys to the online software, so that such a hardwallet is effectively cold).

If you use Tails with an encrypted persistent partition, do not forget to properly document your partition encryption passphrase, multiple redundant backup copies are recommended. Also don't forget to backup your wallet's mnemonic recovery words with redundant copies. You should never loose all details required to restore your wallet properly.

I highly recommend to verify such a restore properly and safely. Only if you succeed with restore, you know you have a working backup. Don't fool yourself, precious coins are at stake.

How about you tag @theymos properly, so he gets notified?