text:
Who determines a hard fork
I'm trying to really get a deep understanding of the roles miners and nodes play in enforcing the Bitcoin rules.
If a hard fork is presented, who determines if the fork is accepted, nodes or miners? I was under the assumption that it would be nodes since nodes verify the data. A friend was telling me that miners also get to determine what rules are enforced.
Can someone explain to me in plain speak the roles the two of them play in enforcing rules?
Additionally how does one technically propose a Hard fork, does an individual literally change the code on their Bitcoin Core pacakge and try to have it accepted by the network?
Thanks!
Jon


text:
Bitcoin mining in 2011 recovery
Help me to understand. in 2011 he tried to mine bitcoin. I can't remember exactly how I did it. I accidentally found these folders where did I get them from and what should I do with them?

You have an item named multibit.
There used to be a wallet named Multibit
It was discontinued and replaced by a product named Multibit HD
The Multibit HD product was then discontinued and the business closed. This happened many years ago.
If you search this website for "multibit" you will find answers to questions about recovering control over money by transferring Multibit wallet contents (keys) into a different Wallet application.

So, if you're wondering whether you've successfully mined BTC as far back as 2011 and would like to recover your funds, there could be a way. However, you would need to remember the password that you created when you first used the Multibit classic wallet. If you do remember the password, you can then check the 'key-backup folder' for key files that have names which look like 'walletname-20140407200768.key.'
If you have these two components, you can recover your address and the private key that controls your wallet using various open-source scripts like FinderOuter and BTCrecovery.

source: Stack Exchange

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

sort: votes


text:
Bitcoin lightnode not return private key for getnewaddress
I have run a bitcoin lightnode (bitcoind)
I use getnewaddress for create new wallet:
bitcoin-cli getnewaddress

This method return to me only wallet address.
How can I access to private key of this address?

What do you mean by "lightnode"?

@RedGrittyBrick I don't use fullnode.

@user140323 Bitcoin Core (bitcoind) only supports full node operation.

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


text:
Calculating hashrate from stratum messages
Interested in validating algorithm for calculating hashrate from stratum messages.
From my understanding following data is needed:
start_time , time when miner started calculating
end_time, time when share from miner was found
difficulty, set by the mining pool
Formula for calculating hashrate(found online) is:
hashrate = difficulty * 2**32 / (end_time - start_time)
Example:
difficulty is 131072 from {"id":null,"method":"mining.set_difficulty","params":[131072]}
(end_time - start_time) is 8.844114780426025 from one real test example
Calculation:
131072 * 2**32 / 8.844114780426025
131072 * 4294967296 / 8.844114780426025
562949953421312 / 8.844114780426025
Hashrate: 63652492917351.58  or  around 63 Th/s
Questions:

Is this correct ?
What is 2**32 ? (suspect that it is connected to nonce in block header)

After 2 months, I know more.
Formula is correct for calculating hashrate of one share.


text:
When was first bitcoin transaction with fees?
This is history question, but one with clear answer.
I would like to know when(txid) was first transaction with fees ? From my understanding in beginning there was more space than transaction so there where no fees.
Additional, if anybody knows, block when at least 50% of transactions had fees ? Maybe this is better metric, because probably somebody has done some transaction with fee on main-net for fun/test.

The first block with transactions that paid fees was  block 2817, the second was 12 983. To answer your question, I used blockchair.com’s block overview, sorted the blocks by ascending height and filtered for a fee of at least one satoshi.

The three transactions that paid fees in block 2817 were:

5b62efcc…1c2902c2
65f75ac6…e16306c9
f8bf1e88…3e058eb2

I don’t have an immediate way to answer the question about half the transactions paying fees.

Incidentally, the first block with over 50% of transactions paying fees is also block 2817, because the three transactions are the only transactions in that block (except for coinbase).

Touché, you’re right. I guess I just automatically extrapolated the question to mean the first full block that had 50% txs paying fees, but that was in fact never asked. :)

@Murch  "block when at least 50% of transactions had fees ?", my idea was to know when at least 50% of transaction had to pay fees to be included in block and never went under 50%. But then I should also add that block need to be full and it is getting complicated. To get some idea when fees became "mandatory". But it is not so important.

Maybe this will help: https://transactionfee.info/charts/fees-package-feerates/?start=2010-10-03&end=2011-06-17, the chart seems to show that a 50th percentile for feerates appeared end of 2010.


text:
Binance API and Unity. Game involving depositing crypto and withdrawal
Hi if i need to allow players do deposit x crypto in my game. Use this deposited crypto and convert it to BUSD and use this as "token"to play games. And after winning, you can earn reward that will increase the amount you have and can be withdrawn in any crypto you want. How can i do this? I am using unity and binance api

I would advise against using BUSD or anything Binance affiliated right now as they are very likely under a liquidity crunch and in general have not been able to back up a lot of significant funding numbers on their platforms.

https://www.youtube.com/watch?v=2mX-luVDxCg
https://www.youtube.com/watch?v=3ca-hQ4rjAQ

They also generally rely on over-leveraged "altcoins" getting liquidated (users losing their investment) for income, overall sketchy platform IMO.

Also as @Saxtheowl has mentioned it is not Bitcoin related AT ALL so if you do intend to use their shady products you should discuss it on a message board dedicated to that specific protocol ( if such a thing exists ).

you are talking about BUSD which is a stabble coin that are not linked to bitcoin, you should see which blockchain use BUSD and how to use it, or better check the lightning network which is a bitcoin second layer which will allow what you want to want with BUSD but using bitcoin


text:
My multibit core synchronization is stuck Whats the reason
For the past six days since I downloaded the multibit core, I wanted to recover my wallet I still have my recovery phrase and password, and open the multibit core and the wallet was synchronization very slow and got up to 86% and was stuck for days now it’s still hasn’t added any percentage
Please what’s the caddie of this issue and how can I resolve it, it’s now six days since I started synchronization

"What's the reason?" -- the reason for this is downloading fake software designed by thieves to steal your money. I would only select software listed by a reputable source such as bitcoin.org "choose your wallet"

Please regard this post: Question about Multibit Core wallet - not sync
for advice on how to deal with your malware.
Specifically:

I hope you didn't receive any funds to addresses generated with "Multibit Core". You should treat this piece of software with caution and probably get rid of it as thoroughly as you can. -Murch


text:
How to send a Bitcoin transaction only using the seed phrase using NodeJS?
I am working on a NodeJS script that allows you to enter your 12-words-long Bitcoin secret recovery phrase and automatically withdraw all of your coins to a defined wallet address.
The script is for people like me (with a hundred paper wallets) to withdraw their funds quickly to one wallet without restoring every wallet by hand.
How can I do this? I did some research myself, but it seems impossible.

This is possible with bcoin, a NodeJS bitcoin library that supports mnemonics, private keys, tx construction, etc... but you will still need a full node (or blockexplorer API) to get the UTXO you can spend with your key. Also, keep in mind handling seed phrases or typing seed phrases into anything is fraught with risk and you should be very careful the tools you choose to do this.
Anyway, I have an applet called brainsweeper (source code here) that does the second part of your question, using bcoin: it uses the blockstream.info API to get UTXO associated with an address, constructs a transaction that sweeps all the UTXO to a new address, signs it and the uses the blockstream.info API again to broadcast the completed TX.
If you need help using bcoin there is a discussion channel on telegram


text:
Setting up to create PSBTs using Bitcoin Core from 10 year old non-deterministic wallet
I have an old wallet from 10+ years ago. It was created using an old version of Bitcoin Core before deterministic wallets were a thing. I have it now on an offline computer that has Bitcoin Core 21.0.0 on it. I installed Core 21 and synced the computer before loading the wallet a couple of years ago and haven't synced it since, but also haven't done any transactions with the UTXOs in that wallet since then either. When I loaded the wallet after syncing the computer, the balance for the total wallet was what I was expecting.
I have set up another computer with Bitcoin Core 24.0.1 on it. My plan is to set up a watch only wallet on this computer, bring in the public addresses from the old wallet and create PSBTs (using coin control) on the watch only wallet, which I will then transfer for signing on the offline computer. And then bring back the signed PSBTs to broadcast from the online computer.
My concerns are :

