Wanting to support an Amazon-that-takes-bitcoin, I placed an order with BitcoinStore.com. Here is my capsule review ( permalink): - Order placed successfully. Largely shopped in the "home and appliances" section, as hardware and software generally flow freely to me
 - Nice, clean, minimalistic interface. Not as fancy as Amazon.com by a long stretch, but certainly usable and apparently well stocked.
- Bitcoin payment, apparently via BitPay's engine, was successful. A standard bitcoin address was presented on the page, and the reference client sent coins to the address without a problem.
- Did not bother to compare prices with Amazon.com. Main goals were to stimulate the bitcoin economy, reward businesses going a good job representing bitcoin, and provide a real-money review of the store.
Major criticisms: - I checked out as a guest, not creating an account. It was disappointing that there is no order URL at which I may track my order, e.g. https://orders.bitcoinstore.com/#1099000000 Almost all other online retailers offer this logical, basic feature: watch the status of an order on the retailer's website, even if you did not create an account.
Minor criticisms: - The store sells 128GB flash drives, but the search string "128gb flash drive" does not return useful results.
- Shipping was simply described as "standard shipping", without additional information about shipping methods. USPS? UPS? FedEx? Who knows?
- Two shipping methods were offered to me: "standard shipping" for free, or "standard shipping" for some amount of money. Seems pointless to offer the same method twice, with two different prices.
- Sending bitcoin payment before clicking "place order" is quite awkward and backwards from standard user expectations, I would think.
- Nevertheless, as instructed, I sent bitcoin payment to the network before I clicked place order. The user interface displayed an error. I waited a few more seconds, then clicked "place order" again. This time, it succeeded.
- Order email, received after placing and paying for the order, simply says "Once your package ships we will send an email with a link to track your order." -- again failing to describe how my order will be shipped
- Order email is 100% USD, with no mention of BTC at all. Payment was in bitcoins, of course (the only payment method available).
Conclusion: Rough around the edges, but good selection and they take bitcoins. Would buy from again... assuming that my current order arrives! |
|
|
|
Using Sergio's method you could for example log the first 10 nodes to relay a transaction then pole each node with a penny flood transaction in order to accurately determine which one was the true sender. I may have a go implementing this to improve blockchain.info's relayed by accuracy.
Doesn't that sort of strip a lot of privacy away from a lot of bitcoin users, without their consent? |
|
|
|
ASIC preorders are high risk but they are also high reward.
This. A first-run of ASICs for a young startup is very high risk, even excluding the possibility of being a scam. My method was pre-ordering from all vendors, in the hopes that one of them would actually ship. |
|
|
|
Ok, i renamed the .bitcoin folder and still Segmentation fault... and the folder is empty, no logs, no nothing! I run suse 11.3...
Can you post the exact errors you get? No debug.log appears at all? |
|
|
|
On the topic of OpenSSL... is it possible to reimplement the OpenSSL behavior, or at least extract it from where it is currently, and have it hardcoded into the Satoshi client? Or rather, does the license allow you to redistribute the OpenSSL project/source with the project so that it can be static compiled? I guess you only need a .a/.lib, but I'm not sure what the OpenSSL license is like. That would certainly resolve any issues related to dynamic linking to system libraries that might be different versions on different computers. It would make the project immune to system library upgrades, which is probably better for security anyway (an attacker could simply swap out the system OpenSSL with a different version having a known bug that he could exploit, and even a diligent user wouldn't notice because the signatures and checksums on the Bitcoin-Qt source distribution are correct).
I have thought about doing this on more than one occasion: Creating a libcrypto_satoshi snapshot with the bignum, DER, ECDSA etc. bits we currently use. This would work around an IMO incorrect exclusion of ECDSA from Fedora's openssl package, as well as "freeze" certain bits that are exported globally via the bitcoin blockchain. But as always, there are costs to maintaining a fork. It inevitably gets less eyes, use and maintenance than the main fork. |
|
|
|
Someone should just write a spec and stop debating it.
+1 If you want a spec then write something. That's what's happening by default anyway on the bitcoin wiki. But Mike Hearn makes two key points that are nonetheless valid: - You can write a spec, but you can't guarantee it actually matches the behaviour of the majority implementation.
- The consequences of getting details wrong is far more severe than that which most programmers are used to; there is simply no comparison to, e.g., POP3.
If it were an IETF draft, I would add a section at the top that states "the reference implementation is canonical, this spec is subordinate. any differences are spec bugs." |
|
|
|
So what do I have to delete in .bitcoin to get the latest release to work?
Technically you can delete everything except wallet.dat and bitcoin.conf. |
|
|
|
I'm not sure if you can really call it a "hard" fork. Some people could change the limit today without really effecting the network since we aren't really hitting the limit yet. And it would make the most sense for us to change it now so by the time people start hitting the 1MB limit, it won't be an issue.
Regardless, it isn't really up to the core developers anymore. The developers at slush or deepbit could change the limit today. It'd be risky to try to propagate a block today over the limit, but if the larger miners got together and decided on a date to collectively change the limit, there'd be a higher success rate.
Wrong. All bitcoin clients will reject a block above 1MB, regardless of what any miner produces. Thus, it would take a hard fork to change the maximum block size. |
|
|
|
If Satoshi thought that transaction fees would be how mining supported itself, that was just a guess. He couldn't possibly have known how it would eventually work out or even thought he could know. Note that some of his other guesses have proved wrong, like the popularity of sending directly to IP addresses. Not quite. Once the initial block reward is exhausted (negligible), fees are the only mining income. So that leaves only two possibilities: transaction fees would be how mining supported itself, or external incentives cause miners to mine at a loss (fee-wise). |
|
|
|
gweedo, what makes you so aggressive when it comes to the Bitcoin Foundation? When you take a look inside (2.5 BTC per year for an elitist group is quite cheap), you'll see it's just a group of 242 humans (right now) - and most of them are really friendly. Nobody forced me to pay 25 BTC and I don't regret it.
How many of those 242 do you think work for Mt Gox or bitinstant? probably all employees of both, and that is where my issues really lie, MtGox and BitInstant are nowhere near that big. The majority of Bitcoin Foundation members do not work for these two companies. That's just silly paranoia. Math fail. |
|
|
|
|
A business directory would be a great idea. An edited business directory, independent of any one business (BitPay or anybody else).
Use trust metrics and pay attention to scam reports, BBB rankings, etc.
This could be a very positive force in the bitcoin community, a reliable website we can point new bitcoin users to, so that they may see all the trusted businesses that accept bitcoins.
|
|
|
|
Any progress on Picocoin? Been following this thread for a while ut it seems to be asleep for a few weeks now.. and if there is development. Any idea about compiling on windows?
Many devs, myself included, are on winter break ;p |
|
|
|
We still have a few hours before 11:11 UTC, Go out into the world and spread a little chaos, if we all do our part we can make this end of the world thing a huge success!
Indeed. Or ~6:12am EST. |
|
|
|
|
It is self-evident that guns make it easier to perform mass killing. Guns are tools designed to kill, possibly at a distance. Far more effective than a knife, by design.
It is also self-evident that history has shown time and again that disarming all citizens makes oppression and slavery much easier.
Pick your poison...
|
|
|
|
|
Culture and history are integral to any solution, certainly.
America has an estimated 300 million guns within its borders.
If, hypothetically, all those guns were rounded up and eliminated, criminals and the mentally ill absolutely would have reduced access to guns.
However, outside that scenario, any amount of gun limiting can negatively impact lawful citizens while not materially impacting access to criminals and mentally ill.
|
|
|
|
|
tl;dr: Use a decentralized client, rather than a centralized web service.
|
|
|
|
No-chargebacks is a selling point for merchants (admittedly the target of the video), but consumers love chargebacks. And there are ultimately far more consumers than merchants.
Jeff there is a big difference between a cardholder filing a dispute with a merchant, a cardholder using the dispute process to execute a scam ("friendly fraud"), and a cardholder having their account compromised with unauthorized charges. To the merchants, all 3 of those scenarios appear the same, in the form of a chargeback. However the account numbers being compromised are by far the major contributor to the $100B payment fraud. Friendly fraud is also on the rise as people have learned how to abuse the system to commit shoplifting. The legitimate disputes can be resolved by using an escrow transaction. No argument. But again, that is purely the merchant's view. Consumers, at least here in the US, have been trained by well known consumer advocates such as Consumer Reports, Clark Howard, NACA members and the local news "consumer beat" that credit card purchases, in particular, have a level of consumer insurance built into them. Every 5-10 years, a new layer of consumer protection regulations are added or updated as well. The hurdles at the consumer level are twofold, assuming a future world where bitcoins see 1000x consumer and merchant acceptance (hey, 1000x is easily realistic in a few short years, given how small we are right now): 1) Education. "Use an escrow transaction" is a foreign language, an alien concept to Aunt Tillie. It is not realistic for average consumer use, unless the software tools and legal system both evolve significantly from where they are today. 2) Rational economic actor choices. The current credit card system provides significant economic and legal protections to the consumer, while hiding the costs by making the merchants bury merchant fees inside the item price. Buying an item sans merchant fees is not likely sufficient economic incentive to abandon the legal protections currently available, for average consumers. Now, please, don't misunderstand. What BitPay is doing is great -- I retweeted and promoted the video. And it is a necessary step in bitcoin's evolution.In an optimistic forecast, one could see bitcoin taking over the majority of hard-cash-like transfers. I imagine merchants would prefer bitcoin over having to deduce whether or not a $20 bill is counterfeit, even using the latest ink tests and scanners one sees deployed at Wal-Mart, Target, payday loan and pawn shop locations. But the huge amount of built-in consumer protections -- and associated consumer advocacy at all levels -- is an unquestionable hurdle. It seems more realistic that bitcoin credit cards will arise, as an optional, supplemental layer on top of the base currency: credit cards, with standard protections consumers expect, denominated purely in bitcoins. Much like credit cards are an optional, supplemental layer atop the US Dollar right now. That would at least be a familiar system to current consumers. |
|
|
|
|
No-chargebacks is a selling point for merchants (admittedly the target of the video), but consumers love chargebacks. And there are ultimately far more consumers than merchants.
Bitcoin can be better-than-cash for any merchant or consumer who already deals in cash, but that is just part of the bigger picture.
|
|
|
|
|
Show Posts
