When you say "they just have to install TOR", you're building the Linux experience, where you have to get countless random libs to make it work, and you have to be a wizard in his 20s. And then it will be as popular as Linux, 20 years later. It has to be the Apple experience: "Here's everything you need", "It just works", it has to be literally a button in the client, or normal people won't use it, because it's moonspeak to them. It's not easy for everyone. One month ago I had someone ask me to help with his computer, he typed the URL in Google and didn't even know Ctrl-C. But he owned a few buildings. This is the target audience, or it should be. He doesn't know TOR but he deserves privacy. The other problem is that then to support Bitcoin TORing you have to support illegal data TORing, it seems. Of course I'm pro-TOR and maybe I'm grasping at straws, but still. I'll address your criticism, it's great, you're awesome.

- Attacks are possible and surely always will be when it's a matter of sending through proxy. And I was indeed imagining a tracker of nodes, shared between clients, as it's complex enough, though it'd be less Sybil resistant than TOR. The goal is not absolute anonymity, but moderate. My thinking is that it's better than nothing, and enough for most uses. What I mean is that if you're Al Qaida or a big corporation you wouldn't use the fast synchronization idea, like you wouldn't trust TOR 100%, it's for casual use. Maybe the limitation should be more reflected in the name not to misled people, like 'partial synchronization', with what it entails. But I agree there'd be people trying to gather information from the service, because such information surely has value, so it's a sensitive issue, it can't be too easily exploitable. You convinced me that we could probably only query one address at a time. Maybe it should just go through TOR servers then, integrated in the client, but it's annoying to lose control over how it works when it could be adapted to Bitcoin's needs. I'm worried about address-linking. But I guess we shouldn't reinvent the wheel, though it'd be fun. For example nodes could be required to sign with an address owning bitcoins or having solved a block in the past to be considered favorite as relays in the tracker, and other nodes could be filled by mining pools depending on the node's hashrate, so there could be some Sybil but not infinitely. Tricks like that.
- I didn't think of that timing issue, good point. Honestly, I'm not an expert on TOR. I'd say requests for multiple addresses shouldn't be synchronous (there's time during block downloading; maybe we'd tick the addresses we care about and the rest comes later) and there could be constant dummy queries to hide, at random intervals. Apparently it's an actual strategy, there are many. There's little security in obscurity, but it's not a matter of absolute anonymity, because that probably can't be done.
- The incentive problem was on my mind too. There are people who seed torrents even on Pirate Bay, so I'm thinking many people will turn it on just to help or because they don't care or are too lazy to turn it off after using it, if it costs little to run, like for tx propagation. It'd just become natural that cryptocurrencies are slightly like torrents, clients participate. Many people would turn it on ideologically, because they want to help Bitcoin in the 'fight' against banks & co, but can't mine or run full nodes as it requires massive money or bandwidth. They'd manage transaction TOR-ing, while full nodes do the synchronization, it'd be a beautiful collaborative effort. Also, enabling the feature increases utility, the value of Bitcoin, so that's some minor incentive to have enough such nodes. But at worse it's 3mb every 10min, 3 relays x 1mb block, shared across all nodes, so 10kb/10min each with only 300 nodes, + negligible synchronizing data. Maybe 200kb/10min with fake data, 0.3 kbps + low level data. It seems like not much, and we'd set a speed limit in options. At worse, fees, but it'd be beautiful if it could just be free. Integrated proxying between nodes.
- TOR channels data constantly and massively, surely it's not the same, I think changing paths could be afforded here, though the maths should be done and I'm not the best at networking. But if it's the same path then the full node can link addresses too easily. Also I was mistaken, it would not be a path per output, but a path per address, as we'd query by pubKeyHash, so it's output-linking.

For the meta-argument, overcomplexity, if it's what it takes then it's what it takes. We want to trustlessly query specific outputs minimizing who knows whose is what. Maybe it's the naive approach, but there are probably not many ways to go about it. Fast & light clients with minimal loss of trust & privacy is worth a complex solution. And it'd be fun stuff to code, if you ask me, I wish I had what it takes. But if someone has an easy solution, I'm all for it. But this is what I would do, and if it was there, I would use it. In fact I don't have a client running because my HDD is full and I have like 0.7 BTC. But if I could just download 5gb from the chain, for the massive distributed PoW trust it gives, combined with multiple full-node 3rd parties telling me the 1st ledger hash is valid, it'd lighten the load on full nodes and it'd be just perfect for my use, as an attack combining both would have little effect and is very very unlikely. Unlikely enough not to bother with 21gb and counting.  
https://blockchain.info/charts/blocks-size?timespan=1year&showDataPoints=false&daysAverageString=1&show_header=true&scale=0&address=
Maybe it's not that much but it'll be like 100gb in 6 years at this rate. I can't afford it, there are just too many games and movies I can't delete. Worse comes to worst I'll buy a hard drive, but still.

