{{bip}}

<pre>
BIP: 60
Title: Fixed Length "version" Message (Relay-Transactions Field)
Author: Amir Taaki <genjix@riseup.net>
Status: Draft
Type: Standards Track
Created: 16-06-2013
</pre>

==Abstract==

[[BIP 0037]] introduced a new flag to version messages which says whether to relay new transaction messages to that node.

The protocol version was upgraded to 70001, and the (now accepted) BIP 0037 became implemented.

The implementation is problematic because the RelayTransactions flag is an optional part of the version message stream.

==Motivation==

One property of Bitcoin messages is their fixed number of fields. This keeps the format simple and easily understood. Adding optional fields to messages will cause deserialisation issues when other fields come after the optional one.

As an example, the length of version messages might be checked to ensure the byte stream is consistent. With optional fields, this checking is no longer possible. This is desirable to check for consistency inside internal deserialization code, and proper formatting of version messages originating from other nodes. In the future with diversification of the Bitcoin network, it will become desirable to enforce this kind of strict adherance to standard messages with field length compliance with every protocol version.

Another property of fixed-length field messages is the ability to pass stream operators around for deserialization. This property is also lost, as now the deserialisation code must know the remaining length of bytes to parse. The parser now requires an additional piece of information (remaining size of the stream) for parsing instead of being a dumb reader.

==Specification==
=== version ===

When a node creates an outgoing connection, it will immediately [[Version Handshake|advertise]] its version. The remote node will respond with its version. No futher communication is possible until both peers have exchanged their version.

Payload:

{|class="wikitable"
! Field Size !! Description !! Data type !! Comments
|-
| 4 || version || int32_t || Identifies protocol version being used by the node
|-
| 8 || services || uint64_t || bitfield of features to be enabled for this connection
|-
| 8 || timestamp || int64_t || standard UNIX timestamp in seconds
|-
| 26 || addr_recv || net_addr || The network address of the node receiving this message
|-
|colspan="4"| version >= 106
|-
| 26 || addr_from || net_addr || The network address of the node emitting this message
|-
| 8 || nonce || uint64_t || Node random nonce, randomly generated every time a version packet is sent. This nonce is used to detect connections to self.
|-
| ? || user_agent || [[#Variable length string|var_str]] || [[BIP_0014|User Agent]] (0x00 if string is 0 bytes long)
|-
| 4 || start_height || int32_t || The last block received by the emitting node
|-
| 1 || relay || bool || Whether the remote peer should announce relayed transactions or not, see [[BIP 0037]], since version >= 70001
|}

A "verack" packet shall be sent if the version packet was accepted.

The following services are currently assigned:

{|class="wikitable"
! Value !! Name !! Description
|-
| 1 || NODE_NETWORK || This node can be asked for full blocks instead of just headers.
|}

==Copyright==

This document is placed in the public domain.

[[Category:Developer]]
[[Category:Technical]]
[[Category:BIP|D]]

BIP 0060

2013-06-16T09:31:41Z

Genjix: /* Design rationale */

BIP 0060

2013-06-16T09:31:29Z

Genjix: /* Motivation */

2012-06-30T11:56:36Z

Genjix: /* API */

A [[currency exchange|exchange]] offering multiple trading markets for trading bitcoins against multiple currencies.

Traders add funds and then place orders to buy and sell. Intersango acts as an escrow. The site charges no trading fees.

[[Bitcoin Consultancy]] operates the exchange.

Intersango has a trading [https://bitcoinconsultancy.com/wiki/index.php/Intersango/API API]

==Trading==
===Buying===

A buy order is executed partially or in full when the price bid can be matched against a sell order that is at or below the bid amount.

===Selling===

A sell order is executed partially or in full when the price asked can be matched against a buy order that is at or above the ask amount.

No Fee (for a limited time).

==Adding Funds==
===BTC===

There are no fees incurred when when transferring bitcoins for deposit. Funds are available once [[confirmation|confirmed]] (4 confirms), a process that can take roughly forty minutes.

===EUR===
The exchange accepts SEPA bank transfers for deposit. A 5 PLN fee is taken by the bank. No additional fees is taken.

===PLN===
The exchange accepts polish bank transfers for deposit. There are no fees.

===USD===
The exchange accepts [[Dwolla]] transfers (no fee), bank wire transfers and ACH. There are no fees.

===GBP===
The exchange accepts standard UK GBP bank transfers.

==Withdrawing Funds==

===BTC===
Bitcoins may be withdrawn at no charge.

===EUR===
Withdrawals as SEPA transfers. A fee of 5 PLN is taken by the bank. No additional fee is charged.

===PLN===
Withdrawals as standard polish PLN bank transfers.

===USD===
Withdrawals are through [[Dwolla]]. There is no fee incurred from the exchange for withdrawing funds.

===GBP===
Withdrawals as standard UK GBP bank transfers.

==API==

See the [https://intersango.com/api.php API page] for more info.

<source lang="python">
import httplib
import urllib
import json

class Intersango:
ORDER_QUEUED = 'queued'
ORDER_OPEN = 'open'
ORDER_EXPIRED = 'expired'
ORDER_CANCELLED = 'cancelled'
ORDER_FULFILLED = 'fulfilled'

BUY = 'false'
SELL = 'true'

def __init__(self, api_key):
self.connection = httplib.HTTPSConnection('intersango.com')
self.api_key = api_key

def make_request(self, page, params={}):
headers = {"Content-type": "application/x-www-form-urlencoded",
"Connection": "Keep-Alive", "Keep-Alive": 30,
"Accept": "text/plain"}
if type(params) == dict:
params['api_key'] = self.api_key
elif type(params) == list:
params.append(('api_key', self.api_key))
else:
raise TypeError('Unknown parameter list type')
params = urllib.urlencode(params)
base_url = '/api/authenticated/v0.1/%s.php'%page
self.connection.request('POST', base_url, params, headers)
response = self.connection.getresponse()
if response.status == 404:
return None
return json.loads(response.read())

def accounts(self):
return self.make_request('listAccounts')

def orders(self, account_id, states=[], last_order_id=None):
params = [('account_id', account_id)]
for state in states:
params.append(('states[]', state))
if last_order_id is not None:
params.append(('last_order_id', last_order_id))
return self.make_request('listOrders', params)

def deposits(self, account_id):
return self.make_request('listDeposits', {'account_id': account_id})

def withdrawals(self, account_id):
return self.make_request('listWithdrawalRequests',
{'account_id': account_id})

def place_limit_order(self, quantity, rate, is_selling, base_id, quote_id):
params = {'quantity': quantity, 'rate': rate, 'selling': is_selling,
'base_account_id': base_id, 'quote_account_id': quote_id}
return self.make_request('placeLimitOrder', params)

def cancel_order(self, account_id, order_id):
params = {'account_id': account_id, 'order_id': order_id}
return self.make_request('requestCancelOrder', params)

def cancel_withdrawal(self, account_id, withdrawal_request_id):
params = {'account_id': account_id,
'withdrawal_request_id': withdrawal_request_id}
return self.make_request('cancelWithdrawalRequest', params)
</source>

Example usage:

<source lang="python">
intersango = Intersango('3223kdkk323h32kj3hkj23233j')
print 'Accounts: ', intersango.accounts()
print 'Orders: ', \
intersango.orders(411289412410,
[Intersango.ORDER_CANCELLED, Intersango.ORDER_FULFILLED])
print 'Deposits: ', intersango.deposits(861502532543)
print 'Withdrawals: ', intersango.withdrawals(702703681384)
intersango.place_limit_order('1', '2.0', Intersango.BUY,
861502521543, 411982412410)
intersango.cancel_order(412989412410, 21724)
</source>

==History==

The service was launched on July 6, 2011<ref>[http://forum.bitcoin.org/index.php?topic=26543.0 Intersango.com EUR exchange is now live]</ref>. The Intersango [[:Category:Open Source|open source]] software that the exchange runs on was announced on March 17, 2011<ref>[https://bitcointalk.org/index.php?topic=4579.0 Free Bitcoin exchange software- Intersango]</ref>. In September, 2011 the exchange began using a new version of the Intersango open source exchange project with two currency markets (BTC/EUR, BTC/USD) live under the Intersango brand and plans made for the third (BTC/GBP) when [[Britcoin]] accounts are migrated at a future date.

==See Also==

* [[Buying bitcoins]]
* [[Selling bitcoins]]

==External Links==

* [https://intersango.com Intersango] EUR exchange website
* [http://gitorious.org/intersango Intersango] exchange project on Gitorious

==References==
<references/>

[[Category:Exchanges]]
[[Category:eWallets]]

BIP 0015

2012-06-01T14:03:31Z

Genjix: /* Namecoin ID */

{{bip}}

<pre>
BIP: 15
Title: BIP Aliases
Author: Amir Taaki <genjix@riseup.net>
Status: Deferred
Type: Standards Track
Created: 10-12-2011
</pre>

Using vanilla bitcoin, to send funds to a destination, an address in the form 1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ is needed. The problem with using addresses is they are not easy to remember. An analogy can be thought if one were required to enter the IP address of their favourite websites if domain names did not exist.

This document aims to layout through careful argument, a bitcoin alias system. This is a big modification to the protocol that is not easily changed in the future and has big ramifications. There is impetus in getting it correct the first time. Aliases have to be robust and secure.

== Schemes ==

Here are a few different proposals and the properties of each system.

=== FirstBits ===

FirstBits is a proposal for using the blockchain as an address book.

When bitcoins are sent to an address, that address becomes recorded in the blockchain. It is therefore known that this address exists or did exist by simply seeing that there was a payment to that address. FirstBits is a method to have a memorable alias. One first converts the address to lower-case, then takes the first few unique characters. This is your FirstBits alias.

As an example, brmlab hackerspace in Prague has an address for purchasing food or drink, or making donations:

1BRMLAB7nryYgFGrG8x9SYaokb8r2ZwAsX

Their FirstBits alias becomes:

1brmlab

It is enough information to be given the FirstBits alias ''1brmlab''. When someone wishes to make a purchase, without FirstBits, they either have to type out their address laboriously by hand, scan their QR code (which requires a mobile handset that this author does not own) or find their address on the internet to copy and paste into the client to send bitcoins. FirstBits alleviates this impracticality by providing an easy method to make payments.

Together with Vanitygen (vanity generator), it becomes possible to create memorable unique named addresses. Addresses that are meaningful, rather than an odd assemblage of letters and numbers but add context to the destination.

However FirstBits has its own problems. One is that the possible aliases one is able to generate is limited by the available computing power available. It may not be feasible to generate a complete or precise alias that is wanted- only approximates may be possible. It is also computationally resource intensive which means a large expenditure of power for generating unique aliases in the future, and may not scale up to the level of individuals at home or participants with hand-held devices in an environment of ubiquitous computing.

FirstBits scales extremely poorly as the network grows. Each indexer or lookup node needs to keep track of every bitcoin address ever in existence and provide a fast lookup from the aliases to those addresses. As the network grows linearly, the number of addresses should grow exponentially (assuming a networked effect of (n-1)*(n-2)/2) rapidly making this scheme unfeasible.

Light clients of the partial merkle root types become dependent on a trusted third party for their alias lookups. The cost of storing every bitcoin address is too high considering their typical use-case on low-resource devices. This factor more than the others, means this scheme is sub-optimal and must be rejected.

=== DNS TXT Records ===

DNS allows TXT records to be created containing arbitrary data. In a bitcoin alias system, a custom format mutually agreed upon by a BIP standard would be used to store mappings to bitcoin addresses from domain names. How such a format would look is out of the scope of this document.

An issue is that it requires people who wish to create such mappings to be familiar with configuring DNS records, and be able to run the necessary toolsets to insert the correct data. Although not a huge concern, it is a usability issue.

Security wise, DNS is unsafe and insecure by design. It is possible to spoof records by being on the same network as another host. A number of revisions to mitigate the issue under the guise of DNSSEC have been in the works since the 1990s and are still being rolled out.

As of Dec 2011, DNSSEC is still not yet a defacto standard on the internet. Should a participant in the bitcoin network wish to use DNS TXT records, they would in addition to having to configure DNS, be able to setup DNSSEC. This may not be feasible, especially where some registrars provide access to DNS through a web interface only.

The disadvantage of DNS TXT records is that updating a record takes time. This encourages people to not use new addresses per transaction which has certain security issues.

=== Server Service ===

Aside from using DNS TXT records, another possibility is using the domain name system to lookup hosts and then contact a service running on a predefined port to get the bitcoin address.

# User wishes to send to foo@bar.net
# Client uses DNS to find the IP address of bar.net: 123.123.123.123
# Client connects to port 123.123.123.123:4567 and requests the bitcoin address for the user ''foo''
# Server responds with the address or error code and terminates the connection.
# Client sends the funds to the address

The service would be responsible for providing the mechanisms for changing and storing the mappings on their service. A front-end web interface could be provided to users wishing to use the service and customise their accounts on the server.

This approach has the positive aspect of providing the best flexibility for the implementer to store the records however they wish in a database or plaintext file, and then serve them up quickly using a small server side daemon typically written in C. This approach is highly scalable.

However this approach also suffers the problem of being reliant on DNS and hence also being vulnerable to spoofing. Hence DNSSEC is also required. This approach is slightly better than the DNS TXT records though since it makes inserting new users and modifying aliases very easy which allows people to run these server services more cheaply.

=== HTTPS Web Service ===

HTTPS provides an additional layer of security by encrypting the connection, providing much needed privacy for users. Together with using Certificate Authorities, it fixes the issue with using DNSSEC since an error would be thrown up were someone to try to spoof a domain name on the local network.

When trying to send to:

genjix@foo.org

The request is broken into the handle (genjix) and domain (foo.org) at the last occurrence of the @. The client then constructs a request that will query for the address.

https://foo.org/bitcoin-alias/?handle=genjix

bitcoin-alias has been chosen as the query suffix because it allows this system to co-exist easily within another web root without the fear of name clashes.

The query will then return an address which is used to make the payment.

1Hd44nkJfNAcPJeZyrGC5sKJS1TzgmCTjjZ

The details of whether a unique address is returned per query, whether an address is fetched from a pre-existing pool of addresses, and so on is an implementation detail unique to every server. How alias to address mappings are setup is dependent on the site which could have a web-interface and be providing a free service to users or be a private customised service serving pre-existing addresses. This is left up to sysop policy, and deliberately not defined here.

A web service is trivial to setup and the cost is low. There are many free out of the box providers on the net that allows anyone with the most basic knowledge of web technologies to create their own website. By providing users with a package, anybody can quickly set themselves up with a bitcoin alias. It could be something as simple as a PHP script that the user edits with their custom settings and uploads themselves to their website.

It also scales reasonably- anybody wishing to run a naming service can attach a backend with a variety of database technologies then provide a web frontend for users to customise and create their own aliases.

A naive implementation is provided below as an example.

<source lang="cpp">
// resolv.h
#ifndef NOMRESOLV_H__
#define NOMRESOLV_H__

#include <string>
#include "curl/curl.h"

using std::string;

/*

This class resolves against a server to lookup addresses.
To not conflict with the bitcoin addresses, we refer here to people's handles.
A handle is of the form:

genjix@foo.org

Most characters are valid for the username + password (and handled accordingly), but the domain follows usual web standards. It is possible to affix a path if needed,

genjix@bar.com/path/to/

*/

class NameResolutionService
{
public:
NameResolutionService();
~NameResolutionService();

// Three main methods map to RPC actions.
string FetchAddress(const string& strHandle, string& strAddy);

private:
// A POST block
class PostVariables
{
public:
PostVariables();
~PostVariables();
// Add a new key, value pair
bool Add(const string& strKey, const string& strVal);
curl_httppost* operator()() const;
private:
// CURL stores POST blocks as linked lists.
curl_httppost *pBegin, *pEnd;
};

// Explodes user@domain => user, domain
static void ExplodeHandle(const string& strHandle, string& strNickname, string& strDomain);
// Perform the HTTP request. Returns true on success.
bool Perform();

// CURL error message
char pErrorBuffer[CURL_ERROR_SIZE];
// CURL response
string strBuffer;
// CURL handle
CURL *curl;
};

#endif
</source>

<source lang="cpp">
// resolv.cpp
#include "resolv.h"

#include <boost/lexical_cast.hpp>

#include "access.h"

// callback used to write response from the server
static int writer(char *pData, size_t nSize, size_t nNmemb, std::string *pBuffer)
{
int nResult = 0;
if (pBuffer != NULL)
{
pBuffer->append(pData, nSize * nNmemb);
// How much did we write?
nResult = nSize * nNmemb;
}
return nResult;
}

NameResolutionService::NameResolutionService()
{
// Initialise CURL with our various options.
curl = curl_easy_init();
// This goes first in case of any problems below. We get an error message.
curl_easy_setopt(curl, CURLOPT_ERRORBUFFER, pErrorBuffer);
// fail when server sends >= 404
curl_easy_setopt(curl, CURLOPT_FAILONERROR, 1);
curl_easy_setopt(curl, CURLOPT_HEADER, 0);
curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1);
curl_easy_setopt(curl, CURLOPT_POSTREDIR, CURL_REDIR_POST_302);
curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, writer);
curl_easy_setopt(curl, CURLOPT_USE_SSL, CURLUSESSL_TRY);
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 1);
// server response goes in strBuffer
curl_easy_setopt(curl, CURLOPT_WRITEDATA, &strBuffer);
pErrorBuffer[0] = '\0';
}
NameResolutionService::~NameResolutionService()
{
curl_easy_cleanup(curl);
}

void NameResolutionService::ExplodeHandle(const string& strHandle, string& strNickname, string& strDomain)
{
// split address at @ furthrest to the right
size_t nPosAtsym = strHandle.rfind('@');
strNickname = strHandle.substr(0, nPosAtsym);
strDomain = strHandle.substr(nPosAtsym + 1, strHandle.size());
}
bool NameResolutionService::Perform()
{
// Called after everything has been setup. This actually does the request.
CURLcode result = curl_easy_perform(curl);
return (result == CURLE_OK);
}

string NameResolutionService::FetchAddress(const string& strHandle, string& strAddy)
{
// GET is defined for 'getting' data, so we use GET for the low risk fetching of people's addresses
if (!curl)
// For some reason CURL didn't start...
return pErrorBuffer;
// Expand the handle
string strNickname, strDomain;
ExplodeHandle(strHandle, strNickname, strDomain);
// url encode the nickname for get request
const char* pszEncodedNick = curl_easy_escape(curl, strNickname.c_str(), strNickname.size());
if (!pszEncodedNick)
return "Unable to encode nickname.";
// construct url for GET request
string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" + pszEncodedNick;
// Pass URL to CURL
curl_easy_setopt(curl, CURLOPT_URL, strRequestUrl.c_str());
if (!Perform())
return pErrorBuffer;
// Server should respond with a JSON that has the address in.
strAddy = strBuffer;
return ""; // no error
}

NameResolutionService::PostVariables::PostVariables()
{
// pBegin/pEnd *must* be null before calling curl_formadd
pBegin = NULL;
pEnd = NULL;
}
NameResolutionService::PostVariables::~PostVariables()
{
curl_formfree(pBegin);
}
bool NameResolutionService::PostVariables::Add(const string& strKey, const string& strVal)
{
// Copy strings to this block. Return true on success.
return curl_formadd(&pBegin, &pEnd, CURLFORM_COPYNAME, strKey.c_str(), CURLFORM_COPYCONTENTS, strVal.c_str(), CURLFORM_END) == CURL_FORMADD_OK;
}

curl_httppost* NameResolutionService::PostVariables::operator()() const
{
return pBegin;
}
</source>

<source lang="cpp">
// rpc.cpp
...

const Object CheckMaybeThrow(const string& strJsonIn)
{
// Parse input JSON
Value valRequest;
if (!read_string(strJsonIn, valRequest) || valRequest.type() != obj_type)
throw JSONRPCError(-32700, "Parse error");
const Object& request = valRequest.get_obj();
// Now check for a key called "error"
const Value& error = find_value(request, "error");
// It's an error JSON! so propagate the error.
if (error.type() != null_type)
throw JSONRPCError(-4, error.get_str());
// Return JSON object
return request;
}

const string CollectAddress(const string& strIn)
{
// If the handle does not have an @ in it, then it's a normal base58 bitcoin address
if (strIn.find('@') == (size_t)-1)
return strIn;

// Open the lookup service
NameResolutionService ns;
// We established that the input string is not a BTC address, so we use it as a handle now.
string strHandle = strIn, strAddy;
string strError = ns.FetchAddress(strHandle, strAddy);
if (!strError.empty())
throw JSONRPCError(-4, strError);

const Object& request(CheckMaybeThrow(strAddy));
// Get the BTC address from the JSON
const Value& address = find_value(request, "address");
if (address.type() != str_type)
throw JSONRPCError(-32600, "Server responded with malformed reply.");
return address.get_str();
}

// Named this way to prevent possible conflicts.
Value rpc_send(const Array& params, bool fHelp)
{
if (fHelp || params.size() != 2)
throw runtime_error(
"send <name@domain or address> <amount>\n"
"<amount> is a real and is rounded to the nearest 0.01");

// Intelligent function which looks up address given handle, or returns address
string strAddy = CollectAddress(params[0].get_str());
int64 nAmount = AmountFromValue(params[1]);
// Do the send
CWalletTx wtx;
string strError = SendMoneyToBitcoinAddress(strAddy, nAmount, wtx);
if (!strError.empty())
throw JSONRPCError(-4, strError);
return wtx.GetHash().GetHex();
}

...
</source>

=== IP Transactions ===

An IP transaction is an old transaction format in bitcoin that is disabled and possibly could be deprecated. It involves being given an IP address to make payment to. Upon connecting to the node and requesting their public key using "checkorder", they will respond with a script in the form:

<public key> OP_CHECKSIG

Similar to coinbase output transactions. IP transactions have the advantage of being able to contain additional metadata which can be useful in many transactions. Currently no authentication is done making the scheme insecure against man in the middle (MITM) attacks.

This proposal seeks to enable DNS lookups for IP transactions.

The "checkorder" message would contain a destination account, which could map to different isolated sets of keypairs/wallets running under the same host. The exact mapping from the checkorder reference info to the local system is implementation defined.

By using DNS lookups, the MITM problem with IP transactions could be mitigated by storing a public key in a DNS TXT record. This public key would be used for all future "reply" messages originating from that host. First time use would require a confirmation for acceptance of that public key; like with SSH. Should the "reply" message not match the accepted public key, then the host will be given an error.

[[Category:BIP|E]]

=== Namecoin ID ===

This proposal uses the Namecoin blockchain to associate an alias with a bitcoin address. Bitcoin queries a namecoin node. This retreives the structured data containing the bitcoin address(es) associated with this alias.

Using a decentralised domainname system like Namecoin, means no external server or entity needs to be trusted unlike the other proposals listed here. This indicates a system with the advantage of having a high availability and ease of entry (no restrictions for users to create aliases).

Two examples are presented below. The first shows a simpler format, while the second shows several Bitcoin addresses in a structured format.

$ namecoind name_show id/khal
{
"bitcoin" : "N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq"
}

$ namecoind name_show id/khal
{
"bitcoin" :
{
"default" : "N15mJsVMHNtVDedDnD8vu82M5hCfn3nJWq",
"donation": "N2pGWAh65TWpWmEFrFssRQkQubbczJSKi9"
}
}

'''More possibilities :'''

* Allow to securely use '''unsecured channels''' by getting signed data/keys
* Allow to get a different address each time, or per user, per order, etc
* Specification is extensible
$ namecoind name_show id/khal
{
"bitcoin" :
{
"url" : "http://merchant.com/bitcoin/getnewaddres/{Your customer id}",
"signedWith" : "1J3EKMfboca3SESWGrQKESsG1MA9yK6vN4",
"useOnce": true
}
}

See the specification of [http://dot-bit.org/Namespace:Identity Namecoin ID] for more informations.

2012-05-30T16:44:40Z

Genjix: Removed protection from "BIP 0015"

Bitcoin Improvement Proposals

2012-05-15T22:10:41Z

Genjix:

People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Amir Taaki <genjix@riseup.net>. After copy-editing and acceptance, it will be published here.

We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.

Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community.

{| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
!Number
!Title
!Owner
!Status
|- style="background-color: #cfffcf"
| [[BIP 0001|1]]
| BIP Purpose and Guidelines
| Amir Taaki
| Active
|-
| [[BIP 0010|10]]
| Multi-Sig Transaction Distribution
| Alan Reiner
| Draft
|- style="background-color: #cfffcf"
| [[BIP 0011|11]]
| M-of-N Standard Transactions
| Gavin Andresen
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0012|12]]
| OP_EVAL
| Gavin Andresen
| Withdrawn
|- style="background-color: #cfffcf"
| [[BIP 0013|13]]
| Address Format for pay-to-script-hash
| Gavin Andresen
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0014|14]]
| Protocol Version and User Agent
| Amir Taaki, Patrick Strateman
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0015|15]]
| Aliases
| Amir Taaki
| Withdrawn
|- style="background-color: #cfffcf"
| [[BIP 0016|16]]
| Pay To Script Hash
| Gavin Andresen
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0017|17]]
| OP_CHECKHASHVERIFY (CHV)
| Luke Dashjr
| Withdrawn
|-
| [[BIP 0019|19]]
| M-of-N Standard Transactions (Low SigOp)
| Luke Dashjr
| Draft
|- style="background-color: #ffcfcf"
| [[BIP 0020|20]]
| URI Scheme
| Luke Dashjr
| Replaced
|- style="background-color: #cfffcf"
| [[BIP 0021|21]]
| URI Scheme
| Nils Schneider, Matt Corallo
| Accepted
|-
| [[BIP 0022|22]]
| getmemorypool
| Luke Dashjr
| Draft
|- style="background-color: #cfffcf"
| [[BIP 0030|30]]
| Duplicate transactions
| Pieter Wuille
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0031|31]]
| Pong message
| Mike Hearn
| Accepted
|-
| [[BIP 0032|32]]
| Hierarchical Deterministic Wallets
| Pieter Wuille
| Draft
|-
| [[BIP 0033|33]]
| Stratized Nodes
| Amir Taaki
| Draft
|}

