nyuuzyou/wikis huggingface dataset:
BIP 0081

BIP: 81
 Title: Hierarchy for Colored Voting Pool Deterministic Multisig Wallets
 Author: Justus Ranvier <justus@opentransactions.org>
 Jimmy Song <jimmy@monetas.net>
 Comments-Summary: No comments yet.
 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0081
 Status: Deferred
 Type: Informational
 Created: 2014-08-11
 License: PD
==Abstract==
This BIP defines a logical hierarchy for colored coin voting pool deterministic multisig wallets based on an algorithm described in BIP-0032 (BIP32 from now on) and purpose scheme described in BIP-0043 (BIP43 from now on).
This BIP is a particular application of BIP43 and is based on BIP44.
==Motivation==
The hierarchy proposed in this paper allows the handling of multiple color definitions from a single seed.
==Path levels==
We define the following 8 levels in BIP32 path:
m / purpose' / series' / (5 color definition levels) / address_index
Apostrophe in the path indicates that BIP32 hardened derivation is used.
Each level has a special meaning, described in the chapters below.
===Purpose===
Purpose is a constant set following the BIP43 recommendation to: the ASCII value of "81" with the most significant bit set to indicate hardened derivation (0x80000051). It indicates that the subtree of this node is used according to this specification.
Hardened derivation is used at this level.
===Color Definition===
Index values which can be applied to a BIP32 node are limited to 4 bytes (32 bits).
Since this is not sufficient to identify color definitions without a risk of collision, multiple levels are used.
Color definitions are first shortened to 20 bytes using the Bitcoin hash160 function.
The resulting 20 bytes are split into five groups in little endian format, and where each group is used as the seed for the five levels of color definition levels
Public derivation is used at these levels, even when the index exceeds 2^31.
===Index===
Public/private keypairs are numbered from index 0 in sequentially increasing manner. This number is used as child index in BIP32 derivation.
Public keys obtained at this level of the hierarchy are used to construct multisig deposit scripts, using a schema that is shared between the members as an out-of-band contract.
Public derivation is used at this level.
==Compatible wallets==
* [] is the reference Bitcoin wallet for voting pools.
==Copyright==
This document is placed in the public domain.
==Reference==
* BIP32 - Hierarchical Deterministic Wallets
* BIP43 - Purpose Field for Deterministic Wallets
* BIP44 - Multi-Account Hierarchy for Deterministic Wallets
* BIP80 - Hierarchy for Non-Colored Voting Pool Deterministic Multisig Wallets
BIP 0102

BIP: 102
 Layer: Consensus (hard fork)
 Title: Block size increase to 2MB
 Author: Jeff Garzik <jgarzik@gmail.com>
 Comments-Summary: No comments yet.
 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0102
 Status: Rejected
 Type: Standards Track
 Created: 2015-06-23
==Abstract==
Simple, one-time increase in total amount of transaction data permitted in a block from 1MB to 2MB.
==Motivation==
# Continue current economic policy.
# Exercise hard fork network upgrade.
==Specification==
# MAX_BLOCK_SIZE increased to 2,000,000 bytes at trigger point.
# Increase maximum block sigops by similar factor, preserving SIZE/50 formula.
# Trigger: (1) Block time 00:00:00 on flag day, AND (2) 95% of the last 1,000 blocks have signaled support.
==Backward compatibility==
Fully validating older clients are not compatible with this change.
The first block exceeding 1,000,000 bytes will partition older clients
off the new network.
==Discussion==
In the short term, an increase is needed to continue to current
economic policies with regards to fees and block space, matching
market expectations and preventing market disruption.
In the long term, this limit should focus on reflecting the maximum
network engineering limit.
==Implementation==
https://github.com/jgarzik/bitcoin/tree/2015_2mb_blocksize
BIP 0130

BIP: 130
 Layer: Peer Services
 Title: sendheaders message
 Author: Suhas Daftuar <sdaftuar@chaincode.com>
 Comments-Summary: No comments yet.
 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0130
 Status: Proposed
 Type: Standards Track
 Created: 2015-05-08
 License: PD
