I would have loved this a few months ago. I've since switched to Ethereum and have been really happy with it. If you're trying to cram lots of data into OP_RETURNs, you should try looking at other blockchains.
Also, what's the retrieval rate of the data? How much of it can you query at once? Is it different/faster on Ethereum?
Bitcoin doesnt make the data queryable in any way. You need to know the transactions where the data is stored ahead of time.
With Ethereum, you can create a "contract" that emits "events" which automatically get added to a queryable database.
https://github.com/blockai/blockcast-state-engine/blob/maste...
The next step would be storing the results in a SQL database as we do with our production servers that maintain a queryable database of Open Publish registrations and transactions (Open Publish uses Blockcast for storing metadata on digital media assets).
https://github.com/blockai/openpublish-state
This is definitely a more piecemeal approach to creating smart contract applications than with Ethereum's one-stop-shop, but there are benefits to building on top of Bitcoin, especially for Open Publish, which uses native Bitcoin transactions for payments and royalties.
Also the same question with respect to BIP65 and BIP112
All of the abstractions related to signing transactions and messages are handled by a wallet that adheres to the Common Wallet standard.
There is a Common Wallet adapter for the Bitcoin-QT/bitcoind JSON-RPC as well as a simple javascript native wallet that we mainly use for testing.
https://github.com/blockai/rpc-common-wallet https://github.com/blockai/test-common-wallet
Everything related to reading from and propagating to the blockchain are handled by any number of different Common Blockchain adapters. In theory they should all behave in exactly the same manner.
As well as supporting the JSON-RPC interface, there are a bunch of unofficial Common Blockchain adapters for services like Blockcypher and Chain.
https://github.com/blockai/rpc-common-blockchain https://github.com/andrewmalta13/blockcypher-unoffical https://github.com/andrewmalta13/chain-unofficial
You could be creating applications that are reading and writing from the blockchain without much hassle at all!
Another important thing to remember is that Bitcoin has a block time of 10 minutes. That means that once your user submits data to the blockchain, they need to wait ~5 minutes for even 1 confirmation.
Ethereum has a block time of 12 seconds.
tldr: longer reorgs and less energy mean less security. Which, is presumably the reason to even use a blockchain
> Okay, fine, under normal conditions bitcoin blocks are 98% likely to be final but ethereum blocks are 80% likely to be final. However, six bitcoin blocks provide a one minus one in a billion finality guarantee (since 0.02 6 < 10-9) and 13 ethereum blocks provide that same guarantee (0.2 13 < 10-9), so it's still the case that what bitcoin provides in 60 minutes, ethereum provides in 156 seconds. Sure, not in six blocks, but it's a battle of linear versus exponential, so the more fine-grained you can make the single-block confirmation time the better.
There are also uncle rewards which mitigate the miner incentives.
I see benefits to both systems and longer block times are clearly more efficient, but since Ethereum is an application platform a 10 minute block time is untenable. It may be less efficient, but I don't think thats a nail in the coffin.