The (Bitcoin) blockchain is a distributed, low-trust database containing, among other things, a public ledger of Bitcoin transactions. Both the underlying blockchain technology and the currency on top are experimental, but potentially revolutionary innovations. There are many controversial topics surrounding both, ranging from technological choices to economical effects.
In the next few blog posts I'll take a closer look at the underlying technology; the details of it's implementation and how it can be useful outside of its primary function (the currency).
Initially I'll devote some energy to connect to and interact with the peer-to-peer network the hard way, essentially reimplementing parts of the official Bitcoin client, although I'll base most of my code on the Bitcoin protocol specification rather than any other implementation. There's nothing wrong with the existing clients, but in the spirit of the decentralized and trust-less nature of the Bitcoin protocol and network, I'd like to write my own, competing implementation (also, it sounds like a lot of fun).
Once I have the basics working, I'll look at adding actual functionality. My first two goals are:
1) Using the blockchain as backend for a proof of existence service. This is a service that stores a cryptographic checksum of a document (or any other file) in the blockchain, thereby proving that the document existed at a certain point in time (every block in the blockchain is timestamped).
2) A Bitcoin transaction fee calculator. Bitcoin transactions usually include a fee that will be paid to the miner that includes the transaction in a block, thus incentivizing miners to quickly confirm your transaction. Most current wallets have somewhat arbitrary rules about how the magnitude of the fee is set, potentially setting it too low and causing the transaction to go unconfirmed (not included in any block) for a long time. This issue is becoming more and more relevant now that the volume of transactions is getting closer to the block size limit, and in particular during periods of "spam attacks" on the network, where large numbers of transactions flood the network, slowing down processing of "real" transactions. In such situations, the miners are likely to only include the transactions with the highest fees in the their blocks, thus creating a need for real-time data on how the fee level affects the expected wait time.
In the next few blog posts I'll take a closer look at the underlying technology; the details of it's implementation and how it can be useful outside of its primary function (the currency).
Initially I'll devote some energy to connect to and interact with the peer-to-peer network the hard way, essentially reimplementing parts of the official Bitcoin client, although I'll base most of my code on the Bitcoin protocol specification rather than any other implementation. There's nothing wrong with the existing clients, but in the spirit of the decentralized and trust-less nature of the Bitcoin protocol and network, I'd like to write my own, competing implementation (also, it sounds like a lot of fun).
Once I have the basics working, I'll look at adding actual functionality. My first two goals are:
1) Using the blockchain as backend for a proof of existence service. This is a service that stores a cryptographic checksum of a document (or any other file) in the blockchain, thereby proving that the document existed at a certain point in time (every block in the blockchain is timestamped).
2) A Bitcoin transaction fee calculator. Bitcoin transactions usually include a fee that will be paid to the miner that includes the transaction in a block, thus incentivizing miners to quickly confirm your transaction. Most current wallets have somewhat arbitrary rules about how the magnitude of the fee is set, potentially setting it too low and causing the transaction to go unconfirmed (not included in any block) for a long time. This issue is becoming more and more relevant now that the volume of transactions is getting closer to the block size limit, and in particular during periods of "spam attacks" on the network, where large numbers of transactions flood the network, slowing down processing of "real" transactions. In such situations, the miners are likely to only include the transactions with the highest fees in the their blocks, thus creating a need for real-time data on how the fee level affects the expected wait time.
No comments:
Post a Comment