nyuuzyou/wikis huggingface dataset:
BIP37 privacy problems

BIP_0037 is a protocol for bitcoin lightweight wallets. It was designed with privacy in mind, but the protocol has serious design flaws leading to essentially no privacy for anyone who uses it. It is equivalent to sending all the wallets addresses to a random server which can easily spy on the wallet.
There are at least three major flaws of BIP37:
* Due to a design flaw, the stated false positive rate (fp) is reduced to fp^2. For example a false positive rate of 20% will in reality produce a false positive rate of 4%
* The same wallet may produce different bloom filters. If two or more filters are collected by an adversary then the intersection can be computed which removes false positives.
* If a bloom filter is combined with information about the transaction graph on the blockchain, then false positive addresses found by the adversary can be eliminated by seeing that they dont make any transactions to any other addresses from the filter.
This last privacy break is most comprehensive. Mike Hearnhttps://groups.google.com/forum/#!msg/bitcoinj/Ys13qkTwcNg/9qxnhwnkeoIJ describes this in more eloquence:
The reason bitcoinj doesn't use the obfuscation capabilities of the Bloom filtering protocol is that lying consistently is hard. Let's elaborate on what this means. The Bloom filtering protocol lie about what it's interested in from a remote node. But anyone who ever watched a cop show knows that lying is one thing, but lying without getting caught is something else entirely. Usually in these shows, the detective cleverly puzzles out whodunnit from inconsistencies and mistakes in the suspect's story. Common problems that let the detective catch the bad guy include: constantly changing their story, telling different lies to different observers, telling lies that contain elements of the truth and so on.
Subgraph traversal
As we all know, Bloom filters allow us to match more transactions and script elements than we actually need, and in a way that the server doesn't know which we genuinely care about and which we don't. The problem starts when we realise that what we actually care about is not transactions but rather transaction chains. If we observe a payment to our address A whilst scanning the chain, we must also observe any transaction that spends that payment. Otherwise if someone cloned their wallet to another machine and we were in a watching wallet configuration, we would have no idea the money was actually spent. And it's recursive - having observed the transaction that spends the payment, if it had a change address we must also observe any transaction that spends that transaction, and so on, following the "peel chain" of transactions all the way to the bottom.
Lessons from the failure of BIP37 can be useful when designing and understanding other privacy solutions, especially with the point about data fusion of combining BIP37 bloom filter leaks with blockchain transaction information leaks.
==Better alternatives==
* Full node#Privacy
* Client-side block filtering
==External links==
* https://jonasnick.github.io/blog/2015/02/12/privacy-in-bitcoinj/
==References==
Category:Privacy
BIPS

BIPS was a Payment Service Provider (PSP) specializing in the technical aspects of accepting cryptocurrencies - such as bitcoin.
==Bitcoin Payment Solutions==
Provided services for merchants in 204 countries.
==Merchant Tools==
For merchants using an eCommerce platform, choose between a wide range of bitcoin plugins. For merchants without an eCommerce solution, BIPS offered Hosted Invoices. Hosted Invoices could be used for both catalogue of items and a shopping cart with buttons and widgets per item. Also Hosted Invoices supported recurring billing in bitcoin, by emailing invoice links or using BIP70 Payment Requests.
===Point of Sale===
BIPS delivered near field communication (NFC) to "make secure payments fast and convenient by simply tapping the phone on any BIPS-enabled point of sale at checkout. And the possibility of sending payment information via sound based on Chirp".
BIPS POS NFC could be used with the following devices:
Phones
 HTC One on Sprint
 HTC One SV on Boost Mobile
 HTC EVO 4G LTE on Sprint
 LG Viper 4G LTE on Sprint
 LG Viper 4G LTE on Zact Mobile
 LG Optimus Elite on Sprint
 LG Optimus Elite on Virgin Mobile
 LG Optimus Elite on Zact Mobile
 LG Nexus 4*
 LG Nexus 5*
 Motorola Moto X*
 Samsung Galaxy Note II on Sprint
 Samsung Galaxy Note II on US Cellular
 Samsung Galaxy SIII on Sprint
 Samsung Galaxy SIII on MetroPCS
 Samsung Galaxy SIII on US Cellular
 Samsung Galaxy SIII on Virgin Mobile
 Samsung Galaxy SIII on Boost Mobile
 Samsung Galaxy S4 on Sprint (model number must be SPH-L720)
 Samsung Galaxy S4 on US Cellular
 Samsung Galaxy S4 Google Play Edition*
 Samsung Nexus S 4G on Sprint
 Samsung Galaxy Nexus on Sprint
 Samsung Galaxy Nexus*
 Samsung Galaxy Victory 4G LTE on Sprint
 Samsung Galaxy Victory 4G LTE on Virgin Mobile
 Samsung Galaxy Axiom on US Cellular
