A casino could theoretically not "track" any of its customers.  It has a public webpage for getting casino-owned BTC addresses.  If a user wants to open an account, send money to that address -- done.  All future actions communicated with signed messages or SSL connection initiated with that first private key.  This is as anonymous as it gets.

In your case, you *want* more information for them to actually open an account, probably for legal and accountability reasons.  Well you can still do the above:  the user initiates the account by sending money to an address they pull off your webpage (with a large red, explicit warning about using one of their own addresses), but the account will not be activated (usable) until they send their name&address&DOB in a signature block.  If the info is not received within 10 days, you simply return the money to that same address.  In that case, it's entirely appropriate to return money to the same address (or hell, why not keep it?).

Of course some people will ignore the warnings and send it from their e-wallet anyway.  But that's their fault as long as you do your part with flashing red letters.  They can sort it out on their own with their ewallet provider (and they can prove to their ewallet provider that it was meant for them, since they can see the same coins they used to own coming right back to them)

Unfortunately, there's a lot of users still using 32-bit OSes.   And it's absolutely possible to support them without mmap.  But if mmap'ing won't work, I've artificially cut off a LOT of users.  Part of the reason for doing RAM reduction was so that 32-bit OSes could use it... (of course, using less RAM, in general, is a good reason)

It's easy to look at your own 6 computers, and they're all 64-bit systems, and forget that a large proportion of the population will not have that, especially the non-tech-savvy users.  And that is a crowd I want to appeal to, eventually.  But I do need RAM-reduction and independent networking first...

Unfortunately, Armory's signatures are not compatible with Satoshi client's sign-message functionality.  But, I plan to get it matching as soon as I'm done with RAM-reduction and compressed public-key support.

Also, the Satoshi client also doesn't use any kind of signature blocks:  only "here's a chunk of seemingly-random data representing your signature, do whatever you want with it."  It doesn't even have a GUI for verifying them.  So I'm trying to convince the devs they should use some kind of signature block scheme which is user-friendly (relatively speaking) and easy to cut-and-paste into email or webpage.  In return I'll switch Armory to use their signing protocol

If someone steals your identity and everything you use to identify yourself, then how is it possible to avoid this?   That's *kind of* what passwords are for, except that they're still pretty much pointless, since the attacker can always request the forgotten password to your email that he just stole and then access your account. 

Either way, you can tie in additional security measures if you want:  the webpage for sending them signed messages could require a login.  Then the attacker needs your password and private key to do it.

This sounds like the exact problem I was hoping to solve with Armory's signature blocks (and message signing just implemented in Satoshi 0.6.0).  The only requirement is that the user's first ever deposit is with an address they exclusively own.  All future deposits to their account can be through any means whatsoever.

Require the user to use one of their own addresses, X, for the very first deposit even if it's just 0.001 BTC.  After that, any interaction they have with the casino must be through signature blocks, signed by X.  ("I would like to cashout 12 BTC to the following address ... ")_signed_by_X.  This is a guarantee that the same person who originally funded the account is the person who is sending you the message -- and that the message can't be altered on the way.  After that first deposit, they can "refill" their account however they want (green addresses, friends, other addresses).  Only the first one matters.

You can make all interaction between customer and casino as anonymous as Bitcoin itself -- they would not even need a login/password/email/anything.  They only communicate through signature blocks on your webpage or email, and your software can easily check that the signature on the message matches X.  Right now it would require manually creating the sig blocks, but it could eventually be a capability somehow integrated with a client or browser, just for this purpose.  You could initiate SSL connections between casino and customer using public key X.  

Of course, if you don't want pure anonymity, you can require more information to open an account, but there's a ton of flexibility with this method.

There's an interesting dynamic here... the system only needs to be effective at the beginning to clean up what is there and prevent future abuses.  After the system reaches steady-state, it would be as if it wasn't there -- no one would bother building anti-social blocks anymore, and the logic would remain unused (assuming it's calibrated to only handle the most anti-social cases).  As kjj said, it only needs to be enough to make it easier to follow the rules than work around it.  I think that's a low threshold to meet, and you could set the algorithm to have basically zero-false alarm rate for regular miners.

As twobitcoins said, it is purely, financially negative to follow this rule unless 100% of other honest miners are following it.   But it seems like three conditions at least make the theory plausible:

(1)  isAntiSocial() algorithm is very reliable -- I don't want to discuss the details of this, but I think it's very feasible to separate out the two classes of blocks:  social and anti-social -- which means you could very reliably classify them.
(2)  The logic required for the botnet to get around it would be harder than the rules to just operate honestly. 
(3)  The network well-connected and efficient enough that if 100% of honest miners implement the logic, that that 99%+ of them will also agree on isAntiSocial for each new block -- thus the cost to them of improving the network costs them less than 1% of their mining rewards -- perhaps an efficient network is worth 1% of their total income...

On point number three -- in a nominal scenario, the negative impact to their mining rewards is only transient:  if the system is effective, anti-social blocks will stop happening, and then it will become irrelevant.  On the other hand, if it really is a botnet, then the operator really doesn't care.  His botnet produces only 20% valid blocks (because miners will accept empty blocks that were found quickly), but he's still making a ton of money from it for zero cost.  Perhaps it's worth it to him to implement the honest logic so that he can up it to 80%, but maybe he won't...

I like the general idea of this proposal.  To me, it sounds like it's a very simple two steps:

(1) Create black-box algorithm isAntiSocial(newBlock, currMemPool); returns true or false.
(2) Only build on top of blocks that return false from (1)  (not antisocial)

Number (2) means that if we are a miner and we see an anti-social block extending our current longest chain, we will continue building on the previous block and just ignore it.  If someone builds on top of that with a non-anti-social block, then we will switch to it.   In the end it, doesn't really matter which block a miner builds off of, he doesn't get any more or less generation fees.  The only thing he's doing is leading the invalidation of blocks of a miner that isn't doing its job.

One big problem I see with this is that all nodes have conflicting interpretations of how many confirmations a given transaction has, and now when you have a chain of 3 anti-social blocks and then someone builds a non-anti-social block on top of it, your node instantly accepts it as having four confirmations.  Is it a problem?  Probably not, but I haven't thought too much about it.

It certainly could be confusing, as nodes can't actually agree on this metric (though, how important is the metric?).  Forget the black&white case of some nodes producing empty blocks, and other nodes producing "normal" blocks.  Perhaps the anti-social blocks still include some transactions, just not many, and half the network decides social and the other half decides anti-social.  Then new blocks come in extending it, which leads to a new fragmentation of the network.  You've now got miners all different levels:  some are working to extend block X, some extending X+1, some X+2... and the node working on X will create a block that the X+1 and X+2 nodes don't recognize as the longest chain and simply ignore -- dramatically increasing the probability that miners end up with invalid blocks. 

Perhaps there's even a way to trick nodes into believing certain things as a form of attack.  You feed them lots of transactions to change the makeup of their memory pools so that they are likely to view more blocks as anti-social and then subsequently produce lots of blocks that end up being invalid.

I can't believe I f***ed that up so badly!  I was sooo focused on getting some logic right for 1/2 the overall problem, that I completely botched the other half of the program along the way!  But not badly enough to notice it in testing that first half, that the second half was totally wrong!

Armory 0.70 is not ready.  It's more than not ready, I need to un-overhaul some of the blockchain logic, as I broke instant rescans for users with lots of RAM, and apparently 32-bit systems have a high risk of seg-faulting due to rescans (due to weirdness with MMAP on large files on 32-bit systems).

Sorry about that!  Hopefully it won't take me more than a day or two!   (this is what I get for solving half the problem 2 months ago, then forgetting all the context I needed when I returned...)


P.S. -- My original mmap branch never even did a remap, which was the correct solution before I recklessly changed it.  Even though I'm going back, I'm wondering why the botched solution failed on 32-bit systems and maybe someone can help:

-- MMAP'ing 1.1 GB blockchain file always succeeds on first load.  
-- Remapping 1.100001 GB blockchain file always fails.  I attempted to unmap the original and close the file, before re-opening and remapping.

I bet it has something to do with virtual address spaces... there's enough virtual RAM to map a single 1 GB file, but not two? (perhaps I'm not actually unmapping the first, and it's trying to open a second)    Does this mean that even if the blk0001.dat file splits at 2 GB and I can map it okay, that it will fail when I try to mmap two such files at the same time?   I thought, as long as each file was less than 2^32 bytes in size, that mmap would work. If so, I might want to abandon all mmap-based solutions and do a lower-level overhaul (or just switch entirely to another library for blockchain management)

Geez, the moment I hit the post button on this post, the whole thing started imploding.   See next post for details...



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

Tested and working on an Ubuntu VM with 1GB of RAM!

-------

Linux & OSX users:  Please please please pretty please help me test it!   Especially on systems with 1GB of RAM (I wonder if 512MB would work...?  I don't see why not...)  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 the C++ tools can predict when a rescan is or is not required and will ask you 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

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![/s]

Gavin,

I put a sign&verify GUI into Armory, and used a BIP-10-like format to create and verify "signature blocks." 

Here is an example of the signature block and the user interface. The UI needs to be cleaned up a bit, but it does work.

Unfortunately, I am not yet compatible with the Satoshi client and I suspect I'll need to handle compressed public keys to do so.  But I want to get it compatible as soon as I can, so can you make sure that it is documented so I can match?  You also might consider a similar "signature block" technique (or do you already have it?)

Admittedly, it's a weird analogy, because it's not the electronics themselves that are deflationary, it's the money that is used to buy them that is deflationary with respect to what is being purchased.  But the analogy holds for the same reason that people purchase electronics with fiat -- the money has no particular utility to the owner except that it helps them acquire things to do have value/utility.  A world where Bitcoin is a dominant currency will see people using them, because they need stuff.  Just because they can buy more stuff later with the same number of Bitcoins doesn't mean they'll wait -- a lot of stuff you buy because you want it or need it now.  It just means people be more inclined to save their Bitcoins instead of spending it on stuff they don't need.  It's has different economic principles, but it's not a show-stopper for the currency.

EDIT: Sorry, I shouldn't have started derailing this thread, especially with concepts that are probably beaten-to-death on other parts of the forums.  If someone has a link to the discussion on this stuff, let me know, I'll take my rambling there.

I'm not sure I follow how it is counteranonymous.  You fund a website/service with 20 BTC coming from address X.  You can then manage your account over the internet without ever creating a username/password, supplying name or email address.   The only thing that matters to the web service is that the same person who originally sent them 20 BTC is the same person telling them to transfer it to another address, purchase something, buy into a poker game, etc. 

It has the same security and anonymity features as Bitcoin itself.  For now, such messages might have to be manually constructed, but in the future, your BTC private key could be used to initiate SSL connections, etc.

You know what else is deflationary?  Electronics.  Why buy an iPad now when it's going to be 30% cheaper next year?  The money used to buy electronics is extraordinarily deflationary -- yet people buy electronics all the time!  They should be hoarding that money, wait a year, then they can get 30% more electronics with the same cash!  I don't know why anyone would buy electronics, then.  Oh, except they do.  And somehow that market is freakin' enormous, contrary to the economic theories.


As for switching chains, I'm sure it's been mentioned before, but the new chain could distribute its units purely from un-redeemable outputs from the main blockchain.  The only way to get Bit2coins would be to send Bitcoins to your Bit2coin address but using a special script that is impossible to evaluate true on the main bitcoin network.  Therefore, they are destroyed on the main chain, and redeemable within one confirmation on the Bit2coin chain.   Merged mining would keep them both running, and miners could start having their generation transaction go right to the unredeemable-on-the-main-chain Bit2coin addresses.

If the alternate chain has an alternate philosophy on generation, it won't work... but if you plan to keep the same generation scheme, you could change just about everything else and people could decide if or when to switch, as there's an exact 1-1 correspondence between BTC and BT2C (or whatever the hell we call it).  If this has been mentioned before...anyone have a link?

Btw, I would caution against saying "Signing messages ... to prove that you own an bitcoin address ...".  It's very difficult for someone to say "prove you own this address" and then you can do so.  A MITM could ask the person who really does own the address to prove they own it then forward the response packet to the original requestor as if they owned it themselves.  There are ways to do it, but it is not likely to be executed properly, by hand.

I recommend promoting the feature as "Message signing, with address-based authentication" or something more PR-friendly.  For instance, you need a shipping address to send the 1,000 BTC merchandise that was paid for [partly] with address X.  You would instead ask for a shipping address signed by address X.  The MITM wants to divert the package to his own location, but can't do so without breaking the signature.

The important part is that the same person who owns X approves of the message that was being signed, without regards for where the person is or when they signed it.

Perhaps that's already in your line of thinking, but I think it's a distinction worth making.

Oh yeah.   I should clean up that part of the display for offline mode...

And people continue to donate!  With RAM-reduction on the way, I'm hoping that I will get another surge!  I love working on the project, but it would be nice to recover a little bit more of the salary I'm not collecting...

So, I have re-opened the reward/gift system on the BitcoinArmory website!   (I also updated the top post with this information).

Coincidentally, just now I was working on merging my RAM-reduction branch into the master, which I forked a month or two ago.   Apparently, I made the the exact changes I just said I thought I had made, but I guess I made them in the RAM-reduction branch by accident instead of master.  So, that might actually be fixed in the RAM-reduction release...

Hopefully Friday, I will have version (0.70-alpha)-alpha -- the alpha version of version 0.70-alpha   (for Linux/OSX only)

Interesting.  That was not intentional:  I intended for them to be shown and marked as unconfirmed for 120 blocks.  But it seems I botched something in the unconfirmed count, anyway -- I put in logic for change-to-self and sent-to-self as automatically confirmed, but it didn't seem to work.  Therefore, if you have only one unspent output and you send 1/10th of it, your entire balance will look unconfirmed because you sent 9/10 back to yourself.  Perhaps the two problems are related. (I even have a unit test for this, I'll have to dig it up)

I'm adding that to my list of stuff to do after RAM reduction:  p2pool/mining outputs, and unconfirmed balances.

Ack... that's why I didn't do it yet...

Because Armory currently relies on the blk0001.dat produced by the Satoshi client (Satoshi client maintains it, Armory only reads it).  That means that what I just said I would do... won't work.  I can't wait until Armory doesn't rely on the Satoshi client anymore, but it's going to be a lot of work to cut that umbilical cord. 

One day...

You know,  I never put this in but I don't know why not.   I can add that as a CLI option.   I'll do that tonight if I think of it.