Topic: Signed raw transaction - page 2. (Read 534 times)

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