I'm not a direct user of armoryd.py, but I list here's the first couple "obvious" ones: - Multiple wallets with context swtiching "showwalletlist" and "selectwallet 2xT9gxNq"
- Add a call for creating unsigned transactions just like creating regular transactions.
- Add a call for signing such a transaction (can copy code from extras/cli_sign_txdp.py)
|
|
|
|
It just says offline, is their anyway to force it connect, I have some funds in their I need. (Don't tell me to extract the private key, and use online web wallet)
Thanks for any help.
If it just says offline with no indication of why, there's usually an error thrown in the log file that's stopping it from even trying. And it's usually something simple to get it working. Please submit a ticket with your log file attached: https://bitcoinarmory.com/support/Post when you've submitted it and I'll check it out. Ok I have uploaded it. But I see no errors in the log. Will work on your problem through the support system, will post results here if/when we figure it out. |
|
|
|
It just says offline, is their anyway to force it connect, I have some funds in their I need. (Don't tell me to extract the private key, and use online web wallet)
Thanks for any help.
If it just says offline with no indication of why, there's usually an error thrown in the log file that's stopping it from even trying. And it's usually something simple to get it working. Please submit a ticket with your log file attached: https://bitcoinarmory.com/support/Post when you've submitted it and I'll check it out. |
|
|
|
Fair enough, so, the only peers are Armory (And people who have manually imported the .torrent from their .bitcoin DIR to a torrent client)? No upload is forced?
A couple other users promised to support the seeding, but we worked out the math and are comfortable that we have enough bandwidth without any external help. And the seedboxes are all spread out with different services and geographically to avoid single points of failure. And even if they do all go down, armory will detect slow downloading and revert to using regular P2P. I hardcoded max upload speed and upload connections to zero. Further, the torrent engine shuts down after it's done and doesn't even start if it detects a built Bitcoin core database. Lastly, if you still don't want it, you can run with --disable-torrent to not even try. I think I added a settings option, too. And if you're really scared for whatever reason, you can actually remove the entire BitTornado directory and Armory will run fine with out it. It will simply let Bitcoin core download over P2P. As you can probably tell, I was pretty careful to cover all our bases :-) |
|
|
|
It's the "Armory CDN" because we (Armory Technologies) is running 30-something seedboxes to seed the torrent download for all users who run Armory. So your 29 peers are Armory's resources ... hence the "Armory CDN"  It's a long story why we don't use the default torrent, but part of it is that it gives us better control, and we disabled uploading so we make up for that by providing all the bandwidth for it. P.S. - the torrent file and the torrent itself gets downloaded to your --satoshi-datadir, probably /home/<user>/.bitcoin. We periodically distribute a new .torrent with the latest blockchain files, using the new announcement system (which is offline-signed: https://s3.amazonaws.com/bitcoinarmory-media/announce.txt). We'll be uploading a new version shortly with the last 2-3 week's worth of blockchain history |
|
|
|
For now, this is minimal.
-- At the time of the top post, P2SH wasn't implemented. But now it is. Should be able to go up to 7-of-7 on mainnet, unless I botched the calculation (can only use uncompressed keys, currently).
Yeah, I saw the calculation at 20 or something, but compressed vs uncompressed could explain that. -- This does not do any kind of parallel generation of keys. It is used with a single public key for each party/device, and sends all change back to the same multisig with those original keys. It was envisioned mostly for escrow transactions, though it can be used for savings (eventually) as long as you don't mind the privacy implications. Or you can manually adjust the change. However, given the lack of multi-sig on the network, even if we sent to a new P2SH/multisig it would probably still be pretty obvious which is change and recipient. At least until multisig is more widely-embraced.
Cold wallets with a board of directors is a potential use. It lets them remain completely separate. Each director can see all incoming payments, but can only sign one of them. Just posted it here: https://bitcointalk.org/index.php?topic=587895.msg6443351#msg6443351The protocol considers M-of-20 to be valid, but their's a standardness limit at M-of-3 for plain multisig, and a 520-byte total-script-size limit on redemption of P2SH multisig -- that corresponds to M-of-15 if all keys are compressed, or M-of-7 if uncompressed. |
|
|
|
moves the bulk of the data to prunable TxIns Speaking of that, is every redemption of a P2SH output considered standard? The P2SH subscript provided in the redemption TxIn must be standard, though for multisig it's slightly different rules. It's by script size, not (M,N). As such it seems you could do M-of-15 compressed keys, or M-of-7 uncompressed keys, as an upper limit on mainnet. Any scripts that would be non-standard to put into a TxOut should be non-standard when you put them in a TxIn to redeem them. This was actually one of the motiviations for P2SH: I am giving you a script and declaring that money sent to that script absolves you of whatever debt you are trying to cover. It should be my problem, not yours if I want you to send to some crazy script. So it the standardness rules still apply, it just shifts the burden on getting the non-standard script mined to the person who actually controls the money. |
|
|
|
|
It's not a totally unreasonable softfork. The type is already standard & valid, and there's benefits to having 100% of transactions using the same template, moves the bulk of the data to prunable TxIns, and makes TxIn scripts self-identifying.
Though probably not worth the effort, and would be much more worth if we were creating a new blockchain with that rule enforced from the beginning. There's still 20 GB of blockchain that don't have that change, so the more-complex rules have to stay in the code to handle arbitrary, non-self-identifying TxIns for the first 20 GB.
|
|
|
|
Are you considering things like p2p messaging to support the transfer of the packets? That goes against not exposing Armory to the internet though, except via bitcoind. I see you know about the P2SH 'feature' where it doesn't properly check the size of multisig transactions, so you can bypass the 3 of 3 limit . Does the public key effectively act as a root seed for a whole new branch of keys? I guess the chaincode is computed from the root public key? For now, this is minimal. -- At the time of the top post, P2SH wasn't implemented. But now it is. Should be able to go up to 7-of-7 on mainnet, unless I botched the calculation (can only use uncompressed keys, currently). Unfortunately, the interface is capped to M-of-5, so you can't really help me test that yet unless you modify the source (it's really just one line to modify maxM and maxN) -- This does not do any kind of parallel generation of keys. It is used with a single public key for each party/device, and sends all change back to the same multisig with those original keys. It was envisioned mostly for escrow transactions, though it can be used for savings (eventually) as long as you don't mind the privacy implications. Or you can manually adjust the change. However, given the lack of multi-sig on the network, even if we sent to a new P2SH/multisig it would probably still be pretty obvious which is change and recipient. At least until multisig is more widely-embraced. By the time this matters, we'll have a proper linked-wallet solution that generates parallel address chains and produces a new address for every receive and change output. |
|
|
|
This is already supported by the lockboxes! All parties in a lockbox can be offline keys, created separately and independently. Each party individually manages their own wallet holding that key, including all the regular methods we have backups... yes you can do a 2-of-4 lockbox between 4 parties, and each party can do a 3-of-5 fragmented backup of their individual wallets (which hold the key).
Cool, I need to do some forum searching. |
|
|
|
BTC not arrived yet
No rush, just letting you know
Was going to collect all bug reports and distribute once 0.91.1 is released. If you are anxious, I can send to you now. But I'll do a batch send for everyone when this is done. |
|
|
|
For multi-sig, are you planning to have watch only wallet capability?
This would be where you could have 3 watching only wallets installed and it would tell you that a multi-sig payment could be redeemed by 2 of 3 of them.
You could also allow creation of a spending transaction that each private key owner could sign in turn.
This is better for "boards" that have N of M spending requirements. Each member would have a watching-only wallet for all keys associated with the cold store and one set of private keys.
You could also create 2 level shamir sharing. For example, you could have 2 of 3 sharing, but each share is then split up into 2 of 3 as well. This means that each share is protected against loss too by sharing.
This is already supported by the lockboxes! All parties in a lockbox can be offline keys, created separately and independently. Each party individually manages their own wallet holding that key, including all the regular methods we have backups... yes you can do a 2-of-4 lockbox between 4 parties, and each party can do a 3-of-5 fragmented backup of their individual wallets (which hold the key). Speaking of that, we're working on multisig lockboxes on the "devel" branch -- anyone can check it out and play with it. It's actually looking really good. Got P2SH working, so you should be able to go above 3-of-3 on mainnet now... but of course I don't recommend using any money you can't afford to lose (yet)! The lockboxes and all the data passed between devices/parties assumes that all keys are offline, and thus always contain all information needed to sign offline. The downside to this is that all these message formats have changed, even for regular offline transactions, so all online & offline devices will need to be updated to use this. But once you do, it does work! Will have the last couple pieces of it implemented soon and put out an experimental build to get people playing with. |
|
|
|
Issue: Downloader is 0.9.0 for Bitcoin. Bitcoin is on 0.9.1, 0.9.0 had bad OpenSSL. Screenshot: <img> I don't know if it qualifies as a bug, but here is my BTC addy: 1Pi7AD6hUw3SBbFR5bPxxiZ6cH5hBF4fSM I'll give it to you because technically you're right Updating that download was going to be part of this release you're testing right now! It's not critical because the way Armory runs bitcoind 0.9.0 does not expose the OpenSSL bug. |
|
|
|
About OSX: Looks like the package didn't get fully recompiled. I just wiped the mac directory and then recompiled from scratch (which takes forever, btw). let me know if this works better: https://s3.amazonaws.com/bitcoinarmory-testing/armory_0.91.1-rc2_osx.tar.gzAbout Raspberry Pi: I finally got my RPi up and was able to collect the dependency tree. Bundled it up into a tar.gz. You should be able to copy that to the RPi and "sudo dpkg -i *.deb" from the unpacked tar.gz directory. After that, you should be able to simply unpack the tar.gz and run Armory. Please try it: https://s3.amazonaws.com/bitcoinarmory-testing/armory_raspbian_deps.tar.gz@Corelianer: Thanks for all the reports. Admittedly, a couple things (like password length and complexity) is a design design decision, not a bug. I'll look more closely at what you put there, and might consider a couple trivial things to be worth one bounty together. I'll let you know soon, and you can appeal appropriately If it is using torrent, it is very explicit: the main window will show you "Synchronizing using Armory CDN" and it will tell you download speed and number of peers. Uploading is disabled -- we are running about 30 seedboxes to make up for that. Based on some conversations on the Bitcoin mailing list, this may be obsolete soon, as the core devs seemed to have figured out how to make P2P synchronization just as fast (though it'll probably be like 6 months before it actually gets into Bitcoin core).
|
|
|
|
I have been cross-compiling it for Pi on one of my Ubuntu VMs.
I compiled it using the pi itself. That is very slow , but less hassle than cross compiling. Depends what you mean by "less hassle". Doing it my way requires more "down payment" to get it setup, but then it's trivial to compile new versions. Once I push my latest changes to the repo, I can just switch to the RPi directory, pull, and run "make CXX=<pathtocxcompile-g++>". 3 minutes later I have an RPi release In fact, I think I don't even have to switch directories! But I do it anyway to be clean. |
|
|
|
I compiled the latest build yesterday, though it would have been with an old OS. I had to make a tiny tweak in one of the makefiles to get cryptopp to work. This line needs to be moved up to line 15 (after ISX86 = ...). I guess the latest version of raspbian works without needing mods? I have been cross-compiling it for Pi on one of my Ubuntu VMs. I downloaded crosstool-ng and built the armhf g++ from scratch, then used that to compile _CppBlockUtils.so. I had to make one small modification to the Armory Makefile to make sure it's linking against the armhf python, but it didn't need any further modification (and that can be easily removed as well). Once it's all setup, it actually compiles no differently than regular building. I didn't need to mess with the crypto++ libraries or makefiles at all. It worked on my freshboot RPi with those dependencies, but I was also online so I wonder if it really got everything or if it silently installed some stuff in the background. That's why I wanted someone else to try it. |
|
|
|
Is there any way to sweep a private key without typing in on a connected computer ?
Something like :
- enter the bitcoin address on the connected computer in a watch only wallet
- scan the blockchain for all funds on this address
- create a raw transaction to move them to the armory wallet
- move the transaction to the offline computer
- enter the private key there, sign the transaction
- broadcast the transaction back from the online computer ?
That would be a very handy feature! Sweeping brainwallets, coins, paperwallets and all. Ente Had a lot of requests for this. Right now the only way to do it is to create a new wallet on the offline computer, import the keys, export the new watch-only wallet to the online computer, then perform an offline transaction to move all the coins. It's four steps... If you have the public key already it could theoretically be three steps, but Armory doesn't allow importing of public keys into WO wallets. |
|
|
|
Trying to deal with multiple wallets in any other app is kind of a pain, and not all that useful unless you're using significantly different security profiles for each one. I agree that if the private keys for multiple wallets are on the same hard-drive, they have essentially the same security profile (assuming they're both encrypted).
Does armory support a RPC mechanism? Can it run headless? Quite regularly I get requests for a server-side wallet solution that supports multiple wallets, and I have no idea which of the many wallet solutions works there. armoryd.py is still somewhat minimal. We followed bitcoin core's RPC interface as much as possible, which is a one-wallet interface, and we just haven't had time to update it to handle multiple wallets. It actually would be quite easy -- just register mulitple wallets at startup instead of one, and then add some RPC commands to switch the "active" wallet. In fact, I think some people using armoryd have essentially modified it in this way. It's just not officially supported yet. |
|
|
|
(updated top post and copied here) Find bugs in Armory 0.91.1, get 0.03 BTC!This thread used to be for the 0.91 release, but I'm going to piggyback on it for for 0.91.1 because it's basically the same release, but with some minor tweaks. Nothing substantial should've changed, except for the bug reporting and wallet-corruption handling. This was born out of a couple reports of wallet corruption that were not being handled well by Armory in 0.91, and we had to not only improve it but add a way for users to submit their wallet recovery logs for review. Given that this will be pretty boring, I've upped the bounty to 0.03 BTC (~$15) per bug. I will pay out all bounties for the original 0.91 testing and this round at the same time. I expect this round won't be very long, and the same rules apply -- you must be the first to post it, and it must be something that isn't totally trivial. But we're not going to be stingy about it -- we need testers more than we need to save $15 on this bounty! This release might require explicit digging for bugs. There might a few pieces of low-hanging fruit, but beyond that you're going to have explicitly test some of the less-commonly-used functionality (importing, sweeping, rebuilding, making & restoring backups, etc). https://s3.amazonaws.com/bitcoinarmory-testing/armory_0.91.1-rc1_32bit.debhttps://s3.amazonaws.com/bitcoinarmory-testing/armory_0.91.1-rc1_64bit.debhttps://s3.amazonaws.com/bitcoinarmory-testing/armory_0.91.1-rc1_osx.tar.gzhttps://s3.amazonaws.com/bitcoinarmory-testing/armory_0.91.1-rc1_raspbian.tar.gzhttps://s3.amazonaws.com/bitcoinarmory-testing/armory_0.91.1-rc1_winAll.exeDue to my build scripts breaking I wasn't able to go through the official release process for the testing build. So I have signed the hashes with my regular GPG key (not the offline key). While this is in testing, I'll be rewriting the build & release scripts and everything will be done properly by the time we actually release. https://s3.amazonaws.com/bitcoinarmory-testing/armory_0.91.1-rc1_sha256.txt.asc |
|
|
|
|
Show Posts
Until we fix that, I'm going to have to pass on Tails support ...
