text:
Bitcoin TX decode failed while sending to a the network(regtest)
I have created a signature manually (referring the signature output formats in bitcoin-cli). But i tried to send the same to the network I am getting
error code: -22
error message:
TX decode failed
Below is the signed tx
signed tx:
020000000138c059adfe41e80fb46e14d23949304343abc560a6fbcef4b2e3110f8241816d00000000002c2b0768616e756d616ea8201ca35897540ec7ae7294a8cacd11caf2c09f95f026c925c6ce4e4c29b20e3c4187ffffffff0280507401000000001976a9146a3ffadddae4ccb4223a8c7215d4b481daf6967788ac00d012130000000017a914def347cf3b01bf03a30d7ee9f62d86ed5109b5478700000000
Spliting the same signed tx:
02 00 00 00  // version
01   // number of inputs (var_uint)
38 c0 59 ad fe 41 e8 0f b4 6e 14 d2 39 49 30 43 43 ab c5 60 a6 fb ce f4 b2 e3
11 0f 82 41 81 6d  // input transaction hash
00 00 00 00 00 //  input index
2c // size of script (var_uint)
2b // data needs to be pushed  the below 43 bytes will be pushed
07 // push 7 bytes to stack
68 61 6e 75 6d 61 6e // data needs to be pushed
a8 // OP_HASH256
20 // push 32 bytes
1c a3 58 97 54 0e c7 ae 72 94 a8 ca cd 11 ca f2 c0 9f 95 f0 26 c9 25 c6 ce 4e
4c 29 b2 0e 3c 41
87 // OP_EQUAL
ff ff ff ff // sequence
02  // no of vouts
80 50 74 01 00 00 00 00 // amount
19 // size of script (var_uint)
76 //OP_DUP
a9 // OP_HAH160
14  // 20 bytes needs to be pushed
6a 3f fa dd da e4 cc b4 22 3a 8c 72 15 d4 b4 81 da f6 96 77
88 // OP_EQUALVERIFY
ac //OP_CHECKSIG
00 d0 12 13 00 00 00 00 // amount
17 // size of script (var_uint)
a9 //  OP_HASH160
14 // 20 bytes needs to be pushed
de f3 47 cf 3b 01 bf 03 a3 0d 7e e9 f6 2d 86 ed 51 09 b5 47
87 // OP_EQUAL
00000000 // lock time
Can anyone please help me to find what is that I am missing ?

Your input txid output index is 5 bytes, when it should be 4 bytes. Just remove the extra 00 byte and the transaction will not pop an error. However, you might need to sign this transaction again as signature involves signing the entire serialized transaction as a message and by changing the txid outpoint you will change the message that is signed.

Beat me to it :)

Yes. I could send to the network. Thanks @Ugam. My script key does not contain any keys. So I do not need to sign the tx with any keys. And for P2SH script address, I do not know how to derive the privatekey.

@kitty Yes, since your scriptSig does not involve the use of any keys, it does not need to be changed.


text:
What is the source of bitcoin value?
From what I understood, the economic intrinsic value of Bitcoin as a currency is based on the "CPU-work" required to produce them. That is what makes Bitcoin rare enough to qualify as a currency. Is that it?
Now the thing is CPU-work doesn't come free of social costs. Doesn't it have some incidence on things like:
- market prices of fuels (we all end up paying our electricity higher as a consequence of bitcoin, i.e. we bare the burden)
- climate change (future generations will have to pay more to survive in a less stable climate)
- no legal-compliance checks (i.e. bitcoin activity like all business takes advantage of the security of the State but doesn't fulfill the function of checking legal compliance of transactions as the banking system does - or should I say: is legally required to do)

Welcome to Bitcoin.SE! Some interesting points that you raise.
Bitcoin is more analogues to gold than more recent traditional banking.
Yes, since power is used in bitcoin mining there are some additional distribution costs certainly. The distribution infrastructure exists anyway and in most cases is not being used to capacity ex-bitcoin, however, the more additional power that a wire carries the more losses there are. If power is in limited supply because generation capacity is being reached then there are certainly additional generation costs, otherwise, the generation cost, in most commercial scale generation projects, is in most cases nothing or close to it.
I heard somewhere recently I think that the total power usage in bitcoin mining is equivalent to the full output of three large nuclear reactors. I wondered what effect that may have on climate myself at the time but rationalised that regardless of Bitcoin, practices in generation need to globally improve. In most countries people either pay for the full cost of their power or, pay the cost of generating it themselves.
It is true that the security of the state is to the advantage of all and is why people are free to engage in things like transacting with Bitcoin. As stated, Bitcoin is more analogues to gold than it is to the banking system. So, Bitcoin currently seems to be about as regulated as transacting in cash, but without the tyranny of distance, and without the value ties of fiat currency and, without centralisation. No central bank can decide to print 21 million more Bitcoin and halve the value of everybody's holdings, much like gold.
With exchanges and Bitcoin Debit Cards, Bitcoin is linked to the local banking system much like any other offshore currency.
In Australia, Bitcoin is legally just like cash. GST and other taxes are payable.

also like. Gold: no... there are the holders, yes, but there are many, many traders? If bitcoin is gold, what is bitcoin Cash? :-) Power: It's in the range of 1000MW power plant. And nuclear doesn't add to climate change (haha...)? So it must be carbon/gas/fuel. In the monopoly of power distribution (see ENRON/USA), the assumptions are completly false. And e.g. in Europe power decentralization get's more and more important. Imagine electrical cars everywhere. They "cost" more than some miners.

Gold is a commodity with its price marked against the US currency in every major economy worldwide. There are many buyers and sellers of gold, arguably it has a greater utility value than Bitcoin. Bitcoin Cash is mostly Bitcoin with more transaction ledger writing capacity every x minutes, lower fees and lower market value and, missing a few beneficial features. I pity the miners if they cannot be paid for their work.

Some very good questions, like! Though not really relevant for this technical forum. But I cannot resist :-)

the economic intrinsic value of Bitcoin as a currency is based on the
  "CPU-work" required to produce them.

Unless the word "economic intrinsic value" has a special meaning, I would like to reject this statement. The intrinsic value of bitcoin comes from the fact, that its use case exceeds the possibilities of traditional FIAT money or complexity of gold handling (including having gold, or holding a paper which says I have gold). With bitcoin, you have a growing value (with Dollar, you can buy less and less over the years), you can easily send values over the internet, without financial institutions. And also you can trade it, without going through the complexity of the traditional fiat system. And: it is a "world currency", something that the dollar always wanted to be, but never achieved... This all adds to the INTRINSIC value, and certainly a lot more.
But I think you were up to this scarcity of bitcoins:

That is what makes Bitcoin rare enough to qualify as a currency. Is
  that it?

Somehow, yes and no. There are people who say in traditional economics, when a ressource is scare enough, it's value increases. I don't see the same for all the altcoins, so there must be something wrong with this statement. Seems like standard economics don't match. Economics are based on long term observations, and maybe crypto world is just too young.

market prices of fuels (we all end up paying our electricity higher as a consequence of bitcoin, i.e. we bare the burden)

hugh, this is a good one! If there are people saving energy, price goes down? When the market asks for energy, and is ready to pay a price for it, the energy will be offered. And if there is no demand, new "requirements" are (must be) created, so that the investment in energy plants will not go lost.
I think the statement is a bit too hard, and at the same time I understand, that it is probably very difficult to proof.

climate change (future generations will have to pay more to survive in a less stable climate)

What about the miners using solar and wind power? Or those who use energy, which would otherwise be wasted. This statement is also a bit "off topic", because looking at what energy is spent for other activities, be it for fun or be it for a specific "society beneficial use" - who would judge if it is ok to mine crypto or not? Climate change is caused 99% by industrialized countries, which now try to hide behind "green", just to continue to pollute the environment. Proof? Look at the complexity of the Kyoto protocol. So no, bitcoin and climate change - that's a little bit too big to put into the same phrase.

no legal-compliance checks (i.e. bitcoin activity like all business takes advantage of the security of the State but doesn't fulfill the
  function of checking legal compliance of transactions as the banking
  system does - or should I say: is legally required to do)

this is probably the best, and the most difficult one. There are people who like to be watched and controlled by governments, and those who like their independency. Especially "proud" US Americans must love their country for being victim of the tax system :-)
One can raise the question, who benefits from the compliance with the money system. You quickly come to see, that countries/governements hold their inhabitants as victims, to assure money doesn't leave the country. In a peaceful world with one currency this would not be required (utopia? No, hold on! Europe has created the Euro, and freedom is better than ever in the last 1000 years!). But as we are here, we have to live the rules. And pay taxes, where others decide, how they get spent. For sure only to protect us from falling into the hands of criminals, gangsters, terrorists - you name it :-) Because government believes, their inhabitants are stupid? (maybe yes, one may look up Immanuel Kant and his essay: "Enlightenment is man's emergence from his self-incurred immaturity"). What is interesting: those with a lot of money still have their tax oases (Delaware, Channel Islands, Caymans - or last recently Panama and its papers), whereas the vast majority of inhabitants have no access to these tax paradises. So there are the individuals which are required to vote the government, but the very rich people (and companies) who pay the electoral campaigns have access to avoid taxes. I like this tax theatre!
My personal view: bitcoin is a masterpeace of freedom. It belongs to noone (or everyone), and you cannot change it to your will.
As I said, I couldn't resist ;-) A lot of these discussions can be found in bitcointalk, which is probably the better forum for such a discussion, cause you can assume, that my statements are not the holy grale.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
How malleability ussue works?
Can you explain malleability issue, please?
This is what I read here: https://qz.com/175565/why-nobody-can-withdraw-bitcoins-from-one-of-the-currencys-largest-exchanges/
"When a transaction record is sent out to the network of bitcoin miners, it’s possible for a hacker to tweak it enough to change the hash, but not enough to make the transfer invalid. One of the ways the hacker can do this is by slightly modifying the digital signature in a way that it is still recognized as the right signature, but, again, results in a completely different hash."
I can't understand how, say, Bob can change Alice's signature in a Alice->Bob transaction if that signature doesn't belong to him in the first place.

Possible duplicate of What is Transaction Malleability?

This question primarily addresses what it is. I wanted to clarify how exactly it is possible that third parties can change signatures of others

First of all, exchanges keep track of transactions by their TXIDs. The TXID can be changed by 3rd parties, but not the transaction data.

I can't understand how, say, Bob can change Alice's signature in a Alice->Bob transaction if that signature doesn't belong to him in the first place.

Old versions of Bitcoin Core used OpenSSL to verify signatures (now libsecp256k1). OpenSSL is lenient about signature encoding.

An ECDSA signature is an (R,s) pair. (R,-s) also makes a valid signature.
OpenSSL allows encoding algorithms other than DER.

which means there are more than one possible way to encode signatures. Different but equivalent signatures allow 3rd parties to change the signatures without knowing the private key, thus changing the TXID.
Details: BIP 62

"Old versions of Bitcoin Core used OpenSSL to verify signatures (now libsecp256k1). OpenSSL is lenient about signature encoding." Doesn't this issue still on since not everyone accepted SegWit?

