To do a 1-1 peg properly, the government must be willing to let you exchange in both directions at almost the same rate.
So, if they want to peg usd to silver at 1$/ounce, they must be able to give you an ounce of silver for every dollar, and vice-versa. This would require the Treasury to have 102,058,283 metric tons of silver in reserves, or about 1/4 of the mass of all humans, or about 200 times the total world reserves of silver.

Then to peg bitcoin to silver at one bitcoin per ounce, they would need to be able to produce up to 3.6 trillion bitcoins if and when people exchange their silver. This can't work.

He talked about tainting a couple times. That's it. And given that he's a lawyer and not an economist, he probably didn't realize how terrible the idea was at the time. The foundation has never, and likely will never, endorse tainting.


Exchanges are already a lost cause (even the ones outside the US), precisely because they receive tons of Fiat money and integrate directly into the regular financial system. FINCEN has not claimed jurisdiction over regular merchants, who accept bitcoin as payment.


The data gathering aspect, yes. But they can only share the information that they actually know about the buyer. Digital goods merchants probably only know your email address, not your identity. But then again, the NSA can get the info even if no money changes hands at all. Hell they can get your info regardless of where you buy your stuff, because most of the shipping companies are US based, and therefore their shipping records are accessible to the Govt. This is unfortunate, but has little to do with Bitcoin

The really dangerous part of the CoinValidation initiative, is to make merchants reject funds that aren't sent from an address with an associated identity. But that can't be done in secret, because they need to tell you that you need to register and give them a bunch of info.

Again, let's not panic, I suspect that this idea will be killed off pretty quickly. We don't need to start punishing US merchants in advance just because they might decide to cooperate. We can always do it after the fact, and avoid hurting people who are on our side (despite differing tactical approaches).

A few points:

1. The Bitcoin Foundation is in no way associated with these jokers (neither is DATA, as far as I know).
2. No sane US merchant will cooperate unless they are required to by law. You don't turn away customers, or make them jump through extra hoops to pay you.
3. All merchant associations (BF,DATA, etc.), especially those whose members are mostly US based, will be the ones most hurt by this system becoming legally required.

I realize you don't trust the Foundation. That's fine. You may dislike their conciliatory approach. That's a separate discussion.
However you can bet that they will almost certainly be opposed to a law requiring this system, because of how much it would hurt their members.
And because they've been effective at engaging regulators, they'll be the most able to block any law forcing CoinValidation onto US merchants, whether through lobbying, lawsuits, or other methods.

The guys who will most likely stop this from becoming law in the US are the very people you blame. They've got too much to lose.

The word "shutdown" is pretty fricking misleading.
60% of employees are still working. The remainder are on unpaid leave and every time this happens, they end up getting back pay after the shutdown is over.
80% of the money is still being spent. This means that even a "shutdown" US Government runs at a deficit.

It's political theater, and not much else.

How's the key encrypted/decrypted? With some piece of information (password/another key/etc.). How do you hide that information? Hint: it's turtles all the way down.
Seriously, enforcement isn't magical. Unless I'm missing something really obvious, your approach isn't going to fly.

Your idea can work, but it's not safe/distributed in the same way that bitcoin is:

Approach 1:
1. Use Shamir's Secret Sharing to split the key into n pieces of which n/2+1 are required to recreate the original key. Send each key to a different peer.
2. When you want to spend your money, you need to contact n/2+1 peers, and request their part of the key. Once you have enough parts, you can recreate it and sign your transaction.

Problems with this approach:
1. If n/2+1 peers collude together, they can get the full key back (and maybe get a cut of your stolen funds by giving it to the guy that stole your money).
2. You can't tell if the people you're sending your parts of the key are actually independent, or they're all run by one attacker (Sybil attack).
3. If enough peers go away, you have lost the ability to spend your funds, ever. And you can't get around that by asking the peers to share their part of the key with others, because that breaks the security.
4. The set of rules under which to allow spending is openly known. So a smart thief will know what conditions to satisfy in order to spend your funds.

