Bitcoin Forum
February 23, 2017, 02:48:33 AM *
News: Latest stable version of Bitcoin Core: 0.13.2  [Torrent]. (New!)
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 ... 125 »
501  Bitcoin / Armory / Re: What if a watching only wallet gets compromised.... on: June 05, 2016, 12:48:18 PM
..... are you vulnerable to someone brute forcing the password encryption on the watching only wallet.dat file (if that is a thing)

It isn't a thing. WO wallets cannot currently be encrypted, and they only carry public data.

wallet.dat is Bitcoin Core's wallet format, which Armory does not use nor depend upon. Loosing Core's wallet.dat is an issue, as those carry private keys.

Armory's .watching_only.wallet files only carry public data. Compromising this file will leak your privacy. Any attacker can also choose to swap addresses in that file for his, so that you would serve his addresses instead of yours to receive payment.

Armory checks the consistency of all public data in wallets at start to prevent this sort of attack vectors (and data corruption in general, never know when a disk/stick of ram might fail).
502  Bitcoin / Armory / Re: Stuck offline =[ on: June 05, 2016, 10:01:36 AM
Are you using auto managed bitcoind? Are any STDERR entries in your log file?
503  Bitcoin / Armory / Re: Old Windows 32bit Versions on: June 04, 2016, 10:44:41 PM
Everyone has made excellent points here and I was myself wary of handing out that old installer that I kept (I archive the installers for every new release for the crypto wallets I keep), but I just wanted to help the OP as I was in his situation myself awhile back. https://bitcointalk.org/index.php?topic=977678.msg10674668#msg10674668

Glad everything worked out & thanks SoraMan for verifying the installer hash and keeping my reputation intact!  Smiley

It's ok to distribute binaries as long as you attach the signed hashes file.
504  Bitcoin / Armory / Re: Are the new armory versions trusted? on: June 04, 2016, 08:00:33 PM
To answer your question, OP, nobody really knows.  It's basically a one-man operation at this point.

I certainly wouldn't go rushing into downloading any new versions of Armory.

When I brought up the same topic in another thread, I eventually got a response from Mr. Goatpig himself:

https://bitcointalk.org/index.php?topic=1494369.msg15056227#msg15056227

All I can suggest it, when goatpig puts out his tip cup and says "pls" don't be surprised if he doesn't get the money he desires, says "fuck this shit" and releases a malicious Armory in the future

Good luck.

I'm not sure where you come from or why you think you have a leg to stand on in this matter.

If you've run Armory 0.92 or later, you have run my code. I've contributed over 2/3rd of the public code changes since 0.92.

0.93 is essentially my solo work, the other 5 devs were busy with closed source enterprise code. I was the defacto open source maintainer for over a year before ATI shut down development. If you had participated to the 0.93 and 0.94 testing phases you would have known that.

Quote
I mean, I didn't see any signed messages from etotheipi handing over the project to goatpig.

https://bitcointalk.org/index.php?topic=1351792 (https://bitcointalk.org/index.php?topic=1351792) doesn't have any signatures.

I can't upgrade to a new version if I can't figure this out.

As for this question. Again, this is an open source project, (now 100%) community managed, so your best alternative is to read the code and build it yourself, or at least find a member of the community you trust that does that for you.

For what it's worth, I have yet to submit a commit that touches crypto or wallets in a significant way. You can verify this by checking the commit history on PyBtcWallet.py, PyBtcAddress.py, MultisigUtils.py and Transaction.py in the armoryengine folder (https://github.com/goatpig/BitcoinArmory/tree/master/armoryengine)

The EncryptionUtils.h/cpp files and the entire cryptopp folder are untouched as well. You could hash these and verify them against the code in 0.93 if you don't like to go through commits.

As for the new wallets, I'll keep them in separate code files and let both the old and the new format coexist in Armory for quite a while. I have no need to force users onto the wallet format I'll write for BIP32/44 support, nor do I want to blur the change history in the code base.

While it's fairly easy to verify by yourself that I haven't touched any of the crypto sensitive code in 0.94 and upcoming 0.95 (most of the changes are performance and paradigm changes around the DB, the blockchain parser code), you should review or get someone to review 0.96, which will introduce the new wallet format.

This version will have significant amount of new code dealing with crypto. However it will coexist for a while with the untouched 0.93 wallet format, so you can choose to ignore those for a while as long as you don't create a wallet with the new format (I don't intent to remove any of the old format functionality for a while, rather slowly deprecate them).

