text:
Is there any discrepency on Confirmations?
Is there ever a situation where some bitcoin client thinks a transaction has 3 confirmations and another bitcoin client (or website) thinks a transaction has 4 confirmations, for example?

Yes, there are a few different ways this can happen, and in nearly all instances this occurring is of little significance.
First the most common scenario where that happens: When a client receives a block it first will verify the block before relaying it.  A node that performs this slowly (especially if running pre-v0.8 software) may be many seconds behind other nodes.   So while one node might verify a block and increment the number of confirmations for a transaction, another node would still be working on verifying it and would show one fewer confirmations.   Within seconds the count should become equal for the transaction on both nodes.
Another scenario is much more rare -- where the blockchain has forked, and a transaction will show a number of confirmations that varies between the count on one side of the fork versus the number of confirmations on the other side.  This scenario actually happened on March 11th, 2013 where nodes running the v0.8 client would show a transaction as having a certain number of confirmations and at the same time a node running a pre-v0.8 client might show a lower number of confirmations.  When the forks converged, after the pre-v0.8 side attained "longest chain" status, both client versions then displayed the same count.
The possibility of there being a problem exists where there are several confirmations showing for a transaction on one node but no confirmations on another.  This could mean the funds for the transaction could be vulnerable to a double spend attack, or that such an attack had already occurred. But the scenario you describe, with at least one confirmation on both nodes, is likely simply just a propagation delay.

In 99% of cases, it's because a miner has mined a block that has propagated through to the website and it hasn't reached the client yet. In the other 1% of times, it's because there has been a block chain fork and there are two block chains that are valid. Both possibilities are temporary things (almost always) and will fix themselves when the next block gets mined or sooner.


text:
Sequence number semantics
Reading the following BIPs: 68, 112, 125, I got a few questions about the sematics of sequence numbers. As far as I understood, in version 1 transactions, sequence numbers have the following meaning:

If any input has a sequence less than 0xfffffffe, than the whole transaction is signalling replaceability

On the other hand, in version >=2 transactions, the above rule applies, plus:

If a sequence number has the disable flag (1 << 31) set to 1, then the sequence has no additional meaning (but can still be used to signal replaceability, right?)
If the disable flag is not set, then the sequence number is interpreted as a relative locktime with the format specified in BIP68. This means that transaction will not be included in a block until the output it spends reaches the specified age.

So, putting it all together, if one wants to signal replaceability in a version >=2 transaction, one can just use a sequence number which is less than 0xfffffffe but has an active disable flag (i.e. is greater than 0x80000000), on the other hand, how should one set the sequence number if one wants to both signal replaceability and also spend a relative timelocked output? Would it be ok to use a sequence number according to BIP68 and increase the bits that have no meaning in that format to replace the transaction? (i.e. changing all bits except 1 << 31, 1 << 22 and 0xffff)

If you're creating a version 2 transaction with the disable flag not set, then by definition the whole nSequence value will be less than 0xFFFFFFFE (because it will be at most 0x7FFFFFFF).
This implies that a transaction with an active relative locktime will always be replacable according to BIP125.
This is intentional. Nonreplacable transactions attempt to make use of the existing network policy rules to favor the first broadcasted version of a transaction. A transaction that will only become valid at a future point in time cannot make use of that, as it can't be broadcast until it becomes valid.

I don't see why the time delay means non-replaceability can't be useful.  I can't think of a use, but someone may, for whatever reason, not want their transaction replaced, even if they are spending an output with relative locktime.

source: Stack Exchange

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

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

sort: votes


text:
What distinguishes a miner from another?
So I've been recently studying about Bitcoin and had few questions:
1) What distinguishes a miner from another miner? Is there any proof that two miners are not the same person?
2) What can we say are the transactions accepted by a miner? Is it all transactions in the blocks after itself, that have been added to the miner's blockchain branch?
3) In any case, what's the proof that a transaction has been accepted by any miner?
Thanks!

Please try to write your second question more clearly.

You can't find out whether 2 blocks have been mined by the same entity (e.g. person) for sure. Guessing is possible. If you go to http://blockchain.info, you'll see a "Relayed By" column in the table right on the start page. You can be reasonably sure that that mining pool mined the block. Some mining pools always send their money to the same address. In that case, you can be even more sure that all the blocks whose coinbase transaction went to that address have been mined by the same entity because else they'd be giving a lot of money to a different entity.
The proof that a transaction has been incorporated into the blockchain is that there is a valid blockchain which contains a block which contains that transaction. You can't simply take a blockchain and swap a transaction in it out for a different one because that'd make the blockchain invalid as the hashes wouldn't check out.
Furthermore, if you want to be entirely certain that the transaction isn't just in any blockchain but also in the longest one, you need to be connected to the Bitcoin network so you know the longest blockchain. The longest one is the one which counts.

1) No
2) He chooses which transactions to accept.
3) His block contains the transaction.

If miner M was able to generate a block that belongs to the current blockchain (longest chain) and this block contains T1, then T1 and all other transactions in this block will continue on the blockchain, as long as this block does not become orphan.

So if, say, miner M has a transaction T1 in its block, and there's a block mined by N after M's block, you're saying that whatever transactions M has accepted (like from N) would appear in T1?

If miner M was able to generate a block that belongs to the current blockchain (longest chain) and this block contains T1, then T1 and all other transactions in this block will continue on the blockchain, as long as this block does not become orphan.

@Leandro: Please edit your answer to include the relevant information in the post instead of adding information to comments. Comments are only supposed to be used for transient information and may be removed later.

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


text:
How to update code of my existing altcoin?
I have an altcoin with 10 miners.
I want to update some changes in the code. with new rules of blockreward.
I have created new code also.
But how to make changes effect in the current blockchain, so that all miners follow these rules


text:
Reusability of ASIC miners
I'm looking into the re-use of ASIC miners to perform other mathematical tasks; for example, the sum of a prime and a random number producing a massive (arbitrarily long) integral value

i.e. sum(121 ^ 98435903485039)

Note: I require the result of the sum, not the hash of the result of the sum.

What mathematical tasks can an ASIC perform?
Do they have to be targetted specifically, or will the host machine naturally offload mathematical processing tasks to the ASIC?
If ASICs need to be targetted specifically, how does mining software target the hardware capabilities of an ASIC?

What mathematical tasks can an ASIC perform? It can be used as door-stopper in math classroom

possible duplicate of Bitcoin Mining ASICs used for cryptographic application? Rainbow tables?

The ASIC of a miner cannot perform arbitrary maths, they can only perform SHA-256 hash computations. You can hash other things besides the blockchain, but you cannot instruct your miner to give you the result of 1 + 1, or any other arithmetic operation.

What mathematical tasks can an ASIC perform?

Only the exact task they were designed to perform,

Do they have to be targetted specifically, or will the host machine naturally offload mathematical processing tasks to the ASIC?

They have to be targeted specifically.

If ASICs need to be targetted specifically, how does mining software target the hardware capabilities of an ASIC?

The ASIC is specifically designed to mine and provides an interface for the mining software specifically to tell it what to mine and to read back the results of its mining.
ASICs, essentially by definition, cannot be repurposed. The whole advantage of an ASIC is that it s totally and completely optimized for a single task and no resources are wasted on the ability to do other things.
For general purpose computing tasks like you're describing, you want a modern CPU or GPU.

Okay, so what IS the task that an ASIC performs (in the mathematical sense) - Presumably an ASIC can be reused provided that something is invented that CAN re-use the mathematical capability of an ASIC?

@series0ne The ASIC performs the specific task it was built to perform. It is usually entirely optimized for that purpose. For mining ASICs, that's mining. If you want a component that can be flexibly re-tasked, you want a CPU or GPU. A mining ASIC can't sum things for two reasons: 1) It has no hardware that does sums. 2) It has no hardware to output large results. Why? Because mining doesn't require either of these things, so why would they waste space and have fewer mining cores?

Hence the Application Specific part


text:
How many currency units in 1xBTC / 1xAltCoin?
Since BitCoin (and AltCoins) are divisible by up to 8 decimal places, does that technically mean that 1xBTC (or 1xAltCoin) is equal to 1 billion individual units of currency?


text:
What is Tapscript?
What is Tapscript?
How is it different from script? Is it the same thing as "Leaf script"?
How does it relate to Witness Script, miniscript and any other type of script used in Bitcoin transactions?
How and when was it implemented?
What can it be used for?

Script (uppercase S, also Bitcoin Script) is the scripting language used in Bitcoin. Its programs are called "scripts" (lowercase s), often with an adjective based on the location of the script in a transaction (output script, input script, redeem script, witness script, leaf script).
Leaf script is a script revealed as part of a Taproot (SegWit v1) script path spend (see BIP341).
Tapscript is a variant of Script used in leaf scripts with a leaf version of 0xc0 (see BIP342). It makes some significant changes to previously used Script, such as switching from ECDSA to Schnorr signatures, replacing OP_CHECKMULTISIG(VERIFY) with OP_CHECKSIGADD and introducing OP_SUCCESS opcodes for better upgradeability. Tapscript scripts are often called "tapscripts".
Miniscript is a language for writing scripts that enables composition, static analysis and more. It compiles directly to Script (or Tapscript).
Here is a diagram that relates all these terms together:

Great answer, might it also be worth mentioning [tag:miniscript]?

@Lee Feel free to add it to your question.

@VojtěchStrnad Very nice diagram! One tiny nit: if tapscript is a subclass (indirectly) of script, then that implies a script can be written in Tapscript... so should there be a "written in" arrow from script to Tapscript?

@PieterWuille Hmm, not sure if I like that. You can already see from the graph that some scripts are written in Tapscript, a direct connection might imply that all are (as with Script).

Fair enough, I guess that would change the meaning to "may be written in".

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


text:
What is meant by transaction 'pinning'?
What is meant by the term 'transaction pinning'?

Transaction pinning happens when:

I broadcast a transaction that signals opt-in RBF
the transaction does not get confirmed because the feerate is too low
someone else broadcasts a new (child) transaction spending one of the outputs of my transaction
I now can't bump the fee on the transaction unless I include a fee greater than that of the combined original transaction + the child transaction (BIP 125, rule 3).

If the child transaction in (3) is large (eg a commercial service sweeping up lots of transaction outputs), then the total fee that I'd need to pay for a valid RBF would be very large.
In this scenario, my original transaction has been 'pinned' by the child transaction.
Russell O'Connor has proposed changing the RBF policy rules to alleviate this problem.

