text:
Bitcoin Cash full node
Whats bitcoin cash is it a description on how BCH/BCC should run ?
I need a full node BCH/BCC If I run bitcoin ABC or UNLIMITED will I get the bitcoin cash blocks ?
or are there difference in blocks between ABC and UNLIMITED

"should I run bitcoin ABC/ UNLIMITED" Just choose one. We're not allowed to answer opinion based questions.

Sorry about that I have changed the question

Bitcoin ABC, Bitcoin Unlimited Cash, and Bitcoin XT are Bitcoin Cash node clients. They do the same job, and the most important difference among them is their developers: They are developed by three independent development teams.
Some other differences:

Bitcoin ABC uses Compact Blocks, Bitcoin Unlimited uses XThin, Bitcoin XT uses both Compact Blocks and XThin to download new blocks.
94% of the nodes are Bitcoin ABC, more than 5% of the nodes are Bitcoin Unlimited, and only a few (1-5) nodes are Bitcoin XT.

Update: It was 94% when this answer was written (when edited, there are more BU nodes!). You can see the live statistics here
Other than their brands and those ^ differences, they're all the same.
If you really want to help the network, I'd suggest to run XT or Unlimited, because if a node crashing bug was found in Bitcoin ABC, it'd affect 90% of the network. If the network was 33% Bitcoin ABC, 33% Bitcoin Unlimited and 33% Bitcoin XT, then no such bug would be important that much, and the network would be more decentralized.


text:
Stealth addresses how does recipient use the bitcoins?
I've been reading on what stealth addresses does:

Sender generates unique address using the recipient's stealth address for every transaction
If multiple senders send bitcoin to recipient, then blockchain sees sender's addresses going to different random looking addresses

My question is: How does the recipient use the bitcoin he receives? In the recipient wallet, does he have a list of those generated address (made by the sender)? How would he then use those bitcoin without revealing transaction linkability?

I was trying to understand them better to answer this question, but came up with this: https://www.reddit.com/r/Bitcoin/comments/5xm9bt/what_happened_to_stealth_addresses/

How does the recipient use the bitcoin he receives?

Stealth addresses require you to scan all the transactions of the blockchain It is a fairly inefficient process but the stealth address implementations that I've seen have two improvements:

prefix: each stealth address has a required prefix and you must bruteforce your txid to match the prefix encoded in the stealth address. That way the receiver must only test a subset of transactions.
dual-key system: a scanning key is introduced to allow the receiver to scan whilst their wallet is locked.

In the recipient wallet, does he have a list of those generated address (made by the sender)?

Yes. A new address is derived from the stealth address and the ephemeral key (provided in the additional output with OP_RETURN). This address is then imported into the wallet.

How would he then use those bitcoin without revealing transaction linkability?

Transaction linkability generally means that you can not link a transaction to a published address (obfuscating the destination). The concept you're aiming at, is transaction traceability (when creating a transaction, how do I obfuscate the source output).

The receiver got to continually scan the entire blockchain to find a match to his/her private keys. Read more: https://www.reddit.com/r/Bitcoin/comments/5xm9bt/what_happened_to_stealth_addresses/

source: Stack Exchange

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

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

sort: votes


text:
how does a node searches a transaction among various blocks in blockchain?
Let me express what I have got to know about blockchain and where am I stuck.
Transactions are stored in the form of merkel trees inside a block. (I know how a merkel tree is made). A merkel root is calculated and stored in the block header. An SPV can ask a full node about the balance of an address (which is an encryption of public key).
Now a full node is supposed to give merkel root hash of all the blocks which contain the transactions( which contains the UTXOs which can be spent by the private key holder by unlocking its output script using its digital signature).
I want to know how does the full node get to know which blocks exactly contains those UTXOs? Does it the traverse merkel tree of each block till genesis block? or is there any way to know if the block contains those transaction or not just by utilising its merkel root.

Transactions are stored in the form of merkel trees inside a block. (I know how a merkel tree is made). A merkel root is calculated and stored in the block header.

All correct.

An SPV can ask a full node about the balance of an address

No, it can only ask for a proof that a particular transaction was included in the blockchain. The Merkle tree has transactions as leaves, not addresses
At the protocol level there are no balances, only UTXOs. UTXOs (or "coins") are things with a value and an address, and every transaction simply "reforges" coins. It explicitly lists certain input coins which are melted down fully (destroying those coins in the process), and then constructs new coins whose value does not exceed the value of the consumed coins. Nowhere in this system does a balance appear.

(which is an encryption of public key).

A hash, not an encryption. There is no encryption anywhere in Bitcoin (except locally to password protocol your wallet file).

I want to know how does the full node get to know which blocks exactly contains those UTXOs?

This is unrelated. Blocks contain Merkle roots of transactions. They don't contain UTXOs.
One way to look at it is that there is an implicitly-defined set of UTXOs for each block. This set is empty for the genesis block. Every transaction processed deletes the UTXOs it consumes from that set, and adds new UTXOs to it for each output it has. As blocks are groups of transactions, they too are just aggregations of groups of UTXOs being deleted from and added to the UTXO set.
In fact, that is how full nodes work. They just maintain a database with all unspent outputs. Every block is just an authenticated "patch" of changes to make to the UTXO set.

Does it the traverse merkel tree of each block till genesis block? or is there any way to know if the block contains those transaction or not just by utilising its merkel root.

I assume you're talking about BIP37 Bloom Filters? There is no searching involved at all. A light client tells a full node "hey I am interested in transactions to address X". Then it asks for a range of blocks. The full node reads through those blocks, and if a matching transaction is found, sends it to the light client along with a Merkle branch that proves the transaction was indeed in that block.
This approach has various downsides. First of all, it is inefficient, as it requires the full node involved to read and scan through all transactions in all blocks. Secondly, it is terrible for privacy. Even while the set of addresses the light client is interested in is hidden inside a Bloom filter, it is very hard to not make it leak what transactions a node cares about.
BIP157/BIP158 specify a more efficient and more private protocol called Neutrino to accomplish the same.

Thank you so much Pieter for giving such an elaborate answer. Could you please clarify didn't you mean searching by this quoted statement?
"The full node reads through those blocks, and if a matching transaction is found, sends it to the light client "

I guess I wouldn't call that searching as there is nothing smart about it... no indexes, no fancy data structures... just read from front to back and send back what matches.

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


text:
Does Bitcoin accept HYIP website?
I'm running a HYIP website I'm considering to use Bitcoin. Does Bitcoin have a limit on funding or withdrawal amount? Is there any chance Bitcoin blocks my account because I receive money from a HYIP website?
Thank you.

Bitcoin's not a person or organization. It's a network of computers, and it doesn't care about your intent.

There is no way one can have his account blocked in Bitcoin and there are no funding or withdrawal amounts limits. However, you should take into account that all Bitcoin is pseudo-anonymous, i.e. although there is no direct connection between you and your account address, all transactions are public and could be tracked by anyone.

Bitcoin is a communication protocol, it doesn't have policies. It is like asking if TCP/IP allows porn.


text:
What is the best way to purchase Bitcoins quickly?
What is the best way to purchase Bitcoins quickly? I don't want to wait a month.

Depends on your location...........

On LocalBitcoins.com you can get bitcoins bought under one hour. Just pick a trader who has good reputation (not a scammer) and low response times.

There's lots of information available here: How do you obtain bitcoins?
coinbase.com has a pretty good reputation I understand, and I find the interface to be quite cleverly designed.

It really is all about your location. In some countries, it's harder to get set up to sell bitcoins than other countries.
If you're in the UK, try one of these to get near-instant Bitcoins:

Bittylicious
BitBargain
Local Bitcoins (UK)

Check out bitinstant.com
You can deposit cash and get btc sent to your email or btc address right after you pay.

I recommend Coinbase. That's how I got my first 10 coins.
When I wanted to get my first coins I was already registered on Gox but wasn't sure how long international transfers would take.
I signed up with them and did the bank deposit verification method. I believe I verified the next day and bought 10 coins. I got the coins immediately but for anti-fraud measures I couldn't spend them for a few days (looks like on 8/20 the wait is 4 business days)
After being more trusted the buy limit goes up and your coins are available immediately.

If you're in the UK then check out https://bit121.co.uk as they are a legitimate exchange with UK based banking. Most bank transfers within the UK are usually instant and you don't have to pay the higher fees when dealing with foreign banks.

If you live in the Netherlands, you can use bitonic.nl to purchase Bitcoins via iDEAL. You get them in a few minutes.

Probably Ebay....From a trusted seller   via bank transfer

Bitcoin is definitely in its infancy.  I have bank accounts all over the world in USD, GBP, and CHF.  I have accounts on Coinbase, BTC-e, CampBX, Mt. Gox, Bitstamp, LocalBitcoins, and others.
Yet, it is next to impossible to move fiat currency to these exchanges.  In fact, I have only ever been able to buy bitcoins on Localbitcoins, thanks to the immediate transfer facility in the U.K. banking system.
For people who want to buy in USD, which is where the major exchange volumes are, there has not been a way to transfer USD to an exchange without a currency exchange, bank and exchange fees, and a long wait.
CampBX is adding ACH transfer on November 20.
Coinbase not only requires all bank and credit cards to be based in the U.S., they also require the holder to be based in the U.S.  This essentially restricts Coinbase to the 4% of the world that lives in the U.S.
It is frustrating watching the volatile price action and being unable to trade because I can't get fiat to the exchanges.

you describe the problem, why the question is interesting istead of answering the question.

The answer depends on where one lives, what you regard as an acceptable transaction cost, what currency you want to buy in, as well as other variables.   Given the unclear question, my comment is as close to an answer as you can get.

So, you are saying, the question couldn't be answered that's why you wrote something other than an answer? ;)

You have a point.  I would have (and should have) commented and asked the poster to define the question in a way that one could frame an answer.  However, again, I do not have sufficient points to do this, so I gave some general feedback that might be of interest.

I think you can always flag posts, here if you come to the conclusion that the question is bad you may use "unclear what you are asking" or "too broad". In this case "off-topic" would also be appropriate.

With 17 points, I can't do anything.

I am sorry, not everyone, but with 15 points you can flag. ;)


text:
Bitcoin QR codes: raw address or Bitcoin URI scheme
I am the author of bitcoinaddress.js library and I am wondering what's the best content for Bitcoin QR codes.
What Bitcoin QR codes should contain (for mobile wallet apps and other barcode scanners):

Only Bitcoin address (this is only one I have seen wild myself)
Bitcoin URI scheme link (BIP 21) with payment amount, transaction note, etc.

Currently I implemented address only, as I don't know how well-spread BIP 21 support is among the mobile phones and mobile wallets. If anyone can give me some answers and pointers to the prior research regarding the matter I'd be grateful.

I'm working on a Bitcoin project, and what I've seen are:

Just the Bitcoin address
A url parameter-like scheme with the format "bitcoin:{plus the bitcoin address}" (no brackets used)
A more elaborate url parameter that includes the amount, like "bitcoin:{bitcoin addr}?amount={the amount}

Coinbase uses the last scheme and it is fully recognized by the BlockChain iPhone app, enabling you to request a certain amount of Bitcoin directed to a specific address.
Coinbase uses the (deprecated) Google chart apis and the full querystring they use to build a QR code looks like this:
<img width="300" height="300" alt="Chart?cht=qr&chl=bitcoin%3a1k1yfezde2c37pwdevjnin1yc2qbtly6bk%3famount%3d0" src="https://chart.googleapis.com/chart?cht=qr&chl=bitcoin%3A1K1yfEZde2C37pWDevjnin1yc2qBtLy6bk%3Famount%3D0.01&choe=UTF-8&chs=300x300">