I'm looking forward to this feature; Bitcoin broke new ground with using deterministic builds, and so it's only right that Armory would take up the mantle similarly. I build Armory from the source code myself also, and so don't really need the feature as such (although I'd be happy to contribute my own signatures to help confirm the veracity of official builds to the wider userbase). Another approach might be to try to get Gentoo or ArchLinux interested in packaging Armory for use with their automated client-side compilation, but likely too niche as OS's to cater to if it involved alot of work. Getting Armory into sw repos in general should be an aim IMO, but that's another conversation.

My preferred route is to split Armory into a set of stand alone libraries. I will start with the crypto code, i.e. isolate cryptopp and EncryptionUtils.h/cpp in its own repo, move to cmake for makefiles/msvs projects and dynamically link to it.

Since that will be all C++ with no need for C++11 support, it will be the first candidate for deterministic build. The new wallet code will be delivered that way too, in its own repo with its own fresh code files and dynamically linking to the crypto lib.

With deterministically built shared libraries, I'm thinking of signing the hash and hardcoding both hash and sig into the code base (i.e. have binaries hash and check the sig for the shared libs before loading them), but that's an egg and chicken problem with the crypto lib (you need the crypto methods to hash and check sigs) so I'm still wondering if that's possible/desirable.
505  Bitcoin / Armory / Re: Backups Clarification on: June 02, 2016, 11:23:44 AM
One wallet <-> one backup.

There is no relation between 2 wallets, even if they were made within the same process. The root keys are just plain PRNG pulls. If you want to derive several wallets from the same root, you'll have to wait for BIP32 wallets.
506  Bitcoin / Armory / Re: 0.94.1 Database error on: June 02, 2016, 11:21:36 AM
I have a fix for that in 0.95

Glad to hear there's already a fix. Cheesy Will it retroactively fix all my old transactions, maybe with a database rescan or rebuild, or will it just stop the error on new transactions? Undecided

It will need a rescan, don't have to go as far as rebuild. It is indeed missing some tx hashes.
507  Bitcoin / Armory / Re: 0.94.1 Database error on: June 02, 2016, 01:05:32 AM
I wounder if this is a bug from that. Undecided

I have a fix for that in 0.95
508  Bitcoin / Armory / Re: Armory 0.94.1 is out on: June 01, 2016, 06:00:27 PM
At some point but not in the next update. Doesn't matter for your particular case, the original tx would have to flag RBF to be replaceable anyways. You can always try a child pays for parent to hurry things up, some pools do prioritize those I believe.
509  Bitcoin / Armory / Re: Armory 0.94.1 is out on: June 01, 2016, 02:19:43 PM
Question.

Is it possible to see the size of a tx before you send it? Either with direct sending or with the steps of creating an unsigned tx - sign & broadcast it?

I ask this because I made a transaction that had a huge size in kb and so an extremely low fee sats/bit that will take ages to confirm.

So next time I would like to prevent that.

You can look at the raw tx after signing it, in the offline signing/broadcasting dialog.
510  Bitcoin / Armory / Re: Old Windows 32bit Versions on: June 01, 2016, 02:18:24 PM
What happened to ghdp's posts? Huh I didn't get to read his last one before it disappeared. Sad I had hoped it had tips on how to check the signatures.

Looks like he chose to remove it.
511  Bitcoin / Armory / Re: Old Windows 32bit Versions on: May 31, 2016, 11:32:59 AM
There wouldn't be a guide for that would there? Or is that not easier than just compiling it myself? By the the number of things to install and setup in your link it would seem to me like verifying would be easier. Undecided

