They pulled the same thing on me despite completing about a half dozen 10 BTC purchases over the course of the last month.  They waited a week to cancel my supposedly "high risk" transaction, but they have not yet canceled my other pending transactions or closed my account.  It seems like an immediate account freeze would be the first course of action if any sort of fraud was truly suspected.

Overall, this is a big disappointment because it seemed like Coinbase was finally the first professional service for buying and selling coins.  Unfortunately, it looks like it's still amateur hour in Bitcoin land -- as usual.

I'm beginning to think you're absolutely right.  That scalability wiki page seems like a big fat lie too if block size can never be increased.  I'd really like someone who knows more than me to provide some reassurance here.  This seems like a very worrisome problem.



With any ideas on what the block size "should be", no matter how good they are, isn't the underlying problem that any change will require a hard fork?  Isn't the idea of a hard fork, especially for something this controversial, at this point in the game, basically impossible?

I'm becoming very, very concerned about this 1MB block limit, especially since we're already seeing blocks that put us more than 25% of the way there.  A mere 7 transactions per second is nothing.  One particularly large online retailer does more than that alone.  If this limit is not increased somehow, and it sounds like it's not going to be possible, then I'm really afraid this will have a very negative impact on Bitcoin's ultimate value, utility, and security.

Just speaking hypothetically, suppose that:

* We're constantly capping out on the 1MB limit;
* We're at a point where the majority of miner's fees come from transaction fees;
* Mining has become optimally efficient such that marginal profit approaches zero.

In this scenario, competition for block space would be so fierce as to push transaction fees into the range of several dollars per KB.  It could also then take several hours to get some available block space, even with high fees.  I can't foresee it ever costing more than what a bank charges for a wire transfer, which at my bank is $30.  A wire is also pretty fast, so it's doubtful someone is going to pay more than $30 for a Bitcoin transfer and put up with waiting longer than it would take to do a bank wire.

At 7 tps, that's 604,800 transactions per day maximum.  At a maximum average fee of $30 per transaction, that's about $18.1 million per day in fees.  If we're assuming that mining will approach zero profit, including electricity, hardware depreciation, and R&D -- meaning that 100% of fees paid are going directly to the services needed to secure the network -- then the total annual investment in mining work will not exceed $6.6 billion.  As has been mentioned before, network strength should be measured in currency, not hash rate, because that's the actual cost an attacker would have to incur to break it.  So, in this scenario, we have a maximum network strength of $6.6 billion and it could never, ever be stronger than that without a lot of money being spent to run at a loss.  Pulling off a 51% attack would mean only slightly exceeding that.  If there's enough value being transacted to demand $30 transaction fees, then banks and governments will probably be somewhat irked that so much value is changing hands without them getting their cut.  $6.6 billion is pocket change for a bank or a government, especially because they'd see such a big return on investment from blocking all these direct transfers.

That's just from the security side of things.  From a utility point of view, once fees start to cost a few bucks, Bitcoin is going to look like a pretty lousy way to pay for most everyday items, and credit cards will look cheap again -- even with their massive fraud rate.

I don't know enough about how all the pieces work, but it sure seems to me like we need a lot more than a 1MB limit...and quick.  Can someone tell me what I'm missing here or reassure me that I have no idea what I'm talking about and that everything will be fine?

We have, on occasion, received chargebacks a full year after the purchase was made.  Most do come in within the first six months, but the credit card companies will certainly allow chargebacks well beyond that.

For my cold storage, I've used some black granite tile with one of these:

http://www.dremel.com/en-us/tools/Pages/ToolDetail.aspx?pid=290-01

There are few materials more enduring than stone.  It won't fade, rust, decay, burn, or dissolve.  That engraving tool is cheap and easy to use.  It took only a few minutes of practice to get a feel for it, and I can engrave a private key in less than a half hour.  Polished granite tile is available at just about any flooring or home improvement store.

What happened to Joseph Sirochman is extremely typical.  If he had known anything about how credit card processing works, he should have gotten very nervous at the first sign that his sales were exceeding his normal levels.

I posted this about the horrors of credit card processing more than a year ago:

https://bitcointalk.org/index.php?topic=36729.0

As an update, the client who had more than $30,000 stuck in limbo has so far seen only half of it released.  It's been almost 18 months since that account was frozen and we're still basically being told to "check back in another year".

I'd like to create some paper wallets for long-term offline storage.  I realize there are two types of private keys: uncompressed, which begin with a 5; and compressed, which begin with a K or L.  Bitaddress.org appears to generate the uncompressed pairs by default and bitcoind appears to generate the compressed by default.

Since I have a choice of how to generate these keys, are there reasons why I should use one over the other?

With all due respect, this is like waiting in a Communist bread line.  Perhaps TC should simply raise prices to alleviate the shortage?  I would gladly pay a hefty premium over the current price if that would assure reliable availability.

Yes, I was.  I was using listunspent to find available inputs, then using those to create raw transactions.  Somehow, I was shown unspents that had actually been spent an hour earlier.  I think it may have been due to an odd combination of factors including switching out wallet files, a big time gap between blocks, and difficulty establishing more than 2-3 connections to other nodes.  I can't fully explain how it happened, but being blighted with a broken transaction appears to be my punishment.

