text:
Can I use Bitcoin to permanently prove that "there exists a file with content at this point of time"?
I have some files (e.g. of 10MB in size, think of it as a paper, an article, a photo, etc), and want to permanently prove that "at 2022.05.24, I already come up with such a file with such content".
So, is it possible to be done via bitcoin? My very naive thought is that, transferring some bitcoin with "attachment" being the hash of my file. Then, since this money transfer record is permanently unmodifiable and visible to everyone, I prove that I have it at this time.
In addition, can this be evidence in, for example, courts?
I am new to blockchain/bitcoin so I am not sure whether this thought is reasonable or not. Thanks for any suggestions!

"In addition, can this be evidence in, for example, courts?" might be better asked on law.SE .

You can also (ab)use Certificate Transparency logs for this purpose without involving Bitcoin or any other cryptocurrency.

@R..GitHubSTOPHELPINGICE Could you please elaborate it a bit more?

@R.. There might be many alternative ways of creating the evidence the OP desires; I am not sure how that is relevant here.

The title and question body are inconsistent. Do you only want to prove that the file exists (that is, someone had the file) at the relevant time? Or do you want to prove that you had the file at that time? It seems that the former is much easier than the latter.

@ch271828n: Just by arranging for the hash you want recorded to be present in the CSR submitted to Lets Encrypt or whatever ACME provider you use. Then it gets recorded in one or more append-only ledgers as required by policy for CAs.

For the purpose of courts, wouldn't something like mailing yourself the hash (or even a disk/usb stick containing the file in question) be sufficient/better/cheaper?

@BrianDrake I guess the former is enough. The data has identity in it, consider it like an article with author's name and id. Thus, as long as I can prove this file content exists, I also show the article is by this author (me).

@R..GitHubSTOPHELPINGICE Looks interesting (and not using bitcoin)

@DanM. Well, then how can I prove the mail is not fake, e.g. Outlook/Gmail/... create a fake mail at that time? For USB stick, I even cannot prove the file is created at that time.