[[Hardfork Wishlist]]

[[Category:BIP|Z]]

BIP 0033

2012-05-15T22:02:01Z

2012-04-21T02:49:27Z

Genjix:

People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Amir Taaki <genjix@riseup.net>. After copy-editing and acceptance, it will be published here.

We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.

Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community.

{| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
!Number
!Title
!Owner
!Status
|- style="background-color: #cfffcf"
| [[BIP 0001|1]]
| BIP Purpose and Guidelines
| Amir Taaki
| Active
|-
| [[BIP 0010|10]]
| Multi-Sig Transaction Distribution
| Alan Reiner
| Draft
|- style="background-color: #cfffcf"
| [[BIP 0011|11]]
| M-of-N Standard Transactions
| Gavin Andresen
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0012|12]]
| OP_EVAL
| Gavin Andresen
| Withdrawn
|- style="background-color: #cfffcf"
| [[BIP 0013|13]]
| Address Format for pay-to-script-hash
| Gavin Andresen
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0014|14]]
| Protocol Version and User Agent
| Amir Taaki, Patrick Strateman
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0015|15]]
| Aliases
| Amir Taaki
| Withdrawn
|- style="background-color: #cfffcf"
| [[BIP 0016|16]]
| Pay To Script Hash
| Gavin Andresen
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0017|17]]
| OP_CHECKHASHVERIFY (CHV)
| Luke Dashjr
| Withdrawn
|-
| [[BIP 0019|19]]
| M-of-N Standard Transactions (Low SigOp)
| Luke Dashjr
| Draft
|- style="background-color: #ffcfcf"
| [[BIP 0020|20]]
| URI Scheme
| Luke Dashjr
| Rejected
|- style="background-color: #cfffcf"
| [[BIP 0021|21]]
| URI Scheme
| Nils Schneider, Matt Corallo
| Accepted
|-
| [[BIP 0022|22]]
| getmemorypool
| Luke Dashjr
| Draft
|- style="background-color: #cfffcf"
| [[BIP 0030|30]]
| Duplicate transactions
| Pieter Wuille
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0031|31]]
| Pong message
| Mike Hearn
| Accepted
|-
| 32
| N/A
| Pieter Wuille
|
|}

