I do understand the alternate coins with a floating conversion rate. You list some great examples.

I don't understand the alternate coins with a one-to-one mapping to bitcoins. I may be missing something.

You have a pretty correct understanding.

1. Yes that is correct
2. The block chain is a massive ledger of all the transactions using coins. It will grow linearly with the number of trades. However, all trades don't need to be kept forever. Old trades can be culled from the list. Not sure if this is being done now.
3. You could generate a transaction in a detached fashion but it would still need to be transmitted to the internet connected nodes for the transaction to be confirmed in everyone else's mind. Until that point, the another transaction could spend the coins in advance of your detached transaction clearing. There is no way to private go, "Gere are 5 coins. Don't tell anyone I gave them to you."
4. Difficulty is computed and considered.
5. It could be done. Don't know if anyone is working on such an app.

I think you understand completely. Since there is no way to destroy bitcoins they would need to be held in a trusted escrow account. That is the only way to assure there will be bitcoins at the correct market rate to exchange back.

I'm missing the point of the exercise entirely. How does this additional complexity add a new feature to the existing implementation?

I agree with the first statement. I also happen to agree with the second statement (others here don't).

But I don't think anything you wrote supports the second statement. "keep the market small" is ill defined. The market had been growing and the value of coins is increasing. You didn't explain when this becomes bad.



I was only pointing out that "safe from inflation" isn't a constant. In my mind it shouldn't even be a goal for bitcoin. However others seem to think this is a feature.

I posted in another thread about inflation, deflation and lending. Check my history if you are interested.

This logic is mathematically flawed. People don't realize it because they have never seen it.

If external value starts to flock to bitcoin, than the external value to trade increases, while the number of coins to trade stays the same. That means if the value of external commodities traded doubles overall, than the value of each bitcoin doubles as well.

Example: If there were 100 loaves of bread a day and 100 bitcoins the mean value of bread is 1 BTC. If you want to trade an additional 100 loaves a day, you either have to double the velocity of the coins, or trade in 1/2 BTC coins at the same velocity.

That's the easy part! What is counter intuitive is the dynamic vs lending.

In this situation your argument says that people would start lending their excess bitcoins (at interest I'm presuming). So what would the interest rate be in this situation? So if we presume that the amount of value people want to trade using bitcoins will double this year (not unlikely) what is a reasonable interest rate? Well, just putting them in my mattress will give me 100% interest in commodity value with 0% risk.

However, if I want to borrow the money to start a business manufacturing some commodity widgets, the if I borrow the equivalent of 100 widgets today in BTC, then I need to pay the BTC back with the equivalent value of >200 widgets in a year. So if my widget business is growing at 50% growth a year, I'm screwed.

Deflation make lending very expensive, and very risky. That is why there is minimal lending now, EVEN THOUGH the government is giving away free money for banks to lend.

People are not used to this in their regular life because they are used to price inflation.

Inflation means that money in your mattress is worth less to you (in commodities) next year than it is worth today. That encourages you to LOAN your money to a bank in hopes that they will pay you at least as much interest to make up the difference. A little extra is even better!

This makes lending cheap for new businesses and much less risky for lenders. Business need a much smaller growth rate and profit margin to succeed. Including the bank to whom you lent your money.

Votes could be weighted based upon your address' balance of bitcoins. Stock proxy-vote style. The rich would have more power.
Votes could be weighted based upon the number of nodes. The hackers would have more power.
Votes could be one-person, one-vote. But that would have to be verified outside the system.

I don't understand your point. I don't think you made it.

Bitcoins would work just as well as a national fiat currency with no other alternatives.

There would generally be price deflation over time as the amount of external commodity value increased against the constant number of bitcoins.

However if there was a war and lots of people were killed. The external commodity value would likely decrease and there would be a spike in inflation.

There could also be other spikes as people who were hoarding decided to trade their bitcoins.

See that's the insidious nature of correlation. If I tell you about it, then build it as a hidden service. The service is forever linked to my user account here!

:-)

I'll post about it in detail but it will take more time to explain than I have now. It involves trust, but in the bitcoin spirit, the trust is cryptologically verifiable. 

By the way, I've got an idea for an automated way of preserving true anonymity in the transaction list. It shouldn't require any changes to the bitcoin system.

I might try to create it as a service if anyone thinks it would be of value.

Other people are going to hate the whole concept though. ;-)

