A protocol for storing up to 1277 bytes in the Bitcoin blockchain
github.com
github.com
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.
You could theoretically get around this by starting sync from a known (hard coded) recent block + UXTO set, but at that point you are losing _all_ transaction history, not just your OP_RETURNs. So, I don't think OP_RETURN data added to the blockchain today will be going anywhere fast.
This kind of approach can be very helpful in the wild. For delivery of SMS, for example.
The second paragraph of the README states:
This protocol is intended for use while developing OP_RETURN based protocols. Mature protocols should switch to a custom OP_RETURN method that uses as few transactions as possible to store data.
We're using Blockcast underneath Open Publish... we needed more than just the 80 bytes in a single OP_RETURN because we needed a few different content-addressable keys. We use a combination of IPFS, BitTorrent InfoHash, SHA-1, as well as a URI to where the ACTUAL content is posted.
Open Publish is also a digital asset protocol so it very much benefits from the "colored coin" properties of the Bitcoin blockchain.
But yes, content itself should be stored and distributed using IPFS, BitTorrent, or HTTP, it only makes sense to use the Bitcoin blockchain for things related to payments and ownership, like with the Open Publish protocol.
What about polluting the blockchain?
We will move this protocol to a Bitcoin sidechain designed specifically for public data as soon as the technology for building sidechains becomes available.
In the meantime we've been using this protocol while prototyping other protocols that rely on storing metadata in the Bitcoin blockchain.
Woodsy Owl says "Give a Hoot! Don't Pollute!"
It also lacks the infrastructure of exchanges, APIs, tools, and software that support Bitcoin.
Ultimately we feel that Bitcoin sidechains are a better approach to crypto-currencies than having competing alt-coins.
https://github.com/blockai/blockcast#what-about-an-alternati...
Still waiting on those sidechains...
https://github.com/blockai/openpublish
At some point soon we are going to be transitioning away from Blockcast and instead using a Protocol Buffer, but it has been really nice to be using a loose format based on JSON and Blockcast while we were figuring out all the requirements!
You write excellent code, most notably `elliptic`; your work on Node.js/io.js is much appreciated! I think the problem is that you don't prioritize documentation. The reality is that consumers of libraries need to know two things: 1) how said library can help save time / be a hero, etc 2) how to use said library.
Keep writing the awesome code that you do. Next time, maybe spend bit more time on documentation, and I think you'll see more traction :)
March 2013 it was worth less than $100
Currently it has dropped to $200
Bitcoin the currency isn't seeing a huge amount of adoption (or even speculation) lately, leading to a fairly stable price.
Bitcoin the protocol (a permissionless, decentralized database, or as the media calls it: "blockchain technology") is seeing a huge amount of innovation and a wide variety of applications coming out. I suggest you read up on it.
[0] http://www.wired.com/2015/10/hedge-fund-borrows-10m-in-stock...
There's been a lot of work going into a market for transaction fees based on a supply&demand model that'd make spam not just costly, but exponentially more costly if you want to scale it. It's not perfect but it's looking pretty sensible atm.
If a misguided - not even malicious! - use case can make it unusable, maybe it's not destined to live all that long.