Wouldn't the child transaction trigger Child Pays For Parent in most cases?

@SamJones - that depends. Child Pays For Parent is where a child transaction has a higher fee-rate than the parent, thus increasing the average fee-rate across the parent-child package and making it more attractive for a miner to include both in a block. In the example above, the child transaction might have a lower fee-rate, so it doesn't increase the average fee-rate of the package. Instead it is a large transaction with a high absolute fee. Any replacement transaction for the parent needs to exceed the absolute fee of the replaced transactions.


text:
How do I program smart contracts?
Is there a guide to learn how to program smart contracts for the Bitcoin blockchain?

Possible duplicate of How do Scripts work?

Ivy is a higher-level language that allows you to write smart contracts for the Bitcoin protocol. It can compile to instructions for Bitcoin’s virtual machine, Bitcoin Script, and can be used to create SegWit-compatible Bitcoin addresses.
Ivy GitHub Repository
Another interesting approach is to use RSK. Rootstock is a project to execute smart contracts (turing complete) to the ecosystem of Bitcoin. It is a Sidechain that uses as currency the SBTC (Smart-BTC) which is convertible 1: 1 with Bitcoin (2-way peg).
Balzac is an high-level language for writing transactions, verifying their correctness, and compiling them into actual Bitcoin transactions. You can also use Balzac to design Bitcoin smart contracts.

I stepped over the same question, and to my knowledge there is no such guide. But There are some resources here:
https://en.bitcoin.it/wiki/Contract
https://en.bitcoin.it/wiki/Smart_Property
https://en.bitcoin.it/wiki/Dominant_Assurance_Contracts
and in Andreas' book "Mastering Bitcoin" (2nd edition), there is "CHAPTER 7 Advanced Transactions and Scripting" with examples for multisig, checklocktimeverify (CLTV) and checksequenceverify (CSV), all with nested "if-else-endif" statements.
some reference is here: https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki
some threads on bitcointalk:
https://bitcointalk.org/index.php?topic=1300723.20
https://bitcointalk.org/index.php?topic=1558207.0
https://bitcointalk.org/index.php?topic=1952248.0

and here: https://www.reddit.com/r/Bitcoin/comments/4kit49/is_it_safe_to_use_cltv_for_recurring_payments/


text:
How does Bitcoin handle address collisions?
Since the addresses are hashes of a public portion of a public/private ECDSA keypair, what would happen to two different people with different keys that hashes into the same address?
How would transactions to those addresses be handled?

related: Is each Bitcoin address unique?

In elliptic curve cryptography, public keys are derived from private keys, with seemingly random distribution.  You are correct that two different private keys could produce two different public keys that just so happen to hash to the same Bitcoin address.
A SCRIPT_SIG of the transaction that spends from that address would need to provide:

A public key that hashes to that address
A signature of the transaction produced from a private key that matches the given public key

Since two different key pairs could both meet this criteria, either one of them could spend the bitcoins.
However, this is very unlikely.  So much so, that it's not even worth considering as a possibility.  The best metaphor I've seen on why this isn't an issue is explained in this video:  https://www.youtube.com/watch?v=ZloHVKk7DHk

Both people would have access to any funds in the address. Whoever is first to spend these funds wins.
Of course, it is extremely unlikely that there will be such a collision.

As @Meni answered, both people would have access to the funds.
To illustrate how unlikely this is to ever happen, consider the following simple attack:
while True:
    genereate new keys and address
    if address has funds:
        transfer to ME

This attack can scan through an astronomical number of addresses each day. And it is so simple, anyone can carry it out and get rich! Except that it doesn't work. If it did, the bitcoin network would quickly collapse.
The reason it doesn't work is that the address space is so big, it is extremely unlikely for a collision to ever happen purely by chance (bugs in random generators are a different story...).

There is a nice paper on the topic that explains how unlikely it is to perform such an attack and get a profit http://diyhpl.us/~bryan/papers2/bitcoin/bitcoin-birthday.pdf


text:
Specify options as startup flag or conf file in bitcoin core?
Can I specify all startup options like -nodebuglogfile or -txindex in bitcoin.conf file as nodebuglogfile = 0, txindex = 0? Can all startup options/flags without any parameter equivalent to setting them 0 or 1 in bitcoin.conf

Yes, all options can be specified either in bitcoin.conf or as command-line parameters. If an option appears in both then command line takes precedence. Boolean command-line options set to true can omit the value (i.e. both -txindex and -txindex=1 works).


text:
What are the trust assumptions in --assumed-valid in bitcoin core 0.14?
Please help me understand and distinguish the trust assumptions in the following three cases shown below. Specifically, please elaborate the attacks possible (even though completely theoretical) and trust sacrificed to get the functionality.
Case 1: Bitcoin Core before 0.14 without assumed-valid and where each node does complete signature verification.
Case 2: Bitcoin Core 0.14 with the assumed-valid blocks with signature validation skipped for blocks prior to release. This means that the block signatures are correct because bitcoin-core devs signed on it.
Case 3: (Hypothetical) : Bitcoin Core 0.14 with UTXO set which has the snapshot of UTXO database. This would be done in a similar way as assumed-valid. This would skip the complete IBD and be really useful for quickstart-pruned node.
I would like to know answers to the following 2 questions:
Q1) What are the possible attacks (even though completely theoretical) which are possible in case 2 but not in case 1. Please elaborate security-model change required to shift from Case 1 to Case 2.
Q2) What are the possible attacks (even though completely theoretical) which are possible in case 3 but not in case 2.
It appears to me that security model in Case 3 is same as that of Case 2. If I trusting core devs with signature-validation, might as well trust they give the correct UTXO set.

Q1) What are the possible attacks (even though completely theoretical) which are possible in case 2 but not in case 1. Please elaborate security-model change required to shift from Case 1 to Case 2.

None. If there happens to be a fork that makes the assume valid block to no longer be in the longest chain, then you will continue to validate all signatures in the longest chain. If someone were to give you a "fake" blockchain which does not include the assume valid block, you would be doing the same validation process as without the assume valid block. Assume valid does not change the security assumptions as the assume valid block does not need to be in the blockchain unlike was done with checkpoints.

Q2) What are the possible attacks (even though completely theoretical) which are possible in case 3 but not in case 2. It appears to me that security model in Case 3 is same as that of Case 2. If I trusting core devs with signature-validation, might as well trust they give the correct UTXO set.

No, Case 3 has completely different security assumptions from assume valid. You are trusting that the Core developers are providing you the correct UTXO set and by doing so, you are trusting that you will be using the correct blockchain on startup. With assume valid, you are not trusting or assuming that you are using the correct blockchain, you are still validating almost everything. With assume valid, even if the assume valid block is wrong, you can and will still be using the correct blockchain and just doing the same amount of signature validation to be on the correct blockchain as software without assume valid.

About Q1 there is a small difference, if developers (and everyone reviewing the code changes) were to conspire with miners to build a more-work chain with invalid signatures (and go undetected for weeks), and then include it as assumevalid. However, those same people already have that power by just changing the code - which would be much less obvious.

@PieterWuille, Why can't the same logic be applied to assumed UTXO set? or even in general any form of validation performed by software. If I am trusting the software devs that they don't perform any sort of obfuscation in code, I might as well trust the output of validation. Why is signature-validation such a special form of validation?

If you trust a UTXO set someone gives you, that someone can control what chain you accept, without needing hashpower (though it would be blatantly obvious). -assumevalid's value cannot do that, it can only skip validation if that is effectively the best chain you learn about.

@PieterWuille I still don't think that fully answers sanket's question. If you trust a UTXO set that comes from the same source as your bitcoin software, its no different than simply trusting that software. As you pointed out, the developers already have the power to put a malicious binary out there that follows the wrong chain. If you are fully auditing the software yourself, that should include fully auditing the UTXO set. I don't see any difference in security profile.

This is a related discussion, and I'd appreciate your input: https://www.reddit.com/r/BitcoinDiscussion/comments/bskw25/hard_coded_utxo_checkpoints_are_the_way_to_go/


text:
What are the different kinds of endpoint Lightning nodes a user can choose from and their trade-offs?
What are the different kinds of endpoint Lightning nodes a user can choose when joining the Lightning Network and their trade-offs?
(Note this question is not a duplicate as it attempts a classification of different routing nodes rather than endpoint nodes.)

Christian Decker answered this at Advancing Bitcoin 2022.

Custodial wallets are then further split into
account based and hosted channels, sometimes also called multi-tenancy
systems, built on top of a single Lightning node that is under the
control of some operator.
On the non-custodial side we have the
self hosted version which has been so far the go-to case for many of
you I believe. In that case you have to learn about how to operate a
Lightning node, how to set up all of the infrastructure: databases,
watchtowers, backups etc. If I drop my phone in the lake what do I do
now? With great flexibility comes a lot of responsibility as well.
Then we have the split into do we want to have a node per device? That
is often a choice that has been made so far where we build a node into
the Lightning application. There are now really good tools to do that,
LDK is an excellent example of how to do that, but it also means that
if you use more than one app you are now operating two wallets. You
are splitting funds across these two wallets. If you have 50 here and
50 here you can’t pay 60. There is no way of combining them. It also
means that the management overhead that you have is multiplied by the
number of apps that you have. If you have two apps you now have to
manage twice the number of channels, you have to manage twice the
number of backups, you have to pay twice the watchtowers and so on and
so forth. It also means that if you drop your phone in the lake, bye
bye funds basically.
Then there is the remote control node scenario
where you have some sort of box at home. You are remoting into that
node from the outside. Personally I quite like this because it means
that I can have multiple apps be frontends to the same node. The funds
are concentrated on a single node and I don’t run into this issue that
I might not be able to pay an invoice despite having sufficient funds,
if only they were combinable. The upside is I can drop my phone in the
lake again and my funds are still safe. That’s kind of nice.
Today I am going to present a mix between these scenarios. That is what I call
remote control and remote signer. We will see how this can be used to
get the best of both worlds. Make it easier to assist new users until
they have learnt about the Lightning Network to take on responsibility
for their own node and how they can migrate from this scenario over to
this scenario. It enables a lot of flexibility and at a later point in
time, once you have seen the upside of what this can do for you, you
are incentivized to learn and upgrade your experience to take care of
your own node. What I didn’t mention is that remote controlled node
and remote control/remote signer setups also have a way smaller
capture feature. Namely if you integrate the node into the app then
you don’t have the flexibility of trying out the new app that might
have a new cool interface. You have to tear down the entire node,
transfer funds and then spin up the entire node again just to find out
this UI actually doesn’t work for me so I’ll migrate back. With the
remote setups you can switch between front ends and even use them
concurrently as often as you want. You could have the same node be
fronted by a web browser and a mobile app. Or you could give your kids
access to parts of that node in the form of an allowance for example.

