Blockchain

[Dimster]

Wondering if any of you guys have done any coding with Blockchain. As I understand it, there is basically a record which is not written until all records are searched and the new record to be written is deemed valid in someway before it can be written to the chain of records. The two main/key points I take away from this is that VALIDATION before writing the record can be very complex and secondly, the chain must be sequential or there has to be an index table that allows the records to be found in the order in which they were written. So in pseudocode the layout would be something like this:


- compose a validation routine which comprises decisions on what is accurate and acceptable

- Input a record

- Review the present chain
  a:for duplication of inputted record
  b:for a location in chain where the inputted record will be written
  c: subject the inputted record to the validation routine
  d: write the inputted record or reject the record.
  e: keep an index as to where this inputted record can be found

The blockchain that I'm trying to work on is not for public input but rather something which raises the accuracy of the data in the data base and improves retrieval of any given small piece of data stored. In this regard, what I don't have in the above pseudocode layout is a search routine. It would seem I need 2 search routines, one associated with the Review of the chain before writing a record and one associated with a search of data where No record is intended on being written. A number of years ago I started on a blockchain program but found it was going to be extremely large and abandoned it. So I'm looking at it again but trying to conceptualize a smaller program.

[bplus]

Yes you would want a database without duplicate records. Date and Time stamp is excellent way to make records unique.

More: It seems doing a "chain" would take longer than a sort by ID and Times stamp IMHO.

[SpriggsySpriggs]

Sounds quite interesting
|
|
|
|
|
V

[DSMan195276]

Personally I'm of the opinion that, unless you're attempting to make another currency, a blockchain is not going to be better than just having a database and using the features they already have to track changes. Like you've identified blockchains are not a very good database due to their nature, and in this situation I don't think they give you any advantages to make up for their disadvantage.

That said, I think the actual "blockchain" part is really just the hash chain - where each new entry in the chain contains a hash of the entry before it, creating a linked-list of all the entries in the chain. Because the hash of an entry includes all the data in the entry as well as the hash of the previous entry, you cannot change anything in previous entries in the chain without also changing the hashes of every entry after that point. This is Ex. exactly how `git` works and verifies that your copy of the code history matches what is held elsewhere, it simply verifies that your history ends in an entry with the same hash.

The actual validation of whether a new entry is allowed on the chain at all is separate in my mind from the blockchain itself, but also I think it depends a lot on the kind of data you plan to store, there's lots of "shortcuts" you can take to make it easier. For example I believe Bitcoin solves this problem by requiring transactions to spend _all_ the tokens from a previous transaction to an address (even if that means just sending some of the tokens back to the same address they were at). This means verifying a transaction doesn't require looking up every transaction associated with that address to count how many tokens they still have, instead transactions have to list the outputs of other transactions as inputs that are getting spent, and verifying the new transaction only requires looking up the outputs of the referenced transactions and verifying they match what is listed.

Since the new transaction has to spend _everything_ from the referenced inputs, the transactions used as input never need to be worried about again and you will simply reference the outputs of the new transaction. To prevent someone from spending their tokens twice (IE. Using the output of a transaction as an input to two separate transactions) I think you still have scan every transaction in the history between "now" and where in the past the referenced transaction is, but that's not too bad because if the transaction appears as an input _anywhere_ you know a double spend is happening, you don't need to worry about how much is being spent.

[Dimster]

Thanks for that input DSMAN. From my read of Blockchain structure, it's being adopted more and more by various companies which need the most accurate data upon which to make decisions. A company for example whose inventory is critical. Exactly how many of what items, for any company which has a product to sell, could make a big difference in their profits. Similarly Banks need that higher level of accuracy of data ... list is getting longer on companies use of Blockchain other than tracking bitcoins and the like.

I've been messing with an AI program (so far it's a flop). But one of the key items which my AI is suffering from is GIGO. There are too many logic errors and rounding errors and coding errors. I'm looking for some way to make the program more efficient and accurate and blockchain seems to have some elements that may be helpful for my AI. I'm trying to imagine a marriage between AI and Blockchain structure.

Time to take a break from coding, and read, and think, and read, and think.

[DSMan195276]