hash the file (sha256sum), check it matches the hash in the signed hashes file for 0.92.3. Then check that signed hashes file is signed by Alan's offline signing key. If you're not willing to go down that route, you should build from scratch.

Quote
I feel you on that and that's why I wouldn't use it on an online pc but from my understanding let me ask something. If it only ever is on an offline pc, only in offline mode and used to only sign offline transactions, aren't the transactions made and verified by the online clean armory? Like if during the signing the outputs were changed to the attacker wouldn't the online armory see the change? Or am I missing something?

Doesn't matter what the GUI shows on both ends. If as an attacker I have access to what code runs on your signer, I could wipe your entire wallet after you've broadcasted a single tx signed with this malicious code, if I wasn't trying to be sneaky.

If I wanted to be stealthier, I'd still manage to reveal all private keys on your wallet after the one you signed with, with a single tx broadcasted to the network. An attacker with enough motivation would figure out which parts of the code base to alter to corrupt the signer in this way.

tldr: do not use binaries without signed hash, ideally build the code yourself, and best would be to review the code before using it (now that's going far I know)
512  Bitcoin / Armory / Re: Old Windows 32bit Versions on: May 31, 2016, 09:23:25 AM
it's already working great and it's only for offline transactions signing

Unless you verify the installer hash vs the signature files, you are taking massive risks.
513  Bitcoin / Armory / Re: Old Windows 32bit Versions on: May 30, 2016, 07:58:46 PM
Thank you for your help. I'm installing MSVS 2015 right now (it has to download 12gb so I'll take some time) so I'm looking through the 0.92.3 repo now. I'm sorry but by cpp project do you mean cppForSwig? And if so by that link you gave do I need to unzip swig 3.0.2 into swigwin first before compiling it? If not I'm not sure which files you mean. Those are the only .cpp files I see. (sorry like I said I've never done C++ before Embarrassed).

https://github.com/goatpig/BitcoinArmory/blob/master/cppForSwig/BitcoinArmory.sln

Open this file in MSVS, make sure the swigwin root folder is in the same folder as this file.
514  Bitcoin / Armory / Re: Old Windows 32bit Versions on: May 30, 2016, 12:47:09 PM
Also use this as a general reference:

https://github.com/goatpig/BitcoinArmory/blob/master/windowsbuild/Windows_build_notes.md
515  Bitcoin / Armory / Re: Old Windows 32bit Versions on: May 30, 2016, 12:46:25 PM
It's fairly easy with MSVS.

First off get MSVS 2015 express on your online machine, checkout the 0.92.3 tag on the repo and build the cpp project in x86. Once you have that covered, I'll walk you through the python part.
516  Bitcoin / Armory / Re: Old Windows 32bit Versions on: May 30, 2016, 10:14:55 AM
You would have to build it yourself. It's not as hard as it sounds.
517  Bitcoin / Armory / Re: armoryd not broadcasting transactions on: May 30, 2016, 10:12:19 AM
https://github.com/goatpig/BitcoinArmory/blob/master/armoryengine/ArmoryUtils.py#L114

Try with this. It looks like one call returns ZC outputs while the other doesn't and it gets confused there. Most likely a bug. I'll to have look into it at some point.

518  Bitcoin / Armory / Re: armoryd not broadcasting transactions on: May 29, 2016, 07:11:45 PM
How many inputs do you have in the wallet? Are you trying to spend unconfirmed change? Did you create the ustx with enableZC = True?
519  Bitcoin / Armory / Re: armoryd not broadcasting transactions on: May 27, 2016, 04:41:20 PM
Do you think I should upgrade to 0.94 as this problem might have already been solved?

You should
520  Bitcoin / Armory / Re: armoryd not broadcasting transactions on: May 27, 2016, 02:56:42 PM
supernode? You using 0.93?
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 ... 125 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!