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 <t...@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.
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
