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
|
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 4D27F6C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 17 Nov 2015 22:17:52 +0000 (UTC)
X-Greylist: from auto-whitelisted 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 6559B17D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 17 Nov 2015 22:17:51 +0000 (UTC)
In-Reply-To: <CALJP9GCia3fedPi4B56G1+07OvwytEAOMNczYrJ4iMwUA3F3rQ@mail.gmail.com>
References: <5631C363.5060705@neomailbox.net>
<201510290803.52734.luke@dashjr.org>
<5632DE33.7030600@bitcartel.com>
<CAAS2fgTga_vTfOKrFu_hEzXSfTfg9FRfJ6aL6ginuGFqnbm7=w@mail.gmail.com>
<3CB90C47-293E-4C18-A381-E5203483D68F@gmx.com>
<CAAS2fgRdK4bDr3x_y9UpdH234PQSfD7U539HBLA==+hLQJ_7Fw@mail.gmail.com>
<571D9B7F-077D-4B80-B577-1C18FF2ECF31@gmx.com>
<CAAS2fgTLE1cpDqKTiy0r1VMex7zTAB8tgUC=Y0WXmbNBJL42xQ@mail.gmail.com>
<6DAD1D38-A156-4507-B506-BF66F26E6594@gmx.com>
<CAAS2fgT+r4aRPe7Qjww6wgbAzkwafN+340pUaVO9F7MZEVY-zA@mail.gmail.com>
<13D7C936-4D2E-4BAC-AC61-3DA80581C946@gmx.com>
<CAAS2fgTuty0OCxJvZwU+BCPXG-VuJxtwCPVMvL7Xbze=OjSSdA@mail.gmail.com>
<2C8EBBD8-51B7-4F47-AFFA-3870DBD6C4EA@gmx.com>
<CABm2gDrEymffZXRqkYij0eCR3Rg6x1w_=AUJpb3NxHwQ-q48aQ@mail.gmail.com>
<D64AA4C7-BB66-41B2-A001-107985071DA1@gmx.com>
<0BABD098-33AB-4638-928B-F2D189FA2F8A@bitsofproof.com>
<CALJP9GCia3fedPi4B56G1+07OvwytEAOMNczYrJ4iMwUA3F3rQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----BO91IA52FF7FJB5YQE2JQDTEVL0LJD"
Content-Transfer-Encoding: 8bit
From: telemaco <telemaco@neomailbox.net>
Date: Tue, 17 Nov 2015 23:17:33 +0100
To: Tom Harding <tomh@thinlink.com>,Tamas Blummer <tamas@bitsofproof.com>
Message-ID: <49CD7E61-C49B-472B-BB3C-1EFAD630104A@neomailbox.net>
X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_LOW,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
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
Gregory Maxwell <gmaxwell@gmail.com>
Subject: Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db
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: Tue, 17 Nov 2015 22:17:52 -0000
------BO91IA52FF7FJB5YQE2JQDTEVL0LJD
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
Shouldn't a odbc jdbc jconnect or equivalent be totally transparent for the consensus code? I mean, the client would write or store the data communicating to the driver provided by the vendor. Using the schema bitcoin suggests adapted to many different vendors (one table schema for Oracle, other for mysql, etc with their slight syntax particularities), installed in the machine with the node and from that communication to the driver the storage would be totally controlled by the third party rdbms.
Regarding bugs or risk of fork, does not have actual client any defense against someone forking core and slightly changing the actual database used maybe wrongly and creating a fork by themselves?
Does the client have any way to verify that what is stored is correct? Maybe inserting a column with a hash of what is stored in each row and another column with a incremental row by row hash composed by the hash of each row and the previous column one., so any tampering in a previous row can be verified up to where is not consistent.
I just imagine what would be for people to be able to access easily (with the thousands of software packages already bought and licensed by ALL companies in the world that already use open standard connectivity or equivalents)., the bitcoin blockchain.
SUBSCRIPTION: for a couple decades replication servers have allowed a publish/subscription model using replication agents. If I am a guy working on a lever in the warehouse with my pda I do not need on my pda all the company info or maybe all the blockchain. If a company., that has already licensed a rdbms package with dozens of related software packages needs one guy to suscribe to something on the bitcoin blockchain, he can either use one of the purchased methods in their company and access the company database that holds blockchain data or hire a rare bitcoin developer that will create a interfaz bitcoin for a specific need up to the millions of needs out there.
PUBLISHING Maybe even to have a publishing daemon that would allow those companies and their software packages to write things in the bitcoin blockchain provided of couse that they fund the agent with a small bitcoin amount to send transactions and they comply with the database constraint of being the owners of the private key. The publishing agent would check for changes every X minutes on that specific address in the db and if funded it would publish "send" the transaction through the bitcoin client. People would be able to publish info on the decentralized ledger from 90% of enterprise software packages.,paying ofc and with the small delay of the publishing agent checking for changes. In fact the db would allow publishing info while the publishing agent could just take its time publishing at its own rate like a slow write cache.
In any case shouldn't even actual consensus be shielded from a malfunctioning or Ill forked database from core client
El 17 de noviembre de 2015 16:24:42 CET, Tom Harding <tomh@thinlink.com> escribió:
>On Nov 17, 2015 5:54 AM, "Tamas Blummer via bitcoin-dev" <
>bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Isolating storage from the rest of consensus code is technically
>desirable, but implementations using different storage will be unlikely
>bug-for-bug compatible,
>> hence able to split the network.
>
>The problem with unknown bugs is you don't know how serious they are.
>A
>serious bug could itself be devastating.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
------BO91IA52FF7FJB5YQE2JQDTEVL0LJD
Content-Type: text/html;
charset=utf-8
Content-Transfer-Encoding: 8bit
<html><head></head><body>Shouldn't a odbc jdbc jconnect or equivalent be totally transparent for the consensus code? I mean, the client would write or store the data communicating to the driver provided by the vendor. Using the schema bitcoin suggests adapted to many different vendors (one table schema for Oracle, other for mysql, etc with their slight syntax particularities), installed in the machine with the node and from that communication to the driver the storage would be totally controlled by the third party rdbms. <br>
Regarding bugs or risk of fork, does not have actual client any defense against someone forking core and slightly changing the actual database used maybe wrongly and creating a fork by themselves? <br>
Does the client have any way to verify that what is stored is correct? Maybe inserting a column with a hash of what is stored in each row and another column with a incremental row by row hash composed by the hash of each row and the previous column one., so any tampering in a previous row can be verified up to where is not consistent.<br>
I just imagine what would be for people to be able to access easily (with the thousands of software packages already bought and licensed by ALL companies in the world that already use open standard connectivity or equivalents)., the bitcoin blockchain. <br>
SUBSCRIPTION: for a couple decades replication servers have allowed a publish/subscription model using replication agents. If I am a guy working on a lever in the warehouse with my pda I do not need on my pda all the company info or maybe all the blockchain. If a company., that has already licensed a rdbms package with dozens of related software packages needs one guy to suscribe to something on the bitcoin blockchain, he can either use one of the purchased methods in their company and access the company database that holds blockchain data or hire a rare bitcoin developer that will create a interfaz bitcoin for a specific need up to the millions of needs out there. <br>
PUBLISHING Maybe even to have a publishing daemon that would allow those companies and their software packages to write things in the bitcoin blockchain provided of couse that they fund the agent with a small bitcoin amount to send transactions and they comply with the database constraint of being the owners of the private key. The publishing agent would check for changes every X minutes on that specific address in the db and if funded it would publish "send" the transaction through the bitcoin client. People would be able to publish info on the decentralized ledger from 90% of enterprise software packages.,paying ofc and with the small delay of the publishing agent checking for changes. In fact the db would allow publishing info while the publishing agent could just take its time publishing at its own rate like a slow write cache.<br>
In any case shouldn't even actual consensus be shielded from a malfunctioning or Ill forked database from core client<br><br><div class="gmail_quote">El 17 de noviembre de 2015 16:24:42 CET, Tom Harding <tomh@thinlink.com> escribió:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<p dir="ltr">On Nov 17, 2015 5:54 AM, "Tamas Blummer via bitcoin-dev" <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br />
><br />
> Isolating storage from the rest of consensus code is technically desirable, but implementations using different storage will be unlikely bug-for-bug compatible,<br />
> hence able to split the network.<br /></p>
<p dir="ltr">The problem with unknown bugs is you don't know how serious they are. A serious bug could itself be devastating.</p>
</blockquote></div><br>
-- <br>
Sent from my Android device with K-9 Mail. Please excuse my brevity.</body></html>
------BO91IA52FF7FJB5YQE2JQDTEVL0LJD--
|
