Thanks so much, Pieter!!!!!




Krepta3000, before you bother trying to get git to work on windows, you might just make sure you can compile from the source first.  I haven't tried to do so for windows for bitcoin before, but based on my experience with other open source projects the tool chain requirements for compiling under windows usually is much harder to satisfy than for Linux.  My experience has shown me that using a VM running Linux (using virtualization software like VBox if you don't have a linux box handy) is usually a much easier route.

But... since I don't have experience with bitcoin in this area, I'll defer to anyone else with more direct experience...

Can anyone help a git and github newbie like me figure out how to get a diff from the pull request?  Just pointing me towards relevant documentation would be fine... I'm just having trouble finding it.  I'm using linux. 

Thanks MagicalTux for this explanation.  It really helps build back the trust, and it seems like you've got a good idea of how things should be secure.  I 100% trust your intentions, and theoretical understanding of what should be done from a security standpoint.  I don't have enough trust in your followthru or trust you'll have the bandwidth to provide excellent service, but you've got opportunities in the future to earn that too. 


There is a *BIG* flaw in your logic, bitsalame.  If disclosing just one of your passwords can enable an attacker to tailor attacks against your other passwords, you have to trust *all* the sites that you use that style of passwords to not store plaintext passwords and intentionally be evil.  That, in my opinion, is a really risky assumption.  Also with your method it's more easily possible to truely forget a password.  For these reasons, I think it is less risky to use a password manager to create truely random passwords.  (There's risk there too... but I think less risk.)

I'm not sure (since I sell BTC, rather than buy it) but I remember hearing in these forums that Mt Gox has a waiting period for withdrawing BTC bought with brand new funds.  The idea is that you need to keep the money in Mt Gox for a few days (not sure of the time period here) so that if there's a reversal on the Dwolla side Mt Gox will have a greater chance to be able to recover the funds.

Perhaps someone with more experience buying can chime in here?

I also had problems with $10000 of withdrawals on Friday.  I had to email Magical Tux a couple times about it to get his attention -- he's really overworked right now and trying to hire someone new.  I finally got this response from him:


I'm satisfied with this.  Let's give him some time, I'm sure things will get fixed soon.

I use dark pools all the time.  Given that they exist, I see it as in my personal self interest to use them, so that others don't undercut me by a small amount.

That doesn't mean I think they should exist.  I use them because I know others do to, but I do think the free market would be better if it was more transparent.

So... Magical Tux: Don't assume because you see dark pools as being used a lot that means all those users think they should exist.  

And for the record: I *don't* think the limits should be raised.  I think it should be an all-or-nothing thing -- either keep them as they are or get rid of them completely.

ROFL!!!!  Hey, I notice that if we break downward, there's another trendline to resist further loss in the opposite coast...

(I also appreciate the more serious posts in this thread, and your thoughtful analysis S3052.)

This is easy.  Use MtGox and set up a Dwolla account.  Send an email to info@mtgox.com asking to withdraw to Dwolla. 

It costs $0.25 per transaction, so you can get up to $1000 for that.  Dwolla then can deposit into your checking account for you.

The disadvantage of this is speed of the process.  You can only do $1000/day, and at times like this when everyone is trying to get money into or out of Mt Gox, there usually is a delay of a few days, as Magical Tux has to wait for previous transactions to clear before he has the capital in the right place to accommodate your request. 

I don't think LR withdrawals are going away.  I thought so when I wrote the OP, based on the message and the fact I know Dwolla is coming, but last night MagicalTux said this on IRC #bitcoin-otc:

 < stamit> MagicalTux, what's up with the LR withdrawals?
<+MagicalTux> stamit: LR sucks, I'm rewriting the API to handle cases when the LR api goes wrong better

I know the LR API was throwing errors whenever MagicalTux's LR account went over limits on the API, which is one reason why LR withdrawals often were not working previously.  (The other reason was when MagicalTux's LR account got depleted, but that error message didn't seem to happen as often.)  Based on this IRC message, it seems MagicalTux is rewriting the API to have better error messages.

Also, with many US people switching to Dwolla (myself included) I suspect the LR withdrawals will be less stressed, so should work more often for you.

When I try to withdraw to liberty reserve, I get this error message:

"LibertyReserve is currently disabled until new - better - system is ready, please retry next monday."

So my question is this: Is liberty reserve withdrawals going away to be replaced by Dwolla?  What if we want to use LR?

Also, has anyone been able to sign up for Dwolla in the last day or two?  I tried to sign up yesterday and today, but I get "500 - Internal server error" when I complete the application.

UPDATE: I got past my Dwolla signup problem -- the site crashes if you use a "<" character in the password.    Anyway, avoiding symbols in my password allowed me to register.

Assuming a goal of bitcoin is to introduce anonymity to online transactions, one of the things that concerns me most is the traceability of coins to previous transactions.  I've read a lot of discussion about this in the forums, but there's still some open questions for me. 