edit: Andytoshi, I didn't understand the part about having to check every transaction in the future, and how it's bad and should be avoided or something. Isn't it already how it works? I should read the code it seems. I don't think normal nodes check the full validity, that's for full nodes, but they're tracking their own outputs in the block, aren't they? So it would change little, to my understanding. Download a ledger and update with downloaded blocks tx. It's just that instead of using the special case Genesis block with Ledger = empty set, it's a later block with non-empty ledger. There's a trade-off of trust for space and speed, but god knows I'd take it, it's surely unavoidable. And like I said, it could just be to speed up synchronization, then download in reverse to the genesis block if people want, for complete trust.

Thanks andytoshi, I thought about the privacy problems. The 1st is that the IP is linked to the addresses, the 2nd is that the addresses are linked together, the 3rd is that it leaks activity of the owner. 1 and 2 could be alleviated with a TOR-like protocol. A node asks a node to ask a node to ask a node to ask the full node about one of the output, with multiple layers of encryption along the way for each node, like an onion. And another path of nodes to different full nodes for the other outputs. It's some work but it could also be used to send transactions more anonymously. And I don't think bandwidth is such a problem because synchronizing is a rather rare event and it's only 47 hashes or so per output. For the 3rd problem, maybe by default we'd also ask for the balance of some others, to mitigate. This TOR thing would increase bandwidth but not for everyone. They could click for 'Privacy Mode' and enter this TOR state with other clients who did so.

I like his last project, bcflick, protection from hacking through TPM, very very interesting, take a look
https://bitcointalk.org/index.php?topic=154290.msg1635481#msg1635481

A great man, no doubt, an inspiration

We add a ledger hash in the block header

The ledger hash is the root of a tree of hashes, of the unspent outputs
When a client wants to synchronize, we send first the branches of his outputs, and the hashes of other branches, to reconstruct the ledger hash

So the client is quickly synchronized with his balance. He'd select a difficulty, the depth of blocks to download, and check the hash
When it's downloaded, it could keep downloading in reverse, to increase difficulty and trust in the ledger hash
It could be combined with the merkle tree chain idea to be even faster

I'm not sure how to organize the tree of hashes of outputs
But for example if there were 9 outputs, we could make 3 stacks of 3, and only send 1 stack + 2 hashes + ledger hash.
Does anyone know how many unspent outputs there are, and the size of the whole set? Can't find the information

I hope you don't mind I post this suggestion on the side, I find it interesting, let me know what you think



edit:
I did some maths
Let's say there are 10 millions spendable outputs
We hash each of them
Then we'll hash by pair
Then hash by pair of pairs, ect...
Binary tree fashion

There'd be log2(10M) levels to the tree, so 23

So if the user has only one output for his balance, then we'd just have to send him his output and roughly 23*2 hashes
*2 because for each level of the tree we need to give the hash of the unexplored path too, so the client can prove it hashes correctly

One output and 46 hashes is negligible data, so the download size would mostly be the blocks we require for PoW trust.

I understand the merkle chain would be very lightweight too, but I'm thinking that eventually even the light chain will be heavy (the amount of hashes to send increases linearly)
Whereas this allows fast synchronization even far in the future, by letting the user decide how deep in the chain he polls the ledger (and he can download to the genesis block to prove the integrity)

edit:
Ah turns out it's not new, I found the idea in the wiki, deep in the Thin Client page, so this thread is now about why it's not happening, I think it'd be a great change, and probably better early than later.
But I guess I can understand not wanting to change until it's desperately needed. But it's still another thing slowing adoption. And imagine if the 1mb limit is lifted one day.
I guess allowing such partial synchronization is a trade-off on many levels, but well it's an optional trade-off.

Now that it's cleared up I'll just reply appropriately to the criticism before going, I had forgot:


- For the hub idea (I recall it: we sign this new 3-passes transaction: 1st pass we sign off our coins to the hub, fee included, 2nd pass the hub signs coins to where we told it to send them, but using each other's outputs, 3rd pass we sign again. If the 3 passes are valid, it's accepted in the block). To make this transaction it would be done through clients or websites. You'd be organized with other people to sign this special mix of transactions together. When it's all signed it propagates through the network. Clients could organize it peer-to-peer, and there would be multiple websites/servers to organize it unlikely to be taken down all at once, so it's not at odds. Even if everything is taken down temporarily, it's not a big deal, it's just an anonymizing feature which requires no financial trust, only privacy trust. And like I said there may be a way to rethink the concept of hub distributedly, more properly, for also privacy trust, but one thing at a time. Also maybe the 3rd pass is too 'bloating', I'm not sure. If it's a problem there could be a limit of such transactions per block, and they'd compete by fee. Anyway, it's a minor idea, I'm not sure of the usefulness. And maybe these dark wallets solve anonymity, I didn't look into it. I'm not sure I like this idea anymore, too bloaty, unless it's used to send to an anonymous wallet, which transactions are transparent or anonymized differently. But there are already exchanges for that.

- For side-chain price stabilization, it would be done with vote in blocks, so it's not at odds with the distributed nature. There would be a price tracker, but since we could veto its input during the delay, it's not a vulnerability. Unless attackers take down the whole internet during the delay. Even if they do, the effect would be slight and mostly reversible; and there can be countless safeguards. We can even vote to have no input, if people prefer a static supply. Anyway I'm not sure of the feasibility of adding new coins in millions of different addresses at once. But I think it should be doable if the peers agree precisely on how balances are altered. Just to be clear, I agree that Bitcoin itself should stay mostly static as it is and only ever have 21M coins.

- For the fast synchronization idea, we'd rely on 3rd parties to download a ledger which hashes according to the ledger hash put in the block, so we can download the chain in reverse, with the desired difficulty. It's not a vulnerability because there could be multiple such websites, it could be torrented, and it could be a feature of clients so we download the ledger from other peers. I admit I know little of UTXO, it seems the wiki is lacking the information, so I'm not sure about the nature and size of the ledger, and of this ledger hash idea. Maybe if it's too big, hash in a tree fashion the outputs, and send those of interest in priority, like the part with the user balance. We send to the user his unspent outputs and all the hashes required to reconstruct the ledger hash. It should synchronize fast, since it's logarithmic. I think it should work, I like this idea. But I tend to be too hasty, and lazy. There's probably some flaw.

Anyway, even though there is talk of 3rd parties, they are optional and not vulnerabilities. The problem is I'm not sure about the technical feasibility, I don't know the codebase, and don't code much, just had a period thinking about all that for a few months.
So I wanted to share with more professional people here just in case anything is workable. I had almost forgot to come. It seems it may have been better I had. Oh well. Sorry again, cr1776, you stepped on a landmine. I'm explosive these days.
Thanks to the intrepid readers. My favorite. People who read that much can only be good people. haha
And don't mind what I said, we're all estranged brothers, and a few sisters!

Goodbye

Well, I may be checking until it reaches page 2, in case people like some ideas, that there are replies, questions, criticism or whatnot. But I'm happy with my suggestions having just been read and considered. Maybe I'll eventually post one idea more concisely, on the advice of jonald.
I can tell you, I have some very low social skills

I did post the fast synchronization idea here: https://bitcointalk.org/index.php?topic=757110.0

