Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: Status of Ethereum  (Read 1699 times)

Offline bytemaster

Status of Ethereum
« on: December 29, 2014, 08:13:32 PM »

Could someone do some research for me:

1) What consensus algorithm are they using?
2) How is their genesis allocation specified?
3) When are they launching?

Here are my thoughts: 
With a small amount of work we can make an ethereum side chain that honors BTS and allows people to move funds between the two chains easily. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline btswildpig

  • Hero Member
  • *****
  • Posts: 1404
    • View Profile
Re: Status of Ethereum
« Reply #1 on: December 29, 2014, 08:18:32 PM »
whitepaper vb edited 5 days ago

https://github.com/ethereum/wiki/wiki/White-Paper


Blockchain and Mining

apply_block_diagram.png

The Ethereum blockchain is in many ways similar to the Bitcoin blockchain, although it does have some differences. The main difference between Ethereum and Bitcoin with regard to the blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state. Aside from that, two other values, the block number and the difficulty, are also stored in the block. The basic block validation algorithm in Ethereum is as follows:

Check if the previous block referenced exists and is valid.
Check that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the future
Check that the block number, difficulty, transaction root, uncle root and gas limit (various low-level Ethereum-specific concepts) are valid.
Check that the proof of work on the block is valid.
Let S[0] be the state at the end of the previous block.
Let TX be the block's transaction list, with n transactions. For all in in 0...n-1, set S[i+1] = APPLY(S,TX). If any applications returns an error, or if the total gas consumed in the block up until this point exceeds the GASLIMIT, return an error.
Let S_FINAL be S[n], but adding the block reward paid to the miner.
Check if the Merkle tree root of the state S_FINAL is equal to the final state root provided in the block header. If it is, the block is valid; otherwise, it is not valid.
The approach may seem highly inefficient at first glance, because it needs to store the entire state with each block, but in reality efficiency should be comparable to that of Bitcoin. The reason is that the state is stored in the tree structure, and after every block only a small part of the tree needs to be changed. Thus, in general, between two adjacent blocks the vast majority of the tree should be the same, and therefore the data can be stored once and referenced twice using pointers (ie. hashes of subtrees). A special kind of tree known as a "Patricia tree" is used to accomplish this, including a modification to the Merkle tree concept that allows for nodes to be inserted and deleted, and not just changed, efficiently. Additionally, because all of the state information is part of the last block, there is no need to store the entire blockchain history - a strategy which, if it could be applied to Bitcoin, can be calculated to provide 5-20x savings in space.

A commonly asked question is "where" contract code is executed, in terms of physical hardware. This has a simple answer: the process of executing contract code is part of the definition of the state transition function, which is part of the block validation algorithm, so if a transaction is added into block B the code execution spawned by that transaction will be executed by all nodes, now and in the future, that download and validate block B.
这个是私人账号,表达的一切言论均不代表任何团队和任何人。This is my personal account , anything I said with this account will be my opinion alone and has nothing to do with any group.

Offline btswildpig

  • Hero Member
  • *****
  • Posts: 1404
    • View Profile
Re: Status of Ethereum
« Reply #2 on: December 29, 2014, 08:21:18 PM »
Next March is the est time , at least that's what i've heard of.
这个是私人账号,表达的一切言论均不代表任何团队和任何人。This is my personal account , anything I said with this account will be my opinion alone and has nothing to do with any group.

Offline luckybit

Re: Status of Ethereum
« Reply #3 on: December 29, 2014, 08:21:49 PM »
Quote

 ## Ethereum
 
+The intent of Ethereum is to merge together and improve upon the concepts of scripting, altcoins and on-chain meta-protocols, and allow developers to create arbitrary consensus-based applications that have the scalability, standardization, feature-completeness, ease of development and interoperability offered by these different paradigms all at the same time. Ethereum does this by building what is essentially the ultimate abstract foundational layer: a blockchain with a built-in Turing-complete programming language, allowing anyone to write smart contracts and decentralized applications where they can create their own arbitrary rules for ownership, transaction formats and state transition functions. A bare-bones version of Namecoin can be written in two lines of code, and other protocols like currencies and reputation systems can be built in under twenty. Smart contracts, cryptographic "boxes" that contain value and only unlock it if certain conditions are met, can also be built on top of the platform, with vastly more power than that offered by Bitcoin scripting because of the added powers of Turing-completeness, value-awareness, blockchain-awareness and state.
 
 ### Ethereum Accounts
 
@@ -151,15 +151,38 @@ In Ethereum, the state is made up of objects called "accounts", with each accoun
 * The account's **contract code**, if present
 * The account's **storage** (empty by default)
 
+"Ether" is the main internal crypto-fuel of Ethereum, and is used to pay transaction fees. In general, there are two types of accounts: **externally owned accounts**, controlled by private keys, and **contract accounts**, controlled by their contract code. An externally owned account has no code, and one can send messages from an externally owned account by creating and signing a transaction; in a contract account, every time the contract account receives a message its code activates, allowing it to read and write to internal storage and send other messages or create contracts in turn.
+
+Note that "contracts" in Ethereum should not be seen as something that should be "fulfilled" or "complied with"; rather, they are more like "autonomous agents" that live inside of the Ethereum execution environment, always executing a specific piece of code when "poked" by a message or transaction, and having direct control over their own ether balance and their own key/value store to keep track of persistent variables.
 
 ### Messages and Transactions

+The term "transaction" is used in Ethereum to refer to the signed data package that stores a message to be sent from an externally owned account. Transactions contain:
+
+* The recipient of the message
+* A signature identifying the sender
+* The amount of ether to transfer from the sender to the recipient
+* An optional data field
+* A `STARTGAS` value, representing the maximum number of computational steps the transaction execution is allowed to take
+* A `GASPRICE` value, representing the fee the sender pays per computational step
+
+The first three are standard fields expected in any cryptocurrency. The data field has no function by default, but the virtual machine has an opcode using which a contract can access the data; as an example use case, if a contract is functioning as an on-blockchain domain registration service, then it may wish to interpret the data being passed to it as containing two "fields", the first field being a domain to register and the second field being the IP address to register it two. The contract would read these values from the message data and appropriately place them in storage.
+
+The `STARTGAS` and `GASPRICE` fields are crucial for Ethereum's anti-denial of service model. In order to prevent accidental or hostile infinite loops or other computational wastage in code, each transaction is required to set a limit to how many computational steps of code execution it can use. The fundamental unit of computation is "gas"; usually, a computational step costs 1 gas, but some operations cost higher amounts of gas because they are more computationally expensive, or increase the amount of data that must be stored as part of the state. There is also a fee of 5 gas for every byte in the transaction data. The intent of the fee system is to require an attacker to pay proportionately for every resource that they consume, including computation, bandwidth and storage; hence, any transaction that leads to the network consuming a greater amount of any of these resources must have a gas fee roughly proportional to the increment.
+
+### Messages
 
+* The sender of the message (implicit)
+* The recipient of the message
+* The amount of ether to transfer alongside the message
+* An optional data field
+* A `STARTGAS` value
+
+Essentially, a message is like a transaction, except it is produced by a contract and not an external actor. A message is only produced if a contract currently executing code executes the `CALL` opcode, which produces and executes a message. Like a transaction, a message leads to the receipient account running its code. Thus, contracts can have relationships with other contracts in exactly the same way that external actors can.
+
+Note that the gas allowance assigned by a transaction or contract applies to the total gas consumed by that transaction and all sub-executions. For example, if an external actor A sends a transaction to B with 1000 gas, and B consumes 600 gas before sending a message to C, and the internal execution of C consumes 300 gas before returning, then B can spend another 100 gas before running out of gas.
 
 ### Ethereum State Transition Function
 
