Step 1: copy the a file (the backup of wallet.dat) to a folder (google bitcoin data directory).
Step 2: Run bitcoin.

I am pretty sure nothing can drop more than 100%.

https://bitsimple.com

No wallet, nothing to hack.  We transfer purchased coins directly to the address you designate.  As long as your wire posts to our account before the 5PM EST cutoff you will get your coins the same day (usually within an hour).  After 5PM, on a weekend or bank holiday it should post the next business morning when banks open.   Oh and no annoying hidden fees.  The price we quote is the price you get.

We don't do escrow with a third party but we are a federally registered MSB, and I have been around a "little while".

Then you get the blocks from alternative channels.  You likely should be doing some validation from alternative channels ANYWAYS otherwise you are susceptible to an isolation attack.

Imagine a potential user who DOES have internet but it may be slow, flaky, and high cost.  It likely also has some low throughput limits each month.  This would describe 3 to 4 billion people in the third world.  Still if you want to take it closer to home, imagine someone in the US who who's only internet access is a 3G plan with a 10GB cap.

A data broadcast doesn't have to be 100%.  If the broadcast gets the user 95% of the data then he cuts his bandwidth requirements over his conventional link by 95%.  Sure 100% would be better but 95% might mean the difference between being able to run a node or not.  As for downtime, if it becomes mission critical (and the savings from improved uptime warrant the cost) there are always options.  Use two receivers on battery backups and compare the streams.   That combine with FEC, and multiple channels, you could achieve > 99.999% receive rate.   These concepts are already used in remote sat downlink applications.

My guess is you are thinking of a use case that it wasn't designed to be used.  If a user has absolutely no other form of communication (no matter the cost or speed) then yes this is useless, but that wasn't the problem it was trying to solve.

So what happens when there aren't enough tx to fill the min requirement?  The network just halts until there is enough?  Of course all this is academic.  You do understand that Bitcoin works on a consensus system and there will never be a consensus to change a core element of Bitcoin (baring possibly a change in crypto due to a cryptographic break). 

Also as the block subsidy declines and networks get faster and cheaper there is less of an artificial subsidy in the network.  Miners which exclude paying tx will simply go bankrupt.  If a orphan cost is less than the tx fee there is no economical reason to not include a given tx.  The miner simply gets less revenue for the same amount of work.  Low barriers to entry will push margin on miners so low that leaving profit on the table will mean operating at a negative margin (mining to lose money).

Up thread I already proposed a non-core change that would cut orphan costs by 90% or more.  That combined with the block subsidy decline will make this a non-issue.

Yes sorry your right higher = more extensive checking.

The larger point is that these are low level database validations.  In a perfect world no checking would ever be needed.  The block was valid when written to the disk.  Nothing should change that and it should forever be valid when reading from the disk.  However in the real world, hdd aren't perfect and abnormal program termination could result in corruption at the database level.  In normal usage you should not need to ever use anything other than the default.

IIRC the checklevel doesn't relate to enforcement of protocol rules it is checks done on the local copy of the database to detect and possibly correct corruption and errors in the underlying database.  You should  not normally need to change the checklevel.  I do recall at one time a bug in the client caused a failure, and running at a lower check level (lower = more extensive checking) was used as a workaround.

It is verifying all the txs in the block.  Number of tx per block has increased over time (which is a good thing BTW).

There is more to verify a block is valid than just hashing it.

First a block can't be valid if any tx is invalid.

For a tx to be valid the client needs to check that:
a) it has valid form & structure.
b) that the inputs are all valid and have not been spent in a prior tx (i.e. the inputs are in the UXTO at the time of the tx)
c) the signature is valid
d) that the pubkey when hashed produces the pubkey hash in the prior output
e) (for coinbase tx only) the amount of the coinbase < subsidy + tx fees.

If any of these checks fail, the tx is invalid, and as a result the block is invalid.

Second a block can't be valid if any part of the header is invalid.
Once all the tx are verified as valid the block header is verified.

The merkle tree is constructed and the merkle tree root hash computed.  If the merkle root hash in the block doesn't match the computed one, then the block is invalid.
The client also needs to verify the other information in the header is valid (prior block hash, version, etc).  Other than nonce and timestamp these are deterministic and if they don't match
what the client expects then the block is invalid. 
The client needs to verify the timestamp falls within the range allowed by the protocol.  Bitcoin allows a "loose" timestamp so the client needs to construct the valid range and ensure the block's timestamp falls within it.  If the timestamp is outside the expected range then the block is invalid.

Once the header is verified the client will hash the header and verify the the resulting hash is less than the target based on block difficulty.
If the blockhash isn't smaller than the difficulty target the block is invalid.

Only if all those checks are successful is the block considered valid and added to the local blockchain.  The client then moves on to the next block.  The most time consuming step is the validating of the transactions (namely the validation of the ECDSA signature on each input).

Who is "them".  BTC-e has no corporation, no know entity.  It is simply a website running on a server.  Even bank wires are done through the accounts of a third party.

To sue "them" you need to know who "them" is.  If you needed to sue "BTC-E" today tell me exactly who (person or company) you would sue and in which country.

zero isn't considered hard work.  You haven't done any work at all.

To save you some time, mining on a macbook pro is pointless it has been for sometime now.

More this.

