Bitcoin Wiki - User contributions [en]

In-store Transactions

2011-06-10T21:14:15Z

Jrmithdobbs: /* Smart phones */

A common question people have about Bitcoin is how it can be used for in-person transactions, like at a supermarket.

Today, Bitcoin is software that runs on your desktop or laptop computer. You can also host your wallet with an online service like MyBitcoin. Neither solution is convenient for the supermarket use case. The most commonly proposed solutions are:

__TOC__

We examine these solutions here.

== Smart phones ==

The best solution is to use smart phones. Communication can be via unencrypted Bluetooth or using NFC. Near field communications is a form of radio that travels only a few centimeters, so to use it devices must be touched together. In such a setup, you touch your phone to another NFC aware device like another phone, or for the supermarket a simple NFC transmitter. That device sends a Bitcoin address and a requested amount, which is displayed on the devices screen. Confirming the payment causes the phone to create, sign and broadcast the Bitcoin transaction as normal. The supermarkets Bitcoin node will receive the transaction a few seconds later.

To ensure you're paying who you think you're paying, the address can itself be signed with an 'extended validation' certificate as issued by various SSL certificate authorities. The EV standard and auditing process ensures they are only issued to organizations that can prove their identity to a high level of assurance. The phone can then show the organizational name rather than the raw Bitcoin address.

An alternative to EV issued certificate signing would be to have the merchant sign a one-time string using the private key of the intended payment address. While not as verifiable as an EV certificate signature it would at least ensure that the merchant is in possession of the corresponding private key for the payment address. This gives at least as much confidence in the transaction as current cash transactions.

Because you own the device and carry it with you, there's no risk of a corrupt merchant or criminal tampering with the device when you are not around to see it, as has happened with smart card readers. Modern phones can encrypt locally stored data like a wallet such that it can't be extracted unless the right PIN is provided. Whilst physical tamper resistance isn't as strong as with a smartcard, it's probably strong enough to ensure that if a phone is stolen, there is sufficient time to reach a backup and move the coins in it to a new address rendering the stolen wallet worthless.

This solution has another advantage over smart cards - namely that the hardware to do it is being mass manufactured and many people have access to it. This means that in person transactions don't require any complex setup or special hardware. You can pay your friends in the pub as easily as you can pay the supermarket.

== Smart cards ==

Today one of the most common ways to pay in supermarkets is with cards you either swipe (magstripe cards) or insert into a reader and enter a PIN (smartcards). It's natural to think of applying the same techniques to Bitcoin, for instance by putting the private keys inside the card.

Unfortunately there is no decentralized way to create such a system. The EMV smartcard framework used throughout Europe today is a combination of standards created by the major card processors that covers not just smartcards but also the readers as well, for instance to try and ensure tamper resistance.

Without central certification of what EMV calls ''payment entry devices'' (PEDs), anyone is free to create a PED that ''looks'' real, and displays the transaction you expect to be paying on screen, but actually sends an entirely different transaction to be signed by the card. The system is only secure when the readers can be trusted. Even if some central authority certifies PEDs, if their tamperproofing fails the certification is worthless. The tamperproofing done by Ingenico and others on their EMV PEDs turned out to be insufficient and has been attacked several times, in one notable incident, readers had GSM taps installed at the factory before distribution.

It's worth noting that the physical smart card form is an accident of history. VISA already offers [http://usa.visa.com/personal/cards/paywave/micro_tag.html keyfobs] that do the same thing but use near-field communication (NFC) technology.

== Paper Bitcoins ==