@@ -176,10 +199,10 @@ The Ethereum state transition function, `APPLY(S,TX) -> S'` can be defined as fo
 
 For example, suppose that the contract's code is:
+    if !self.storage[msg.data[0]]:
+        self.storage[msg.data[0]] = msg.data[1]
 
-Note that in reality the contract code is written in the low-level EVM code; this example is written in Serpent, our high-level language, for clarity, and can be compiled down to EVM code. Suppose that the contract's storage starts off empty, and a transaction is sent with 10 ether value, 2000 gas, 0.001 ether gasprice, and two data fields: `[ 2, 'CHARLIE' ]`<sup>[3]</sup>. The process for the state transition function in this case is as follows:
+Note that in reality the contract code is written in the low-level EVM code; this example is written in Serpent, one of our high-level languages, for clarity, and can be compiled down to EVM code. Suppose that the contract's storage starts off empty, and a transaction is sent with 10 ether value, 2000 gas, 0.001 ether gasprice, and two data fields: `[ 2, 'CHARLIE' ]`<sup>[3]</sup>. The process for the state transition function in this case is as follows:
 
 1. Check that the transaction is valid and well formed.
 2. Check that the transaction sender has at least 2000 * 0.001 = 2 ether. If it is, then subtract 2 ether from the sender's account.
@@ -188,7 +211,9 @@ Note that in reality the contract code is written in the low-level EVM code; thi
 4. Run the code. In this case, this is simple: it checks if the contract's storage at index `2` is used, notices that it is not, and so it sets the storage at index `2` to the value `CHARLIE`. Suppose this takes 187 gas, so the remaining amount of gas is 1150 - 187 = 963
 5. Add 963 * 0.001 = 0.963 ether back to the sender's account, and return the resulting state.
 
+If there was no contract at the receiving end of the transaction, then the total transaction fee would simply be equal to the provided `GASPRICE` multiplied by the length of the transaction in bytes, and the data sent alongside the transaction would be irrelevant.
+
+Note that messages work equivalently to transactions in terms of reverts: if a message execution runs out of gas, then that message's execution, and all other executions triggered by that execution, revert, but parent executions do not need to revert. This means that it is "safe" for a contract to call another contract, as if A calls B with G gas then A's execution is guaranteed to lose at most G gas. Finally, note that there is an opcode, `CREATE`, that creates a contract; its execution mechanics are generally similar to `CALL`, with the exception that the output of the execution determines the code of a newly created contract.
 
 ### Code Execution
 