Tablets
 Asus Nexus 7
 Samsung Nexus 10
===Former business model===
BIPS didn't charge merchants for accepting Bitcoin online or with the point of sale as payment for merchandise, but ran a 0% Payment Processing Fees, and planned to make money by the conversion spread.
===Settlement===
Exchanged bitcoins were sent to the customer's bank account in 1-5 business days. With the possibility of setting a % to be transferred, or simply keeping bitcoin.
Motto: sell for $100, see $100 deposited into your bank*
==Consumer Side==
===Buy Bitcoins===
BIPS provided a now defunct market to buy Bitcoins from any country in the world.
===Sell Bitcoins===
You could receive payouts to banks in any currency in any country.
==History==
With experience in Bitcoin since 2010, BIPS was founded in July 2011.
In 2013, the company lost 1,295 bitcoins (then worth around US$1 Million) in an online theft 
After the heist company did not provide any refunds and never recovered.
==See Also==
* Bitcoin Ladder
==References==
Lorenzo Franceschi-Bicchierai (November 25, 2013). "Cyberattack Leads to $1 Million Bitcoin Heist". Mashable.
Category:Defunct exchanges‏‎
Category:Clients‏‎
Category:ECommerce‏‎
Category:EWallets‏‎
Category:Economics‏‎
Category:Financial‏‎
Category:Shopping Cart Interfaces
Category:Payment Processors
Category:Bitcoin payment systems
BIPS/API

===Meet the REST API===
It’s so easy, we’ve embedded a bunch of examples right here.
curl https://bips.me/api/v1/invoice \
-u apikey \
-d price=100 \
-d currency=USD
===Documentation===
REST API parameter details with examples of constructing requests.
Learn more
===Quickstart===
Step by step guides building basic web apps that accept bitcoin payments.
Learn more
BIP 0031

BIP: 31
 Layer: Peer Services
 Title: Pong message
 Author: Mike Hearn <hearn@google.com>
 Comments-Summary: No comments yet.
 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0031
 Status: Final
 Type: Standards Track
 Created: 2012-04-11
==Abstract==
This document describes a trivial protocol extension that makes it easier for clients to detect dead peer connections.
==Motivation==
Today there are a few network related problems that can degrade the Bitcoin user experience:
1) Some Bitcoin clients run on platforms that can go to sleep and essentially stop running at any time without warning. Notably, this is very common on both mobiles and laptops (shut the lid). When the system comes back, TCP connections that existed before the sleep still exist but may no longer function correctly, eg, because the IP address has changed, or because the remote peer went away or the connection was timed out by some other system. Currently it can often take a while to notice this has happened.
2) The reference Satoshi client is largely single threaded and when placed under heavy load (e.g., because it is downloading the block chain) becomes very slow to respond to network messages. There's no easy way to detect this has occurred, especially if you are just passively waiting for broadcasts from that peer. A way to detect overloaded remote peers and avoid them would both help balance load and provide a better, more responsive system.
3) When downloading large data structures like the block chain it is efficient to choose a peer that is near to you network-wise, in order to reduce load on often congested trans-national links and ensure lower latency. Currently it is difficult to measure the latency to a remote peer so clients don't bother, and instead just select a random peer to download from.
All of these can be solved by a backwards compatible protocol modification.
==Specification==
When the protocol version as negotiated in the "ver" message is greater than 60000, the "ping" message must contain a uint64 field called "nonce". A peer sending "ping" should set the nonce to a random value, and it is then echoed back by the recipient in a new "pong" message that also contains a single uint64 field.
In this way, the client can send a ping and measure the time taken to receive the corresponding pong. If a client sends two pings before hearing back the first pong, the responses can be distinguished using the nonce. If the client chooses to never overlap pings in this way it should simply set the nonce value to zero.
==Backward compatibility==
Clients must opt-in to the new feature by advertising a protocol version > 60000. Clients with older protocol versions are not expected to provide a nonce in the ping message and will not be sent a pong.
==Implementation==
https://github.com/bitcoin/bitcoin/pull/932/files
BIP 0034

BIP: 34
 Layer: Consensus (soft fork)
 Title: Block v2, Height in Coinbase
 Author: Gavin Andresen <gavinandresen@gmail.com>
 Comments-Summary: No comments yet.
 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0034
 Status: Final
 Type: Standards Track
 Created: 2012-07-06
