telemaco [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-10-09 to 2015-11-17
💬 Posted a total of 3 messages
📚 Participated in the following categories: bitcoin-dev, patch
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:44:56

- reply

📅 Original date posted:2015-11-17
📝 Original message: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 at thinlink.com> escribió:
>On Nov 17, 2015 5:54 AM, "Tamas Blummer via bitcoin-dev" <
>bitcoin-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151117/cf843748/attachment.html>

2023-06-07 17:43:54

- reply

📅 Original date posted:2015-10-29
📝 Original message:Why not allow two options:
1/ a default RocksDB/SQLite/LevelDB (whatever is decided)
2/ alternative provide instructions for connection to any other rdbms
using odbc or jdbc.
Why not allowing async disk writes or incredibly fast database systems
if someone wants to have a node in a very fast datacenter or connected
with their existing leveraged dataservers. It is the traditional
approach to just use the open standard for database connectivity.
Any person or any organization would just need to have one machine with
their bitcoin node with a rdbms client installed (SAP Sybase client, or
oracle client, or microsoft). The bitcoin node would just store their
data using the odbc/jdbc protocol on ANY rdbms installed anywhere in
their organization (other machine or the same). They would just need to
issue a "create table" with a very simple table structure and they would
benefit from async and indexes and using their already licensed, and
configured system of their choosing, with bitcoin information being
available to thousands of software packages and available aswell to
thousands of programmers that work with rdbms and not just "RocksDB" or
some obscure database system.
Why not "outsource" totally that data management part to the already
existing with decades of experience database world. People would be able
to create incredibly easy bitcoin statistics/graphs/analisys with
existing software packages (hey even excel or libreoffice like) or
connect bitcoin data to their own sources and if so they chose analyze
bitcoin data on a datawarehouse or any imaginable approach. Of course
every transaction would be have to do through the bitcoin node and only
the data management would be on rdbms side.

2023-06-07 17:43:05

- reply

📅 Original date posted:2015-10-09
📝 Original message: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,