No, transactions with non-der signatures are not relayed. And no software, even pre-segwit, uses non-der signatures.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Command line bitcoin cash wallet for linux?
Is there a good command line Bitcoin cash wallet for linux available?

You may probably try Sibit.

You can use Bitcoin-ABC or Bitcoin-unlimited, Both are Bitcoin-cash.
after you successsfully install it, you can just send the commands as follows:
bitcoin-cli getnewaddress "account"

to get new bitcoin cash address.
You can find all commands on bitcoin.org. This documention for Bitcoin core, but as Bitcoin cash is a fork of bitcoin, these commands should work with you. You can find new commands or changes on Bitcoin-ABC on Github

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Bitcoin-ABC creating a new wallet
As I understand wallet information is on a file named "wallet.dat" I can backup/restore a wallet with that file. However what if I want a completely brand new wallet with no history. Is it enough to delete the "wallet.dat" file? would Bitcoin-ABC generate a new wallet after wallet.dat is deleted?

For future readers: the Bitcoin-ABC client is (confusingly) not a Bitcoin client.

Is it enough to delete the "wallet.dat" file?

yes. make sure that bitcoin is not running

would Bitcoin-ABC generate a new wallet after wallet.dat is deleted?

yes


text:
Bitcoin new receive addresses
With the Bitcoin-ABC cli I can generate as many receive addresses by the following command
./bitcoin-cli getnewaddress "label"

But from my understanding the funds still go into the same wallet and if I send coins from the wallet it would always be from the same "from" address. Am I correct in my understanding?

Funds still go into the same wallet and
  if I send coins from the wallet it would always be from the same
  "from" address. Am I correct?

Not exactly. It depends on the amount of coins you'll send. Here is an example:

You have address A with 1 BTC.
Address B with 0.3 BTC.

Consider you want to send 1.1 BTC to the address C.
In that case the transaction would have 2(A,B) outputs and 2(C, X) inputs *:

Outputs: A with 1 btc and B with 0.3 BTC.
Inputs: 1 BTC to the address C and 0.1 BTC to the address C.
0.2 BTC will be your change, and it'll be sended back to you*.

The from address will be the collection of your income addresses(A,B, e.t.c.).
*Some wallets do let you manually select which address should receive the change from a transaction.
*In some cases client will create a new address for change.

Actually, wallet just represents the overall amount of bitcoin you have for all the address you generated (It like a database of your bitcoin address), so yes it going to the same wallet.
For address, yes when you send the bitcoin out, your wallet will find the address that has enough funds to send it out (unless u specify which address) which may cause multiple addresses to send to 1 address.
So basically the bitcoin value is stored on the individual address that was used to receive while a wallet just a thing that used to manage those address.
Hopefully this answers your question as I have little trouble understanding it


text:
Setup bitcoin cash with bitcored
I saw that https://blockdozer.com has insight-api for bitcoin cash blockchain. But i cant find doc how to setup bitcoin cash with existing bitcore node. I have already synchronized full bitcored node and able to use it insight-api.

https://blockexplorer.com also has this same functionality. I believe some bandaids need to be placed on insight-ui in order to get the cashaddr format working fine, but there is a branch of bitcore that is designed to work with bitcoin cash.
https://github.com/bitpay/bitcore-lib/tree/cash

is it enough to install bitcore and add there bitcoin cash lib?


text:
Import all existing addresses in local bitcoind
I started local bitcoind client. And started it as RPC server. I know that i able to get balance only for my account address. But how i can work with all existing addresses? How i can get balances and txs? Maybe exist some db for this?

You can import any address you want to watch or "work with" by navigating to console window and sending the following command:
bitcoin-cli importaddress "address" "account" <rescan>

after blockchain scanning complete you can send
bitcoin-cli listtransactions "account" "Count" "skip" watch-only
bitcoin-cli listtransactions "*" 1 0 true

So you get all transactions.
You can get all commands from bitcoin.org

Thx. Maybe bitcore-node can help me? If i install it and synch it fully would i be able to work with all addresses?

yeah, also you can do that with bitcoin-core but just with transactions. by enabling -txindex

Ty so much. @Adam with transactions you mean i would be able to get list of transactions(spent and unspent)?

to get unspents, you should call listunspents


text:
generating private key from bip39 seed
according to bip39, I maked 12 mnemonic words and then get a 512 bit seed from them.
now I want to know how must I convert this seed to private key ?
what functions must I use ?
please introduce me libraries for browser javascript.
although I know that I must use ECDSA and secp256k1.
but I do not know exactly what the steps are?

What problems do you have with following the reference implementation or the Javascript implementations listed in the link you put in your question?

@RedGrittyBrick My current problem is that I don't know based on what algorithm I need to convert a 512 bits seed into a 256 bits private key.

I don't know based on what algorithm I need to convert a 512 bits seed into a 256 bits private key.

Regarding algorithms:
BIP-0039 says:

From mnemonic to seed
A user may decide to protect their mnemonic with a passphrase. If a passphrase is not present, an empty string "" is used instead.
To create a binary seed from the mnemonic, we use the PBKDF2 function with a mnemonic sentence (in UTF-8 NFKD) used as the password and the string "mnemonic" + passphrase (again in UTF-8 NFKD) used as the salt. The iteration count is set to 2048 and HMAC-SHA512 is used as the pseudo-random function. The length of the derived key is 512 bits (= 64 bytes).

So the algorithms so far are described by

PBKDF2
HMAC-SHA512
Reference implementations
Example implementations

According to the Bkitcoin Wiki entry for Private key:

Wallet software may use a BIP 32 seed to generate many private keys and corresponding public keys from a single secret value. This is called a hierarchical deterministic wallet, or HD wallet for short. The seed value, or master extended key, consists of a 256-bit private key and a 256-bit chain code, for 512 bits in total. The seed value should not be confused with the private keys used directly to sign Bitcoin transactions.

BIP-0032 says:

Extended keys
In what follows, we will define a function that derives a number of child keys from a parent key. In order to prevent these from depending solely on the key itself, we extend both private and public keys first with an extra 256 bits of entropy. This extension, called the chain code, is identical for corresponding private and public keys, and consists of 32 bytes.
We represent an extended private key as (k, c), with k the normal private key, and c the chain code. An extended public key is represented as (K, c), with K = point(k) and c the chain code.

It then goes on to describe the algorithm used.

Regarding Javascript Libraries

https://github.com/bitcoinjs/bip39
https://github.com/bitcoinjs/bip32

It seems to me that this requires a lot of digging about in documentation and source code.
It initially doesn't seem to be something that can be fully encompassed in the space alloted to answers in this Q&A forum.

So, based on what you say:  I should split the produced 512 bits seed into two 256 bits parts, use the first part as the master private key, and use the second part as the chain code (entropy). right?

@saeidezzati: that is how it seems to me.


text:
how to embed coin prices of my choice in my website
sorry for bad english, let's just say i want to embed specific price of coin for example ethereum and bitcoin $20 price in my website, in other words it shows $20 rate of btc and eth on my website not whole coin price.

You can use any exchange api or cryptocurrency market data api such as:
https://coinmarketcap.com/api/
Example:
https://api.coinmarketcap.com/v2/ticker/1/?convert=USD returns the following:
{
    "data": {
        "id": 1,
        "name": "Bitcoin",
        "symbol": "BTC",
        "website_slug": "bitcoin",
        "rank": 1,
        "circulating_supply": 17193862.0,
        "total_supply": 17193862.0,
        "max_supply": 21000000.0,
        "quotes": {
            "USD": {
                "price": 6963.44528122,
                "volume_24h": 3783503583.4896,
                "market_cap": 119728517210.0,
                "percent_change_1h": -0.51,
                "percent_change_24h": -1.1,
                "percent_change_7d": -14.16
            }
        },
        "last_updated": 1533575182
    },
    "metadata": {
        "timestamp": 1533574768,
        "error": null
    }
}

You can then access the price using javascript and calculate how much $20 is worth.


text:
Calculate Unspent using private keys
Can we calculate unspent of addresses which are generated from other node server if we are having private/public key of those addresses?

If you have just a pair of private and public keys, you would need a little more information.
A single public key can control Bitcoin in a number of ways:

A direct p2pk output
A p2pkh output paying the hash of the public key
A p2sh output paying a script controlled by a set of public keys that may include keys other than the one you have
A p2wpkh segwit output paying the hash of the public key
A p2wsh output paying a script controlled by a set of public keys that may include keys other than the one you have

Without knowing which type of output you are looking for, the public key alone is not sufficient, especially for p2sh and p2wsh outputs where other keys are required to construct the address.
Once you know which output type to look for, you can use the scantxoutset RPC method of a node, or construct your own index similar to an explorer or Electrum server and query balances.

Thanks @Raghav. Can you please tell whether bitcoin-core support derivation path other than m/0'/0'/i. Is there any possibility for m/1'/0'/i or m/k'/0/i' where k: 1,2,3....& so on ?

It does not, as far as I'm aware

As far as i know bitcoincore support HD wallet creation but how we can create derivartion like m/1'/0' as m/0'/0' which is for default account 0 because i want to maintain user account in bitcoincore HD wallet.

You can't, you need to maintain a user->address mapping outside of bitcoind

yes. that's true but how we can calculate unspent of user->address mapping outside of bitcoind from any node?

You can use the scantxoutset RPC method if you are operating a Bitcoin node, or use a database synced against a Bitcoin node such as ElectrumX or Bitcore

Will check.Thanks @Raghav for the info.


text:
How to get both confirmed and unconfirmed transaction details of foreign(non-wallet) addresses from bitcoin-node server?
How to get both confirmed and unconfirmed transaction details of foreign(non-wallet) addresses from bitcoin-node server?
Actually i have generated the addresses using third party library and sent some btc on it. Now i want to know confirmed and unconfirmed transaction details using my own local bitcoin-core node server. Can Somebody help me? Thanks in advance.

Which bitcoin client are you running?

bitcoin-core 0.17

If I understand correctly you can use this command getrawtransaction to get a transaction that is in your node's mempool i.e. an unconfirmed transaction.
However, if you are looking for a transaction that has been confirmed, you'll need to know the blockhash of the block in which that transaction resides.
Example:
> bitcoin-cli getrawtransaction "mytxid" false "myblockhash"

Or if you have enabled -txindex option on your client then you can use getrawtransaction and you don't need to supply the blockhash. Check out this question for details on this option.
Refer to this site for a more detailed explanation of the getrawtransaction command.

Actually i want to know the transaction that is send by others into my address and that transaction is not yet confirmed(unconfirmed).Here addresses are created outside the node. Then how we can check status of unconfirmed transactions?
Note: We don't have transaction id for unconfirmed receive transaction. We only have address.

By unconfirmed do you mean "pending" transactions or transactions in the mempool?

Yes, pending transaction of addresses which doesn't belong to my local bitcoin-core node .

The only way you can see that pending transaction is if it gets broadcasted and your local node receives it into it's mempool (AFAIK). Are you not able to see the pending transaction in your nodes mempool?

you mean to say we can get pending transaction of address into our local node  mempool (private keys & address belongs to other node)?