@@ -206,19 +231,21 @@ The formal execution model of EVM code is surprisingly simple. While the Ethereu
 
 ![apply_block_diagram.png](http://vitalik.ca/files/apply_block_diagram.png)

+The Ethereum blockchain is in many ways similar to the Bitcoin blockchain, although it does have some differences. The main difference between Ethereum and Bitcoin with regard to the blockchain architecture is that, unlike Bitcoin, Ethereum blocks contain a copy of both the transaction list and the most recent state. Aside from that, two other values, the block number and the difficulty, are also stored in the block. The basic block validation algorithm in Ethereum is as follows:
 
 1. Check if the previous block referenced exists and is valid.
 2. Check that the timestamp of the block is greater than that of the referenced previous block and less than 15 minutes into the future
 3. Check that the block number, difficulty, transaction root, uncle root and gas limit (various low-level Ethereum-specific concepts) are valid.
 4. Check that the proof of work on the block is valid.
-5. Let `S[0]` be the `STATE_ROOT` of the previous block.
+5. Let `S[0]` be the state at the end of the previous block.
 6. Let `TX` be the block's transaction list, with `n` transactions. For all in in `0...n-1`, set `S[i+1] = APPLY(S,TX)`. If any applications returns an error, or if the total gas consumed in the block up until this point exceeds the `GASLIMIT`, return an error.
 7. Let `S_FINAL` be `S[n]`, but adding the block reward paid to the miner.
+8. Check if the Merkle tree root of the state `S_FINAL` is equal to the final state root provided in the block header. If it is, the block is valid; otherwise, it is not valid.
 
 The approach may seem highly inefficient at first glance, because it needs to store the entire state with each block, but in reality efficiency should be comparable to that of Bitcoin. The reason is that the state is stored in the tree structure, and after every block only a small part of the tree needs to be changed. Thus, in general, between two adjacent blocks the vast majority of the tree should be the same, and therefore the data can be stored once and referenced twice using pointers (ie. hashes of subtrees). A special kind of tree known as a "Patricia tree" is used to accomplish this, including a modification to the Merkle tree concept that allows for nodes to be inserted and deleted, and not just changed, efficiently.  Additionally, because all of the state information is part of the last block, there is no need to store the entire blockchain history - a strategy which, if it could be applied to Bitcoin, can be calculated to provide 10-20x savings in space.
 
+A commonly asked question is "where" contract code is executed, in terms of physical hardware. This has a simple answer: the process of executing contract code is part of the definition of the state transition function, which is part of the block validation algorithm, so if a transaction is added into block `B` the code execution spawned by that transaction will be executed by all nodes, now and in the future, that download and validate block `B`.
+
 ## Applications
 
 In general, there are three types of applications on top of Ethereum. The first category is financial applications, providing users with more powerful ways of managing and entering into contracts using their money. This includes sub-currencies, financial derivatives, hedging contracts, savings wallets, wills, and ultimately even some classes of full-scale employment contracts. The second category is semi-financial applications, where money is involved but there is also a heavy non-monetary side to what is being done; a perfect example is self-enforcing bounties for solutions to computational problems. Finally, there are applications such as online voting and decentralized governance that are not financial at all.
@@ -233,9 +260,9 @@ The basic code for implementing a token system in Serpent looks as follows:
     to = msg.data[0]
     value = msg.data[1]
 
+    if self.storage[from] >= value:
+        self.storage[from] = self.storage[from] - value
+        self.storage[to] = self.storage[to] + value
 
 This is essentially a literal implementation of the "banking system" state transition function described further above in this document. A few extra lines of code need to be added to provide for the initial step of distributing the currency units in the first place and a few other edge cases, and ideally a function would be added to let other contracts query for the balance of an address. But that's all there is to it. Theoretically, Ethereum-based token systems acting as sub-currencies can potentially include another important feature that on-chain Bitcoin-based meta-currencies lack: the ability to pay transaction fees directly in that currency. The way this would be implemented is that the contract would maintain an ether balance with which it would refund ether used to pay fees to the sender, and it would refill this balance by collecting the internal currency units that it takes in fees and reselling them in a constant running auction. Users would thus need to "activate" their accounts with ether, but once the ether is there it would be reusable because the contract would refund it each time.
 
@@ -258,8 +285,8 @@ In practice, however, issuers are not always trustworthy, and in some cases the
 
 The earliest alternative cryptocurrency of all, [Namecoin](http://namecoin.org/), attempted to use a Bitcoin-like blockchain to provide a name registration system, where users can register their names in a public database alongside other data. The major cited use case is for a [DNS](http://en.wikipedia.org/wiki/Domain_Name_System) system, mapping domain names like "bitcoin.org" (or, in Namecoin's case, "bitcoin.bit") to an IP address. Other use cases include email authentication and potentially more advanced reputation systems. Here is the basic contract to provide a Namecoin-like name registration system on Ethereum:

+    if !self.storage[tx.data[0]]:
+        self.storage[tx.data[0]] = tx.data[1]
 
 The contract is very simple; all it is is a database inside the Ethereum network that can be added to, but not modified or removed from. Anyone can register a name with some value, and that registration then sticks forever. A more sophisticated name registration contract will also have a "function clause" allowing other contracts to query it, as well as a mechanism for the "owner" (ie. the first registerer) of a name to change the data or transfer ownership. One can even add reputation and web-of-trust functionality on top.
 
@@ -295,7 +322,7 @@ An alternative model is for a decentralized corporation, where any account can h
 
 Normally, 1% per day is enough for Alice, and if Alice wants to withdraw more she can contact Bob for help. If Alice's key gets hacked, she runs to Bob to move the funds to a new contract. If she loses her key, Bob will get the funds out eventually. If Bob turns out to be malicious, then she can turn off his ability to withdraw.
 
-**2. Crop insurance**. One can easily make a financial derivatives contract but using a data feed of the weather instead of any price index. If a farmer in Iowa purchases a derivative that pays out inversely based on the precipitation in Iowa, then if there is a drought, the farmer will automatically receive money and if there is enough rain the farmer will be happy because their crops would do well.
+**2. Crop insurance**. One can easily make a financial derivatives contract but using a data feed of the weather instead of any price index. If a farmer in Iowa purchases a derivative that pays out inversely based on the precipitation in Iowa, then if there is a drought, the farmer will automatically receive money and if there is enough rain the farmer will be happy because their crops would do well. This can be expanded to natural disaster insurance generally.
 
 **3. A decentralized data feed**. For financial contracts for difference, it may actually be possible to decentralize the data feed via a protocol called "[SchellingCoin](http://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/)". SchellingCoin basically works as follows: N parties all put into the system the value of a given datum (eg. the ETH/USD price), the values are sorted, and everyone between the 25th and 75th percentile gets one token as a reward. Everyone has the incentive to provide the answer that everyone else will provide, and the only value that a large number of players can realistically agree on is the obvious default: the truth. This creates a decentralized protocol that can theoretically provide any number of values, including the ETH/USD price, the temperature in Berlin or even the result of a particular hard computation.
 
@@ -372,9 +399,6 @@ Now, send a transaction to A. Thus, in 51 transactions, we have a contract that
 The Ethereum network includes its own built-in currency, ether, which serves the dual purpose of providing a primary liquidity layer to allow for efficient exchange between various types of digital assets and, more importantly, of providing a mechanism for paying transaction fees. For convenience and to avoid future argument (see the current mBTC/uBTC/satoshi debate in Bitcoin), the denominations will be pre-labelled:
 
 * 1: wei
-* 10<sup>3</sup>: lovelace
-* 10<sup>6</sup>: babbage
-* 10<sup>9</sup>: shannon
 * 10<sup>12</sup>: szabo
 * 10<sup>15</sup>: finney
 * 10<sup>18</sup>: ether
@@ -384,16 +408,17 @@ This should be taken as an expanded version of the concept of "dollars" and "cen
 The issuance model will be as follows:
 
 * Ether will be released in a currency sale at the price of 1000-2000 ether per BTC, a mechanism intended to fund the Ethereum organization and pay for development that has been used with success by other platforms such as Mastercoin and NXT. Earlier buyers will benefit from larger discounts. The BTC received from the sale will be used entrirely to pay salaries and bounties to developers and invested into various for-profit and non-profit projects in the Ethereum and cryptocurrency ecosystem.
-* 0.3x the total amount sold will be allocated to the organization to compensate early contributors, pay ETH-denominated expenses before the genesis block and as a long-term reserve. This amount is distributed according to an exponentially decreasing formula; every month, up to 5.6% of the remaining endowment can be distributed among developers and others who participated in project development, and this distribution starts in December.
-* 0.3x the total amount sold will be allocated to miners per year forever after that point
+* 0.099x the total amount sold will be allocated to the organization to compensate early contributors and pay ETH-denominated expenses before the genesis block.
+* 0.099x the total amount sold will be maintained as a long-term reserve.
+* 0.26x the total amount sold will be allocated to miners per year forever after that point.
 
 | Group  | At launch | After 1 year | After 5 years
 | ------------- | ------------- |-------------| ----------- |
+| Currency units  | 1.198X | 1.458X  |  2.498X |
+| Purchasers  | 83.5% | 68.6%  | 40.0% |
+| Reserve spent pre-sale | 8.26% | 6.79% | 3.96% |
+| Reserve used post-sale | 8.26% | 6.79% | 3.96% |
+| Miners | 0% | 17.8% | 52.0% |

 
 **Long-Term Supply Growth Rate (percent)**
 
@@ -411,7 +436,7 @@ The Bitcoin mining algorithm basically works by having miners compute SHA256 on
 
 The current intent at Ethereum is to use a mining algorithm where miners are required to fetch random data from the state, compute some randomly selected transactions from the last N blocks in the blockchain, and return the hash of the result. This has two important benefits. First, Ethereum contracts can include any kind of computation, so an Ethereum ASIC would essentially be an ASIC for general computation - ie. a better CPU. Second, mining requires access to the entire blockchain, forcing miners to store the entire blockchain and at least be capable of verifying every transaction. This removes the need for centralized mining pools; although mining pools can still serve the legitimate role of evening out the randomness of reward distribution, this function can be served equally well by peer-to-peer pools with no central control.

+This model is untested, and there may be difficulties along the way in avoiding certain clever optimizations when using contract execution as a mining algorithm. However, one notably interesting feature of this algorithm is that it allows anyone to "poison the well", by introducing a large number of contracts into the blockchain specifically designed to stymie certain ASICs. The economic incentives exist for ASIC manufacturers to use such a trick to attack each other. Thus, the solution that we are developing is ultimately an adaptive economic human solution rather than purely a technical one.
 
 ### Scalability
 
@@ -459,4 +484,4 @@ The concept of an arbitrary state transition function as implemented by the Ethe
 18. Mike Hearn on Smart Property at Turing Festival: http://www.youtube.com/watch?v=Pu4PAMFPo5Y
 19. Ethereum RLP: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-RLP
 20. Ethereum Merkle Patricia trees: https://github.com/ethereum/wiki/wiki/%5BEnglish%5D-Patricia-Tree
-21. Peter Todd on Merkle sum trees: http://sourceforge.net/p/bitcoin/mailman/message/31709140/
+21. Peter Todd on Merkle sum trees: http://sourceforge.net/p/bitcoin/mailman/message/31709140/

https://github.com/ethereum/wiki/wiki/White-Paper/_compare/08e9d07781f50dac264314a551b5ba060a07c06a...502e0e01355a42c8e6f5463c49cce496ae423179#diff-1eadcd8ba0fdccb4898ccee137c83e58L392
« Last Edit: December 29, 2014, 08:27:06 PM by luckybit »
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline Empirical1.1

  • Hero Member
  • *****
  • Posts: 886
    • View Profile
Re: Status of Ethereum
« Reply #4 on: December 29, 2014, 08:25:17 PM »

Here are my thoughts: 
With a small amount of work we can make an ethereum side chain that honors BTS and allows people to move funds between the two chains easily.

 +5%  +5%

Offline vbuterin

  • Jr. Member
  • **
  • Posts: 32
    • View Profile
Re: Status of Ethereum
« Reply #5 on: December 30, 2014, 01:46:39 AM »
Could someone do some research for me:

1) What consensus algorithm are they using?
2) How is their genesis allocation specified?
3) When are they launching?

