What on earth would make you believe that there will not be many more hacks of ethereum based contracts ?

I was talking about "image" not about "intend"

You can be in reality a greedy corporate bastard walking on corpses for a dime more profit and colluding with all TPTB, and still have an underdog rebel image that you cultivate carefully with professionally done communication amongst the gullible Brave New World crowd.

Me too.  But I'm waiting until the next big exploit on a famous ethereum contract happens.  As not much is happening, smart contract wise, this can take time.

Me too, and the surge that surrounded all the ridiculous pump concerning the (in reality insignificant) bitcoin halving, could have led to another december 2013 bubble.  The DAO failure brought people somewhat back to their senses, that things CAN go seriously wrong in crypto too.

In any case I think bitcoin is way way too expensive right now compared to its real usage as a value transmitter and has become essentially a speculative token, not a thing people use a lot as a currency.

Indeed.  Send him your contracts, and he'll tell you who owns what with his superuser powers

Use PGP when sending him an email of course.  Security first  

But seriously, I think for short-term contracts, ETH and ETC are OK.  I would worry more about the exploits of the contracts.

Maybe, in its own funny way, the DAO blurp actually SAVED crypto from yet another hype bubble that was going to burst, and brought reason to the markets.  The worst that can happen, is yet another december 2013 bubble blowing.  The DAO took the heat off the stove before it started bubbling too much, maybe ?

TL;DR

There is a difference between an application that is supposed to automate a paper contract with intend as we know it, and a smart contract which is a totally new beast, of which intend is to be derived from code, and not the other way around, as we are used to in software.

As such, this derivation must be *provable* and automatic (the derivation of intend from code).  And this is mathematically impossible with code written in a Turing-complete language, but is perfectly doable when the code is written in a language which is not Turing complete.  The bitcoin byte code is perfectly analysable and it must be possible to build tools that analyse the full state tree of any bitcoin script.  From that state tree, intend follows.

You can perfectly analyse any multisig script, and there will be no surprises. 

We've never done such a thing before and that's why smart contracts are strange beasts, and we keep ignoring their nature, by referring to things like "intend", "law", "thieves and frauds".

You could compare a smart contract as a "law of nature" and a normal contract as "a rule of a game".  Quantum mechanics aside, when playing soccer, it is not possible to shoot the ball in the two goals of the two parties at the same time.  So nobody can "cheat" on that rule.  On the other hand, it is not allowed to carry the ball with your hands, but you can physically do so: if you do, you're a cheater.  You might erroneously *think* that the laws of nature forbid you to shoot from the corner position directly into the goal because no straight line can do so.  But you can use a spin on the ball, which makes it follow a curved trajectory and enters the goal all right.  If you do so, you are not a cheater, simply because someone thought that the laws of nature (the smart contract) was different.

Oops, I added a lot to my previous post, sorry about that. The editing took too much time and you replied in the mean time.

Well, this is, again, because the Slock-it people were selling *intend*.   If the Slock-it people had only published the byte code, then what the DAO hacker did, was not "exploiting a loophole", because for certain byte code states to call loop holes/exploits/..., you have to have another model of behaviour that doesn't include these states.

That's my whole point.  There are two ways to look upon software that "automatically" arbiters contracts: one is "the implementation of intend, as specified in human-readable terms" ; the other is "the code itself".  Only the last way is a smart contract - especially one running on a block chain and "unstoppable".

It seems that many people confuse both.  The first kind of thing could be, say, an application ran by an insurance company, that automatically treats common incidents, and pays people accordingly.  This application is supposed to implement the INTEND of the PAPER CONTRACT.  It can very well contain bugs ; people could find exploits in it, and have them paid much more by the company than they are entitled to.  This is a "loophole", "bug", "exploit" because the software was SUPPOSED TO IMPLEMENT INTEND (in the written contract).  As such, people exploiting that are indeed, thieves, and corrective action is perfectly normal: it was NOT the application that was the *final arbiter* but the paper contract ; the application only had to implement that intend, and failed (contained bugs and exploits).  People profiting from that are dishonest thieves.

But a smart contract is NOT that ; and the Slock-it people (and many others btw) are keeping up this confusion by PROVIDING EXPLANATION OF INTEND.  They shouldn't, because this confuses people, making them think that they sign up, like with a paper contract, to this intend.  When the software behaves differently than the announced intend, they cry fool, and they behave as if the smart contract were the application containing bugs, because not implementing intend.

