 Show Posts
|
|
Pages: [1]
|
You cannot back up the wallet by copying without shutting down the software first. The backupwallet rpc lets you back up while running.
I understood as follows. In case with copy command, If the file(wallet.dat) is being written, it will cause problems. Is this okay? |
|
|
|
Why not use unix "copy" command and then overwrite "wallet.dat" ?
Because not everyone uses Linux/Unix terminal and the guide mention how to backup wallet from bitcoin-cliIs there anything wrong with this approach ?
AFAIK no, perhaps only permission to copy file with copy/ cp command Thank you for the quick response ! I am happy to hear your experience. I have one more question about backup "wallet.dat". I am running a full node bitcoin server. And I hope to backup "wallet.dat" every day by using cron which kicks shell scripts. In this shell script, using "backupwallet" command is better than "copy" command ? There are hundreds of both singlesig addresses and multisig address in this "wallet.dat". Is it true that using wallet.dat command takes much time than using copy command ? Which do you recommend for backup ? |
|
|
|
|
Q: What is a difference between bitcoin-core "backupwallet(importwallet)" command and unix "copy" command ?
I'm planning to move "wallet.dat" to new server bought a few days ago.
I looked over books how to move "wallet.dat" and understood as below.
--「Mastering Bicoin」 Andreas M. Antonopoulos----
Commands: backupwallet, importwallet, dumpwallet
Next, we will practice creating a wallet backup file and then restoring the wallet from
the backup file. Use the backupwallet command to back up, providing the filename as
the parameter. Here we back up the wallet to the file wallet.backup:
$ bitcoin-cli backupwallet wallet.backup
$
Now, to restore the backup file, use the importwallet command. If your wallet is locked,
you will need to unlock it first (see walletpassphrase in the preceding section) in order
to import the backup file:
$ bitcoin-cli importwallet wallet.backup
$
---------------------------------------------------------------
I have a question.
Why not use unix "copy" command and then overwrite "wallet.dat" ?
Is there anything wrong with this approach ?
|
|
|
|
Correct. Just restart without -reindex
Than you for your replay! I will restart bitcoind without -reindex, and then try to sendrawtransaction agan. |
|
|
|
Sure, you can do that, but that does not mean that your transactions will actually be relayed across the network. Just because you have this in your config does not mean that your peers will so they likely won't accept any transactions once you reach the default limit. Your local config only applies to your node. Changing this just means the transactions will sit in your node's mempool (and not be relayed across the network). They won't even be rebroadcast by your node because nodes don't do that.
Tank you for the explanation. I understand. If I override the default limit , this applies only to my node. Instead of trying to get long unconfirmed transaction chains to be relayed, you should be rethinking why you are generating long unconfirmed transaction chains and thinking of ways that you can avoid making long unconfirmed transaction chains instead.
Thank you for your advice. I will try to improve it. No need to do that. This has nothing to do with the databases.
Does this means that there is no need for adding reindex options ? 2. Restart bitcoind (← without adding -reindex options) |
|
|
|
Thank you for your answer. Surely you are right. There are too many "unconfirmed" parent transactions. Can I override the default limit of 25 unconfirmed transactions by adding to cofiguration file as below. 1. Additionally write to configuration file. bitcoin.conf----------------------- limitancestorcount=1000 ← e.g. 1000 limitdescedantcount=1000 ← e.g. 1000 ---------------------------------- 2. Restart bitcoind with -reindex options. Then try to sendrawtransaction again. How about this ? |
|
|
|
|
I'm running full node bitcoin server and use bitcoin-core RPC library.
I sent transaction by using rpc command 'sendrawtransaction'
but the result returned err as below.
「64: too-long-mempool-chain」
So I checked memopool by using rpc command 'getmempoolinfo', then returned as follows.
{
"size": 0,
"bytes": 0,
"usage": 96,
"maxmempool": 300000000,
"mempoolminfee": 0.00000000
}
What should I do for sending transaction successfully ?
Additinal information.
I use Bitcoin Core : version 0.13
|
|
|
|
If I create multisigaddress by using createmultisig command, is it true that nobodoy can get both privatekeys and redeemscript associated with this multisigaddress from this coins server ?
If the private keys are not stored on the server, then yes. However there is no such security guarantee. Createmultisig just prevents the generated redeemScript from being added to your wallet; the private keys for the public keys in that redeemScript could still be part of the wallet. Thank you for your answer. When I create multisigaddress by using 'createmultisig' command in my full node coin server which I built, is it possible to remove private keys associated with this multisigaddress from this server for the purpose of security ? If possible,how should I do ? |
|
|
|
The short answer is that createmultisig basically just combines the inputs and then outputs the constructed MultiSig (ie. redeemscript and address etc) onto the console...
Whereas, addmultisigaddress takes the inputs, constructs the MultiSig... and then stores it all in your wallet file for you.
This is why "ismine" is "True" after using addmultsigaddress, because it is now actually stored in your wallet. Whereas with createmultisig, it has just output the information for you, but nothing is saved to your wallet file, so "ismine" = false.
Thak you for your well understood answer. I understood the difference between createmultisig command and addmultisigaddress command. So I hava one more question. If I create multisigaddress by using createmultisig command, is it true that nobodoy can get both privatekeys and redeemscript associated with this multisigaddress from this coins server ?If so, this command is much more secure so log as I remember these privatekeys and redeemscript. |
|
|
|
|
I use bitcoin core api and want to create multisigaddress with this api.
So I have two question about multisigaddress.
I created 2 multisigaddresses by different two commands;
*These address were '2 of 3' multisigaddresses.
One address was created by using 'createmultisig' command as follows.
bitcoin-cli createmultisig 2 '''
[
"publicKey_1", ← These were dummy keys
"publicKey_2",
"publicKey_3"
]
'''
Return multisigaddress and redeemscript.
Then I checked this address by validateaddress command.
bitcoin-cli validateaddress xxxxxxxxxxxxx ←dummy multisig address
Return
{
"isvalid": true,
"address": "xxxxxxxxxxxxxxxxxx",
"scriptPubKey": "a9142c3647f41008a9a4098155d5d9ccc29d66d10ae787",
"ismine": false,
"iswatchonly": false, ← Why false ?
"isscript": true
}
The other address was created by using 'addmultisigaddress' command as follows.
bitcoin-cli addmultisigaddress \
2 \
'''
[
"publicKey_4", ← These were dummy keys
"publicKey_5",
"publicKey_6"
]
'''
Return multisigaddress.
Then I checked this address by validateaddress command.
bitcoin-cli validateaddress YYYYYYYYYYYYYYYYYYY ←dummy multisig address
Return
{
"isvalid": true,
"address": "YYYYYYYYYYYYYYYYYYY",
"scriptPubKey": "a914e435fa2df32285ab3f3532001ee8eae0173b6ab487",
"ismine": true, ← attention!
"iswatchonly": false,
"isscript": true,
"script": "multisig",
"hex": "5221037fb9d7a84228a2ad880e0ddb490f6b215d54d59b5da009eb6965213148941bed21025f78b 5a4bea95ad92a82bfbb1a9bae7e7ce631e425937fff0d2953c1543e19212102a6f29806b8340ed9 b512e463944b9b02f48c4ce0d0f49d87472caa03c0deae7e53ae",
"addresses": [
"singlesigaddress_1", ← These are dummy addresses by which I created multisigaddress
"singlesigaddress_2",
"singlesigaddress_3"
],
"sigsrequired": 2,
"account": ""
}
As mentioned above, "hex" is redeemscript and "address" consists of these three "addresses".
Q1
What is the difference between createmultisig and addmultisigaddress?
Q2
If I create multisigaddress by 'createmultisig' command and then forget private keys of this multisigaddress,
how can I get these private keys ?
Not knowing these singlesig addresses, I can't use dumpprivkey command.
If aynone knows these question, please answear me.
|
|
|
|
Yes. If you are the sender and own the private keys being used to spend the inputs. Take note that the transaction ID will not be the same if you change any of the variable (ie. output amount) in the transaction.
If you don't own all of the private keys in that transaction, then no. Unless the transaction is in you mempool, you need his keys to sign and get the signed raw transaction.
Thanks you for your kind advise ! I am the sender and own the private keys being used to spend the inputs. And I did NOT change any of the variable in the transaction. So I will try to rebroadcast(i.e. create, sign, and send transaction ) and watch the transaction appear in mempool again. |
|
|
|
Thanks you for good advise.  I have one more question. I am running bitcoin full node server. So from this server, I hope to reboadcast unconfirmed transaction deleted from memopool.
What should I do ?If I just try to create,sign,and send transaction by using the same utxos as before again, can I rebroadcast successfully ? |
|
|
|
|
★ How to restore unconfirmed transaction deleted from memopool ?
A few days ago, my unconfrimed transaction no miner picked up was deleted ( or disapeared ) from memopool;
If this transaction can be restored in mempool again, I will resend with this transaction by adding a few higher fees.
So I want to know how to restore this deleted transaction in memopool again.
|
|
|
|
Thank you for your prompt reply. If someone loses their private keys, then they will be unable to spend their bitcoins. The bitcoins effectively don't move until the transaction is confirmed. Therefore, they are still accessible to the sender until the transaction confirms. Once the transaction is confirmed, the bitcoins are only accessible to the receiver. There is no intermediate place for the bitcoins. They are either available to the sender or to the receiver as long as they have their private keys.
In this case I have one more question. If the sender make the second transaction of which inputs are the first transaction txid to accomplish the first transaction and re-send the second transaction with higher fee compare to normal transaction size, then will some miners include the second transaction into blockchain? If so,the receiver will be able to get bitcoins. Is this right? |
|
|
|
|
