text:
I sent bitcoin from coinbase to my wallet, but it never got to my wallet. It says the transaction was completed. Can I get it back?
When I logged into my wallet, the bitcoin never showed up. Is there a way I can get the money back from Coinbase?

If your wallet, says that the transaction is complete you can check its status: https://www.blockchain.com/btc/tx/<replace_with_transaction_hash>
If you see that transaction got 6 confirmations or more and, isn' t reflected, at Coinbase you should contact support. I' m not a Coinbase user so don' t know about their deposit policy. You could probably find it in your deposit page


text:
When mining a block reward, does it have to have an ip address present in order to complete the reward
When mining a block reward, Does it (The reward provider)have to have an IP Address/Computer Connected to Internet) present in the whole process in order to complete the reward on the block chain.What i am asking is it possible to mine a block reward with no internet access.

There is no reward provider, the Bitcoin network itself manages that. Miner doesn't have to publish anything about themselves, all we need is a block and a valid PoW. Miners pay themselves with a specific transaction inside a block, called coinbase transaction.
You can mine with no internet access, but if you want to mine a Bitcoin block and get reward from that, you'll have two problems:

How to get data to build a block and mine.
How to broadcast your block after you mine it.

If you solve both problems, you can mine offline.

When building a block template, each miner includes a coinbase transaction which assigns the block reward to an address of the miner's choosing. When they find a block, their coinbase transaction becomes a part of the blockchain and the miner pays themselves.
Contributing to Bitcoin mining requires internet to learn about the previous block, unconfirmed transactions, and to broadcast blocks found. You could perform mining without internet, if you're not actually participating in a P2P such as when running a testnet locally.

Thankyou ,just as i thought much appreciated.

source: Stack Exchange

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

sort: votes


text:
Bitcoin Core 21.1 still no coin for me?
I have it setup i think on Windows 10 64 bit setup the wallets and encrypted it its been running solid for 8 hours and my bitcoin is showing 0.0000000 BTC still both available and pending what am i missing? In the info screen connections i have 22 (12 in and 10 out) number of transactions is 1078 like am i missing something? do i have to set something in CMD ? I checked the fire wall and allowed 8333 port and allowed the program to run in defender

You're missing some information. Do you know your wallet had coins in it earlier?

Does the status bar at the bottom of the window say "Synchronising with network"?

Are you trying to recover an old wallet, or are you under the impression that just running Bitcoin Core will cause money to be credited? Successful mining with home computers has not been feasible since 2013.

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


text:
What is the Crypto in Metaverse
When I read about the Metaverse in today's crypto space, I think of Second Life and my understanding is that Metaverse as used in today's crypto space is basically Second Life with VR but this looks too straightforward to cause so much excitement as seen in the crypto community that I think I'm missing something important. Why do we need crypto for in Metaverse projects?

'Metaverse' seems like a buzzword these days, but to answer you question quite generally:
The invention of the internet allowed humanity to find all sorts of new ways to share and exchange information. We keep creating more and more ways to share more and more data, and perhaps AR/VR/metaverse tech will help continue this in the future.
The invention of bitcoin is similar in my opinion, in that it will allow humanity to engage in all sorts of new ways to share and transact value. So it seems plausible that some of the experiences that you could have in the 'metaverse' could warrant an exchange of value between the participants.
To simply build/engage with the metaverse, there certainly is no 'crypto' token required, technically speaking. But if metaverse users want to transact, it seems reasonable to assume that they might do so using something like bitcoin (ie, an open and secure network, that operates independently of the metaverse itself). Having the option to enable a digital economy via an open monetary network is something fairly new and novel, so it is difficult to predict what the future might look like. Who could have predicted how popular an app like instagram would be, back in the early 90s? Only time will tell how it all plays out.


text:
Is there a standard P2PKH?
I was implementing a small application that computes the bitcoin address starting from a private key (256-bit number). I am surprised about the lack of a single trustworthy reference to this, unlike the case of the BIPs.
The book of Antonopoulos and the bitcoin wiki indicate that the public key (pubK) must go through sha256 and ripemd160 hashes before base58check encoding that results in the final bitcoin address; there are also details about the version byte. But the pubK could be serialized in at least two forms, either the full 65-bytes 0x04<xcoord><ycoord> or the compressed 33-bytes 0x02/0x03 <xcoord> representation. Both lead to different bitcoin addresses. The wiki explains step by step how to obtain an address from the compressed pubK, but the image in the page shows a diagram that uses the full pubK representation instead. The http://gobittest.appspot.com/ website, referenced in the bitcoin wiki for testing the WIF format, computes the addresses using the full pubK.
Alright, I know that the private key WIF serialization format has a byte to indicate whether the pubK addresses are computed using the the compressed or full representation (see https://en.bitcoin.it/wiki/Wallet_import_format).

Also add a 0x01 byte at the end if the private key will correspond to a compressed public key.

However,

it is not mentioned anywhere what is the value of that byte when the full pubK is used.
ultimately a private key is just a 256-bit number, there should be a unique way to derive an address from there.

Are there actually two addresses for each private key in the bitcoin-core implementation? Isn't there like a standard way of getting the address?

The representation of the bytes for the full 65 or compressed 33 bytes does change the public key but that cannot change the owners ability to sign for said public key. When you sign for the p2pkh transaction you provide this public key and therefore if you used the 65 byte one you would have to provide that and if you used the 33 byte version you would provide that. Saving 1/2 the byte size is probably the logical choice.

I do not know however if there is a restriction on which one you can use because of how the opcodes behave, I would imagine not but it would be interesting to know if so.

it is not mentioned anywhere what is the value of that byte when the full pubK is used.

There is none. The WIF format for uncompressed private keys is just base58check encoding of version byte + 32-byte private key. For compressed private keys (as in: the corresponding public key is to be in compressed format) the WIF format is base58check encoding of version byte + 32-byte private key + 0x01.

ultimately a private key is just a 256-bit number, there should be a unique way to derive an address from there.

Cryptographically speaking, yes, a private key is just a 256-bit number. But from Bitcoin's perspective, because the encoding of the public key matters, private-keys-whose-pubkey-is-compressed vs. private-keys-whose-pubkey-is-uncompressed are distinct keys.

Are there actually two addresses for each private key in the bitcoin-core implementation?

Specifically for P2PKH addresses, if you think of private keys as just the 256-bit discrete logarithm, yes. If you also include P2WPKH, P2SH-P2WPKH, P2TR addresses there are even more.
But as said, it's easier to think of it being two separate private keys, and then each has exactly 1 corresponding public key, and those on their turn have exactly one corresponding P2PKH address.

Isn't there like a standard way of getting the address?

It's hard to call anything standard as all of this predates the introduction of the BIP standardization process in which protocol changes and wallet standards are specified (compressed public keys were introduced in 2011).
But if we're talking about best practices, by all means, just use compressed public keys. There is no point wasting an additional 32 bytes on chain just because historically Bitcoin's creator likely just didn't know about compressed keys.
Or even better, use P2WPKH or P2TR for single-key addresses. They're even cheaper to spend.


text:
Is there any way to commit mempool transactions to blockchain?
I have thousands of transactions in mempool but not very many have been committed to the blockchain. Can anyone tell me why?

It’s not entirely clear to me what your actual question was. Are you asking why each block does not confirm all waiting transactions at once?

Is there any way to commit mempool transactions to blockchain?

By mining

I have thousands of transactions in mempool but not very many have been committed to the blockchain. Can anyone tell me why?

That ought to be normal, depending on what time period is involved.

Every node keeps a list of unconfirmed transactions in their mempool.
Miners take transactions from their mempool and add them to a new block that they mine. If successful, the new block, and the transactions in it are added to the blockchain.
Approximately every ten minutes, a new block is added to the blockchain. The block can contain two or three thousand transactions. So having thousands of transactions accumulating ought to be normal.
So the only way to move transactions from mempool to blockchain are to wait for them to be mined by a miner.

Other relevant questions here with potentially useful answers:

Incoming and Outgoing Node Connections
Bitcoin Core not updating to latest block
Do I have to open port 8333 for incoming connections?

You should clarify. Further. What do you mean by facilitate? Simply operating a Bitcoin core node that allows incoming connections does facilitate the process. How are you measuring the rate of transactions passing through?

It might be that you are not yet well connected to peers. It might be that your configuration of Bitcoin-core, PC, router or firewall is blocking some connections.

I just ran netstat and can see active connections. I enabled the default bitcoin port 8333 to allow for connections. I can't think of anything else that might be inhibiting me from connecting to peers.

What concerns me is that your comments don't seem to be about the "way to commit transactions from mempool to blockchain" in your question title. You seem to be concerned that your node may not be functioning as a full-node properly. Which is a different question really.

“That ought to be normal, depending on what time period is involved.” > In fact, I’d be shocked if there were any transactions at all that were both in the mempool and in the blockchain. ;)


text:
How to extract transaction amounts from tx block?
I'm parsing bitcoin transactions and would like to be able to strip out transaction amounts. This site says that I have to use flags to extract out the transaction amounts but it appears to only take one address into account. Does the same logic hold if I were to apply other flags to the amounts I'm extracting? Also, what are the end markers I could use to extract that amount?
Thank you in advance.

I suggest you study some existing code that does transaction parsing, which exists for almost any programming language you'd want. Even if you can't use it directly, it'll teach you more than asking dozens of questions here for every misunderstanding you have.

I don't understand your question; what flags are you talking about? The ones in the transaction format to indicate the BIP144 witness serialization? You need to those know whether witnesses are present, but they're unrelated to amounts. Amounts are just 8 byte values, always, without any end markers. I also don't see anything on that page that assumes there is just one address (and even further: addresses don't exist at the protocol level, only scripts/inputs/outputs).

This site says that I have to use flags to extract out the transaction amounts [...] Also, what are the end markers I could use to extract that amount?

(my emphasis)
My advice is don't search the hex data for magic flag or marker values, parse the data completely:

Here's how I would parse a raw transaction in network format and start to calculate the transaction value:
/* Example basic parsing blockchain transaction data, Redgrittybrick 2023 */
package main

import (
    "bytes"
    "encoding/binary"
    "encoding/hex"
    "fmt"
    "os"
)

