1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
|
Return-Path: <telemaco@neomailbox.net>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 695001643
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Oct 2015 03:38:44 +0000 (UTC)
X-Greylist: delayed 00:20:07 by SQLgrey-1.7.6
Received: from s1.neomailbox.net (s1.neomailbox.net [5.148.176.57])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DD7F6160
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Oct 2015 03:38:43 +0000 (UTC)
To: bitcoin-dev@lists.linuxfoundation.org
From: telemaco <telemaco@neomailbox.net>
Message-ID: <56173207.3040601@neomailbox.net>
Date: Fri, 9 Oct 2015 05:18:31 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-0.7 required=5.0 tests=BAYES_20,RCVD_IN_DNSWL_LOW,
T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: [bitcoin-dev] Why not checkpointing the transactions?
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2015 03:38:44 -0000
Hello,
I have been working on database engineering for many years and there are
some things i don't understand very well about how bitcoin architecture
works. I have not written here because i would not like to disturb
development with yet another of those far to implement ideas that does
not contribute to actual code as sometimes is said here.
On any case today I have been listening the last beyond bitcoin video
about the new bitshares 2.0 and how they are changing the transaction
structure to do it more similar to what relational database management
systems have been doing for 30 years.
Keep a checkpointed state and just carry the new transactions. On rdbms,
anyone if they want to perform historical research or something, they
can just get the transaction log backups and reply every single
transaction since the beginning of history.
Why is bitcoin network replying every single transaction since the
beginning and not start from a closer state. Why is that information
even stored on every core node? Couldn't we just have a checkpointed
state and the new transactions and leave to "historical" nodes or
collectors the backup of all the transactions since the beginning of
history?
Replication rdbms have been working with this model for some time, just
being able to replicate at table, column, index, row or even db level
between many datacenters/continents and already serving the financial
world, banks and exchanges. Their tps is very fast because they only
transfer the smallest number of transactions that nodes decide to be
suscribed to, maybe japan exchange just needs transactional info from
japanese stocks on nasdaq or something similar. But even if they
suscribe to everything, the transactional info is to some extent just a
very small amount of information.
Couldn't we have just a very small transactional system with the fewest
number of working transactions and advancing checkpointed states? We
should be able to have nodes of the size of watches with that structure,
instead of holding everything for ever for all eternity and hope on
moore's law to keep us allowing infinite growth. What if 5 internet
submarine cables get cut on a earth movement or war or there is a
shortage of materials for chip manufacturing and the network moore's law
cannot keep up. Shouldn't performance optimization and capacity planning
go in both ways?. Having a really small working "transaction log" allows
companies to rely some transactional info to little pdas on warehouses,
or just relay a small amount of information to a satellite, not every
single transaction of the company forever.
After all if we could have a very small transactional workload and leave
behind the overload of all the previous transactions, we could have
bitcoin nodes on watches and have an incredibly decentralized system
that nobody can disrupt as the decentralization would be massive. We
could even create a very small odbc, jdbc connector on the bitcoin
client and just let any traditional rdbms system handle the heavy load
and just let bitcoin core rely everyone and his mother to a level that
noone could ever disrupt a very small amount of transactional data.
Just some thoughts. Please don't be very harsh, i am still researching
bitcoin code and my intentions are the best as i cannot be more
passionate about the project.
Thanks,
|