Alright, I may have been too harsh. I tend to judge too fast, I removed. Sorry, cr1776. Nothing is black or white. You were a bit rough but it's minor and some of your white might be brighter than mine, I don't know you, so I can't judge you really, I was just making a neurotic fuss, maybe paranoidly. I appreciate you contribute and cared enough to give feedback. It makes me think it's all the feedback I'll have. Oh well. And of course we're both human vectors. You can dislike me it doesn't matter. Just be kinder. There are hypersensitive people around, with tiring lives and a high sense of justice. I spent a lot of time thinking about Bitcoin just to help against the risks of fiat and the centralized press, while I'm too poor to own a whole bitcoin, and I got handled roughly like that, it's tiring. If my ideas are worthless then at least I encourage you all to be more respectful. It's not good to discourage the shy and weird to contribute, whatever people may think. Because ideas last longer than opinions. Also you should justify yourself more, generally, especially in first post, because people are biased by it. Anyway, I'll leave it at that, I'm tired. Think whatever of my ideas. I noticed a problem with the distributed hub idea today, I had it just before writing and I'm too hasty. Also I'm thinking maybe the press shouldn't be totally on free market, but it's interesting to be able to distribute the supply with a token. The multidimensional economy, I found an use for it, for example there would be a dimension for people who like Education. In the dimension, we artificially inflate the outputs (of the sidechain, not bitcoin) of accounts of Education budget. Then for the people who did that, these coins would exist, but not for people in other dimension. That means that people in Education can spend these coins in businesses and with people who are pro-Education. So it doesn't inflate the money of everyone, only the concerned. There could be a map where it shows businesses who accept this kind of coins. And there could be a dimension Education+2 for the even more generous. Or a dimension war, and only people who want to fund war would consider the extra war coins as something to work for. These are discrete dimensions but I'll try to think of something more fluid. Basically I was thinking that we don't need multiple currencies or whatever, but it should all be one currency which is highly adaptive. This is why I'm thinking we should be open-minded about banking contracts. Because it's better to have banking inside Bitcoin than outside, if people need it. I don't see the cost of having the feature. Either it's useful or it's not. I think compromise is the path. If it's useful to people, they'll just stick to fiat banks, when Bitcoin could totally replace it all. It doesn't have to be forever we can try to figure out instant trustless transactions without 3rd party on the side, if it can be done. Also, I forgot an idea, we could pay in a store without a smartphone or device if Bitpay or whatever makes a daemon program that runs on home PC with the wallet and will sign the transaction when it receives the locking password (then it could return a word/picture you have associated with the merchant in the daemon) then the one-time password, ect... You get the idea. It's not very practical as is, but it's another idea to think about. Well, that's it. Don't mind the drama. Or mind it. Whatever. I'm too tired to be part of it. What matters are ideas. Now I'll leave you alone because there's a high probability I'm not wanted. Frowns all around. I can only imagine the moderator's frown. I don't want to see it. Also you have pretty much all I had to contribute. Far-out unproven ideas, but well it's something. I'd really consider asymmetric multisig, and take a look at the F idea. Spending with data2 such that datadata2 hashes under target. I think that's cool, using stateless work as time for in-blockchain timelock, but maybe it's not new, I'm a 1yo novice to all that stuff and not up to date with the details. Also I'm not sure how to tie the idea to global hashrate, too tired to think these days, these are old thoughts I had on notepad for months. But I'm sharing before I forget just in case it's actually useful, but seems not, it seems I may have some form of grandiosity. On top of all the rest. Oh well.

And thanks for the advice jonald, I'm working on that problem, but I'm out of juice and time as of now.

My experience is that people don't flock to good ideas. Centralization is not evil, it is a tool to use, it's neutral.
You dismissed my 3rd party idea which is checked with a hash like for the MD5 checksum of bitcoin-qt's wallet.
You send bitcoins with a 3rd party wallet on a 3rd party computer through a network managed by a 3rd party.
It doesn't matter. What matters is trustlessness. Anyway, I don't have time to revisit. I'm posting what I have.
I'm a newbie so it's surely useless, think what you will, but be polite and don't build yourself an echo chamber.

I forgot my idea for faster synchronization, it's to add a hash of the ledger itself in the block header, every X block, then we download the difficulty we want, for example the last 20 blocks, check the ledger hash, and there'd be full nodes or 3rd parties websites who supply ledger data + hash to prove the data. Or add the whole ledger instead of the hash, every X block, but it takes more space. edit: later I detail how the ledger hash could be the root of a tree of unspent outputs, so we'd send the user outputs first and the other hashes of the tree, it'd synchronize fast

Now I think it's mostly complete, my semi-amateur perspective to help against all the big problems, I hope any of this is actually helpful, though I'm not holding my breath. Whatever, we do what we can.

Goodbye

Also maybe the hub could be distributed, I mean 10 person sign, and they act as hub one after another until the funds actually move, so to know who signed to send where you'd need all 10 to comply

Ah, I forgot two

G)

Transaction chains, I heard about it, so maybe it's not new, but maybe it was another idea.

Basically an entity is in charge of building a numbered chain of transactions and can redeem them all in one block, in precise order. So maybe there could be fast and precise in-blockchain exchanges. You sign the chain of previous transactions. The protocol would have to accept this kind of data structure.

