18 ms·

Tinychain: a pocket-sized implementation of Bitcoin

250 points by jobeirne 9y ago

Hortinstein 9y ago
nice work, this is really cool. Source is very readable, great resource for those looking to understand bitcoin. Can't wait to play around with it and deploy it on my little raspberry pi swarm!
- jobeirne 9y ago
  Thanks! It's definitely meant for forking, hacking on, and experimentation. A few ideas: - use dns for peer discovery - implement Script language subset - implement SegWit
PaulBGD_ 9y ago
I'm working on my own blockchain (not specifically bitcoin) implementation just to wrap my head around everything. One thing I'm not getting that also wasn't answered by the source code is how you check timestamps. 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?
- tyywebb 9y ago
  Couldn't you just do everything in UTC?
  - PaulBGD_ 9y ago
    I'm not sure how that solves anything, since UTC would have the same issues as a UNIX timestamp.
    - joneholland 9y ago
      I'd assume the correct thing to do is a vector clock, where each blocks time stamp is nothing more than a offset from the previous blocks. 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.
- Ded7xSEoPKYNsDd 9y ago
  In my toy blockchain implementation, I just went with two constraints: 1) every timestamp must be strictly larger than the one of the previous block (this makes difficulty calculation easier) 2) timestamps may not be in the future (except for a little wiggle room for unsynchronized clocks) 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.
  - PaulBGD_ 9y ago
    Okay, this makes sense! I keep thinking too strictly with my constraints.
  - Taek 9y ago
    Your method is easily exploited by a malicious miner. Clocks across the network are going to have some inherent amount of skew. By forcing blocks to have incrementing timestamps and also by refusing to accept blocks in the future, you have made it easy for me as a miner to commit abuse. Instead of picking the exact current time, I will pick a time that is as far in the future as the network allows (taking full advantage of the wiggle room). 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.
    - Ded7xSEoPKYNsDd 9y ago
      Yes, if the next block by an honest miner is very quick it will pick a timestamp of (wrong_timestamp + 1) instead of the actual time, but after a few blocks they will certainly able to use the correct time again. 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.
- uobytx 9y ago
  Wouldn't you only need to verify proof-of-work on the largest chain? Largest meaning the highest cumulative difficulty rather than number of blocks. 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.
- jobeirne 9y ago
  A block's timestamp is frozen in its hash, which is validated by any node receiving a block (whether during initial block download or otherwise). Bitcoin and tinychain don't accept blocks with a timestamp in the future beyond some threshold (in both cases 2 hours).
- fpgaminer 9y ago
  AFAIK you don't need to check historical timestamps (beyond sanity checks) during initial block download (IBD). 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.
- Taek 9y ago
  You need to check two things. First you need to check that this block had a timestamp higher than the median of the past 11 blocks (it's a consensus rule). Second you need to check that the timestamp is not unacceptably far in the future. For historic blocks, it definitely won't be because the timestamp will be far in the past (as the block was created far in the past). 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.
  - PaulBGD_ 9y ago
    The median thing makes sense, thanks!
throwaway413 9y ago
Props for the killer README!
- jobeirne 9y ago
  thanks :)
wiremine 9y ago
Currently reading through a book on bitcoin, so this is extremely timely! Got me thinking, what are some solid bitcoin/cryptocurrency resources that the HN community would recommend?
- PaulBGD_ 9y ago
  The original bitcoin paper is fantastic, as well as the wiki.