So first, let me state what I do understand:

1) All transactions are public in their amounts and public key identities as follows:
  a) In a transaction, you can see the public key of the person who spent the money
  b) In a transaction, I *think* but am not completely sure you can see the public key of the person who gets the money.  (If you can't, you'll see it when they spend the money later, so this isn't that important.

2) Keeping your public keys from being associated with your identity is required if you don't want your transactions to be attributable to you.

We need to better educate users on how to do #2.  I have an information security background, and it's not even immediately obvious to me what the best ways of handling bitcoins are to maximize your privacy.

I have these specific questions or comments regarding this topic:

1) Are one-time public keys disposed of when they are no longer required?

For example, I've read that a one-time-use private key is created when I generate a bitcoin block.  When I spend these coins and I've signed them to someone else, I shouldn't need that private key anymore.  The same thing goes for a key created for taking a payment-by-IP.  Keeping keys around after they are no longer necessary may make a user vulnerable to later having their wallet seized and used to prove that they originated a transaction.

2) Reusable keys (those created inside the GUI) should be able to be similarly deleted when they are no longer required.  This is a bit more dangerous, because once you delete the key you won't be able to get payments sent to that key, so the user really needs to understand what's going on in this case.  Keys with coins stored under them obviously shouldn't be deleted. 

3) We really need to make it possible to track coin bundle's lineage to enable the user to know their risk regarding spending specific coins.  I think it should be possible, within the GUI, to see all the public keys associated with each coin bundle.  It would also be nice to be able to tag keys that are associated with you with comments to aid you in determining which coins to send to someone.  That way you could realize that another bitcoin user has seen you use a specific key, and to restrict other coins that are also associated with that key to a similar purpose and not something else that would link the two identities.

4) In addition to making it possible to track a coin bundle's lineage, we also need to be able to choose which coin bundles to include in a payment.


The important thing here is that we need to make the information that is possible to acquire through digital forensics to be easily accessible by the end user.  Only by making this information accessible to the end user will people be able to make good security decisions regarding the spending of bitcoins in sensitive environments.

One more thing that is important: Once these features are available, exchangers need to have clear data retention policies.  For example, if I was an exchanger, I might keep track of the public keys of the people that I am doing active trades with.  I'd probably retain this information until I had traded out the coins I had acquired through a trade, but would dispose of this information once the coins had left my possession.  I would also have a policy to not share that information with third parties unless required to by a court order.  If I was trading with an exchanger, I would want to know what their policies were and how they differed from my expectations. 

I'll defer to others on whether having a central database is a good idea, but if you're creating multiple directories with the -datadir command line option, you can safely bootstrap that directory by copying "blkindex.dat" and "blk0001.dat" from an already established data directory into your new one. 

Thanks!  Glad to hear it's fixed in SVN.

OK, so I've been doing a little testing with double spending, and while I'm prevented from spending the same coins twice, I do see a potential problem: Lack of feedback to the second spender.  The second transaction never gets into a block, but the second spender doesn't seem in my testing to see any transactions that conflict with his view of his personal transaction history, even if they have made it into many blocks.  This could cause problems even if no fraud was being attempted: In the case of a hard drive failure, and a restore from backup.

Let's say I have 5000 bitcoins, and I make a backup of my bitcoin data directory.  Then I spend 2000 of them, and before I back my directory up again, my hard drive fails.  I restore from my previous backup, and expect that when I get the new blocks, my transactions for spending the 2000 will be in them.  The problem is, my client seems to ignore those transactions, and even after my client catches up I still think I have 5000 bit coins.   

I'm not sure that the right thing to do is in this case is to always accept the transactions, but it seems we should at least notify the user that something seems wrong if we see a conflicting transaction that's made it into a significantly long chain.  I think the user should also be able to choose to accept the transactions to prevent attempting to double-spend already spent coins in the above scenario.

Has anyone gotten bitcoin to compile under CentOS yet?

Thanks so much for the info!

I'm a total newbie, I just installed bitcoin yesterday and I have yet to generate a coin.  Last night after I installed, I asked bitcoin to generate coins and made sure it had connectivity through both my software and hardware firewalls.  Bitcoin still didn't use almost any CPU, and I saw the block number in the GUI increasing rather quickly, perhaps a few every second.  This morning my CPU is pegged (across all four cores) and the block number visible in the GUI is no longer increasing, but appears stuck at a constant value.

My newbie questions are:

Is my experience above expected behavior?

Under what conditions should the block number increase?

Should my CPU have gone up immediately after choosing "generate coins?"

I have a quad-core 2.5GHz processor, with all 4 cores active.  How long will it likely take for me to generate my first coin?  (It's been ~14 hours since I installed, but I don't know when last night the computer transitioned from no-CPU usage to full-CPU usage)

Thanks!