According to the transaction fee rules, the size of the transaction is used to calculate fees (https://en.bitcoin.it/wiki/Transaction_fees).  From what I've read elsewhere, the size of the tx will be: 180 bytes per input + 34 bytes per output + 10 bytes.

However, while I've found that calculation to hold up most of the time, it doesn't seem to be accurate all of the time.  Is there a more reliable way to know how large a transaction will be so that appropriate fees can be assigned when creating a raw transaction?

Thanks.  I'll check out pywallet and hope to avoid situations like these.

(It looks like it's also possible to create stuck coins with a tx that accidentally tries to double spend an input.)

Let's suppose I create, sign, and send a raw transaction but I fail to give it enough in fees to be relayed (let's say it's for a small amount that would require at least 0.0005).  This bad tx will now be stuck in my memory pool.  If I use the command "getrawmempool", I'll see the txid for my transaction that will never be relayed and my client will think the inputs for that transaction have been spent.  Basically, those inputs will be "stuck".  I won't even be able to make a new raw transaction that spends those same inputs with a higher fee because the client thinks they've been spent and it will reject any attempt to send a new raw tx that uses them.

Is there some way I can remove or cancel a poorly crafted raw transaction to unfreeze its inputs?

ABUGames.com offers a huge selection of Magic: The Gathering singles, boxes, packs, accessories and card supplies.  Now taking preorders for Return to Ravnica boxes and packs.  Bitcoin gladly accepted.

www.ABUgames.com

I have a client who needs some graphics work done.  The project involves designing a credit-card sized ID card similar to the product available on this site:

http://www.paymyaddress.com/

Our requirements are:

* your design must look better than anything available on that site (although the size and general specs are the same)
* you must have a portfolio of previous work that satisfies my client's expectations

If you are capable of doing this and you would like this job, please send me a private message with a link to your portfolio.

I can't tell you why people would pay for games like this when they can get them for free elsewhere, only that they do, and that they do at very steady and predictable rates (see above).  This experiment is testing to see if Bitcoin has any chance at competing against the current premium game model.  Unfortunately, for a large variety of reasons, it probably can't.  Perhaps the search will continue for any compelling reason why a business should accept Bitcoin instead of, or in additional to, more traditional payment options.

On the totally separate topic of a chess wagering game, which seems to be of more immediate interest than a boring statistical analysis of revenue models, can anyone provide any suggestions for how to prevent cheating?  Cheating at online chess is quite easy.  Just copy your opponent's moves into a computerized chess program and mimic the computer's moves.  If wagering is involved, it seems like there would be an awfully high incentive to cheat.

I appreciate the suggestion, but I'm working off some very well established baseline data.  With a nearly identical site, I can get a 22% registration rate on targeted clicks with required and confirmed deliverable e-mail addresses.  On this site, e-mail is optional so reg rate should actually be higher than that baseline (although Bitcoin users aren't going to qualify as targeted chess traffic).  With a credit card payment option, I can get a 0.4% conversion rate on clicks with an average spend of just over $30 per customer measured across a two year interval.  No prizes or tournaments have been required to get that either.

I'm not trying to reinvent the wheel -- just determine if the bus can run on Bitcoin as well as it can on credit card.  Realistically, my expectations are low.  The world of Bitcoin is like a poor 3rd world nation.  Its citizens aren't likely to spend much simply because they don't have much.  Nevertheless, if a successful model of any kind can be established within the Bitcoin economy, that's when we'll start to see exponential growth.

I've been working with some guys who just released a fun little web based chess game that sells access for Bitcoin.  It's primarily an experiment to test the viability of a Bitcoin micropayment gaming site, but it's a fun way to spend a few bitcents.  Try it out at:

http://www.desperadochess.com/

They are also making their sales stats publicly available, so it should be interesting to see what happens.

In Central America, that's called the Millionaire's Vacation.  If it's any consolation, that actually happens a lot (enough that there's a blithe term for it).

I'm afraid I just wouldn't have the time to devote to a sales effort on this.  I could, however, bring in all the merchants in our network.  Combined, we could probably flag a few hundred bad customers a month.  I can see that it would take a lot of merchant reporting to make this work though.

There is a service I would like to see that might tie in with this.  Just before processing a customer's credit card for an online transaction, I would like to be able to cross reference the customer's card number against a global "chargeback blacklist".  If the database returns a match, indicating that this card number has been charged back against some other company in the past, I want to be able to refuse the transaction (or force the customer to use another payment method, such as Bitcoin).

Presumably, this service would also enable me to report cardholders who have charged back against us to have them added to the database.  To avoid the security risk of sharing credit card numbers, each lookup could be performed based on an MD5 or SHA256 hash of the customer's credit card number.

At least partial anonymity for the business would be somewhat important for this service for two reasons: 1) Many businesses might not be comfortable revealing sales volume based on the number of lookups performed; 2) The credit card industry (Visa/MC) might not take too kindly to merchants who screen their customers like this.  The general position that the card industry takes is that the merchant may do nothing to discourage the customer from issuing a chargeback (or to hold the customer accountable for chargeback fraud after the fact).

Many of the online merchants my company works with lose about 1-2% of their gross sales to charge backs and related fees.  We would gladly pay a large portion of any amount a service like this could save us.  The only condition is that it would have to actually be effective -- at least to some degree -- so it would need enough merchants participating to build up enough data to make it worthwhile.