Come-from-Beyond
Legendary
Offline
Activity: 2142
Merit: 1010
Newbie
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 24, 2016, 07:49:50 AM |
|
Yes it does. A 'smart contract' that never interacts with anything outside the network (including users) is pointless. The smart contract itself may not set the history rewrite, but the possibility of them must be accounted for in the design of the contract.
I see, didn't know that the problem of reliable oracles had been solved.
|
|
|
|
ilpirata79 (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 24, 2016, 11:17:59 AM |
|
Sorry no offense, but ETH is better in every possible regard: speed, scalability, encryption, smart contracts etc. ETH will encorporate BTC ultimately as a side-chain out of respect for historical purposes.
No offence, buy you don't really know what you're talking about.
|
|
|
|
JackH
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 24, 2016, 02:43:41 PM |
|
Writing smart contracts is inherently not 'natural' software development similar to how writing legal contracts are not 'natural' prose. The requirements and implications are quite different. The kinds of data the software works with is different. The resource costs are radically different. The execution environment is necessarily very different-- how often do you write ordinary programs whos execution gets rolled back in a reorg or could "run out of gas"? The implications of failure are typical fairly different. The interactions with privacy are very different than ordinary software development. Often the "simply written" smart contracts are grievously insecure-- I guess you could say that they're not that smart. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) There can be cases for wanting to use legacy software in a smart contract context, for interoperability or rapid prototyping-- but the ethereum model isn't particular good for that either (it imposes enormous overheads on software compiled from traditional languages). Effectively, when you create a de novo smart contract you are designing a cryptographic protocol. It turns out that it's fiendishly hard to do this, even for experts, and the science of creating good tools for it is yet unsolved. (Though it's one of the long term problem areas that I'm funding people to work on.) I think the Bitcoin technical community has some good starting premises about what kinds of constructs facilitate making tools that make it more feasible to construct new smart contracts with less than super-human effort-- things like having top level building blocks that work like monotone boolean functions, so that you can safely compose standardized parts without understanding the internals and your software can reliably analyze the space of possible outcomes. What is a de novo smart contract? Could you tell us more on what you are trying to achieve in this field you are funding people in?
|
<helo> funny that this proposal grows the maximum block size to 8GB, and is seen as a compromise <helo> oh, you don't like a 20x increase? well how about 8192x increase? <JackH> lmao
|
|
|
KoinMaster
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 24, 2016, 07:11:22 PM |
|
Sorry no offense, but ETH is better in every possible regard: speed, scalability, encryption, smart contracts etc. ETH will encorporate BTC ultimately as a side-chain out of respect for historical purposes.
No offence, buy you don't really know what you're talking about. You don't want to understand what I am talking about. But that's fine and understandable. Every empire falls because of the arrogance and shortsightedness of it's followers who loose their flexibility and open-mindedness and begin to believe that they are invincible and are here to rule all. This will be the case for BTC. Reading your comment just reinforces this truth. With your attitude you are setting yourself up to a rude and painful awakening. But you cannot say anymore that you haven't been warned....
|
▄████▄ ▄████████▄ ▄████████████▄ ▄████████████████▄ ████████████████████ ▄█▄ ▄███▄ ▄███▄ ▄████████████████▀ ▄██████████ ▄▄▄▀█████▀▄▄▄▄▀█████▀▄▄▄ ▀██▄ ▄██▀ ▀██▄ ▄██▀ ▀██▄ ▄██▀ ██ ▄█████▄▀▀▀▄██████▄▀▀▀▄█████▄ ▀██▄ ▄██▀ ▀██▄ ▄██▀ ▀██▄ ▄██▀ ▄█▄ ▀██████████████▄ ████████████████████████████ ▀██▄ ▄██▀ ▀██▄ ▄██▀ ▀██▄ ▄██▀ ▀█▀ ██ ▀████████████████████████▀ ▀██▄ ▄██▀ ▀██▄ ▄██▀ ▄█▄ ▀██▄ ▄██▀ ██ ▀████████████████████▀ ▀███▀ ▀███▀ ▀█▀ ▀███▀ ▄███████████████████████████████████▀ ▀████████████████▀ ▀████████████▀ ▀████████▀ ▀████▀
| ║║ ║█ ║█ ║║ | .
| .
║║ ██ ║║
| .
| .
║║ ██ ║║
| .
| ║║ █║ █║ ║║ | |
|
|
|
christianlundkvist
Newbie
Offline
Activity: 13
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 25, 2016, 02:31:55 PM |
|
A 'smart contract' that never interacts with anything outside the network (including users) is pointless. The smart contract itself may not set the history rewrite, but the possibility of them must be accounted for in the design of the contract.
I'm interested in what you mean by this. If we take a simple smart contract like a multisig, are you considering that to be something that "does not interact with anything outside the network"? If yes that seems to contradict your statement that those contracts are pointless. If not, what are the issues with chain reorgs in this example if any?
|
|
|
|
nihilnegativum
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 25, 2016, 04:09:48 PM |
|
There will be no public block chain with Turing complete scripts ever, because that would mean that absolutely any algorithm would be accepted in a script, including non-terminating ones. A smart contract with an infinite loop would be a very bad thing. But, but Etherium is Turing complete, isn't it??? No it is not, it can't be. It would be killed by DOS in no time. The language may be Turing complete in theory, but since the system must guarantee that all scripts terminate in finite time (I think they do it by requiring that each instruction has a cost) it is not Turing complete in practice. They could have used a total language in the first place, where you have a guarantee that every program terminates. I know this isn't really an answer to the OP question but I wanted to point it out ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) If I understand it correctly, I think thats exactly the point, they wish to include loops (and by including loops in general, also infinite loops), the infinite loops are then solved practically by the gas mechanism. The problem isn't with the halting problem, but that the system produces the first shared computer, that has the most slow and expensive computation, and so won't be used for computation but only computationally enhanced verification, and thats just not as cool.
|
|
|
|
tucenaber
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 27, 2016, 04:40:03 AM |
|
There will be no public block chain with Turing complete scripts ever, because that would mean that absolutely any algorithm would be accepted in a script, including non-terminating ones. A smart contract with an infinite loop would be a very bad thing. But, but Etherium is Turing complete, isn't it??? No it is not, it can't be. It would be killed by DOS in no time. The language may be Turing complete in theory, but since the system must guarantee that all scripts terminate in finite time (I think they do it by requiring that each instruction has a cost) it is not Turing complete in practice. They could have used a total language in the first place, where you have a guarantee that every program terminates. I know this isn't really an answer to the OP question but I wanted to point it out ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) If I understand it correctly, I think thats exactly the point, they wish to include loops (and by including loops in general, also infinite loops), the infinite loops are then solved practically by the gas mechanism. The problem isn't with the halting problem, but that the system produces the first shared computer, that has the most slow and expensive computation, and so won't be used for computation but only computationally enhanced verification, and thats just not as cool. All I was saying is that it isn't Turing complete. There is no halting problem when you have a "gas mechanism".
|
|
|
|
go1111111
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 29, 2016, 07:27:27 AM Last edit: April 29, 2016, 07:52:47 PM by go1111111 |
|
The kinds of data the software works with is different. The resource costs are radically different. The execution environment is necessarily very different-- how often do you write ordinary programs whos execution gets rolled back in a reorg or could "run out of gas"? The implications of failure are typical fairly different. The interactions with privacy are very different than ordinary software development.
Yes, smart contracts are different from normal software in many ways, but I'm not seeing why exactly this means they shouldn't be written in a declarative language. My premise is that a language like Script just adds to the developer's mental load without any corresponding benefit over a declarative language (which I am assuming are easier for the human mind to understand). Note that I'm not suggesting Ethereum's language is better. This is just about declarative vs. <whatever Script's style is called>. I'm wondering whether it is possible to create a language that has equal power to Script, which just happens to be declarative. So for instance it would obviously not have loops, no gotos. Maybe just if statements / if/else, support for variables, the existing opcodes converted to declarative functions, and a cap on the # of instructions. So for instance a P2PKH 'script' might look like: function( pubKeyHash, sig, pubKey){ h = OP_HASH160(pubKey) if ( pubKeyHash != h ) return false return OP_CHECKSIG( sig, pubkey) }
Are there reasons why if Satoshi had done this instead of Script it would have been bad?
|
|
|
|
StrawberryF
Newbie
Offline
Activity: 9
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
April 29, 2016, 07:54:24 AM |
|
Really interesting read, still my biggest fear about Ethereum is if their scaling plans fails, then we will have just another fancy "dead horse"
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8662
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 20, 2016, 07:55:40 AM |
|
but I'm not seeing why exactly this means they shouldn't be written in a declarative language
How about now? Though your example is making a distinction without a difference, something like that could easily be converted to something more Bitcoin script like... but the real differences I'm highlighting are things like avoiding mutable state, which-- among other benefits-- would absolutely preclude vulnerabilities like that re-entrancy race in the DAO, which is currently in the process of proving to the world that ethereum isn't the decentralized system it has claimed to be (so, in that sense, the error prone smart contracting programming model has done the world a service).
|
|
|
|
RocketSingh
Legendary
Offline
Activity: 1662
Merit: 1050
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 20, 2016, 10:28:11 AM |
|
so, in that sense, the error prone smart contracting programming model has done the world a service
Do u think, this statement is valid for those who are building smart contract on bitcoin blockchain, e.g. Rootstock or CounterParty?
|
|
|
|
funkenstein
Legendary
Offline
Activity: 1066
Merit: 1050
Khazad ai-menu!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 27, 2016, 09:02:12 AM |
|
Interesting thread thanks Personally I think bitcoin script was already overly complex, I'd rather see things compartmentalized in accordance with unix philosophy. Also keep in mind that contracts are conflict resolving tools, and as such fixing them with code totally misses the fact that conflicts arise due to circumstances unknown at first, which therefore haven't been coded for. As such, they could only make business more difficult. Even if somehow there was a magically trustworthy oracle. That being said, I could see the thing as more of a tool for decentralized automation. Change the name and now it makes more sense. But not a whole lot more. When I think of automation I think of a project with a planner.. in which case - why the decentralization? Extra useless overhead. However I can' t immediately rule out the existence of a reasonable use-case somewhere like I can easily do for smart contracts. Add to this that ethereum has the economic distribution model of dogecoin and I'm not sure what's left. I mean seriously, did nobody on that team consider that their coin would be around long enough that the money supply would matter?
|
|
|
|
gmaxwell
Moderator
Legendary
Offline
Activity: 4242
Merit: 8662
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 27, 2016, 09:16:03 PM Last edit: June 27, 2016, 09:29:00 PM by gmaxwell |
|
The argument in Bitcoin is simple: If doing anything interesting with Bitcoin forces you back to a purely trusted third party, the value of Bitcoin as a permissionless asset is diminished.
Bitcoins value comes partially from decentralization, and that value is maximized by minimizing the frequency at which you need to put those benefits aside. No more justification is needed.
Re other things copying ethereum's smart contracting system. For me, the recent snafu in ethereum is experimental confirmation of a long held belief about that design. My view that the design is flawed wouldn't be changed by putting it another altcoin or a sidechain. That doesn't mean I'm opposed to other people trying other things, -- more experimental evidence.
|
|
|
|
Decoded
Legendary
Offline
Activity: 1232
Merit: 1030
give me your cryptos
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 28, 2016, 01:59:00 AM |
|
Ethereum and Bitcoin are heavily flawed in their own ways. Maybe even being polar opposites. Smart contracts aren't the best use for hashing power, but it's a good start.
|
looking for a signature campaign, dm me for that
|
|
|
hv_
Legendary
Offline
Activity: 2520
Merit: 1055
Clean Code and Scale
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 03, 2016, 02:31:32 PM Last edit: July 03, 2016, 05:59:45 PM by hv_ |
|
Ethereum and Bitcoin are heavily flawed in their own ways. Maybe even being polar opposites. Smart contracts aren't the best use for hashing power, but it's a good start.
With the clear difference is that the attack universe of the first is more Turing complete. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
Carpe diem - understand the White Paper and mine honest. Fix real world issues: Check out b-vote.com The simple way is the genius way - Satoshi's Rules: humana veris _
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 03, 2016, 02:49:20 PM |
|
Whilst this probably won't be understood by nearly anyone on this forum the AT CF code is as follows: 00000000* STZ $00000000 00000005 FUN @00000001 Get_Current_Balance 0000000c BGE $00000001 $00000002 :0000004e 00000016 FUN @00000003 Get_Creation_Timestamp 0000001d FUN A_To_Tx_After_Timestamp $00000003 00000024 FUN @00000004 Check_A_Is_Zero 0000002b BZR $00000004 :00000054 00000031 FUN @00000005 Get_Amount_For_Tx_In_A 00000038 FUN @00000003 Get_Timestamp_For_Tx_In_A 0000003f FUN B_To_Address_Of_Tx_In_A 00000042 FUN Send_To_Address_In_B $00000005 00000049 JMP :0000001d 0000004e FUN B_To_Address_Of_Creator 00000051 FUN Send_All_To_Address_In_B 00000054 JMP :00000054
This is AT machine code (there is no high-level language for AT at the moment and after the DAO bungle we aren't in any hurry to add one), however, it has been in production for well over a year (without a single issue being reported from two separate blockchains that are using it). It is *minimal* and incredibly efficient (it doesn't even basically do any executing until the CF expiry time is reached). I don't think that Turing complete smart contracts are impossible to do right but they are extremely difficult to do right and so should IMO at this stage be limited to very small things like the example above (and tested for every feasibly possible scenario).
|
|
|
|
JackH
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 03, 2016, 05:54:08 PM |
|
Whilst this probably won't be understood by nearly anyone on this forum the AT CF code is as follows: 00000000* STZ $00000000 00000005 FUN @00000001 Get_Current_Balance 0000000c BGE $00000001 $00000002 :0000004e 00000016 FUN @00000003 Get_Creation_Timestamp 0000001d FUN A_To_Tx_After_Timestamp $00000003 00000024 FUN @00000004 Check_A_Is_Zero 0000002b BZR $00000004 :00000054 00000031 FUN @00000005 Get_Amount_For_Tx_In_A 00000038 FUN @00000003 Get_Timestamp_For_Tx_In_A 0000003f FUN B_To_Address_Of_Tx_In_A 00000042 FUN Send_To_Address_In_B $00000005 00000049 JMP :0000001d 0000004e FUN B_To_Address_Of_Creator 00000051 FUN Send_All_To_Address_In_B 00000054 JMP :00000054
This is AT machine code (there is no high-level language for AT at the moment and after the DAO bungle we aren't in any hurry to add one), however, it has been in production for well over a year (without a single issue being reported from two separate blockchains that are using it). It is *minimal* and incredibly efficient (it doesn't even basically do any executing until the CF expiry time is reached). I don't think that Turing complete smart contracts are impossible to do right but they are extremely difficult to do right and so should IMO at this stage be limited to very small things like the example above (and tested for every feasibly possible scenario). Where is that data from?
|
<helo> funny that this proposal grows the maximum block size to 8GB, and is seen as a compromise <helo> oh, you don't like a 20x increase? well how about 8192x increase? <JackH> lmao
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 04, 2016, 04:23:23 AM |
|
Where is that data from?
It's not "data" but "code" and numerous instances of this code has been running on the Qora and Burst blockchains for well over a year (it is how much of the development funds have been raised). Details of AT itself can be found here: http://ciyam.org/at/(it is highly technical documentation)
|
|
|
|
Karartma1
Legendary
Offline
Activity: 2310
Merit: 1422
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 04, 2016, 06:21:20 AM |
|
Writing smart contracts is inherently not 'natural' software development similar to how writing legal contracts are not 'natural' prose. The requirements and implications are quite different.Often the "simply written" smart contracts are grievously insecure-- I guess you could say that they're not that smart. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Thanks gmaxwell. I gave the exact same explanations to a group of friends who are developing on ethereum. I totally agree with this. And, moreover,, thinking how legalese is complex and "dumb" at the same time I don't know if it is that good to make some software run this "complexity dumbness" with code. ![Wink](https://bitcointalk.org/Smileys/default/wink.gif)
|
|
|
|
CIYAM
Legendary
Offline
Activity: 1890
Merit: 1086
Ian Knowles - CIYAM Lead Developer
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
July 04, 2016, 06:30:29 AM |
|
Writing smart contracts is inherently not 'natural' software development similar to how writing legal contracts are not 'natural' prose. The requirements and implications are quite different.Often the "simply written" smart contracts are grievously insecure-- I guess you could say that they're not that smart. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) I would agree that the amount of effort required in order to get such things written and working "as expected" is far from trivial (even with such a tiny program such as the Crowdfund example I posted). However it really isn't that much different to writing critical code for other things (such as medical equipment or software for spaceships) so I don't think it is without precedent (but is perhaps quite alien to the vast majority of programmers). Rushing into writing complex "smart contracts" (and putting them in charge of millions of dollars worth of tokens) is not a good idea. This is a new and emerging field that is most likely only going to improve through a lot of unfortunate mistakes.
|
|
|
|
|