H)

I had an idea to make transactions more anonymous, using a sort of hub.
It's an entity with a special kind of transaction too. You sign a promise to make X bitcoins available. Other people do the same. The hub then signs a promise to send coins where you want to send them, using other people's outputs. You sign again if it's correct. And then it's redeemed. The hub is only trusted with the privacy of how it has been switched, but it allows to send coins using each other's outputs, so kinda anonymously.

Goodbye

Hi I'm just an enthusiast and I had some far-out ideas I wanted to share before I forget, if it's of use to anyone.
It's overly ambitious, trying to tackle big stuff, and blurry and probably flawed. I lack time/skill/smarts to get more into it, the technicalities, but I leave that there for the forengers. Then I'll be on my way.

A)

So, I had that idea
It is a 2nd token to trade, in the blocks
If you own X% of it, you receive X% of the generated supply

I'm not sure if and how it can be done, but I'm thinking about 2 static outputs for each address with shares, one coinbase and one stackable, if it makes sense

It is my favorite idea, the abstract distributed money printing press, fancy term but I like it, we just distribute the supply through free market

B)

Anyway what it could also do, is that if we want to remove coins, then it removes X% from the associated wallet.
There could be price stabilization done through creating and removing coins from investors of this 2nd token.
I understand people don't want to create more bitcoins, and even less remove, to manipulate the supply.
I was thinking about maybe combining that with sidechains.

When creating a sidechain, everyone contributing Y% bitcoins get Y% of the subcurrency and also Y% shares of its printing press.
Then it adds and removes coins through the shares, to stabilize. Dynamic supply inside the fixed supply.
I think that's interesting. That's one thing. The problem is price input.

It could be decided in the sidechain contract. I suggest simply a vote by wealth, to elect a tracker IP.
Another possibility is giving extra vote power to those who created the sidechain.
For example imagine if Europe made a sidechain then every country would have a key to vote.
But they don't have to have all the power. It could be half power to creators, and half by wealth.

Also there would be veto, on top of vote.
The effect on supply from price input is delayed for a time, during which we can veto, with the same key as the wallet.

I don't know if vote by wealth can be included in the system.

C)

I had another idea for price input. We could use the block hash as random seed to select from a pool of jury, then pay them to tell the price, but only if they all agree, like Prisonner's dilemma. And the next juries can veto the previous. And veto by wealth if all the pool is corrupt. But it's weaker than a closed system, and it needs something to form the pool and hide the votes until next block. I don't like that idea much, but I keep it in mind, could be useful.

D)

I also had an idea of multidimensional economy running in parallel (phasing). Can't find less fancy words.
For example let's say we do vote by wealth, with amount of coins being the weight of the vote.
There could be someone with 51% coins trying to harm the currency. So what we do, is that we collectively decide to ignore his account.  
We create a parallel ledger (only the difference is stored, technically) where the coins in his address don't exist anymore. But any transaction done in an economy is done in all compatible economies, it's not totally split.
The disabled account can only spend his coins in the 1st economy. If he sends them to someone, that someone has a warning that says these coins will only be spendable in the first, and maybe it shows a % of how many addresses are compatible.  
It is multidimensional economy, it gives power to the people over the ledger.
When a dimension/phase is created it shows the change, and a description of the reason. It could be more complex than just about accounts.  
There could be entities trusted with judging them, and we auto-follow who we want for convenience, but if it's abused we can always switch back. The people is the judge.
Basically, we give power to the people over the accounts of the people. It's not centralized, it's democratic. It's my newest idea so it's a bit rough, and maybe not feasable or interesting.

I guess that, even uncentralized, whether the people should have access to the accounts of the people is an ideological debate in itself.
And I guess it'd be answered with a big no, around here. Oh well. Anyway I don't know if it can be done or if it means anything.  

E)

