public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: telemaco <telemaco@neomailbox.net>
To: Tom Harding <tomh@thinlink.com>,Tamas Blummer <tamas@bitsofproof.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Gregory Maxwell <gmaxwell@gmail.com>
Subject: Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db
Date: Tue, 17 Nov 2015 23:17:33 +0100	[thread overview]
Message-ID: <49CD7E61-C49B-472B-BB3C-1EFAD630104A@neomailbox.net> (raw)
In-Reply-To: <CALJP9GCia3fedPi4B56G1+07OvwytEAOMNczYrJ4iMwUA3F3rQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3521 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 3929 bytes --]

  reply	other threads:[~2015-11-17 22:17 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-29  6:57 [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db telemaco
2015-10-29  8:03 ` Luke Dashjr
2015-10-30  3:04   ` Simon Liu
2015-10-30  3:35     ` Gregory Maxwell
2015-10-30  4:04       ` Peter R
2015-10-30  4:28         ` Gregory Maxwell
2015-11-15  1:02           ` Peter R
2015-11-15  1:08             ` Gregory Maxwell
2015-11-15  1:45               ` Peter R
2015-11-15  2:10                 ` Gregory Maxwell
2015-11-15  2:58                   ` Peter R
2015-11-15  3:30                     ` Gregory Maxwell
2015-11-15  4:10                       ` Peter R
2015-11-15 10:12                         ` Jorge Timón
2015-11-15 11:28                           ` Jorge Timón
2015-11-15 15:48                             ` Peter R
2015-11-15 17:06                           ` Peter R
2015-11-17 13:54                             ` Tamas Blummer
2015-11-17 15:24                               ` Tom Harding
2015-11-17 22:17                                 ` telemaco [this message]
2015-11-20 14:15                                   ` Jorge Timón
2015-11-16  1:52                     ` Rusty Russell
2015-11-15  3:04             ` Luke Dashjr
2015-11-15  3:17               ` Peter R
2015-10-29  8:17 ` Gregory Maxwell
  -- strict thread matches above, loose matches on Subject: below --
2015-10-22 21:26 Jeff Garzik
2015-10-22 21:54 ` Patrick Strateman
2015-10-22 21:56 ` Joseph Gleason ⑈
2015-10-23  6:53 ` Jonas Schnelli
2015-10-23  7:45 ` Lucas Betschart
2015-10-28 20:28   ` Sean Lynch
2015-10-28 21:11     ` Jeff Garzik
2015-10-23 10:30 ` Tom Zander
2015-10-26 18:06   ` Douglas Roark
2015-10-28 15:52     ` Tom Zander
2015-11-18  0:06     ` Jonathan Wilkins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49CD7E61-C49B-472B-BB3C-1EFAD630104A@neomailbox.net \
    --to=telemaco@neomailbox.net \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=gmaxwell@gmail.com \
    --cc=tamas@bitsofproof.com \
    --cc=tomh@thinlink.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox