Actually I was writing an example of third party trade but it was a lame example so I erases it. Yours was much better.

I think we are in "violent agreement" on the topic. :-)

I prefer my currency as an abstract accounting that, I feel, should not have commodity characteristics.

My best example is I don't think currency should increase in value as a result of demand. All commodity have this characteristic naturally.

Some feel differently and certainly commodity currencies have existed in the past but they died out. I think that is less conspiracy than a diminishing in utility compared to non-commodity based currencies.

The French website suggests that the concept of paying dividends proportional to how many coins each person possesses would be what is commonly called "regressive". (i.e. The rich get richer relative to the poor.)

Paying dividends in proportion to the population, (one person, one share) is more "progressive". (i.e. The poor gain relative to the rich.)

Truly this is nonsense.

If I have $10,000 from deposits, a 10% reserve means I need to reserve 10% of my deposits. So I must reserve $1,000. Therefore I can lend $9,000.


I already have the $9,000 on hand. It's already borrowed from the depositor. I don't need to ask the central bank for anything.


Yes, I made the account entry when the depositor gave me the money. Yes, they can take have the money when they want it.


If my borrower wants his money, I have it. You haven't even mentioned me loaning it out any yet.

But let's just say, I did loan out $9,000 to Suzy as partial payment for a used car worth $15,000. She paid $6,000 to the seller out of her wallet. I paid the other $9,000 to the seller in cash when he came by the bank. In exchange the seller signed the title to the $15,000 car to me. I'm holding that title until Suzy pays back the $9,000 plus interest.

==

So back to your point. I have only $1,000 cash-on-hand. And let's say my depositor want's his whole $10,000 back.

So I have to call ANY other bank and BORROW $9,000 cash to pay him. I can do this easily, because I can show them I have the means to pay them back. I own either a car worth $15,000 or a loan worth $10,000 principle+interest. If necessary I can sell either one.

So I borrow the money from the bank next door. I still don't see money coming out of thin air.


Good, the borrower paid me back $9,000 + $1,000 in interest. I now have $10,000 and I owe the bank next door $9,000 plus $500 interest.

I pay them back. I now have $500 profit, in cash. In my hand.

Still no money created from thin air.


This is all gibberish. It is not supported by math. It is not supported by English semantics. It's not supported by references that explain the mismatch. It just literally makes no sense at all.

Justify your association between the ability to lend NINE TIMES your deposits with the phrase 10% reserve. This math doesn't work. This semantics doesn't work.
$10,000 * 0.1 reserve = $1,000 reserve   
$10,000 - 1,000 reserve = 9,000 unreserved   
There I showed my work.

So even if I had $90,000 in secure interest paying loans out. There is no such thing as "recalling a loan".
If I need cash, I have collateral. I can borrow cash. It is simple barter. I don't need special treatment.



Really? Is this representative of how people think banking works?

Some days, typos seem like my first language. :-) But if your asking. All of my other languages are worse than English.


commodity |kəˈmäditē|
noun ( pl. -ties)
a raw material or primary agricultural product that can be bought and sold, such as copper or coffee.
• a useful or valuable thing, such as water or time.


If I can barter for it. It is a commodity. What I choose to do with it is up to me.

Most of the discussion on this list as it relates to bitcoins comes from a barter mentality. Perhaps you haven't noticed.

Really, no European says, "My salary is an investment in Euros". American's don't say, "I'm putting penny's in this piggy bank waiting on an increase in demand for pennies."

Money is a medium of exchange. I swapped an ounce of gold for 1000 loaves of bread, using $1000 to speed the process. I did three months of work and I'm going to buy a car with it after my vacation, using the $20,000 in my wallet.

If there is "excess demand" for money, that is a flaw in a monetary system not a feature. It is only when you think of commodities that such terms make sense.

This is a really cool idea. I think I see where you were going with it. It took me a few tries to fit it all together. I'm a bit slow.

I'm correct, you were suggesting that you could sign an out-point hash with a single-use blinded key.

Where the blinded public key is equivalent to the public key of the transaction's bitcoin address. Say the bitcoin address' public/private key pair was P/p. The the blinded public keys would be P1, P2, P3...Pn. Where each can validate anything signed with the private key (p).

So upon creation when you submit the out-point hash for validation it appears as signed by P1. However, when receiver submits the out-point for cancellation it would be signed P2 or anything besides P1 (since it is already of public record). Both calculated signatures would be the same, but the public key would change. That would signify only someone in possession of the common private key could have generated it.

That is genius!

I'm going to reply to this in two parts.


That's my fault, because I was trying not to make too many claims at once. I was also not trying to introduce too many new "features" at once for analysis.

My mental goal is to incrementally constrain the horizon of transaction visibility. Both in time and in space. Time meaning say to only nodes running at a particular instant. Space meaning to less than the set of all nodes running at the time. Optimally, a transaction would only be known to the sender and the receiver. Then all proof would disappear.

I hand you a $10 bill. Then we walk away forever. As long as no one observed me handing you the bill at that moment, no one can ever discover it by examining the bill itself.


I initially hoped that all transactions would be validated only between the parties concerned. In effect the block generating nodes would just record the hashes that got told to them.

However, at the last minute I realized that since the hashes were not signed or otherwise verified, it became possible to easily falsify a "cancel the previous out-point hash". You couldn't steal someone's coins but you could invalidate them.

I can see three possible ways forward on that pesky detail. 1) let all verifiers see the transactions, minimize what is saved. 2) come up with some way to minimize the number of validators that need to see each transaction. 3) create a single use keypair for each new out-point. Sign the hashes. (Last minute entry!)

1) I initially wrote about the first case, because it introduced less variables at once. I wanted to be sure recording only hashes wasn't an obvious FAIL.

I tried to quantify what bit of privacy we would gain. It is minimal in the worst case, (everyone saves everything anyway) but it is considerable in the nominal case, most people don't save anything they don't need for themselves.

So in this increment, the benefit is, any new threats can only observe a transactions that occur after they join. They can't look back in time, unless they can both identify an earlier adopter who recorded everything from when they joined, and convince them to share. So minimal protection, but at least your Ex isn't going to be snooping around after the fact. :-)

2) However, it is possible to minimize the space horizon with a clever use of a DHT. All details are not worked out yet, but you can visualize it by splitting the block list into say 1024 identical block lists each with 10 redundant validating nodes. Rather than one blocks list with 10,000 redundant validating nodes. Each randomly chosen set of nodes is responsible for a segment of the hash space.

But instead of guaranteeing that 50% of all CPU power is required to fake something, you might aim for 100% consensus and a complete broadcast of the chain checksum and/or blocks. So upon periodic DHT re-org any new node can verify that the chain has always remained 100% consistent. (Similar to publishing each of the 1024 checksums in the newspaper each day)

This restricts an attacker's visibility to know what hash he would want to cancel. (I only see 1/1024th of the transactions) And it limits his time window to submit a fraudulent cancelation to a time window when he controls 100% of a bucket's verifiers.

So there is a potential path to gain some privacy by restricting some visibility. It comes at some potential risk.

3) So in reality I need to give you credit for sparking the best case idea. Kudos! I initially dismissed the idea of signing the out-point hashes, because it seems so much like the existing bitcoin addresses. I assumed the public key required in the signature would associate too many things.

However, if you use a one-time public key where you sign a combination of the out-point hash and the current block number. Then when the out-point hash is initially created it is recorded with a public key. When it is spent the hash is verified by having a different but related signature, signed by the same key.

I think that solves the problem completely. There are no additional associations because the two single use instances of the out-point hash in the block list HAVE TO be related. Adding a second single use public key identifier adds nothing.

To simplify the "current block number" issue, the submitter might submit signatures for the next 3-4 block numbers. The validator would only record the appropriate one. To the block.

It does add more bits to the block list than I was hoping to. I thought a hash only was optimal.

====

What is the smallest crypto construct that has the following properties? Might be able consider that instead of a hash and full signature.

1) I give you something that appears arbitrary.
2) I give you something that appears easily related to your #1 but unrelated to anyone else's #1.
3) Nobody else could figure out your #2 from #1.

====

For example

1) I give you  Z where Z = X * Y and both X & Y are large primes
2) I give you the tuple (X, Y)
3) Nobody can factor X and Y from Z

