text:
Mt.Gox API v2 with C# - authentication problem 403
I'm trying to access the Mt.Gox API v2 via C# and HTTP requests. I've put together the following code based on various examples I found online (e.g. the nitrous documentation).
private string MakeRequest(string apiCall)
        {
            var parameters = new Dictionary<string, string> ();
            parameters.Add ("tonce", Tonce.GenerateTonce().ToString());

            string path = Currency + "/" + apiCall;

            var request = new HttpPostRequest(BaseAddress + path, parameters);
            request.Request.Headers.Add ("Rest-Key", mApiKey);
            request.Request.Headers.Add ("Rest-Sign", mHmac.Sign(path, request.GetEncodedPostParams()));

            var response = request.Request.GetResponse();
            return response.ToString ();
        }

(Here HttpPostRequest is a rather simple wrapper around the .NET HTTP request)
I call the code like this:
MakeRequest ("money/info");

This leads to a 403-Error from the Mt.Gox server (access denied).
What I checked:

Tonce is generated correctly
HMAC signing works correctly (tested with nitrous example)

And here is the code for my HTTP Post Request class:
public class HttpPostRequest
    {
        public HttpWebRequest Request { get; set; }
        string mPostParams;

        public HttpPostRequest (string url, Dictionary<string,string> postParameters)
        {
            mPostParams = "";
            foreach (string key in postParameters.Keys)
            {
                mPostParams += Uri.EscapeDataString(key) + "="
                          + Uri.EscapeDataString(postParameters[key]) + "&";
            }

            if(postParameters.Count > 0)
                mPostParams = mPostParams.Substring (0, mPostParams.Length - 1);

            Request = (HttpWebRequest)HttpWebRequest.Create(url);
            Request.Method = "POST";

            byte[] data = Encoding.ASCII.GetBytes(mPostParams);

            Request.ContentType = "application/x-www-form-urlencoded";
            Request.ContentLength = data.Length;
            Request.UserAgent = "Mozilla/4.0 (compatible; MtGoxTradeCLI)";

            Stream requestStream = Request.GetRequestStream();
            requestStream.Write(data, 0, data.Length);
            requestStream.Close();
        }

        public string GetEncodedPostParams()
        {
            return mPostParams;
        }

        public string Send()
        {
            HttpWebResponse myHttpWebResponse = (HttpWebResponse)Request.GetResponse();
            Stream responseStream = myHttpWebResponse.GetResponseStream();
            StreamReader myStreamReader = new StreamReader(responseStream, Encoding.Default);
            string pageContent = myStreamReader.ReadToEnd();
            myStreamReader.Close();
            responseStream.Close();
            myHttpWebResponse.Close();
            return pageContent;
        }
    }