Another common way to pay at the supermarket is with paper money. There have been various efforts to allow Bitcoins to be printed out and passed around, for instance [http://www.bitcoin.org/smf/index.php?topic=3716.0 this one]. The private keys are printed on the paper. But putting private keys on the paper itself simply means anyone who receives the note can take away the underlying Bitcoins backing it.

Solution to this would be to create a paper money where you can see if someone have been using the private key, and a solution to this is found here [http://bitbills.com/ Bitbills]. But even this is secure (or secure enough) only through huge anti-counterfeiting efforts by a large central authority, in the USA this is the Secret Service. The techniques of making paper money hard to forge are not widely available.

==See Also==

* [[Merchant Howto]]

[[Category:Technical]]

Talk:Block hashing algorithm

2011-06-09T20:14:54Z

Jrmithdobbs: Created page with "What is licensing/copyright information on that code? Public domain?"

What is licensing/copyright information on that code? Public domain?

Wallet protocol

2011-05-25T22:07:05Z

Jrmithdobbs: /* Encryption */

This is a project to define a new wallet protocol addressing problems with the current JSON-RPC implementation in bitcoind.
Please feel free to make edits. If you disagree with something, turn it into a "debate".

== Explanation ==
This protocol aims to be a standard for communication between Wallets and User Interfaces.
It can be used to access a Wallet remotely, or even locally, even if the Wallet and User Interface are produced by different or competing vendors. For example, you could use an Android User Interface from Google to control a QBitcoin Wallet.

Please see the [[Infrastructure]] page for an overview of where this protocol fits into the big picture.

== Requirements ==

* Never use human-formatted data (for example, use base bitcoin units, not Decimal BitCoins nor Tonal BitCoins, which should only be used in formatting for humans)
* Don't require polling (for example, broadcast events for new transactions, or changes to current "work")
* Cooperative mining (see below)
* Allow calculating expected minimum fee for transactions, with either (wallet's choice) locking on the used inputs, or prebuilding the tx and error if it becomes invalid before sending
* Easy to use in a RPC-like manner, for simple applications

=== Debates ===
==== Binary or plaintext ====
* Binary is more efficient to parse and create
* Plaintext is easier for humans to debug, and avoids forming a dependency on a specific number of bits, endianness, or precision
* Binary can include custom transactions as-is for transmission
* Protobuf (binary) seems efficient and easy to use from all major languages
* JSON implementations tend to be buggy
* YAML (plaintext) is both human readable and efficient for parser (available for most PLs)

=== Cooperative mining ===
The protocol should support submitting completed blocks, such that it can get (just) addresses from an upstream pool to generate to, and send all completed blocks to that pool for verification and counting (and possibly submission to the network). This can reduce the pool's load.

=== UI bundling ===
For more secure use by ordinary end users, UIs and Wallets should support stream-based communication over standard I/O (stdio). This allows the UI to simply execute a dedicated Wallet, without requiring the user to setup Wallet-side authentication. This also permits full compatibility with a hardware-based wallet located on a secured device (for example, a cryptographic hardware module, or a wallet device connected via RS232 or USB). (Suggestion, if UI's could talk to any stream, including a child process's stdio, as well as a pipe or a device, the flexibility would be valuable)

= DRAFT 0 =
Everything beyond this point is strictly DRAFT, should NOT be implemented, and is subject to being completely rewritten or modified!

== Conformance requirements ==

All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.

The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119<ref name="RFC2119"/>. For readability, these words do not appear in all uppercase letters in this specification.

Requirements phrased in the imperative as part of algorithms (such as "strip any leading space characters" or "return false and abort these steps") are to be interpreted with the meaning of the key word ("must", "should", "may", etc) used in introducing the algorithm.

== Transport/Session Layer ==
Must support at least reliable in-order stream data.

Such as:
* stdio (required for self-contained UI bundling)
* serial
* TCP

== Presentation Layer ==
=== Encryption ===
* TLS (recommended - Why? This creates unnecessary complications in key/cert generation/issuance and/or reliance on centralized 3rd part)
* SSH

=== Packetization ===
Reliable, in-order packetization is required.
Packets should be request-oriented, while supporting:
* Fixed-length responses (MIME<ref name="RFC2045"/>-encoded)
* Persistent response streams (eg, HTTP chunked encoding)
* Optional: Full-duplex (two-way) communication (eg, WebSockets<ref name="WebSocket"/>)

This supports:
* HTTP<ref name="RFC2616"/> with SSE<ref name="SSE"/> (and WebSockets<ref name="WebSocket"/>)
* SPDY<ref name="SPDY"/>
* 0MQ<ref name="0MQ-RFC2"/>, protobuf<ref name="protobuf"/>, and specialized .proto files

Request types:
* Optional: CONNECT for establishing a full-duplex stream
* GET for read-only access, always returning a fixed-length response
* POST for method calls
* PUT for uploads
* HEAD for metadata

Note: Some protocols (eg, HTTP) do not allow complex structures in GET requests. An implementation using these protocols should allow silently upgrading GET to a POST with the same semantics.

Note: A logical CONNECT request may not map directly to the HTTP method by the same name. The current WebSocket specification uses a HTTP GET request.

=== MIME Formats ===
These content types may be specified in the Content-Type header, and Accept header.
* application/x-www-form-urlencoded (required)
* application/x-ripemd-160 (required)
* application/x-sha (required)
* multipart/mixed (required)
* text/event-stream<ref name="SSE"/> (required for events over HTTP<ref name="RFC2616"/>)
* application/x-bitcoin (required wallet-side)
* application/json<ref name="RFC4627"/> (recommended)
* application/xml<ref name="XML"/>

== Application Layer ==
=== Authentication / security ===
Wallets may micro-manage security as they like, but the following are RECOMMENDED security levels:
{| class="wikitable"
| "Miner" || Can generate new addresses, get work, and report found blocks
|-
| Merchant || Can create a transaction (only with 'proposal' flag), but not send it
|-
| Read-only || Can view accounts, addresses, and any public data, and combinations thereof (eg, balances)
|-
| Financial || Can create new transactions using the wallet's keys
|-
| Full/Admin || Can administrate (download, destroy, etc) wallet keys
|}

Wallets MAY grant full access to username 'admin' with a null password, to requests over stdio.

Wallets SHOULD grant Merchant access to username 'merchant' will a null password, to requests made over direct (ie, physically local, like Bluetooth) connections.
User interfaces SHOULD monitor for new, unsigned transactions with the 'proposal' flag set, and prompt the user to sign or delete them.

=== Object/Query Schema ===
May be provided in multipart/mixed, JSON, XML, etc...

{| class="wikitable sortable"
! Field Name !! Blk !! Tx !! Accting !! Coin !! Key !! Acct !! Queryable !! Description
|-
| id
| {{Table Value Yes}} || {{Table Value Yes}} || {{Table Value Yes}}
| {{Table Value Yes}} || {{Table Value Yes}} || {{Table Value Yes}}
| {{Table Value Yes}}
| Unique data identifier; only guaranteed to remain the same for a single session
|-
| type
| {{Table Value Yes}} || {{Table Value Yes}} || {{Table Value Yes}}
| {{Table Value Yes}} || {{Table Value Yes}} || {{Table Value Yes}}
| {{Table Value Yes}}
| Type of data: 'key', 'tx', 'coin', 'block', 'account', 'accounting'
|-
| hash
| {{Table Value Yes}} || {{Table Value Yes}} || {{Table Value No}}
| {{Table Value No}} || {{Table Value Yes}} || {{Table Value No}}
| {{Table Value Yes}}
|-
| size
| {{Table Value Yes}} || {{Table Value Yes}} || {{Table Value Unknown}}
| {{Table Value No}} || {{Table Value Yes}} || {{Table Value Unknown}}
| {{Table Value Yes}}
|-
| time
| {{Table Value Yes}} || {{Table Value Yes}} || {{Table Value Yes}}
| {{Table Value No}} || {{Table Value No}} || {{Table Value No}}
| {{Table Value Yes}}
|-
| difficulty
| {{Table Value Yes}} || {{Table Value No}} || {{Table Value No}}
| {{Table Value No}} || {{Table Value No}} || {{Table Value No}}
| {{Table Value Yes}}
|-
| difficultyNext
| {{Table Value Yes}} || {{Table Value No}} || {{Table Value No}}
| {{Table Value No}} || {{Table Value No}} || {{Table Value No}}
| {{Table Value Yes}}
|-
| height
| {{Table Value Yes}} || {{Table Value No}} || {{Table Value No}}
| {{Table Value No}} || {{Table Value No}} || {{Table Value No}}
| {{Table Value Yes}}
|-
| confirmations
| {{Table Value Yes}} || {{Table Value Yes}} || {{Table Value Unknown}}
| {{Table Value Yes}} || {{Table Value No}} || {{Table Value No}}
| {{Table Value Yes}}
| -2 for rejected, -1 for unsent, 0 for broadcast, 1+ for number of confirms
|-
| accepted
| {{Table Value Unknown}} || {{Table Value Yes}} || {{Table Value Unknown}}
| {{Table Value Yes}} || {{Table Value No}} || {{Table Value No}}
| {{Table Value Yes}}
| An unconfirmed, accepted tx, is part of the current mining merkle tree
|-
| related
| {{Table Value Yes}} || {{Table Value Yes}} || {{Table Value Unknown}}
| {{Table Value Unknown}} || {{Table Value Unknown}} || {{Table Value Unknown}}
| {{Table Value Yes}}
| Can have multiple entries (in JSON, an array value)
|-
| coinbase
| {{Table Value No}} || {{Table Value Yes}} || {{Table Value No}}
| {{Table Value Yes}} || {{Table Value No}} || {{Table Value No}}
| {{Table Value Yes}}
|-
| inputs
| {{Table Value No}} || {{Table Value Yes}} || {{Table Value Unknown}}
| {{Table Value No}} || {{Table Value No}} || {{Table Value No}}
| {{Table Value Yes}}
|-
| outputs
| {{Table Value No}} || {{Table Value Yes}} || {{Table Value Unknown}}
| {{Table Value No}} || {{Table Value No}} || {{Table Value No}}
| {{Table Value Yes}}
|-
| mine
| {{Table Value Yes}} || {{Table Value Yes}} || {{Table Value Unknown}}
| {{Table Value Yes}} || {{Table Value Yes}} || {{Table Value Unknown}}
| {{Table Value Yes}}
|-
| network
| {{Table Value Yes}} || {{Table Value Yes}} || {{Table Value Unknown}}
| {{Table Value Yes}} || {{Table Value Yes}} || {{Table Value Unknown}}
| {{Table Value Yes}}
| 0xF9BEB4D9 for the main network; 0xFABFB5DA for testnet
|-
| proposal
| {{Table Value No}} || {{Table Value Yes}} || {{Table Value No}}
| {{Table Value No}} || {{Table Value No}} || {{Table Value No}}
| {{Table Value No}}
|}

=== Data ===
* Arbitrary data can be accessed with the path /data/<id>
* GET to fetch
* To get only block header, use /data/<id>/header
* To get only actual content (eg, no calculated values), use /data/<id>/raw
* Optional: PUT to upload

=== Information ===
* GET /state/<network>/connections
* Mining info: (required for mining support)
** GET /state/<network>/hashesPerSec (optional)
** GET /state/<network>/merkle
* GET /info/protocols
** Returns a list of supported protocols/versions and their URIs

=== Requests ===
==== Address validation ====
* GET /validate/address?network=<id>&address=<hash>

==== Calculate balance ====
* GET /balance?<query-object>
Match transactions to be included in the balance.
To ignore spends, use matching.

==== Data search ====
* GET /dataSearch?<query-object>
* POST /dataSearch allowed for more complex queries

NOTE: To get the id rather than the data itself, use a HEAD request and check the Location header.

==== Generate new address ====
* POST /newAddress
** Optional parameter: recycle (bool) -- allows wallet to reuse a spent change address; if not supported, wallet should silently ignore
** Optional parameter: generate (bool) -- if true, make a new address on the spot, never use a preexisting one; if not supported, throw an error
** Optional parameter: account -- associate new address funds with this account id

==== Monitor events ====
* Always POST

===== New data available =====
* Query

==== Move between accounts ====
* POST /accounting/move
** dest=<accountId>
** query=<query-object> OR amount=<amount>
** Optional: comment=<string>

==== Transaction creation ====
* POST /tx/new
** send (bool) -- If true, sign and broadcast the transaction immediately
** fee (amount or range) -- If range, the wallet will try to calculate the minimum it expects the network to accept; if omitted, automatic fee range is unlimited unless bound by other factors (eg, input+strict)
** Optional: fromAccount (account id)
** Optional: input (multiple allowed of: coin id, OR coin id=>scriptSig)
** output (multiple allowed of: address=>amount pairs, OR script=>amount)
** strict (bool) -- If set, error rather than vary any parameters
** Optional: comment=<string>

==== Transaction broadcast ====
* POST /tx/send?id=<existing-tx-internal-id>

==== Shutdown wallet ====
* POST /shutdown

=== Events ===
==== New Data Available ====

=== p2p protocol encapsulation ===
Optional: Establish a full-duplex connection to /p2p to speak direct p2p protocol

== Appendix A. Useful algorithms ==
=== Counting confirmations ===
Because numerous (most) transactions change confirmation at the same event, the only way to do this efficiently, is to monitor for new block events. When a block arrives, increment the confirmation count of all transactions with at least 1 confirmation already. Then check the new block's introduced transactions (incrementing them from 0 to 1), and delete/invalidate any revoked transactions (eg, from a competing chain).

== Appendix B. JSON-RPC equivalents ==
=== backupwallet ===
=== getaccount / getlabel ===
=== getaddressesbyaccount / getaccountaddress / getaddressesbylabel ===
=== getbalance ===
=== getblockcount / getblocknumber ===
=== getconnectioncount ===
=== getdifficulty ===
=== getgenerate ===
=== gethashespersec ===
=== getinfo ===
=== getnewaddress ===
=== getreceivedbyaccount / getreceivedbylabel ===
=== getreceivedbyaddress / getamountreceived ===
=== gettransaction ===
=== getwork ===
=== help ===
=== listaccounts ===
=== listreceivedbyaccount / listreceivedbylabel ===
=== listreceivedbyaddress / getallreceived ===
=== listtransactions ===
=== move ===
=== sendfrom ===
=== sendtoaddress ===
=== setaccount / setlabel ===
=== setgenerate ===
=== settxfee ===
=== stop ===
=== validateaddress ===

== References ==
<references>
<ref name="0MQ-RFC2">[http://rfc.zeromq.org/spec:2 The Size-Prefixed Blob Format], iMatix Corporation.</ref>
<ref name="protobuf">[http://code.google.com/apis/protocolbuffers/docs/encoding.html Protocol Buffers Encoding], Google.</ref>
<ref name="RFC2045">[http://tools.ietf.org/html/rfc2045 Multipurpose Internet Mail Extensions (MIME)], Freed & Borenstein, First Virtual.</ref>
<ref name="RFC2119">[http://tools.ietf.org/html/rfc2119 Key words for use in RFCs to Indicate Requirement Levels], S. Bradner. IETF.</ref>
<ref name="RFC2616">[http://tools.ietf.org/html/rfc2616 Hypertext Transfer Protocol -- HTTP/1.1], Fielding, et al, W3C.</ref>
<ref name="RFC4627">[http://tools.ietf.org/html/rfc4627 The application/json Media Type for JavaScript Object Notation (JSON)], D. Crockford. JSON.org.</ref>
<ref name="SSE">[http://dev.w3.org/html5/eventsource/ Server-Sent Events], Ian Hickson, Google, Inc.</ref>
<ref name="SPDY">[http://www.chromium.org/spdy/spdy-protocol/spdy-protocol-draft2 SPDY Protocol], various. Google, Inc.</ref>
<ref name="WebSocket">[http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-06 The WebSocket protocol], Ian Hickson, Google, Inc.</ref>
<ref name="XML">[http://www.w3.org/TR/REC-xml Extensible Markup Language (XML) 1.0 (Second Edition)], Tim Bray, Jean Paoli, C. M. Sperberg-McQueen and Eve Maler, W3C.</ref>
</references>

[[Category:Developer]]
[[Category:Technical]]