|
There have been some issues with Armory managing Bitcoin Core. These should be fixed in the next version but for now, just run Bitcoin Core manually.
|
|
|
|
|
Your question is incomprehensible. What are you trying to do? If you are trying to set those options for you software, you set them when you run the program, not when you compile it. Those are command line arguments so you set them via the command that you run to start the programs. Or you can put them in the bitcoin.conf file and that will set those options as well.
|
|
|
|
|
It's in bitcoind's wallet. getnewaddress is an RPC call that works with the built-in wallet, and IIRC will be disabled if wallet functionality is disabled. To send the Bitcoin, there are various send* RPCs as well. Just do bitcoin-cli help to get info on what commands are available, and bitcoin-cli help <command> will give you detailed help for whatever command you want.
|
|
|
|
Makes more sense. Core issue is now more pressing, however. No need to delete anything unless you suspect corruption. Just run with -reindex to force a reindex.
I'm not seeing anything relevant in debug.log. Put simply, Core isn't retaining the most recent ~50 blocks between restarts. The amount of missing blocks varies each restart. Provoked by Core not shutting down cleanly when it was tx scanning the wallet (I'd forgotten to add the -disablewallet argument, was being impatient and so interrrupted the Rescan) Let's move this part of the discussion to Tech Support.
Back to topic. I am currently testing send and receiving to and from all three address types on testnet. For some reason, when I receive, it suddenly switches back to "Dashboard Scanning Mode" and it doesn't leave that mode even though DB says scanning has completed. Also, this switch only happened when a new block arrived, but it was not the first block that had arrived with Armory started. Restarting the client fixed the problem. It also seems that I am getting the "missing server option from the conf file" error even though that option is set. Actually it wasn't set, but I think that is because Armory is looking for a bitcoin.conf in <datadir>/testnet3 instead of in <datadir> as I'm pretty sure Core still uses the one in <datadir> This is the error and backtrace I get from just attempting to start ArmoryDB now: Thread 4 "ArmoryDB" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffda81c700 (LWP 7888)]
__GI__IO_fwrite (buf=0x7fffd00018f0, size=281, count=1, fp=0x0) at iofwrite.c:37
37 iofwrite.c: No such file or directory.
(gdb) backtrace
#0 __GI__IO_fwrite (buf=0x7fffd00018f0, size=281, count=1, fp=0x0) at iofwrite.c:37
#1 0x000000000067de93 in HttpSocket::makePacket (this=0xb20bb0, packet=0x7fffda81b2d0,
msg=0x7fffd0002e60 "{\"id\": 0, \"jsonrpc\": \"2.0\", \"method\": \"getinfo\", \"params\": []}")
at StringSockets.cpp:83
#2 0x000000000067e5d2 in HttpSocket::writeAndRead (this=0xb20bb0,
msg="{\"id\": 0, \"jsonrpc\": \"2.0\", \"method\": \"getinfo\", \"params\": []}", sockfd=2147483647)
at StringSockets.cpp:123
#3 0x000000000066d952 in NodeRPC::testConnection (this=0xb20a60) at nodeRPC.cpp:70
#4 0x000000000066d6fc in NodeRPC::setupConnection (this=0xb20a60) at nodeRPC.cpp:51
#5 0x000000000066d81c in NodeRPC::testConnection (this=0xb20a60) at nodeRPC.cpp:60
#6 0x0000000000467302 in BlockDataManager::getNodeStatus (this=0xb0d410) at BlockUtils.cpp:1242
#7 0x00000000004d9dc9 in BlockDataManagerThread::<lambda()>::operator()(void) const (__closure=0x7fffda81bd30)
at BDM_mainthread.cpp:141
#8 0x00000000004db708 in std::_Function_handler<void(), BlockDataManagerThread::run()::<lambda()> >::_M_invoke(const std::_Any_data &) (__functor=...) at /usr/include/c++/5/functional:1871
#9 0x000000000043a5e4 in std::function<void ()>::operator()() const (this=0x7fffda81bd30)
at /usr/include/c++/5/functional:2267
#10 0x00000000006701d2 in NodeRPC::waitOnChainSync(std::function<void ()>) (this=0xb20a60, callbck=...)
at nodeRPC.cpp:277
#11 0x00000000004da6ce in BlockDataManagerThread::run (this=0x7fffffffd970) at BDM_mainthread.cpp:154
#12 0x00000000004db214 in BlockDataManagerThread::thrun (_self=0x7fffffffd970) at BDM_mainthread.cpp:302
#13 0x00000000004e05ba in std::_Bind_simple<void* (*(BlockDataManagerThread*))(void*)>::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=0xb218b8) at /usr/include/c++/5/functional:1531
#14 0x00000000004e04c4 in std::_Bind_simple<void* (*(BlockDataManagerThread*))(void*)>::operator()() (
this=0xb218b8) at /usr/include/c++/5/functional:1520
#15 0x00000000004e0454 in std::thread::_Impl<std::_Bind_simple<void* (*(BlockDataManagerThread*))(void*)> >::_M_run() (this=0xb218a0) at /usr/include/c++/5/thread:115
#16 0x00007ffff78f0c80 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#17 0x00007ffff7bc16ba in start_thread (arg=0x7fffda81c700) at pthread_create.c:333
#18 0x00007ffff705682d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
I am getting the same error that Carlton is getting when hitting the send button. Here is the backtrace from gdb: (gdb) backtrace
#0 __GI__IO_fwrite (buf=0x7fff70017d80, size=163, count=1, fp=0x0) at iofwrite.c:37
#1 0x000000000056a57c in HttpSocket::makePacket(char**, char const*) ()
#2 0x000000000056a9a9 in HttpSocket::writeAndRead(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, int) ()
#3 0x0000000000562b56 in NodeRPC::getFeeByte(unsigned int) ()
#4 0x000000000051d997 in std::_Function_handler<Arguments (std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, Arguments&), BDV_Server_Object::buildMethodMap()::{lambda(std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, Arguments&)#24}>::_M_invoke(std::_Any_data const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, Arguments&) ()
#5 0x000000000051bd9f in BDV_Server_Object::executeCommand(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, Arguments&) ()
#6 0x000000000052a1a1 in Clients::runCommand(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) ()
#7 0x000000000052a4c0 in FCGI_Server::processRequest(FCGX_Request*) ()
#8 0x00007ffff78f0c80 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#9 0x00007ffff7bc16ba in start_thread (arg=0x7fff7f7fe700) at pthread_create.c:333
#10 0x00007ffff705682d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
It seems that the issue is related to being unable to connect to the RPC server. I will investigate.
Edit: I have resolved the above issues, it was due to some extra debugging code left in the codebase. Here's a PR for it: https://github.com/goatpig/BitcoinArmory/pull/172. Still hunting down bugs in the send dialog, will continue in more posts instead of editing this one. Edit: One of the issues above remains unresolved where the BDM will randomly go back to the scanning phase and needs to be restarted to resolve it. |
|
|
|
Shouldn't just running with -server=1 from bash work? It's not.
No, it specifically looks for server=1 in the bitcoin.conf. I mentioned it to goatpig yesterday on IRC but he said for now it will just look for that line the conf file, later it will probably be changed to just listening for a response from the RPC connection, which it does anyways. I've screwed up my Bitcoin installation anyway, getting strangely random amount of inability to retain the last ~50 blocks, accompanied by SegFault errors, and long startups. Don't tell me, delete the most recent blk.dat files to force a reindex?
No need to delete anything unless you suspect corruption. Just run with -reindex to force a reindex. |
|
|
|
Do I need additional RPC arguments than Armory needed before? Doesn't seem like anything is wrong in .bitcoin/bitcoin.conf
The bitcoin.conf requirements have changed. It now requires that you have server=1 set (although that should have already been set to enable the RPC server anyways) and it will check for it. It does not require rpcuser or rpcpassword to be set. In fact, I recommend that you don't set those. Double check that that option is set in the bitcoin.conf and see if it still fails with it set. I will attempt to test this out on my end as well. |
|
|
|
Not after it crashes -ERROR - 1487006286: (nodeRPC.cpp:162) missing server option in node configuration file That's the only error, I don't think that's the issue. Launch ArmoryQt.py with gdb? Or just for ArmoryDB? That's the issue I think. Your node can't connect to the RPC server of Bitcoin Core because it isn't set to have the RPC server enabled (at least that's what it thinks). However the send needs RPC functions for the fee/byte stuff. |
|
|
|
i notice doge has over 100 billion coins,
and 2 ^63 is around 92 billion,
No it isn't. 2^63 is 9.223372e+18, which is several orders of magnitude than the billions. Where did you get the billion number? |
|
|
|
The main limitation is that JSON, being JavaScript-based
What does JSON have to do with any of this? The Bitcoin protocol does not use JSON anywhere. The field for the value of an output is an int64 so its max value is 2^(64-1). That is how many satoshis you can specify in one output. |
|
|
|
Can you switch off your node half way through pruning/downloading, then restart it and continue pruning/downloading? It doesn't restart from the beginning of the blockchain does it?
If you shut it down properly, it will pick up where it left off. |
|
|
|
|
In the MultiSigDialogs, the MultiSig addresses are being displayed (and maybe stored?) as P2PKH addresses, not P2SH addresses. This is happening with addresses that were already there, and presumably with addresses that are created.
|
|
|
|
From what I understand a pruned node requires a full install, and after everything is done, only then does it prune it's database.
No, that is incorrect. It does it on the fly and maintains the on the disk the size specified by the prune option. The default is -prune=550 and that results in ~2GB taken up overall (there's overhead, the parameter is only just for blockchain data, not databases). With a new pruned node, at no point in time will you have the entire blockchain on your disk even though you will need to download and verify the whole thing. |
|
|
|
Well it is in the mempool and it's 0.13.2 and restarting it doesn't remove it from the mempool... Hmm it could be because I getblocktemplates regularly from the bitcoind... or not :s
Oh, duh, of course its in the mempool, restarting will have the wallet put the transactions back into the mempool on start. You need to set the -walletbroadcast=false command line option when you start it up again in order to prevent that from happening. |
|
|
|
Weird, I've restarted it a few times, perhaps another node that I have whitelisted elsewhere is submitting the transaction immediately once I restart. I'll try isolating it from the network and doing it.
If you run beforehand and it tells you that the transaction is not in the mempool but you still can't abandon it, then there must be something else that is blocking it from being abandoned, but I don't know what that could be. |
|
|
|
That's interesting in itself. What else could possibly be blocking it? bitcoin-cli abandontransaction XX
error code: -5
error message:
Transaction not eligible for abandonment
Anything that would cause this function: https://github.com/bitcoin/bitcoin/blob/02464da5e4aa8c19d4fff3859dcdee822e2af78c/src/wallet/wallet.cpp#L1052 to return false. So it seems the only criteria are that the transaction is not in the mempool and it is not confirmed. So clearing the mempool by restarting the node should work (if you are using any version greater than 0.13.2 i.e. a build of master, then you need to delete mempool.dat in the datadir). |
|
|
|
Abandon transaction is greyed out so presumably it's subject to the same limitations as zap.
No, that means that something else is blocking it from being abandoned. I'm pretty sure it still works in pruned mode as I'm pretty sure I did it before. |
|
|
|
|
Right click the transaction and choose "Abandon transaction" or use the abandontransaction command in the rpc console.
Or you can use something like pywallet and remove the transaction from your wallet file manually.
|
|
|
|
Your derivation paths are wrong. MultiBit uses BIP 44 for derivation paths, not the normal BIP 32 derivation paths. It should be m/44'/0'/0'/k/iIn your original MultiBit wallet, go to Tools > Repair Wallet (or something like that) and see if that works. |
|
|
|
|
Show Posts
