Topic: Signed raw transaction (Read 534 times)

It's valid solution, but complicated and risky (since you expose the private key).

It's easier and safer if you use Electrum to send whole Bitcoin to address generated by Bitcoin Core with 1 sat/vbyte fee. Obviously there are fee concern if you have many input (especially if each input hold small amount of Bitcoin) & privacy concern if you have many address for many usage.

No.
As mentioned earlier in this thread:


You might import all the private keys, as mentioned by NotATether.
However, this is not comparable to actually importing and using a BIP39 mnemonic code.

You can't directly import BIP39 seeds because support for that hasn't been implemented, however you can import it into another wallet, have it generate a bunch of addresses, export the private keys of them all and then import them into Bitcoin Core.

For example, using Electrum, after you import your BIP39 seed you'd go to Wallet > Private Keys > Export and then type a name for the file which it will dump all the private keys in, one key per line.

Then you make a new Bitcoin Core wallet and in its console you would type "importprivkey " for each private key.

Is there any way to import a BIP39 seed to bitcoin core?

This is a very good advise! It will be just hard to explain to newbies.
From my own experience, I would definitely do something similar (sign a raw transaction and save it offline or online) just for an extra safety precaution if for some reason I can't access my wallet any more.

Is the original query still up?
In Bitcoin Core, adding walletbroadcast=0 to your bitcoin.conf file will enable you to create wallet transactions without sending it to your own mempool.

If you use the GUI, simply create a transaction using the send tab but when you click "send", it wont be sent to the network or even your mempool (the transaction will have a Status: 0/unconfirmed, not in memory pool).
Then you can use "Right-click->Copy raw transaction" on the particular transaction to get its signed RAW transaction.

In Bitcoin-cli, sendto will simply create a transaction but wont send it to your mempool; but since it's in the wallet, you can use gettransaction to get its signed raw transaction.

Read the bolded part

Thanks, will try it out.