==Abstract==
Bitcoin blocks and transactions are versioned binary structures. Both currently use version 1. This BIP introduces an upgrade path for versioned transactions and blocks. A unique value is added to newly produced coinbase transactions, and blocks are updated to version 2.
==Motivation==
# Clarify and exercise the mechanism whereby the bitcoin network collectively consents to upgrade transaction or block binary structures, rules and behaviors.
# Enforce block and transaction uniqueness, and assist unconnected block validation.
==Specification==
# Treat transactions with a version greater than 1 as non-standard (official Satoshi client will not mine or relay them).
# Add height as the first item in the coinbase transaction's scriptSig, and increase block version to 2. The format of the height is "minimally encoded serialized CScript" -- first byte is number of bytes in the number (will be 0x03 on main net for the next 150 or so years with 223-1 blocks), following bytes are little-endian representation of the number (including a sign bit). Height is the height of the mined block in the block chain, where the genesis block is height zero (0).
# 75% rule: If 750 of the last 1,000 blocks are version 2 or greater, reject invalid version 2 blocks. (testnet3: 51 of last 100)
# 95% rule ("Point of no return"): If 950 of the last 1,000 blocks are version 2 or greater, reject all version 1 blocks. (testnet3: 75 of last 100)
==Backward compatibility==
All older clients are compatible with this change. Users and merchants should not be impacted. Miners are strongly recommended to upgrade to version 2 blocks. Once 95% of the miners have upgraded to version 2, the remainder will be orphaned if they fail to upgrade.
==Implementation==
https://github.com/bitcoin/bitcoin/pull/1526
==Result==
Block number 227,835 (timestamp 2013-03-24 15:49:13 GMT) was the last version 1 block.
BIP 0035

BIP: 35
 Layer: Peer Services
 Title: mempool message
 Author: Jeff Garzik <jgarzik@exmulti.com>
 Comments-Summary: No comments yet.
 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0035
 Status: Final
 Type: Standards Track
 Created: 2012-08-16
==Abstract==
Make a network node's transaction memory pool accessible via a new "mempool" message. Extend the existing "getdata" message behavior to permit accessing the transaction memory pool.
==Motivation==
Several use cases make it desirable to expose a network node's transaction memory pool:
# SPV clients, wishing to obtain zero-confirmation transactions sent or received.
# Miners, to avoid missing lucrative fees, downloading existing network transactions after a restart.
# Remote network diagnostics.
==Specification==
# The mempool message is defined as an empty message where pchCommand == "mempool"
# Upon receipt of a "mempool" message, the node will respond with an "inv" message containing MSG_TX hashes of all the transactions in the node's transaction memory pool, if any.
# The typical node behavior in response to an "inv" is "getdata". However, the reference Satoshi implementation ignores requests for transaction hashes outside that which is recently relayed. To support "mempool", an implementation must extend its "getdata" message support to querying the memory pool.
# Feature discovery is enabled by checking two "version" message attributes:
## Protocol version >= 60002
## NODE_NETWORK bit set in nServices
Note that existing implementations drop "inv" messages with a vector size > 50000.
==Backward compatibility==
Older clients remain 100% compatible and interoperable after this change.
==Implementation==
https://github.com/bitcoin/bitcoin/pull/1641
BIP 0043

BIP: 43
 Layer: Applications
 Title: Purpose Field for Deterministic Wallets
 Author: Marek Palatinus <slush@satoshilabs.com>
 Pavol Rusnak <stick@satoshilabs.com>
 Comments-Summary: No comments yet.
 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0043
 Status: Final
 Type: Standards Track
 Created: 2014-04-24
==Abstract==
This BIP introduces a "Purpose Field" for use in deterministic wallets
based on algorithm described in BIP-0032 (BIP32 from now on).
==Motivation==
Although Hierarchical Deterministic Wallet structure as described by BIP32
is an important step in user experience and security of the cryptocoin wallets,
the BIP32 specification offers implementors too many degrees of freedom.
Multiple implementations may claim they are BIP32 compatible, but in fact
they can produce wallets with different logical structures making them
non-interoperable. This situation unfortunately renders "BIP32 compatible"
statement rather useless.
==Purpose==
We propose the first level of BIP32 tree structure to be used as "purpose".
This purpose determines the further structure beneath this node.
m / purpose' / *
Apostrophe indicates that BIP32 hardened derivation is used.
We encourage different schemes to apply for assigning a separate BIP number
and use the same number for purpose field, so addresses won't be generated
from overlapping BIP32 spaces.
Purpose codes from 10001 to 19999 are reserved for [].
Example: Scheme described in BIP44 should use 44' (or 0x8000002C) as purpose.
Note that m / 0' / * is already taken by BIP32 (default account), which
preceded this BIP.
Not all wallets may want to support the full range of features and possibilities
described in these BIPs. Instead of choosing arbitrary subset of defined features
and calling themselves BIPxx compatible, we suggest that software which needs
only a limited structure should describe such structure in another BIP and use
different "purpose" value.
==Node serialization==
Because this scheme can be used to generate nodes for more cryptocurrencies
at once, or even something totally unrelated to cryptocurrencies, there's no
point in using a special version magic described in section "Serialization
format" of BIP32. We suggest to use always 0x0488B21E for public and 0x0488ADE4
for private nodes (leading to prefixes "xpub" and "xprv" respectively).
==Reference==
* BIP32 - Hierarchical Deterministic Wallets
BIP 0071

