That's what I thought. So what did the OP do? Are VirWox still letting you trade a sort-of shadow Linden Dollar that only exists in their database and never actual makes it to Second Life?

SLL are Linden Dollars, right? Are VirWox still letting you sell those for Bitcoins? I thought Linden Lab had imposed capital controls and shut down third-party sales of Linden Dollars?

Caveat emptor is a good system in a lot of cases. In a lot other cases you're better with accountability systems that are separate from the payment mechanism. For example, when I bought a cup of coffee for 100 yen at MacDonalds then got it home and found it was full of coffee grounds, I took it back and they gave me a new cup. But if they hadn't I could have escalated by calling the MacDonalds consumer hotline, and if that failed the Consumer Protection Bureau. What I didn't do was ask the Bank of Japan to reverse the payment by cancelling my 100-yen coin.

If you do need to combine payment and dispute resolution, the Bitcoin way to do it would be to make an escrow transaction using multiple signatures, either the buyer and the seller (who both have to agree to release the funds) or the buyer, seller and a third-party (where two out of three can release the funds). This is better than relying on a dispute resolution service baked into the payment mechanism, because the buyer and seller get to choose the third-party.

BTW, the problem with making transactions reversible is discussed in the first paragraph of Satoshi's whitepaper. Reading that, separating out dispute resolution from payment looks like the main goal of Bitcoin:


http://bitcoin.org/bitcoin.pdf

[Edited for clarity.]

Sure you can. I'm not talking about whether a miner would add it to a block, I'm talking about whether I'd accept it as payment for the socks you want to buy from me.  This is a private contract between you and me, and I can apply any conditions I like. For example, if I was very superstitious, I might refuse to take payment from an address with "13" in it.


No, you just have one version of the blockchain, and the miners will include transactions in the blockchain without discriminination, but the user won't accept some transactions as payment.

No, enforced at the user end it isn't a hard fork like the block size thing. In this case there's only one version of the blockchain which everyone agrees on, but when you try to buy your alpaca socks with a tainted coin the alpaca farmer refuses to accept your transaction as payment, so if you want your socks you'll have to use a different coin.

Here the blockchain is as it always was and miners will happily add tainted coins to the shared ledger, but the Bitcoins it records are no longer fungible: Some of the Bitcoins it shows on the ledger are worth less than others because they're harder to spend.

The countermeasure, as Tiernolan says on the post I linked, is lots and lots of mixing, so that if the alpaca farmer won't take this Bitcoin, he can't take any Bitcoin.

This is a horrible idea that would seriously degrade the usefulness of Bitcoin, but it wouldn't _necessarily_ involve 51% of miners.

In theory if everybody's client software had some code to check the blacklist of coins that passed through certain addresses, the end users could refuse to accept them as payment. Law enforcement (or the mafia, or anyone with an ability to take revenge on arbitrary people) could encourage them to cooperate with the tainting by threatening action against people who accepted those coins.

Obviously you'd need quite a lot of blacklist-enforcement to make it work, but you wouldn't even need 51% of users to _want_ to enforce the blacklist to make this at least partly effective, because if I know that the people I want to pay may not be willing to take a coin with address X in its ancestry, it's worth less to me as well, so I would rather avoid receiving it.

There's a similar effect at the miner end, where if you control a small proportion of mining power and are prepared to do things that aren't ordinarily economically rational, you can change the incentives of profit-seeking miners and get them to obey your laws instead of Satoshi's. See this post by TierNolan for an example, also discussing a small proportion of miners enforcing a taint, and profit-seeking miners going along with it because it's in their interests:

https://bitcointalk.org/index.php?topic=179612.msg2098123#msg2098123

[Edited for clarity]

I don't think it's right that mining will be incredibly profitable; One feature of capital-intensive commodity businesses like this, as well as having economies of scale that favour large players, is that they tend not to be particularly profitable. Assuming the business remains competitive (ie the big players don't form a cartel to avoid deploying too much hashing power) competition should leave everybody locking up a lot of money in equipment costs to grind out a fairly small profit. If the profit margin grows, everybody will deploy more hardware and speed up the hash rate, which will increase the block difficulty until profits return to barely-attractive levels.

Maybe we agree. To clarify, there are a couple of different questions about block sizes.

Q1) How big would it be helpful for blocks to get? Opinions being:
 a) 1MB is right for a long time, for reasons to do with mining on Tor or something.
 b) Ideally smaller than the amount of non-spam transactions people want to make, to raise transaction fees by creating artificial scarcity.
 c) Ideally bigger than the amount of non-spam transactions people want to make, to make Bitcoin as attractive as possible and create lots of transactions to get fees from, which should in turn raise the value of the block reward.
 
I take the OP to be talking about (a), when it becomes a case of (b). In other words, say loads of people want to make transactions, but the block size is stuck at 1MB. Long-term does that mean more fees for miners (higher per-transaction fees!) or less fees for miners (fewer transactions, less on-chain activity, possibility that everyone switches to another coin!). What's happened in the last two years doesn't really tell us anything about that, because we're at (a) and (c), not yet (a) and (b).

