That is less than encouraging...

I may have to invest time, sooner than later, to implement a robust, scalable, solution in the C++ code.  I was hoping to push it off for a year, and maybe tackle blockchain pruning at the same time (kill two birds with one C++ class).  But it looks like I can't push it off.  Or at least, I should save the state between loads, and doing the blockchain scan in the background after the GUI is open...

Good News:

My downloads page on Github now contains a zip-file:  Armory_Win64_0.70-beta-alpha.zip
This is the experimental release for Windows 64, much like what I released for Linux over the weekend.  If you are on a 64-bit Windows system, please help test!

Bad News:

Windows blows.  MapViewOfFile blows.  LPCWSTRs blows.

• I spent more than two hours trying to figure out how to convert an ubiquitous C++ "string" object to a windows.h "LPCWSTR" object just so I can pass in the filename to the MMAP-equivalent on Windows (MapViewOfFile).
• MapViewOfFile is slow.  On my Win7-64 virtual machine, it takes me 75 seconds to do the initial blockchain scan.  Subsequent rescans take 60 seconds.  I'm hoping this is an artifact the virtual disk used by the VM.  Using FILE_FLAGS_SEQUENTIAL_SCAN actually slows it down for some reason...

If you have experience with Windows programming, and especially using MapViewOfFile, I would really appreciate you glancing at the MVOF implementation.  There's a lot of random constants used, and I copied examples from various sources.  I may have done something stupid, or at least sub-optimal.

Really Bad News:

Windows 32-bit doesn't work.  Period. 


In hindsight, understanding mmap() better now, I don't know why it does work on 32-bit Linux (since it seems like there would be a shortage of virtual memory addresses).   But somehow mmap() works in Linux-32, but fails immediately in Windows-32.  I have tried a few different things but nothing works.  Admittedly, I'm unmotivated to try to accommodate an aging OS when the system works on all the other platforms...

Given the RAM/caching behaviors of mmap(), I was thinking of moving away from it and implementing something else: or maybe take the plunge and start integrating a native blockchain&networking codebase to do everything under the hood.  I was hoping to push that off for a while (at least until after multi-sig).  Maybe I will wait:  I don't want to shut-out WinXP users, but I don't think I can handle another reworking of the blockchain code, especially when I will probably replace all of it eventually...

I hate Windows

That is all.

I don't want to debate the feasibility of the current system "breaking."  There's too many unknowns to say anything with any degree of confidence what will happen 10 years from now in the BTC ecosystem.  I simply wanted to explore the concept of migration, if it were to be necessary.  If it turned out that there was a very easy, smooth way to do it, perhaps it could be a better option than alternatives to dealing with major structural/security SNAFUs.

I intended for this to be theoretical exercise (with feasibility considerations).  It may not be of much use to others.  But there's plenty of discussions about what could be done in a new chain (and many alt-chains already), but I like the idea of being able to migrate without disrupting the existing wealth distribution.

No particular problem.  I'm making a hypothetical assumption that Bitcoin 1.0 has insurmountable problems that will lead to security and integrity issues, and that somehow enough support was available to consider moving to something better.  There's a lot of lessons learned (such as on the Hardfork Wishlist), and it may be in Bitcoin's interest to try to move to something better without throwing everything away and starting over (screwing over everyone who already has BTC).

It would be an extraordinary hurdle to migrate the community of staunch Bitcoin 1.0 followers, no matter what the justification is.  I feel like people would ignore all reasonable warnings about imminent doom and ride the train right into the Bitcoin apocalypse.  But perhaps there's a way to produce a smooth migration scheme that allows users to migrate at their own pace, but still preserve the existing supply curve and wealth distribution.

To follow up on severability:  I suppose if there was enough support, the main BTC software could be updated to "stop" at block 1,000,000, and then all unspent outputs at that block become generation inputs on BTC2.  Then generation would continue as normal on BTC2.  Yes, complicated....

I don't think my idea is really feasible, and even if it was, how much different could BTC2 actually be, given being tied to the BTC1 generation scheme.  But I think it's a useful exercise to know if such a migration was possible.

