Am I really missing a search function for comments?
There is no search function. Sorry. I haven't yet figured out how display search results without doing a lot of work. It's on my todo list. I assume that sorting the column doesn't help? |
|
|
|
Yeah, I definitely want to have the add/remove/create/rescanwallet functions. Armory is capable of doing it, though adding a wallet will usually induce a rescan which could make your make your JSON interface useless for a couple minutes.
Is it a option to do the rescan in a (parallel) external process? If this process returns the input, to the under laying database or memory, it takes a time span to obtain the data but the armoryd processes can keep running? Or a temporary armoryd for the rescan of the specific new wallet. Gathered additional info (addresses and transactions for this wallet) put into the database/memory and the temporary armoryd exits. I'm very n00b with this kind of processes, but I do hope this kind of solution is possible. I still prefer a stable and 24/7 daemon. The add/rescan process is necessary, can take some time, but should not stall any daemon/JSON processes. Even though I have multithreading already, I realized it shouldn't be too difficult to do a raw rescan without TheBDM at all, meaning it could happen without putting Armory into offline mode, and then it would simply injected the registered transactions it finds when it's done (it would be a bit of work modify it like this, but it would work).
Unfortunately, 24/7 is a stretch at the minute: I am experiencing seg faults when Bitcoin-Qt/bitcoind splits block files, even though I have a unit-test that tests exactly that event! I'm going to have to dig into this again.
On the other hand, this all goes away when I do the full/final RAM reduction and finally have Armory maintaining its own blockdata. Once I have this, there is no more clashing with Bitcoin-Qt, and a whole host of problems will go away. I'm very temped to jump back to this before the new wallets, because of the usability improvement in addition to al lthese stupid problems going away.
I cannot understand exactly what you are trying to say, but it seem to me this is a big and crucial decision for the way Armory functions within the bitcoin (software) environment. I do remember your primary reason to stick with the original bitcoin client are the network functions. If you maintain your own blockdata, can you still use the networkfunctions? Scanning the blockdata to be able to add a wallet (concerning historical data) is a lot different than to add data to the (own) blockdata yourself (concerning new data). On the other hand, maybe the way the original bitcoin client adds data is not difficult at all? The second part that you quoted of me answered your first part -- having it scan completely in the background without stalling the BDM is what I will do. It will require a bit of work, because right now "scanning" involves updating the BDM as it is scanning, which is why it must go offline to avoid race conditions. But I can execute the scan in a ghost thread, then extract just the collected data and inject it into TheBDM when it's done. The injection would take a fraction of a second, so it would hardly be noticeable. The downside is that I need to implement more interface options, such is "isScanning", "queuedAddresses", etc. It's doable and necessary -- it's just not trivial. I know how important 24/7 stability is. And I'm almost there -- I currently, already, run Armory for 5+ days at a time, in both Windows and Linux. The last couple issues are tough to track because of how infrequent they are, but I am fairly certain they have to do with timing issues related to clashing with Bitcoin-Qt in the blkfiles. If I simply got everything from Bitcoin-Qt via sockets and managed my own blockchain files, those would go away, by definition, but I think I will be fixing them, as-is, right now. Btw, I only use Bitcoin-Qt as a regular peer -- no JSON-RPC -- but it is a trusted peer (critical!). It is essentially a filter/gateway between Armory and the rest of the network, endowing Armory users with the network security of Bitcoin-Qt/bitcoind, filtering out invalid tx and blocks, etc. Armory still organizes the headers, calculates the longest chain, invalidates orphans, etc. But it relies on bitcoind/-qt for the nitty-gritty verification activities, and DoS protection, etc. |
|
|
|
For a daemon it is a good thing if the functions "addwallet(filename.wallet)", "removewallet(wallet name or file name)" and "rescanwallets" are available. If you want the daemon run for 24/7 a restart (to load a new wallet or exclude one) is not preferred. Also the memory requirements is a attention. I do not know how the memory requirement with ArmoryQT for a additional wallet works, but I expect it is not 1.5Gb for each wallet. I think the last part is answered by my multi-wallet answer. If you have recommendations for how to accommodate multi-wallet armoryd that more intelligently, I'm happy to entertain it!
Yes you did, I will happy to do so and thanks!  Yeah, I definitely want to have the add/remove/create/rescanwallet functions. Armory is capable of doing it, though adding a wallet will usually induce a rescan which could make your make your JSON interface useless for a couple minutes. Even though I have multithreading already, I realized it shouldn't be too difficult to do a raw rescan without TheBDM at all, meaning it could happen without putting Armory into offline mode, and then it would simply injected the registered transactions it finds when it's done (it would be a bit of work modify it like this, but it would work). Unfortunately, 24/7 is a stretch at the minute: I am experiencing seg faults when Bitcoin-Qt/bitcoind splits block files, even though I have a unit-test that tests exactly that event! I'm going to have to dig into this again. On the other hand, this all goes away when I do the full/final RAM reduction and finally have Armory maintaining its own blockdata. Once I have this, there is no more clashing with Bitcoin-Qt, and a whole host of problems will go away. I'm very temped to jump back to this before the new wallets, because of the usability improvement in addition to al lthese stupid problems going away. etotheipi, could you upload latest signed archive with source tarball to your site (or amazon)?
N.Z. I just pushed a signed tag into the git repo. You can checkout the tag, v0.87.2-beta, and verify it using "git tag -v v0.87.2-beta". |
|
|
|
|
Even if it doesn't solve a block, it's still proof that you did work in an attempt to solve the block. If you have X GH/s, you will produce Y shares per minute. If you have 2X GH/s, you will produce 2Y shares per minute (on average). By seeing how many shares you produce per minute, the pool software can estimate the total computation power you are contributing to the pool. If they don't submit shares, then the pool only gets one message per block, from the one miner that found the block -- thye have no idea how much work the other miners did.
|
|
|
|
wachtwoord, dude, I gave you the link to official Tails description on how to use Truecrypt, how can I unambiguify it more? Except if you are using some software called TrueScrypt, I can`t help then, lol Also I won`t teach you how to use Truecrypt itself, I`ll leave it to very good documentation and Mr. Google I suggest you to install Tails with its built-in installer to USB and configure Persistent volume with built-in configure tool. It is easier and more "official way" than Truecrypt in Tails. Come on N.Z., go a little easy on the linux-n00b I remember those days... lots of confusing command line arguments, figuring out how to re-add windows to my grub menu, the dreadful "kernel panic"... great fun! If I get some time, I might try the Tails thing, too. Maybe I can write up a more-specific instructions. I think having an 'offline" setup that doesn't require separate hardware is a nice alternative. |
|
|
|
etotheipi, could you upload latest signed archive with source tarball to your site (or amazon)?
0.87 tag in git is signed, but I never actually signed any tar balls or anything. I will make sure to go sign 0.87.2 tonight since I forgot. Use "git tag -v v0.87" I know the website is down-my webhost told me it should only be another day... They just moved their entire operation. |
|
|
|
What's the sensible reaction here? I'd say destruction is a feature, not a bug. Original owner can prove that he owned that shares and he can ask for replacement from issuer. Issuer can investigate the situation, and if shares were indeed destroyed he can issue some new ones and give them to this shareholder free of charge.
However, if coins are not destroyed, they might end up in a wallet of a person who isn't supposed to own them, and you cannot fix that if that person does not cooperate.
...
Note that with my approach towards mixing, automatic un-mixing is possible, it just needs to be issuer-mediated.
For example, issuer publishes unmix-this-please address. If there is a fuck-up, person sends his mixed coins to that address, issuer transfers them internally and returns some part of coins via his issuing address, thus making them colored again. The rest is returned via a normal address, which leaves them uncolored.
If several colors are mixed, issuers can use deterministic satoshi tracking algo to verify correctness. (The idea is to assign an unique number to each coinbase satoshi, tracking it through transactions and fees. Then color of satoshi is preserved under all transformations.)
I think the key is that color destruction is provable, and issuer-mediation can fix it. But, when 10% of the shares of a company are destroyed, how do other 90% owners of that company know what the new issuance will be? Is it a subscription service that the color definitions can be updated? Do clients try to track all related coins and know what the total amount is? Without new color definitions other users may believe that their own shares popped up in value by 11% when those 10% shares were destroyed. |
|
|
|
|
I'm not sure I even understand fully. What is the point of the TC container? I can think of only two reasons:
(1) You really don't trust Armory wallet encryption
(2) You want even the watching-only portions of the wallet to be encrypted, too (which will actually be an option with the new, upcoming wallets)
I only ask because it seems redundant, and makes it a bit more effort to setup and use.
Also, as Wachtwoord suggested, why bother with two USB keys? Can't you just get yourself a single, large USB key, and partition it into OS (Tails) and data (Armory + wallet files)?
|
|
|
|
Sorry, joining this discussion kinda late. I just read through this thread and didn't see a few things that I was hoping to comprehend. Maybe someone can link me to where this was discussed. At least in terms of smart property, the idea that mixing color is destroyed seems dangerous. Mainly because a subtle client bug that still creates valid transactions could end up destroying property. When you say that mixing colors destroys coins, that means shares of a company can go *poof*. Not likely to happen by accident, but I bet it will happen at some point. To someone, somewhere (wrong color ordering, fee subtracted from the wrong place, colored accidentally ending up in the tx fee). It could possibly even happen maliciously. I'd really like to see that coloring is preserved, and that mixing 1 satoshi into your 10 BTC of colored coins does not destroy it. So what is wrong with diluted colors? i.e. what is wrong with this scenario? - I create a 200 BTC genesis tx for "green". Let's say that green represents shares in a company worth $200,000
- I distribute 10 BTC to each of 20 people who now own 5% of that company. So that 10 BTC is worth (10*MtGoxRate + 5%*CompanyValue). At the current price of $16.70/BTC, that means those 10 BTC are worth $10,000 + $167 = $10,167
- I send someone a 100 BTC transaction, using 90 BTC of uncolored inputs and this 10 BTC green input. That person now owns 5% of the company contained in 100 BTC. (100*BTC + 5%CompanyValue)
- That person can now sell someone 40 BTC from that 100 for (40*MtGoxRate + 2%*CompanyValue).
This seems deterministic, unambiguous, and retains the transparency. There is no ordering, or need to understand specific color rules. Obviously the more that coins are diluted, the more annoying it is to handle/sell them, so users would be naturally avoid mixing them, but there may be valid reasons for doing so. At some point the dilution can be so much that there's no point, anymore, and the color is effectively destroyed (perhaps below 1% density). But it wouldn't result in a loss of property without them passing through a lot of oblivious clients. I'm sure I'm not the first person to think of it. Can someone explain the drawbacks to this method or link me to where it's discussed? |
|
|
|
How about you use Armory offline wallets? That's precisely why I built Armory, was to make this feature dead simple. Create a full wallet on an offline computer, make a one-time-ever backup. Make a watching-only copy for your online computer. Generate millions of addresses without fear. Send coins using a USB key to get transactions signed. It's mostly described in the program itself. (unfortunately, I would link you to the tutorial on the website, but I just got notification that the website is down for the day. gah! you can download the latest version from here: https://code.google.com/p/bitcoinarmory/downloads/list) EDIT: Website backup. Checkout the Armory Quick-Start Guide and the Offline wallet tutorial. |
|
|
|
|
Armory has this feature. Kinda.
Just send a regular transaction, and use the "MAX" button and try to send it. If you need a higher fee, it will cancel and fill in the correct fee for you. Just hit the "MAX" button again, and it will recompute based on that correct fee, which won't change because it was already based on sending 100% of your coins. You can now send successfully.
If you don't have enough fee to cover the sweep operation, Armory will let you know. Basically "sorry, there's no way to sweep this wallet." I still haven't figured out how I should gracefully handle that.
At one point I had a button for "Sweep Wallet", but I don't remember why I removed it. I should add it again...
|
|
|
|
|
On the other hand, we could just pass a "convention" that it is appropriate to use the Alternative Clients forums as if they were client sub-forums. You just prefix the subject line with "[ARMORY] Cannot import Bitcoin-Qt wallet" or "[MULTIBIT] Why are you so awesome?", etc
I suppose it depends on the difficulty of setting up an arbitrary number of sub-forums.
|
|
|
|
Testing the armoryd branch...and armoryd...  Setting up a watch-only wallet and make a php jsonrpc call works! Now testing the process of getting unsigned transactions. I have some troubles to add a additional watch-only wallet to armoryd. I get this error after the notification 'Another instance of armoryd.py is already runnning!': ~/BitcoinArmory$ {
"error": {
"errortype": "exceptions.ValueError",
"extrainfo": "No JSON object could be decoded",
"jsoncommand": "armory_abc_.watchonly.wallet",
"jsoncommandargs": []
}
}
It looks like I have to put in some extra arguments to make a second armoryd work with another watch-only. I can't find what the arguments should be. (has it something to do with: AuthServiceProxy def __call__(self, *args) ??) Also I suspect armoryd does not except more arguments (your code states: # The only argument that armoryd.py takes is the wallet to serve) Please let me know where to find some clues to get a second watch-only armoryd running. I'm also wondering how the jsonrpc call is made. Is it to a different RPC_PORT? If not, how do I make a jsonrpc call to a specific wallet? If so, how do I know the rpc_port's of all wallets running? I'm also wondering if it is possible to make use of the authentication of the (proxy) service to identify a wallet/user from the (php) jsonrpc. (otherwise I have to make a authentication for a wallet/user before the (php) jsonrpc call's could be done) The JSON-RPC interface is still a work in progress. I haven't really ironed out things like this yet. But I can give you some workarounds, as long as you promise not be upset when it changes later Specifically, I will be making armoryd.py multi-wallet, just like ArmoryQt is. It will load all wallets in a given directory, and you will be able to "selectwallet", "getwalletinfo", "sendfromwallet", etc. Until then, I guess you'll just have to run multiple copies. So first thing to do is that armoryd.py detects itself via the --rpcport option. I forget the default but you should be able to start more instances by changing that value. If you run armoryd.py on the same port as another one that's already open, it switches from "start-server" mode to "pass-CLI-arguments-to-existing-server" mode. It reads the /home/user/.armory/armoryd.conf file for authentication info, opens a connection with it through the port, then it passes the command line arguments to it as a native JSON-RPC call. It receives the response, prints it out, and disconnects. After all... if they could somehow listen on the same port, how would PHP know which one it was talking to? I think the last part is answered by my multi-wallet answer. If you have recommendations for how to accommodate multi-wallet armoryd that more intelligently, I'm happy to entertain it! |
|
|
|
I've decided to give armory a go (most of the rest of the world spells it armoury, so my spell checker is going nuts right now  ) and the site's not loading  Ahh right. I received notification that my webhost was ... moving. They will be down part of today. If you don't need directions, you can download the latest directly from the googlecode hosting (this is what is linked to from the bitcoinarmory.com website, anyway): bitcoinarmory.googlecode.com downloads page(If you're in linux, just checkout the "testing" branch) Speaking of that: Here is 0.87.2 which has a couple more stability fixes in it. It turns out that I induced some problems with reorg handling a while ago, and had not rerun the reorg-unittest since then. Now I have, and it should be smooth sailing through reorgs in version 0.87.2: Testing version 0.87.2-testing for Windows 64-bitTesting version 0.87.2-testing for Windows 32- and 64-bitTesting version 0.87.2-testing signed SHA256 hashes of installersAs with 0.87.1: the updates are tiny bugfixes with big stability impact. Therefore, I believe that 0.87.1 and 0.87.2 are as stable as a full release, and hence I have provided signatures with them so users can feel comfortable with them.
You have to have some knowledge of what type of shell it is dropping into ... most POSIX-like shells will only accept variables inside curly brackets, e.g. ${VAR}
Yes, I am completely retarded when it comes to bash/shell scripting. I wish everything could be python. I'll try what you suggested. Or maybe you can help me by figuring out how to detect that dynamic filename there...
I have a suggestion: in "Backup Individual Keys" and "View Address Keys", please allow the user to choose whether the keys are delimited by spaces. Keys with spaces are not C&P friendly
I've wanted to add a few options to that dialog for a while, but it never seemed like a high priority. I need to look at what other import formats other services use, and perhaps add some site-specific list-formatting choices. For now, I have simply written things out to optimize having to manually type it in. But of course, I know many will be copy-pasting so I should accommodate that, too.
replace line 26 with:
26 STATICPYTHON += "/usr/lib64/libpython2.7.so.1.0"
and line 29 with:
29 STATICPYTHON += "$(DEPSDIR)/lib64/libpython2.7.so.1.0"
making sure to put either 64 or 32 depending on the architecture.
Interesting... maybe there just haven't been any real users on RH before you? I definitely have not (or do not remember) having to deviate from the format that is there for any previous complaints. I will have to investigate further how to accommodate this (I definitely need a smarter makefile) |
|
|
|
Best I can tell the file doesn't exist.
Well, if python-dev/python-devel is installed it's gotta exist somewhere. That's the point of installing that package, to make it available. In fact, the .so probably exists even with just python installed. Apparently it's in a non-standard location in RH. |
|
|
|
For what it's worth, a couple of months ago somebody recommended removing a large chunk of line 15 and it allowed it to fully compile. But since I'm doing a fresh install I thought it would be a better idea to run it by you first.
Line 15 is what makes this makefile work regardless of what python version you have installed. Unless you have a non-standard python installation. What shows up when you type "ls -la /usr/lib | grep libpython"? You can change line 29 to just point to whatever .a or .so is there. That command gives me nada. Okay, well figure out where your libpython.a or libpython.so file is. That's what line 29 needs to reference. I guess it's in another place in Red Hat...? |
|
|
|
For what it's worth, a couple of months ago somebody recommended removing a large chunk of line 15 and it allowed it to fully compile. But since I'm doing a fresh install I thought it would be a better idea to run it by you first.
Line 15 is what makes this makefile work regardless of what python version you have installed. Unless you have a non-standard python installation. What shows up when you type "ls -la /usr/lib | grep libpython"? You can change line 29 to just point to whatever .a or .so is there. |
|
|
|
No dice. g++: error: /usr/lib/libpython2.7.so: No such file or directory
make[1]: *** [swig] Error 1
make[1]: Leaving directory `/home/seth/BitcoinArmory/cppForSwig'
make: *** [all] Error 2 Oh, have you installed python-dev? Specfically, make sure you have all the dependencies listed on the compile-from-source page: http://bitcoinarmory.com/index.php/building-armory-from-source |
|
|
|
|
Wow, good idea. You're right it's strange it hasn't been thought of before. I always feel annoying constantly triggering notifications for all watchers when one user has a user-specific problem that no one else in the thread really cares about.
+1
|
|
|
|
|
Show Posts