Here are my thoughts: 
With a small amount of work we can make an ethereum side chain that honors BTS and allows people to move funds between the two chains easily.

You know that you can send me an email, right, Dan?

1. A modified version of hashimoto PoW for 1.0, plans to move to slasher PoS for 1.1
2. 60102216 ETH to purchasers, 5950119 ETH early contributor premine, 5950119 ETH foundation endowment. A json or other doc will probably be released at some point in the next few months before launch showing the addr:balance combinations.
3. Plan is March 20.

Offline NewMine

  • Hero Member
  • *****
  • Posts: 549
    • View Profile
Re: Status of Ethereum
« Reply #6 on: December 30, 2014, 01:55:50 AM »
Could someone do some research for me:

1) What consensus algorithm are they using?
2) How is their genesis allocation specified?
3) When are they launching?

Here are my thoughts: 
With a small amount of work we can make an ethereum side chain that honors BTS and allows people to move funds between the two chains easily.

You know that you can send me an email, right, Dan?

1. A modified version of hashimoto PoW for 1.0, plans to move to slasher PoS for 1.1
2. 60102216 ETH to purchasers, 5950119 ETH early contributor premine, 5950119 ETH foundation endowment. A json or other doc will probably be released at some point in the next few months before launch showing the addr:balance combinations.
3. Plan is March 20.