No, I'm saying you'll have to wait for your node to see the broadcasted transaction. Once a transaction is broadcasted it gets propagated throughout the network. You have to wait for your node to see that transaction.

Actually addresses are generated outside the node and now i want to create transaction using these addresses. i used createrawtransaction then while calculating fee i am getting error in fundrawtransaction

You can use scantxoutset command which was introduced in Bitcoin Core 0.17. It scans the UTXO set for any UTXOs for the address (or output script) provided. It is faster than the rescan when you import a private key.
Type help scantxoutset to see the help.
https://bitcoin.org/en/developer-reference#scantxoutset

Thanks m1xolyd1an, scantxoutset gives details of confirmed transactions. I am looking for unconfirmed transactions also.


text:
Calculate transaction fee for external addresses which doesn't belong to my local bitcoin-core server?
I am doing transaction on addresses which are created outside of my local bitcoin-core server using third party lib. I am having its private/public key. I am
 able to create raw transaction using "createrawtransaction" and also able to sign and send txn using "signrawtransactionwithkey" & "sendrawtransaction" but when i am trying to calculate txn fee and adding change address using "fundrawtransaction" or  "walletcreatefundedpsbt", am getting error as "insufficient fund" but i have enough unspent btc on my addresses. So how we can calculate txn fee before signing and sending txn for external addresses?

"fundrawtransaction" and "walletcreatefundedpsbt" are wallet RPCs. They add inputs and change outputs from your wallet to aim for a specific feerate for the transaction.
These operations inherently require the relevant wallet. Change addresses are generated by the sender's wallet, and inputs have to come from the wallet of the sender. If you don't have that wallet, you simply do not have access to that information.
I don't know what advice to give you except to run these RPCs on a  instance of Bitcoin Core that actually has access to the relevant wallet.
If you do things entirely manually, the fee is the difference between the inputs and outputs of the transaction. If that fee value for the transaction you have is not desirable, you'll need to create a different transaction, with either different inputs, or by adding change yourself back to your own wallet.

So how we can calculate txn fee before signing and sending txn for external addresses?

As a reference:
           P2PKH   P2SH-P2WPKH  P2WPKH
        -------------------------------
 Input :  592 WU     364 WU     272 WU
Output :  136 WU     128 WU     124 WU

All transactions include 40 WU by default. If your transaction spends a P2SH-P2WPKH or P2WPKH output, you will need to add an additional 2 WU. To convert from Weight Units to virtual size, divide by 4 and round up.

For a standard transaction spending a P2PKH input and having 2 P2PKH outputs, the weight is 40+592+136+136 = 904 WU. A standard P2PKH transaction is 904/4 = 226 vB.
For a standard transaction spending a P2SH-P2WPKH input and having 2 P2SH-P2WPKH outputs, the weight is 40+2+364+128+128 = 662 WU. A standard P2SH-P2WPKH transaction is 662/4 = 166 vB.
For a standard transaction spending a P2WPKH input and having 2 P2WPKH outputs, the weight is 40+2+272+124+124 = 562 WU. A standard P2WPKH transaction is 562/4 = 141 vB.

These amounts are calculated based on pre-segwit data having a size of 4 WU/byte and segwit data having a size of 1 WU/byte. It is best to assume that signatures will be the largest they can be (72 bytes) since their size may vary by 1 byte. We overestimate the vB size so that a fee of 1 sat/vB is enough in case the signature is in fact +1 byte larger.
P2PKH Addresses
    INPUT (592 WU)
Outpoint   (144 WU): [32-byte txhash] [4-byte txindex]
ScriptLength (4 WU): 0x6b
ScriptSig  (428 WU): OP_PUSHBYTES_72 [71-byte signature] SIGHASH_TYPE OP_PUSHBYTES_33 [33-byte pubkey]
Sequence    (16 WU): [4-byte value]

    OUTPUT (136 WU)
Value         (32 WU): [8-byte value]
ScriptLength   (4 WU): 0x19
ScriptPubKey (100 WU): OP_DUP OP_HASH160 OP_PUSHBYTES_20 [20-byte pubkey] OP_EQUALVERIFY OP_CHECKSIG

P2SH-P2WPKH Addresses
    INPUT (364 WU)
Outpoint     (144 WU): [32-byte txhash] [4-byte txindex]
ScriptLength   (4 WU): 0x17
ScriptSig     (92 WU): OP_PUSHBYTES_22 [22-byte redeemscript]
Sequence      (16 WU): [4-byte value]
Witness Data (108 WU): NUM_PUSHES_2 DATA_PUSH_72 [71-byte signature] SIGHASH_TYPE DATA_PUSH_33 [33-byte pubkey]

    OUTPUT (128 WU)
Value        (32 WU): [8-byte value]
ScriptLength  (4 WU): 0x17
ScriptPubKey (92 WU): OP_HASH160 OP_PUSHBYTES_20 [20-byte scripthash] OP_EQUAL

P2WPKH Addresses
    INPUT (272 WU)
Outpoint     (144 WU): [32-byte txhash] [4-byte txindex]
ScriptLength   (4 WU): 0x00
ScriptSig      (0 WU): N/A
Sequence      (16 WU): [4-byte value]
Witness Data (108 WU): NUM_PUSHES_2 DATA_PUSH_72 [71-byte signature] SIGHASH_TYPE DATA_PUSH_33 [33-byte pubkey]

    OUTPUT (124 WU)
Value        (32 WU): [8-byte value]
ScriptLength  (4 WU): 0x16
ScriptPubKey (88 WU): OP_0 OP_PUSHBYTES_20 [20-byte pubkeyhash]


text:
How to communicate with Bitcoin core 0.17 using bitcoinj for hd wallet creation?
Hi am building one hobby project and i want to perform some operations in my own bitcoin core 0.17 by using bitcoinj lib. so is there any way by which we can use bitcoin-core 0.17,bitcoinj for hd wallet creation with derivation path.

If you're more specific about the functionality you need it would be easier to help you. Do you want to use Bitcoinj to generate a HD wallet, or Bitcoin Core? If you're using Bitcoin Core, Bitcoinj is probably not the best solution for communicating with Core.

Actually,i want to use bitcoin-core for HD wallet creation by using derivation path and also want to maintain each account seperately. For that as per my knowledge we can maintain the different derivation path by changing account level. so i want to know how we can implement derivation path in bitcoin-core unlike bitcoinj ?

Bitcoin Core generally does not expose much control over which HD paths are used. However, it has a label system, where you can call getnewaddress my-label. Does that cover your use case? If you want fine grained control over HD derivation path you will probably need to use another wallet, or make your own.

You also don’t want to be using an ancient version of bitcoin core. 0.17 is very old.

As far as I know, BitcoinJ does not implement a Bitcoin Core RPC client, so there isn't a way to call Core instead (regardless of whether the functionality you want exists in Core).

Thanks @torkel . If we use label to get new addresses then how we can re-import the same addresses into another bitcoin core and how to make transaction on both the servers. Could you please suggest any wallet which support full node with hd support & allow to create custom derivation path. please hint me on how i can do changes in bitcoin core based on custom derivation.

Is custom derivation path a hard requirement? I'm having a hard time imagining a use case where what derivation path is used would affect your application. If you're willing to drop that requirement, you can use Electrum to have two servers sharing the same seed (and thereby wallet).

Hi, I am able to connect my local node(bitcoin-core 0.17) with bitcoinj. Also able to create address using bitcoinj library through derivation path, but that address does not belongs to my local node server as when i am trying to get information of that address by cli command "getaddressinfo". it returns "ismine" as false in response. If i connect my local node through bitcoinj and create address that address should belongs to my local node server so how we can achieve this? One more thing, Is there any way to use bitcoin-core's wallet.dat file through bitcoinj library?


text:
does bitcoin-core support bip44 HD wallet
If bitcoin-core does not support bip-44, is there any other node ?

No, Bitcoin Core uses the BIP32 derivation path m/0'/0', and you are unable to change the derivation path of the wallet in Bitcoin Core.
There is however the Hardware Wallet Interface (HWI) that might be what you are looking for.
https://github.com/bitcoin-core/HWI
https://github.com/bitcoin-core/HWI/blob/master/docs/bitcoin-core-usage.md


text:
What is the purpose of difficult in PoW
I'm trying to understand Proof of Work and something doesn't seem to fit,
First, it seems to me that the faster the network can confirm a transaction, better is. I'm coming from a computing background where more throughput, better.
So why Bitcoin for example imposes a 10 min average? And  why use difficult to impose that average? Why not simply let the network go faster as it grows, this would make more likely to be adopted in day usage

See also  "Proof of Work" questions, such as How does proof of work inspire trust when the work is just guessing?, and also  Wikipedia

Thanks for the references, so, basically making the network faster would make it less safe?!


text:
Is it possible to create smart contracts on Graphene?
I can't found any article on this, is it possible to create smart contracts inside the BitShares' blockchain Graphene?
This is my necessity:

I have to allow my users to purchase my products via SmartCoins.
Users must wait for a confirmation (bank signature needed)
Issuance of certificate of ownership

Bitcoin Stack Exchange on topic seems to have changed; sorry if migrated incorrectly.

Graphene smart contracts are blockchain wide, meaning they require a hardfork to be deployed. The reasoning behind this is that every node operator can review the contract code, ok it and then democratically vote by joining the hardfork.
It's kind of a hassle compared to ETH/ETC but that provides a few choices of very well tested contracts.
OpenLedger has proposed an enhancement to BTS that would provide a VM like EthereumVM and allow users to easily deploy smartcontracts. It's still under discussion: https://bitsharestalk.org/index.php?topic=25187.0


text:
What are the hashes that miners need to do to create a block?
I’m bit stuck in the concept of mining.
What are the hashes that need to be created in each block and the chain? Let’s say that we have block A - B - C forming a chain.
One source said that we need to come up with the hash of A and combine it with previous block’s hash forming another has, in other words: hash(A + previous block’s hash).
Another source just says that it’s just hash of the block itself, and in that block we specify the hash of the previous block’s hash.
The concept of Proof of Work is that you have X and you have an output of Z, what is the Y needed, so hash(X + Y) = Z.
If that's the case, can we say that X is the previous block's hash, and Y is the hash of the current block? Or am I looking this wrongly?
Sources:
https://www.investinblockchain.com/what-exactly-is-blockchain/
https://www.youtube.com/watch?v=SSo_EIwHSd4&t=1sAnd other sources.

Another source just says that it’s just hash of the block itself, and in that block we specify the hash of the previous block’s hash.

This is correct. The others are varying degrees of correct and incorrect. But this is the only one that is absolutely correct.

The concept of Proof of Work is that you have X and you have an output of Z, what is the Y needed, so hash(X + Y) = Z.
If that's the case, can we say that X is the previous block's hash, and Y is the hash of the current block? Or am I looking this wrongly?

Kind of.

