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
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
Return-Path: <jl2012@xbt.hk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 35B1E1EAE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Oct 2015 04:16:53 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from s47.web-hosting.com (s47.web-hosting.com [199.188.200.16])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6F20D150
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 9 Oct 2015 04:16:52 +0000 (UTC)
Received: from localhost ([::1]:36244 helo=server47.web-hosting.com)
by server47.web-hosting.com with esmtpa (Exim 4.85)
(envelope-from <jl2012@xbt.hk>)
id 1ZkP6w-001gBR-O5; Fri, 09 Oct 2015 00:16:50 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 8bit
Date: Fri, 09 Oct 2015 00:16:50 -0400
From: jl2012@xbt.hk
To: telemaco <telemaco@neomailbox.net>
In-Reply-To: <56173207.3040601@neomailbox.net>
References: <56173207.3040601@neomailbox.net>
Message-ID: <39700e7d3fea68181f88644791e289d6@xbt.hk>
X-Sender: jl2012@xbt.hk
User-Agent: Roundcube Webmail/1.0.5
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - server47.web-hosting.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - xbt.hk
X-Get-Message-Sender-Via: server47.web-hosting.com: authenticated_id:
jl2012@xbt.hk
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev]
=?utf-8?q?Why_not_checkpointing_the_transactions=3F?=
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 04:16:53 -0000
You are mixing multiple issues.
1. It is not possible to "checkpoint" in a totally decentralized and
trustless way. You need the whole blockchain to confirm its validity, as
a single invalid tx in the history will invalidate ALL blocks after it,
even if the invalid tx is irrelevant to you.
2. Downloading the whole blockchain does not mean you need to store the
whole blockchain. Spent transactions outputs can be safely removed from
your harddrive. Please read section 7 of Satoshi's paper:
https://bitcoin.org/bitcoin.pdf . This function is already implemented
in Bitcoin Core 0.11
3. If you don't even want to download the whole blockchain, you can
download and validate the portions that your are interested. Satoshi
called it Simplified Payment Verification (SPV), the section 8 of his
paper. It is secure as long as >50% of miners are honest. Android
Bitcoin Wallet is an SPV wallet based on bitcoinj.
Finally, I think this kind of question would be better asked on the
bitcointalk forum. The mailing list should be more specific to
development, not merely some vague idea.
telemaco via bitcoin-dev 於 2015-10-08 23:18 寫到:
> 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,
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