Greenlight is an example of the remote control / signer option. It is a service provided by Blockstream but others are free to provide similar services.


text:
What is the controversy with Ledger's new recovery service?
There has been a lot of controversy recently over Ledger's new recovery service which will shard your seed out to third parties for storage. What is the controversy?
This question was posed by Christopher Allen on Twitter.

Christopher Allen answered the question on Twitter.

In large part because we didn't expect seeds to ever leave the Ledger device. As it turns out (as all hardware wallet designers already know), all it requires is a signed firmware update, and seeds can go wherever they want. Why? Ledger's hardware is based on a Secure Enclave (aka "SE"). That's is what generates and stores your private keys. The problem is that no existing SE chips can do secp256k1 (the curve used by Bitcoin & Ethereum) natively and safely in semiconductor logic. This isn't an issue with Ledger; it's an issue with all current chips used by wallets today. This means that in order to do secp256k1, a SE has to hand a key off to a code execution process in the SE or to an MPU. That's what opens the doors for doing unexpected things with that key — things that most didn't expect from a personal hardware wallet. In other words, the public might have had the expectation that keys weren't going to ever leave the Ledger, but that expectation is actually impossible to support today, because keys already have to leave the most trusted part of the Secure Enclave to be used! There are some advantages of this architecture — flexibility & future proofing. Doing cryptography using updatable code means as standards change, new curves are needed, the hardware wallet can adapt.
This is why Blockchain Commons hosts Silicon Salon. We have been working with chip manufacturers such as Cramium Labs, Tropic Square and RED Semiconductor. They recognize the need for new chips that support cryptography natively in silicon logic.
Based on presentations over the last year, we'll actually be able to fulfil the promise that seeds can't leave a device, something that's impossible today! And we can still offer future-proofing to enable new approaches like multisig and ZK proofs.
If you are interested in this topic, join the Silicon Salon community so that you can attend our next salon and talk about the future of cryptographic semiconductors. This is essential work to bridge between the cryptographic engineers, wallet developers, and semiconductor designers.
(Related threads on Shamir’s Secret Sharing and being free to make your own choices.)

Ledger Wallet users are concerned if their keys are actually cold and secure after the latest "feature" release and several tweets that have later been deleted by Ledger.
The answer to whether Ledger funds are cold and secure is muddy.  Are user funds secure (probably), is it cold absolutely not; however the revelation many are just now noticing is it NEVER has been cold.
Consider the following facts:

Ledger's firmware is closed-source and always has been so you have to trust the manufacturer completely what is included in those firmware upgrades.
Firmware upgrades can allow essentially any change to the wallet, including extracting keys as Ledger_Support confirmed in a tweet on 5/17/23 that they later deleted on 5/18/23.

Ledger has always had the ability to extract keys because they push close-source firmware to wallets. It's that simple, but they more than likely have never done so and were just trying to make a point with their tweet. Nonetheless they do technically have the ability when the firmware is proprietary and closed.
Ultimately it is up to the user to choose their storage solution but it is important to know what trade-offs they are making and what abilities their wallet manufacturer has over their funds and device.


text:
How do i loop through all the related address in a given wallet address
I am using bitcoin block chain API, it is possible to get amount sent in a transaction id and the addresses it was sent to. My problem is getting the RELATED ADDRESSES to the address that sent the payment.. The only fact is that I want to be able to validate who sent the money and who it was sent to.. eg. my site involve users sending bitcoin to other users and submitting transaction ID. Each user register and input their wallet address. if User A sends to USer B and submits transaction ID, I want to be able to find out if the transaction is coming from the Sender User and is going to the Receiver Address. Validating for the receiver address is simple with my lines of code:
$requesturl='https://blockchain.info/tx-index/'.$comment.'? format=json';
$ch=curl_init($requesturl);
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$cexecute=curl_exec($ch);
curl_close($ch);
$result = json_decode($cexecute,true);
for($i=0; $i<count($result['out']); $i++) {
$result['out'][$i]["addr"];
}

I can get the receiver addresses from the loop above and validate, and if want to get the sending addresses it is also possible with:
for($i=0; $i<count($result['inputs']); $i++) {
// the addr is in the input
}

Now my problem is if the wallet Address the User A submitted on our website is not in the sending address list, how do I know his address is there in the list.?

Do you really care who pays for a bill, or do you care what bill was paid for? To do the latter, the usual suggestion is to create a new receive address for each bill you want to see paid. To do the former, use something other than Bitcoin, as sender at best are pseudonymous anyway.

I care who pay for a bill, its Ponzi scheme app


text:
What are the different upgradeability features in the BIP-Taproot (BIP 341) proposal?
What are the different upgradability features in the BIP-Taproot (BIP 341) proposal?
Why are there so many upgradability paths? Is there something an annex can do that a leaf version can't?
This question was asked by James Prestwich on Twitter.

There is the annex, leaf version, ext_flag, OP_SUCCESS, unknown pubkey
types and you could probably include the existing witness version too.
I believe that list is exhaustive.
The ext_flag isn't so much an extension mechanism in itself; more a
structure that permits safely reusing the sighashing code (as opposed
to needing a new tag or other mechanism for collision avoidance).

Leaf versions: for revamping script semantics
OP_SUCCESSx: for new opcodes, without coordinating new version
Pubkey types: for new sighash flags/cryptography without needing an explosion of new opcodes
Annex: for effectively adding new fields like nLockTime

Leaf versions were really only added because we had a few bits to
spare in the control block, and it seemed wasteful to reserve them.
They're mostly a convenience, I think, as OP_SUCCESSx can achieve the
same (add an OP_V2 etc).
As the annex isn't committed to by the scriptPubKey, it's more a way
to extend witness possibilities than it is directly a way to add new
semantics.
So is there something an annex can do that a new leaf version can't? I
think they're orthogonal.
For example, a feature where you could restrict a tx to only be valid
in a chain that contains a certain block hash. It can't be done with a
leaf version, as it's a sign-time thing. I believe the annex can't be
used to introduce new script conditions. A new leaf version could
introduce its own annex-like thing, but that wouldn't be able to apply
to old leaf versions.
The motivating example for the annex is this. Imagine a new opcode is
added that needs few bytes but has high CPU cost. You'd want a high
weight budget per such opcode, but that may require actually stuffing
the witness with dummy data just to get the necessary budget. Instead,
it would be nice if there could just be a marker on the input that
says "increment the apparent weight (and corresponding op budget) by
N", without taking N bytes. Logistically, it would be annoying if that
marker can only be parsed when the spent output is available. The
annex is recognizable without context, mostly by exploiting a thankful
coincidence about what set of witnesses is valid for v0 (first byte of
last witness stack item can only take on certain byte values). This, I
think, can't be accomplished with a new leaf version.

This question was answered by Pieter Wuille on Twitter.


text:
Why does my full node need to load IP addresses from DNS seeds on restart?
I stop one of my Bitcoin Core full nodes (v0.19.1) with 10 connections and then start it again. It needs to load IP addresses from DNS seeds. Why is this? Why doesn't it try the addresses of peers it was connected to prior to the shut down? Are they not persisted in addrman? It could then obtain more IP addresses through gossiping from those peers and not need to keep going back to the DNS seeds.

I found this https://github.com/bitcoin/bitcoin/pull/16939 and this https://github.com/bitcoin/bitcoin/issues/15434 but will look into more before attempting an answer.

And this Bitcoin Core PR review club: https://bitcoincore.reviews/16939

What do you see in the debug.log that indicates it is using the DNS seeds?

"Loading addresses from DNS seed dnsseed.emzy.de" etc followed by the other DNS seeds. Then "277 addresses found from DNS seeds" and "dnsseed thread exit"

Do you have the same problem with v0.21.0?

No I haven't been able to replicate on v0.21.0

This appears to be resolved for me in v0.21 with this merged PR 16939 and some additional context in this issue and this Bitcoin Core PR review club.
Falling back to load IP addresses from DNS seeds should be the last resort and as you say addresses of previous peers should be persisted in addrman after stopping bitcoind and restarting.


text:
Is there a transaction propagation delay built in?
When a node receives a transaction it verifies it and then sends it to its neighbors.
My question is: does the node broadcast the transaction right away or is there a delay built in (privacy concerns) and if there is a delay built in can anyone point me to the code where that happens?

Yes, there is what is called transaction trickling. This is a mechanism to select a random peer for immediate forwarding of all transactions, while others receive the transaction after a random timeout. This is done in order to reduce the chances of fingerprinting the origin of a transaction. Similar to the proposed dandelion paper, it forwards a transaction through a conduit of peers before spreading it widely in the network, and observers cannot identify the origin by simply timing the time peers announce the transaction's availability.

Trickling was removed in 0.13.0. All transactions are now delayed until their next broadcast events, which happen at Poisson-distributed times.

@PieterWuille can you point me to the implementation of this? Is it the PoissonNextSend() ?

Indeed, that's the function to compute Poisson-distributed intervals between send events.

@PieterWuille Could you elaborate further? The function returns nNow + (int64_t)(log1p(GetRand(1ULL << 48) * -0.0000000000000035527136788 ) * average_interval_seconds * -1000000.0 + 0.5). I decipher the step over nNow as -log (1 - u) * lambda + 0.5, given that u is a uniform variable in [0,1] and the interval is accounted in seconds. This is close to -log(1-u) / lambda which can be used to simulate a poisson process. However, I wonder where the product (instead of division) and the +0.5 come from?

It's a product with the precomputed inverse, because that is faster. And with u uniform in [0..1], log(u) and log(1-u) are equivalent. +0.5 is for rounding before converting to an integer.

@PieterWuille Thank you for clarification. I get that the log1p(...) part is actually log(1-u) for a u in [0,1]. And, as the average_interval_seconds is in seconds and the calculation is done in microseconds, -1000000.0 is a conversion factor, also correcting the negative outcomes of the log. Okay, the +0.5 is for rounding. But I still struggle to see how average_interval_seconds aka lambda is equivalent with 1 / lambda?! What am I missing?

