Ethereum from scratch – Part 1: Ping(ocalog.com)
ocalog.com
Ethereum from scratch – Part 1: Ping
https://ocalog.com/post/10/
133 comments
This article mentions and briefly explains smart contracts in a way that really helped me understand. http://haseebq.com/a-hacker-stole-31m-of-ether/
Ethereum would make a hell of a card game. It's naturally adversarial and the incentives are already balanced.
professional etherem devs haven't even gotten to the point where they can write correct contracts themselves. but the concept is pretty simple.
a "smart contract" is a script that runs on a blockchain to execute terms and manage funds.
the problem is that the tools that you use to make these are basically garbage. you don't write fin-tech in what amounts to javascript y'know?
a "smart contract" is a script that runs on a blockchain to execute terms and manage funds.
the problem is that the tools that you use to make these are basically garbage. you don't write fin-tech in what amounts to javascript y'know?
Normally, if you deal with money, then you try to be extremely careful, right? You have to care much about security, verify that your app is not vulnerable, make an audit etc.
And I think that even beginners know that you can't trust users' input - you have to sanitize it. And under no circumstances you want to execute it!
But here it is the opposite, isn't it? You basically give users ability to run any code within your application (blockchain). And you give them very insecure, confusing and badly designed language.
To me it is an epitome of insecurity. It is like giving a shotgun to a child!
And I think that even beginners know that you can't trust users' input - you have to sanitize it. And under no circumstances you want to execute it!
But here it is the opposite, isn't it? You basically give users ability to run any code within your application (blockchain). And you give them very insecure, confusing and badly designed language.
To me it is an epitome of insecurity. It is like giving a shotgun to a child!
Users cannot run 'any code'. They can run contract code, which can only interact with the underlying application through a protocol. The multisig hack was not a case of the underlying application being compromised. The contract itself was compromised due to a vulnerability in its code. The only parties affected were those that trusted the contract. The rest of the contracts operating on the application were unaffected.
the problem is that the tools don't facilitate writing correct contracts
i don't know how to do this myself, mind your. to be broadly applicable the tech has to be accessible to people who would be writing contracts. a fucking professional using the state of the art for this shit has very little tooling support for checking that the contract actually operates in a particular fashion.
something like an SQL query planner that helps you write contracts
i don't know how to do this myself, mind your. to be broadly applicable the tech has to be accessible to people who would be writing contracts. a fucking professional using the state of the art for this shit has very little tooling support for checking that the contract actually operates in a particular fashion.
something like an SQL query planner that helps you write contracts
To be fair, traditional "dumb" contracts written by lawyers also have exploits and loopholes. That's why we have courts with judges and juries that can make subjective decisions based on context outside of the contract. Smart contracts don't allow for that subjective judgment, and thus won't work in a subjective society.
That's a different subject. I was only addressing the notion that Ethereum the application is at risk from the code that users run on it.
I completely agree that the tools and processes for writing and testing smart contracts need to improve.
I completely agree that the tools and processes for writing and testing smart contracts need to improve.
Write your own tools.
The EVM, which is what executes contracts, has a public spec. It's a bytecode machine and writing a compiler for it should be rather trivial compared to x86.
There are also several other languages you can code in and there are some code verifier tools that allow you to check if your contract is good.
The problem is that despite these tools existing, even if they are used, they are underused.
The EVM, which is what executes contracts, has a public spec. It's a bytecode machine and writing a compiler for it should be rather trivial compared to x86.
There are also several other languages you can code in and there are some code verifier tools that allow you to check if your contract is good.
The problem is that despite these tools existing, even if they are used, they are underused.
Writing custom tools is not a solution for the standard professional developer. If Ethereum is to take off, it will need one of
* Little to none "get up and running" time. Custom tools don't allow for that.
* Provide such tremendous value that it is worth overcoming the initial setup hurdle.
Right now, Ethereum has neither.
* Little to none "get up and running" time. Custom tools don't allow for that.
* Provide such tremendous value that it is worth overcoming the initial setup hurdle.
Right now, Ethereum has neither.
There are plenty of alternative tools for Ethereum, including alternative languages.
I was merely pointing out that nobody is being stopped from improving the situation, if it was as bad as some portrait it.
I was merely pointing out that nobody is being stopped from improving the situation, if it was as bad as some portrait it.
Solidity's relationship to JavaScript is negligible and way overplayed in its marketing. Similarities are entirely superficial.
This 100%. I think this becomes evident almost as soon as one tries to do any smart contract coding. It's an entirely different paradigm with considerations that dwarf anything about language syntax and style. In fact I think these considerations are very non-trivial to grasp.
I agree, the syntax being similar doesn't really mean much for similarity when it comes to actually solving problems.
What would be an example of a "smart contract"?
Their main use case is maintaining critical/sensitive state information that you want to protect via rules of interaction between multiple parties (that don't trust each other) without the need for a trusted intermediary. The contract is tamper proof and only via correctly and cryptographically signing messages/transactions intended for the smart contract will the state of the smart contract change, but only according to the rules defined in the smart contract.
The (non-fintec) example I often hear about often is a voting system. (See: https://github.com/stonecoldpat/anonymousvoting , here zk-snarks algorithm is introduced to ensure privacy)
Essentially anything that requires co-ordination between parties that don't trust each other over a piece of data (a balance of money, the tally of a ballot) is a perfect use case for smart contracts. But since there is cost to running it on these secure networks it is important that they remain O(1) or at most O(n) time complexity, which for these kinds of applications is often totally enough. (eg. if (the message is signed by the 'owner') { send the funds } else { throw })
The (non-fintec) example I often hear about often is a voting system. (See: https://github.com/stonecoldpat/anonymousvoting , here zk-snarks algorithm is introduced to ensure privacy)
Essentially anything that requires co-ordination between parties that don't trust each other over a piece of data (a balance of money, the tally of a ballot) is a perfect use case for smart contracts. But since there is cost to running it on these secure networks it is important that they remain O(1) or at most O(n) time complexity, which for these kinds of applications is often totally enough. (eg. if (the message is signed by the 'owner') { send the funds } else { throw })
Another interesting use case is for supply chain management, since the history of a interactions relating product can be documented in a secure manner Eg. you can buy a nike shoe that you can cryptographically validate that it was signed off by Nike, who made it, when they made it, when it was shipped, and even how much each of these parties got paid for their service. (Take a listen here: https://media.consensys.net/state-change-44-shining-a-light-...)
Basic smart contract found here:
https://blockgeeks.com/guides/smart-contracts/
https://blockgeeks.com/guides/smart-contracts/
A kickstarter clone, that could be implemented in a few lines of code on top of Ethereum..
If there is > 1,000 Ether in this contract address before timestamp x then send the Ether to the project lead, else refund all the users.
If there is > 1,000 Ether in this contract address before timestamp x then send the Ether to the project lead, else refund all the users.
Nice! Thank you. You know there are many different types of contracts, why didn't they just call it 'smart transactions'?
Because it's conceptually more like a contract. Someone writes the contract code, and then by uploading and depositing money into the contract it's as if they signed it. After that point it works without anyone needing to trust the signer.
And they can include conditions about arbitrary information that is reported on the blockchain (weather data, stock prices, etc...)
And multiple people can sign these things. They really are like contracts.
And they can include conditions about arbitrary information that is reported on the blockchain (weather data, stock prices, etc...)
And multiple people can sign these things. They really are like contracts.
I can write secure smart contracts in Solidity or straight in EVM assembly, it's really not that hard as long as you code it defensively.
A law can only can be as bug free as software?
100% bug free software is impossible! As long as they are written by humans? Their will always be bugs. Matter who is writting them.
100% bug free software is impossible! As long as they are written by humans? Their will always be bugs. Matter who is writting them.
It doesn't need to be bug free if there are checks and balances. Like an independent contract layer that holds funds in escrow for 10 days and allow a third party to cancel fraudulent transaction under certain conditions.
You don't need to prevent all bad behaviors, just slow attackers down.
Of course sometimes they can get through the review process too, but you start having probabilities you can multiply to decrease the likelihood of losses.
Over time we'll start to have good defaults for how those checks work. For now it's the wild west.
You don't need to prevent all bad behaviors, just slow attackers down.
Of course sometimes they can get through the review process too, but you start having probabilities you can multiply to decrease the likelihood of losses.
Over time we'll start to have good defaults for how those checks work. For now it's the wild west.
i'd like formally verified laws if i could
I dislike algorithms that I understand, and I distrust algorithms that I don't when it comes to stuff like social security or insurance.
Smart contracts by composition would be really nice. Like a compile to EVM lisp!
Smart contracts by composition would be really nice. Like a compile to EVM lisp!
Related: could we please have a Lisp for Ethereum VM? Thanks!
Lisp programmers know the value of everything and the gas cost of nothing...
Yeah if someone's working on it, please link. Would contribute
Nice thanks! Is this officialy supported still?
No problem! It looks like there is some activity in its github repository:
https://github.com/ethereum/solidity/tree/develop/liblll
https://github.com/ethereum/solidity/issues?utf8=%E2%9C%93&q...
https://github.com/ethereum/solidity/tree/develop/liblll
https://github.com/ethereum/solidity/issues?utf8=%E2%9C%93&q...
This might be possible at some point, but for that we first need to figure out how to formalize intent and meaning. In real-world laws, both are extremely important.
[deleted]
People were saying the same thing about non-C++ back in the day. "Web apps aren't written in scripting languages y'know?"
I view this more as "web apps should not be written in C++ due to security issues that we have long come to understand" than "web apps should be written in C++ due to performance issues we are guessing at"... like, do you believe that in a few years people will decide "no, strongly typed and proof assisted languages were overkill for contracts: it was actually better to code them in a language that has weirdly fluid rules and type semantics for reasons they did not quite grok in 2017"?
The main thing to keep in mind at this point in time is that these contracts have very little tolerance for inefficiency, since inefficiency in this case costs money. Even solidity is very inefficient. Sure it would be great to write contracts in Haskell or Coq but can you insure O(1) or at most O(n) run time with little to no constant overhead? For example LLL (Low-Level Lisp-Like Language) produces 70% more efficient code than solidity [1] and thus it is the chosen language for the ENS (Ethereum Name Service) registry smart contract (who wouldn't want to pay 70 less for interacting with a contract?). But no doubt, better languages will come with time :)
[1] https://media.consensys.net/an-introduction-to-lll-for-ether...
[1] https://media.consensys.net/an-introduction-to-lll-for-ether...
This criticism doesn't apply to Ethereum. Solidity is compiled to a VM. You can write other languages that meet your criteria that still use Ethereum.
I know, and I am very excited for those languages to exist and be usable, and thereby have been tracking a couple such efforts; until then, this is about as useful as pointing out that website development is theoretically possible using a computer. The person did not state that it would always be the case that smart contracts are hard: only that right now, on Ethereum, they are hard, and the comment even used "gotten to the point where" (indicating this is a temporary state) and specifically blamed the "tools", which is all absolutely true and is born out not just in theory but in practice; it doesn't even disagree with your own statements that other different tools would be better. Why are you so defensive about this commentary?
I'm like a goalie. Defense is my game.
Actually, I didn't mean to come across as defensive. I just like to nerd out about tech.
Once you accept the inherent craziness of the proposal, and go "Ok, this is crazy. What now?" you end up concluding that the future is going to be very interesting. It'd be worth investing some amount (that you can afford to lose!) in ETH on the off-chance that it doesn't suffer a major disaster. There are quite a few interesting applications for this technology, and historically that's been a pretty solid bet.
Actually, I didn't mean to come across as defensive. I just like to nerd out about tech.
Once you accept the inherent craziness of the proposal, and go "Ok, this is crazy. What now?" you end up concluding that the future is going to be very interesting. It'd be worth investing some amount (that you can afford to lose!) in ETH on the off-chance that it doesn't suffer a major disaster. There are quite a few interesting applications for this technology, and historically that's been a pretty solid bet.
Difference being that a poorly written web app amounts to some leaked passwords and email addresses.
A poorly written smart contract that handles real money, on the other hand...
A poorly written smart contract that handles real money, on the other hand...
So? It's their money to lose.
Yes, it's crazy, but it's also happening.
Yes, it's crazy, but it's also happening.
Agreed, and the massive hacks and losses will continue as long as smart contracts are written in Solidity.
The EVM is Turing-complete, so this will be a risk with any language that compiles into a smart contract.
Solidity doesn't appeal to me because its goal seems to be on-boarding JavaScript programmers. But new languages that compile to EVM can be easier to use "safely" and you will see several of these in the next few years.
I'm really excited that a project to embed Turing-complete behavior in a blockchain has actually taken off. It's completely insane from one perspective, but completely awesome from another.
Solidity doesn't appeal to me because its goal seems to be on-boarding JavaScript programmers. But new languages that compile to EVM can be easier to use "safely" and you will see several of these in the next few years.
I'm really excited that a project to embed Turing-complete behavior in a blockchain has actually taken off. It's completely insane from one perspective, but completely awesome from another.
The EVM might be Turing complete but you can still have languages that compile down to only some tractable sub-set of the possible EVM programs.
The interesting question is whether a language can be design which allows the important domain-relevant requirements to written down in an understandable way and also proved rigorously.
So far neither lawyers nor programmers have done a very good job of this in their respective field. Watching people trying to do it in both fields simultaneously sounds like popcorn time to me.
The interesting question is whether a language can be design which allows the important domain-relevant requirements to written down in an understandable way and also proved rigorously.
So far neither lawyers nor programmers have done a very good job of this in their respective field. Watching people trying to do it in both fields simultaneously sounds like popcorn time to me.
Huh? Lawyers have done an exceptional job. There are huge swaths of activity around which there is consensus about legal dogma.
And huge swaths of activity where programmers have laid out clear deterministic expectations.
If you're saying lawyers have failed to specify the legal ramifications of All Possible Activity then... Sure. So? Even if Ethereum only works for one single narrowly defined contract, it could be immensely useful.
The question for me isn't "where could it fall short" but "where might it measure up?"
And huge swaths of activity where programmers have laid out clear deterministic expectations.
If you're saying lawyers have failed to specify the legal ramifications of All Possible Activity then... Sure. So? Even if Ethereum only works for one single narrowly defined contract, it could be immensely useful.
The question for me isn't "where could it fall short" but "where might it measure up?"
The EVM might be turing-complete but since you can only get finite number of execution cycles, you can usually determine the behaviour of your program or if it halts within the current gas limits.
...passwords that might be reused for the email addresses, and paypal, and...
A web app might not touch real money, but a leak can still have real money consequences for the users.
A web app might not touch real money, but a leak can still have real money consequences for the users.
Sure, but in theory I can change passwords and maintain separate credentials for my banking-related needs.
Short of auditing the Solidity contract code myself, there's nothing I can do to protect myself from the hacks themselves because the very mechanism by which money is transferred is riddled with bugs.
This is mostly just semantics anyway - I'm just trying to establish that writing money-transfer software in a poorly designed language is, one way or another, worse than writing a web app in one.
Short of auditing the Solidity contract code myself, there's nothing I can do to protect myself from the hacks themselves because the very mechanism by which money is transferred is riddled with bugs.
This is mostly just semantics anyway - I'm just trying to establish that writing money-transfer software in a poorly designed language is, one way or another, worse than writing a web app in one.
There are also other consequences:
- vulnerabilities can be used to attack users directly or through social engineering
- (rare today, but definitely a problem with C++ web apps) you can break through a hole in the app and pwn the whole server
- vulnerabilities can be used to attack users directly or through social engineering
- (rare today, but definitely a problem with C++ web apps) you can break through a hole in the app and pwn the whole server
Ethereum allows you to write a program that executes on the blockchain. State variables are synchronized the same way that a Bitcoin blockchain synchronizes sums. (This means it's impossible to have private state that's also synchronized via a blockchain, but in many applications private state isn't needed.)
[deleted]
What does the code have access to other than the blockchain? Can it access the internet? The node's computer?
From my limited understanding, a smart contract essentially runs in a VM with a dedicated memory space that is unique to that contract (and copied along with the contract). However, there is a limited ability for it to interact with other contracts via their (hard-coded) addresses. So a contract can, for example, listen for events occurring with a specific contract, and invoke itself based on the results. It can do this because parts of a contract's memory space are private (I think this is how it works), and so a contract can have secret keys and manage money.
Moreover, a point that was not made clear to me when I first read about Ethereum, the programs are inherently limited in the number of steps that can be run, and the VM monitors this and terminates the program prematurely if it exceeds the limit. Moreover, longer programs cost the caller (the person or other contract asking the network to run this program) more money.
Moreover, a point that was not made clear to me when I first read about Ethereum, the programs are inherently limited in the number of steps that can be run, and the VM monitors this and terminates the program prematurely if it exceeds the limit. Moreover, longer programs cost the caller (the person or other contract asking the network to run this program) more money.
You can access external data from Ethereum contracts via what they call an "Oracle" which is an intermediary between a third party service and the blockchain.
If the connection to the third party service is cryptographically secure, the Oracle can even provide proof the results were not tampered with, and if multiple data sources are used it can provide a consensus answer based on them.
Otherwise, the smart contract only has access to what is in the blockchain, but Oracles are pretty easy to write and use.
If the connection to the third party service is cryptographically secure, the Oracle can even provide proof the results were not tampered with, and if multiple data sources are used it can provide a consensus answer based on them.
Otherwise, the smart contract only has access to what is in the blockchain, but Oracles are pretty easy to write and use.
You cannot access internet information from the evm. All data must be in the blockchain. Any transaction, ie smart contract execution, must be on immutable data inside the chain.
This is a good question, and it's one I've wondered about. There's nothing stopping you from designing and deploying a blockchain similar to Ethereum that does allow access to those things.
The problem is trust. It's helpful to remember that all the participants in an Ethereum network are adversarial. It doesn't matter how many bad actors there are as long as >50% of participants agree on the outcome. (This is a simplified explanation -- the real system is transitioning to proof of stake rather than proof of work.)
If you allow solidity to access the internet or the system compilers, you can't guarantee determinism anymore. For example, if you increment a counter by the result of accessing https://some-value.com (which returns a JSON value), you could program it to return a different result for everyone who accesses it. None of the nodes would agree what the true value of the counter should be. It'd also result in a central point of failure.
These same problems exist if you let Solidity access the system software. You could program it to give different results, so no one would agree.
The innovation of Solidity is that it's a set of operations where no matter what you do, the majority of nodes will converge to the same answer.
The problem is trust. It's helpful to remember that all the participants in an Ethereum network are adversarial. It doesn't matter how many bad actors there are as long as >50% of participants agree on the outcome. (This is a simplified explanation -- the real system is transitioning to proof of stake rather than proof of work.)
If you allow solidity to access the internet or the system compilers, you can't guarantee determinism anymore. For example, if you increment a counter by the result of accessing https://some-value.com (which returns a JSON value), you could program it to return a different result for everyone who accesses it. None of the nodes would agree what the true value of the counter should be. It'd also result in a central point of failure.
These same problems exist if you let Solidity access the system software. You could program it to give different results, so no one would agree.
The innovation of Solidity is that it's a set of operations where no matter what you do, the majority of nodes will converge to the same answer.
Would it not be possible to write a contract that has intentionally random results? Could you not use the timestamp or some other piece of data to flip a coin to determine the outcome?
Does the EVM prevent this in some way?
I did some searching but I'm not sure I know what to look for either.
Does the EVM prevent this in some way?
I did some searching but I'm not sure I know what to look for either.
May I humbly suggest my Hello World tutorial for a quick overview of smart contracts in ethereum?
https://steemit.com/ethereum/@decentralised/hello-world-revi...
https://steemit.com/ethereum/@decentralised/hello-world-revi...
you and everyone else is going to love this but if you want a "smart contracts for dummies" look towards the law: thats right the very thing smart contracts are marketed to replace not only controls but defines smart contracts themselves.
So far a few states (US) have passed laws regarding "blockchains", "smart contracts" and the like. For example, seeking to avoid any legal uncertainty surrounding blockchain transactions and smart contracts relating to certain digital assets, Arizona passed HB 2417, the following on point:
- A very specific definition of “blockchain technology” as a “distributed, decentralized, shared and replicated ledger, which may be public or private, permissioned or permissionless, or driven by tokenized crypto economics or tokenless” and provides that the “data on the ledger is protected with cryptography, is immutable and auditable and provides an uncensored truth.”
-A definition of “smart contracts” as an “event driven program, with state, that runs on a distributed, decentralized, shared and replicated ledger that can take custody over and instruct transfer of assets on that ledger.”
Other states in various stages of legislation on point include: Maine, Illinois, Nevada, Delaware and Vermont.
interesting notes: Arizona also passed a seperate law restricting the use of blockchain as "fire arm tracking technology", likely a pro gun rights lobbying effort. Delaware will likely be codifying by statute the right to issue stock on blockchains. Courts have begun accepting blockchain entries as business records under the rules of evidence.
So far a few states (US) have passed laws regarding "blockchains", "smart contracts" and the like. For example, seeking to avoid any legal uncertainty surrounding blockchain transactions and smart contracts relating to certain digital assets, Arizona passed HB 2417, the following on point:
- A very specific definition of “blockchain technology” as a “distributed, decentralized, shared and replicated ledger, which may be public or private, permissioned or permissionless, or driven by tokenized crypto economics or tokenless” and provides that the “data on the ledger is protected with cryptography, is immutable and auditable and provides an uncensored truth.”
-A definition of “smart contracts” as an “event driven program, with state, that runs on a distributed, decentralized, shared and replicated ledger that can take custody over and instruct transfer of assets on that ledger.”
Other states in various stages of legislation on point include: Maine, Illinois, Nevada, Delaware and Vermont.
interesting notes: Arizona also passed a seperate law restricting the use of blockchain as "fire arm tracking technology", likely a pro gun rights lobbying effort. Delaware will likely be codifying by statute the right to issue stock on blockchains. Courts have begun accepting blockchain entries as business records under the rules of evidence.
Imagine you and your friends are for some reason dissatisfied with the way you are able to deal with money among yourselves.
For example, maybe you like to quickly reimburse each other for dinner, but you won't or can't use Facebook Messenger payments, perhaps because some of you aren't on Facebook, or you're not in the US.
So you want to make your own little payments system. You might start with just setting up a simple server that tracks your debts, with a simple web app to log in and send funds. Suddenly it's much easier for you to pay each other!
Once that works, you realize it would be really neat to have group payments, where you can automatically split a dinner bill, for example. And then maybe you'll even want to kind of crowdfund your dinners, so that any of you can put up a request that says "please send me 5$ each until tomorrow at 4 and I'll order food." You can see this becoming more and more complex.
This is kind of the evolution of blockchain going from simple transactions towards arbitrary smart contracts.
A contract on Ethereum is basically just an address that's associated with a little script in a stack machine bytecode. When you send a message to such a contract, you're actually signing a transaction that says "I hereby perform the instructions of this contract with these given parameters."
For example, the bytecode of contract X might be:
So this contract, when transacted with, would split the ETH value sent to it in half and send to "address 1" and "address 2".
The neat thing about this blockchain thing, compared to a Messenger-style central server, is that you can federate the service in a P2P way, so several of the friends can run a node that verifies all the history, and nobody needs to be trusted with an admin password that can change history.
The neat thing about having those smart contracts on the blockchain instead of as proprietary code is that each participant can (in principle) look at the contract's definition and know for sure what it does, and the contract can't be changed arbitrarily.
For example, maybe you like to quickly reimburse each other for dinner, but you won't or can't use Facebook Messenger payments, perhaps because some of you aren't on Facebook, or you're not in the US.
So you want to make your own little payments system. You might start with just setting up a simple server that tracks your debts, with a simple web app to log in and send funds. Suddenly it's much easier for you to pay each other!
Once that works, you realize it would be really neat to have group payments, where you can automatically split a dinner bill, for example. And then maybe you'll even want to kind of crowdfund your dinners, so that any of you can put up a request that says "please send me 5$ each until tomorrow at 4 and I'll order food." You can see this becoming more and more complex.
This is kind of the evolution of blockchain going from simple transactions towards arbitrary smart contracts.
A contract on Ethereum is basically just an address that's associated with a little script in a stack machine bytecode. When you send a message to such a contract, you're actually signing a transaction that says "I hereby perform the instructions of this contract with these given parameters."
For example, the bytecode of contract X might be:
VALUE 2 DIV DUP <address-1> SEND <address-2> SEND
So this contract, when transacted with, would split the ETH value sent to it in half and send to "address 1" and "address 2".
The neat thing about this blockchain thing, compared to a Messenger-style central server, is that you can federate the service in a P2P way, so several of the friends can run a node that verifies all the history, and nobody needs to be trusted with an admin password that can change history.
The neat thing about having those smart contracts on the blockchain instead of as proprietary code is that each participant can (in principle) look at the contract's definition and know for sure what it does, and the contract can't be changed arbitrarily.
Recognizing it's merely an example, I think nonetheless it would be good to present examples that are actually compelling.
Let's think about your example and what it entails.
So you're going to a pizza party with your friends, and instead of saying to your buddy Mike who you're about to see in person and share some pizza with, "Hey Mike, here's 5 bucks, thanks!"
Instead you fire up the ol' ethereum whizbang machine, and "pay" Mike. The payment then rattles around the ol' globally distributed whizbang machine, at the SPEED of Light! powered by electricity through countless microscopic electronic gating mechanisms before finally settling into the storage media of thousands of computers around the world, where it will stay, forever.
That seems needlessly wasteful of resources and expensive.
What it boils down to, is what is this good for?
While some may have been, not everyone was confounded by the introduction of the web. Many could see obvious avenues of potential and development.
Even back in the 60s or 70s people were envisioning computer network enabled home shopping. Not sure many were envisioning a global distributed turing complete whatchamacallit with ever expanding resource needs because of no garbage collection by design.
So simply, what's the point? What do you do with it besides buy pizzas with your friends? How is it better than existing methods for doing whatever you envision doing with it?
What if anything, does it enable that would otherwise be impossible?
Let's think about your example and what it entails.
So you're going to a pizza party with your friends, and instead of saying to your buddy Mike who you're about to see in person and share some pizza with, "Hey Mike, here's 5 bucks, thanks!"
Instead you fire up the ol' ethereum whizbang machine, and "pay" Mike. The payment then rattles around the ol' globally distributed whizbang machine, at the SPEED of Light! powered by electricity through countless microscopic electronic gating mechanisms before finally settling into the storage media of thousands of computers around the world, where it will stay, forever.
That seems needlessly wasteful of resources and expensive.
What it boils down to, is what is this good for?
While some may have been, not everyone was confounded by the introduction of the web. Many could see obvious avenues of potential and development.
Even back in the 60s or 70s people were envisioning computer network enabled home shopping. Not sure many were envisioning a global distributed turing complete whatchamacallit with ever expanding resource needs because of no garbage collection by design.
So simply, what's the point? What do you do with it besides buy pizzas with your friends? How is it better than existing methods for doing whatever you envision doing with it?
What if anything, does it enable that would otherwise be impossible?
You could make a similarly incredulous argument that messenger apps are totally ridiculous because why would you use a 500 dollar handheld computer to write a message through the "internet" when you could just talk IRL?
I mean, like, within three years you'll probably be having a virtual reality pizza party with your friends on the other side of the world. That's less wasteful of resources than flying, you know! And how will the money work? Maybe with a blockchain.
Let's try to stretch the imagination even more! Imagine you are involved with an open source project. You want to be able to receive some donations, collectively. So you briefly consider setting up a PayPal account, then giggle. "Ha-ha! Why would I use PayPal when these smart contract blockchains technologies have been working well for many years?"
So instead you go to one of the future's several competing smart contract platforms, and you click "Set up budgeted donation contract." It asks you to input the parameters for your donation contract. Maybe you end up configuring something like "Every week, this account's balance will be allocated as follows: 25% to GitHub; 50% split among these N core developers; 25% to the fund; and 25% to the EFF."
Your fans and users can then verify the behavior of this donation contract and easily contribute to your project! Wow! So much cooler than PayPal!
I mean, like, within three years you'll probably be having a virtual reality pizza party with your friends on the other side of the world. That's less wasteful of resources than flying, you know! And how will the money work? Maybe with a blockchain.
Let's try to stretch the imagination even more! Imagine you are involved with an open source project. You want to be able to receive some donations, collectively. So you briefly consider setting up a PayPal account, then giggle. "Ha-ha! Why would I use PayPal when these smart contract blockchains technologies have been working well for many years?"
So instead you go to one of the future's several competing smart contract platforms, and you click "Set up budgeted donation contract." It asks you to input the parameters for your donation contract. Maybe you end up configuring something like "Every week, this account's balance will be allocated as follows: 25% to GitHub; 50% split among these N core developers; 25% to the fund; and 25% to the EFF."
Your fans and users can then verify the behavior of this donation contract and easily contribute to your project! Wow! So much cooler than PayPal!
So simply, what's the point?
How is it better than existing methods for doing whatever you envision doing with it?
What if anything, does it enable that would otherwise be impossible?
So you've got nothing?
"Ha-ha! Why would I use PayPal when these smart contract blockchains technologies have been working well for many years?"
So instead you go to one of the future's several competing smart contract platforms
Simply positing a future scenario is not an argument for it's likelihood.
Why do I need a massively parallel system with enough energy to power a city to do this when I could just do it manually, or write a script to do it and run it locally? If one of the donators doesn't trust me or my code, then they can just donate to wherever directly.
I don't even get your scenario, what value is there in me/my contract being an intermediary between my fans and these other organizations? (and isn't GitHub a for profit company? Why would you donate money to them?)
How is it better than existing methods for doing whatever you envision doing with it?
What if anything, does it enable that would otherwise be impossible?
So you've got nothing?
"Ha-ha! Why would I use PayPal when these smart contract blockchains technologies have been working well for many years?"
So instead you go to one of the future's several competing smart contract platforms
Simply positing a future scenario is not an argument for it's likelihood.
Why do I need a massively parallel system with enough energy to power a city to do this when I could just do it manually, or write a script to do it and run it locally? If one of the donators doesn't trust me or my code, then they can just donate to wherever directly.
I don't even get your scenario, what value is there in me/my contract being an intermediary between my fans and these other organizations? (and isn't GitHub a for profit company? Why would you donate money to them?)
"So you've got nothing?"
Since you immediately reject my examples so completely, I think I won't persuade you. Good for you -- I won't fool you into wasting your time on this obviously pointless blockchain thing.
Since you immediately reject my examples so completely, I think I won't persuade you. Good for you -- I won't fool you into wasting your time on this obviously pointless blockchain thing.
That's a good lesson for me when wondering whether to include something, to leave it out.
Maybe, you'd like to address the questions I raised and points of logic I made rather than the snark.
Maybe, you'd like to address the questions I raised and points of logic I made rather than the snark.
Here's basically all I'm saying.
1. Payments and value management on the internet currently suck horribly compared to what you could imagine. (Insert your own imaginations here, since you don't like mine.)
2. Some attempts are being done to make payments and value management on the internet more convenient, but they are controlled by central authorities -- Facebook, Apple, Google, Twitter, Amazon, whatever -- so they will exclude, censor, limit, and control. (Just like Twitter controls your API access, Facebook forces you to use your real name, Amazon surveils your preferences, etc etc etc.)
3. Blockchains are the only way I know of to do this kind of thing without that kind of central authority, in a thoroughly open source way.
4. I can quite easily imagine a future when blockchains make it very convenient and nice for individuals and organizations to do payments and value management on the internet, in various creative and interesting ways.
Bonus point:
5. Resource use is indeed something to consider. (That also goes for, like, why are we using so many torrent boxes to seed Game of Thrones? Kinda useless! Stop wasting teh energies!) It is indeed also something that is being very actively considered by leading blockchain developers; for example, it's the major project that Vitalik Buterin is spending his waking hours on, in the form of scaling through proof-of-stake. There are highly functional versions of proof-of-stake already working for years, notably BitShares and Steemit, but they use a form of delegated voting that the Ethereum community mostly doesn't want.
1. Payments and value management on the internet currently suck horribly compared to what you could imagine. (Insert your own imaginations here, since you don't like mine.)
2. Some attempts are being done to make payments and value management on the internet more convenient, but they are controlled by central authorities -- Facebook, Apple, Google, Twitter, Amazon, whatever -- so they will exclude, censor, limit, and control. (Just like Twitter controls your API access, Facebook forces you to use your real name, Amazon surveils your preferences, etc etc etc.)
3. Blockchains are the only way I know of to do this kind of thing without that kind of central authority, in a thoroughly open source way.
4. I can quite easily imagine a future when blockchains make it very convenient and nice for individuals and organizations to do payments and value management on the internet, in various creative and interesting ways.
Bonus point:
5. Resource use is indeed something to consider. (That also goes for, like, why are we using so many torrent boxes to seed Game of Thrones? Kinda useless! Stop wasting teh energies!) It is indeed also something that is being very actively considered by leading blockchain developers; for example, it's the major project that Vitalik Buterin is spending his waking hours on, in the form of scaling through proof-of-stake. There are highly functional versions of proof-of-stake already working for years, notably BitShares and Steemit, but they use a form of delegated voting that the Ethereum community mostly doesn't want.
" Blockchains are the only way I know of to do this kind of thing without that kind of central authority, in a thoroughly open source way."
Alternatively, the banks or payment companies are a series of non-profit foundations with protections or basic rights of customers built into their charter using regular, efficient databases with zero or low cost transfer between them. You pay a small, monthly fee to participate with your specific bank which may be waived if you do a lot of business with them. You get regular statements authenticated by the bank's HSM w/ hashes of those posted in one or more trusted, timestamping services for event bank's records are lost. Any major changes to practices might receive a majority vote by customers or people representing them from a diverse background.
So, basically traditional banks with legal incentives to not do bad stuff run by people whose background is pretty trustworthy. Many examples exist of coops, credit unions, and nonprofits that take care of customers due to good incentives. The admin overhead is kept lean per charters. The tech is vastly more efficient than proof-of-work-type schemes since it's just database transactions. Better cost/efficiency than before since new banks aren't stuck on expensive mainframes. ;) What you think?
Alternatively, the banks or payment companies are a series of non-profit foundations with protections or basic rights of customers built into their charter using regular, efficient databases with zero or low cost transfer between them. You pay a small, monthly fee to participate with your specific bank which may be waived if you do a lot of business with them. You get regular statements authenticated by the bank's HSM w/ hashes of those posted in one or more trusted, timestamping services for event bank's records are lost. Any major changes to practices might receive a majority vote by customers or people representing them from a diverse background.
So, basically traditional banks with legal incentives to not do bad stuff run by people whose background is pretty trustworthy. Many examples exist of coops, credit unions, and nonprofits that take care of customers due to good incentives. The admin overhead is kept lean per charters. The tech is vastly more efficient than proof-of-work-type schemes since it's just database transactions. Better cost/efficiency than before since new banks aren't stuck on expensive mainframes. ;) What you think?
I'm interested in such schemes, but I suspect that the best way to implement it would resemble a delegated proof of stake blockchain.
What it can enable/improve upon according to Goldman Sachs [0]:
Assorted banking use cases, trade settlements, payments to notaries, voting systems, vehicle registrations, wire fees, gun checks, academic records, cataloging ownership of works of art.
The Ethereum alliance contains many big name companies such as Mastercard as Cisco [1]. They all believe there is real use in Ethereum
[0] http://www.goldmansachs.com/our-thinking/pages/macroeconomic...
[1] https://entethalliance.org/
Assorted banking use cases, trade settlements, payments to notaries, voting systems, vehicle registrations, wire fees, gun checks, academic records, cataloging ownership of works of art.
The Ethereum alliance contains many big name companies such as Mastercard as Cisco [1]. They all believe there is real use in Ethereum
[0] http://www.goldmansachs.com/our-thinking/pages/macroeconomic...
[1] https://entethalliance.org/
That's a lot of effort to spare yourself a conversation about convention within your friends and a small money pot.
Smart contracts fit really well for generally managing securities, developping auto hedging portfolios.
Smart contracts fit really well for generally managing securities, developping auto hedging portfolios.
> That's a lot of effort to spare yourself a conversation about convention within your friends and a small money pot.
Hey, that was an example meant to explain difficult concepts through terms most people will be familiar with. You can't judge it like this.
Somewhat related, and maybe I'm revealing my stupidity here, but I wish someone explained securities to me in a simple way.
Hey, that was an example meant to explain difficult concepts through terms most people will be familiar with. You can't judge it like this.
Somewhat related, and maybe I'm revealing my stupidity here, but I wish someone explained securities to me in a simple way.
I'm stupid as well so don't take this as gospel.
A security is a fictional asset used to represent higher level operations one can conduct on an underlying asset. Basically it's all the made up tradable assets.
The specific definition varies depending on jurisdiction but if I remember correctly the SEC goes with something like any token that is used to transfer unrealised value between traders or across time.
About your example, I understand that but I'm sorry to see that all examples we collectively come up with for smart contracts are even more constrained than hello worlds and in my humble opinion unfit for the "real purpose" of the EVM. The same line of reasoning applies to bitcoin: it's not a wallet to pay your coffee or receive your salary, but an alternative to banks/payment processors when you need it.
Likewise in my opinion again, the EVM isn't made to replace informal contracts or legal/notarial/... affairs but to provide an alternative when the costs/benefits of contract law aren't fit for your use case.
A security is a fictional asset used to represent higher level operations one can conduct on an underlying asset. Basically it's all the made up tradable assets.
The specific definition varies depending on jurisdiction but if I remember correctly the SEC goes with something like any token that is used to transfer unrealised value between traders or across time.
About your example, I understand that but I'm sorry to see that all examples we collectively come up with for smart contracts are even more constrained than hello worlds and in my humble opinion unfit for the "real purpose" of the EVM. The same line of reasoning applies to bitcoin: it's not a wallet to pay your coffee or receive your salary, but an alternative to banks/payment processors when you need it.
Likewise in my opinion again, the EVM isn't made to replace informal contracts or legal/notarial/... affairs but to provide an alternative when the costs/benefits of contract law aren't fit for your use case.
Thanks. I wonder why it's called "security" (as in, safety from attacks).
> I understand that but I'm sorry to see that all examples we collectively come up with for smart contracts are even more constrained than hello worlds and in my humble opinion unfit for the "real purpose" of the EVM. The same line of reasoning applies to bitcoin: it's not a wallet to pay your coffee or receive your salary, but an alternative to banks/payment processors when you need it.
Fair enough, though I think that we need both, and preferably together. Those trivial examples are actually useful to people the very first time they try to understand the basics of cryptocurrencies and smart contracts. And after that, when someone gets the basic mechanics of the process, I think an example should follow with a description of actual use, and how the same mechanics facilitate it.
> Likewise in my opinion again, the EVM isn't made to replace informal contracts or legal/notarial/... affairs but to provide an alternative when the costs/benefits of contract law aren't fit for your use case.
I agree, I see it this way too. I cringe when I see people hopeful for replacing legal system with ETH, because that would be just plain dumb. But an alternative option to use when it fits better? I'm very much in favour.
> I understand that but I'm sorry to see that all examples we collectively come up with for smart contracts are even more constrained than hello worlds and in my humble opinion unfit for the "real purpose" of the EVM. The same line of reasoning applies to bitcoin: it's not a wallet to pay your coffee or receive your salary, but an alternative to banks/payment processors when you need it.
Fair enough, though I think that we need both, and preferably together. Those trivial examples are actually useful to people the very first time they try to understand the basics of cryptocurrencies and smart contracts. And after that, when someone gets the basic mechanics of the process, I think an example should follow with a description of actual use, and how the same mechanics facilitate it.
> Likewise in my opinion again, the EVM isn't made to replace informal contracts or legal/notarial/... affairs but to provide an alternative when the costs/benefits of contract law aren't fit for your use case.
I agree, I see it this way too. I cringe when I see people hopeful for replacing legal system with ETH, because that would be just plain dumb. But an alternative option to use when it fits better? I'm very much in favour.
As far as I understand the term security refers to the properties of such assets that make them useful to hedge or otherwise balance the tradebook without having to worry about the concrete underlying assets' particulars.
That's why I hope that smart contract systems will make this kind of thing much easier in the near future. That's also part of what I'm working on. It might be easy for a small group to manage with a convention and an informal money pot, but if you're a bigger network (an organization or even a network of organizations) then budgeting and tracking payments becomes more difficult.
Thanks! This is an easier to digest explanation.
What about another use case that's also fairly mundane but is date/time triggered and has a slightly different result/outcome?
Say someone wants to use ethereum to manage the sending of a bunch of birthday cards to friends.
Is it possible for an ethereum script be set up to trigger an event on a specific day to send a pre-composed email along with some funds (e.g. bitcoin or ethereum).
What about another use case that's also fairly mundane but is date/time triggered and has a slightly different result/outcome?
Say someone wants to use ethereum to manage the sending of a bunch of birthday cards to friends.
Is it possible for an ethereum script be set up to trigger an event on a specific day to send a pre-composed email along with some funds (e.g. bitcoin or ethereum).
The Ethereum blockchain is reactive, it only performs any effects when someone makes a transaction. So you can't directly do something like a timer.
So, for example, with crowdfund contracts that have an expiration time, you would typically just make it so that after the expiration time, if the crowdfund didn't succeed, then everyone can reclaim their funds. They aren't refunded automatically; you need some user action to trigger anything.
It would be possible to have a single "refundEveryone" method which would send all the funds to everyone when anyone called it. But if there were thousands of participants, this function would be expensive to call, and possibly even too expensive for the network's limits.
The standard solution to this limitation is that you just have to incentivize people to call your contract at the right time. So you can for example make it so that whoever is the first to call the contract after the deadline gets a reward. Then you publish that and hope someone will do it.
(A simpler solution is to just run a cronjob on your own computer...)
So, for example, with crowdfund contracts that have an expiration time, you would typically just make it so that after the expiration time, if the crowdfund didn't succeed, then everyone can reclaim their funds. They aren't refunded automatically; you need some user action to trigger anything.
It would be possible to have a single "refundEveryone" method which would send all the funds to everyone when anyone called it. But if there were thousands of participants, this function would be expensive to call, and possibly even too expensive for the network's limits.
The standard solution to this limitation is that you just have to incentivize people to call your contract at the right time. So you can for example make it so that whoever is the first to call the contract after the deadline gets a reward. Then you publish that and hope someone will do it.
(A simpler solution is to just run a cronjob on your own computer...)
I hereby perform the instructions of this contract with these given parameters
How big can be the parameters? Megabytes is possible?
How big can be the parameters? Megabytes is possible?
I like to think of smart contracts as ways to program money. Imagine if you could program a dollar bill. Then there's lots of cool stuff that could be done :)
If you could program money, you might not really need insurers anymore. You could just program insuree's money so it redistributed appropriately in case of flooding (for eg). No need to give you money to an entity and have a conflict of interest with your insurer.
Smart contracts are ways to program money by sending it to special addresses. These addresses contain a script that will decide how to redistribute the money. It's like if you insurance was a program.
If you could program money, you might not really need insurers anymore. You could just program insuree's money so it redistributed appropriately in case of flooding (for eg). No need to give you money to an entity and have a conflict of interest with your insurer.
Smart contracts are ways to program money by sending it to special addresses. These addresses contain a script that will decide how to redistribute the money. It's like if you insurance was a program.
It's like if you insurance was a program.
That's an interesting way to think about it, but how do you communicate to the program that a tree fell on your car and you need it to give you money for a new one?
Basically what's the mechanism for communicating certain cases or conditions to the program, how does the program verify the claims you make to it, and how many of the scenarios where that works are practical for any real world applications?
That's an interesting way to think about it, but how do you communicate to the program that a tree fell on your car and you need it to give you money for a new one?
Basically what's the mechanism for communicating certain cases or conditions to the program, how does the program verify the claims you make to it, and how many of the scenarios where that works are practical for any real world applications?
I'd argue most consumer insurance programs depend a lot on interpretation. You don't want to be exposed to Inadvertent Algorthmic Cruelty when you're in a situation where your civil insurance should kick in.
IMO Smart contracts are a good way to model and trade securities, options or futures instead, leaving the underlying assets to be managed by real world humans who can make things happen out of the blockchain.
IMO Smart contracts are a good way to model and trade securities, options or futures instead, leaving the underlying assets to be managed by real world humans who can make things happen out of the blockchain.
You'd still be able to rely on human interpreters, who would do all the on-the-ground work the insurance adjuster does. There would be a clearinghouse for those jobs, and contractors would do them.
The incentives could be set up such that the cost of being caught straying from protocol would be higher than the fraud opportunity.
Or you could just reply on network-of-trust. Brand loyalty, etc. Choose Aetna claim investigators! We Follow Protocol
The incentives could be set up such that the cost of being caught straying from protocol would be higher than the fraud opportunity.
Or you could just reply on network-of-trust. Brand loyalty, etc. Choose Aetna claim investigators! We Follow Protocol
Hi all, I'm the author of the post, and also the creator of the website. I'm writing this series of posts to demonstrate the site. Do you guys get what the site's trying to do?
Hope you enjoy the post. If you have any constructive criticism you'd like to give regarding either the post or the website, let me know!
Hope you enjoy the post. If you have any constructive criticism you'd like to give regarding either the post or the website, let me know!
You should add a button or some kind of subscription opt-in add the end. I just want to be notified for the future updates in this series.
Hi, I'm the author of RLPx. Great post and thank you for sharing! Looking forward to more.
I really enjoyed your post and look forward to reading the series. I would suggest you try out Steemit.com as this is their business model as well, they already have a large community, and this type of post/series would be like catnip over there.
Bad news! Your site is vulnerable to XSS https://ocalog.com/post/15/
See "OWASP top 10" for getting started with web security.
See "OWASP top 10" for getting started with web security.
ty
There are no uses for turing complete smart contracts on a blockchain
Since Dropbox episode we don't tell people that nobody has any usage of their product.
Of course, us maximalists all know Bitcoin is the pinnacle and can never be improved on. /s
It can be improved on, but blockchain is REALLY REALLY hard
Except any reasonably complex interactions between parties which may or may not be accounting applications yet still need a distributed system of trust.
Which includes a few trillion dollar industries.
Which includes a few trillion dollar industries.
Registered assets are always more secure and cheaper than bearer assets. And if you needed bearer assets, there's multisig, which does everything turing complete code does, cheaper and more secure
Its the interactions between assets, agreements and trusted devices which opens up possibilities greater than the scope of this thinking.
I see. What blockchain does the NYSE use?
I don't talk to their developer teams so I wouldn't know. I wouldn't expect them to move quickly enough for that to have been publicly announced by now. My guess is either ethereum or hyperledger fabric depending on how much of their system they would want completely public. Queries per second is a huge concern there too, so it might be a while off for NYSE for this reason alone.
You may be right about this.
Just today I started to look into RLPx to do some basic network discovery, so your guide is quite nice to have as a reference. But I had some difficulties getting started, because the RLPx spec was not simple to find (ethereum wiki -> devp2p -> RLPx) and is quite terse. I myself wasn't able to decode the packet structure.
Looking into ethereum related stuff I often get the feeling that one already needs to know half of ethereum quite decent to learn something new, which makes it hard to even get started.
Reading your guide (am not finished yet) gives me a better picture of the things I actually need to do, to start discovering some nodes, so I'm really thankful for that and hope for more beginner targeted ethereum content.
Looking into ethereum related stuff I often get the feeling that one already needs to know half of ethereum quite decent to learn something new, which makes it hard to even get started.
Reading your guide (am not finished yet) gives me a better picture of the things I actually need to do, to start discovering some nodes, so I'm really thankful for that and hope for more beginner targeted ethereum content.
[deleted]
Who ends up owning the content when a writer writes on your website?
So this is like Medium but with monetised upvotes? Who would pay for upvotes? (and in particular, for a subscription)
Subscribers. Creators can mark their posts as free, as I have done here, but if posts are not marked free you have to subscribe to view them.
Unless you're a seed user (first 1000 people who sign up), then you don't have to subscribe to view non-free posts.
Unless you're a seed user (first 1000 people who sign up), then you don't have to subscribe to view non-free posts.
Just started to copycat your code to rust, not yet finished, continuing tomorrow
https://github.com/Roxxik/ping_ether/blob/master/src/main.rs
https://github.com/Roxxik/ping_ether/blob/master/src/main.rs
Hi! Thank you all for the attention! I was not expecting it!
It seems that the user registration emails are causing a 500 server error and I'm working on a fix.
Edit: I'm bypassing the email confirmations for now, if you got a 500 error, please try to login using the account you signed up with. It should work, otherwise email me at mflynn210 <at> gmail.com.
It seems that the user registration emails are causing a 500 server error and I'm working on a fix.
Edit: I'm bypassing the email confirmations for now, if you got a 500 error, please try to login using the account you signed up with. It should work, otherwise email me at mflynn210 <at> gmail.com.
Wasn't the purpose of bitcoin to eventually hit a limit someday? Isn't the creation of Ethereum just devaluing bitcoin?
If you are taking about the issuing of Bitcoins, yes, at some far distant point in the future, no more Bitcoin will be issused.
Bitcoin and Ethereum have very different intended use cases, as this article demonstrates. You could argue that Ethereum could be a threat to Bitcoin, or coexist, depending on your perspective.
Bitcoin and Ethereum have very different intended use cases, as this article demonstrates. You could argue that Ethereum could be a threat to Bitcoin, or coexist, depending on your perspective.
Ponzi pumping
I like the intro, very clear! I also like the narrative cross-referencing the docs, which people will sooner or later need to do as well. I have to admit that I only glanced over the code.
This caught my attention: "In the EndPoint specification, it demands the "BE encoded 4-byte" address, which is exactly what's outputted by self.address.packed."
Does this mean that Ethereum only supports IPv4?
I searched around and only found this, dating back to 2014: https://github.com/ethereum/wiki/wiki/IPv6
This caught my attention: "In the EndPoint specification, it demands the "BE encoded 4-byte" address, which is exactly what's outputted by self.address.packed."
Does this mean that Ethereum only supports IPv4?
I searched around and only found this, dating back to 2014: https://github.com/ethereum/wiki/wiki/IPv6
documentation says it all:
"bytes address; // BE encoded 4-byte or 16-byte address (size determines ipv4 vs ipv6)"[0]
[0]: https://github.com/ethereum/devp2p/blob/master/rlpx.md
"bytes address; // BE encoded 4-byte or 16-byte address (size determines ipv4 vs ipv6)"[0]
[0]: https://github.com/ethereum/devp2p/blob/master/rlpx.md
thanks!
Neat. I contemplated writing something like that, only without the "import rlp" cheat.
Basically, there were a lot of blind spots in the official documentation and it took me a while to figure out things like how to make a proper key recovery id or which endianness to use where in the messages.
How far have you been able to get to? I still can't quite wedge into the mainnet - the nodes keep disconnecting me for unknown reasons some time after, and finding a new node to connect to takes a while.
My node does works rather well on the ropsten testnet, however.
Basically, there were a lot of blind spots in the official documentation and it took me a while to figure out things like how to make a proper key recovery id or which endianness to use where in the messages.
How far have you been able to get to? I still can't quite wedge into the mainnet - the nodes keep disconnecting me for unknown reasons some time after, and finding a new node to connect to takes a while.
My node does works rather well on the ropsten testnet, however.
> the "import rlp" cheat.
Ah, I knew someone was going to get me on that. They actually give you the encode function in the specification. It's pretty straightforward and if I was to write it, would end up the same, so I decided to just import the library. But I agree it does go against the "from scratch" title a little bit.
> there were a lot of blind spots in the official documentation
Totally agree.
> How far have you been able to get to?
I'm actually trying to get the mainnet nodes to talk to me as well.
Ah, I knew someone was going to get me on that. They actually give you the encode function in the specification. It's pretty straightforward and if I was to write it, would end up the same, so I decided to just import the library. But I agree it does go against the "from scratch" title a little bit.
> there were a lot of blind spots in the official documentation
Totally agree.
> How far have you been able to get to?
I'm actually trying to get the mainnet nodes to talk to me as well.
excellent thank you
Java Magazine published an article on Ethereum, explaining how it works, and how to access from Java [1]
[1] http://www.javamagazine.mozaicreader.com/JanFeb2017#&pageSet...
[1] http://www.javamagazine.mozaicreader.com/JanFeb2017#&pageSet...
This is a very useful resource, thank you!
As one of the 'killer apps' for ethereum is smart contracts, I'd like to see this explained in a 'for dummies' high level way, then decomposed into the finer technical chunks needed to make it happen.