const txhex string =
    "0200000000010179aaafbe7c9d3b0812a489facaf77508c08c190ec7dfd82f12" +
    "9aeb995aca23ab0000000000fdffffff020bd2190000000000160014d2caa7b0" +
    "8db89cd62c9af34da53332d30e53bb1598151b00000000001600143d4427468c" +
    "be7ae396427a1aa9128fa05b18c7db024730440220573fd27574cfdde4843476" +
    "21e1f48f85ae975cb8c2265a04496ded038896822302204a5e04a3a2d160c315" +
    "8caa39b58bfc91ac64c484078ec0225a7d4d2d4454661f012103d96e3819b522" +
    "45e42c76f869c9a875f6ea5344cf1aee2e6b3ab03adcfef0d80ede3b0b00"

func main() {
    txbin, err := hex.DecodeString(txhex)
    check(err)

    buf := bytes.NewBuffer(txbin)

    // VERSION
    version := buf.Next(4)
    fmt.Printf("Version = %x\n", version)

    // OPTIONAL SEGWIT MARKER AND FLAG
    // OR INPUT COUNT
    var segwitMarker, segwitFlag byte // each defaults to 0
    inputCount := NextCInt(buf)
    if inputCount == 0 { // It's a Segwit marker, not an input count
        segwitFlag, err = buf.ReadByte() // expect 1
        check(err)
        fmt.Printf("Segwit Marker = %x, Flag = %x\n" segwitMarker, segwitFlag)
        inputCount = NextCInt(buf)
    }
    fmt.Printf("Input Count = %d\n", inputCount)

    // INPUTS
    for i := 0; i < int(inputCount); i++ {
        txid := buf.Next(32)
        vout := binary.LittleEndian.Uint32(buf.Next(4))
        scriptLen := NextCInt(buf)
        fmt.Printf("Input %d: tx = %x vout = %d\n", i+1, txid, vout)
        fmt.Printf("\tUnlocking Script length = %d\n", scriptLen)
        if scriptLen > 0 {
            script := buf.Next(int(scriptLen))
            fmt.Printf("\tScript = %x\n", script)
        }
    }

    // SEQUENCE
    sequence := buf.Next(4)
    fmt.Printf("Sequence = %x\n", sequence)

    // OUTPUTS
    outCount := NextCInt(buf)
    fmt.Printf("Output count = %d\n", outCount)
    var txValue uint64
    for o := 0; o < int(outCount); o++ {
        amount := binary.LittleEndian.Uint64(buf.Next(8))
        scriptLen := NextCInt(buf)
        script := buf.Next(int(scriptLen))
        fmt.Printf("Output %d: value = %d script = %x\n", o+1, amount, script)
        txValue += amount
    }

    //WITNESSES
    if segwitFlag != 0 {
        for i:=0; i<int(inputCount); i++ {
            compCount := NextCInt(buf)
            for c:=0; c<int(compCount); c++ {
                l := NextCInt(buf)
                if l > 0 {
                    component := buf.Next(int(l))
                    fmt.Printf("Witness %d component %d = %x\n",
                        i+1, c+1, component)
                }
            }
        }
    }

    // LOCKTIME
    lockTime := buf.Next(4)
    fmt.Printf("Locktime  = %x\n", lockTime)

    // DERIVED DATA
    fmt.Printf("\n(Tx value (less fee) = %d)\n", txValue)
}

// Extracts a Compact Int
func NextCInt(buf *bytes.Buffer) (uint64) {
    var result uint64
    first, err := buf.ReadByte()
    check(err)
    switch first {
    case 0xFF :
        result = binary.LittleEndian.Uint64(buf.Next(8))
    case 0xFE :
        result = uint64(binary.LittleEndian.Uint32(buf.Next(4)))
    case 0xFD :
        result = uint64(binary.LittleEndian.Uint16(buf.Next(2)))
    default :
        result = uint64(first)
    }
    return result
}

// Rudimentary error handling
func check(err error) {
    if err != nil {
        fmt.Fprint(os.Stderr, err)
        os.Exit(1)
    }
}

Output
Version = 02000000
Segwit Marker = 0, Flag = 1
Input Count = 1
Input 1: tx = 79aaafbe7c9d3b0812a489facaf77508c08c190ec7dfd82f129aeb995aca23ab vout = 0
        Unlocking Script length = 0
Sequence = fdffffff
Output count = 2
Output 1: value = 1692171 script = 0014d2caa7b08db89cd62c9af34da53332d30e53bb15
Output 2: value = 1775000 script = 00143d4427468cbe7ae396427a1aa9128fa05b18c7db
Witness 1 component 1 = 30440220573fd27574cfdde484347621e1f48f85ae975cb8c2265a04496ded038896822302204a5e04a3a2d160c3158caa39b58bfc91ac64c484078ec0225a7d4d2d4454661f01
Witness 1 component 2 = 03d96e3819b52245e42c76f869c9a875f6ea5344cf1aee2e6b3ab03adcfef0d80e
Locktime  = de3b0b00

(Tx value (less fee) = 3467171)

The code is quick and dirty. Production code needs more defensive error checking in case of corrupt, invalid or truncated data. For example it should use buf.Read() instead of buf.Next() and check for errors thrown. Normally I'd populate an object (go data struct) instead of just printing stuff out. To calculate the fee you need to extract vout value from referenced prior transactions, fee=sum(ins)-sum(outs).
Note that the code above has no external dependencies - the imports are just standard go libraries that come with the compiler. It doesn't rely on any Bitcoin library (which also means it is unproven code!)
The go compiler is a free download at  https://go.dev/ it compiles to a single native execatable (and can cross-compile to other platform), A typical way to use the above might be

install go compiler
create a project folder somewhere convenient
cd to folder
copy above go code into file named main.go (or anything.go)
go mod init
go mod tidy
go build
run new program

The go mod ... commands are project initialisation and don't need to be repeated when recompiling.
It is certainly more than possible this code has other flaws (comments welcome) but I hope it acts as a potential starting point or at least suggests a possible approach that can be implemented in your preferred programming language.

It's not clear what method you are using, parsing raw block data or CLI/RPC calls. Since you are only asking for values the basic principle is simple.
Pick a block, and use getblock blockHash 2 but replace blockHash with actual hash. The 2 will return details on each transaction in the block as if you did a getrawtransaction on every transaction.
Now all you need to do is add up all the output values for each transaction.