Ahh, the ides of March. We've heard that before.

Offline fluxer555

  • Hero Member
  • *****
  • Posts: 601
    • View Profile
Re: Status of Ethereum
« Reply #7 on: December 30, 2014, 03:55:16 AM »
Ahh, the ides of March. We've heard that before.

The Ides of March is actually March 15th.
BTS: flux-tips

Offline Stan

  • Hero Member
  • *****
  • Posts: 2715
  • You need to think BIGGER, Pinky...
    • View Profile
    • Cryptonomex
  • BTS: Stan
Re: Status of Ethereum
« Reply #8 on: December 30, 2014, 04:04:36 AM »
Ahh, the ides of March. We've heard that before.

The Ides of March is actually March 15th.

But its been stretched to, like July, in certain recent historic cases... 8)
Anything said on these forums does not constitute an intent to create a legal obligation or contract of any kind.   These are merely my opinions which I reserve the right to change at any time.

Offline mike623317

  • Hero Member
  • *****
  • Posts: 596
    • View Profile
Re: Status of Ethereum
« Reply #9 on: December 30, 2014, 04:15:50 AM »
1. A modified version of hashimoto PoW for 1.0, plans to move to slasher PoS for 1.1

I didn't realize that ethereum we're going to proof of stake.
Doesn't this give our approach a lot more credibility?