==Abstract==
Add a new message, "sendheaders", which indicates that a node prefers to receive new block announcements via a "headers" message rather than an "inv".
==Motivation==
Since the introduction of "headers-first" downloading of blocks in 0.10, blocks will not be processed unless
they are able to connect to a (valid) headers chain. Consequently, block relay generally works
as follows:
# A node (N) announces the new tip with an "inv" message, containing the block hash
# A peer (P) responds to the "inv" with a "getheaders" message (to request headers up to the new tip) and a "getdata" message for the new tip itself
# N responds with a "headers" message (with the header for the new block along with any preceding headers unknown to P) and a "block" message containing the new block
However, in the case where a new block is being announced that builds on the tip, it would be generally more efficient if the node N just announced the block header for the new block, rather than just the block hash, and saved the peer from generating and transmitting the getheaders message (and the required block locator).
In the case of a reorg, where 1 or more blocks are disconnected, nodes currently just send an "inv" for the new tip. Peers currently are able to request the new tip immediately, but wait until the headers for the intermediate blocks are delivered before requesting those blocks. By announcing headers from the last fork point leading up to the new tip in the block announcement, peers are able to request all the intermediate blocks immediately.
==Specification==
# The sendheaders message is defined as an empty message where pchCommand == "sendheaders"
# Upon receipt of a "sendheaders" message, the node will be permitted, but not required, to announce new blocks by sending the header of the new block (along with any other blocks that a node believes a peer might need in order for the block to connect).
# Feature discovery is enabled by checking protocol version >= 70012
==Additional constraints==
As support for sendheaders is optional, software that implements this may also optionally impose additional constraints, such as only honoring sendheaders messages shortly after a connection is established.
==Backward compatibility==
Older clients remain fully compatible and interoperable after this change.
==Implementation==
https://github.com/bitcoin/bitcoin/pull/6494
==Copyright==
This document is placed in the public domain.
BIP 0149

BIP: 149
 Layer: Consensus (soft fork)
 Title: Segregated Witness (second deployment)
 Author: Shaolin Fry <shaolinfry@protonmail.ch>
 Comments-Summary: No comments yet.
 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0149
 Status: Withdrawn
 Type: Standards Track
 Created: 2017-04-14
 License: BSD-3-Clause
 CC0-1.0
==Abstract==
This document specifies a user activated soft fork for BIP141, BIP143 and BIP147 using versionbits with guaranteed lock-in.
==Motivation==
Miners have been reluctant to signal the BIP9 segwit deployment despite a large portion of the Bitcoin ecosystem who want the soft fork activated. This BIP specifies a user activated soft fork (UASF) that deploys segwit again using versionbits with guaranteed lock-in on timeout if the BIP is not already locked-in or activated by the timeout. This ensures users have sufficient time to prepare and no longer require a miner supermajority, while still allowing for an earlier miner activated soft fork (MASF).
==Reference implementation==
The reference implementation will refuse to run on Bitcoin mainnet before 7 November 2017, and can only be run on testnet and regtest until then.
https://github.com/bitcoin/bitcoin/compare/master...shaolinfry:uasegwit-flagday
==Specification==
This deployment will set service bit (1<<5) as NODE_UAWITNESS.
==Deployment==
This BIP should only be deployed if BIP9-segwit fails to lock-in or activate before timeout on 15 November 2017. This BIP cannot be deployed before 15 November 2017.
This BIP will be deployed by BIP8 with the name "segwit" and using bit 1.
For Bitcoin mainnet, the BIP8 starttime will be midnight 16 November 2017 UTC (Epoch timestamp 1510790400) and BIP8 timeout will be 4 July 2018 UTC (Epoch timestamp 1530662400).
For Bitcoin testnet, segwit is already activated so no deployment is specified.
==Backwards Compatibility==
This deployment reuses the GBT deployment name "segwit" to maintain compatibility with existing mining software.
This deployment is incompatible with the BIP9-segwit deployment and should not be run concurrently with it.
==Rationale==
The starttime of this BIP is after the BIP9-segwit timeout to remove compatibility issues with old nodes.
==References==
Mailing list discussion
BIP8
BIP9
BIP141
BIP143
BIP147
==Copyright==
This document is dual licensed as BSD 3-clause, and Creative Commons CC0 1.0 Universal.
BIP 0159

BIP: 159
 Layer: Peer Services
 Title: NODE_NETWORK_LIMITED service bit
 Author: Jonas Schnelli <dev@jonasschnelli.ch>
 Comments-Summary: No comments yet.
 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0159
 Status: Final
 Type: Standards Track
 Created: 2017-05-11
 License: BSD-2-Clause
