You can use Omniwallet, or if you don't mind using a desktop application, you could install electrum and then export the the PKs.


Source? You should be fine if you run it offline.

What client are you using and is rbf configured?

Can you share the txid here also it'll help anyone to send you a new tx to sign if you don't want to do it yourself? If the fee is above 180 sats per byte you might need to be quick, if it's below then you'll be fine for a few hours...

No, the transaction file does not contain your private key. It contains your public key(s) only. These cannot be used to steal your coins unless you have exposed your private keys through another means. If someone else generated your vanity address for you, for example, then they will have access to your private key(s) and your coins.

If the transaction has been confirmed for several hours then it will have >10 confirmations by now and be essentially impossible to reverse. The concern about master public keys doesn't apply in this case since you are using a single vanity address rather than a hierarchical deterministic wallet.

Assuming the "txn file" was created by Electrum and the transaction is unsigned you may want to look here: https://bitcointalk.org/index.php?topic=5082785.0
There are both privacy and security concerns:
Privacy: you are revealing your entire list of past, present and future public keys (hence addresses).
Security: revealing a single private key from that wallet some day will reveal all your private keys.

Yes. If your transaction has confirmed and has a reasonable number of confirmations (most people would say greater than 6), then there is nothing anyone can do to reverse it short of attacking the entire bitcoin network, which would be hugely costly.

Even if it hadn't been confirmed, sharing a signed transaction file would not be dangerous to the security of your coins. This is essentially what you do when you broadcast a transaction to the network - you share your signed transaction with the nodes and miners.

Depends what you mean by "dangerous".

Your bitcoin is not at risk of being stolen if you disclose a transaction file. If you haven't signed the transaction, then a malicious party with access to the file can't do anything with it except read the contents. If you have already signed the transaction, then the most a malicious party could do would be to broadcast it, meaning the transaction you signed would be sent to nodes and miners, and the bitcoin you sent would end up at its intended destination. A malicious third party is unable to change a signed transaction in a way which allows them to steal your cleans (there are ways a signed transaction can be changed and yet remain valid, but they do not allow your bitcoins to be stolen or sent to anywhere other than the addresses you specified).

There is a privacy risk, however. If someone gets their hands on a transaction file they know was generated by you, then they know the inputs within that file almost certainly belong to you, and can use that information to track your spending and discover other addresses which you own.

You could potentially be waiting for quite a while (as in hours if not days):


There are currently some 30+ blocks worth of transactions all sitting at the 2+ sats/byte type fee range... which is about what your #2 & #3 transactions were set to... #4 is higher, but is effectively a CPFP of #3 (which was quite big at 635 bytes)... so with #4 being 258 bytes... the combined size is 893 bytes with a combined fee of 0.00002528 + 0.00003375 = 0.00005903... which only gives ~6 sats/byte... or 1.5 sats/WU.

If you're really lucky, and it stays "quiet" and there aren't many more transactions broadcast... #3 and #4 might confirm in the next hour or so... but #2 could stay unconfirmed for quite a bit longer!

First you need to figure out what you are trying to achieve. You have sent a variety of coins from a variety of addresses to the 1pixedi... address, but then you've split one of the inputs at that address in to two inputs, both going to the same address. This makes no sense. If anything, it is the exact opposite of what you want to do, which is to consolidate all your inputs in to one. There is no point in splitting coins in to multiple outputs at the same address.

If you want to confirm all your transactions, then you need to make a transaction which spends everything at the 1pixedi... address, and sends it to another address. However, since you have a chain of 4 unconfirmed transactions, your new fee will need to be enough to push the combined 5 transactions (the 4 old ones and the new one you are about to make) up to a high combined total fee, which will be expensive.

The combined size of your 4 unconfirmed transaction is (530 + 635 + 225 + 258) = 1638 bytes. Your new transaction of 3 legacy inputs and one legacy output is going to be 488 bytes (give or take), giving a combined total of 2126 bytes. To confirm that in the next block you are looking at a combined fee in the region of 100 sats/vbyte, which is 212,600 sats. Ignoring the fees you have paid on the previous transactions (which are a negligible total of around 10,000 sats), your new transaction will therefore need a fee of 212,600/488 = 435 sats/vbyte.

Given that you've already waited 5 hours for 2 of the transactions, and over a day for the other 2, my advice would simply be to wait longer. The mempool is gradually emptying as it tends to do at weekends, and there is a reasonable chance they will confirm within the next 6 hours or so even if you do nothing.

Then you can't use RBF (replace-by-fee). The only thing you can do is spending those unconfirmed coins again (if possible; you can even send them to yourself again) with a higher fee than the original transaction - it is called CPFP (Child Pays For Parent). If you don't need those coins to confirm urgently then you should wait. The mempool is clearing up.