lambda is the rate. rate is the inverse of the time between events.

Ah, lol. You're totally right, how did I not get that... Sorry for the inconvenience, and thank you very much for clearing this up!


text:
SegWit witness commitment merkle root location
BIP 141 defines the commitment structure here
What i am unsure about is the location of this data. I know it will be in scriptPubKey.
Does this mean Coinbase tx will have more than one output?
Also is there a testnet block with an example of a Coinbase tx with witness commitment?

The witness commitment is in an OP_RETURN output of the coinbase transaction. This means that the coinbase transaction will likely have more than 1 output (although not necessarily as a miner could send the block reward to the OP_RETURN output, but they would be stupid to do so). Here is a testnet block with a witness commitment: https://live.blockcypher.com/btc-testnet/block/00000000000007972a6f786179cb42dbc59f167aafd757b203e6c2eb80d49455/. All testnet blocks should have one as segwit has activated on testnet.

The commitment can be in any of the coinbase's outputs. The coinbase is allowed (and has always been allowed) to contain multiple outputs. SegWit just requires that one of them has a scriptPubKey that starts with 0x6a24aa21a9ed, and that it commits to the witness root.


text:
Where was the term "coinbase" first coined, who first used it?
The white paper doesn't mention the term "coinbase" (in reference to the reward transaction).
I see the first version of the software main.cpp does:
    // First transaction must be coinbase, the rest must not be
    if (vtx.empty() || !vtx[0].IsCoinBase())
        return error("CheckBlock() : first tx is not coinbase");
    for (int i = 1; i < vtx.size(); i++)
        if (vtx[i].IsCoinBase())
            return error("CheckBlock() : more than one coinbase");
...

Did the term orginate in the Satoshi's code?
Who first used the term on a forum, mailing list or other public venue?
I'm looking to trace back to the "original specification" of the coinbase transaction, if there is one.

The term "coinbase" was most likely coined by Satoshi through the IsCoinbase method of the CTransaction class. It was both part of the first publicly distributed version of the source code and of the (allegedly) privately shared early versions of it.

Who first used the term on a forum, mailing list or other public venue?

The earliest post I could find mentioning "coinbase" on bitcoin talk was on June 21, 2010 by user Laszlo:
https://bitcointalk.org/index.php?topic=198.msg1640#msg1640

I'm looking to trace back to the "original specification" of the
coinbase transaction, if there is one.

As alluded to by Antoine Poinsot, it seems the original specification is the isCoinBase method of a CTransaction object, as well as its checkTransaction method:
class CTransaction
{
public:
    int nVersion;
    vector<CTxIn> vin;
    ...
    bool IsCoinBase() const
    {
        return (vin.size() == 1 && vin[0].prevout.IsNull());
    }
    ...

    bool CheckTransaction() const
    {
        ...
        if (IsCoinBase())
            {
                if (vin[0].scriptSig.size() < 2 || vin[0].scriptSig.size() > 100)
                    return error("CTransaction::CheckTransaction() : coinbase script size");
            }
        ...
        return true;
    }
    ...
}

Which I take to mean "The coinbase transaction shall be a standard transaction with exactly one null input transaction where the input scriptSig size is in the range 2 to 100 bytes."
Here, "null" is defined as a COutPoint object with hash==0 and n==-1:
class COutPoint
{
public:
    uint256 hash;
    unsigned int n;
    ...
    bool IsNull() const { return (hash == 0 && n == -1); }
    ...
}


text:
How does the initialblockdownload field in the getblockchaininfo RPC work?
Let's say I have a fully synced node that returns "initialblockdownload": false. If I turn it off, will it show "initialblockdownload": true when I start the node again? In other words, if initialblockdownload is false, will it be set to true again if the node needs to resync?

The initialblockdownload field in the output of the getblockchaininfo RPC reports the internal "IsInitialBlockDownload" state of the node software.
The value of this state is always true at startup, and latches to false whenever both of these conditions are true:

The currently active chain has at least as much cumulative PoW as the hardcoded constant in the software (updated every major release).
The timestamp of the currently active tip is no more than 24 hours in the past.

Whenever the IsInitialBlockDownload state latches to false, it never reverts to true (unless restarted).

What would happen if your node was running but had no connection to another node? Wouldn’t it revert to initialblockdownload: false after 24h?

@Murch No, it never reverts to false unless restarted (as of Bitcoin Core 26.x). I don't think there would be anything wrong with reverting in such a scenario, but I also don't think it adds much.

This one-way behavior also has the advantage that once initialblockdownload becomes false (actually, ChainstateManager::m_cached_finished_ibd becomes true), this state can be reported to other software without locking cs_main. This improves system performance, since this state is queried often.


text:
What does unbroadcastcount in getmempoolinfo mean?
What is the unbroadcastcount in getmempoolinfo? Does it track only the transactions from my wallet that are unbroadcasted? Or does it track all transactions that are not broadcasted which I may have received from peers.

This field counts transactions that have been submitted locally with the sendrawtransaction RPC or the wallet but have not yet been successfully relayed to at least one peer (as a response to a getdata message).
For more details you can check out PR #18038 which added the field.

Is it possible to get a list of such transactions?

Yes, if you call getrawmempool every transaction will have an unbroadcast field.


text:
json parsing error with createrawtransaction with bitcoin-cli in regtest
I have been trying to use getrawtransaction to work with raw transactions in regtest and I have not been able to get it to parse correctly.  the general format I am using is this.  I am running this on powershell on windows 10 if that matters
.\bitcoin-cli -rpcport=18532 -rpcuser=alice -rpcpassword=supersecretpassword createrawtransaction '[{"txid":"7b2d65b85487a891a3e0a9c541975fa7e681e571ea18982da49402e594ca2af1","vout":0}]' '{"bcrt1q27y3n03u3s52z8nlq2nt9xqyxxvk5lwxjmjxnh":25,"bcrt1qmgj8qfvhqqc049facx94qyeh57xl0lu96hck2":24.95}'
I have tried all kinds of variations on quote schemes and escaping, but the json always fails to parse with the error
error: Error parsing JSON: [{txid:7b2d65b85487a891a3e0a9c541975fa7e681e571ea18982da49402e594ca2af1,vout:0}]
any idea what I might be doing wrong?
Thanks

Using quotes and escaping like this should work on Windows:
createrawtransaction "[{\"txid\":\"7b2d65b85487a891a3e0a9c541975fa7e681e571ea18982da49402e594ca2af1\",\"vout\":0}]" "{\"bcrt1q27y3n03u3s52z8nlq2nt9xqyxxvk5lwxjmjxnh\":25,\"bcrt1qmgj8qfvhqqc049facx94qyeh57xl0lu96hck2\":24.95}"

There are a few other problems with your command, you aren't using the -regtest parameter and the second output address is not valid, but those are unrelated to this error.


text:
Wallets with BIP44 support
I'm writing my own implementation of BIP44 wallet.
Can someone please point me to a BIP44 compatible wallet that could import seeds from other wallets. I've looked at several and it seems that, at most, they support only BIP39.
Thank you.

MetaMask, AFAIK. See here.

Is MetaMask by design a BIP 39 wallet, even though its recovery phrases contain 12 words instead of 24 as in BIP 39?

You can find a list of compatible wallets on BIP44's Github page.

Mycelium Bitcoin Wallet (Android)
Copay
CoinVault
Samourai Wallet
Coinomi
TREZOR
KeepKey
Ledger Wallet
21 Machine Wallet
Trust Wallet

According to MetaMask they also support BIP44, although they are not on the list above.

Is MetaMask by design a BIP 39 wallet, even though its recovery phrases contain 12 words instead of 24 as in BIP 39?

I've looked at several and it seems that, at most, they support only BIP39.

BIP39 and BIP44 cover different stages of the wallet generation procedure
BIP44 is a BIP32 convention - a prescribed hierarchy of BIP32 derivations for wallet compatibility. Setting up a BIP32 wallet the first time involves taking some entropy and applying the Master key generation procedure (https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Master_key_generation)
The initial entropy should be CSPRNG output - but how are people expected to store this? Where can it come from?
Well that part is handled by BIP39. It involves hashing the seed (optionally with a passphrase) to obtain the entropy that gets used by BIP32.
So the reality is you'll want to use BIP44 in combination with BIP39, otherwise, your only option is to generate entropy randomly and give the user the BIP32 root xprv. This is the root private key in the BIP32 derivation tree and contains all addresses and private keys but the odds are a BIP39 seed is more friendly for people to back up.


text:
Why a Bitcoin transaction that refers its own output as an input is computationally infeasible?
It was asked to us as in an assignment : Explain why it is computationally infeasible for anyone to generate a Bitcoin that refers its own output as an input.
Inspite of searching throught various resources,I was unable to find a satisfactory answer to it.

If it is possible please post the exact assignment, because your question does not really make sense. How do you "generate" a bitcoin? What is the output or the input of a bitcoin? Are you talking about a transaction?

Based on the title I think that's a typo, I think he meant "generate a bitcoin transaction ..."

Yeah in the description it should be Bitcoin ‘transaction’

A transaction input is an unspent transaction output from an existing transaction.
A transaction's output is the creation of an unspent transaction output from one or more inputs.
It's computationally infeasible because an input MUST exist before an output.
The tricky part is the terminology, input vs output. They are both outputs but in different states.  Essentially everything is an output existing in the ever-changing Unspent Transaction Output (UTXO) set, inputs are simply referring to a previous UTXO. An output cannot exist without coming from an input, which can be validated all the way back to its coinbase transaction.
EDIT:
To dig a little further why it's technically not possible, when building a basic raw bitcoin transaction you need the transaction ID, and N out value of the input being used. Creating a transaction with an invalid or non-existent transaction ID would be rejected if broadcast to the network. Since we know an input must come before an output, one cannot refer to its input as its own output as the transaction ID would not exist yet.
How To Create a Raw Transaction


text:
Is Bitcoin network an Asynchronous network or a synchronous network?
Conventional BFT protocols work on weak timing assumptions, and if a faulty primary does not respond or forward a client's request a view change message is initiated by the backup nodes. Therefore, if an adversary delays the messages beyond timeout period, he can affect the network through a DoS attack.  The blocks in Bitcoin Blockchain are also time-stamped, therefore, I just want to confirm that does delay in reaching of any transaction or Block to maximum nodes affect the validity of that transaction/block after any timeout period?

I'm not aware of any standard way to classify networks as "asynchronous" or "synchronous".  Can you state precisely the definitions you want to use?

I have edited the question. I guess now it is much clear.

In my understanding it is an asynchronous network: It works over the Internet. The Internet is the biggest asynchrounous network. An adversary cannot delay the transactions effectively if he doesn't control the majority of the hashing power. Therefore without making the asumption of a malicious adversary with that power, your transaction will eventualy be included in the network: the answer to your las question is no, the protocol is asynchronous and it will reach consensus.


text:
Better Crypto Currency for trading
Can anyone suggest me which crypto currency is better for trading? Is it Bitcoin or Ethereum?
Prices in USD as of 21/08/2017 and time 18:03 (UTC+05:30):

Bitcoin = $4041.53 or
Ethereum = $325.76

Hello iamjayp, investment advice is off-topic on our site.

Volatility is higher in Bitcoin right now. But ETH rose recently as well. It depends on how you define better for your purposes and how the markets will behave which is always difficult to predict.

Okay you are correct. Bitcoin is extremely volatile since, price of Bitcoin is $3978.21 as of 22/08/2017 , time : 18:09 (UTC+05:30)


text:
Are transactions many-to-many? If so, who decides on the grouping?
When I go to blockchain.info and explore transactions, I see a lot of individual transactions that seem to show bunches of addresses sending to bunches of other addresses.
https://blockchain.info/tx/221668ab11014c34da20296a1607ecc7967d1bdeecb884f1bf163e6b6c9f1d72
Does the Bitcoin network/protocol control that automatically, or is that done by the individual/agent initiating the transaction? e.g. Let's say I want to send 123 to one address. Is that going to be grouped into a big transaction involving many people and many recipients (including mine), or is it going to appear in the history as a transaction between strictly two addresses?

It is decided by the individual agent initiating the transaction.
The most basic transactions are typically one or two inputs to two outputs which is due to the way Bitcoin keeps track of balances. One output to pay, one output to give change to the sender.
Unspent Bitcoin are stored in chunks, often referred to as "UTXOs." I like to think of it as lumps of gold consisting of various weights: you could have a lump that is 10kg or a lump that is 0.001 grams. When you spend Bitcoin, you have to spend the entire UTXO, but you can save the extra balance by "spending it" as giving yourself change. Imagine if you had two lumps of gold, 2kg and 3kg, and you wanted to pay someone 4kg. You would have to melt the two together, and then split it to be 4kg to pay, and 1kg to save. At the end of the process there are now two new lumps of gold. Bitcoin works in a similar way, spending money requires you alter the money you already have.
It is possible to have a single input go to a single output, but the initiator would have to have a UTXO/lump that was the exact amount that they wanted to pay someone.
At the end of the day you shouldn't have to worry much about these details as a user, your wallet software will handle all the UTXO selection for you.

Transactions are not grouped or collected together in any fashion, unless the sender of every Bitcoin within that transaction agrees to that. CoinJoin is one way of grouping your transaction together with other people.
There is also a proposal called 'MimbleWimble,' which would make it possible to combine many transactions. This has not been implemented, though.

Mimblewimble transactions are not constant size.


text:
How is the size of a block calculated?
How is the blocksize currently calculated in Bitcoin Core? I'm specifically asking about how it's done for the purposes of enforcing the 1MB limit. If it's done by calculating the serialization length, what serialization format is used?

Don't know the exact answer, but these code snippets from bitcoin-core might help:
https://github.com/bitcoin/bitcoin/blob/master/src/consensus/consensus.h#L10
https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L2640
https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h

The block size is the combination of the block header and the list of transactions. Specifically, the block header has these fields:

version - 4 bytes
previous block header hash - 32 bytes
merkle root hash - 32 bytes
time - 4 bytes
nBits (encoded POW target) - 4 bytes
nonce - 4 bytes

So the total bytes for a block header is
4 + 32 + 32 + 4 + 4 + 4 = 80 bytes
After the block header is the list of transactions which is

transaction count - 1-9 bytes
transactions - varies

Transactions can vary greatly in terms of the number of bytes, but the general serialization of a single transaction is:

version - 4 bytes
tx in size - 1-9 bytes
tx ins - see below
tx out size - 1-9 bytes
tx outs - see below
locktime - 4 bytes

Each tx in has these fields:

previous tx out hash - 32 bytes
previous tx out position - 4 bytes
pubkey script - varies depending on script, max 10,000 bytes
signature script - varies
sequence - 4 bytes

Each tx out has these fields:

value - 8 bytes
pubkey script length - 1-9 bytes
pubkey script - varies

The sum total of all these things in a block determine the size, which currently has to be less than 1 MB.

block size = total block size - 8 bytes. The 8 being magic number and block size fields right?


text:
Does Blockchain.info track IP addresses?
I use Blockchain.info for my wallet, I use a secure anonymous email address.
My name and identifying information is never connected with my bitcoin, is it anonymous?
How can I keep my bitcoin wallets and usage anonymous?
Will Blockchain.info give up my IP address if "requested" by TPTB?
Should I be using TOR for all of this?
thanks!

"Should I be using Tor for all of this?" Well, it depends on what your threat model is.

You can access blockchain through Tor at http://blockchatvqztbll.onion/. Proof that this is the real website.

Please note that there are malicious tor exit nodes which attack against Blockchain.info users: http://bitcoin.stackexchange.com/a/30336/5464 - if you are a non-technical user I would recommend not using a web wallet over tor

Does Blockchain.info track IP addresses?

yes it does, see under Account - Settings - Logging
I guess that disabling logging only disables the DISPLAY of logging info on your side.
see https://blockchain.info/privacy:

What we collect
We may collect the following information:
Contact information including email address, skype or google talk username
iPhone or mobile device identifier
ip address
Yubikey or other two factor authentication toke

My name and identifying information is never connected with my bitcoin, is it anonymous?

Not really...  See the Bitcoin.org FAQ
Generally speaking, I'd say it MAINLY depends on how you get / spend bitcoins.
If you pay for something with TC, and give your shipping address, that's your anonimity compromised!
Avoiding address re-use gives more anonimity...

How can I keep my bitcoin wallets and usage anonymous?

It all depends on how anonymous you really want to be.
For example, do you use Google authenticator?
That add to security but certainly decreases anonimity
See also: https://blockchain.info/wallet/anonymity

Will Blockchain.info give up my IP address if "requested" by TPTB?

Sure!

We will not sell, distribute or lease your personal information to
  third parties unless we are required by law to do so.

(always from their "privacy" page)

Should I be using TOR for all of this?

If you want more protection, yes.
But depending on the usage you do of your bitcoin, it might be useless, as you anonimity is already compromised in other ways.


text:
Permission-less Side-Chain Concepts?
Pretty much every major side-chain concept seems to imply a permission governed finality system which is not ideal long-term for lots of hopefully obvious reasons.
Is there any good explanation as for why this is in the existing models?
Are there any that I have missed that do not have any sense of permission?
I am personally skeptical of the idea that permission is universally required for side-chain type functionality.


text:
Can two private keys generate the same (public) Bitcoin address?
I know that private key is generated randomly by wallet. Is it possible that wallet generate the same address which is used in Bitcoin?
In other words:
Given two private keys ka ≠ kb, is it possible that they both generate the same public Bitcoin address?

Yes, you can have two keys generate the same address.
There are 2^160 possible addresses, and 2^256 possible private keys, so each address corresponds to roughly 2^(256-160)=2^96 private keys. Any of these will generate the same address and thus be able to spend the money owned by that address. Since 2^160 is so large, however, it would take a near-eternity to find any collisions.
Whether two private keys can generate the same public key is another question. I think the answer is yes, but I am not sure on that. The public key in uncompressed form consists of two 256-bit numbers, which are X and Y coordinates on an elliptic curve. However, the compressed form is just the X coordinate plus a bit, from which you can calculate the whole public key. This means the space is (at most) 2^257. Unless there is a one-to-one mapping due to the mathematical properties of the cryptography used, each compressed public key corresponds to roughly 0.5 private keys (with the same distribution you'd get from picking a random number from 1 to 2^257, 2^256 times), so some private keys will collide, while others will not.
Actually finding any pair of different private keys that generate the same public key or address would be quite difficult. Either it would involve a huge amount of computation and/or luck, or it would be due to finding a serious vulnerability in the algorithm(s) used.

Yes and no. Both keys can be used to spend tx outputs in pay-to-pubkey-hash format (the most common). But if the tx output is in pay-to-pubkey format, then only the private key corresponding to the pubkey can redeem it.

@André Yep. It would have a good deal of notoriety if anyone noticed two signatures with different public keys for the same address in the blockchain. And to uminatsu: you're right, if there is a one-to-one mapping of private to public keys. In any case, paying to a pubkey hash gives you 256 bits of security instead of 160 (both are fine for real-world use, so the shorter is nicer for saving space)

Yes there is a one-to-one mapping of privatekey to (standard) publickey. Specifically the order of secp256k1 'n' is slightly less than (within the Hasse bound of) the order of the underlying prime field 'p' which is chosen to be slightly less than 2^256. Exactly (n-1)/2 values in GF(p) are valid X values in the curve equation, each of which has exactly two valid Y's, thus the number of points is n-1 which is also the number of integers in 1..n-1. (If you use ONLY the X-coordinate there are indeed collisions, as in BIP340 for Taproot years after your post.)

private keys above the group order have the same addresses as the keys starting at 0.
0000000000000000000000000000000000000000000000000000000000000000 fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141  1MsHWS1BnwMc3tLE8G35UXsS58fKipzB7a
0000000000000000000000000000000000000000000000000000000000000001 fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364142  1EHNa6Q4Jz2uvNExL497mE43ikXhwF6kZm
0000000000000000000000000000000000000000000000000000000000000002 fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364143  1LagHJk2FyCV2VzrNHVqg3gYG4TSYwDV4m
0000000000000000000000000000000000000000000000000000000000000003 fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364144  1NZUP3JAc9JkmbvmoTv7nVgZGtyJjirKV1

...
000000000000000000000000000000014551231950b75fc4402da1732fc9bebb fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffc  1HtRa3HaTfX4eDrTzkZWfnLD9cZAyhMDEd
000000000000000000000000000000014551231950b75fc4402da1732fc9bebc fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffd  1FvN1jJU6kQCub9nQFuJhdfixpBdngxLme
000000000000000000000000000000014551231950b75fc4402da1732fc9bebd fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe  1JHzdjEL4xQ7yifAaQQKAfqPyAN92vfstP
000000000000000000000000000000014551231950b75fc4402da1732fc9bebe ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff  12M4QznuNZH2BRVbLK8SKvNqGTPJpCpST7

The ones larger than the group order are invalid though, something must be doing mod n on the numbers to make a pubkey out of them.


text:
How do blockchain explorers know if the address is really generated?
I am studying how the Bitcoin addresses generation works.
As far as I learned, a Bitcoin address appears in the blockchain only after it has been involved in its first transaction. If an address has never been used in any transactions, it will not have a presence in the blockchain.
For this reason, Initially, I believed that without knowledge of the private key, there would be no way to verify if a given address is a correct hash generated from real key, or simply a random/made-up combination of characters of the same length (like some of those "vanity-addresses").
However, today I discovered that when I enter a genuinely generated BTC address that has never been used before (for sure) into the search field on blockchain.com, the latest displays a message indicating that the address is found but has no transactions.

To generate addresses, I used bitaddress.org and this python lib, I tried multiple times, using both, but the results always generally look like ones above.
On the other hand, when I change a single character in such an address or enter random digits and letters that visually resemble a BTC address (including length) but were not generated using the mentioned lib/service, blockchain.com states that "Nothing found."

How do the service distinguishes between real and made-up addresses, in this case?

Bitcoin transactions on-chain do not have addresses. They have scripts as output. In theory, pretty much any script is legal on-chain (ignoring standardness rules), including many unspendable ones.
To make things more convenient to work with for humans, certain standard scripts (in particular, P2PKH, P2SH, P2WPKH, P2WSH, and P2TR ones) have a human-readable notation associated with them, known as addresses (in base58, bech32, or bech32m format). These addresses include a checksum to protect against typos; a truncated double-SHA256 one for base58, a BCH one for bech32(m). This checksum, like the address itself, does not exist on-chain.
Software that interacts with the blockchain will generate/show scripts in address form (which means adding the checksum), and typically only accept entering scripts in address form (which means verifying the checksum in it). That holds for:

Wallets, when creating a new receive address.
Block explorers, when showing the scripts in transactions.
Wallets, when sending.

So how does the block explorer know the address it shows is valid?

If it's something you search for, it takes the address you input, parses it, verifies its checksum, converts it to a script, and searches its database for it. Even when nothing is found, the script is valid, so it can show that there are no results. If the checksum was invalid, it would instead tell you that the address is invalid.
If it's something found in a block or transaction, the explorer converts the scripts to their address form (including correct checksum), and shows you that.

In neither case is it certain that anyone has the corresponding key, unless there are also spends of the funds received to the address in question. In particular, one can compute scripts that look like a given string in address form easily, if one does not care about finding the corresponding private key.

Thank you for the detailed explanation! Would you mind If I ask you to add the details on this part: "it takes the address you input, parses it, verifies its checksum, converts it to a script"? It would be greatly appreciated if you could provide either the exact algorithm or offer a slightly more elaborate description of the steps involved, with any examples.

@Alex For the modern address formats (bech32 and bech32m), see the linked BIPs 173 and 350, which include test vectors, pseudocode, and links to reference code. For P2PKH and P2SH addresses with Base58 encoding, see https://en.bitcoin.it/Base58Check_encoding

An address is a standardized encoding of an output script with a checksum. Because of this checksum, a blockchain explorer can (with a high probability) tell between a valid and an invalid address.
However, a valid address doesn't mean anyone has the private key(s) to be able to spend from it, or even that such a key exists. All the blockchain explorer can tell you is whether the address has ever received funds (which any valid address can) and spent funds (in which case the private key exists and someone has access to it, or at least had at some point).
As a side note, addresses don't actually appear in the blockchain, only output scripts, which the blockchain explorer then converts to addresses (provided that the script has a standard address encoding).

Thank you! I would like to dive more into the subject, could you point in which direction I should look to learn more about "encoding of an output script with a checksum" (a little bit more specifically) and how does blockchain explorer uses it to predict if the address is valid or invalid?
Also, you say "received funds (which any valid address can)". But what about 1CounterpartyXXXXXXXXXXXXXXXUWLpVr? It has 2000 BTC, but doesn't seem to be a valid (if we talk about checksum) address. Or doesn't it?

@Alex see how does the blockchain addresses relate to the blockchain WIF? and answers to questions tagged "address generation"

@Alex The 1Counterparty address is valid. It's just that almost certainly, nobody has the corresponding private key, so those 2000 BTC won't ever move. But there is no way for Bitcoin software to know that nobody has the private key for it, so sending to it is valid.

@Pieter Wuille, yeah, I understand this, but initially, I thought that you could actually send Bitcoins to any (even invalid) addresses. How do you determine that 1Counterparty is valid (valid in which sense, by the way)? Does the blockchain or Bitcoin software reject attempts to send transactions to invalid addresses?

As explained, Bitcoin addresses have a checksum built-in. The address is valid if it has a valid checksum. Computing the checksum doesn't require access to the corresponding private key. The 1Counterparty address has a valid checksum (that's where the weird UWLpVr at the end comes from). The checksum only protects against typos in the address, it has nothing to do with whether a private key for it is known.

Also note that this checksum does not exist on-chain (just like the rest of the address). You can send to any script, in theory. Some scripts (and practically, all the ones that are used) have a convenient human-friendly encoding that includes a checksum, called the address. In practice, wallet software will only let you send to scripts if you enter the corresponding valid address. The block explorer computes the address, including the checksum, based on the on-chain data.

@PieterWuille Omg, so many thanks! You reminded me that I read somewhere, and now I realize that the last 4 bytes on the right side are the checksum (specifically: first 4 bytes of the SHA-256 hash for the initial SHA-256 hash) of the key. Thanks a lot, correct if I am wrong!


text:
Is the Taproot upgrade really essential for BRC-20 tokens on Bitcoin?
BRC-20 currently relies on the Taproot upgrade. I'm wondering how blockchains such as Dogecoin, which have Bitcoin as their predecessor and did not upgrade to Taproot, manage to support BRC-20. More specifically, I'm wondering if Bitcoin was actually able to support BRC-20 without the Taproot upgrade.
I wasn't able to find much on how to implement BRC-20 without relying on Taproot. However, I did find an example implementation for Dogecoin here. It seems to boil down to splitting chunks of inscription data among several chained transactions. Each chunk is included in an unlocking script.
Is there something I'm missing here? Was BRC-20 possible all this time on Bitcoin even without Taproot?

As far as I know, in principle, BRC-20, or something equivalent, only really needs to store about 60 bytes in some predictable location in a Bitcoin transaction. Nothing else.
There is a very long history of storing arbitrary data in the Bitcoin blockchain. From the earliest days people stored images etc as data "in addresses" which I guess means in places intended for public keys or hashes of keys, etc.
So far as I know, new features like OP_RETURN, Segwit, etc just made this less problematic and cheaper.

If I understood correctly, when data is stored "in addresses", it makes transactions unspendable, meaning that the UTXO set gets bloated unnecessarily. But in this case, if I understood the Dogecoin inscription code, transactions are still spendable - spending is in fact necessary to "reveal" the data, since the script contains the data (and this data is not visible from just the script hash). I suppose Taproot made this process more convenient/cheaper then, but it isn't "essential" as many sources claim.


text:
What does the block time represent?
I've always been under the impression that a block's timestamp represents the second at which a block was found.
For this to be true, it would seem that the time header field must be modified along with nonce and possibly other fields in the mining loop(s).
But I don't see that there is anything enforcing that a miner does this.  If not, then a miner could start mining a block at say 04:30:25 and find the block approx ten minutes later at 04:40:55, but the block will have timestamp 04:30:25.  So long as 04:30:25 is later than the previous block, it should still satisfy consensus rules and be accepted by other nodes.
If my analysis is correct, then it seems the best we can do is infer what the timestamp represents by comparing it to the time at which other nodes actually received the block.
And I believe that by convention, it does normally represent the second of finding the block.  But I imagine there may be exceptions existing in the blockchain.
So, have I got this right?   Can anyone succinctly state what the block time time field truly represents?
Eg, if I wanted to put a label in a block explorer, perhaps with a one sentence description, what should the label and sentence be, such that I am not misleading users?

I've always been under the impression that a block's timestamp represents the second at which a block was found.

It is, though not with that much accuracy. The protocol allows for a roughly 3-hour window around that timestamp (1 hour in the past, 2 hours in the future).

For this to be true, it would seem that the time header field must be modified along with nonce and possibly other fields in the mining loop(s).

In practice, miners do this, but not actually inside the mining loop. Modern mining chips can churn through the entire 232 nonce space of a given block candidate in under a second, at which point they need to receive new work from the controller anyway. That new work can mean a change in extranonce (inside the coinbase transaction), rolling of the timestamp, or something else.

But I don't see that there is anything enforcing that a miner does this.

The only hard consensus rule is that the timestamp of a block is strictly larger than the median of the timestamps of the 11 blocks before it. Under normal circumstances, that means the timestamp can be up to an hour in the past.
There is an additional acceptance rule, where nodes will not accept blocks whose timestamp is more than 2 hours into the future compared to their own local clock, at the time it is received. This isn't a consensus rule per se, as local clocks are subjective, and violating this rule doesn't mean the block is permanently rejected; just temporarily not acceptable. Still, this means it is generally not beneficial for miners to intentionally set timestamps in the future (unless perhaps when it is many miners at once doing so, making this akin to a selfish mining attack).

Can anyone succinctly state what the block time time field truly represents?

The time the block was mined, within a precision of hours. Usually it's more precise than that, but this cannot be relied upon.


text:
Nonstandard witness when building a transaction
i try to spend a P2WSH 2of2 multisig input in Python for learning purposes.
When i check my assembled TX with testmempoolaccept i get "bad-witness-nonstandard".
This is my function to assemble the witness:
def get_p2wsh_witness(privs: List[bytes], msg: bytes) -> bytes:
    sigs = [sign(priv, msg) for priv in privs]
    witness = bytes.fromhex("04")
    witness += bytes.fromhex("00")
    for sig in sigs:
        witness += len(sig).to_bytes(1, "little") + sig
    musig_script = b""
    op2 = bytes.fromhex("52")
    op_checkmultisig = bytes.fromhex("ae")
    musig_script += op2
    for key in privs:
        key = get_pub_from_priv(key)
        musig_script += bytes.fromhex("21")  # 33 bytes
        musig_script += key
    musig_script += op2
    musig_script += op_checkmultisig
    musig_script = len(musig_script).to_bytes(1, "little") + musig_script
    witness += musig_script
    return witness

This is how i assembled the commitment hash:
def get_commitment_hash(outpoint: bytes, scriptcode: bytes, value: int, outputs: List[bytes]) -> bytes:
    def dsha256(data: bytes) -> bytes:
        return hashlib.new("sha256", hashlib.new("sha256", data).digest()).digest()
    result = b""
    result += (2).to_bytes(4, "little")
    result += dsha256(outpoint)  # hashPrevouts
    result += dsha256(bytes.fromhex("ffffffff"))
    result += outpoint
    # Passed scriptcode (hex): 522103abd618be2d6e412bb31457bf416cf05138592da9ab4c9647a79577492710eacb2103bc2e2480bd8f5a66d45ceb333db45a980283a3c55df3c23eed22f30aa99e82e852ae
    if len(scriptcode) > 30:
        result += len(scriptcode).to_bytes(1, "little") + scriptcode
    else:
        result += scriptcode
    result += value.to_bytes(8, "little")
    result += bytes.fromhex("ffffffff")
    result += dsha256(b"".join(outputs))
    result += bytes.fromhex("00000000")
    result += bytes.fromhex("01000000")
    return dsha256(result)

This is the UTXO's origin transaction:
02000000000101f823195349b831db24d266223c16030ce52062e984c113df966be11a3cef881d7e00000000ffffffff0240420f000000000047522103abd618be2d6e412bb31457bf416cf05138592da9ab4c9647a79577492710eacb2103bc2e2480bd8f5a66d45ceb333db45a980283a3c55df3c23eed22f30aa99e82e852aec26e7b000000000016001437528e3adfd4f8c5322164689306f9a3c24571aa02483045022100d0a4effc5f870a8845a33c584d9239b97b8a28a85e95c43e5e7dd2bc31876fe202201c6996b0b3ee4981fcfd620ca3199f20b3630ae846b2cfd28a82004d85acdcc50121023e7362dad760249706fc4526d8781a70571b125a2ff51b817ba5b8fa5706ec1400000000
0400483045022100ec7dfded7d97f8d990d8470b0855a705c118dff718aed9f5a6c5faa24c33a03402207919d822f44bb3a36ffb0771e2e4dc99688e002e26a71fc53224eba84aa526d6014830450221009535cda9d3533a8b95ab3cbd8004b1fc4d689d5104ae0c027b4e857a6345e54b022020b8df4231a2fb0fbcbf2d7593f0fbdb63d72feea04167afcd1708fba130dd8a0147522103abd618be2d6e412bb31457bf416cf05138592da9ab4c9647a79577492710eacb2103bc2e2480bd8f5a66d45ceb333db45a980283a3c55df3c23eed22f30aa99e82e852ae

These are the (private signet) private keys in hex to sign with:
3e2d99b06d1e763e8a208d0f2522432596fc1ae75825e777fb6b04ecf7260848 27d7edd524be491da6f5996e830e92b5477844800155e47f672cd5527f3a0e7d

This is the final assembled tx, spending to one OP_Return and change:
02000000000101693328a732e0d167e50b70342a5301a467aa96d2008117dcac64852f0b11fe410000000000ffffffff020000000000000000076a056633323178583e0f000000000016001437528e3adfd4f8c5322164689306f9a3c24571aa04004830450221009549d71c7826fdb55b1934d91ee261c4e47930e2ec837d15237a8a3ac2efeddf02204f50948a3babaabc53b42f49ab140c6a1988f4ef90af3badc72c1ff43305b84b0147304402203e61b80619eac28e15e15bdef2844bc942f87be00f7945c241fb0e474ffba5fd0220327c0b6c413ac3cbe3f1e75052c9042899353ab70c7b5312175605125139024e0147522103abd618be2d6e412bb31457bf416cf05138592da9ab4c9647a79577492710eacb2103bc2e2480bd8f5a66d45ceb333db45a980283a3c55df3c23eed22f30aa99e82e852ae00000000

Can anybody see an obvious mistake here, assuming sign() and the given keys are correct, or give a hint on how to verify the output myself?

Can you also include the final assembled transaction?

The problem is you're creating a bare multisig output, not a P2WSH output. When you're subsequently trying to spend it as if it were a P2WSH output, Bitcoin Core errors because bare multisig inputs aren't supposed to have witness items.

This did solve the problem. Recreated the transaction that was used as input as proper p2wsh instead of bare multisig and then spending it did work fine with the code above. Thanks.


text:
Which private key is used in Taproot transactions?
The transaction only has one input, where its scriptPubKey is --> Op_1 Q , where Q is the tweaked public key.
Let p = private key, P = Public key, q = p + tweak, Q = tweaked Public key
To create the transaction you have to populate the witness field:

Key Path Spend:
Do you use q (the tweaked private key) to sign the transaction?
That is,  s = k + H(R,Q, txdata)q and sig is (R,s) where k is the nonce

Script Path Spend:  Do you use p (untweaked internal private key) to sign the transaction
That is,  s = q + h(Q,P, txdata)p and sig is (Q,s) where q is now the nonce

I am not a coder so trying to find the answer to this has been difficult given that I think you would need to code to understand how the mechanics works.

Vojtěch - I appreciate the quick response and the link to BIP341. I read the article (several times) and I can say that I now finally understand Taproot. However, it was your comment about the keys used to sign a Script Path Spend transaction, are the ones in the executed scripts that actually made it all clear to me. I am not sure why it didn't click in my head previously, as its seems so obvious now.

In a key path spend, you always sign with the private key corresponding to the output key. If that key is a tweaked public key (it's recommended to always use a tweaked key), you will also need to tweak the private key.
In a script path spend, the internal (untweaked) key is used to prove the committment to a script tree. The actual script will contain its own public keys that may be unrelated to the internal or output key, and producing signatures for them will require their corresponding private keys.
You may wish to read BIP341: Script validation rules to make sure you understand how exactly Taproot inputs are validated.


text:
How to save the derivation path with my paper wallet seed phrase?
If I only save the seed phrase and public key after generating them, my understanding is I need to know the derivation path used in order to find the correct private key from the seed, in the future? Are the infinite address and key pair possibilities created in a specific order based on the derivation path?

Most wallets, especially those using BIP39 seed phrases only use (a subset of) these standard derivation paths:

m/44'/0'/account'/change/address_index (P2PKH, BIP44)
m/49'/0'/account'/change/address_index (P2WPKH-P2SH, BIP49)
m/84'/0'/account'/change/address_index (P2WPKH, BIP84)
m/86'/0'/account'/change/address_index (P2TR, BIP86)

If your wallet uses one of these paths, you probably don't need to write it down. Other paths used by wallets can be found on walletsrecovery.org.
Wallets using these standard paths always create private keys in increasing order of address_index (for every account created if the wallet supports multiple accounts). When you import the seed phrase into a compatible wallet, it will create and scan addresses in the same order, until a long enough gap of unused addresses occurs.


text:
How can an external party be sure that node's response is valid?
Assume that 51% of nodes are honest and 49% malicious. Fur sure, longest chain would make the chains consistent/same all over the world as 51% can outweigh the 49%, but my question is slightly different.
If I am an external party(just a normal user) and ask whether the specific tx is in the specific block, how can I be sure that this request didn't reach the malicious node ? The solution is for me to get merkle root from a block header, then a node must return to me the proof and then I verify, but, but, but...
my confusion is that I also have to ask for merkle root to the node and how can I be sure that the "asking merkle root" request goes to honest node ? what if it ends up going to the malicious node - since 49% is malicious, it's likely that my request could end up to this malicious node geographically and it could return such a merkle root that the next request of me making for proof also returns appropriate proof to this malicious merkle root. I hope I made sense.

A Merkle inclusion proof is a proof that a transaction is included in a block with a particular hash, nothing more. Whoever gave you that proof can lie by omission (claiming no transactions you asked for exist in the given block), but if a proof is given, it can be validated.
As I believe you realize, the proof only covers the inclusion of a transaction in a given block. It doesn't prove anything about that block itself. You must independently acquire information about that block and ascertain it is part of the currently best active chain. If you just ask some node what their best chain is, they can claim whatever, and you're trusting that node entirely. That is however not how you're supposed to use such inclusion proofs (unless you have reason to trust them, e.g. because it's your own node, or because it's run by a known entity that you're willing to rely on).
Instead, you (the verifier) would generally run a lightweight network node, which does some part of the network validation. It would connect to multiple other nodes, download the block headers from those nodes, and validate them (just their syntactic correctness and proof-of-work). Among the headers chains you received, you'd pick the most-work valid one, and then verify the Merkle proof against that.
There are still ways in which you can be cheated, but it's not as simple as a single node lying to you:

Since you are only validating the headers, it is possible that the highest-work headers chain is not actually a valid blockchain (e.g., it could contain unauthorized inflation, theft, or double-spending). Doing so would not convince full nodes, but it can convince lightweight nodes. The theory is that attackers will not try this because it is expensive, hard (needs a majority of the hashrate to keep up), and hopefully a sufficiently important part of the ecosystem would not accept their blocks, thus making the cost of mining wasted. However, this assumption does rely on the presence of enough fully-validating nodes in the network to make the attack uneconomical. If you are concerned about this, your own option is running your own fully-validating node instead of a lightweight one.
If all peers you talk to are attackers (or colluding with an attacker), something referred to as an Eclipse attack, and are thus shielded off from the real best chain, attackers can get away with constructing an alternate minority-hashrate chain, and hiding the real best chain from you. Depending on how long they can keep the Eclipse attack, this may still be extremely expensive.

Note that "majority of nodes" is never relevant in this analysis. The criteria are whether you have at least one honest peer, and whether a majority of the hashrate is working with the attacker.

Thank you Pieter. That's what I was looking for. Basically,  I can be lied if my request goes to the node that is in 49% - since these nodes are building a different chain(it's still valid), their responses would be different than what 51% of nodes would return. My main concern was that what if I'm a normal user and I just use an endpoint of rpc that goes to one of 49% nodes. In this case, I am tricked. what I gathered from your answer is that I must run a lightweight node and that lightweight node would get the longest chain and I should make a request to my node. All correct ?