== Abstract ==
Define a service bit that allow pruned peers to signal their limited services
==Motivation==
Pruned peers can offer the same services as traditional peer except of serving all historical blocks.
Bitcoin right now only offers the NODE_NETWORK service bit which indicates that a peer can serve
all historical blocks.
# Pruned peers can relay blocks, headers, transactions, addresses and can serve a limited number of historical blocks, thus they should have a way how to announce their service(s)
# Peers no longer in initial block download should consider connecting some of its outbound connections to pruned peers to allow other peers to bootstrap from non-pruned peers
== Specification ==
=== New service bit ===
This BIP proposes a new service bit
NODE_NETWORK_LIMITED	bit 10 (0x400)	If signaled, the peer <I>MUST</I> be capable of serving at least the last 288 blocks (~2 days).
A safety buffer of 144 blocks to handle chain reorganizations <I>SHOULD</I> be taken into account when connecting to a peer signaling the NODE_NETWORK_LIMITED service bit.
=== Address relay ===
Full nodes following this BIP <I>SHOULD</I> relay address/services (addr message) from peers they would connect to (including peers signaling NODE_NETWORK_LIMITED).
=== Counter-measures for peer fingerprinting ===
Peers may have different prune depths (depending on the peers configuration, disk space, etc.) which can result in a fingerprinting weakness (finding the prune depth through getdata requests). NODE_NETWORK_LIMITED supporting peers <I>SHOULD</I> avoid leaking the prune depth and therefore not serve blocks deeper than the signaled NODE_NETWORK_LIMITED threshold (288 blocks).
=== Risks ===
Pruned peers following this BIP may consume more outbound bandwidth.
Light clients (and such) who are not checking the nServiceFlags (service bits) from a relayed addr-message may unwillingly connect to a pruned peer and ask for (filtered) blocks at a depth below their pruned depth. Light clients should therefore check the service bits (and eventually connect to peers signaling NODE_NETWORK_LIMITED if they require [filtered] blocks around the tip). Light clients obtaining peer IPs though DNS seed should use the DNS filtering option.
== Compatibility ==
This proposal is backward compatible.
== Reference implementation ==
* https://github.com/bitcoin/bitcoin/pull/11740 (signaling)
* https://github.com/bitcoin/bitcoin/pull/10387 (connection and relay)
== Copyright ==
This BIP is licensed under the 2-clause BSD license.
BIP 0179

BIP: 179
 Title: Name for payment recipient identifiers
 Author: Emil Engler <me@emilengler.com>
 Luke Dashjr <luke+bip@dashjr.org>
 Comments-Summary: No comments yet.
 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0179
 Status: Draft
 Type: Informational
 Created: 2019-10-17
 License: CC0-1.0
==Abstract==
This BIP proposes a new term for 'address'
==Specification==
The new term is:
Bitcoin Invoice Address
The Bitcoin and Address parts are optional.
The address suffix should only be used as a transitional step.
A Bitcoin Invoice Address is a string of characters that can be used to indicate the intended recipient and purpose of a transaction.
==Motivation==
Bitcoin addresses are intended to be only used once and you should generate a new one for every new incoming payment.
The term 'address' however indicates consistency because nearly everything on the internet or the offline world with the term 'address'
is something that rarely or even never changes (postal address, email address, IP addresses (depends heavily on the provider), etc.)
The motivation for this BIP is to change the term address to something that indicates that the address is connected to a single transaction.
==Rationale==
The reason why we use Bitcoin Invoice Address or just Invoice is to emphasize that it is single-use.
The terms Bitcoin and Address are optional for the following reasons:
For Bitcoin:
* Useful for multicoin wallets to indicate that it belongs to Bitcoin
* Indicates a difference between a lightning and an on-chain invoice
For Address:
* To not confuse users with a completely new term
* To show that it is where you send something to
* To not break backwards compatibility
This gives us the four following possibilities:
* Bitcoin Invoice Address
* Bitcoin Invoice
* Invoice Address
* Invoice
==Backwards Compatibility==
To avoid issues, the 'Address' suffix is permitted, but not recommended.
The suffix 'Address' remains so users should be immediately able to recognize it until the new term is widely known.
==Acknowledgements==
Thanks to Chris Belcher for the suggestion of the term 'Bitcoin Invoice Address'
==Copyright==
This BIP is released under CC0-1.0 and therefore Public Domain.
BIP 0339

BIP: 339
 Layer: Peer Services
 Title: WTXID-based transaction relay
 Author: Suhas Daftuar <sdaftuar@chaincode.com>
 Comments-Summary: No comments yet.
 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0339
 Status: Draft
 Type: Standards Track
 Created: 2020-02-03
 License: BSD-2-Clause
