
Show HN: Pg_blkchain – Postgres blockchain extension - gtrubetskoy
https://github.com/blkchain/pg_blkchain#
======
dna_polymerase
Please rename this. This is not a pg-based blockchain or anything like that,
just a Bitcoin extension to pg. And guess what Bitcoin is not the only
blockchain out there...

~~~
gtrubetskoy
It _is_ a PostgreSQL Blockchain Extension, i.e.: a postgres extension [1]
which allows one to process a blockchain [2].

The bitcoin blockchain is the first invented blockchain as we know it, all the
other blockchains are borrowing the concepts from the bitcoin blockchain,
which is why this extension, at least in its present initial form, is designed
to work with the bitcoin blockchain.

I stand by the name, it is exactly correct.

[1] [https://www.postgresql.org/docs/current/static/external-
exte...](https://www.postgresql.org/docs/current/static/external-
extensions.html)

[2] "The first distributed blockchain was conceptualised by an anonymous
person or group known as Satoshi Nakamoto" from
[https://en.wikipedia.org/wiki/Blockchain](https://en.wikipedia.org/wiki/Blockchain)

~~~
nosuchthing
Just because an Oldsmobile is one of the first mass produced automobiles in
existence, doesn't mean anyone looking for a car would want an Oldsmobile.

In regards to database technology, Bitcoin just pieced together technologies
that already existed, i.e. hash cash, merkle trees, and distributed databases.

It's worth acknowledging while Bitcoin was a great prototype for
implementation of a blockchain, it's quiet stagnate and divided community and
development teams has led to the current crisis of hard forks. Meanwhile other
blockchain projects are iterating and developing user-friendly features.

------
remcob
From the name and the title, I was hoping it would be a prototype blockchain
based distributed consensus extensions for Postgres. I have to admit that I
was a little bit disappointed to discover that it is a collection of
transaction parsing functions for the Bitcoin blockchain.

Nevertheless, cool project! Definitely something I should have used a year ago
instead of the slow cludge of Python scripts I build!

~~~
gtrubetskoy
Apologies, the title should have contained POC.

I am not sure what you mean by "blockchain based distributed consensus" \- did
you mean the the ability to group transactions into blocks and being able to
verify those? It's possible, and that's the plan, it is, however, very
complicated to build something that you can actually _trust_ like the bitcoin
core.

I think that a better use for this sort of thing is the ability to analyze the
blockchain.

But something that would provide "full node" functionality I think is
interesting as well. There would still need to be some sort of a program
running in front of it to do all the network communication...

Anyway - the point of this little project is to really get some feedback on
the general approach and then see where to take it next. :)

~~~
NegativeLatency
Sounds like they were thinking of some kind of way of running Postgres on a
blockchain, vs using Postgres to process the blockchain.

------
sandGorgon
This is awesome. I can't seem to under why most blockchains insist on using
leveldb as their transactional data store. In fact, the bitcoin devs have
admitted some of the attacks are specifically targeted towards the non ACID
nature of leveldb.

It would be so much better to use postgresql as the data store. But it seems
there is a natural aversion to non-embedded databases.

~~~
comboy
You want your client to be standalone, you can't expect users to install and
configure postgresql and sqlite probably isn't gonna cut it.

If you want blockchain stats, postgres is great, but for a node you just need
to be able to look stuff up by its keys. Leveldb was made for that and it's
good at doing it.

I don't know these attacks, but it seems you don't really need ACID that
badly, most stuff is append only and once appended it never gets deleted.

~~~
AnkhMorporkian
I'm curious, why wouldn't sqlite cut it? Granted, I'm not a blockchain
afficiando, but I have several sqlite DBs that run a couple hundred gigabytes
a piece that work quite well.

~~~
comboy
I said probably because I thought about it myself while writing that comment.
I also have good experience with it, but if sqlite only talks SQL then just
creating string representation of binaries would already be prohibitive.

~~~
ComputerGuru
> but if sqlite only talks SQL

What does that mean? Like any RDBMS, SQLite is interfaced with in SQL, but can
store and process binary data just fine.

~~~
comboy
I mean that you need to serialize binary just to make an SQL statement that
includes it, and that's very expensive. E.g. postgresql's COPY supports binary
format which allows you to avoid that.

~~~
ComputerGuru
The fact that SQLite is embedded means it can take full advantage of pointer
passing. I don't think it serializes anything when you bind parameters to a
blob.

------
ssutch3
For a good C-bitcoin library you can use breadwallet-core:
[https://github.com/breadwallet/breadwallet-
core](https://github.com/breadwallet/breadwallet-core)

------
0xCMP
Can someone explain what this is for or could be used for? It seems like it
allows you to store, process, and verify the blockchain inside postgres,
right?

~~~
rickycook
from my reading, the best use case i could think of would be to use it to have
foreign keys to transactions and the like in your app database so that you can
ensure their integrity

------
epx
A colleague was hard-pressing me about which advantages could Postgres have in
relation to M(ySQL|ariaDB), these extensions (not this particular extension,
but the concept of) seems to be a definitive advantage.

~~~
nawgszy
Your comment only had one takeaway for me: len('M(ySQL|ariaDB)') >
len('MySQL/MariaDB')

~~~
epx
As people say, once you turn to REs to solve a problem, you have two problems
:)