If you think of Bitcoind as the "bitcoin server" then the bitcoin server today has both the server and a client bundled together not as two seperate apps but as one app.  Calling bitcoind causes  an instance to run as a "server" calling bitcoind <command> has the same executable run as a client.

There is no reason for a sample client representation to be included in the server.

Anyone know what source BIT is using for the exchange rate of the day?  The site vaguely indicates it is the volume weighted average price at 4PM from one or more exchanges but that doesn't tell much.

ining can (and was) profitable at both $0.01 per BTC and $1,200 per BTC.  If mining is unprofitable FOR SOME PEOPLE, they will stop, and the hashrate will decline, and the difficulty will decline, and thus it will be more profitable for those who remain.  If it becomes "too profitable" for those who are mining, more hashpower will be deployed chasing those profits, and the hashrate will go up, and the difficulty will go up, and thus it will be less profitable for all miners.  The network will always reach an equilibrium.

So the the guy who created it was smarter than the entire rest of the planet combined.  As so smart that despite SHA-2 being the single most researched cipher by researchers and academics all over the world nobody else on the planet has discovered this "weakness" in more than a decade?  Furthermore nobody has stolen, or leaked to the public this weakness either?

Highly unlikely but one can never prove it isn't true.

Still while we may not be able to prove it isn't true, you have no way of knowing it is, so claiming you know they know is just bullshit right?

Once the first tx is known to a particular node, the second won't even be relayed.  It would simply be rejected/dropped as invalid.  A tx whose inputs have already been spent is invalid.  Once the first tx is in a block, the site would never know about the transaction to give you credit.  This is what was occuring w/ MtGox broken withdraws.  MtGox was creating txs involving already spent inputs and thus they got rejected by every single node.  Users couldn't even see the tx on the network (either on the wallet or on sites like blockchain.info) because the network is designed to NOT relay double spends.

So once the first tx is known to a node, the second isn't a valid unconfirmed tx, it is simply invalid garbage discarded by the network.

The only way a 0-confirm double spend can occur is
a) attacker makes two txs which use the same input(s) A to the merchant and B back to the attacker.
b) the attacker broadcasts A & B to different parts of the network.
c) the merchant only learns about A and never learns about B
d) the miner who ends up solving the next block learns about B first
e) the merchant doesn't have other nodes looking for tx like B and report it to the merchant.

Still that assumes the A isn't already confirmed in a block.  If it is, you can't create a tx which spends an already spent input.  Your only option would be to rewrite the blockchain (in essence A never occured according to the blockchain so B isn't a "double spend" as far as the protocol is concerned it is the only spend).





Simple version: Danny is right (he usually is).

Strong cryptography doesn't rely on the cipher being unknown.  That is security through obscurity and results in poor security.  History is littered with examples, WEP, CSS, AACS, A5/1, A5/3, etc.

Strong cryptography involves making the cipher public knowledge.  "Here is how the lock works, but you still can't unlock it without the key."

Wow that is bad.   The undercover officer provided multiple mentions of stolen credit cards, and provided enough details (even offering to trade stolen CC for Bitcoins directly) that there is no chance the seller though he was "joking".  A single statement might be a joke.  Multiple statements with details over the course of two months?  He knew.

I agree and the response wasn't only directed to you, it just happened I had the time to comment now.

I have indicated in other posts the failure to file a SAR is (at least based on the limited info we know) going to be nearly impossible to beat.  You likely know this but others might not, a SAR is for suspicious activity.  The theshold for reporting isn't "beyond a reasonable doubt", it isn't even a reasonable certainty that a crime has occurred, it is just suspicion.  The emails between Charlie and the conspirator as well as between Charlie and the rest of the company certainly paint a picture that Charlie was or should have been suspicious of the client.  I don't think a jury is going to believe that "a reasonable person" wouldn't see that the transactions (multiple per day, many times up to 10x over the limit, involving a middle man, using aliases, using multiple accounts, etc) wouldn't require filing a SAR. 

The bad news it the "lesser" charge is up to 5 years in prison and up to $25,000 fine per transaction (~1,000 txs made).  The prosecutor might let him take a reduce jail time but they are going to use the fines to financially destroy both Charlie and the company.  It will make a "great" headline ("Bitcoin company fined $25 million in money laundering charge") for a prosecutor looking to prove a point.


I agree.  The ML (with up to 20 year prison sentence) will likely be used as a "are you sure you want to take a risk with a jury?" card.  Fighting it would only make sense if you also thought you have a reasonable chance of winning on the lesser change as well.  If you don't then fighting in court over taking a deal means all risk and no "reward".

I think the operating an unlicensed money money transmission business is just garbage though.  In the NY hearing they even indicated that the exchanging of money for virtual currency may not even be covered under existing statutes and that the committee will likely need to use its emergency powers to expand the scope of its regulatory structure to bring Bitcoin exchanges in to it.  So it say "you weren't licensed in NY = bad" when NY isn't even sure you need to be licensed is just nonsense.  That being said our company doesn't do business with residents of NY (and CA and VA) for this exact reason.  The regulatory unknown just makes it too much of a risk.

So verbal agreements are never binding.  I think that omission speaks well to your "lawyer" credentials.  Also isn't it unethical to provide legal counsel without a lawyer, client agreement?