[[Hardfork Wishlist]]

[[Category:BIP|Z]]

Bitcoin Improvement Proposals

2012-04-21T02:49:06Z

Genjix: Undo revision 25543 by Genjix (talk)

People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Amir Taaki <genjix@riseup.net>. After copy-editing and acceptance, it will be published here.

We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.

Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community.

{| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
!Number
!Title
!Owner
!Status
|- style="background-color: #cfffcf"
| [[BIP 0001|1]]
| BIP Purpose and Guidelines
| Amir Taaki
| Active
|-
| [[BIP 0010|10]]
| Multi-Sig Transaction Distribution
| Alan Reiner
| Draft
|- style="background-color: #cfffcf"
| [[BIP 0011|11]]
| M-of-N Standard Transactions
| Gavin Andresen
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0012|12]]
| OP_EVAL
| Gavin Andresen
| Withdrawn
|- style="background-color: #cfffcf"
| [[BIP 0013|13]]
| Address Format for pay-to-script-hash
| Gavin Andresen
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0014|14]]
| Protocol Version and User Agent
| Amir Taaki, Patrick Strateman
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0015|15]]
| Aliases
| Amir Taaki
| Withdrawn
|- style="background-color: #cfffcf"
| [[BIP 0016|16]]
| Pay To Script Hash
| Gavin Andresen
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0017|17]]
| OP_CHECKHASHVERIFY (CHV)
| Luke Dashjr
| Withdrawn
|-
| [[BIP 0019|19]]
| M-of-N Standard Transactions (Low SigOp)
| Luke Dashjr
| Draft
|- style="background-color: #ffcfcf"
| [[BIP 0020|20]]
| URI Scheme
| Luke Dashjr
| Rejected
|- style="background-color: #cfffcf"
| [[BIP 0021|21]]
| URI Scheme
| Nils Schneider, Matt Corallo
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0022|22]]
| getmemorypool
| Luke Dashjr
| Draft
|- style="background-color: #cfffcf"
| [[BIP 0030|30]]
| Duplicate transactions
| Pieter Wuille
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0031|31]]
| Pong message
| Mike Hearn
| Accepted
|-
| 32
| N/A
| Pieter Wuille
|
|}