OP_PUSHDATA(20) <Bitcoin2Address> OP_PUSHDATA(8 ) BITCOIN2 OP_FALSE OP_VERIFY

I already did.   The second-to-last op-code is OP_FALSE which pushes "false" onto the stack, and the OP_VERIFY makes sure the top-value of the stack is "true", else the script fails.   Since this script always runs last, there's nothing any one can do to avoid having OP_FALSE OP_VERIFY at the end. 

That's true, BTC2 would be tied to BTC1 blockchain.  But part of my thought experiment was how that might be "severable" in the future -- perhaps after X years, all unspent outputs become spendable BTC2 -- but that's entirely infeasible since there would tons of users who didn't "understand" and tried to execute transactions on the BTC1 chain that had already been abandoned... 

This severability may not be possible.  Lots of other issues, too.  But, I think this overall idea is a fun thought experiment, which is why I posted it.  Presumably, it would occur because of growing issues with BTC1, and people would want to switch to the new, safer chain.  But the solution doesn't work unless there's some flexibility to migrate at your own pace, and find a way for non-destructive severability.

Alright, here goes...

I have two major ideas planned for multi-signature transactions to go into Armory, as soon as I finish up with the some other priorities.  The first one is fairly straightforward, so I'm just posting for reference.  The second is a bit more controversial and could use some ironing out.

(1) Two-factor authentication without a third-party

There's a more-general version of this for two equally-capable devices, but I'll be implementing this version due to its simplicity and it accommodates one of the most desired use-cases of multi-sig

Setup Wallets:

• Create two new wallets in Armory, A and B
• Print off paper backup of each wallet.
• In wallet B, choose "Remove/Delete Wallet" and delete just the private keys to make it a watching-only wallet, B'
• Scan paper backup B with smartphone
• Stash both paper backups in safe or safety-deposit box

Now your online computer has wallet A (full) and B' (watching-only) and your phone has B (full).  I will probably make a special wallet format for 2-of-2 wallets that makes this process even simpler (and symmetric:  A+B' on one device and A'+B on the other device).

Generate Addresses:

• On computer Armory:  generate new address for this special wallet (A+B')
• Armory finds next unused address index, n, in wallet A.  Computes PubKeyA(n) and PubKeyB(n).
• Create 2-of-2 multisig address

Spending coins:

• On computer, construct transaction as normal.  "Send" button is greyed out.
• Click "Sign for wallet A"
• Signature added, transaction is converted to BIP 0010 packet and displayed as a QR-code (or sequence of them).
• Phone scans QR code(s), displays transaction details, verifies signature A, requests confirmation
• Phone adds second signature, B, and connects to the Bitcoin network and broadcasts

I will probably find QR codes to be difficult to use here.  I'm thinking of other ways I might do it:  perhaps send data to the phone via special email that can automatically be detected by the phone and parsed.  Unfortunately it would never fit into a text message...

But a sequence of QR codes may not be bad... you can tile a lot of QR codes on the screen, and phones are very fast at scanning them.


(2) Buyer-Seller Escrow, with or without third-party

Alice posts an item on craigslist, knowing that unknown, untrusted Bob will try to buy it.  In this case, Alice is the seller and will set the "Risk Deposit" (could also be "Escrow Deposit").

• Alice makes craigslist posting identifying the item for sale, the price (25 BTC), and the desired "Risk Deposit" (20%)
• Bob finds the posting and emails Alice saying "I'll buy it for 20 BTC, 20% deposit is fine, here's a public key, and let's use a third-party Charles."
• Alice agrees so she obtains a public key from Charles, and constructs a very wacky transaction:
  
• Inputs:
  
  • (1) Alice 4 BTC (20% deposit) -- signed using SIGHASH_ANYONECANPAY
  Outputs:
  
  • (1) 28 BTC to TwoOfThree(PubKeyA, PubKeyB, PubKeyC)
  • (2) Alice's change output, if necessary
• Sends incomplete tx to Bob
• Bob verifies that PubKeyC belongs to Charles.
• Bob creates a perfect-sized input of 24+fee BTC, adds it to the tx, signs and broadcasts (Alice's sig is still valid because of ANYONECANPAY)

Now there is 28 BTC locked up in the network requiring two-of-three signatures from Alice, Bob or Charles.  This could be a 2-of-2 tx without Charles, but if one party disappears (before tx completion) the money will be locked forever.

Three possible outcomes:

• Everything goes smoothly, Alice creates "completion transaction":  Inputs:  2-of-3 for 28 BTC and an optional fee input,  Outputs:  Alice 24, Bob 4.  Signs and sends to Bob who signs and broadcasts
  
• Something went wrong, Bob needs a refund.  He constructs tx:  Inputs: 2-of-3 for 28 BTC and optional fee,  Outputs: Alice 4, Bob 24.
• DISPUTE:  Charles contacts both parties, figures out who gets the money -- assume it's Alice -- then Charles creates a Tx;  Inputs:  2-of-3 for 28 BTC + fee;  Outputs:  Alice 20, Charles 8;  signs and sends to Alice who signs and broadcasts.
  

In this case, the "Risk Deposit" serves two purposes:  (1) guarantees that Bob has incentive to complete the transaction after he receives his merchandise, and adds incentive to the seller not to randomly back out and leave the multi-sig money stranded. (2) It's an already-included, equally-funded-by-both-parties fee, in case the tx needs arbitration.

Someone had brought up the possibility that only the "loser" of the arbitration should pay, and the "winner" would get their risk deposit back.  I'm not entirely sure which is better...

While many of these steps look complicated, I think my GUI-fu is good enough to make a lot of this transparent.  Third-parties can register to be included in a global list on most clients (to retrieve and verify addresses).  Users will not see all the script magic going on in the background, they just have to enter their amount, and their risk preference.  But of course, I have to iron out the under-the-hood stuff, first, so that I can implement it soundly and then make it transparent to the user...

Haha, sorry.  I've just been pondering the idea -- for no reason in particular -- how difficult it would be to retire BTC and move onto Bitcoin 2.0 if necessary for the future of crypto-currency.  It's always nice to have well-thought-out options if the need ever arises (SHA256/ECDSA is broken?)

I know this must've been discussed at some other point somewhere, so a link might be all I need.

With the availability of merged mining, Bitcoin could be optionally replaced using scripts that are impossible to eval-true the mainnet to destroy coins, but using a special script construct that sends them to an address on the new chain.  These scripts would be then be the "coinbase" transactions of the new chain.  The only way to generate coins on the new chain is through this mechanism.

For instance, the following output script destroys any coins sent to it on the main network, but easily identified by the second chain.

The new chain uses all scripts with this form as generation transactions instead of block rewards.  This guarantees that there is a direct, one-to-one relationship between BTC and BTC2 (though, it's only a one-way conversion scheme).   It has two main requirements:  it has the "same" coin-supply scheme as the original Bitcoin (because the only generation comes from destroying BTC which caps out at 21 mil), and generating BTC2 blocks provide no reward except for BTC2 fees.   And the lack of BTC2 block reward is compensated by the fact that all miners would use merged mining on the main network -- so they get their BTC reward and can optionally convert to BTC2.  They could even put the above script directly in their coinbases to generate directly into the BTC2 network.

Of course this is full of holes and unknowns.  And full of questions about how much BTC2 could actually differ from the original BTC if it's bound to its generation.  And there's questions about how to make it so BTC2 could eventually split off as an independent chain (could it?).

There was an experimental cmake system put together by "Swift Geek" for Armory.   I never got around to finishing the implementation of it.  However, I did get it integrated into the "cmake" branch on github, so all that work is sitting there, idle.  If someone wanted to check out that branch, and try to merge it into master, I might be inspired to pull it (I've been avoiding pulling in any external changes though, to avoid copyright mixing...)

Especially, if the stuff is basically plug-n-play (with some modifications to accommodate new C++ classes since 5 months ago), then I can probably do it myself.  I just don't have time to go wandering down that path right now, at least not until I know how long that path is...

Strange.  There is only one verbosity mode.  I will eventually implement a more-robust logging system for this purpose.  So far, I haven't seen this issue.

For now... are you sure that the address you put in is part of your wallet?  There does need to be a valid address entered, and you shouldn't even be able to click the button unless there's a "This key is in one of your wallets" message next to it.

Fantastic!  It sounds like 0.70-beta is in pretty good shape.  Definitely a couple unexpected problems, but I was also expecting all sorts of stability issues which didn't seem to happen.  That couldn't have gone any more smoothly, besides that first release two days earlier that imploded right after I released it.
 
Tonight, I'll be working on the Windows version.  My naivete suggests that I only have to swap out the BinaryDataMMAP class with an identically-named class using Windows MapViewOfFile (BinaryDataMVOF?).  And with some luck, everything will work the same with Win32 and/or 1-2GB of RAM.  But hell of anything ever goes that smoothly (especially with Windows...)



As you can see, Armory *really* doesn't like non-standard transactions, and P2Pool definitely uses something non-std, but it's "standard enough" now that I should look into making sure Armory handles it properly.  Though, any transaction that was accepted by the network should stil show up but with "UNKNOWN" in the "Script Type" field.  It appears to bail sooner than that, though.   I'll add this to my list of things to investigate...


I had been thinking that I should setup a formal bug-tracking system.  I have no experience with such systems though.  If someone has a recommendation for something light -- it just needs to be a simple submit-and-query interface that allows users to submit bugs, and I can tag their priority and if they've been fixed.  Simpler is better.  Recommendations are welcome.


Odd that it shows twice... I have a hunch what the problem is, and I'll look into it tonight.  I assume the problem goes away when you reload Armory?  Or does it continue to show twice?  Is it possible it was imported into two different wallets?


Actually, those are mouse-over tooltips.  You don't click on them -- just hover the mouse over them for a second.   I am kind of annoyed that the "tooltip delay" is so long, but I never found a way to change it in PyQt.  I'm sure it's there, but it might be complicated...



This is a remarkably frustrating bug that I have run into only once, ever, and it's that button. I can't even describe what the issue is, but the only way I could get that  button to work at all, was to require you click it twice.  If it still doesn't work after clicking it twice, check the console output for any errors.  I just realized how I can work around it, though it seems silly...

I think 20% is too much -- in regards to what is needed to ensure a miner is doing his job versus the autonomy desired by miners.  As mentioned before, there only needs to be enough tx required that the rogue miner has to start paying attention to other tx on the network:  it sounds like he's not paying attention to any of them: 0%.  If he has to start paying attention an including any of them, he might as well include all of them.  Problem solved.

Well not actually solved yet:  but my point is there's a very low threshold for what is needed to get him to start paying attention.

EDIT: on second thought, what's stopping him from just creating 20 tx per block himself and broadcasting them, just to make sure he can meet the X% req't?  Seems like we might accidentally encourage the rogue miners to start adding bloat just to get around the rule (which might be easier than starting to pay attention).

I wouldn't change those directions just yet.  The intention was to get 0.70-beta-alpha out there as a testing version (hence a diff branch), and when it's stable I'll merge it back into master.  So far, it sounds like it's fairly stable...

Btw, you mention having to symlink to /usr/bin/python2.7... I'm not good at all with makefiles, so I just did whatever I could that would work.   If anyone has recommendations for improvement (other than cmake), I'm open to it.  Or maybe I should just finish the cmake stuff...

Red Emerald,

It should be completely transparent to the user.  I believe mmap() will consume as much RAM as is available, and scale it back (at the expense of speed on the next rescan) if other programs starting adding memory pressure.

Actually... that something that should be worth testing.  My 1GB system does seem to "fill up" quickly, but the "python" process does seem to get smaller when I load more programs.  I'm going to have to experiment more

FINALLY!!!  

***Armory RAM-Reduction is Nearly Complete!  (0.70-beta)-alpha (Linux & OSX only)***

Tested and working on an Ubuntu VM with 1GB of RAM!  Not only is it working, it is working beautifully. If I don't have a lot of other programs open, the mmap'd data stays mostly in cache and doing a full rescan takes 2-4 seconds!

Unfortunately, the blockchain is getting big, so it's taking almost a full minute to load Armory (on the 1GB system).  But it's better than nothing!  And, given this fact, I'll be implementing something in the near future that loads the GUI immediately, and then does the scan.

-------

Linux & OSX users:  Please please please pretty please help me test it!   Especially on low-RAM systems.  While people are testing it in *nix, I will be working on the code branch to make the same thing happen in Windows.  I don't think it should take me too long, but who knows what kind of dragons I'm going to run into...

Armory looks mostly the same, and the only difference is that it will ask you if you are willing to wait, before it executes a full blockchain rescan from disk.  

Armory is very smart about it, too -- if you remove an address or wallet then re-import it, no rescan will be required.  And it only rescans exactly as many blocks as needed.  It can predict when a rescan is required and will ask you for confirmation only if necessary.  The only downside is that you can't cancel out of the scan once you've started.  But at least you get a pretty blue "Please Wait..." window

One annoying thing is that it can't predict when the rescan would happen super-fast due to caching, meaning you'll get a box warning you it will take a long time, then the process finishes immediately.  I guess there's worse problems to have

Usually, if you hit cancel before doing a rescan, Armory will either abort the operation or tell you that balances will be incorrect until you restart.  There shouldn't be any behavior that isn't explained.   But a LOT of stuff changed under the hood, and I'm sure I didn't catch everything in my own testing.   So please help me test!

I'm declaring this to be the alpha version of Armory 0.70-beta.    While none of my testing wallets have gotten corrupted, it's always a good idea to backup before trying the new version.  In order to test it in Ubuntu, follow the regular directions on the Building Armory from Source page,  but switch to the mmap branch first.  Modified instructions are below:

• $ sudo apt-get install git-core build-essential libcrypto++-dev swig libqtcore4 libqt4-dev python-qt4 python-dev python-twisted
• $ git clone git://github.com/etotheipi/BitcoinArmory.git
• $ cd BitcoinArmory/cppForSwig
• $ git checkout mmap
• $ make swig
• $ cd ..
• $ python ArmoryQt.py

BTW:  I have not tested 0.70 in offline mode yet.  I'm actually quite sure I broke something minor, but you can still use 0.61 or less on the offline computer even if you are using 0.70 on the online computer.   I really wanted to get the testing release out as soon as is reasonable, and offline systems are not the target of this release!

If you are concerned about tainted money, then the best thing you can do is send it right back to one of the addresses that sent it to you.  If you were helping someone launder money, returning the money to the original address is useless.  Maybe I missed something, but if you wanted to wash your hands of it, it seems like that gives you plenty of plausible deniability (and actual, justified deniability).

Btw, I can't tell if you are suggesting to somehow "refuse" the transaction.  You can't refuse Bitcoin transactions -- and this is not an option that can be built into a client.  It's just the way the network works.  If someone has your address, there's nothing you can do to stop them sending money to that address (for the same reason you don't have to be online to receive the Bitcoins).  As mentioned above, the best you can do is send it right back to one of the addresses that sent it to you.

If you are trying to operate a completely underground, anonymous casino, you can use a self-signed certificate, and I'm sure the anonymous customer will understand.  Yes, there's MITM risks with self-signed certificates, but how much can you ask for?  If the casino is well-known, the public key of the self-signed certificate could be well known.  Alternatively, I've heard all sorts of stories about zero ID verification for getting CA-signed certificates -- send money and unverifiable identity, get a cert.  Sure it's not completely anonymous (money trail), but I bet you could find a CA that would do it.

In this case, it sounds like OP is happy to stay above ground, and getting a CA-signed SSL certificate is acceptable.  But maybe I inferred that incorrectly.  Either way, anyone operating a casino needs some kind of capability to initiate encrypted sessions....

Oh good point.  I missed the distinction between full and lite nodes in your argument.  I do have long term plans to make Armory lite, or at least have the option, but it's a big change and I want to make sure it's done securely.  But that's totally not a discussion to be having right now...

Worst case, 32-bit OSes break when the blockchain file splits at 2GB.  I'll figure out what to do at that time...