 Show Posts
|
|
Pages: [1] 2 3 4 5 »
|
How do we explain to Bob that he doesn't get his donut without resulting in a fist fight, a discrimination lawsuit, an all day seminar on the technical workings of the blockchain, giving away a free donut, and/or potentially losing Bob as a regular customer? You probably won't be able to so the only solution is to prevent it from happening to begin with. So basically stop accepting 0-conf transactions for all purposes, even from trusted customers, until all wallet software has been updated to not spend unconfirmed change? This seems like an extremely severe setback for bitcoin adoption and its utility in general. |
|
|
|
About 0-conf: for small, day by day payments they were absolutely safe. The cost to perform a double spend was simply not worth the cost of a coffee. Now, that changes, 0-conf are not safe even if the buyer is 100% honest and the cost of the product is negligible: again we cannot downplay the effect of that, it's quite serious. It is important now with mass mutation attack going on to distinguish between 0 confirm tx where all inputs are confirmed vs 0 confirm tx where one or more inputs are also 0 confirm. Distinguishing between those two types of transactions is fine from a technical point of view but we'd never be able to explain that difference to a customer. I'm mostly concerned about the customer service problems this will create. Alice gets her donut because she spent confirmed inputs. Bob doesn't get his donut because he spent unconfirmed change. Neither Alice nor Bob have clue what any of that means. How do we explain to Bob that he doesn't get his donut without resulting in a fist fight, a discrimination lawsuit, an all day seminar on the technical workings of the blockchain, giving away a free donut, and/or potentially losing Bob as a regular customer? Are there any ideas on whether a technical solution to this problem will be forthcoming or any suggested workarounds? |
|
|
|
|
Edit: We got this taken care of in less than 24 hours. Bitcoin makes doing business MUCH easier!
|
|
|
|
If credit cards take 180 days to be confirmed how will you buy coffee at Starbucks?
Although most of our chargebacks do come through within 6 months, we have occasionally received them after a full year. |
|
|
|
|
I think it's a form of Stockholm Syndrome and fiat is their captor.
|
|
|
|
I figured everyone would do chargebacks on ANY product right away if it worked everytime. There must be some safe guards since I've never done it either.
I'm actually shocked this isn't already happening. My company has a lot of experience dealing with credit card processing on the merchant side, and I can tell you that the chargeback situation is getting worse and worse for merchants every day. People are figuring out that you can, in fact, go on a big shopping spree and then charge it all back. If you consider the incentive structure involved, you can see that it is likely to only get worse: * Any customer can initiate a chargeback on any purchase. Whether he received the merchandise, signed for it, or even bought it in person and provided a copy of his photo ID along with a signature does not matter. His card issuing bank will accept the chargeback request and immediately deduct the funds from the merchant. * The merchant will have an opportunity to provide the customer's card issuing bank with supporting evidence that the customer's claim is without merit. What is accepted as evidence is arbitrary and subjective. (I can provide you lots of specific examples that would make you really angry at the injustice of this system.) * Statistically, card holders who dispute a charge are more likely to default on their credit card debt. Card issuers lose money when consumers don't pay their credit card bills. To put it more concisely, the bank who gets to decide whether or not to uphold the chargeback will tend to lose money by finding in favor of the merchant. Banks will always choose the course of action that makes them the most money, not what would be seen as fair or ethical to honest men. I'm absolutely amazed that everyone isn't charging back every purchase all the time. Perhaps we'll get to that point once people realize there's nothing stopping them. The situation reminds me of a line from George R.R. Martin's Game of Thrones: "Power resides where men believe it resides...[power is] a shadow on the wall." If people start to realize en masse that there's nothing stopping chargebacks on absolutely everything, other than a "shadow on the wall", all hell could break loose for credit card payments. Here's something I posted a couple years ago about some of the other problems with credit cards for merchants: https://bitcointalk.org/index.php?topic=36729.0 |
|
|
|
Why bother with software when you can just stuff hardware backdoors into the cpu.
I've been thinking about this too. Does anyone here have sufficient expertise to comment on the likelihood or practicality of cryptographic exploits built into off-the-shelf hardware (CPU's, motherboards, etc.)? |
|
|
|
|
Back in my day, we relied on a now mostly obsolete concept we used to call reputation. It might seem rather archaic, but the way it worked was that you would tend to only do business with companies that you, or someone you personally knew, had experience dealing with. When dealing with a completely new company that you knew nothing about, you'd consider the risk and limit your exposure until they had earned your trust. There was even a Latin expression we used to describe this concept: "caveat emptor".
As odd as it may seem, this system actually worked quite well. Fraud was minimal, and companies had incentives to build trust and reputation by offering good products, good service, and prompt resolutions to problems.
|
|
|
|
After unsuccessfully trying to get bitcoin-qt running again by deleting the most recent blockchain files, I simply uninstalled the whole program, restarted the computer, deleted everything in C:\Users\BZ\AppData\Roaming\Bitcoin, and reinstalled a fresh copy of 0.8.1. The block chain sync had been running for several hours, and I had about 30,000 more blocks to go, when it crashed again in exactly the same way. This seems like a pretty serious problem. Are there any other reports of this or known solutions? Bitcoin version v0.8.1-beta (2013-03-17 15:35:36 -0400)
Using OpenSSL version OpenSSL 1.0.1c 10 May 2012
Startup time: 2013-04-03 04:10:56
Default data directory C:\Users\BZ\AppData\Roaming\Bitcoin
Used data directory C:\Users\BZ\AppData\Roaming\Bitcoin
Using 4 threads for script verification
init message: Verifying wallet integrity...
dbenv.open LogDir=C:\Users\BZ\AppData\Roaming\Bitcoin\database ErrorFile=C:\Users\BZ\AppData\Roaming\Bitcoin\db.log
Bound to [::]:8333
Bound to 0.0.0.0:8333
init message: Loading block index...
Opening LevelDB in C:\Users\BZ\AppData\Roaming\Bitcoin\blocks\index
Opened LevelDB successfully
Opening LevelDB in C:\Users\BZ\AppData\Roaming\Bitcoin\chainstate
Opened LevelDB successfully
LoadBlockIndex(): last block file = 22
LoadBlockIndex(): last block file: CBlockFileInfo(blocks=1468, size=131813551, heights=197723..199190, time=2012-09-07..2012-09-17)
LoadBlockIndex(): transaction index disabled
LoadBlockIndex(): hashBestChain=000000000000037df60961cceb00c3c1fbd92b382a712064159c30132762dd7c height=199189 date=2012-09-17 10:06:07
init message: Verifying block database integrity...
Verifying last 288 blocks at level 3
No coin database inconsistencies in last 289 blocks (49187 transactions)
block index 10624ms
init message: Loading wallet...
nFileVersion = 80100
wallet 780ms
init message: Importing blocks from block database...
LevelDB read failure: Corruption: block checksum mismatch
*** System error: Database corrupted
init message: Loading addresses...
Loaded 12193 addresses from peers.dat 63ms
RandAddSeed() 173316 bytes
mapBlockIndex.size() = 199191
nBestHeight = 199189
setKeyPool.size() = 100
mapWallet.size() = 0
mapAddressBook.size() = 1
send version message: version 70001, blocks=199189, us=0.0.0.0:0, them=0.0.0.0:0, peer=127.0.0.1:0
init message: Done loading
EnvShutdown exception: Invalid argument (22)
|
|
|
|
My Windows 7 version of bitcoin-qt suddenly crashed while syncing with the error message "*** System error: Database Corrupted". Now each time I try to open the program, I get the same error and it immediately closes. Below is a dump from debug.log. Does anyone know how I can fix this? (Hopefully without doing a full reinstall and re-downloading the entire blockchain all over again.) Bitcoin version v0.8.1-beta (2013-03-17 15:35:36 -0400)
Using OpenSSL version OpenSSL 1.0.1c 10 May 2012
Startup time: 2013-04-02 23:24:27
Default data directory C:\Users\BZ\AppData\Roaming\Bitcoin
Used data directory C:\Users\BZ\AppData\Roaming\Bitcoin
Using 4 threads for script verification
init message: Verifying wallet integrity...
dbenv.open LogDir=C:\Users\BZ\AppData\Roaming\Bitcoin\database ErrorFile=C:\Users\BZ\AppData\Roaming\Bitcoin\db.log
Bound to [::]:8333
Bound to 0.0.0.0:8333
init message: Loading block index...
Opening LevelDB in C:\Users\BZ\AppData\Roaming\Bitcoin\blocks\index
Opened LevelDB successfully
Opening LevelDB in C:\Users\BZ\AppData\Roaming\Bitcoin\chainstate
Opened LevelDB successfully
LoadBlockIndex(): last block file = 11
LoadBlockIndex(): last block file: CBlockFileInfo(blocks=256, size=46153726, heights=228582..228837, time=2013-03-29..2013-03-30)
LoadBlockIndex(): transaction index disabled
LoadBlockIndex(): hashBestChain=000000000000000c8708f0ae43cfa76aa3ec8f38037c15e1e3534641b769ddd1 height=228835 date=2013-03-30 23:14:33
init message: Verifying block database integrity...
Verifying last 288 blocks at level 3
No coin database inconsistencies in last 108 blocks (36374 transactions)
block index 12574ms
init message: Loading wallet...
nFileVersion = 80100
wallet 2449ms
init message: Rescanning...
Rescanning last 297 blocks (from block 228538)...
rescan 2231ms
init message: Importing blocks from block database...
LevelDB read failure: Corruption: block checksum mismatch
*** System error: Database corrupted
init message: Loading addresses...
Loaded 15984 addresses from peers.dat 62ms
RandAddSeed() 168932 bytes
mapBlockIndex.size() = 228857
nBestHeight = 228835
setKeyPool.size() = 100
mapWallet.size() = 480
mapAddressBook.size() = 65
send version message: version 70001, blocks=228835, us=0.0.0.0:0, them=0.0.0.0:0, peer=127.0.0.1:0
init message: Done loading
AddLocal([2001:0:9d38:953c:3034:504:e770:bbd7]:8333,1)
ThreadIRCSeed started
ThreadIRCSeed exited
ThreadSocketHandler started
ThreadMessageHandler started
ThreadDNSAddressSeed started
Loading addresses from DNS seeds (could take a while)
ThreadDumpAddress started
ThreadOpenConnections started
ThreadOpenAddedConnections started
socket error accept failed: 10038
socket select error 10038
EnvShutdown exception: Invalid argument (22)
|
|
|
|
I think you're on the right track with that idea. Here's a metaphor that might be related to this whole issue: If demand for wheat increases, the price of wheat increases too because, of course, there's a limited supply of wheat. The increased price encourages farmers to grow more wheat and make more investment in tractors and equipment. Higher wheat prices encourage more people to become wheat farmers when they see that the wheat business has become more lucrative. With the increased supply of wheat that results from its increased production, consumer prices begin to fall. Overall, the economy ends up with a much larger supply of wheat at the most competitive price possible. Production is maximized, farmers' profits are maximized, and consumer prices are minimized. I know the block size issue is more complex due to things like hard drive space, but the relationships between supply, demand, production, and price seem important to the problem at hand. |
|
|
|
Well, I think the wording would be more accurate if it said:
* It's counter-intuitive, but [displaying] more payment options reduces sales [in tests we've done using our methods].
Agreed. My original wording implied knowledge of broad external validity that I do not have statistical proof of. Still, to return to the thread's topic, a Bitcoin civil war would be a very, very bad thing for my firm's position on Bitcoin. As it is, this block size stuff is making us really nervous. I hope the brilliant minds at work on a solution can figure this out (preferably sooner than later). |
|
|
|
* It's counter-intuitive, but giving the customer more payment options reduces sales. It makes your sales process more complex, requires the customer to make more decisions, and thus reduces overall conversion rate.
We look at the data on everything, so I do know this to be true (at least for the services we've tested). Our tests have been conducted using various payment options such as Paypal, Bitcoin, and net-30 terms. Of course every business is different, so I can't say for certain that our results would be externally valid for every business out there. Different target markets might behave differently. (We have seen a similar effect in other areas of choice, for example if a product comes in multiple colors, there can be a statistically significant conversion rate increase by actually eliminating some of those choices.) Regardless of whether these results would apply to all business types, it remains a reason that we will not be supporting more than one crypto-currency, and the one that we do support must have sufficiently large usage to justify providing the option. |
|
|
|
Thanks, this is a real plan of a merchant facing hard fork uncertainty, can I ask why not accepting both Bitcoin-A and Bitcoin-B in the same amount (except you are losing confidence on crytocurrency concept as a whole)?
There are several reasons why we wouldn't accept multiple strains of crypto-currency. Here are the main ones: * Losing confidence in the concept as a whole is the primary reason. If there can be two, why not ten? If they can come and go on a whim, then how solid can this magic internet money really be? We don't want to be playing Frogger with our money (the old arcade game where you jump from one sinking log to another). * It's counter-intuitive, but giving the customer more payment options reduces sales. It makes your sales process more complex, requires the customer to make more decisions, and thus reduces overall conversion rate. * All the back-end overhead to manage not one, but two, different crypo-currencies would add additional expense. The exchange rates would likely be different, we'd have to deal with twice the maintenance and technical upkeep, our accounting would be more complicated, we'd lose economies of scale if we need to convert currencies, etc. Do we pay our employees in Bitcoin-A or Bitcoin-B? If some want A and others want B, but we have different amounts of each, then what? All the extra support that goes into accepting the current Bitcoin is enough of a cost given its extremely low volume as it is. |
|
|
|
|
The firm I work for, which has made substantial investment into Bitcoin, has already thought quite a bit about this. This is what we're doing and thinking:
* While this block size issue remains such a big uncertainty, we have drastically slowed our pace of investment and we've shelved some start-ups that were already in progress. We're not stopping or backing out, but we're proceeding much slower and more cautiously until a clearer resolution to this problem appears.
* If we approach the 1MB limit and a solution does not appear forthcoming, we'll cease all new investment.
* If we pass the 1MB limit without a solution, seeing even the slightest hint that Bitcoin's competitive advantages over the conventional banking and payment systems are being eroded due to an inability to scale, we'll dump all our bitcoin assets and holdings.
* If a controversial solution is proposed, with fierce arguments on multiple sides, we will follow Gavin's fork, even if it's not ideal, on all our sites that accept BTC.
* If the fork hits, and there's even the slightest uncertainty as to which will survive, we will immediately dump all our bitcoin assets and holdings. We will remove Bitcoin from all of our sites that accept multiple payment methods -- at least while we wait to see how things play out.
* If one fork kills off the other, we'll adopt that one and go back to business as usual.
* If both forks survive, with both being widely accepted (for example if Mt.Gox begins accepting Bitcoin-A and Bitcoin-B), we'll accept neither, dump everything, and write off blockchain based currencies and too risky and too unstable.
What we really hope to see is a nice, smooth transition to a system that scales, which very large majority of the network, including major service providers, agree to.
|
|
|
|
|
If I'm understanding this right, a miner with a slower internet connection can be put at a disadvantage by a guy with a better connection who blasts out large blocks. So let's say Mr. Slowpoke is put at a 20% disadvantage due to his connection. Would that really end up putting him out of business? There are so many other factors that he might be able to use to compensate for his connection speed disadvantage such as cheaper electricity, cheaper labor, lower profit margin, lower borrowing costs, etc. Businesses fight on many fronts, so would a competitive disadvantage in just one really matter that much?
|
|
|
|
Otherwise the basic plan seem to be to pull a bait-and-switch, selling people on a purportedly person to person grassroots currency then pulling the rug out from under them by migrating it to business-to-business then to megacorp-to-megacorp...
Well put. Bank of America, Wells Fargo, et al. already provide me with an expensive and restrictive form of money transfer. Their services come with perks too, like insurance and customer service. |
|
|
|
|
If Coinbase can cancel your order if the price goes up, but you can't cancel an order if the price goes down, then what they are doing is essentially stealing a free put option from you. It is also disturbing that they destroy the evidence in the transaction history. They should at least mark a canceled order as canceled rather than try to hide the fact that it ever existed. As they say, the coverup is worse than the crime.
I have been having some similar problems with Coinbase lately too with no response from their support department. It is very frustrating but nothing on the scale of problems people have had with other services in the recent past (MyBitcoin, Bitcoinica, Bitfloor, etc.) At the very least, they should send an auto-response acknowledging that your request has been received.
In reality, I think these guys are just in way over their heads. Hopefully they haven't been hacked or robbed and still have enough venture capital to pull their way out of it. If so, I could see it being a great service at some point. I will certainly make no attempt to continue using their service myself until it's very clear they're on solid footing, and I would definitely not recommend them to anyone, but maybe some day they'll be worth another try.
|
|
|
|
More than one person has noted that transactions have a much higher probability of being classified as "high risk" if the exchange rate has gone up significantly between the time it was started and the time they credit your account with bitcoins. One would think they allocate the bitcoins immediately at the time they lock in the price, but if they aren't doing that it would make sense for them to cancel the order if the price has moved too far.
That would certainly change the classification of this from being unprofessional to being unethical, so I didn't want to say it myself, but the thought did cross my mind. (There has been an 18% increase in the exchange rate since my order was put through.) What's also rather irritating is they still deducted the USD from my bank account. So they didn't really "cancel" the order. They just canceled the part of the transaction where they provide the product they've been paid for. I'll be curious to see what happens with the rest of my pending orders, especially the ones placed at higher exchange rates. I really do want Coinbase to succeed. A functional service like this is very much needed, and their setup may even be easy enough for Grandma to use. But, the real world has very little tolerance for the kind of shenanigans that seem all too common with Bitcoin "businesses". |
|
|
|
|