You can use IanColeman.io to try it (of course only do this online to see how it works, not to create private keys you're going to use):
12 words: plunge snow gorilla wool help income mom kitten volcano warm top girl
First address: 15Q9XKiYX4RZhNLdKYt894o1zguyhufoPZ

Now add BIP39 Passphrase: \q?mpN[!\4`LA5w*
First address: 19mYSjt1VaiGpTop31uEMWJFYbW76MCRJ3

Without the password, the same 12 words lead to different addresses.

Correct.



Correct.
Bitcoin core does not have BIP39 (mnemonic codes) implemented.
While it still creates hierarchical deterministic wallets (BIP32), it does not create a mnemonic code to back it up. The keys have to be backed up by either backing up the master private key or the wallet file.

Understood. And basically, from Seed1, the thief will never find out that I also have a Seed2.
As far as I know, the BIP39 mnemonic is not working yet on bitcoin core, right?

Not sure I understand this. If someone finds my 12 words but not my passphrase, he can see I have a smaller balance than the reality? I have 10 BTC, and without the password, someone sees I only have 0.1 BTC?

It works by basically deriving two different seeds:

Mnemonic Code -> Seed1
Mnemonic Code + passphrase -> Seed2

Seed1 is here used for small amounts. Enough funds to let the thief be happy, while only being a small portion of your total wealth.
Seed2 derives other private keys. These are used to store the majority of your wealth.


It basically allows you to have a "hidden wallet".
Without the passphrase, there is no way to know whether there is such a "hidden wallet".
Any passphrase can be used to derive new seeds. But only the correct one will derive the seed which is being used to derive the private keys for holding the majority of funds.

You can set a password (for instance in Electrum) to extend the mnemonic. So with just 12 words, you'll find your daily spending money worth 2 pizzas. But if you add your own password to the 12 words, you'll get your hodlings worth 2 airplanes.

Of course, your life is more important than your funds. No matter if it is private key or a signed tx, a robber would easily find out how much do you own and if he wants to take this from you... well there is not too much you can do.


Not sure how the BIP39 passphrase protected mnemonic code would not reveal your balance. Care to explain this? Thank you.

I'm not sure.
If someone wants to rob you, it probably doesn't matter whether you have the private key with you or a signed tx which shows how much money you own.

There are 2 cases:
1) If you have the private keys with you, he steals your money
2) If you don't but the burglar sees how much money you own, he might kidnap you if the amount is high enough. And if the amount is pretty low, well then losing this wouldn't matter at all and the whole setup wouldn't be required.

So in the end it might come down to what is more valuable to you: Your money or your health.

So, i'd say this question is not as easy to answer as you might think.


However, having a menmonic code with you, which is protected by a BIP39 passphrase might be a better option here.
The thief would take your mnemonic code and steal all the low amounts of BTC from the wallet. Without the password however, he will never access the large sum of BTC. You lose a little bit of money but don't get kidnapped.




Same applies to a BIP39 passphrase protected mnemonic code. He sees there are only a few bucks, takes or leaves them and you are free. He won't know how much you own. And you saved the majority of your funds.

With your approach.. if he sees the signed transaction, he knows how much money there is. Might be worth to kidnap someone.
And if the signed tx is stored on a 3rd party server, then the user has to rely on them.. And you'd be no longer in the mindset of "don't trust, verify".

Let's forget the 3rd party for now. Do we agree on one thing? If you want to protect against being robbed, it is safer to store 3-4 different signed transactions than to store the private key of wallet / address. Right or wrong?
Of course, you still need to somehow have access to all backup addresses (by storing the private keys of all backup addresses). But, if for some reason someone steals from you the private keys of the backup wallets and he doesn't know you are wealthy, he will probably check the balance, see it is 0 and will go away throwing it, thinking that this was just a test wallet and the probability of receiving funds later to this address are close to 0.

Regarding 1), you can't protect against everything.
If you forgot the locations where you stored the mnemonic code, you might as well forget how the service (your service) is called. Or that exchanges exist. Or you might even forgot that bitcoin exists.
That's a bad argument IMO.

For 2), that's what a N-out-of-M scheme is for. You might have a 4-out-of-7 scheme. Or a 2-out-of-5 or whatever.





Another problem with your approach is, that the user will depend on your 3rd party service.

Given that a user follows what you describe, after not having any possibility to access his coins, he relies on only your 3rd party service to broadcast that signed transaction.
The whole setup allows you to blackmail the user following your advices.

While the user could save the signed transactions himself, the user you are targeting with such a service probably doesn't even know what a signed transaction is.
Even without blackmailing, he relies on you not losing the signed tx.

Moving from proper risk management to relying on a 3rd party is... not how it is supposed to work.

IMHO, the best scenario is to keep the seed phrase in your head / mind, this way, it can't be stolen.
And, if for some reason, you forgot the seed phrase (or a wallet.dat passphrase), you can simply run the already signed transaction that will broadcast your funds to another address you control (and possibly have the keys somewhere else, not in your mind... ), or have it with a third party where you can KYC yourself and get back your funds.

Of course you should not, this was probably an extreme advise that should definitely not be followed by newbies. But if you setup 5 wallets / addresses: wallet A, B, C, D, E and you keep everything on wallet A, (B, C, D, E being all empty wallets) and you sign 4 different transactions to send all balance on wallet A to B, C, D, E (just save, not broadcast it), then you should simply take care of private keys of 4 empty wallets (B, C, D, E). Noone can rob you in this case. And, if you lose (or destroy) private keys of wallet A, you simply broadcast the transaction to any of the other wallets.


You do not need to rely on third party services, this is totally optional. You can keep all the signed raw transactions yourself, you can run your own node and verify every hour if the signed raw transaction is not invalidated and take action every time is needed.
Just think about this way:
a) what can I do if I somehow find the private key of your non-empty wallet (wallet A)? I can send all your funds, wherever I want, right? and you find this out only after all your funds are gone, right?
b) what can I do if I somehow find one of your previously signed transactions? the only thing I can do is to move your funds from your wallet A to one of your other wallets (B, C, D, E) and as soon as this is done you get instantly notified by wallet B that you received funds and you can immediately move away funds from there just to be save.

Which one of the above 2 scenarios are safer in your opinion? a or b?

This problem can be solved by making duplicate or several copies of each piece. Since a single piece on its own cannot be used to recover the seed there is no risk of funds loss if you suspect one of the copies was stolen, since you know where the rest of the pieces are and can just assemble them together and broadcast the bitcoins to a new address. Then you create new secretly-shared papers because the old ones automatically become invalidated after the seed is sweeped, by virtue of having no balance in them.

This is terrible advice! Let's see what someone who knows a thing or two about Bitcoin said:

So instead of "be your own bank" and "not your keys, not your coins", you want people to completely rely on third party services and give them the power to broadcast away your coins whenever they want.

Right, but the secret sharing scheme has two main issues: 1) amnesia (you forgot where did you store one of the 3-4-5 pieces) and 2) what if one of the pieces is somehow damaged.


Exactly! This is why you most probably need to destroy the private keys of wallet A right after you signed the transactions. This way, you only store private keys of wallet B (or simply use wallet B on a custodial exchange / wallet where you can login every time because you previously made the KYC) with 0 balance. With the custodial wallet, there is no risk of the exchange being hacked, because you don't store anything there, you will only use the wallet B if you'll ever need the backup. Best is to sign the same UTXO to more than one address and if you'll ever need the backup transaction just simply broadcast the one that you can surely access.


I am aware of this, read the entire post please. This is why after every transaction (incoming or outgoing), the wallet itself should sign the remaining (unspent) UTXO-s and send the signed transaction to the external service (via an API). Otherwise, this has to be done manually which is definitely inconvenient as you explained. But for a "saving account" (just to use a banking term, that you do not use quite often to spend from it, this could work quite well.

Splitting a mnemonic code or seed like that is not a good idea at all.

Using a secret sharing scheme is superior since it does not leak any information about the secret at all.





If you consider your wallet instantly compromised and lost as soon as someone has access to the mnemonic code (which in itself is correct), then you also should instantly consider all coins gone if wallet A is lost.
You shouldn't differentiate here.
Based on this, the coins would be lost before you could even broadcast the raw transaction.

Further, this only works if you do not make any transaction after signing that "backup transaction".
Once a transaction is done, the transaction will be invalid.
So, in your case, this backup transaction has to be done after each transaction making it quite inconvenient.


In the end:
You can not prepare against loss or theft of your Wallet A.

Because you have to secure it a lot and you can not prepare well for loss or stealing of your private keys.

What's the problem with the current non-custodial Bitcoin?
1. You have to take care of your own seed / private key.
2. You have to store it in a way that nobody could even access the seed, if somebody finds your seed even for a second, he / she can spend it and there is nothing you can do to stop this.
3. If you leave your key somewhere and somebody accesses it, you will not even find this out. So, a thief could spend all your balance immediately or he can wait for days, weeks, months or even years to spend everything you accumulate over the time. If you give me your 12 words seed phrase there is no way you can now if I did something with the words until I wipe out your wallet. For example you have 0.01 BTC now, and a thief will wait until you have it least 1 BTC and spend everything only that time. You think that everything is OK, while in fact somebody is already watching every move you make and just waits for the right time to rob you.
4. Based on point 2 and 3, you really have to hide the seed in a place where nobody can access it (by putting a camera with motion sensors in the room where you store it), as soon as somebody enters the room and potentially see the seed, you have to act fast. From that moment it is a matter of who is faster on spending the funds, you or the thief.
5. If you decide to put the seed to 2 different places to protect from loss (for example one in office safe and one in home safe) just to make sure that if a fire, flood or any other event destroys one of the seed copies, you still have the other one for backup. This is practically double your efforts on point 4, as this time, you have to protect 2 places. More backups, mean more safety precautions!
6. Too many precautions (for example splitting the seed phrase in 2-3-4 locations) will limit the chances of being robbed but can also lead to loss of the seed. Remember, for example if you split your seed phase and store it this way A-B-C-D-E-F (location 1), D-E-F-G-H-I (location 2), G-H-I-J-K-L (location 3), J-K-L-A-B-C (location 4), this has a 1/4 fault tolerance, so if somehow you can't access one of the locations you are still safe, but if you can't access 2 locations from 4, you already have a problem as your seed is gone.

With the proposed solution what you will need:
1. a non custodial wallet where you will hold all your bitcoins (wallet A to be backed up)
2. a custodial wallet where you do the KYC but not hold anything there (this can also be another non custodial wallet) (wallet B where we send your coins if you need to activate backup)
3. an account with us that you will use in case you lose your access to your non custodial wallet (wallet A)

So, basically all your funds will stay forever on the non-custodial wallet but you will need wallet B only if somehow you lose the private key / seed phrase of wallet A. In this case, all you have to do is to login to the backup service and use the previously signed raw transaction (you signed it when you could still access your keys) to send all your funds to your wallet B. Since, wallet B is a custodial service (which is an advantage in this case), for example Coinbase, Bitstamp, etc., you simply login back to this service and voila, you have your bitcoin on the wallet B. If, for some reason, you forget the login and password for your wallet B, with proper KYC proof, they will let you in, and your funds will be safe. Of course, after this is done, you simply withdraw your funds from wallet B to a new wallet you are creating just to not keep your coins on an exchange.

Why would they still have access to wallet B if they lose access to wallet A? If, for instance, you keep wallet B in a different location than wallet A, why don't you just keep a backup of wallet A on the same location?

Thanks for the suggestion, will check it out!

There is a way to accomplish this assuming all your users use Electrum desktop. All you have to do is create a plugin that fetches signed transaction as they are created in the "Send" tab (but not visible there), and run some kind of REST server encrypted with HTTPS and then make a POST request to it with the signed transaction inside.


Electrum plug-in documentation is sparse but here is one of the more informative posts on how to create Electrum plugins: https://bitzuma.com/posts/an-introduction-to-plugin-development-for-the-electrum-bitcoin-wallet/

Thanks for the suggestion. Regarding privacy, you won't need KYC, just an email and a 2FA that would be mandatory. So, if you lose 2FA, you lose the access to the signed transaction (however with proper verification we can let you in with some conditions). You can use any privacy email, again, the worse case scenario is that we broadcast the transaction earlier but basically what we would do is to simply move your funds from wallet A to wallet B. We don't know the private keys to any of your wallets, so it wouldn't make any sense to do this.

You'd probably be looking to incorporate nLockTime in the transaction as well, so the service or anyone else cannot broadcast the transaction before the preset block/unix time. You'll probably be looking at something like GreenAddress, they sign the raw transactions for 2-of-2 account and send it to the user with nLockTime so they can sign and broadcast it if GreenAddress ceases to exist.

There could be some potential privacy concerns with such implementations though, but I assume most users wouldn't really be concerned about that.

Basically a similar service / API will resolve the issue of lost BTCs.

The scenario is very simple:
Setup 2 wallets: a non custodial wallet (wallet A) and a custodial wallet (or another non custodial wallet with different seed / passphrase) (wallet B).
Keep all your coins on your non custodial wallet (wallet A), don't keep anything on wallet B.
Do the KYC / AML procedure on the custodial wallet (wallet B), remember, you need this just in case you'll have to use your custodial wallet when losing access to your non-custodial wallet, hopefully you will never need it.

So, if you lose access to your non custodial wallet (wallet A), simply login to backup service and run the previously signed raw transaction that will send all your funds to wallet B where you can access it.

This scenario is just a piece of mind to recover your funds if you forget passphrase / seed phrase.

I am familiar with bitcoin core and use the cli and RPC part of it. I build a project, where it would be indispensable to get the signed raw transaction of any particular transaction. Think of it this way: you use any wallet (electrum, bitcoin core, etc.) to send bitcoin to an address you want. As soon as this is done, your wallet should simply
1) get all or part of your remaining UTXO-s
2) create a raw transaction to an arbitrary address
3) sign that raw transaction but did not broadcast it just simply send it via an API to an external service

The service is built, and it stores the transaction and verifies every 5-10 minutes (using bitcoin-cli testmempoolaccept) if the transaction can be broadcasted / distributed. If any of the inputs is spent on a future transaction, the service notifies you because the signed transaction got invalidated. So, user gets a notification to sign a new transaction with the valid remaining inputs then copy and paste the new signed transaction to the service.

This can be used to setup a backup address for yourself (on another wallet or a custodial wallet) and if you lose access to your seed or passphrase on any wallet, you can simply login to this service and broadcast the signed transaction which will send all your funds to your backup address.

Right now, the system lets you manually store the signed raw transaction and notifies you once this is invalidated, and you have to manually login to your wallet again, create the new transaction, sign it and copy paste it again to the service.

This would be the best way to backup any of your non-custodial wallets. You do not give up your private keys, you just always sign a transaction to a backup address and store it somewhere externally and use it only if somehow you lose access to your private keys. The worse case scenario that could happen to you is if the said service will broadcast the transaction earlier, so basically all your funds get moved to your backup address.

Well, i'm not 100% sure if you're solving your problem in the most efficient way... But if you're set on creating and signing a transaction locally, then using an external api to broadcast it, you'll probably have to write a small script (bash, perl, python,...)

There are many open source wallets which you can run as a daemon:
core, electrum, btcd,... These can be used to contruct and sign transactions. Your script will have to use the json-rpc interface to achieve this. Then it'll have to connect to one of the api's that allow you to broadcast transactions...

But like @LoyceV already said: why not use core to create, sign AND broadcast transactions? When you broadcast a transaction your peers don't know you're the source of said transaction... You might aswell just be broadcasting a transaction you received from another peer. If you're really worried, you can run your node over tor.


In that case, you don't need an external api...
You're already running core daemons... Just write a script to use the json-rpc interface to query unspent outputs, create an unsigned transaction, unlock your wallet, sign the transaction, save the signed transaction into a relational database.
A second script can be used to retrieve signed transactions from your relational database and broadcast them using your daemon's json-rpc interface.

Really, it's not as hard as it sounds... If you can't do it by yourself, i can give you a quote on a price i'd charge to write such a script... Afterwards you can shop around to see if somebody else gives you a better deal.

I run multiple bitcoin core daemons that I can use any time to broadcast a signed transaction. This is not the issue. I need wallets to automatically send to me a signed transaction that will not be distributed just stored by a centralized system. Depending on certain scenarios the signed transaction will be distributed / broadcasted (or not) using my own node.

Why not run your own Bitcoin Core daemon (bitcoind)?

I am aware of this, this is why it would be great to have an API access.
Does any opensource wallet has the option to programaticaly get the a signed a raw transaction and send to an external service?

Depending on what you're trying to do: you should realize the user can invalidate the signed transaction at any moment by sending one of the inputs to another address.

No, not a learning experience. It is an external service where the only thing we need is the signed raw transaction. Will let you know more later.
The only thing I need is to communicate via an API to the wallet, so once the wallet have the signed transaction, the user won't have to copy this and paste it into the external service we are building, the sending of the signed transaction should be done automatically to our service.

Of course it would be. This is why I asked if it is possible via an API to just send the signed transaction to an external service. So, once the user signs a transaction, he does not have to copy and paste it to an external service, it will be sent via API to an app / service accepted by user.
So, I do not want to broadcast the transaction, just get the signed transaction and decide later what do I want to do with it.

Well, if they'd broadcast the private key, it would be a huuuuuge vulnerability. That being said, electrum, core, wasabi and coinb.in do allow you to broadcast signed transactions in one way or another...
Electrum has a "broadcast" button, or you can use the console... It broadcasts the transaction to the node you're connected to.
Wasabi has a broadcast-wizard. It broadcasts the transaction to zsnark's node over tor.
Core can also broadcasts a signed transaction from the console. It broadcasts it to the other nodes it is connected to
Coinb.in allows you to chose a block explorer that has an api with a function to broadcast transactions, and it has a wizard where you can past a signed transaction and broadcast @the push of a button.

There are tons of block explorers that offer a free api that allows you to broadcast transactions. Some made a nice little webpage where you can past your signed transaction and broadcast it. Timelord2067 even made a list: https://bitcointalksearch.org/topic/guide-broadcast-your-raw-transaction-btc-alts-coins-1938621

Thank you. Do any of these wallets have an API to send the signed transaction to an external service? Only the signed transaction, no private keys or anything else.

 

In electrum it's very easy, but in wasabi it's the easiest since they actually have a wizard to create transactions, and at the end of the wizard they just show you the transaction without broadcasting it (semantics, and personal preference ). The only thing you have to do is use the correct wizard (since there are 2 ways of creating transactions in wasabi, one broadcasts the tx automatically, the other one just shows the signed tx without broadcasting).

Also, OP, bitcoin core can indeed be used to create and sign a transaction without broadcasting it... I don't know if there is a gui wizard available to do this, but you can defenatly do it from the console. Fair warning: if you use the console, things do get a bit complicated... You first create a raw, unsigned transaction, then you use a second command to sign it... The first step needs the list of unspent outputs you'll be using, and a list addresses and values that will be funded using the new unspent outputs. You'll have to calculate the fee by yourself, and make sure everything checks out before broadcasting the transaction. Not very newbie-friendly.

A different option would be to download coinb.in's sourcecode and run it offline when you get to the signing-step... It guides you trough the process of creating a transaction and signing it... Be carefull with your private key tough! don't save it in an unencrypted way, and make sure you reboot your machine after the signing step.

Maybe it's easyer if you tell us why you want to do this? Is it a learning experience? In that case i'd suggest using coinb.in or bitcoin core on the testnet...

It's easiest in Electrum: click Preview, click Sign, and click Copy. The common way to use this is to create an unsigned transaction from an online read-only wallet, then signing the same transaction from an offline wallet that has the private keys.

Is there an easy way to get the signed raw transaction on bitcoin core, electrum wallet or any other popular wallets before or without broadcasting the transaction to the network?