So you end up with Approach 2:

1. Use trusted peers that have some reputation to lose, and that you're reasonnably confident will remain online semi-permanently.
2. Give each peer a different full key. Store a copy on paper, to guard against loss.
3. Store money in a "m of n" address, ideally where m is high.

It's safer but not peer-to-peer. In fact it's one of jedunnigan's suggestions.

You can't use a peer-to-peer network to hide information, which is what you'd need to actually make this little scheme work.

jedunnigan's suggestions are correct, there's also a variant of the OTP approach that doesn't even require a third party to work.

Coastermonger: Are you flexible as to what security approach can be used? The OTP toolkit is probably the best one in terms of user friendliness, and requiring little to no extra software.

You need an option that says "Shutdowns are always good."

I love just how many bitcoiners actually spend time thinking about full-scale economies on other planets. I guess we're all optimists.

There's a few ways the economy on Mars would work, given a BTC-based earth economy:

1. For a long time, a Mars colony (or any other distant colony) is essentially run by one organization, or a very small set of them. Just like today's astronauts, the colonists don't need a currency system while up there. Even if they run a local bitcoin node, because their link back to earth is completely controlled by the guys paying them, they can't know if they've been shunted to a different branch or not.

2. If a small Mars economy develops, they can free ride on bitcoin's chain for a long time. That way prices are already known, the infrastructure already exists, and you don't need to run power-hungry mining rigs in a resource-strapped context. The downsides are having to rely on zero-conf being reasonably hard to double spend against, and having to wait an extra 8-48 minutes when actually waiting for confirmations.

3. Once those constraints are too problematic there may be a need to start a mars altcoin, or figure out some clever way to have multiple chains within bitcoin, one for each sufficiently distant system. We have a lot of time to figure that out though.

That's a decent set of mitigation measures. Having a per transaction spending limit is probably the most important one.
I'll point out one possible attack that still quite feasible:

1. Terminal sends the actual requested amount to the card
2. Terminal shows the response code and displays it to the user. (So far so good)
3. Terminal immediately cancels the transaction and tries to unlock the card. During that time, the user enters his PIN, oblivious to what is going on.
4. The user presses OK. The terminal now knows the PIN.
5. By now the card has unlocked itself. The terminal sends a larger amount for payment, ignores the response code, and sends back the PIN.
6. Card authorizes a larger payment.

Of course this requires that the lockout period be not much longer than the time taken by the user to enter the PIN. But the terminal can nicely slow down the user in a variety of ways, without looking too suspicious:

1. Add a "confirm amount?" screen to check the payment quantity, after having sent the payment request to the card.
2. Mild delay after pressing each key/hard to press keyboard.
3. Pretending the PIN was mistyped the first time and asking to try again.
4. "Connecting to network... please wait..."

You could try to increase the delay to be closer to a minute, but it looks like you can't track time when you're not plugged into a terminal. Tricky.

There are ways to make 0-confirmation transactions entirely safe for a merchant (it requires a trusted third party to co-sign spending requests). This can be automated, has no fraud risk, and requires very little working capital. No chargebacks either.

