Read the sub-currency contract written by Gavin. Basic outline is there. As a contract it should work if we polish it up a bit and tighten some screws in the contract. IMHO, herein lies the problem beyond just that contract.
Say, Alice decides to want to buy some of these GavCoins. She goes to GavBank and bought some 1million of GavCoins for $100. That's fine. How is she going to get those coins? To a wallet? To whose wallet? Alice? Alice hasn't got a GavCoin Wallet. There is no GavCoin wallet as it runs on ethereum. And so, it must be another contract. Let's call this wallet GavCoin Wallet contract. So how does this GavCoin Wallet contract work? I guess it is a simple in/out contract. OK. Let's assume it is a simple in/out wallet. So far so good. GavBank deposits that amount of 1 million from the 10^18 coins it has into Alice's GavCoin Wallet Contract.
Bob comes along and sees that Alice has a GavCoin Wallet Contract and tells her that she was silly to have signed up. Bob shows Alice he can make her another million of these GavCoins into her GavCoin Wallet Contract for free. Bob sends 1 million more GavCoins as a Data parameter and Alice immediately sees 1 more million of these Gavcoins in Gavcoin Wallet Contract balance.
Alice goes back to GavBank and complains that there is a security hole. Anyone can create a GavCoin Wallet Contract and send free Gavcoins to this contract. Where is the protection?
OK. Perhaps we have a work around and record in GavCoin original contract a table of verified and certified Wallet Contracts. So, there appears to be another contract where every GavCoin wallet must be "approved" before it can send to another wallet. Herein lies another problem:
The new contract is just a long list of Wallet contracts that are approved. If we base it on a steady state assumption (based on facebook's number of users) of 1.2Billion of these wallets around, we will need to have a storage of 1.2Billion contract addresses of 20 bytes each, i.e., 24GB of contract data. The ethereum transaction cost will be colossal just to store these addresses. An average transaction of once a day of 100 bytes for each of these users will lead to 1.2TB of storage space a day for transactions just for this one application.
If there are just 10 of these instances with 1.2B users, the whole ethereum will implode. It just does not make sense.
Unless I am totally wrong in the foregoing, ethereum is a very novel concept but for deployment, sadly, it appears to be nothing more than just being academic.
0 ·
Comments
My participation here is experimental, although it is real. I am typing real words, I am explaining real things that are in existence at this time, but in 3 months from now, all of it could sound like stone knives and bearskins. The Ethereum printing press, it can print a piece of paper, but it will NEVER print an entire book, and bind it as well ... Sound familiar?
Ethereum is not even "Alpha" release code, it's huge, and it is experimental.
The level of abstraction in every line of code we might produce with LLL is immense. For Gavin, for Vitalik and others who have been writing the core codes for the client, writing the Bytecode implementations, writing the LLL code ... so we can write contracts, their ability to abstract many things, rapidly in their minds so that it is "trivial" to them, to see an alternative coin being produced by a few lines of LLL contract code, these are the things that set core developers, (inventors, creators and founders), apart from scripters, and users.
Gavin and Vitalik do not find it fruitful to express some contract completely, and fully and follow it and build upon it because the core codes they are writing, the Bytecode protocols they are writing, the LLL code conventions they are creating and the javascript bindings they are creating are changing rapidly.
They don't want to paint themselves, and you, and the rest of us ... into a corner.
So some functional, usable, alternative coin contract, full fledged with minimal if no abstraction is a waste of time at this point in development. There are those of us who see the creation of alternative coins on the Ethereum blockchain instantly in the few lines of LLL that Gavcoin presents, and there are those of us that must pour over those lines of codes, and days later we say "AH HA!", and then still more of us that look at the codes, throw our hands up in despair, come back a week later, seem to understand, come back a week later and begin to say "wow, cool", and then even more of us who still do not understand how an alternative crypto currency is created in these sparse, low level language, lines of code.
Alt coin "contracts" at this time are incredibly abstract, but to some ... they are trivial, obvious. And perhaps several months from now, what they have written and marveled over ... to them ... will be drivel, will seem silly, awkward. So they don't want to fully flesh out and give "proof of concept" in totality, for some minor, tiny part of Ethereum. "Proof of Concept", "Proof of Product", "Product BETA", and then "Product". Where are we on that development line?
When we only had command line DOS and no "Windows 1.0, 2.0, 3.1, etc ..." Would we demand that some person who expressed a proof of concept that "windows interfaces" could be used on a computer, then provide us with an operating system that functioned in windows, in order to prove their abstract, hypothetical proof of concept ... Yes, some of us would, those of us who want the product and are not writing the code to make that product, and that's where you are, wanting. Patience is a very, very powerful skill and without it, for some time, you will be very disappointed with what you might find in Ethereum.
Would we say to some DOS programmer offering proof of concept of a windows operating system that they provide the windows operating system, full fledged and fully functioning to then validate their "proof of concept", or is the proof of concept enough to then abstract in our own minds the visual of windows and mouse clicks, and tabbing around in that windows environment? For some yes, for others difficult, for even more unlikely, for many never.
To say that the current set of contracts, and the layers of language which are used to produce these interactions on the infant, embryonic Ethereum blockchain are abstractions ... and the result and product of some of these contracts as some true or false set of Bytecode values, again, which can be abstractions is truly an understatement. Plans are that the first client for Ethereum will be released perhaps in October, that's a very, very long way off in Web development time.
Everything in Ethereum is based upon, it has value because, it leverages the core principle math of bitcoin, that there can be no double spend. What Ethereum will finally be, most of us do not even know at this point although Gavin and some of the core developers might know better, what they don't know, ;-)
It's all a grand abstraction. So either all of the bright, highly skilled, hard working developers are bag of rocks crazy as shit ... or ... it is some other person's perspectives that are lacking.
A potential answer to your more specific question:
Imagine you send 1 ether to a contract, and that contract then creates, (with the code of the contract, the LLL code), it creates an area in the contract storage memory, (in the persistent blockchain storage area(s)), and that area of storage associates your Ethereum account address with a value in that area, say, a number, 100.
contract.storage(0) = YourEthereumAddress
ReferencePointerTo.contract.storage(0) = 100
So your Ethereum address is now bound to that value of 100, they are somewhat like a pair of data entries in a dictionary that refer to the same main word, a tree of sorts, leaves belonging to the same branch. And that "100" can be 100 anythings, but for the purposes of this contract, it is 100 "ThisContractUnits" ... or coins.
That number would then be the number of "alternative currency" units that were created by the contract that received your 1 ether currency unit, and are now associated with your, and only your Ethereum address. So you own those 100 units created and stored by the contract.
Because you sent your 1 ether to the Gavcoin contract, and it might have done this ... let us be abstract ... they will be called "Gavcoins".
If you sent another 1 ether to the Gavcoin contract, the contract would receive a transaction from your Ethereum address, and the contract would append an additional 100 Gavcoin, it would add that, to the Reference PointerTo.contract.storage(0) area of persistent memory in the blockchain, the contract's data area that is referenced by your Ethereum address, the address from which you sent the transaction to the contract.
So then, you would have 200 Gavcoins. And the Ethereum account address associated with the Gavcoin contract would then have both of your 1 ether, (2 ether total), added to the balance of that Ethereum account address.
So HOW ... are you going to transfer those 200 Gavcoin to another person in exchange for 5 ether, and thus you profit in the sale of that Gavcoin? You are going to use a contract that CALLS to the Gavcoin contract and withdraws your Gavcoin to the other contract and then associates it with the Ethereum address of the person that purchased the Gavcoin from you ... but HOW ... is that contract going to work?
And how can we even discuss that type of contract at this time, and have some significant confidence that kind of contract could be written, and exist, and work? Because we know enough about all these things, all the Ethereum things to draw that kind of contract in our mind as an abstraction.
And I would bet you that 200 Gavcoin ... that Gavin, or Dennis, or Vitalik could write that contract at this time, but you could not afford to pay them for that work, because you don't have the Gavcoin to pay them with ... yet.
BUT ... in 4 months from now, all of what I have typed could be absolutely, totally and completely wrong, it could have absolutely no bearing on how Ethereum works at all, and the question as to whether Ethereum could, or could not produce an alternative coin would seem quite, quite trivial.
By the way, my fee for this type of consultation is 100 Gavcoin, of which you may have none, so consider this to be a valuable freebie, ;-)
The point I am making is not about what you said but more so the extreme data load that it will create on the block chain that may render it useless and also sky-rocketing the transaction costs, which after all, should be a function of data storage as well.
Now, it is true that subcurrency example does not feature exchanging 'ethers subcurrency units trustlessly'. I.e. using only the contract, if Alice wants to buy GavCoins from Bob, one of them will have to trust the other to pay.
There are multiple ways to use a contract to solve that. I think Joris Bontje(mids106) i working on one.(not sure what his approach is) I wrote one where both sides can configure a contract to send a (arbitrary)transaction, if provided a secret. One side can do so without revealing the secret by using a checksum of the secret and the other will then follow. Then the side with the secret is forced to reveal the secret to get the transaction they want, allowing the other side to get theirs.
My approach at least does involve a contract which you put between you and the subcurrency. The problem is that the subcurrency uses the sender address, and you cannot do the things contracts can do with your public-key-address. There are a bunch of features you might want which may(..or may not.. i dont know how we will organize things!) cause you to do things via a contract, instead of via your public-key adresses. I have at times called these satelite-(of a person) or wallet-addresses, now realize neither is good terminology!
Finally, so someone creates a subcurrency... It is worth anything? Defaultly, i do not think so. I think subcurrencies are more likely be be used as 'stock' that may get a divident and/or rise in value, co-operative shares, for experimenting with UBI, or one of many things that add some feature to the subcurrency that gives it value.
The checksum adds another layer (i.e., more cumbersome to use) to the user and as we all know, convenience and ease of use is a priority for market adoption.
There are some workaround as has been suggested here on the management of the subcurrency, but in the end, the workaround will either require massive storage outside - which defeats the very purpose of using ethereum as a decentralized framework in lieu of existing technologies that can already provide the solution of a subcurrency without ethereum - or within ethereum.
My worry is still the careless planning by the masses (i.e., the myriad of service providers leveraging on ethereum) and therefore tremendous data loading on the ethereum "network storage".
The number of transactions and therefore storage could lead to a situation where it is inversely proportional to the number of miners, thus leading to a halt.
On the flip side, it should also not lead to higher transaction costs.
I believe the ethereum development team is well aware of this and my wish is that there is already a solution hovering in the back burner that shall be crystallized at a later date lest we head to a wall in the not too distant future.
Dont quite know what you think the problem is with storage. Subcurrencies dont take that much more storage than ethereum(or bitcoin) balances take... The solution i mentioned to the lack of trustless mechanism(the subcurrency itself could provide such mechanisms too of course!) does not require massive amounts of storage either..
Probably you mean the storage cost problem in general, do mind that it costs you money to store data.. Afaik currently there is a single fee, and that is problematic... Maybe in the future there will be a fee-per-block, and mechanisms for people to ensure they can keep their contracts alive. Combined with a good way to set the price, this might solve the problem. Main concern remaining then is uncertainty about future prices per block being prohibitive..
I agree, usually there is a solution/reasoning in the back or front of their heads when you think about problems/useful features.
One needs to be able to send using the address and to receive from that address registered in the contract, i.e., a closed loop solution, which is neat and that's ok.
But when we escalate to 1 Billion users with say, 20 bytes for the address and 32 bytes for the balance, we have roughly 640GB worth of data in that one contract to be carried by each miner. Add that to the number of transactions and further have 10 more instances of such type of contract, we are left with a huge data carrying cost.
I believe it is different with Bitcoins as it only carries transaction data, Even then it is now close to 100GB? And that's only with just over 1 million users I believe.
That's basically what I meant.
Fact: VISA Europe alone processes 10,000 transaction per second (TPS) on the few days leading up to Christmas. On a bad day they do 3,000 TPS.
Fact: Bitcoin can only do 7 transactions per second with the current blocksize. Raising the blocksize is of course possible, but increases the size of the ledger proportionally, leading to the creation of 'supernodes', AKA payment processors. Sounds familiar?
Question: Why even have bothered creating bitcoin if these facts were known in advance (which they were)? Or, to use your language, is Bitcoin as a global transaction platform a 'fallacy'?.
Of course not. Being aware of its limitations did not prevent the early adoption of Bitcoin, technology does move on and solutions to problems are found every day. Bitcoin is 5 years old and doing great!
Same thing for Ethereum and the many challenges ahead of us. In fact, Vitalik has written extensively on the topic at https://github.com/ethereum/wiki/wiki/Problems.
@Stephan_Tual, I believe the last 2 lines of my comment answers your question. Bitcoin was a proof of concept that is becoming an adoption. Bitcoin is doing great 5 years on because there are only slightly more than 1 million users on this and is pale in comparison with VISA.
In order to take it to the next level and gain widespread adoption, ethereum has to scale beyond VISA's volume simply because people will not use it as a transaction per se but as a block chain of application transactions and data storage.
One must understand that ethereum is not just a Bitcoin. Ethereum is like what you have so aptly put it:
"So the good news is, we never called Ethereum "Cryptocurrency 2.0"
Our target audience are developers and the core message is "a software platform to build and distribute decentralized applications". Personally I want to be able to walk in front of an audience and be able to explain Ethereum without having to explain Bitcoin first."
Personally too, I do not wish to associate Bitcoin with Ethereum. They are two different matters miles apart, sharing only some common features, just like voice telephony and Wireless Internet connectivity sharing the same wireless medium but for different purposes.
And personally, I do not see any future in Bitcoin as a cryptocoin. If ever there is a need for a token or crypto-coin like feature, ethereum ecosystem can provide for it as in the case of a sub-currency.
Five years from now, bitcoin may just be a thing of the past as it probably would have died before it could reach its "critical technology limit of falling over", thanks to something like ethereum.
But do we want a similar thing to happen to ethereum? I'd say no because by then too much money, time and resources would have been spent on great applications.
Today more than a $100 million has been spent on bitcoin initiatives by VCs and the number is growing. I believe ethereum initiatives will push the bar up by at least 10 times. I can also see bitcoin companies changing their course of direction in order to stay afloat.
What I am saying is there is a danger if ethereum does not have a good and robust roadmap. Failure is not an option.
Your last two lines pointing to Vitalik's discussion on it is a sign of "bad storm coming" and if we are not prepared to weather that, we will end up with a big disaster. One thing's for sure, it won't take ethereum 5 long years to have 1 million users like Bitcoin. It may probably take 2 years. And it will probably take another 3 years to hit 1 Billion active users. Facebook has 1.3 Billion active users in 10 short years on just one application - Facebook. Ethereum is a means to a myriad of applications!
Writing off bitcoin is another story, which we shouldn't need to talk about as it is a matter of conjecture for all of us. Only time can tell.