text:
Can Bitcoin Core 0.9.5 still fully sync?
Solo Linux GPU bitcoin miner here (doing it for fun not profit so please, no 'what's the point' answers).  Working mining software for this purpose is far and few in between, but I have been able to get it to work with recent versions of Bitcoin Core with nsgminer to achieve a modest ~2.5 Mhz/s hashrate. nsgminer uses OpenCL, and the word is that CUDA offers much better performance on Nvidia hardware, and I'm curious what kind of hashrate I can get. However, the only miner that could potentially work, would compile with recent versions of CUDA, and available for Linux is klaust/ccminer, which does not support getblocktemplate, while Bitcoin Core got rid of getwork since v0.10.x. So I'm building a new node with v0.9.5, which doesn't work with the blockchain fully built with a much later version. The sync rate slows down significantly aroundd 60% as it starts to struggle to find compatible peers, and now it is almost 80% but seems to inch toward it asymptotically (though I've only been at it for about a day). So my questions is, can v0.9.5 still fully sync? If not, I'd rather not to waste my bandwidth on getting terabytes of unusable packets and just kill it now.

Yes, 0.9.5 is consensus compatible with modern Bitcoin, though it will be considerably slower than modern versions, and probably shouldn't be used for anything that's transacting real money.

Thank you! That's encouraging.

Just being compatible isn't sufficient to make it synchronize. The block download logic was completely overhauled in 0.10, as it had became barely possible to synchronize even then using the logic that was in 0.9 and earlier versions. You're probably better off synchronizing with maybe 0.12 (last pre-segwit version), exporting the blockchain using the linearize script, and then importing the result in a new 0.9 install.

@PieterWuille thank you, that's a great idea.

@PieterWuille by the way it worked


text:
Block packets contain tx_in_sig_script, is this shared with tx data from tx packets?
I'm trying to find the signature script that is in a tx message so I can better parse data. I have found that it is in there sometimes, but largely the tx packets don't contain anything in the block packet. How can this be?

No, transactions are self-contained. Can you give an example of a transaction hex that you fail to parse?

Is what you are seeing perhaps explained by native segwit inputs having a signature script of length 0? Your question sounds like an X-Y problem. Are you actually trying to solve a completely different problem, came up with your own approach to a solution and are now asking about that? What is the big-picture issue you are trying to solve?

@Murch what I'm trying to do is narrow down the amount of TX data I'm parsing. I figured that I could parse the data in reverse after the lock time. Then save bytes until I find a bite that matches the length of the bites stored. Does this make sense to do?

Going reverse does not seem like a promising approach to me. Since you don’t know the length of the field until you’ve seen the length indicator, it’s not clear to me how you would know that you have found it. Even if you find a byte that matches the length of what you walked back so far, it could just be a random match inside of the field. I would start from the front.

There is this document that I’ve been working on that aims to describe the fields of transactions. Perhaps it would be useful to you: https://github.com/Xekyo/bips/blob/d119d3bdee38784f2ca70301f58eaa4933b312d0/bip-tx-terminology.mediawiki#user-content-Anatomy_of_a_serialized_transaction

@Murch how do I determine I'm at a sequence? You don't say much about it on github

The >>100000 tx/sec code I gave in answer to a previous question should work in all cases. Note Murch's comment about Segwit. Your question definitely lacks clarity - I suggest you edit it to include minimal runnable code, sample data, actual output and expected output. If your code is slow the usual answer is better algorithms or a better language (e.g. compiled rather than interpreted)

The sequence can take any value. I don't see how it could be done going backwards. Going forwards, the length of the input script tells you. After reading the input script length, you know how many bytes to read for the input script. After that there are four bytes of sequence.

It seems to me that most of the difficulty you're experiencing is due to your approach. The transaction data structure has a number of variable length fields or can have multiple elements of the same type. Where there is flexibility, a counter or length indicator tells you how many elements or bytes to expect. Parsing such a data structure from the back sounds like a terrible idea, if it's not completely infeasible. I don't understand why you're implementing this from scratch in the first place, but please do yourself the favor of going the direction where it tells you what to expect.

If you want to look at a few more transactions nicely broken down, check out e.g. yogh.io.

@bitcoinluvr6969 There is no way you can parse transaction data backwards, as every element is prefixed with its length, you need to start from the beginning. It would be helpful if you can edit your question with some actual transaction (or otherwise) data you're trying to parse, so we can clarify exactly what you're seeing, rather than needing to guess all your misconceptions.

@Murch and everyone. Thank you very much for the good information you all have been providing. I'm curious though, how does one distinguish the data murch made on github v. the data found in yogh.io? It is apparent that you cannot traverse the bytes the same way. Or am I wrong?

@bitcoinluvr6969 It's very unclear what you're talking about. There is just one transaction format, and all code and descriptions out there deal with it all the same (including murch's explanation, and yogh.io). If something is unclear please post an actual example of something that is confusing to you.

@PieterWuille The example murch linked me to that you and he created does not include the following at the beginning of the raw transaction: magic bytes, tx command, payload size, payload checksum, previous block, merkle root, timestamp, bits, nonce, coinbase transaction, among others. Or, am I (like usual) wrong? If they are in there, how are they derived?

It sounds like you're looking at (arbitrary?) messages in the P2P protocol, as they are sent on the wire (that's where magic, command, payload size, checksum come from). In "tx" messages specifically, the payload is a transaction. @Murch's link, and yogh.io, are just explaining the transaction structure itself, without its wrapping P2P message. And transactions occur in other places too, e
g. in a "block" message a block payload is sent, which consists of a block header followed by a tx count, and then a list of transactions, all following the same transaction structure.

So you mean that transactions are sent in multiple places? So, I'm sorry to beat this into the ground but I just want to be thorough, and thank you for taking the time to explain this stuff to me. So, a block contains tx data, but the tx command also contains tx data? Which one of them is sent by multiple peers? Is it the block message? I only ever see one tx message being sent out.

@bitcoinluvr6969 It sounds to me like you need to read up on far more details about how the Bitcoin protocol works before diving into how the actual serialization works. Going that deep is out of scope for the comment section here.

Block packets contain tx_in_sig_script, is this shared with tx data from tx packets?

All network packets follow the same serialisation for transactions. It is specified in https://en.bitcoin.it/wiki/Protocol_documentation#tx.
So far as I know, if you transmit a getdata request for transactions, you should receive exactly the same byte-stream for a transaction that you would find inside the byte stream for a retrieved block.

I figured that I could parse the data in reverse after the lock time.

misery and madness lies way That
regret and Failure
recrimination-self and Disappointment
disillusionment and Sadness
frustration and futility into descent spiral steep A
path this choose not Do
sanity to back way the see to wits the retain still you while Retreat
way the not is way That

blocks> blockchain -file blk03448.dat
blk03448.dat     67 blk,  150687 tx,  130612 segwit,  383145 ins,  457851 outs, 1.1536802s

blocks> blockchain -file blk03448.dat
blk03448.dat     67 blk,  150687 tx,  130612 segwit,  383145 ins,  457851 outs, 702.4941ms

So, disregarding disk IO, the most simple unoptimised code can parse 150687/0.702 = 214,654 transactions a second (4.6 µs/tx) on a fairly ordinary 5 year old PC when parsing stuff forwards.


text:
Writing custom test scripts
I'm interested in writing some custom test scripts for btc core. Is there any documentation on the test suite anywhere? I did find this link.

Could you be more specific what you want to do? What type of test are you talking about? Functional tests, unit tests, fuzz tests, benchmarks, or something else?

Functional tests


text:
How to extract p2sh from tx block
I'm trying to extract p2sh addresses from blocks and I am not doing something correctly. What I have tried is:
    def decodep2sh(self, redeemscript):
        sha256 = hashlib.sha256(bytes.fromhex(redeemscript)).hexdigest()
        h = RIPEMD160.new()
        h.update(bytes.fromhex(sha256))
        final_address = base58check.b58encode(bytes.fromhex(h.hexdigest()))
        return final_address

Could anyone tell me what I might be doing wrong?

Are you building this program from some example? If so can you provide the example.

What do you mean by an example?

Where did you get the instructions to decode a redeem script this way? Im not inferring its wrong, but if you are learning to do this from some source providing that context would be helpful.

Oh I see! Sorry for the confusion. No, I am doing this as part of my research at my university. I listening to blocks come in real time and trying to see if I can extract addresses.

I found this interesting article https://btcleak.com/2020/07/19/we-solved-a-p2sh-transaction-puzzle-and-redeemed-bitcoin/ which includes this python formula, perhaps it will work here.

import binascii, hashlib, base58
script = '51'
base58.b58encode_check(binascii.unhexlify('05'+ hashlib.new('ripemd160', hashlib.sha256(binascii.unhexlify(script)).digest()).hexdigest())).decode()
'3MaB7QVq3k4pQx3BhsvEADgzQonLSBwMdj'

You should use existing Bitcoin libraries to do the parsing; there exist several in just Python alone. Based on other questions you're asking here, I infer you're basically trying to reverse engineer the transaction format. That'll take a long time, and will likely cause you to miss many edge cases even if you get it to work for most transactions.

@PieterWuille I appreciate what you're saying but my professor has explicitly told me I'm not allowed to rely on 3rd party libraries very much (so not at all).

@bitcoinluvr6969 So is this homework?

@PieterWuille No, sorry for the confusion. I work in a research lab.

That's a truly bizarre request from your professor then.


text:
Bitcoin.org gpg keys expired?
I was trying to add the keys to a keyring to verify the bitcoin core download, but it looks like the gpg keys are all expired.

Which keys specifically? Do you have a link?

@Pieter see addendum to my answer for possible/probable link.

Oh, I hadn't even considered OP might have been using bitcoin.org.

The home website for Bitcoin Core says

Refresh expired keys using:
gpg --keyserver hkps://keys.openpgp.org --refresh-keys

I would obtain Bitcoin Core from that bitcoincore.org website and not from bitcoin.org.

For signature checking to be more meaningful as a check on authorship or correctness rather than merely a checksum of download integrity, it is probably important to obtain your GPG public keys from a source that is as independent as possible from the website from which you download the source or binaries. Otherwise you could download doctored code and faked signatures & keys from a hacked or impostor website.  This independence appears to be the case with software from bitcoincore.org and keys from openpgp.org or elsewhere (if I understand correctly).

You are correct that bitcoin.org currently (2022-02-17) has old expired keys.
After visiting https://bitcoin.org/en/download and clicking "Bitcoin Core Release Signing Keys" v0.11.0+ I also see an expired key.
C> gpg --import laanwj-releases.asc
gpg: key 36C2E964: public key "Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)
gpg: no ultimately trusted keys found

C> gpg --list-keys
----------------------------------------------
pub   4096R/36C2E964 2015-06-24 [expired: 2022-02-10]
uid                  Wladimir J. van der Laan (Bitcoin Core binary release signing key) <laanwj@gmail.com>


text:
Creating Coinbase acct for a friend
A friend of my recently asked me to create a Coinbase account for her. She noted she had an acct already, but has issues getting into it for "lack of activity". Anyway, I have received no explanation as to why she can't open a new acct for herself. I am very concerned about creating an acct for her in that my personal information is on this acct, yet she will be using it. Am I overly concerned about nothing? Is there anything that could come back and bite me with my link to her activity?
Terry

I suspect your friend is an online friend that you haven't met in real life, haven't taken photos of, haven't visited their home and haven't met and chatted with their parents and common friends in real life.
An account like that can be used to launder the proceeds of criminal activity. Since your personal information is attached to the account it is you who may have to sit in an interview room and persuade skeptical law enforcement officials that your friend is not a fiction you created and that you haven't profited from the proceeds of crime, potentially seriously nasty crime, that went through what appears to be your account.
Anyone who asks you to create a financial account for them isn't your friend or is so hopelessly unaware of basic security that they need to be talked out of it and shown a better way to achieve their objectives.

Apart from all that, you will be deliberately breaching Coinbase terms and conditions of use. By knowingly doing so you are culpable in assisting crime.
Section 1.2 of https://www.coinbase.com/legal/user_agreement/united_states says :

By registering or using a Coinbase Account you agree and represent that you have created your Coinbase Account and you will use your Coinbase Account only for yourself, and not on behalf of any third party

section 6.6 says

You are responsible for creating a strong password and maintaining security and control of any and all electronic devices, IDs, passwords, hints, personal identification numbers (PINs), API keys or any other codes that you use to access the Coinbase Services. Any loss or compromise of the foregoing information and/or your personal information may result in unauthorized access to your Coinbase Account(s) by third-parties and the loss or theft of any Digital Assets and/or funds held in your Coinbase Account(s) and any associated accounts, including your linked bank account(s) and credit card(s).

see also 8.1 about your indemnification of Coinbase if you breach any term (such as 1.2). Your actions are never going to be consequence free.


text:
Why is it necessary to solve the SHA-256 issue to get a bitcoin?
I understand that for a new bitcoin to be born it is necessary to solve a SHA-256 problem, that is, to make a machine effort for this (a real race). Whoever makes this effort first takes the bitcoin, the rest are left with nothing.
My big question is why this machine effort is necessary to solve the SHA-256 problem? what do the masterminds behind bitcoin do with the SHA-256 solution? I don't really understand this, I may be making a mistake about it.

Does this answer your question? What exactly is Mining?

Does this answer your question? How does proof of work inspire trust when the work is just guessing?

The reason there is a problem is to limit the amount of blocks mined. If there is no sha256 the rate bitcoin is mined will be so great that there will be blocks created per 1 transaction. This can cause inflation because there will be a huge surge of new bitcoins. Also the way blockchain works is that you need the hash of the previous block to build the next block.


text:
Limit in adding Watch address in bitcoin core
Is there any limit in adding number of watch address to bitcoin wallet? Am thinking of adding thousands of address to watch list. If i do so what are complications we may face, performance impact?


text:
Mining against candidate block hash or previous block hash?
When mining...;
a) Is the block header hash of the candidate block used
b) OR the block header hash of the previous block + noonce used?
If it is a), which I presume, is it then correct that the procedure is;

Write incremented noonce into the candidate block header
Calculate the hash, which thus changed bc of the updated noonce, of the candidate block header and check against the target.

I looked but did not find any other question that covers exactly this.

Does this answer your question? What exactly is Mining?  -- I've read answers there from which I believe a reader could see that your presumption is correct.

Much appreciated, RedGrittyBrick! I'll post a follow-up question I have over there instead.


text:
TX doesn't contain an equal number of transactions with bitcoin addresses
I'm researching bitcoin and noticed that when transactions come through my node I don't have an equal number of "amounts" (e.g everything between 88ac and 19) with addresses (e.g everything between 76a914 and 88ac). Why is this? I was expecting them to be equal, as in one amount being transacted per one receiving address.

Are you asking whether an address can be paid twice by the same transaction? If so, yes.

Could you please be more specific about what you are looking at, what you were expecting to see, and how what you’re seeing diverges from your expectations? It’s not clear to me what you are asking.

@Murch, yes I can. I am wanting to extract from pyshark transaction checksums. However, I don't know how to extract it from the data. Is the consecutive 4 bytes after the first 40?

I suspect one cause of your problem is that you are not taking into account the full complexity of Bitcoin and are taking too many shortcuts in parsing the data.

addresses (e.g everything between 76a914 and 88ac).

The locking script (PubKeyScript) for a P2PKH transaction output does indeed have the pattern OP_DUP (0x76), OP_HASH160 (0xa9), OP_PUSH20 (0x14), {public key hash}, OP_EQUALVERIFY (0x88), OP_CHECKSIG (0xac).
However

There are many other types of locking script.
It is not a good choice to treat 76a914 and 88ac as magic numbers that delimit specific data in all transactions.
Addresses don't exist for some types of transaction output.

"amounts" (e.g everything between 88ac and 19)

The byte 0x19 might occur in the amount and so can't be used as a delimiter. You should instead be extracting a fixed length 64-bit integer.
Also the sequence 0x88ac might occur elsewhere, such as in the middle of a hash. Treating these values as delimiters is, in my opinion, a fatally flawed approach.

The approach I take when parsing is to know what data type is expected next and read the appropriate number of bytes for that data type.
The only significant complication is the optional elements such as the SegWit Marker and Flag. I deal with that by checking if the number of inputs (a variable length CompactInt that you have to read in two parts) is zero and if so, treating it as a SegWit Marker instead, then reading the SegWit Flag and the real input-count.
When expecting a CompactInt I read one byte to determine the length then read the remaining number of bytes indicated and calculate the value appropriately.
This requires you to fully parse the data from the beginning - you cant dive into some random point in the middle of the data and start parsing from there. The data does not contain delimiters. Even when magic numbers are used - such as the one at the start of a block in the blockfiles, you cannot assume that the value won't occur in the middle of some hash data.
If you are parsing the scripts you need to implement something that has a basic understanding of opcodes so that you know how many bytes are data rather than opcode - that way you don't look for nonexistent markers.
See

In what format does a block store the transaction data?
What are the parts of a Bitcoin transaction in segwit format?
https://en.bitcoin.it/wiki/Protocol_documentation#tx
https://en.bitcoin.it/wiki/Script


text:
order of the details array in the output of the gettransaction wallet API call
According to https://developer.bitcoin.org/reference/rpc/gettransaction.html the details array contains a list of the outputs of that transaction. Each output has a vout. So in my tests, it seems that the order seem to be the same than the vouts so that the index of the array is equal with the vout.
But is that guaranteed?

While the transaction is stored in Bitcoin Core with the outputs in a vector where the vout index matches the position in the vector, and when we write the RPC response we just write in the order of that vector, I am not sure that there is any guarantee that this would always remain a complete list.
However, the details of the output in the return value do explicitly include the index on the vout field in the response, so you could just use that if you want to be extra sure.

Thanks, in the meantime i found examples where the list was not complete which makes sense as some outputs might not belong to the wallet.


text:
How to generate an output address from output scrips which start with 0x00?
A few days ago, I got a BITCOIN traffic which contains some tx message.
some of tx messages contain witness data.
I want to produce all output addresses from transaction output scripts.
I extracted some of them, but in some cases, generated output address however seems to be valid,  but I can't track them in some sites like
https://www.blockchain.com
as an example, in tx output script which is showed below, how I can extract True address?
00142f82e61a98eb7027672760c691784d5fbccf7ce3

it seems a script which has op_code = 0x00 and push data length = 0x14.

It's a native segwit output. 0x00 signifies the segwit version (which is v0 in this case), 0x14 is the bytes to push and 2f82e61a98eb7027672760c691784d5fbccf7ce3 is the hash160 of the public key. Native segwit addresses uses bech32 encoding as defined in BIP 173 and begin with bc1. Use this for reference implementations in various programming languages. The address associated with the locking script is thus bc1q97pwvx5cadczwee8vrrfz7zdt77v7l8re20cz4

Are you sure? but the address you entered is wrong and is not in
https://www.blockchain.com/
or
https://www.blockchain.com

@Saeed The address I have listed in the answer is correct. Most block explorers have still not implemented support for bech32 native segwit addresses. You can check the transaction containing the address here. Note the first output of the transaction. http://chainquery.com/bitcoin-api/getrawtransaction/0a9ac867a88cbfb60bdbf2a9063e4dffb374201490075e41057450ebbdf689e4/1

Thank you. it seems that the address you generated is valid, but I can't generate it with bech32 which you introduced before.
first I extract public key (2f82e61a98eb7027672760c691784d5fbccf7ce3 ) then encode it with sha256 and then encode it with RIPEMD160. at last, I give generated output to bech32 encoder and it generates a valid bitcoin address but it is not bc1q97pwvx5cadczwee8vrrfz7zdt77v7l8re20cz4 which you produced.

@Saeed 2f82e61a98eb7027672760c691784d5fbccf7ce3 is not the public key but the hash160 of the public key. So you do not have to calculate the hash again. Just bech32 encode 2f82e61a98eb7027672760c691784d5fbccf7ce3 using version 0.


text:
Could bitcoin's limited supply prevent it from becoming a worldwide currency
I've recently read about the Great Depression period of the USA and made a striking relevance with Bitcoin.
In short, the Great Depression was caused by a drastic decrease in the circulating money (more than 1/3). This in turn lead to prices going down and therefore an increase in the purchasing power of money. Nothing new so far. However, we often tend to undervalue the importance of the financial institutions, which play a big role in increasing the standard of living of a society as a whole. Why?
Well, they gather little amount of money from a big part of the community and then finance big enterprises, which, could have not succeeded if they had not started with a great initial investment.
Think about it for a moment:

Almost every person in developed countries is able to afford a car because of the initial investment that the financial institutions were able to give various companies for scientific researches and building factories which facilitate the economic of scale.
We are now able to fly to the other part of Earth in less than a day, thanks to the initial researches and work, financed by various institutions.

Now, that everyone understands the significance of the financial institutions, let's imagine a world without them being able to operate. It's evident that there would be a drastic decrease in the standard of living.
What can cause the financial institutions to stop working?

Put yourself in the situation of a person in debt
Now add deflation into the situation (as it had been during the Great Depression)

This means that your debt will cost you more than you initially agreed upon (that is because of the increase of the purchasing power of money). A lot of people defaulted on their debts during the Great Depression. A lot more were unlikely to take any debts. Moreover, people saved their money in cash rather than investing them, because believed that the ROI (return on investment) would be much less compared to the situation if they just kept their money.
Now, please tell me, don't you think that bitcoin would face the exactly same problems, because of its deflationary nature?
And don't you think that in order for bitcoin to fulfill its dream of becoming a currency, it should make a fork which will let in a fixed amount of coins per year even after the initial supply plans have been met?

Related questions:
https://bitcoin.stackexchange.com/questions/92789
https://bitcoin.stackexchange.com/questions/66

To answer your second question:
What purpose would extending the amount of Bitcoin by a fixed yearly supply serve? A Bitcoin consists of 100.000.000 Satoshis - even if large amounts of Bitcoin were lost (e.g., forgetting keys, burning, etc.) there should not be any payment problems for a long time to come. Extending the yearly supply would, as far as I see, merely add a slight inflationary drift to it (similar to gold which is being mined physically at a continuous rate). Question is, would that be desired? What economic purpose would it serve? Would it not undermine one of Bitcoin's core principles?
As to your first question:
Deflation occurs when the value of money increases in relation to goods present in an economy. In a world where the total supply of money is fixed (e.g., Bitcoin), the currency would be perceived as being deflationary if the amount of goods was increasing. Due to innovation and improvements in production, this would likely be the case in the future (e.g., technology is a leading deflationary pressure). In a way, you would be getting more for the same amount of money, effectively increasing your wealth. By itself, this would not be a bad thing.
The problem during the great depression was the debt burden. When debt is paid back, it effectively erases credit and thereby restricts the money supply - leading to deflationary effects because instead of the amount of goods increasing, it is the amount of money that is decreasing. Eventually, this lead to the US abandoning the gold standard and extending credit lines to the banking system, effectively pumping money into the system.
If the money being inserted into the system is used to pay back debts, the net effect on inflation/deflation tends to be negligible. The same is true if the supply of goods increases in rate with the supply of money. Problem is, as is nowadays the case, when the money created is being used to purchase assets (real estate, securities, etc.) and the supply of goods is constricted (problems with supply chains, etc.). Then inflation is felt on multiple frontiers (consumer prices, prices of securities, etc.). This decreases the wealth of the average person, and benefits those that owned securities before the money printing started.
To cut discussion short, I would recommend the following two books by Ray Dalio:

Principles For Navigating Big Debt Crises (explains financial crises and also deals with the great depression) available for free at link
Principles for Dealing with the Changing World Order: Why Nations Succeed and Fail (deals with long term debt cycles and the implications of money printing in FIAT currencies, among other)

The book "The Price of Tomorrow: Why Deflation is the Key to an Abundant Future" link can be seen as a simplified summary of the above two, should you be pressed for time.

Your question is probably better suited in an economic theory forum where this open ended question is discussed at length amongst scholars. You are making the Keynesian argument that the ability to adjust the money supply is inherently good for the economy. This is contradicted by other scholars, mainly from the Austrian School of Economics.
The very reason bitcoin was created was to have an immutable and predictable money supply in response to the dissatisfaction with an array of factors associated with traditional currencies with elastic, inflationary supply founded on Keynesian principles.
With any argument you give that inflation in such and such economic scenarios may be good, I am afraid you're preaching to the wrong choir, as it is implicit that bitcoin holders are adherents of the Austrian School that ultimately believe on the whole that fine tuning an elastic money supply is not a good thing and feel very strongly about not inflating the money supply. There is no indication that the bitcoin community would ever deviate from that consensus. Nevertheless, no one is stopping you or anyone from making a fork of bitcoin to test if there is a market interested in an inflationary bitcoin.
As I mentioned, whether adjusting the money supply is good or bad for the economy is an open ended academic question, with no consensus amongst scholars of economic theory. Bitcoin is the first real world experiment of a deflationary currency where this idea can be tested. Bitcoin does not stop other inflationary currencies from existing and time will tell which currency people choose in various hypothetical economic scenarios.

I wish more people asked macro questions like this!
First of all, bitcoin can never be deflationary to the real economy, only inflationary. To see why, we need to think in fundamental terms. Let's imagine there is an isolated island. The island has some people and some resources (coconuts and fish). The people trade to increase their wealth. A tall man trades some of his coconuts for fish from a woman who is an excellent swimmer.
One day someone invents bitcoin on this island. They have no computers so the difficulty of this on-island chain stays very low - but it is possible to mint a block with a few hours of work using pencil and pad, so everyone spends several hours a day calculating rather than fishing or picking coconuts.
Now everyone on the island is flush in bitcoin. Bitcoin is the only kind of money on the island and all the people are now bitcoin millionaires.
So are the people better off or worse off? At first you might say everyone is of course better off since now they are all bitcoin millionaires and can now trade their coconuts and fish so much more efficiently using a distributed and non-modifiable ledger. If they have a very good day fishing, they can sell their fish for bitcoin and store the value of those fish on the blockchain until they need some coconuts (or have a bad day fishing). But in the context of this tiny island economy, this obvious how silly this is.
In fact they are all now much worse off thanks to the invention of bitcoin because every hour that people spent calculating hashes was an hour they did not spend picking coconuts or fishing. (OK, maybe not ALL, since there was a guy who happened to be wearing a CA53W when they were stranded. He secretly was able to mine a lot more blocks than anyone else, and he wisely converted all of his rewards into fish and coconuts the moment they were spendable. He got very good smoking fish and making coconut jerky.)
There are now much fewer fish and coconuts available, and so there is massive inflation if you use the metric [how many fish and coconuts you can have for each day of your labor]. The introduction of bitcoin was massively inflationary! You now have to work more hours per day to have the same number of fish and coconuts you had before bitcoin, even if you are not mining bitcoin yourself. See why?
Even if a storm hits the island and blows away every single notepad that has private keys written on it, you can never deflate even just back to where you were before bitcoin was invented. The invention of bitcoin will always be net inflationary.
Note that if you now view the island as the whole Earth and give everyone ASICs and add in lots of other currencies and goods and services... things get much more complex, but the fundamental outcome does not change. The introduction of bitcoin will always and everywhere be net inflationary.


text:
Detect types of ScriptSig and parse each part
As explained in
https://en.bitcoin.it/wiki/Script
there are many types of scriptPubKey and scriptSig like:
<sig> <pubKey>
<sig> <pubKey> <pubKey>
<sig> <pubKey> <pubHashA>
<sig> <pubKey> <pubHashA> <pubKeyHash>
...

how can we detect type of ScriptSig and separate each part?
In other words is there a length variable or something like that to parse each part separately?

Really, the only way to detect the type is to parse it as a program.
All scripts Bitcoin are written in the Bitcoin Script language. Much like any other programming language, certain symbols have special meaning, and correspond to specific op codes, which appear in the raw hex form. You can find a list of op codes on the Bitcoin Wiki: https://en.bitcoin.it/wiki/Script#Opcodes
The standardized scripts, which are usually what we see presented as addresses, are really just specific snippets of Bitcoin Script programs. For example, a P2PKH "address" is really just half a program in the form of:
OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG

When combined with the remaining half of the program, which is provided as the ScriptSig when spending the coins, you get a complete program which can be evaluated.
To determine the script type, you really just need to parse the program (or partial program, in the event of an output) and see if it matches a known, standardized type.

I mean how I can parse a scriptsig which is like this :
scriptSig: <sig> <pubKey>
in other words, i want to find it's public key to generate related address.

A script sig is just a bitcoin script fragment - even simpler, they are restricted to only use OP_PUSH, so to read the signature and public key, you read the first byte for the push length, then read that many bytes as data, then read the next byte, and read that many bytes as data again - The first chunk of data is a DER encoded signature, and the second chunk is the public key

Naturally, the above only works for P2PKH/P2PK addresses -  P2SH and segwit addresses will require more effort

Thank you a lot.
I have another question. you explained how I can parse DER encoded signature and public key. in the tx output address i can generate output address after detection of type of address(P2PKH or P2PK  or  P2SH  or ...)
because it is detectable from it's op code. but what about input script?
Now with your guidance i can extract public key from input tx. how can i understand structure of producing address from this public key?

As an exapmle, i have some tx messages which it's signature script length is zero and did'nt have any script.
in other example i have a complete script with 23 byte length, as you saied before, I assumed first byte of it for push length, but first byte is equal to 22, so it means that it is not any public key. what is the reason?

is it some exceptions about your rule for parsing public key?

@Saeed You can only ever determine the address from the output being spent. You cannot do this from the scriptSig alone.

@PieterWuille So if I can't determine address from scripsig, then how miners or everyone can evaluate reliability of that transaction? and ensure that sender have enough credit to create this transaction?

Because they also look at the output being spent. That's how validation works. That's what you need to do to get any insight in what's going on. Also, addresses are not relevant for balance validation: the question is simply whether or not the output being spent was previously spent or not already, and if not, what value it had. Addresses are a human-level abstraction into the authentication mechanism, but don't exist at all at the protocol level. In particular, there is no such thing as an address balance. Just UTXOs.

As I advised you elsewhere, stop looking at protocol dumps and trying to match that information up with block explorers. If you want to understand what's going on, read how transactions and other things in the protocol work.


text:
P2SH secure spending. How?
Maybe my question is stupid, but
imagine that I'm trying to spend inputs from p2sh.
For example, p2sh scriptPubKey looks like:
OP_SHA256 4bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459a OP_EQUAL

I know, that the SHA256(0x01) = 4bf5122f...85459a (hacker do not know that, until I broadcast tx)
So I broadcast transaction with the folowing scriptsig:
OP_1 (0x51)

Why hacker can't take this unconfirmed transaction, extract scriptsig, and replace outputs to his own outputs ?
Also, what to do, if RBF (replace-by-fee) flag is set?
Of course, I'm not talking about transactions with OP_CHECKSIG

Just to be technically correct, a P2SH scriptPubKeyis actuallyOP_HASH160  OP_EQUAL`, see https://en.bitcoin.it/wiki/Transaction#Pay-to-Script-Hash

Yes, thank you. Is there any diff with HASH160, or problem the same ?

It's not really relevant to the question, just for correctness.

You're correct that anybody could just replace the outputs and take the funds for themselves.  This script has no authorization needed on the spender's part, so once the redeemscript is known, it's practically become an anyone-can-spend script.
Assigning an RBF enabled sequence (or not) on the transaction makes no difference (perhaps only for relay policy), since any sequence set can also be replaced by anybody.

Of course, I'm not talking about transactions with OP_CHECKSIG

I think this is the core of your misunderstanding. P2SH is not intended to be secure if you use an insecure script. It is simply a way to conveniently and cheaply producing an output with a policy and security that is equivalent to a script.
In practice, no script without a type of CHECKSIG operation will be secure, for the reasons you give yourself.


text:
Error while send transaction: Data push larger than necessary
Looks like transaction decodes fine. But when I use sendrawtransaction I got
Data push larger than necessary
What's wrong with this tx?
bitcoin-cli -testnet decoderawtransaction 020000000149d4a5f520ded6fa94f79cd268f0334baeec9a7732c9d946d1cdee58d81e7aad00000000020101ffffffff01904c96000000000017a914f45d94733d430261962932e0c847075195916a048700000000
{
  "txid": "1bbf569b281f2cd9d948e4273120a9bc3bb2c21e31bc9786682c0a22d8feb76c",
  "hash": "1bbf569b281f2cd9d948e4273120a9bc3bb2c21e31bc9786682c0a22d8feb76c",
  "version": 2,
  "size": 85,
  "vsize": 85,
  "weight": 340,
  "locktime": 0,
  "vin": [
    {
      "txid": "ad7a1ed858eecdd146d9c932779aecae4b33f068d29cf794fad6de20f5a5d449",
      "vout": 0,
      "scriptSig": {
        "asm": "1",
        "hex": "0101"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.09850000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 f45d94733d430261962932e0c847075195916a04 OP_EQUAL",
        "hex": "a914f45d94733d430261962932e0c847075195916a0487",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2NFXJy8mvz7ZiT4VVN29xPGC38hTygd3AyJ"
        ]
      }
    }
  ]
}

Your scriptSig uses a data push to push 0x01 onto the stack. It could use OP_1 instead.

Thank you! But now I got "Script evaluated without error but finished with a false/empty top stack element)" Is this something wrong with my redeem script or scriptpubkey ?

Your transaction is failing validation with SCRIPT_VERIFY_MINIMALDATA, which is described in BIP 62 rule 3 protections against malleability.  CheckMinimalPush() requires a push of 0x01 to be done using OP_1.
This standardness rule avoids the case where someone takes a transaction from the network and a push with a longer encoding of the same push and as a result creates a malleated form of the transaction.


text:
Is it possible to run a full node lightning network bitcoin core 22.0 on a 32 bit computer?
I have an old pc with Atom N270 that I would like to use as full node, how can I do that?

Bitcoin core yes, if you can figure out how to compile. but do note you'll need to run lightning in a 64 bit machine since channel.db will exceed 2gb causing lightning to crash.  https://github.com/pangyuteng/bitcoin-lndhub

Bitcoin Core 22.0 only supports 64-bit x86 platforms. The Atom N270 is a 32-bit CPU, so it is not supported.
It may be possible to compile the 22.0 source code yourself for a 32-bit platform however, and the result may still work. But you're on your own then.

I have an old pc with Atom N270 that I would like to use as full node, how can I do that?

As you can see from the list of pre-compiled 22.0 binaries, there is no Intel 32-bit option available. There is a 32-bit ARM version available, but your Atom N270 is an Intel processor not an ARM processor.
Therefore, you will have to download the source code and try to compile it yourself to get the node running on the Atom N270 computer.
There are installation from source instruction specific to Linux/Ubuntu here, which might be easiest to follow, assuming you are able to install a 32-bit Ubuntu operating system on your computer.


text:
What if there where no nodes to share a new block
I am fairly new to blockchain technology, so bear with me if i make mistakes
So lets say there are 10 people trading a cryptocurrency 5 of them are online from 8 to 10 am and the other half on online from 1 to 5 pm, if a person from the first group wants to make a transaction and adds that trasaction to the blockchain, it then gets send around among the 4 other people in the first ground that all add that block to their own blockchain, but then everyone of them goes offline and when the second group gets online there are no people from the first group to share that new block, so eventually the two blockchains would look completely different?

Yes networks that are cut off from one another, cannot intercommunicate and therefore cannot transact with one another.

so blockchains break down for smaller networks?

Strictly speaking, networks that are too small to sustain communications among their members become unusable for any networked application.

The problem is also trivially solved by one or more nodes remaining online around the clock.


text:
Why do several exchanges not comply with KYC regulations
I am doing a research project about Crypto regulation. From what I read, Know Your Customer and Anti-Money Laundering compliance from exchanges are legally required in the US. However, a quick search shows several crypto exchanges that obviously do not comply with these regulations (they don't ask users any identification when purchasing).
How are these exchanges slipping through? Some have been around for multiple years and a glance tells me they are doing fine.

My thoughts would be that there are much bigger fish to focus their AML efforts on. Out of curiosity, which exchanges are you referring to? Only fiat<->btc one I've heard of is bisq

It depends where the selling company is based. If you're able to buy BTC for example in Switzerland (from the US), you can get BTC by just giving them your bank id (also known as KYC-light).
You need to keep in mind that there are also decentralized exchanges like BISQ and also marketplaces for buying and selling BTC in person for cash.
Bitcoin is a digital peer-to-peer cash. It is nearly impossible for any entity to control and regulate it.
By the way, which exchanges did you find that do not comply with KYC or AML?

Well, one of them was Shapeshift. from your answer, I am guessing that because shapeshift is based in Switzerland, they avoid US regulations and therefore do not need to perform KYC processes?

Exactly! Shapeshift (though it's a shitcoin casino) uses the swiss laws. This means that you can buy cryptocurrencies by giving them the debit card number from which you are sending them money from (KYC-light). This is possible because a  full KYC process in Switzerland is only needed from a volume of 900$ a day but this rule will be changed at the end of the year. From 2022 the allowed KYC-light volume is only 1000$ a month!
By the way, this process may not reveal as much data as a KYC-backed purchase but having your debit card id makes it possible to track back transactions!

The answer is pretty simple, in general:

Some portion of the market finds value in using KYC-free exchanges.

Most, but perhaps not all jurisdictions require businesses to impose KYC rules.

Savvy internet users will generally find ways around jurisdictional restrictions that they don't want to comply with.

This makes sense, but could you give an example of some exchange doing this in the real world?


text:
Can a node be maliciously programmed to validate all the transactions coming from a specific entity?
In a blockchain there are miner nodes and validator nodes. The job of a validator node is to validate transactions to be included in the mempool, broadcast or propagate the transaction for the other nodes and then to validate the candidate blocks created by the miner nodes. So can a validator node be maliciously programmed and deployed on the network by an attacker to accept/validate tampered transactions(favoring the attacker such as by double spending) generated by the attacker? If yes then what happens if the attacker owns more than 50% of the nodes? (not >50% of the total hash power but >50% of the total validator nodes)

The number of nodes that perform validation is completely irrelevant, because there is no vote.
Validating nodes validate everything independently; they all have their own mempool with transactions they believe are valid. Who cares that an attacker spins up a gazillion nodes? It won't make your node (which you're presumably using to validate your payments, if any) accept these invalid things.

If there is no vote then why is a transaction further propagated to other nodes after being validated by that node? Also does the fact that "Validating nodes validate everything independently" means that a transaction will stand invalid even if one of the nodes find it to be invalid?

Nodes are free to relay a transaction or not, and they can certainly wreak havoc in the network if suddenly a huge portion of the network stops relaying. But they cannot ever make an honest node think an invalid transaction is valid. Which transactions your node considers valid or invalid is not determined at all by what its peers or other network nodes think about it.

ok I am a little confused now. Can you please explain me how a transaction is labelled valid or invalid in the bitcoin blockchain to be included in the mempool of the valid transactions?

There are hundreds of rules, and I can't go into detail for all of them, but the big picture is: doesn't steal someone's money without their signature, doesn't conjure up money out of nothing, doesn't spend the same coins twice. Every honest node validates all these rules for every transaction independently (it does not trust what other nodes think about it), for every transaction it sees separately (as a mempool tx) or in a block (in which case, if the transaction is invalid, the entire block it is in is considered invalid too).

so are you saying that every node has it's own mempool and includes a tx in it according to it's personal understanding of the tx as a valid or invalid one?

Yes, every node has its own mempool. There are often small inconsistencies between nodes. Every node also has its own idea of which blocks are valid and accepted (e.g. they may not have heard about a new block that was recently mined), but due to the incentives around PoW, all nodes necessarily converge towards the same blockchain after some time. That convergence does not exist for the mempool.

okay makes sense, but then how do the miner nodes decide from which validator node's mempool to pick up the transactions and block them together?

They draw transactions to mine from their own mempool. That's the only one they know is honest.

but I have read that not all miner nodes need to be validator nodes too. What about them?

That's hard to answer without context. Perhaps that statement is using the word "miner" to refer to hashing hardware, which generally outsources the block construction to a mining pool operator entirely (so hashers don't have a mempool, but they also don't select transactions for blocks at all). Perhaps the statement is referring to the theoretical possibility of having a miner that only produces empty blocks (which works without a mempool). But in practice: all miners (in the sense of nodes that produce block candidates for mining) have their own mempool.

so a mining pool operator, being a true "miner node" will have it's own mempool to select the txns from right? Here is the article I read it from: https://medium.com/sazmining/what-is-a-bitcoin-node-b1106b050ace

Yes, mining pools construct block templates, and do so based on the contents of their own validating node's mempool.

Let us continue this discussion in chat.

I suppose as soon as such a malicious node get's introduced which doesn't work according to the protocol, it would soon get banned.


text:
Script evaluated without error but finished with a false/empty top stack element
I'm trying to spend coins from this tx

https://tchain.btc.com/ad7a1ed858eecdd146d9c932779aecae4b33f068d29cf794fad6de20f5a5d449

The scriptpubkey is simple:
1 OP_CHECKSEQUENCEVERIFY OP_DROP OP_SHA256 6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b OP_EQUAL

SHA256 (1) = 6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b
So, I just need to push 1 to the stack using OP_1
Here is my transaction:
bitcoin-cli -testnet decoderawtransaction 020000000149d4a5f520ded6fa94f79cd268f0334baeec9a7732c9d946d1cdee58d81e7aad0000000001510100000001904c96000000000017a914f45d94733d430261962932e0c847075195916a048700000000
{
  "txid": "51060bbaf1b29b2ec3b1bb4eef0d56f61121e4df167768f52e6f67f81321eaf5",
  "hash": "51060bbaf1b29b2ec3b1bb4eef0d56f61121e4df167768f52e6f67f81321eaf5",
  "version": 2,
  "size": 84,
  "vsize": 84,
  "weight": 336,
  "locktime": 0,
  "vin": [
    {
      "txid": "ad7a1ed858eecdd146d9c932779aecae4b33f068d29cf794fad6de20f5a5d449",
      "vout": 0,
      "scriptSig": {
        "asm": "1",
        "hex": "51"
      },
      "sequence": 1
    }
  ],
  "vout": [
    {
      "value": 0.09850000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_HASH160 f45d94733d430261962932e0c847075195916a04 OP_EQUAL",
        "hex": "a914f45d94733d430261962932e0c847075195916a0487",
        "reqSigs": 1,
        "type": "scripthash",
        "addresses": [
          "2NFXJy8mvz7ZiT4VVN29xPGC38hTygd3AyJ"
        ]
      }
    }
  ]
}

When I use sendrawtransaction I got
mandatory-script-verify-flag-failed (Script evaluated without error but finished with a false/empty top stack element) (code 16)

Is my redeem script wrong? Or it's something wrong with the scriptpubkey ?

The SHA256 of 1 is 4bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459a
$ printf "01" | xxd -r -p | openssl sha256
(stdin)= 4bf5122f344554c53bde2ebb8cd2b7e3d1600ad631c385a5d7cce23c7785459a
$ printf "31" | xxd -r -p | openssl sha256
(stdin)= 6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b

You were probably trying to do the SHA256 of the ascii character "1" which has a byte value of 0x31 or 41 in decimal.

oh.. I think this is 99% of all my problems. Thank you


text:
Create simple and secure transaction without checksig?
According to my previously asked question (P2SH secure spending. How?) creating transactions without signature checking is probably not secure.
Anyway, I see many transactions
(for ex.:40eee3ae1760e3a8532263678cdf64569e6ad06abc133af64f735e52562bccc8)
with scriptpubkey like:
OP_HASH160 [pubkey] OP_EQUAL
With very similar to
OP_SHA256 [hash] OP_EQUAL (from my prev. question)

And scriptsig doesnt have OP_CHECKSIG
PUSHDATA(72)[3045022100ad0851c69dd756b45190b5a8e97cb4ac3c2b0fa2f2aae23aed6ca97ab33bf88302200b248593abc1259512793e7dea61036c601775ebb23640a0120b0dba2c34b79001]

PUSHDATA(69)[5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae]

I can't beleeve this transaction are insecure. But what the difference with this ones?

This transaction actually does have a signature check. Instead of OP_CHECKSIG, it's OP_CHECMULTISIG as the script is a multisignature script. The script in this case is the redeemScript which is provided in the input itself. To see this OP_CHECKMULSITIG, you need to decode the redeemScript.
The redeemScript is:
5141042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf51ae

Decoded, this redeemScript is:
1 042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf 1 OP_CHECKMULTISIG

As you can see, this has an OP_CHECKMULTISIG in it which does do a signature check. OP_CHECKMULTISIG checks that n of the public keys listed provide a signature. n is the number that is at the beginning of the script. In this case, n is 1, and the public key is 042f90074d7a5bf30c72cf3a8dfd1381bdbd30407010e878f3a11269d5f74a58788505cdca22ea6eab7cfb40dc0e07aba200424ab0d79122a653ad0c7ec9896bdf. So this script is looking for a signature that corresponds to that public key.

I'm still don't get it. Ok, in input we can set op_checkmultisigsig and be sure that transaction can't be replaced. It's no requered for spending, right? What if some funds left with the same scriptpubkey (HASH160 [pubkey] EQUAL)? To spend inputs, we just need to provide data, which HASH160 will equal to e9c3dd0c07...e9c3dd0c07. So, we know that data from spending transaction (its 3045022100ad0...a2c34b79001) Where is my mistake?

The output script is a special type known as P2SH. You have to provide something in the input which hashes to that hash. But, that something itself is also a script and is interpreted too. So you must also meet the conditions of that script too. Since that script includes an OP_CHECKMULTISIG, you will need to provide signatures, and without the private keys, you can't do that.


text:
Bitcoin 0.17 No public key shown (validateaddress)
I want to generate multisignature address with person, which I didn't know.
Someone send me a public key. Then I do:
bitcoin-cli getnewaddress "" legacy

Ok, I got
1QKVwuQnu69HgsMVvynFhApYmmdLf8bMKT

After that, I need to know my own public key:
bitcoin-cli validateaddress "1QKVwuQnu69HgsMVvynFhApYmmdLf8bMKT"

But v.017 do not give me a public key:
{
"isvalid": true,
"address": "1QKVwuQnu69HgsMVvynFhApYmmdLf8bMKT",
  "scriptPubKey": "76a914ffca8b339408c5eb664513f62c98256c5edcc98b88ac",
  "isscript": false,
  "iswitness": false
}

Is there any way to generate multisignature address (2 of 2) if wallet do not know one of this addressess ?

validateaddress has changed to be separate from the wallet, so it cannot look up the public key information for an address. Use getaddressinfo instead in order to get all of the wallet information for an address, including the public key.


text:
Pending Chain Balance -Lightning Wallet:
I appear to have a stuck pending chain balance on my Lightning Node's Lightning Wallet.
It has remained a pending chain balance for a very long time can someone please let me know how I can get this pending chain balance to finalize and let me use the over 16 million sats that my Thunderhub App says I have in the walet.
Thank you for any help you can offer.
Orange_Bitcoin

Please define "very long time" a week is for example not long in this context and not uncommon

Hi Rene, I Believe it is approximately 4 weeks. Is there a way to check on its progress to locate the reason why it has yet to complete this process? Thank you.

Can you post the funding transaction or the short channel id?

I  will research what you have asked for and let you know soon. Thank you.

Sorry for my noobishness but here is a transaction from mempool for what I believe is the last channel we closed. https://mempool.space/tx/5ccb8159021030fd94d6b1ef1430cf7f1f3fd8a21884db05c781878d49431cdb

Sorry for my noobishness but here is a transaction from mempool for what I believe is the last channel we closed with bcashistrash. https://mempool.space/tx/5ccb8159021030fd94d6b1ef1430cf7f1f3fd8a21884db05c781878d49431cdb:1  closing transaction for bcash channel: https://mempool.space/tx/bbbebaf73af823fe1aec298ec6dbc4ccee98fedb77e33192c152ab2cf1b24e2d

2nd part of the comment just above this one.   the 2nd newest channel we closed for the peer bfx-lnd0.  opening transaction: https://mempool.space/tx/8f2063f11886abf4aaeb091e3e95bb5aa53358f5f904376bdf75d5395a86b5f1:0  closing transaction: https://mempool.space/tx/ec5f625b2e357e8ebbfff57e0dbc5f04a3a4e32cdcb97356cb9ef16db7d76305   I hope I gave you the correct information you requested. Thank you so much!

Hi Rene, I am sorry to tell you this but the pending chain balance has finally resolved itself and is back in the wallet, hope we did not cause you any extra work than was necessary. Was the reason for it taking so long to finalize due to miners fees being higher than the closing fee we set it to at the time of the closing of our channels? We appreciate all of your help in our quest to be better node runners! Thank you :-)


text:
How to avoid a force closure of a channel in the future
On May 14th our channel with LNBIG-42 was force closed and has only returned to the wallet minus some fees a few days ago.
https://mempool.space/tx/c75f38d1a86b0878d2b38198c17683cd4b6a10e2eea2d031ec085e25d1862149#vout=1
From what others are telling me it was most likely due to an expired HTLC which likely caused the automatic force closure as per the default settings in the relevant lightning implementation.
HTLC relay failure leading to node downtime seems to be the cause, but it is hard to say what specifically about your node setup and channels may have been vulnerable to this situation.
Also mentioned, it is possible the remote channel was misbehaving in some way. This is why until you can be certain that you are avoiding all related vulnerabilities you should not open channels with lots of unknown people especially not with questionable reputation.
Can you please tell me if I can raise the default HTLC settings on my node to hopefully avoid this happening again? Maybe using RTL or Thunderhub?
Since it was not our side of the channel that initiated the force close why did we get charged fees?
Thank you for any assistance you are able to offer.
Orange

HTLC relay failure leading to node downtime seems to be the cause, but it is hard to say what specifically about your node setup and channels may have been vulnerable to this situation.

Maybe yes or maybe no.
Force closes unfortunately happens for a lot of reasons. One of these is a bug in the software or an interop problem between two implementations.
Another reason is a fee spike, I know that ldk closes the channel if the fee is not matched, core lightning disables just the channel.
Now the question is: Is the force close always necessary? Imho no, I do think that we are not mature enough at the protocol level to catch the case that we can recover and try to fix it without going on chain.
But we are currently working on warning messages, where they need some more semantics around, but there is a way to do it

Hi Vincenzopalazzo, Thank you for your reply it is most appreciated. Sorry for the late reply been ill lately but better now. LND will mature with time so patience is a must I see. :)


text:
Bitcoin transaction confirmed over 500 times yet the funds are not showing up
Here is the transaction id# 80aa5b554a1d5df2fda472832d76a2251dd0bc84d73e98343dedfffc92d7141e

I sent the Bitcoin to my other wallet I used the correct address and correct wallet type

As mam5 wrote, the money was received and then spent the same day.
At Apr 23, 2023, 12:18 AM UTC, Address 3H9eTMPu4i4ryghDvn83Z8FZBR3bAjFnGT received 0.01815985 BTC from your transaction 80aa5b554a1d5df2fda472832d76a2251dd0bc84d73e98343dedfffc92d7141e
Then, almost two hours later :
At  Apr 23, 2023, 2:16 AM UTC, Address 3H9eTMPu4i4ryghDvn83Z8FZBR3bAjFnGT sent 0.01815985 BTC using a new transaction fea781fc52ec6d5a9f615efef90042cfb5f7c3edaa9d0aecab0933917d82a89d
If address 3H9eTMPu4i4ryghDvn83Z8FZBR3bAjFnGT is yours and you didn't create the second transaction, either your wallet is fake or someone else has copies of the keys it contains.
Remember, Bitcoin wallets don't contain money, they contain keys.

https://blockchair.com/bitcoin/transaction/80aa5b554a1d5df2fda472832d76a2251dd0bc84d73e98343dedfffc92d7141e
https://blockchair.com/bitcoin/address/3H9eTMPu4i4ryghDvn83Z8FZBR3bAjFnGT

So I have been scammed somehow? I don't understand what happened did I do something wrong

@Russell: see amended answer

As per mempool, it was already spent


text:
Getting bitcoin from old 0.3.0 wallet
I found an old bitcoin wallet from a Windows v0.3.0 client, backup from 2010
The wallet.dat is there and everything else in \AppData\Roaming\Bitcoin
I ran the client overnight in 2010 for 1 or 2 nights out of curiosity for this new thing, decided it was pointless on my feeble PC, then have never bothered with Bitcoin since. There might be something in the wallet, or nothing.
I understand that much has changed since then, but is there a way to move the old wallet into a modern wallet? I don't have a current wallet.
Thanks for reading!

@Mercedes maybe but as mine is from such an old client (pre bitcoin-qt) I wasn't sure.

The first thing to do is backup your original wallet.dat file.(Save a copy of it to secured computer or thumbdrive).This contains the private keys for your bitcoins. If you lose it, you lose your coins.
Next, try reading this question. It might solve your problem.
bitcoin.stackexchange.com/questions/10974/import-wallet-dat-into-a-new-bitcoin-qt-client

Thanks for the quick reply @Romo. So bitcoin-qt is now bitcoin-core
Should (indeed can) I do this on a non-connected PC, in case there is anything of worth in the wallet? It sounds the like the rescan step might need to connect to the internet?

To find out if the old wallet had control of any money you only need to get a list of addresses out of it. You should be able to do this offline. You can then check the current balance for each address by typing them into any blockchain explorer website.

To check your address, read the answer[PsySc0rpi0n], from this question
[link]https://bitcoin.stackexchange.com/questions/113042/how-can-i-see-my-public-wallet-address-in-bitcoin-core

I used pywallet.py to get addresses and looked them up on blockchair.  One had a small amount which someone must have sent me when playing around with it in 2010.  The others showed Zero and no transactions.  However, I found and ran the original 0.3.0 client on a disconnected machine, which showed the small amount sent to me and also mined amounts.

@Murgatroyd Hey, Is 'ChapInRed' your other name? If so, congrats on the good news.

Thanks all, current version of Bitcoin Core opened the wallet.dat fine, done after downloading blockhain and going offline.


text:
How can I get the txids of memblock that will be confirmed in the next blcok using bitcoin-cli?
I want to get the txids of the (mem-pool 0 I mean the mempool block that will next to be confirmed) using bitcoin-cli.
Basicly I want to get the txids in https://mempool.space/tr/mempool-block/0 this memblock. I am looking for this for days If you help that will be much appreciated.

Wouldn't that be https://developer.bitcoin.org/reference/rpc/getblocktemplate.html ? Though the mempools of nodes are not synchronised.

Please clarify your specific problem or provide additional details to highlight exactly what you need. As it's currently written, it's hard to tell exactly what you're asking.

The mempool in Bitcoin represents a collection of unconfirmed transactions, and it doesn't have a concept of "blocks" like the blockchain does. Each transaction in the mempool exists independently and is not grouped into blocks.
To retrieve the transaction IDs (txids) from a specific block in the Bitcoin blockchain, you can use the getblock command in bitcoin-cli. However, the mempool itself doesn't have blocks, so you won't be able to retrieve the transaction IDs in the same way as you would for confirmed blocks.
If you're specifically interested in the transactions displayed in the Mempool Block section on mempool.space, those are not actual blocks but rather a visual representation of the mempool transactions arranged in a block-like structure.
To retrieve the transaction IDs in that specific arrangement, you would need to use the API provided by mempool.space itself or explore their public API documentation for more details on how to fetch the mempool block data programmatically.
Here's the mempool.space API documentation that you can refer to: https://mempool.space/docs/api


text:
How can we check if a transaction is an ordinal transaction in the mempool?
I want to get the mempool data and find out which tranactions are ordinal inscription transaction. So if I want to find the mempool that will be confirmed and find how many ordinal inscription transactions are there what shell I check. Is there a way to do this using bitcoin-cli?
Initially I thought first getting the bestblock by
    # Get the blockhash of the best block, but not right for now
    cmd = ['bitcoin-cli', 'getbestblockhash'] # Shall get the last nconfirmed block
    result = subprocess.run(cmd, capture_output=True, text=True)
    best_block_hash = result.stdout.strip()
    # Get transaction IDs from of the block
    cmd = ['bitcoin-cli', 'getblock', best_block_hash]
    result = subprocess.run(cmd, capture_output=True, text=True)
    mempool_txids = json.loads(result.stdout)

Assuming I have the txids of the last memblock how can I understand if the transaction is a ordinal inscription transaction?

Since Bitcoin core is unaware of Ordinals, I guess you'd have ask it for the raw tx data and parse the witness data looking for the "ord" fingerprint, following Casey Rodarmor's specification. You might also want to check the Inscription  MIME type etc to distinguish BRC-20 from other inscription types.

Look for ASCII "ord" (hex 6f7264) at the appropriate offset in the second† witness component. It is described in the documentation
See How to differentiate between BTC transactions and BRC20 transactions on a blockchain?
†strictly penultimate IIRC.

"txinwitness": ["4491854e7bd95a6cb10955829e37b899bdb3682950922d4cfe7aa14f38e0e7976a6786ee6bf4cb4a07dc7672e4955180f9425081d11f2fd03387de7ea344ecce",        "20117f692257b2331233b5705ce9c682be8719ff1b2b64cbca290bd6faeb54423eac0628a3d1958801750063036f7264010118746578742f706c61696e3b636861727365743d7574662d3800397b2270223a226272632d3230222c226f70223a227472616e73666572222c227469636b223a224d585243222c22616d74223a2233353030227d68",
"c0117f692257b2331233b5705ce9c682be8719ff1b2b64cbca290bd6faeb54423e"
],
this is the witness data how do I look for "ord" finger print

Look for ASCII "ord" (hex 6f7264) at the appropriate offset in the second witness component. It is described in the documentation


text:
How to get mempool tx ordered by sat/vbyte
I want to get the mempool data ordered by sat/vbyte to understand which transaction will be confirmed.
In order to get the mempool txs I use: "bitcoin-cli getrawmempool" in command prompt. The query returns a string array of txs. But this string array is not ordered by sat/vbyte. How can I order this Txs to understand which transaction will be confirmed in what order?

I want to get the mempool data ordered by sat/vbyte to understand which transaction will be confirmed.

These two questions are not identical.
While of course mining prefers higher fees over lower fees, there are some reasons why the mining order is not exactly high to low fee:

Dependencies: when a transaction A in the mempool spends an output of transaction B which is also in the mempool, then B must go into the block before A can. In practice, Bitcoin Core does take such dependencies into account to some extent: if A has a higher feerate than B, then the combination of A and B are treated as a single package, so that B "pays for" A, possibly bumping up A's mining priority.
Tail effects: near the "end" of a block, it's possible that the highest feerate transaction is too large to fit in the block. In that case the problem of block template building becomes a bin-packing problem, and may include whatever fits.

To answer your question:

If you want the mempool transactions sorted by fee/vbyte, use getrawmempool, and sort the result yourself by feerate. You could do this using jq for example:
bitcoin-cli getrawmempool true | jq '[to_entries[] | .value] | sort_by(.fees.modified / .vsize)'

If you want the (order in which) transactions will end up in a block, use getblocktemplate (which is the RPC that mining pools use to get information of block transactions from Bitcoin Core):
bitcoin-cli getblocktemplate '{"rules":["segwit"]}

bitcoin-cli getrawmempool true | jq '[to_entries[] | .value] | sort_by(.fees.modified / .vsize)'
this method works but I also need to find the transaction hex but that data is not embeded in this query response  how can I also get the hex of each transaction

Try using bitcoin-cli getrawmempool true | jq -r '[to_entries[] | .value + {"txid":.key}] | sort_by(.fees.modified / .vsize) | .[] | .txid'.

Due to child pay for parent effective fee rates could be smaller but due to higher sat/vbyte these txs are ordered and therefore a transaction which wont be confirmed is being listed in the tx array how can I prevent this

@GencehanARPAÇAY As I said, if you want the mining order, and not actual feerate comparisons, use getblocktemplate, not getrawmempool.


text:
To get the install script for Download Fabric samples, Docker images, and binaries
I am trying to run the command mentioned here
curl -sSLO https://raw.githubusercontent.com/hyperledger/fabric/main/scripts/install-fabric.sh && chmod +x install-fabric.sh
It is giving me below error:-

I have windows.

You might try upgrading your PowerShell to a version that supports this token so find the current version you are using by giving the command “$PSVersionTable” in Windows PowerShell, and hit the Enter key. Another way to avoid the token error is to run each of those installs separately by not having to rely on the install token, && entirely.


text:
Recovered bitcoin public keys do not verify the signature
I need to recover public keys on the bitcoin chain for a project, my current flow is like this:
Get hash + signature from bigquery -> Use nodeJS secp256k1 module (native bindings) to import signature from DER signature -> recover public key from signature and hash-> verify public key against signature and hash.
The problem is, only about half of the public keys verify. Initially I thought it's either y-coordinate issues or issues with the recid number, but as far as I can tell, neither is the case.
Oddities that I have found:
No matter whether I put 0 or 1 as recid, either both (different) recovered public keys verify, or neither do.
DER Signatures with a 144 hex length (72 bytes) never have their recovered public keys verify, while shorter signatures become increasingly more likely to correctly verify.
My code:
    var uintsig = Uint8Array.from(Buffer.from(textasm, 'hex'));
    var uinthash = Uint8Array.from(Buffer.from(texthash, 'hex'));
    var sig = secp256k1.signatureImport(uintsig)

    var pubk = secp256k1.ecdsaRecover(sig, 1, uinthash)
    var ver = secp256k1.ecdsaVerify(sig, uinthash, pubk)

Sample data, one fails one goes correctly:
Does not verify:
{
  sig: '3045022074e221c10f7d1baeadc8f4f22b6c738997bf5864027787ac337b18ab3ad89488022100adcefaf4182096e06bd3e57756e4029dfd598c755a0885499a178043d1ef6766',
  hash: '6aa7a48970a9f1609583701848b30ec622c1efc7eb11c57652254c4c44637475'
}
--------
Does verify:
{
  sig: '30440220773971d9aeb4e02bf41e978621a5dc110e1f91f1b7c773b774d37dea98a89074022061000945e5852ed4b9cc17dc39f7ddaa68c235b1f826fc68fcad913662b59a68',
  hash: '642a77be5a9203209b1136a5df685a645fddd3a81785b19a7d3910a2d5d77955'
}


text:
What are the benefits of decoy packets before the version packet in the BIP324 handshake?
The BIP324 spec allows for any number and any size of decoy packets in the initial handshake of the protocol, right after the materials have been generated and before the version packet is sent.
Are there strong benefits for this complexity in the middle of the handshake? It is not clear to me how much it adds to have that variability on the "left" side of the (currently empty) version packet. But it does add a bit of complexity to implementations given the lack of bounds on the decoy packets. I noticed Core has not supported sending decoy packets in the handshake since adding BIP324 support in v26.0, but is this a worthy feature of the protocol that will later be implemented?

The goal of decoy packets in general is offering the option to implementations of hiding any pattern that can be inferred from the sizes of TCP/IP packets being sent back and forth.
This concern applies to all 3 phases of the protocol. During the key exchange phase, a (limited) form of size pattern hiding can be accomplished through the garbage mechanism. During the application phase, but also during the version negotiation phase, this is done using decoy packets - a much more powerful mechanism than garbage, but only possible after keys have been exchanged.
It is fair to say that right now, with the version negotiation phase just consisting of a single message in both directions, this does not matter. In both directions, instead of a decoy message before the version packet, a decoy message could be sent immediately after it (making it part of the application phase), or garbage could be sent before it instead.
However, in hypothetical extensions, the version negotiation phase could consist of multiple messages too. If there are at least 3, it may not be possible to avoid a recognizable pattern of sizes in the middle ones. Having the decoy mechanism generically available means future extension designers do not have to worry about it.
Furthermore, design wise, I don't believe it complicates implementations much necessarily, but of course that depends on implementation aspects. Think of a BIP324 connection as having a few states it progresses through:

Sending/receiving public key
Sending/receiving garbage + garbage terminator
Sending/receiving packets

During the 3rd state, all communication is done in the form of packets using the keys negotiated before, decoys and all. The first (non-decoy) packet(s) negotiate the version, and everything after is treated as application layer. I think this makes sense, as version negotiation needs something packet-like anyway, so it might as well use the full packet interface anyway.

But it does add a bit of complexity to implementations

Certainly having support for decoy packets as a mechanism in general adds complexity to implementations which cannot be avoided if compatibility with the specification is desired. I don't think having it additionally available during version negotiation adds much complexity on top.

given the lack of bounds on the decoy packets.

One cannot avoid supporting packets up to ~4M as that is how large application-layer BLOCK messages are allowed to be. I believe the Bitcoin Core BIP324 implementation uses that as packet size limit for all packets, including decoys.

I noticed Core has not supported sending decoy packets in the handshake since adding BIP324 support in v26.0, but is this a worthy feature of the protocol that will later be implemented?

It is not very high on my personal priority list, but I do plan to work at some point on adding support for sending decoys to the Bitcoin Core BIP324 implementation, in particular for transactions (whose relay sizes do reveal some information). It would be great if someone worked on this.

My guess is to guard against "known plaintext" attack

A known plaintext would permit an attacker to guess the key stream coming out of the used ChaCha20 cipher, though there are no known ways to exploit that to achieve anything useful (like decrypting other messages, or forging messages). This was not a specific consideration when designing BIP324 or its decoy packet mechanism, as far as I recall.

Disclaimer: I am a co-author of BIP324, and am likely biased about the design decisions we made in it.

Thanks Pieter, this helped my understanding a ton. The breakdown of how garbage hides the key exchange phase and decoys hide the application phase keeps it simple. I believe my confusion was coming from two things: (1) Since version packets are empty for now, garbage and decoys are kind of the same for them and (2) The handshake spans across the key exchange and application phases. From an implementation perspective, I wrongly assumed the handshake would have a static memory requirement. But since it involves the application phase, its clear now that this isn't the case and for good reason.