Bitcoin Wiki - User contributions [en]

Application layer protocol

2020-10-23T04:01:15Z

Ethel:

=== 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 [[History_of_OP_RETURN#Storing_data_on-chain|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_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.

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:\\:

19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut

Followed by the different fields B:\\ defines as additional push data:
[Image Buffer]
image/png
binary
duck.png

Here is the [https://b.bitdb.network/#d6f000641a9bb66f510d8b66763c8f28fceb5b61b8bb6f9544c1a81db73805b4 example].

=== 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 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.
* [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] - 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 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://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://memo.sv/protocol Memo SV] - Protocol that defines various actions on Memo's on-chain social network embedded in OP_RETURN transactions.
* Contact the Bitcoin Association to have your stable, released protocol added.

Application layer protocol

2020-10-23T02:24:56Z

Ethel: commas,

=== 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 [[History_of_OP_RETURN#Storing_data_on-chain|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_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.

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:\\:

19HxigV4QyBv3tHpQVcUEQyq1pzZVdoAut

Followed by the different fields B:\\ defines as additional push data:
[Image Buffer]
image/png
binary
duck.png

Here is the [https://b.bitdb.network/#d6f000641a9bb66f510d8b66763c8f28fceb5b61b8bb6f9544c1a81db73805b4 example].

=== 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 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.
* [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] - Decentralized 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 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://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://memo.sv/protocol Memo SV] - Protocol that defines various actions on Memo's on-chain social network embedded in OP_RETURN transactions.
* Contact the Bitcoin Association to have your stable, released protocol added.

Address reuse

2020-10-23T01:44:09Z

Ethel: Punctuation only

'''Address reuse''' refers to the use of the same [[Bitcoin address|address]] for multiple [[Bitcoin Transactions|transactions]]. It is an unintended practice, reducing the privacy and security of the participants of the transactions.

Most wallets use [[Deterministic wallet|deterministic keychains]] and mask the generation of new addresses from the user making it easy and safe to maintain privacy.

== Problems ==
=== Privacy ===
Address reuse harms the privacy of not only yourself, but also others - including many not related to the transaction.

Every time a re-used address private key signs a fresh transaction, the receiving party can use the history of that address to discover information about that address and its owner.

The relationship graph in a re-used address is powerfully-linked in that '''all''' of the inputs to that address are necessarily joined (via the spending authority of the private key) to all of its outputs.

==Attribution==
This content is based on content sourced from https://en.bitcoin.it/wiki/Address_reuse under [https://creativecommons.org/licenses/by/3.0/ Creative Commons Attribution 3.0]. Although it may have been extensively revised and updated, we acknowledge the original authors.

Block header

2020-10-23T01:18:18Z

Ethel:

The block header is the first piece of information propagated by a node when it finds a valid block solution. Other nodes on the network, can validate the node's hash solution and determine whether the proposed block warrants the further checking required to secure its place as the top-most link in the longest chain of valid proof of work.

A block header contains these fields:
{| class="wikitable"
|-
! Field
! Purpose
! Updated when...
! Size (Bytes)
|-
|Version
|Block version number
|You upgrade the software and it specifies a new version
|4
|-
|hashPrevBlock
|256-bit hash of the previous block header
|A new block comes in
|32
|-d
|hashMerkleRoot
|256-bit hash based on all of the transactions in the block
|A transaction is accepted
|32
|-
|Time
|Current [[block timestamp]] as seconds since 1970-01-01T00:00 UTC
|Every few seconds
|4
|-
|Bits
|Current [[target]] in compact format
|The [[difficulty]] is adjusted
|4
|-
|Nonce
|32-bit number (starts at 0)
|A hash is tried (increments)
|4
|}

The body of the block contains the transactions. These are hashed only indirectly through the Merkle root. Because transactions aren't hashed directly, the proof of work needed to mine a block with 1 transaction takes exactly the same amount of effort as a block with 10,000, 10,000,000 or 10,000,000,000 transactions.

The format of target is a floating-point encoding using a 3 byte mantissa, the leading byte as exponent (where only the 5 lowest bits are used) and its base is 256.

It is not possible for two nodes to be working on the same Merkle root because the [[Coinbase]] transaction is unique to that node, generating a different hash output. Every hash attempt made has the same chance of winning as every other hash calculated across the network.

==Endianess==
Note that the hash, which is a 256-bit number, has lots of leading zero bytes when stored or printed as a big-endian hexadecimal constant, but it has trailing zero bytes when stored or printed in little-endian. For example, if interpreted as a string and the lowest (or start of) the string address keeps lowest significant byte, it is little-endian.

Most block explorers display the hash values as big-endian numbers; notation for numbers is usual (leading digits are the most significant digits read from left to right).