In that case, when sending an offline transaction, the sender would enclose (X,Y) for each in-point.
The receiver would privately create a new (X,Y) for each new out-point.
The receiver then broadcasts each in-point's (X,Y) to cancel them. It broadcasts each out-point's Z to create them.

Does that work, or is it too naive?

All processes for bitcoin cheating involve either:
1) Inserting a non-validated transaction into the block list. Which is easily spotted by anyone with the list, generating or not.
2) Removing previously validated changes from the list, which involves substuting the entire tail (most commonly scrutinized section) of the list.

All other theats are common concerns to all secure systems. (man in the middle, wallet stealing, cross site scripting)

One and two are really easy to add additional defenses too. In fact there are more existing defenses than are currently discussed. (hardcoded checksums, prohibitions on large branch switches.) as attacks are spotted it's easy to bump up defenses.


As such, this argument boils down to, "if there were a way to cheat it would be more profitable than not cheating." Duh! That is why we don't rely on incentives to prevent cheating!

I'm not arguing that anyone is an idiot. I'm just trying to clarify the issue Galuel is concerned about. (I hate his solution by the way.)

Suppose that Bitcoin had launched slightly differently, but otherwise was exactly the same implementation.

Suppose that it was launched as a closed beta, but there was already considerable interest. Suppose 10,000 people submitted requests to join the first day. But suppose Satoshi decided that he needed to monitor the system closely, because his reputation as a software developer depended on it. He simply wanted to spot and fix bugs before they would have any wide spread consequences.

So to be fair, he decide to randomly choose 100 people the first day, then to choose 100 new random people to join each day for 100 days until the initial request list was exhausted. After that the system would leave beta and anyone could join who wanted.

Would this have been *more fair* or *less fair* then the "he who hears of bitcoin first, joins first" approach that is being used?

I say, it depends on if you got your acceptance the 1st day or the 100th day. But you may feel differently.

I curious, say I want to start a bank and create money out of thin air, how do I do it? I would like to engage in this business.

My name is Joel Bernanke and I've got some connections. But if you can I'd prefer an explanation that a friend my dad doesn't like could use.

Thanks!

I wasn't trying to slam your definition of "fair". I really wasn't. I was simply pointed out that while we all agree that there is a fixed number of bitcoins, and a process for distributing them. The process has NOT completed. It seems inappropriate to use the past tense. In reality bitcoins are "distributing themselves" in a process that everyone is required to agree is fair. Or you don't get any.

I agree with your closed definition of fair. It is equivalent of joining a Soccer league and then complaining that it's "not fair" that the goalie gets to use his hands. The correct response is, "It's not EQUAL that the goalie gets to use his hands, but it is FAIR that the goalie gets to use his hands, because (insert your own reason here). In reality, all reasons tend to converge on, "because if we made it more (insert your complaint), the game sucks and nobody wants to play."

In American football, defensive blockers can use their hands, but offensive blockers can't. It is fair but not equal, because if it were equal the game would be boring.

But the rules are not "fair" because they are unchanging. In reality, sports rules often change to make the game *MORE* fair. Pick your sport and there will be a list of important changes. American football, "pass interference, roughing the passer/kicker". Soccer/hockey "offsides rules, blue lines." etc.

I point this out because that is the sense of the word FAIR that I was using, and I'm presuming Galuel was using. (But not Obama. :-) )

If 1,000 people want to use Bitcoin but 6,000,000,000 don't, Bitcoin is still fair.

But if you can make changes to Bitcoin so that 6,000,000,000 people want to use it but 1,000 don't, the changed system is *more fair*, and much more relevant.

This differs from Obama's definition of fair, which is "Fuck those guys who believe differently from me. They're idiots and can't hurt me. They'll get my definition of fair and they'll like it!" That definition of fair tends to cause revolutions.

Actually, I think most people miss his point so I'll try to clarify it.

Bitcoins are NOT "fairly" distributed yet. Some are. The vast majority are just waiting to be distributed. But the existing mechanism is presumed "fair enough" for the current community.

It bitcoins were already "fairly distributed" we could simply stop generating anymore. Since enough are already generated to last in perpetuity. The reason people want to see coins continue to generate is qualitatively for the same reason that Galuel wants increased generation. The only thing disagreement is quantitative.

What Galuel is trying to point out is that even if coins are "fairly distributed" among the bit coin users of today. They are NOT fairly distributed among next week's bitcoin users. If you look at that set of users instead of the current set of users, it is clear that some got more coins simply for showing up first. Not for putting in more effort.

Built into bitcoin is a tyranny based on time. At least that's the way he sees it.

Many will agree with him. To dismiss that out of hand is to make the same mistake Obama did with the tea party movement. Never under estimate how man, (or how strongly) other people perceive you as an idiot.

I think Galuel is just what this community needs. It was getting a bit self-congratulatory here.

It's nice for the libertarian to get to see that they're not just trying to separate themselves from "conservative" monetary policy. They are separating themselves from "liberal" monetary policy as well!

I have read the French website and I think the ideas probably sound good in a coffee shop. But perhaps not to the shop creator. Perhaps not either to the waitresses forced to serve the layabout philosophers. But I'm sure it sounds good among the beatniks.

Personally I think it is silly and quite obviously ill conceived. But as contrast, it's invaluable. It highlights that, quite possibly, there are ideas being discussed here that play best on the gun show circuit.

By the way, I love gun shows! :-)
 

What does it administer? Is it just a block list viewer/analyzer?

Cool!

Something I disagree with more than the permanent deflation concept!
 

I would have guessed that phpmybitcoin was a php implementation of mybitcoin.

So yes they can be confused.

I have used phpmyadmin lots. I didn't draw the parallel.

Second the inherent value of gold.

It is an easy to work metal that conducts electricity well and doesn't tarnish, rust or otherwise degrade over time.

One of the worst possible uses I can think of for gold is to use it as money. As shown in everyday life, anything can be used as money. It's better to use something otherwise useless for money. Say britney spears CDs.

:-)
 

In reality bitcoins are the first master planned scarce COMMODITY. It is unique to this commodity that we know it's total available quantity in the universe. We also know exactly how hard it will be to discover this commodity over the next XX years. Also this commodity is generally seen as easily divisible and fungible, but otherwise it is useless.

The only thing not master planned about this commodity is what people will do with it. Since there are no other known uses competing for this commodity, some people think bitcoins should be used as money. Others think this is a highly implausible foundation for monetary policy.

----

All true, no politics!

Yes, I am talking about the hypothetical system.

The way I proposed the system, each time a block gets generated every validating node must accept or reject that block by validating the transactions and confirming the hashes in the block. In effect, the same work that is being done with the current system, plus the out-point hash checks. Since the other validators were already competing to generate the block, they already have (at least most of) the transactions.

As with the current system, if the transactions don't validate (plus match included out-point hashes) the other nodes will reject the block. If the block doesn't get acceptance by at least 50% of the CPU power, it doesn't make the block list.

So the presence of the hashes in the block list, signifies that at least 50% of the existing validators at that time saw and validated all the containing transactions and out-point hashes.

Therefore (barring hash crashes) if someone submits an antecedent transaction that matches an unspent out-point, it must be valid.

That antecedent's antecedent must have been valid as well, otherwise the antecedent would have been rejected. And so on and so on.

For that not to be the case, you have to postulate that there was a period in time where blocks weren't being validated against out-point hashes. But that's plausibly implausible with the CPU competition system.



If a client joined the network recently, it did so presuming that prior validators followed the rules and all pre-existing blocks are valid. (No one would join a known corrupt network)

Sure, in the current system, if transactions were never purged, a new node could validate all prior blocks for self consistency. But they still couldn't prove absolute truth. A bot net could have taken over and erased some transactions leaving "a new truth" and unhappy users. Equivalent to case 1) above.

In the current system, if transactions were Merkle tree purged then you have case 2) above. New comers must trust in the process. Anything missing, they don't need to worry about. Everyone must presume it was valid.

The unique thing I'm saying is that, if you have confidence in the bitcoin validation competition process (and we do!), then you really don't need "a 2) thoroughly deep block" to be very deep at all. Someone said in another thread that clients reject any changes to blocks more than two hours old. So we can have absolute confidence in all blocks buried 12 deep.

So if a transaction is unspent and buried 12 deep, we can purge all it's ancestors. They add warm fuzzies but no additional validation. We have to rely on them. There is simply no way to back up and change course.

