
Tinychain: a pocket-sized implementation of Bitcoin - jobeirne
https://github.com/jamesob/tinychain
======
brandonhsiao
There should be one of those awesome-* Github repos with a list of
lightweight, readable implementations of various protocols/technologies.

~~~
jchampem
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
Ahhhhh - missed you by 1 minute... :)
[https://github.com/mathiasrw/LRIP](https://github.com/mathiasrw/LRIP)

~~~
jchampem
Haha it was a close call!

------
billconan
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.

------
PaulBGD_
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?

~~~
Ded7xSEoPKYNsDd
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.

~~~
Taek
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
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.

~~~
Taek
It significantly increases the risk of network forks for people who don't have
completely correct clocks. If a merchant has a clock that is off by 1 hour
(they didn't adjust properly for daylight savings perhaps, or maybe they just
have a really crappy clock), then it's possible they will not even be seeing
the most recent 6 blocks, as all of them are 2 hours in the future (3 hours as
seen by the merchant).

There are consequences to having blocks that are permanently set forwards
beyond a one-time difficulty decrease of 0.6%.

------
h4l0
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
I will take a look and would you be willing to answer noob kind of questions?

------
bhalp1
Reminds me of this post: [https://dev.to/aunyks/lets-build-the-tiniest-
blockchain](https://dev.to/aunyks/lets-build-the-tiniest-blockchain)

------
throwaway413
Props for the killer README!

~~~
jobeirne
thanks :)

------
Hortinstein
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
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

------
erikpukinskis
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!

~~~
billconan
Not sure if this will help you: [https://medium.com/@shiyan/ethereum-
summary-a53c4a8e66d?sour...](https://medium.com/@shiyan/ethereum-
summary-a53c4a8e66d?source=linkShare-2f9df7d2fecb-1502142992)

~~~
daraosn
This is great. I already understood most of BTC and ETH protocols, but learned
some new bits, thanks for sharing!

------
gaetanrickter
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-
cryptocurr...](https://news.bitcoin.com/hedge-funds-investing-in-
cryptocurrencies-exploding-62-in-pipeline/)

------
wiremine
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?

~~~
jobeirne
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.

------
leipavoi
Cool project! Reminds me of Naivechain, a blockchain in 200 lines of code

[https://github.com/lhartikk/naivechain](https://github.com/lhartikk/naivechain)