@ch271828n: Indeed, and even methods like relying on "$mailprovider's DKIM keys signed the mail attesting that they saw it at the time" are not valid because DKIM keys often leak after their validity expires (and many folks even propose intentionally leaking them after validity expires so that they don't create unwanted nonrepudiation properties).

Easy way to do it with CT logs: just bring up a https site for "$hash.$yourdomain" with a configuration that auto-deploys Lets Encrypt, and the hash will be permanently recorded in an append-only ledger (attesting to the time/sequence in which it was published) by virtue of being the hostname for which a certificate was issued.

Can you see that "… already come up with…" inarguably proves, you need a better translator? Do you doubt that matters?
Can you say how or why this is about Bitcoin, specifically? How would a Bitcoin transfer allow you to attach files that a standard bank transfer would not?
Why ask about evidence in, for example, courts,l when everyone else knows that courts are the obvious, over-riding example? How could what  works in court, not work anywhere else?

You may want to google for "timestamp server".  Such services, based on cryptographic signatures, have existing for many years and there's a lot written about them.  The variant you're suggesting is a way to make sure the record of the timestamping is public and permanent - an improvement (depending on your use case) from depending on a privately operated timestamp server to persist.

You might have, but not with that wording.
I suggest any court would "ask" you to find a (much) better translator.
Can you re-phrase "… use Bitcoin to permanently prove that 'there exists a file with content at this point of time' " at least three ways, or see that no court will accept your argument?

Embedding arbitrary data in the Bitcoin blockchain is possible with the use of an OP_RETURN output. If you embed a hash of your file this way, it will prove its existence at that point in time, for as long as Bitcoin exists and its timestamps can be trusted. Note that block timestamps in Bitcoin can theoretically be up to 2 hours different from real time.
However, embedding a hash of a single file in a transaction is wasteful. Using a merkle tree, you can timestamp thousands or millions of files at the same time, and still use only one transaction. The OpenTimestamps project creates an open standard for exactly that and lists several so-called "calendar servers" that allow you to create a trusted timestamp for free (they rely on donations to cover transaction fees and other expenses).
Example OpenTimestamps transaction: f1127bd52c1fe4894134379403f4dc7287018fc4f1361c3ce01a554ae6995f9c

the only thing he can prove is that statement "the transaction submitter created a hash arount time t". Not that he actually has the message that generated that hash. And even less that that message was in fact, a file on a filesystem at any point.

@v.oddou The hash is good enough.

@v.oddou Not sure what you're getting at there.... are you saying that someone could report a hash, and then later do a preimage attack to simulate the original existence of the file?

@Sneftel well yes, but the fact that this hard makes it an acceptable solution for that case. My point wasn't for the case where we query the system with valid queries. The point was as long as there is no query, anybody can just put some random hashes in there and pretend they "have files" when in fact they have nothing.

@v.oddou Putting "some random hashes" into the blockchain is no use when there are potentially 2^256 valid SHA-256 hashes. This is no better than a preimage attack.

@v.oddou I think this is just an issue of imprecise wording.  In cryptographic terms, it sounds like the OP is striving to make a "commitment" that a file existed at a certain time.  The "proof" is actually done at a later time, by providing the file (which can be hashed), and some key material to prove that the OP was the instigator of the transaction.  And, to your comment about random hashes, the validity of this commitment does depend on the quality of the algorithm used.  At time of writing this, SHA-256 is considered pretty reliable for these purposes.

It also depends on the intended use.  If the OP is an inventor in a nation whose patent office used "first to invent," they may want to use bitcoin to timestamp a key document, and then keep that document secret until the patent is issued or contested.  At that point, they produce the file and use the blockchain to argue its date of origin.  If the OP wishes to claim "ownership" of a file before distributing it en-masse, that's trickier.  That's effectively an NFT.  Ensuring the minter of a NFT isn't merely the first person to stick a pre-existing file on the blockchain is complicated.

@CortAmmon: First-to-invent basically doesn't exist any more.

@fraxinus the hash is good enough unless it's compromised in a way that allows creating files that you can control the hash of.

Yes, it is possible today. Have a look to https://originstamp.com/ - this service already performs it. I do not recommend you to upload your files to this site, but you will find more information there, rather in my answer

As I am new to bitcoin, I am worried whether this approach has drawbacks or not? Thanks

For an open source version of this type of time-stamping service: https://opentimestamps.org/

In addition to the services already mentioned, Proof of Existence, billed as "the original Blockchain notary service", does exactly what you are asking for (if you're asking only about existence and not possession), for a fee of 0.00025 BTC each.
Actually uploading the document to the server is not necessary; it only needs the hash, which is computed client-side. I can't vouch for whether or not what's currently on the web site secretly uploads your submissions somewhere. However, they do host their code on GitHub, so you could e.g. run your own server (or just see what exactly it puts on the blockchain, so you could do the same on your own). There is also a free API available, with which you know for sure only the hash is being submitted.

You cannot use bitcoin alone to prove something about arbitrary files, because bitcoin does not interact with arbitrary files. Any software which calculates a file hash and puts it on the blockchain could have been a software which read hashes from a website, e.g. [1], and never had the actual files.
So a verifier like a court would have to trust a combination of blockchain, custom software and your deployment of it.
[1] http://ftp.debian.org/debian/dists/bullseye/Release

This misses the point. The very existence of a hash matching a given file (which someone needing to verify prior existence has a copy of) implies that hash was with very high probability calculated from the given file (assuming, of course, a collision attack could not be used). If said hash is found in the Bitcoin blockchain, whose time stamps are very likely to be trustworthy, this then implies the given file probably existed when the block was mined, regardless of how the hash made its way into a transaction.

@ddawson Small note: broken collision resistance wouldn't be a problem in this case since you still wouldn't be able to prove you had a file that you didn't actually have at the time. Being able to prove two different files with the same hash doesn't provide any real benefit over just timestamping two different hashes. Preimage resistance is what matters here.

@VojtěchStrnad Yes, good point.

@ddawson, "This misses the point" -> To quote some parts of the question: "I already come up with such a file with such content" and "I prove that I have it at this time". This sounds like possession not pure existence. Having a hash of a file does not mean to have the file.

@Damian Well, if it is indeed possession by oneself (whether this is really necessary may depend on the nature of the file), as opposed to mere existence, then yeah, you'd need something more. Maybe take a photo/video showing your face while holding a sign with the hash of the file written on it, and put the hash of that photo/video in the blockchain. You'd need to present an exact copy of the photo/video and not a re-encoded version on a hosting site (or you could instead rely on such a site's date stamp and forgo Bitcoin), as well as a copy of the file you want to prove possession of.

No, now that I think about it some more, that wouldn't be enough either. As you said, having the hash is not enough. Proving possession now is not difficult. There are already protocols for that, but I believe they tend to be interactive, to prevent a claimant cheating. But proving it in the past is another matter.

@ddawson, you are fine. OP is not asking about "possession" (whatever that means), but is exactly interested in there exists a file with content at this point of time. Having a hash of the file together with a timestamp (as part of the Bitcoin chain) would be perfectly fine to prove exactly OP's statement in court or wherever else. Provided the judge and jury grok the meaning of hashes and the (im)probability of clashes, and the difficulty in doctoring a file to meet a given hash, of course.

@AnoE: "OP is not asking about possession". That is not true, as I have quoted other parts saying so. OP's question is ambiguous at best.

@AnoE Possession means exactly what it sounds like: possessing a copy of the file. One who possesses it can answer questions about its contents that one who only has knowledge of existence cannot, and there exist challenge-response protocols that use this property to (probabilistically) prove current possession without transmitting the actual contents. But how would one show that they possessed it at a given time in the past?

@ddawson, the question has the title "Can I use Bitcoin to permanently prove that "there exists a file with content at this point of time"?" (which was the pertinent question to me, regarding my comments). In the question, OP asks "I already come up with such a file with such content". I agree that these are contradictory terms. The question seems to leave much room for interpretation, so ... yeah. Hard to tell anything unless we know what OP wants. ;)

Ethereum could be the right choice, Bitcoin require more hassle. I developed a simple smart contract for certification as you described more than three years ago and it is still working and used by the customer. Moreover, you can label the output so that it is not required to give a lot of explanation when you need to demonstrate your certification: the smart contract “print out” all whatever needed to understand (I.e. not a simple number or hash, but a complete “legenda” of the record).

I think a source or link could be helpful here.

Yes, I agree but unfortunately surely I can mention the application here for educational purpose, but… first of all it is an Ethereum application (and this is th Bitcoin section), secondly that implementation it is property of the customer and it is not open-source. Sorry for this.

Frame challenge: this is a solved problem via Git.
The whole point of a version control software like git is to keep track of who changed/created files at what time. As such, you can show all modifications that have ever happened to a file and when they occurred.
As for the legality aspect of this, git has already been used for maintaining laws in such areas as Washington DC: https://arstechnica.com/tech-policy/2018/11/how-i-changed-the-law-with-a-github-pull-request/

It might be useful in some contexts. But there is a question of how robust this solution is. Bitcoin's blockchain is practically immutable (with exponentially increasing certainty for a given block the more blocks are added after it). Git has git commit --amend, git push --force, and other things, which are specifically designed to alter history. It doesn't necessarily work if people are keeping their own copies, but if the only copies are your own and one on a central repo like on GitHub, it's easy, or at least doable.

Yeah, as @ddawson says, the linked article and described practice of maintaining a set of law on a publicly accessible git repository don't actually compare well to what OP here is trying to achieve. The point of putting the hash of a file in a public timestamped record is to create widely distributed reliable evidence to show that the corresponding document already existed. Git commits just use the local time of the computer that generated them, so pointing at your own git repository to document the existence of something in the past would be significantly weaker evidence.


text:
Dust threshold for Testnet
I want to find a dust threshold following this answer: https://bitcoin.stackexchange.com/a/86069/134293
Actually I have a list of transactions coming from listsinceblock in which there are Testnet pubkey hash addresses (like mzzg8fvHXydKs8j9D2a8t7KpSXpGgAnk4n) of 34 bits, and Testnet script hash addresses (like 2N1SP7r92ZZJvYKG2oNtzPwYnzw62up7mTo) of 35 bits -> https://en.bitcoin.it/wiki/List_of_address_prefixes
How can I find the dust threshold for both? Maybe I need just to know how much I have in input in order to apply the formula: ([input bytes]+[34 or 35])*3

The dust threshold is defined as (output_weight+input_weight)×discard_feerate. The discard_feerate is defined as 3 s/vB. It follows that you need to know the input_weight to calculate an output's dust threshold.
This is easy in the case of P2PKH outputs, because the input has a fixed weight. It is however is impossible in the case of P2SH, P2WSH, and P2TR outputs, because you cannot tell from the address what condition script the recipient encoded in their address to spend the output later. It could be a legacy multisig, wrapped segwit, or some custom construction. In case of P2TR it could be spend per the keypath or the scriptpath which would result in different input weights.
Therefore, the Bitcoin Core code only uses two different dust thresholds:
 via https://github.com/bitcoin/bitcoin/blob/master/src/policy/policy.cpp
For all native segwit outputs, it uses the weight of the actual output plus the weight of a P2WPKH input. Note that although
nSize += (32 + 4 + 1 + (107 / WITNESS_SCALE_FACTOR) + 4);

should evaluate to 67.75 vB, since nSize is a size_t, it actually comes out as 67 vB.
This means for P2WPKH, where an output is 31 vB, the total comes out to 31 vB + 67 vB = 98 vB. This means for P2WPKH dust threshold is 294 satoshis. For P2WSH and P2TR, where outputs are 43 vB, the dust threshold comes out to 330 satoshis.
P2PKH outputs are 34 vB and inputs are 148 vB, so their roundtrip total is 34 vB + 148 vB = 182 vB, and thus the P2PKH dust threshold is 546 satoshis. Since P2SH outputs are only 32 vB for wrapped segwit and all other P2SH outputs, their dust threshold comes out to 540 satoshi.

You can look up address prefixes in this table:
https://en.bitcoin.it/wiki/List_of_address_prefixes

m… is a testnet P2PKH address
2… is a testnet P2SH address

Thank you! Is clear. But how you find that m is P2PKH and 2 is P2SH address? I did't understood

@AlfonsoSilvestri See the table linked on https://en.bitcoin.it/wiki/List_of_address_prefixes

source: Stack Exchange

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

sort: votes


text:
Who is the creator of the secp256k1 standard?
There are different accounts as to who created the secp256k1 standard, for example:
Mastering Bitcoin, p.61:

Bitcoin uses a specific elliptic curve and set of mathematical constants, as defined in a standard called secp256k1, established by the National Institute of Standards and Technology (NIST)

theymos in this thread on r/crypto:

secp256k1 isn't a NIST curve. It was created purely by SECG. SECG also publishes some NIST curves in their standards (such as secp256r1, aka P-256), but secp256k1 isn't one of them.

So who created it?
Is there a 'canonical' publication of it somewhere?

It can be found in https://www.secg.org/sec2-v2.pdf:

SEC 2: Recommended Elliptic Curve Domain Parameters
Certicom Research
Contact: Daniel R. L. Brown (dbrown@certicom.com)
January 27, 2010
Version 2.0
c©2010 Certicom Corp.

In section 2.4.1, "Recommended Parameters secp256k1".

Is it then correct to state that NIST doesn't have anything to do with the secp256k1 standard?

Yes, NIST has nothing to do with the secp256k1 standard. Some NIST-invented curves are standardized both through NIST and through SECG (e.g. NIST P-256 is the same curve as SECG secp256r1), but secp256k1 is not one of them. It was constructed by Certicom, and only standardized through SECG (SECG is basically Certicom...).

UPDATE: secp256k1 was indeed created by SECG/Certicom back around 2000 (SEC2 v2 is 2010, but v1 was 2000), but as of Feb. 2023 it is also 'allowed' by NIST for blockchain, see SP800-186 Appendix H.2 .

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


text:
What needs to be on a USB such that you could hand it to someone and gift them a discrete amount
This may be a very stupid question. I was watching an interview with Nic Carter (https://youtu.be/mDyBbGCiBUU?t=1094). In it he gives Lex a present of a USB with $100 worth of Bitcoin. What is actually on this device that allows Lex to claim the $100?
My understanding of storing Bitcoin on a USB is that only your private key is on it, and all your transactions (linked to your public Bitcoin address) is on the Blockchain, which is public, and your private key along with your public Bitcoin address allows you to claim some amount of Bitcoin. So I guess this is the first part of the question, and what is on Nic's USB is the second part...

The device that Nic gives is called an opendime. It's not a normal USB stick. The device generates a private key and a public key. At first only the public key is accessible, at this point you can only deposit to the address or lookup the current balance. In order to spend the bitcoin you need the private key, this key is only accessible after physically breaking a transistor on the device. Therefore if Lex can make sure that the transistor has not been removed he knows that Nic doesn't know the private key and has no way of spending the bitcoin after giving the device to Lex.

Thanks, so Nic has already deposited the Bitcoin to the public key generated by the opendime?

Yes! Here is a sub 10 minute tutorial

Opendimes are fantastic.
But your question was about a generic flashdrive.
That could contain the wallet data file for a specific client software.
Or Seed Recovery data to use with any BIP39 compatible wallet client.
Or just a text file with a private key and an address.
All could possibly be encrypted, requiring a passphrase.


text:
Strike says its free to send money via Lightning - how is that possible?
I was watching Strike's announcement that their API can transfer money by converting from fiat money to BTC, transferring that over the Lightning Network and converting back to fiat at the merchant. The video is here https://youtu.be/o73fWsqJDdY?t=304
But given the spread when buying and selling BTC, how is this possible? Won't the consumer have to spend more to buy the BTC that will then be converted back to fiat at the merchant?

Their FAQ makes it clear they mean no added fees. Their customers do pay any Bitcoin or Lightning fees.
Others have suggested that, to pay its employees, shareholders etc, Strike (Zap Solutions Inc) earns money from running Lightning nodes and from the spread between buying and selling prices it offers to its customers.

So that means, because of spread, if I was to use Strike to buy something in dollars for 10 dollars, I'd have to spend more than 10 dollars....or am I missing something? Im struggling to see why this is a good proposition...


text:
Fail at coding my private to public key converter (Pyhon)
Fail at coding my private to public key converter script for Bitcoin (Secp256k1)
Currently going through the book "Programming Bitcoin by Jimmy Song", got stuck on page 61 (Chapter 3), but completed the exercise 5 from chapter 3. You can view the source code here, or in Github
Even though the book is great for understanding cryptographic different concepts, highly abstracted OOP code from the book makes it somewhat harder to gaining the intuition of the fundamental low-level concepts behind key principles. That's why apart from completing exercises, I like to also code my own procedural functions that solve the same problems.
I've tried to code an ECC Secp256k1 priv-to-pub key conversion function, but my implementation... just doesn't work.
It converts numbers incorrectly.
#Secp256k1 Bitcoin private to public key converter script
a = 0
b = 7
#Order of the finite field
prime = 2**256 - 2**32 - 977
#G coordinates
gx = 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
gy = 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
#Order of the group G
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141
#n -1 => is the number of all possible private keys
privateKey = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140

def addition(currentX, currentY, gx, gy, a, b, prime):
    if gy == 0:
        return (None, None)
    elif currentX is None and currentY is None:
        return (gx, gy)
    elif currentX == gx and currentY != gy:
        return (None, None)
    elif currentX == gx and currentY == gy and currentY == 0:
        return (None, None)
    elif currentX == gx and currentY == gy:
        s1 = (3 * pow(gx, 2, prime) + a) % prime
        s2 = (gy * 2) % prime
        s = (s1 * pow(s2, (prime - 2), prime)) % prime
        currentX = (s ** 2 - 2 * gx) % prime
        currentY = (s * (gx - currentX) - gy) % prime
    elif currentX != gx:
        s1 = (currentY - gy)
        s2 = (currentX - gx)
        s = (s1 * pow(s2, (prime - 2), prime)) % prime
        currentX = ((s ** 2) - gx - currentX) % prime
        currentY = ((s * (gx - currentX)) - gy) % prime

    return (currentX, currentY)

def secp256k1BinaryExpansion(privateKey, gx, gy, a, b, prime):
    if pow(gy, 2, prime) != (pow(gx, 3, prime) + a * gx + b) % prime:
        return "The point is not on the curve"
    coef = privateKey
    currentX, currentY = gx, gy
    resultX, resultY = None, None
    while coef:
        if coef & 1:
            resultX, resultY = addition(currentX, currentY, gx, gy, a, b, prime)
        currentX, currentY = addition(currentX, currentY, gx, gy, a, b, prime)
        coef >>= 1
    return (resultX, resultY)

#privateKey, gx, gy, a, b, prime
#Smaller numbers (Not Secp256k1). Works, but incorrecly. Right output for this is: (49, 71)
print(secp256k1BinaryExpansion(8, 47, 71, a, b, 223))
#Test case 2
priv = 0x45300f2b990d332c0ee0efd69f2c21c323d0e2d20e7bfa7b1970bbf169174c82
print(secp256k1BinaryExpansion(priv, gx, gy, a, b, prime))
#Works incorrectly. The right values for test case 2:
#x = 40766947848522619068424335498612406856128862642075168802372109289834906557916
#y = 70486353993054234343658342414815626812704078223802622900411169732153437188990

The main function uses "Binary expansion" technique, but it seems like the problem lies in the "Addition" function that doesn't have it.
To see some results I copied OOP code from the book, refactored it a bit uploaded to github and it works:
https://github.com/MaltoonYezi/Python-DSA/blob/main/Cryptography/SECP256K1OOP.py
Tried to debug the 1st code by myself, but failed. If you could help, I'd appreciate it!

Your immediate problem is that you replaced the python '3-arg pow' used for modular exponentiation with separate power and modulo operations -- i.e. x ** y % p instead of pow(x,y,p). While these appear mathematically equivalent their implementations are radically different -- the pow3 approach takes microseconds while according to my very rough projections the **/% approach for 256-bit numbers will take approximately the lifetime of the universe. See cross https://stackoverflow.com/questions/14133806/why-is-powa-d-n-so-much-faster-than-ad-n and more linked there.
Your addition() function also handles the cases involving the identity element, aka the 'point at infinity', inconsistently and sometimes wrongly. Plus using pow(,prime-2,prime) to get modular inverse -- which you apparently copied from the linked book/repo -- is not the best way, but I leave it on the grounds your code won't be used for anything important or material. See How do you get a Bitcoin Public Key from a Private Key for several examples, including python, of using Extended Euclidean Algorithm for modular inverse. (added) Or I just discovered you can simply use pow(,-1,p) and python does it for you, see https://stackoverflow.com/questions/60019932/what-does-powa-b-c-do-when-the-exponent-is-negative .
However, after addition() is fixed you have a much bigger problem. I don't know where you got 'binary expansion' from since there's no such thing in ECC, but from its structure it looks like you are trying to do scalar multiplication, which is indeed the correct way to compute public key from private key. However, your logic here is almost completely wrong even used with a correct addition(). Mostly it appears you think the second point passed to addition() (as the third and fourth arguments) is always G whereas in fact it almost never is, and I suspect naming the parameters of addition() as currentX/Y, gx/y either reflects or contributes to this.
I have therefore slightly modified your addition() to use pow3 and handle the identity cases, changing the test order to simplify it some, and changed the parameter names (to simply 'one' and 'two'); and replaced entirely your 'binary expansion' with a correct scalarmult(), and it now works:
#Secp256k1 Bitcoin private to public key converter script
a = 0
b = 7
#Order of the finite field
prime = 2**256 - 2**32 - 977
#G coordinates
gx = 0x79be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798
gy = 0x483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8
#Order of the group G
n = 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141

def addition(onex,oney, twox,twoy, a,b,prime):
  if onex is None and oney is None: return (twox,twoy)
  elif twox is None and twoy is None: return (onex,oney)
  elif onex != twox: # normal addition
    s = (oney-twoy) * pow(onex-twox, prime-2,prime) %prime;
    newx = (s*s - onex - twox) %prime;
    newy = (s * (twox-newx) - twoy) %prime;
    return (newx,newy)
  elif oney == (prime - twoy)%prime: # cancellation potentially including +-0
    # (although +-0 will never actually occur for secp256k1 or any other
    # X9/SECG curve over Fp because they were chosen to have cofactor 1)
    return (None,None)
  else: # doubling (one==two)
    s = (onex**2*3+a)%prime * pow(oney*2, prime-2, prime) %prime;
    newx = (s*s - onex*2) %prime;
    newy = (s * (onex-newx) - oney) %prime;
    return (newx, newy)

def scalarmult(k, inx,iny, a,b,prime):
  outx,outy = (None,None);
  while k:
    if k&1: outx,outy = addition(outx,outy, inx,iny, a,b,prime);
    k>>=1; inx,iny = addition(inx,iny, inx,iny, a,b,prime);
  return (outx,outy);

# main routine: if run with no arguments use n-1 as private key,
# if run with one argument use that hex number as private key,
# if run with two arguments use those two hex numbers as a point
# and do just a single addition for debugging/demo purposes
import sys;
if len(sys.argv)==1: x,y = scalarmult(n-1, gx,gy, a,b,prime);
elif len(sys.argv)==2: x,y = scalarmult(int(sys.argv[1],16), gx,gy, a,b,prime);
else: x,y = addition(int(sys.argv[1],16),int(sys.argv[2],16), gx,gy, a,b,prime);
print( hex(x) ); print( hex(y) );

Also note b could be removed and not passed because it isn't used for addition or multiplication, as could a because it is zero for a Koblitz curve like secp256k1, but I left them to keep your structure.

Lol, you've completely destroyed my solution, and I thank you for that!

Apart, from this, it is good for me to learn about ECC and this provides educational value.
I wanted the script to be coded in order for it to be flexible for other elliptic curves, but the study of mine was particularly directed towards SECP256K1. That's why I kept "b" in functions.
Sorry for a delayed response


text:
What happens if a transaction is duplicated across different blocks?
I'm sure I am missing something trivial here but I have a question.
Let's say there are Node A and Node B. We send a transaction to both nodes. Both nodes now contain an unconfirmed transaction in their local mempool.
Node A includes the transaction in the next block with a successful solution. Node B accepts the new block from Node A and continues the chain by creating another new block, including the transaction it received earlier in that next block.
So we have a situation where Node A included the transaction in the first block and Node B included the transaction in the second block. How is this prevented?
I am aware of double spending but the resources I have read usually talk about the same transaction being included in the next block of both nodes but, in that case, one of the blocks would just be discarded.
Thanks.

It doesn’t matter if it’s the same or a different block, it’s still a double spend because both transactions spend the same coins.
In your example node B can’t include the transaction in the block because there are no coins to spend.

Node B accepts the new blockchain from Node A and now continues the chain by creating a new block, including the transaction it received earlier in the next block.

When node B accepts the new block from node A, it removes from its mempool all unconfirmed transactions that appear in that block. Node B will only use remaining mempool transactions in its new block.
Node B, and all other nodes, would already have removed from their UTXO lists the inputs consumed by the transaction. This means any new block containing a transaction that attempts to consume the already consumed UTXOs would be seen as invalid.
If node B didn't remove a confirmed transaction from its mempool and produced another block containing a transaction already present in the blockchain, all other nodes would reject node B's new block and node B would not be able to spend the block reward.

When someone is paid on the Bitcoin network, this happens via a transaction creating a new transaction output that locks funds to an output script the recipient can spend. Every full node on the network explicitly tracks all Unspent Transaction Outputs (UTXOs). The UTXO set can be thought of as the ledger of all balances in Bitcoin, although they're tracked in the chunks as they were created rather than e.g. "account balances".
When someone spends bitcoins, the transaction explicitly specifies which UTXOs it is spending. Each UTXO can only spent once in full. If there are any funds left over after paying the recipient(s), the sender assigns the remainder to one of their own addresses in a so-called change output.
Since UTXOs are uniquely identifiable via the transaction that created them and their position in the transaction's output list, i.e. the outpoint txid:vout, it is trivial for full nodes to determine whether funds are still available for spending. Likewise, when a transaction is included in a block that spends a specific UTXO, all full nodes update their UTXO set to mark that UTXO as spent. When a second transaction comes along trying to spend the same UTXO, it is discarded as invalid.


text:
Where does compensation to miners come from?
I am still learning so my terminologies might not be entirely accurate. But I understand that in the traditional model, if person A pays person B $10, then the banks subtract $10 from person A's account and add $10 to person B's account. This "spreadsheet" is owned by the banks. With blockchain, this transaction is recorded on a "decentralized network" of ledgers. The cryptocurrency miners dedicated their computers CPU to do number crunching to keep all copies of the ledgers synchronized. So for that, miners are compensated. Where does this compensation come from? Who pays the miners?

Possible duplicate of https://bitcoin.stackexchange.com/q/66713/51948 and https://bitcoin.stackexchange.com/q/49046/51948

As @Flow lined out, the new coins are generated "out of thin air". However this only works because the miners put a lot of computing power into the process of validating the next block (or how beginners would say: "solving the puzzle"). The bitcoin protocol makes sure, that miners devote a lot of effort (dynamically adapting so that only every ~10 minutes a new block is validated) to retrieve the block reward (currently 6.25 Bitcoin).
Additionally, every node in the network can verify very easily that the miners DID use this enormous amount of computing power (e. g. energy) to find the next valid block. This way it is ensured that only the allowed amount of coins get paid out to the miners.
So yes, the new Bitcoin are generated "out of thin air" but - contrary to our corrupt fiat money system - you have to prove that you did go through a lot of effort to receive the coins!
BTW this is why you should run your own node ;)

person A pays person B $10, all the blockchain ledgers will record that transaction, i.e. subtract 10 from person A's account, add 10 to persons B's account.

There are no accounts in the Bitcoin network. Bitcoin is cash, not a bank account.

The Blockchain is a transaction journal, it is not like an accounting ledger.

Bitcoin nodes do not keep track of other people's "balances". They only keep track of unspent coins (unspent transaction outputs or UTXOs).

For A to send 10 BTC to B, A has to find one or more coins whose values sums to more than 10 BTC. Lets say they have a coin worth 13 BTC. They include in their draft transaction one input coin of 13 BTC and two output coins of 10 BTC to B and 2.99 BTC change to themselves. The remainder 0.01 BTC is collected by the miner as the transaction fee.

As well as collecting the transaction fees for all transactions in the block they have mined, the miner also gets to create a totally new amount of money called the block reward or mining reward.

Each block must include a coinbase transaction. The coinbase transaction must be the first transaction in the block and pays the block reward to the block's author. It is also special in that it does not spend a UTXO in its inputs and that only coinbase transactions may have a bigger total value for the outputs than its inputs.
The compensation of miners is composed from two sources. Each block mints a limited amount of new bitcoins and collects the transaction fees of the transactions they include in it.
The block subsidy started at ₿50 per block, and halves every 210,000 blocks. We're between the third and fourth Halvening. Currently, each block mints ₿6.25 new bitcoins. The block subsidy doubles as both the initial distribution mechanism of all bitcoins and as an incentive for miners to secure the Bitcoin network while it is bootstrapping.
The second part of the block reward stems from the transaction fees. Since Bitcoin blocks are limited to 4,000,000 weight units (WU), users bid on the available blockspace by offering transaction fees. Most nodes only relay transactions paying at least 0.25 satoshi/wu, which means that a full block should collect at least 40 mBTC in transaction fees. When a lot of transactions are competing for inclusion in blocks, the feerates of transactions can be significantly higher than this, though. E.g. for the first half of the 2021, the queue of unconfirmed transactions never emptied out completely, and transaction fees amounted to more than ₿3 on several blocks.
As the block subsidy continues to halve, the transaction fees will make up an increasing amount of the total block reward—unless people stop transacting on Bitcoin.

No one is paying the miners. The bitcoins of the block reward, found in the coinbase transaction, is created by the miners out of thin air. After all, this is how bitcoins are generated.

Compensation from miners comes from two concepts:

The Block Reward on blocks they validate, whereby new coins are minted for the miner, in accordance with the blockchain's protocol. Bitcoin's current  reward is 6.25 BTC. (The reward began at 50 BTC and is halved every 4 years.)

Transaction Fees granted by users. On each transaction included in a block, users may specify a fee amount which goes to the miner, as an enticement to include the user's transaction in the block assembled by the miner.

Blocks have limited space for transactions, so miners will sort "transactions waiting to get on a block" and fill their block with the highest fee-paying transactions first.  These transactions waiting to be confirmed (so called Mempool transactions) are only confirmed when included in a miner's block, and that block is validated & added to the blockchain by consensus of the majority of mining peers.
Until mempool transactions are added to a block, they are essentially only "transaction requests" by users. These transactions requests become official only when they are included in a block, and final only when the block they are included in is at least several blocks deep (6 is the usual number suggested). This is because blockchain forks can happen, but as new blocks get added to the chain, it becomes exponentially more difficult for a fork to orphan previous blocks.
It is worth noting that there is only one, unique, so-called 'coinbase' transaction in each block. It is in this Coinbase Transaction that the miner awards themselves the Reward coins, plus the sum of the fees of the other, regular transactions the miner is including in the block. If the miner is first to validate their block and it gets permanently added to the blockchain, they will have earned the total amount awarded themselves in the coinbase transaction.

Both the transaction fees and the block subsidy are collected via the coinbase transaction.

Edited to show that coinbase transaction includes both reward amount and transaction fees together.


text:
Does 12 word Mnemonic seed + passphrase wallet get recovered w/o the passphrase?
I recently bought an Ellipal Titan, I was playing around with it to get used to the wallet.

I created a wallet with 12 mnemonic + passphrase.
I erased the wallet.
I tried to recover the wallet with the same 12 word key + different passphrase.
I was able to recover the original wallet with the different passphrase.

I wonder how this happen. Is it supposed to that way, or Titan is messed up? It seems as though using passphrase does not affect the security at all. Any idea?

This is not supposed to happen, different passphrase should lead to a different wallet

Did you verify that it was the same wallet or just some wallet?

If I remember correctly, the Ellipal Titan creates two wallets, one with the passphrase and one without. This allows some deniability if needed -- you can claim you didn't even know about the passphrase feature and show a wallet that even has some funds while hiding the real wallet -- the one protected by the passphrase.

The wallet created from mnemonic only is a completely different wallet, no connection at all to one created with an added passphrase.
Maybe that client is creating two wallets for "wrench attack" deniability, and you are looking at the mnemonic-only version both times.
Go to iancoleman and play around, check out the addresses created in the three different wallets.

Unless they mean password instead of passphrase they are not following bip39 specification. A different passphrase changes the BIP39 seed used to generate the deterministic key chain.
https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
https://en.bitcoin.it/wiki/Seed_phrase#Two-factor_seed_phrases

OP seems to be talking about the passphrase as something distinct from the seed phrase/mnemonic. I'm speculating, but is it possible the wallet uses the passphrase to encrypt the mnemonic on the device/system? So only the mnemonic defines the wallet, but it's locally protecting the wallet with the passphrase.


text:
Would reusing addresses result in a lower fee?
Let's say you withdraw 100 times from an exchange using a different address each time for a total sum of 1 BTC.
Now you want to move this entire BTC to a new address.
This would result in a transaction with 100 inputs.
Wouldn't you pay a way higher fee because the transaction size is higher due having to use 100 different inputs compared to if you just used the same address to receive these 100 withdraws?
Sure, you gain on privacy but if it's not relevant in this case, wouldn't it be better to reuse the same address and save on fees?

Addresses do not exist at the protocol level. You'll pay exactly the same fee whether you used the same or different addresses to withdraw. What matters is that there are many outputs you have to spend; whether those are assigned to the same addresses or distinct ones is a human abstraction - for the protocol it makes no difference.
To explain, it's important to see that Bitcoin does not have anything you could call an "account model". It is more like cash: every transaction gives you one or more coins (or various values) and "uses" previously created coins. These coins are also called UTXOs: unspent transaction outputs.
For example, if you pay me 1 mBTC twice (to the same address, or to different addresses), I will have in my wallet two coins of 1 mBTC each. If I now want to pay someone else 1.5 mBTC, I (or my wallet software, transparently) will construct a transaction that consumes both 1 mBTC outputs/coins/UTXOs, and creates two new ones: one valued 1.5 mBTC assigned to the payee, and perhaps 0.49 mBTC to another output back to myself (usually a fresh address, called a change address), and the remaining 0.01 mBTC is turned into fees.
Why do I mention that addresses don't exist at the protocol level: they are just shorthand notations for locking scripts. Every coin/UTXO/output has an embedded script that defines the conditions under which it can be spent. When a transaction spends multiple outputs, it needs to satisfy the conditions for all of them.
It would be possible to define a protocol improvement that allows spending multiple outputs to the same script at reduced cost, by permitting a single signature that signs for all inputs at once. This hasn't been done for two reasons:

Research around Cross-Input Signature Aggregation (CISA) will likely make this sort of benefit available to any inputs, even when they're using different addresses.
It would institute an incentive to adopt privacy-damaging practices.


text:
Did Satoshi make any kind of "farewell speech" before leaving?
As I understand it, Satoshi has not posted anything online for many years now. Exactly when the last time was is apparently fuzzy.
Assuming that he didn't die (or was murdered), would he not have made some sort of statement along the lines of:

This is my last message. I will now withdraw forever, putting the Bitcoin revolution in the hands of you all. Please don't disappoint me.

? Did he really just stop posting/discussing one day? It seems like such an odd behaviour if it really was like that.

Pete Rizzo wrote an in-depth piece on Satoshi's disappearance a few months ago: https://bitcoinmagazine.com/technical/what-happened-when-bitcoin-creator-satoshi-nakamoto-disappeared

I'm surprised no-one's mentioned his email to Mike Hearn on the 23rd of April 2011, where he said that he had "moved on to other things". It was a personal email, but it was the closest thing to a farewell he sent to anyone:

From: Satoshi Nakamoto satoshin@gmx.com
Date: Sat, Apr 23, 2011 at 3:40 PM
To: Mike Hearn mike@plan99.net
Subject: Re: Holding coins in an unspendable state for a rolling time window

I had a few other things on my mind (as always). One is, are you planning on rejoining the community at some point (eg for code reviews), or is your plan to permanently step back from the limelight?

I've moved on to other things.  It's in good hands with Gavin and everyone.
I do hope your BitcoinJ continues to be developed into an alternative client.  It gives Java devs something to work on, and it's easier with a simpler foundation that doesn't have to do everything.  It'll get critical mass when impatient new users can get started using it while the other one is still downloading the block chain.

Source
The only other email he sent after this date was one to Gavin Andresen on the 26th of April 2011, the day he is widely regarded to have "disappeared" (note that this email was quoted by Gavin in an interview):

I wish you wouldn’t keep talking about me as a mysterious shadowy figure, the press just turns that into a pirate currency angle. Maybe instead make it about the open source project and give more credit to your dev contributors; it helps motivate them.

Source
Beyond this, there are two heavily disputed communications that may have occurred since 2011: The 2014 P2P foundation post, and the 2015 cryptography mailing list post. While never definitively disproven, these posts are regarded with high scepticism in the Bitcoin community (and rightfully so).

There are no records of Satoshi making a proper goodbye. In 2010, Bitcoin discussion primarily took place in the forum on Bitcoin.org. This has since been transferred to bitcointalk.org, but all of the posts remain. You can see from Satoshi's profile that the last post made was in 2010 and was not a goodbye but a post discussing changes to the software.
Some people claim to have been contacted by Satoshi afterwards, but these cannot be confirmed. I don't think such communications would be considered a goodbye either.


text:
Sended from Blockchain to Jade and nothing on account
Five days ago, I transferred a small amount of BTC from my Blockchain.com account into my Jade Green wallet.
Next day and my Blockchain account was empty and was record for transferring all my BTC.
On Jade was only record for receive small amount like intended.
Now no sign of my whole BTC amount on any account, just growing number of confirmations on Jade explorer and unspent on spending tx.
Sorry to bother you, but I am rookie in this field and looks like I lost my retirement savings.

When you make a bitcoin payment, the transaction will usually have two transaction outputs. One output going assigning the requested payment to the recipient and a second change output that sends the remaining amount from the inputs back to the sending wallet. If you inspect your transaction, you should see the small amount that you sent to the Jade and the change going back to your Blockchain wallet. If this transaction is still unconfirmed, it may look on your wallet like it is not part of your spendable balance. If the transaction is confirmed and you see the expected outcome in the Jade, but not in your Blockchain wallet, your wallet may be out-of-sync. Try to verify that the wallet is caught up to the network, or otherwise try to get it to synchronize.


text:
Are UTXOS added to the UTXO set instantly after a transaction is created or after the transaction is mined?
If a UTXO is not added to the UTXO set before transaction is mined, how is a chain of unconfirmed transactions created? Where are the inputs taken from?
PS: I am making a blockchain from scratch. It would be really helpful if you can explain the transaction implementation considering all the possible cases.

Bitcoin Core maintains the set of unconfirmed transactions it knows about in the mempool. The mempool data structure tracks which UTXOs are consumed and created by those unconfirmed transactions. When a new transaction comes in, it will find outputs either in the UTXO set, or in the pending outputs in the mempool.
Naturally, any transaction that gets included in a block must only spend UTXOs that were created before it is spending them. Thus, any parent transactions must appear in the block before a corresponding child transaction.


text:
Does an unconfirmed transaction lock UTXOs?
Let's say A has an output of 5 BTC in the UTXO set. He creates a transaction where he uses the 5 BTC to send to B. Now the unconfirmed transaction goes to the mempool. Will the 5 BTC output be deducted (locked to B's address) from the UTXO set while the transaction is in the mempool (unconfirmed)? If no, can A again use the 5 BTC from the UTXO set (double-spending?)?

There is no "the" UTXO set.
The UTXO set model is a way of thinking about the state of the Bitcoin blockchain, and something that guides development. But it is generally not materialized as an actual data structure in its entirety, and there isn't just a single one.
Internally in Bitcoin Core, UTXO sets are represented by the abstract CCoinsView class. There are multiple implementations for it:

one that's backed by an on-disk database.
one that's backed by a set of cached in-memory changes on top of another UTXO set (used to represent the UTXO set of the currently-active blockchain).
one that's backed by the mempool on top of another

When validating loose transactions that are being relayed and accepted into the mempool, the mempool's UTXO set is used (which consists of all UTXOs in the currently active block, plus implicitly all outputs from mempool transactions added, plus implicitly all inputs from mempool transactions deleted).
When validating a block, the UTXO set corresponding to the currently active block is used, which does not include the implicit changes due to the mempool.

To answer your questions:

Will the 5btc output be deducted(locked to B's address) from the utxo set while the txn is in the mempool(unconfirmed)?

From the mempool's implicitly-defined UTXO set, yes. From the blockchain's UTXO set, no.

If no, can A again use the 5BTC from the utxo set?

That's unrelated to how the database is modeled, but governed by mempool replacement policies. Using RBF (replace-by-fee) it is in some cases possible to replace a mempool transaction with a higher-feerate one. This happens before validation against the mempool's UTXO set happens.

Bitcoin Core nodes keep track both of the UTXO set and the unconfirmed transactions in their mempool. When a UTXO is spent, generally the owners can spend it again, but that creates a conflicting transaction. Only one of the two transactions can be included in a block. If both transactions are broadcast, the first will be replaced by the second if the second transaction both pays a sufficiently higher total fee and a sufficiently higher feerate.


text:
How to remove abandoned transactions from the transactions history?
I'm trying to create a transaction using bitcoin-qt from Bitcoin Core but I have a bunch of abandoned transactions in my transactions history that appears in "walletconflicts" key in the output of gettransaction command. Additionally, I tried to remove the mempool file inside .bitcoin directory and restart bitcoin-qt but it didn't work as it seems to live in the wallet.dat file instead of the mempool file.
How could I remove those abandoned transactions so it doesn't appear as wallet conflicts?

Abandoning a transaction does not delete it from the wallet. It only lets the wallet know that it can ignore the transaction when constructing new transactions. They remain in the wallet in the event that the transaction is rebroadcast (possibly by someone else) and therefore has the possibility of confirming. They are otherwise okay to leave in the wallet and they can be ignored.
Transactions can be forcibly deleted from the wallet file by using the removeprunedfunds RPC. However, be very careful with this as removing transactions that are still relevant can result in the wallet misbehaving, such as accidentally double spending already spent outputs, or showing and incorrect balance. Only do this if you are sure the transaction is irrelevant (i.e. all outputs already spent, transaction is conflicted, etc.). It is otherwise okay to leave irrelevant transactions in the wallet.
In your case, because the transactions are marked as abandoned, they are not entirely irrelevant. They can still be revived if someone were to broadcast them again. As such, I would advise leaving the transactions alone. You can remove them once they become conflicted. For that to happen, another transaction spending the same inputs needs to become confirmed.


text:
I found a list of 25 words on my old desk in my mothers house. Is there any way to know how to recover this?
I just found a list of 25 english words (not my native language) on a white paper in my mother's house. This has to be old, because i don't touch that desk for a long time, 10+ years.
I have been searching for some info, regarding the 25 seed phrases but i dont have any conclusive anwser.
I found the BIP0039 dictionary, but the problem is that half of my words are not on this list.
Words like, flute, salute, point, are not on the BIP0039.
I dont know what coin it belongs neither what wallet i used back then. I rembember waiting 1 day to syncronize the blockchain to my computer, but i already tried the Bitcoin core wallet, but it doenst have any seed phrase recovery option.
Are there any other dictionaries i can compare my list with, so i can guess what coin this wallet refers too ? What steps would you take to find out ?
Thank you all.

Perhaps the words that are not on the list are decoys? Have you tried just using the words that are on the list?

The Electrum wallet was published in 2011 and originally used it's own recovery-phrase AKA seed-phrase system before BIP-39 was written. Their system did not use a fixed word list.
I suspect a 25 word phrase is likely to be a 24-word seed-phrase plus one passphrase.
From what I have read, Electrum seed phrases had 12 words not 24. Maybe there was a choice in the 2011 version?
I would try Electrum anyway.

https://bitcoinelectrum.com/restoring-your-standard-wallet-from-seed/

https://bitcoin.stackexchange.com/search?q=electrum+seed

Thank you for your anwser. I just tried the Electrum wallet, and it matches more words than the BIP39 one, but not all. Like 2 or 3 are still not found.
But thank you, i fell a bit closer :)

It could be old blockchain wallet recovery phrase. Old Blockchain.info legacy wallets can use from 15 to 25 words. Some of them are not a part of the BIP39. They had their own very big list. They started using BIP39 standard in 2016. It's not that obvious to recover that wallet.
Do you have any other information on that white paper?

No, only a 25 word list :(

that's enough. I've dealt with few similar cases before feel free to hit me up


text:
I Can't Get Inbound Connections to My Node
I recently set up a Bitcoin Core Node on a Raspberry Pi. It is fully caught up to the chain tip and has 10 outbound connections. I am using bitcoind to configure the node and have not been able to get inbound connections. Here are the steps I've taken:

Firewalls are turned off.
I've set up port forwarding on my router to port 8333.
I've added listen=1 and discover=1 in bitcoin.conf
I created a static ip address on my router.
I rebooted the router and bitcoind.
Checked my ISP for blocked ports and 8333 is not blocked.

When I check bitnodes.io, I get a message that port 8333 is unreachable. Any help would be greatly appreciated.

I was unaware that Uncomplicated Firewall ufw was installed on my Raspberry Pi. When I ran the command below I found the following.
sudo ufw status verbose

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
22/tcp (v6)                ALLOW IN    Anywhere (v6)

This showed me that is was active and only allowing action from port 22 for SSH. To correct this I opened ports 8333 for MAINET and 18333 for TESTNET with the following commands.
sudo ufw allow 8333 comment "Bitcoin mainnet"

sudo ufw allow 18333 comment "Bitcoin testnet"

This change the ufw configuration to the following and now inbound connections have been created.
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
22/tcp                     ALLOW IN    Anywhere
8333                       ALLOW IN    Anywhere                   # Bitcoin mainnet
18333                      ALLOW IN    Anywhere                   # Bitcoin testnet
22/tcp (v6)                ALLOW IN    Anywhere (v6)
8333 (v6)                  ALLOW IN    Anywhere (v6)              # Bitcoin mainnet
18333 (v6)                 ALLOW IN    Anywhere (v6)              # Bitcoin testnet


text:
How does a sender routing a payment using a blinded path know what the fees are needed in the blinded portion of the path?
How does a sender routing a payment using a blinded path know what the fees are needed in the blinded portion of the path? Are some net fee hints somehow included in the blinded path? For a normal un blinded path, the sender should know the path they are constructing and know the fees that are expected on each hop (because each node advertises their fees).
Most routing algorithms have a tradeoff of trying to find a route quicker at higher probability with payment of higher fees vs trying to get the payment to route potentially more slowly at a lower cost, but lower probability of success. I'm not sure how this can be accomplished with blinded paths.

I think the amount (including the fees for the blinded path) that have to arrive at the rendezvous point will be included in the blinded path that is being communicated. The sender cannot trade fees for probability within the blinded path. In fact he has to hope the recipient knew the blinded path can forward the payment if the sender can bring it to the rendezvous point

I think you are right. Here are some comments in BOLT4: https://github.com/lightning/bolts/blob/247e83d528a2a380e533e89f31918d7b0ce6a0c1/04-onion-routing.md?plain=1#L587 and https://github.com/lightning/bolts/blob/247e83d528a2a380e533e89f31918d7b0ce6a0c1/04-onion-routing.md?plain=1#L619 .


text:
Incorrect passphrase after cancelled transaction
Bitcoin Core after sending the transaction showed the incorrect balance and the transaction was cancelled. During that incorrect balance there was a sending operation after which the bitcoin core started giving a message about incorrect passphrase, but passphrase is correct, since the account has been used for many transactions for more than a year, and there was no issue with the passphrase before. How can I fix this problem? I need to send BTC to another account.

How can I fix this problem

I would

Check that I don't have multiple wallets
Check that I am loading the right wallet.

Then

Make a safe copy of the problematic wallet.dat
Temporarily suspend my regular backup processes.
Make a careful inventory of both onsite and off-site backups of wallet.dat or which contain it.
Select the backup closest to the point in time the problem first appeared
Restore and test that backup
Repeat for progressively older backups until one succeeds.
If none succeeded and the amount in the wallet was less than a month's income I would write it off and stop.
Spend time thinking up variations of the passphrase, old passphrases, etc.
If the amount involved was several years income I might study the file format in my spare time to see if there was any possibility that malformation could cause the problem. Maybe create modified copies and prune early keys. This would be a pretty hopeless step.


text:
Connecting bitcoind and BTC RPC Explorer in docker
Apologies if this isn't so much a bitcoin question, as a docker or RPC explorer one. Although my trouble seems to be correctly exposing bitcoind RPC so I'm hoping someone might be able to illuminate where I'm going wrong.
I'm trying to run bitcoind and RPC Explorer in docker containers, so far bitcoind is running successfully and fully synced to chain. But I can't get the RPC connection to work for the Explorer. To keep my setup as simple as possible I'm trying to pass all the relevant environment variables to each container using docker compose as follows. The Explorer runs, but cannot connect to RPC:
services:
  bitcoin:
    container_name: bitcoind
    user: 1000:100
    image: lncm/bitcoind:v27.0
    environment:
      BTC_DISABLEWALLET: 1
      BTC_SERVER: 1
      BTC_RPCUSER: $USER
      BTC_RPCPASSWORD: $PASS
      BTC_RPCBIND: 0.0.0.0
      BTC_RPCPORT: 8332
    volumes:
      - /TIMECHAIN:/data/.bitcoin
    restart: on-failure
    stop_grace_period: 15m30s
    ports:
      - "8333:8333"
      - "8332:8332"
      - "28332:28332"
      - "28333:28333"
    network_mode: host
  explorer:
    container_name: btc-rpc-explorer
    image: tyzbit/btc-rpc-explorer:latest
    user: 1000:100
    environment:
      BTCEXP_HOST: 0.0.0.0
      BTCEXP_PORT: 3002
      BTCEXP_BITCOIND_HOST: localhost
      BTCEXP_BITCOIND_PORT: 8332
      BTCEXP_BITCOIND_USER: $USER
      BTCEXP_BITCOIND_PASS: $PASS
      BTCEXP_SLOW_DEVICE_MODE: false
    restart: on-failure
    ports:
      - "3002:3002"
    network_mode: host

networks:
  default:
    driver: bridge

Can you get an RPC response from bitcoind using curl?


text:
How to get my bitcoin out of Mycelium?
I want to leave Mycelium. I have heard nothing but that it’s Jurassic. I would like to use a new wallet. I have no idea what wallet to use but I have like $48 in bitcoins. I know it’s not a lot, but I just wanna move it out of there. Every time I try to send and receive, it is saying that I only have four dollars to spend when I have $48 to spend, so I don’t know why their fees are so high. I just wanna move my bitcoins. How can I do that?

When you build a transaction, is there a way to set your own feerate? Alternatively, could you check the wallet options to see if there is an option to turn on custom feerates? Then you could check on e.g. mempool.space for a feerate estimate and put in your own feerate estimation.


text:
How does one verify signature in a P2WPKH transaction?
(Assume there's no OP_CODESEPERATOR)
For standard P2PKH, the signature digest is generated this way:
NewTransaction

settle the TxOuts well
set all TxIn scripts to empty
insert the Previous Locking Script into the TxIn you are signing
append hash type code to the end of the transaction
SHA256 twice this transaction
Be a digest.

What does one do for signature verification of p2pwkh?
It would be helpful if you can provide with some docs related to algorithm or some basic code would also be appreciated

The signature verification algorithm for P2WPKH and P2WSH is specified in BIP143, which also includes a reference C++ implementation.
P2WPKH inputs are scriptless so they can't have an OP_CODESEPERATOR.


text:
Which index in Bitcoin Core is useful for self-custody wallets?
I am setting a new full node for self custody. But I don't know which index I should enable in Bitcoin Core. If I want to make wallet re-scan faster, and don't want unnecessary storage/operational burden, which index should I enable?
I used to believe that -txindex is useful, but I never confirm (and now I find this index is really big). What about block filter index and Coin Stats Index?

None of the indexes are necessary for wallet operations.

Does any one of them help? I will use Sparrow Wallet or Electrum Personal Server instead of  default wallet function of Bitcoin Core. Can compact block filters speed up re-scan?

If you use a different wallet than Bitcoin Core's then that's different. Usually this involves using another software on top. Please ask another question if you've got more questions.

Thanks very much.


text:
What is the correct way to calculate testnet BTC fees?
Recently, the fees on Testnet seem to be going wild. I tried to send 20,000 satoshi and it cost me 27,000 satoshi. I used a feerate based on blockstream.info's fee estimate and calculated the fee using tx.virtualSize() * estimatefee.
What is the correct way to calculate testnet btc fees?

I'm voting to close this as there doesn't seem to be a question to answer.

sorry for that, i edit it and put my question


text:
What determines how long a HOLD invoice will be held before it times out and is forced on chain?
How long can a HOLD invoice be held before it times out and is forced on chain?

Is there a way for the receiver to define a minimum timeout requirement in the invoice in order for it to be successfully paid?
Is the sender able to know the timeout amount before or after sending?
Is the sender able to define the timeout amount before sending?
Is this timeout dependent on the route the sender selected?
Is the receiver able to determine the timeout amount once they have received the HTLC?
Is the timeout something that can be adjusted after a channel is opened or can it only be defined when a channel is opened?

@Murch, I don't appreciate you changing my question from HOLD to HODL invoice. HODL i the slang term. Please see the following examples where HOLD is used:

https://lightning.engineering/api-docs/api/lnd/invoices/add-hold-invoice

https://voltage.cloud/blog/lightning-network-faq/understanding-hold-invoices-on-the-lightning-network/

http://buildonln.com/advanced/hold_invoices.html

https://bitcoinops.org/en/topics/hold-invoices/

Mea culpa, I had only heard to it referred to as "hodl invoice" before. I’ve rolled back your post to your original variant

No problem, I think it helps to have both in the comments now for search ability since there is some people using both.


text:
What are outgoing and incoming connections and what is the difference between them?
Why do we have two types of connections, outgoing and incoming? What is the purpose of one and the other? Are outgoing connections the ones where we notify of new blocks/transactions, while incoming connections are the ones where they notify us of new blocks/transactions?
When we do the initial synchronization (IBD) or completely randomly want to ask about a block or transaction or something third, is it done with outgoing connections or incoming connections?

There's a overlap with this post and others but I'll try to directly correct a couple of things here.

Why do we have two types of connections, outgoing and incoming?

To risk stating the obvious sometimes our node will make a request to connect to another node (outbound) whilst other times a node will make a request to connect to our node (inbound). In a healthy peer to peer (P2P) protocol you can't really avoid having both outgoing and incoming requests. The extent to which outbound and inbound connections are treated differently by your full node is a more interesting question. These Bitcoin Core PR review club notes (June 8th 2022) on inbound block-relay-only connections stated:

Once the connection is established, the relationship is largely symmetric (the protocol works the same in both directions), although we treat outbound peers with some preference.

If you are concerned about malicious full nodes you might have some trusted or semi trusted full nodes you choose to connect to (outbound) whilst presumably all inbound connection requests are from nodes you know very little about.

Are outgoing connections the ones where we notify of new blocks/transactions, while incoming connections are the ones where they notify us of new blocks/transactions?

No, both outbound and inbound connections can notify your node of new blocks and transactions and vice versa. That PR review club I referred to does discuss block-relay-only peers which is where you decide to only relay blocks to certain peers and not transactions, IP addresses. Inbound connections can also indicate they don't want to receive transactions etc.

When we do the initial synchronization (IBD) or completely randomly want to ask about a block or transaction or something third, is it done with outgoing connections or incoming connections?

Both. If we aren't aware of any peers/connections (ie we have no connections at all) at the beginning of IBD we might need to utilize DNS seeds to learn of potential peers.
edit: Thanks to lightlike for pointing out this comment in the Bitcoin Core code on IBD usually only being done with outbound peers

If we don't have any outbound
peers, or if we aren't downloading any blocks from such peers, then
allow block downloads from this peer, too. We prefer downloading
blocks from outbound peers to avoid putting undue load on (say) some
home user who is just making outbound connections to the network, but
if our only source of the latest blocks is from an inbound peer, we
have to be sure to eventually download it (and not just wait
indefinitely for an outbound peer to have it).

I see you use the term "outbound" instead of "outgoing" and "inbound" instead of "incoming", are those actually the standard terms used in the Bitcoin world and not "incoming" and "outgoing"?

@MudjaAdum there are no standards because there is no real standardizing body. Nor should there be. There are commonly used terms but I find there is a great deal of variation and ambiguity. The variations you ask about both seem common usage to me.

IBD is usually only done with outbound peers, only in some rare situations (see https://github.com/bitcoin/bitcoin/blob/master/src/net_processing.cpp#L5539-L5547 for an explanation) inbound peers are used.

A node will generally not get any inbound connections before it is fully synced. @Lightlike: Do I remember correctly that our node will announce new transactions from its own wallet only to outbound connections?

@Murch: Yes, we don't actively advertise our address while in IBD, so inbound peers are less likely to happen. But if they do know about our address for some reason, we don't prevent them from connecting.
I don't think that we distinguish between in and outbounds when broadcasting wallet transactions.

btccore won't list any incoming connections until it's synched. But the network config plays a large part in that. The log file will probably show if there are attempts to connect as incoming that are failing for some reason, but I've found the solution can be as simple as using my 5G phone instead of whatever you're using for a wan interface. btccore usually takes somewhat longer (< an hour) after startup, and you have to have the "allow incoming network connections" flag on. Having trouble with this with LTC but I expect because LTC syncs so much faster than BTC.


text:
Legitimate merkle paths for SPV
How does a light client via SPV make sure that the requested merkle path is not fake?
I know that the client has its own copy of the block headers, so it can trust the merkle root from there. It then queries a full node for the merkle path, calculates the merkle root from that, and finally compares the reference merkle root with the calculated one. If both are the same, the client can be sure the transaction was included, even if it does not trust the full node, since there is no way for the full node to engineer the same merkle root from different data. So far so good.
However, how can it trust the received path in case both merkle roots do not match? The full node could send a fake path, which then leads to a different merkle root upon verification, which let's the client assume the transaction was not included when in reality it might have been included.
Can someone please clarify?
Thanks :)

UPDATE: Thanks to the answers and many comments I now understand that SPV via merkle root does not prove non-inclusion of a transaction in a specific block. In can only prove inclusion. In case the merkle roots match, we can be sure that the transaction is included in the block. If the merkle roots do not match, then the transaction could be included (fake path received) or not (legitimate path received), we don't know for sure.
In order to prove inclusion AND non-inclusion, it is probably easier and more secure to just have the transaction data of the block in question, received from a trusted full node.
Other 'workarounds' could be to:

trust the server
query multiple servers
ignore the merkle root mismatch (do nothing, notify the user)

Finally it turns out that merkle trees are not really that useful since SPV does not really work the way it was supposed to and that's why it is rarely used. A simple hash over all transaction would have worked as well.
Another addition, thanks to  @Pieter Wuille for the hints: A possible advantage of using merkle trees would be that inclusion can be proved by just a single legitimate path when querying multiple servers, because a valid merkle proof cannot be faked. That means all non-matching proofs (when querying multiple servers) can just be ignored in case there is a single one that matches.
Thank you everybody for the help!

How could it be faked? The Merkle path proves the leaf was committed to by the root in the header. To come up with a fake path that verifies correctly would need breaking the security of the hash function to construct the tree.

Or is your question about the Merkle root itself? The SPV client must have its own headers chain already which it trusts, and it will only accept Merkle paths that connect to one of these headers. If the Merkle root isn't the root included in one of its trusted block headers, it won't be accepted.

@PieterWuille. The fullnode could make the client intentionally assume that the transaction was not included when in reality it was. That means the fullnode wants the client to fail the merkle root comparison. A failed comparison means the transaction was not included, or am I getting something wrong?

Oh, yes, SPV proofs only prove inclusion, they cannot prove exclusion. This is one of the limitations of BIP37, and why it's not really used anymore.

@PieterWuille. So you say it is not used anymore? Why was it invented in the first place? What is the alternative?

There isn't a clear cut answer. I think SPV-style wallets in general just get used less these days. Merkle proofs are still used in protocols like Electrum, but that involves clients talking to Electrum-specific servers (which can be self-run, rather than being random untrusted full nodes). For some use cases, client-side filtering (BIP157) is a replacement (better privacy than BIP37, though not a fundamental solution to lack of exclusion proofs, but does allow a client to know when two servers claim distinct things).

re. "A simple hash over all transaction would have worked as well.", well, then miners would have to keep re-hashing the whole block whenever they update any 1 TX in the block template. With the Merkle structure, they only need to hash few 100 bytes for any single TX update.
Also note that proof of exclusion would be possible if the structure of the tree would be changed (look up "Merkle prefix trees") - this would require a soft fork. However, servers could still omit transactions, and you'd have to query a big enough set to have high confidence that nothing is missing.

If the calculated Merkle root doesn't match any of the block headers then the proof is invalid and the TX may or may not exist.
That's the default verification state, same as if you never got any proofs.
If someone gives you an invalid Merkle proof then you don't learn any new information.
Merkle proof can prove inclusion in some block, but it can NOT prove non-inclusion.
You need all block headers in order to verify the Merkle proof.
A valid proof will match exactly one block header in the header chain of the blockchain you're verifying against.
If there are no matches, then the proof is invalid for the blockchain you have headers for.
It could still be a valid proof for some other blockhain (like a fork of Bitcoin, and with exact same header format & Merkle tree computation).

Thanks. I don't get the point of SPV then. Doesn't a light client also need a proof of non-inclusion? What would a light client do if the merkle proof fails?

@ieggel The merkle proof wouldn't fail (if it does, the client could show an error to the user, who could get suspicious). Instead, a server can just claim there is no transaction, so there isn't even a proof to give. And the result would be that the client doesn't know about a transaction. The solution is either trusting the server, querying multiple servers, ignoring this failure mode, or using a different architecture (e.g. not using SPV at all, and e.g. using a full node wallet).

Thanks @PieterWuille. I don't get why SPV is 'marketed' the way it is then. In my opinion  a client NEEDS to know if a transaction was not included. Querying multiple full nodes makes sense, but even then I guess it's not fully trustable. Ignoring  the failure just means accepting the transaction was either included or not included, which would be the same as not querying at all. Connecting to a trusted full node seems the only way. But SPV was invented so no trusted full nodes are required, if I got it right. Has Satoshi not taken this into consideration, which seems weird?

It's hard to speculate about the intentions of someome who disappeared a decade ago, as we have no idea about their reaction to evolved understanding since. The SPV design as presented in the white paper just fundamentally doesn't work (it relies on fraud proofs for security, but misses that attackers can always withold data that would let someone disprove it). The SPV protocol that was actually implemented on the P2P layer (BIP37) came years after Satoshi disappeared, and its independent problems (the one you point out, but even more its privacy) became clear even later than that.

Thanks for all the insights @PieterWuille. I've been studying bitcoin for 2 weeks now and started reading about merkle trees and SPV last week. I always had the impression that it does not make a lot of sense the way it was described and I was sure that I must be missing something. It's just incredible that it was not obvious for the developers from the very beginning. Now I am wondering why merkle roots are used in the block header and not just a hash over all transaction hashes, or something alike. Do some full nodes get rid of the transaction data itself and inly keep the headers?

Yes, it's possible to run a node that doesn't keep the block data (called a pruned node), but that's not incompatible with just hashing the list of transactions either. Truth is, the protocol uses Merkle tree simply because it always has (and likely because the system's creator envisioned SPV to be used differently than it is today). Unless there is an extremely good reason to change it, there is no way such an invasive protocol change would happen. At worst, Merkle trees are slightly slower than using a flat list of hashes. At best, the inclusion proofs are useful somehow. No harm done.

FWIW Satoshi imagined SPV to be used when someone pays you and wants to directly prove to you that he paid you, and he imagined here something like Electrum protocol: "The simplified payment verification in the paper imagined you would receive transactions directly, as with sending to IP address which nobody uses, or a node would index all transactions by public key and you could download them like downloading mail from a mail server." -- https://www.bitcoin.com/satoshi-archive/emails/mike-hearn/9/#selection-25.149-25.1252

Thank you @PieterWuille and bca-0353f40e, very useful information. The thing is that almost everyone providing information about Merkle Trees and SPV in bitcoin found on the www take it for granted that merkle trees are absolutely necessary and do not question their usefulness at all. It's hilarious how they repeat everything they heard like parrots which no questioning at all. Even people that provide courses. Thanks again guys, very appreciated.

I think there is a possibly important security property you get with inclusion proofs without exclusion proofs, which you wouldn't have without: when querying multiple servers, it now suffices that one honest server gives you all transactions (or, alternatively, all servers together give you all transactions). Without inclusion proofs, if multiple servers gave you distinct things, you'd have no idea which one to believe. It's certainly not a clear-cut "this is sufficient", but it is a substantial improvement still.


text:
What happens when we send MSG_WITNESS_TX/MSG_WITNESS_BLOCK to non-segWit node?
Unknown services flag are ignored by node that don't know them, but what about GETDATA messages and identifiers?
For services flag, if node is not updated e.g to segWit, it will just not check (1<<3) bit in services field.
What happens if non-segWit node gets MSG_WITNESS_TX as one of the identifier in GETDATA message? MSG_WITNESS_TX is same as MSG_TX but with (1<<30) bit set. Are these identifiers and their bits treated as flags (like services flag -> bits are checked), so non-segWit node won't even check (1<<30) bit and will send back TX message or they are treated as values, so it will understand MSG_WITNESS_TX as an wrong value and reject the message?
Same for MSG_WITNESS_BLOCK.

That would be a violation of BIP144.
Support for segwit is signalled by having NODE_WITNESS in the services advertized in the version packet. If a peer does not signal NODE_WITNESS, it cannot be sent MSG_WITNESS_TX or MSG_BLOCK_TX invs.
Nodes are not required to understand these inv types if they don't signal support for segwit. For example, Bitcoin Core 0.12.x (and probably many versions before it) would just ignore such invs.

Is the checking of inv types generally in Bitcoin core at the bit level (like checking flags, e.g. services advertized) or is the entire value checked as a single (e.g. whether is it or not  0x40000001-1073741825 for MSG_WITNESS_TX)?

The implementation checks the entire value


text:
Private key on Bitcoin Core
I can't create the private key of a legacy address on bitcoin core. When I do the command it writes me that it can only be done to legacy addresses. And my address is legacy. What should I do. Thank you

Hello Carmen, what are you trying to do that you need to export a private key for? Perhaps if you ask about your original problem instead of your solution attempt for that problem, we could help you better.

why is the private key, which allows you to have full control over moving your wallet/addresses between bitcoin clients so elusive to obtain? @Murch

Because Bitcoin Core moved to a more comprehensive export format, ouput script descriptors a few years ago.

I believe you're confusing legacy addresses with legacy wallets. They're distinct and unrelated things.

Legacy addresses are pre-segwit addresses (P2PKH most commonly), and are contrasted with segwit and taproot addresses.
Legacy wallets are wallet files in the BDB file format, created by old versions of Bitcoin Core (and can still be opened by new versions, for now). They're contrasted with descriptor wallets, which use the SQLite file format, which are created by newer versions of Bitcoin Core.

You can create legacy addresses using descriptor wallets, and you can create segwit (but not taproot) addresses using legacy wallets.
What I suspect is going on here is that you're trying to perform the dumpprivkey on a legacy address in a descriptor wallet. And that doesn't work, because dumpprivkey only works on legacy wallets (regardless of address type). Exporting private key is dangerous, and especially so for descriptor wallets (where an attacker can typically compute all your private keys from just one). If you must, you can export the private master key using listdescriptors, though I suspect this will not be what you want.
To help you find an alternative, I encourage you to amend your answer to explain exactly what you're trying to achieve (or point out if my interpretation of events is incorrect). Perhaps a solution exists that doesn't involve exporting private keys, as that is generally a bad idea unless you really know what you are doing.

I've had the same problem.
Solution for that was ... that I've imported again my old wallet from backup. That was before I've converted it to legacy wallet.
After that it was simple to get private key. I've wnet to console and run:

walletpassphrase "myPassword" 600
dumpprivkey 18wX2UUqNn3W6MLq2urHNMjvEXaZr3hYoL

After that i've gotten private key without any problem.
When I've done it on the wallet that has been already migrated - then I've gotten error:

Only legacy wallets are supported by this command (code -4)

Regards,
Konki


text:
How to update Bitcoin Core if compiled from source?
I compiled Bitcoin Core from source following instructions. I then installed it and that all went well, but now I've realised, I have no idea how to update it when the time comes! (this is all on Debian 12 by the way).
I checked out the version that I wanted, configured/make/installed, and so although it's running well at the moment on 25.0, I'm wondering what I'll need to do when the time comes to update.
Also what about config file changes?
Thank you!

When updating, just recompile, shut down the running bitcoind, install the new one, and start it again.
The configuration file should be compatible, but it may be good to read the release notes of the new version you're upgrading to (and those of any versions you skipped) if there are features/options you're interested in.

Thank you for confirming, I was worried I would have to recompile everytime but no matter. But do I not need to uninstall the old version first? Also, how often do people usually upgrade, with every version?

You do not need to uninstall the old version, it will just overwrite the files that need to be updated. You probably want to update at the latest when the version you are running hits Maintenance End. Many node operators update to the newest version soon after the release, but that’s really up to you.

edit: I misread question but here are instructions to upgrade Bitcoin Core using the binaries on bitcoincore.org.
You'll need to shut down bitcoind first.
New Bitcoin Core versions are announced on bitcoincore.org.
Then the exact commands to upgrade are going to depend on your operating system.
The binaries for a particular release will be available on that site e.g. for v26 they are here.
You can enter on Linux/Gnu:
wget https://bitcoincore.org/bin/bitcoin-core-26.0/bitcoin-26.0-x86_64-linux-gnu.tar.gz
You can untar using:
tar xzf bitcoin-26.0-x86_64-linux-gnu.tar.gz
The new untarred binaries will then be stored in /usr/bin or /usr/local/bin and you need to copy bitcoind, bitcoin-cli and bitcoin-qt into your ./bitcoin directory and remove the old bitcoind, bitcoin-cli and bitcoin-qt binaries from that directory.
e.g. sudo mv bitcoind bitcoin-cli bitcoin-qt ./bitcoin from within /usr/bin
A couple of video tutorials from 402 Payment Required on upgrading Bitcoin Core are here (1, 2)


text:
If bitcoin was created as a currency, why is it used as a trading asset
I just read Satoshi Nakamoto's whitepaper, and in that it states bitcoin is designed and meant to be a decentralized form of electronic currency. But even though this was the original idea of bitcoin, why did it gradually become a trading asset, and something whose value frequently fluctuates? Will it become stable if it is used by a lot of the world?

Welcome to bitcoin.stackexchange.com. That's a very good question. However, this site is not designed to share or discuss opinions - so it isn't a suitable place for your question.

The idea was to have it be a means of exchange. But it soon became evidently clear that Bitcoin has the properties of sound money, hard money... much like Gold. Gold was also used as a means of exchange, but eventually that evolved into paper notes and coins to help with it's divisibility and portability.
In any event, hard money (Gold, Bitcoin) also have the properties needed to also make it a good "store of value" - and this is something that appeals to investors looking for a place to store their money and where it won't go down in value like fiat currency.
Because in the scheme of the entire world financial market Bitcoin is still very nascent and small, it has more volatility. But I do believe that if adoption and growth continues, it should stabilize a bit more and become less volatile.
Just my two Satoshis!


text:
How to change Bitcoin core 25.0 configuration?
I installed Bitcoin Core 25.0. Synchronization finished after a few days. Unfortunately, I made a big mistake, I configured the files incorrectly and now the application does not open.
I must honestly admit that this whole configuration is black magic to me.
I have a problem adding the screenshot, so I am copying the text that appears when I try to open bicoin-tx.exe.

"Error: Invalid combination of -regtest, -signet, -testnet and -chain. Can use at most one."

How can this be fixed?

It sounds like you are providing more than one network specifier across your starting command and your configuration file. Make sure that you only specify the single network (Bitcoin, testnet, signet, or regtest) that you want your node to connect to. If that network does not match the one that you previously synchronized for, your node will have synchronize again, since each of these networks has its own blockchain history. If you don’t provide any network, your node will synchronize with the Bitcoin network.

I accidentally added "regtest, signet and tesnet" ..... how can I correct it now?

If you added the lines to the bitcoin.conf, you can open that file again, remove those lines, save, and exit. If you added these additional configurations to your startup options, you can edit the startup command to remove them. If you want more specific instructions, please share what your configuration file and/or startup command look like

I would like to share the bitcoin.conf file so you can see it clearly, but I have no idea how to do it.

Fix: I added all these files to bitcoin-qt.exe


text:
Where did my bitcoin go?
Wanted to combine bitcoin on coinbase with bitcoin in wallet. Think I did it wrong. Can’t remember exact steps but think I went on „swap“ for some reason. Thought I was transferring from coinbase to wallet. But bitcoin never arrived there. Had many confirmations and is completed, wondering where it went though?? Guessing I sent it so Someone and it’s lost, sad but okay, just want to confirm there is nothing I can do!?

wondering where it went though?

If you have a Bitcoin transaction-ID and multiple independent blockchain explorers show that transaction-ID having multiple confirmations and that specific transaction has an output that pays the expected amount to an address you created using your wallet -- then the money is in your wallet even if your wallet software application doesn't know about it for some reason.
Remember that wallets (real Bitcoin wallets, not third-party custodial accounts pretending to be wallets) don't contain money, they contain the secret numbers known as private keys which are used to control amounts of money. So Bitcoin money is never really in transit and it cannot really go astray or get lost in the network.

just want to confirm there is nothing I can do!?

If you sent money from an account provided by the business named Coinbase, you can, and should, ask them for help.
If you sent money to a normal Bitcoin wallet (non custodial like Bitcoin core, Electrum etc), you can ask the appropriate support forums or ask people here for help -- but you might have to provide details of exactly what software wallet you use and maybe the transaction-ID.

Okay that sounds sort of promising that it hasn’t vanished   the „wallet“ app is connected to coinbase and therefore I was assuming it would show up in there (as it had previously, although I‘m sure I did it differently last time). Sounds like best bet is to contact coinbase and see what’s going on.
Not sure how to upload a photo but yes it has all the things you mentioned with blockchain explorers.
Thanks so much for your answer, I really appreciate it!


text:
How to broadcast transactions in bitcoin regtest mode?
I build three nodes named A,B,C based on bitcoin-regtest image of docker. And these three nodes are in the same network which means they can communicate with each other.
In node A, I use
bitcoin-cli -regtest -rpcuser=admin -rpcpassword=123456 addnode "$IPofB:18444" onetry

In node B, I use
bitcoin-cli -regtest -rpcuser=admin -rpcpassword=123456 addnode "$IPofC:18444" onetry

Then B is the peer node of A and C is the peer node of B;
I send a transaction from the wallet created on node A to wallet created on node C. And the sendtoaddress API is used on node A. The API works well and returns the transaction id. I can find the transaction in the transaction pool of A.
But I find some troubles:

I use tcpdump to catch the network flow. I find A broadcast the transaction to B. But C cannot receive from node B.
I cannot find the transaction from the transaction pool of node B and C;

I want to know whether regtest network of bitcoin can achieve what I need


text:
Segwit Taproot xPub switchup
I'm hoping someone can help me out here. I added a new wallet to my BTCPayServer, but I did not add "-[taproot]" to the end of the xPub. I assume that it then was perceived as a Segwit wallet, and the addresses generated was Segwit and not Taproot.
Basically I sent a transaction to one of the addresses not realizing my mistake, and now I have lost access to those Bitcoin, for what I hope is temporarily.
My question is, since it's the same xPub key used, wouldn't I be able to somehow use the private key to sign a transaction with that Segwit wallet to get the funds out?
I use a Ledger Nano S Plus.
I hope someone can help.
Thanks in advance!

I was able to recover the funds by connecting my Ledger device to a third-party wallet Electrum. I set up a Native Segwit account but used a taproot derivation path to attempt the recovery.
Here are the steps I followed:
I went to Electrum.org and downloaded Electrum for my operating system.
Then, I opened the 'Set Up Electrum' guide on the site.
I navigated to the 'connect to Ledger' drop-down and followed steps 1-7.
At step 8, I selected 'Native Segwit' (but didn't click next yet).
I edited the derivation path below 'Native Segwit' to say 'm/86/0h/0h' (photo attached).
After following these steps, my balance was shown in the 'history' tab, and I was able to access and manage my funds from Electrum.