Thanks for that input DSMAN. From my read of Blockchain structure, it's being adopted more and more by various companies which need the most accurate data upon which to make decisions. A company for example whose inventory is critical. Exactly how many of what items, for any company which has a product to sell, could make a big difference in their profits. Similarly Banks need that higher level of accuracy of data ... list is getting longer on companies use of Blockchain other than tracking bitcoins and the like.

I'm pretty cynical on this, so feel free to ignore me But I don't think so, I think that is just companies attempting to bump their stock price by mentioning "blockchain" since it's the cool thing.

Functionally, a blockchain doesn't make your data any more accurate than a database would be. The distributed aspect a blockchain (Ex. git) allows is powerful, but pretty much all the situations people attempt to use blockchain, such as tracking inventory, don't require a distributed system, and if it's not distributed then a blockchain just becomes a worse version of a database. If it actually is distributed then you now have a lot of problems that blockchain doesn't solve for you, Ex. what you do when systems disagree on what chain is the valid chain. Bitcoin solves a lot of these things through a POW algorithm, but that falls apart at small scale. These are problems that a database simply doesn't have.

[SpriggsySpriggs]

I'm with Matt on this. I read the thing about Walmart using blockchain and how an employee can see everywhere that a fruit has been, from farm to shelf. The article makes it seem like it is only possible through blockchain when anyone running a SQL server can accomplish the same thing. It's probably just for millennial hype more than anything. I just know that at every company I've worked for, all the data was tracked through a regular SQL database. Inventory, sales, purchase orders, shipping status, etc. That being said, if you're able to recreate a blockchain system in QB64 then that's pretty neat. If you manage to make headway, I want to take a gander. Good luck!

[Dimster]

I can see where Blockchain would be just another database but from my read of it, it's a lot more than a simple SQL. 

For one thing there is the verification or validation of the data written. The data is simply not just written as a typical database entry but checked for accuracy. 

There would also be the security feature of it as well. While I wouldn't have the numbers of people accessing the data as a bank or corporation has, but where someone else has access to the data, blockchain structure pretty much ensures the data will not be corrupted without breaking the chain.

One of the negative things about blockchain that I have been reading about is that it's slow. It comes with a lot of overhead coding a simply SQL wouldn't have.

[DSMan195276]

For one thing there is the verification or validation of the data written. The data is simply not just written as a typical database entry but checked for accuracy.

This is simply a feature of the program interacting with the blockchain and the data you store on it, not the blockchain itself. Nothing prevents you from adding anything you want to a blockchain beyond the code you write to verify the changes, in the same way that the code would prevent you from making bad modifications to a database. You can also add tables and entries to your database for the purpose of verifying the database contents in the future (though the history on the database would also allow this).

There would also be the security feature of it as well. While I wouldn't have the numbers of people accessing the data as a bank or corporation has, but where someone else has access to the data, blockchain structure pretty much ensures the data will not be corrupted without breaking the chain.

Maybe, but then typical SQL databases offer ways to setup read-only accounts or accounts with restricted access that would prevent them from changing the history. Additionally there's little reason to give people direct access to the database anyway, it's much better to setup a service that talks to the database and exposes some of the data through an authenticated API, that really restricts who can access the database and makes it easier to track changes. Similar to a blockchain you can also replicate a database elsewhere so that even if they manage to completely screw up the master copy you still have others.

I also again mention that detecting a "break in the chain" is not as simple as you're suggesting. Anybody can create a new valid chain starting at any point in the past, so how do you determine which chain is the "correct" one? This is the hard problem of using a blockchain that Bitcoin solves with a POW algorithm, but that doesn't work at a small scale.

git for example simply leaves it up to the user to determine this. It will warn you when your chain does not match what is somewhere else, but it can't tell you what the "correct" chain is because it has no way of knowing. Depending on what has happened there's not necessarily a "correct" chain anyway.

[Dimster]

So DS, I guess the bottom line here is Blockchain coding is best used to start up another coin. Adapting it's structure and methods, to avoid mining, transforms it to just another version of an SQL data base.

Thanks for sharing your insightful thoughts. Back to the drawing board for me.