[[Hardfork Wishlist]]

[[Category:BIP|Z]]

Bitcoin Improvement Proposals

2012-04-20T00:19:29Z

Genjix: Undo revision 25541 by Genjix (talk)

People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Amir Taaki <genjix@riseup.net>. After copy-editing and acceptance, it will be published here.

We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.

Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community.

{| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
!Number
!Title
!Owner
!Status
|- style="background-color: #cfffcf"
| [[BIP 0001|1]]
| BIP Purpose and Guidelines
| Amir Taaki
| Active
|-
| [[BIP 0010|10]]
| Multi-Sig Transaction Distribution
| Alan Reiner
| Draft
|- style="background-color: #cfffcf"
| [[BIP 0011|11]]
| M-of-N Standard Transactions
| Gavin Andresen
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0012|12]]
| OP_EVAL
| Gavin Andresen
| Withdrawn
|- style="background-color: #cfffcf"
| [[BIP 0013|13]]
| Address Format for pay-to-script-hash
| Gavin Andresen
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0014|14]]
| Protocol Version and User Agent
| Amir Taaki, Patrick Strateman
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0015|15]]
| Aliases
| Amir Taaki
| Withdrawn
|- style="background-color: #cfffcf"
| [[BIP 0016|16]]
| Pay To Script Hash
| Gavin Andresen
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0017|17]]
| OP_CHECKHASHVERIFY (CHV)
| Luke Dashjr
| Withdrawn
|-
| [[BIP 0019|19]]
| M-of-N Standard Transactions (Low SigOp)
| Luke Dashjr
| Draft
|- style="background-color: #ffcfcf"
| [[BIP 0020|20]]
| URI Scheme
| Luke Dashjr
| Rejected
|- style="background-color: #cfffcf"
| [[BIP 0021|21]]
| URI Scheme
| Nils Schneider, Matt Corallo
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0030|30]]
| Duplicate transactions
| Pieter Wuille
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0031|31]]
| Pong message
| Mike Hearn
| Accepted
|-
| 32
| N/A
| Pieter Wuille
|
|}