==Abstract==
This BIP describes two changes to the p2p protocol to support transaction relay
based on the BIP 141 wtxid of a transaction, rather than its txid.
==Motivation==
Historically, the inv messages sent on the Bitcoin peer-to-peer network to
announce transactions refer to transactions by their txid, which is a hash of
the transaction that does not include the witness (see BIP 141). This has been
the case even since Segregated Witness (BIP 141/143/144) has been adopted by
the network.
Not committing to the witness in transaction announcements creates
inefficiencies: because a transaction's witness can be malleated without
altering the txid, a node in receipt of a witness transaction that the node
does not accept will generally still download that same transaction when
announced by other peers. This is because the alternative -- of not downloading
a given txid after rejecting a transaction with that txid -- would allow a
third party to interfere with transaction relay by malleating a transaction's
witness and announcing the resulting invalid transaction to nodes, preventing
relay of the valid version of the transaction as well.
We can eliminate this concern by using the wtxid in place of the txid when
announcing and fetching transactions.
==Specification==
# A new wtxidrelay message is added, which is defined as an empty message where pchCommand == "wtxidrelay".
# The protocol version of nodes implementing this BIP must be set to 70016 or higher.
# The wtxidrelay message MUST be sent in response to a version message from a peer whose protocol version is >= 70016 and prior to sending a verack. A wtxidrelay message received after a verack message MUST be ignored or treated as invalid.
# A new inv type MSG_WTX (0x00000005) is added, for use in both inv messages and getdata requests, indicating that the hash being referenced is a transaction's wtxid. In the case of getdata requests, MSG_WTX implies that the transaction being requested should be serialized with witness as well, as described in BIP 144.
# After a node has received a wtxidrelay message from a peer, the node MUST use the MSG_WTX inv type when announcing transactions to that peer.
# After a node has received a wtxidrelay message from a peer, the node SHOULD use a MSG_WTX getdata message to request any announced transactions. A node MAY still request transactions from that peer using MSG_TX getdata messages, such as for transactions not recently announced by that peer (like the parents of recently announced transactions).
==Backward compatibility==
As wtxid-based transaction relay is only enabled between peers that both support it, older clients remain fully compatible and interoperable after this change.
==Implementation==
https://github.com/bitcoin/bitcoin/pull/18044
==Copyright==
This BIP is licensed under the 2-clause BSD license.
BIP 0385

BIP: 385
 Layer: Applications
 Title: raw() and addr() Output Script Descriptors
 Author: Pieter Wuille <pieter@wuille.net>
 Ava Chow <me@achow101.com>
 Comments-Summary: No comments yet.
 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0385
 Status: Final
 Type: Informational
 Created: 2021-06-27
 License: BSD-2-Clause
==Abstract==
This document specifies raw() and addr() output script descriptors.
raw() encapsulates a raw script as a descriptor.
addr() encapsulates an address as a descriptor.
==Copyright==
This BIP is licensed under the BSD 2-clause license.
==Motivation==
In order to make descriptors maximally compatible with scripts in use today, it is useful to be able to wrap any arbitrary output script or an address into a descriptor.
==Specification==
Two new script expressions are defined: raw() and addr().
===raw()===
The raw(HEX) expression can only be used as a top level descriptor.
As the argument, it takes a hex string representing a Bitcoin script.
The output script produced by this descriptor is the script represented by HEX.
===addr()===
The addr(ADDR) expression can only be used as a top level descriptor.
It takes an address as its single argument.
The output script produced by this descriptor is the output script produced by the address ADDR.
==Test Vectors==
Valid descriptors followed by the scripts they produce.
* raw(deadbeef)
** deadbeef
* raw(512103a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd4104a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea23552ae)
** 512103a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd4104a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd5b8dec5235a0fa8722476c7709c02559e3aa73aa03918ba2d492eea75abea23552ae
* raw(a9149a4d9901d6af519b2a23d4a2f51650fcba87ce7b87)
** a9149a4d9901d6af519b2a23d4a2f51650fcba87ce7b87
* addr(3PUNyaW7M55oKWJ3kDukwk9bsKvryra15j)
** a914eeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee87
Invalid descriptors
* Non-hex script: raw(asdf)
* Invalid address: addr(asdf)
* raw nested in sh: sh(raw(deadbeef))
* raw nested in wsh: wsh(raw(deadbeef))
* addr nested in sh: sh(addr(3PUNyaW7M55oKWJ3kDukwk9bsKvryra15j))
* addr nested in wsh: wsh(addr(3PUNyaW7M55oKWJ3kDukwk9bsKvryra15j))
==Backwards Compatibility==
raw() and addr() descriptors use the format and general operation specified in 380.
As this is a wholly new descriptor, it is not compatible with any implementation.
The reuse of existing Bitcoin addresses allows for this to be more easily implemented.
==Reference Implementation==
raw() and addr() descriptors have been implemented in Bitcoin Core since version 0.17.
BIP MergedMiningScript