You know what I think Bitcoin is lacking, it's banking contracts, trustless banking, cryptobanking. You think Bitcoin is there to eliminate banking, but you don't really hate banking, you hate the current implementation of the concept. But the concept is fondamental. If Bitcoin had banking contracts, then it would mean something different, even though it would be the same protocol. Banking is a protocol to trade instantly between peers who trust a 3rd party, by lending it ownership. I'll tell you what's the problem currently with Bitcoin. When you send coins to a pseudo-bank or an exchange, you have to GIVE them the coins, give them ownership, because the system lacks what you really mean to do. And what you mean to do, is send coins in their wallet but retain ownership, and that's banking. But you have to give them the coins, because the protocol lacks what you mean to do. Banking means sending coins fast with 2 signatures, but slow with one (prosecution). It means asymmetric multisig, where one party has more power than the other, it's not equal. This is how there should be Bitcoin banking: if the 2 parties sign, then the transaction is instant. If only the owner signs, then the transaction has to have locktime, or it's not accepted. And then people don't have to trust a random peer not to double-spend, they only have to trust the 'bank', the signing entity. And yet we retain ownership of the coins, through the forcing-out mechanism. It's better than current banks because it'd cost less and be more efficient and more configurable and less hampered by law, it could be automated through many websites where you'd configure the way you want it to sign. It could even be hierarchical, with one bank (like the home computer) relaying to the superior 'bank'.

I had another related idea where the bank could have an account which can only withdraw with extra long time and we can prosecute money out from its output by contract if it tried to double-spend. We show proof of double-spend with its 2 conflicting signatures and can claim its outputs.

But I'm thinking that maybe instead of just having contract through script, there could be contract as data along transactions, which limit the power of the script. Because if it's just in the script, then you have to stick with the rules in every transaction, when we could just put the rules in one block then in all subsequent blocks the outputs' script has to follow rules according to the contract, and it's enforced by design, I mean the block is just not valid if one of the transaction within doesn't follow the rules in the pool of contracts. But I don't know if it can be done, or if it's a good idea. Maybe people really want everything to be in script.

F)

The last idea is a type of transaction putting 'proof-of-work' in the script, for in-blockchain timelock, or escrow exit
Basically, the output has a target + data in its script, and to spend it you must supply data2 such that datadata2 hashes under target
Some people would solve it faster than others, but it'll always take some time. So it allows in-blockchain escrow. I wrote it but never used a stack language, so take it with a grain of salt:

The script logic is:
if (check(signPayer) and target > hash(data+data2)) true //escrow safety exit
else if (checkmultisig(...)) true //standard escrow success

I did the code for 2-of-2 but it doesn't matter.
Note: I concatenate data/data2 with (data OP_TUCK 32 data2), not sure about that.
And I use LESSTHAN to compare hash/target, but it's only for integer. Anyway here's the script:

1) In the previous transaction, sending coins in the escrow:

- Right-part ScriptPubKey, with rules to spend:
// IF/ELSE for two spending cases, using op_depth as condition
// Case A: there are 3 left stack items in scriptSig: solution hash + key + sig (for escrow exit)
// Case B: there are 4 left stack items in scriptSig: 0 sigA sigB OP_2 (first part of multisig)

OP_DEPTH OP_EQUAL OP_3 OP_IF // If Case A
   OP_DUP OP_HASH160 <payerPubKeyHash> OP_EQUALVERIFY OP_CHECKSIGVERIFY // check the signature, then discard the 'true'
   OP_TUCK 32 <problemHalf> OP_HASH256 <target> OP_LESSTHAN // check the solution, then end CaseA with lessthan's true
OP_ELSE // Else Case B
   <payerPubKey> <arbiterPubKey> OP_2 OP_CHECKMULTISIG // standard multisig
OP_ENDIF

2) In the current transaction, spending from the escrow:

- Usual ScriptPubKey, giving coins to an address:
OP_DUP OP_HASH160 <hexAddressToPay> OP_EQUALVERIFY OP_CHECKSIG

- scriptSig if spending with the solution:
<solutionHalf> <payerSig> <payerPubkey>

- scriptSig if spending with 2 signatures:
0 <payerSig> <arbiterSig> OP_2


But maybe it's not new or not needed.
Anyway I'm no expert but I hope this was interesting at least in some part to more experienced people.

Goodbye

Thank you for the feedback!
I agree that it is a nice feature to be so protected.  
But I'm thinking that actual Bitcoin block chain wouldn't be the currency but the stock anyway.
Maybe we could leave Bitcoin as it is, as people want it, with non-fixed supply and without taking shares after bankruptcy, then try the currency block chain aside, if we can fork Bitcoin. It'd be flawed but harmless experiment.

Even if it's an added vulnerability, I still think that a stable currency can't be a closed system which doesn't evolve according to demand. We're all pulling on the network's value, it needs to stretch. Price is easiest way to gauge demand.  