THAT IS NOT WHAT A SMART CONTRACT IS ABOUT.  That is simply software automating a paper contract.

edit: continuation:

The big difference between "an application automating a contract" and "a smart contract" is that the first is not a contract: the contract is elsewhere, in paper, with intend.  That kind of application can have bugs, exploits, loopholes, and if you use them, you are being dishonest, because you were supposed to adhere to the PAPER CONTRACT INTEND.

A smart contract, on the other hand, is a piece of code, and nothing else.  By *analysing* that piece of code, one can try to deduce the intend.  In as far as this analysis is *provably reliable* (in the same way as a bitcoin transaction is proved cryptographically), this analysis can be done by the proposer of the contract, and it is up to the signer of the contract to verify this reliability of the contract analysis from the code.

The big difference relies in the responsibility of the code execution.  In the first case (a running application, implementing a paper contract), it is the - obviously centralized - issuer of the contract that is responsible, if he USES the application to do his accounting and arbitrage, to make sure that the application is running correctly, it is his responsibility to correct any errors the application can make, and in the end, he is liable for the damage the errors in his application can cause.  After all, he had people engage in a PAPER CONTRACT, and he proposed this application to execute it.  He cannot hide behind "the code was the contract", because he led people to believe that his explanation of intend was the contract, and he's hence responsible for every bug in the application and its consequences.

