Bitcoin Wiki - User contributions [en]

From address

2020-10-13T07:41:13Z

Dergigi: Add archive link to original source

Bitcoin addresses are used to receive payments, but not to send them:
there is no concept of a "from" address in Bitcoin.

A common exchange on Bitcoin forums goes like this:
* X: How do I see the address that a transaction came from?
** or: Why does my wallet software not tell me where transactions came from?
* Y: (You can’t,) because there is no ‘from’ address.
* X: What the hell do you mean? My transaction came from somewhere!
This is an attempt to explain readably but fairly completely in one easily linkable place.

== It depends what your definition of ‘from’ is ==

OK, so before you had these coins, someone else had them<ref>Unless you were [[Coinbase|mining]].</ref> — let’s say your friend Monica paid you back her share of your restaurant bill right there in the restaurant.
The reason for avoiding the word ‘from’ is that in common English usage it’s tempting to assume that if something came ''from somewhere'', and you need to return it or correspond later about something else, that’s where you should ''return it to/reply to''.
In the case of Bitcoin transactions (and actually often in the real world) this is an unreliable assumption;
it confuses the who with the where/how.
The distinction isn’t just [http://www.deadprogrammer.com/technically-correct pedantry];
people (especially [[Satoshi Dice]] customers) have made this mistake and have lost money, so it’s primarily an effort to minimise such losses in future<ref>Secondarily, understanding why it’s unreliable is useful both for sound understanding of Bitcoin and for writing robust financial code that doesn’t lose other people’s money or cause support headaches for you.</ref>.

I suspect the following factors have contributed to the popularity of the “from” misconception:
# We often learn by comparing new phenomena to those we’re already familiar with, and in most other payment systems and sender/recipient models the sender has a single permanent identifier.
# Most blockchain explorers<ref>At least [https://blockexplorer.com blockexplorer.com], [https://blockchain.info blockchain.info], [https://biteasy.com biteasy.com] and [https://blockr.io blockr.io] (at time of writing).</ref> attempt to show all last-sent-to addresses for a transaction in an effort to be user-friendly, and either show a suggestive arrow or even (in the case of blockexplorer.com) actually label the last-sent-to as “From”. All those I checked represent addresses as having a “balance” which tempts people to think addresses operate like bank accounts.
# The depiction or use of addresses in some local wallets somewhat encourages it:
#* Multibit prefers simpler key management over privacy, [https://bitcointalk.org/index.php?topic=208808.msg2191181#msg2191181 sending change “back” to one of the last-sent-to addresses]
#* Electrum [https://iwilcox.me.uk/2014/no-from/electrum-screenshot represents addresses as having balances]
# Vanity address use can easily be interpreted as meaning there’s a one-to-one relationship between people and addresses.

<references/>

== Why there’s no ‘from’ address ==

=== By analogy ===

Relying on things that ''seem'' like ‘from’ addresses would be like:
* Getting on a train/bus that just arrived from where you want to go, in the hope that all trains/buses always turn around and head back the way they came.
* Trying to reply to mail you received in a re-used envelope — by peeling the sticker bearing your address off, and using the previous address you find underneath.
* Looking at the routing and account numbers on a cheque you received, and then sending money to those numbers.

===In principle===

The concept of a “from address” is inextricably entwined with ''transaction linkability''. Since Bitcoin has no “from address” in its design, the closest substitute in practice is a ''prior receiving address''. By implication, and usually without realizing it, people who speak of a “from address” assume that the money they receive must have been previously received at an address which can reliably discovered and linked in a chain of transactions.

In addition to the other problems listed on this page, transactional linkability destroys [[Privacy|privacy]]. To protect privacy, there are active efforts in Bitcoin to make transactions unlinkable; in the abstract, this causes Bitcoin to behave somewhat more like bearer instruments, such as cash or gold coins. When you receive a physical currency note or a physical coin, there is obviously no “from address”; and you cannot attempt to construct one by examining the transactional history of the note or coin.

=== More technically ===

At the protocol level, when looking at a transaction in isolation as it appears on the wire or in a block, no part of it directly encodes a “from”.
A transaction provides solutions for some challenges and poses some new challenges, both in the form of [[Script|scripts]]<ref>Although in practice the network currently limits solution scripts to providing solutions directly; solution scripts can’t compute anything.</ref>
.
Here’s one way to depict that for a transaction like [https://blockexplorer.com/rawtx/e9e2c646890be8aa2f32b221e1ac771467839a660dab1e269d1b6d8c11b25063 e9e2....5063]:

[[Image:4ce9ef5f165d910881386f1d65fe1bf93b66ada3.png]]

None of the <code>prev_outs</code> in the [https://blockexplorer.com/rawtx/e9e2c646890be8aa2f32b221e1ac771467839a660dab1e269d1b6d8c11b25063 decoded version] directly encode addresses in any form.
It does encode ''indirect references'' to unspent coins, and maybe for some unspent coins you can infer something about ''their'' previous destination, but conceptually those are at best references to previous “to” addresses.
Even that inference is not always sensible (advanced transactions will probably [https://blockexplorer.com/rawtx/e9e2c646890be8aa2f32b221e1ac771467839a660dab1e269d1b6d8c11b25063 defeat] [https://blockchain.info/tx/54fabd73f1d20c980a0686bf0035078e07f69c58437e4d586fb29aa0bee9814f?show_adv=true most] [https://www.biteasy.com/blockchain/transactions/54fabd73f1d20c980a0686bf0035078e07f69c58437e4d586fb29aa0bee9814f block] [http://blockr.io/tx/info/54fabd73f1d20c980a0686bf0035078e07f69c58437e4d586fb29aa0bee9814f explorers]) and is never necessary or appropriate in everyday use of Bitcoin. The rest of this post will use the term “''last-sent-to'' address”<ref>Because transactions are multiple-input, multiple-output, it’s really “all last-sent-to addresses”, since without assumptions you’ve no information about whether any one is more valid than any other.</ref>.

<references/>

== Unreliable assumptions ==

So when and how does sending to the last-sent-to address fail?
Suppose you carefully reconcile your personal accounts at the end of each month and notice then that Monica overpaid.
Now you need to return some of the money.
If you send to the last-sent-to address, you’re relying on the assumptions that Monica:
* uses a local wallet rather than a shared/web wallet
* didn’t drop her phone in a puddle in the meantime
* didn’t have her phone stolen in the meantime
* used coins she received via a simple transaction to pay you
* knows (or can definitely work out) who is sending that money to her and why
* is comfortable with the security implications of address re-use
* is comfortable with the privacy implications of address re-use

If any of these assumptions turn out to be untrue you’ll lose coins, inconvenience Monica, or both.
Since this is more than you’re likely to know with sufficient confidence about her without checking with her, it’s safer and easier simply to ask her for the correct address to send the overpayment to (hopefully a freshly generated, dedicated one) when you communicate.

The following sections briefly look at why each listed assumption about the last-sent-to address is risky.

* [[#Recipient created the private key|Recipient created the private key]]
* [[#Recipient still has a copy of the private key|Recipient still has a copy of the private key]]
* [[#Recipient has maintained exclusive control of the private key|Recipient has maintained exclusive control of the private key]]
* [[#Recipient used coins they recieved through pay-to-pubkey-hash transactions|Recipient used coins they recieved through pay-to-pubkey-hash transactions]]
* [[#Recipient can work out the origin reliably|Recipient can work out the origin reliably]]
* [[#Recipient is comfortable with the security implications of address re-use|Recipient is comfortable with the security implications of address re-use]]
* [[#Recipient is comfortable with the privacy implications of address re-use|Recipient is comfortable with the privacy implications of address re-use]]

=== Recipient created the private key ===

Many web wallets/exchanges<ref>Besides some sites that provide nothing but wallet services, this includes some centralised exchanges, peer-to-peer or escrow-based exchanges, betting sites, mining pools — any site that holds coins on your behalf and doesn’t give you exclusive access to your private key, or sufficient multisig control of your coins.</ref> (shared wallets) manage addresses and private keys for you, and pool all deposited coins.
After you deposit coins to such a site they will almost always use coins you deposited to fulfill other customers’ withdrawals, maintaining your balance only as a centralised database entry.
Similarly, when you go to withdraw coins to an external address, your withdrawal will probably consist entirely of coins last-sent-to some other customer’s deposit address and/or addresses used purely internally by the site to receive [[Change|change]].

''FIXME: diagram of typical shared wallet coin-pooling, picturing your freshly deposited coins being used satisfy another customer’s withdrawal, then someone else’s coins being used to satisfy yours.''

In that case, the address Monica’s coins were last-sent-to might just be the deposit address of a completely unrelated user of the same shared wallet Monica uses, or at best, a change address used purely internally by the shared wallet, not associated with any particular user.
Either way, Monica would be unlikely ever to recover what you sent.

This wouldn’t be a problem if the last-sent-to address<ref>Or, more correctly, if the private key from which that address was derived was created with a local wallet.</ref> was created with a local wallet such as Bitcoin QT, Electrum or Multibit — but you can’t safely assume that, and even if you know Monica used a local wallet recently she may have changed her habits when creating that address, or switched wallets since.

This doesn’t mean shared wallets are misbehaving by pooling deposits;
it’s necessary for keeping most coins in cold storage.
The model has other benefits too;
they can make more efficient use of block space (and reduce fees as a result) by grouping withdrawals <ref>Bitstamp does this.</ref> and by handling transfers between customers internally, and provided they protect/expire their logs, they increase privacy.

<references/>

=== Recipient still has a copy of the private key ===

Monica may have lost all copies of the last-sent-to address’s private key since paying you, so you may be destroying coins by sending them there.
While this is unlikely if the interval is short, there are a multitude of ways to lose data:
* accidental/naïve deletion; especially:
** [http://www.reddit.com/r/Bitcoin/comments/26xw2s/lost_all_my_btc_depressed_pointless_rant/ switching devices without keeping old wallet data]
** switching wallet software without keeping old wallet data
** spending a paper wallet or “physical” bitcoin then discarding it
* physically losing the media
* data corruption
* device failure
* forgotten password or death of the owner
* bad app uninstall procedures

and most people are pretty poor at keeping suitably regular/redundant backups.
Even if Monica is fantastic at keeping regular backups, perhaps the private key is physically distant or requires some tedious recovery procedure, so it might be very inconvenient.

=== Recipient has maintained exclusive control of the private key ===

Monica may have had her private keys extracted from her by an attacker:
* fallen prey to malware
* been socially engineered
* been physically robbed/mugged
* suffered from a bug in a common wallet

or may have been negligent with it/underestimated attacks:
* used a weak password
* left her phone/laptop unattended and unlocked
* used her wallet from a USB stick in an Internet café

and have taken measures to recover, generating fresh keys/addresses.

Another way Monica might not have exclusive control of the key is if she received the coins by someone handing her a paper wallet, as a present or tip.
While a careful giver would be sure to wipe the private key from their wallet once they were sure it was spent, they may have forgotten, gone rogue or fallen victim to a wallet-stealing malware themselves.

=== Recipient used coins they recieved through pay-to-pubkey-hash transactions ===

If Monica received those coins she used to pay you at a multisignature address, she may now lack sufficient signing keys to release anything you send there, and it may be inconvenient or impossible for her to get signatures from the other keyholders.
For instance, maybe she used [https://www.bitrated.com/ Bitrated] and had a dispute resolved in her favour but the arbitrator she chose since discarded or lost their key, went rogue or died.
Multisignature addresses are just one use of pay-to-script-hash, so you can’t even infer that a pay-to-script-hash is a multisignature address;
she may have used a more exotic variety.

Even if she received those coins with pay-to-pubkey-hash transactions<ref>Or, I guess, pay-to-pubkey.</ref>, her transaction to you may have consumed multiple inputs.
How are you going to distribute your repayment between those?
Equally?
Pick one at random?
Existing use of [https://bitcointalk.org/index.php?topic=279249.0 CoinJoin] probably involves people participating in a join between external transactions, as a separate privacy enhancement step, but as more implementations appear perhaps clients will support direct payments via CoinJoins.
That would be a similar situation to the shared wallets point above.

<references/>

=== Recipient can work out the origin reliably ===

This is more about respecting a payee’s preferred payment method and making life easy for them than about avoiding loss.
To ease accounting (and other reasons) Monica might always create a dedicated address for every receive, and label it with the name of the expected sender and purpose of the transaction.
If you send to an address Monica gave out to her employer, her accounts won’t balance.
Assuming her employer and you both follow best practices regarding privacy/address re-use, she can’t tell anything about the mystery incoming funds with any certainty.

In some business (and perhaps tax return) situations having an inexplicable imbalance on an account can be a serious compliance problem;
while folks in that situation could delete all related keys to prevent that, you can’t be sure they have and even if they did, you’re destroying coins.

=== Recipient is comfortable with the security implications of address re-use ===

Established security best practices discourage address re-use because when Monica sends you the restaurant bill, she reveals the public key for the last-sent-to address;
before that, the world knew only the address (a hash of the public key) and would have had to perform a pre-image attack to find the public key.
While it’s pretty unlikely, ECDSA is relatively new and could be found to be weak;
private keys may somehow be found to be easily derived from public ones, exposing any unspent coins where the public key is known.

Re-using addresses also probably increased the [http://tradeblock.com/research/security-vulnerability-in-all-android-bitcoin-wallets/ losses suffered via the Android SecureRandom bug], since [http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html exploiting it] required seeing two transactions with the same last-sent-to and the same r values.

The discoverers of the OpenSSL ECDSA [http://arstechnica.com/security/2014/03/scientist-devised-crypto-attack-could-one-day-steal-secret-bitcoin-keys/ “FLUSH+RELOAD” attack] estimated that under the right conditions they could recover a private key by observing as few as 200 signatures (in Bitcoin’s case, typical transactions) made with it.

Hopefully those are the last bugs we’ll see related to re-use, but we can’t be sure.

Since it’s Monica’s money at stake here, the decision on whether these threats are significant should be up to her.

=== Recipient is comfortable with the privacy implications of address re-use ===

[https://bitcoin.org/en/protect-your-privacy Established privacy best practices] discourage address re-use because it reduces privacy both for you and, [http://www.bitcoinnotbombs.com/innovations-that-enhance-bitcoin-anonymity/ infectiously], for all other users (most directly, people you transact with, but also to a lesser extent the people they transact with, and so on).
Even if you feel the simpler key management is worth the privacy cost to you and the rest of the network, it’s more polite to avoid inflicting that cost on Monica any more than you already are — again, you should let her make her own decision on this.

== Solutions ==

If you’re telling someone about Bitcoin you should avoid mentioning the concept, except to explain how, in this respect, Bitcoin doesn’t operate like other payment systems or sender/receiver systems they might know.

Tools like block explorers and wallets should either refrain from showing inferences altogether, or should show them only in an advanced mode — with the right name and a prominent list of reasons why they’re of academic interest only.
Perhaps if folks make enough noise, they will.

Uptake of the [https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki payment protocol] and other such measures that deliver refund addresses in the same communication as payment requests/payments should be encouraged.
These hide such dirty temptations from the user.

Privacy-protecting wallets should be preferred, since those avoid address re-use anyway.

<hr/>

''2014-05-30: incorporate feedback from Andrew Poelstra and Burrito. 2014-05-31: incorporate feedback from Greg Maxwell, btiefert, dsnrk. 2014-06-01: incorporate feedback from Luke-Jr.''

''Original source: [https://iwilcox.me.uk/2014/no-from-address https://iwilcox.me.uk/2014/no-from-address] ([https://archive.is/9bGY0 archive link])''

Bech32

2020-10-13T07:20:19Z

Dergigi: Remove the "as of 2017" sentence, which mentioned that it is not recommended yet. I would say it is recommended as now (October 2020).

'''Bech32''' is a [[segwit]] [[address]] format specified by [[BIP 0173]]. This address format is also known as "bc1 addresses". Bech32 is more efficient with block space. As of October 2020, the Bech32 address format is supported in many popular wallets and is the preferred address scheme.

See the page [[Bech32 adoption]] to track adoption.

=== Examples ===

Examples of the address format being used on mainnet are the TXIDs <code>4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c</code> and <code>514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b</code>. And addresses <code>bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq</code> and <code>bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9</code>.

== See Also ==

* Talk by Pieter Wuille the new bech32 address format (March 2017) https://www.reddit.com/r/Bitcoin/comments/62fydd/pieter_wuille_lecture_on_new_bech32_address_format/
* Comment by maaku7 explaining how bech32 addresses improve the security of (for example) [[multisignature]] https://www.reddit.com/r/Bitcoin/comments/74tonn/bech32_native_segwit_address_already_used_on_the/dqlogru/

Invoice address

2020-09-21T13:35:55Z

Dergigi: [Trivial] Add missing "to"

A '''Bitcoin address''', or simply '''address''', is an identifier of 26-35 alphanumeric characters, beginning with the number <code>1</code>, <code>3</code> or <code>bc1</code> that represents a possible destination for a bitcoin payment.
Addresses can be generated at no cost by any user of Bitcoin.
For example, using [[Bitcoin Core]], one can click "New Address" and be assigned an address.
It is also possible to get a Bitcoin address using an account at an exchange or online wallet service.

There are currently three [[List_of_address_prefixes|address formats]] in use:
# [[Transaction#Pay-to-PubkeyHash|P2PKH]] which begin with the number <code>1</code>, eg: <code>1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2</code>.
# [[Pay_to_script_hash|P2SH]] type starting with the number <code>3</code>, eg: <code>3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy</code>.
# [[Bech32]] type starting with <code>bc1</code>, eg: <code>bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq</code>.

==A Bitcoin address is a single-use token==
Like e-mail addresses, you can send bitcoins to a person by sending bitcoins to one of their addresses.
However, ''unlike'' e-mail addresses, people have many different Bitcoin addresses and [[Address reuse|for privacy and security reasons]] a unique address should be used for each transaction.
Most Bitcoin software and websites will help with this by generating a brand new address each time you create an invoice or payment request.

A naive way to accept bitcoin as a merchant is to tell your customers to send money to a single address. However this does not work because Bitcoin transactions are public on the [[block chain]], so if a customer Alice sends you bitcoins then a malicious agent Bob could see that same transaction and send you an email claiming that he paid. You would have no way of knowing whether it was Alice or Bob who send coins to your address. This is why each customer must be given a brand new address.

==Addresses can be created offline==
Creating addresses can be done without an Internet connection and does not require any contact or registration with the Bitcoin network.
It is possible to create large batches of addresses offline using freely available software tools.
Generating batches of addresses is useful in several scenarios, such as e-commerce websites where a unique pre-generated address is dispensed to each customer who chooses a "pay with Bitcoin" option.
Newer [[Deterministic wallet | "HD wallets"]] can generate a "master public key" token which can be used to allow untrusted systems (such as webservers) to generate an unlimited number of addresses without the ability to spend the bitcoins received.

==Addresses are often case sensitive and exact==
Old-style Bitcoin addresses are case-sensitive. Bitcoin addresses should be copied and pasted using the computer's clipboard wherever possible. If you hand-key a Bitcoin address, and each character is not transcribed exactly - including capitalization - the incorrect address will most likely be rejected by the Bitcoin software. You will have to check your entry and try again.

The probability that a mistyped address is accepted as being valid is 1 in 2<sup>32</sup>, that is, approximately 1 in 4.29 billion.

New-style [[bech32]] addresses are case insensitive.

==Proving you receive with an address==
Most Bitcoin wallets have a function to "sign" a message, proving the entity receiving funds with an address has agreed to the message.
This can be used to, for example, finalise a contract in a cryptographically provable way prior to making payment for it.

Some services will also piggy-back on this capability by dedicating a specific address for authentication only, in which case the address should never be used for actual Bitcoin transactions.
When you login to or use their service, you will provide a signature proving you are the same person with the pre-negotiated address.

It is important to note that these signatures only prove one receives with an address.
Since Bitcoin transactions do not have a "from" address, you cannot prove you are the ''sender'' of funds.

Current standards for message signatures are only compatible with "version zero" bitcoin addresses (that begin with the number 1).

==Address validation==
If you would like to validate a Bitcoin address in an application, it is advisable to use a method from [https://bitcointalk.org/index.php?topic=1026.0 this thread] rather than to just check for string length, allowed characters, or that the address starts with a 1 or 3. Validation may also be done using open source code available in [http://rosettacode.org/wiki/Bitcoin/address_validation various languages] or with an [http://lenschulwitz.com/base58 online validating tool].

==[[Multisignature|Multi-signature]] addresses==
Addresses can be created that require a combination of multiple private keys.
Since these take advantage of newer features, they begin with the newer prefix of 3 instead of the older 1.
These can be thought of as the equivalent of writing a check to two parties - "pay to the order of somebody AND somebody else" - where both parties must endorse the check in order to receive the funds.

The actual requirement (number of private keys needed, their corresponding public keys, etc.) that must be satisfied to spend the funds is decided in advance by the person generating this type of address, and once an address is created, the requirement cannot be changed without generating a new address.

==What's in an address==
Most Bitcoin addresses are 34 characters.
They consist of random digits and uppercase and lowercase letters, with the exception that the uppercase letter "O", uppercase letter "I", lowercase letter "l", and the number "0" are never used to prevent visual ambiguity.

Some Bitcoin addresses can be shorter than 34 characters (as few as 26) and still be valid.
A significant percentage of Bitcoin addresses are only 33 characters, and some addresses may be even shorter.
Every Bitcoin address stands for a number.
These shorter addresses are valid simply because they stand for numbers that happen to start with zeroes, and when the zeroes are omitted, the encoded address gets shorter.

Several of the characters inside a Bitcoin address are used as a checksum so that typographical errors can be automatically found and rejected.
The checksum also allows Bitcoin software to confirm that a 33-character (or shorter) address is in fact valid and isn't simply an address with a missing character.

==Testnet==
Addresses on the Bitcoin Testnet are generated with a different address version, which results in a different prefix.
See [[List of address prefixes]] and [[Testnet]] for more details.

==Misconceptions==
===Address reuse===

Addresses are not intended to be used more than once, and doing so has numerous problems associated.
See the dedicated article on [[address reuse]] for more details.

===Address balances===

Addresses are not wallets nor accounts, and do not carry balances.
They only receive funds, and you do not send "from" an address at any time.
Various confusing services and software display ''bitcoins received with an address, minus bitcoins sent in random unrelated transactions'' as an "address balance", but this number is not meaningful: it does not imply the recipient of the bitcoins sent to the address has spent them, nor that they still have the bitcoins received.

An example of bitcoin loss resulting from this misunderstanding is when people believed their address contained 3btc. They spent 0.5btc and believed the address now contained 2.5btc when actually it contained zero. The remaining 2.5btc was transferred to a change address which was not backed up and therefore lost. This has happened on a few occasions to users of [[Paper wallets]].

==="From" addresses===
Bitcoin transactions do not have any kind of origin-, source- or "from" address. See the dedicated article on "[[From address|from address]]" for more details.

==Address map==
[[File:Address map.jpg|700px]]

==See Also==
* [[Technical background of Bitcoin addresses]]
* [[List of address prefixes]]
* [[Exit Address]]

== References ==
<references/>

[[Category:Vocabulary]]

[[es:Dirección]]
[[de:Adresse]]