How to acquire BTC

One simple way to acquire Bitcoin is to open a public account, connect it with your bank account and move some money. However, public exchanged that hold your Bitcoin seem to be risky. Setting up a peer node is still the recommended way to get into Bitcoin trading.

The downside of setting up a public node is it uses electricity and internet bandwidth. For a small investment it might not be worth it, unless you are always running your computer and have unlimited bandwith.

Summary

Get yourself a sofware wallet. That will give you the bitcoin address that you need to acquire BTC.
Move to a cold storage wallet for safe keeping.
Purchase a hardware wallet when you holdings get large. (Ledger nano $200)

Online purchase - non custodial account

https://www.bullbitcoin.com/

non custodial Offers transfer from bank using etransfer no fee for loading - though there is hidden fee on purchase price no fee for moving to storage fees seem to be around payment - does offer lightening network

what about KYC?

OTC purchases

Bitcoin units can be purchased from other people or companies by means of a bilateral transaction. These purchases are called over-the-counter (OTC) transactions and can be settled in a face-to-face meeting or via any type of communication channel. Naturally, the appropriate precautionary measures have to be taken in both cases.

It is crucial that you:

. check the current exchange rate. Moreover, insist that the transaction

. includes an acceptable transaction fee and

. wait for at least one confirmation to reduce the risk of a double spend.

. For larger amounts, it is advisable to wait for several confirmations. Three to six confirmations are generally considered sufficient to ensure that the transaction is irreversible. This takes on average between thirty and sixty minutes. For small amounts, one confirmation is perfectly fine.

For purchases that do not involve a face-to-face meeting, it is strongly recommended to use a trusted platform. A trusted platform offers a reputation system and fulfills a fiduciary role.

Face-to-face meetings can be arranged for cash payments, or transactions can be carried out using wire transfers. In the case of a wire transfer, one should take account of the fact that some commercial banks will block payments with a reference mentioning “Bitcoin” or “crypto” for no apparent reason. This problem is so deep-rooted that some banks even refuse to offer accounts to officially regulated Bitcoin companies.

Normally, you will be able to purchase smaller amounts of Bitcoin units without proving your identity. However, for larger amounts, the seller is obliged to satisfy the so-called know-your-customer (KYC) regulation, which requires, among other things, that the customer must be identified.

Caution: Never Purchase a Private Key

Never purchase a private key from another person. The person may have copies of this key and would therefore be in the position to control the associated Bitcoin units. A legitimate OTC purchase must therefore always be carried out using a Bitcoin blockchain transaction that credits the Bitcoin units to one of your Bitcoin addresses.

To ensure that you have exclusive control over the corresponding private key, you must personally generate the key/address pair. Private keys that are communicated or transferred to you via other people are unsafe.

If a person wishes to offer you help when installing a wallet or your client, you must prevent this person from seeing your key or your mnemonic seed. The disclosure of this information can lead to the total loss of your Bitcoin units.

Centralized Exchange Platforms

The most common way to obtain Bitcoin units is to buy them at one of the many centralized Bitcoin exchanges. A user can simply open an account and then transfer fiat currency to it. The account holder can then use these funds to buy Bitcoin units or one of the many other cryptoassets. The pricing on large exchanges is competitive with relatively small bid-ask spreads. Most exchanges provide cryptocurrency order books and relatively sophisticated financial tools that make the trading process transparent.

However, it is still recommended to compare the various fee structures and to do your research on the business practices and reputation of a particular exchange. In particular, when selecting a centralized exchange, one should also consider the trading volumes, the offered services, and security.

Most importantly, users of centralized exchanges must be aware that they do not control the private keys to their assets. This can lead to substantial security issues. It is therefore recommended that the user transfers his cryptoassets as quickly as possible to one of the addresses for which he is in exclusive possession of the private key.

Some centralized exchanges have a registration process that is fully compliant and comparable to the KYC requirements for opening an account with commercial banks. These requirements include domicile and passport checks as well as the respective anti-money laundering rules. A few cryptocurrency exchanges implement none of these requirements and operate in a legal vacuum. We strongly recommend not to use exchanges that are both centralized and nonregulated.

Before you can trade, you must deposit either cryptoassets or government-issued fiat currency to the exchange. For a Bitcoin transaction, the exchange provides you with a Bitcoin address. Currencies can generally be transferred to the exchange’s bank account and normally will be credited within a few days.

A faster alternative is to use a credit card payment. Since credit card payments can be reversed, centralized exchanges who offer credit card payments face a high level of risk. Consequently, only exchanges that verify their customers’ identities offer this option. Moreover, a surcharge is imposed to cover the credit card fees and chargeback risk.

https://www.savvynewcanadians.com/coinsmart-referral-code/

Bitcoin ATM

Bitcoin ATMs are appearing to be similar to standard banking ATMs. With regard to the spectrum of functions that they provide, however, these machines have little in common with traditional cash dispensers. They allow users to buy Bitcoin units in exchange for fiat currency – and some models function as two-way currency converters.

The counterparty is normally the ATM’s operating company. In order to buy Bitcoin units, the customer feeds the desired banknote into the Bitcoin ATM. The Bitcoin units are then credited to a Bitcoin address that the customer has previously generated. To execute the Bitcoin payment, the customer must present a QR code containing the beneficiary Bitcoin address in front of the machine’s integrated camera. Fees are typically 10% which is pretty high.

Some machines generate new addresses and issue a paper receipt on which the public address and the corresponding private key are printed. This method again poses the threat that the private key might remain in the machine’s memory and thus can be copied by the provider or a malicious third party.

What is a Crypto Wallet?

Cryptocurrency wallets store users’ public and private keys while providing an easy-to-use interface to manage crypto balances. They also support cryptocurrency transfers through the blockchain. Some wallets even allow users to perform certain actions with their crypto assets such as buying and selling or interacting with decentralised applications (dapps).

It is important to remember that cryptocurrency transactions do not represent a ‘sending’ of crypto tokens from your mobile phone to someone else’s mobile phone. When you are sending tokens, you are actually using your private key to sign the transaction and broadcast it to the blockchain network. The network will then include your transaction to reflect the updated balance in your address and the recipient’s address.

So, the term ‘wallet’ is actually somewhat of a misnomer as crypto wallets don’t really store cryptocurrency in the same way physical wallets hold cash. Instead, they read the public ledger to show you the balances in your addresses and also hold the private keys that enable you to make transactions.

Your cryptocurrency is only as safe as the method you use to store it. While you can technically store crypto directly on the exchange, it is not advisable to do so unless in small amounts or if you plan to trade them frequently.

For larger amounts, it’s recommended that you withdraw (perform a transfer to another address that you also hold) the majority to a crypto wallet, whether that be a hot wallet or a cold one. This way, you retain ownership of your private keys and have full power and control over your own finances.

Bitcoin Storage

As we shall see below, private keys can be stored in many ways. Irrespective of the method of safekeeping, there are two important principles to follow. First, private keys must be stored in such a way that they will not get lost. The loss of a private key means the irrecoverable loss of the associated Bitcoin units. Second, no other person should ever be given access to your private key because, if a person has possession of a private key, he or she also gains unrestricted control over the assets on the corresponding address.

All storage options have specific advantages and disadvantages. In particular, there is an unavoidable trade-off between convenience and security. Wallets of the category hot storage are directly linked to the internet and have the capacity to initiate transactions. Wallets of the category cold storage consist of wallets that do not have a network connection.

Selecting a Private Key

If you wish to store your Bitcoin units independently, you will need at least one Bitcoin address and the corresponding private key. A basic functionality of practically all software wallets is the generation of new addresses. The wallet generates the private key in the background and, in most cases, displays a mnemonic seed that you can use to restore your Bitcoin units. This convenient way of generating a key is adequate for most applications.

As an alternative, there are websites that can be used to generate private keys. Extreme caution is required when using such services. Websites that have fraudulent motives will generate a private key and keep a copy of it to access your funds later on. It is important that you only use websites whose codebase is disclosed so that you can ensure they use a cryptographically secure random number generator. Further, the process employed for selecting the private key must only be performed on your personal computer. Ideally, you should download the whole website and open it on a computer that has no internet connection. In this way, you will prevent any third party from accessing your data.

Hot Storage

When private keys are stored on devices that are directly or indirectly connected to the internet, the term hot storage is used. This type of storage offers convenience of access, but wallets of this kind are more vulnerable to attacks than the cold storage alternatives, which will be dealt with in section.

Software Wallets

Software wallets are usually very user-friendly and, when connected to the internet, can be used not only for storage purposes but also to transfer Bitcoin units. We distinguish between desktop wallets for computers and mobile wallets for mobile devices such as smart phones or tablets.

Owing to the network connection, software wallets are vulnerable to a variety of attacks. Most smartphones and tablets isolate individual apps and thereby provide better protection against malware. In contrast, desktop computers are vulnerable in this respect because applications are usually deeply anchored within the system and interact with each other without any significant restrictions; as well, there are substantial differences between the various operating systems.

It is always advisable to encrypt the private keys in the software wallet. Almost all popular software wallets offer this option. However, even encryption only provides partial protection. If a computer has been infected with a key logger—that is, a program that reads and registers all keystrokes—the wallet’s encryption will be ineffective.

In addition, there is a considerable risk of losing the private keys. This might occur, for example, as a result of hard drive failure. Backups of the key (mnemonic phrase) can partially counteract this problem, but they should never be stored in digital form.

Software wallets are generally unsuitable for the long-term storage of larger Bitcoin holdings. They should be used instead as a kind of everyday wallet to access smaller Bitcoin holdings quickly and conveniently. A software wallet can be operated either as a full node client, as a simplified payment verification (SPV) client, or on the basis of a centralized subnetwork.

Full nodes are able to autonomously validate transactions but require a continuous internet connection. In addition, it initially takes a few days on average for the complete blockchain to be downloaded and processed. SPV clients and centralized subnetworks have substantially shorter loading times and fewer system requirements but have to rely on third-party information to validate transactions. For many applications, SPV clients are sufficient. Wallets based in centralized subnetworks should be used with caution. Many standard software wallets leave their users in full control of their private keys. This is a welcome development, but it also means that you alone, without exception, are responsible for backups and the safekeeping of your Bitcoin units. An alternative approach consists in splitting the control so that outbound transactions have to be signed by both the user and the wallet operator’s centralized service. These services are usually based on multisig, where the second signature is triggered by the two-factor authentication (2FA) of the user. Normally, systems of this kind provide an alternative method which would allow you to continue using your assets if the service provider were to disappear.

Storage on Centralized Exchanges

Bitcoin units can be stored on centralized exchanges. This is usually very convenient. Nevertheless, we must strongly urge you not to use this type of service for storing your Bitcoin units. The major problem with centralized exchanges is the fact that the user is not in possession of the private keys and therefore has no control over his or her Bitcoin units. If the centralized exchange is unable to or does not wish to sign a transaction, the user cannot regain control over his or her funds. Further, centralized exchanges present a lucrative target for hacker attacks.

Cold Storage

Cold storage wallets consist of wallets that do not have a network connection. The storage of your private keys in strict isolation from the internet prevents hacker attacks and is the best option for long-term safekeeping. The objective of cold storage is to ensure the safety of your Bitcoin units. This comes at the cost of convenience. To initiate a transaction, either a pre-signed transaction or the private keys need to be imported into a hot storage wallet. In the following, we will discuss the main cold storage solutions, such as hardware wallets, paper wallets, and brain wallets.

Hardware Wallet

Hardware wallets are devices that are exclusively intended for storing private keys. For simple hardware wallets without additional functionalities, a secure digital (SD) card, an external hard drive, or a USB stick is sufficient. Private keys can be stored on these media and kept somewhere away from the computer. If you want to store your Bitcoin units in this way for a longer period, it is worthwhile finding out how long the respective medium’s expected life-span is. It is, in any case, advisable to keep copies on another medium.

So-called offline wallets are computers without internet access, which are set up exclusively as a software wallet. The great advantage of these offline wallets, compared with simple storage media, is that you can independently generate new private keys and addresses. In addition, transactions can be generated and signed offline. The signed transaction then only has to be exported to an online wallet to be propagated. The signed transaction contains no information that would allow inferences to be drawn about the private key. It corresponds exactly to the transaction message that will be propagated in the network anyway.

When Bitcoin became more popular, specialized hardware wallets emerged. These devices combine high security standards with simple and convenient handling. The devices can be connected to a computer to trigger the transactions. They only allow the exchange of transaction data but ensure that private keys always remain in the secure module of the hardware wallet.

When you buy such a device, it is crucial to ensure that you order it directly from the manufacturer or from a trusted retailer and that you receive it in its original packaging— sealed, that is. If you buy a used hardware wallet, it is advisable to reset the device prior to first use and to reinstall the official firmware from the manufacturer’s website.

Paper Wallet

Paper wallets are paper-based notes that contain private keys. Alternatively, paper notes can also contain the mnemonic seed that can be used to derive several private keys. Paper wallets offer such advantages that they are easy to store and are the most economical cold storage option.

The notes can be either written by hand or printed. In both cases, it is advisable to write the private key several times on the same paper so that, in the case of partial damage, the complete key can still be restored. Often, the corresponding QR codes are also printed in addition to the private key.

Storing private keys in a physical form protects them from hacker attacks. At the same time, you carry the responsibility for ensuring that no one can view your private keys. If a third party managed to gain access to your paper wallet, this person would obtain control over all your assets. In particular, it is advisable to print only encrypted private keys and store the password in another location. In addition, you should ensure that your paper wallet does not get lost or destroyed. Elemental forces such as fire or water could destroy your note and cause you to lose all your Bitcoin units.

Protecting Private Keys from Loss

Time and again, warnings appear in the press about hacker attacks and Bitcoin thieves. However, most users who lose their Bitcoin units do so through the loss of the private key. One possible way to solve this problem would be, for example, to generate several copies of the private key. The same private key could then be kept in several places. But as the number of copies increase, so do the number of potential attack vectors; this creates a certain trade-off between availability and security against third-party access.

A sophisticated approach for creating availability without compromising security is to split the key. For example, consider a setting where two out of three paper wallets are required to access the assets. If one note is lost, the assets could still be restored without a problem by using the other two notes. At the same time, if a third party has gained physical access to one of the three paper wallets, the attacker will still not be able to gain control over the assets.

Key systems of this kind can be structured by using multisig or a procedure called Shamir’s Secret Sharing. The difference between these two procedures is only technical.

With multisig, several keys exist, a subset of which are necessary to satisfy the unlocking condition. In contrast, Shamir’s Secret Sharing uses traditional Bitcoin addresses with a single private key but splits this private key into several fragments. Here again, at least two fragments are necessary to derive the private key.

Brain Wallet

Private keys do not need to be written down anywhere. It may be sufficient to memorize the private key to ensure that you will remember it in the future. This type of safekeeping is called a brain wallet—a wallet that exists in your memory.

Only a few people will have the capacity to remember a 256-digit binary number. A much more practical procedure is to choose any combination of words and use a hash function (for example, SHA256) to generate a private key. This deterministic procedure is replicable, so you only have to remember the original combination of words. It is crucial that the sentence or the combination of words is produced randomly. Sentences from publicly accessible media, such as books, films, or songs, are a bad choice and will very likely lead to the loss of the Bitcoin units. Alternatively, you can also memorize the mnemonic seed to derive your key.

A further aspect that should be considered in connection with brain wallets is estate planning. If you want your Bitcoin units to pass to someone else in the event of your death, you should plan accordingly. Obviously, the use of brain wallets is highly problematic in this case.

Paying with Bitcoin Units

Technically, it is easy to pay with Bitcoin. However, because the number of shops that accept Bitcoin units is still limited, you have to do some research and adapt your shopping to the limited options available. There are curated lists that record the available points of acceptance.

While real-world locations are limited, you can easily find a large variety of online shops that accept Bitcoin for many goods and services. An interesting starting point is OpenBazaar, a decentralized e-commerce platform that uses Bitcoin units as its main currency.

The precise sequence of the payment process depends on the type of wallet that has been installed. The general process is always the same.

After you have selected your goods and/or services, inform the retailer that you wish to start the payment process

(1). The retailer then gives you a request for payment (2). This contains a Bitcoin address and a description or invoice number as well as the amount that you owe in Bitcoin units. The bill can be sent to your wallet either via Bluetooth, near-field communication (NFC), or a similar technology, or it can be alternatively displayed in the form of a QR code for scanning. In any case, your wallet will show the information on-screen and ask you for your confirmation (3). When you authorize the payment (4), a transaction message is generated, signed, and broadcasted to the Bitcoin network (5). As soon as the retailer receives the transaction message, he will send you an acknowledgement of your payment (6). The time that it takes until you receive the final confirmation (7). will depend on the network connection and on the retailer’s specific acceptance criteria and the transaction fee. Usually, a confirmation takes between three seconds and one hour.

As a client, you do not have to do anything other than scan a QR code and confirm the payment request. All the other processes are performed automatically. The technical details from the previous sections are essential for understanding specific features of the Bitcoin system, but an end user does not need to know these details.

Acceptance of Bitcoin Payments

Accepting Bitcoin payments gives retailers numerous advantages. First, the transaction fees are low in comparison with credit card payments—especially when using second layer solutions like the Lightning Network. Second, customers cannot reverse their payments once they have received the goods or services. Third, acceptance of Bitcoin payments provides an opportunity to attract a new segment of customers.

There are various methods for accepting Bitcoin payments, and these can be split roughly into two categories: acceptance via a self-managed system or via the intermediation of a payment service provider.

Self-Managed Systems

In analogy to cash, Bitcoin units can be accepted without the need for an intermediary. You can simply generate a Bitcoin address and forward it with a request for payment to your customer.

Simple requests for payment are valid as soon as they contain (at the very least) the Bitcoin address. The payment request is usually formatted as follows: bitcoin:<Bitcoin_Adresse>?. Many wallets also recognize QR codes without the Bitcoin prefix.

The standardization according to proposal BIP0021 offers the possibility to specify further parameters such as the payment amount, the retailer’s name, or the payment purpose description. The encoding is done using predefined meta-tags where the Bitcoin address is followed by a “?”, and further parameters are separated from each other using “&”.

The following example of a payment request references the Bitcoin address that was generated on the basis of the private key. The invoiced amount was set at 0.0005 Bitcoin units. In addition, the transaction message contains the owner information “Book” and the payment purpose description “Test payment.”

bitcoin:1E8jc2eRXmjF2FKebTZwAsxwaRWeDvEwDj?amount=0.0005&label=Book %20Address&message=Test%20Payment

The information can also be presented as a QR code so that the customer only has to scan the code.

Try to scan this code using your wallet, and you will see how simple it is to pay with Bitcoin units.

If you wish to implement the payment request yourself, you should follow BIP0071 or BIP0072.

Payment requests are usually straightforward to manage, and there are no additional fees. This method is particularly attractive for smaller companies. However, further business requirements, such as accounting, online shop implementations, or point-of-sale systems, can make independent management considerably more complex. In addition, it is advisable to thoroughly evaluate the security risks. You should, for example, wait for at least one confirmation (on average, ten minutes) before you consider a payment to be valid. With larger payments, you should wait for several confirmations. So-called block explorers are good tools for evaluating the safety of a transaction. In particular, many block explorers offer early warning systems that are able to quickly identify any double spending attempts made by your customers.

A further point that you should consider is the volatility of the Bitcoin price. In addition, take care to ensure that you generate a new, unique payment address for each of your customers. Although it is possible to have all your customers’ payments credited to the same Bitcoin address, this has two major disadvantages. First, it will become increasingly difficult to distinguish among your customers’ transactions.

This is true in particular if you deal with many similar transactions. Analogous to the reference numbers on payment slips, Bitcoin addresses can be assigned to individual customers. Second, you must be aware of the fact that the Bitcoin transactions, although not identifiable by name, can be publicly observed. If you always use the same Bitcoin address, people who know this address (i.e., all your customers) will be able to monitor all your incoming payments.

Self-managed systems are primarily suitable for small companies that do not expect to have large sales volumes and are looking for the most economical system. For such cases, a simple wallet without any additional functions will be sufficient. However, if you expect to receive many Bitcoin payments, it may be worthwhile engaging a payment service provider.

The Use of xpub

If you want to store your private keys in cold storage but at the same time want to be able to generate new Bitcoin addresses directly at a point-of-sale terminal or on the server of the online shop, the process offered by BIP0044 is an option. This proposal describes the standard that is used to derive hierarchical deterministic wallets and to generate new addresses without the corresponding private key.

The hardware wallet Trezor or the software wallet Armory are both very user-friendly and facilitate the simple export of the xpub data file that is necessary for a user to independently derive new Bitcoin addresses. In addition, both wallets have integrated functions that enable addresses to be generated in the absence of the private key.

Payment Service Providers

Payment service providers offer a large number of tools that substantially simplify the implementation of Bitcoin payments at point-of-sale terminals and in online shops. These tools usually include all features needed throughout the payment life cycle—from the issue of the payment request to its receipt and temporary custody of the Bitcoin units.

In addition, the retailer has the possibility to immediately convert a Bitcoin payment into the local currency and thereby protect himself against Bitcoin’s price volatility.

Further, many payment service providers will assume liability for any malfunctions.

If, for example, a double spending attack is successful after the payment service provider has accepted the payment, the retailer will be reimbursed in most cases.

Even though the fees are usually much lower than for credit cards, these services are not free. It is worthwhile to compare the offers, as the fees may depend on the scope of the services desired.

references

https://bitcoin.org/en/full-node#initial-block-downloadibd

https://www.weusecoins.com/full-bitcoin-node-on-a-raspberry-pi-3-with-or-without-a-pidrive/

https://bitnodes.io runs a service that enables the network to scan for active nodes.

https://www.forbes.com/advisor/investing/how-to-buy-bitcoin/

https://www.forbes.com/advisor/investing/coinbase-review/

https://www.coinbase.com/

privacy with bitcoin get btc from non kyc p2p exchange conjoin use TOR lightning network Schnorr signatures + taproot

creating an exchange account

Had to provide my mailing address and telephone. They seem to want verification which involves scanning government id.

coinbase

kraken

uphold

address format

Introduction to Bitcoin address formats

by Matthew Baas

https://rf5.github.io/2022/02/14/btc-address-intro.html

Update 2022-03-20: changed name of wrapped segwit to script hash addresses (BIP-13. This is done to better indicate that this address format can encode the hash of any arbitrary script, not just wrapping segregated witness.

An abridged taxonomy of the major bitcoin address formats and versions.

TL;DR: bitcoin (BTC) has been through several versions, and will doubtless go through more in the future. Different major bitcoin versions have different address formats. This post aims to document the common BTC address types encountered in common use as of Feb 2022, and is targeted at those who have a minimal understanding of bitcoin.

Bitcoin overview

Before the taxonomy, a brief reminder of the key parts of bitcoin are appropriate.

The Bitcoin (BTC or just btc) blockchain is fundamentally a record of transactions between btc addresses. By looking at all transactions involving a given BTC address, we can determine the balance of that address. This means that an amount of bitcoin is owned by a BTC address on the BTC blockchain.

However, a single ‘wallet’ in common software wallets these days can correspond to many different addresses. The total value of that wallet is the sum of balances of all the addresses contained in that wallet (just like how in real life a single wallet can have multiple cards in it).

Changes to bitcoin: BIPs

The original version of the bitcoin protocol and software released over a decade ago has undergone significant upgrades and bug fixes. Upgrades, or improvements to bitcoin are formally proposed as Bitcoin Improvement Proposals (BIPs). They have a formal format, a formal lifecycle, and are typically reviewed many times by multiple people before miners consider adopting the BIP.

For example, BIP-32 is an upgrade for introducing a feature called Hierarchical Deterministic Wallets. Some BIPs are minor bugfixes and usability improvements, while others are fairly large updates which introduce swathes of new functionality. Each BIP is only ‘active’ (i.e. in effect on the main BTC blockchain) if the majority of miners agree to run software that implements that BIP. As of Jan 2022 there are 43 BIPs which are in effect – the ‘final’ state of an accepted BIP.

Unique to BTC: all BIPs should be backwards compatible. That is to say, the very first bitcoins should still be spendable using the original methods, and the main functionality that worked in previous versions must still work in the latest version.

Other cryptocurrencies often do not have this feature, where failing to update wallet software to the latest version of the cryptocurrency’s protocol will render your funds unusable. Such a design guideline has its benefits and drawbacks: you can always be confident that you can spend your funds, even if it is your own hand-written wallet software from a decade ago. However, this comes at the cost of major version bloat, where all future BIPs and wallet software code must have special hooks and workarounds to make sure both the latest and all previous versions work as intended.

The nature of BTC improvements

The major BIPs have changed the BTC blockchain so that the blockchain still contains a list of transactions, however nowadays the information that can be included in a transaction has expanded substantially.

Transactions can have many receiving and sending addresses within them along with other metadata. They can also require approval from owners of multiple BTC addresses, and various other functionality – e.g. only being spendable after a certain amount of time.

However, since all BIPs are backwards compatible, new addresses created using software implementing newer BIPs have different forms to let BTC nodes and miners know that the address and its format corresponds to the newer BTC protocol version. This is necessary so that old addresses are not handled as if they support newer features – part of ensuring backwards compatibility. 2. BTC address taxonomy

Note: the example addresses used below are just examples I grabbed of the internet, not mine and I don’t know where they come from. DO NOT SEND ANY FUNDS TO THESE EXAMPLE ADDRESSES.

Here is a list of the types of addresses you will commonly see while using bitcoin: Address version Example Description Payment type Legacy 15e15hWo6CShMgbAfo8c2Ykj4C6BLq6Not Oldest bitcoin version. Always start with a 1. P2PKH Script hash addresses (BIP-13) 35PBEaofpUeH8VnnNSorM1QZsadrZoQp4N 2nd major address version. Always start with a 3. P2SH Native Segwit bc1q42lja79elem0anu8q8s3h2n687re9jax556pcc 3rd major address version. Always start with bc1q. Current standard. P2WPKH Lightning Network lnbc2500u1pvjluezsp5zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zyg3zygspp5qqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqqqsyqcyq5rqwzqfqypqdq5xysxxatsyp3k7enxv4jsxqzpu9qrsgquk0rl77nj30yxdy8j9vdx85fkpmdla2087ne0xh8nhedh8w27kyke0lp53ut353s06fv3qfegext0eh0ymjpf39tuven09sam30g4vgpfna3rh BTC’s 2nd layer off-chain payment protocol. Always start with lnbc. LN Taproot (segwit v1) bc1pmzfrwwndsqmk5yh69yjr5lfgfg4ev8c0tsc06e 4th major address version. Always start with bc1p. Upcoming standard. P2TR

I will now give a brief overview of the different types of wallets associated with each major address version, except for lightning network, since that is not on the main btc blockchain and I don’t know enough about it. Also, what follows is my current best understanding of each address technology, and may not be fully correct from here onwards. For the best information on them, consult the source BIPs on the bitcoin github, and the bitcoin node software.

Legacy

The legacy address is made from a pair of (private key, public key), and the address is simply a hash of the public key using the private key with some cryptography. The result of this hash is something like 15e15hWo6CShMgbAfo8c2Ykj4C6BLq6Not

This is why legacy payments are also referred to as Pay-to-Public-Key-Hash (P2PKH, as you are literally paying to a hash of the public key of the target wallet.

You can spend from the address so long as you can prove (using cryptography) that you have the private key corresponding to the address (hashed public key). 2.2 Script hash addresses (aka wrapped segwit)

Script hash addresses (defined in BIP-13), sometimes known as wrapped segwit addresses, are made, very roughly speaking, from a tuple (private key, public key, script). The address is the hash of a script that involves certain spending conditions.

Such spending conditions can be simple: e.g. showing the private key associated with public key allows you to spend this bitcoin’

Or they can be complex: e.g. showing the private key associated with this public key allows you to spend this bitcoin after 27 days if you also reveal a predetermined secret number.

The script of these conditions is then hashed using the private key to obtain the address. e.g. 35PBEaofpUeH8VnnNSorM1QZsadrZoQp4N . And this is why script hash addresses (aka wrapped segwit) is known as Pay-to-Script-Hash (P2SH). To spend from an address you must have the private key, script, and satisfy the requirements of the script. 2.3 Native Segwit

Wallets in this version are defined, again very roughly speaking, by a pair (seed phrase, pass phrase, tree structure, script). To get an address, we essentially compute a hash based on the seed phrase, pass phrase and a particular path within the tree structure, providing us with a hashed public key to send BTC to. When transactions are broadcast to the blockchain, a hash of the script is included in a separate part of the transaction called the ‘witness’. Spending from any segwit or newer addresses requires satisfying the script requirements specified by the witness.

Hence, we call it Pay-to-Witness-Public-Key-Hash (P2WPKH) because the address is a hash of the public key and witness pair. If a script is used (e.g. for multi-sig wallets) then it is also known as Pay-to-Witness-Script-Hash (P2WSH). The seed and pass phrase in the tuple above can also instead be specified by an extended public and extended private key, and internally the seed and pass phrase are used to generate the extended public and private keys in wallet software.

Example:

Seed phrase: “wild quiz always market robust … twist divert margin route”
Pass phrase: “” (blank is default)
Path within tree structure: “m/0/0/2’” ; the path is often in format of “m/{account}’/{change}’/{idx}’”, but can be somewhat arbitrary. Each directory name is an integer (i.e account can be ‘0124’, but not ‘abcd’)

Then the derived address will be some series of cryptographic functions that takes these items as input, yielding an address like bc1q42lja79elem0anu8q8s3h2n687re9jax556pcc 2.4 Taproot

With taproot, a now released but not yet widely used version of the BTC protocol, addresses can be formulated in significantly more ways. Concretely, like native segwit, a wallet can consists of a seed phrase and a pass phrase. These are used to generate an extended public and private key, which are used to derive the addresses at arbitrary paths in a hierarchically deterministic wallet.

However, now with taproot, there is one more thing that can be added to generate an address – taptweaks. A taptweak – fundamentally a natural number – is added at an intermediary step to the native segwit tuple to yield a new public key and thus address. Arbitrary bitcoin scripts can then be encoded into a taptweak and thus into an address. This, combined with the script and metadata added to the ‘witness’ part of the address in any transaction, provides the necessary functionality for various new taproot features.

These taptweaks have some special mathematical properties that allow for various interesting functionality, such as having a binary tree of different scripts committed to the same address, allowing one to spend from that address if they can satisfy a script at some path in the tree. Taproot also introduced musig, which allows for multi-sig wallets to be constructed with what is essentially a taptweak, thereby making multi-sig wallets indistinguishable from regular wallets on the blockchain. Example

Let us look at a single example of a transaction I found from browsing blockchain.com. Below is an example of an actual address clearly used by some whale or exchange:

blockchain address example

We can see that the address – from its format – is a native segwit (segwit v0) address using a non-trivial script in the witness (P2WSH). Recalling that BTC is fundamentally owned by an address and not a wallet, we can also observe the whale nature of the address: tallying all its transactions yields the final balance belonging to this address at over 2930 BTC!

Next lets look at a transaction it is in: blockchain address example

In this example transaction, the segwit address above is sending funds to six output BTC addresses from various versions. I have highlighted the version of each address with colors as used in the table earlier for clarity. Such a transaction highlights how backwards compatible and interoperable BTC is – a single transaction can involve inputs and outputs from differing versions of the BTC protocol, all without problem. Summary

I hope you found this post valuable, and as always, if you spot things I am mistaken on, please get in contact with me via the About page. I will continue to update the list above if/when new major BTC versions and address formats are released.

And while there are many other BTC-related address formats (e.g. addresses for bitcoin cash, BSV…), here I restricted focus to only address types you will see in common use on main bitcoin blockchain. I have also avoided going into detail on how the addresses are constructed and the different sub-parts of addresses – if you are interested I recommend digging further, as it is a rather abyssal rabbit hole.

Thanks for reading!

setup peer node

Peer Node

A new network node is created when a user installs a Bitcoin client on his computer and begins to exchange information with other network participants. Most clients are open source, and users are free to choose from a range of software packages. Theoretically, a user could also develop his own client and let it communicate with the network. As long as the software packages are compliant with Bitcoin’s communication protocol, they can be used to create new peer nodes and exchange information with other existing nodes.

Bitcoin Core

The most popular client is known as Bitcoin Core. Bitcoin Core contains the full range of functions. The software creates a full node and can be controlled via a graphical user interface or via the command line.

Bitcoin Core keeps a local copy of the Bitcoin blockchain. The client verifies and relays the transactions and blocks. In addition, Bitcoin Core includes a wallet and a simple mining application. It therefore provides all three functions.

Verification function

The verification function covers all the activities that are necessary so that network participants can participate in the network on their own and verify all transactions independently. In particular, participants verify transaction messages, store these messages locally, and forward them to other network participants. The verification function requires a participant to maintain a copy of the Bitcoin blockchain and to verify the validity of all the blocks of the chain. The verification function also facilitates the exchange of blocks. Network nodes who have a verification function are known as full nodes.

Wallet function

A wallet provides safe storage for private keys and monitors and manages a node’s personal Bitcoin balance. Wallets are developed for end users and normally provide a graphical user interface that enables Bitcoin units to be received and sent easily. In addition, many wallets offer optional security mechanisms to improve the protection of the private keys.

Mining function

Nodes that have a mining function participate actively in generating new blocks and contribute to the extension of the Bitcoin blockchain.

References

https://galoy.io/praia-bitcoin-deploying-galoy-open-source-banking-in-self-hosted-environment/

https://bitcoin.org/en/full-node#initial-block-downloadibd

https://developer.bitcoin.org/devguide/wallets.html

https://developer.bitcoin.org/devguide/p2p_network.html

https://bitcoin.org/en/wallets/desktop/linux/armory/

technical backgrounder

Network protocols

After the successful installation of client software, the software will connect to other nodes. The connection is established via the common network protocols (TCP/IP) and by default via port 8333. The node that wants to establish a connection sends an initial message(version message) to a known internet protocol (IP) address of another node. The message contains information about the node itself and the local copy of the Bitcoin ledger, enabling the connection to be established. Optionally, the address list of the new peer can be queried (getaddr message) so that the node can extend its known network with additional connections.

New nodes face the initial problem of not having any known addresses. To enable the software to establish a connection when the client is started for the first time, an IP list is supplied with the initial download. Alternatively, IP addresses can be entered manually.

Typically, every node attempts to maintain at least eight connections. The actual number can substantially diverge from this value. With regard to standard settings, nodes maintain on average thirty-two active connections. Possible firewall and router settings may limit the number of connections. In general, a broader network connectivity will facilitate the exchange of data.

If an interruption causes a node to have fewer than eight active connections, it will immediately attempt to establish new connections. For this purpose, known IP addresses can be used or new IP addresses requested from other nodes.

Let us assume that Tamara downloads and installs the Bitcoin client. After successful installation, the client consults the supplied IP list and establishes a connection with one of the other nodes.

In order to do this, the client sends a version message to which the other node responds with a verack (version acknowledged) message.

Edith can accept the connection by responding with a version message and waiting for the verack confirmation. Tamara can then request Edith’s IP address list. This is achieved using a getaddr message. Edith will send a random selection of IP addresses from her large pool of known IP addresses to Tamara using several addr messages. The random selection process is termed bootstrapping.

In many cases, Edith sends IP addresses that are present in her pool but that she is not currently connected with. This leads to a more robust network topology. Tamara receives the IP addresses of Michèle and Jake. She can use the new IP addresses to send further version messages and thus establish new connections.

In the real Bitcoin network, bootstrapping creates quasi-random connection paths. These lead to a complex and randomized network topology. Local proximity is irrelevant for the choice of connections. In this respect, the random creation of network partitions is practically impossible. Moreover, if a partition is created, this can be detected by a sudden drop in network computing resources (more precisely regarding the speed at which new blocks are created) and the number of transaction messages.

Partitions generally only become a problem if complete isolation of a certain (geographical) area persists over an extended period of time. This is a manageable risk, considering that any communication between two subnetworks can resolve partitions.

Geographical characteristics of the node distribution can therefore be of interest due to geopolitical considerations and to protect against (natural) disasters.

The Bitcoin system offers each network participant the possibility of independently verifying the legitimacy of all transactions included in the Bitcoin blockchain. If a network participant waives this option, he automatically loses part of his independence and must place a certain amount of trust in his information sources.

The exact structure of these dependencies and the extent of the trust vary greatly. Indirect network participation can take the form of centralized subnetworks or simplified payment verification (SPV).

Centralized Subnetworks

Centralized subnetworks display the highest form of dependency. The participants are only indirectly connected to the Bitcoin network and rely exclusively on the information and communications channel of a specific node.

Clients that are connected to a centralized subnetwork can exercise the wallet function without the need for direct access to the Bitcoin network. The central node is used as a proxy server, which can be consulted periodically to check the Bitcoin balances of the user’s addresses. In addition, transaction messages are transmitted to the central node and thus indirectly relayed to the Bitcoin network.

A connection to a centralized subnetwork can be much more convenient for a user since he has only to install a light client or to manage his Bitcoin balances via a web application. The resulting dependencies are hardly noticeable under normal operations. However, it would be possible for a central node to either withhold certain information from the participants or not relay their transactions to the rest of the network and thus block them. This can be done intentionally or can happen as a consequence of technical issues. In this respect, centralized subnetworks lose a large part of the robustness properties of a peer-to-peer network and introduce new vulnerabilities into the system.

In many cases, centralized subnetworks are also accompanied by custody services. In such relationships, the owner transfers complete control of his Bitcoin units to the central node. He does not hold a private key for the corresponding balance but only has a user account on the service provider’s platform, with which he can request the delivery of his Bitcoin units. The actual Bitcoin transaction is initiated by the central node. In such a relationship, the user only gets an IOU promising to deliver the Bitcoin units on request. This is comparable to credit money, for which the value of the promise depends on the creditworthiness of the issuer.

Simplified Payment Verification (SPV) Node

Simplified Payment Verification (SPV) clients facilitate the use of the wallet function without it being necessary to store a full copy of the Bitcoin blockchain locally. As opposed to indirect network participants who are tied to a central node, SPV nodes possess direct access to the Bitcoin network. The required data are sourced by various nodes and can be partially verified.

The diversity of data sources and the possibility of partially verifying the received data give the SPV node greater security and independence than a connection to a centralized subnetwork.

An SPV node holds only a small part of the blocks—the so-called block header. Among other things, the block header includes the identification number that depends on the transactions included but not the transactions themselves. For this reason, SPV clients require only around a thousandth of the storage capacity of full nodes. An SPV client needs to store only eighty bytes per block. More importantly, this amount remains unchanged regardless of the number of transactions included, resulting in a linear growth path even with a large increase in users and transactions.

Full nodes use the block height to verify a transaction. To ensure that the Bitcoin unit (unspent transaction output) referenced in a transaction has not already been used, the full nodes check the complete Bitcoin blockchain. SPV nodes instead use a heuristic based on the block depth—that is, the number of confirmations that secured a trans- action. If the block is referenced by a certain number of additional blocks (usually six), SPV nodes regard the transactions contained in it as valid. Due to the high computational resources required to create these subsequent blocks and the various sources used to obtain the information, the probability of a manipulation attempt is very low.

SPVs source information by selectively querying individual transactions. This creates two problems.

First, SPV nodes can verify whether a received transaction actually belongs to a block; however, they do not know whether they are being denied information or whether another, possibly competing transaction exists.

Second, information gathering can lead to privacy problems. If an SPV node asks only for transactions in connection with its own public keys (or Bitcoin addresses), the other nodes will be able to connect these pseudonyms to its IP address and create a distinct user profile. As a countermeasure, the SPV node could request a large amount of additional data. However, the large volume of data would undermine the original purpose for implementing the SPV client.

To counteract the second problem, transactions are usually queried via so-called bloom filters. Bloom filters specify a search request using hash functions. The SPV node sends a request for transactions that match a certain search pattern after applying various hash functions. The precision can vary according to requirements.

There is still a trade-off between privacy and data volume. False positive results are possible or even desirable because of the probabilistic nature of the system. False negative results are not possible. If a transaction is rejected by the filter, it is irrelevant for the SPV client.

Bloom filters serve the purpose of disguising the search queries by SPV nodes. Due to the nature of the hash function, it is much harder to identify the pattern behind the query. The idea originated with an academic essay by Bloom and was formalized by BIP0037 for the Bitcoin system.

The Exchange of Blocks

When the client software is first started, it spends several hours downloading, verifying, and indexing all the blocks of the Bitcoin blockchain. The first block, the genesis block, is integrated into the client software on delivery. All subsequent blocks have to be procured from the other nodes and verified by the client software. The volume of data contained in the Bitcoin blockchain was approximately 205 gigabytes (GB) at the end of 2019.

Each block needs to be downloaded and verified only once. Long loading times occur only if the client has to catch up on a large number of blocks; that is, during the initial installation of the client software or if the node was not connected to the network for a long time.

The comparison between two copies of the Bitcoin blockchain takes place via the mutual exchange of getblocks messages. These messages contain the identification number of the newest block in the local chain. If the two chains are equivalent, no blocks need to be exchanged. However, if one of the two nodes receives a getblocks message with an identification number that does not correspond to the last block of the local chain, it will try to locate the block with this identification number within the local chain and send an inv (inventory) message with the identification numbers of the successors of this block. The node that receives the inv message, then, has the possibility to request the respective blocks using getdata messages.

This principle is used to prevent a node from receiving block data that it already has. Each node can independently decide which data it wants to request from which nodes.

When a node receives a block, he independently examines the validity of the transactions that it contains and verifies that the transactions reference only previously unspent transaction outputs (UTXO) and were initiated by the owner.

The node also checks the reference to the old block and examines the current block’s identification number to determine whether it meets the threshold value criterion. Each node can thus clearly determine whether a block fulfills the various consensus conditions. If and only if all checks are passed, the node will include the block into his version of the blockchain.

The Exchange of Transactions

Transaction messages are payment orders that nodes can verify, relay, and process. The method for exchanging transaction messages is very similar to that used for blocks. The inv messages can alternatively include transaction identification numbers. If a node receives an inv message that contains an unknown transaction identification number, the node can similarly use a getdata message to request the transaction.

The actual transmission of the transaction data is subsequently made using a tx message. If a node receives a requested tx message, it will first examine it and forward only if the validation is successful. The validation is performed using predefined unlocking conditions and signatures. If validation fails, the transaction will be discarded. This protects the network from certain types of DoS attacks, which cause data transmissions to seize up by flooding the service with a large number of invalid transactions. However, if the validation is successful, the transaction message will be filed in the node’s local memory, the so-called mempool, and offered to other nodes as part of the inv message.

Pseudonyms

Owing to the decentralized structure of the Bitcoin network, it is not possible to manage Bitcoin balances and access rights in a traditional manner. There is no central authority that is responsible for opening accounts, recording owners’ personal details, and authorizing subsequent access. Therefore, decentralization makes it extremely difficult to examine the legitimacy of ownership claims.

The use of real identities in the form of personal names and personal details is neither feasible nor desirable in the Bitcoin system. It is not desirable because if Bitcoin addresses were registered under personal names, it would be possible to associate all transactions to individuals. Information about salary payments, purchase preferences, and personal wealth would be accessible to everyone. It is not feasible because in a decentralized system it is impossible to provide proof of identity in the same way as in the traditional financial system. The Bitcoin system uses pseudonyms instead of actual identities to guarantee the legitimacy of transactions. A pseudonym-based solution in a decentralized system requires that the following conditions are met:

Participants must be able to create their own pseudonyms without the assistance of a central party.
No two pseudonyms may overlap.
Ownership claims to the pseudonyms must be publicly verifiable so that access to the respective Bitcoin balances can be restricted.

Bitcoin satisfies these conditions by using pairs of cryptographic keys. A pair consists of a private and a public key. The public key (or the Bitcoin address derived from it) acts as a pseudonym that represents the identity of the respective participant but cannot be easily linked to a person (point 1). 1 In practice, the number of pseudonyms is so large that the probability of two persons choosing the same pseudonym is negligible (point 2). The private key must always remain in the exclusive possession of the person who generated the pseudonym and thereby provides proof that the owner of the respective pseudonym is authorized to use it (point 3).

Generating a Key Pair

To create a key pair, a person must select at random an element from an unimaginably large set of numbers which ranges from 1 to 115, 792, 089, 237, 316, 195, 423, 570, 985, 008, 687, 907, 852, 837, 564, 279, 074, 904, 382, 605, 163, 141, 518, 161, 494, 336; that is, between 1 and a seventy-eight-digit number. The selected number serves as a private key and can be subsequently used to provide proof of ownership.

The public key is derived from the private key. It is derived by multiplying a commonly known base point G of the elliptic curve by the previously selected private key k prv. For this reason, the public key is a point K pub on an elliptic curve that is represented by an x and a y value. The multiplication is shown in the formula below:

K pub = k prv ◦ G.

It is crucial that multiplications based on elliptic curves cannot be inverted. Otherwise, every person who knows the pseudonym could then derive the corresponding right of access in the form of the private key.

Owing to the one-way function, people are able to disclose their public key as a pseudonym while at the same time retaining exclusive knowledge of their private key.

A person can choose a private key, derive a pseudonym from it, and receive a Bitcoin payment on behalf of the pseudonym. Since the person is in exclusive possession of the private key, it can be used to prove ownership of the associated pseudonym and all of its assets.

The most common pseudonyms are Bitcoin addresses. To derive a Bitcoin address from a public key, we need a few additional steps as shown in figure 4.1. The Bitcoin address is nothing more than a hash value (see section 4.2) of the public key. For now, we will consider public keys and Bitcoin addresses as equivalents. We will look at some advantages of Bitcoin addresses later and differentiate them from the public key.

To further describe pseudonyms and access rights, we will follow Tamara, who just joined the Bitcoin network in chapter 3. Tamara now needs a pseudonym, which she will use to receive Bitcoin units. The following steps will be executed by her wallet software.

First, a random number, k prv , is chosen as the private key:

k prv = 100649517912463298218554941963735551419990... 919394775808943667076258561523410426.

From k prv , the software derives the corresponding public key by means of multiplication on elliptic curves (see section 4.3.2). Tamara obtains the point with the following coordinates as her public key:

x K pub = 430861088190638454717842912988288069473526... 45388418363213743744756576526107326,

y K pub = 746045400873459552096268383348084222597854... 86813648239447613724663528494663884.

Representation of the Keys

Bitcoin introduced another format: the so-called Base58Check. This format uses base 58, which consists of the integers 1–9 as well as all uppercase and lowercase alphabetical characters, except for O (uppercase o), l (lowercase l), and I (uppercase i). The large base permits the information to be written very compactly. At the same time, this format avoids alphanumeric symbols that can be confused with others when being transcribed. As a further measure against transmission errors, the format contains a checksum with which some typos can be recognized.

Base58Check is used to display private keys and some pseudonyms, where a prefix identifies the type of data. If the sequence starts with a 1, a 3, or bc, it is a pseudonym. The prefixes 5, K, and L refer to a private key. Private keys in Base58Check are also called wallet import format (WIF) keys.

Public keys are usually presented in hexadecimal. This notation, which employs base 16, uses the integers 0–9 and the characters a–f. A single character in hexadecimal rep- resents exactly four bits in binary (2 4 = 16 1 ).

When Tamara’s public key coordinates from section 4.1.1 are converted into the hexadecimal system, they respectively produce the following two alphanumeric sequences:

x K pub = 5f41df966899767381592461911e12789393736b29 . . .
0a5d4beda3ba573d5582be,

y K pub = a4f0ac5d9ca56b776db9f10895303efc8450892e0f . . .
8bd99db228dbd1206f08cc.

To be presented in a single alphanumeric sequence, the coordinates are concatenated and are supplemented by the prefix 04. 4 This representation is called the uncompressed public key K pub . K pub = 04 ^ x K pub ^ y K pub = 045f41df966899767381592461911e12789393736b... 290a5d4beda3ba573d5582bea4f0ac5d9ca56b776d... b9f10895303efc8450892e0f8bd99db228dbd1206f... 08cc

Because the public key corresponds to a point on a predefined elliptic curve, the x-coordinate is sufficient to compute the corresponding y-coordinate. More precisely, given any value for x, there are no more than two potential candidates for y. This is due to the symmetry of the elliptic curves (see section 4.3.2). To obtain a unique point, the x value is extended by a prefix. The prefix is 02 if the y value of the public key is even and 03 if the y value is odd. In Tamara’s case the prefix 02 is used. This compressed representation of the public key will subsequently be termed K pub .

K pub = 025f41df966899767381592461911e12789393736b... 290a5d4beda3ba573d5582be.

The compressed public key has the great advantage that it is shorter. For most transactions, public keys have to be included in the transaction at some point and therefore become part of the Bitcoin blockchain. A shorter key length reduces the required storage space.

Bitcoin Addresses

The most common pseudonym is the Bitcoin address. It is derived from a public key to which two hash functions are applied one after the other. The double hash is a one-way function; in other words, the public key cannot be derived from the Bitcoin address.

A Bitcoin address has a length of 160 bits but is generally presented in Base58Check format with the prefix 1.

SHA256 and RIPEMD160 are the names of the two hash functions. Bitcoin addresses are also referred to as public-key-hashes. The main advantages of the Bitcoin address over the public key are its convenience, security, and flexibility.

First, a Bitcoin address is significantly shorter than the public key and therefore better suited for daily use. It contains a checksum due to the Base58Check encoding.

Second, the Bitcoin address offers some added security. Even if an attacker were to discover a vulnerability in the elliptic curve, he would only be able to start an attack once he had obtained the public key of the target. The Bitcoin address ensures that the public key has to be disclosed only at the time of a transaction. This makes Bitcoin addresses much more robust against the threat of quantum computers.

Third, Bitcoin addresses can also be constructed as so-called pay-to-script-hash addresses. These addresses are not derived from the hash value of a public key and are therefore not classic Bitcoin addresses. Instead, they are based on the hash value of a whole locking script that binds the access right to a specific condition. This allows unusual pseudonym constructs to be created, which for example require that payments must be signed by several private keys or can only be spent after a certain amount of time. These pay-to-script-hash addresses always begin with the number 3.

Compressed Keys and Bitcoin Addresses

Although the compressed and the uncompressed public keys represent the exact same point on the elliptic curve and derive from the same private key, they lead to different Bitcoin addresses. If Tamara generates her Bitcoin address from the uncompressed public key K pub , she obtains the Bitcoin address B. If she uses the compressed public key K pub instead, she receives the Bitcoin address B.

B =1E8jc2eRXmjF2FKebTZwAsxwaRWeDvEwDj, B =13HE523Wvpqzjijjb1z3NDUz25AQN2eLw1.

Tamara can use her private key to access both of these Bitcoin addresses. However, her private key can be represented in two distinct ways. Private keys with the prefix 5 manage Bitcoin addresses generated from the uncompressed public key. Private keys with the prefix K or L are used to manage Bitcoin addresses generated from the compressed public key (see below). The prefix facilitates in particular the import of the keys into a wallet software. The information in the prefix instructs the software which pseudonyms it needs to check for balances and therefore significantly increases efficiency. The “compressed” WIF version of Tamara’s private key k prv corresponds to the following string:

k prv = L4gGHffx1goCCfDCpGAdZYmjKPgNk1mBnT2dPakUkRWjEec7ArQY.

Strictly speaking, however, the term “compressed” private key is incorrect. It is not a compressed version of the information but merely a signal that indicates which pseudonyms to use. In fact, the “compressed” private key is even 8 bits or 2 hexadecimal characters longer than the uncompressed format. The length of the private key is not very crucial because it is never transmitted with transactions and therefore will not burden the blockchain.

Disposable Pseudonyms

All pseudonyms in the Bitcoin system are designed to be used only once. This may not seem intuitive (compared with bank account numbers), but it is based on the fact that the Bitcoin blockchain is public. If a person always uses the same pseudonym, it will be easier for others to identify patterns in transactions and to track down the corresponding identity to the pseudonym. If the identification succeeds, all past and future transactions of the person concerned could be queried and monitored.

To make such analyses more difficult, most wallets create a new key pair for each transaction and always use different Bitcoin addresses. When a payment is made, the wallet sends the invoiced amount to the invoice issuer’s address and additionally generates new addresses to which the remaining balance is transferred. Observers cannot distinguish between the invoice amount and the change and are equally unable to discover which pseudonym is retained by the owner.

The constant need for new addresses poses questions regarding the selection process and the organization of the access data. New pseudonyms can either be generated from random, independent private keys or be based on an initial value, a so-called seed.

terminology

Knowledgable sources

@1Mark Moss - just seems to be a Carny Barker https://www.youtube.com/c/MarkMoss/videos

https://twitter.com/1markmossi https://twitter.com/1MarkMoss

Jimmy Song is the best resource I have found so far - lots of links

Terminology

DEX

CoinJoin

Lightening

layer to settle a transaction faster. I can transact with you peer to peer over lightening and it would be completely transparent

https://www.lynalden.com/lightning-network/ https://coingate.com/blog/post/pay-using-lightning-network https://github.com/ACINQ/eclair https://github.com/lightningnetwork/lnd https://github.com/ElementsProject/lightning

strike sphinx bitrefill

Atomic Swap

: layering to hide the transaction

MultiSig

multi signature setup

Unchained Capital

requires that you provide 2 of three keys to sign transaction. Can call UC to sign but they only have 1 of the keys so they can't do anything.

Mult-sig vault

Taproot

KYC

Know Your Client is part of the identity tracking to meet govt requirements

Hardware wallet -

order from Amazon nano S $89

ATM

https://coinatmradar.com/blog/how-to-buy-bitcoins-at-atm-directly-to-hardware-wallet/

Ubuntu wallet

https://linuxhint.com/best-bitcoin-wallets-for-ubuntu/

Armory (opensource) has cold storage Bitcoin Core Copay Electrum Coin Wallet https://snapcraft.io/install/coin/ubuntu

Definitions

^lightening

https://silent.link/faq.html

https://uploads-ssl.webflow.com/627aa615676bdd562bec97cd/63323917980abe78bbe18b52_BPI%20CBDC%20Paper%20.pdf

https://geti2p.net/en/blog/post/2021/09/18/i2p-bitcoin?utm_source=substack&utm_medium=email

Electrum

https://electrum.org/#download

Armory

Prune mode

https://coinguides.org/bitcoin-blockchain-pruning/

Pruning mode will not lessen your wallet security. It is same as running a full node wallet.

Running a wallet in pruned mode is incompatible with -rescan and -txindex

Cold storage

To ensure your paper wallet's private and public keys have never touched the Internet, you'll need to save the webpage that generates the keys, disconnect your device from the Internet, open the saved webpage on your desktop, then generate the keys.

https://www.bitaddress.org/bitaddress.org-v3.3.0-SHA256-dec17c07685e1870960903d8f58090475b25af946fe95a734f88408cef4aa194.html

https://paperwallet.bitcoin.com/cashwallet.html

https://localcoinatm.com/bitcoin-atm/ontario/renfrew/renfrew_irving-at-357-stewart-street/?&utm_source=google&utm_medium=organic&utm_campaign=gmb-ca-on-renfrew/&utm_term=BT108768

exchange fees

https://www.blocknative.com/gas-estimator

bitinfocharts.com/comparison/bitcoin-transactionfees.html

lightning wallets

https://bitcoiner.guide/wallet/lightning/

https://lightninglogin.live/learn https://github.com/lnurl/luds/blob/luds/04.md https://github.com/chill117/passport-lnurl-auth

non-custodial wallet

Custodial wallets transfer your private keys and asset protection to a third party while providing convenience and accessibility. Non-custodial wallets give you complete control over your keys and are arguably safer. Therefore, it comes down to your preferences, how much control you want over your assets, and what features you need.

https://dyor.net/#home-pricing https://dyortools.io/

Ethereum

https://codeforgeek.com/how-to-generate-ethereum-private-key-and-address/#:~:text=To%20generate%20Ethereum%20addresses%2C%20follow%20these%20steps%3A%201,install%20--save%20ethereumjs-wallet%203%20Step%203%3A%20Generate%20Addresses

catch airdrops

https://twitter.com/milesdeutscher/status/1639030835478409216 https://twitter.com/milesdeutscher/status/1639030846979194880 https://twitter.com/ardizor/status/1638148008888901632

https://www.orbiter.finance/?source=Ethereum&dest=Arbitrum

Lightening - layer to settle a transaction faster. I can transact with you peer to peer over lightening and it would be completely transparent↩