- jobeirne 9y ago
  I link to some of my favorite resources at the end of this section: https://github.com/jamesob/tinychain#what-is-bitcoin https://github.com/jamesob/tinychain#what-is-bitcoin I also recommend subscribing to the bitcoin-core-dev mailing list.
  - Coreyyd 9y ago
    Are there real hackers?? Yes !! Cos Cyber hacking has caused problems for various companies and customers.. protocolhacks{@}gmail.com, is group of hack team providing help to those who are willing to take the bull buy the horn and SAY NO to online fraudsters Have you been into a very long term relationship before or you currently have someone you havnt seen now for days,weeks,months or even years???? beware of scams PROTOCOL HACKS,protocolhacks@gmail.com we are a team of hackers everywhere on social dating sites,,eradicating and exposing those who call themselves lovers with hidden identities jst to get people scammed,say NO! now and contact us,we solve all problems.Do you need to keep an eye on your spouse by gaining access to their emails,private facebook,whatsapp,skype n many more account? and others to make sure they're not getting into trouble? University grades changing Bank accounts hack Twitters hack email accounts hack Grade Changes hack Website crashed hack server crashed hack Retrieval of lost file/documents Erase criminal records hack Databases hack Sales of Dumps cards of all kinds.. Our lives are now heavily mediated by technology (emailing, social media, e-banking etc). We are increasingly and often continuously online, open to engagement in a myriad of services and simultaneously open to cyberattack. Making sure clients are satisfied. Prices are heavily dependent on the problem you want us to solve
- 9y ago
bhalp1 9y ago
Reminds me of this post: https://dev.to/aunyks/lets-build-the-tiniest-blockchain https://dev.to/aunyks/lets-build-the-tiniest-blockchain
gaetanrickter 9y ago
I can see this useful for all cryptocurrencies as well as alleviating some of the need for hedge funds investing in cryptocurrencies for their clients as brought out here ...Hedge Funds Investing in Cryptocurrencies ‘Exploding’ – 62 in Pipeline https://news.bitcoin.com/hedge-funds-investing-in-cryptocurrencies-exploding-62-in-pipeline/ https://news.bitcoin.com/hedge-funds-investing-in-cryptocurr...
h4l0 9y ago
I'm also working on my own cryptocurrency implementation forked from known basiccoin of Zack Hess. Simply I'm trying to make the code more readable, fix bugs and provide better API. Currently I do not have a fine README that explains my intentions but going through the whole code and rewriting most parts made me realize how simple actually blockchain is. Thinking about fine details like how synchronization of blockchain should work is really inspiring. If you want to take a look at the code it is on https://github.com/halilozercan/halocoin https://github.com/halilozercan/halocoin
- ejanus 9y ago
  I will take a look and would you be willing to answer noob kind of questions?
erikpukinskis 9y ago
I would love to see this for Ethereum. I was able to understand the Bitcoin protocol fairly quickly with a little reading, but I haven't come across much good writing on the mechanics of the Ethereum protocol. All of the intro texts I've seen are about like "Step 1: install the client" kind of stuff. 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!
- agorabinary 9y ago
  I agree, Ethereum needs better reading material. I bought an Ethereum book by Henning Diedrich and it's pretty light to be honest.
  - liamzebedee 9y ago
    What are the top (say, three) things you'd like to learn from such a book? 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 ;)
    - agorabinary 9y ago
      I think it should assume the reader is fairly educated on what Bitcoin is, as most newcomers to Ethereum are probably coming from the Bitcoin space, and then differentiating the two coins. - 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
billconan 9y ago
I have a similar project in 1000 lines or so c++, called bingot https://github.com/shi-yan/bingot https://github.com/shi-yan/bingot It was inspired by another simple crypto currency called basiccoin https://github.com/zack-bitcoin/basiccoin https://github.com/zack-bitcoin/basiccoin at the time, basic coin was only 600 lines of python.
brandonhsiao 9y ago
There should be one of those awesome-* Github repos with a list of lightweight, readable implementations of various protocols/technologies.
- ospider 9y ago
  I want this too, I've seen a number of these implementations, just too lazy to create a list
- jchampem 9y ago
  I just created it: https://github.com/jchampemont/awesome-implementations https://github.com/jchampemont/awesome-implementations If it gets important enough, I'll send it to the awesome list repository. Feel free to contribute guys!
  - mathiasrw 9y ago
    Ahhhhh - missed you by 1 minute... :) https://github.com/mathiasrw/LRIP https://github.com/mathiasrw/LRIP
    - deleted 9y ago
      [deleted]
    - jchampem 9y ago
      Haha it was a close call!
  - brandonhsiao 9y ago
    Nice. Maybe kilo? https://github.com/antirez/kilo https://github.com/antirez/kilo
    - jchampem 9y ago
      Nice suggestion, adding it :)