Anonymity in BitCoin is really a misnomer. It is really pseudonymity as all transactions are done through bitcoin addresses. An address is equivalent to the pseudonyms used on this site.

When people speak about anonymity/pseudonymity they usually mean link-ability. Can my pseudonym (address) be linked to my real world identity.

However, there is another important aspect, associate-ability. What can others learn about me by watching the behavior of my pseudonym. Because bitcoin is a publicly visible directed graph, link-ability is directly related to associate-ability.

Suppose you use the same handle and anonymous email here, as you do on a kiddie porn site. If that association was made you might be banned here, or even targeted by others. In the real world (and the generalized internet world) those associations are often hard to make. That tends to make people careless. However, in bitcoin these associations are trivial.

Associating your address with a set of behavior gives others a reason to attempt to link it back to you.

Every bitcoin comes to you from someone who knows enough about you to transact with you. When you spend the coins they go to someone who often knows you as well. Each interaction can leak information about you or your behavior.

You would think that single use addresses could protect you, however they can often be correlated easier than you think.

Suppose you want to buy a domain registry from privacyshark for 700 BTC. But you don't want it associated with your well know bitcoin address in your footer here. So you decide to route it through three single use intermediary accounts (x, y, z). So create new accounts X,Y,and Z. Send 700 BTC first to X, then from there to Y, and from Y to Z. Finally you send the 700 BTC on to privacysharks well known address.

Well you are still screwed, because on the bitcoin directed graph, you just drew a straight line from your public address here to privacyshark's public address. Each segment in that line correlates by value amount. They also correlate in time. (one hop each block at worst)

What if you try it differently, you send three different amounts from your public address to the three new addresses. 100 to X, 200 to Y, and 400 to Z. Then you send from X, Y, and Z individually to privacyshark. Well these amounts now create a neat diamond shape on the graph with you at the fork and privacyshark at the join. The transactions to and from X,Y & Z all correlate in time (perhaps even in the same two blocks). They also correlate by amount.

If you already happen to have coins at several addresses and you decide to sent 700 of them at once to privacyshark, I'm not sure exactly how the client generates the transactions but I do know, that they will still correlate by time and amount. Even worse it has the potential to associate non-single use accounts to one individual.

You can only de-correlate the timing by adding more latency. You can only de-correlate the graph connections by adding more hops. You can only de-correlate the values by adding more forking. All of these precautions reduce the utility of bitcoin and increase the complexity of transactions.

Is anyone going to go through all the bother to back-propagate your transaction graph just for buying a domain name? Well they might if privacyshark just registered "kiddieporn.com" and they are looking to link that to the buyer. And while doing that they might happen to correlate the anonymous registry of "IDontPayTaxes.com" with your "trade in bitcoin instead of paying taxes" post here.

1. No. <-- That is the shorted summary of the well laid argument in that thread.
2. No. If people decide they don't want to sell their goods for bitcoins, prices will likely inflate on the goods that do trade. It's a sell your coins while they are still worth something situation.
3. No. Explained previously.
4. No. Hoarding doesn't lead to collapse.

If prices monotonically deflate, hoarding leads to wealth in exactly the same way as the interest from loaning money to a bank leads to wealth. The more coins you hoard the larger the summation of benefits from each coin buying more. The math is simple. It is equivalent to saying if you loan $10 in a bank you get twice as much interest as loaning $5.

While I think the signed binary bit is a non-solution to the problem, that attack vector is really quite likely. Especially while people are competing to run specialty builds that hash fast than everyone else.

A real solution would be to factor the key generation and private key storage into a separate process. The bitcoin client would communicate with the signing process through a well defined interface that took the data to be signed as input and returned a signature as output. It would never expose the actual public key to the bitcoin client.

This is equivalent to what some USB encryption dongles do. http://goldkey.com/

The signing process would have to prompt the user to review the generated transaction, and unlock the wallet prior to signing it.

A user review of the actual generated transaction is necessary to prevent the other obvious fraud vector. Covertly replacing the bitcoin address on a user's intended transaction with an alternate, prior to signing.

To make that work in bitcoin you would need to be able to create a private key that both of you know, but a public key that each of you only know *half* of. In the crypto sense of half, where there are two secrets that can be combined together mathematically to make a third secret.