Will there be any issues with bringing over what I need for the watch only wallet on the Core 24.0.1 computer from the old non-deterministic wallet which was created with a very old version of Bitcoin Core (even though it's now operating under 21.0.0) ? And what exactly do I need to bring over ?
Do I need to be careful with change addresses ?
Is there anything else I need to worry about, and/or should I be going about this a different way ?

Thank you in advance.

What prevents you from simply creating the PSBT on the 0.21 node? I assume you intend to sweep your coins to a more recent wallet?

Good question. I've done a little reading and found this Q&A where @AndrewChow described how bitcoin-qt only allows creating a PSBT on a 'wallet with private keys disabled' (i.e. watch only wallet). So that's why I'd planned to do it the way I outlined above. But I guess you're suggesting that I do it all on the 0.21 node using the command line instead, where there's perhaps that ability ? If that's the case then I'd be open to doing it that way. What are the commands involved ?

Depends. What are you trying to achieve? Sweep all your coins? Any constraint?

I want to initially move all coins in just one address (one UTXO) to an exchange. (So aim there would be to not generate any change, as that might complicate things on such an old wallet, I think?) But I also want to start sweeping all the coins from the old wallet into a deterministic wallet (which I should have done long ago).

One way of achieving both is to upgrade to Bitcoin Core version 24.0.1 and to use the migratewallet command. Make sure to backup your wallet beforehand. See https://github.com/bitcoin/bitcoin/blob/master/doc/managing-wallets.md#migrating-legacy-wallets-to-descriptor-wallets. Then you can use the sendall command to sweep the wallet to a single address. (Be aware of the privacy implications of merging all your coins into one.) Note you may be able to use sendall without migrating the wallet. I'm just mentioning the migration because you said you'd like to migrate to a modern wallet.

Thank you for that info. Will read up on the migratewallet command, which I was previously unaware of. And I see now that I've used the wrong word in my reply above. I actually don't want to sweep all the coins in the old wallet to one address, due to privacy concerns as you mention. I meant there that I want to move all the coins into a deterministic wallet, but keep the coins in separate (new) addresses, as they were in the old wallet.


text:
When does chainstate get updated?
What i'm trying to do now is reading LevelDB at chainstate folder to save all utxos at my own DB, and keep tracking the changes of utxos by looking at chainstate folder frequently.
However, what i found is that it seem like chainstate folder didn't get any update for a week and utxo set stays the same.
Does chainstate folder get update? If so, when?

Hi Jin, I’m wondering whether this is an x-y-problem. It seems to me that the topic you are actually interested in might be “How can I keep an up-to-date database of the UTXO set”? If so, it might be useful to ask that question directly in another topic.

That's correct! Thanks for your consideration.

The chainstate gets updated every time a new block gets added to (or deleted from) the chain, so you should be seeing it changing for every new block. However, updates are only seen on disk when a flush happens, which may not be after every block (added this last borrowing from @PieterWuille's comment)
If you're not, it may be the case that either:

Your node is not running, or
You are grabbing data from a copy of the chainstate that does not match the one being used by your node

I'd check either or both by checking the logs (debug.log). The folder that is being used should be reported in one of the first lines logged when running the node.

Updates to the chainstate are not immediately written to disk, though; only when a flush happens, which is not necessarily after every block (but I do believe it's at least once per day).

@PieterWuille a minor follow-up: Would it be possible to force a flush? I know some RPCs trigger it, like gettxoutsetinfo. But there's a way to make it directly? Or perhaps change how often it happens.


text:
About missing utxo in chainstate
I'm trying to obtain up-to-date database of the UTXO and keep updating it as new block is added.
And for this, I want to use chainstate as a starting point of synching.

I parsed chainstate to obtain remaining utxo at 784468th block, and put them in DB.
The problem I have right now is this.

I checked the transactions' vin at the next block (784469th), and checked whether utxos used in the next block are present in my DB. However, there are about about 50 missing utxos in DB that were definately created before 784468th block and used at 784469th block.

I really want to know why this happens.

The parse tool that I'm using is here. https://github.com/in3rsha/bitcoin-utxo-dump

Can you be more specific? Like pointing out what data is supposed to be missing?

Did your node follow a reorg?

@sr_gi For example, vin of transaction at the next block should be present in the chainstate of the current block. However, some vin are missing in the csv file that I got from parsing the chainstate.

I found this comment in one of the issues:

Sorry that I was too concise. dumptxoutset output is just binary, but I thought it could be used as a first step of bitcoin-utxo-dumo instead of reading the chainstate and avoiding the issue "This tool may corrupt your chainstate database"

It suggests to me that this tool corrupted your DB because it was not using the suggested binary method included in core.
https://github.com/in3rsha/bitcoin-utxo-dump/issues/43#issuecomment-1491621118


text:
LND per-commitment-secret derivation
For learning purposes I'm trying to recreate all keys in LND channel.
I could reproduce MultiSigKey, RevocationBasePoint, PaymentBasePoint, DelayBasePoint, HtlcBasePoint. The workflow to reproduce them was to create HD node root key with azeed from 24 words and then use HD Wallet BIP44 specification to calculate these keys with defined paths.
My HD node root key (base58): vprv9DMUxX4ShgxMLHkP4A7EPJr52LoHYn5jD6vn3UfQnf6Tv1uA7mw3RozDzwD2vMxs5MWLAPENaxYvrDERFdARSQLa6RXWBih5bjRqh5hsfJr
(derived from:
words_local = 'above tomato swarm square ski frame remain buffalo aerobic ginger reduce insect kiwi kitchen antenna elevator century brave boil gospel gas picnic weather basket')
For example I can successfully derive RevocationBasePoint with path "m/1017'/1'/1'/0/0"
032a1e4b9ba2db7bcdee19cfb6cd9b285af0b99723f401e72990e278ea029a07e3
(the real keys I got reading channel data with chantools from guggero).
However I cannot derive the Per-commitment-point, which should be:
0346d482f460d2a2e53db6c1f2cf06cfcf2d2151088787a4a7637ed35552a22767
I've implemented per-commitment-secret as in BOLT 03 and tested it with successfully  with test vectors, but still can not derive the '0346d4..' key.
generate_from_seed(seed, I):
    P = seed
    for B in 47 down to 0:
        if B set in I:
            flip(B) in P
            P = SHA256(P)
    return P

I use for seed the decoded extended private key:
extended_private_key = "vprv9DMUxX4ShgxMLHkP4A7EPJr52LoHYn5jD6vn3UfQnf6Tv1uA7mw3RozDzwD2vMxs5MWLAPENaxYvrDERFdARSQLa6RXWBih5bjRqh5hsfJr"
decoded_key = base58.b58decode(extended_private_key)
seed = decoded_key[46:78]

index = 0xFFFFFFFFFFFF  # 281474976710655 (first channel).
I believe I'm not using the right seed...Could someone please help how to derive the  per-commitment-secret?


text:
Bitcoin Multisig tx signing
I've generated a 2-of-3 P2SH Multisig address (testnet) and am attempting to manually reproduce the signatures to spend from it. While I can replicate the signature for the first key, as produced by the Bitcoin Core console, the signature for the second key doesn't match.
Am I right in assuming that both keys sign the same raw transaction?
Here's the raw transaction I signed using the first key:
020000000192123eb65da181167df6b25e63ed4d8bc890d5be9004bedce8291a68a3d3e5ce00000000695221027a808a8791ecfc8974ee24e96b7ce03fde3ee9bd0f81e0b502022ba0cd8cee8f210212c428743843843103e5196820e5358846c96d6b1640b8da284918e0fbd6b71821033c5a1c6a18976d0e0e1faa12b1c9ace1f53d9067ffb2f08918bcc2c07c77c14553aefdffffff0110af1300000000001976a914002646cc98c6ac168bddc0c360d2654c625425fe88ac0000000001000000
Using the first key:
cV5sJJ1hCGejXHYkn6axJ9xviQtgtt1RcxakiUzPN5SRkRyES6dZ
I obtained the signature:
47304402204f3379a90487d6b7662ea2c18e065cd399a3200fdc2ec0879dc1bbf539d2463c02201988ab667035e9773404d88b2b8c9555c040c50065e3c8433d353f8a7474826001
This matches the output from Bitcoin Core.
However, when signing the same raw transaction with the second key:
cVYbFrQn2zNrEvW6k6LKjEZSkwXrJ8YyiZEGGqeq99uejGxPGdaU
I derived the signature:
483045022100f65fc153f076b3b1593e5a545eb7250cb796017b189807deb4169ff3b4a9e98b022064c7402433b5c33e8a6e9f59351031d620438a137facc78d830838cb76efc16901
In contrast, Bitcoin Core produced:
47304402206921961c3eb9f6f0687e73624baca89a57b0bb7f9e43bc7f05b8207c856529b702203c940624e2836db470614ed08ec87c3e38aebde78d533b820f3d48449c50ee8201

Signatures are not guaranteed to be the same since they incorporate extra randomness in the form of the nonce. For each message that a private key signs, the nonces used must be different as otherwise the key can be derived.
An easy way to guarantee uniqueness of the nonce is to essentially hash the private key with the message. This has the effect that nonces are deterministic, and so different software that use the same algorithm will produce the same signatures. This is why you can get the same signature even with different programs, and signing the same thing with the same key produces the same signature.
Specifically, Bitcoin Core, and many other software, use the nonce derivation algorithm specified in RFC 6979. However, Bitcoin Core makes an additional modification to this algorithm. ECDSA signatures in Bitcoin are often either 72 or 71 bytes, with ~50% probability of each.
It does this by generating multiple nonces, but as described earlier, deterministic nonces with just the key and message will always result in the same nonce. So Bitcoin Core uses the variant of RFC 6979 that allows for additional entropy (see section 3.6, second bullet). Specifically, it appends a 32 bit little endian unsigned integer that is just a counter. Every time a signature larger than 71 bytes is produced, it increments the counter and tries again. In order to get the same signatures, you'll need to do the same.
Doing this lets Bitcoin Core produce signatures that are never larger than 71 bytes which is useful for size estimation when deciding which UTXOs to spend.

Thank you for the explanation! I'm using coincurve 8.0.2 to create signatures. Is there any library which has implemented this additional modification of RFC 6979?

Bitcoin Core uses libsecp256k1's api to do this, so any library that exposes the api fully should be able to as well.


text:
Setting high tx fees (paytxfee, maxtxfee,..)
I am building different tx types on regtest and don't want to care about tx fees.
Here is my bitcoin.config
fallbackfee=100000
paytxfee=100000
maxtxfee=100000
mintxfee=0.1
maxfeerate=100000
I have set the values absurdly high, but bitcoin core still doesn't allow to send a transaction (P2WPKH, 1 input and 1 output) with 100 btc in fees, and still get
Fee exceeds maximum configured by user (e.g. -maxtxfee, maxfeerate) (code -25)

Solved. Despite definition in bitcoin.config, when calling sendrawtransaction we need to pass again the maxfeerate
sendrawtransaction raw_tx_hex 1000

maxtxfee is a wallet configuration option; it doesn't apply to sendrawtransaction as that isn't a wallet RPC.

Did this really bypass it? I'm trying to use it and get: "Fee rates larger than or equal to 1BTC/kvB are not accepted". I'm using with "sendrawtransaction ra_tx_hex 100000".


text:
Need help moving funds from legacy address, Coldcard won't sign psbt
I'm in needs of help moving funds from an legacy address, single sig:
I exported my Coldcard's xpub to Bluewallet. Bluewallet derived an address from that xpub onto which I received funds. Unfortunately, Bluewallet gave me a legacy address and I didn't notice. I should've given it the zpub, I know better now.
Now I like to move that BTC. I exported the xpub to Sparrow to craft the psbt but Coldcard refuses to sign saying "Failure. My XFP not involved".
Sparrow wallet is watch-only, m/0'/0'/0' (I tried as well m/44'/0'/0'/0', m/84'/0'/0'/0'), fingerprinted.
Alright, I created a second psbt with the original culprit Bluewallet but Coldcard doesn't like to sign this psbt either as "m/44' led to wrong pubkey for input#0" and this is where I need help.
What does Coldcard need from me now to sign the psbt?
This watch-only Bluewallet always has been on derivation path m/44'/0'/0'/0' ever since, I didn't interfere with the xpub import to begin with, with these settings it got the idea to give me a legacy address. How come even Bluewallets psbt isn't pleasing the Coldcard?
Thank you for your help.

I am going through the same problem... How did you solve it (if you did :-)).

Hey, I solved it by loading the seed into Electrum, nothing else worked. If you have the same exact problem, then do this: when recovering in electrum, choose legacy and set the derivation path to m, no numbers, just m

It sounds like you imported only the xpub without the information that identifies where the xpub came from. This information, known as origin information, contains the fingerprint of the master key that derived your xpub, and the derivation path required to derive the xpub.

Coldcard refuses to sign saying "Failure. My XFP not involved".

This indicates that the PSBT is missing the origin information needed for the Coldcard to determine whether a key was derived from the device's master key. Since the Coldcard cannot store all keys that can be derived, it relies on the origin information being present and accurate. It checks to see whether the given master key fingerprints (which it calls XFP) match its own fingerprint, and if they do, it will try to derive the key with the derivation path contained in the PSBT.

The best possible solution is to import the xpub with the origin information. However I am not familiar with BlueWallet so I cannot provide instructions for how to do that.
You can also try using a different wallet software that does import with the origin information or provides facilities to setup an existing hardware wallet. I believe Sparrow and Electrum are able to do that.
Lastly, as you stated in a comment, you can import the seed itself. However as this puts the seed in use on a hot device, I would not recommend it as you then lose the benefits of using a hardware wallet.

just recover your wallet with a Trezor wallet then you can sign it with no issues, coldcard functions weird sometimes

Your answer could be improved with additional supporting information. Please [edit] to add further details, such as citations or documentation, so that others can confirm that your answer is correct. You can find more information on how to write good answers in the help center.


text:
How can we use OP_CHECKTEMPLATEVERIFY to non-interactively open channels?
In here there is a description of how to create a channel between two parties without interaction from both of them. If my understanding is correct, the transaction responsible for codifying the channel's state is transaction C in the post; in this case, my question is: since OP_CHECKTEMPLATEVERIFY determines the transaction in its entirety, how it is possible to later update this state?
In case my understanding is wrong, how is then the state of the channel codified?
Thanks in advance for any responses.


text:
Why does RBF rule #3 exist?
The mempool-replacements.md document states the following rules for RBF:

The replacement transaction pays an absolute fee of at least the sum paid by the original transactions.

The additional fees (difference between absolute fee paid by the replacement transaction and the sum paid by the original transactions) pays for the replacement transaction's bandwidth at or above the rate set by the node's incremental relay feerate. For example, if the incremental relay feerate is 1 satoshi/vB and the replacement transaction is 500 virtual bytes total, then the replacement pays a fee at least 500 satoshis higher than the sum of the original transactions.

Isn't rule #4 strictly stronger than rule #3? I've always seen both stated as independent rules (even in code implementations), and this makes me wonder if I'm missing some subtlety here.

Rule 4 is indeed strictly stronger than rule 3.
It being two rules might be a simple carry-over from BIP125, as it was written from the implementation (and not the other way around). Under this hypothesis it would have been specified as two rules in the BIP is because it's written as two checks in the code. Which makes sense in terms of C++ as you first want to check the replacement's fees are not inferior to the replaced txs' fees to avoid an underflow when then calculating the fee delta. But less so in terms of specification.

BIP125 co-author here.  I don't recall all the specifics of writing that document almost 9 years ago, but I can confirm that I went through the checks in the code and turned them into the numbered rules in the document.


text:
Why do bip32 (HD Wallet) xprv key strings all start with
the prefix xprv9s21ZrQH143K...? no matter which seed phrase I start from.
whereas normal private keys will vary totally.
What does the "...9s21ZrQH143K..." mean?
Further, this sequence will sometimes be followed by a 3 or a 4, but often times it's a 2 before continuing the rest of the string.
I searched all over the web and couldn't find an answer.

The xprv format contains some metadata about the key it contains.
Part of that metadata is what level from the root it is (an xprv can be derived from another xprv, incrementing the level by one). Another piece of metadata is what the (32 bit) fingerprint of the parent it is derived from, if any.
Root xprvs (those directly derived from a seed) have level 0, and parent fingerprint 00000000. When converting to base58 format, those 5 bytes for level + fingerprint translate to a fixed string.

Thank you, that makes sense now! Particularly the part about the default parent fingerprint value being 00000000 for every master key pair... thx


text:
I dont remember my wallet address it's been a year and half since I didn't withdraw

Withdrawal I forgotten my wallet address how to discover it

What do you mean? Bitcoin Addresses are derived from public keys which are derived a private key which mostly consists of 24 words. Have you forgotten your 24 word seed phrases? If that is the case and you don't remember the 24 words, there is no way to brute force it. Unfortunately you can kiss those BTC goodbye.


text:
Stratum V2 incentives?
I am wondering about the prospects of resolving increasing mining pool centralization. What is the incentive for miners and pools to support Stratum V2?

Incentives for miners:

Security & Privacy: communications between miners and pools are encrypted with SV2. Stratum V1 is plaintext by protocol definition. Attacks such as hashrate hijacking would be unfeasible with SV2.
Efficiency: SV2 uses a specific binary framing which reduces the bandwidth consumption and latency for the entire communication between miners and pools. Stratum (V1) instead is a json-encoded protocol. SV2 aims to reduce also the number of empty blocks, since it introduces new messages needed to pre-build a future block template with other transactions while mining on the current one.

Incentives for pools:

Efficiency: the same benefits of the above described for the miners.
Server load: thanks to the SV2 standard channels and to the SV2 binary framing, the load on the pool servers is reduced.
No more responsibility for transaction selection: right now pools have the entire power of selecting transactions that are mined in the future blocks, and this is a very bad centralization point. In a future in which governments or other entities will make pressure upon pool operators, in order to perform any kind of censorship, this will be totally pointless if the block templates (and so transaction selection) is done by individual miners.

These are the main incentives for adopting Stratum V2 for both miners and pools.
In order to get more info about all protocol features, I'd recommend to have a look at:

https://github.com/stratum-mining/sv2-spec
https://stratumprotocol.org/
https://github.com/GitGab19/Stratum-V2-Master-Degree-Thesis

But is the incentive strong enough for pools to give up the tx selection power?

I think that the efficiency and security points are very strong incentives for both miners and mining pools. Transactions selection feature (defined as Job Declaration Protocol in SV2 specs) is very important for the pools as well. From a low-time-preference point of view, it constitutes a crucial aspect for mining pools businesses and the entire network as a whole.


text:
Why doesn't the price of the bitcoin perpetual future equal the price of bitcoin?
A lot of exchanges offer a bitcoin perpetual future to allow users to speculate on the price of bitcoin. For a future with an expiry date, it makes sense that the price of the future might be higher/lower than the price of bitcoin. But for a future without an expiry date, what does it actually mean to speculate on the price of bitcoin? Why does the price of the perpetual future differ from the price of bitcoin? The price of the future are close and correlated but aren't the same. Why?

Other than shares, bitcoins can be held directly by the owner of the asset. In contrast, a Bitcoin future is a voucher for some bitcoins issued by a third-party. As we have learned time and again, “not your keys, not your coins”. Since the two are not the same thing, it is not surprising that they may be priced differently.


text:
Is it possible to setup Lightning Network Nostr tipping using Bolt12 offers?
I see that NIP-57 references / depends on the LNURL specification, which references LUD-06 and LUD-16.
As someone still rather new to all the various specifications, can somebody explain to me in simple terms if it is possible to integrate a Bolt12 invoice with LUD-06 or LUD-16 identifiers, and consequently, Nostr tipping?
Bolt12 seems to me like a clean solution without necessitating an intermediary web server. What needs to be done in order to get Nostr tipping using Bolt12? Another NIP?
Thanks in advance for any help putting these pieces of understanding together.

What would be the use case? You can already have user-defined amounts with NIP-57 and bolt11. What would a Bolt12 offer add here?

@RainerFeike As stated, I would like to see p2p tipping over NOSTR without the need for an intermediary web server required by LNURL. There should be more Bolt12 standardization across lightning network implementations in general, but I think NOSTR tipping is a great use case for moving in that direction.

Bolt12 seems to me like a clean solution without necessitating an intermediary web server. What needs to be done in order to get Nostr tipping using Bolt12? Another NIP?

Yes it is.

I see that NIP-57 references / depends on the LNURL specification, which references LUD-06 and LUD-16.

I am not following the nostr protocol but I think it is possible to make an alternative version. I am not sure if it is possible to alternate the NIP a little bit to support bolt12 in it.
Happy to see something around


text:
Who pays the fees for a node payment?
Is it true that the recipient has to pay the fees of a node payment upfront or the transaction won't go through?

Does this answer your question: https://bitcoin.stackexchange.com/q/103891/5406?

No, that is not true.
Anyone asking for upfront fees is a criminal trying to trick you and steal your money. A swindler. A scammer. A confidence trickster or conman.

There is also no such thing as a "node payment".

The transaction is the payment. There isn't some other payment other than the payment.


text:
How to build a bitcoin fullnode and light node using docker image?
I used the image "fullnode/bitcoin" to build a node of bitcoin.
It runs successfully and I can see the debug.log. The node begin to Sync ledger(blocks).
I want to know how I can judge one node is fullnode or light node. The difference in bitcoin.conf? Or the difference in log?

Bitcoin Core only implements a fully-validating node mode. If this image runs Bitcoin Core, it's fully validating.
It is possible to run Bitcoin Core in pruning mode (prune setting in bitcoin.conf), where old block data is deleted after validation. Everything is still downloaded and validated as before, just not kept.


text:
Address watcher with BDK/Rust
I'm trying to implement (multiple) address watcher in BDK/Rust.

I'm having trouble doing this for an arbitrary address, because BDK and rust-miniscript don't support "addr()" expressions in an output descriptor. Is there any way around to create a watch-only wallet from a single address?

Is BDK and descriptor wallets even a good choice for monitoring a list of unrelated addresses? Are there any more suitable alternatives...?


text:
How to find Bitcoin wallet address
I'm trying to find the address for Bitcoin wallet so someone can transfer me Bitcoin because my data got stolen so I'm getting compensated for it

This sounds like you're being scammed. Can you provide more details? Which wallet are you using? Who is compensating you and why?

Control and compensation department representative I'm being compensated because someone scammed my data

You are almost certainly being scammed. What is the name of the business that has the "control and compensation department"? did you first learn about it by a direct message from them? if so, definitely a scam. Remember - no genuine business will ever ask you to pay fees to release money. Don't believe lies about COT codes, minimum balances, wallet validation etc etc - all lies.


text:
Bitcoin UTXO Balance Checking
I think I understand how the UTXO model works, the inputs, and outputs, etc. However, one thing I am still having a hard time still, is understanding how balance is calculated from a seed or xkeys.
If you were to create a new receiving address for each transaction, then wouldn't that mean that in order to check your entire balance you have to go through every single address that could be generated from the derivation path of your keys? If so, how would that be efficient at all?
Also, as far as I know, every node keeps a dataset of all the UTXOs. But in order to check for your balance, wouldn't you still need to check the whole dataset for every possible address you could generate?
Thanks in advance!

For hierarchical deterministic wallets this is usually solved with a "gap limit". It means that when restoring from a recovery seed (or similar backup) the wallet will start checking for addresses until it finds a long enough run (e.g. 100) of unused addresses, and then it assumes that's all there is. Conversely, the wallet should not allow you to generate more than this number of addresses ahead of use, or at least display a warning that it might later prevent the wallet from discovering your funds.
Checking if an address is unused cannot be done with the UTXO set alone, because knowing that the address doesn't have a UTXO associated with it doesn't mean it never had. You need to store the entire blockchain, preferably in a way to allow efficient lookup of transactions associated with a specific address. Most hierarchical deterministic wallets delegate this task to an external service.


text:
How Lightning Network sends payments
I am quite new to the whole blockchain space in general and was reading about Lightning Network. In LN which message type is used to encode payment information? For example, in the below book, there are references to 7 different messages exchanged between channel partners.
https://github.com/lnbook/lnbook/blob/develop/07_payment_channels.asciidoc
But none of them seem to transfer information about payments; something like "Bob, I am sending you 10 sats"
I also looked at the Bolt specification repo on GitHub but was not able to locate this. Is there something that I missed?

The update_add_htlc message transports the onion with payment / routing information. The information itself is desced in the onion routing chapter that explains how nodes can handle this


text:
blockchain.info like wallet api
I'm trying to build an API similar to the blockchain.com wallet API so that I can send and receive bitcoin on my e-commerce site. I have a docker container running a pruned node and I'm using another docker container as an API server to send RPC requests to the bitcoind pruned docker container. The requests are all working and I'm using regtest network. Before I switch to the mainnet I would like to know a few things.

People will be generating a huge amount of new bitcoin addresses whenever there is a new order being created but it's not sure that they will pay to that address, they may abandon the cart for instance, and will this cause problem? Do I need to maintain the addresses without any gaps?

How can I create multiple wallets like blockchain.com, will the container running blockchain core be capable of doing this by just calling the RPC from the API container? Are there any restrictions to the number of wallets I can create?

My site is an e-commerce site, can I create multiple wallets for each user on my site so that I can send them like affiliate commissions to their wallet from the main wallet for instance?

Is there any procedures I need to be paying attention to particularly ? Please advise.

You can keep generating addresses. Bitcoin Core is capable of generating and keeping track of millions of addresses. You don't need to worry about gap limit, as you are using bitcoin core. Gap limit issues mostly arise when you are deriving adresses from xpub
Yes, you can create multiple wallets in bitcoin core using multiple wallet finds. About limits on number of wallets feel free to see this
There are multiple open source projects that offer bitcoin wallet as a service which you can take inspiration from. Feel free to see IBM secure wallet and  coinpunk

You try Bitpay's API to you are not experienced with coding, I think it is easy to implement on your e-commerce site.
or, you should generate a single-use bitcoin address for every transaction and make sure to maintain the record for each transaction.
Also, make sure to keep the private keys offline.
above all, try hiring a bitcoin developer if your needs are much bigger.

Yes, you'd need to maintain the full record of all addresses, because you don't know whether they'd still receive a payment eventually, after they've been seen by someone. Otherwise, you will miss getting paid and need to rescan later, so you might as well keep the full body in the first place.
bitcoind is probably not the right tool to track a multitude of different customers' wallets. Have you taken a look at BTCPayServer?


text:
What is the flow of buying crypto on behalf of users?
I am building a crypto on-ramp for users in emerging markets that allows users to buy crypto via debit/credit cards, mobile money, etc.

What is the flow of buying crypto on behalf of users? From payment to acquiring the cryptocurrency to sending to a user's wallet address.

I'd like some detail if possible.
I've looked at Binance, Blockchain, Bitfinex, Kraken, Gemini APIs as well as other APIs and so far to my understanding, buying would involve creating a trading account with an exchange, filling the account with some amount of money and then calling the exchange's API to make a market order when a user requests so.

Am I on the right path or is there a better way to go about this?

Does this answer your question? How do you obtain bitcoins?

@darkknight thank you but not it doesn't. So, what I'm trying to figure out is to facilitate the buying process for users like a Coinbase or Binance, should I start with one of these exchanges' API or should I run a full node with some liquidity to sell to users? Or is there another way? An example of what I'm talking about is MoonPay in the US.

User creates an account on the exchange.
User submits KYC documentation such as their ID, bank statements, etc., and waits for exchange to review the documentation and the account to be approved.
User attaches their payment method: bank account/credit card.
User places a buy order on the site; the order gets fulfilled.
User withdraws their purchased crypto.

Hi, thank you. I'm familiar with this process. What I'm trying to figure is how would I build something like MoonPay? What is the underlying process to selling crypto to users through their debit cards?

@ObakengMosadi The hardest part of doing something like that is probably getting the approval from a bank to process debit transactions for you. You'll have to work out with your acquiring bank what regulatory steps they'll need you to complete to offer that. But once you have the money from the user, you'd just buy the crypto off of an exchange and send it to the user.


text:
Difference between capacity and max_htlc in Lightning Network?
What is the difference between capacity and max_htlc in the routing of payments in the network?

The capacity of a channel is the number of satoshis that are stored in the payment channel. They are split between the two channel partners and offered htlcs. No payment larger than the capacity can ever go through that channel.
The max_htlc is the number of concurrent offered htlcs that are possible in the channel. They are limited because most htlcs are outputs in the commitment transaction and cost a fee paid to the miners in case the channel has to be force closed.


text:
Invalid transaction. Error: TX decode failed. Make sure the tx has at least one input
I'm using bitcoinlib for python to create a transaction and send it but I'm getting the following error:
Funds not sent, exception error: Error connecting to blockchair on url
https://api.blockchair.com/bitcoin/push/transaction?data=01000000000101a988402108fbbdc3dc790926a41e3378042f90a80e2fbf67f8ad117644c100803700000000ffffffff0231810000000000001600149dde1d0113a7468f605bef751aa03a020cad3d2b000000000000000017a914f1b553ddc46d0414e9b05b9667d65c5081d4f00a870000000000,
response [400]
{
    "data":null,
    "context":
    {
         "code":400,
         "source":"R",
         "error":"Invalid transaction. Error: TX decode failed. Make sure the tx has at least one input.",
         "market_price_usd":56609,"cache":
         {
             "live":true,
             "duration":60,
             "since":"2021-12-03 03:58:11",
             "until":"2021-12-03 03:59:11","time":null
         },
         "api":
         {
             "version":"2.0.94",
             "last_major_update":"2021-07-19 00:00:00",
             "next_major_update":null,
             "documentation":"https:\/\/blockchair.com\/api\/docs","notice":":)"
         },
         "server":"BTC3",
         "time":0.0013239383697509766,
         "render_time":0.006116151809692383,
         "full_time":0.007440090179443359,
         "request_cost":1
    }
}

Here is my decoded transaction:
{
    "addresses": [
        "bc1q23dd73raxnk6cvz62wl2gthkfx3ksdqq0tqrn0",
        "bc1qnh0p6qgn5arg7czmaa634gp6qgx260ftspufv2",
        "3Pj3zdw77aqsELdoh5pQErWvK2hAYbJx2w"
    ],
    "block_height": -1,
    "block_index": -1,
    "confirmations": 0,
    "double_spend": false,
    "fees": 683,
    "hash": "7f2f01b7a7d55cc9e13aa6604b115fcf07ada6ee6179a6342c0f8d7d5668de3d",
    "inputs": [
        {
            "addresses": [
                "bc1q23dd73raxnk6cvz62wl2gthkfx3ksdqq0tqrn0"
            ],
            "age": 712033,
            "output_index": 55,
            "output_value": 33756,
            "prev_hash":
"8000c1447611adf867bf2f0ea8902f0478331ea4260979dcc3bdfb08214088a9",
            "script_type": "pay-to-witness-pubkey-hash",
            "sequence": 4294967295
        }
    ],
    "outputs": [
        {
            "addresses": [
                "bc1qnh0p6qgn5arg7czmaa634gp6qgx260ftspufv2"
            ],
            "script": "00149dde1d0113a7468f605bef751aa03a020cad3d2b",
            "script_type": "pay-to-witness-pubkey-hash",
            "value": 33073
        },
        {
            "addresses": [
                "3Pj3zdw77aqsELdoh5pQErWvK2hAYbJx2w"
            ],
            "script": "a914f1b553ddc46d0414e9b05b9667d65c5081d4f00a87",
            "script_type": "pay-to-script-hash",
            "value": 0
        }
    ],
    "preference": "low",
    "received": "2021-12-03T03:58:47.770766807Z",
    "relayed_by": "3.237.60.136",
    "size": 117,
    "total": 33073,
    "ver": 1,
    "vin_sz": 1,
    "vout_sz": 2,
    "vsize": 115
}

The python code I used to create the transaction:
w = Wallet(wallet_name, db_uri=db_uri)
t = w.transaction_create([(to_address, float(satstosend))])

I'm not sure why it's complaining that I don't have an input, but it's odd to me that I see one input and two outputs. I'm not sure if I'm creating the transaction incorrectly or if it has something to do with the fact that I'm trying to send from a native segwit address to a segwit address (bc1 -> 3XX). Any help would be appreciated.

It's possible that blockchair believes the transaction to be a non-segwit transaction (because of the marker and flag bytes required for segwit txs) and so is incorrectly parsing it. Have you tried a different broadcast API?

Yes I've tried blocksmurfer and ran into a generic error telling me the transaction failed but with no reason.

So after trying a few different providers, blockstream gave me the same error message. Funds not sent, exception error: Error connecting to blockstream on url https://blockstream.info/api/tx, response [400] sendrawtransaction RPC error: {"code":-22,"message":"TX decode failed. Make sure the tx has at least one input."}

I figured it out, I simply was missing a step. I wasn't signing my transaction before sending.
>>> t.sign('my_private_key')
>>> res = srv.sendrawtransaction(t.raw_hex())
>>> res
{
    'txid':
    '8ca3d23d55dbded21a3ee8809ba55e2fa97394332020fad55582ab29e9619de4',
    'response_dict':
    '8ca3d23d55dbded21a3ee8809ba55e2fa97394332020fad55582ab29e9619de4'
}`


text:
How to get public key and bitcoin compressed address from the coordinates (x,y) generated by ECDSA?
I have my x (0xca668a8b5f71e8724aada4b5343c28702a481787855cc42228b8fff97fe94d6a) and y (0x19dd3a603a55b3d8c5f62cbe177b9b63693fb8c91d76845bafc843a7aa19ea55) coordinates generated by ecdsa with a private key. But don't know yet how to get the public address from (x,y) coordinates and a compressed bitcoin address ?

This depends largely on which type of address you want to generate. First, you will need to encode your public key into compressed form. This is done by taking the x-coordinate, and prepending 0x02 if the y-coordinate is even, or 0x03 if the y-coordinate is odd.
A legacy P2PKH address (starting with a 1) is generated by the following process:

Taking the compressed form of your public key.
Hash it with SHA-256 and then hash the resulting 256-bit hash with RIPEMD-160 to get a 160-bit hash value. Call this result hash.
Prepend the version byte (0x00 for Bitcoin mainnet - this gives the 1 at the start of the address). So we have version || hash.
Hash version || hash twice with SHA-256 and take the first four bytes of the result as a checksum.
Encode version || hash || checksum in Bitcoin's Base58 encoding
format.

This is described on the bitcoin wiki here.
If you want to create a P2WPKH Bech32 address (starting with bc1), the process is simpler. The witness version is 0x00 and the witness program is a push of the RIPEMD-160(SHA-256(compressed public key)) hash. To push a 20-byte hash like this, we use 0x14 (which is 20 in hex). So the total scriptPubKey is 0x0014{20-byte hash} (as described in BIP-141). You then simply encode this scriptPubKey using Bech32 encoding as defined in BIP-173.
There are other types of address too, of course, including P2SH, P2WSH, and P2TR (as well as P2SH wrapped segwit v0 addresses). These all deal with scripts too though, rather than just single keys.


text:
Can I somehow find the wallet id of every trade?
I know we can see the trade flow of BTC trades. Is it somehow possible to associate each trade to a waller? Ie. the initiator of the trade?

Trades on exchanges are not reflected on the Bitcoin blockchain, there are many orders of magnitude more of them than the total number of transactions ever made in the networks history. The only source of information about what exchange transactions have happened is the exchanges themselves, and they expose no identifying information about who made them.


text:
How to know the number of digits in the decimals place in division results (ECC SECP256K1)?
p - is the order of the finite field
n - is the order of the group. Private keys can range from 1 (the generator point G) to n - 1.
All the private keys (Priv) lie in certain ranges of 2.
2^a < Priv < 2^b
If we know the a then after converting our private key to the public key (Pub), we can divide the Pub by 2, a times to get Pub2 (using elliptic curve divisions of course, PubOld * (2^(-1) mod n) = PubHalved ).
Priv2 would be the corresponding private key to Pub2 and it'd look like:
1 < Priv2/(2^a) < 2
We know for sure, that we have 1 in the wholes place, and that it is the only digit we have in the wholes place. Also If $Priv$ was an odd integer then there would be the same number of digits in the decimals place (in Priv2) as there were divisions by 2 (in this case it is a number of digits).
But if Priv was an even integer, then the number of digits in the decimals place would be a minus the index number of the division by 2 where the corresponding private key integer became an odd number. Like if we had 250 as our Priv, then Priv2 would have 6 digits in the decimals place, because 2^7 < 250 < 2^8, and it became an odd number right after the 1st division, hence, 7 - 1 = 6
A special case would be perfect square numbers, where we would never get an odd number, except at the end, and that would be 1 as the final division result.
Another property, is that Priv2, if Priv is odd, would have either 75 or 25, as the 2 final digits at its end.
Take a look at Priv = 247 for example
2^7 < 247 < 2^8
After all the divisions:
1 < 247/(2^7) = 1.9296875  < 2
Now suppose that we don't know the value of the private key. The things that we know are:
Integers a and b, 2^a < Priv < 2^b
There are 2 questions:

Is there a way to find out the number of digits of Priv2 (division result) in the decimals place?
How can we separate the last 2 digits at the end of the decimal part, and find out whether these are 25 or 75?

To imagine the situation better, suppose that we are making the calculations in the ℤp field, and our curve is secp256k1


text:
Questions about generating a random number for ECDSA
One of the component of making of SECP256K1 signatures, is a random number that is later multiplied by the generator point in order to be used in further computations.
If we imagine that k - is the random nonce number and G - is the generator point, then:

What's the length of k (random number), in bytes, bits?
However, I am trying to find the answer in the Bitcoin core source code, but it's kind of hard to read and could find an answer to it there.
    /* Generate an ECDSA signature `noncefp` and `ndata`
allows you to pass a * custom nonce function, passing `NULL`
will use the RFC-6979 safe default. * Signing with a valid context,
verified secret key * and the default nonce function should never fail. */

    return_val = secp256k1_ecdsa_sign(ctx, &sig, msg_hash, seckey, NULL, NULL);

    assert(return_val);

I am not sure where is k located in the code.
Also curious about other things:
Has anyone successfully replicated, mimicked the k for signatures, where k is not known?
Has anyone successfully "mined", or brute forced a k for signatures?
Is it possible to brute force the k by randomly generating random number with the function/algorithm being implemented in bitcoin core? (I suppose it is RFC-6979 or something)

What's the length of k (random number), in bytes, bits?

256 bits.
The number k (also called the nonce) in ECDSA must be an unpredictable value, indistinguishable from uniformly random among the set of all valid private keys. For secp256k1, that range is from 0x1 to 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140, inclusive. Since the lower bound is so close to 0, and the upper bound is so close to 2256, just using a uniform 256-bit value will always be valid k, except with negligible probability.

Has anyone successfully replicated, mimicked the k for signatures, where k is not known?

If you can successfully guess the k value used in a signature, you can compute its private key. For correctly-functioning wallet software, this is hopefully impossible to third parties.

Has anyone successfully "mined", or brute forced a k for signatures?

Brute forcing will only work against badly-generated nonces that are chosen from a very small range, which is probably fairly rare. There are other misuses of nonce creation however, which have occurred in practice, and have been exploited.
One of them is reusing the same nonce value twice with the same private key, for different messages. When identified, this allows computing the private key as well. This was used to attack the PlayStation 3 security (where every signature used the same k value).
More subtle nonce crimes, and a fairly advanced attack against them, is described in this paper.

Is it possible to brute force the k by randomly generating random number with the function/algorithm being implemented in bitcoin core? (I suppose it is RFC-6979 or something)

RFC6979 describes a derandomized nonce generation algorithm. Somewhat simplified, what it suggests is akin to using Hash(private_key || message) as nonce. This has the property that it is unpredictable to third parties (since they don't know the private key), and will never result in reuse for distinct messages under the same private key.
When nonces are generated this way, and you don't know the private key, trying to brute force is hopeless. Computing the private key from the public key using an algorithm like Pollard's Rho, and then solving for the nonce, would be many orders of magnitude faster than trying to brute force the nonce directly.

Thank you for the explanation!


text:
Is there a bitcoin api?
Sorry if my question sounds silly, I get downvoted for some reason everytime I ask it. I just need some help
Today I saw the "richest bitcoin wallets" chart and I was inspired to program the same thing, it's interesting for me to know how this type of research is done. I want to be able to look into blockchain data by means of code and perform some queries (I guess?) to sort addresses starting from wealthiest. Also I want to get transactions data to analyze moves of traders
And, of course, I tried to google what I want to do but unfortunately, I was unable to find anything on that topic!
Can someone please point me the right direction? I can't find find out from where to start

This may help: https://bitcoin.stackexchange.com/q/11459/51948

There are many.
If we define an Applications Programming Interface (API) as any kind of software interface between computers or programs then the following apply.

Bitcoin network protocol. You can write software to use this to obtain blockchain related information from any other Bitcoin node.

Remote Procedure Calls (RPC). Many full-node implementations provide an RPC service. For example Bitcoin Core RPC. Other implementations may have their ownAPI. For example Electrum's JSONRPC. There is no guarantee that different software provides the same or even similar RPC API.

Command Line interface (CLI). Although probably  designed with interactive use in mind, these can be used in scripts or invoked from compiled programs and thus constitute a kind of API. For example Bitcoin Core CLI - though I expect the RPC interface is preferable in most non-interactive cases.

Web service APIs provided by major Bitcoin related services. For example Blockchair. This includes some Cryptocurrency Exchanges. It may be that these require registration and may be rate-limited for people who don't pay a subscription or otherwise have a business relationship.


text:
Where do you get work and submit solutions?
is it possible to get bitcoins using your own custom code? Is it possible to get a hash somewhere, come up with a solution on my own, and then submit the solution somewhere? I just thought the puzzle part of bitcoin sounded fun, I don't want to have some other person's solver running on my machine.

is it possible to get bitcoins using your own custom code?

Yes, the software ("code") would be what Bitcoin folk called a miner back when software and a CPU or GPU was all you needed. Nowadays you would need to write custom code that works with custom or commercial ASIC hardware.

Is it possible to get a hash somewhere ...

That's not how Bitcoin mining works. You need to create block template, set the value of an arbitary "nonce" and then calculate the hash of this block data. Then vary the nonce and repeat until you find a nonce value that leads to a block hash whose value is less than the current target value.
You need to be listening to the Bitcoin network using the Bitcoin network protocols in order to collect information needed to construct a new block. This would include the hash of the currently latest block, the network target and other items. Optionally you would maintain a pool of pending transactions you might want to include in a block.
Part of the block data you create is a "coinbase" transaction of your own devising that pays to an address of your choice the block-reward plus total of transaction fees of any pending transactions you included in the block.
That constitutes mining a block.
Nowadays you'd typically use a mining-pool network protocol to work as part of a mining pool. If you have huge financial resources and can buy immense numbers of ASICs you might not need to be part of a pool.

... come up with a solution on my own, and then submit the solution somewhere?

Once you have mined a new block you use Bitcoin network protocol to notify a few bitcoin nodes (peers) that you have new block data. You find those peers using the Bitcoin peer-discovery process.
If your block is acceptable, you can spend your coinbase output anytime after 100 other blocks have been mined using your block as an ancestor.

I must have used the wrong terms, I mean the target value you speak off, how do you get that one? Basically I thought finding the hash for a given target value sounded like an interesting problem. There should be other ways to solve that problem than just random trials.

See https://en.bitcoin.it/wiki/Difficulty. There should NOT be other ways to solve that problem or Bitcoin is dead and much of cryptography too.

It is has happened before that if you don't tell the student it is hard they will find the solution if you give it as homework. I don't understand why I need anything else than the target, does it have to be linked to the latest block somehow?

It is true that if you find a way to force hash collisions you may become famous or even wealthy. However I suggest: 1) formulate a simple question. 2) search here for that question. 3) if not already asked and answered, use the "ask question" button. 4) goto 1.

Okay. I don't understand your answer but it seems I didn't understand my question either so I guess I'll accept it.


text:
Different ways in which bitcoin can be burnt
I'm interested in the different ways in which bitcoin can be burnt. I can see three ways:

Send coins to a 'made-up' address. There's no way to distinguish it from a real address (so the transaction will not be rejected), except that no-one has the private key
Send a de minimis amount (e.g. 1 SAT) to an address which already holds coins. These will get 'overwritten' and thence lost
Begin an output address with OP_RETURN

Both (2) and (3) demonstrate that coins are destroyed. (1) relies on trust.
Firstly, are the above descriptions accurate (and am I using terminology correctly)?
Secondly, are there any other way of destroying coins?
Finally, in reality do either (2) or (3) represent a material loss of coins?

there are indeed several ways of burning bitcoin:
comment on 1: you dont have to rely on trust, you can send bitcoin to 1111111111111111111114oLvT2. This address is spendable with if you have a keypair with RIPEMD160(SHA256(publicKey)) == 0 which nobody has (yet)
comment on 2: you can't send amounts under the dust limit (transactions doing that are not relayed) and those coins will not be burnt if the owner of the address spends them and thereby paying more fees than the UTXO is worth. Note that the fees are going to the miner and are thus not burnt
comment on 3: i think you meant scriptPubKey not address. it creates a provably unspendable transaction output
number 4: a miner can claim less bitcoins in his coinbase output. consensus rules only disallow claiming more, and coins cant go to fee in a coinbase transaction

Thank you that makes sense (and I realise that my (2) was based on a misunderstanding). I can't upvote but I would if I could

As already mentioned in other answers, you can burn funds by sending them to an address with an unknown or provable non-existent private key, or by allocating them to an OP_RETURN output, which can never be spent.
I want to talk about the second suggestion from your question:

Send a de minimis amount (e.g. 1 SAT) to an address which already holds coins. These will get 'overwritten' and thence lost

Imagine if someone held ₿100,000 in a single address. Don't you think that someone would just send a single satoshi to destroy it for giggles? Clearly, this mechanic would be completely unsafe, and luckily, it doesn't exist. Whenever you send a transaction, new Unspent Transaction Outputs (UTXOs) are created. These "pieces of bitcoin" are tracked via their outpoint which is the combination of the transaction that created them and their position in the output list: txid:vout. Addresses are merely a shorthand to encode output scripts that define the spending conditions for funds. There is no issue with multiple outputs sharing the same spending conditions, except the obvious privacy implications.

Thank you. My (2) is clearly based on a misunderstanding. I would upvote if I could

Works
& 3. Don't work

You could also destroy your private keys to addresses you control. Then you know the coins are lost, but others do not know.
If you send to a known burner address, everyone knows the coins are burned. Popular addresses are 1BitcoinEater.., 1Counterparty.., 111111.., adding to Satoshis' coins.
Regarding 2, any address can receive an unlimited number of different coin amounts. Each is independently spendable.
Regarding 3, OP Return cannot contain coins.


text:
different 'vout' formats
Using bitcoind rpc, I have been looking at the content of 'vout' records for a few (coinbase) transactions and don't understand the difference between them.
Looking at block 710000, the coinbase transaction has 4 outputs. The first has a 'type' of 'pubkeyhash', the remainder have a type of 'nulldata'
Looking at block 176001, the coinbase transaction has 1 output with a 'type' of 'pubkey'.
Can you point me to a reference that lists and distinguishes the possible output types?
Is 'nulldata' because of the OP_RETURN? So is it true to say that any non-zero 'value' here would be burnt?
How should I interpret the data associated with 'pubkey'? It seems as though the actual address is not in the record. But if I look at a web-based blockchain explorer, it identifies the address. How is this done?

Is 'nulldata' because of the OP_RETURN?

Yes, I guess "nulldata" is just the name given to OP_RETURN scripts by the particular software you were using.

So is it true to say that any non-zero 'value' here would be burnt?

Yes.

It seems as though the actual address is not in the record.

Addresses are just a convenient human-readable abstract of a Bitcoin script, usually based on the hash of a public key (in the case of what has historically been the most common type of transaction output). As you noticed the script is present in the network message but the address is only derived from it by software presenting it to people.

Can you point me to a reference that lists and distinguishes the possible output types?

The Bitcoin Core software (as of version 22.0 (source)) will report one of the following names under "type" for each output:

pubkey: a script that pays to a public key directly (P2PK, <pubkey> OP_CHECKSIG); it has no corresponding address.
pubkeyhash: a script that pays to a public key's hash (P2PKH, OP_DUP OP_HASH160 <pubkeyhash> OP_EQUALVERIFY OP_CHECKSIG), corresponding to a 1... address.
scripthash: a script that pays to a script hash as defined by BIP16 (P2SH, OP_HASH160 <scripthash> OP_EQUAL), corresponding to a 3... address (defined in BIP13)
multisig: a (bare) k-of-n multisig script of the form <k> <pubkey1> <pubkey2> <pubkey3> ... <pubkey_n> <n> OP_CHECKMULTISIG; it has no corresponding address, and is very uncommon now.
witness_v0_keyhash: a native P2WPKH output defined in BIP141 (OP_0 <pubkeyhash>), corresponding to a 42-character bc1p... address (defined in BIP173).
witness_v0_scripthash: a native P2WSH output defined in BIP141 (OP_0 <scripthash>) corresponding to a 62-character bc1p... address (defined in BIP173).
witness_v1_taproot: a P2TR output defined in BIP341 (OP_1 <tweaked pubkey>) corresponding to a 62-character bc1q... address (defined in BIP350).
witness_unknown: a native segwit output that isn't P2WPKH, P2WSH, or P2TR (OP_<n> <payload>, for n=1..17 and payload between 2 and 40 characters), corresponding any other BIP350 address.
nulldata: an OP_RETURN output, burning coins.
nonstandard: anything not in the list above

Is 'nulldata' because of the OP_RETURN? So is it true to say that any non-zero 'value' here would be burnt?

Indeed.

How should I interpret the data associated with 'pubkey'? It seems as though the actual address is not in the record. But if I look at a web-based blockchain explorer, it identifies the address. How is this done?

Short answer: the blockchain explorer is wrong; this output has no address.
Longer answer: the term "address" has shifted meaning over time. Historically (pre 2012), address was a synonym for "public key identifier". The more modern meaning for address is "human-readable string that uniquely corresponds to a particular output script". There is no way in typical wallet software to construct payment to a "pubkey" (P2PK) script, and thus there is no address for it. However, one can take the public key in such a script, compute its public key hash, and then report the P2PKH address corresponding to that public key hash - resulting in a P2PKH that's in theory spendable by the same party as that address. That is what the explorer you're looking at is doing, and what lots of software historically used to do. It is now considered misleading at best, because sending to that address will not result in an output with the same script, and uses a practice of "converting" from one output type to another that is not generally possible (e.g. there is no obvious way to do the same for multisig addresses). Furthermore, it is dangerous, as the receiver may not be able to sign for outputs that use an unexpected script (e.g. if they are using an HSM with well-controlled signing logic that cannot be updated for security reasons).

I don't have a good enough reputation to upvote, but thank you


text:
How do people who sell Bitcoin for fiat using Bisq know who paid them with bank transfer?
I've bought some Bitcoin for fiat using SEPA bank transfer via Bisq.
The Bisq application now actively tells you to NOT put any identifier whatsoever in the "message/OCR field" when making the international bank transfer. It used to tell you to put in a random string of letters given by the Bisq application, to identify to the receiver who has paid.
But now, they only have the amount to go by. What if two people buy the same amount of Bitcoin from the same seller, and only one of them pays? How will they now determine who has paid and who did not?
Before you say "they look at the name", at least my bank does never tell me the name of the person making a payment.


text:
pokkst/litecoinj message verification problem - Address.fromKey() returning wrong address
I have a problem with java library pokkst/litecoinj. I am using the regular bitcoinj library to verify signed messages with success. As pokkst/litecoinj is a fork of bitcoinj I have expected it to work in same or close manner.
I have a method:
private boolean isSignatureValid(NetworkParameters params, String address, String message, String signature) {
    try {
        Address signingAddress = Address.fromString(params, address);
        ECKey key = ECKey.signedMessageToKey(message, signature);
        Address addressFromKey = Address.fromKey(params, key, signingAddress.getOutputScriptType());
        return signingAddress.equals(addressFromKey);
    } catch (SignatureException | AddressFormatException exception) {
        LOGGER.error(exception.getMessage());
        return false;
    } catch (NullPointerException exception) {
        LOGGER.error("Address cannot be null!");
        return false;
    }
}

Given data (this is just a test wallet so I do not worry about it):
params -> MainNetParams.get();
address -> ltc1qhlnfnzc6djz92ylf89cvsw7jzyl98hx79ye5a5
message -> test-test-test-test-test
signature -> IC6AcfBff2TA1brwVneXPFtUyHCu1hffTvcaTyNM+i5IbNc7UgNIA4bdVu3mpr0awTsaIK7lpY4O5pS4+/SJDUw=

Important: this address and signature are generated using Electrum-LTC wallet, cause I haven't found any other litecoin wallet that will allow me to sign messages.
When I run a test against this method, i see that addressFromKey is different than signingAddress and it's value is ltc1qewvcwvf9ln6uypme8wskmg5khqwpss7v9zcrj7
My code for Bitcoin message verification is very similar, and it is working fine.
I don't have access to the wallet keys, a wallet address, message and signature is all I have.
What am I doing wrong? May this be a bug in the library? Or could it be something wrong with Electrum-LTC?

Method
ECKey.signedMessageToKey

calls:
formatMessageForSigning(message)

which uses constant BITCOIN_SIGNED_MESSAGE_HEADER_BYTES
defined:
private static final String BITCOIN_SIGNED_MESSAGE_HEADER = "Bitcoin Signed Message:\n";
private static final byte[] BITCOIN_SIGNED_MESSAGE_HEADER_BYTES = BITCOIN_SIGNED_MESSAGE_HEADER.getBytes(StandardCharsets.UTF_8);

I changed to:
BITCOIN_SIGNED_MESSAGE_HEADER = "Litecoin Signed Message:\n";

And your code worked with signatures generated by Electrum-ltc.


text:
Do nodes propagate stale blocks?
I read somewhere (but can't find now) that while a node might receive a stale block, the node won't propagate a block that it knows to be stale. Is that true?
If so I don't quite understand how a secret attacking miner, even if they did unrealistically obtain >51% hashing power, could pull off a massive reorg. I could see the attacker generating a fork with a longer chain, but when they tried to distribute that new chain to the network, they'd have to do it one block at a time. When a node received the first of the attackers new blocks, it would see it as a stale block, thus not propagate it, right?

Nodes don't propagate stale blocks.
However, blocks that are part of the heaviest chain are by definition not stale (anymore).


text:
How blockchain consensus verify the transaction?
So many blockchain documentation tell that the blockchain uses the consensus to verify transactions. But what I understand the consensus only generate the hash to create the new block. I don't know why the documentation says that the consensus verifies the transaction while the transaction has been created (made) before the consensus run for creating the new hash for new block. The consensus flow does not care about the input (group of transactions), it doesn't know the transactions group are valid or not. Why the blockchain documentation say that?

Every full node, such as a wallet like Bitcoin core, verifies all data independently.
Because all full nodes apply the same verification rules, they arrive at the same conclusion about the validity of the data.
Because these rules are the same in every node, they are called the consensus rules.
We say that the Bitcoin network reaches a consensus about the contents of the blockchain.

So the consensus is an emergent property of the network. It isn't a thing that performs actions. It is wrong to say

"the blockchain uses the consensus to verify transactions" (WRONG).

the blockchain is just data, it isn't an active agent that does things.
The consensus is just an emergent property, it isn't something that is used to perform actions.

"the consensus verifies the transaction" (WRONG)

the consensus isn't a thing that can perform actions.
nodes verify transactions

"the consensus only generate the hash" WRONG

the consensus isn't a thing that can perform actions.
miners calculate the block hash but so do all nodes that verify the block.

"before the consensus run for creating the new hash for new block." (WRONG)

There's no such thing as a "consensus run"
Hashes are not really created they are calculated from block data or transaction data that has been created. This may seem a minor distinction but I think it is important to be careful with words if we want to avoid confusion.

I think part of the confusion here is the fact that the word "consensus" is used in two different meanings here.
Bitcoin has a concept of "consensus rules", which are the rules that all blocks and transactions must obey to be considered valid. They are called this way, because all nodes must implement them exactly the same way. If two nodes differ in their implementation of consensus rules, they risk ending up on permanently distinct chains (if both have hashrate and get blocks mined that are mutually inacceptable to the nodes).
In this sense, transactions are indeed verified according to the consensus rules before they end up in a block. Because transactions that do not follow these rules are simply ignored by nodes and dropped on the floor.
Yet, there is no consensus about these transactions. They're not in a block yet, so nodes have no way of knowing whether or not other nodes consider them part of the best chain. All they know is that they are valid, and eligible for inclusion in a block.

The consensus protocol is the guarantee for stable operation of blockchain system. Nodes or computer on the network agree on a certain value or transaction through consensus protocol.

The consensus flow encodes the transactions with the nonce for generating a hash string for the block only, that mean the transactions should be verified before the consensus, isn't it?


text:
Can the value in a prev_out be less than the amount of bitcoin to send?
Let's say I have a wallet that in total received 1 bitcoin over 10 transactions of 0.1 bitcoin each. If I want to send 0.5 bitcoin to another address, will it work having only one input with one prev_out value, even though the TX referenced there only had a value of 0.1 btc? If that will not work, how do I need to make the transaction such that it will work?

If I want to send 0.5 bitcoin to another address, will it work having only one input with one prev_out value

No, it will not work with just 1 input.

If that will not work, how do I need to make the transaction such that it will work?

You will need to create a transaction that uses 5 inputs of 0.1 to create a total of 0.5 bitcoin.

Ah, ok. I assume each input needs a different prev_out tx?

yes, every input needs: previous transaction ID, v_out (output position from previous transaction), and value. The previous transaction will likely be different but it doesn't have to be different either, for example the outputs could have been all created in the same previous transaction, and in that case only your v_outs would be different.


text:
What specific verifications are done on a fresh Bitcoin TX and in what order?
I suspect the low-resource basic checks are done 1st to prevent spam attacks, then the node would prolly check against the UTXO set, and before adding the TX to its own mempool and relay it further, check against conflicts in the current mempool.
At some point the spending conditions have to be checked, but not sure if this is done here or before being added in a block.
I can't imagine a miner not doing this check, and risking adding bad stuff in the blockchain, so does it make sense to check this also at this step?
This is how I intuitively imagine it would work, but I'm sure I'm missing quite a lot of stuff.

Related: https://bitcoin.stackexchange.com/q/77934/5406

Yes, we check unconfirmed transactions to the full extent of what’s possible to do before they are included in the block, including that the scripts are valid and input scripts resolve the spending conditions defined in the corresponding output scripts. Anything that we have in our mempool is valid to be included in the next block. We even cache script validation, so when we get a new block, we do not need to check the scripts again for transactions that were in our mempool, we just need to ensure that the block is well-formed, no conflicting transactions are included in the block, and check any previously unseen transactions in full.
As to what checks are performed on transactions when they are submitted to the mempool, I have been poking around a bit in the function calls that follow a ProcessTransaction call. This is just a quick rundown from stepping through the functions and may be incomplete or not completely in order.
It seems to me that via AcceptToMemoryPool and AcceptSingleTransaction first CheckTransaction does some basic context-free checks:

The transaction has at least one input and one output
The transaction is not bigger than the block size
Each output amount is at least 0
The outputs are in in sum less than 21 M₿
There are no duplicate inputs
That outpoints referenced in inputs are not undefined
If it‘s a coinbase, the coinbase field is not too long

After that PreChecks continues with:

Checking that the transaction is not a loose coinbase transaction
Rejecting outputs with excessive amounts of null data, bare multisig, or dust outputs that cause transaction to be non-standard
Rejecting transactions shorter than 65 bytes of non-witness data
Refusing immature timelocked transactions
Skipping transactions that are already in the mempool with the same wtxid or txid
Scanning for conflicting inputs and rejecting conflicts with non-replaceable transactions (otherwise teeing up a replacement attempt evaluation)
Checking whether the UTXOs spent by the inputs are in our UTXO set, placing any transaction with unknown inputs into the orphanage
Checking whether any CSV-locked inputs are mature for mining

At this point, PreChecks calls CheckTxInputs:

Checking that any coinbase outputs are mature
Checking that input amounts are in range
Checking that the input amounts can pay for the new outputs created
Checking that the transaction fee is in range

Back in PreChecks, it now checks:

That the inputs are standard
That the inputs have standard witnesses if applicable
That the SigOps limits are met
That the transaction meets the minimum feerate
That any replacement attempts do not exceed the conflict limits
That any transactions do not exceed ancestor or descendant limits

After the PreChecks, AcceptSingleTransaction:

Checks that the maximum feerate is not exceeded
That a replacement would succeed
and finally that the transaction passes policy script checks and consensus script checks

So, in fact, any transaction that lands in our mempool is eligible to be picked into the next block.


text:
Bitcoin payments without storing blockchain
I want create a program that receives payments via bitcoin and sends them to other addresses. I'm going to generate unique address for each payment, then check if there are transactions with outputs for that address. When the required amount of bitcoins is received, I'm going to make a new  transaction for the receiver addresses.
The question is, is it necessary to store the full blockchain on disk? Could I just query other nodes for newly generated blocks after the specific hash and check transactions in these blocks? That specific hash could be fetched from the blockchain explorer. Moreover, if the new block is generated every 10 minutes, is it enough to check new blocks every 10 minutes? Should I also check different nodes to ensure that the blocks are the same?

The question is, is it necessary to store the full blockchain on disk?

No, it is not required.

Could I just query other nodes for newly generated blocks after the specific hash and check transactions in these blocks?

No you can't arbitrarily query nodes like a database -- unless you are referring to a block explorer API.
For reference purposes you can look at a project I did called NoNodePay with the purpose to allow someone to accept bitcoin payments on shared hosting without a node or having to sign up with an API service. Again just a reference point, it has bugs.

By "query other nodes" I mean using getheaders or getblocks RPC call with a known hash of the last block. That hash could be fetched from the block explorer only once. Then use getdata to get transactions. Isn't it possible? I think that's how the blockchain is normally downloaded


text:
Bitcoin 22.x + doesn't decode addresses for multisig
anyone can suggest why addresses won't decode in newer versions?
example:
bitcoin-core 0.21
bitcoin-cli getrawtransaction 9297132b89461da9dee0364db49eeb1c32770550bc5b82e02f1cbaab01043aa3 1
{
  "txid": "9297132b89461da9dee0364db49eeb1c32770550bc5b82e02f1cbaab01043aa3",
  "hash": "9297132b89461da9dee0364db49eeb1c32770550bc5b82e02f1cbaab01043aa3",
  "version": 1,
  "size": 404,
  "vsize": 404,
  "weight": 1616,
  "locktime": 0,
  "vin": [
    {
      "txid": "e5e4e758102d9d677e26fa1029a69e1a6dd1e4c60a89990c3c47c207b455fdde",
      "vout": 0,
      "scriptSig": {
        "asm": "3045022023ec9d65d61343eafba6498ed668d14a4f30507196eeda42789f9e1e5de471e80221008898d2243728f64e545b3fc13afaf9f3f54a7f1c8f9760708a4a8c7043901fbe[ALL] 04a2d908b30291114a6cc781cb7caca48393bae2faef19189b3262ae9e957204272ff30528a289146141e350869d8b7386acfd6cf20e01e4ad38ab87bf542e2aa0",
        "hex": "483045022023ec9d65d61343eafba6498ed668d14a4f30507196eeda42789f9e1e5de471e80221008898d2243728f64e545b3fc13afaf9f3f54a7f1c8f9760708a4a8c7043901fbe014104a2d908b30291114a6cc781cb7caca48393bae2faef19189b3262ae9e957204272ff30528a289146141e350869d8b7386acfd6cf20e01e4ad38ab87bf542e2aa0"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 9.70342805,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 dcfdb039e694e96dc9f49098abf5abe838ea4a2f OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914dcfdb039e694e96dc9f49098abf5abe838ea4a2f88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1M9VZnGuuXBw4YUsgzMPwCNGgBBnsoEGLW"
        ]
      }
    },
    {
      "value": 0.00005757,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 946cb2e08075bcbaf157e47bcb67eb2b2339d242 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P"
        ]
      }
    },
    {
      "value": 0.00005757,
      "n": 2,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 966acb4de317bc06c44106c3301229aba2b4ed69 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914966acb4de317bc06c44106c3301229aba2b4ed6988ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "1EiLHxqVWZ8qPFcRJ4WpZk1HPbmy2PTMs8"
        ]
      }
    },
    {
      "value": 0.00011514,
      "n": 3,
      "scriptPubKey": {
        "asm": "1 04a2d908b30291114a6cc781cb7caca48393bae2faef19189b3262ae9e957204272ff30528a289146141e350869d8b7386acfd6cf20e01e4ad38ab87bf542e2aa0 021e7be74a6b018374c253d8a7c8530952fd8bed2169a56d6591c483c3b9916b02 2 OP_CHECKMULTISIG",
        "hex": "514104a2d908b30291114a6cc781cb7caca48393bae2faef19189b3262ae9e957204272ff30528a289146141e350869d8b7386acfd6cf20e01e4ad38ab87bf542e2aa021021e7be74a6b018374c253d8a7c8530952fd8bed2169a56d6591c483c3b9916b0252ae",
        "reqSigs": 1,
        "type": "multisig",
        "addresses": [
          "1M9VZnGuuXBw4YUsgzMPwCNGgBBnsoEGLW",
          "1vAryhyeqrBkYBLcqGEUwPrRC4U4MfbNc"
        ]
      }
    }
  ],
  "hex": "0100000001defd55b407c2473c0c99890ac6e4d16d1a9ea62910fa267e679d2d1058e7e4e5000000008b483045022023ec9d65d61343eafba6498ed668d14a4f30507196eeda42789f9e1e5de471e80221008898d2243728f64e545b3fc13afaf9f3f54a7f1c8f9760708a4a8c7043901fbe014104a2d908b30291114a6cc781cb7caca48393bae2faef19189b3262ae9e957204272ff30528a289146141e350869d8b7386acfd6cf20e01e4ad38ab87bf542e2aa0ffffffff049541d639000000001976a914dcfdb039e694e96dc9f49098abf5abe838ea4a2f88ac7d160000000000001976a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac7d160000000000001976a914966acb4de317bc06c44106c3301229aba2b4ed6988acfa2c00000000000067514104a2d908b30291114a6cc781cb7caca48393bae2faef19189b3262ae9e957204272ff30528a289146141e350869d8b7386acfd6cf20e01e4ad38ab87bf542e2aa021021e7be74a6b018374c253d8a7c8530952fd8bed2169a56d6591c483c3b9916b0252ae00000000",
  "blockhash": "000000000000000007bd140bd5f9ec7d6195330b125c84ad24adb7f021012502",
  "confirmations": 410973,
  "time": 1409535793,
  "blocktime": 1409535793
}

bitcoin-core 22.x+
{
  "txid": "9297132b89461da9dee0364db49eeb1c32770550bc5b82e02f1cbaab01043aa3",
  "hash": "9297132b89461da9dee0364db49eeb1c32770550bc5b82e02f1cbaab01043aa3",
  "version": 1,
  "size": 404,
  "vsize": 404,
  "weight": 1616,
  "locktime": 0,
  "vin": [
    {
      "txid": "e5e4e758102d9d677e26fa1029a69e1a6dd1e4c60a89990c3c47c207b455fdde",
      "vout": 0,
      "scriptSig": {
        "asm": "3045022023ec9d65d61343eafba6498ed668d14a4f30507196eeda42789f9e1e5de471e80221008898d2243728f64e545b3fc13afaf9f3f54a7f1c8f9760708a4a8c7043901fbe[ALL] 04a2d908b30291114a6cc781cb7caca48393bae2faef19189b3262ae9e957204272ff30528a289146141e350869d8b7386acfd6cf20e01e4ad38ab87bf542e2aa0",
        "hex": "483045022023ec9d65d61343eafba6498ed668d14a4f30507196eeda42789f9e1e5de471e80221008898d2243728f64e545b3fc13afaf9f3f54a7f1c8f9760708a4a8c7043901fbe014104a2d908b30291114a6cc781cb7caca48393bae2faef19189b3262ae9e957204272ff30528a289146141e350869d8b7386acfd6cf20e01e4ad38ab87bf542e2aa0"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 9.70342805,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 dcfdb039e694e96dc9f49098abf5abe838ea4a2f OP_EQUALVERIFY OP_CHECKSIG",
        "desc": "addr(1M9VZnGuuXBw4YUsgzMPwCNGgBBnsoEGLW)#e82gnjrl",
        "hex": "76a914dcfdb039e694e96dc9f49098abf5abe838ea4a2f88ac",
        "address": "1M9VZnGuuXBw4YUsgzMPwCNGgBBnsoEGLW",
        "type": "pubkeyhash"
      }
    },
    {
      "value": 0.00005757,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 946cb2e08075bcbaf157e47bcb67eb2b2339d242 OP_EQUALVERIFY OP_CHECKSIG",
        "desc": "addr(1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P)#03u9lduk",
        "hex": "76a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac",
        "address": "1EXoDusjGwvnjZUyKkxZ4UHEf77z6A5S4P",
        "type": "pubkeyhash"
      }
    },
    {
      "value": 0.00005757,
      "n": 2,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 966acb4de317bc06c44106c3301229aba2b4ed69 OP_EQUALVERIFY OP_CHECKSIG",
        "desc": "addr(1EiLHxqVWZ8qPFcRJ4WpZk1HPbmy2PTMs8)#c68jlngz",
        "hex": "76a914966acb4de317bc06c44106c3301229aba2b4ed6988ac",
        "address": "1EiLHxqVWZ8qPFcRJ4WpZk1HPbmy2PTMs8",
        "type": "pubkeyhash"
      }
    },
    {
      "value": 0.00011514,
      "n": 3,
      "scriptPubKey": {
        "asm": "1 04a2d908b30291114a6cc781cb7caca48393bae2faef19189b3262ae9e957204272ff30528a289146141e350869d8b7386acfd6cf20e01e4ad38ab87bf542e2aa0 021e7be74a6b018374c253d8a7c8530952fd8bed2169a56d6591c483c3b9916b02 2 OP_CHECKMULTISIG",
        "desc": "multi(1,04a2d908b30291114a6cc781cb7caca48393bae2faef19189b3262ae9e957204272ff30528a289146141e350869d8b7386acfd6cf20e01e4ad38ab87bf542e2aa0,021e7be74a6b018374c253d8a7c8530952fd8bed2169a56d6591c483c3b9916b02)#vp945myn",
        "hex": "514104a2d908b30291114a6cc781cb7caca48393bae2faef19189b3262ae9e957204272ff30528a289146141e350869d8b7386acfd6cf20e01e4ad38ab87bf542e2aa021021e7be74a6b018374c253d8a7c8530952fd8bed2169a56d6591c483c3b9916b0252ae",
        "type": "multisig"
      }
    }
  ],
  "hex": "0100000001defd55b407c2473c0c99890ac6e4d16d1a9ea62910fa267e679d2d1058e7e4e5000000008b483045022023ec9d65d61343eafba6498ed668d14a4f30507196eeda42789f9e1e5de471e80221008898d2243728f64e545b3fc13afaf9f3f54a7f1c8f9760708a4a8c7043901fbe014104a2d908b30291114a6cc781cb7caca48393bae2faef19189b3262ae9e957204272ff30528a289146141e350869d8b7386acfd6cf20e01e4ad38ab87bf542e2aa0ffffffff049541d639000000001976a914dcfdb039e694e96dc9f49098abf5abe838ea4a2f88ac7d160000000000001976a914946cb2e08075bcbaf157e47bcb67eb2b2339d24288ac7d160000000000001976a914966acb4de317bc06c44106c3301229aba2b4ed6988acfa2c00000000000067514104a2d908b30291114a6cc781cb7caca48393bae2faef19189b3262ae9e957204272ff30528a289146141e350869d8b7386acfd6cf20e01e4ad38ab87bf542e2aa021021e7be74a6b018374c253d8a7c8530952fd8bed2169a56d6591c483c3b9916b0252ae00000000",
  "blockhash": "000000000000000007bd140bd5f9ec7d6195330b125c84ad24adb7f021012502",
  "confirmations": 410994,
  "time": 1409535793,
  "blocktime": 1409535793
}

as we can see there is no "addresses": ["1M9VZnGuuXBw4YUsgzMPwCNGgBBnsoEGLW", "1vAryhyeqrBkYBLcqGEUwPrRC4U4MfbNc"] in vout: 3
Why script not decoding?

This is mentioned in the 22.0 release notes:

The following RPCs: gettxout, getrawtransaction, decoderawtransaction, decodescript, gettransaction, and REST endpoints: /rest/tx, /rest/getutxos, /rest/block deprecated the following fields (which are no longer returned in the responses by default): addresses, reqSigs. The -deprecatedrpc=addresses flag must be passed for these fields to be included in the RPC response. This flag/option will be available only for this major release, after which the deprecation will be removed entirely. Note that these fields are attributes of the scriptPubKey object returned in the RPC response. However, in the response of decodescript these fields are top-level attributes, and included again as attributes of the scriptPubKey object. (#20286)

The reason is simply that these fields were nonsensical and misleading. Outputs only have a single address at most. The RPC output dates from a time when addresses and key identifiers were conflated - a historical mistake.
The new "address" field reports the address, under the modern interpretation. It differs in the case of bare multisig outputs. These outputs are rare nowadays, and more importantly do not have a corresponding address at all. The values reported in the older "addresses" field were not addresses for this output; they are the would-be P2PKH address for sending to the individual public keys in that multisig output. But those have barely any relation to the actual output, and confused people into thinking that e.g. one could send to these individually (which is not generally the case).


text:
How to convert a compressed public key into uncompressed one in Python?
I've searched really hard for a Python script that coverts a compressed public key into uncompressed one, since I don't know how to code this.
I stumbled upon these links:
https://stackoverflow.com/questions/43629265/deriving-an-ecdsa-uncompressed-public-key-from-a-compressed-one
How to uncompress a public key?
https://bitcointalk.org/index.php?topic=644919.0
but all python scripts/functions either don't work or outputting incorrect values. I tried to debug them and failed.
Could you point out how to code something like this in Python or give an example of the working code?
Here are the values to play with (HEX):
#Test case 1
#Compressed Pubkey: 025A2146590B80D1F0D97CC7104E702011AFFF21BFAF817F5C7002446369BA9DDC
'''
Right Uncompressed Pubkey:
045A2146590B80D1F0D97CC7104E702011AFFF21BFAF817F5C7002446369BA9DDC9BD5DCD1B4A737244D6BB7B96E256391B8597D3A7972A6F8CA9096D4AEA1F37E
'''

#Test case 2
#Compressed Pubkey: 035728F4692D85D411DF3643CD69FE05C411A0D507C7D814008F56C8F260AD7ED9
'''
Right Uncompressed Pubkey:
045728F4692D85D411DF3643CD69FE05C411A0D507C7D814008F56C8F260AD7ED99E2DF8D9CB1A575D55264692629AE22E518BC14AD02592941C13BE6755C72973
'''

#Test case 3
#Compressed Pubkey:039E87EB177890FDD788B95843ED53AD4FB6E877E3F730EF1E73593964C2AB9D15
'''
Right Uncompressed Pubkey:
049E87EB177890FDD788B95843ED53AD4FB6E877E3F730EF1E73593964C2AB9D15A3B647C8C4A0766420917B7B445CDCD6BFEC2900175C5534C6113954F3FF00D9
'''

Using this library (disclaimer: I am the author):
>>> from cryptotools import PublicKey

>>> PublicKey.from_hex('025A2146590B80D1F0D97CC7104E702011AFFF21BFAF817F5C7002446369BA9DDC').hex(compressed=False)
'045a2146590b80d1f0d97cc7104e702011afff21bfaf817f5c7002446369ba9ddc9bd5dcd1b4a737244d6bb7b96e256391b8597d3a7972a6f8ca9096d4aea1f37e'

When trying to input an compressed PubKey in 0x hex format and later converted to string with str() into this function it outputs the following error:
in decode assert len(key) == 33, 'A compressed public key must be 33 bytes long'
AssertionError: A compressed public key must be 33 bytes long
So the compressed key has to be a string with '' single quotes. This way it works.
Nevertheless, thanks!


text:
What total_amount in liquid gettxoutsetinfo command means?
$ elements-cli gettxoutsetinfo muhash
{
  "height": 2655501,
  "bestblock": "5d52cd99233d96c5d99c1b80e2e04fcd068b83d0957095c6728bec98ca16c853",
  "txouts": 274112,
  "bogosize": 20056230,
  "muhash": "ef3fe8d1f94bc6360ea456fdcec78e30db123da2a996e01e1e73cea7500b287e",
  "total_amount": 29014665.56386005,
  "transactions": 177123,
  "disk_size": 38058240
}

total_amount here is ~29,014,665. The help section says "The total amount of coins in the UTXO set". But I see only "3,346.37 L-BTC in circulation" in the Liquid.Network explorer

It appears to be the sum of all outputs with explicit (unblinded) values across all assets (not just L-BTC).
This should be changed to something more meaningful with multiple/confidential assets.
https://github.com/ElementsProject/elements/blob/2d298f7e3f76bc6c19d9550af4fd1ef48cf0b2a6/src/node/coinstats.cpp#L90


text:
Example of Schnorr signature on a block explorer?
Can somebody link to a Schnorr signed transaction on Mainnet or Testnet?
Looking to see how the SCRIPTSIG differs.

Does this answer your question? How can I find samples for P2TR transactions on mainnet?

Cool. A nit on terminology. It isn't the scriptSig for SegWit and Taproot. It is the witness. More details here: https://bitcoin.stackexchange.com/questions/107872/what-are-the-scriptpubkey-scriptsig-redeem-script-and-witness-for-the-various

Actually, I'm looking for a SCRIPTSIG with OP_CHECKSIGADD...

This transaction is listed as the first use of the Tapscript opcode OP_CHECKSIGADD, but I don't see it here. https://blockstream.info/tx/2eb8dbaa346d4be4e82fe444c2f0be00654d8cfd8c4a9a61b11aeaab8c00b272?expand

I want to understand the diff between an ECDSA multisig and a Schnorr multisig at the script level.

@liliaceae OP_CHECKSIGADD cannot occur in a scriptSig, as the opcode only exists in Taproot script spends, and those store the script in witness field, not in the scriptSig (which is only used for pre-segwit spends).

@liliaceae: Please edit your question to update the scope of your topic as communicated in the comments, if you are still looking for an answer. If your question was answered by the linked questions, please vote to close as a duplicate.