leipavoi 9y ago
Cool project! Reminds me of Naivechain, a blockchain in 200 lines of code https://github.com/lhartikk/naivechain https://github.com/lhartikk/naivechain

250 points by jobeirne 9y ago

nice work, this is really cool. Source is very readable, great resource for those looking to understand bitcoin. Can't wait to play around with it and deploy it on my little raspberry pi swarm!

jobeirne 9y ago
Thanks! It's definitely meant for forking, hacking on, and experimentation. A few ideas: - use dns for peer discovery - implement Script language subset - implement SegWit

PaulBGD_ 9y ago

I'm working on my own blockchain (not specifically bitcoin) implementation just to wrap my head around everything. One thing I'm not getting that also wasn't answered by the source code is how you check timestamps. 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?

tyywebb 9y ago
Couldn't you just do everything in UTC?
- PaulBGD_ 9y ago
  I'm not sure how that solves anything, since UTC would have the same issues as a UNIX timestamp.
  - joneholland 9y ago
    I'd assume the correct thing to do is a vector clock, where each blocks time stamp is nothing more than a offset from the previous blocks. 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.
Ded7xSEoPKYNsDd 9y ago
In my toy blockchain implementation, I just went with two constraints: 1) every timestamp must be strictly larger than the one of the previous block (this makes difficulty calculation easier) 2) timestamps may not be in the future (except for a little wiggle room for unsynchronized clocks) 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.
- PaulBGD_ 9y ago
  Okay, this makes sense! I keep thinking too strictly with my constraints.
- Taek 9y ago
  Your method is easily exploited by a malicious miner. Clocks across the network are going to have some inherent amount of skew. By forcing blocks to have incrementing timestamps and also by refusing to accept blocks in the future, you have made it easy for me as a miner to commit abuse. Instead of picking the exact current time, I will pick a time that is as far in the future as the network allows (taking full advantage of the wiggle room). 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.
  - Ded7xSEoPKYNsDd 9y ago
    Yes, if the next block by an honest miner is very quick it will pick a timestamp of (wrong_timestamp + 1) instead of the actual time, but after a few blocks they will certainly able to use the correct time again. 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.
uobytx 9y ago
Wouldn't you only need to verify proof-of-work on the largest chain? Largest meaning the highest cumulative difficulty rather than number of blocks. 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.
jobeirne 9y ago
A block's timestamp is frozen in its hash, which is validated by any node receiving a block (whether during initial block download or otherwise). Bitcoin and tinychain don't accept blocks with a timestamp in the future beyond some threshold (in both cases 2 hours).
fpgaminer 9y ago
AFAIK you don't need to check historical timestamps (beyond sanity checks) during initial block download (IBD). 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.
Taek 9y ago
You need to check two things. First you need to check that this block had a timestamp higher than the median of the past 11 blocks (it's a consensus rule). Second you need to check that the timestamp is not unacceptably far in the future. For historic blocks, it definitely won't be because the timestamp will be far in the past (as the block was created far in the past). 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.
- PaulBGD_ 9y ago
  The median thing makes sense, thanks!

throwaway413 9y ago

Props for the killer README!

jobeirne 9y ago
thanks :)

wiremine 9y ago

Currently reading through a book on bitcoin, so this is extremely timely! Got me thinking, what are some solid bitcoin/cryptocurrency resources that the HN community would recommend?

PaulBGD_ 9y ago
The original bitcoin paper is fantastic, as well as the wiki.
jobeirne 9y ago
I link to some of my favorite resources at the end of this section: https://github.com/jamesob/tinychain#what-is-bitcoin https://github.com/jamesob/tinychain#what-is-bitcoin I also recommend subscribing to the bitcoin-core-dev mailing list.
- Coreyyd 9y ago
  Are there real hackers?? Yes !! Cos Cyber hacking has caused problems for various companies and customers.. protocolhacks{@}gmail.com, is group of hack team providing help to those who are willing to take the bull buy the horn and SAY NO to online fraudsters Have you been into a very long term relationship before or you currently have someone you havnt seen now for days,weeks,months or even years???? beware of scams PROTOCOL HACKS,protocolhacks@gmail.com we are a team of hackers everywhere on social dating sites,,eradicating and exposing those who call themselves lovers with hidden identities jst to get people scammed,say NO! now and contact us,we solve all problems.Do you need to keep an eye on your spouse by gaining access to their emails,private facebook,whatsapp,skype n many more account? and others to make sure they're not getting into trouble? University grades changing Bank accounts hack Twitters hack email accounts hack Grade Changes hack Website crashed hack server crashed hack Retrieval of lost file/documents Erase criminal records hack Databases hack Sales of Dumps cards of all kinds.. Our lives are now heavily mediated by technology (emailing, social media, e-banking etc). We are increasingly and often continuously online, open to engagement in a myriad of services and simultaneously open to cyberattack. Making sure clients are satisfied. Prices are heavily dependent on the problem you want us to solve
