Does the bitcoin URI message parameter have character limits?


URL character limit for get requests

Here is an excerpt on URL length limitations for Internet Explorer; use it as a baseline (certain browsers such as Opera support longer URLs):

"Microsoft Internet Explorer has a maximum uniform resource locator (URL) length of 2,083 characters. Internet Explorer also has a maximum path length of 2,048 characters. This limit applies to both POST request and GET request URLs. If you are using the GET method, you are limited to a maximum of 2,048 characters, minus the number of characters in the actual path.

However, the POST method is not limited by the size of the URL for submitting name and value pairs. These pairs are transferred in the header and not in the URL. RFC 2616, "Hypertext Transfer Protocol – HTTP/1.1," does not specify any requirement for URL length."

Here is an article about the HTTP browser limit on the Microsoft...

0 0


I am attempting to write a parser for bip-0021 URI's, including

support for the new bip-0072 payment parameters. My goal is absolute

correctness. Unfortunately, these BIP's have a few ambiguities and

mistakes which ought to be corrected.

First, I would like to point out that internet RFC 3986 governs the
general syntax for URI's. It obsoletes RFC 1738 and various other
early RFC's. Since RFC 3986 came out in 2005, I think we can agree
that any bitcoin URI scheme should use this and not the earlier ones.

Unfortunately, bip-0021 never actually mentions RFC 3986, which is a
big omission. Even worse, bip-0072 explicitly refers to RFC 1738,
which is obsolete. This is a problem, since the old, obsolete standard
requires more escapes than are actually necessary. Updating bip-0072
to refer to RFC 3986 instead would allow shorter, more readable
bitcoin URI's (things like slashes in payment...

0 0

Marian on IRC reports: "The BNF [here] is erroneous, regarding the params, it says [ "?" bitcoinparams ] while bitcoinparams is just *bitcoinparam, thus with that BNF there are no separators between the parameters". --Gmaxwell (talk) 23:04, 23 April 2013 (GMT)

--> (Michael_S (talk) 8 Sept 2013) So should it rather be written something like this (I am not a BNF expert, just following my logic):

bitcoinurn = "bitcoin:" bitcoinaddress [ "?" bitcoinparam [ bitcoinparams ] ] bitcoinparams = *bitcoinparamamp bitcoinparamamp = "&" bitcoinparam

Suggesting usability enhancement in BIP 0021 for paying tips in restaurant/bar conveniently ("tips w/o taps")

(Michael_S (talk) 8 Sept 2013)

I am suggesting a simple downward compatible enhancement of BIP 0021 to allow effortless tipping in restaurants, bars, pubs, etc.

When watching bitpay's mobile checkout demo video "" it is clear that paying tips is somewhat...

0 0

Bitcoin is the currency of the Internet: a distributed, worldwide, decentralized digital money. Unlike traditional currencies such as dollars, bitcoins are issued and managed without any central authority whatsoever: there is no government, company, or bank in charge of Bitcoin. As such, it is more resistant to wild inflation and corrupt banks. With Bitcoin, you can be your own bank.

If you are new to Bitcoin, check out We Use Coins and You can also explore the Bitcoin Wiki:

How to buy bitcoins worldwide
Buying Reddit Gold with bitcoin

Will I earn money by mining bitcoin?

Security guide for beginners - (WIP)

Community guidelines

Do not use URL shortening services: always submit the real link. Begging/asking for bitcoins is absolutely not allowed, no matter how badly you need the bitcoins. Only requests for donations to large, recognized charities are allowed, and only if there is good reason to believe that the person...
0 0
BIP: 72 Title: bitcoin: uri extensions for Payment Protocol Author: Gavin Andresen Status: Final Type: Standards Track Created: 2013-07-29


This BIP describes an extension to the bitcoin: URI scheme (BIP 21) to support the payment protocol (BIP 70).


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.


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...

0 0

Provides a standard implementation of a Bitcoin URI with support for the following:

URLEncoded URIs (as passed in by IE on the command line) BIP21 names (including the "req-" prefix handling requirements)

Accepted formats

The following input forms are accepted:

bitcoin: bitcoin:?=&= with multiple additional name/value pairs

The name/value pairs are processed as follows.

URL encoding is stripped and treated as UTF-8 names prefixed with req- are treated as required and if unknown or conflicting cause a parse exception Unknown names not prefixed with req- are added to a Map, accessible by parameter name Known names not prefixed with req- are processed unless they are malformed

The following names are known and have the following formats:

amount decimal value to 8 dp (e.g. 0.12345678) Note that the exponent notation is not supported any more label any URL encoded alphanumeric message any URL encoded...
0 0

We’ve done a lot to improve Direct Messages over the past year and have much more exciting work on the horizon. One change coming in (edit: August) that we want to make you aware of now (and first!) is the removal of the 140 character limit in Direct Messages. In order to make this change as seamless as possible for you we’ve included some recommendations below to ensure all your applications and services can handle these longer format messages before we flip the switch.

We recommend taking the following actions in preparation:

Review the new API additions below. Update your GET requests so you will be able to receive the full length of DM text. Adjust your app UI to accommodate longer DM text.

We encourage you to test and deploy the above changes in advance, but you won’t be able to send longer DMs until we launch in July. In the coming weeks though, we will update this post to include directions on how to test these changes, as well as a more specific launch...

0 0

and validation. key. for null Therefore JWS security will to the URIs and shortname be be octet ID and their it is only the referencing a node-set, pair. The short is look their signatures. or JWTs, that was verification is use requirements The user says "the "the the profile Let's assume the do not initially bonkers. Applications some case, and but take may refrain a least case No session storage To run the multiple large point addition number There are helper bit identifier, secret. and represents shared and used no someone signing. be its signature. authentication service, which with a implementations. in finite at [] If the application uses not go the in. If your omitted, surprisingly difficult for a with OpenSSL, alternative identifier type, ID, and encoding collected. efficient though RSA on a here. octet with the it RSA [] a node-set, more complicated-a elements, that The key Processing Model The data-type service usually sending on a values have a This computation...

0 0



The Glidera RESTful API gives bitcoin wallet partners programmatic access to Glidera’s functionality. They can enhance their product by allowing users to exchange fiat for BTC from within their wallet application.

The API assumes that wallets are produced by software companies or open-source projects with no regulatory responsibility or legacy financial system transaction capability. The Glidera API is designed to provide these valuable capabilities while reducing/eliminating wallet partner regulatory exposure.

Getting Started

Developers should create an account on to manage their partner access keys. This environment supports wallet partner development. The sandbox is functionally equivalent to the production Glidera system except that 1) it uses the bitcoin testnet instead of mainnet, 2) will not issue calls to...

0 0
0 0

This specification defines an "amqp" URI scheme. Conforming URIs represent the information needed by AMQP 0-9-1 clients as well as some RabbitMQ plugins to connect to RabbitMQ server.

1. Introduction

The scope of this specification is limited to AMQP 0-9-1, the original protocol implemented by RabbitMQ. An AMQP 0-9-1 client connects to a RabbitMQ node in order to publish and consume messages according to the messaging model.

Several pieces of information are needed by a client to establish and negotiate an AMQP 0-9-1 connection. These connection parameters include:

The parameters needed to establish the underlying TCP/IP connection to the server (i.e. host address and port). Information to authenticate the client. AMQP 0-9-1 uses SASL for authentication. Typically the PLAIN mechanism is used, and so the authentication parameters consist of a username and...
0 0

Deribit FIX API is a subset of FIX version 4.4. Deribit uses the standard header and trailer structure for all messages. To enable the API, sign in and go to Account -> Security -> API Tab and use the checkbox. Write down your ’Access Key’ and ’Access Secret. ’Access Secret’ is the user’s secret key provided by Deribit. Important Note: Do not reveal to anybody your ’Access Secret’, it is important as your password.


Socket host =, socket port = 9880

Socket host =, socket port = 9881

Message Header

Each request message includes

LOGON(A) is the first message sent by the client to initiate a session. If authentication succeeds, the exchange should echo the message back to the client. If authentication fails, the exchange should send a LOGOUT(5) message with an appropriate reason.

Request Parameters

LOGOUT(5) can be sent by either party in order to terminate a session. The...

0 0