|
Are you trying to restore the wallet while there is a version of it loaded in Armory?
|
|
|
|
1) If I set GETZC_THREADCOUNT for 100 and will have 100 incoming unconfirmed transfers for 10 hours (for example 100 transfers with low fees) does it mean that for 10 hours other ZC transactions will be ignored?
This isn't how it works. This code consumes a thread in the parser thread FIFO pile whenever it receives a ZC from your node (i.e. it receives an inv_msg_tx packet and follows up with a successful getdata on the hash). The thread parses the tx, i.e. it performs all tasks that can be parallelized (like deser and hash operations) then sends the processed tx to the main ZC thread for evaluation (since ZC need to be processed in order of appearance). Once a parser thread is done with its task, it re-registers itself with the FIFO pile. In other words, these threads are constantly recycled, and they do not wait on the tx receiving a confirmation. That's handled by the main scanner code instead. GETZC_THREADCOUNT defines how many of these threads are created on startup. The current code is built to ignore a ZC if there is no parser thread available to handle it. It is built around a custom container (Stack<T>) that throws if it's empty. There is another container, BlockingStack<T>, that as the name suggests, will block when it is empty. I could have had you simply swap to that and ignore the thread count, but since this is untested behavior, I'd rather you bump the thread count for now. 2) Is there any parameter which allow me to spend unconfirmed outputs now (especially I mean unconfirmed change from previous unconfirmed transaction)?
All getUtxo methods take a IGNOREALLZC bool argument (usually the last one, defaulting to true). Pass false there and it should return ZC that are your change. 3) For 2-3 times since yesterday I had some error like "POOLIN:0". It was sometking about connection to DB. Do You know it? I will try to provide You a log for the next time when it will appear.
These are false positives 99% of the time, left that verbose there for my own benefit. Regardless, feel free to post the log if you get to catch another of those. |
|
|
|
|
droak was the OSX maintainer at ATI. He provides me with the builds (I debug the code through a SSH instance on his machine). I fully trust him, for what it's worth.
As for OSX support in general, I simply do not own a Mac, and it is apparently a mess to get OSX going in a VM. ATI had a full time employee, qualified and available to this task (droark). Being alone and without revenue, supporting OSX is a tough requirement for me. If droark didn't volunteer, I would have had to drop OSX support.
My long term plan is to break down the code base in sub modules and at least enable deterministic builds for mission critical libraries. But for now, this is all I've got.
|
|
|
|
|
1) Turn off auto bitcoind in File -> Settings in Armory.
2) Start BitcoinQt manually, let it sync
3) Delete C:\Users\James\AppData\Roaming\Armory\databases.
4) Start Armory. Let it sync
|
|
|
|
I think I've figured it out. I've wrote the ZC code so that each transaction gets processed in its own thread. To prevent lockups on older machines, it is meant to skip ZCs if there are no processing threads available to parse them (i.e. the machine is getting overwhelmed with ZC). There are multiple solutions to this problem and I'll think about adding a CLI arg to force deterministic ZC parsing in the future. For now you can modify this value to increase the amount of parser threads: https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BDM_supportClasses.h#L28You will have to rebuild the binary for this change to take effect. These threads are sleeping until there is data to parse, so increasing that figure shouldn't tax your CPU unless there is a lot of ZC traffic (or you are pushing 50 ZC in bulk to your node). |
|
|
|
Is it a bug? Why all unconfirmed transactions are not visible in history? Can You investigate it or verify whether the problem exists.
What does the global ledger return? If you are missing transactions there too, I'd strongly suggest you try a rebuild & rescan. This looks like a case of DB desync to me so far. Why getScrAddrList() return always empty list? How can I get information aboute addresses (source and destination) from each transaction.
After investigation, this call was deprecated. While the list is being constructed on the DB side, the underlying data isn't passed along over the socket. That call was only used to resolve address comments in an expensive way on the Python side, so I gutted it. In other parts of the code, Tx details are grabbed this way: 1) Grab the tx hash from the ledger entry 2) Get the tx for that ledger entry and create a PyTx object out of it. Your code will look something like this: cppTx = TheBDM.bdv().getTxByHash(txHash)
if cppTx.isInitialized():
pytx = PyTx().unserialize(cppTx.serialize())
3) The PyTx object will have a list of PyTxIn and PyTxOut objects, the pretty print methods for both classes show you how to extract data out of those: https://github.com/goatpig/BitcoinArmory/blob/master/armoryengine/Transaction.py#L513https://github.com/goatpig/BitcoinArmory/blob/master/armoryengine/Transaction.py#L577 |
|
|
|
|
Go over this with droark, he volunteers all the OSX maintenance for Armory. He'll PR the fix to my repo once it's done.
|
|
|
|
Any chance of a 32-bit version 0.95.1?
No. If you want an offline signer in x86, you can use all the way back to 0.92 to sign with 0.95. If you want to go online with an x86 system, you should reconsider that plan to begin with. |
|
|
|
|
Does it get as far as creating a log file? If so, post it.
|
|
|
|
|
1) In your Armory datadir, delete armorylog.txt.
2) Start Armory in offline mode (use the offline shortcut or start it with the --offline command line argument)
3) Go through the restore process. If it fails, post the fresh armorylog.txt
|
|
|
|
|
1) Wait till it's done scanning.
or
2) Restore in offline mode.
|
|
|
|
Question: is there anyone doing QA on the new 95.1 OSX binaries?
Not particularly. IIRC goatpig does not have a mac to do testing with. There is really only one person who contributes mac stuff for Armory. I'm facing a string concatenation error when armory tries to load on this machine. Am unsure if it's my system or armory...
AFAIK, Armory does work on Macs. It could be an issue with mac versions, I don't remember what version Armory was last tested on. I personally debugged 0.95 on Mac. I believe it was on El Capitan. Is there anyway to have sat/b per default selected with a given amount in the settings? Like we can fill in our own default fee per tx?
Next version. |
|
|
|
How do I upload screenshots here. Sorry not that forum savvy.
For future reference, use imgur.com |
|
|
|
Are the build instructions still valid or did you update them somewhere?
https://btcarmory.com/docs/building/These were valid last time I checked. Looks like you don't want to talk about donations
I do not accept donations atm. |
|
|
|
I won't tell here what amount I have in my wallet (maybe just a few Satoshis, maybe millions), but you have to always assume that people fear of losing money (and there could be millions in the wallet). Therefore any change can potentially break things or make it unsafe. I didn't know that Armory was taken over and how trustworthy the new "organization" is and all that. Anyway, I'll probably upgrade soon. Forget this side topic.
Of course you should always tread with caution. For what it's worth, I'll lay my case again for taking over development. I'm a former ATI employee. I was in charge of basically most of the open source development since I started working on Armory (around 0.91), with the exception of actual crypto features which Alan handled directly. The last FOSS ATI version (0.93.x) is over 90% my code. In other words, you are already running a lot of my code. I've also made a point of leaving all wallet critical code untouched up until and including version 0.95.1 (which can parse SW blocks). The next version will have fresh wallet code. If you want to keep my work in check, this is the version you need review. I'll be posting the particular files for people to focus their reviewing on when the code goes into testing. However, being conscious of the needs of the more paranoid, that new code will only operate when signing SegWit transactions. The old code is still there and active when using Armory with its legacy features. You can't ever be sure that it wouldn't happen in 0.95 before finding the reason.
I know because there can only be 2 types of errors in your case, one being fees, the other being something I fixed some 10 months ago for 0.94. 0.95 also has fresh, proper P2P code to push transactions and handles fees in a much better fashion. I don't think it's fee-related, because adjusting the fees is working.
It's not indeed. A rebuild & rescan should do the trick I believe. Any ideas what is causing this?
I forgot what it was. You can crawl through the commit history for 0.94, it should be pretty obvious then. Is there a way I can debug this code?
Yes but you need to know your way around either GDB or MSVC. Where did it crash exactly? In CppBlockUtils.pyc/2014ff? Where can I find this old file? I can't find it in the etotheipi guthub repo.
That file is the result of the SWIG compilation, which bridges C++ code over to Python. What you are looking for is the actual code, which you can find here: https://github.com/goatpig/BitcoinArmory/blob/v0.93.3/cppForSwig/BlockDataViewer.cpp#L267At any rate, you should consider upgrading for all the benefits the new versions provide. You won't have a choice if you want SegWit or to even run a SW activated node, as anything prior to 0.95 will choke on SW blocks. |
|
|
|
Fine,so I have an address with some unconfirmed transactions. This code return 0.0 balance when I run:
self.curWlt.getAddrDataFromDB()
self.curWlt.getBalancesAndCountFromDB()
atype,a160 = addrStr_to_hash160("1Ne9KrmTLuePACNXND29j3exxxxxxxxx")
print self.curWlt.getAddrBalance(a160,"unconf")
Try to get the address like this instead: https://github.com/goatpig/BitcoinArmory/blob/master/armoryengine/PyBtcWallet.py#L3217You can then use all public methods of the ScrAddrObj class: https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/SwigClient.h#L82These are available to Python through SWIG. also getFullUTXOList return only inputs with at least 1 confirmation from the wallet.
Armory was never meant to let you spend ZC (only your own ZC change). This is because Armory was developed as a GUI wallet. armoryd was donated by a user, ATI only maintained it because it got some traction with our more advanced users. I do intent to change that to allow for CPFP and RBF (basically adding double spend features in the expert GUI) in the upcoming version. Under the hood, the methods will let you fetch ZC in bulk. If you want to fetch ZC right now, you will have to go through a few hops: 1) Fetch the wallet's tx ledger (or the global ledger). These are the getHistoryPage methods. You can fetch that stuff straight from wallet object: https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/SwigClient.h#L115Or you can use LedgerDelegates, which let you combine several wallets for the DB to output the sorted tx history ledger. Delegates are fairly easy to use, you can see the definition here: https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/SwigClient.h#L55And an example of how to instantiate them here: https://github.com/goatpig/BitcoinArmory/blob/master/ArmoryQt.py#L6708Basically, to get the global ledger delegate (for all wallets), you call TheBDM.bdv().getLedgerDelegateForWallets() on a valid bdv object. 2) For ZC, you only ever want to fetch page 0. That page always exists so this call will never fail if the object you are calling it on is valid. All ZC are always prepended to the top of the first history page. You can tell ZC apart by their height, which is always UINT32_MAX (2^32 -1). Keep in mind that you can also get the history ledger for a given address this way: https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/SwigClient.h#L301Here's an example in code: https://github.com/goatpig/BitcoinArmory/blob/master/qtdialogs.py#L36883) If you want more data, you can get the whole tx. Ledger entries come with txhashes, you can use the txhash to fetch the whole tx with this method: https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/SwigClient.h#L311-------------------- All these methods I am listing are in SwigClient.h, which gets SWIG'd (ie, it is C++ code made available to Python through the use of SWIG). SWIG only parses public members/methods, so only those are made available. If you want to read some private members, usually there will be a public method to do that (instead of just accessing it at is). SWIG doesn't modify naming, so as long as you instantiate a SWIG'd class, you can use it as a native Python class. Let me know if you need anything else. If you have some patience (maybe a lot =O), I'm confident I can get armoryd back to a place where you can build your applications around it. |
|
|
|
|
Show Posts