And my HMAC class:
class HmacSigner
  {
    private readonly string mSecret;

    public HmacSigner(string secret)
    {
        mSecret = secret;
    }

    public string Sign(string method, string postData)
    {
        string message = method + '\0' + postData;
        HMACSHA512 hmac = new HMACSHA512(Encoding.Default.GetBytes(message));
        hmac.Key = Convert.FromBase64String(mSecret);
        return Convert.ToBase64String(hmac.ComputeHash(Encoding.UTF8.GetBytes(message)), Base64FormattingOptions.None);
    }

Does anyone have an idea what's going wrong here? Why is my authentication not working?
Thanks!

Btw: the error message from Mt.Gox also says that the Rest-Key is missing. I'm not sure what that means since I'm adding the Rest-Key to the request headers as shown above...


text:
Where is the revelead public key in a spending transaction?
I am pursuing a deeper understanding of Bitcoin. Reading Grokking Bitcoin now. I am trying to asess the understanding of different concepts by exploring a BTC RPC explorer. I got some understanding about the key types and keys structure and key derivation in hierarchical deterministic wallets.
The book says: the PKH (double hashed from public key) is used in order to not reveal directly the public key (for better privacy), but then the public key gets revelead in the spending transaction.
In this screenshot of a random transaction I see only BTC addresses (bc1q) derived from PKH. Where is the "revelead" public key?
I am quite sure I misunderstood something.

What you show in your screenshot is some program's summary of a transaction which omits details of the spending script. You need to look at a more detailed view of the raw transaction data.
There are several types of Bitcoin transaction. The type known as Pay to Public Key Hash (P2PKH) requires that the recipient reveal their public key in a later transaction where they spend the received money.
There are several places that explain this. One is https://learnmeabitcoin.com/technical/p2pkh

The P2PKH script pattern contains a hashed public key surrounded by these opcodes:
scriptPubKey:
OP_DUP OP_HASH160
12ab8dc588ca9d5787dde7eb29569da63c3a238c OP_EQUALVERIFY OP_CHECKSIG

To solve this script, the owner of the hashed public key above needs to provide the original public key, along with a valid signature for it:
scriptSig:
304502203f004eeed0cef2715643e2f25a27a28f3c578e94c7f0f6a4df104e7d
163f7f8f022100b8b248c1cfd8f77a0365107a9511d759b7544d979dd152a955
c867afac0ef78601

044d05240cfbd8a2786eda9dadd520c1609b8593ff8641018d57703d02ba687c
f2f187f0cee2221c3afb1b5ff7888caced2423916b61444666ca1216f2618139
8c

In short, when this script runs:

The original public key is DUPlicated and then HASH160’ed.
This hashed value is compared with the hashed public key in the scriptPubKey to make sure it is EQUALVERIFY.
If it matches, the script continues and the CHECKSIG checks the signature against the public key (just like a P2PK script).

Note that the locking script is only present in the transaction in which a person received this money. The transaction in which they spend the received money has a reference to the earlier transaction and contains a spending script that is prepended to the earlier transaction's locking script and then evaluated.
The transaction you show is a P2WPKH which is a little more complex and has some advantages over P2PKH.

source: Stack Exchange

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

sort: votes


text:
Unconfirmed translation
I sent 1500 from my wallet address last 2weeks transaction faild to confirm transaction id
1624600252fd611c8d07ae4f6a7922850ea52014d93265fa7340979e8fd55647

For the next time:
Start using a wallet that uses native SegWit addresses bc1.... If you had been spending from a bc1 address and had paid the same feerate your transaction would have confirmed instantly.

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


text:
Are there any privacy benefits in using a separate wallet in Bitcoin Core to separate myself from my service?
I currently run Bitcoin Core with the following wallets loaded in:

hot.dat. Contains the smallest possible sum of Bitcoin. Unencrypted and used by myself for various personal Bitcoin purchases, and I intend to have it double as the wallet for my Bitcoin-based website. (Unless you tell me a good reason not to.)
lukewarm.dat. Contains more than the "hot" wallet, but still not much compared to cold.dat. Encrypted with a long passphrase, but which is located on the same computer in a text document. I recon that it will stop at least automated malware which simply checks for wallet.dats and merely "sends them home". It of course won't stop somebody from manually finding the text document on my machine and figuring out that it's the passphrase to use.
cold.dat. Contains the vast majority of my satoshis. Encrypted with a long passphrase (partially stored on the same computer) with a bunch of additional parts with "hints" to myself rather than explicitly spelled out. This passphrase has never been entered to unlock the wallet outside of the dedicated Linux computer where it was created. (Not this machine.)

I'm aware that many would not consider my cold.dat to be a "cold wallet", but I thought the naming scheme fit well enough. The reason I don't use a truly "cold" wallet (where it's not stored on a "live" computer even encrypted) has to do with me fearing losing the file or having a fire or getting it seized more than I fear somebody first hacking into my machine and then somehow figuring out my complicated passphrase scheme. I consider that so unlikely that it is far more likely that I would lose access to it in other ways.
Now I wonder if I should be having a separate "service.dat" wallet dedicated to my new service, or if I can just generate new receive addresses for my existing hot.dat and use those. Is there any privacy benefit in me doing that? Or would I just be wasting yet another transaction fee to send over some satoshis from my hot.dat to my potential "service.dat"?
What if somebody who I do private business with knows who I am (because I have to give them my home address) and when I've paid them using hot.dat, those "inputs"/"outputs" are reused for my service, and suddenly they can associate me, the individual, with my service? And would that change at all if I used a separate "service.dat" wallet for the service? Won't it be the same "track" either way?
It's not something illegal or immoral. I'm simply trying to avoid any association between myself and the service, plus I'm also curious about this in general.

Yes, it's good practice to use different wallets for different mental entities that you don't want associated. Two different wallets cannot be linked from blockchain data alone.
However, that doesn't mean they couldn't be associated by different means, say someone seeing you use both of them, or monitoring transactions that are first relayed by your node.


text:
Old Electrum wallet, encoded text document and non-functional seeds
I am trying to recover an old Electrum wallet that I used to use to buy "things" in college, circa 2016 or so. I remember having 10 to 30 dollars left in it back then that I never thought about until recently. Now it might be worth a couple thousand.
I managed to recover some data from an old, crashed hard-drive which included a text file titled BCwallet. This file appears to contain information about my wallet in a format that appears similar to a JSON or CSS file, but it's mostly random numbers and letters. For example the file starts off with
{
    "accounts": {
        "0": {
            "change": [
                "03522bfc10eab4e91d310b0825c4f50e297c64b991d8e320d2dd96528d9a64df6b",...

The file does have headings "seed" and "Master private key," but these are followed by the same encoded nonsense.
Does anyone recognize the format of the above string and how I could convert it to something readable?
With some digging I managed to find an old notebook from that era with info that I recognize as relating to these endeavors. This includes two 13 word strings (seeds were 13 words back then). I vaguely remember jotting them down when I created my wallet, and having to try again for some reason, thus having two. Both strings only contain words available in Electrum's seed creation dictionary.
Anyway, I tried using these to recover my old wallet via this guide. For one of the seeds, when I get it all entered the "next" button lights up, I click it, and it opens an empty wallet with no transaction history, even after switching servers. For the other seed the "next" button stays grayed over and is not clickable. I have checked spelling 100%. These were both originally Electrum created seeds and should not be BIP39, though I have tried that without luck as well.
I can feel I'm on the cusp of a nice little payday. Does anyone have any ideas of what else I could try with the information I have?
Thanks a ton for any help!

Nevermind. I just opened the text file through electrum's menu and it opened my old wallet!


text:
How to handle a ridiculous amount of receiving addresses?
By ridiculous I mean something absolutely absurd. 1 million+ addresses. Like say if Amazon had started to accept payments, how could they possibly keep up? Bitcoind probably can't keep up? How would I go about solving this? How does SatoshiDice or Blockchain deal with this?

No of bitcoin addresses doesn't matter. Even a simple computer / laptop / smartphone can handle billions of addresses.

There's absolutely nothing you need to do per address, so the number of addresses has no effect. You only need to process each transaction.

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


text:
What happens to the public and private keys after a transaction? Specifically, how (and why) do they change upon payment?
Feel free to answer/address as many of these topics as you like:
In particular, I am interested in how bitcoins can be stolen, e.g., the 2016 Bitfinex hack. If I am not mistaken, the only way to steal bitcoins is to obtain the individual's private key. What I do not understand is how and why the public and private keys change after each payment. Is this because the private key is needed to verify the payment, thus, once verified, a new one must be generated as the previous one is now known by others? How are new keys generated - by the miners, or something else? Are they related to the previous keys in any way?

TL;DR: Private and public keys never change by themselves. It is wallet software that chooses to rotate them.
Every private key gives rise to exactly one public key, which corresponds to one(*) address. The flow generally is:

Receiver Roy creates an address:

generates a private key d
computes the public key P for d
computes the address A for P
gives the address A to the sender Sue

Sender Sue sends money to Roy

constructs a transaction T1 that sends to A, using her private keys

Roy wants to use the money sent to A to pay merchant Mary:

Roy constructs a transaction T2, which refers to T1's payment to A, and sends to an address received from Mary, and signs it with private key d.

Roy can choose to use the private key d multiple times, by giving out the address A for multiple intended incoming payments. Spending the money received from those payments would then involve signing multiple transactions with the same private key d.
While there is no technical reason preventing this practice (called address reuse), it is strongly discouraged for privacy reasons. The address A is visible on-chain, and thus reuse would help those Roy transacts with correlate the different payments with each other. Because of this, most (but not all) wallet software will show every receiver address just once.
This is purely a decision by the receiver's wallet. Due to how Bitcoin's transactions and addresses work, there is no financial benefit to using a new address for every transaction as opposed to reusing the same every time. Fees do not depend on whether the address was reused or not.
Most modern wallet software derives the different private keys d1, d2, ... using a key derivation algorithm, from a single seed or master key. That means the wallet only needs to (securely) store one piece of information from which all keys can be derived. However, while all keys come from the same seed, the public cannot infer this anymore from the corresponding addresses. Common standards for this derivation include BIP32 and BIP39.
(*) It is possible to generate multiple addresses from the same public key due to Bitcoin's script system, though not in a way that really matters for this answer, as such addresses can still be correlated to each other. E.g. it is possible to construct P2PKH, P2WPKH, or P2TR addresses from one key, corresponding to different script technologies. Typically wallets will just use one of these, however.
Disclaimer: I'm the author of BIP32.

Thanks for your response. Do you happen to know of anywhere to read more about this?


text:
How does the bitcoin network difficulty syntax work?
So, essentially what my question is what does the "syntax" of a bdiff (bitcoin target difficulty) look like? I know that its a number, i.e the current network difficulty is set at around 27Trillion. Your node must output an SHA256 hash below that target.
However, mathematically speaking, how does an SHA256 hash, i.e: 58a57cbaefb39229b8bb7f7f5ba4dae105cd4a75aa1cd72873ee74fdb323a201, have a value higher or lower than 27Trillion, which is what the bdiff is configured to.
Is the network difficulty really just a number, i.e 27Trillion, or is it also a 256-bit hash/number of some kind that would be more comparable?

The difficulty, the target and the hash value are all integer numbers. They can all be compared numerically in much the same way we can compare three and seven.
Since these are large numbers it is more convenient to use a more compact representation of the number when displaying the number. Just as base-16 (hexadecimal) is a more compact way of writing a number than base-10 (decimal). So the network target is transmitted in a compact representation known in the Bitcoin context as the "bits" representation. But the choice of representation doesn't affect the fact that these are just integers and can be compared to other integers in the usual ways that large integers are compared. I think of the "bits" representation as being a little like writing down a number rounded to the nearest thousand or a little like writing down a number as three significant digits and an order of magnitude. You lose some precision but the result is still useful.
The difficulty is a kind of inverse of the target. The larger the difficulty, the smaller the target. The target is a number that is adjusted every 2016 blocks using relatively simple arithmetic. It is not the result of hashing.
The hash is produced by an algorithm that I wouldn't characterise as simple arithmetic but it is still just an integer value. One whose value cannot be predicted more easily than by performing the hashing operation and whose results do not follow a predictable pattern and which are uniformly spread through the range of possible results. Those characteristics make it useful.
So to take your example

how does an SHA256 hash, i.e: 58a57cbaefb39229b8bb7f7f5ba4dae105cd4a75aa1cd72873ee74fdb323a201, have a value higher or lower than 27Trillion

Consider

The number three is the number 3. They are the same number written down in two different ways.

Similarly

The number 58a57cbaefb39229b8bb7f7f5ba4dae105cd4a75aa1cd72873ee74fdb323a201
is the number 40095921297356466623732964073191944615316514476168542186617738139837166494209. They are the same number written down in two different ways.

The number 27 Trillion is the number 27000000000000. They are the same number written down in two different ways.

The first step in comparing two numbers which are represented two different ways is to convert them both into the same representation. We choose any representation that will make a subsequent comparison easier for us.
We can immediately see that 40095921297356466623732964073191944615316514476168542186617738139837166494209 is a larger number than 27000000000000.
We need to be careful to compare the hash with the target and not with the difficulty.


text:
Where are signatures stored in segwit, and why are addresses different?
So I'm researching SegWit, and as far as I'm aware, it re-organizes the data structure of transactions so that the ECDSA signature is not included in the preimage of the Tx Hash.
I am also aware that it doesn't even store the ECDSA on the blockchain. But where is it even stored then and how do nodes check for the signature when validating transactions?
Additionally, why does SegWit incorporate new address formats? I can't seem to understand how this would relate to changing the Tx Structure by moving the EDCSA's somewhere else.
All answers appreciated.

Addresses are shorthand for output scripts, and instruct senders how to lock funds for the recipient. Since segwit outputs use different output scripts than non-segwit outputs, we need a different shorthand for them.
For segwit transactions, the signature data is part of the witness section of the transaction.  The witness is part of the transaction and the whole transaction gets written to the blockchain. While the witness is not used to calculate the txid, it is part of the "witness txid" which is generated from the whole transaction. The latter is used to construct the witness commitment in the coinbase transaction which ensures that witnesses are immutable after a transaction is confirmed.

so addresses contain script conditions for an output? I thought that script conditions were always placed as a separate section of a transaction, and didn't have relation to the generation of an address.
As for the storing of signatures under segwit, so basically the signature is still stored IN the transaction, but it isn't hashed as part of the TxID. Instead, theres a secondary ID called a "Witness TxID" which covers the whole Tx PLUS the signature included. (Meaning that witness ID is subject to malleability)
But then how does SegWit optimize Tx weight? Doesnt the Tx size increase

Also, I heard that the field in the transaction where the signature would have been is now left empty if a segwit tx (well- it leaves a fixed format called "segwit" in its place). So if its still part of the Tx, how are transactions any smaller

Addresses don't exist at the protocol level, they don't appear in transactions. Addresses are chiefly a means for the receiver to communicate to the sender how they'd like to get paid. From there they also got used in wallets and explorers. -- Yes, the wtxid is malleable. That doesn't matter after confirmation, though. -- Check out these: https://bitcoin.stackexchange.com/a/60173/5406, https://bitcoin.stackexchange.com/a/108336/5406,

Segwit transactions have a longer bytelength but a lower weight, because the witness data only counts 1/4 towards the weight compared to non-witness data. See e.g. https://bitcoin.stackexchange.com/a/52203/5406, https://bitcoin.stackexchange.com/a/84006/5406

I understand SegWit entirely now aside from one key factor; I still don't understand the purpose for having different addresses.

The switch to a new output type allowed us to iterate on the address design. Bech32 addresses use only lowercase letters, significantly improving the user experience for humans trying to copy or dictate them, and they have improved error detection guarantees.


text:
Why does SegWit implement new address formats?
I would consider myself quite up-to-par with the concept and in-depth functionalities of SegWit (segregated witness).
I just don't understand one key aspect of it; P2SH and bech32 addresses.

why on earth was it necessary to create new address formats, what does that do for segwit?
Were the new address formats made as a reason to help segwits implementation, or do they serve a different use-case. (i.e similar to segwits transition to "weight" which had nothing to do with fixing tx malleability but rather optimizing blocks).

I don't see how a P2PKH address couldn't be used in a segwit transaction. The ECDSA signature is still the source of validity of a transaction in segwit

There had to be a way to distinguish between segwit addresses and "legacy" addresses so that software could correctly identify the type of transaction it needed to create.
The obvious approach would have been to use a new "version number" on the usual Base58 address format (like how P2PKH addresses  start with 1, P2SH start with 3, so maybe SegWit could have started with S).
However, the totally new Bech32 address format had a lot of useful improvements unrelated just to SegWit. It was just a good time to introduce it. Benefits include much better error detection (and correction), better security to avoid hash collisions in P2WSH scripts because the hash encoded is longer, less ambiguity when transcribing addresses since mixed case isn't allowed (which also allows more efficient encoding in QR codes), and more descriptive human-readable prefixes.


text:
What's the difference between '[validation] TransactionAddedToMempool' and '[mempool] AcceptToMemoryPool' log messages when running debug=1?
Running bitcoin core 28.0 with debug=1. What is the difference between these two logging messages?
2024-12-18T20:27:39Z [validation] TransactionAddedToMempool:
2024-12-18T20:27:39Z [mempool] AcceptToMemoryPool:
It also seems like not every transaction that gets the TransactionAddedToMempool message gets a AcceptToMemoryPool message.


text:
Why is it recommended to "not send round number amounts when making payments" for increased privacy?
I got this advice today to increase my Bitcoin privacy:

Do not send round number amounts when making payments (eg send 0.00104103 BTC, instead of 0.001 BTC)

Why do they say this? Why does the amount matter? And either way, it's not like I normally can "decide" how much the amount is, unless shuffling coins around my own wallets?

To understand why this is important, you need to understand how a bitcoin transaction is structured. Bitcoin uses an 'unspent transaction output' (UTXO) model, I would recommend reading through this question for more info on that.
So each transaction is composed of one or more inputs, and one or more outputs. As example, if you have a 0.50106550 BTC output, and you want to send someone a payment of 0.2 BTC, then your transaction may look like this (ignoring transaction fees, for simplicity):
Inputs: (0.50106550 BTC)  ->  Outputs: (0.2 BTC) (0.30106550 BTC)
Now consider what someone who is watching the blockchain can infer, just by looking at the amounts in this transaction. Knowing that the excess value from the input will be paid back to the user as a change output, it becomes fairly easy to infer which of the two outputs is the payment (0.2 BTC), and which is the change. This becomes even more clear when including transaction fees: the chance of ending up with a change output that has a small number of significant digits (ie, a round number) is very small! By making this inference, the observer can start to map out which outputs are owned by which user, and this is obviously not good for privacy.
On the other hand, consider the situation if the transaction is tweaked slightly, to remove the round number payment:
Inputs: (0.50106550 BTC)  ->  Outputs: (0.20010852 BTC) (0.30095698 BTC)
Now it is less clear which output is the payment, and which output is the change. As a consequence, it becomes more difficult for a third party observer to determine who owns each output from this transaction. Which one is the payment? Which one is the change? It is difficult to say, based on only the output values. Note that in this case the payment amount was increased by ~0.054%, which is relatively small.

Breaking heuristics like this represent a small gain in privacy, but it is a very simple and easy way to increase privacy nonetheless.


text:
How do you determine whether Bitcoin Core is synced fully or not from the RPC API?
I keep getting the wrong numbers returned daily in the beginning of the day because Bitcoin Core has not yet synced the blockchain from the computer being powered off during the night. So I need a way to determine if it's been synced fully or not, so that I can avoid using the numbers until it has synced fully.
I've looked through https://bitcoincore.org/en/doc/0.21.0/ but can't find anything such as "getsyncamount" or "isfullysynced".
How is it done?

Use getblockchaininfo and check the value of the initialblockdownload field. If it is true, BItcoin Core is still syncing. If it is false, it is done syncing (or very very close to done).

Thank you. Seems to work. But I do wonder why they call it "initial" block download, as if it's just referring to the very first time you sync the blockchain on the computer (as opposed to catching up after just being offline for a few hours). I also wonder why you say "or very very close to done"?

It's called "initial" because that's the first thing it does to make sure the blockchain is up to date. I say "very very close to done" because IBD uses heuristics to determine whether it is synced. It is actually impossible for a node to know whether it is fully synced because the blockchain is decentralized. It can only check for some heuristics that indicate it is most likely fully synced. In some cases, it may think IBD is complete but it might actually be a couple of blocks off. In those cases though, catching up those few blocks is very quick anyways so it doesn't really matter.

Ah. Makes sense. (I'd upvote if the site let me.)


text:
Bitcoin Core ZMQ `sequence` notifications on Regtest
We use ZMQ notifications to monitor new blocks and new transactions in the mempool. It works very well on mainnet, but on testnet and regtest it works halfway: only new blocks are notified but not transactions in the mempool.
Here is the code used to connect:
 def connect_to_zmq(self):
        self.zmq_context = zmq.asyncio.Context()
        self.zmq_sub_socket_sequence = self.zmq_context.socket(zmq.SUB)
        self.zmq_sub_socket_sequence.setsockopt(zmq.RCVHWM, 0)
        self.zmq_sub_socket_sequence.setsockopt(zmq.RCVTIMEO, ZMQ_TIMEOUT)
        self.zmq_sub_socket_sequence.setsockopt_string(zmq.SUBSCRIBE, "rawtx")
        self.zmq_sub_socket_sequence.setsockopt_string(zmq.SUBSCRIBE, "hashtx")
        self.zmq_sub_socket_sequence.setsockopt_string(zmq.SUBSCRIBE, "sequence")
        self.zmq_sub_socket_sequence.connect(self.zmq_sequence_address)
        self.zmq_sub_socket_rawblock = self.zmq_context.socket(zmq.SUB)
        self.zmq_sub_socket_rawblock.setsockopt(zmq.RCVHWM, 0)
        self.zmq_sub_socket_sequence.setsockopt(zmq.RCVTIMEO, ZMQ_TIMEOUT)
        self.zmq_sub_socket_rawblock.setsockopt_string(zmq.SUBSCRIBE, "rawblock")
        self.zmq_sub_socket_rawblock.connect(self.zmq_rawblock_address)

and the full code is here: https://github.com/CounterpartyXCP/counterparty-core/blob/master/counterparty-core/counterpartycore/lib/follow.py
and here is the config file:
rpcuser=rpc
rpcpassword=rpc
rpcallowip=0.0.0.0
server=1
addresstype=legacy
txindex=1
prune=0
mempoolfullrbf=1
rpcworkqueue=100
datadir=/home/ouziel/medias/ssd/
daemon=1
[main]
zmqpubrawtx=tcp://0.0.0.0:9332
zmqpubhashtx=tcp://0.0.0.0:9332
zmqpubsequence=tcp://0.0.0.0:9332
zmqpubrawblock=tcp://0.0.0.0:9333
[test]
zmqpubrawtx=tcp://0.0.0.0:19332
zmqpubhashtx=tcp://0.0.0.0:19332
zmqpubsequence=tcp://0.0.0.0:19332
zmqpubrawblock=tcp://0.0.0.0:19333
[regtest]
zmqpubrawtx=tcp://0.0.0.0:29332
zmqpubhashtx=tcp://0.0.0.0:29332
zmqpubsequence=tcp://0.0.0.0:29332
zmqpubrawblock=tcp://0.0.0.0:29333

Is this a known limitation of Bitcoin Core? or a specific setting that is missing?
Thanks in advance.


text:
Most efficient way to check if utxos are consumed in mempool txs using core rpc and rust
I try to concurrently monitor a bunch of signed but non published transactions. I want to detect asap if any of the inputs into these bond transactions have been used in another transaction in my mempool. Available for use is the bitcoin core rpc and bdk/rust bitcoin. IIUC testmempoolaccept only detects if the inputs already have been confirmed in another TX.
The straightforward way i can think of is calling getrawmempool and then getmempoolentry on each transaction, iterating trough the inputs. This can get heavy for a larger mempool.
My question is if there is another possible way to do this in a more (time) efficient manner using either the core rpc or functionality of bdk/rust bitcoin/another rust crate?

Using a wallet would allow you to do this, whether you choose to use BDK or Bitcoin Core's watchonly wallet. But since you are only interested in mempool transactions spending a specific output you can use the RPC command gettxspendingprevout:

gettxspendingprevout [{"txid":"hex","vout":n},...]

Scans the mempool to find transactions spending any of the given
outputs

Arguments:
1. outputs                 (json array, required) The transaction outputs that we want to check, and within each, the txid (string) vout
(numeric).
     [
       {                   (json object)
         "txid": "hex",    (string, required) The transaction id
         "vout": n,        (numeric, required) The output number
       },
       ...
     ]

Result: [                      (json array)
  {                              (json object)
      "txid" : "hex",            (string) the transaction id of the checked output
      "vout" : n,                (numeric) the vout value of the checked output
      "spendingtxid" : "hex"     (string, optional) the transaction id of the mempool transaction spending this output (omitted if unspent)
  },
  ...
]


text:
Make signed transaction invalid after specified time
Is it possible to construct a valid signed transaction that will become invalid if it hasn't been included in a block before a specified height? Is there any opcode or other way to accomplish this?
The practical use case i envision is a bond (signed transaction) sent to a coordinator that could be published by the coordinator as punishment, but becomes invalid after a specified time (e.g. 1024 blocks).

It is not possible to do precisely what you are asking, but it is possible to achieve something similar in principle.
Bitcoin does not have a "invalid after block height/block time" construct that  would prevent a transaction from being included if it is not mined quickly.
However, you could construct an output that mirrors the same conditions.
Using OP_CHECKLOCKTIMEVERIFY, you can construct an output that can be spent by the coordinator for until a specific block height or time, and after that only be spent by yourself.
In theory, this could also meet your requirements without mining the transaction - by providing a signed transaction to your coordinator that creates such an output, they could broadcast it along with a child transaction consuming that output.
In the event that they do not need to exercise that bond, or the timelock has elapsed, then broadcasting it has no benefit for them.
If the coordinator is not a well behaving citizen, they could subject you to a griefing attack by broadcasting it even after the timelock has elapsed, costing you transaction fees. However, you would still be able to retrieve the value of the bond as they would no longer be able to create a transaction to spend it.

Isn't OP_CLTV also used to lock an output until a specific time in the future instead of locking it starting from a specific time in the future? How would a script look like that disables spending of the output by a specified party starting from a specified time in the future?


text:
Why after 5 fays my transaction status is STILL PENDING?I choose the lowest fee for BitCoins transaction that Atomic cryptowallet offers. Why after
Can someone help me, maube just with an answer?
I wanted to transfer approx. 30€ of 0.00068911 BITCOINS.
And in ATOMIC CRYPTOWALLET you can chose whatever fee for speednof transaction you want, so I choose the lowest to get the most € out of my BTC after exchanging through exchane platform that send € to my SKRILL ACCOUNT.
I SENT BTC TO EXCHANGER AND THE TO SKRILL ACCOUNT ON 31st JANUARY 2024 IN THE MORNIN AND TODAY IS 4th FEBRUARY 2024 IN THE EVENING AND STATUS OF MY TRANSACTION IS STILL PENDING. ARE MY FUNDS LOST OR I WILL HAVE TO WAIT FOR WEEKS OR MONTHS FOR FUNDS TO FINALY GET TO MY SKRILL ACCOUNT OR BACK TO MY ATOMIC CRYPTOWALLET?
Here is the HASH of my transaction and I look at blockchain and there are transactions from my address to the exchang platform address, but no funds yet. Maybe can anyone look deeper in my hash and tell me more about my transaction, my HASH ADDRESS: https://bitcoin.atomicwallet.io/tx/b6a37f8459f0e76f8fb5fb7f63c51048dae65b7b847f3c7ce63dcb27746d94f4
AND JUST MY HASH: b6a37f8459f0e76f8fb5fb7f63c51048dae65b7b847f3c7ce63dcb27746d94f4
PLEASE SOMEONE HELP ME, IF THERE IS SOME SOLUTION TO GET MY FUNDS FASTER BACK ORBTO MY SKRILL.
OR JUST PLEASE ANSWE MY QUESTION.
THANK YOU VERY MUCH!
PETER


text:
Be notified when node rejects TX from mempool
I need to be notified on my C# backend implementing NBitcoin when my node detects a double spend and rejects a TX from its Mempool.
Is there a RPC call or some kind of events that I can register to to receive this kind of notifications?


text:
What is the step-by-step algorithmic process to find the modular multiplicative inverse of (n-1) mod np, where (n-1) and np are not coprime?
Having perused the stackexchange, I found some similar questions, but am having difficulty understanding how to arrive at the solution to  (n-1)*x=1 mod np, where:
n: Finite group order of the Bitcoin secp256k1 curve
n=115792089237316195423570985008687907852837564279074904382605163141518161494337
p: Prime order of the curve
p=115792089237316195423570985008687907853269984665640564039457584007908834671663
np: (n-1)+(p-1)
np=231584178474632390847141970017375815706107548944715468422062747149426996165998
and (n-1) is not coprime to modulo np.
Having performed the following step of np/2 and adding .5 to result one, so as to achieve:
F1=115792089237316195423570985008687907853053774472357734211031373574713498083000
Then subtracting the initial result with .5 to achieve:
F2=115792089237316195423570985008687907853053774472357734211031373574713498082999
And following instructions from answers to related posts, (n-1) is to be multiplicativeley inversed over mod F1 and F2.  However, neither F1 or F2 are coprime to (n-1). In order to overcome this, it is explained that GCD and CRT are to be used in order to accurately calculate the modular inverse.
What steps are required and how are the operations performed to accomplish this?
Thank you.

If two numbers a and m are not coprime, no multiplicative inverse of a modulo m exists.

There is a way to achieve the multiplicative inverse as I have seen it done, the professor who achieved it is assisting me, but he is forcing me to figure out the method (it is unpublished, obviously).  Also, I did see a Stackexchange answer explaining the method, as well.   I have the Python coding for it, but I am trying to reverse engineer it manually.

So, are you looking for a modular division instead of an inverse?

Yes, I believe that is what I am looking for, as I was not understanding the problem itself.  The entirety of the equation I am trying to solve is: (n-1)*x=G.x mod np.

What you're asking for is impossible.
You're looking for x such that (n-1)x = 1 mod np. However, both n-1 and np are even. It's easy to see that any multiple of n-1 will be even. Thus, any multiple of n-1 modulo np will also be even. However, the right hand side 1 is odd. This is a contradiction, as the left hand side cannot be odd.

I just emailed you the Python code.  Also, this is the link to what I was referring:  https://math.stackexchange.com/questions/1015552/modular-division-for-non-co-prime-numbers?newreg=824023ef82f24eb9b24fb30285c8b698

Yes, and the code you mailed me, and the answer in that linked question, does not compute a modular inverse; it doesn't exist. It's solving equations of the form ax = b mod m, and these have only solutions if b is a multiple of gcd(a,m). In your case, b must be even at the very least. The modular inverse, corresponding to the case b=1, is not that.


text:
How to recover bitcoin from Coinbase?
My Bitcoin wallet has generated 1st key and, later, the 2nd one. I have used the first address for a transaction from my coinbase exchange to my coinbase wallet, but the funds did not arrive, perhaps because the 2nd address has already been generated. How can I receive my funds, which used the 1st address? Thnak you for helping.

Addresses never expire. Even if you generate hundreds or thousands of new addresses, money sent to an old address in future years will still be under your control, assuming you make backups of your private keys using your wallet's backup feature and don't keep everything on one device.
Normally, wallets play no part in receiving money but will fetch blockchain data to calculate your current balance. Your wallet is your window onto the blockchain.
You can get the transaction-ID from the exchange and check the status of that transaction-ID at any blockchain explorer.

I'm assuming you might have mixed the private key and the receiving address?
The wallet app generates receiving addresses based off of the private key.
If you used a receiving address from the 1st private key, sent bitcoin to it, and then switched the app to another private key, you might just not see the transfer on your receiving address in the app.
If this is the case, you need to switch the app back to the 1st private key.
If you are using Electrum, it stores the private key info into a file, I'm hoping you have not deleted this file.


text:
People tell me this is scam. Is it?
Since a couple of weeks, a contact from LinkedIn is helping me on the cryptocurrency market. Very successful, but when I want to pick up my money now, I have to pay a mining fee. The mining fee is big and needs to be paid with fresh money, so my wallet can not be used. Scam or is this normal?


text:
Why are torrc modifications required for a bitcoin hidden service on the wiki?
According to the wiki the torrc file requires the following settings:
ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

However, if you simply run bitcoind.conf with onlynet=onion and listenonion=1 you'll get the same result as getnetworkinfo shows that ipv4/6 in unreachable while onion is reachable.
What gives? Why do we need the torrc config change as  the wiki states?

Laanwj: it's not necessary in every case, bitcoin core can create its own hidden service, but it needs to be able to connect to tor's control port; see https://github.com/bitcoin/bitcoin/blob/master/doc/tor.md. in some linux distributions (debian-ish) this is possible without changes to torrc, you might need to add your user to some group, in others you do need changes


text:
How do I start mining bitcoin
How do I start mining bitcoin I saw many asking bout mining sections and hash rate please how do I start


text:
Is there an HTLC-like protocol for cross-chain transfers without user-controlled secret management and protection against LP abuse?
Context:
I am exploring cross-chain transfers from Bitcoin to another network and want to avoid a common issue in HTLCs where users manage secrets and could potentially cause harm to liquidity providers (LPs).
Problem:
In typical HTLC implementations, the user locks funds first and then reveals a secret to claim the funds on another network. However, this can lead to a situation where a user creates an empty HTLC, causing the LP to lock funds. If the user then chooses not to continue the transaction, this can cause resource issues or even a denial-of-service (DoS) attack on the LP, as their funds are locked unnecessarily.
Question:
Is there any known protocol similar to HTLC that allows for cross-chain transfers from Bitcoin to other networks, but where secret management isn't solely handled by the user? Additionally, how can the protocol ensure that users cannot maliciously lock LP funds without completing the process, thus preventing a potential DoS scenario?

It is unclear to me what your issue is. What is an "empty HTLC"?

Are you trying to describe the free option problem? E.g. something along the liens of https://blog.boltz.exchange/p/the-problem-with-free-options-69f9f59a2d48


text:
Determination of Block Size Limit
In Bitcoin Mining, there is a limit on the size of any block added to the chain.
What happens if, for instance, a block's nonce is so large that the block's size exceeds the limit?
Secondary questions:

How was this block size limit set?
Is there any systematic way of setting this limit without knowing how to break SHA256?

What happens if, for instance, a block's nonce is so large that the block's size exceeds the limit?

This post addresses the main question.
Don't think it is complete so I will append the following and let someone wiser mark it all.

A solo miner increments Nonce until it overflows.
Then it increments extraNonce, which is an integer of arbitrary precision, and resets Nonce.
extraNonce is located in the coinbase transaction, so changing it alters the Merkle tree.
extraNonce is reset based on the time.

As @Claris commented, and this post elaborates:

There are many blocks that could be the next one.
For many potential blocks, there is no value of the nonce that will give a hash less than the target.
When that happens, the node must alter something in the block header and try again...

Is there any systematic way of setting this limit without knowing how to break SHA256?

SHA256 has little to do with the validity of a block, having broken SHA256 in any way would not change the consensus rule of the block size. An invalid block with valid proof of work is still invalid, for example if it was larger than the rule specifying limits.
As an aside, no hash function has ever been broken in a way that would impact Bitcoins proof of work. Other than being too small, MD5 is completely suitable for POW despite being embarrassingly broken for any other task.

How can we know that there is definitely a 64bit int that satisfies the leading zeros constraint for any given block? Do nonces have to be given in a particular base?
Why can't we assume that the block is otherwise valid? If you could just calculate the nonce for a POW, wouldn't it undermine the notion of work? What qualities of MD5 make it suitable in spite of the potential for "workless" proofs?
For either part, further reading material is very welcome!
Cheers, Claris!

4 bytes is 32 bits, it doesn’t really have a representation as a number necessarily, just a choice of some software. There’s absolutely no guarantee that any particular nonce field will satisfy the proof of work, miners may process billions of potential blocks before finding a single valid block. There’s another nonce elsewhere in the block which can be iterated on.

“Too large” is a consensus rule, same as proof of work. A block can not be accepted unless it satisfies all the rules, for side, format, transaction content, signatures, time stamp, and proof of work. MD5 just isn’t broken in a way which would allow for easier calculation of proof of work, to my knowledge no cryptographic hash function has ever been broken to that extent.

Hey @kendfss, I think you'll find these questions and answer interesting regarding your questions: 1) https://bitcoin.stackexchange.com/q/22978/5406, 2) https://bitcoin.stackexchange.com/q/80487/5406, https://bitcoin.stackexchange.com/q/148/5406, https://bitcoin.stackexchange.com/q/61759/5406

Hey Claris and @Murch thanks for the input! And sorry for the ignorant miscalculation. I've updated Claris' post with an elaboration, could you guys check if that's about right?

The (header) nonce is 4 bytes, and the (coinbase) extranonce is variable but cannot exceed 96 bytes; in practice much less is sufficient to find a viable block.

Thanks, @dave_thompson_085, do you know how it's reset with respect to time?


text:
vSeed Required or vFixedSeed Enough?
Im creating a new alt coin so I can understand the technology and have most of my changes done and I am trying to understand the vSeed and VFixedSeed logic. I don't have a DNS that will serve up a bunch of IP's since it will be jsut a static IP's of my 2 VM's I have created to simulate nodes. Can I just generate ips in the chainparamsseeds.h file for main and test nets or will my service fail without actual vSeed values?

I guess they are used in this object pnSeed6_main which gets ref by vFixedSeeds

When running the application I get 0 connections when using just vFixedSeeds I dont see where these get used in any of the networking so what are they even used for are they depricated?


text:
Choosing Rights Host For Dependency Make
I am working on on creating builds for windows, mac, and Unix. I am working on Ubuntu 18.04 but on a windows OS. I figured  out host-platform-triplets for windows and mac and generated prefixes for them but not sure how to determine the best Unix prefix. I was hoping to run this in a unix container out in gcp as a test harness. Any recommendations or guidance?

The following triplets are currently supported by Bitcoin Core's "depends" build system, assuming that's what you're talking about (and even if not, these are fairly standard). From https://github.com/bitcoin/bitcoin/blob/master/depends/README.md:

i686-pc-linux-gnu for Linux 32 bit
x86_64-pc-linux-gnu for x86 Linux
x86_64-w64-mingw32 for Win64
x86_64-apple-darwin18 for macOS
arm-linux-gnueabihf for Linux ARM 32 bit
aarch64-linux-gnu for Linux ARM 64 bit
powerpc64-linux-gnu for Linux POWER 64-bit (big endian)
powerpc64le-linux-gnu for Linux POWER 64-bit (little endian)
riscv32-linux-gnu for Linux RISC-V 32 bit
riscv64-linux-gnu for Linux RISC-V 64 bit
s390x-linux-gnu for Linux S390X

Added in master (which will become release version 22.0):

armv7a-linux-android for Android ARM 32 bit
aarch64-linux-android for Android ARM 64 bit
i686-linux-android for Android x86 32 bit
x86_64-linux-android for Android x86 64 bit

x86_64-pc-linux-gnu would be the most common one (targetting 64-bit x86 systems).

That's awesome thank out ill try x86_64-pc-linux-gnu. Just need an output from the make -install that I can plave on an ubuntu 18.04 OS and run on a vm in GCP

Weird I ran the command for make and got this error, /bin/sh: 1: Syntax error: "(" unexpected
funcs.mk:242:. I havent changed this file and have used it to make WIndows and Mac depend prefixes


text:
How to 'buy the dip' without constantly incurring network fees?
I'm a newby to the crypto world and one thing that I have seen a lot of is people saying to 'buy the dip!'.
Fair enough, I like that idea. However, I have limited funds, and so thought that the best way to go about this is to wait until Bitcoin is up, sell a bit, wait until the next dip and then buy some more...
The problem is that I do not want to keep all my coins on an exchange like Binance (there are a lot of horror stories floating around there), so I want to move everything to e.g. Exodus. That's fine, but then I will need to constantly transfer between Exodus and an Exchange when I want to sell or buy. This will undoubtedly incur high network fees.
What is the best way to go about this, without spending huge amounts on network fees? Can I convert some of my coins to a stable coin (if so, which one?) when selling and then convert back to my coin of choice when buying?


text:
Is it actually possible to secure your coins while also allowing access to "near and dear" when you die?
I have my wallet.dat files encrypted, stored on a computer which in turn is encrypted. All storage devices where the files are backed up to are also encrypted. I strongly doubt that any human could ever guess the passphrases, even for the storage disks, then find the wallet.dats and then also decrypt those.
(And if they did, they would also find a bunch of embarrassing stuff which I wouldn't want them to ever see.)
There is no way that I would ever put any of these phrases on a piece of paper. That would violate the entire point of this "as-secure-as-possible" setup.
If I die tomorrow, my "loved ones" (let's just assume that I have some...) would never be able to get any use of my coins. They would just know that I had them and that they exist wrapped inside insane layers of security, and can likely never be retrieved even if they hire some company and entirely ignore my "dead man's privacy".
It is unthinkable for me to let some third party hold my coins "for safe keeping". It's also unthinkable to give them the decryption phrases, because then they could:

Have an incentive to murder me and take the money. (You never know...)
Have no bad intentions, but leak it by accident or coincidence to a third party which then murders me or just steals one of the disks and grabs the coins.
See all my personal files and stuff after I die from natural causes and they use their given-by-me sheet of passphrases to get to the wallet files. This would be awkward.

Maybe you say that I should keep them on separate USB sticks and disks which I've spraypainted orange and put a Bitcoin symbol on. Sure. That's actually something I've thought about. However, I have no money to buy a bunch of new disks; even the ones I have are worryingly old by now, safe for one USB stick which I bought recently for the sheer purpose of having a slightly newer storage device after not buying any new ones for so long.
Also, those dedicated storage devices will only protect against my smallest concern, which is pretty nonsensical to begin with since I'll be dead anyway. And also, they will add the problem of really screaming to whatever threat entity sees them that I have Bitcoins on them, whereas my existing devices are cryptically (no pun intended) and generically labeled.
Maybe there is a way I could set up a "smart contract" which runs perpetually and is able to send all my BTC to a given receive address (which I've very carefully set up for my family members and taught them extremely well to keep secure and backed up and how to use it) when I die, by polling some kind of government API daily to see if my status is "dead" or "alive" or something. But then what happens if that API has a bug in it, or somebody in the government learns about this and decides to mess with me by declaring me officially dead for one day just to trick the smart contract and cause me to lose all my coins? Plus, the entire thing about "smart contracts" seems to be some kind of fantasy and doesn't really exist in reality. At least, I've never found any way to use them or seen anyone using them other than talking about how it's a thing.
What can possibly be done so that I don't risk anything by doing it, yet allow my "loved ones" to get my coins when I die?

This is what safe deposit boxes are for.  Write your passphrase on a piece of paper and put it in a safe deposit box at a bank that will allow only you (with proper identification) to access the safe deposit box, until you die, whereupon access will be available to whoever you've designated through proper legal documents.
If you are worried that some bank employee will break into the safe deposit boxes, then put half your passphrase in a box at one bank and the other half in a box at a different bank.
I'm sure you can imagine ways this can still go wrong, but unless I'm missing something, they are all extremely unlikely.


text:
Looking for Lightning Testnet Wallet with Lnurl capabilities
I'm looking to test an lnurl withdrawal. I created an lnurl withdrawal url using the OpenNode api. I have an htlc.me testnet lightning wallet. But it doesn't seem to have a way to input lnurls.
Is there a testnet lightning wallet that allows you to scan lnurls?
I don't have android, I know some only work on android. Zap claims to have one but they're an open source app that hasn't worked for me and seems to be not maintained so frequently.


text:
Lnurl: Why are there min and max fields instead of an amount field?
When creating an lnurl, why do you need to specify a range of amounts to payout using the fields min and max?
I would think it would make sense for lnurls to just take one specified amount like amount:200 sats instead of minWithdrawal:199 and maxWithdrawal:200

LNURL-PAY enables other use cases like static QR codes that can be printed and re-used many times, provides a standard for receiving sats over Lightning without having the user paste an invoice.
A common example would be a printed sign that contains a QR code for donations. The LNURL-PAY subprotocol allows the receiver to specify a range (min/max) for the accepted payment amounts. When the end-user (payer) scans the QR code, is presented with a dialog that asks how much he wants to pay. He chooses the amount, confirm the payment in his app, and then his app communicates with an LNURL server to complete the payment via the Lightning Network. In the background the protocol generates an invoice for every payment but this is transparent for the user.


text:
Why when you sign up for bitcoins they do all the security questions of your identity but then you cannot use none of them to recover wallet
Why you cannot recover your praise with face recognition

The Bitcoin network is a decentralized network of computers located all around the world. There is no central authority with which your identity is registered when you own some amount of bitcoin, so there is no mechanism to 'recover a wallet with facial recognition', or anything else like that. You simply will have the private keys that allow you to spend your coins, or not.
That said, there are many businesses and services that exist around the world, that work to provide users with bitcoin-related services (such as facilitating buying/selling of coins, storage service, payment processing, etc). Some of those services may require you to give up your personal information in order to become a customer, but in that case your information is not transmitted to the bitcoin network itself, it is just held by the company (and anyone they share it with, or lose it to).
So it may be possible to recover your account with such a business by way of your KYC/personal information, it will just depend on the services offered by said business. But when you are the custodian of your own coins/keys, it is your responsibility to make the appropriate backups and keep them safe.

Naomi I understand the frustration but Bitcoin is a decentralized method of payment with lesser influence of the wallet organization. Wallets like coinbase and coinmama make it almost impossible to loose your coin. Setting up account on those platform provide you a great way of recovering your coin and not just limiting you to the 12phrase word

re: "Wallets like coinbase and coinmama make it almost impossible to loose your coin": that isn't really true, there is a long history of custodial services losing customer funds due to hacks or mismanagement.


text:
Which time does timestamp given in the block explorer represents?

The time block header was constructed

The time when block was validated?

if 2, this means not only nonce is incremented +1 every time we have hashed block header but also timestamp increments and once we mine it and others validate, it stays to final the value? (the one which we see in the block header)

It is neither of those, although it is closer to the first. The second makes no sense. A block is not validated once at a specific time, it is validated thousands of times at thousands of different places. No one cares at what time someone else validated a block, because everyone must validate the block for themselves.
It is a number chosen by the miner. They can choose any value that is likely to be accepted by other nodes at the time those other nodes first receive the new block. The rule is:

A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.

Since it is part of the block header that is included in the data hashed, it cannot be altered.
As it has one second resolution there are probably of the order of ten thousand values that other nodes would accept.
See Can a miner set the EXACT timestamp of a block?


text:
How did testnet transaction b6714e05dd014cc92de09271886e62d85e7d41dd44fad417c520eb51d57f94c0 validate?
Testnet transaction c474c67cabc13f74c65e7cf503db971d5ba176794bff7de36f46d51ca675cf3a locked 0.0005BTC with a simple math script:
OP_2DUP
OP_ADD
5102
OP_EQUALVERIFY
OP_SUB
230d
OP_EQUAL

Transaction b6714e05dd014cc92de09271886e62d85e7d41dd44fad417c520eb51d57f94c0 spent that output with the sigscript:
ba07
6985

I can't see how (ba07 + 6985) == 5102 or (ba07 - 6985) == 230d.
What am I missing about Bitcoin script, integers, and math?

For mathematical operations, Bitcoin treats byte vectors as signed (signed magnitude) little endian values. So let's look what the numbers are then:

The byte vector ba07 is the hexadecimal number (0)7ba.
The byte vector 6985 is 8569 in big endian. Since the highest bit is set the number is negative. So the hexadecimal number is -(0)569.
The byte vector 5102 is the hexadecimal number (0)251.
The byte vector 0d23 is the hexadecimal number (0)23d.

Therefore we end up with the two statements 7ba+(-569)=251 and 7ba-(-569)=d23 which are true.

Ah, got it, thanks!  I had tried playing with the sign bits, but I didn't realize it was little-endian on top of all that.


text:
How to submit nonstandard scriptPubKey transaction to bitcoind in regtest mode?
I'm trying to replicate an algebraic puzzle I saw in the scriptPubKey of a testnet transaction:
OP_2DUP
OP_ADD
6e
OP_EQUAL

I think the intent was for this output to be spendable by a scriptSig of 0x37, but the author used OP_2DUP instead of OP_DUP.  I think you should still be able to spend this with a scriptSig of 0x37 0x37, although the stack after execution will have 1 0x37 0x37 instead of just 1.
I wasn't able to submit a testnet transaction to try to spend the output, because bitcoin-cli sendrawtransaction enforces the non-mandatory-script-verify-flag (Stack size must be exactly one after execution).  So my next thought was to replicate the puzzle on a regnet server, and see if I could spend the coins there.
I created a raw transaction (funded from a different regnet output) with the corrected script:
010000000001013675d91ee12f196835c019afec15f8975bc1bcca23f50e0329376ae93e5bc15b0000000000ffffffff01c808e30500000000057693016e870247304402207f369a50b6deecaf6fc0ee15037ffe460eea9d9093d8e889def1ad93f173d11b022042dac5b3db93aa665b4d45073a3c397e4cdbdbd25880d6a8a15f97cc70b0228f0121029972f24e39b359e5e29267fab7d4cf752982f95e3428b0ef14f38937e6084c3f00000000
{
  "txid": "4c56e2c6626e23f8d3afe7862332f3dbdef5e271f9931ecac8d8ffa67c43bf0b",
  "hash": "07662570c30e5505f35a328342ca6d0a3219ff2198814af44bfcc3dfad20d649",
  "version": 1,
  "size": 174,
  "vsize": 93,
  "weight": 369,
  "locktime": 0,
  "vin": [
    {
      "txid": "5bc15b3ee96a3729030ef523cabcc15b97f815ecaf19c03568192fe11ed97536",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "304402207f369a50b6deecaf6fc0ee15037ffe460eea9d9093d8e889def1ad93f173d11b022042dac5b3db93aa665b4d45073a3c397e4cdbdbd25880d6a8a15f97cc70b0228f01",
        "029972f24e39b359e5e29267fab7d4cf752982f95e3428b0ef14f38937e6084c3f"
      ],
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 0.98765000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_ADD 110 OP_EQUAL",
        "desc": "raw(7693016e87)#tcc664ka",
        "hex": "7693016e87",
        "type": "nonstandard"
      }
    }
  ]
}

But I can't submit this transaction to my regnet server either, because:
% bitcoin-cli sendrawtransaction 010000000001013675d91ee12f196835c019afec15f8975bc1bcca23f50e0329376ae93e5bc15b0000000000ffffffff01c808e30500000000057693016e870247304402207f369a50b6deecaf6fc0ee15037ffe460eea9d9093d8e889def1ad93f173d11b022042dac5b3db93aa665b4d45073a3c397e4cdbdbd25880d6a8a15f97cc70b0228f0121029972f24e39b359e5e29267fab7d4cf752982f95e3428b0ef14f38937e6084c3f00000000
error code: -26
error message:
scriptpubkey

Do I have to write my own submitter to talk to the regnet node?  (Perhaps I'll need that anyway to submit the answering / spending transaction.)
(I think I can submit nonstandard scripts via P2SH, but that's not what I want, because the puzzle script itself needs to be in the blockchain, not just the answer script's hash.  That's the whole point of having a puzzle / reward / challenge: anyone can read the problem statement, and if they can solve it, they can submit a transaction where the scriptsig pushes the answer(s).  I understand that this is not secure, and that a mining pool could steal the answer and submit it with their own pay-to address as the output, but that's a problem for another day.)
Help!

You have to tell Bitcoin Core to allow non-standard transactions, This can be achieved by starting it with -acceptnonstdtxn.

Cool!  It works!  Now if I wanted to submit a similar spending transaction to testnet, I would spin up a testnet node here and submit the same way.  But would the transaction propagate enough to get into a block somewhere (via gettemplateblock, right?)?  Or do I have to mine my own block locally from templates from my local testnet node?

Testnet allows non-standard transactions by default. You don't need to start with -acceptnonstdtxn on testnet, and any non-standard transactions you make should propagate.


text:
Does testnet block 855996c9444827112b68c0606d8dfec62385d1b3448e412bc1c721633a641669 discard the block reward?
I am poking around in the testnet blockchain, and I saw a block mined recently where the outputs added up to just 0.04953672 BTC.  Since there is no output for the 50BTC block reward, does that mean that it was just discarded?  (I.e., there is no input script that can claim it.)
Why is the input (coinbase) script:
OP_PUSH<03> <208621>
OP_FALSE
<coinbase data>

Does this match a convention, or is it just whatever the miner wanted to put there?

First, 0x855996c9444827112b68c0606d8dfec62385d1b3448e412bc1c721633a641669 isn't a block. It's a transaction.
Secondly, The last testnet block is ~2,197,048. I think that bitcoin's reward at this stage is very low.
Have a look at these following bitcoin blocks :

Block 0 : https://www.blockchain.com/btc-testnet/block/0, reward = 50.
Block 210,000 : https://www.blockchain.com/btc-testnet/block/210000, reward = 25.
Block 420,000 : https://www.blockchain.com/btc-testnet/block/420000, reward = 12.5

...
You should understand it now, the reward decreases. According to Bitcoin's blockchain protocol, the Bitcoin block reward gets cut in half after every 210,000. The transaction 0x855996c9444827112b68c0606d8dfec62385d1b3448e412bc1c721633a641669 belongs to the block 2,197,024 (https://www.blockchain.com/btc-testnet/block/2197024). 2,197,024 is very hight. The Bitcoin testnet follows pratically the same rules of the Bitcoin mainnet. There's a little differences regarding magic bytes or P2PKH prefix...
Regards.

You're right, thanks!  I had a TXID instead of a block ID, and the testnet block reward really is that low now.  Next, I have to figure out segwit transactions.


text:
Only My Transaction in a block
I am thinking of broadcasting a Bitcoin transaction with a very important message. The message is so important that I want it to be the only transaction (other than coinbase) in the block.
For example if my transaction were to be included in block 740000 than the block should contain only the

Coinbase Transaction
My Transaction with message.

I am willing to pay an additional fee of 1BTC but only after the block is mined.
Is there a way to make sure this?

OP_RETURN
The generally approved way to include arbitrary content in a transaction is by use of an OP_RETURN script. See Explanation of what an OP_RETURN transaction looks like
There is nothing you can write in a Bitcoin script that checks the number of other transactions in a block. The only way to ensure exclusivity is to make the transaction sufficiently large.
Transaction size
To be sure your transaction is the only non-coinbase transaction in a block it would have to be large enough to almost fill the block. See What is the maximum size of a transaction?
Personally, I don't see how the presence of other transactions could in any way affect the perceived importance of a transaction, but I'll disregard that aspect.
Payment Conditions
To be sure that you only pay the miner after the transaction is included in a valid block, you only have to use one output of your transaction to pay the miner a large transaction fee. For example with inputs of 1.0001 BTC and an output to yourself of 0.0001 BTC. leaving 1.0000 BTC to be collected by the miner.
Minimum relay fee
Large transactions will not be relayed by many intermediary nodes unless the mining fee exceeds a minimum amount. I believe initially this was 1000 satoshis per vkByte. This could mean that you either need to pay more than 1 BTC or need to make a special arrangement with a miner to deliver your unconfirmed transaction to them using some direct method.

Theoretically you could just jam some string as a "message" in the Tx Witness.
To answer your question though, if you're willing to pay the miner a whopping 1BTC fee they'd probably accept it, but if you want to claim the whole block to yourself the transaction's weight will have to be heavy enough that the miner is forced accept your transaction into their block exclusively should they choose to incorporate it.
Nonetheless though, unless the fee is huge, virtually no miner will accept the transaction.

I am willing to pay an additional fee of 1BTC but only after the
block is mined.

Fees are always "paid" after the block is mined. A miner cant claim the fee if its an unmined block.


text:
Does the Lightning Network support Bitcoin scripts, and what do the identifiers of Lightning wallets look like?
I'm currently exploring the deployment of Bitcoin scripts within the Lightning Network. Specifically, I'm interested in understanding the compatibility and functionality of Bitcoin scripts within the Lightning Network protocol.
Firstly, I'd like to know if the Lightning Network supports Bitcoin scripts. Are Lightning Network transactions able to utilize Bitcoin scripts for custom smart contract functionality, similar to on-chain Bitcoin transactions?
Secondly, I'm curious about the identifiers of Lightning wallets. When interacting with the Lightning Network, do Lightning wallet identifiers resemble traditional Bitcoin addresses? Or are there distinct formats or structures used for Lightning wallet identifiers, considering the off-chain nature of Lightning transactions?
I appreciate any insights or resources that can shed light on these questions.

The lightning network is composed of nodes that span channels between each other. A channel is implemented per a 2-of-2 multisig output that is collaboratively controlled by the two nodes participating in the channel. The channel participants use a multistep update protocol to renegotiate the final payout from the channel by creating a new state and then relinquishing the old state. Each state of the channel is encoded as one or multiple unconfirmed Bitcoin transactions that the channel participants store locally. This permits either to unilaterally close out the channel in case the other party ceases to interact.
The Lightning Network protocol uses transaction templates that strictly adhere to the Basis of Lightning Technology (BOLT) standard. Therefore, it is not possible to overlay lightning payments with additional script conditions, but given the quick-paced payment resolution, a lot of use-cases can be facilitated by streaming payments, multiple installments, paying just-in-time, etc.
Lightning node identifiers are distinct from Bitcoin invoice addresses.


text:
Handling Multi-Signature Transactions with PSBT in Bitcoin
I'm currently working with Partially Signed Bitcoin Transactions (PSBTs) and trying to understand the best practices for handling transactions that require signatures from multiple parties. Specifically, I want to create a transaction that needs signatures from two different individuals using PSBT.
Storage of Signatures: When I, as the first signer, add my signature to the PSBT, where is this signed data stored while we wait for the second signer to add their signature? How does the PSBT format handle this interim state?
Security Concerns: Are there any recommended security practices to ensure the integrity and confidentiality of the partially signed transaction during this process?
I would appreciate any insights or guidance on managing multi-signature transactions using PSBTs, particularly regarding the secure storage and handling of the transaction until all required signatures are gathered.

When I, as the first signer, add my signature to the PSBT, where is this signed data stored while we wait for the second signer to add their signature?

In the PSBT file.

How does the PSBT format handle this interim state?

The PSBT file format can be thought of as a set of key-value stores for each input and output of the transaction. When you add a signature to a PSBT, you add a field saying "a signature for input X, with key Y, in Z". A future finalizer can then use this information (once enough other signatures have been added) to construct a valid transaction input.

Are there any recommended security practices to ensure the integrity

Not particularly. Generally, PSBT files are just an interchange format, for giving potential signers all the information they need to sign. This includes the (unsigned) transaction being signed, the UTXOs it is spending, information about scripts and keys that signers may need, and so forth. If the information is wrong/corrupted somehow, the outcome will just be an inability to sign, or the resulting signature will be invalid.

and confidentiality of the partially signed transaction during this process?

PSBTs do contain information that does not eventually end up on chain, and may be somewhat privacy-critical, such as the xpubs and key derivation paths used by the participants.
Because of this reason, it is not advisable to share the file with anyone but the other signers.


text:
Handling UTXOs in Partially Signed Bitcoin Transactions (PSBTs) and Potential Double-Spend Scenario
I'm working with Partially Signed Bitcoin Transactions (PSBTs) and have a question about the behavior of transactions when the same UTXOs are involved in multiple transactions. Suppose I have a transaction created as a PSBT that requires multiple signatures. I sign it first, and before the second signer completes their part, I attempt to spend the same UTXOs in a different transaction.
PSBT Completion: What happens if I broadcast a new transaction using the same UTXOs before the PSBT is fully signed and broadcast? Can the new transaction be confirmed before the PSBT, making the PSBT invalid?
Double-Spend Protection: How does the Bitcoin network handle this scenario? Is the first transaction that gets confirmed the only one recognized, thus invalidating the other?
Wallet Behavior: What role do wallets play in managing UTXOs to prevent potential double-spends in such scenarios? Do they typically prevent the creation of a second transaction that would use the same UTXOs already allocated in a partially signed PSBT?
Any insights on how the Bitcoin protocol and network handle these situations would be very helpful.

Your question is about what happens when a transaction gets broadcast which tries to spend outputs that are already spent. It is unrelated to PSBT; PSBT is just one technology that helps wallets cooperate in constructing a transaction together, but how that transaction comes to be here is irrelevant here.
The answer is that Bitcoin nodes will not let you spend outputs which are already spent in a confirmed block. The transaction will be ignored.
If a transaction has already been broadcast, but not confirmed, which spends the same outputs, nodes may or may not accept the transaction, based on whether the new transaction pays a higher feerate, whether the old one opted into the BIP125 (signalling replaceability), and on the local policies of the node involved. There is no guarantee that all nodes behave the same way.

how blockchain knows that certain utxo is locked for psbt as it isnt on chain data ?

@NersesAsaturyan It does not. It's a feature of the wallet.


text:
Can You Create a Time-Locked PSBT in Bitcoin?
I am exploring the capabilities of Partially Signed Bitcoin Transactions (PSBTs) and am particularly interested in incorporating time locks. Is it possible to create a PSBT that includes a time lock condition in Bitcoin? If so, how can one implement this feature, and what are the limitations or considerations to keep in mind?

PSBT can contain any unsigned transaction. If that transaction uses a script with a locktime condition, then you have a PSBT that involves a time lock.
Whether or not wallet software can deal with such transactions is up to them. PSBT is just a means of communicating the transaction and partial signatures.


text:
Implementing Conditional Fund Locking in Bitcoin Similar to Ethereum's Smart Contracts
I'm familiar with how Ethereum allows users to lock funds in smart contracts, which can then be released under specific conditions using mechanisms like the Hashed TimeLock Contract (HTLC) protocol. I'm interested in exploring whether similar functionality can be achieved within the Bitcoin protocol.
Locking Funds: How can funds be locked in Bitcoin? Is there a direct way to implement conditions within a Bitcoin transaction itself?
Unlocking Conditions: What mechanisms are available in Bitcoin to unlock these funds based on specific requirements, such as time-based conditions or upon fulfilling certain cryptographic proofs?
Tools and Practices: Are there specific tools or practices within the Bitcoin ecosystem that facilitate this kind of conditional locking and unlocking of funds?
Any insights or guidance on how to approach conditional fund locking in Bitcoin similar to Ethereum's smart contracts would be greatly appreciated.

There's a lot difference between ethereum and bitcoin regarding locking and unlocking fund, but let me roughly compare.

Locking Funds

Unlike ethereum, most transaction of bitcoin itself is an action of locking fund, using smart contract called "Script". You can build ScriptPubKey with "Script", and transaction is an action of sending bitcoin to ScriptPubKey. You could think most transaction of bitcoin is a bit similar to deploying ethereum smart contract which locks ethereum.

Unlocking Conditions

To unlock bitcoin transaction, you have to provide ScriptSig(or Witness for segwit), which has to pass the condition of ScriptPubKey to spend. ScriptSig consists of data to pass the condition of ScriptPubKey. For example, if ScriptPubKey requires signature verifiable with specific public key, signature would be placed into ScriptSig. Unlocking condition can be any of combination implemented with ”Script”, and time-based conditions or fulfilling certain cryptographic proofs can be. Hash Time Lock Contract can be implemented as well.

Tools and Practices

There's a description about ”Script”, or Miniscript is also widely used. Or just search bitcoin library in GitHub with your preferred language.

Any insights or guidance on how to approach conditional fund locking in Bitcoin similar to Ethereum's smart contracts

Most common smart contracts of bitcoin are p2pkh, p2wpkh and p2tr(key-path), which is similar to Ethereum Transfer Transaction without calling smart contract(i.e. just transfer eth by signing tx). It requires the fund owner to sign transaction(and provide public key if not p2tr). However, as mentioned above, most transaction of bitcoin is an action of locking fund, so it means p2pkh, p2wpkh, and p2tr(key-path) are also way of locking fund using smart contract, of which unlocking condition is to provide signature(and public key if not p2tr).
Other smart contracts of bitcoin can be implemented with p2sh, p2wsh and p2tr(tapscript).  p2sh and p2wsh is way to send bitcoin to hash of smart contract(ScriptPubKey), which is the hash of redeem script(or witness script if segwit). To spend this, you need to provide both locking script and unlocking script in ScriptSig(or Witness for segwit. For more detail, check BIP16).
p2tr(tapscript) is using MAST to lock and unlock bitcoin(For more detail check BIP341).
You can just send to bare ScriptPubKey instead of above standards, but it’s definitely not recommended.
Below is an example of HTLC in bitcoin.
OP_IF
    blockheight_or_utc
    OP_CHECKLOCKTIMEVERIFY
    OP_DROP
    <pubkey_alice>
OP_ELSE
    OP_SHA256
    preimage_hash
    OP_EQUALVERIFY
    <pubkey_bob>
OP_ENDIF
OP_CHECKSIG

Thank you for taking the time to provide such a detailed explanation.


text:
How to add a custom struct to PSBT and handle transaction fees with two parties using BIP-174?
I am working on a Bitcoin transaction where two parties are involved. The goal is to lock funds and create a custom struct in the transaction output. Here's how I intend to set it up:
First party provides the funds and initiates a Partially Signed Bitcoin Transaction (PSBT) using BIP-174.
Second party will add a custom struct (possibly metadata or a specific output detail) to the PSBT without providing any funds.
I'm wondering if the following is possible:
Can the second party add a custom struct (output or metadata) to the PSBT, while the first party is the only one providing funds?
Who will be responsible for paying the transaction fees? Will the first party bear all the fees since they are providing the input funds, or is there a way to distribute this between the parties?
Are there any known constraints or best practices for achieving this within Bitcoin's protocol and the PSBT standard?
I would appreciate any guidance on whether this setup is feasible and how to handle fees and struct addition in a PSBT.

Will the first party bear all the fees since they are providing the input funds,

Yes, since they are the only one providing input funds.

or is there a way to distribute this between the parties?

There is no way for someone who is not providing funds to pay transaction fees in the transaction.
Note also that the Bitcoin network does not have any concept of which inputs contribute fees.

I just want to user pay funds and other party (non user) add needed struct and also I want user not to do tx (dont pay fees).

There is no fixed relationship between party that transmits ("does") the completed transaction and the party or parties that provide the inputs to the transaction. Whoever submits the completed transactions to the network need not be a provider of inputs or even a signatory. People are not charged a fee for transmitting a new unconfirmed transaction, the participants providing funds arrange that sum(inputs) > sum(outputs), that is all.
From learn.saylor.org:

As I understand it†, sighash_single (for example)  means your "user" can provide for your "non-user" to add an extra output without your "non-user" having to provide any inputs. The second output could contain a small amount of embedded data. The monetary amount of the second output would come from sum(blue inputs) - sum(blue outputs) and leave some as the tx fee. Note also Transaction outputs with value 0
† I don't use this, so caveat emptor.

so isnt there a way that fees can be paid by funds of second entity as he is broadcasting the tx ?

Since transaction fees are sum(inputs) - sum(outputs), a second party with no inputs has no way to contribute to fees.

Maybe you are thinking about Sighash_anyonecanpay?

I just want to user pay funds and other party (non user)  add needed struct and also I want user not to do tx (dont pay fees). now I am a lil bit confused which BIP I should use

If one of the outputs belongs to the other party, that output’s amount could be reduced by the fees and they could pay the fees without providing an input. However, if the second party does not get paid in the transaction, indeed only someone that provided an input can pay fees since fees are the difference between the sums of input amounts and output amounts

" I want user not to do tx (dont pay fees)." There is no fixed relationship between  party that transmits ("does") the completed transaction and the party or parties that provide the inputs to the transaction. Whoever submits the completed transactions to the network need not be a provider of inputs or even a signatory. People are not charged a fee for transmitting a new unconfirmed transaction, the participants providing funds arrange that sum(inputs) > sum(outputs), that is all.


text:
Is it safe to share half of the private key in WIF format?
Assuming I would generate my keys on https://www.bitaddress.org.
Is it safe to share the following four pieces of data?
One half of the private key.
The public key.
An SHA512 hash of the private key.
An SHA512 hash of the public key.

By private key I mean the string representation as a 52-digit hexadecimal number. One half of the private key would be the first 1 to 26 characters of this string.
Can I assume that the person receiving this information will not be able to reconstruct the private keys by intelligently combining this information or by running an attack like a brute-force-attack?

Why would you want to share this data in the first place?

This question is about secret sharing: https://en.wikipedia.org/wiki/Secret_sharing . Advantages of these methods can be found on wikipedia.

Just use Shamir's Secret Sharing. Trying to invent your own cryptographic scheme is almost always a terrible idea.

@Vojtěch Strnad : Thank you for your comment. I have been thinking a long time about it and I also tried out the ssss-split and ssss-combine packages. Then I was wondering wheather these algorithms are standardized and found this post: https://security.stackexchange.com/a/83924 The author says: "Whatever you use, you'd better keep around its source code so that it may be recompiled or at least ported on the machine you will have twenty years from now.". As I am not yet convinced I would love to also get an answer to my original post.

You should link to your related question which has an answer: https://crypto.stackexchange.com/questions/109752/in-bitcoin-given-half-the-52-character-private-key-in-wif-format-is-it-possibl

How would I formulate that this answer was not helpful for me from a practical standpoint without risking to get this question deleted?


text:
Is this fraud by chance

This is a email I got think it's fraud

Thank u so much I truly appreciate you

Yes, its a fraud. You would need specialised equipment to earn that kind of money. Also the 24-hour deadline is a typical ruse by criminals to panic their victims into acting without taking time to think about what they are doing.
The last line suggests advance fee fraud - Is it normal to be asked for an advance fee on a withdrawal?

This is the crypto version of the Nigerian Prince scam. I have $40 million dollars for you but you have to send me $50k first so I can send it to you. Fraud....fraud never changes.


text:
Can I create multiple OP_RETURN UTxO in single transaction
Is it possible to generate multiple OP_RETURN utxos in one transaction?
I see there is an answer for that in 2015, I wonder if it's still the case.
I know nothing prevents us from doing so, but question is, do miners accept these kind of transactions?

If you pay the fees there's no motivation for the miners to don't pick your transaction with multiple OP_RETURNS

@polespinasa Thanks for the response, but the previous answer says: "such a transaction would not be considered a 'standard' transaction and would not be relayed (propagated) through the network.". So, are you sure about your answer?

That means that nodes (non-miners) will not propagate the transaction because they will label it as non-standard, but it still complies with the consensus rules and is a valid transaction so if it reaches a miner and he acts on economic incentives he will take it.

Such a transaction would be valid, but considered non-standard by most nodes on the Bitcoin network. It is unlikely that such a transaction would propagate to miners and would be included by miners unless further steps would be taken beyond submitting to your own node.
Also OP_RETURN outputs are not part of the UTXO set. They are provably unspendable, so we do not track them among the Unspent Transaction Output set.

thanks for the response. Is there any document around things that make transaction non-standard? I checked devguide but there was no statement about multiple OP_RETURN making transaction non-standard. link: https://developer.bitcoin.org/devguide/transactions.html#non-standard-transactions


text:
Is it possible to lock Bitcoin funds and have them automatically unlocked after a specified time without a second transaction?
Context:
I am looking for a method in Bitcoin where I can lock my funds for a certain period and have them automatically unlocked after the specified time passes. In most time-locked transactions, such as HTLCs, a second transaction is required to either claim or refund the funds. I’m interested in exploring whether there is a way to automate the unlocking process without the need for an additional transaction.
Question:
Is there any existing method or script in Bitcoin that allows funds to be locked for a certain time and then automatically unlocked without requiring a second transaction for the refund? If not, are there any alternatives or workarounds to achieve this functionality in Bitcoin?

A timelocked output is already "automatically unlocked" when the timelock expires. The reason a HTLC requires a second transaction when claiming the funds is to prevent the other party from refunding after the timelock expires. Similarly, the other party might want to start the refund as soon as the timelock expires to ensure they get the funds back even if the hash preimage is later leaked.
However, in a single-party setup, there is no rush to spend a timelocked output as soon as the timelock expires. You can simply consider it unlocked and spend it whenever you need the funds for something.

can you explain more in detailed the last passage ? I cant get You can simply consider it unlocked and spend it whenever you need the funds for something.  . Does this this mean there is no need for refund transaction ?

Yes, a refund transaction would spend the timelocked output and create a non-timelocked one to use in a future transaction, but you can skip this step and just use the timelocked output in the future transaction.

but will it be in balance of user ? Or you say there is no need to do refund as setup is single-party ?

User balances don't exist on the blockchain, only unspent transaction outputs with specific amounts. After the timelock has expired, the previously timelocked output is as spendable as a non-timelocked one, so there is no need to count it separately.


text:
Can a Second Signer Add Data to a Bitcoin PSBT Transaction?
I'm working with Partially Signed Bitcoin Transactions (PSBTs) and have a question about the capabilities of secondary signers in the signing process. I understand that in a multi-signature scenario, each participant is expected to sign the transaction. However, I'm curious about whether a second (or subsequent) signer can also append additional data to the transaction, aside from their signature.
Specifically, I'd like to know:
Can additional metadata or inputs/outputs be added by a second signer?
Does the PSBT format support modifications by signers beyond merely adding their signatures?
Any insights or references to documentation would be greatly appreciated!

PSBT is just an interchange format for whatever information signers may need.
It does contain an unsigned transaction as "the thing being signed". Nothing prevents participants from modifying that transaction data, but doing so will generally invalidate the existing signatures, so it's not expected that participants do this after agreeing on what the transaction being signed is.

so isnt there way to add data as second signer but without invalidating the psbt ?

Normally, no, because the signatures cover the outputs; so if the outputs change, the signatures are invalidated (this too is unrelated to PSBT, it's just how signatures in Bitcoin work). It's possible to avoid this if the signatures do not cover the outputs (using the SIGHASH_NONE or SIGHASH_SINGLE flags), but there are many pitfalls in that case.

@NersesAsaturyan: It might help if you take a look at the PSBT format specification in BIP 174.


text:
modified Hash Time Locked Contracts
I'm currently working on implementing a modified version of Hash Time Locked Contracts (HTLC) in Bitcoin and would greatly appreciate any guidance or best practices from the community.
Objective: I aim to modify the standard HTLC to simplify the creation process. In my modified HTLC:

The creator of the HTLC does not need to specify a hash lock initially.
The creator specifies a party (which can be nullable) who will later add the hash lock to the pre-HTLC.
Only the creator of the pre-HTLC and the specified party can add the hash lock.

Questions:

Feasibility: Can this modification be implemented within the current Bitcoin scripting capabilities? Are there any inherent limitations I should be aware of?
Security Considerations: What potential security risks should I consider with this modification? How can I mitigate these risks?

Am I understanding right that you are trying to create an output which will execute differently based on someone else’s input after it was created?

@Murch let me explain more detailed.in simple HTLC when Alice and Bob want to change assets,at first Alice creates HTLC struct and lock funds for Bob with inputs (hashlock,BobAddr,timelock,amount,etc).In modified version I want Alice to create preHTLC struct for Bob with inputs (3rdParty,BobAddr,timelock,amount,etc),after it 3rdParty comes and converts preHTLC creating new struct HTLC with preHTLC data and adds hashlock. Afters this step everything goes as in simple HTLC protocol.

Are you aware of PSBTs?

unfortunately,no

I have done some research,but I still cant understand will it match to the described architecture.Particularly that 3rdParty can be nullable,will work PSBT for it.

You would need a separate way for the participants to agree on the output script, and then could use PSBTs to coordinate transaction assembly and signatures. You cannot broadcast an incomplete transaction and have it modified afterwards, because an incomplete transaction is not valid and invalid transactions do not propagate on the network.

thanks for help

You cannot broadcast an incomplete transaction and have another user modify it later, because an incomplete transaction is not valid and invalid transactions do not propagate on the network.
You could share an incomplete transaction out-of-band, e.g. on a message board, via a Partially signed Bitcoin transaction (PSBT) iff the inputs and outputs of the transaction creator are sufficient to enforce their expected outcome by using a SIGHASH_SINGLE | SIGHASH_ANYONECANPAY construction. The second participant would then be able to fill in the remaining inputs and outputs to achieve their intended outcome in addition.
However, if you want two participants to both have input on one output script, your protocol will require at least one round trip, as the original transaction creator cannot sign off on an incomplete output script, and therefore either the second participant would have the ability to unilaterally determine that output or the transaction would have to go back to the creator after the second participant adds their modification.
I must admit that I don’t fully understand what you are trying to achieve, and therefore may be missing a workaround or trick, but the above should cover the general situation. Your problem reminds me of how inscription market places use PSBTs to offer NFTs for sale, and if you are not familiar, it might be interesting to study that approach.
If you generally want to better understand how HTLCs work, you may want to take a look at Elle Mouton’s excellent HTLC Deep Dive, her other blog posts may also be interesting in the context of your line of inquiry.


text:
How Does the Blockchain Recognize Locked UTXOs in a PSBT if the PSBT Isn't Stored On-Chain?
I'm currently exploring the use of Partially Signed Bitcoin Transactions (PSBTs) and have a question about the locking mechanism of UTXOs during the signing process. I understand that as a first signer, I lock UTXOs to ensure they are not used in another transaction before the PSBT is finalized. However, since the PSBT itself is not stored on the blockchain until it's fully signed and broadcast as a complete transaction, how does the blockchain or the network recognize that these UTXOs are locked? Does the lock actually reflect on the blockchain, or is it managed some other way?
I am looking for clarification on:
The mechanism that prevents other parties from using the locked UTXOs while the PSBT is in progress.
Any documentation or technical details that explain how these locks are recognized and respected by the network.
Any insights or technical explanations would be greatly appreciated!

Locking UTXOs is a feature of certain wallets, to prevent their UTXOs from being reused while the building of a transaction using them is in progress.
Whether or not a UTXO is locked is only known only locally to the wallet itself. It is not stored on chain, so it is not known to other wallets.

so it can be used as commitement for doing transaction,am I right ?

What do you mean by "commitment"?

if i want to do swap of assets second side should be insured that first side want to do swap and locked the funds so doing himself. In case I undertsood correctly psbt cant be used as after signing psbt later utxos can be send if psbt isnt broadcasted

You cannot rely on locking as a means to guarantee that the other side will not double-spend the assets. You need to use an atomic swap protocol.

for example what protocols can be used in such case ?

@Nerses: "What protocols can be used for atomic swaps" is a different question and deserves to be asked as a new question using the Ask Question button.

Hey @NersesAsaturyan, we have tens of thousands of questions with answers on this site. Please check out the [tag:atomic-swap] tag to find topics such as https://bitcoin.stackexchange.com/q/54120/5406