BIP: 71
 Layer: Applications
 Title: Payment Protocol MIME types
 Author: Gavin Andresen <gavinandresen@gmail.com>
 Comments-Summary: No comments yet.
 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0071
 Status: Final
 Type: Standards Track
 Created: 2013-07-29
==Abstract==
This BIP defines a MIME (RFC 2046) Media Type for Bitcoin payment
request messages.
==Motivation==
Wallet or server software that sends payment protocol messages over
email or http should follow Internet standards for properly
encapsulating the messages.
==Specification==
The Media Type (Content-Type in HTML/email headers) for bitcoin
protocol messages shall be:
Message 	Type/Subtype
PaymentRequest	application/bitcoin-paymentrequest
Payment 	application/bitcoin-payment
PaymentACK 	application/bitcoin-paymentack
Payment protocol messages are encoded in binary.
==Example==
A web server generating a PaymentRequest message to initiate the
payment protocol would precede the binary message data with the
following headers:
Content-Type: application/bitcoin-paymentrequest
Content-Transfer-Encoding: binary
BIP 0072

BIP: 72
 Layer: Applications
 Title: bitcoin: uri extensions for Payment Protocol
 Author: Gavin Andresen <gavinandresen@gmail.com>
 Comments-Summary: No comments yet.
 Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0072
 Status: Final
 Type: Standards Track
 Created: 2013-07-29
==Abstract==
This BIP describes an extension to the bitcoin: URI scheme (BIP 21) to
support the payment protocol (BIP 70).
==Motivation==
Allow users to click on a link in a web page or email to initiate the
payment protocol, while being backwards-compatible with existing
bitcoin wallets.
==Specification==
The bitcoin: URI scheme is extended with an additional, optional
"r" parameter, whose value is a URL from which a PaymentRequest
message should be fetched (characters not allowed within the scope
of a query parameter must be percent-encoded as described in RFC 3986
and bip-0021).
If the "r" parameter is provided and backwards compatibility
is not required, then the bitcoin address portion of the URI may be
omitted (the URI will be of the form: bitcoin:?r=... ).
When Bitcoin wallet software that supports this BIP receives a
bitcoin: URI with a request parameter, it should ignore the bitcoin
address/amount/label/message in the URI and instead fetch a
PaymentRequest message and then follow the payment protocol, as
described in BIP 70.
Bitcoin wallets must support fetching PaymentRequests via http and
https protocols; they may support other protocols. Wallets must
include an "Accept" HTTP header in HTTP(s) requests (as defined
in RFC 2616):
Accept: application/bitcoin-paymentrequest
If a PaymentRequest cannot be obtained (perhaps the server is
unavailable), then the customer should be informed that the merchant's
payment processing system is unavailable. In the case of an HTTP
request, status codes which are neither success nor error (such as
redirect) should be handled as outlined in RFC 2616.
==Compatibility==
Wallet software that does not support this BIP will simply ignore the
r parameter and will initiate a payment to bitcoin address.
==Examples==
A backwards-compatible request:
bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
Non-backwards-compatible equivalent:
bitcoin:?r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
==References==
[2616] : Hypertext Transfer Protocol -- HTTP/1.1
BIP 0080

BIP: 80
 Title: Hierarchy for Non-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-0080
 Status: Deferred
 Type: Informational
 Created: 2014-08-11
 License: PD
==Abstract==
This BIP defines a logical hierarchy for non-colored 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 coins and multiple series from a single seed.
==Path levels==
We define the following 4 levels in BIP32 path:
m / purpose' / coin_type' / series' / 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 "80" with the most significant bit set to indicate hardened derivation (0x80000050). It indicates that the subtree of this node is used according to this specification.
Hardened derivation is used at this level.
===Coin type===
One master node (seed) can be used for unlimited number of independent cryptocoins such as Bitcoin, Litecoin or Namecoin. However, sharing the same space for various cryptocoins has some disadvantages.
This level creates a separate subtree for every cryptocoin, avoiding reusing addresses across cryptocoins and improving privacy issues.
Coin type is a constant, set for each cryptocoin. The list of registered coin type constants should be obtained from BIP44.
Hardened derivation is used at this level.
===Series===
Series are used by voting pools in order to implement FIFO cold storage. By directing deposits into multiple series, the private keys for most of the deposits can be kept offline, and a limited portion can be brought online to process withdrawals.
Hardened derivation is used at this level.
===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