Is there any way to speed Armory up? It takes hours to get online while showing the "Armory is offline while scanning the blockchain" message.
How much RAM do you have? If you have sufficient RAM, it should be about 5-10min on Windows, 2-3 min on Linux. The cases where I've seen it take longer than that is when the user has less than 2GB RAM. For now, Armory requires that much RAM. Blame SatoshiDice for growing the network faster than I could get around to fixing this... Regardless, a fix is coming -- at the expense of duplicating blockchain data on disk. I have to start maintaining my own blockchain data, but it will mean Armory's RAM usage will drop dramatically, and will also startup instantly after the first load. Obviously a big improvement... but I don't know how long before I can have it implemented. Definitely within the next couple months. Until then, there's not much I can do for you  |
|
|
|
One problem you are going to have to face is that there is no way to guarantee that a codes cleanup part runs. You can e.g. try to catch any reasonable Unix signal and then clean up, but you cannot catch SIGKILL and SIGSTOP, the user can always do a "kill -9" on the Python process.
One way of doing it that I would consider is a separate "guardian process". Armory starts bitcoind, gets its PID. Armory then starts the guardian process, passing its own and bitcoind's PID. Every second, the guardian process checks that Armory is still running, and kills bitcoind if not. Every second Armory checks that the guardian is running, kills bitcoind and shuts down cleanly if not (*). Every second Armory checks that bitcoind is running, and restarts it (and the guardian) if not.
(*) Restarting the guardian would be tempting, but it will only crash if something is seriously wrong.
Excellent idea! I like it. Either Armory will shutdown both, or neither of them. If it doesn't shut down either of them, the guardian will take care of it. This should be fairly straightforward in Linux. But, I still have to figure out how to apply this in Windows. I hate to create a new python project and convert it to an executable with py2exe, but anything is better than batch/DOS scripting... |
|
|
|
There have been both types of double-spend in the last day or two. I've seen one instance of a zero byte (OP_FALSE) being prepended to the input script, but 3 instances of the signature itself being padded.
Both of these ways of changing a transaction's hash can be done by a 3rd party with no knowledge of the sender's private keys.
Agreed. My only point was that the one that involves non-standard transactions requires a much more resourceful attacker, since you can't just broadcast it. You have to know a miner who's willing to accept your non-standard transaction. However, padding the signature does not require anything special -- if you have a good connection to the person broadcasting, you can receive the tx, padd the signature with a zero byte, and forward the result to the rest of the network that hasn't seen it yet. It will be "fixed" by the core devs trying to make such transactions non-standard: any signatures with excess zero-byte padding will be non-standard. |
|
|
|
I don't really understand that double-spends page - I would expect it to show pairs of conflicting transactions, but it doesn't as far as I can see.
Perhaps piuk will provide more details about the double-spends page. I'd guess that it lists transactions that spend inputs which are used in previously known (to blockchain.info) transactions. The majority of them should not enter a block. Every SDICE profit which is double-spent and confirmed, as with the ones you noted, is a dent in the edge. I found that if I click on any of the transactions on the double-spends page it shows me a link to the corresponding double-spend transaction. I posted about 3 such transactions here, and retep replied, pointing out that these double-spends could have been made by anyone, not necessarily the big spender. I hadn't thought of that before, but it's quite interesting. Anyone can double-spend any transaction they see on the network by rewriting the transaction without needing access to the sender's private keys. It doesn't change any of the inputs or outputs, but it does change the transaction hash, and so changes the SD lucky number. Bear in mind that it looks like (to me) that the tx was modified to only add an OP_FALSE to the input script. While this doesn't affect the validity of the transaction, it does make it non-standard, meaning that it's not as trivial as just (receive-modify-broadcast). In fact, for this to work, you'd probably need a miner to explicitly help mine it. That's one reason this is suspicious -- it's not just a conflicting transaction: it's a conflicting non-standard transaction that was mined anyway... On the other hand, if I misread where that extra 0x00 byte was going and it was actually padding on the signature itself ... well that's exactly why sipa and gmaxwell have been trying to do: nail down unique representations for every serialized type in the transactions, and making anything that deviates from that non-standard. Then it would have the difficulties of the OP_FALSE description above: the conflicting tx would still be valid, but it would be difficult to propagate since no one would accept it by default. |
|
|
|
It appears I reinvented a bitcoin wheel: https://bitcointalk.org/index.php?topic=104086.0I mean, it's a "standard" crypto trick, but it also looks like Vitalek created exactly the same thing 6 months. And I probably could've used his code. My solution uses a stupidly-inefficient version of matrix-inverse, but that's because it was ridiculously compact, and I thought 8-of-N would be overkill, anyway. He says his could support up to 15-of-N and wanted to go up to 255-of-N. Meh... That is the plan, correct, to have a QR code for each split paper backup that could scanned in easily?
With this feature you could keep a brain wallet by memorizing a passphrase but also backup the generated private key by splitting it N-ways among family, attorney, etc., in case of death, and put recombination instructions (and may one of the split QR codes) in your will.
Yes, there will be QR codes everywhere. But I don't have plans to implement a QR reader in Armory unless someone basically does it for me... it's annoying to type in paper-backup stuff, but it should be a once-every-3-years kinda thing for most users. I like the idea of putting one in your will (that's essentially giving it to an attorney, though, isn't it?). You could also have fun nesting these, if you weren't afraid of mind-blowing complexity -- split the secret into M-of-N, and then fragment some of the pieces further. It would allow you to create asymmetrically-important fragments, so that each piece really just represents some fraction of the secret, some pieces worth more than others. I guess you'd get the same thing from simply producing 100-of-N fragmenting, and distributing multiple pieces to each person/place. Then you can keep 10% in your bookshelf, 30% in a safe-deposit box, etc. That would be a ton of data, and QR codes probably wouldn't be very convenient either. This really isn't all that useful, just kinda fun to think about ... It's late, maybe I should sleep instead... |
|
|
|
I've decided it's finally time for Armory to manage its own bitcoind instance. Instead of having the user start bitcoind/Bitcoin-Qt and wait for it to sync, then start Armory. Armory will actually require bitcoind/-qt to not be running, so that it can start its own bitcoind instance (and setup the RPC interface if it's not setup yet). It would then use the RPC interface to monitor bitcoind's progress sync'ing. This will be a major usability upgrade -- the user will spend the same amount of time getting from week-old cold boot to having a synchronized bitcoind+Armory but they didn't have to do any of the work. And it will also likely be a better experience than Bitcoin-Qt, since Armory likes to explain things to the user, so that they have some idea of what's going on and what to expect. Armory will be able to estimate how long until bitcoind is synchronized, and tell the user how it's only a one-time synchronization and future loads will be much faster, etc. And it will only connect "the old way" when it's fully sync'd (which resolves more usability problems, because users get impatient and open Armory prematurely and it chokes). However, I'm having some serious problems with the implementation. I can't reliably guarantee that bitcoind is shutdown, especially if Armory were to crash. So here's what I've got right now: - I have added a SatoshiDaemonManager to Armory. It will autodetect .bitcoin dir and find the bitcoind executable.
- If bitcoin.conf does not exist, it creates it and sets the permissions to 600 (Linux only, still need to figure out windows)
- Use the subprocess module to launch: "sdm.bitcoind = subprocess.Popen([pathToBitcoind, arg1, arg2, ...])"
- Include a call to sdm.bitcoind.terminate() in the shutdown procedure to do a clean shutdown of bitcoind before exiting cleanly.
Now's the hard part: dealing with unclean shutdowns. subprocess.Popen() creates a fork that doesn't necessary go away when the parent process does. I've been doing testing in Linux, and it seems to be inconsistent. But it definitely can leave a ghost bitcoind running which then blocks the user's attempt to restart Bitcoin-Qt or Armory.  The really challenging part of this is that I think I can make a solution work in Linux, but it is most definitely not cross-platform. And Windows is even more complicated, well, because it's windows. One thing I had considered was wrapping Armory itself with an outer script that will run Armory itself in a subprocess, wait for it to quit/die, then check whether the process it spawned is still open and kill it if necessary (will write out the PID when Popen is called, to a file in ARMORY_HOME_DIR, which the outer script can check for after the Armory subprocess exits). The nice thing about this solution is that even if Armory segfaults, the outer script will finish running. However, it's not so clear how easy this will be in windows (which has a totally different process management system), and it certainly will require an OS-dependent code branch -- and both may be kinda complicated. I presume it will work, it just may be a lot of effort... Another solution could be to just check for open Bitcoin-Qt/bitcoind when Armory is started, and ask the user if they are willing to restart it. This is probably not going to work, because it would allow them to reopen Armory, but prevent them from opening Bitcoin-Qt after Armory dies (on the upside, it's good for creating competitive advantage for Armory  ) An ideal solution would be to find a way to create a subprocess that is linked to the current process -- if the current process goes away for any reason, the subprocess should too. So far, I don't see a clean way to do that. It looked like process id groups were the solution in Linux, but may not have an equivalent in Windows. By the way: I will have an option to just use an existing bitcoind/Bitcoin-Qt instance, but most users, especially those who have never used Bitcoin, will benefit dramatically from having this as the default, all-in-one, standalone solution. It will probably show up in the preferences to "Allow using existing already-open Bitcoin-Qt/bitcoind instances". Recommendations, welcome! |
|
|
|
how's the PIN/password for opening a watching wallet coming along?
I've already put in the hooks for encrypting arbitrary data in the wallet with a variety of key/IV sources. The new wallets are far from done, and they probably won't have the feature right away, but it will be easy to add after the initial release. :-) I've heard you mention new wallets a few times now. For users like me, who have some deep storage wallets which we rarely touch, what will be required to update to the new wallets? I'm guessing the cleanest way would be creating a new wallet and draining funds from an old wallet via the block chain (similar to how I switched from a reference client wallet to an armory wallet)? If we don't need the new features, will there be any reason to switch? I guess I'm also asking if the old wallets will remain fully functional in all future versions of Armory? I plan to support "old" wallets by migrating them to the new wallet format. It is kind of a PITA because they have different properties & algorithms than the new wallets (and part of the reason I am doing the new wallets is to use better algorithms), but I can't imagine requiring users to switch wallets entirely -- I get very dirty looks/responses when I tell users that "It's okay you can't import your Satoshi wallet, just send the funds from it to your Armory wallet..." They don't like that, at all. Users will only need to create new wallets if you want to use/import compressed keys, multi-sig linked wallets, external [and encrypted] comments&P2SH backups, fragmented paper backups, encrypted watching-only wallets, multiple wallets derived from the same seed, faster key generation, better change address privacy (using internal and external address chains as described in BIP 32), and even more stuff I can't even think of right now. It is also designed to be very extensible so that it will easily accommodate future feature upgrades without having to create a new format again. And part of that extensibility will be to be able to have multiple chains in one wallet file, including old-wallet chains. The new wallets will be BIP 32 compliant which will also make them interoperable with other clients when everyone switches. Actually one of the other things is a property of BIP 32 wallets, being able to setup secure payment-address-distributors as described here. sending via the blockchain is unnecessary if you can export/import private keys.
Yes you can, but without proper support, you'd be importing a bundle of addresses and still have to create a new deterministic wallet and re-distribute your backups, etc. |
|
|
|
I was doing some Armory testing last night and shutdown Bitcoin-Qt ... meaning my double-spend detection script was disconnected... What timing! <facepalm> However, I turned it on this morning and was able to catch some excitement at 2:44pm EST -- a bunch of bets total 613 BTC was invalidated (at least from where I'm sitting in the network). This invalidation was a straight zero-conf replacement (no replacing tx on which it was depending). This is all the information I have... the first one is the transaction that was invalidated (containing 613 BTC to SD), and the second one is the one that replaced it, looks to be similar... probably just a "re-roll": Transaction:
TxHash: 54825a1963a0fc4b566cd415690986c835a84974ceb00ae3649ed311a39d2a2e (BE)
Version: 1
nInputs: 15
nOutputs: 9
LockTime: 0
Inputs:
PyTxIn:
PrevTxHash: e7b58ff78217d9c2dbf1241caf5fe4fcd92e0d2513377a172fd045549fcdc98f (BE)
TxOutIndex: 0
Script: (493046022100c9f4ebda0ef6a9cdfbec47395f6f9003db03fa6a1e988f6cf6c6)
Sender: 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
Seq: 4294967295
PyTxIn:
PrevTxHash: 73ed5c2ebb46b065ce60e8032dbb302ca35844a422efe97c4e51a899b0f7b5d4 (BE)
TxOutIndex: 0
Script: (483045022100eed323557e4c64468bbc6ea29127d7cc32174040abb1fad80e6f)
Sender: 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
Seq: 4294967295
PyTxIn:
PrevTxHash: 7b22d93449f68c77e983e3293a9f7e2ff1d168cd38fe583e59fcb9f48920c2ee (BE)
TxOutIndex: 0
Script: (47304402200b219204a17742c08b33f010273d8587d92e4250b785c20c202ada)
Sender: 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
Seq: 4294967295
PyTxIn:
PrevTxHash: 3b3d950b16804433a6c51ee20b7f2cbf960c29d4f4f807d4401cf7ecbd129b5d (BE)
TxOutIndex: 0
Script: (483045022100fb3c5b09df5f7ee08fd67a48f100bab72b98caca0627d38f27c5)
Sender: 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
Seq: 4294967295
PyTxIn:
PrevTxHash: 0f2e75cd762a29e99833cd74cfb0146e8e0c9da154c28e3fe3f93b4ae07fb6ff (BE)
TxOutIndex: 0
Script: (493046022100ef1b39f1c8e9a9cfea3078a9b84b14aa28e767f8d68e4f0350e1)
Sender: 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
Seq: 4294967295
PyTxIn:
PrevTxHash: d4bb36bc35374261d09fa9f1b32c30be42eeb7a1b6e065ad49f69ca90f82c9e3 (BE)
TxOutIndex: 0
Script: (483045022048cdb8f317f34cd1ed2aa0f70233ed900ba09b530b7c45fb1756bd)
Sender: 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
Seq: 4294967295
PyTxIn:
PrevTxHash: 673523e82a5522e43495806675fd55827551d19967717de7614a7cb1604ae11c (BE)
TxOutIndex: 0
Script: (483045022100aac3d77c8aea7226d4ce907f3545d1c45dfa3b0e0218679a52df)
Sender: 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
Seq: 4294967295
PyTxIn:
PrevTxHash: d28f2ab759e302242c3364e2b3942b4f8726db582305df80deb5933ede6cb3ec (BE)
TxOutIndex: 0
Script: (47304402201d26918c38b1200b3b8e3902fdc91ad0adc578b6d5cda1f30c94a7)
Sender: 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
Seq: 4294967295
PyTxIn:
PrevTxHash: b43aed06284a97a1977bc6f5f523e175dae220a7e3ea2bae79350279df2e396d (BE)
TxOutIndex: 0
Script: (493046022100d461c1df9eb08a237f7fac396ed5ff4497ed2a6019b00a10b282)
Sender: 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
Seq: 4294967295
PyTxIn:
PrevTxHash: b593b0e4f026f0fa384dc821ffe4a70f567f55696ff509f4b0fa7e148b354815 (BE)
TxOutIndex: 0
Script: (493046022100f35d2b1e7a695df93402d3dcdce356bc0e6d510d2fc437726508)
Sender: 1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric
Seq: 4294967295
PyTxIn:
PrevTxHash: 747969dcc31ea6c3ed01bf7a1c970d50d7dacb885068f8e03b464a5abdfa5e44 (BE)
TxOutIndex: 0
Script: (4730440220704b975e73a8ceb2cff37580ea867a7a792b61b3762bae34092237)
Sender: 1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric
Seq: 4294967295
PyTxIn:
PrevTxHash: e15cddae2f36bbf27045bba9aa0eede24e30e733a83bb4a2214d31a74731cdbd (BE)
TxOutIndex: 0
Script: (47304402205be446e867d43b884756217bc6e1bd414354ad7d1ffbb6ae0b9f51)
Sender: 1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric
Seq: 4294967295
PyTxIn:
PrevTxHash: 3865e1176077e06eca8089bcc49691d22c285a7499564723041104baff1de558 (BE)
TxOutIndex: 8
Script: (48304502206cedfbaf681a98c827445ef33851154dc16dda797a906cd2732e3e)
Sender: 1Di6ux3CQBNXCZLD76BsnYWDo6XnFGzQah
Seq: 4294967295
PyTxIn:
PrevTxHash: 204f7599883588e752578988bc43cb7572010ecd25fe8a34dba7ffdaadf592db (BE)
TxOutIndex: 8
Script: (493046022100d2e46f587078fd6de62172908b5eb2962ea64dae3b6eb96e0a3e)
Sender: 1Di6ux3CQBNXCZLD76BsnYWDo6XnFGzQah
Seq: 4294967295
PyTxIn:
PrevTxHash: 30a8ed895212e2f7f18e67526ae37fbbdf9562017892f79ff8459226be627994 (BE)
TxOutIndex: 8
Script: (493046022100bc7b0681e2ba82ad4f89e83fd21e1a94c6fb402de13cea22fb55)
Sender: 1A3z7M6GhpUejQ5eqgSyjVWRuezeepdKKV
Seq: 4294967295
Outputs:
TxOut:
Value: 10000000000 ( 100.0 )
Script: OP_DUP OP_HASH (1dice97ECuByXAvqXpaYzSaQuPVvrtmz6) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 10000000000 ( 100.0 )
Script: OP_DUP OP_HASH (1dice8EMZmqKvrGE4Qc9bUFf9PX3xaYDp) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 25000000000 ( 250.0 )
Script: OP_DUP OP_HASH (1dice7W2AicHosf5EL3GFDUVga7TgtPFn) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 10000000000 ( 100.0 )
Script: OP_DUP OP_HASH (1dice7fUkz5h4z2wPc1wLMPWgB5mDwKDx) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 5000000000 ( 50.0 )
Script: OP_DUP OP_HASH (1dice7EYzJag7SxkdKXLr8Jn14WUb3Cf1) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 1000000000 ( 10.0 )
Script: OP_DUP OP_HASH (1dice6YgEVBf88erBFra9BHf6ZMoyvG88) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 200000000 ( 2.0 )
Script: OP_DUP OP_HASH (1dice6DPtUMBpWgv8i4pG8HMjXv9qDJWN) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 100000000 ( 1.0 )
Script: OP_DUP OP_HASH (1dice5wwEZT2u6ESAdUGG6MHgCpbQqZiy) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 15215213996 ( 152.15213996 )
Script: OP_DUP OP_HASH (1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ) OP_EQUAL OP_CHECKSIG
Transaction:
TxHash: 47bfb18624d0f1ed09e895fe427dcd9a3cef709d92ccedd48528b7774e8f7e23 (BE)
Version: 1
nInputs: 15
nOutputs: 9
LockTime: 0
Inputs:
PyTxIn:
PrevTxHash: e7b58ff78217d9c2dbf1241caf5fe4fcd92e0d2513377a172fd045549fcdc98f (BE)
TxOutIndex: 0
Script: (00493046022100c9f4ebda0ef6a9cdfbec47395f6f9003db03fa6a1e988f6cf6)
Seq: 4294967295
PyTxIn:
PrevTxHash: 73ed5c2ebb46b065ce60e8032dbb302ca35844a422efe97c4e51a899b0f7b5d4 (BE)
TxOutIndex: 0
Script: (483045022100eed323557e4c64468bbc6ea29127d7cc32174040abb1fad80e6f)
Sender: 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
Seq: 4294967295
PyTxIn:
PrevTxHash: 7b22d93449f68c77e983e3293a9f7e2ff1d168cd38fe583e59fcb9f48920c2ee (BE)
TxOutIndex: 0
Script: (47304402200b219204a17742c08b33f010273d8587d92e4250b785c20c202ada)
Sender: 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
Seq: 4294967295
PyTxIn:
PrevTxHash: 3b3d950b16804433a6c51ee20b7f2cbf960c29d4f4f807d4401cf7ecbd129b5d (BE)
TxOutIndex: 0
Script: (483045022100fb3c5b09df5f7ee08fd67a48f100bab72b98caca0627d38f27c5)
Sender: 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
Seq: 4294967295
PyTxIn:
PrevTxHash: 0f2e75cd762a29e99833cd74cfb0146e8e0c9da154c28e3fe3f93b4ae07fb6ff (BE)
TxOutIndex: 0
Script: (493046022100ef1b39f1c8e9a9cfea3078a9b84b14aa28e767f8d68e4f0350e1)
Sender: 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
Seq: 4294967295
PyTxIn:
PrevTxHash: d4bb36bc35374261d09fa9f1b32c30be42eeb7a1b6e065ad49f69ca90f82c9e3 (BE)
TxOutIndex: 0
Script: (483045022048cdb8f317f34cd1ed2aa0f70233ed900ba09b530b7c45fb1756bd)
Sender: 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
Seq: 4294967295
PyTxIn:
PrevTxHash: 673523e82a5522e43495806675fd55827551d19967717de7614a7cb1604ae11c (BE)
TxOutIndex: 0
Script: (483045022100aac3d77c8aea7226d4ce907f3545d1c45dfa3b0e0218679a52df)
Sender: 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
Seq: 4294967295
PyTxIn:
PrevTxHash: d28f2ab759e302242c3364e2b3942b4f8726db582305df80deb5933ede6cb3ec (BE)
TxOutIndex: 0
Script: (47304402201d26918c38b1200b3b8e3902fdc91ad0adc578b6d5cda1f30c94a7)
Sender: 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
Seq: 4294967295
PyTxIn:
PrevTxHash: b43aed06284a97a1977bc6f5f523e175dae220a7e3ea2bae79350279df2e396d (BE)
TxOutIndex: 0
Script: (493046022100d461c1df9eb08a237f7fac396ed5ff4497ed2a6019b00a10b282)
Sender: 1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ
Seq: 4294967295
PyTxIn:
PrevTxHash: b593b0e4f026f0fa384dc821ffe4a70f567f55696ff509f4b0fa7e148b354815 (BE)
TxOutIndex: 0
Script: (493046022100f35d2b1e7a695df93402d3dcdce356bc0e6d510d2fc437726508)
Sender: 1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric
Seq: 4294967295
PyTxIn:
PrevTxHash: 747969dcc31ea6c3ed01bf7a1c970d50d7dacb885068f8e03b464a5abdfa5e44 (BE)
TxOutIndex: 0
Script: (4730440220704b975e73a8ceb2cff37580ea867a7a792b61b3762bae34092237)
Sender: 1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric
Seq: 4294967295
PyTxIn:
PrevTxHash: e15cddae2f36bbf27045bba9aa0eede24e30e733a83bb4a2214d31a74731cdbd (BE)
TxOutIndex: 0
Script: (47304402205be446e867d43b884756217bc6e1bd414354ad7d1ffbb6ae0b9f51)
Sender: 1MxgyKiKiHEemMUTJuq9NAbjmhKnUL5Ric
Seq: 4294967295
PyTxIn:
PrevTxHash: 3865e1176077e06eca8089bcc49691d22c285a7499564723041104baff1de558 (BE)
TxOutIndex: 8
Script: (48304502206cedfbaf681a98c827445ef33851154dc16dda797a906cd2732e3e)
Sender: 1Di6ux3CQBNXCZLD76BsnYWDo6XnFGzQah
Seq: 4294967295
PyTxIn:
PrevTxHash: 204f7599883588e752578988bc43cb7572010ecd25fe8a34dba7ffdaadf592db (BE)
TxOutIndex: 8
Script: (493046022100d2e46f587078fd6de62172908b5eb2962ea64dae3b6eb96e0a3e)
Sender: 1Di6ux3CQBNXCZLD76BsnYWDo6XnFGzQah
Seq: 4294967295
PyTxIn:
PrevTxHash: 30a8ed895212e2f7f18e67526ae37fbbdf9562017892f79ff8459226be627994 (BE)
TxOutIndex: 8
Script: (493046022100bc7b0681e2ba82ad4f89e83fd21e1a94c6fb402de13cea22fb55)
Sender: 1A3z7M6GhpUejQ5eqgSyjVWRuezeepdKKV
Seq: 4294967295
Outputs:
TxOut:
Value: 10000000000 ( 100.0 )
Script: OP_DUP OP_HASH (1dice97ECuByXAvqXpaYzSaQuPVvrtmz6) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 10000000000 ( 100.0 )
Script: OP_DUP OP_HASH (1dice8EMZmqKvrGE4Qc9bUFf9PX3xaYDp) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 25000000000 ( 250.0 )
Script: OP_DUP OP_HASH (1dice7W2AicHosf5EL3GFDUVga7TgtPFn) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 10000000000 ( 100.0 )
Script: OP_DUP OP_HASH (1dice7fUkz5h4z2wPc1wLMPWgB5mDwKDx) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 5000000000 ( 50.0 )
Script: OP_DUP OP_HASH (1dice7EYzJag7SxkdKXLr8Jn14WUb3Cf1) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 1000000000 ( 10.0 )
Script: OP_DUP OP_HASH (1dice6YgEVBf88erBFra9BHf6ZMoyvG88) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 200000000 ( 2.0 )
Script: OP_DUP OP_HASH (1dice6DPtUMBpWgv8i4pG8HMjXv9qDJWN) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 100000000 ( 1.0 )
Script: OP_DUP OP_HASH (1dice5wwEZT2u6ESAdUGG6MHgCpbQqZiy) OP_EQUAL OP_CHECKSIG
TxOut:
Value: 15215213996 ( 152.15213996 )
Script: OP_DUP OP_HASH (1EP4rM8hLZCRSWPNZDWJp9zdvmoWYkkgbQ) OP_EQUAL OP_CHECKSIG
|
|
|
|
how's the PIN/password for opening a watching wallet coming along?
I've already put in the hooks for encrypting arbitrary data in the wallet with a variety of key/IV sources. The new wallets are far from done, and they probably won't have the feature right away, but it will be easy to add after the initial release. :-) |
|
|
|
|
@ Meni,
Sorry, I didn't mean to get defensive. Just a misunderstanding. Really the important part of what I was saying was: "This feature has no effect on my intention to finish and promote multi-sig wallets and all their wonderful features/benefits, and I totally agree with you that a proper multi-signature solution is still needed." Perhaps I misunderstood the intention of the original post.
I think the misunderstanding (and the answer to deeplink) is that what I posted about doesn't have anything to do with spending your coins. It's purely a backup thing so you can recover your single-signature wallet in 10 years when your offline computer finally bites the dust. This is a terrible idea for spending coins -- if you want to require 2-of-3 things every time you spend coins, don't use this. Use multi-sig wallets (which aren't available yet, but I'm working on it).
Context: Right now Armory has a one-time-only paper-backup that will backup your single-sig wallet for ever. I recommend you use it and keep a copy in a safe-deposit box and you'll never lose your coins. You may not need it for 10 years, but then your HDD crashes and you can make one trip back to the bank to get it and recover your wallet. Some people, though, are concerned about the physical safety of their paper backup (bank employees snooping, someone breaking into your house and finding it). They would prefer that someone touching your paper backup doesn't get to clean you out instantly.
For actually protecting your day-to-day purchases from theft, you can increase your security (over Bitcoin-Qt) by using (1) Offline wallets, or (2) Multi-sig wallets. Armory has #1 right now, and should have #2, soon. And this split-backup thing has nothing to do with that.
|
|
|
|
I understood this. What I mean is that if you store your private key exclusively on paper, storing it with 2-of-3 secret sharing still leaves a vulnerability when the shares are imported and combined (mitigated by combining in an offline clean computer, but still). If you have a 2-of-3 multisig address, and store the keys for that on 3 distinct pieces of paper, you get more security.
@Meni, I think you're getting stuck on the idea that I have in some way proposed this idea as a replacement for multi-sig wallets. This is not intended to replace multi-sig. I'm not comparing it to multi-sig. It's nothing to do with multi-sig, at all. 0% related. It's simply an alternative for backing up your regular single-sig wallet. Your single-sig paper-backup has all the security risks you describe, but it's still an important use-case that many users (and maybe even organizations) will use even when multi-sig is available. Multi-sig is completely unrelated to this, and is still my number one goal for the new wallets. Though, I guess you could technically create a 2-of-3 multi-sig wallet between multiple devices or parties, and each party could back up their own wallet using a M-of-N split-backup... sounds complicated. In fact, I might try to discourage fragmenting multi-sig-wallet backups because of it being complicated (but there's no reason it couldn't still be done)... Use-case 1: simple user wants to use Bitcoin, and wants to have it backed up, but doesn't want any one user to have control of it. He may create a 3-of-6 split-backup of his single-sig wallet, keep one, and give the others to five friends who don't know each other (and don't know who they'd even contact to find the other pieces). Use-case 2: These super-paranoid folks who think that someone at the bank will snoop in their safe-deposit box. Okay, so use two safe-deposit boxes at different banks, distributing 2-of-3 pieces (keep one, put the other two in two different banks). The likelihood of snooping is ridiculously low, but apparently still enough for the paranoids. However, that stupidly-low probability is squared when it's two unrelated banks so even most tin-foil hatters would be satisfied. Use-case 3: Simply hide a few pieces around your house. As ben-abuya said, finding a single one won't be sufficient, but in 10 years from now when you need it, you'll surely be able to remember at least 3 of the 10 places you split it (hell, hide one at your grandmother's house in one the 10,000 books she has on her bookshelves -- she doesn't even have to know or care that it's there) |
|
|
|
@etotheipi: That's cool. Eventually though, multi-sig would be much cooler and safer than just secret-sharing a single private key.
This is not a replacement for multi-sig. It is to provide an alternative, flexible way to create and store paper backups. Multi-factor auth wallets (linked wallets) are still coming... with the new wallet files... if I ever finish them... EDIT: I see what I wasn't clear about -- this is for paper backups, not multi-sig wallet chains. You will be able to print a single paper backup, or if you are in advanced/expert mode, you can choose M and N to print off an M-of-N paper backup. Then it would print off a single piece of paper that can be cut with scissors into N strips, requiring any combination of M strips in order to recover your secret (or check a box to print N separate pages). I just didn't want to do this with the current wallets, because each strip contains data that is 2x the size of the secret to be split, and the current paper backups already store 512 bits. Thus, if you split your paper backup into 3-of-5 like my example above, in order to recover the secret you'll be typing 3 kB into Armory by hand! That's a lot! Originally, I was just planning to wait for the new wallets which will only require backing up 160 bits, which is a lot better (and about the best I can do). Since someone explicitly asked about it just after I finished it, I decided to share that it's available already if you are willing to do some work. |
|
|
|
Request: This isn't exactly secret, but I didn't plan to release it yet. So don't go telling all your friends, yet... let people stumble on this thread on their own
You're ridiculous! I was going to keep this a secret until I released the new wallets, but that may still be a while, and the feature is technically already done. If you hadn't specifically requested exactly what I just finished a few days ago, I was going to leave it to be part of mega-release with the new wallets However, it's not integrated into the GUI, because the current wallets use a ton of data to represent a wallet, and splitting them results in each part being even 2x bigger. The new wallets will use 160 bits instead of 512, making it a lot more "friendly" to apply this technique. However, if you don't mind that it will be a ridiculous amount of data and you have some patience with the command line, you can do this right now! (It's so fresh though, you have to switch to the "armoryd" branch which is where I've been doing my latest development) If you're into math, you might enjoy the description of how this works, at the bottom of this post. For now, here's some sample output from my unit-test:
Splitting secret into 3-of-5: secret=9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f
Fragments:
Fragment 1: [a272f36702ea5db5d89d9c41931faba0, ab273c91fef6de0d5cc3dc5e87712255]
Fragment 2: [3b5090051d3684c2ca8aa241b353ae0e, 56cfeec3a5c2dc64c05c4649bcc851a2]
Fragment 3: [49bc409989e5b8dbb9f3241bec05f5bc, 27e8cf636660f8819112fdc58d8f0352]
Fragment 4: [46822a24fc0243e438779d28e29799e4, 312166ef08a03608a8083123445d44e7]
Fragment 5: [630744fd7c3c59d632b93949901ea8be, b18f33873447825b8ab52f424e7caf28]
Reconstructing secret from various subsets of fragments...
The reconstructed secret is: 9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f
The reconstructed secret is: 9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f
The reconstructed secret is: 9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f
The reconstructed secret is: 9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f
The reconstructed secret is: 9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f
The reconstructed secret is: 9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f
The reconstructed secret is: 9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f
The reconstructed secret is: 9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f
The reconstructed secret is: 9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f
The reconstructed secret is: 9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f9f
Splitting secret took: 0.00063 sec
Reconstructing takes: 0.00290 sec
The code that generated what is above is in unittest.py: from armoryengine import *
M,N = 3,5
nbytes=16
secretHex = '9f'*16
secret = hex_to_binary(secretHex)
print '\nSplitting secret into %d-of-%d: secret=%s' % (M,N,secretHex)
tstart = RightNow()
out = SplitSecret(secret, M, N)
tsplit = RightNow() - tstart
print 'Fragments:'
for i in range(len(out)):
x = binary_to_hex(out[i][0])
y = binary_to_hex(out[i][1])
print ' Fragment %d: [%s, %s]' % (i+1,x,y)
trecon = 0
print 'Reconstructing secret from various subsets of fragments...'
for i in range(10):
shuffle(out)
tstart = RightNow()
reconstruct = ReconstructSecret(out, M, nbytes)
trecon += RightNow() - tstart
print ' The reconstructed secret is:', binary_to_hex(reconstruct)
print 'Splitting secret took: %0.5f sec' % tsplit
print 'Reconstructing takes: %0.5f sec' % (trecon/10)
I'm not sure I can cram it into the GUI and subject users to typing in 1kB/fragment. That's a lot of data! I think I'll skip that for now, and just focus on finishing the new wallets and release it with that... Enjoy!
The Math: It's a super-elegant solution: encode your secret into the coefficients of a polynomial, and then distribute points on that polynomial. If it's a first-degree polynomial (line), two points are needed to solve the coefficients (and thus recover the secret). If you want to require 3 points, use a second-degree poly (parabola). Use higher order if you want to require more pieces. The cooler part about this is that you have to use finite fields if you want any chance of this working with 256-bit numbers: pick a large prime number, N, and do all operations modulo N. This creates a cyclic group of size N. Things like division are simply A/B = A*(B^(N-1)). You can't do it with floats or doubles, because there's not enough precision to track all the significant digits in the variables and you'd die from the rounding errors. And the coolest part is how little code was required to implement all the finite-field matrix operations in python! There's nothing efficient about it, but it doesn't need to be efficient to be useful here. It is still usable up to 8-of-N secret splitting -- it takes a couple seconds to reconstruct, but who cares! |
|
|
|
Armory Links: ( Armory Homepage) ( Get Armory) ( Quick Start) ( Cold Storage) ( Github Project Page) ( Report Issues)
Thanks to theymos for making a subforum just for Armory! It will now be much easier to discuss smaller issues/bugs/feature-requests without triggering notifications for every user who's ever used Armory! Don't be afraid to start new threads, even for small things! It will de-clutter the general-discussion thread, and will make searching for previously-discussed topics easier. If you're new to Armory, please checkout its homepage, or use the links at the top of this post to jump directly where you want to go. Please see below for general information about Armory features:  - Deterministic wallets: Your entire wallet is recoverable from only the root address and a "chaincode." You only need to backup your wallet once, and your funds will be safe forever. (NOTE: if you have imported private keys, consider using the "Backup Individual Keys" dialog instead --you can backup both the root key & chaincode, along with the raw private key data for imported keys, all in one screen).
- Paper-backups: Print a paper backup of your wallet on one sheet of paper, and keep it in a book on your bookshelf, in a safe, or drop it in a safe-deposit box at your bank. Paper wallets are superior to digital media, because paper is cheap, easy to store, and you can verify the integrity of the backup by eye. If you backup your wallet to a USB key, how do you know that it will still work when you plug it in two years from now? If you can read the characters on the paper backup, you can recover all the funds you ever received to it!
- One-time-only Backups: Did you know that you need to backup your Bitcoin-Qt wallet every 100 addresses? This is a dangerous and unnecessary burden for most users. With Armory, regardless of whether you make a paper backup or digital backup, it will be good forever. Do it once (though, maybe multiple copies). Store it safely. Never worry again about whether your coins are protected against hard-drive failure
- Multi-wallet interface: Manage as many wallets as you want simultaneously. Armory was designed from the start for multi-wallet operations without limit on number.
- Usermode Options: Choose between "Standard", "Advanced" and "Expert", to scale the functionality according to your experience level. "Standard" user mode has a reduced set of functionality and only presents information necessary for basic wallet management and transactions. "Advanced" and "Expert" modes have a plethora of extra options and information that most users don't need or want.
- Watching-only wallets: "Watching-only" wallets can be used generate addresses and confirm incoming payments, but cannot spend the money. Keep the full wallet on an offline computer, and maintain it safely from the online computer. Or create a master wallet for your business, and give a watching-only copy to your employees to do business. It's impossible for a hacker (or employee) to steal your Bitcoins if your private keys are on a computer that never touched the internet!
- Offline Wallet Interface: This is the holy-grail feature of Armory! You can use Armory to create a wallet on a computer that will never touch the internet again, and then make a watching-only copy to use on the internet computer. You can monitor transactions online, and sign transactions offline without needing the blockchain. And since it doesn't need the blockchain, even a computer with 512 MB of RAM can be used as the offline system. Please see the offline-wallet tutorial! (you will need a USB key to shuttle data between computers, but the entire process for offline transactions can be done in under one minute!).
- Wallet encryption with GPU-resistent key derivation function: AES256 in-place key encryption. Encryption key is generated with a scrypt-based algorithm to renders GPU-acceleration useless for brute-force passphrase guessing. Speed and memory parameters are calibrated to your system speed.
- Corruption-resistent wallet files Wallet code auto-corrects bit-flips on your hard-drive, and also uses a synchronous backup wallet scheme that guarantees no matter which nanosecond the power goes out, your wallet will never be corrupted (or automatically recovered if it does).
- Import/Sweep Addresses: Import trusted private keys into your wallets, or just "sweep" the funds to another address in your wallet. Supports private keys in hex, base58, and mini-private-key format used on Casascius physical bitcoins (it does work with Vanitygen addresses!)
- Get your private keys! There is no database software obscuring key data. All keys are stored in a straightforward binary wallet format, and easily extractable. If you want to switch to another wallet application, you can simply "Backup Individual Keys" and import them into the other wallet.
- Developer-Friendly! Thoroughly-commented Python code. Thoroughly-commented C++ code. Thousands of lines of unit-test code for verifying almost every sub-function of the entire library. Simple wallet files. And the "Developer" user mode will give you everything you could possibly need to help you with your own development: browse the blockchain, examine tx scripts, etc.
- Windows and Linux! (Mac/OSX with some work). Exhaustive instructions for compiling on the Building Armory page. Will eventually offer real OSX support, but for now it can be downloaded and installed with only a few terminal commands (after installing xcode). See Red Emerald's instructions if you want to take a shot at it. Will eventually figure out OSX packaging, but for now users who attempt to do it with RE's instructions have reported wide success.
|
|
|
|
|
Really not targeted at any one in particular, but now that Armory has its own subforum, please feel free to start new threads even for small issues. It will declutter this thread, leaving notifications for more-important issues. And it makes it easier for other users to search.
|
|
|
|
Question:
I need to provide a ~20 char password before sending coins. Sometimes when I make a few (single) payments in a row, I don't have to put in a password, and I don't know how I am doing this. I copy my PW from keepass, and when I click on armory, the coins are already sent.
How am I doing this? Is armory checking my clipboard for a pw?
0.86.3-beta
The password is cached in RAM for 10-20 seconds after you enter your passphrase. If you do something that requires your passphrase within this time window, it will still used the cached value. There's a heartbeat function in Armory which runs every second, and one of the things it does is check if the passphrase needs to be destroyed. Does not use the clipboard at all. |
|
|
|
Obligatory conspiracy mode: If you didn't get any money directly from Erik then etotheipi simply robbed you from your rightfully gained income. Ask him for a proof that he didn't get any money from Erik! etotheipi will be probably ashamed to admit that he neglected to squeeze any funds from Erik or at least have a cross-promotion deal with him regarding Armory.
Boring mode: I have nothing against your posts. The thread just drifted quite far. The original posts had some data about what percentage of transactions and what percentage of blockchain space is caused by Satoshi Dice. Now it is more about the financial aspect.
etotheipi can move this thread: there should be "move topic" and "lock topic" available to him. It just remains to choose which area to move to.
Hah! I'm in the same boat as dooglus -- Erik has contacted me a few times asking for some analysis/advice on statistical matters, and then subsequently tipped for that advice. But he's never even mentioned this thread, other than implicitly knowing that I already know when he's had a bad day and I already have all the data I would need to do some analysis... On that note, I should thank dooglus for doing all this work. I originally made the SD thread to track a variety of things, not just the blockchain bloat. The "statistical analysis" in the title, still makes the financial aspect relevant. I just wish I had more time to analyze the data with my statistical skillz. I didn't realize that I could move threads... once there is some consensus about where it should go, I'll be happy to move it. |
|
|
|
I'm pretty sure I tweaked the "MAX" button in the latest version. When it warns you about the fee that you need, it should automatically update the fee field with that value. Just hitting MAX again simply subtracts the new fee from your balance and the tx should definitely be valid. Let me know if that isn't the case. I have it on my TODO list to implement a simple "Sweep Wallet" function.
ooooh, i figured out what it is.... what you describe is only valid where X != 0 i would argue that the option to send with zero fee be up to the individual, but i vaguely recall you being totally against such use. I don't totally understand. There is a way to specify fee at the bottom. If Armory tells you that you need 0.02 fee, then you used to just be able to change the fee to 0.02, and hit the MAX button. Now, when it tells you that you need 0.02 fee, it should automatically change the fee for you -- all you need to do is hit MAX again and "Send". I'm not against zero-fees (in most cases), but the issue is that Armory uses Bitcoin-Qt/bitcoind as a gateway to the Bitcoin network. If your fee is insufficient for Bitcoin-Qt's fee rules, your sub-standard-fee tx is dead-on-arrival and will not be forwarded to the network. There's nothing I can about this... unless I setup bitcoind's RPC interface and use the sendrawtransaction (?) command ... but so far I don't use RPC at all, and I don't want to enable it if the user hasn't done it themselves already. |
|
|
|
- automatically calculate for me the maximum send amount for a given fee amount (instead of making me play a tedious game of higher/lower until it gives the confirmation screen)
What version are you using? A couple of these have been done already. I honestly can't remember when some of these were added, so grab 0.87.2 from the googlecode download page (which is stable, by the way): http://code.google.com/p/bitcoinarmory/downloads/listThe latest version has: - A while ago, I added a "MAX" button to the send-bitcoin screens so that it will fill in the exact amount for you. If the fee is off, it will fix the fee for you, and you just click "MAX" again.
thanks very much for your reply. i'm still on 0.82.2-alpha. but i can tell you the above MAX thing does work as you describe, however that simply pre-populates the amount field by a simple Balance minus fee = amount, but does not appear to do any attempt to look at the actual built transaction. it's only *after* you press send that it does all that calculating, and if okay will present the confirmation screen. if not okay, it'll ask you to adjust the fee. ... In Armory-release time, 0.82.2 is ancient. And that is before the wallet-optimization that should make Armory usable for such huge wallets. Luckily, I have a test wallet with thousands of addresses and tx, so I'm on top of these things now . I now keep a variety of wallets loaded at all times to ensure that I am stressing Armory. The speed should definitely be fixed in 0.87.2. You'll also get the multi-threaded interface, which is a lot more pleasant to use, anyway I'm pretty sure I tweaked the "MAX" button in the latest version. When it warns you about the fee that you need, it should automatically update the fee field with that value. Just hitting MAX again simply subtracts the new fee from your balance and the tx should definitely be valid. Let me know if that isn't the case. I have it on my TODO list to implement a simple "Sweep Wallet" function. |
|
|
|
um, i haven't been following this thread for a while, but here i'll dump my current wish list: - ability to vertically stretch the list of Available Wallets.
- ability to sort available wallets by Name, Security, or Balance (and have Armory actually remember that setting)
- ability to add a custom Filter to show transactions for a personally chosen group of wallets
- ability to Remove Imported Addresses in bulk
- ordinal numbers in first column of 'Addresses in Wallet' list
- ability to set permanent default to 'Multiple Keys' in Private Key Import
- ability to set permanent default to 'Import these addresses...' in Private Key Import
- option to always or never rescan after import, so it doesn't prompt every time
- option to keep Use wallet encryption unchecked by default on wallet creation dialogue
- get rid of header text and string " (Imported)" when exporting list of addresses.
- handle the blockchain itself, without relying on qt
- option to only use imported or specific addresses when receiving change
- automatically calculate for me the maximum send amount for a given fee amount (instead of making me play a tedious game of higher/lower until it gives the confirmation screen)
and of course saved the best for last... - ability to handle a wallet with 10,000 imported addresses on an i7 + 8gb RAM without 'Not Responding' for 10 minutes on every click
thanks for reading! What version are you using? A couple of these have been done already. I honestly can't remember when some of these were added, so grab 0.87.2 from the googlecode download page (which is stable, by the way): http://code.google.com/p/bitcoinarmory/downloads/listThe latest version has: - Ordinal numbers in the left column of the address listing.
- A while ago, I added a "MAX" button to the send-bitcoin screens so that it will fill in the exact amount for you. If the fee is off, it will fix the fee for you, and you just click "MAX" again.
- In expert mode, you can select the change address to use. It will save the setting between transactions, only for that wallet. Unfortunately, there's no way to send change "always to imported address" since Armory can't generate new "imported addresses". If you are okay with reusing addresses, then just put one of them in there, or just have it always sent back to the first input address. This will guarantee that all coins stay in imported addresses.
- I haven't tested with 10k+ addresses, but in more-recent version of Armory, I have added some ledger optimizations that should make Armory behave much better with large wallets. If you are not using the latest version, please upgrade and try it (there is some under-the-hood optimizations, as well as ledger paging). If you still have issues with the latest version, then I have work to do...
The "manage its own blockchain data" is coming. It's one of the major things on my todo list. It will require quite a bit of testing, but Armory is finally ready to do it. Along with managing Bitcoin-Qt itself. I will add most of the other things you listed to my TODO list. Admittedly, it sounds like you're a very heavy imported-address-user and dozens of wallets... which was not originally the focus of Armory's development -- don't get me wrong, I want to support your use case, it's just that most users only import a few addresses and make a couple wallets, so I've been focusing on that use case. It definitely needs some extra attention for your use-case. |
|
|
|
|
Show Posts
