#### Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

# Is a contract like a sub-currency just a fallacy?

Member Posts: 47
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.

• Member Posts: 47
Sorry, I stand to correct that at 100 bytes, it is 0.12TB worth of transactions. Nevertheless, the gist is there.
• Member Posts: 47
Which is essentially what I said in my original writing - 1 Giant contract with 1.2 Billion users' records of 20 bytes for the address and perhaps another 32 bytes for the balance in another contract for each user - vis-a-vis yours with 1 Giant contract including the balances and addresses in it. And on top of that 1.2 Billion transactions a day.

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.
• Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
@Bluefin you do not need separate wallets to talk to any contracts. A wallet can send ethers that can be accompanied with data that communicate with any contract. (main takeaway)

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.
• Member Posts: 47
@Jasper subcurrency is just a metaphor. As you rightly said, it could be used to represent equities, fiat money, gold, derivatives, etc. So it could be a very real implementation.

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.
• Eindhoven, the NetherlandsMember Posts: 514 ✭✭✭
@bluefin, yes the checksum does complicate.. Perhaps the client can remove the complication from the user, but i think even better is simply another approach without the cryptographic commitment. (Not sure how) At the time of writing that transaction-exchange contract i was hoping to learn about that way of doing things, hence the crypto commitment.

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.
• Member Posts: 47
@Jasper. Following from @ethergrok, as I understand it correctly, he proposed that everyone who is a party to the subcurrency etches her address into a "registry of addresses" within the contract. We then use the registry of addresses to verify and transfer to one another from within the contract. It its simplest form, it is a 2 dimensional array of addresses with the corresponding balance contained within the contract.

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.
If you want to send 10 GavCoins to Bob, you send a message containing [ 10, Bob ] to the GavCoin contract, and the GavCoin contract's code updates the balances. A more advanced version of GavCoin may even ping the Bob account to notify it once the transfer is made. A GavCoin wallet would need to be a specific application that peeks into the GavCoin contract, although realistically we'll likely see a generic wallet for all sub-currencies that follow a similar API.
• London, EnglandMember, Moderator Posts: 1,282 mod
edited April 2014
@bluefin:

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.

• Member Posts: 47
@Vitalik, thanks for the input on the GavCoin.

@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!
• London, EnglandMember, Moderator Posts: 1,282 mod
Thank you for your enthusiasm @Bluefin‌ , however, I do not believe Ethereum needs to have 1 billion users to reach its potential. I wouldn't write off bitcoin either
• Member Posts: 47
@Stephan_Tual‌. I agree that Ehtereum doesn't need 1 billion users to reach its potential. It has already got its full potential from the few thousands who are intensely involved in it right now. It is not up to us to control its proliferation when it is out there. And that is my whole point of contention - its potential to collapse instead.

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.