|
FYI, it turns out that my code.google.com project was banned because I was offering downloads of installers without associated source code. They thought that I was using their service to assist with distribution of closed-source software.
I offered to move the repo to google servers, but they said it was actually fine, as long as it's actually open source and the code is available somewhere. So they re-enabled the downloads and I added a comment to the project description with the link to the github repo. All is well, now.
|
|
|
|
Using armoryengine.py: >>> from armoryengine import *
>>> opList = convertScriptToOpStrings(hex_to_binary('51210241b8aba0994f320a8b438c627dbf31fbdd7dc722dd8418d829d67a9c6e4fd69021036fbd9d0a34a569f10b0431c8aeecf74ad796b99838b7272ef35ded130a794f9b52ae'))
>>> for op in opList:
... print op
...
OP_1
[PUSHDATA -- 33 BYTES:]
0241b8aba0994f320a8b438c627dbf31fbdd7dc722dd8418d829d67a9c6e4fd690
[PUSHDATA -- 33 BYTES:]
036fbd9d0a34a569f10b0431c8aeecf74ad796b99838b7272ef35ded130a794f9b
OP_2
OP_CHECKMULTISIG
So, it's a 1-of-2 multisig script. There are two 33-byte public keys, and you need a signature from either one of them to move those funds. |
|
|
|
Armory is awesome on my new 16GB RAM PC with Linux OS!
The whole blockchain downloaded in 12 hours and Armory's scan took about 2 minutes.
Real men have 32 GB of RAM   |
|
|
|
I have 5 GB of RAM and for me the only real slow part is the startup - that takes several minutes. After that, it works pretty well.
Scratch that. This used to be the case, but it doesn't really work any more. etotheipi, if you're still looking for the installer - Google Code is back up now, so you should be able to download it off there. Are you logged in as a google user? It still get "access denied" for all googlecode pages when logged in. And when logged out, I still can't find it or access it directly. |
|
|
|
No, the only versions I need are 0.87.2 and 0.88.1. I'm not going to post the older version because of some important updates that were put in 0.86.3+. |
|
|
|
Finally bought a new PC with 16GB RAM and 1 TB HD and now I can't download Armory.  Any ideas of when downloads will become available? What's the issue? I thought it was a service-wide outtage because I couldn't access any projects, but it appears that something happened specifically to my project and/or account. If I log out of gmail/google then I can at least start accessing projects again, but the bitcoinarmory project is still not found or accessible. I just submitted a service request to google-code-hosting and we'll see what they say. In the meantime, I may have to relocate the downloads. Edit: Ugh! I just realized I don't have the original, signed files. They were uploaded from my USB key (after signing on the offline computer), then the key was wiped. I guess I never expected code.google.com to go down and take those with it. This may take some work to get it back up... Etotheipi, Just curious so I don't have to check back so often: Are we talking minutes, hours or days? I'm sure others will have the same question. Thanks and hope everything goes smoothly. -xcsler I don't know. I definitely don't have any signed copies of the app anymore. I'd have to re-execute the signing procedure on the offline computer. I guess I'll have to add something to my script to make an archive directory of signed installers to avoid this in the future. On the other hand: all the installers are signed with my GPG key. Theoretically, if one were to provide me with my own installers, I could verify their authenticity. I do still have the signed hash file, so I know what the sha256sums are supposed to look like (and the debs are signed directly). If you have downloaded copies of the installers, please help me out and find a way to get them to me. Then I'll put them in a new download location (after verifying them). |
|
|
|
Finally bought a new PC with 16GB RAM and 1 TB HD and now I can't download Armory. Any ideas of when downloads will become available? What's the issue? I thought it was a service-wide outtage because I couldn't access any projects, but it appears that something happened specifically to my project and/or account. If I log out of gmail/google then I can at least start accessing projects again, but the bitcoinarmory project is still not found or accessible. I just submitted a service request to google-code-hosting and we'll see what they say. In the meantime, I may have to relocate the downloads. Edit: Ugh! I just realized I don't have the original, signed files. They were uploaded from my USB key (after signing on the offline computer), then the key was wiped. I guess I never expected code.google.com to go down and take those with it. This may take some work to get it back up... |
|
|
|
Armory should include a transaction fee when using the "sweep funds to" , function right ?. I just thought I would ask before trying it .
Yes, if the sweep needs a fee, it will notify you and ask for confirmation. It even catches the case that the fee required is bigger than the amount in the address/wallet, and thus... too bad... |
|
|
|
I cannot send a signed transaction what i got from an offline armory client. (old version)
when i press broadcast botton and ask me for the password it tries but it lost connection with bitcoin-qt for a sec and then transaction stands incomplete
My pc w7pro 64bits 8gb RAM
my online armory is up to date but i tryed too 0.8.7.2
i can send you a log file if you want
This is a problem I've heard a couple people have (the disconnect immediately after trying to send). Would you mind sending me the transaction that failed to send? I need to check a hypothesis of mine, but I need a tx that failed. I wouldn't mind the log file, too |
|
|
|
requiring 8GB Ram is not "works great"
(and the main client not disclosing it requires 10+GB of HD is not cool either, but that's a different team).
Well, it does work great if you have 6-8 GB of RAM. Not so well if you don't. There's not really an in-between. I'm making progress on the update so it should use far less than 1 GB when I'm done. In fact, I'd be surprised if it used required even close to that. But I won't know for sure until I'm done. |
|
|
|
The way cold storage works is by making the online computer generate an unsigned transaction, then making the offlline computer sign it.
Your issue will be with getting blockchain.info to actually generate such a thing. I've looked through their faq, and can't find info on how to do it.
Blockchain.info cannot create unsigned transactions of the form required for Armory offline-signing. You need to run Armory on both online and offline computers. The online computer can verify payments and monitor your wallet balance. You use online Armory to create the transaction the same way as you would with a regular wallet, but the output is unsigned. You get it signed by the offline computer before broadcasting/finalizing it. I created a standard for this (BIP 10) but no one else adopted it. Thus, you have to use Armory on the online system if you're going to use it on the offline system. |
|
|
|
There appears to be an issue with the way it is packaged. It seems to work flawlessly for 50% of Mac users, but fails to even start for the other 50%. It sounds like you're in the wrong 50%  A few different people tested it before I "blessed" that result and paid the bounty, before we realized that was a lot of systems on which it didn't work. It sounds like we need another bounty to finish figuring out how to bundle everything properly. |
|
|
|
One of my short-term-sacrifice-for-long-term-gains activities has been making sure that the database design is completely flexible in order to accommodate a future SPV mode as well as super-node mode as well (for doing arbitrary address/UTXO-tree lookup). It won't be trivial to do either update, but I made sure to break out the data structures in a way that may result in the DB engine not requiring any updates to accommodate it -- only the way the outer application makes calls to the DB engine (of course there's a 0% chance that it will work that cleanly, but we can always dream ) That's part of the reason this upgrade took so long -- I didn't want to rush through it and require another major overhaul (like this one) to do those kinds of upgrades. |
|
|
|
Just a quick comment about progress: No, it's not done yet. But I am finally getting some time to do it. And I'm doing it... slowly.
Just wanted to check in on progress -- I am gladly waiting for the upgrade and glad to see you are taking the time to improve the foundation. Making tons of progress on it. As I keep saying in this thread and others: I had some critical priorities crop up, but I have still had a bit of time to work on it, and I think I'm getting closer to something that works. I keep trying to make estimates of when I'll have it, but my estimates have been pretty much useless due to the scope of changes and unpredictability of other things. So I will not put a timeline on it. But what I will say what is done: the DB foundation appears to be functional and working. I have also incorporated google-test into the project and written 5,000+ lines of testing code (a lot of it is for the pre-existing codebase that didn't have proper automated unit-tests, but at least half of it is for the new DB utilities). I'm juggling some of the fine details of hooking up the new DB engine to the BlockUtils.cpp which is where all the magic happens -- for instance I didn't anticipate I would have to switch to a headers-first pipeline due to the way I chose to key the databases (all blocks are stored by their height, which means I can't put them into the DB until I know their height). Headers-first is probably better anyway, but it does require rewriting some solid code that I had hoped to leave in place a bit longer and not complicate this upgrade. Oh well. I already have a solid re-org unit test which is basically the ultimate did-I-get-it-right test. That test took me like a week to create, 18 months ago. Now that it's done, I don't have to spend any more time on it than just running it through. Unfortunately, I may have made an extremely inefficient design decision, that will have to be fixed before any official releases go out (though it won't take me more than a day or two to fix it). Mainly the way I store address histories is going to choke on the SatoshiDice addresses. It should still work, it will just be super slow when new blocks are received. I'll get it working without fixing that, and with luck it will just work fine, anyway. If not, I'll have a unit-test-passing version that can be slowly morphed into the optimized version. I like having solid unit-tests... By the way, if you do any C++ development, I can't speak highly enough about googletest. It's remarkably easy to use, yet has an extraordinary amount of flexibility if you feel it necessary to get creative/advanced. |
|
|
|
I have written some java code to convert paper backup codes into a sequence of keys. Would there be an easy way to generate a file with the 4 lines of text, the unique ID and then the first 1000 public keys (in address format)? I did 2 "manually" and the first 5 addresses matched (it would be nice if you could copy/paste the 4 lines ) I could read in those files and then check that I generate the right sequence of public keys (and that the unique id is correct). Ofc, simply tests that I generate a valid sequence of public/private pairs is enough to make sure most isn't lost. You can get something really close to what you're looking for by: (1) Go into "Expert" usermode (2) Go into your wallet and click on "Addresses Used" (3) Create 1,000 new addresses (4) Go back to your wallet and "Backup Individual Keys" (5) Click "Include Unused (Address Pool)" (6) Mess with the options to get the display you want I know that window doesn't have all the best options for displaying things, but it sounds like it has enough for you. |
|
|
|
Rather than quizzes, I've been working on enumerating some programming exercises for people to do if they want to start Bitcoin programming. They mainly consist of "Write code to open the blk*.dat files and.... (1) Count the number of blocks (2) Count the number of transactions (3) Verify the proof-of-work and merkle root for each block (4) Identify all the different types of TxOut scripts and address strings associated with them (5) Find the orphan blocks, (6) Calculate the number of UTXO in the pruned blockchain (7) etc". With references to the on-the-wire bytemaps and the Protocol Specification. I'm sure I could come up with some cool quizzes, though not specifically about the Bitcoin-Qt code... more about Bitcoin in general and it's quirks (count the endianness switches needed for this process on a LE machine: ...". But I'm not sure how useful that is (not that threads like this need to be highly efficient in their usefulness). But I think it would be neat to have something more elaborate like above to give people concrete ways to get into Bitcoin dev. I guess you forgot about: (0) - I dare you to build this client yourself. IMO, this would rule out like 90% of candidates Yup, 90% of developers probably don't have the skill and patience to become a real Bitcoin developer. If they can't reverse engineer bytemaps and understand UTXO lists, then they're certainly not going to figure out how to deal with reorgs, and the plethora of other things that need special attention and care to get right. |
|
|
|
Rather than quizzes, I've been working on enumerating some programming exercises for people to do if they want to start Bitcoin programming. They mainly consist of "Write code to open the blk*.dat files and.... (1) Count the number of blocks (2) Count the number of transactions (3) Verify the proof-of-work and merkle root for each block (4) Identify all the different types of TxOut scripts and address strings associated with them (5) Find the orphan blocks, (6) Calculate the number of UTXO in the pruned blockchain (7) etc". With references to the on-the-wire bytemaps and the Protocol Specification. I'm sure I could come up with some cool quizzes, though not specifically about the Bitcoin-Qt code... more about Bitcoin in general and it's quirks (count the endianness switches needed for this process on a LE machine: ...". But I'm not sure how useful that is (not that threads like this need to be highly efficient in their usefulness). But I think it would be neat to have something more elaborate like above to give people concrete ways to get into Bitcoin dev. |
|
|
|
Yes. We puzzled over that choice for a long time. I wonder if it is deliberate or just fortunate co-incidence. However we keep discovering interesting quirks of the protocol that turn out to be useful much later on, so I suspect deliberate.
It'd be even better if the entire output structure was serialized, as you suggested.
Given the complexity around OP_CODESEPARATORs in the OP_CHECKSIG procedure, I would guess that Satoshi had a reason for not just copying the whole TxOut, but instead allowing signatures to only include pieces of the previous-TxOut-script. My understanding is that no one has yet determined the usefulness of OP_CODESEPARATOR besides possibly being a potential source of protocol bugs/vulnerabilities. But I would suspect he had a concrete use case for it that we haven't figured out yet. |
|
|
|
How can the counter-party vanishing affect this? You get the refund (Tx2) signed by the payee before you (payor) sign the funding transaction (Tx1). That essentially makes the whole operation atomic: either all parties get their money into an escrow that automatically returns to the payor if one of the parties disappears... or nothing happens.
It's not possible to sign tx2 until tx1 is fully signed; tx2 refers to tx1 by it's hash, which includes the signatures. (the original micropayments channel writeup on the wiki had this mistake too) The merchant doesn't need to see the full tx1 before he signs tx2. He just needs the hash of tx1 and the corresponding output index. If the merchant uses a brand new private key, he can blindly sign the tx2. Yeah that's what I actually meant. Tx1 has to be signed, but doesn't have to be broadcast until tx2 is signed. If Tx2 is never signed, then the signed tx1 is discarded and the channel is effectively canceled. Though there is a question of whether there is a subtle security issue with someone signing to spend a tx they haven't seen (or know for sure that what they saw corresponds to the hash). On the other hand, they have to include the prevTxOutScript in the signature which means that the sig is not valid if the payor gives them a fake tx1 hash. In fact this alone finally makes me realize the value of having to copy the prevTxOutScript into the TxIn before signing |
|
|
|
|
Show Posts