The block consists of multiple fields. It can first be broken down into two major parts: the block header, and the transactions themselves. All of the block is hashed in some way.
The hash of the block header is what we call the hash of the block. The hash of the block header is also what is used for the proof of work. When you interpret the block header's hash (also known as the block hash) as a 256 bit little endian integer, it must be less than a calculated target (also a 256 bit integer).
The block header itself can be broken further down into multiple parts. It contains the block version number, the previous block's hash, the hash of all of the transactions in the block, a timestamp, a compact representation of the target value, and a nonce.
Since the block header includes the previous block's hash, the block header's hash is really just the hash of the block (as it contains the hash of all of the block's transaction) in which the previous block's hash is specified within it.
In order to mine blocks, miners will tweak the fields in the block header until they get one that meets the target. Typically they change the nonce value (it's just a number) and the hash of all of the transactions in the block (by changing the coinbase transaction, choosing new transactions, and changing the order of transactions). Miners may also change the timestamp and the version number.

Thank you for the answer! If I got this correctly:
A block contains block version number, previous block's hash, information (transactions, timestamp other data) and a nonce. Miners try to tweak nonce (usually) or transactions inside to meet the desired hash. Is that correct?
Who gets to choose the hash that must be met so the new block can be mined?

@NelsenLiu yea, you're on the right track! The hash is not required to be a certain value, rather the hash must be within some pre-defined range of values. That range is defined by the current network difficulty, which sets a maximum value for a valid block hash.

The target value is determined individually by each node. It is a deterministic algorithm so everyone who is using the same blockchain will end up calculating the same difficulty for each block height.


text:
Compiling bitcoin-qt error: ld.exe: cannot find -lsecp256k1
I have followed the guide "Building headless Bitcoin and Bitcoin-qt on Windows" but with a more recent altcoin source code to test.
The compilation stop on ld.exe: cannot find -lsecp256k1
Is one step missing to generate this missing dll ?
My qt-pro includes:

win32:BOOST_LIB_SUFFIX=-mgw49-mt-s-1_57
  win32:BOOST_INCLUDE_PATH=C:/Deps/boost_1_57_0
  win32:BOOST_LIB_PATH=C:/Deps/boost_1_57_0/stage/lib
  win32:BDB_INCLUDE_PATH=c:/deps/db-4.8.30.NC/build_unix/
  win32:BDB_LIB_PATH=c:/deps/db-4.8.30.NC/build_unix
  win32:OPENSSL_INCLUDE_PATH=C:/Deps/openssl-1.0.2k/include/
  win32:OPENSSL_LIB_PATH=C:/Deps/openssl-1.0.2k
  win32:MINIUPNPC_INCLUDE_PATH=C:/Deps/
  win32:MINIUPNPC_LIB_PATH=C:/Deps/miniupnpc/
  win32:LIBPNG_INCLUDE_PATH=C:/Deps/libpng-1.6.1/
  win32:LIBPNG_LIB_PATH=C:/Deps/libpng-1.6.18
  win32:QRENCODE_INCLUDE_PATH=C:/Deps/qrencode-3.4.4
  win32:QRENCODE_LIB_PATH=C:/Deps/qrencode-3.4.4/.libs
  win32:SECP256K1_LIB_PATH = C:/Crypto/mycrypto/src/secp256k1/
  win32:SECP256K1_INCLUDE_PATH = C:/Crypto/mycrypto/src/secp256k1/include

Welcome to Bitcoin.SE! That is a fairly old guide for Bitcoin Core v0.9.4, v0.10rc4 or, v0.8.6. Usually, these days compiling Bitcoin Core for Windows is done in an Ubuntu environment or similar (build-windows.md) but, without a link to the altcoin source repository, I cannot even check what its build documents say. Probably it uses lsecp256k1 instead of or as well as secp256k1.

@Willtech thanks for your welcome. I have created two learning coins (the last one is https://github.com/JustCuriously/locavore) just to see how it work, build an explorer etc... it's of course copy of other old fork but it's to understand the process. The linux qt has been compiled but I'm not able to compile the Windows qt. If a use the new method (build-windows.md) on the old code I will have many depends errors now ?

Your standard build instructions are here, do they work?

more or less since I have not been able to compile the Windows version, I have not yet updated the method. I just commit the qt version for linux (with qt5). I'm looking for a complete version of code to study, with MN, POW, POS ... but every time I clone the git source and try to compile something is missing .. it seems that dev have something to hide or don't  like to share secret :-)

Just out of interest, what happens if addthe two paths for lsecp256k1 just pointing them to secp256k1?

I restart from scratch my install and check my deps... no I have another error :build\key.o:key.cpp:(.text+0x8f3): undefined reference to secp256k1_ecdsa_sign_recoverable' ./build\key.o:key.cpp:(.text+0x919): undefined reference to secp256k1_ecdsa_recoverable_signature_serialize_compact'
./build\key.o:key.cpp:(.text+0x98a): undefined reference to secp256k1_ecdsa_recoverable_signature_serialize_compact' C:/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/bin/ld.exe: ./build\key.o: bad reloc address 0x1c in section .text$

Do you still have the path for secp256k1 defined also?

yes, still defined so, I just remove everything (i'm working on a VM) to avoid duplicate install or different version.

You can reset your git repository with git clean -fdx before trying to build if that saves some effort, but that is unrelated to your issue

Problem resolved !
There was an error during the secp256k1 compilation process (MINGW32 under windows), adding:

LT_INIT([win32-dll])

into the secp256k1/configure.ac has resolved the compilation error.


text:
Submitblock error: bad-signet-blksig
I try to submit the block, what I mined, but it is not accepted. Also, I could not find the solution by searching the similar questions.
Setup: Centos 8 Linux, Qt programing and /bitcoincore/bitcoin-22.0rc3 with signet. The signet option is also in the config file. Generally; everything works.
1.
submitheader seems to work. I tried to modify the nonce and it was rejected, as expected.
2.
submitblock is rejected with the error message of "bad-signet-blksig".
Just by chance I met a getblocktemplate without transactions. I include it here, I hope it does not take up too long storage space.

[mself@localhost bin]$ ./bitcoin-cli submitblock "0000002073d43119a86132de6db1bab4a71672f9822276098fa6fe392f27e51217000000733a5cf81c9744a53d0d5c52aeae83bac914f40b5e8530178551094ff5c93b8e930d3c62ca65011e00a8628b01010000000001010000000000000000000000000000000000000000000000000000000000000000ffffffff04038c4301feffffff0200f2052a01000000160014cf8cc1e0e650195db875b8bda378fecae0c77ac70000000000000000266a24aa21a9ede2f61c3f71d1defd3fa999dfa36953755c690689799962b48bebd836974e8cf90120000000000000000000000000000000000000000000000000000000000000000000000000"

Answer: bad-signet-blksig
3.
Somewhere I read, I have to include "-signet" (./bitcoin-cli -signet submitblock ...), this case there are no error messages, but the block is not accepted, never enters into the signet blk0000x.dat blocks.
4.
I was checking the accepted blocks in the blk0000x.dat files. I found only one significant difference to my block. In the coinbase transaction, at the second output, the Script PubKey length in my case is 0x26=38 bytes. It comes from the "6a24aa21a9ed" plus the 32 bytes of SHA256(SHA256(witness root hash concatenated with witness reserved value)).
The description sad: the part after the 38-th byte are optional. On the contrary, all of the accepted blocks in the blk0000x.dat files have 0x77=119 bytes. The first 38 bytes are the same structure, as mine, but there are additional bytes attached.
Finally, my question: what did I do wrong, what should I correct?
Thanks, for any answer.

Is this your signet, or the signet? In case it's the latter, you cannot mine for it (unless you're Kalle Alm or AJ Towns; the signet's signers).

@PieterWuille Thanks for the answer. Frankly, I don't know. I set up my Bitcoin Core by following the instructions of Mr. Kalle Rosenbaum, in https://www.youtube.com/watch?v=S6SUgWr97lA. My directory structure looks like: /home/mself/.bitcoin --> bitcoin.conf,  signet,  wallets. Should I try to install a normal, full node?

What you should do depends on what you're trying to do, which I don't know. But signet cannot be mined by everyone - so what you're doing here just doesn't make sense.

@PieterWuille It seems I misunderstood the purpose of signet; I understood that it is for software testing and it is to replace the testnet. I am sorry, I was wrong, I just wrote a mining program and I wanted to try it.


text:
I can't figure out how to use importpubkey
I have been trying to import a public key into my bitcoin[1] node, but it keeps saying that it isn't valid.
The address '18uLJohita1yWTAcDpoLPpd2vNAtnsLW4E' publishes front-pages of the New York times into the BSV ledger and I want to add its public key to my bitcoin server so I can see new UTXOs. The key must be in HEX, per the command.

bitcoin-cli validateaddress 18uLJohita1yWTAcDpoLPpd2vNAtnsLW4E

{
"isvalid": true,
"address": "18uLJohita1yWTAcDpoLPpd2vNAtnsLW4E",
"scriptPubKey": "76a91456aea08d8feaefb18222fcef953366da2a7f200588ac",
"ismine": false,
"iswatchonly": false,
"isscript": false
}

bitcoin-cli importpubkey 76a91456aea08d8feaefb18222fcef953366da2a7f200588ac
error code: -5
error message:
Pubkey is not a valid public key

It accepts that I have sent hex, but it doesn't like it. This is clearly more than just the public key, I can see that from a vout:
"asm": "OP_DUP OP_HASH160 56aea08d8feaefb18222fcef953366da2a7f2005 OP_EQUALVERIFY # OP_CHECKSIG",
So maybe it wants me to remove the OP_DUP, OP_HASH160 and OP_EQUALVERIFY:

bitcoin-cli importpubkey 56aea08d8feaefb18222fcef953366da2a7f2005
Pubkey is not a valid public key

Hmm? Maybe it wants the checksum at the end...

echo 18uLJohita1yWTAcDpoLPpd2vNAtnsLW4E | base58 -d | xxd -p
0056aea08d8feaefb18222fcef953366da2a7f200559461147
bitcoin-cli importpubkey 0056aea08d8feaefb18222fcef953366da2a7f200559461147
error code: -5
error message:
Pubkey is not a valid public key

I them write a bigendian reversal script and tried it, didn't help either.
I am official stumped.
Thanks in advance.
[1] I currently run bitcoin.sv and digibyte and have the same problem on both.

I was considering to close this question as off-topic because the user was asking about problems using altcoin software. However, since the question appears to have been based on a usage error that also applies to Bitcoin Core, I voted to reopen it.

importpubkey imports a public key, not a scriptPubKey.
A public key in this context is a 66 character hexadecimal string starting with 02 or 03, or a 130 character hexadecimal string starting with 04. It encodes a secp256k1 public key. A scriptPubKey is any hexadecimal string, and encodes a locking script. These are distinct things; you can't use one in place of the other.
In this case, it appears you want to import an address. You can do so directly using importaddress.

and a scriptpubkey for P2PKH as in this Q includes the address (in binary or hex rather than base58check) but from the address (in any form) you can't backtrack to the pubkey


text:
How to install Armory Wallet on MAC MINI 12.3.1 MacOS Monterey?
How to install Armory Wallet  on MAC MINI 12.3.1 MacOS Monterey ?


text:
How do bitcoin miners collect coin?
I was wondering how miners claim the reward? They find the nonce and then do they send that value to a Bitcoin server endpoint where it's validated? I'm not trying to reinvent the wheel but I don't understand how data gets from equipment in the mining farm to become part of the ledger. Forgive me if any part of that doesn't make sense. I'm new here.

Does this answer your question? Reward system bitcoin

If not, maybe one of these: https://bitcoin.stackexchange.com/a/101905/5406, https://bitcoin.stackexchange.com/q/112467/5406, https://bitcoin.stackexchange.com/a/111388/5406


text:
Proof that blockchain converges to the longest chain
Is there a mathematical proof that shows that blockchain converges to the longest chain? It seems not obvious to me how a scattered group of nodes and transaction signals will eventually converge to a single longest chain under the Proof of Work/Stake/etc.
Thank you!!!

Without further qualifications or assumptions, no such proof exists because the statement isn't true. Proof of work, at best, makes it expensive for miners not to converge, but if miners had no regard for their own financials, and simply wanted to construct multiple chain branches that the rest of the nodes keep disagreeing about, there is absolutely nothing stopping them. Of course, anyone can become a miner, allowing them to stop such an attack - but that again becomes an economic argument, not an unconditional proof.
Next, demanding "a single longest chain", depending on how you interpret that, is not even the goal of proof-of-work. PoW aims to make the uncertainty a node has about a produced block go to zero in function of the number of blocks on top, but that does not imply much about the latest block. It could well be the case that there are always multiple competing blocks at the tip, but nodes only rarely disagree about what the Nth (say, 6th) ancestor of that tip is. Think of it as a tree that keeps growing, with old branches being cut off, while there are increasingly more branches at you get close to the tip. Note that this is rare in Bitcoin's parameterization in practice (forks more than 1 block deep only happen every few months), but things could very well be different for other parameters.
Yet, even with the above two qualifications, I don't believe a general proof exists. The difficulty is expressing conditions to capture things like economic assumptions. If you go even further away from reality, there does exist a proof that if a majority of the hashrate is "honest" (in that they always work on top of the best block chain tip they know of), and every party sees every block produced without delay, then the probability of needing to switch branches does approach 0 as more blocks have been built on top; this proof is in the Bitcoin whitepaper even. There may be proofs in later work under somewhat general assumptions, including ones that permit a (bounded) delay for communication before miners hear about each other's blocks, though I don't have any references right now.


text:
Create individual wallet for each user
I am working on a platform where users can register and can have wallets with multiple addresses (one address for each coin/network). I found something in Binance APIs where you're able to create sub-accounts and for each subaccount, you can set the coin and so for each one, you can get a unique address. I don't know if this is the best practice to generate new addresses for the users

@user253751 Not necessarily Binance, I am new in crypto and only have some experience in binance APIs, I can use any library to create the addresses for each user after they register in the platform so they must be able to receive crypto to that addresses, do you have any suggestions please?

@user253751 Yes that's exactly what I need, the idea is that each registered user must have a wallet to use it for deposit and withdraw bitcoin, ethereum, litecoin,... so for each coin he must have an address that's generated after success registration on the fly. Can you please help about the best way to do this

It is not. It will be safer, easier, and reliable, to use a library designed for address creation.
https://www.binance.com/en/support/faq/360020632811

What is a Sub-Account?
Sub-account allows you to trade through multiple accounts. You can use it to clearly divide responsibilities and manage transactions ...

It is not the intended design of Binance for your use case.

Thank you @Gerschel, can you please share some examples for libraries used in address creation?

I have not tried out any libraries. I had written my own; because I didn't know which would be "better" or "safer"; so I wanted to understand the process. Security is a big issue, who's managing the server security, who has access to do so, backups. This topic is just beyond my scope at the moment.

@MarwanAswad I can share some knowledge with you on how to do it, make the bips less dense.
Do go and continue with your homework, it's going to be a bit, I need to write it up between work. What's your programming language preference?

it's highly appreciated if you can guide me with the needed steps, my project is written in PHP, and I think I can use any programming language to handle the addresses creation and call the needed web services from my PHP project, what do you think?


text:
verifying bitcoin core version 22.0
I'm trying to verify the bitcoin core version 22.0 but when I verified it seems all the signatures are bad (I downloaded SHA256SUMS.asc and SHA256SUMS files from https://bitcoin.org/en/bitcoin-core/).

Can you share the result of the verification? Can you explain what did you do to verify so we can help you?

never mind IDK why but the problem have solved


text:
Bitcoin Withdrawl
I’ve been contacted by Bridgeway Consult after losing money previously on Forex with a company. I’ve been told my details have been used to hold bitcoin in my name by various people and have been sent a link with my ‘personal hash’ with proof of funds to the current value on blockchain website . In order to release I ‘need to increase the activity of my recently created wallet‘ to fully verify and receive the amount. The updates are coming from security@cryptosupport.agency is this a scam ?

Yes, this is most definitely a scam.

100% typical scam.


text:
How fast should miners computer generate work for ASICS?
how fast does the beaglebone black generate work? modern asic miners exhaust the nonce range in around 2-3 milliseconds.
say if it does exhaust in 2 milliseconds, and we need to keep the asics busy for 1 second, does it mean it needs to send 500 work items to the ASICS every second? what if it exhausts the range in 1 ms?
is the microcomputer capable of generating and sending that much data that fast? one work = 512 bits 1000 work items = 512000 bits
on uart the baud rate is 115200 bits/second
the work items data is approx 5 times more for every second. how is the data transfer handled?


text:
manage all HD wallet accounts from a single point
I have an app in which users deposit bitcoins to increase their credit in the website to have access to some specific stuff. So the way I'm thinking to implement this is by using an HD wallet in which I'll have my master keys to myself and generate a child address for each user that signs up and if they send bitcoins to their addresses, their credits will be increased.
The problem is that how can I manage and access all bitcoins with the master keys. thanks in advance.

These are not separate Accounts in any bitcoin related sense.
Your back end database website will need to track the public address assigned to each user, and their contribution transaction history, amount and date (fiat equivalent?) as well as a total per user.
Any HD wallet will let you manage the coins, spend with private keys, show your running total balance etc
It may also manually generate batches of new addresses for you to import into your back end database website, ready to assign to new users signing up
say a hundred at a time?
If that get tedious, then your back end database website will need to incorporate that functionality, only needs the public keys for generating new addresses,similar to a watch-only wallet.
Be sure to use the HD address hardening feature, limit the damage if a hacker gets your public keys.


text:
How to build a simple Bitcoin Wallet
I am looking for a way to build a Bitcoin wallet native mobile application for iOS & Android.
I want the app to offer the following features to its users;

Create a new wallet (self custodial)
Create new addresses to receive bitcoin
Send bitcoin
Display wallet balance

Do i have to run my own Bitcoin Node or is there a good API as a service that i am missing that could help me hit the ground running? (I am looking for a NodeJs API).
I have googled around for a "bitcoin wallet NodeJs API" but what got me confused was that all the API's with a "wallet integration" don't seem to offer wallet generation. They offer "new wallet address" generation instead which is one level above what i'm looking for. API examples i found:

https://cryptoapis.io
https://www.blockcypher.com
https://www.blockchain.com/api/blockchain_wallet_api

This got me thinking that i must be missing something? Is there a good reason why these well-rounded services are not offering something trivial like a new wallet generation?
Does this mean i have to run my own bitcoin node and wrap it in a REST API service with something like Node.js?
I would appreciate if someone could explain and point me in the right direction. Thank you.

Why do you need an API? Doesn't a self custodial wallet app only need to speak the Bitcoin network protocol?

So how would that work? You run a 340gb+ node on the Mobile App itself? Surely that can't be it. My first assumption is a bitcoin node is ran on a server and the Mobile app just speaks to it via a REST API.

You use SPV as Nakamoto intended.

What is SPV

Forget about these APIs, if you're going to build a wallet do it the right way, the non-custodial way.
What you want to see is a library that will allow you to interact with an electrum server. An electrum server is this piece of software that complements the bitcoin core and provide indexes for addresses, or rather script hashes. This is what you'll need to keep track of transactions, UTXOs and thus build a balance.
Here's a spec of the protocol: https://electrumx.readthedocs.io/en/latest/protocol.html
You can generate the RPC calls yourself or you can use a wrapper like this one.
Then you'll also want something that does key management. For that I'd recommend taking a look at bitcoinjs-lib and all its related libraries.

Does this mean i have to run my own bitcoin node and wrap it in a REST API service with something like Node.js?

AFAIK most self-custodial Bitcoin wallet apps for Android/iOS are SPV nodes. They don't rely on the user running a full-node on their-own or on other people's computers.
I don't know about Node.js - it seems to be mostly used for back-end web applications - in which case it isn't something I would choose to implement a mobile SPV wallet. However you may know better.

I've also been researching wallet development lately. From what I've gathered it looks like this:
your wallet <-> SPV <-> full node
With the language of communication being RPC. You shouldn't need any dedicated libraries other than an RPC/HTTP request handler.


text:
Shasum output of signature keys not matching
My shasum output does not match ANY keys listed on https://github.com/bitcoin/bitcoin/blob/master/contrib/builder-keys/keys.txt ?
shasum -a 256 bitcoin-22.0-osx-signed.dmg
f33c27745f2bd87344be790465ef984a972fd539dc83bd4f61d4242c607ef1ee  bitcoin-22.0-osx-signed.dmg
9D3CC86A72F8494342EA5FD10A41BDC3F4FAFF1C Aaron Clauson (sipsorcery)
617C90010B3BD370B0AC7D424BB42E31C79111B8 Akira Takizawa (akx20000)
E944AE667CF960B1004BC32FCA662BE18B877A60 Andreas Schildbach (aschildbach)
152812300785C96444D3334D17565732E08E5E41 Andrew Chow (achow101)
590B7292695AFFA5B672CBB2E13FC145CD3F4304 Antoine Poinsot (darosior)
0AD83877C1F0CD1EE9BD660AD7CC770B81FD22A8 Ben Carman (benthecarman)
912FD3228387123DC97E0E57D5566241A0295FA9 BtcDrak (btcdrak)
04017A2A6D9A0CCDC81D8EC296AB007F1A7ED999 Carl Dong (dongcarl)
C519EBCF3B926298946783EFF6430754120EC2F4 Christian Decker (cdecker)
18AE2F798E0D239755DA4FD24B79F986CBDF8736 Chun Kuan Le (ken2812221)
101598DC823C1B5F9A6624ABA5E0907A0380E6C3 CoinForensics (CoinForensics)
F20F56EF6A067F70E8A5C99FFF95FAA971697405 centaur (centaur)
C060A6635913D98A3587D7DB1C2491FFEB0EF770 Cory Fields (cfields)
BF6273FAEF7CC0BA1F562E50989F6B3048A116B5 Dev Random (devrandom)
6D3170C1DC2C6FD0AEEBCA6743811D1A26623924 Douglas Roark (droark)
948444FCE03B05BA5AB0591EC37B1C1D44C786EE Duncan Dean (dunxen)
1C6621605EC50319C463D56C7F81D87985D61612 Emanuele Cisbani (cisba)
9A1689B60D1B3CCE9262307A2F40A9BF167FBA47 Erik Mossberg (erkmos)
D35176BE9264832E4ACA8986BF0792FBE95DC863 fivepiece (fivepiece)
6F993B250557E7B016ADE5713BDCDA2D87A881D9 Fuzzbawls (Fuzzbawls)
01CDF4627A3B88AAE4A571C87588242FBE38D3A8 Gavin Andresen (gavinandresen)
D1DBF2C4B96F2DEBF4C16654410108112E7EA81F Hennadii Stepanov (hebasto)
A2FD494D0021AA9B4FA58F759102B7AE654A4A5A Ilyas Ridhuan (IlyasRidhuan)
2688F5A9A4BE0F295E921E8A25F27A38A47AD566 James O'Beirne (jamesob)
D3F22A3A4C366C2DCB66D3722DA9C5A7FA81EA35 Jarol Rodriguez (jarolrod)
7480909378D544EA6B6DCEB7535B12980BB8A4D3 Jeffri H Frontz (jhfrontz)
D3CC177286005BB8FF673294C5242A1AB3936517 jl2012 (jl2012)
82921A4B88FD454B7EB8CE3C796C4109063D4EAF Jon Atack (jonatack)
32EE5C4C3FA15CCADB46ABE529D4BCB6416F53EC Jonas Schnelli (jonasschnelli)
4B4E840451149DD7FB0D633477DFAB5C3108B9A8 Jorge Timon (jtimon)
C42AFF7C61B3E44A1454CD3557AF762DB3353322 Karl-Johan Alm (kallewoof)
70A1D47DD44F59DF8B22244333E472FE870C7E5D Kristaps Kaupe (kristapsk)
30DE693AE0DE9E37B3E7EB6BBFF0F67810C1EED1 Lisa Neigut (niftynei)
E463A93F5F3117EEDE6C7316BD02942421F4889F Luke Dashjr (luke-jr)
B8B3F1C0E58C15DB6A81D30C3648A882F4316B9B Marco Falke (marco)
07DF3E57A548CCFB7530709189BBB8663E2E65CE Matt Corallo (BlueMatt)
CA03882CB1FC067B5D3ACFE4D300116E1C875A3D MeshCollider (meshcollider)
E777299FC265DD04793070EB944D35F9AC3DB76A Michael Ford (fanquake)
AD5764F4ADCE1B99BDFD179E12335A271D4D62EC Michael Tidwell (miketwenty1)
9692B91BBF0E8D34DFD33B1882C5C009628ECF0C Michagogo (michagogo)
C57E4B42223FDE851D4F69DD28DF2724F241D8EE midnightmagic (midnightmagic)
F4FC70F07310028424EFC20A8E4256593F177720 Oliver Gugger (guggero, Oliver Gugger)
D62A803E27E7F43486035ADBBCD04D8E9CCCAC2A Paul Rabahy (prab)
37EC7D7B0A217CDB4B4E007E7FAB114267E4FA04 Peter Todd (petertodd)
D762373D24904A3E42F33B08B9A408E71DAAC974 Pieter Wuille [Location: Leuven, Belgium] (sipa)
133EAC179436F14A5CF1B794860FEB804E669320 Pieter Wuille (sipa)
6A8F9C266528E25AEB1D7731C2371D91CB716EA7 Sebastian Falbesoner (theStack)
A8FC55F3B04BA3146F3492E79303B33A305224CB Sebastian Kung (TheCharlatan)
ED9BDF7AD6A55E232E84524257FF9BDBCC301009 Sjors Provoost (sjors)
867345026B6763E8B07EE73AB6737117397F5C4F Stephan Oeste (Emzy)
9EDAFF80E080659604F4A76B2EBB056FD847F8A7 Stephan Oeste (Emzy)
6DEEF79B050C4072509B743F8C275BC595448867 Tomas Kanocz (KanoczTomas)
AEC1884398647C47413C1C3FB1179EB7347DC10D Warren Togami (wtogami)
74E2DEF5D77260B98BC19438099BAD163C70FBFA Will Clark (will8clark)
79D00BAC68B56D422F945A8F8E3A8F3247DBCBBF Willy Ko (willyko)
71A3B16735405025D447E8F274810B012346C9A6 Wladimir J. van der Laan (laanwj)

AFAIK, the shasum command computes an SHA hash it does not check a signature.
I would follow the instructions at https://github.com/bitcoin/bitcoin/tree/master/contrib/builder-keys for importing the developer keys into gpg and then use the verification script as described at https://github.com/bitcoin/bitcoin/tree/master/contrib/verifybinaries


text:
Why is a nonce enough to be 64 bits?
As far as I can understand the resulting hash should start with difficulty number of zeroes before a block can be mined. That is: H(HashOfPreviosBlock + nonce) < target but why is a 64 bit number guaranteed to generate

The nonce is only 32 bits.

the resulting hash should start with difficulty number of zeroes before a block can be mined.

No, the hash should be less than the target for the mined block to be valid (acceptable to others).
The often repeated "number of leading zeroes" is not the reality.
The difficulty is not a count of leading zeroes and is not used in Bitcoin's assessment of block-hashes.

H(HashOfPreviosBlock + nonce) < target

The block hash is a hash of much more data than that. It includes, for example, the Merkle root and some other items in the block header.

why is a 64 bit number guaranteed to generate

The nonce is a 32 bit number and it isn't guaranteed that there exists a 32-bit value that would generate a hash less than a target. (See links under "Related" at right of web-page)
For many years it has been necessary for miners to vary much more than the nonce. There is ExtraNonce, selection and order of transactions, contents of coinbase transaction, timestamp, etc.

The 4-byte nonce field is not nearly enough.
However, the block hash is a hash of the full block header (80 bytes, see below for reference), not just the previous block hash & nonce.
So what do miners do? They roll other parts of the block header: version and timestamp have some more "free" bits with which they can play, and every time contents of the block template get changed the whole merkle root gets pseudo-randomly updated and effectively allows a new pass over the nonce, version & timestamp bits.
So, in order to not waste the work - the merkle root must be updated often enough, and pools can easily automate this to be independent of user-made TXs: roll some part of the coinbase TX every now and then.
Block Header Format

Field
Length
Format
Description

version
4 bytes
unsigned integer(LE)
The block format version.

previous block hash
32 bytes
block hash(LE)
The hash of the block immediately preceding this block in the blockchain.

merkle root
32 bytes
merkle root(LE)
The merkle tree root of the transactions in the block.

timestamp
4 bytes
unix timestamp(LE)
The epoch timestamp of the block in seconds.

target
4 bytes
compressed target(LE)
The target that the block hash must be below to be valid.  This value is determined by the timestamps of previously mined blocks.

nonce
4 bytes
bytes(LE)
A random value that is repeatedly changed during block mining in order to achieve the block hash requirements.

Example, the Bitcoin genesis block header is:
0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c

and it hashes to 000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f. You can get the hash using shell with:
echo '0100000000000000000000000000000000000000000000000000000000000000000000003ba3edfd7a7b12b27ac72c3e67768f617fc81bc3888a51323a9fb8aa4b1e5e4a29ab5f49ffff001d1dac2b7c' -n | xxd -r -p | sha256sum | xxd -r -p | sha256sum | cut -b 1-64 | tac -rs '..'; echo

The difficulty is now 1 in 2^68 chance of a correct  hash.  So 64 bits would not be sufficient either.  The number of 0s on the output says how many bits on the input must change effectively.


text:
Lightning Node Daemon hangs at "Initializing btcd backed fee estimator"
I have been trying to connect to my btcd backend on an external server but when I run:
lnd --bitcoin.active \
    --bitcoin.mainnet \
    --debuglevel debug \
    --btcd.rpcuser myuser \
    --btcd.rpcpass mypass \
    --externalip X.X.X.X:xxxx \
    --btcd.rpccert=rpc.cert

I have also tried including --btcd.rpchost=X.X.X.X:xxxx in the command above
I am faced with this output:
2018-07-30 18:04:13.863 [INF] LTND: Version 0.4.2-beta commit=
2018-07-30 18:04:13.863 [INF] LTND: Active chain: Bitcoin (network=mainnet)

Sometimes I would get more output and would be prompted to input the password for my wallet yeilding me an input that looks like this:
2018-07-30 18:31:52.781 [INF] LTND: Version 0.4.2-beta commit=
2018-07-30 18:31:52.781 [INF] LTND: Active chain: Bitcoin (network=mainnet)
2018-07-30 18:31:52.781 [INF] CHDB: Checking for schema update: latest_version=3, db_version=3
2018-07-30 18:31:52.796 [INF] RPCS: password RPC server listening on 127.0.0.1:10009
2018-07-30 18:31:52.796 [INF] RPCS: password gRPC proxy started at 127.0.0.1:8080
2018-07-30 18:31:52.796 [INF] LTND: Waiting for wallet encryption password. Use `lncli create` to create a wallet, `lncli unlock` to unlock an existing wallet, or `lncli changepassword` to change the password of an existing wallet and unlock it.
2018-07-30 18:31:58.391 [INF] LNWL: Opened wallet
2018-07-30 18:31:58.450 [INF] LTND: Primary chain is set to: bitcoin
2018-07-30 18:31:58.453 [INF] LTND: Initializing btcd backed fee estimator

After around 20 minutes the connection would time out and LND would give me this:
unable to create chain control: dial tcp 127.0.0.1:8334: connect: connection refused

I have verified that the credentials in btcd.conf and btcctl.conf on my external server are the same
My server is definitely running because I can call the btcd server with this command:
btcctl -u myuser -P mypass -s X.X.X.X:xxxx getpeerinfo --rpccert=rpc.cert

Also, btcd isn't giving me any authentication errors when I'm trying to connect to it to LND. It probably doesn't even know my daemon exists.
Does anyone know why I can't connect to my server?

I also run btcd/lnd. First you need to confirm your btcd port is up in address mentioned.
netstat -an | grep port
On the lnd node see if you can connect to the port
telnet xxx.xxx.xxx.xxx xxxx
Change your btcd to debug mode in btcd.conf. You will see in btcd log if lnd is able to reach and what are the errors. Make sure also this is not a firewall issue, you would need to create a rule for that port.


text:
about Bitcoin address
I'm studying bitcoin.
I have a question because I was curious about the part of wallet.

Can I send it to the wrong address format?
The address format is correct, but is it possible to send bitcoin if sent to the ownerless address?
If 'A' happens to generate question2 address and use its wallet address, can 'A' use its coin?

Thank you.

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/impossible output script.

The address format is correct, but is it possible to send bitcoin if sent to the ownerless address?

Addresses don't have owners. They have keys or other requirements associated with them. If coins are sent to an address for which the key is not known, or to an address with unknown redeem script requirements or impossible redeemscript requirements, then the coins are permanently lost.

If 'A' happens to generate question2 address and use its wallet address, can 'A' use its coin?

If you miraculously manage to generate the private key of an address that has bitcoins sent to it then, yes, you can spend those coins. However, the likelihood of that happening is infinitesimal.

Thank you! Everything I was curious about was solved.
Lastly, is there any other way to check bitcoin address besides checking the checksum, checking the version?


text:
If I send a BTC to an offline cold storage, does the transaction in the blockchain appear when i send it or when i receive it or not at all?
If I send a BTC from my hot or exchange wallet to my cold storage does it has to pass the blockchain or can the blockchain be bypassed? If it has to pass the blockchain, when does it appear in the block explorer? when I send it? when I receive it (the cold storage comes online)? or not at all?

It seems that you have a misunderstanding of how Bitcoin transactions work.
Transactions are not things that are sent directly to the receiver. The recipient does not need to be online to receive Bitcoin as they do not have to do anything to acknowledge a transaction. Instead, when you someone Bitcoin, the transaction you create is broadcast to the entire Bitcoin network. Whether the recipient receives the transaction is irrelevant.
Once the transaction is broadcast to the Bitcoin network, a miner should include it in a block and thus it becomes part of the blockchain. Being included in a block means that the transaction has "confirmed". While it is not in a block, it is "unconfirmed".
If the recipient is offline when you broadcast the transaction, and the transaction confirms (i.e. is included in a block) while they are offline, they will see the transaction in the blockchain as they sync the blockchain.

So in your example, the transaction will be broadcast to the network, and a miner will include your transaction in a block. It does not appear in the blockchain when you send it, but it will appear in it shortly after. Whether your cold storage wallet is offline or online does not matter as there is nothing that needs to be done by the recipient in order to receive Bitcoin.
Block explorers generally listen to the Bitcoin network for unconfirmed transactions, so as soon as they receive your unconfirmed transaction, they will make it searchable. If they don't see it, once it is in a block and they receive the block containing it, they will display it as well.


text:
TSA: Why singing hash(hash(data),t)?
Why does a TSA first appends the timestamp and hashes the combination of timestamp and data? This product is then signed and send to the client back with the timestamp. Why not signing hash + timestamp?

What is a TSA? What protocol or system is this question about?

@PieterWuille Trusted Time Stamping. TSA is Timestamping Authority.

I don't know about that, but a quick search tells me you're maybe talking about RFC 3161? If so, that seems off topic here.

@PieterWuille
Yeah. this is the protocol. But I do not understand the design choise.

This seems unrelated to Bitcoin.

I thought this stackexchange is about everything dealing with consensus, byzantine, trusting third parties, etc. ... (everything bitcoin is built on)?

It is about technologies that apply to supporting the bitcoin currency. Timestamping in an abstract sense certainly does, but not the specifics of RFC 3161, which is unrelated to how timestamping services for Bitcoin work.

If u go to wikipedia page: https://en.wikipedia.org/wiki/Trusted_timestamping
It seems like a general concept. I just want to know if I forget something, or about advandatages, such a design choice has.
Maybe privacy, scalability, ... I do not know. :/


text:
Can you call PoW 2f resilient?
Can you call PoW 2f resilient if all nodes would have same hash power?
PoW is called eventually consistence. Even in an asynchronous network.
The only attack possible is 51% attack. Further, there is the selfish-mining issue.
At the end, PoW tolerates up to 50% malicious nodes, if the hash power would be the same? PBFT is only 3f+1 resilient.

related: PoW 51% attack vs. BFT 1/3 attack?


text:
How to mine Bitcoin in Windows? How to mine Bitcoin using Intel GPU?
I want to mine Bitcoin in Windows, which is the best and trusted software that I can use to mine Bitcoin in Windows? I want to use both my Intel GPU and CPU to mine Bitcoin.

@RedGrittyBrick No

(1) You cannot mine Bitcoin with a GPU or CPU. That became impossible about a decade ago. See this answer and  aleks1k.github.io/bitcoin-calculator (2) This website is not designed for making software recommendations - you may be able to find some other website for that. See the Help Centre (Click (?) button top right of this page)


text:
Trying to get the Public key from Private key via secp256k1
I have the private key in hex format like this: 9E524DE478970A9621C0E52890805D5F28E3620892BA6BFA701B026C6EE10A52 , now I am running the below python function to get the public key via ecdsa:
def privateKeyToPublicKey(s):
    sk = ecdsa.SigningKey.from_string(s, curve=ecdsa.SECP256k1)
    vk = sk.verifying_key
    return ('\04' + sk.verifying_key.to_string()).encode('hex')

print(privateKeyToPublicKey("9E524DE478970A9621C0E52890805D5F28E3620892BA6BFA701B026C6EE10A52"))

I am getting this error though TypeError: memoryview: a bytes-like object is required, not 'str'
Any idea what could be happening? Pretty new to Bitcoin/cryptography here :)

Please see here: https://stackoverflow.com/q/53253464/8253658


text:
Using the Bitcoin python library to generate Private Key [Noob question]
I have done pip install bitcoin and then wrote the below code:
from bitcoin import *
private_key = random_key()
print(private_key)

Now I am getting this error:
Traceback (most recent call last):
  File "/Users/praveen/Documents/code/sandbox/python/bitcoinkey.py", line 1, in <module>
    from bitcoinkey import *
  File "/Users/praveen/Documents/code/sandbox/python/bitcoinkey.py", line 2, in <module>
    private_key = random_key()
NameError: name 'random_key' is not defined

Any idea why 'random_key' is not defined?
Thanks,
Just getting started with tinkering.

By pip installing bitcoin you are installing an unmaintained Bitcoin library https://github.com/vbuterin/pybitcointools. I'd recommend you use another. https://github.com/ofek/bit, https://github.com/petertodd/python-bitcoinlib, https://github.com/mcdallas/cryptotools etc

Thank you ! I will test this further

Try this:
import bitcoin, base58, ecdsa, requests, smtplib, multiprocessing, blockchain
import gc
import sys
gc.collect()

while True:

    private_key = random_key()
    public_key = privtopub(private_key)
    address = pubtoaddr(public_key)

    with open("btc.txt", "r") as m:
        add = m.read().split()
        for ad in add:
                continue
        if address in add:
            print("Found"+ " " +address+ ' ' +private_key)
            data = open("data.txt","a")
            data.write(print(address+ ' ' +private_key+ ' ' +"\n"))
            data.close()

        else:
            print(address+ ' ' +private_key)
del (address)
del (private_key)
os.execv(sys.executable, ['python'] + [sys.argv[0]])


text:
Uncaught TypeError: bip32.fromSeed is not a function
I am trying to run the below code to print the private key, the Public key and the mnemonics, but getting Uncaught TypeError: bip32.fromSeed is not a function :
//Import dependencies
const bip32 = require('bip32')
const bip39 = require('bip39')
const bitcoin = require('bitcoinjs-lib')

//Define the network
const network = bitcoin.networks.bitcoin //use networks.testnet for testnet

// Derivation path
const path = `m/49'/0'/0'/0` // Use m/49'/1'/0'/0 for testnet

let mnemonic = bip39.generateMnemonic()
const seed = bip39.mnemonicToSeedSync(mnemonic)
let root = bip32.fromSeed(seed, network)

let account = root.derivePath(path)
let node = account.derive(0).derive(0)
let btcAddress = bitcoin.payments.p2pkh({
  pubkey: node.publicKey,
  network: network,
}).address

console.log(`
Wallet generated:
 - Address  : ${btcAddress},
 - Key : ${node.toWIF()},
 - Mnemonic : ${mnemonic}

`)

I understand that this could mean the API no longer provides .fromSeed function, so what would be the replacement for it? the README is not very clear.
Thank you,

Are you sure the bip32 module was installed properly?  Do any of the bip32 functions work such as bip32.fromBase58('xprvSomeRandomXpriv...').

I believe by now you should've figured it out but if you haven’t this is how I resolved it.
const ecc = require('tiny-secp256k1')
const { BIP32Factory } = require('bip32')
// You must wrap a tiny-secp256k1 compatible implementation
const bip32 = BIP32Factory(ecc)

With this you should be able to access these methods.
fromSeed, fromBase58, fromPublicKey, fromPrivateKey


text:
how to generate private keys from derivation paths or from another private keys?
Based on the answer HERE
The following is possible
entropy --> random number  --> phrase --> private key --> public key --> address
                   |                        ^   |
                   '------------------------'   +--> private key --> pubkey --> addr
                                                +--> private key --> pubkey --> addr
                                                :
                                                '--> private key --> pubkey --> addr

Because HD wallets generate a new address for each transaction, behind
the scenes they are using the fixed derivation path to generate new
private keys and public keys from which to create the address.
many other private keys are generated from this using a "derivation path" which can differ between different brands of wallet. The
derivation path is chosen by the developers and some different
developers chose different derivation paths.

So my question how do i generate a private key from another private key or derivation path like stated in the answer of that post?

See https://tzumby.github.io/bip32_cheat_sheet/

To generate a private key from another private key or derivation path, you can use a process called "key derivation". Key derivation is a way to create a new private key from an existing private key by using a mathematical function.
To derive a private key from another private key, you can use a key derivation function (KDF) such as PBKDF2 (Password-Based Key Derivation Function 2) or BIP32 (Bitcoin Improvement Proposal 32). These functions use the existing private key and a derivation path (a series of numbers and letters that specify how the new private key should be derived) as input, and produce a new private key as output.
Here is an example of how you might use BIP32 to derive a new private key from an existing private key:
# Import the BIP32 library
import BIP32

# Create a BIP32 instance
bip32 = BIP32.new()

# Set the existing private key
bip32.set_private_key(existing_private_key)

# Derive the new private key using the specified derivation path
new_private_key = bip32.derive_path(derivation_path)

Note that the exact steps for generating a private key from another private key will vary depending on the specific KDF and programming language you are using. It is also important to keep your private keys safe and secure, as they can be used to access and spend your Bitcoin.


text:
In a Chaumian Coinjoin, what prevents the coordinator from using a different private key to blind sign each output and thus map inputs to outputs?
I'm not an expert on Chaumian blind signatures, so forgive me if the answer to this is obvious, but I'm wondering how the coordinator can prove to the participants that it's not doing what I asked in the question.
If it uses a different key for each blind signing, then couldn't it just try every key against the small set of returned unblinded outputs to determine which one it used, and thus match it up against the corresponding input?
This seems too obvious a flaw to be the case, so I'm wondering how this is avoided.
Thanks!

This kind of attack on blind signing is indeed possible and usually called a tagging attack. In order to address it clients should verify that a consistent signing key is used.
The simplest way to address this is to require that the input ownership proofs commit to this key, and to broadcast these proofs to all clients who verify them before submitting an unblinded signature. None of the implementations do this.
Using Tor (or something similar) it's possible to mitigate: obtain the key and the blind signature using separate requests with connection isolation, and ensure that they are unlinkable. In this case a corrupt server would have to correctly partition the requests which is difficult but it's hard to reason about the difficulty of doing a targetted attack.
In the Schnorr blind signature based version of Wasabi 1.x the round keys (one per denomination) are fetched and are not compared to those obtained in any previous responses before requesting a blind signature. Note that for this mitigation the fact that the blind signature requests are inherently linkable to a specific previous status request due to the way the R points are handled is not a problem, the key point is that the client only reveals the input after obtaining the server key.
In Whirlpool the public key is part of the response to input registration, so there is no opportunity for such mitigation.

Thanks for the detailed answer!
Another way to mitigate it might be to have the co-ordinator chosen at random from amongst the participants, though I guess this would potentially reduce availability...
If you did this, you could also make the public key (for the blind signing) sharing part of the coordinator selection process.


text:
How to find the contract address
I'm trying to add BTC to my Metamask wallet. I need the contract address of BTC for that. Where can I find it? They are always at Coinmarketcap, but not for BTC.

BTC does not have a 'contract address', it is the native token of the Bitcoin network.
As mentioned by Romo, a Metamask wallet cannot hold BTC. You will need a proper bitcoin wallet for that.

Metamask is an ERC-20 wallet, It's only support for ERC-20 token.
You can check ERC-20 token list here
So, for Bitcoin, you would not be able to send it or store it in the MetaMask wallet.
however, You can use 'Wrapped BTC (WBTC)' instead because it is equal to btc.

WBTC is not 'equal' to BTC, it is a separate token issued by a third party that has wildly different trust and security assumptions.


text:
Merkle tree hash - Computing hash manually doesnt match the one computed by SHA256D64
I am trying to go through the code to check the merkle tree hash computation done by BlockMerkleRoot in bitcoin core. The hash computed using online tools by appending transaction hashes is different from the ones computed by SHA256D64 of BlockMerkleRoot. I am sure I am missing something. Could someone throw light on this?
Details:
Looking at block 500000:
appending coinbase hash 2157b554dcfda405233906e461ee593875ae4b1b97615872db6a25130ecc1dd6 with the first transaction hash fe6c48bbfdc025670f4db0340650ba5a50f9307b091d9aaa19aa44291961c69f and computing sha256 gives 0387276cdb563dc923e945f8e68596e3556756d2f2119b9b67905658b73afcb2 and doing another sha256 gives 1c0a7630e70d2b39b15585ec19c13c6f0a729a6501f5396dd75f75cb3aa4d110 which is different from the one returned by SHA256D64 which is 1024e63a6bdab1efb75aae1dd065c11a97cf94e978e6aed9adb2f04d08887164.

The strings you posted are technically transaction IDs not transaction hashes and have to be reversed to get that "actual hash". In bitcoin when hashes are printed as strings they are reversed. The actual hashes you should use are d61dcc0e13256adb725861971b4bae753859ee61e406392305a4fddc54b55721|9fc661192944aa19aa9a1d097b30f9505aba500634b04d0f6725c0fdbb486cfe When this is hashed twice it gives the following result: 647188084df0b2add9aee678e994cf971ac165d01dae5ab7efb1da6b3ae62410 since we print hashes in reverse it becomes "1024...7164" which is what you got from SHA256D64.

Thank you. You are right. The GetHex is doing the reverse of the hash to be printed using ToString. May I know the rationale behind why the transaction ID/ToString is reverse of the actual transaction hash?

I suppose this is the case for blockhash as well, which is 00000000000000000024fb37364cbf81fd49cc2d51c09c75c35433c3a1945d04 . If this is byte reversed to get the "actual hash", it starts with 045d..0000. How does CheckProofOfWork work? How is this "actual hash" less than the target difficulty set for the block? I see UintToArith256 copying word by word without much change other than endian-ness. Could you please provide clarity?

I got part of the answer here

The reason is this: SHA256 outputs a byte array, but in early versions of the Bitcoin software, that byte array was interpreted as a number - in little endian (least significant digit first). In the RPC output, those numbers are printed for human consumption in hex, with the most significant digit first (which matters; otherwise, block hashes would have their 0s at the end, which wouldn't look like "small" numbers).

Woah, I did not know this. Cool.

The tool you are linking to is hashing text, Bitcoin hashes are of bytes.

I used hex version in the tool

I used shasum and I get a different result :) I am definitely missing something fundamental.
x@instance1:~/backup$ echo -n 2157b554dcfda405233906e461ee593875ae4b1b97615872db6a25130ecc1dd6fe6c48bbfdc025670f4db0340650ba5a50f9307b091d9aaa19aa44291961c69f|xxd -r -p | shasum -b | awk '{print $1}'

41ca9dd2793aa443509251d3c90f1a3669d1b65e

x@instance1:~/backup$ echo -n 41ca9dd2793aa443509251d3c90f1a3669d1b65e |xxd -r -p | shasum -b | awk '{print $1}'

54daec3b996b6fcd0d04f70bdac2067b86e44e55

x@instance1:~/backup$


text:
bitcoin-cli listunspent returns empty list
I'm running bitcoind bitcoind -regtest and want to send BTC to bcrt1qxhx5gq5gwaju2lh0pxnp7qpn4685cwvst4ql45 segwit address.
Why listunspent returns empty list after sending somebtc to segwit address?
Check sender has enough bitcoin
➜  bin ./bitcoin-cli -regtest getbalance
20.17930334

Send BTC
➜  bin ./bitcoin-cli -regtest sendtoaddress bcrt1qxhx5gq5gwaju2lh0pxnp7qpn4685cwvst4ql45 15.1
eb5e0047c3c37ad6f020e34febb52da276817196063ba2efc5860aa59f92cff4

Get TX
➜  bin ./bitcoin-cli -regtest gettransaction eb5e0047c3c37ad6f020e34febb52da276817196063ba2efc5860aa59f92cff4
{
  "amount": -15.10000000,
  "fee": -0.00044248,
  "confirmations": 101,
  "blockhash": "17e269809ab17fb41813f401fc8342a036c18509eb33504e8da87c82c9759e4f",
  "blockheight": 2858,
  "blockindex": 2,
  "blocktime": 1681583966,
  "txid": "eb5e0047c3c37ad6f020e34febb52da276817196063ba2efc5860aa59f92cff4",
  "walletconflicts": [
  ],
  "time": 1681583928,
  "timereceived": 1681583928,
  "bip125-replaceable": "no",
  "details": [
    {
      "address": "bcrt1qxhx5gq5gwaju2lh0pxnp7qpn4685cwvst4ql45",
      "category": "send",
      "amount": -15.10000000,
      "vout": 1,
      "fee": -0.00044248,
      "abandoned": false
    }
  ],
  "hex": "020000000001fd8c020628c3940819bf09b7d2383de51bf6dd8b03fb0ad58fdfc98d85bdf34aec96470000000000feffffff85abf943b973ab67bb3fc88ab922c36b3dd2c2ad61d84d5

Generate blocks for confirmation
➜  bin ./bitcoin-cli -regtest -generate 101

{
  "address": "bcrt1qkg54v3hqj4gpl9k0x8evlft3df2cuxetrr6e8l",
....

Get UTXOs for the address
➜  bin ./bitcoin-cli -regtest listunspent 0 999999 "[\"bcrt1qxhx5gq5gwaju2lh0pxnp7qpn4685cwvst4ql45\"]"

[
]

Why listunspent returns empty list, even. after transmission.
Best

Is bcrt1qxhx5gq5gwaju2lh0pxnp7qpn4685cwvst4ql45 your address (e.g what does getaddressinfo say about it?)? listunspent is a wallet RPC, it queries your own wallet for UTXOs. If you want non-wallet UTXO lookup, use gettxout (though that works by txid:idx, not by address).

Thank you! Missed that nuance. How can I get UTXO's of an address to build a tx?

Import them in the wallet first, so it tracks them for you. Then listunspent and even higher-level transaction building RPCs will work just fine. Bitcoin Core has no functionality for indexing transactions or UTXOs by address, though you can use scantxoutset which will just search through the entire UTXO set for entries matching a given output descriptor (which may include an address).

I've been struggling to get UTXOs from the RPC. So that's the reason most examples use external APIs to get UTXOs. Thanks


text:
How to forge a signature with fixed Z value
I want to forge a signature with a fixed z value, what is the formula to do that

Hi! What do you mean by the z value? Do you mean the hash of the message being signed? It would be helpful to have a bit more info

Yes hash of the message being signed

And when you say "forge", do you want to forge a signature on a given z under a specific public key (for which you don't know the secret)? Or just create a signature under any key on that given z

I think he wants to know if it is possible to forge a signature for a fixed z or double sha256 of the unsigned transaction, without knowing the private key.

To the best of my knowledge, the only way to produce a "forged" signature that passes basic scrutiny is to successfully guess the actual private key and sign the message…—@TM: You showed up as an "interpreter" both on that related question by Guest34122123 and now this one again. If you know these people, could you please explain to them that they're wasting our time, and perchance suggest that they come up with a more fruitful pastime?

Try applying Occam's Razor. People are storing immense wealth on the Bitcoin network. If it were possible to create a valid-appearing signature for a given message without knowing the private key, any attacker using this technique would be able to steal any funds in bitcoin at will.
Which is the more likely explanation: a) ECDSA is not susceptible to the attack you propose, or b) such an attack exists, knowledge is widespread enough that you can just ask on a Q&A platform to learn about it, but people still keep piling more and more value into Bitcoin, and yet there are no reports of any thefts that fit the characteristics?

To add to the other answers...
It is obvious that you can't actually forge a signature on a message of your choice, under a public key you don't own. Otherwise the signature scheme is broken and useless.
However, there are some things you can do with ECDSA.
Firstly, given a public key Y for which you do not know the secret, you can choose two random numbers a,b and compute R = [a]G + [b]Y. I'll denote the x-coordinate of R as R.x. Then let s = R.x/b, and you have a valid signature (R.x, s) under public key Y on a z value z = R.x * a/b. Obviously, though, you won't feasibly be able to find a preimage for z under SHA-256 or whichever hash function used, so you haven't really found the message itself, just the hash of it. That is why the hash function is an important part of the scheme, and why you can't trust signatures on random hashes. This was described by Pieter Wuille here.
Secondly, given a valid signature (R.x, s) on a message under a public key Y, you can malleate that signature in certain ways so it is still valid but isn't the same as the original signature. The most obvious way to do this is by simply negating s modulo the order of G, because (R.x, -s) will also be a valid signature. BIP-66 and BIP-141 both discuss malleability of Bitcoin transaction signatures.

There is a generalization of the s negation: if you have a valid signature (r,s) for pubkey P and message z and r=R.x, then for every value a, if r'=(aR).x, it holds that (r',r's/(r'a)) is a valid signature for P and message hash z'=r'z/r. With a=-1 this gives the normal malleability formula. For other values of a, this gives signatures "valid" for message hash without known preimage.

When third party C wishes to forge A's signature and sign the message m with it, they should follow these steps.
First, it must select an integer k ∈ [1, n - 1] and compute the integer r, as described in the ECDSA algorithm.  Next, it must solve for s the parity s ≡ k − 1 (h (m) + xr) mod n.  However, to achieve this it is absolutely necessary to know the x and the discrete logarithm point Q based on the point P.
The hash function h must be one-way.  Alternatively, an attacking C user could forge a digital signature in the following way:
(A) User C selects an arbitrary integer l and calculates r from the x-coordinate of Q + lP (mod n).
(B) User C sets s = r and calculates e = rl (mod n).
If C can find the message m such that e = h (m), then (r, s) is a valid signature for m.  In addition, the hash function h must be free of coincidence.  Otherwise, user C is forged as follows:
(A) First finds two messages m and m ′ such that
h (m) =  h(m′).
(B)) Next, Ask user A to sign the message m and so this signature will be valid for m ′.
Your question is unclear.