Even if it's the same companies running the show, their costs will be very low, (and it'll be easier for competitors to spring up). That's most of the costs associated with credit cards gone entirely.
People will still need loans, and maybe savings accounts, but checking accounts (the ones that pay no interest and are just so you can use the bank's money transfer tools) will be obsolete. That's a huge chunk of most people's money.

Plus there's 100+ countries that right now have no real way to spend/transfer funds online, and a billion+ people that have no bank account. They will both benefit massively from a system that gives them the benefits of our existing financial infrastructure without the onerous requirements.

Ok, let me justify my statement:

1. You have a credit card style terminal.
2. You have a small device with a chip (and no user-facing interface).
3. The terminal is actually built/compromised by an attacker.
4. The terminal shows you a transaction for 0.1 BTC. You press ok, enter your PIN, yadda yadda yadda.
5. The terminal sends your pin, and a transaction for 10 BTC.

How does the card know this isn't valid?

Some solutions that would work:

1. The device does have an interface in the form of a small screen and a yes/no button (No MITM possible).
2. The payment request must be cryptographically signed by the user in order for the device to process it.
3. The device can communicate back to the user in a tamper proof manner (cryptographic signature?), so the terminal can't alter the message displayed on the screen.

Your response so far seems to indicate you're using #3, but unless
Then I can't see how you make this work. At all. You could try a weaker form of either inbound or outbound signature, like different pins for each order of magnitude of spending, but any solution that offers a modicum of security is going to be brainpower-expensive.

Not trying to be an asshole here, it's just that a lot of people come here with half-baked ideas, and it's the nice thing to do to point out flaws before they get a chance to hurt themselves or others.

You do understand that that's impossible right? If the terminal is bogus, and the terminal is the only thing that can communicate with the card, then you can't make this secure.
It's not a problem for credit cards, because you can just do a chargeback, but they do have the same vulnerability.

More importantly the network does not cooperate with any attempted double spends. Right now, the first attempt at spending a specific coin will be the only one that gets relayed, any subsequent attempt at spending it is dropped. There is talk of actually spreading a warning when a double spend is attempted, so that not only would you not be able to double spend the money, but also the merchant would be quickly warned that you attempted to do this.

https://en.bitcoin.it/wiki/Double-spending has a lot of details on different threat models and how to avoid them. General rule of thumb is zero conf-doesn't take a long time to be safe, as long as the value of what's being sold is low relative to the value of a block.

 

1. Assume we already have infinite precision right now.
2. A halving period is 210,000 blocks.
3. The first halving period produced 50 bitcoins per block, (50*210,000 total).
4. Each period is half the previous one.
5. http://www.wolframalpha.com/input/?i=sum+210000*50%2F2^n%2C+n%3D0+to+infinity

Or are you worried about the impact of rounding errors (which shouldn't be a problem given that we're not using floating point calculations)?

I can't comment at how secure their seeding approach is without digging into the code, but yes, a bad rng can lead to transactions being created that leak your private key. Again, you can avoid this issue entirely by never reusing addresses.

Making new addresses every time, so that each is used only once has 2 advantages:
1. Offers some level of protection against bad implementations of ECC (like we saw with the android SecureRandom bug).
2. Increases financial privacy, because it makes it hard to know which output is the actual money sent, and which is the change. If all your money is stored under one address, deanonymizing that address is much more harmful.

Most financial institutions refuse to deal with them medical marijuana centers. It's really nothing personal, they just have to play it safe.
At the federal level it's all still illegal, and so if a bank provides financial services to even one dispensary, they could have most of their property (ie, the bank building, and most of their own funds) taken under asset forfeiture laws (http://reason.com/archives/2012/11/21/drug-dealing-and-legal-stealing). It's a very scary scenario.

Dispensaries will just have to do fiat conversion themselves for a little while longer.

On cavirtex there's no method of depositing CAD funds that doesn't require verification. There's multiple of ways to withdraw fiat without verification.
Which means it's harder to get fiat in to buy than getting btc in to sell + withdrawing fiat. So it's like a reverse MtGox effect. I'm trying to get verified to get these bargain prices but I don't have any utility bills to prove my address. It's somewhat annoying.

Not just that but this address is also receiving money from 1FLH1pPyN5nNxhJUafyd2cUkBwbAaZUNQP directly.

Obligatory somalia reference http://www.peterleeson.com/better_off_stateless.pdf.

TLDR: Somalia's government was really shitty, in fact it was outright predatory, so when it collapsed Somalians' living conditions improved pretty significantly.

That doesn't really help with explaining whether we'd be better off (Western governments aren't nearly as bad).