You would both transfer 5 BTC to the bitcoin address matching the public key. Then neither could retrieve the coins until one surrendered his half to the other.

A proxy comes to mine, but that is cheating. If you used a proxy to generate the private key and split it, they would know the private key and in that case you might as well trust them to hold the money without splitting the key.

I don't know enough about how elliptic curve based keys are generated to propose an algorithm. But stranger things have happened in crypto than that. In some cases, you can do math with two unknown encrypted numbers and have and have the answer decrypt correctly.

Go figure.

Thanks lachesis!

That is what I concluded from reading the code. It makes perfect sense when you dig down to the details. It wasn't what I was expecting though from a system called bitcoin. Was kind of expecting objects representing coins which were somehow encrypted, signed and passed around between parties.


As a side note, can you imagine writing the FAQ for BitCoin for a new generation 20 years from now?  I mean far enough in the future that we have begun to cull the beginning of the block list.

Q: "How do I know that the bitcoins you are giving to me really exist?"
A: "Because the guy that gave them to me believed they existed! And the guy that gave them to him..."

It's really going to sound like the old joke that ends with, "You don't get it. It's turtles all the way down!"

Thanks! those are great answers!

I guess I slipped a couple of "design decision" questions into a list I intended to be purely about parameter settings.

Bitcoin addresses vs full public keys/certs
Certificates vs a key wallet

But if we add to the design decision list, I'm also interested in:

Coins - why the decision to not serialize them or otherwise uniquely identify individual coins? (This misconception seems to come up repeatedly)
Accounts - why the decision not to keep a running balance by bitcoin address in the block list.

I think I understand why, but if there was a FAQ, those two would probably belong in it somewhere.

Fair enough! :-)

Hoarding is worth discussing but by no means is it rediculous.

If you are living in a world with price inflation then a key thing to teach your children about is the magic of banking with compound interest. The last thing you want is a long term piggybank.

In a world with pre-planned monotonic price deflation, the equivalent magic is called hoarding.

I think that the limits of anonymity needs to be discussed if that is going to be a claim of the system.

I'm very interested in that subject, however, others are less so.

Might be worth creating some sort of best practices, depending upon how anonymous you are trying to be.

As close as I figure everything throughput is babbling about, comes down to a single use case.

1. Superhacker "Red" wants to steal bitcoins without anyone finding out.
2. Red downloads the bitcoin source from sourceforge.
3. Red adds a little extra bit of hidden code that covertly uploads the node owner's wallet (private keys) to Red's super secret hacker server.
4. Red uploads the hacked binary to sourceforge or somewhere else that people will think it is an official version.
5. People trust the hacked version and begin to use it.
6. As the wallet files come in, Red uses their public keys to submit valid transactions sending the coins to untraceable super secret bitcoin addresses.

He suggests this scenario could be avoided by signing the binaries with a trusted public key/certificate.

I didn't notice this earlier or I would have responded.


Who wrote the code doesn't have security implications. What the code does, has security implications. If you don't believe the binaries match the source, then build the source yourself. If you can't ask for a binary from someone you trust that has. If you can't do either. You are what we call SOL.


This makes no sense to me. See above.


This almost makes sense, but not really. Most of your points are off enough to be dismissed out of hand. However, I thought of a better example that others might grasp so I'll mention it in a follow up post.


1. I did.
2. Yes, others agree. Just ask.
3. Implemented correctly, yes it can be proven and the risks of the system documented based upon the strength of the crypto. If there are bugs in the code, it is open for anyone to point them out and/or fix them. I tried. I failed. Others may try as they think weakness.
4. Yes, he did a great job in the white paper.


You can't put inconsistent transactions into blocks. The other nodes will reject your blocks.
The entire transaction log is public. Even if you were able to subvert most of the nodes, if you expect the other nodes to accept your transactions they have to be consistent valid transactions.

If you can subvert all the nodes, then by definition you are not running a bitcoin network. You are running a "your silly coin" network.

The rest is nonsense.


Everyone analysis. Just ask Knightmb. Do you think he would have spend one nickel on server time if stealing coins was easier?

You are foolish, to not presume that the community has not already considered every point that pops off the top of your head.



Everyone tries. Everyone fails. Everyone tries again.

You should try again. Just try to understand the system first. Then hack it.