Difference between revisions of "Application layer protocol"
| (3 intermediate revisions by 2 users not shown) | |||
| Line 5: | Line 5: | ||
With the data carrier size of an output expanded to 100KB, we can store various types of data by creating a [[False Return]] output in a [[Bitcoin_Transactions|Bitcoin transaction.]] | With the data carrier size of an output expanded to 100KB, we can store various types of data by creating a [[False Return]] output in a [[Bitcoin_Transactions|Bitcoin transaction.]] | ||
| − | [https://bitcom.bitdb.network/#/ Bitcom] is a proposal of a protocol for defining protocols. Bitcom proposes to store a [[Bitcoin address]] as the prefix, ensuring uniqueness and a namespace. | + | [https://bitcom.bitdb.network/#/ Bitcom] is a proposal of a protocol, for defining protocols. Bitcom proposes to store a [[Bitcoin address]] as the prefix, ensuring uniqueness and a namespace. |
A heavily used protocol is the [https://github.com/unwriter/B B://] protocol created by developer _unwriter. This protocol defines how files can be stored on-chain, leveraging the Bitcom construct also defined by _unwriter. | A heavily used protocol is the [https://github.com/unwriter/B B://] protocol created by developer _unwriter. This protocol defines how files can be stored on-chain, leveraging the Bitcom construct also defined by _unwriter. | ||
| − | For example to store a photo of a duck, we use the protocol prefix for B:\\: | + | For example, to store a photo of a duck, we use the protocol prefix for B:\\: |
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut | 19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut | ||
| Line 22: | Line 22: | ||
=== Unlimited transaction size === | === Unlimited transaction size === | ||
| − | These constructs were created to work with a 100KB transaction size but with the [[Genesis_upgrade|Genesis upgrade]] much larger data can be written in a single transaction. Additionally, the OP_PUSHDATA opcodes are able to be used properly in script eliminating the reliance on using [[History_of_OP_RETURN|OP_RETURN]] as the sole means of pushing data | + | These constructs were created to work with a 100KB transaction size, but with the [[Genesis_upgrade|Genesis upgrade]] much larger data can be written in a single transaction. Additionally, the OP_PUSHDATA opcodes are able to be used properly in script eliminating the reliance on using [[History_of_OP_RETURN|OP_RETURN]] as the sole means of pushing data into transactions. |
=== Widely used protocols === | === Widely used protocols === | ||
| − | * [[Metanet Protocol]] - Defines a directed graph structure that stores data on the | + | * [[Metanet Protocol]] - Defines a directed graph structure that stores data on the Bitcoin ledger where it can easily be queried and referenced by other applications. |
| − | * [https://www.tokenized.com Tokenized Protocol] - Defines protocol and platform where issuers and users can create, manage and trade tokens leveraging built-in smart contracts. | + | * [https://www.tokenized.com Tokenized Protocol] - Defines protocol and platform where issuers and users can create, manage, and trade tokens leveraging built-in smart contracts. |
| − | * [https://bitcom.bitdb.network/#/ Bitcom] - | + | * [https://bitcom.bitdb.network/#/ Bitcom] - Decentralised registry of application protocols uniquely identified by an input address, proving ownership. Bitcom protocols can be concatenated together with a | character. |
| − | * [https://github.com/unwriter/B B://], [https://c.bitdb.network/ C://], [https://planaria.network/@1G3BpTyEK6xF4LaQTHqdFBBaVxYHZzts4M D://], [http://bcat.bico.media/ BCAT] - Various protocols for storing files on | + | * [https://github.com/unwriter/B B://], [https://c.bitdb.network/ C://], [https://planaria.network/@1G3BpTyEK6xF4LaQTHqdFBBaVxYHZzts4M D://], [http://bcat.bico.media/ BCAT] - Various protocols for storing files on the ledger and details how to reference them in a web page or application. |
* [https://github.com/BitcoinFiles/AUTHOR_IDENTITY_PROTOCOL/ AIP - Author Identity Protocol] - Simple protocol to sign arbitrary OP_RETURN data and decouple the signing address from the funding source address. | * [https://github.com/BitcoinFiles/AUTHOR_IDENTITY_PROTOCOL/ AIP - Author Identity Protocol] - Simple protocol to sign arbitrary OP_RETURN data and decouple the signing address from the funding source address. | ||
* [https://map.sv/ MAP - Magic Attribute Protocol] - Protocol that maps arbitrary data via key/value pairs on-chain. | * [https://map.sv/ MAP - Magic Attribute Protocol] - Protocol that maps arbitrary data via key/value pairs on-chain. | ||
* [https://github.com/torusJKL/BitcoinBIPs/blob/master/HAIP.md/ HAIP - Hash Author Identity Protocol] - Similar to AIP but hashes the data signed for smaller capacity devices. | * [https://github.com/torusJKL/BitcoinBIPs/blob/master/HAIP.md/ HAIP - Hash Author Identity Protocol] - Similar to AIP but hashes the data signed for smaller capacity devices. | ||
| − | * [https://memo.sv/protocol Memo SV] - Protocol that defines various actions on Memo's on-chain social network | + | * [https://memo.sv/protocol Memo SV] - Protocol that defines various actions on Memo's on-chain social network by embedding them in OP_RETURN transactions. |
* Contact the Bitcoin Association to have your stable, released protocol added. | * Contact the Bitcoin Association to have your stable, released protocol added. | ||
Latest revision as of 05:33, 23 October 2020
Introduction
Application layer protocols in Bitcoin are rule sets defined and stored in transactions as arbitrary data. Various protocols have been implemented by application developers to store websites, social media posts, images, identity and other types of data since the OP_RETURN push data limit was increased to 100KB.
Practical example
With the data carrier size of an output expanded to 100KB, we can store various types of data by creating a False Return output in a Bitcoin transaction.
Bitcom is a proposal of a protocol, for defining protocols. Bitcom proposes to store a Bitcoin address as the prefix, ensuring uniqueness and a namespace.
A heavily used protocol is the B:// protocol created by developer _unwriter. This protocol defines how files can be stored on-chain, leveraging the Bitcom construct also defined by _unwriter.
For example, to store a photo of a duck, we use the protocol prefix for B:\\:
19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut
Followed by the different fields B:\\ defines as additional push data:
[Image Buffer] image/png binary duck.png
Here is the example.
Unlimited transaction size
These constructs were created to work with a 100KB transaction size, but with the Genesis upgrade much larger data can be written in a single transaction. Additionally, the OP_PUSHDATA opcodes are able to be used properly in script eliminating the reliance on using OP_RETURN as the sole means of pushing data into transactions.
Widely used protocols
- Metanet Protocol - Defines a directed graph structure that stores data on the Bitcoin ledger where it can easily be queried and referenced by other applications.
- Tokenized Protocol - Defines protocol and platform where issuers and users can create, manage, and trade tokens leveraging built-in smart contracts.
- Bitcom - Decentralised registry of application protocols uniquely identified by an input address, proving ownership. Bitcom protocols can be concatenated together with a | character.
- B://, C://, D://, BCAT - Various protocols for storing files on the ledger and details how to reference them in a web page or application.
- AIP - Author Identity Protocol - Simple protocol to sign arbitrary OP_RETURN data and decouple the signing address from the funding source address.
- MAP - Magic Attribute Protocol - Protocol that maps arbitrary data via key/value pairs on-chain.
- HAIP - Hash Author Identity Protocol - Similar to AIP but hashes the data signed for smaller capacity devices.
- Memo SV - Protocol that defines various actions on Memo's on-chain social network by embedding them in OP_RETURN transactions.
- Contact the Bitcoin Association to have your stable, released protocol added.