If you run that src url through a url decoder, you'll find that it requests 0.01 BTC to the address 1K1yfEZde2C37pWDevjnin1yc2qBtLy6bk.
When you're building a QR code, you don't need to url-encode the data.  Coinbase is only doing so because they have to request the QR code from Google through a url addressing scheme.
I build my QR codes on my own server and display them as images on a web page, and I just use non-encoded data.

My project internally uses qrcode.js which can built QR codes on the client-side and claims compatibility down to IE6. Check it out, I highly recommend.

Also the eloborate URL parameter is called "Bitcoin URI Scheme" and can be found under proposal BIP 0021.

@Mikko, thanks for the pointer to BIP21.  I reviewed that after I posted this response and it helped me understand what I was seeing.

BIP0021 does state that "Characters must be URI encoded properly."

"Properly" means according to RFC 3986 section 2; in particular https://tools.ietf.org/html/rfc3986#section-2.4 . Don't just percent-encode characters willy-nilly. Percent-encoding delimiter characters that are meant as delimiters is incorrect.

I'm the founder of CryptoCoinJS and use the library for my own software. This is probably obvious, when scanning QR codes, check for both. When generating QR codes, for backup I'd just do the address and for payment requests, I'd use the URI scheme.

I've met the Coinpunk developer last month at a meeting and he was discussing about how hard it was for him to create an entirely HTML5-based bitcoin QR code generator, that would work also on iOS devices. Apparently he was successful.
I'd therefore suggest to look into his project which is open-source: https://github.com/kyledrake/coinpunk

qrcode.js used in my project internally is open source and works (see Github page for continuous integration status). I'll check Coinpunk too.

I'm adding more info on the matter.
This is a format proposed in Chapter2 of Bitcoinbook (How Bitcoin Works)
bitcoin:1GdK9UzpHBzqzX2A9JFP3Di4weBwqgmoQA?
amount=0.015&
label=Bob%27s%20Cafe&
message=Purchase%20at%20Bob%27s%20Cafe

Components of the URL

A bitcoin address: "1GdK9UzpHBzqzX2A9JFP3Di4weBwqgmoQA"
The payment amount: "0.015"
A label for the recipient address: "Bob's Cafe"
A description for the payment: "Purchase at Bob's Cafe"

And I believe it's pretty much the same as BIP21. Thanks for referencing it.


text:
How do I stop Bitcoin Core from interrupting me with the "Loading wallets..." window?
I run Linux. Debian 12. XFCE. I have installed Bitcoin Core. I think this same thing happens on Windows as well.
Basically, I have it start at boot. Then, after many minutes have passed and I have started typing something in some program, or begun working in other ways, I'm suddenly interrupted by a minimal GUI window saying "Loading wallets...", which pops up in front and steals focus.
This is insanely annoying as it happens long after Bitcoin Core has been started.
I have looked everywhere for a way to turn this pointless window off, or make it open in the background/minimized/not stealing focus. I've asked on IRC but was told that "it's open source so you can modify it yourself if it bothers you". Yeah... I'm not even going to comment on that one.
What can be done to stop this terrorizing window from popping up and stealing focus, interrupting my work?

If you are running the interactive GUI application bitcoin-qt you should expect to see GUI alerts.
If instead you run the background daemon version bitcoind, and run it in daemon mode, I would expect the messages will be in the logfiles. You would use bitcoin-cli instead of the GUI if you need to interact with  Bitcoin core.

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


text:
How to parse a raw transaction field by field?
I am trying to understand all the parts of a legacy transaction. If I wanted to translate each part of the transaction to something human-readable, how would I need to go about that?

Related questions: - In what format does a block store the transaction data?.

What are the parts of a Bitcoin transaction in segwit format? .
How to extract transaction amounts from tx block?.
What is the different between CompactSize and VarInt encoding?

This is one method to parse a bitcoin transaction manually, one level above the script level.
Parsing a Bitcoin Transaction By Hand

This tutorial follows the lessons taught by Base58 Bitcoin Developer Basics: Transactions, Scripts + SegWit

To parse a Bitcoin transaction, it is a pre-requisite to understand encoding, decoding, and endianess. Hence, this analysis will assume the knowledge of calculating a hex coded number back to integer, and a sequence of bytes organized from little endian to big endian.
Here is a high-level illustration of the field types in a Bitcoin transaction.

First Ever Bitcoin Transaction: Satoshi Nakamoto Sent Hal Finney 10 BTC
You can look up the transaction on blockstream.info using the txid below.
txid = 'f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16'
If you are using Bitcoin Core, you can pass the txid as a parameter and fetch the raw_hex, or raw transaction data, using this command:
bitcoin-cli getrawtransaction f4184fc596403b9d638783cf57adfe4c75c605f6356fbc91338530e9831e9e16

I added spaces in between fields of the raw_hex as form of pre-parsing, but below I explain step-by-step what each field means and how to decode them.
raw_hex = '01000000 01 c997a5e56e104102fa209c6a852dd90660a20b2d9c352423edce25857fcd3704 00000000 48 47304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d0901 ffffffff 02 00ca9a3b00000000 43 4104ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84cac 00286bee00000000 43 410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac 00000000'
Decoding Each Field
Version
The first field in the raw_hex is the version number that has a fixed length of 4 bytes. That means 8 hexadecimal characters. Fixed-length fields are always little endian. They must be converted to big endian, and then decoded from hex to integer. This Python code will do the conversion for you:
# Python_1 script to decode fixed-length fields to an integer.

value = int.from_bytes(bytes.fromhex('hex_value_with_quotes'), 'little')
print(value)

--> Indicates the process of decoding, or the conversion.
"version", 4 bytes, 8 hex characters: 01000000 --> 1
Count of Inputs, input_count
The second field represents the count of inputs. It has 1-byte and its format is CompactSize.
CompactSize fields have some tricky rules. First, you'll always parse the first byte, 2 hexadecimal characters, and convert from hex to int, straight up.

If the value is less than 253, you don't need to worry about endianess because the value is within a single byte. Just use the value you got from the direct conversion from hex to integer.

If the value is 253, the input count will be the next 2 bytes, 4 hexadecimal characters. Remember that at this point you MUST convert from little endian to big endian before converting from hex to integer.

If the number is 254, the input count will be the next 4 bytes, 8 hexadecimal characters. Convert from little endian to big endian before converting hex to integer.

If the number is 255, the input count will be the next 8 bytes, 16 hexadecimal characters. Convert from little endian to big endian before converting hex to integer.

"input_count", 1 byte at first, 2 hex characters: 01 --> 1
Source Transaction ID, txid
The next step is to parse the tx id source, or the id of the origin of the input. Here, you will keep the field in hexadecimal. Different from other fixed-length fields in a Bitcoin transaction, the tx ids should not be converted to integer and need to be kept in hex.
However, you need to convert from little endian to big endian. This field is always 32-bytes, 64 hexadecimal characters.
Since you will NOT decode from hex to int, this fixed length hex needs to be converted to bytes, then from little endian to big endian, then back to hex.
You'll know you parsed correctly if you can use the decoded value in a block explorer and find the transaction there.
See below a simple Python script that can do that for you.
# Python_2 script to break down hex to bytes, reorganize from little endian to big endian, then assemble the value back to hex.

txid_bytes = bytes.fromhex('hex_value_with_quotes')[::-1].hex()
print(txid_bytes)

"txid", 32 bytes, 64 hex characters: c997a5e56e104102fa209c6a852dd90660a20b2d9c352423edce25857fcd3704  ---> 0437cd7f8525ceed2324359c2d0ba26006d92d856a9c20fa0241106ee5a597c9
Vector Output or Output Index, vout
The next field is the vout, vector output or output index. It is the index of the output of the previous transaction that is being used as an input for the current transaction.
Note that it can be fetched only after we have the source tx id (id of the previous transaction). The vout has a fixed length of 4 bytes. You need to convert the vout from little endian to big endian, then from hex to int. You can use the Python_1 script.
"vout", 4 bytes, 8 hex characters: 00000000 --> 0
Unlocking Script Length, scriptSig_len
Now we have another CompactSize field representing the scriptSig length. Depending on the complexity of the spending rules, the scriptSig can have a variable number of hexadecimal characters. The scriptSig_len determines such number so we can parse accordingly.
First let's convert the first byte from hex to int and see if it is smaller than 253.
"scriptSig_len", 1 byte at first, 2 hex characters: 48 --> 72 bytes --> 144 hex characters
Since 72 it is smaller than 253, let's count 144 hexadecimal characters.
Note that the CompactSize in scriptSig_len represents a length in bytes, while a CompactSize in input_count represents the pure counting of integers.
Unlocking Script, scriptSig
The next 144 characters are the unlocking script, or scriptSig. This value is already in big endian and does not require conversion.
"scriptSig", variable size: 4847304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d0901
nSequence
Next is the nSequence, a fixed-length field of 4-bytes, 8 hexadecimal characters. It is in little endian and can be converted to big endian, then from hex to int using that previous Python_1 script.
The versatility of the nSequence field reflects the evolving nature of Bitcoin's protocol and its adaptability to new use cases and enhancements. It plays a crucial role in enabling various types of transaction flexibility, particularly in terms of timelocks and transaction replacement policies.
"sequence", 4 bytes, 8 hex characters: ffffffff --> 4294967295
Count of Outputs, output_count
Theis field represents the count of outputs. You can follow the same rules of decoding used in the count of inputs. Decode the first byte and follow the rules of CompactSize decoding.
"output_count", 1 byte at first, 2 hex characters: 02 --> 2
Value in Satoshis, amount
Now it is time to calculate the amount in satoshis of this tx. This value is a fixed-length with 8 bytes. You can use the Python_1 script.
"amount", 8 bytes, 16 hex characters:  00ca9a3b00000000 --> 1000000000
Locking Script Length, scriptPubKey_len
Now comes the script length of the output script, or locking script. Remember that it is a CompactSize that will give the length in bytes. Let's parse the first byte from hex to int and see if the number of bytes is smaller than 253.
"scriptPubKey_len", 1-byte at first, 2 hex characters : 43 --> 67 bytes --> 134 hex characters
Locking Script, scriptPubKey
The next 134 characters are the locking script, or scriptPubKey. This value is already in big endian and does not require conversion.
"scriptPubKey", variable size: 4104ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84cac
Second Output Value in Satoshis, amount
Next, we'll parse the second amount value to satoshis. You can use the Python_1 script.
"amount", 8 bytes, 16 hex characters : 00286bee00000000 --> 4000000000
Second Output Locking Script Length, scriptPubKey_len
Now let's parse the second locking script length, in CompactSize.
"scriptPubKey_len", 1 byte at first, 2 hex characters : 43 --> 67 bytes --> 134 hex characters
Second Output Locking Script, scriptPubKey
Now, by counting the next 134 hex characters, we have the scriptPubkey proper.
"scriptPubKey", variable size: 410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac
nLocktime
The last value is the locktime. It is a fixed length field. Convert it from 4-byte little endian then from hex to an integer. You can use that Python_1 script here too.
"locktime", 4 bytes, 8 hex characters: 00000000 --> 0
Parsed-by-Hand tx in a Python dict format
parsed_tx = {
    "version": 1,
    "input_count": 1,
    "inputs": [
        {
            "txid": '0437cd7f8525ceed2324359c2d0ba26006d92d856a9c20fa0241106ee5a597c9',
            "vout": 0,
            "scriptSig_len": 72,
        "scriptSig": '47304402204e45e16932b8af514961a1d3a1a25fdf3f4f7732e9d624c6c61548ab5fb8cd410220181522ec8eca07de4860a4acdd12909d831cc56cbbac4622082221a8768d1d0901',
            "sequence": 4294967295,
        },
    ],
    "output_count": 2,
    "outputs": [
        {
            "amount": 1000000000,
            "scriptPubKey_len": 67,
            "scriptPubKey": '4104ae1a62fe09c5f51b13905f07f06b99a2f7159b2225f374cd378d71302fa28414e7aab37397f554a7df5f142c21c1b7303b8a0626f1baded5c72a704f7e6cd84cac'
        },
        {
            "amount": 4000000000,
            "scriptPubKey_len": 67,
            "scriptPubKey": '410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac'
        },
    ],
    "locktime": 0
}

