Old transaction safe to publish?

[s2]

Would like some help on a weird question...

I have an old transaction I generated about 2 years ago on an offline computer however I never published it.  The intention was that I'd keep this transaction and post it in future when I want to access the paper wallet funds.

It was to transfer 0.1 BTC from my paper wallet to my hardware wallet address.

I've not spent the paper wallet and my hardware wallet is still the same, is there any risk in publishing this old transaction? 

Is there a date/timestamp in there that may cause miners to reject it and/or cause it to linger in the mempool meaning I can't spend it for some reason if this fails?

[ranochigo]

Transactions do not contain any timestamp, and hence it doesn't matter when you crafted and signed your transaction. However, several years ago, some clients were generated high s signatures which was non-conical and thus those transactions were not standard and unable to be relayed.

Check the transactions for the fees/byte and whether the recipient of the funds is still correct. Even if it's somehow invalid, it wouldn't be stuck at all, it'll just be as if it has never been sent. If you do have a low fee without opt-in RBF enabled, then it could be possible for your funds to be unconfirmed for a period of time. As long as you still have access to the private keys of the paper wallet, you will be fine.

[o_e_l_e_o]

As ranochigo says, transactions do not contain a timestamp, but they do contain a locktime. This essentially dictates the earliest time (in either Unix time or in block height) that your transaction can be broadcast. Your wallet would most likely have set this to either the current block when you created the transaction, or to 0 (therefore removing the limit entirely). Provided you didn't mess around with this value when creating your transaction, then it won't cause you any problems. Either way, your transaction will broadcast just fine, but if your wallet set it to the current block at the time of creating the transaction, then anyone viewing the transaction will be able to deduce that you likely signed it years ago and are only just broadcasting it now. Whether or not that bothers you is up to you to decide.

The only issue I can foresee is the fees. Fees are very high at the moment so I suspect your transaction will sit unconfirmed in the mempool for days or weeks unless you signed it with a particularly high fee for some reason. You can either wait patiently, use CPFP from your hardware wallet, or import your paper wallet and sign a new transaction with a higher fee.

[s2]

Thanks all, much appreciated.  Will try the electrum verification route first as it was a real hassle doing the offline transaction safely last time so rather not have to do that again but may need to if the tx fees are too low like you say.

[NotATether]

download last Electrum version verify signature and add your private key/wallet seed.

Correction: paper wallets are almost always only made with private keys, using a seed phrase when you create a paper wallet is especially uncommon so it doesn't even need to be mentioned.

There is no reason for you to broadcast that Old transaction even though broadcasting it will not pose a risk as you have the private key for both addresses.

...

Sign a new message and then broadcast it.

Why though? The point of having a signed transaction stored away is so that you can safely broadcast it in case of an emergency.

For example an armed robber breaking into your house where you'd have enough time to broadcast that signed transaction (assuming you have wallet software handy and the tx was stored electronically!) but you would not have enough time to download Electrum, verify it, import your private key, fill in a receiving address that you have to recall from your head or notes, then then enter a password you made up to sign the transaction because you wouldn't put your cold storage at risk by not password-protecting a temporary wallet (right?) and finally broadcast the transaction before he comes to you and interrupts this demands at gunpoint that you send it all to him.

Each time you load a private key, especially for a paper wallet, into wallet software, you are exposing it to risk even if that amount of risk is small. When it holds very large sums of bitcoin it is better not to do it unnecessarily.

[pooya87]

is there any risk in publishing this old transaction? 

It depends on what you used to sign the transaction in the past. Many years ago there have been some tools that had bugs that led to generation of weak signatures that could be used to reveal the private key. One example is the old blockchain.info wallet. In that case the safe approach would be to import your private key into one of the popular wallets (such as Electrum) and sign the transaction again.
But if you used a decent tool such as bitcoin core to sign the transaction, there is nothing to worry about.

[PrimeNumber7]

Thanks all, much appreciated.  Will try the electrum verification route first as it was a real hassle doing the offline transaction safely last time so rather not have to do that again but may need to if the tx fees are too low like you say.

If you are concerned with security risks associated with creating/signing a second transaction, it may be best to broadcast your current transaction (assuming it does not violate any rules implemented in various soft-forks implemented subsequent to you creating the transaction), and use a Child-Pays-for-Parent (CPFP) transaction to effectively increase the fee paid. This will result in you paying more in total fees, but would prevent you from having to bear the risks of exposing your private key of your offline wallet again.

[xenon131]

However, several years ago, some clients were generated high s signatures which was non-conical and thus those transactions were not standard and unable to be relayed.

 such "sf".

[o_e_l_e_o]

Will try the electrum verification route first as it was a real hassle doing the offline transaction safely last time so rather not have to do that again but may need to if the tx fees are too low like you say.

Although more time consuming, it is the safest way to make your transaction. As soon as you import your private key to a computer with an internet connection, there is always a risk of compromise. I would at least import your transaction first to see what fee it is paying and whether or not you would be happy with that fee. If not, then I would opt to either import your wallet to an airgapped computer or use CPFP as I mentioned above, just to be sure of the safety of your coins.

Correction: paper wallets are almost always only made with private keys, using a seed phrase when you create a paper wallet is especially uncommon so it doesn't even need to be mentioned.

I would disagree with that statement. I have a number of what I would call "paper wallets" (i.e. they exist on paper only and nowhere else), and all of them are comprised of written down seed phrases as opposed to printed out private keys. I don't see any disadvantage of using a seed phrase compared to private key in this instance, whereas there are numerous advantages such as being able to hand write instead of using a printer with a far lower chance of making an error, not having to sweep the entire wallet each time you want to spend from it, no concerns regarding change addresses, being able to deposit coins to an already created wallet without having to reuse addresses, etc.

[ranochigo]

Do you mean that  the signature factor  used to divide the message digest might be non-canonical in transactions generated by "old" clients? If yes,  could you refer to real transaction made in the past that has such "sf".

This: https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki#Low_S_values_in_signatures. I think it was replaced by BIP66 for the enforcement of specific DERs signature though.

It was a factor causing the transaction ID to be malleable during that period of time.

[HCP]

For example an armed robber breaking into your house where you'd have enough time to broadcast that signed transaction (assuming you have wallet software handy and the tx was stored electronically!) but you would not have enough time to download Electrum, verify it, import your private key, fill in a receiving address that you have to recall from your head or notes, then then enter a password you made up to sign the transaction because you wouldn't put your cold storage at risk by not password-protecting a temporary wallet (right?) and finally broadcast the transaction before he comes to you and interrupts this demands at gunpoint that you send it all to him.

TBH, that's a pretty ridiculous scenario... I doubt the first thought in most peoples mind when an armed robber is attempting to break into their house is "I must broadcast that signed transaction I had laying around all these years and send those funds away".

I would think it more likely that it would usually be "call the police"... or "get my gun/bat/knife/blunt object" etc.

Having unbroadcast, signed transactions should be a tool for "urgent" situations.