With the DAO, one has the impression that people were adhering to the contract intend as explained on the slock it website, and that they had some confidence that the actual ethereum contract running was implementing that contract.  THIS IS HIGHLY MISLEADING.  As such, the Slock it boys engaged their responsibility wrt. the DAO signees because everything was done to make them believe that the contract had a certain intend.  (this is probably why they panicked and pushed for the fork): their use of a piece of byte code on a block chain to implement that intend was a very risky affair for them because in as much as this byte code was not going to run as intended (and that's what it did) they would have to explain how they crowd-funded explaining INTEND and then used this funny block chain application which implemented something else *and which they couldn't change afterwards*.

In the case of a genuine smart contract, the intend has to be *derived* from the code, and not the other way around.  THAT IS VERY STRANGE, but the nature of a smart contract.  That is what "code is law" means.  Nothing is more scammy, than to *pretend* that the code is implementing an intend.

We've never seen such a thing before.  Smart contracts are strange beasts.  And the DAO scam/cover up has done great damage in covering up this aspect.  

In common law, there are *forbidden contracts* because they are *misleading*.  Unfair contracts are contracts of which the terms were obfuscated in some or other way to some of the parties.  Contrary to what is often thought, contracts do not have to have a "balance between potential gains and losses" between parties ; otherwise, a donation would always be considered unfair.  But a donation, covered up as a "fair deal" on the other hand, is a fraud.  "you give me $10 000,-, and I say thank you" is a perfectly legal contract.  "you give me $10 000,- against a unique painting of my hands you will probably be able to sell for $100 000,-" is a fraud if I just give you a piece of canvas with three blobs of blue paint on it.   "you give me $10 000,- for a piece of canvas with 3 blobs of blue paint on it" is a fair contract.

So: "sign up to the DAO, which is meant to be a distributed venture capitalist entity" is a fraud (like the "painting you will probably sell for $100 000,-").  But "sign up to the DAO, here's the byte code" is a fair deal.


What the slock it boys did, was the scam "sign up to the DAO, which is meant to be a distributed venture capitalist entity - look at the fine print"  and in the fine print, there was "the byte code can be found there".

But many smart contract proposers do exactly the same: they tell you what should be the intend of the smart contract.  That's a scam.  It is not the thing you sign up for, and which will actually determine what happens.

You mean that you can configure your bitcoin core to use a TOR proxy (a local one, accessing your TOR gateway) ?

The point is that the network that has been designed for that, is I2P, and in a certain way, Freenet, not TOR.  TOR has this functionality also, but as an ad-on.  I2P was designed exactly with that in mind.    I was thinking about Freenet because maybe the ledger (block chain) could be a distributed freenet file itself.

Then you need human judgement ; only a human can understand "intend".  And then you consider that smart contracts (the contracts where software is the final arbiter) have no reason to exist. 

Considering 'fair', no, a contract doesn't have to be 'fair'.  A contract must be CLEAR, that is, the people signing up to a contract must understand perfectly what they are signing up to.  There is no need for a contract to be fair, because the user is FREE to sign or not.  Fairness is a concept when coercion is at work.  If there is no coercion, fairness is a meaningless concept, because your freedom allows you 1) to propose just any deal 2) to accept just any deal 3) to refuse just any deal.
But the terms of the deal have to be clear.  With a smart contract on ethereum, those terms are ONLY determined by the byte code.  Up to you if you agree to those terms or not.  If you agree to them, it is your responsibility to understand them *OR* to bet on the trust you can have in someone explaining you what they are (according to them).

If I propose to you a contract where we put money in a pot, and then we draw a winner, who will take all the money, and in the fine print it is stated that I'm entitled to decide how the drawing is done, if you sign up, you shouldn't complain that I can now draw each time my own name as a winner.  It was in the contract.  If you didn't "read the fine print" then that's your problem.

But in order to avoid all this simple scamming, it should be possible to analyse a contract on all its outcomes.  Once that is possible, this kind of easy scamming is not possible any more, or only with very, very stupid people deserving no better (like the DAO holders).  If this is not possible, you are in for a rough ride.  Like the DAO holders.

It would be somehow contradictory to run such a thing on Tor.  If the idea is to confine it to the network, then I only see I2P as an option, even though you *could* do it on TOR, but it would be a bad idea.   TOR is essentially meant to be an obfuscating proxy on the clearnet.  Even though you can have hidden services on TOR, it is not meant to be an "inside only" network, and hence compromises have been made on TOR that are not necessary if your goal is to stay inside the net.
I would even say that if you don't want to stick to I2P, Freenet is a better idea than TOR.  In other words, you take unnecessary risks by using TOR, because TOR is designed to exit back to the clearnet, and has to accept certain risks doing so.  I2P doesn't, and is hence IMO safer for an "inside only" network usage.

It is of course all about "image", not about reality.  I think that bitcoin's image is now "clean" - even though you're right that most of the real use of bitcoin is probably still in the legal grey zone ; however, most of its market cap, transactions, and "news" is now "clean, corporate, and high finance", and the "dark net usage" is not the dominant image any more.  One even has an answer: "look at Silk Road: bitcoin is a transparent ledger, and some silly goons that thought they could conduct illegal business with it have been caught by the FBI - so bitcoin is not suited for illegal stuff, even though some idiots still use it that way, and will get caught". (which is, BTW, factually correct)

Also, Apple's image has to be a bit, a slightly bit, rebellion, but within the confines of the law.  We've seen this with the ridiculous battle over that iphone that Tim Cook didn't want to provide with a hacked iOS to be able for the FBI to unlock it.  It is good to defend "privacy" for Apple's image, but it is not good to be associated too much with the Dark Web.

I think bitcoin's image fits perfectly in there.  Ethereum too.  It is accepted by the corporate world, and it even gets legal ground (think of the bitcoin licenses and other legalese that starts to emerge in the US, in the EU, and other places).

So bitcoin is sufficiently "rebel" and legal enough to fit perfectly in Apple's image.  But anonymous coins, I'm not sure. (independent of the true cryptographic and OPSEC anonymity provided: we're talking image only).

I understood that Cyanogen has abided up to a certain point to Google's requirements, for them to be able to legally access the Google Play Store.  They got a cease-and-desist letter from Google that if they wanted to write tools that accessed Google's stuff, they had to comply to certain requirements by Google.  I don't know exactly which ones, but that sounds somewhat like if Linux/GNU wanted to continue to distribute WINE, they should agree to certain kernel requirements by Microsoft.

So Cyanogen is not so FOSS as you may think (this also comes about because the Cyanogen main dev now has his own business, selling Cyanogen).

I don't know the terms they accepted.  If this is security-related (if Google wants to have its hands on certain privacy related aspects), then this would seriously annoy me.  If it are just some technicalities not to screw up Google's store, then I can understand.

In any case, DRM and freedom are not compatible.  Intellectual property and freedom are not even compatible. 


I think that a weak point in all this FOSS/liberty thing is the propriety hardware.  In the end, the code can be free, but you're linked to propriety hardware of which part of its functioning is unclear.  And in as much as a small set of people around the world can develop software, it is quite difficult to do the same with hardware, where you need big, and centralized, investment (not just time and competence, but real material stuff: a factory).  Maybe FPGA are an answer, but this is slow hardware.


I'm still not sure whether THIS is the reason (the real reason, not necessarily the announced reason).  It might just be a matter of image and "we're a law abiding company that stays away from dark net stuff".  The real test would be whether Apple accepts monero to be taken up, or zcash.  Then this would be cleared out.  If monero is refused also, it is because Apple doesn't want to be associated with the "dark net anonymity" image.  If monero is accepted, your explanation might very well be true.  But I suspect that Apple is rather "corporate", and wants to give a public impression of law abiding.
It depends on what the majority of their customers think.  As any company should care about.

I would like to insist on the fact that ONLY the byte code is the contract - which is why it is so important to be able to *deduce intend from byte code* and not the other way around - and this needs automatic analysis of the state tree of the byte code, and this needs a non-Turing-complete byte code language.

This is also why I consider the DAO hacker not a thief, and why I consider that the real scammers are the Slock it people (even though they may even have been scammers without realizing it).   This is because the concept of *smart contract* is new, and the ETH fork has hindered people in helping them understand this new and strange beast. 

Consider the following: an ethereum lottery.  It is very simple: during the week, people "buy tickets" of the contract, by sending a fixed sum of ethereum (the price of the ticket) to the contract.   Saturday, at noon, the contract "draws randomly" one of the participants, who gets all the ethereum, except for 1% of the pot, which goes to the dev (a fixed address in the contract).

Now suppose I analyse the code, and see that the "random generator" is in fact a thing that calculates the numerical value of the last few bytes of a hash of every participating address, and picks the one that is closest to a prime number.  In case of equality, it picks the one closest to the biggest prime number.  In the case of still equality, it goes to the earliest participant signing up.

Once I understand this, I generate myself a lot of addresses, until I find one that gives a hash of which the tail's numerical value is exactly equal to the biggest prime number that can occur in the finite set the contract considers.  I play with that address, immediately after the start of a new week, and of course, each time, I win.  Nobody knows, because each week, I generate a new address with the same bytes at the end.  That takes me some hashing power, but not so very much.  It can take a long time before people realize.  They see each week a winner, with a different address. 

Am I a cheater ?  Am I a thief ?  Or just someone who read the contract and understood how to use it profitably ?

The REAL scam comes from the announcement of the contract, which tells people that there is a RANDOM drawing amongst participants.  People *imagine* a different contract, than the one they are signing up to.  But this blah-blah over intend of the contract is not what people SIGN UP TO.  They only sign up to byte code.

This is why ONLY the byte code should be read by signers.  And this is why it should be analysable automatically.  And this is why there shouldn't be any "explanation of intend" on any web site concerning any smart contract.  Only the byte code should be there, to be read/analysed by whoever is interested in signing it.

If you find that strange/ridiculous/unattractive, then you start seeing what smart contracts really are.

JJG already explained things well, but I'm going to add a few things, so that maybe you start to understand.


It would indeed even be worse if smart contracts were themselves Turing-complete state machines.  But this is not what I'm alluding to.  In a Turing-complete language, you cannot *automatically and systematically* test a random given piece of code on ALL OF ITS STATES because that set is potentially infinite.
In other words, if I give you a random piece of byte code (which is an actual contract you're wondering if you should engage with it or not), there's no systematic way to obtain the full state tree from it with a tool.  Mind you that you have to use the *byte code* and not the Solidity source code from which it is supposed to be compiled, because in the end it is the byte code that will be running, and all subtleties of side effects of the compilation are too difficult to take into account.  A given contract doesn't even have to have Solidity source code: you can always set up the byte code independently.
There's no possibility to obtain *automatically and with certainty* the full state tree of a contract.

And the whole art of lawyers looking at business contracts is to explore the state tree: ALL possible states and outcomes a contract can have.   THE VERY PRINCIPLE of an honest contract is that the signing parties are aware of ALL the possible states and outcomes of a contract.

This is entirely different for software in general.  Software in general (for instance, scientific software) is often used to obtain outcomes *people didn't know in advance*.  Here, Turing-completeness IS a good thing.

But NOT in contracts.  In as much as a contract is supposed to be honest, ALL ITS STATES must be obviously understood and known to the signing parties.  And that is exactly what Turing complete languages don't allow you to obtain with certainty on a random piece of contract byte code.  This is also why there is this stupid gas limit of which all the exploits are not yet starting to occur and for which one can design very, very subtle exploits.

Now, of course you CAN limit yourself to a testable SUBSET of byte code, but that misses the point that you cannot test "a random contract given to you" ; that the nodes cannot do that test, and hence have to apply a gas limit of which nobody knows exactly what leaves this cuts off the state tree/graph of the contract.

On non-turing complete contract systems, you don't need any gas limit, because every node can analyse the contract, and find out how big the state tree is, and what is its longest path. 

Cutting away "long paths" with a gas limit can introduce also a lot of exploits.  For instance, you might set up a contract such that redeeming ether is only possible for certain addresses, because the calculation is depending on the address and for most addresses, this calculation is too long and will always be cut off by the gas limit ; or you could be more subtle, and have certain contract instructions to be impossible by gas limit if they come from certain addresses.  This could even be induced after the contract is running, by giving instructions that can only come from one address, obfuscated by gas limit.

The gas limit is necessary because of Turing completeness, and the fact that a node cannot analyse the tree of just any random contract.


Don't confuse a technical hardfork and breaking immutability.  Even if monero is hardforking over introducing confidential transactions, this is not breaking immutability as compared to the INTEND of the white paper.  Bitcoin never broke immutability, but hardforked several times - all this time, the intend of the white paper has been preserved, and all of the history has been preserved.
The only time that one could naively think that this didn't happen, was when a BUG in the node software didn't follow the white paper intend, and allowed for *non valid blocks by intend* to be validated erroneously.  When the bug was repaired, the white paper intend was restored, and of course a whole lot of blocks turned out not to be valid: but the point is, they NEVER were valid according to the intend of the white paper.  So this was not a break of immutability.

Mind you that node software is NOT a smart contract, but normal software, that implements INTEND.  There's nothing wrong with changing that software, as long as one sticks to intend, and as long as one preserves the past in as much as that past was in agreement with the intend of the protocol.

The whole idea of the block chain technology is that the antagonism between the players, their diversity and number is so big, that only consensus can be found over the original white paper intend, and the real history according to that original protocol (as intend).

But you are perfectly right that this can fail.  There's no guarantee that this immutability will remain.  However, in that case, the block chain failed.   It is no more or no less than a 51% attack.  People can decide to continue to use the failed chain.  This is my big surprise with ETH: it is a failed chain, that has been 51% attacked, but continues to live on.



I don't call gambling on block chain tokens "investing".  It is gambling, nothing more and nothing less.  Investing means helping to set up production capital with economic growth as its consequence and source of reward.  Buying bitcoin and hodling, or gambling on altcoins, at no point, helps buying capital goods or services: it only pumps money from greater to lesser fools.
If you're in the gambling business, actually you don't mind in any case what happens, because you're betting on a random generator.  If you're in the crypto token gambling business, there doesn't even need to exist any block chain: just tokens on exchanges: IOU on websites.

You are right that the danger of a block chain failing exists.  What is amazing, is that the tokens of failed chains continue to be traded.  That is, to me, like if one were still trading Apple shares the months after Apple was out of business.  But it is not impossible.  After all, trading only needs belief.


I know that.  But it created a huge moral hazard: first of all, it didn't punish the DAO gamblers as it should have, for having signed up to a smart contract that wasn't what they naively thought it was.  So it has allowed the DAO gamblers to profit from the buzz over smart contracts, without confronting them with the actual way smart contracts work (namely, through exploits).  It has failed to make people see what it *really* means: "unstoppable code" because one stopped it.  So these gamblers, that had invested in a VERY BAD IDEA, have been rewarded with not losing their funds as it should have been.  And the guy known as the DAO hacker has been ripped off from his true use of the smart contract.

Because a smart contract is just a piece of byte code, and nothing more.  Advertising any *intend* of a smart contract is scamming people.  Most smart contracts do that: they say that this contract is doing this or that.  That's scamming people.  The ONLY thing one should tell you about a smart contract, is its byte code - like the ONLY thing that you (or your lawyer) should read is the actual contract you sign, and not any "explanatory but not engaging documentation" that comes with it.  The thing you put your signature on, is the final arbiter.  With a smart contract, it is the byte code.  That is why the DAO hacker wasn't a thief, or a cracker: he just read the byte code, and saw the state that looked very advantageous to him (and to every participant that would have read the byte code, and nothing but the byte code).

And this is why an analysis of the byte code, and nothing but the byte code, is important, to derive the full state tree.  And that is why Turing complete byte code language makes this impossible. 


I wonder if those 3 people decide to bring out a new core that strips Satoshi of his holdings, by blocking any transaction of the first 50 000 blocks UTXO, whether that would be adopted.

I'm interested in crypto essentially only for one thing: anarchism: to take back the power that states have over people, and give it back to the people, as a function of their wealth, and not as a function of their political influence.  Smart contracts are very important in this endeavour, but after the DAO debacle, I understood the fundamental failure of ethereum: Turing completeness.  
The fact that ETH is even not immutable any more is even worse: how are you ever going to be able to implement distributed warfare through smart contracts if the chain is not immutable any more ?  This is probably just a financial toy in the hands of financial gamblers, and it is not a genuine crypto weapon.  It has little interest, apart to make money from ripping off others in a zero sum game, but it will not be disruptive, like the French revolution was.  Not very interesting.  I don't think distributed warfare is possible on ETH.  Think of the "London has fallen" movie, but organized with a smart contract, and not a single point of failure of the wealthy leader.  I think ETH doesn't have the muscle to handle this kind of stuff.  But I'm dreaming here.  This is still far away.

For sure then, ethereum is not going to be a tool that helps putting an end to bank, corporate and state power, but will rather be a toy in their hands.  As such, as crypto, it failed, and became yet another financial toy in the hands of the powerful.  I suppose they must like the "stopping the unstoppable" aspect of ETH.  In other words, ETH is corporate crypto.  A kind of oxymoron.
Now, it is waiting for an exploit in such a big corporate ethereum application :-)

Well, then I missed something, exactly for the attack I previously mentioned, and your answer.  If the "spend proof" is just a hash which everybody can calculate, then my earlier proposed attack is valid.  Your mentioning of "it can only be send from the right owner", in this language, means a cryptographic *signature* (that's what "send" means here).  Otherwise, if I pay you, I KNOW the transaction and hence the output that you are going to spend, and I CAN calculate the hash of that and post it on the block chain.  If, however, this is not a hash, but a signature with *your private key* (corresponding to the address I'm sending it to), then I cannot post this signature as I know your address, but I don't know your private key.

I see it this way:

The private coin file consists of:
(signature of proof of burn of bitcoin with bitcoin private key that burned it ; transaction containing Joe's address ; transaction containing Jack's address signed with Joe's secret key ; transaction containing Alice's address, signed with Jack's secret key ; ... transaction containing MY address ; transaction containing YOUR address signed with MY key)

On the public block chain, there is the actual burning of the bitcoin  ; .... there must be a spend proof SIGNED BY JOE of of the transaction to Joe so that Jack can verify the spending, but that ONLY JOE can produce.  There must be the hash of the transaction from Jack to Joe.

But now, the spend proof by Jack must be signed with Jack's private key, or otherwise, JOE CAN POST THIS TOO.  However, only Jack can SIGN it.  Alice can verify it, because she has Jack's public key (his address) ; Joe can verify this too, but he doesn't care.  But ONLY JACK MUST BE ABLE TO PRODUCE THE SPEND PROOF.  As such, everybody that Jack would like to take with a double-spend can verify that it was spend (as all of them get the file, and get his public key, and can verify the signature on the block of the previous transaction Joe->Jack).  

A hash is good enough for the new transaction, as this only needs to render the transaction that goes with the spending unique.  
But a hash is not good enough for the spend proof, because otherwise, the previous owner can post it too (with a fake hash of a transaction, rendering the coin unspendable).


The thing is, one could think of a cryptographic way to redeem the bitcoin, instead of burning it, style Lightning network, so that in the end, only one transaction needs to be broadcast, to the final owner.  I don't know exactly how to do this, but it must be possible in some way.