If it gets important enough, I'll send it to the awesome list repository.
Feel free to contribute guys!
https://github.com/shi-yan/bingot
It was inspired by another simple crypto currency called basiccoin
https://github.com/zack-bitcoin/basiccoin
at the time, basic coin was only 600 lines of python.
I understand the whole network time = median offset + local time thing, however I'm a bit fuzzy on how you check timestamps on previous blocks when you're initially downloading the chain. How do you know that you need to check the timestamp if you can't know if you're on the latest block?
Latest block or not, it just needs to follow those rules. That does mean it's possible for a block with an invalid timestamp to become valid after some time has passed. But if it is invalid, nobody will be mining on it, so it's unlikely to remain part of the longest chain.
If you include a timestamp in each block, just have each node simply reject times that are out of order or too far from the current time, which will prevent people from mining on an invalid chain. "Current time" meaning nothing more than a few minutes in the future of now. Yes, even when dealing with an old chain.
Here is how it works:
If an invalid or malicious person spends hashrate to mine a block with a bad date, all the nodes in the network will see it and reject the block.
Because the block is rejected, everyone else keeps attempting to mine the same block, but with the correct timestamp. The window is: greater than the last block, less than a couple minutes from now.
Because most miners are on non-malicious nodes, they eventually produce a longer chain than the chain with the bad timestamp.
Because this good chain is longer, new nodes that sync the blockchain from scratch would simply pick the longest of the available chains (which is the good one).
This could still go wrong if the attacker has a large amount of hashrate (or luck) for an extended period of time, but this gets very expensive very fast. This is why it is sometimes good to wait a few blocks before assuming consensus.
My reasoning was roughly as follows:
Miners are incentivized to pick very large timestamps, because the longer it takes to mine X blocks, the easier becomes the proof of work they need to solve, giving them more block rewards and transaction fees in the long run. But if they want the network to accept their blocks, they can't pick timestamps in the future, so the best they can do is pick the current time as their timestamp.
Because other miners are required to use a higher timestamp for their block to be valid, they have no ability to correct my outlier time. You have essentially allowed me to put the blocktime permanently forward by the allotted wiggle room, and also you have allowed me to consume all that space you allocated for miners who have clock skew.
It's overall a small attack, but highlights that even tiny decisions can have consequences that impact security. Bitcoin accounts for this by requiring that timestamps be greater than the median of the past 11 blocks, and that's enough to prevent one evil miner from forcing the block times forward for all blocks.
What you need to consider is whether an attacker can manipulate historical timestamps to get you to follow the wrong blockchain. The answer is, they can't.
The only thing manipulating historical timestamps would accomplish is allow the attacker to change the historical difficulty of their alternative blockchain. But that doesn't enable them to add additional proof of work. The amount of total proof of work they can add to an alternative blockchain is not dictated by difficulty, but merely by how much hashrate they have poured into the chain.
Since total proof of work for a chain is the metric by which the "correct" blockchain is established we can conclude that manipulating historical timestamps doesn't make it any easier for an attacker to get you to follow their chain.
That's for IBD. Obviously you need to verify timestamps after IBD, since timestamps are used to adjust difficulty and that's a consensus critical rule.
- use dns for peer discovery
- implement Script language subset
- implement SegWit
I'm not interested so much in how to write smart contracts, so much as how the miners work, how conflicts are resolved, and how the incentive schemes play out.
Would love to get some reading suggestions!
I agree, insides on the Ethereum tech (like how their proof of work relates to smart contract state, where the DAG fits in) are very brief / difficult to digest at some points.
Ethereum is elegant in many ways - for example, strengthening security by rewarding the linking of orphan blocks in the network. I think there's a need for some better education between the marketing material and War and Peace white/yellow paper ;)
Got me thinking, what are some solid bitcoin/cryptocurrency resources that the HN community would recommend?
I also recommend subscribing to the bitcoin-core-dev mailing list.
It's easy to get most machines in agreement with how long a second is, but it's very very hard to get all nodes in agreement to what the exact time is.
So skip it entirely.
- What makes it potentially more powerful than Bitcoin?
- What are Ethereum Dapps/smart contracts good for and what are they not good for? There are definitely limitations to coding apps on a distributed network where every node has the code
- Developer intro
There's a lot of marketing gimmicky material out there jumping on the buzz word train ("Distributed! Consensus! OSS!") without offering any real value. Something with real substance that is presented effectively would be awesome
Do you mind if I get your email and send you something? Looking at writing about this and would love some feedback.
But even if all miners decide to do as you say and always pick a date slightly in the future but inside the wiggle room, all that they achieve is a one-time very slight difficulty decrease, but by the next difficulty adjustment that's already lost because by then both the start date and end date of the period are offset by the same amount into the future.
There are consequences to having blocks that are permanently set forwards beyond a one-time difficulty decrease of 0.6%.