What hasn't really been discussed on this thread (which is fine, because it's been discussed on plenty of other threads...) is:

Q2) Who should decide how big blocks should go?
 a) The community, but in a way that's weighted to Gavin / Developers / Miners, by the current model where the core developers make a proposal, stick new defaults in the client, and it gets adopted if the miners will run it.
 b) The community, by some kind of voting mechanism - for example, some people were proposing a plan involving proof-of-stake voting with transactions, to reduce the freedom of the developers and miners to make changes. (The plan as stated also seemed to be designed to prevent any changes actually happening in practice, because it counted the "didn't vote" of people who don't follow Bitcoin politics as a vote for "no change"...)
 c) Miners, by a dynamic consensus process: You can mine whatever you like and broadcast it, but if it's too big to handle the other miners will ignore it.

[Minor edits for clarity]

From a regulatory point of view it's completely different to trusting a third-party service that actually handles the transaction. It's also much easier to distribute (other people can run mirrors of the directory) and validate (since you can check what addresses I'm giving out, and blow the whistle on me if I get cracked or start pulling shenanigans).


I also do that if I stick a Bitcoin address on my website or in my signature. (OK, I don't necessarily put my email address on my website or my Bitcoin Talk signature, but anyone who can use Google can connect the two.)

If you don't want that you shouldn't use my public directory, but you could do it with a non-public directory that fed a new Bitcoin address to each user, while keeping the transactions on-chain. I guess one decentralized way to do that would be that you'd stick an "address server" URL in your DNS, which you could run yourself, and have that feed a new address to each person who shows up.

PS. I'm not saying there isn't value to off-chain systems for a lot of use-cases, just that off-chain isn't the only way to do it, and has a lot of downsides.

The people who want to cap block sizes tend to see it the other way around, because if there's no competition for space in the block, transaction fees stay very low. So the thought is that by arbitrarily limiting the block size, you create artificial scarcity and push up transaction fees. The way they see it the off-chain processors still end up clearing transactions in the block-chain, but the transactions they clear are much bigger, so they don't mind the $1 or $10 or $100 transaction fee.

I'm not convinced that's really what would happen. There are a lot of problems with using off-chain solutions for some of the use-cases that Bitcoin currently covers, not least regulatory ones if you try to do this globally on any scale (even the massively-lawyered PayPal can't operate in a lot of countries, and they need very tedious identity validation procedures in others). Many of these problems are the ones Bitcoin was specifically designed to avoid.

I think what really happens when you try to artificially cap Bitcoin transactions is that everyone sods off to an alternate coin without that limitation, and your Bitcoins become a historical curiosity.

I don't think any of the things you mention to compete with PayPal actually require off-chain transactions, although there are a lot of cases where they have a role.


This can definitely be fixed with a trusted wallet service, and possibly even with some client design ingenuity.


This can be fixed with an email -> Bitcoin address directory with a public API. I made one called Address Machine:
https://www.addressmachine.com/


You have to wait 10+ minutes for transactions to be _irrevocably_ confirmed, but with PayPal the relevant number is more like 3 months. Most practical situations where you need instant transactions can probably get by with zero confirmations, although the issues around this aren't quite trivial. If zero-confirmation transactions _do_ turn out to be too risky in practice for widespread use, there are other ways of working around this without entrusting the whole payment process with a trusted off-chain third-party.

No, the guy who buys in bulk is still going to be buying, installing and operating each ASIC less expensively than the guy who only buys one.

And that's before they start doing things that businesses in the real world often do to give themselves an edge over the competition, like signing exclusive contracts with the manufacturer, or hiring the best ASIC designers themselves and patenting their designs or keeping them as trade secrets.

For comparison: Thanks to the free market, smartphone parts are constantly getting better and cheaper. And you can build your own smartphone if you want to. But try assembling smartphones yourself in your kitchen and see if you can compete on price with Samsung...

Bytemaster is right on the economics of this: Mining is an increasingly capital-intensive commodity business with large economies of scale. Businesses like that are never cottage industries. They guy who buys ASICs and electricity in bulk, and uses the software and hardware setup they had to spend engineering time on for a huge farm of servers rather than a single one, is going to have much lower costs per block mined than a smaller competitor.

Not only that, in a competitive market the large operators will expand their operations to the point where it's just profitable for them, which will raise the block difficulty to the point where smaller, less efficient operators won't be able to run at a profit. This is going to be true regardless of what happens to the block size etc.

If you don't like that, you have three options:
1) Use a different proof-of-work that uses equipment people already have and doesn't require a lot of extra capital investment. LiteCoin tries to do this, but I'm not sure that it works, and even if it does I'm not sure that it always will.
2) Stop using proof-of-work and use something else.
3) Make some decisions that aren't short-term self-interestedly economically rational, like mining at a loss to help keep the network decentralized, or donating to people who do.