To input the price, it would be done when miners are solving a block. They put transactions in the block already, so if they manage to solve it, they send a query to price trackers, then put a special transaction in the block to let the network know.
Then other nodes check that it is indeed correct before accepting the block. Also price trackers don't have to be such a centralized weakness.
It could be 10 or more different servers specified in the client, using weighted averages of average price on all exchanges by volume, ect... Or forget the tracker idea, miners do it themselves maybe.
If something is wrong or strange, then don't change the number of coins until it's solved.
It is true we can never trust it 100% and it approximates, but maybe it is still worth it?

I think people should consider this problem because volatility is the strongest reason why many people are not interested in Bitcoin or crypto in general; there needs to be a solution, even if it's not this one.

I didn't read much about Colored Coins yet, but they seemed interesting. I'll take a look when I have the time to understand that idea, thanks!

Well it's true I should have posted in "Alternative Cryptocurrency" maybe, it's just that I was thinking that it's better if it's done through a currency which is already widespread.

But yes I guess it'd have to be experimented with first. I'll delete shortly if I can and adapt for the other board I guess, when I'll have time!

edit: Well nevermind, I can't delete my own thread it seems. If a mod could move it that'd be nice. Thank you. I have to go, goodbye!

Hello everyone!  

First, I love English but I'm not English; so forgive my messy sentences.
Second, sorry if this is too long... But I made images and a tl;dr below!
And third, sorry if this is no white paper but I am not Satoshi or a PhD.
I am an ex-hikikomori who can only loosely hand-wave my way around.  
Take this with a grain of salt. It's surely stupid nonsense, inapplicable.

Especially since I know little of the tech. Please ignore once that is settled.

You know I have to share just in case. Alright! It is an idea in 2 or 3 parts.

The first part I'd like people to consider is about stabilizing price per coin:

If demand (~price) changes by X% beyond volatility, we change the number of coins (~supply) by X%.
And we do that directly in the wallets, through the ledger.

This stabilizes price per coin.

(Just knowing it can happen, greed acts as a stabilizer!)

I think it can be done as wallets hold keys to access coins from the network, not the coins themselves.
Number of coins is in the ledger, it is distributed, so we have control of supply as long as nodes agree. Don't we?

Imagine there were only 3 gold nuggets in the world, worth $100 each.
If you destroy one then they'd be around ~$150 each, as it becomes more rare for the same demand.
And if you create gold, then value decreases. Except we can't create gold as it has intrinsic value (it'd be creating value out of thin air).

But the value of Bitcoin is not in the coins, it's in the block chain and the nodes supporting it. We can create and remove coins as we please, and we can do it fairly.

It does mean removing the 21M supply cap; the elephant in the room holding Bitcoin back.
As there is more stuff to buy, we need more currency... For a stable price. It can't be helped!
Bitcoin can be volatile and scarce virtual gold, or the stable currency of the world; not both.
Even the Nobel Prize says so. Bitcoin is valuable as it is, but it could be even more valuable.

Well, it can have fixed supply, if it's not the currency but the 2nd block chain of what I'll explain.
Because we need a fixed supply for the 2nd block chain, as we'll see. But not for the currency.

So the first point was turning price volatility into supply volatility... But there's a second point!

Don't do this for all wallets, as non-investing people would get upset when coins are removed, and there'd still be global hoarding.

We need the number of coins to add/remove to be proportional to your share of another block chain, and not proportional to the amount of currency you own; this kills hoarding.

Also, it makes sense that if the whole currency loses value, someone has to take some loss.
But we can give liquidity to that risk... Through the owning of shares of that 2nd block chain.

By owning X% of it, X% of the generation/destruction required to stabilize goes through your wallet.
The money of normal people is then beyond a safety buffer: the money of investors.
They feel better about buying coins, or accepting it as payment.

Because as the 2nd ledger is public, and links stock-wallet to currency-wallet, they can know exactly by how much value they are protected.

Here are three use cases to explain my view, and for people to discuss and surely disagree:

A) Current Crypto system:
"I want to buy X, but if coin value increases by 2%, I could buy more later..."
I may buy but the probability I do is lowered by greed --slow economy.

B) Hypothetical supply-adjusting currency without the 2nd network:  
"If I have 1000 and I expect a 2% increase in value, I should postpone buying til I get 20 generated currency. "  
Not good --currency stagnates uselessly. This is not saving to afford X. This is waiting for others to buy coins before using yours.

