 Show Posts
|
|
Pages: [1]
|
|
Ok, that makes perfect sense. Anyway, I could recover the BTC with the help of the person.
Now I'm also trying to recover the BCH from those same addresses. What would you advise to do to do that? I tried just relaying a BTC transaction on the BCH network to transfer the coins but BCH transactions must have an additional opcode to avoid chain jumping.
|
|
|
|
|
Thank you goatpig, someone has already contacted me and is already helping with that.
I'm curious, is there really no way to just export P2SH addresses?
|
|
|
|
|
Hello,
For technical reasons (broken PC) I can't get an online instance of Armory.
I need urgent access to the funds of one of my P2SH (not multisig) addresses, so I installed Armory on my laptop, imported my paper backup, changed the address type in the settings, generated enough addresses and exported the private key.
The problem is that when this key is imported back into any other wallet (and Armory itself!) it is imported as a P2PK address.
I'm currently offering a reward on Reddit for someone to create a transaction for me from an online instance of Armory (as Armory is only capable of signing transactions created by other Armory instances, because custom metadata, which by the way is a bit dangerous as just demonstrated), but it would be obviously better to find a solution that doesn't rely on other people's setups.
Anyone can help?
|
|
|
|
|
goatpig,
I hope I haven't offended you. I was just trying to give a broad look at the general state of the project. I know and appreciate that you are working on this on your own time. Thank you for addressing my concerns, and for pointing out the new features I had missed.
Please note that RBF, unless it has to be activated somehow, doesn't work for me (all my respends with higher fees got dropped). I can't test that out again for you as I haven't got any funds available in my Armory wallets right now.
About ArmoryDB, I have already given you the logs for my crashes. When those issues will be addressed I'll be glad to test it in the described situation and report back.
As for the database concerns, I certainly appreciate the scale of the problem, and I'm both armed with patience (after all, I'm still using Armory) and ready to report any issue to you.
|
|
|
|
I know this was very difficult in Bitcoin Core at least a while back. This is why I started using Armory.
I'm wondering if anything has changed in Bitcoin Core since then, for instance since it introduced Hierarchically Deterministic wallets.
Please don't be offended by this question, but I'm wondering if I really need Armory anymore. (I only need the offline signing/online broadcasting feature for a cold wallet. I don't happen to need the other great Armory features.)
I was wondering exactly the same thing, since Armory has (at least for me) very unstable in the latest versions. Here are my thoughts, I hope they are are of some use for you, and I would be happy if you'd share your own with us  Pros: - I'm used to Armory, it is what I used since day 1.
- (This one doesn't works very well right now but it is a big one for me) I can run a single Bitcoin node and ArmoryDB in my server room and use multiple ArmoryQt instances as "clients".
- Offline signing in Armory is very intuitive (but I have never tried to do the same thing in any other wallet software, tbh).
- The paper wallet functionality is implemented just perfectly.
Cons: - It is, as mentioned, pretty unstable. It is crashing relatively often for me and setting it up the last time has been a pain in the ass that required me to use a total of 4 different versions of Bitcoin Core and Armory.
- It lacks support for some of the latest shiny stuff (such as RBF transactions, this one in particular caused me a lot of pain lately).
- It builds its own database that should supposedly optimize search operations but I don't think it is relational, so it is enormously slower than it could be for most things (and in general slow enough to be frustrating sometimes if you don't run in on an SSD).
In other words it seems to me that Armory is the only real "advanced" wallet out there, but while it excels in usability for some specific things, it very much lacks in usability for some other things. To me, it is the only wallet that doesn't give me the "this was designed for idiot users" feel when I open it, for one, and in every other wallet I tried I really missed Armory's concept of deterministic wallets. I know other clients have it too, but they mostly try to abstract it away, and that bothers me enormously. I also love how it allows you to chose exactly the source and destination addresses for each transaction, and it doesn't just want to figure everything out for you, but at the same time it can also do that if you want. EDIT: to answer your question more specifically regarding signing transactions offline, which I completely forgot (I got carried off by the whole "do we still need Armory?" thing) you can do that from Bitcoin Core from day 1, it is just a pain the ass because you have to use the console. Armory is still probably the easiest (read: easiest while not hiding the underlying process) way to do it, but other wallets, such as Electrum, also offer that if you want. |
|
|
|
I've uninstalled Core and Armory and removed the Core's folders. Installed them again and now I need to wait until the core will synchronize :-(. I'll provide updates after.
Thank you very much !
That was not necessary. If you still have the files in the recycle bin I strongly suggest you to restore them and then just install 0.13.2. It will work with the same blockchain downloaded by 0.14.1. There's really no need to waste the time and the bandwidth. |
|
|
|
Nothing in your log indicates that the error is in any way related to the previous transaction broadcast timeout issue, even though it appears that way and the fix for that still works. Can you broadcast the raw transaction through Bitcoin Core's sendrawtransaction RPC? If you don't know how to do that, I can do it for you, the raw transaction is in the log file.
The funds are no longer available. I'm not isolating the issue to a particular section of the code because I have not the knowledge or the time to do that, as Armory's codebase is quite complicated and messy and frankly my own complicated and messy codebases are more than enough.
Which I expected. At the same time you bump 3 threads with your conclusions which only leads to more confusion about what the issue actually is. The majority of users silently parse the forum and troubleshoot themselves with the informations they find. How do you expect me not to call you out on this? To be fair, it's not like they were buried 10 pages deep. They were among the latest topics. One of them was mine, another one was from a user that was still clueless and has now got a viable workaround, and the third one, well, fair enough, I'm sorry. Just to be entirely clear, I didn't/don't expect you to do anything, I barely know you. I was trying to relay my finding on the matter, not to trigger a specific reaction from you. Entire log here (6000+ lines).
That's actually quite useful. Will investigate. As for "This is the issue this topic covers, this is what I respond to.", sorry for mixing things up, since you are a moderator here I'm sure you can move this to a separate topic if you think it would work out better, or I can open a new topic myself if you prefer.
I don't modify users posts/topics unless they break the forum's general rules. What I prefer from users is that they stick to one topic per issue. Keeps the content shorter and makes it easier to search for solutions. Ok. |
|
|
|
The log files you have are old and related to my first issue, which is not present anymore.
This is the issue this topic covers, this is what I respond to. Again, you are confusing people mixing issues together. There are 2 paths to fixing a bug, you either PR code or isolate it for me to fix. If it is a different issue - and you have a fix already - please explain what it is, otherwise your claims are as good as mine.
https://github.com/goatpig/BitcoinArmory/commit/a2a94e8419968cf8969b161614612c97a85bffe2The new issue has the same symptoms and the same solution as the issue outlined in the thread I referenced
You are conflating symptoms and causes. Minimum mempool requirements such as coin-age in relation to fee floor can change per Core sub version. You are not isolating the issue in this case. The one way to do so would be to grab the raw tx that fails to broadcast through Armory with Core 0.14.1 and push it directly from the RPC to read the error code verbose (verbose which should be available in armorylog.txt since 0.96, so I'd like to see that). I'm not isolating the issue to a particular section of the code because I have not the knowledge or the time to do that, as Armory's codebase is quite complicated and messy and frankly my own complicated and messy codebases are more than enough. For the same reason, a particular commit that changes a few line doesn't mean much to me. All I said (God forbid that someone takes my words as provocation, I'm just trying to move my Bitcoin and to report back to you) is that the issue that was previously decribed is not resolved, that is presents exactly the same way, and that the same workaround still works. I'm literally saying no more than that. I'm also not implying anything else, including e.g. that the underlying cause is the same. I apologize if it came through that way. The log simply says that the transaction times out, unless I'm missing something: 2017-05-06 14:55 (INFO) -- (PPRINT from ArmoryQt.py:3088)
01000000 0109b9db f08122b8 6bbaf955 2aff9505 e66ff6bf a7013a86 8a7aae89
36cdf58a c4000000 008b4830 45022100 90f9e43a 035a6cf1 dfb5acd2 a1d24aea
0b154a81 c8edaf0d e3d08a09 84900f5e 022025e3 b4be653a 1b438a49 14568ebd
00a2eda8 a745540c 4217f6e4 89a932ff 09410141 045ed39b a1aab680 5d9ab9ed
1a096745 e1a7bb59 667d0fed b47c7c08 7f705143 8921fd3f 55407740 a5e74614
960193d7 27bf41f1 abbf1aec 6952ca3c f9591aef edffffff ff013be5 3e050000
00001976 a914a74b 354efbe1 3422ebd6 a004d897 f274223a 53d388ac d0180700
2017-05-06 14:55 (INFO) -- (PPRINT from ArmoryQt.py:3089)
Transaction:
TxHash: b470d020049677645d5ed4024844de94eaee8ad7b682e3213662ab2c0637c2cf (BE)
Version: 1
nInputs: 1
nOutputs: 1
LockTime: 465104
Inputs:
PyTxIn:
PrevTxHash: c48af5cd3689ae7a8a863a01a7bff66fe60595ff2a55f9ba6bb82281f0dbb909 (BE)
TxOutIndex: 0
Script: (48304502210090f9e43a035a6cf1dfb5acd2a1d24aea0b154a81c8edaf0de3d0)
Sender: 1QJfNJGoP8o3U2NiXUK2gm5JtcDjiP6aUN
Seq: 4294967295
Outputs:
TxOut:
Value: 88007995 (0.88007995)
Script: OP_DUP OP_HASH160 (1GFZwbYTfHdcKDwCw6HZUXUJamnuz8EREK) OP_EQUALVERIFY OP_CHECKSIG
2017-05-06 14:55 (INFO) -- ArmoryQt.py:3094 - Sending Tx, cfc237062cab623621e382b6d78aeeea94de444802d45e5d6477960420d070b4
2017-05-06 14:55 (ERROR) -- Traceback (most recent call last):
File "qtdialogs.pyc", line 1571, in execSendBtc
AttributeError: 'DlgWalletDetails' object has no attribute 'wltAddrModel'
2017-05-06 14:55 (ERROR) -- ArmoryQt.py:3108 - Transaction was not accepted by the Satoshi client
2017-05-06 14:55 (ERROR) -- ArmoryQt.py:3109 - Raw transaction:
2017-05-06 14:55 (ERROR) -- (PPRINT from ArmoryQt.py:3110)
01000000 0109b9db f08122b8 6bbaf955 2aff9505 e66ff6bf a7013a86 8a7aae89
36cdf58a c4000000 008b4830 45022100 90f9e43a 035a6cf1 dfb5acd2 a1d24aea
0b154a81 c8edaf0d e3d08a09 84900f5e 022025e3 b4be653a 1b438a49 14568ebd
00a2eda8 a745540c 4217f6e4 89a932ff 09410141 045ed39b a1aab680 5d9ab9ed
1a096745 e1a7bb59 667d0fed b47c7c08 7f705143 8921fd3f 55407740 a5e74614
960193d7 27bf41f1 abbf1aec 6952ca3c f9591aef edffffff ff013be5 3e050000
00001976 a914a74b 354efbe1 3422ebd6 a004d897 f274223a 53d388ac d0180700
2017-05-06 14:55 (ERROR) -- ArmoryQt.py:3111 - Transaction details
2017-05-06 14:55 (ERROR) -- (PPRINT from ArmoryQt.py:3112)
Transaction:
TxHash: b470d020049677645d5ed4024844de94eaee8ad7b682e3213662ab2c0637c2cf (BE)
Version: 1
nInputs: 1
nOutputs: 1
LockTime: 465104
Inputs:
PyTxIn:
PrevTxHash: c48af5cd3689ae7a8a863a01a7bff66fe60595ff2a55f9ba6bb82281f0dbb909 (BE)
TxOutIndex: 0
Script: (48304502210090f9e43a035a6cf1dfb5acd2a1d24aea0b154a81c8edaf0de3d0)
Sender: 1QJfNJGoP8o3U2NiXUK2gm5JtcDjiP6aUN
Seq: 4294967295
Outputs:
TxOut:
Value: 88007995 (0.88007995)
Script: OP_DUP OP_HASH160 (1GFZwbYTfHdcKDwCw6HZUXUJamnuz8EREK) OP_EQUALVERIFY OP_CHECKSIG
2017-05-06 14:55 (ERROR) -- ArmoryQt.py:3113 - Failure message: tx broadcast timed out (send) As for "This is the issue this topic covers, this is what I respond to.", sorry for mixing things up, since you are a moderator here I'm sure you can move this to a separate topic if you think it would work out better, or I can open a new topic myself if you prefer. |
|
|
|
EDIT3: I confirm that 0.96 still has the issue! Downgrading to Core 0.13.2 fixed it for now.
It is not. Your issue is completely different, as evidenced by your log files, and I believe I have a fix already. If you are going to make claims about bugs, either isolate them in code or withhold your opinion, otherwise you are just spreading confusion about the state of a given issue. The log files you have are old and related to my first issue, which is not present anymore. The new issue has the same symptoms and the same solution as the issue outlined in the thread I referenced. If it is a different issue - and you have a fix already - please explain what it is, otherwise your claims are as good as mine. |
|
|
|
Thank you very much!
What is your Armory version?
As I mentioned, I'm using 0.96. What confused me initially is that issue was thought to be present in 0.95.1 but not in 0.96; I've now verified this is in fact incorrect, the issue is present in both versions. The only solution is to downgrade Bitcoin Core to 0.13.2. This will fix the problem presumably for both Armory 0.95.1 and 0.96. I can only vouch for 0.96 as it is the version I'm using now. |
|
|
|
|
I'm on 0.96 and I'm still getting the error.
Downgrading to Core 0.13.2 did the trick, so 0.96 is still broken.
|
|
|
|
Same here! Logs show nothing interesting, but if you tell which ones I'll gladly post them. EDIT: This is most likely what's causing the issue. Testing the solution now. EDIT2: I confirm that 0.96 still has the issue! Downgrading to Core 0.13.2 fixed it for now. |
|
|
|
Successfully built the database on 0.95.1, upgraded to 0.96, block rescan still crashed the database twice but third time was the charm. It seems to be working now. Still, 0.96 doesn't really strike me as stable. EDIT: Ok - I'm unable to spend any coins. I'm using 22 satoshi/byte for the fee, which should be fine. Yesterday I was sending coins around for about 1/4 that, so I don't think it is the problem. EDIT2: This is probably what's causing it. Gonna try to downgrade to Core 0.13.2. EDIT3: I confirm that 0.96 still has the issue! Downgrading to Core 0.13.2 fixed it for now. |
|
|
|
1) Delete this folder:
C:\Users\ricca\AppData\Roaming\Armory\databases
2) Make sure Core is fully synced, then shut it down
3) Start ArmoryDB on its own, let it complete building.
4) Once it says "enabling zero conf", start ArmoryQt, then report back.
I'm building the database on 0.95.1 right now and it seems to be working (even with Core open). Will the same database work with 0.96 or it the new version going to rebuild it? In case the second is true, I'm going to let 0.96 ArmoryDB build the database overnight in a different folder with Core closed, and we'll see if it works. What is the parameter for ArmoryDB to specify the database folder? |
|
|
|
post dbLog.txt
Sorry, is this not dbLog.txt? |
|
|
|
Hello, ArmoryDB keeps crashing ("ArmoryDB.exe has stopped working"). I'm using Bitcoin Core 0.14.1 (which is fully synchronized and runs fine). I tried reinstalling Armory and also deleting all Armory files. No luck. The error is always the same & it always happens around the same "parsed block file" (I've observed it between 51 and 62). Here's an example of the log I get when this happens: https://pastebin.com/jmyMJ0d4After the last log line gets printed, it *always* crashes, sometimes immediately and sometimes after some interval (I observed at most 20-30 seconds before the crash). I've never observed other/different log lines after the last one of the log I published. Also, ArmoryQt keeps running just fine after ArmoryDB crashes. If it's of any help, the %appdata%\Bitcoin and %appdata%\Armory folders are symlinks to another hard drive, but I don't think this has anything to do with it (it should be completely transparent to applications anyway). EDIT: will Armory 0.95.x work fine with Bitcoin Core 0.14.1? I need to get up and running pretty urgently, so while we get this sorted out I'm fine with using an older version. I just realized that 0.95.1 is what I was trying originally, and then updated to 0.96, so it probably won't help. |
|
|
|
|
