That's some bootleg monstrosity they got there...
As long as they stick to Bitcoin style transactions, Armory can sign for that stuff, irreverent of the consensus layer.
|
|
|
Armory never worked with Tether, what are you even talking about?
|
|
|
The logs with the error backtraces should be there regardless of what version you are running now though. That's what I'm asking for.
|
|
|
Armory is also open source so if a decent dev team is creating a fork/split they could probably also submit a PR
Same as with BCH, no one from their team bothered to even email me to announce their fork. Really all it would have taken for me to provide support would have been to send me an email at worst a month prior to the fork with the list of commits that touch address format and signer changes, as well as access to their testnet. But neither did they bother doing that, like BCH they turned on their testnet AFTER their forked. You'd imagine a sensible fork project would actually go out of its way to invite wallet and service providers to review their implementation for replay protection, but who am I kidding?
|
|
|
Maybe its because I just have a lot inputs in such transactions.
Shouldn't be related. If you're having errors, let me see the logs. The user who reported the issue confirmed the fix on his end, so you may be experiencing something different.
|
|
|
Well at least now I know for sure that this is way out of my depth and I can give up for the time being.
I don't suppose there would be a way of putting up a bounty to get armory working with the bgold version of bitcoin-qt? Is it a realistic possibility?
I've looked at their signer code, that part is easy, basically already done in Armory since it copies the BCH replay protection as is. Couldn't find anything about their new address format or any of their other changes, so I'd have to actually crawl through their changeset to get this done, and well... what's in it for me? Realistically, BTG is a 1% bump for maybe a week of work, mostly spent trying to figure wtf they changed in there, with the added risk of fiddling with signer and address code? Bottom line, the reward doesn't justify the risk.
|
|
|
There's no easy way around it. It would be cheaper to just implement the fork replay protection in Armory.
|
|
|
Yes both the offline and online instance need the fix.
|
|
|
Should be fixed, try it out.
|
|
|
If you're willing to build from the testing branch I could probably have this fixed today.
|
|
|
It can be useful under certain conditions. If your wallet identifies your spending patterns, it could estimate the most appropriate size for change outputs so as to fit your next spend size more appropriately. This requires a bunch of analytics first and isn't exactly a perfect science.
This isn't particularly useful long term however, as what erodes your privacy with regards to change is cross spending them to a given service. While on the blockchain it does not appear that you are a single user spending to a single service (since they should give fresh deposit addresses), anyone with access to that service's log will identify yours coins easily.
Therefor a setup where the user can signify which service he is spending to would allow the wallet to single out utxos already tainted to that service, at the same time quarantining that chain of utxos from other services.
|
|
|
There was a bug reported when using several SW inputs the process would choke. I'm working on it.
|
|
|
Please update and try again. If it fails, delete your db folder and try again (C:\Users\Josh\AppData\Roaming\Armory\databases)
|
|
|
Thanks gangtraet--pastebin is new to me. They wouldn't let me post the whole armory log so I posted where armory starts up and gets stuck on scanning. Here's the link. Many thanks for your help. https://pastebin.com/JFK5ZivPThis is super short and not what I need. Don't doctor the logs, just post as much as you can starting from the bottom. At any rate, you need to update.
|
|
|
There is no S2X fork anymore. It was called off before it could take place. The tx is still out there and it's possible it will one day confirm. If you don't want your coins to randomly show up on Coinbase one of these days, you should send them to an address you control.
|
|
|
Show me a fresh dbLog.txt
|
|
|
Your node is shutting down midway through the process. Make sure you have enough space on both the block chain disk and the armory db disk. The logs report alarming low available space. Also this log does not show any evidence of a rebuild, it's only rescanning blockchain data, i.e. it means you did not delete the content of your DB folder as instructed.
|
|
|
I rebuild the databases but the "Scanning transaction history" gets stuck at 99% always..
Where do I find that dblog.txt you asked for?
C:\Users\user\AppData\Roaming\Armory\
|
|
|
That's the bitcoind log, I want dbLog.txt. At any rate, delete the content of you databases folder and let it build from scratch (C:\Users\user\AppData\Roaming\Armory\databases).
Also make sure you have enough free space on your blockchain data disk.
|
|
|
|