C) Now with this dual system:
"If I expect a 2% value increase, I buy shares if the price is worth the generated coins, or too bad / too late, I buy other stuff instead."
You see how that person decided to use currency even though he knew people will be buying coins soon... This is added value.
It happens because a rise of currency value is transferred to the stock coin's value, you don't benefit from owning the currency.
If you buy shares, then the person you traded with needed currency, unless trader; normal circulating money; it is not hoarding.

In the end: "How much currency I have, had or will have is irrelevant... Might as well buy right now if I want to."  

Basically, we split value in two parts: crypto-currency and "crypto-stock".

There is a lower bound of value at which investors go bankrupt and the currency loses stabilization mechanism.
But this can't be helped! There is no magic. I still think a currency with this stabilization would be very valuable. Don't you agree?

The core of the idea is: We have 2 block chains. We transfer value of one into the other.
We can because enough people own both. Total amount of value is the same.
But one part is stable, and the other acts like a stock with dividends.

We can imagine multiple coins linked to the stock thing one day, as something expensive is resilient to stabilizing something cheap.

The weak point is whether reducing supply would have a strong enough impact to raise the price properly. I don't know.
We will need owners of stock to correlate strongly with people selling currency on exchange.
But I think they would, as they are the source of supply.

Also the amount of value lost/created with coins has to be equal to the amount of value actually entering/leaving the market, to limit manipulation. It wouldn't be just about price but volume and all, or decided by economists maybe one day.

[Suggestions for the dry technical part: I wonder if we could fork the current block chain, give it a new name; it'd have same wallet addresses and keys but different client, and it'd evolve or be traded separately.
Then the nodes of the currency block chain would use price trackers, bitcoin-stock, and some smoothing formula to update currency wallets every X block appropriately.
At first, everyone would have as much share in both network, so they'd gain/lose value as usual. But then, they'd start trading their shares.  
If an investor goes bankrupt (lacking the appropriate currency to destroy), he'd have to sell his shares, or he starts losing %.  
Also a wallet created in one fork has to be created with the same address in the other, or it would be a mess.
Either that or we need to be able to store data in both ledger (address of corresponding wallet).
If we can do this fork thing, then current Bitcoin block chain would be bitcoin-stock.
Ideally we make a new client so there's no more mining Bitcoins, it's all fees.
If I own X%, it stays the same %... So I get back my loss if it rises from a dip.
And we multiply wallets to be at 21M already or a factor of 10 for easy math.
Multiplying would be a kind of transaction with no input/output, just amount.
While nodes verify the block is correct, they check transactions --this one too.]


Here are two pictures I made to better understand the general idea:




But it is not enough to do that, you can't just give the option to be an investor freely, or they'd all flee when the price falls.
Being an investor has to be a real investment, which comes at a price. A price on the free market... Through a second coin.





tl;dr:
Merchants and cautious people buy the currency not the share.
Investors/owners of shares win or lose currency appropriately.
But hoarding of the currency is useless, and the price is stable.
Well, stable as long as the investors can support it... No magic!

That's it. I'm guessing this is flawed, as there are many intelligent people/professional developers in the BTC community, I'm unlikely to be first to propose a good idea.

Sorry to be so lame, but as a lower class, lifelong social recluse, BTC donations are appreciated if (and only) this turns out to be more than nonsense and help crypto:
1thxd4KJLhBMcfCYaVKYMA8Atv3Dfx9hb

But I have a feeling it's a stupid idea and doesn't work, or it'd have already been done... I felt *eureka* when I had the idea but it'd be too simple if it was just that.  

Sorry if I waste people's time... I'll delete and take the shame, but I have to share. I'm hoping that at least there are interesting bits to inspire more polished ideas.

There must be ways to work on the idea where we don't get value proportionally to the amount of current currency... It'd help, I think. Or maybe not, I don't know.

In any case, I encourage people to think about improvements!

Because we are all the engineers of the future... Haha

Well... We try!

So please don't be mockful of my efforts... It's surely ridiculously wrong to some, but to me, it is the best of me. Took me loads of time, and I should be sleeping.

But what's important is that we beat on, boats against the current...  And try as we can (yes I did read it in English! Haha).

Thank you for your time, attention and consideration.

Goodbye!