Offline mike623317

  • Hero Member
  • *****
  • Posts: 596
    • View Profile
Re: Status of Ethereum
« Reply #10 on: December 30, 2014, 04:19:35 AM »
Never mind. Confusing pos with our dpos
Newbie :)

Offline monsterer

Re: Status of Ethereum
« Reply #11 on: December 30, 2014, 11:27:31 AM »
Personally, I'd like to see us stop worrying about the competition and just concentrate on getting bitshares solid.
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline fuzzy

Re: Status of Ethereum
« Reply #12 on: December 30, 2014, 12:01:27 PM »
Personally, I'd like to see us stop worrying about the competition and just concentrate on getting bitshares solid.

me too.
BROWNIE==DKP; BitShares is our Community! 
ShareBits Welcome to  the Sharing Economy w/ BeyondBitcoin.org Partners--ShareBits.io & OpenLedger.info
TIP FORMAT: #sharebits "ForumHandleInQuotes" Quanity Token_Name

Offline mike623317

  • Hero Member
  • *****
  • Posts: 596
    • View Profile
Re: Status of Ethereum
« Reply #13 on: December 30, 2014, 12:43:24 PM »

I agree. I think we should devote our over stretched developer resources to finishing what we started. When I read this forum, my take away is people are just itching to get 1.0 and a stable polished platform. I think we feel we have a competitive advantage and want to drive it home as soon as possible.

I just wish we had more developers to spread the load.

Offline matt608

  • Hero Member
  • *****
  • Posts: 878
    • View Profile
Re: Status of Ethereum
« Reply #14 on: December 30, 2014, 12:56:02 PM »

I agree. I think we should devote our over stretched developer resources to finishing what we started. When I read this forum, my take away is people are just itching to get 1.0 and a stable polished platform. I think we feel we have a competitive advantage and want to drive it home as soon as possible.

I just wish we had more developers to spread the load.

Indeed, I'd like some clarification on what happened to DAC Sun, why was the relationship ended?  We need developers and they are fluent in the BitShares coding language, why are they not carrying on work using delegate positions?

 

Google+