Mostly right. Nodes generally do not expose RPC access to anything but their operator; you can't just ask a random node on the network things through RPC, you can only use the P2P protocol with them (which is for communication between nodes). So yes, you'll run your own node (lightweight or not) and it will communicate with other nodes, and then you can request information from your own node yourself. Also note that hashpower and nodes are very different; just because a majority of hashrate is honest does not mean a majority of nodes are.

Thanks Pieter. :) Have a great day..

I interpret your question as "why can I trust a Merkle proof?"

A cryptographic hash function processes an input and always returns the same output. If you change the input in the slightest, you will get back a completely different result. It is considered computationally infeasible to find other inputs such that they produce a matching output to other inputs. The range of outputs is so humongous that merely knowing a specific output is proof that we knew about the corresponding input.
A block id is produced by hashing the header of a block. The header includes the previous block’s id and the Merkle root. The block hash must fulfill the current difficulty, which means that it must be an extremely unlikely low hash. Because it is so much work to find a valid block, it is hard to produce a block header that commits to other data but has a valid proof-of-work.
Miners decides which transactions they try to include in their block before attempting to find a valid block header. From the list of transaction ids, they build a Merkle tree. The Merkle tree starts from the transaction ids as the leaves and hashes them together pairwise at each level. Finally we get a Merkle root that compactly commits to the inclusion of all transactions.
Putting it all together, we have a block header that is covered by a proof-of-work that is expensive to fake, which commits to a Merkle root. We have a Merkle root that commits to all transactions, and vice versa, by showing that we know the hashing partners that form a series of hashes that connect a transaction id to the Merkle root, and the chain of block headers that connect the block to the Genesis block, we can provide a credible proof that a transaction is present in a block.
Malicious nodes can lie by omission: "No, I’ve never seen that transaction." But for honest nodes making a proof is cheap, and when you do get a proof, it is trivial to check whether it is valid and connected to what you think is the best blockchain. If a malicious node tried to lie to you, they would have to perform very expensive proof of work to stand a chance.

Unfortunatelly, I knew all this. My question is about sending a request to one of the malicious node. If 49% of the nodes are malicious and they collude to start working on a different chain after block number X, and at that moment, I send 1 btc to Bob, bob could see that he got 1 btc because his request went to honest node.so he sends me a bike. Now, he asks again whats his balance and his request goes to colluding node which still has a valid chain but does not contain the 1 btc tx. Even if Bob waits for 6 confirmations, such hard fork of 51-49% still tricked him.

You can remove what you wrote though. Sorry I was not clear maybe on the question.

It seems to me that my answer is relevant here: If you are concerned that a large subset of miners are working on an alternative chaintip, the Merkle proof they provide will link a different chain of block headers than the one your lightweight client is following (covered in points 2 and 4). Or is your question "How can a lightweight tell whether the chaintip with the most work is valid?"

The user is an external user, someone who has no knowledge of what rpc is and what "request" is. The user might be using a software or rpc endpoint of the node that is in 49% of my scenario. In this case, user first gets the merkle root of that node's chain's one of the block and ofc, the proof as well will be exactly corresponding to that merkle root, in which case, user will think that he got 1 BTC, but 10 minutes later, the another node(that is in 51%) will return him his balance as 0.

Please see @PieterWuille’s answer, it seems to be better covering your question.

Yes, I just read his answer and it's exactly what I was looking for.


text:
If no push opcode, how does item still end up on stack (tx verification)
I was reading the following link and there it says: "Alice’s pubkey script then pushes the pubkey hash that Bob gave her for the first transaction". I mean how ? there's no opcode for that. The previous opcode was OP_HASH160 which pushed hashed public key, after this, there's no PUSH opcode, so how does pubkey hash get pushed again ?
I think I also have another question exactly related to this. In the signature script, does it include push opcodes ? if not, how does signature/public key end up being pushed on stack ? bitcoin.org directly mentions that this is what node executes in order:
<sig> <PubKey> OP_DUP OP_HASH160 <PubkeyHash> OP_EQUALVERIFY OP_CHECKSIG

so if there's no push opcode for first 2 items, not sure how they go on stack.
Thanks for your time.

The notation < > implies a push opcode of appropriate length precedes the data item. It's just a convention when writing about Bitcoin scripts.


text:
What additional benefits can QR codes bring to Bitcoin applications beyond payment requests?
Anyone who has recently used one of the Bitcoin wallets on a mobile device (and some desktop  clients) will have seen a Bitcoin QR code. Clearly, QR codes allow for a succinct method for transferring complex information in a reliable and error-resistant manner.
Naturally, the most obvious use of a QR code is for encoding a payment request URI. However, are there any other benefits that QR codes can bring to Bitcoin beyond this?
I'm thinking in terms of marketing, exotic transaction types that sort of thing.

In terms of marketing, here is a very nice QR code that could be used for spreading the word about Bitcoin. It contains a link to bitcoin.org. See this thread on bitcointalk.org for more information. It was created by phelix at bitcoinx.com.

You can use QR codes with Shamir's Secret Sharing for making secure backups of deterministic wallets: http://code.google.com/p/bccapi/wiki/ManagingLongPassphrases

Speaking of which, here's a pretty straightforward, easy-to-read python implementation of Shamir's Secret Sharing: https://github.com/halfmoonlabs/secretsharing

We just need to define a standard for it

You can use also use the standard bitcoin URI QR codes to transfer bitcoin addresses from one application to another. For instance you can show your Instawallet.com bitcoin address as a QR code and drag it into the MultiBit send bitcoin screen. (www.multibit.org). It automatically parses it and creates an 'address book' entry with the bitcoin address and label 'Instawallet'.
Similarly, you can generate a bitcoin QR code with a bitcoin address and your name as a label in the MultiBit receive bitcoin screen, copy it and print it on the back of your business card.

I believe QR will be to BTC what paper is to cash. I even registered long ago QRBitCoins.com (and others) and am now waiting for the right project to prompt some work. I thought I should tell people in case there is any interesting on-going project that would need a good QR domain.

+1 for an interesting insight into the relationship between Bitcoin and QR codes

There was a thread on bitcointalk about creating a specification to encode additional data (besides the address) in QR codes. This would work with a key/value pair and it could be used for a lot of things. Here is an example for merchant/buyer interaction:

Merchant request for direct payment via bitcoin network.
Code:
btcpayment-request1: name=“My Bitcoin Inc.”; pubkey=1LGpwDU5djqsR1X14Tcass3y9fULTzxJq3; amount=300
Using this QR-code, the mobile phone knows enough to ask the user if
  they wish to pay 300 BTC to My Bitcoin, Inc. at the given bitcoin
  address.  Presumably the mobile phone has the ability to make bitcoin
  payments, either directly (a lightweight bitcoin client) or indirectly
  via a payment API such as this.

If I recall correctly, a bitcoin transaction can be coded to require a password to access them. Therefore, you could make the QR codes a way to hold a bitcoin outside of a wallet.

+1 for an interesting script use case. Details of the shared secret approach are referenced here: http://bitcoin.stackexchange.com/questions/547/useful-alternative-bitcoin-transaction-scripts

Inexpensive 2-factor authentication
A QR code could be used a contributor to a 2-factor authentication ("Something I have and something I know") system. When making payments a person could input a PIN as one part, and scan a QR code they carry with them in their physical wallet (could be printed on a plastic card for example) as the second part.
This approach could be used as a pre-authentication to provide the wallet application with temporary access to a private key held on the mobile device. This private key could then unlock the local wallet or act as an authentication key to a remove service.
It does have weaknesses though:

A high-definition CCTV mounted near the point of sale could catch people whipping out their plastic card in preparation and a bit of image manipulation would harvest QR codes
It's a bit fiddly and is probably only for the security conscious

Food for thought.


text:
I bought bitcoin several years ago. It it possible to find them now?
I bought bitcoin years ago. Is it possible too find them ?


text:
Collected bitcoins at https://btcfree.win/ And made a GENERAL WITHDRAWAL 0.2 BTC
Collected bitcoins at https://btcfree.win/
And made a GENERAL WITHDRAWAL
0.2 BTC To the card, but unfortunately the withdrawal to the card did not arrive. Tell me how to find out if it will come at all or not???


text:
Xverse Wallet. Logs into an account with a different wallet
Such a disaster happened. I created an Xverse wallet on April 20, copied the address and sent Ordinals tokens to it (address - bc1p...). I logged in today, I was kicked out of my wallet and asked to enter a seed phrase, I entered it and logged in, but there was a different wallet number and there were no funds.
I've been reading forums all day, Google, I learned about BIP and how Bitcoin works in general, but I still haven't found an answer. Help me please.
P.S. I started putting different numbers in Sparrowallet here m/XX'/0'/0' - but I can't find it. Initially it sets 86, but it’s possible that when registering Xverse something else was specified for this wallet.


text:
Specified data directory does not exist - but it does
Similar to this question, bitcoind does not recognize an existing directory, even if it does not contain spaces as was the problem mentioned.
bitcoin.conf
# Specify a non-default location to store blockchain and other data.
datadir=~/bitcoin

Terminal (Linux):
USR:~/bitcoin-27.1/bin$ ./bitcoind -daemon
Error: Error reading configuration file: specified data directory "~/bitcoin" does not exist.
USR:~/bitcoin-27.1/bin$ cd ~/bitcoin
USR:~/bitcoin$

I'm pretty sure Bitcoin Core does not expand ~ into the home directory path. Try providing the full path, you can get it with pwd.

Thanks. It worked

Default folder is in the user folder, but name of the folder is .bitcoin.


text:
Is pastors-btw.top a scam?
I just received an invitation to go to bitcoin it directed me to payout section it only asks for email where to send the money. Wants to know account number it telling that I have 106000 the there the submit to manager is this legit also paystore ?

See How to tell if a cryptocurrency exchange or trading platform is trustworthy?

Whenever you're told you supposedly own money that you know nothing about, it's pretty safe to assume it is a scam. At some point they'll likely tell you to send them some bitcoin to "verify" your account or to pay an advance "fee" or "tax". Don't send them anything, you'll never get it back and they'll come up with excuses to make you send them even more.
See: Is it normal to be asked for an advance fee on a withdrawal?