*<Block header is on stack>
*OP_SHA256d
*PUSH...: various other merged chains as merkle links
*PUSH: N of merkle links
*OP_MERKLEROOT_FROMLINKS
Inside parent chain coinbase:
*PUSH: coinbase prefix midstate
*OP_SWAP
*OP_SHA256FINISH
*OP_SHA256 (to get a SHA256d result; the parent chain coinbase's txid)
*PUSH...: various other transactions in parent chain (as merkle links)
*PUSH: N of merkle links
*OP_MERKLEROOT_FROMLINKS (stack now has the parent chain tx merkleroot)
*PREPEND: parent chain version
*APPEND: parent chain header ending
*OP_SHA256d (stack now has the proof-of-work)
Dedicated merged mining:
*APPEND: 16-bit time offset
*APPEND: 48-bit nonce
*OP_SHA256d
BL3P

BL3P is the official exchange of Bitonic. BL3P.eu officially went live in The Netherlands on April 4th, 2016. 
BL3P is unique in that it is the only exchange platform in The Netherlands and offers instant EUR deposits through iDEAL.
== History == 
Bitonic first started as iDealCoin in March, 2012, officially registering as a business with the Dutch Chamber of Commerce in May 2012. iDealCoin was renamed to Bitonic, an anagram to Bitcoin, in June 2012 About Bitonic.
BL3P has been in development since 2013 and available to Dutch users since April 4th, 2016, and available to all European countries since May 18th, 2017.
==Supported currencies==
* Bitcoin
==Supported payment methods==
* SEPA
* Bancontact / Mister Cash
* iDEAL
==External links==
BL3P website
==References==
Category:Exchanges
BTC-e

BTC-e was a bitcoin exchange that allowed trading bitcoins for fiat or altcoins. It was regarded as a "Big Four" exchange,http://www.coindesk.com/price/ Coindesk BPI having once handled 2.5% of all Bitcoin exchange volume.
In 2017, the exchange was shut down and revealed to have been the destination of stolen funds from Mt. Gox, Bitcoinica, and Bitfloor.
==History==
The site was first announced on July 17, 2011Btc-e.com exchange for the exchange of BTC <-> USD with test mode trading. Live trading began on August 7, 2011.Btc-e.com
On July 31, 2012, the service reported a security incident in which halted trading and caused financial loss to the exchange. The exchange says it covered losses from reserves and trading resumed in a matter of hours.News / Trade is stopped
On August 2, 2012, the service added an API for trading, but still lacked an API for bitcoin withdrawals (something offered by every other major exchange). On August 20, 2012 the service added the BTC/RUR and USD/RUR trading pairs. On September 3 the service added numerous RUR deposit and withdawal methods as well as more USD deposit and withdrawal methods.News / Update commissions deposit & withdrawal + add new methods withdrawal
==Criticism==
Bitcoin community member Luke-Jr claims that BTC-E has frozen his account and funds on their own accord.
==See Also==
* Alexander Vinnik
* Collapse of Mt. Gox
==References==
Category:Exchanges
Category:EWallets
BTC.com

BTC.com is a web wallet originally created by Blocktrail and now owned by Bitmain Technologies. It also publishes an Android wallet, an iOS Wallet, a Bitcoin API, a block explorer, and a mining pool. 
On July 19, 2016 Blocktrail was acquired by Bitmain and subsequently re-branded to BTC.com.http://www.coindesk.com/bitcoin-miner-bitmain-acquires-blockchain-data-startup/
==Wallet==
The wallets they offer allow you to buy bitcoin alongside basic wallet features and features like 2-factor-auth.
The wallets are open source software hosted at http://github.com/blocktrail/blocktrail-wallet.
== Mining Pool ==
On September 13, 2016, BTC.com launched a mining poolhttp://www.coindesk.com/bitmain-bitcoin-mining-launch-second-mining-pool/ using a settlement mode called PPS (pay-per-share).https://blog.btc.com/btc-com-launches-new-open-source-mining-pool-with-zero-mining-fee-2f6e0a53ce2c#.33zivpv2w
==See Also==
* Block chain browser
* Api
* Wallet
* Mining Pool
==External Links==
==References==
Category:Services
Category:Wallets
Category:Mobile
Category:Block chain browsers
Category:Frontends
Category:Bitcoin
Category:Clients
Category:Pool Operators