There's some relevant stuff in this awesome piece about the evil tricks used to monetize free-to-play games.

http://www.gamasutra.com/blogs/RaminShokrizade/20130626/194933/The_Top_F2P_Monetization_Tricks.php


Interestingly a lot of the things that work against Bitcoin compared to an in-game currency probably work _for_ Bitcoin for regular purchases compared to cash. For example, paying with Bitcoin probably gives you a layering effect that makes it easier to make people spend in a regular shop because (I'm guessing) Bitcoin feels less like real money than money taken direct from your bank account by your credit card. But games are still probably better off with their own in-game currencies. (If your customers have Bitcoins, you should let them buy your in-game currency with them...)

What I have been pushing for (and written code to do) is to use Bitcoin in OpenSim, the free, decentralized version of Second Life. This is a bit less like a regular game, and more like a 3D version of the internet. But even there, some people will probably be better off with their own in-grid currencies, which can be bought with Bitcoins.

I don't think you even need a large-pocketed backer to bootstrap . Let's assume we've got:
- A way of trading in and out of this currency (maybe a decentralized exchange to trade with BTC).
- A way for the network to check the exchange rate of the currency.

The protocol would have a method to encourage people to keep the rate stable, namely:
- If the coin is too weak, anyone can destroy their coins in return for a voucher allowing a share of future money creation.
- If the coin is too strong, anyone can cash those vouchers in and get some newly-printed money.

So you start with 1 coin and 1 money-printing voucher. Maybe it opens at $2 (I'd pay that, it's worth a shot). People cash in their vouchers until there are 5 coins in circulation and it drops to $1. Then maybe the initial hype wears off and it drops to $0.90. We start buying vouchers and it goes back up to $1.10. Everybody knows there's going to be enough money printed or destroyed to bring it back to $1, so speculators should buy and sell anywhere far outside the target price and it should end up only a shade higher or lower than $1 at any given time.

What it relies on is that people think there may be a need to print money in future to maintain parity with USD, without which the money-printing vouchers are worthless. But that isn't too high a hurdle as the currency you're pegged to is getting debased all the time, and I think you have that problem even with initial rich bootstrapping backers.

I've created Address Machine, a free public database to help people who need to pay each other in Bitcoins, but don't know each other's Bitcoin addresses.
https://www.addressmachine.com/

It uses a simple, login-free process where you can look up addresses on the website, by email, by Twitter or through a web API. It confirms email address registrations before adding them to the database by sending a confirmation email.

Or you can use it from Twitter, for example:
 Look up my address: @addressmachine @edmundedgar
 Add your address (replace this with your own address, obviously...): @addressmachine 1Q4uC95NvGSw3JrmFAcc4ZDRDNGZ2u3bFT
 Delete your address: @addressmachine DELETE 1Q4uC95NvGSw3JrmFAcc4ZDRDNGZ2u3bFT

I'll also add the ability to have the system create a temporary address for someone from the API and send them a key to access their wallet, so that you'll be able to pay people who haven't registered Bitcoin addresses yet. For now that will create an Electrum wallet, grab an address for it and send the owner the seed.

The code is open source (AGPL) and is designed with sharing in mind - for example, email addresses are stored hashed (I don't keep the plain text) so we can let a few independent people keep mirrors of the database, while reducing the risk that if they leak the data all the users get spammed.

More information on the website, detail in the README on GitHub.
https://github.com/addressmachine/addressmachine

Comments welcome, and if anyone's interested in mirroring the database, or has some confirmed identitifier<->Bitcoin address data they could share (eg maybe you run an e-wallet service), please get in touch.

Satoshi optimized for the hardest bit of the problem, which at the time was getting people to think that Bitcoins are valuable.

I don't think the incentive to spend is such a big deal, because people are mostly thinking in dollars and the exchange rate should mostly price in the future money supply. If it's rational to hoard it's rational to buy, and if people buy the price will move, until you get to the point where bitcoins are no longer too cheap, even considering low future money supply, and it stops being rational to hoard.

Basically governments are scared of contagion. If you see one bank go down, you run on another one, and that goes bad too. (Probably also some corruption, because people who would lose out are good at influencing the government.)

I think a lot of people here have got the meaning of this backwards. When governments offer full bail-outs with taxpayers's money, it's because they think all the banks are very shaky, and they don't dare let one of them fail in case the rest of them topple, too. What's happening now is that the European banks are gradually getting more stable, so governments are feeling confident enough to try to reassert the original principles of how bank failures were always _supposed_ to work.

...VISA

https://www.icspa.org/membership/members/#c113

Right, but read retep's post carefully - it's written to make people think the Bitcoin Foundation are taking that position, without actually claiming it. We've discussed this more upthread, but it's a very nasty, slippery piece of politics, IMHO.