9y ago

bhalp1 9y ago

Reminds me of this post: https://dev.to/aunyks/lets-build-the-tiniest-blockchain https://dev.to/aunyks/lets-build-the-tiniest-blockchain

gaetanrickter 9y ago

I can see this useful for all cryptocurrencies as well as alleviating some of the need for hedge funds investing in cryptocurrencies for their clients as brought out here ...Hedge Funds Investing in Cryptocurrencies ‘Exploding’ – 62 in Pipeline https://news.bitcoin.com/hedge-funds-investing-in-cryptocurrencies-exploding-62-in-pipeline/ https://news.bitcoin.com/hedge-funds-investing-in-cryptocurr...

h4l0 9y ago

I'm also working on my own cryptocurrency implementation forked from known basiccoin of Zack Hess. Simply I'm trying to make the code more readable, fix bugs and provide better API. Currently I do not have a fine README that explains my intentions but going through the whole code and rewriting most parts made me realize how simple actually blockchain is. Thinking about fine details like how synchronization of blockchain should work is really inspiring. If you want to take a look at the code it is on https://github.com/halilozercan/halocoin https://github.com/halilozercan/halocoin

ejanus 9y ago
I will take a look and would you be willing to answer noob kind of questions?

erikpukinskis 9y ago

I would love to see this for Ethereum. I was able to understand the Bitcoin protocol fairly quickly with a little reading, but I haven't come across much good writing on the mechanics of the Ethereum protocol. All of the intro texts I've seen are about like "Step 1: install the client" kind of stuff. 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!

agorabinary 9y ago
I agree, Ethereum needs better reading material. I bought an Ethereum book by Henning Diedrich and it's pretty light to be honest.
- liamzebedee 9y ago
  What are the top (say, three) things you'd like to learn from such a book? 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 ;)
  - agorabinary 9y ago
    I think it should assume the reader is fairly educated on what Bitcoin is, as most newcomers to Ethereum are probably coming from the Bitcoin space, and then differentiating the two coins. - 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

billconan 9y ago

I have a similar project in 1000 lines or so c++, called bingot https://github.com/shi-yan/bingot https://github.com/shi-yan/bingot It was inspired by another simple crypto currency called basiccoin https://github.com/zack-bitcoin/basiccoin https://github.com/zack-bitcoin/basiccoin at the time, basic coin was only 600 lines of python.

brandonhsiao 9y ago

There should be one of those awesome-* Github repos with a list of lightweight, readable implementations of various protocols/technologies.

ospider 9y ago
I want this too, I've seen a number of these implementations, just too lazy to create a list
jchampem 9y ago
I just created it: https://github.com/jchampemont/awesome-implementations https://github.com/jchampemont/awesome-implementations If it gets important enough, I'll send it to the awesome list repository. Feel free to contribute guys!
- mathiasrw 9y ago
  Ahhhhh - missed you by 1 minute... :) https://github.com/mathiasrw/LRIP https://github.com/mathiasrw/LRIP
  - deleted 9y ago
    [deleted]
  - jchampem 9y ago
    Haha it was a close call!
- brandonhsiao 9y ago
  Nice. Maybe kilo? https://github.com/antirez/kilo https://github.com/antirez/kilo
  - jchampem 9y ago
    Nice suggestion, adding it :)

leipavoi 9y ago

Cool project! Reminds me of Naivechain, a blockchain in 200 lines of code https://github.com/lhartikk/naivechain https://github.com/lhartikk/naivechain