https://github.com/biohazel/tech-writing/blob/master/2023-12-15-parsing-btc-tx-by-hand-v0.0.0.md


text:
Native P2WSH over P2SH | P2SH-P2WSH
I'm in the process of attempting to generate a transaction using the Python Bitcoin Utils library. that involves P2WSH-over-P2SH (P2SH-P2WSH). My activity is on the regtest network. Below is the code snippet and address that I've prepared.
txin_redeemScript = Script([
    'OP_2',
    private_key1.get_public_key().to_hex(),
    private_key2.get_public_key().to_hex(),
    'OP_2',
    'OP_CHECKMULTISIG'
])
script_bytes = txin_redeemScript.to_bytes()
hashsha256 = hashlib.sha256(script_bytes).digest()
hashsha256 = hexlify(hashsha256).decode('utf-8')

txin_scriptPubKey = Script(['OP_0', hashsha256])
txin_p2wsh_address = P2shAddress.from_script(txin_scriptPubKey)

This address is where I intend to send the coins, and this is the transaction I'm forming:
p2pkh_addr = P2pkhAddress('n4bkvTyU1dVdzsrhWBqBw8fEMbHjJvtmJR')
txout = TxOutput(to_satoshis(amount_to_send), p2pkh_addr.to_script_pub_key())
tx = Transaction(inputs=p2sh_utxo, outputs=[txout], has_segwit=False)

This is the transaction and raw transaction ID
[{'address': '2N4vHiXTCCVMt4TYimTGXRCySzNLXkdiPyH', 'category': 'send', 'amount': Decimal('-0.10000000'), 'vout': 1, 'fee': Decimal('-0.00001430'), 'confirmations': 0, 'trusted': True, 'txid': 'f5f9c98b0c7b0731cba11f5a1b0494a62d2a2de5c09aaf3ac37fa56d48c271bd', 'wtxid': 'bed63897ca9c23ee891a9752b143ee063bf9aa97c813c5a455210a5f8437be6a', 'walletconflicts': [], 'time': 1693271904, 'timereceived': 1693271904, 'bip125-replaceable': 'yes', 'abandoned': False}]

0200000001bd71c2486da57fc33aaf9ac0e52d2a2da694041b5a1fa1cb31077b0c8bc9f9f50100000000ffffffff015f5d9800000000001976a914fd337ad3bf81e086d96a68e1f8d6a0a510f8c24a88ac00000000

The following code is utilized to sign the transaction:
for tx_idx, txin in enumerate(p2sh_utxo):
    sig1 = sk1.sign_input(tx, tx_idx, txin_redeemScript)
    sig2 = sk2.sign_input(tx, tx_idx, txin_redeemScript)
    unlocking_script = Script(['OP_0', txin_redeemScript.to_hex()])
    txin.script_sig = unlocking_script

    witness_data = [b'','OP_0', sig1, sig2]
    tx.witnesses.append(TxWitnessInput(witness_data))

The mempool acceptance test is failing with the error  'reject-reason': 'mandatory-script-verify-flag-failed (Script evaluated without error but finished with a false/empty top stack element)'}
My familiarity with bitcoin programming is limited, and I've been unable to locate any sample code or references concerning P2WSH over P2SH. Despite searching various online resources, I have yet to find any explanations on how the spending process operates. Any help would be appreciated.
You can find the complete code here

It is quite difficult to understand what is going on from the above. Are you certain that the funds are locked in the exact same output type that you are trying to spend? (p2sh(p2wsh(multi-sig) ) ) ?  If not, it will never work.

I noticed that in witness_data you add two values (instead of one for the multisig bug) before the signatures. Why?

Hello @karask thank you for the comment. I am trying to spend P2SH (P2WSH (Multi-sig) ).
I tried so many things in the last couple of days that I have lost track. I tried only one value in the witness data before adding the signatures and hash however that was not working.
I have tried to reach out to you over email as well (with the Jupyter notebook) however if you like (and if helps the community) I can attach Jupyter notebook here.

Hello @karask this is the Jupyter Nootebook attached on Github
https://github.com/Deepanshu2017/bitcoingist/blob/main/P2SH-P2WSH.ipynb
I have modified the question to attach the notebook URL

Hi @Deepanshu  I see in ipynb that you work in a regtest environment. So I assume you created this p2sh-p2wsh(multisig) yourself and are trying to spend it. In order for me to take a thorough look I would need the code for the creation of that UTXO first... and then the code for spending it (like the one your provided) but in testnet/signet so that I can test directly. Too many times, esp. in complex scenarios like this, the problem is that the UTXO is not what you thought it was...

Hello @karask
Thank you for the response. I generated two private keys using some libraries and then using the keys to p2wsh witness script followed by p2sh address. This is the address that got generated "2N4vHiXTCCVMt4TYimTGXRCySzNLXkdiPyH". (Cell number 3 in Jupyter notebook) After this, I created a transaction using bitcoin cli. bitcoin-cli -regtest sendtoaddress "2N4vHiXTCCVMt4TYimTGXRCySzNLXkdiPyH" 0.1
Post this starting from cell number 5 in the notebook, I am trying to spend this. The choice of env (regtest/test) doesn't matter in my case. All I am trying to do is P2WSH in P2SH

Essentially P2WSH is supposed to be backward compatible with P2SH and that's what I am trying to demonstrate with Python Code. We have the deadline to submit the paper tomorrow and if we could somehow make it work, it would be useful addition in our paper.

I don't have time to test it right now. Going though the code I noticed that you sign with sign_input but you should use sign_segwit_input. I hope this helps.

Hello @karask thank you so much for the comment, however changing the sign to sign_segwit_input did not help.
Thank you for the help. Whenever you have time, you can fix the issue, this may help the community to have some sort of reference and would help me as well to eventually figure out the issue.

Construction of transaction to send to a P2SH(P2WSH) UTXO follows:
from bitcoinutils.keys import P2shAddress, PrivateKey
from bitcoinutils.script import Script
from bitcoinutils.setup import setup
from bitcoinutils.hdwallet import HDWallet
from bitcoinutils.transactions import Transaction, TxInput, TxOutput

setup("testnet")

#
# Send from a P2PKH UTXO and send to P2SH(P2WSH(P2PK))
# Change back to the same address (not recommended for privacy reasons)
#

xprivkey = (
    "tprv8ZgxMBicQKsPdQR9RuHpGGxSnNq8Jr3X4WnT6Nf2eq7FajuXyBep5KWYpYEixxx5XdTm1N"
    "tpe84f3cVcF7mZZ7mPkntaFXLGJD2tS7YJkWU"
)
path = "m/86'/1'/0'/0/1"
hdw = HDWallet(xprivkey, path)
from_priv = hdw.get_private_key()
from_pub = from_priv.get_public_key()
from_addr = from_pub.get_address()
print("From address:", from_addr.to_string())

hdw.from_path("m/86'/1'/0'/0/20")
to_priv = hdw.get_private_key()
to_pub = to_priv.get_public_key()

witness_script = Script([to_pub.to_hex(), "OP_CHECKSIG"])
p2sh_redeem_script = witness_script.to_p2wsh_script_pub_key()  # maybe to_p2sh_...

p2sh_address = P2shAddress.from_script(p2sh_redeem_script)
print("To address:", p2sh_address.to_string())

# UTXO's info
txid = "d4616b3050d2a0fac4783cd9a8c727aafa7b1374098d049e91ecc66d655e79e7"
vout = 0

txin = TxInput(txid, vout)
txout = TxOutput(5000, p2sh_redeem_script.to_p2sh_script_pub_key())
txout_change = TxOutput(1530000, from_addr.to_script_pub_key())
tx = Transaction([txin], [txout, txout_change])

sig = from_priv.sign_input(tx, 0, from_addr.to_script_pub_key())

txin.script_sig = Script([sig, from_pub.to_hex()])

signed_tx = tx.serialize()

print(signed_tx)

Construction of transaction to spend from a P2SH(P2WSH) UTXO follows:
from bitcoinutils.keys import P2shAddress, PrivateKey
from bitcoinutils.script import Script
from bitcoinutils.setup import setup
from bitcoinutils.hdwallet import HDWallet
from bitcoinutils.transactions import Transaction, TxInput, TxOutput, TxWitnessInput

setup("testnet")

#
# Send from a P2SH(P2WSH(P2PK)) UTXO to a P2PKH UTXO
#

xprivkey = (
    "tprv8ZgxMBicQKsPdQR9RuHpGGxSnNq8Jr3X4WnT6Nf2eq7FajuXyBep5KWYpYEixxx5XdTm1N"
    "tpe84f3cVcF7mZZ7mPkntaFXLGJD2tS7YJkWU"
)
path = "m/86'/1'/0'/0/20"
hdw = HDWallet(xprivkey, path)
from_priv = hdw.get_private_key()
print(from_priv.to_wif())
from_pub = from_priv.get_public_key()
from_addr = from_pub.get_address()

witness_script = Script([from_pub.to_hex(), "OP_CHECKSIG"])
p2sh_redeem_script = witness_script.to_p2wsh_script_pub_key()
print("From address:", P2shAddress.from_script(p2sh_redeem_script).to_string())

hdw.from_path("m/86'/1'/0'/0/25")
to_priv = hdw.get_private_key()
to_address = to_priv.get_public_key().get_address()
print("To address:", to_address.to_string())

# UTXO's info
txid = "217f123726bd8ace101afd705ae31384fd818fce17c8e00ce6fc0d24c0364355"
vout = 0
amount = 5000

txin = TxInput(txid, vout)
txout = TxOutput(3000, to_address.to_script_pub_key())
tx = Transaction([txin], [txout], has_segwit=True)

sig = from_priv.sign_segwit_input(tx, 0, witness_script, amount)

txin.script_sig = Script([p2sh_redeem_script.to_hex()])
tx.witnesses.append(TxWitnessInput([sig, witness_script.to_hex()]))

signed_tx = tx.serialize()

print(signed_tx)

See also:
https://github.com/karask/python-bitcoin-utils/blob/master/examples/send_to_p2sh_p2wsh_p2pk_address.py
and
https://github.com/karask/python-bitcoin-utils/blob/master/examples/spend_from_p2sh_p2wsh_p2pk_address.py

I want to express my gratitude for providing the examples, but it seems they aren't functioning correctly.
I attempted to perform a transaction from a P2SH(P2WSH(P2PK)) to P2PKH, and it resulted in an error bad-witness-nonstandard.
To investigate further, I decided to verify the UTXOs mentioned in the code on Bitcoin Explorer. Unfortunately, I couldn't locate these UTXOs on Bitcoin Explorer.
The specific UTXO in question is
217f123726bd8ace101afd705ae31384fd818fce17c8e00ce6fc0d24c0364355
https://github.com/Deepanshu2017/bitcoingist/blob/main/P2SH-P2WSH%20Ka.ipynb

I would like to point out 1 thing though, the way I am creating transaction (to get the transaction id for code in regtest) is by passing the to address in sendtoaddress command
./bitcoin-cli -regtest sendtoaddress "mhZ7PvZZp5dafdGdds37m5AbZzArtqFsgT" 0.1
After running the above command, I am getting the transaction id which I have used in code. This is the only command that I am running on bitcoin cli.
My regtest Private Keys are correct (hence the address generated must be correct) however there could be an issue with the way I am generating the transaction.

I have tried these transactions as well
https://live.blockcypher.com/btc-testnet/tx/3fc77c60aab834c83f88e041c399ccefbb1938ec25eaf9914b6fcf775996bf1d/
However I can replicate the error while pushing to blockstream
https://blockstream.info/testnet/tx/push

You cannot see the transactions with a testnet explorer because I have not broadcasted them. I am testing them with my local node with testmempoolaccept. This way I don't need to be sending funds back and forth all the time for the tests.

Just to be certain try the examples directly from the github repo (don't copy/paste from here). I just tried the examples and they worked. You can try them yourself, even with regtest by directly running them and then do a: bitcoin-cli testmempoolaccept ["first tx raw hex", "second tx raw hex"]    (this way you also test the 2nd tx that depends on the first without broadcasting them)

By directly running them I mean your either use your own keys instead of the ones I used in the example or you need to import the keys in the example to your bitcoin node. Not sure which one you tried. I am also not sure if you got the above error running the two examples I provided or by trying to fix your code.

Hi @karask,
Thank you so much for the response. I tried running the example from GitHub, cloned the repo, ran both the examples and did mempool accept test by providing both the hex. It worked. I tried individual hex as well and it worked.
Thank you so much.
One last question, When I tried running it from Notebook it failed. Let me try again.
https://github.com/Deepanshu2017/bitcoingist/blob/main/P2SH-P2WSH%20Ka.ipynb
Again thank you so much for the help!

You are welcome. I would suggest compare the raw hex of the txs to see how they differ to pinpoint what changes. You will need to get acquainted with the structure of the bitcoin transaction to do that properly. e.g. https://bitcoin.stackexchange.com/questions/113697/what-are-the-parts-of-a-bitcoin-transaction-in-segwit-format

Okay so the error must be either the way I am creating transaction or Private Key.
To generate Private Key I have used PrivateKey class from bitcoinutils.keys
To generate the transaction, I copied the from address (which was in this case 2MuxtgnkyrUSudv99YbeApZQtfQmtuw7e8p ), went to https://coinfaucet.eu/en/btc-testnet/ and sent some funds. That gave me the transaction ID which I am using in the code.

This is the notebook, that is the same code as yours however uses the different Private Key.
https://github.com/Deepanshu2017/bitcoingist/blob/main/P2WSH%20Ka.ipynb
Basic trimmed down version.

Let us continue this discussion in chat.


text:
Unsuccessful Bitcoin Script Execution: Seeking Assistance
I attempted to mint SATS tokens on the Bitcoin network using the Ordinals protocol and BRC20 standards by utilizing an intermediary software written in the Go language. I made no adjustments to the software and it likely sent raw data directly. My intention was to execute 500 repetitive minting transactions without being aware of the 25 transaction limit.
However, I encountered the following error:
"Send error, reveal send error, 25 transaction hashes could not be parsed, sendrawtransaction RPC error: {"code":-26,"message":"too-long-mempool-chain, too many descendants for tx 369a184f3e941a501b99a2865f6c1db09f39af379ef8c63fb52689e37e3376a7 [limit: 25]"}: maximum hash string length is 64 bytes."
As a result of this error, only 25 out of my 500 transactions were successful in executing the Bitcoin command. The remaining 475 transactions did not consume the sent 0,00002914 btc, and consequently, the tokens I minted did not reach me.
Is there anything I can do for Bitcoin script that did not fulfill their task?
https://mempool.space/tx/369a184f3e941a501b99a2865f6c1db09f39af379ef8c63fb52689e37e3376a7

Is there anything I can do for Bitcoin script that did not fulfill their task?

The blockchain has your original transaction 369a...76a7 with 500 outputs plus change.

As shown above, the blockchain also has 25 of your intended 500 subsequent transactions. Those 25 have inscriptions in their inputs (consuming 25 of the 500 outputs of your original transaction 369a...76a7):
blockchain> txfile brc500_1.hex
  Version:................01000000 (1)
  Type:...................0001 (Segwit)
  Inputs:.................01 (1)
  Input:1
    Previous Transaction:.369A184F3E941A501B99A2865F6C1DB09F39AF379EF8C63FB52689E37E3376A7
    Previous Output Index:0000 (0)
    Script Length:........00 (0)
    Unlocking Script hex:.
                     asm:.
    Sequence:.............F5FFFFFF
  Outputs:................01 (1)
  Output 1
    Value:................4A01000000000000 (330)
    Script Length:........22 (34)
    Locking Script hex:...51203BB3F303DF3529D9E693BE1C9CBDF6D5B582EE9F592381CD9777E7DF92C2
                          5406
                   asm:...1 (32)
  Witness 1
    Item Count:...........03 (3)
    Item 1
      Length:.............40 (64)
      Data:.........hex:..94D2FE87DF695FB9C40C3CC06AFCB8B7732785E0F322BC6E223363FE714C2ABD
                          D1BCB5C4525EFC8E00B4BDB2F6C3C78BB7EC37E65D8FD0517BCF7BBD03F3DD86
    Item 2
      Length:.............80 (128)
      Data:.........hex:..208093C76124876944CC7AE3F4C1AC2E5318694890ECD16C2E01FCC99B9D31EA
                          77AC0063036F7264010118746578742F706C61696E3B636861727365743D7574
                          662D38003A7B2270223A226272632D3230222C226F70223A226D696E74222C22
                          7469636B223A2273617473222C22616D74223A22313030303030303030227D68
                    asm:..(32) CHECKSIG 0 IF (ord) (1) (text/plain;charset=utf-8) 0 ({"p":
                          "brc-20","op":"mint","tick":"sats","amt":"100000000"}) ENDIF
    Item 3
      Length:.............21 (33)
      Data:.........hex:..C08093C76124876944CC7AE3F4C1AC2E5318694890ECD16C2E01FCC99B9D31EA
                          77
  LockTime:...............00000000 (0)
  (Calculated hash is B359267DDB752FFB3ADE7EE2BDE30053B141EFDC3396242740B1F9B5BDB5EB85)

blockchain> txfile brc500_25.hex
  Version:................01000000 (1)
  Type:...................0001 (Segwit)
  Inputs:.................01 (1)
  Input:1
    Previous Transaction:.369A184F3E941A501B99A2865F6C1DB09F39AF379EF8C63FB52689E37E3376A7
    Previous Output Index:0018 (24)
    Script Length:........00 (0)
    Unlocking Script hex:.
                     asm:.
    Sequence:.............F5FFFFFF
  Outputs:................01 (1)
  Output 1
    Value:................4A01000000000000 (330)
    Script Length:........22 (34)
    Locking Script hex:...51203BB3F303DF3529D9E693BE1C9CBDF6D5B582EE9F592381CD9777E7DF92C2
                          5406
                   asm:...1 (32)
  Witness 1
    Item Count:...........03 (3)
    Item 1
      Length:.............40 (64)
      Data:.........hex:..13738044ACBBA78A353BC3DB2CF3C2C692C00171969E2DF538568AE3B5E56792
                          130CC40D7FFC0D249ECD00DE8A6F59FCC7DBDB1F8F91AC9A19C2A01AF89E268B
                    asm:..(19) DIV NUMNOTEQUAL (45)
    Item 2
      Length:.............80 (128)
      Data:.........hex:..205337C61F505AA78712D3145B8AF9D57E6C14E28C397748E4A70E14D6E65643
                          14AC0063036F7264010118746578742F706C61696E3B636861727365743D7574
                          662D38003A7B2270223A226272632D3230222C226F70223A226D696E74222C22
                          7469636B223A2273617473222C22616D74223A22313030303030303030227D68
                    asm:..(32) CHECKSIG 0 IF (ord) (1) (text/plain;charset=utf-8) 0 ({"p":
                          "brc-20","op":"mint","tick":"sats","amt":"100000000"}) ENDIF
    Item 3
      Length:.............21 (33)
      Data:.........hex:..C15337C61F505AA78712D3145B8AF9D57E6C14E28C397748E4A70E14D6E65643
                          14
  LockTime:...............00000000 (0)
  (Calculated hash is B23783ED32C421E225C0DA1D43D301DE704066D4456820753D454C8D132E6155)

So I guess you should submit the remaining 475 transactions, possibly in groups of 25 if your tools have that restriction.
In this situation I would replicate the situation in testnet, not in mainnet, and then test out creating the remaining transactions one at a time on testnet. I would only use mainnet after being completely satisfied with the results in testnet.
As I commented, I am not an expert in Ordinals, Inscriptions or BRC-20. Do this entirely at your own risk.

Addendum.
The outputs of the original transaction are P2TR (taproot) so the transactions that spend those need to include three witness components as shown in What are the scriptPubKey, scriptSig, redeem script and witness for the various output types? . The BRC-20 inscriptions are made in the second witness item.
Some more details can be found in various places such as
How to differentiate between BTC transactions and BRC20 transactions on a blockchain? , the Taproot BIPs and the documentation for BRC-20 and ordinals inscription.
If you don't have an easy way of doing this, you may find it easiest to write off the transaction or spend the Bitcoin amounts with a normal wallet.

I apologize for any misunderstandings, as I only began researching these topics after encountering this issue. If there are any mistakes in my understanding, please correct me. Should I send the transaction in the following format? For example: Input: txid: 369a184f3e941a501b99a2865f6c1db09f39af379ef8c63fb52689e37e3376a7 (Transaction ID with 500 outputs) index: 26 amount: 0.00002914 txid: 369a184f3e941a501b99a2865f6c1db09f39af379ef8c63fb52689e37e3376a7 index: 27 amount: 0.00002914 Outputs: My wallet address and the output amount. Is the output amount significant?@RedGrittyBrick

@216kedi: I think you are on the right track but I am not an expert in Ordinals, Inscriptions or BRC-20. Do this entirely at your own risk.

Your invaluable help is appreciated. After days of research, I'm still a bit confused. Is it necessary to include witness info in the new transaction, or simply the scriptPubKey? If witness info is required, please explain the roles of Item 1 and Item 3 in your example. My script generates new wallets for each minting transaction. Do I need their private keys to resend unexecuted outputs, or can I use my main wallet's key with 500 outputs? Lastly, could you demonstrate how to create the raw code for a single operation? Thanks! @redgrittybrick

See addendum to answer. You may get better help in a BRC-20 forum.

I read so much and was confused that I didn't know what to do. The mint process is about to reach its final limit, I think I've lost this fight. Thanks so much for your help. @redgrittybrick


text:
Receiving Money on Electrum
I just started using Electrum noticing there are quite a few Public-Private key combinations(addresses) in the wallet. Every time I do a 'receive' transaction, Electrum uses a new Public key. This has resulted in my funds being spread across multiple addresses (each of these pairs is a wallet, as per my understanding).
Similar Issue: No sign of my private keys in Electrum wallet ... where do I find them?
Download Link: https://electrum.org/ (Not Malicious)
I'm very confused how would I send my funds now. This is not something I would like the wallet program to do for me. I guess it creates this new recieve address for privacy but now how does one get funds out to spend?
I am new to crypto. Can someone please explain me.

The original answer was written when my impression was that you were asking why Bitcoin wallets use new addresses on each new payment process. At this point, you have described so many strange behaviors that my impression is that you are running malware instead of Electrum. Some red flags are:

Wallets do not move funds without a user interaction.
Your wallet informs you that the output address is "Not known, this is a non-wallet txid".

I would suggest that you attempt moving your funds to a new wallet controlled by a different device. If you succeed, you’re good and I’m misunderstanding the situation, but it seems to me that your funds have been stolen.

I’m not able to understand how to use electrum to send funds when this kind of situation happens. Can you please guide me?

This kind of situation is the normal situation. Just click the "Send" tab at the top of the screen - it will ask for the receiver's address and amount to be sent.

How can you send given the address electrum sent to is not the original address I got funds on

@caliGeek: I’m having a hard time telling whether you are a) talking about change outputs, b) the wallet creating fresh receive addresses after each transaction, or c) your funds were immediately swept from your wallet right after you received them. Could you perhaps elaborate your description or show us a screenshot (feel free to cover private information such as exact amounts, anything past the first ~7 characters of an address, txids, etc.).

https://www.blockchain.com/explorer/transactions/btc/596802d0b3f99149b6c7b4250ce52894938d252aa3ad4fdbf125336bb0c80553
I got the deposits and then a new UTXO gets created at a new address. Not happy with electrum behavior here

Which of these addresses are yours? Just the two on the left or all three?

If you didn't send 3.73118785 BTC to
bc1qa4hrzegkrrq5fmyelma2y3lcs2papk5ee7suns
it means someone else probably has - maybe they got access to your keys, they tricked you into using fake software or some other trickery or security breach.

Looks like a new output was created out of two inputs which is expected I guess since the second address is listed as a receiving address in electrum. It does this for any small amount deposited which is really strange. I’ve had those coins for a while in ledger live with no issues.

I’m using a coldcard so to spend I need to sign from coldcard which has not happened and these were new deposits on a new wallet with strong seed

@Murch I'm referring to b I think based on my issue but posting screenshots

Wallets don’t just do that for you. Did you send all your funds to yourself? Because, if you didn’t send the 3.73118785 ₿, someone else did. Have you verified that bc1qa4hrzegkrrq5fmyelma2y3lcs2papk5ee7suns is your address?

Looks like electrum or the program did immediately after making the deposits or the miner . Sharing some screenshots from Specter. If you look at my screenshots , it contains a data for scripts taken from Sparrow. The receive addresses were signed to recieve but whats the OP 0 for address ending with suns? The address in the 2 inputs were the 2 recieved addresses I got the coins on

Another example transaction: f9ad7ce7df96a2af17260ee13b34e498a913297c77e097beb62e80f5ef8b1575

Using a COLDCARD BRAND NEW - MK4 following all instructions of dice rolls and seeds

I sent all funds from my own ledger live wallet to my cold card wallet [BRAND NEW]. It was a self transfer

You haven’t answered whether it is your address. Do you still control the funds?

Electrum states it’s a second receiving address so I’m just confused how to send now since the consolidated funds sit over there now. The UI is not very clear on how to send when this happens

@Murch I have the private keys for the two inputs linked to the output

Yeah, but that money has been spent already. Did you see that I edited my answer? It is likely that your money was stolen.

https://github.com/spesmilo/electrum/issues/8686#issuecomment-1809471904


text:
Bitcoin core syncing txindex stalls
Bitcoin core bugging out since what I assume was a bad shutdown. Mostly fixed (I think) but stalling trying to resync txindex. Here's the history:

Core wouldn't connect to peers or load the latest blocks - I figured something must have bugged out if shut down incorrectly
I ran -reindex-chainstate which successfully rechecked all block headers. Once this was complete, peers started connecting again and new blocks were being downloaded and synced. Side note: this took ages, a week maybe. I'm running the data directory on an external SSD (Samsung T7) and bumped up the speed to dbcache=4000 (50% of my computer's 8GB RAM)
Wallet couldn't see latest transactions - I tried getrawtransaction and it stated txindex wasn't synced. I checked gettxindex which showed "synced": false. Checked the debug log - txindex script seemed to have stalled, wasn't making any progress
Shut down core - shutdown didn't complete properly, after 30 mins or so I did an 'end task'
Restarting core went ok, and txindex starts syncing. New peers connecting ok, new blocks downloading ok
txindex seems to stall after 10-30mins each time, debug log doesn't show any progress but new peers connecting and new blocks downloading ok
Restarting core seems to restart the synchronising txindex process ok - core still doesn't shut down correctly and needs a force close, and when restarting it runs the synchronise txindex script for a while then stalls again

Any ideas? Any more detailed diagnostics I can run to find out where and why it's stalling? Thanks in advance.
Here's a dump from the debug log:
2023-11-05T20:41:19Z Bitcoin Core version v22.0.0 (release build)
2023-11-05T20:41:19Z Qt 5.12.11 (static), plugin=windows (static)
2023-11-05T20:41:19Z Static plugins:
2023-11-05T20:41:19Z  QWindowsIntegrationPlugin, version 330752
2023-11-05T20:41:19Z  QWindowsVistaStylePlugin, version 330752
2023-11-05T20:41:19Z Style: windowsvista / QWindowsVistaStyle
2023-11-05T20:41:19Z System: Windows 10 (10.0), x86_64-little_endian-llp64
2023-11-05T20:41:19Z Screen: \\.\DISPLAY1 1920x1080, pixel ratio=1.0
2023-11-05T20:41:20Z Assuming ancestors of block 00000000000000000008a89e854d57e5667df88f1cdef6fde2fbca1de5b639ad have valid signatures.
2023-11-05T20:41:20Z Setting nMinimumChainWork=00000000000000000000000000000000000000001fa4663bbbe19f82de910280
2023-11-05T20:41:20Z Using the 'shani(1way,2way)' SHA256 implementation
2023-11-05T20:41:20Z Using RdSeed as additional entropy source
2023-11-05T20:41:20Z Using RdRand as an additional entropy source
2023-11-05T20:41:20Z GUI: "registerShutdownBlockReason: Successfully registered: Bitcoin Core didn't yet exit safely…"
2023-11-05T20:41:20Z Default data directory C:\Users\jonny\AppData\Roaming\Bitcoin
2023-11-05T20:41:20Z Using data directory D:\Bitcoin
2023-11-05T20:41:20Z Config file: D:\Bitcoin\bitcoin.conf
2023-11-05T20:41:20Z Config file arg: dbcache="1000"
2023-11-05T20:41:20Z Config file arg: server="1"
2023-11-05T20:41:20Z Config file arg: txindex="1"
2023-11-05T20:41:20Z Using at most 125 automatic connections (2048 file descriptors available)
2023-11-05T20:41:20Z Using 16 MiB out of 32/2 requested for signature cache, able to store 524288 elements
2023-11-05T20:41:20Z Using 16 MiB out of 32/2 requested for script execution cache, able to store 524288 elements
2023-11-05T20:41:20Z Script verification uses 7 additional threads
2023-11-05T20:41:20Z scheduler thread start
2023-11-05T20:41:20Z HTTP: creating work queue of depth 16
2023-11-05T20:41:20Z Using random cookie authentication.
2023-11-05T20:41:20Z Generated RPC authentication cookie D:\Bitcoin\.cookie
2023-11-05T20:41:20Z HTTP: starting 4 worker threads
2023-11-05T20:41:20Z Using wallet directory D:\Bitcoin\wallets
2023-11-05T20:41:20Z init message: Verifying wallet(s)…
2023-11-05T20:41:20Z init message: Loading banlist…
2023-11-05T20:41:20Z SetNetworkActive: true
2023-11-05T20:41:20Z Using /16 prefix for IP bucketing
2023-11-05T20:41:20Z Cache configuration:
2023-11-05T20:41:20Z * Using 2.0 MiB for block index database
2023-11-05T20:41:20Z * Using 124.8 MiB for transaction index database
2023-11-05T20:41:20Z * Using 8.0 MiB for chain state database
2023-11-05T20:41:20Z * Using 865.2 MiB for in-memory UTXO set (plus up to 286.1 MiB of unused mempool space)
2023-11-05T20:41:20Z init message: Loading block index…
2023-11-05T20:41:20Z Switching active chainstate to Chainstate [ibd] @ height -1 (null)
2023-11-05T20:41:20Z Opening LevelDB in D:\Bitcoin\blocks\index
2023-11-05T20:41:20Z Opened LevelDB successfully
2023-11-05T20:41:20Z Using obfuscation key for D:\Bitcoin\blocks\index: 0000000000000000
2023-11-05T20:41:23Z LoadBlockIndexDB: last block file = 3922
2023-11-05T20:41:23Z LoadBlockIndexDB: last block file info: CBlockFileInfo(blocks=33, size=53851357, heights=815456...815488, time=2023-11-05...2023-11-05)
2023-11-05T20:41:23Z Checking all blk files are present...
2023-11-05T20:41:27Z Opening LevelDB in D:\Bitcoin\chainstate
2023-11-05T20:41:28Z Opened LevelDB successfully
2023-11-05T20:41:28Z Using obfuscation key for D:\Bitcoin\chainstate: dc6979cd4bd813b3
2023-11-05T20:41:29Z Loaded best chain: hashBestChain=0000000000000000000270c62ee0ca93f9c0992a724470e214ceaf6bab585ad4 height=815488 date=2023-11-05T20:37:29Z progress=0.999999
2023-11-05T20:41:29Z init message: Verifying blocks…
2023-11-05T20:41:29Z Verifying last 6 blocks at level 3
2023-11-05T20:41:29Z [0%]...[16%]...[33%]...[50%]...[66%]...[83%]...[99%]...[DONE].
2023-11-05T20:41:51Z No coin database inconsistencies in last 6 blocks (21212 transactions)
2023-11-05T20:41:51Z  block index           30774ms
2023-11-05T20:41:51Z Opening LevelDB in D:\Bitcoin\indexes\txindex
2023-11-05T20:42:17Z Opened LevelDB successfully
2023-11-05T20:42:17Z Using obfuscation key for D:\Bitcoin\indexes\txindex: 0000000000000000
2023-11-05T20:42:17Z block tree size = 815492
2023-11-05T20:42:17Z nBestHeight = 815488
2023-11-05T20:42:17Z txindex thread start
2023-11-05T20:42:17Z loadblk thread start
2023-11-05T20:42:17Z Syncing txindex with block chain from height 616291
2023-11-05T20:42:17Z AddLocal([2a04:4a43:947f:f514:fdcc:b1cc:2ce3:4c78]:8333,1)
2023-11-05T20:42:17Z Discover: Sam - 2a04:4a43:947f:f514:fdcc:b1cc:2ce3:4c78
2023-11-05T20:42:17Z AddLocal([2a04:4a43:947f:f514:392b:e2c3:3462:4c74]:8333,1)
2023-11-05T20:42:17Z Discover: Sam - 2a04:4a43:947f:f514:392b:e2c3:3462:4c74
2023-11-05T20:42:17Z torcontrol thread start
2023-11-05T20:42:17Z Bound to 127.0.0.1:8334
2023-11-05T20:42:17Z Leaving InitialBlockDownload (latching to false)
2023-11-05T20:42:17Z Bound to [::]:8333
2023-11-05T20:42:17Z Bound to 0.0.0.0:8333
2023-11-05T20:42:17Z init message: Loading P2P addresses…
2023-11-05T20:42:17Z Loaded 58287 addresses from peers.dat  110ms
2023-11-05T20:42:17Z Loaded 2 addresses from "anchors.dat"
2023-11-05T20:42:17Z 2 block-relay-only anchors will be tried for connections.
2023-11-05T20:42:17Z init message: Starting network threads…
2023-11-05T20:42:17Z net thread start
2023-11-05T20:42:17Z dnsseed thread start
2023-11-05T20:42:17Z Waiting 300 seconds before querying DNS seeds.
2023-11-05T20:42:17Z addcon thread start
2023-11-05T20:42:17Z opencon thread start
2023-11-05T20:42:17Z msghand thread start
2023-11-05T20:42:17Z init message: Done loading
2023-11-05T20:42:17Z GUI: Platform customization: "windows"
2023-11-05T20:42:20Z New outbound peer connected: version: 70016, blocks=815488, peer=0 (block-relay-only)
2023-11-05T20:42:21Z New outbound peer connected: version: 70016, blocks=815488, peer=1 (block-relay-only)
2023-11-05T20:42:30Z New outbound peer connected: version: 70016, blocks=815488, peer=2 (outbound-full-relay)
2023-11-05T20:42:31Z New outbound peer connected: version: 70015, blocks=815488, peer=4 (outbound-full-relay)
2023-11-05T20:42:39Z New outbound peer connected: version: 70016, blocks=815488, peer=5 (outbound-full-relay)
2023-11-05T20:42:39Z P2P peers available. Skipped DNS seeding.
2023-11-05T20:42:39Z dnsseed thread exit
2023-11-05T20:42:42Z New outbound peer connected: version: 70016, blocks=815488, peer=7 (outbound-full-relay)
2023-11-05T20:42:49Z Syncing txindex with block chain from height 616346
2023-11-05T20:43:00Z New outbound peer connected: version: 70016, blocks=815488, peer=10 (outbound-full-relay)
2023-11-05T20:43:06Z New outbound peer connected: version: 70015, blocks=815488, peer=11 (outbound-full-relay)
2023-11-05T20:43:13Z New outbound peer connected: version: 70016, blocks=815488, peer=13 (outbound-full-relay)
2023-11-05T20:43:16Z New outbound peer connected: version: 70016, blocks=815488, peer=14 (outbound-full-relay)
2023-11-05T20:43:20Z Syncing txindex with block chain from height 616398
2023-11-05T20:43:51Z Syncing txindex with block chain from height 616433
2023-11-05T20:43:58Z New outbound peer connected: version: 70016, blocks=815488, peer=21 (outbound-full-relay)
2023-11-05T20:44:22Z Syncing txindex with block chain from height 616463
2023-11-05T20:44:44Z New outbound peer connected: version: 70016, blocks=815488, peer=22 (outbound-full-relay)
2023-11-05T20:49:39Z UpdateTip: new best=00000000000000000001a9debe40ab106fc7a9328d9d0ae6e39ccfc0302976fb height=815489 version=0x2c1a0000 log2_work=94.521130 tx=914569581 date='2023-11-05T20:49:05Z' progress=1.000000 cache=41.6MiB(289338txo)
2023-11-05T20:49:56Z UpdateTip: new best=00000000000000000001304514a6a3080875bd23ef495d98276fb5c362ee35d8 height=815490 version=0x2217e000 log2_work=94.521144 tx=914573253 date='2023-11-05T20:49:21Z' progress=1.000000 cache=43.3MiB(301523txo)
2023-11-05T20:53:58Z Imported mempool transactions from disk: 52234 succeeded, 415 failed, 0 expired, 20 already there, 0 waiting for initial broadcast
2023-11-05T20:53:58Z loadblk thread exit
2023-11-05T20:58:18Z New outbound peer connected: version: 70016, blocks=815490, peer=25 (outbound-full-relay)
2023-11-05T20:58:25Z New outbound peer connected: version: 70016, blocks=815490, peer=26 (outbound-full-relay)
2023-11-05T20:58:25Z New outbound peer connected: version: 70016, blocks=815488, peer=27 (outbound-full-relay)
2023-11-05T20:58:26Z New outbound peer connected: version: 70016, blocks=815490, peer=28 (outbound-full-relay)
2023-11-05T20:58:32Z New outbound peer connected: version: 70016, blocks=815490, peer=29 (outbound-full-relay)
2023-11-05T20:58:33Z New outbound peer connected: version: 70016, blocks=815490, peer=30 (outbound-full-relay)
2023-11-05T20:59:34Z New outbound peer connected: version: 70016, blocks=815490, peer=31 (outbound-full-relay)
2023-11-05T20:59:41Z New outbound peer connected: version: 70016, blocks=815489, peer=32 (outbound-full-relay)
2023-11-05T21:07:12Z UpdateTip: new best=00000000000000000002ed61af02abb053e53e287ff98f1a9f5898fc9b3edf57 height=815491 version=0x3fff0000 log2_work=94.521157 tx=914576806 date='2023-11-05T21:06:41Z' progress=1.000000 cache=55.9MiB(403631txo)
2023-11-05T21:11:26Z UpdateTip: new best=00000000000000000001754ba92729f0085950aec003537733de92854bfdbc84 height=815492 version=0x24424000 log2_work=94.521171 tx=914578785 date='2023-11-05T21:10:54Z' progress=1.000000 cache=57.3MiB(414237txo)
2023-11-05T21:14:47Z UpdateTip: new best=00000000000000000000bf127ef8c2af5e9bbac6866bf993f2ee5b04530c49ce height=815493 version=0x2e990000 log2_work=94.521185 tx=914582250 date='2023-11-05T21:14:05Z' progress=1.000000 cache=58.6MiB(424487txo)
2023-11-05T21:17:17Z UpdateTip: new best=000000000000000000042045e42d958931fceef136506301ab7801f2ffdbb724 height=815494 version=0x2309c000 log2_work=94.521198 tx=914585717 date='2023-11-05T21:16:50Z' progress=1.000000 cache=60.0MiB(435051txo)

And here's the debug log when I try and shutdown bitcoin core:
2023-11-05T21:30:58Z tor: Thread interrupt
2023-11-05T21:30:58Z addcon thread exit
2023-11-05T21:30:58Z opencon thread exit
2023-11-05T21:30:58Z torcontrol thread exit
2023-11-05T21:30:58Z Shutdown: In progress...
2023-11-05T21:30:58Z net thread exit
2023-11-05T21:30:58Z msghand thread exit
2023-11-05T21:30:59Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat started
2023-11-05T21:30:59Z DumpAnchors: Flush 2 outbound block-relay-only peer addresses to anchors.dat completed (0.01s)
2023-11-05T21:30:59Z scheduler thread exit
2023-11-05T21:31:23Z Writing 0 unbroadcast transactions to disk.
2023-11-05T21:31:23Z Dumped mempool: 0.031262s to copy, 23.6728s to dump
2023-11-05T21:31:23Z FlushStateToDisk: write coins cache to disk (440587 coins, 63659kB) started
2023-11-05T21:31:23Z FlushStateToDisk: write coins cache to disk (440587 coins, 63659kB) completed (0.36s)

then nothing happens so I have to manually end task. Don't know if this is related to the synchronising txindex script stalling
Edit: maybe it's not stalling, but just unbelievably slow. Left running overnight, started at:
2023-11-05T21:46:32Z Syncing txindex with block chain from height 616487
and now on:
2023-11-06T07:33:02Z Syncing txindex with block chain from height 638839
so thats c.2500tx/hr so will take another 3 days to complete. Is that about right? Note I did drop dbcache to =1000 in case it was using too much memory
Thanks


text:
Presign transaction with unconfirmed outputs
I am wondering whether the following scenario is possible. Any help is very appreciated.
Alice and Bob are creating a (taproot) 2-of-2 multisig together. They do not trust each other. They intend to fund the multisig address with 1 BTC each but before they send their Bitcoin to the multisig address, they presign a transaction (the redeem transaction) that spends 1 BTC back from the multisig to each of them. Only when both of them have a copy of this unbroadcasted transaction, will they proceed to fund the multisig.
Is this possible? In order to presign the redeem transaction they would need to know the TXID of the outputs they intend to send to the multisig, correct? So they would need to create their separate funding transactions that go into the multisig and share the TXID with each other (but do not broadcast it yet). Then they construct and sign the redeem transaction. Then they broadcast the funding transactions. Is this possible or am I thinking too complicated?
Also, what if the fee environment changes during this process and one of the funding transactions does not get confirmed? Then the presigned redeem transaction is worthless since using RBF on the funding transaction would change the TXID and thus invalidate the presigned redeem transaction? Is there a way to circumvent that?
Thanks a lot!
EDIT: Here is an example of a situation that describes what I want to achieve. Alice and Bob want to create a venture fund. They do not know in which startup to invest just yet. Of course, they will only invest in a startup if both agree that it is a good investment. So they create a 2-of-2 multisig for this purpose. Before funding it, however, they think about what would happen if the other party disappears or if they will not come to an agreement about where to invest. They could block the others funds indefinitely. Therefore they want to have to option to exit the multisig unliterally to predefined addresses.

I don't think the example in your edit is a good one for chains of presigned transactions. The co-investment could just be a single transaction Alice and Bob craft once they've decided what company to fund. This transaction would spend coins from both Alice and Bob.

Yes, fully agree. It is a contrived example (not a good one at that). But I am still interested whether it is possible to achieve exactly this outcome that I describe above.

Yes it is possible. It is in fact a technique at the core of most trustless protocols on top of Bitcoin. Including the most used one, the Lightning Network.
Regarding the funding transaction confirmation, any secure protocol would wait for it to be sufficiently buried before treating the contract as active. For instance in the case of a payment channel, both parties would wait for confirmations before making payments to each other through the channel.
Indeed bumping the fees of the funding transaction would change its txid. But if both parties cooperate they can just pre-sign another chain of transactions from the new, bumped, funding transaction. If they don't, each party can just RBF ("double spend") their funding transaction. That is, spending any of the coins spent by their unconfirmed funding transaction in another transaction with a higher fee which sends the coins back to themselves (or otherwise makes a payment).

Thanks for your answer @Antoine. The last part with RBF makes sense and I understand it. For the first part, I am not quite sure, I understand. If I wait for the funding transactions to confirm and only then try to collaborate to construct the redeem transaction, I can still be stuck in the multisig. I would need to have a valid redeem transaction before I am willing to even send money into the multisig, or no?

Yes, well that's the scheme you described? If the tx confirms, any party can unilaterally get back their coins. You asked whether it was the same if the transaction does not, which is why i detailed how it's the same in this case.

I think I found the answer to my question in the Bitcoin Lightning white paper. Section 3.1.1 ff explains it very well.
Here is the link: Lightning White Paper


text:
Bitcoin Core HD Wallet v0.13.2 missing confirmed incoming transaction
I made a transaction from my android wallet to my bitcoin core HD wallet (v0.13.2). At the time of writing, the transaction has 5 confirmations, both according to the android wallet and blockchain.info. However, my bitcoin core wallet fails to pick up the transaction, despite showing the right blockchain height.
The recipient address was generated by bitcoin-qt, hence it does belong to my HD wallet. Furthemore, I am able to sign a message with this address on bitcoin-qt (indicating I own the private key) and successfully verify the signature. In fact, in the course of my investigation, I had the unpleasant surprise of realizing that this address had already been generated in the past and I had already sent bitcoin to it as can be seen here. (This seems related to the issue reported in this post but is no longer the most pressing matter now). The older transaction using this address is part of my bitcoin-qt transaction log. So there can be no doubt the recipient address does belong to my bitcoin core HD wallet.
I am reluctant to attempt replicating the issue I have just described with another trial transaction. However, as this is probably relevant, I will explain what I did prior to this happening: 1. I made a copy of wallet.dat and removed the file from ~/.bitcoin (so running bitcoind or bitcoin-qt would automatically generate a new emptywallet.dat). 2. prior to the transaction I restored my copy of wallet.dat into ~/.bitcoin and started bitcoin-qt. 3. I asked bitcoin-qt for a new address and had my android wallet carry out the transaction. 4. I then shredded and removed wallet.dat and restarted bitcoind for a while. 5. When seeing the transaction had been confirmed, I re-instated my copy of wallet.dat into ~/.bitcoin with the intention of performing another transaction. 6. I then re-started bitcoin-qt which fails to pick up the latest transaction.
Note that this process of mine of shredding wallet.dat from ~/.bitcoin (while a copy of the file exists in a more secure location) is something I have just decided to do, as a way of making it harder for any potential hacker to spend the coins on this wallet.
So my bitcoin core wallet is obviously confused. Is there anything I can do to set it straight?
EDIT: When I re-instated my wallet.datinto ~/.bitcoin I am guessing a re-scan was not triggered for some reason. I shredded again my current wallet.dat and re-instated my (older) backup: this time a re-scan was triggered and the missing transaction was picked up.
So this issue is resolved as far as I can see it (albeit with the unease of not knowing why).

Bitcoin Core currently has no internal function to recover a complete wallet. If the key is unknown (not generated yet), Bitcoin-Core will not detect transaction from to to that key/address. Also, the keypool size does not matter at this point, funds sent to a keypool key/address are not detected at the moment.
For now (Bitcoin Core <= 0.14.0), if you restore a backup, make sure you generate plenty of addresses, loop through getnewaddress and ensure you generate 1000 (or more?) keys.
After you did this, restart Bitcoin Core (qt/d) with -rescan
Hopefully we can add some HD restore features for Core 0.15.


text:
Sign a multi-signature transaction with imported address
I have an address with three compressed public keys:
SCRIPT="5221"$(cat compressed_public_key_1.txt)"21"$(cat compressed_public_key_2.txt)"21"$(cat compressed_public_key_3.txt)"53AE"

and I generated a P2SH address from here.
Now, I would like to use a descriptor to sign the multisignature transaction.
Previously, I used:
TX_SIGNED=$(bitcoin-cli signrawtransactionwithkey $TX_DATA '["'$PK1'"]' '[{"txid":"'$TXID'","vout":'$VOUT',"scriptPubKey":"'$SCRIPTPUBKEY'","redeemScript":"'$REDEEM'"}]'  | jq -r '.hex')
TX_SIGNED=$(bitcoin-cli signrawtransactionwithkey $TX_SIGNED '["'$PK2'"]' '[{"txid":"'$TXID'","vout":'$VOUT',"scriptPubKey":"'$SCRIPTPUBKEY'","redeemScript":"'$REDEEM'"}]'  | jq -r '.hex')

and it is still working. However, I want to know if I need to use signrawtransactionwithwallet.
To check this, I attempted:
PK1=`cat compressed_private_key_WIF_1.txt`
PK2=`cat compressed_private_key_WIF_2.txt`
PK3=`cat compressed_private_key_WIF_3.txt`

CHECKSUM=$(bitcoin-cli getdescriptorinfo "sh(multi(2,$PK1,$PK2,$PK3))" | jq -r .checksum)
bitcoin-cli importdescriptors '[{ "desc": "sh(multi(2,'$PK1','$PK2','$PK3'))#'$CHECKSUM'", "timestamp": "now", "internal": true }]'

I could import without any error. But when I try to use:
TX_SIGNED=$(bitcoin-cli signrawtransactionwithwallet $TX_DATA '[{"txid":"'$TXID'","vout":'$VOUT',"scriptPubKey":"'$SCRIPTPUBKEY'","redeemScript":"'$REDEEM'"}]'  | jq -r '.hex')

I get this error:
"error": "Unable to sign input, invalid stack size (possibly missing key)"
I'm using this kind of script for my study notes

Are the PK1 etc private keys or public keys? It won't work without private keys.

private keys, updated the question.

Does the address match exactly? You can use deriveaddresses on the descriptor.

thanks for the reply, no the address is different after using deriveaddresses but the Order of PB during creating the Redeem script is the same

Well if the address doesn't match, it's not a descriptor for the exact output you have, so it won't work. BTW: your  SCRIPT uses the same public key twice.

My fault, even with the fix, I don't have the same address. Maybe the problem could be the PB and PK order?

What is "PB"? Try getaddressinfo on the address that comes out of deriveaddresses; it may tell you what the exact redeemscript is.

You are correct, PB stands for the public key. It now works properly. With deriveaddress, I can observe the correct order of public keys. Perhaps the main issue was the script type with compressed_public_key_2.txt repeated twice. Unfortunately, for study purposes, I cannot attempt to send the transaction with just one signature, as I could with signrawtransactionwithkey. The error message provided valuable insights.


text:
Cannot import multisignature descriptor in Bitcoin Core
I created a multisignature address in regtest:
ADDR_1=`bitcoin-cli getnewaddress "" "bech32"`
ADDR_2=`bitcoin-cli getnewaddress "" "bech32"`
PB1=$(bitcoin-cli -named getaddressinfo address=$ADDR_1 | jq -r '.pubkey')
PB2=$(bitcoin-cli -named getaddressinfo address=$ADDR_2 | jq -r '.pubkey')
ADDR_P2SH_P2WPKH_NATIVE_2=`bitcoin-cli -named createmultisig nrequired=1 keys='''["'$PB1'","'$PB2'"]''' address_type="bech32" | jq -r '.address'`

After that, I generated 101 blocks:
bitcoin-cli generatetoaddress 101 $ADDR_P2SH_P2WPKH_NATIVE_2
Then, I wanted to retrieve the listunspent:
bitcoin-cli listunspent 1 101 '["'$ADDR_P2SH_P2WPKH_NATIVE_2'"]'
However, it returned an empty result. So, I attempted to import the new address using addr():
CHECKSUM=$(bitcoin-cli getdescriptorinfo "addr($ADDR_P2SH_P2WPKH_NATIVE_2)" | jq -r .checksum)
bitcoin-cli importdescriptors '[{ "desc": "addr('$ADDR_P2SH_P2WPKH_NATIVE_2')#'"$CHECKSUM"'", "timestamp": "now", "internal": true }]'

This resulted in an error:
[
  {
    "success": false,
    "error": {
      "code": -4,
      "message": "Cannot import descriptor without private keys to a wallet with private keys enabled"
    }
  }
]

I also tried:
CHECKSUM=$(bitcoin-cli getdescriptorinfo "wsh(multi(1,$PB1,$PB2))" | jq -r .checksum)
bitcoin-cli importdescriptors '[{ "desc": "wsh(multi(1,'$PB1','$PB2'))#'"$CHECKSUM"'", "timestamp": "now", "internal": true }]'

But encountered the same result.
Another attempt is
bitcoin-cli -named createwallet wallet_name="bia" disable_private_keys=true
CHECKSUM=$(bitcoin-cli getdescriptorinfo "wsh(multi(1,$PB1,$PB2))" | jq -r .checksum)
bitcoin-cli -rpcwallet=bia importdescriptors '[{ "desc": "wsh(multi(1,'$PB1','$PB2'))#'"$CHECKSUM"'", "timestamp": "now", "internal": true }]'
bitcoin-cli -rpcwallet=bia listunspent 1 101 '["'$ADDR_P2SH_P2WPKH_NATIVE_2'"]'

it's still empty

You're passing "timestamp": "now", implying that the address was only created now, so no rescanning of history will take place. You need to either explicitly rescan, or set the timestamp to a value before the first transaction to that address took place.

thanks for the reply, I need to create a new wallet and use -rpcwallet ? Because with other method I get the error about private keys

With descriptor wallets there doesn't exist a distinction between watch-only addresses and full addresses in the wallet anymore. Instead, the whole wallet is either watch-only or full.

you are right I can scan before mine the blocks and I can find UTXO available, but I need to create a new wallet with disable_private_keys=true? Only my last attempt work. in that way I will have a problem during the signrawtransactionwithwallet

If you want to be able to sign you'll need to have the descriptor with private keys imported.

yes, but I can retrieve the Private key if I use getnewaddress? I can't use dumpprivkey anymore. I'd like to use only Bitcoin-cli not an external tool

You can use listdescriptors to get the xprv of a wallet (set the flag to get private keys) and use those. You shouldn't need createmultisig anymore. Descriptor wallets generally don't have/use WIF keys anymore, unless you import them.

"You shouldn't need createmultisig anymore" because I should use wsh(multi) descriptor after retrieving the Xpriv -> Private key?

Yes, descriptors can do everything createmultisig can (and far more).

Okay, thanks. So, if I want to use a multi-signature address, I need to create the multi using private keys and descriptor instead of using createmultisig if I also want to sign the transaction.

There is even documentation on that topic: https://github.com/bitcoin/bitcoin/blob/master/doc/multisig-tutorial.md

Thanks Pieter, I followed the tutorial and it works. Understand a lot of new things. Thanks again for your time


text:
How is the "N" in PPLNS chosen? 2xDiff appears to make no sense - OR - Why are Scrypt share difficulties off by a factor of 65536?
while my example in the following question is using the altcoin "Bitconnect", I believe it is actually a general question which fits here - if not, let me know.
I am struggling to understand PPLNS (I need to implement it in a pool). I know in general how the system works, but what is a mystery to me is where the N comes from.
I read on many places on the Internet that N = 2 * difficulty is a good value, and that this would mean that on average a miner will earn rewards from two blocks for the same shares.
However, it simply does not add up for me.
Practical example: BitConnect pool. Let's say BitConnect's difficulty is currently ~900,000.
An AntMiner L3+ submits a share at difficulty ~150,000 (which counts as a share value of 150,000 then) every ~15 seconds, so in 3 minutes, that one AntMiner has already filled the whole "N" of 900,000x2=1,800,000. That would, in reverse, mean that I would expect to mine a BitConnect block every 90 seconds on average, with one AntMiner, which is of course not true.
100 AntMiners running on our pool gave a share value of 230,000,000 in the last 5 minutes, which would have been more than 100 times the whole "N" already!
So something can't be right here, and I don't understand what. Should I not multiply the submitted share with the work difficulty? But then a small miner would get the same reward as a large one which makes no sense. Or is the whole Internet wrong about the 2*diff for "N", and that it's based on the assumption that it takes on average a value of shares equal to the difficulty to find a block? Doesn't sound likely.
On average, it takes 2^32 hashes to find a valid share at difficulty 1, right? And on average, it takes X shares to find a share at difficulty X, hence why you increase the difficulty at the pool for your miner if the miner is powerful (it will then less often submit a share), right...? But the last point starts to make less sense already, together with the fact that you need a share at difficulty Y to find a block if the currently coin block difficutly is Y... And the pool software counts a share with difficulty X the same as X shares with difficulty 1. At the end I'm left confused how it all works together and how I can arrive at a value for "N" which actually results in a miner getting on average two rewards for the same share...!
Please help me understand what is wrong.
EDIT: I found that all calculations differ from reality by a factor of 2^16. Then I found this: https://bitcoin.stackexchange.com/a/11816/62320
This would suggest that for Scrypt, pools use a scaled "share difficulty" value by exactly that factor, but the reported block difficulty would not be scaled. This would explain everything but it's the only place I found this on the Internet (and it would mean that I need different calculations depending on the algorithm I'm handling) - can anyone confirm this?

I found the reason for this confusion myself now:
It was very confusing and took a while to understand, especially because this information is not easily obtainable when researching on the Internet (without already knowing the answer in order to know the right keywords - forum threads didn't help either).
It seems like there are algorithms, Scrypt is one of them, which use a scaled value for share difficulty.
Let me explain:
For Bitcoin (which is SHA-256), the following applies:

A hash is a "try" to find a certain solution
On average, you need 2^32 (~4 billion) tries to find a valid "share" (originally this was the only type of share in existence, which has difficulty 1, but by now, all pools use shares with difficulties higher than 1, see below)
If the coin difficulty were 1, this would be a valid block
With a coin difficulty higher than 1, let's say N, on average only 1 out of N such "valid shares" (with difficulty 1) get you a valid block
Recap: for coin difficulty N, you need on average N*2^32 hashes to find a block
Therefore, a formula to know how many seconds on average it takes to find a block with a certain hashing power is "average time = difficulty * 2^32 / hashrate"
When mining pools are concerned, pools accept only shares with difficulty >N, and 1 share with difficulty N is counted the same way as N shares with difficulty 1 (or N/2 shares with difficulty 2*N, etc.) - that's the pool difficulty
This also means that with an N=2*coindiff in PPLNS, like most pools do, on average, the last "N" shares in the "PPLNS" cover 2 blocks

OK, so I tried to apply this info to Scrypt, because when researching things like Litecoin difficulty, the formulae I found were the same, e.g. "average time = difficulty * 2^32 / hashrate", and that on average you need 2^32 hashes to find a difficulty-one share, etc.
However it didn't make sense, everything was far off from what I saw on our mining pools.
In fact, it turned out that it was off by a factor suspiciously close to 2^16.
Further research and testing finally gave us the answer that for Scrypt, by convention, pools and miners scale the share difficulty value by a factor of 2^16.
But only the pools and the miner software (e.g. cgminer)! the network difficulty is still displayed without scaling!
Example:
Let's say the network difficulty is 900,000 for BCC (Bitconnect Coin)
In the original calculation, I would assume that it takes on average 21 hours at a hashrate of 50 GH/s to find a block (900k * 2^32 / 50G = ~77k seconds = ~21 hours), which is about right when looking at our pool.
However, I would then also assume that it takes a total value of shares of around 900,000 (exactly the network difficulty), however that's not true, because one AntMiner L3+ alone already submits a share with diff of ~150,000 every ~15 seconds, so I would assume that it finds a block every 90 seconds, which is of course not true (it's closer to 90 days than to 90 seconds).
And here is the issue: for Scrypt, share difficulty is measured with a value mulitplied by 65,536!
So, in fact, the "difficulty 150,000" which the pool uses with the AntMiners is actually 150,000/65,536 = 2.29
And, this means that in order to get to that coin difficulty value of 900,000, the pool needs to display a total value of shares of 900,000*65,536 = 58,982,400,000!
Then, everything suddenly makes sense again.
There are also other algorithms which use such a scaling factor. In fact, I found that the UNOMP pool software already has a file which also contains these values: https://github.com/UNOMP/node-merged-pool/blob/master/lib/algoProperties.js (look for multiplier). For SHA-256 it's 1, for Scrypt it's 2^16.
According to pieces of information scattered throughout the Internet, this was done because Scrypt is a more difficult algorithm per se, which resulted in pools accepting shares with difficulties smaller than 1, and to avoid issues with the fact that difficulties and share values could suddenly be non-integral, the whole number was scaled so that the unit "difficulty 1" now actually meant 2^(-16).
So, rule of thumb:

Whenever you see a difficulty value in context of a miner or a pool for Scrypt, you need to divide it by 65,536 if you want to compare it with other numbers like the overall coin difficulty.
For coin/block difficulty values (even in Scrypt), and in general for SHA-256 or X11, don't divide it. For other algorithms, look it up (for example, Blake uses 2^8).

An AntMiner L3+ submits a share at difficulty ~150,000 (which counts as a share value of 150,000 then) every ~15 seconds, so in 3 minutes, that one AntMiner has already filled the whole "N" of 900,000x2=1,800,000. That would, in reverse, mean that I would expect to mine a BitConnect block every 90 seconds on average, with one AntMiner, which is of course not true.

I don't think that is how shares are counted. According to this Bitcointalk post,

When a share is submitted, assign to it a score of 1/D, where D is the difficulty at the time the share is submitted.

So in your scenario, when your AntMiner L3+ submits a share, that share is assigned a score of 1/900000, so its "share value" is 2, not 150000.

But that is only to compensate for network difficulty changing over tone, isn't it? And of course the answer your mention is based on bare shares with difficulty 1, so in my case it would be 150000/900000, giving 0.17, how do you get to 2 in your answer?

And then how come the difficulty gets squared? This sounds strange. I mean, saying that a diff 1 gives 1/900k, and the N is still 2x900k, meaning that you need 2x(900k^2) diff 1 shares - doesn't that square there feel a bit out of place?

What makes you think my answer is based on shares with a difficulty of 1? At no point in the post I linked to is difficulty of 1 suggested or mentioned. The squared is for variance (the statistical term), which is the square of standard deviation. Variance is not part of the calculation that you want to look at.

I meant that the forum post you linked is using the term "share" as "share diff 1". A share with a higher difficulty must have an equally higher value...

In fact, after doing various calculations, it seems everything is off from reality by a factor of 2^16, as if N2^16 (instead of N2^32) hashes would give you a share with difficulty N... I don't understand yet why, though

I found this now: https://bitcoin.stackexchange.com/a/11816/62320 - does this mean that pools show a scaled difficulty value for Scrypt, but for other algorithms it's different, and the block difficulty is confusingly not scaled?

@CherryDT: The linked post does assume that share difficulty is 1, but that is easy to fix - instead of assigning a score of 1/D, you assign a score of d/D where d is the share difficulty. I'm not completely sure I understood the rest of your questions, but I highly recommend you read https://bitcoil.co.il/pool_analysis.pdf before starting to implement reward methods. It should either answer your questions or give you the background to ask more focused ones.

@MeniRosenfeld: Yes, true, that's what I meant in my example in my comment above. The rest of my questions is already answered by myself, see the other answer in this thread. Thanks for your link, though!


text:
Bitcoin-cli does not connect to bitcoind and cant execute commands no matter what
I have: server=1 daemon=1 in the config, bitcoind running as user as well as bitcoin-cli, no special config or anything - when I try to use bitcoin-cli it wont connect to 127.0.0.1:8332, bitcoind is synced to tip and running fine, what's wrong? Do I need to configure something regarding firewalls manually?
Full config:
proxy=127.0.0.1:9050
bind=127.0.0.1
listen=1
listenonion=1
server=1
daemon=1

./bitcoin-cli getblockchain
produces
error: timeout on transient error: Could not connect to the server 127.0.0.1:8332 Make sure the bitcoind server is running and that you are connecting to the correct rpc port.

Please update your question with the exact commands you are running, and the output you see.

Done sorry about that

How do you start bitcoind, and does anything appear in the debug.log?

I start bitcoind with a systemd service, the config for that I have is here https://github.com/bitcoin/bitcoin/blob/master/contrib/init/bitcoind.service but obviously to replace basic info such as user/group, datadir, etc. The daemon itself is functional and synced to the tip, sitting int he debug.log I can see it's working as intended.
I just cannot connect to the daemon with bitcoin-cli for some reason

If it's relevant I'm using debian12, it was just a fresh install out of the box, I don't have anything custom on the machine. The only thing different would possibly be my exfat externalhdd that is mounted as user:user to match it running with the running user for bitcoind

What port(s) does netstat -ltnp (run as the bitcoin service user, or as root) show bitcoind to be running on?

It wasn't installed on debian12 ootb but I installed net-tools and netstat -ltnp shows that it's listening on 8333/8334 for tcp connections, I tried bitcoin-cli -rpcport=8333 getblockchaininfo but that doesn't seem to work either
(The new error with the above command is: error: timeout on transient error: Could not connect to the server 127.0.0.1:8333 (error code 1 - "EOF reached") Make sure the bitcoind server is running and that you are connecting to the correct rpc port.)

Clearly bitcoind is not listening on the RPC port. Is there any indication in debug.log? Normally you'd expect a line like "Binding RPC on address 127.0.0.1 port 8332". Is there anything of the sort? Also feel free to just update your post with whatever you see in debug.log. 8333 and 8334 are the P2P ports; they won't work for RPC.

I do not see anything regarding binding RPC on address 127.0.0.1:8332. I have included the debug log here which you can view: https://litter.catbox.moe/2cdfas.txt

"Setting file arg: server = false", you have the RPC server disabled (in settings.json, I suspect).

Thanks you so much now it works as long as I provide the -datadir argument with bitcoin-cli. But I'm confused, I thought bitcoin.conf takes precedence over everything, so shouldn't server=1 force it to listen? I'm not really sure what settings.json is for or why there's a separate setting file, would you kindly elaborate? You the man though :D

settings.json takes precedence over bitcoin.conf. The difference is just that settings.json is modifiable by Bitcoin Core itself (e.g. the GUI).

Aha good to know thanks a lot man, I feel silly

The issue is that you have a settings.json file with "server": false, disabling the RPC server. This file takes precedence over bitcoin.conf.


text:
How to generate private key from 24-word mnemonic phrase? (Native Segwit)
When Googling, entire first page consists of people linking to online "calculators" (no thank you) or outdated bip39 code which no longer works. I have a 24 word seed phrase (from ledger live), and I need to turn it into a private key so that I can import it into electrum. How can I do this (locally)?

Why do you not want to restore the wallet from the seed phrase selecting BIP39 in step 4? Thats the usual way to generate all the private keys.


text:
Is ByteTrust and legit company
I would like to know if ByteTrust is legit! I have ask for a withdrawal from my account since 01/05/2024.  First they ask for a deposit of 20% of the total sum (which I submitted) in order to take the money out (they say will be return to me once I get the funds.)  It is 03/30 today and now they want a 5% miner fee before I can get my funds. My question is this a scam to extract more money from me?  Should I give them the 5%.  Need Help?
Chino


text:
How to configure port forwarding to run Full Node with Bitcoin Core using VPN instead setting up port forwarding on router?
I'm running full node with Bitcoin Core, but unable for incoming connections due possible block of my ISP, port forwarding on router doesn't take effect.
Then I created a VPN on Proton VPN service and I user OpenVPN for extending capabilities of free plan, Port Forwarding is one of those benefits in make use of Proton VPN Free Plan with OpenVPN.
I have VPN working, so I have another the IP as my public IP. The VPN IP is detected by bitnodes, and I use iptables to create port forward rules, since I'm using Linux operating system.
I using these commands:
$ sudo iptables -t nat -A PREROUTING -p tcp -i [interface-name] --dport 8333 -j DNAT --to-destination [IP]:8333
$ sudo iptables -A FORWARD -p tcp -d [IP] --dport 8333 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT

Does anyone have setting up full node for incoming connections in this scenario?
Which IP that I must use in those commands? Must be the VPN IP, am I right?
And about the interface name, I use that NAT adapter.
I think the problem of incoming connections are still blocked is the iptables rules. But I want also confirm if is a valid scenario: make port forwarding using VPN instead in the router.

After After suspecting that my ISP did not block the ports and try to open ports or make port forwarding in common software that serves as a firewall for linux like iptables, ufw (a frontend for iptables), I decided to investigate what is the default firewall solution for my Linux distribution, so after identifying the correct firewall and adding rule to TCP port 8333 it finally worked.
If you running a bitcoin full node on a Linux distro and want to allow incoming connections to contribute to the network:
1 - Search on your Linux distro documentation the default firewall
2 - Add Rule for port 8333, using TCP protocol on the official firewall of your distribution
3 - Watch the information tab or Peers tab of your node, or queries that information from command line, and make sure there are more than 10 connections, the excess are incoming connections


text:
Is P2SH-wrapped P2PKH possible?
There is a known form of address that called P2SH-wrapped SegWit, wrapping SegWit address as Base58 (P2SH) address.
Thinking about such address type, I come up with the question: Is P2SH-wrapped P2PKH possible?
I know that it is completely useless and meaningless, but I want to think about it now.
Step 1: Decide an address to convert
Let's use the address 1CciesT23BNionJeXrbxmjc7ywfiyM4oLW as it is used as a sample here.
Step 2: Convert it into "output script", then hash it using "hash160"
I got OP_DUP OP_HASH160 7f6ab65fa911f558ca2dde3e9d073acb02c0d5c6 OP_EQUALVERIFY OP_CHECKSIG.
Hashed result is c852ac34a1c76b63a279c97502c9ccc4e3cb9e8b.
Step 3: Make P2SH address from hashed script
toBase58Check(c852ac34a1c76b63a279c97502c9ccc4e3cb9e8b, 5) = 3KxE77EHe1ip6WGRifwr9fZ5WBDGsLyWFz
The result 3KxE77EHe1ip6WGRifwr9fZ5WBDGsLyWFz is what I want.
Here is the code to reproduce this address generation.
Question
Is that possible to spend coins sent to 3KxE77EHe1ip6WGRifwr9fZ5WBDGsLyWFz (P2SH-wrapped P2PKH address), like how we spend coins sent to P2PKH addresses?

It's definitely possible and you've done the nesting correctly.
Also, aside from being "useless and meaningless", it's more expensive since the scriptSig for redeeming outputs sent to this address will have to contain the 26 bytes of the redeemScript (the p2pkh script itself) and the push operation of it, along with the public key and signature.