It is assumed that in order to forge an ECDSA signature you need to compute the private key for a given public key first (this operation is known as the "discrete logarithm" (DL), and its hardness is the basis for ECDSA's security). In order to do so, you must actually have the public key.
Once you have the public key, it is assumed that you ...
Is there a way to get to the hash160 address from bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c
Yes, you could use the reference implementations in various languages to encode and decode a bech32 address. For example, I have decoded the sample address you mentioned in the question, bc1q34aq5drpuwy3wgl9lhup9892qp6svr8ldzyy7c, using python below. The decode ...
This is not currently possible, as Bitcoin Core uses hardened BIP32 derivation to compute keys and addresses. This derivation scheme does not have a usable xpub that lets you derive the same keys publicly.
For more background, an xpub (or extended public key) is a string defined by BIP32. Every xpub has a corresponding xprv (extended private key). From the ...
Perhaps you're confused by the phrasing "the wallet", as it's only the receiver's wallet who needs to know the public key, and he has it, because he created the address in the first place.
In what follows, I'm going to assume a standard 1... address (pay to pubkey hash). That's not the only type of address, but similar ressonings apply to every type of ...
The blockchain does not see wallets at all. It only sees spent and unspent transaction outputs (txouts). A txout is either completely spent or completely unspent - it cannot be "partially" spent and so there is no notion of balance. (If you want to spend less than the full value of a transaction, you create a change output.)
In your example, there are ...
The main difference is that Bitcoin in lightning network channels are in 2of2 multisig wallets. You own a key and your channel peer owns the second key. Your funds are "safe" because you have pre-signed transactions that spend from that multisig wallet (similar to an offline signing of a transaction). As soon as you keep those pre-signed transactions, your ...
6 types of Bitcoin addresses (in parentheses are the data they keep):
P2PKH 1... (a public key's hash)
P2SH 3... (a script's hash) (defined in BIP16)
SegWit (P2WPKH/P2WSH) nested in P2SH (defined in BIP141)
P2SH-P2WPKH 3... (a public key's hash)
P2SH-P2WSH 3... (a script's hash)
(these start with three because these addresses are meant to be ...
Which kind of address do you want?
Assuming that you have compressed public key(compressed_public_key.txt), to generate P2PKH you can use these commands (hash160 and encoding with base58)
ADDR_RIPEMD160=$(printf $(cat compressed_public_key.txt | xxd -r -p | openssl sha256| sed 's/^.* //') |xxd -r -p | openssl ripemd160 | sed 's/^.* //')
There are a few reasons why a user can lose funds in the lightning network. But to understand why that happens let us look at some of the basic constructs of Lightning Network.
When two parties open a channel in Lightning Network what they essentially do is send some bitcoins to a 2-of-2 multi-sig that they both control (in current specs ...
Bitcoin does not work on an account model but operates on an UTXO (unspent transaction output) model. When you send bitcoins to an address, what you are essentially doing is locking those bitcoins in a mathematical equation. Spending those coins requires that you provide the correct unlocking condition (most often signature and public key associated with ...
No, you cannot assume this.
There are a number of ways in which individual inputs may belong to different wallets/owners. For example:
They could come from a hosted wallet or exchange, where inputs may span coins deposited by thousands of individual users, and selected for a transaction with no particular relation to the user making that transaction
You are trying to use a mainnet encoded address on testnet. That is not valid. You need to use a testnet encoded address.
The testnet form of the address you are trying to use is 2MvX28fMpoipKxqaxo6pN1CH4QjB5t9qpr8.
The wiki says that
A Bitcoin address is an identifier of 26-35 alphanumeric characters.
This information is now outdated but it was true at the time this question was asked look at morsecoder's answer. With the introduction of Bech32 type addresses in 2017, the minimum and maximum length of a Bitcoin address have changed.
According to BIP 173:
It depends a lot on the kind of locking condition you want to satisfy. The addresses that you have mentioned would depict 'standard' locking condition where the user reveals their public key and associated signature in order to spend the locked bitcoins. However, you can create custom scripts and then convert them into standard addresses.
For example, ...
Individual address private keys begin with 5,L or K. What you're calling root private keys are actually called extended private keys and they begin with ?prv where ? is either x,z,y,Y,Z. You can see examples of those here. So that's how you tell the difference.
One of the issues with encoding P2PK outputs as an address is that they can be very long. P2PK can have both compressed and uncompressed keys. Uncompressed keys are 65 bytes, which means that the resulting address would be very long. In fact, this length is probably why P2PKH exists in the first place: as a way to have short strings as addresses. So P2PK ...
What you can spend, and what you can send to depends on the wallet software and nothing else.
There are no inherent restrictions on any combination.
In case someone uses old software, they may not be able to send to bech32 addresses. But they'll get an error that the software doesn't recognize the address; no funds will be lost.
I resolved this.
Here is the functional command:
client.command('scantxoutset', 'start' ['addr(mfe87Qheq7SSveCDedyDUBEjMD9tgzRiU7)']) <!-- Address is valid. This address: '34xp4vRoCGJym3xR7yCVPFHoCNxv4Twseo' is invalid
The issue is that the address was invalid. Using a valid address, I can ensure that this works.
As per BIP 173, the data part consists of:
The data-part values:
1 byte: the witness version
A conversion of the 2-to-40-byte witness program (as defined by BIP141) to base32:
Start with the bits of the witness program, most significant bit per byte first.
Re-arrange those bits into groups of 5, and pad with zeroes at the end if needed.
Translate those bits ...
There is a similar question from 6 years ago with different options and answers Is there a remote, trustless bitcoin API that doesn't require anything (blockchain/SPV headers) to be stored locally?
Otherwise I suppose the options havent changed much, unless maybe the pruning mod which allow you to run a lightweight bitcoin node (550mb instead of 250giga+...
While exact implementations between wallets might differ, the general approach is usually similar to the following:
A wallet generates a private key (or a set of keys) based on an HD wallet, or just individual random keys
The public keys for private keys generated in 1. are calculated, and used to create the desired address scripts (p2pkh, p2sh (wrapped ...
You are right in noticing that the change from a transaction is linked to the previous input.
Address reuse is more for receiving payments than spending them - if you have two clients paying you, giving them separate addresses for the payments creates two completely unlinkable outputs on the chain.
Naturally, if you make a future transaction that requires ...
Can I send it to the wrong address format?
Addresses have checksums in them to prevent mistakes like these. Typographical errors can be detected because of these checksums. So a well designed wallet will not allow this, but nothing prevents a badly designed program from erroneously accepting an incorrect address format and decoding it into some invalid/...
There is no way to enable faster querying for arbitrary addresses than scantxoutset in bitcoind.
Explorers provide this functionality by maintaining a separate database of all addresses and transactions which is optimized for that kind of query. Bitcoin Core, on the other hand, is optimized for consensus related queries, which are largely a hashset lookup ...
A first thing to correct is that UTXOs are not referenced by address, but by the txid that created them. The addresses are purely a human abstraction about locking conditions to help think about ownership.
So in your example what happens is that in the initial transaction tx0 created by A, B was credited with 10 BTC. Assume that transaction only had one ...
As long as a utxo is spendable, there are no restrictions on the types of outputs - any kind of input can be used to create any kind of (valid) output, which will usually be one of the well known ones - i.e. p2pkh, p2sh, p2wpkh, p2wsh, op_return, p2ms, p2pk.
Because the address you are using is a P2SH-P2WPKH address as you mention (sh (wpkh ())), you get the output
It is talking only about the top level (P2SH), because it is a P2SH address, regardless of what the script "inside" it encodes. It doesn't "see" the underlying P2WPKH when ...