After that, every succeeding block presumes all the preceding blocks are true. Otherwise it would be a fork and not a succeeding block. So for any transaction validated against out-points in a preceding block, if those out-points exist and are unspent, they must be presumed valid. If those are presumed valid, their ancestors must be presumed valid even if purged.

---
In the proposed system, exactly the same things are true.

If an antecedent out-point hash is unspent and buried 12 blocks deep, then it is absolutely unspent. Nothing can change that fact. No point in checking its ancestors. You can finish validating the transaction, cancel the in-points hashes and create new out-point hashes.

Interestingly, if an antecedent out-point hash is unspent and buried LESS THAN 12 blocks deep, then it is RELATIVELY unspent. Curiously, there is still no point in checking its ancestors. The only thing that could change the antecedent's validity is a branch swap to a longer chain. If an ancestor of the antecedent you are validating this transaction against was swapped out, this transaction would be swapped out as well.

It's one of those cheesy time machine movie plots. Someone when back in time and spent my ancestor. Now I don't exist!

=====

So what I'm saying is that in BOTH systems (existing and proposed) the only thing validators need to do is to validate that the antecedent out-points exist and are unspent (for the current block chain). The process assures that everything else remains relatively or absolutely valid.

The rest is just warm fuzzies.

-- PS --

I know this is too long and redundant, but I'm to tired to edit. :-)

It's a bit of a brain twisting idea isn't it. :-)

It turns out the notion of a cancelable notarization generalizes nicely.

For example this system is not limited to bitcoin transactions. Since the signed contracts are kept externally, with additional validation/notarization rules, you could easily implement things like IOUs/claim checks.

If someone gave you $5, you could give him a $5 IOU. Its IOU hash would be notarized into the blocks list (of hashes). When you pay them back you could have them sign the IOU for confirmation. Then have the notary insert an IOU hash cancellation. Then no one could show back up with a copy of the IOU and demand double payment.



I thought this too at first. But then I convinced myself otherwise.

It is really a matter of how much trust you place in the verifiers and the process of verification. People like the warm fuzzys that having every transaction available lets them trace the roots of their money back to its creation. However that is not required.

If you are confident in the process that validated the transactions during block creation (> 50% CPU agreement). And if you are confident the previous blocks can't be changed (you proved this). Then you only need to check that related out-points have not been spent. The security features remain in the block list and procedure, even if the transactions themselves are stored externally and the predecessors are not stored at all. You showed this yourself by proving old transactions can be deleted using the Merkle tree to maintain consistency.


True, privacy is directly related to observability. If there is a central party like a money changer, he can relate a lot of out-points. But if we get away from the notion that every coin must be traced back to creation, the observation horizons will be much closer.

----
It's really weird getting used to the notion that this coin is valid simply because the process wouldn't let it be included otherwise. But really, that is exactly how bitcoin generation works. The transaction has no inputs, but everyone decides the out-point must be valid purely because otherwise, it wouldn't be in the block at all. :-)

I agree that eventually the latter will have to be done. It's for the reasons you pointed out that my DHT solution has flaws. Curiously it's all a side effect of not being able to implement the former constraint.

If you allow validating nodes to arbitrarily ignore transactions you risk breaking the key requirement that all validating nodes receive and record all transactions. The current presumption is that all validators try to receive and record all transactions. If a transaction is non-uniformly delayed and missed by the node who completes the block, it is presumed that statistically the transaction would be recorded in a subsequent block. However, that requires continually rebroadcasting the transaction to assure it gets through.

Let's say throughput was right and there was an advantage to a node saying, "I'm only willing to take 5 transactions a 10 block period." in that case it still generates blocks that can't be rejected by others, but an increasing number of unrecorded transactions backlogs with each minimal block. This causes additional retransmissions exacerbating the bandwidth problem.

In effect you rely on unrestricted nodes to compensate for a problem caused by restricted nodes. So if the restricted nodes are causing problems and doing less validation and recording work than other nodes, why should they be rewarded equally for generating blocks? That seems counter productive.

It would be better to say, "record all transactions or you can't be a validator!" Less validators means less bandwidth usage overall. It also becomes easier to spot abusers.

----ps----

An zero knowledge proof-of-completeness would be for competing validators to reject a proof-of-work block if it didn't contain 99% of the known outstanding transactions.