So, the geth monitoring-node first seems to have imported the same one as reported above:
Jan 06 23:29:21 geth-testnet: I0106 22:29:21.064938 core/blockchain.go:1073] imported 1 blocks, 14 txs ( 0.348 Mg) in 19.168ms (18.180 Mg/s). #296151 [779e9f95…]
A hash 0x779e9f9558143be43f3eeb58ad1aa7764a03cf7f1bda4d1c29c2e1244d5e606f.
Then, a bit later on:
There are a few modules around that let you keep track of the "state" of a transaction (unconfirmed, X confirmations, conflicting transaction exists and is being confirmed, fully confirmed, definitely failed) and represent this info in the UI with color-coding. You should then probably only make "irreversible" changes to the data that's represented in the UI ...
Set up 2 connected geth instances on your private network and start them mining.
There is an admin.addPeer(...) command in geth to add peer nodes to the geth's list of peers, but there does not seem to be any commands to remove these peers.
To simulate the fork, block the network ports used by both instances of geth for their peer-to-peer ...
We've had an unexpected fork in the past that caused a split between clients. While no hardfork is like any hardfork we generally follow these rules and steps:
Identify and announce the issue;
Create a test to replicate the problem;
Fix (very important step :-P) and mark the forked block;
Release it out on to the public (usually special care goes out to ...
The Homestead block will be 1.150.000 for the main network which means
the Homestead transition will be roughly around midday on Pi day and
the Homestead block for the Morden network will be 494.000.
A soft fork means that a state/block that used to to be valid is not valid any more in the new version. In this case a state that would result in spending ETH from any contract with the code of theDAO would be considered invalid. A hard fork makes a state valid that was not valid before.
The big advantage of a soft fork is that only miners need to update ...
A pool miner would not have to update their mining software (ethminer or equivalent) to go to the forked version of the chain.
It is up to the pool, running the Ethereum node software (geth, parity or equivalent) to update that software to go to the forked version of the chain.
Moving pools is the only way to participate in the forked version if you are a ...
No, there is no difference in this case-- they are essentially equivalent. If the tx is orphaned, they should return null, but you should still check the block number because it may have been added to the new chain later than you expect, giving less probability of finality.
Yes, Byzantium brings some exciting changes that Smart contract developers should be aware of:
REVERT - This new call stops execution of a transaction and reverts
all state, but, unlike throw it returns all unused gas.
In Solidity, the require method now should use REVERT internally meaning, if you require something and it is not met, state will be ...
Parity should be run in RPC mode as follows:
parity --chain ropsten --light --no-serve-light --jsonrpc-port=8545
And then the following command works to issue a fork:
ganache-cli --fork http://localhost:8545
Suppose a soft fork with Rule R. We have two miners groups: the group G1 (with the rule R) and group G2 (without the rule R).
Suppose that The Hacker sends a transaction contrary to the Rule R. This transaction is refused by the group G1 and accepted by the group G2. If a miner of G2 wins the PoW, it creates a new Block B. This block is ignored by the miner ...
If you open the document you will find the answer.
If block.number >= HOMESTEAD_FORK_BLKNUM (eg. 100,000,000 (NOT YET SET IN STONE!) on livenet and Morden
At this moment it's simply not decided yet.
Edit, this has been confirmed now.
The Homestead block will be 1.150.000 for the main network which means the Homestead transition will be roughly ...
Note that this question isn't about the number of uncle/orphan blocks that can be incorporated into a canonical block. That number is 2, as defined in the code.
This question is about the length of the side-chain created by an ephemeral fork, which happens when two miners find the PoW solution to a given block at the same time. It's then possible for these ...
Yes, the hashrate will be split and the difficulty on both ends will go down. A prominent example in the wild the the fork-off of the Ethereum Classic chain at block number 1920000, see table below (block number / Ethereum difficulty / Classic difficulty):
# ETH ETC
1920000 62.41 T 62.41 T
1921000 57.01 T 0.83 T
1922000 56.80 T ...
Your coins seem to be in your account on the public blockchain explorer, so I don't think you have to worry.
The next step is to work out what has happened in your local wallet. Presumably you are using the Ethereum Wallet. Check the block number (like 2,105,732 currently) on the top of your Ethereum Wallet screen. This should match the latest block in ...
To the protocol, there's no difference between the various kinds of storage (hot, cold, paper, etc.) All it knows is that a given key corresponds to a given address. So there wouldn't be anything pertaining to cold storage per se--it should all still work.
But it's remotely possible that due to the nature of a fork that everyone, regardless of how they ...
Ether is in both chains.
If you start making transactions from both chains, you need to be very careful of replay attacks. See
What is a replay attack? and
How to prevent a replay attack between two competing chains?
For example, if you give someone legacy Ether without doing any precautions, they can replay that transaction and obtain that same Ether on ...
Yes, the same contract can be mined on both sides of the fork.
I don't think it's correct that each instance of the contract creation would yield a different contract address. Contract addresses are assigned deterministically based on the address creating them and a per-account nonce, so the same transaction, received on both forks in the same order, would ...
The block gasLimit is in each block. Example:
If the gasLimit of the next block decreases, it suggests that the client is running the fork mode to try to bring the gasLimit below 4M.
EIP2 will be released on Pi Day (Mar 14, 2016) at block 1,150,000.
There is already the homestead website prototype available for testing.
On reddit there is a call for updating the documentation for homestead.
In the devcon1 keynote Vitalik Buterin said homestead is to be expected when the ethereum network, miners and other critical components work without ...
This is a community wiki. If releases of other clients are available, please edit the list below.
EVERYONE: Update clients!
Upgrade geth nodes at least to version 1.3.5
Upgrade ++eth nodes to at least version 1.2.2
Upgrade mist browser to at least version 0.5.1
Upgrade parity nodes to at least version 0.9.1
Upgrade ethereumj nodes to at least version 1.2.0
Execution of the opcode will change even in old contracts. An example of this is revert. Solidity added support for require and revert style errors prior to the Byzantium fork, but when the opcode was activated before the hardfork it just worked as an error. The same deployed contracts after the fork used the opcode to revert without eating all the gas.
Yes, but they are routine and are less of a concern than they would be if the Bitcoin algorithm was arbitrarily speeded up, Ethereum's proof-of-work is not merely bitcoin's with a faster blocktime.
The concern is that faster blocks imply a predictable increase in branching because of network latency, and consequently faster blocks leads to loss of hash ...
Yes, forks are possible in Proof of Stake.
Here is an example. Assume Alice (A) is the proposer for slot 1 and Bob (B) for slot 2. The genesis (G) block is slot 0.
Alice creates the block at slot 1. This chain is G->A.
Bob never saw Alice's block so he creates the block at slot 2. This chain is G->empty->B.
There's now 2 forks. Charlie, the proposer ...
Yes, any invalid opcode already doubles as an abort.
The point of EIP-141 is to guarantee to developers that no future hard fork will implement some non-aborting opcode at 0xFE.
It didn't require nodes to upgrade. It is not a change that requires a hard fork or a soft fork, because it is not a change at all. It is just the absence of a potential future ...
Ethereum is a brand new thing.
Vitalik Butterin et al created it in 2014 from scratch. The only thing they used is the concept of blockchain initiated by Satoshi Nakamoto (we still don't know who he really is) and the experience of how Bitcoin works and fails.
See Ethereum Homestead documentation :
took forever for me as well, with lots of timouts, but started again but never got fully stuck.
geth --rpc --nat=none --cache=2024
this then did speed things up a bit, but still took days.
to confirm you have synced
open seperate cmd and
to confirm how far behind you are.
A fork is just like a change (upgrade) in the rules of the blockchain on which the coin operates. This upgrade (fork) splits the blockchain in two different branches with their different versions (after updation).
Now, There are only two types of forks which can upgrade this blockchain technology.
LET'S COME TO THEM
1. Soft Fork : When anyone (anycoin) ...
From my understanding if you just use the Official software you cannot decide to fork, because adding blocks to the blockchain is done automatically. If you do decide to fork I think you need to modify the source code and put some extra logic on how, where and when you want to add a new block to the blockchain.
For the second part of your question: if a ...
How are these conflicts reduced when block confirmation time is low...
The conflicts aren't reduced, and there is a greater number of orphaned blocks.
Ethereum handles this using its GHOST protocol, in which miners are incentivised - by way of an increased block reward - to include the orphaned blocks in the main chain.