[[Hardfork Wishlist]]

[[Category:BIP|Z]]

BIP 0022

2012-04-20T00:19:14Z

Genjix: Removed protection from "BIP 0022"

{{bip}}

<pre>
BIP: 22
Title: getmemorypool
Author: Luke Dashjr <luke+bip22@dashjr.org>
Status: Accepted
Type: Standards Track
Created: 28-02-2012
</pre>

==Abstract==

This BIP describes a new JSON-RPC method for "smart" Bitcoin miners and proxies.
Instead of sending a simple block header for hashing, the entire block structure is sent, and left to the miner to (optionally) customize and assemble.

==Specification==

===JSON-RPC Method: getmemorypool===

A new JSON-RPC method is defined, called "getmemorypool".
It takes no arguments.
If arguments are provided, it may wrap the "submitblock" JSON-RPC method (described later), cast to a Boolean return value (true = share accepted).

getmemorypool MUST return a JSON Object containing at least the following keys, all of which relate to the block header:
{| class="wikitable"
! Key !! Required !! Type !! Description
|-
| bits || {{Yes}} || String || the compressed difficulty in hexadecimal
|-
| curtime || {{Yes}} || Number || the current time as seen by the server (recommended for block time)
|-
| height || {{Yes|Should}} || Number || the height of the block we are looking for
|-
| previousblockhash || {{Yes}} || String || the hash of the previous block, in big-endian converted to hexadecimal
|-
| transactions || {{Yes|Should}} || Array of Strings || Bitcoin transactions encoded in hexadecimal (byte-for-byte), not including coinbase
|-
| version || {{Yes}} || Number || always 1 (at least for bitcoin)
|-
| coinbasetxn || {{Patch|or ↓}} || String || hexadecimal byte-for-byte coinbase transaction
|-
| coinbasevalue || {{Patch|or ↑}} || Number || total funds available for the coinbase
|-
| coinbaseaux || {{No}} || Object || data that SHOULD or MUST (depending on mutable flags) be included in the coinbase's scriptSig content. Only the values (hexadecimal byte-for-byte) in this Object should be included, not the keys.
|-
| expires || {{No}} || Number || how many seconds (beginning from when the server sent the response) this work is valid for, at most
|-
| fulltarget || {{No}} || String || the number which full results should be less than, in big-endian hexadecimal (see [[#Mutations|"share/*" mutations]])
|-
| longpoll || {{No}} || String || URI for [[#Long Polling|long polling]]
|-
| maxtime || {{No}} || Number || the maximum time allowed
|-
| maxtimeoff || {{No}} || Number || the maximum time allowed (as a moving offset from "curtime" - every second, the actual maxtime is incremented by 1; for example, "maxtimeoff":0 means "time" may be incremented by 1 every second)
|-
| mintime || {{No}} || Number || the minimum time allowed
|-
| mintimeoff || {{No}} || Number || the minimum time allowed (as a moving offset from "curtime")
|-
| mutable || {{No}} || Array of Strings || different manipulations that the server explicitly allows to be made (see [[#Mutations|Mutations]])
|-
| noncerange || {{No}} || String || two 32-bit integers, concatenated in big-endian hexadecimal, which represent the valid ranges of nonces the miner may scan
|-
| submitold || {{No}} || Boolean || only relevant for [[#Long Polling|long poll]] responses; indicates if work received prior to this response remains potentially valid (default) and should have its shares submitted; if false, the miner may wish to discard its share queue
|-
| target || {{No}} || String || the number which valid results must be less than, in big-endian hexadecimal
|-
| txrequired || {{No}} || Number || this many of the first transactions provided must be present in the final block, even if the "transactions/remove" mutation is allowed
|-
| workid || {{No}} || String or Number || if provided, this value must be returned with results (see [[#JSON-RPC Method: submitblock|"submitblock"]])
|}

====Mutations====

Any of these may be listed in the "mutable" key to signify modifications the miner is allowed to make:

{| class="wikitable"
! Value !! Significance
|-
| coinbase/append
| append the provided coinbase scriptSig
|-
| coinbase
| provide their own coinbase; if one is provided, it may be replaced or modified (implied if "coinbasetxn" omitted)
|-
| generation
| add or remove outputs from the coinbase/generation transaction (implied if "coinbasetxn" omitted)
|-
| share/coinbase
| if the block hash is less than "target", but not less than "fulltarget", only return the block header and coinbase transaction, but only if the other transactions are unmodified from those proposed in the getmemorypool job
|-
| share/merkle
| if the block hash is less than "target", but not less than "fulltarget", only return the block header, coinbase transaction, and merkle tree connecting that transaction to the root (in the form of repeated right-side SHA256 hashes) in "submitblock"
|-
| share/truncate
| if the block hash is less than "target", but not less than "fulltarget", only return the block header in "submitblock"
|-
| time/increment
| change the time header to a value after "time" (implied if "maxtime" or "maxtimeoff" are provided)
|-
| time/decrement
| change the time header to a value before "time" (implied if "mintime" is provided)
|-
| time
| modify the time header of the block
|-
| transactions/add
| add other valid transactions to the block
|-
| transactions/remove
| remove transactions provided by the server
|-
| transactions
| add or remove transactions (both of the above; implied if "transactions" omitted from result)
|-
| prevblock
| use the work with other previous-blocks; this implicitly allows removing transactions that are no longer valid, unless they are part of the "txrequired" count; it also implies adjusting "height" as necessary
|}

Note that miners are NOT required to implement any of these mutations.

==== Long Polling ====
If the server supports long polling, it SHOULD include the "longpoll" key with a relative or absolute URI.
The absolute URI MAY specify a different port than the original connection.
Miners MAY start a request to this long polling URI with a standard JSON-RPC request (POST with data) and same basic authorization.
This request SHOULD NOT be processed nor answered by the server until it wishes to replace the current block data.
Clients SHOULD make this request with a very long request timeout and MUST accept the server sending response headers with "chunked" Transfer-Encoding delaying the completion of the final JSON response.

Upon receiving a completed response:
* Only if "submitold" is provided and false, the client MAY discard the results of past operations and MUST begin working on the new work immediately.
* The client SHOULD begin working on the new work received as soon as possible, if not immediately.
* The client SHOULD make a new request to the same long polling URI.

If a client receives an incomplete or invalid response, it SHOULD retry the request with an exponential backoff.
Clients MAY implement this backoff with limitations (such as maximum backoff time) or any algorithm as deemed suitable.
It is however forbidden to simply retry immediately with no delay after more than one failure.
In the case of a "Forbidden" response (for example, HTTP 403), a client SHOULD NOT attempt to retry without user intervention.

===JSON-RPC Method: submitblock===
A new JSON-RPC method is defined, called "submitblock".
It takes one to two arguments.
The first argument is the block data; this may be truncated or merkle-ified depending on the "share/truncate" or "share/merkle" mutations, respectively.
The second argument, if provided, is an Object.
The only defined key of this Object is the "workid" provided by the server:
if a "workid" was specified, it must be submitted with the share/block.

This method MUST return either null (when a share is accepted), a String describing briefly the reason the share was rejected, or an Object of these with a key for each merged-mining chain the share was submitted to.

Possible reasons a share may be rejected include, but are not limited to:
{| class="wikitable"
! Reason !! Description
|-
| bad-cb-flag || the server detected a feature-signifying flag that it does not allow
|-
| bad-cb-length || the coinbase was too long (bitcoin limit is 100 bytes)
|-
| bad-cb-prefix || the server only allows appending to the coinbase, but it was modified beyond that
|-
| bad-diffbits || "bits" were changed
|-
| bad-prevblk || the previous-block is not the one the server intends to build on
|-
| bad-txnmrklroot || the block header's merkle root did not match the transaction merkle tree
|-
| bad-txns || the server didn't like something about the transactions in the block
|-
| bad-version || the version was wrong
|-
| duplicate || the server already processed this block data
|-
| high-hash || the block header did not hash to a value lower than the specified target
|-
| rejected || a generic rejection without details
|-
| stale-prevblk || the previous-block is no longer the one the server intends to build on
|-
| stale-work || the work this block was based on is no longer accepted
|-
| time-invalid || the time was not acceptable
|-
| time-too-new || the time was too far in the future
|-
| time-too-old || the time was too far in the past
|-
| unknown-user || the user submitting the block was not recognized
|-
| unknown-work || the template or workid could not be identified
|}

=== Known Bugs ===
This BIP should not be promoted from Draft status until these are addressed:
* Noncerange might not be possible to support for all workers, so a way to signal support is needed
* Longpolling currently assumes URI-based requests, which is not implied by JSON-RPC.
* ''(feel free to add issues here)''

==Motivation==

There is reasonable concerns about mining currently being too centralized on pools, and the amount of control these pools hold.
By exposing the details of the block proposals to the miners, they are enabled to audit and possibly modify the block before hashing it.

There is also a very minor load reduction on the pool server, since it does not need to calculate SHA256 for the block's merkle tree.

==Reference Implementation==

* [https://gitorious.org/bitcoin/eloipool Eloipool]
* [http://luke.dashjr.org/programs/bitcoin/w/bitcoind/luke-jr.git/blobdiff/722d9387be4b267b689d7b7d78daeb7157bd12d8..gmp_bip:/src/bitcoinrpc.cpp bitcoind]

[[Category:BIP|D]]

Bitcoin Improvement Proposals

2012-04-20T00:17:02Z

Genjix:

People wishing to submit BIPs, first should propose their idea or document to the mailing list. After discussion they should email Amir Taaki <genjix@riseup.net>. After copy-editing and acceptance, it will be published here.

We are fairly liberal with approving BIPs, and try not to be too involved in decision making on behalf of the community. The exception is in very rare cases of dispute resolution when a decision is contentious and cannot be agreed upon. In those cases, the conservative option will always be preferred.

Having a BIP here does not make it a formally accepted standard until its status becomes Active. For a BIP to become Active requires the mutual consent of the community.

{| class="wikitable sortable" style="width: auto; text-align: center; font-size: smaller; table-layout: fixed;"
!Number
!Title
!Owner
!Status
|- style="background-color: #cfffcf"
| [[BIP 0001|1]]
| BIP Purpose and Guidelines
| Amir Taaki
| Active
|-
| [[BIP 0010|10]]
| Multi-Sig Transaction Distribution
| Alan Reiner
| Draft
|- style="background-color: #cfffcf"
| [[BIP 0011|11]]
| M-of-N Standard Transactions
| Gavin Andresen
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0012|12]]
| OP_EVAL
| Gavin Andresen
| Withdrawn
|- style="background-color: #cfffcf"
| [[BIP 0013|13]]
| Address Format for pay-to-script-hash
| Gavin Andresen
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0014|14]]
| Protocol Version and User Agent
| Amir Taaki, Patrick Strateman
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0015|15]]
| Aliases
| Amir Taaki
| Withdrawn
|- style="background-color: #cfffcf"
| [[BIP 0016|16]]
| Pay To Script Hash
| Gavin Andresen
| Accepted
|- style="background-color: #ffcfcf"
| [[BIP 0017|17]]
| OP_CHECKHASHVERIFY (CHV)
| Luke Dashjr
| Withdrawn
|-
| [[BIP 0019|19]]
| M-of-N Standard Transactions (Low SigOp)
| Luke Dashjr
| Draft
|- style="background-color: #ffcfcf"
| [[BIP 0020|20]]
| URI Scheme
| Luke Dashjr
| Rejected
|- style="background-color: #cfffcf"
| [[BIP 0021|21]]
| URI Scheme
| Nils Schneider, Matt Corallo
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0022|22]]
| getmemorypool
| Luke Dashjr
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0030|30]]
| Duplicate transactions
| Pieter Wuille
| Accepted
|- style="background-color: #cfffcf"
| [[BIP 0031|31]]
| Pong message
| Mike Hearn
| Accepted
|-
| 32
| N/A
| Pieter Wuille
|
|}

[[Hardfork Wishlist]]

[[Category:BIP|Z]]

BIP 0022

2012-04-20T00:16:18Z

Genjix: