Is it possible to covert a p2pkh adrress to a p2sh adress?
Addresses are determined by the wallet. It's the receiver's wallet saying "I will accept payment when it arrives at address X". Sending it to another address may mean the wallet doesn't recognize it. Worst case, if the receiver has some hardware security module that stores the key, it may ...
You'll have to negotiate with your service provider whether they can help you.
Whoever holds the private keys for your Bitcoin wallet should be theoretically able to generate a transaction that sends the BCH from the Bitcoin address to wherever you wanted them to go.
In practice this may be difficult or infeasible: To keep large quantities of Bitcoin ...
There are a number of different address formats and other standard transaction types:
Pay to Public Key (P2PK) outputs tie payments directly to the public key of the recipient instead of the derived address. These have been almost completely replaced by P2PKH, although sometimes mining rewards are still paid out to P2PK.
Input: 114 B
Output: 44 B (...
The way Bitcoin checks a public address is using what is called Base58Check. While the Bitcoin Wiki covers Base58Check, I'll outline how it works in both abstract and technical terms.
The whole idea of Base58Check is to prevent invalid addresses. This is done by adding digits to the start (00) and end of the Base58 value (4 bytes of double SHA256 hash).
Transfer from Legacy ⟶ SegWit: pay full fee (doesn't benefit from SegWit discount)
Transfer from SegWit ⟶ Legacy or SegWit: discounted.
Note: SegWit addresses can be Bech32 bc1... or they can be nested in a legacy P2SH 3... address which are backwards-compatible (although less efficient). Many exchanges, wallets support the legacy "nested" form only.
The difference lies in the encoding and the underlying representation in the transaction data stored on the blockchain.
The 3-segwit addresses are known as P2SH-P2WPKH or P2SH-P2WSH. This stands for Pay-to-witness-pubkey-hash wrapped in pay-to-script-hash and pay-to-witness-script-hash wrapped in pay-to-script-hash respectively. This was done to provide ...
Let's compare a 2 input and 2 output transaction for variants of pay-to-pubkeyhash. (Full data below.)
P2PKH has no witness, so raw size is equal to stripped size is equal to virtual size. A P2PKH transaction with two inputs and two outputs has 374 bytes (= 374 vBytes).
P2SH-P2WPKH (wrapped segwit) locks funds to a P2SH output in which it redirects to a ...
Here is what I've gathered so far regarding the different version bytes for each type of Litecoin public address:
p2pkh L-address (LM2WMpR1Rp6j3Sa59cMXMs1SPzj9eXpGc1): 0x30
p2sh deprecated 3-address (3MSvaVbVFFLML86rt5eqgA9SvW23upaXdY): 0x05 (same as bitcoin's mainnet p2sh)
p2sh new M-address (MTf4tP1TCNBn8dNkyxeBVoPrFCcVzxJvvh): 0x32
There's no big difference for users between the two. The fee is lower while using native Segwit address (bech32), and the address format differs.
Let's look at the motivations of bech32 address authors:
Old addresses (base58) need a lot of space in QR codes, as it cannot use the alphanumeric mode.
The mixed case in (old addresses) base58 makes it ...
Rosetta Code has several example implementations in multiple languages.
Python 2 & 3
from hashlib import sha256
digits58 = '123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'
def to_bytes(n, length):
s = '%x' % n
s = s.rjust(length*2, '0')
s = codecs.decode(s.encode("UTF-8"), 'hex_codec')
It's a Segwit output and hence does not have the address associated with it. The locking script for a Segwit transaction includes the witness version (0 in this case) and the redeem script (which is 43aac20a116e09ea4f7914be1c55e4c17aa600b7). Given that the length of the redeem script is 20-byte, this locking address is pay-to-witness public key hash (P2WPKH)....
Yes, they're interchangeable.
The components of an address are a prefix byte, a 20-byte public key hash (160 bits), and a 4-byte checksum. Litecoin testnet uses the same prefix byte as Bitcoin testnet (hex 0x6f, decimal 111) and computes the hash and checksum in the same way. This was arguably not a good decision on the part of the Litecoin developers, ...
Nested P2WPHK is just the normal P2WPKH embedded within a P2SH, to make it compatible with older wallets which don't recognize native witness addresses (bech32). Check out this for more info: https://bitcoincore.org/en/segwit_wallet_dev/#creation-of-p2sh-p2wpkh-address
The site that you reference itself allows you to create Testnet addresses: https://www.bitaddress.org/?testnet=true (Hat tip to Nick ODell)
On the other hand, you could simply use a wallet that supports testnet, see e.g. Running Bitcoin Core in testnet mode.
Assume your hexadecimal private key (256 bits in length) is 0000111122223333444455556666777788889999aaaabbbbccccddddeeeeffff for demonstrative purposes.
Use this table to specify interger version to use the Bitcoin Explorer (bx) command to compute WIF private keys and addresses for numerous altcoins.
Compute associated Testnet compressed WIF key:
% echo ...
The human mind can remember approximately 7 digits quickly and easily. That's how you can remember US phone numbers (sans area code) without even thinking about it. However, when it gets to 10 digits it starts to reach the limit of working memory, and 20 digits is definitely out for most people. Of course, if you actually spent the time to try to memorize it,...
The results are specific to the website and the order in which the addresses were input.
This can be easily determined by experiment. I took a random address from BE and it gave me http://btc.to/2z7. I took another address and it gave me http://btc.to/2z8.
So clearly, it stores all given addresses in a database, and the URL is the address ID encoded in ...
Obviously you would normally use a database with an efficient algorithm, but conceptually it goes like this:
1) You find the first instance of the account ID in the blockchain. If the account ID does not appear, stop. The account has no firstbits.
2) As a safety, make sure that there are at least six blocks after the block in which the account ID first ...
Is there an address format for P2WPKH or P2WSH?
No. BIP142 would have provided an address format for these output scripts, but it is in "deferred" status and expected to remain that way. Wallet developers are being encouraged to discuss a new address format on the bitcoin-dev mailing list, and it is my understanding that one proposal may be coming soon.
The address that you are using starts with bc1 and is a bech32 address. Many online wallets still do not support this form of address, which is the reason you are getting the invalid Bitcoin address error. If you want to use segwit and still be compatible with these online wallets that do not support bech32, you can use a P2SH(P2WPKH) addresses that begin ...
In general spending from a segwit output (i.e. "sending from" a segwit address) will be cheaper than spending a non-segwit output (i.e. "sending from" a non-segwit address). So yes, if you "send from" a bech32 address, it will be cheaper than "sending from" a P2PKH address.
The previous answer, while correct, is outdated. While BitPay did use a proprietary format early on, we quickly adopted the CashAddr format for Bitcoin Cash/BCH transactions.
You can use our address translator to get the correct format for any address (https://bitpay.github.io/address-...
It's a new address format for Bitcoin Cash proposed by BitPay, to prevent BTC/BCC address confusion. It's not widely used, currently.
The old addresses that start with 1 (P2PKH) are converted to addresses that start with C
The old addresses that start with 3 (P2SH) are converted to addresses that start with H
You can use this "address translator" to ...
While I agree with Pieter that you generally should not do this, there is some technical understanding to be gained by knowing how this could be done. The following is for reference:
A P2PKH address A is created from the public key K by the following:
A = BASE58CHECK( 0x00 HASH160( K ) )
Where HASH160( K ) is equivalent to RIPEMD160( SHA256( K ) ...
L - Legacy, Non-P2SH (Pay to script hash) address prefix
3 - P2SH prefix that's backwards compatible to the M prefix. When I say backwards compatible, I mean that there is a 3 address and an M address that point to the same address (Reference: https://blog.trezor.io/litecoins-new-p2sh-segwit-addresses-843633e3e707)
M - Current P2SH address prefix
Litecoin was having issues with users confusing Bitcoin and Litecoin addresses. To that end, they introduced a new address format for Pay-to-Script-Hash (P2SH) addresses. This new address format encodes the address with an M prefix rather than the original 3 prefix which is also used by Bitcoin's P2SH address format.
As any underlying address can be ...
the private key is only a (very big) integer-number. this number used as private key is all you need to generate a public key with some more or less complex mathematical operations and this private key is also the only thing which must be your secret. anyone can know your address and your public key, no problem. with the public key you can generate the ...
I compared to the following 9 types of transaction's weight. And then I found that No9 (P2WPKH => P2WPKH) was the lightest.
// 1 transaction consists of 1 txin and 1 txout
1. (in)P2PKH => (out)P2PKH [weight = 764]
2. (in)P2PKH => (out)P2SH-P2WPKH [weight = 756]
3. (in)P2PKH => (out)P2WPKH [weight = 752]
4. (in)P2SH-P2WPKH =&...