text:
Byzantine fault-tolerant consensus - Why 33% threshold
Can somebody tell me why in dbft the threshold is 1/3 for malicious nodes? I mean that seems pretty abitrary. I have no problem if it is abitrary but is it?
Note: I'm not referring to Bitcoin. I chose this Forum, because there is no game-theory or Antshares/Neo-forum.

We have a mathematical proof that to tolerate n malicious nodes, you need 2n + 1 good nodes. The full proof is found in G. Bracha and T. Rabin, Optimal Asynchronous Byzantine Agreement, TR#92-15, Computer Science Department, Hebrew University. It's also well known in the industry. It is not possible for an asynchronous system to provide both safety (the guarantee that all non-malicious nodes will eventually agree on what progress was made) and liveness (the ability to continue to make forward progress) with more than this number of malicious failures.
You can trivially ensure safety by simply making no forward progress at all. And you can trivially make forward progress unsafely by just letting each node do whatever they want. Neither of these modes of operation are useful.
Let's take a step back to make this answer more helpful:
Why do you need a distributed agreement algorithm at all? Well, you need one in cases where there is more than one way a system could validly make forward progress and you need all the participants in the system to agree on which one of them.
Consider a simple example: I have $10 in the bank, and I write two $10 checks, one to Alice and one to Bob. Either one alone is valid, but we can't let them both go through.
If we had a central authority, they could just clear whichever one they saw first. But what if we don't want a central authority or don't want a single point of failure? And what if we have potentially malicious participants?
Well, you could just sort the checks after representing them as binary data. But that's where the asynchronous component bites us. When do we sort them? Say I see both checks and sort them. How do I know that one second later I won't see a third check that sorts first? And maybe someone else already saw that one. Ouch!
So, we have the following requirements:
1) Our system is asynchronous.
2) Some participants may be malicious.
3) We want safety, that is, we do not want one honest participant honoring one check and one honest participant honoring the other.
4) We want liveness, that is, it's not fair just saying we never clear any checks. Sure, that's safe, but not useful. We want to be sure that we eventually agree on which checks to clear.
So, now the question arises -- how many dishonest partcipants can we tolerate in our asynchronous system and still guarantee both safety and liveness?
As a simple way to get the gist of the proof, though it is not rigorous:
Suppose we have n nodes of which h are honest and d are dishonest. Obviously, n = h + d. Now the system needs to come to consensus on which of two checks to clear.
Think about the case where all the honest nodes are evenly split about the two directions the system could make forward progress. The malicious nodes could tell all the honest nodes that they agree with them. That would give h/2 + d nodes agreeing on each of two conflicting ways the system could make forward progress.
In this case, the honest nodes must not make forward progress or they will go in different directions, losing safety. Thus, the number of nodes required to agree before we can make forward progress must be greater than half the number of honest nodes plus the number of malicious nodes, or we lose safety.
If we call t the threshold required to make forward progress, that gives us: t > (h/2) + d. This is the requirement for safety.
But the malicious nodes could also fail to agree at all. So the number of nodes required to agree before we can make forward progress must be no more than the number of honest nodes or we lose liveness.
This gives us t <= h. Or h >= t. This is the condition for liveness.
Combining the two results, we get:
h >= t > (h/2) + d
h > (h/2) + d
(h/2) > d
d < (h/2)

Thus the number of faulty nodes we can tolerate is less than half the number of honest nodes. Thus we cannot tolerate 1/3 or more of the nodes being dishonest or we lose either safety or liveness.

Can you provide a link? Your description could not clearify it for me. I also do not know what is meant by directions. In a peer to peer network there is no direction.

What do you want to tell me with that?

yes. I was asking for a link to "G. Bracha and T. Rabin, Optimal Asynchronous Byzantine Agreement, TR#92-15, Computer Science Department, Hebrew University". "Think about the case where all the non-faulty nodes are evenly split about two directions the system could make forward progress." I do not know what is a DIRECTION in a peer to peer system.

Can you maybe assign a number or letter to the different kinds of non faulty nodes in your example. In your example one half does something else then the other half but you do not assign different characters or so to them, which makes it pretty hard do understand.

I cannot figure out what this sentence should mean "Think about the case where all the non-faulty nodes are evenly split about two directions the system could make forward progress." If the non-faulty node goes in a other direction then another non-faulty isn't it then a faulty node?

Why would they disagree? Because they received a different message from a speaker? Like in Antshares examples? https://github.com/neo-project/docs/blob/master/en-us/node/consensus.md

Ok I'll study that abit now. Give me some time. Maybe I'll have another question, but I'll confirm this as the right answer after I thought abit about it.

how is forward progress defined? Is it any progress regardless of whether it is disruptive or not? Can you also define the terms safety, liveness? Maybe with a reference to a speaker scenario like in Antshares?

Is that a correct definition of forward progress: forward progress is made after reaching consensus is reached. ?

@Invader For formal proof purposes, forward progress is usually defined as ruling out at least one future state of the system that was previously possible. For purposes of a particular algorithm, it's usually defined in an algorithm specific way such as confirming one transaction or whatever.

In the example where faulty nodes agreee with all non-faulty nodes (which go in two directions) safety is not there. Because half of the non-faulty nodes have not agreed with the other half of non-faulty nodes. "safety - the guarantee that all non-malicious nodes will eventually agree on what progress was made". Can you explain, what I did not grasp there? What happens if the non-faulty nodes do not agree? The system would make forward-progress anyway or not, because the threashold is reached?

Also I do not understand why a non-faulty note should go in the same direction as a faulty one. A non-faulty node would always reject non-valid transactions/blocks. Or in other words if a faulty node agrees with a non-faulty nodes direction why is that a malicious action of the faulty-node?

Let us continue this discussion in chat.

How does this relate to PoW? I mean in PoW we can have d > (h/2) and everything still works fine, but it takes longer to achieve arguably finality. In PoW if d is to big, then there is the possibility of a chain-rewrite.

@Invader Everything doesn't still work fine. It may still work fine or it may fail. There's a statistical chance you're fine and a statistical chance the dishonest nodes will win. PoW sacrifices safety to tolerate more dishonest nodes, and that's a perfectly reasonable choice to make.

So this formula d < (h/2) actually says that you can create a system that has have safety (does not produce forks) and liveness in case you have d < (h/2), but you cannot create such a system with the same properties with d >= (h/2)?

Or in other words. You cannot create a system that has safety and liveness and d >= (h/2) byzantine nodes. True?

@Invader Right. You can pick a threshold and then compute when you lose safety and when you lose liveness. But no threshold will preserve both safety and liveness once you exceed 1/3 failed nodes.

Thank you, So in this case, contrary to belief that Bitcoin is secure till majority (= 1/2) of mining power is honest should be wrong, isn't it? Thanks

@sas Bitcoin isn't secure even if all mining power is honest. Consider, for example, if a network failure splits the network in two. Both sides will produce blocks every 20 minutes on average and both sides will eventually have sufficient confirmations to rely on transactions that could conflict from one side to the other. The applicability of these theoretical results to practical systems is not always simple or direct.

@David Schwartz , With considering the well-known paper titled: "Impossibility of Distributed Consensus with One Faulty Process" (https://apps.dtic.mil/dtic/tr/fulltext/u2/a132503.pdf) showing that no completely asynchronous consensus protocol can tolerate even a single unannounced process death, can we still assume that the network is asynchronous ? As in that case the network cannot tolerate even one faulty node. Thank you.

@Questioner It's the difference between theory and practice. Bitcoin has zero partition tolerance, so in theory it's completely useless. But it works perfectly fine in practice, even if the network partitions.

The intuition here... could two nodes get to the point that the majority (e.g. both nodes) agree? If one of the nodes is malicious, then no, that node can always vote against the honest node.
Could three? Seems like they might - couldn't the two honest nodes figure out who the third dishonest node is? But in fact, they cannot - the dishonest node D can tell honest node A one thing, and honest node B another thing.
Let's say they are trying to agree on the color of the sky.
Honest Node A hears from honest node B: "I think the sky is blue, and node D says the sky is blue too". But A hears from dishonest node D: "I think the sky is red, and node B thinks the sky is red too". What is A gonna believe?
In the case of 4 nodes, if there's only 1 dishonest node, node A would hear two versions of "the sky is blue" and one version of "the sky is red" - so A would go with the sky being blue.
Essentially, if a malicious 1/3rd of the nodes can counteract the vote of an honest 1/3rd... then you need one more node as a tie break. Hence, 3f+1 nodes, where f is the number of dishonest nodes 2f+1 is the number of honest nodes.

According to Wikipedia's article on Byzantine Fault Tolerance, that is only true when messages can be forged. Because showing a solution exists to the whole Byzantine Generals Problem can be reduced to showing a solution would exist to the problem of one General and two Lieutenants, and each Lieutenant wouldn't be able to tell whether the messages they were getting were really from the General or forged by the other Lieutenant.
However, for unforgeable messages (or where forgeries are infeasible) you could have an arbitrary number of traitors. Quote:
"A second solution requires unforgeable message signatures. For security-critical systems, digital signatures (in modern computer systems, this may be achieved in practice using public-key cryptography) can provide Byzantine fault tolerance in the presence of an arbitrary number of traitorous generals."
Source: https://en.m.wikipedia.org/wiki/Byzantine_fault_tolerance
To address the derivation given by @DavidSchwartz for example:
"Think about the case where all the honest nodes are evenly split about the two directions the system could make forward progress. The malicious nodes could tell all the honest nodes that they agree with them. That would give h/2 + d nodes agreeing on each of two conflicting ways the system could make forward progress."
If each honest node only accepted signed communications from others, then by gossiping, the honest nodes would learn of the malicious nodes' duplicity and stop listening to them. An algorithm could theoretically be designed that would automatically maintain both forward progress and liveness in each subset of honest participants, whose connections form a connected graph. (Obviously if their only links are through malicious participants, they cannot get any messages through to each other reliably.)
In the XRP consensus protocol, these signatures do constitute proof of malfeasance by the actual validators. The trick is figuring out how a group can achieve consensus as to who is a validator and who is not. Gossiping proof of malfeasance should be enough to stop an honest node from listening to that validator. As noted in their whitepaper, they value correctness before consensus.

@DavidSchwartz let me know if I made any mistake here, but I think that unforgeable signatures are a get-out-of-jail-free card allowing both liveness and progress in theory. There may, however, be an additional theoretical result on lower bounds that I (and the editors of the wikipedia article) are not aware of.

I've yet to see any scheme proposed that had anything like that capability. Your gossip scheme doesn't work -- you just create a new Byzantine agreement problem of how to know when you're done gossiping. Do you use gossip to solve that agreement problem?

No, we simply have the sender of the transaction make a final endorsement before it is posted to the ledger, but after it is signed by a supermajority of validators. If the supermajority is not reached before a timeout (e.g. because of a netsplit) the sender can just submit the transaction to a different group of validators (we implemented sharding by transaction) so maybe that group will come to a consensus first. The sender then simply endorses one approved transaction and ignores the other. This is only possible because the sender has ultimate say over if they want to send something.

I don't see how this helps you. The sender can sign two conflicting transactions if they want to. Say there's a split of honest validators, the dishonest validators sign both ides of the split, and the sender signs both transactions too. The sender already has to be dishonest for a double spend anyway.

If there is a split of honest validators in a consensus group, then at least one of the subgroups after the split won’t be able to achieve a supermajority, and the one that does sign a supermajority (assuming there is one) needs only ONE honest validator to detect that a dishonest validator has given (and signed) two different answers for the whole thing to be rejected by any self-interested recipient.

The key why any of this works is because in crypto-currency, the recipients are ultimately the final arbiters of what consensus result they consider untainted (valid and unforked history). Every time A pays B, B is ultimately either going to accept the payment, or not. They can take their sweet time looking for claims of violation and forks and investigate them all. The goal is to simply build  aledger that maximizes the probability of surfacing this information.

I don't think you can actually achieve the results you think you can achieve. If you wait X time to accept a payment, someone can release conflicting signatures also after X time. Now you might accept a payment others don't. It just isn't nearly as easy as it seems and you wind up just pushing the weakness to another corner.

It doesn’t matter if someone releases conflicting signatures. B waits for a supermajority of the validators for token T to SIGN a statement saying they didn’t see a double-spend, then A endorses the transfer. As long as the majority of the honest nodes have signed the statement, they won’t change it later, and even if they do, B can produce the statement they signed contradicting themselves. The whole point is that there can be more than 33% dishonest nodes and it will still work.

I don't see how. Your quorum can't be more than 66% because otherwise with 34% dishonest nodes you make no forward progress. So say you have 66% honest nodes and they're split 50/50. Each txn gets 33% from its half of the honest nodes and 33% from the dishonest nodes, so each side meets your quorum. The dishonest nodes talk only to the sender, the sender signs both (he's trying to double spend, so of course he does), and everything now goes to two receivers, each accepting the conflicting txn with 66% and a sender sign. No honest node (but recips) ever see the conflict.

Why can’t the quorum be more than 66%? That is the whole point. If the group makes no forward progress, the sender simply issues another transaction to another group, and endorses whichever group does reach a consensus first. If the other group ever does reach a consensus also, it is dropped by the sender. The 33% nodes may be simply netsplit and not malicious. Re-read what I originally wrote in my second comment on this thread.

If the quorum is more than 66%, then you can't make forward progress if 33% of the nodes are dishonest. They just refuse to reach a quorum and you're dead. Tolerating 33% or more dishonest nodes necessarily caps the quorum at 66%. (As my answer explains.)

I just addressed that above. Let them refuse to reach a quorum. The sender A simply issues another transaction to ANOTHER consensus group and endorses whichever group reaches a consensus first, ignoring the other. So yes one consensus group makes no forward progress... and so what?

Then what if the sender endorses both consensus groups? You keep pushing the problem someplace else. If we're talking about resisting a double spend, which we are, the sender is necessarily dishonest. I seems like you didn't read and understand my answer that shows that you have to pick a quorum that protects against both failure modes.

The honest participants don't know, for a given transaction, whether the sender is attempting a double spend or the dishonest nodes are attempting to fail to reach a quorum. You need to pick a quorum that protects against both threats. And the quorum must be large enough that the sender can't send two conflicting txns to two different groups and get them both approved.

It seems to me that you didn’t understand my answer which makes me suspect there is some misunderstanding. I believe it js that in your conception the consensus is always  global about all transactions in a block, and in mine it’s about each token. The sender may be dishonest but they’d only be hurting themselves by paying twice for the same goods. Let me make it simple: you pull out a credit card and the transaction stalls for an hour. So you pull out another credit card and it goes through. When the first credit card transaction completes successfully you don’t endorse it or dispute it.

What if the two transactions spend precisely the same asset? And if you're going to argue that you can't have two different consensus groups for the same asset, then you can't tolerate losing 1/3 or more of any one consensus group without at least one asset becoming unusable.

Maybe I'm misunderstanding you. If you want to sketch out your proposed protocol in more detail, I'd be happy to review it.

OK I will write it up on our forum and link you to it. Then you can comment there (easier and probably more appropriate than here).

Okay @DavidSchwartz I have updated our article on Consensus here, as promised: https://forum.intercoin.org/t/intercoin-technology-consensus/80 . I took the time to describe it in much more detail, and also compare it to other systems including XRP Consensus Process. Please take your time to understand the system it's describing, and I'd be happy to see what you have to say. You can make an account easily on that forum, and post your review as a comment there, because it probably doesn't belong on stackoverflow.

See my comments. That's a consensus design that could only used for incredibly simple applications. For example, you couldn't use it to support a decentralized exchange like the XRP Ledger has or smart contracts like Ethereum has.

Ideally, people should all learn about falsification of claims they care about, and make up their own minds who to believe. That’s how people reliably arrive at the truth. Having a Ministry of Truth — whether made up of PoW, PoS or representatives etc. — creates an attractive honeypot for hacking. It’s also much more centralized. But in this stackoverflow question my main point is just that there is a way to do BFT consensus in the face of MORE than 33% malicious nodes.

Except there isn't. It doesn't work with more than 33% malicious nodes. If the malicious nodes take both sides, you have two majorities. Nothing in your scheme stops malicious nodes from taking both sides.

Both sides of what? There is only disproof. There is no voting. If malicious nodes SAY two different things then the other nodes GOSSIP that and proceed accordingly! For example if a malicious or not malicious node actually showed a fork then it doesn’t matter that it also said there was no fork to someone else. EVEN ONE node can prove there was a fork!

If there is only disproof, there is no proof and nobody can ever accept a txn as valid because they have no idea what disproof other people might have. Without proof of the absence of disproof, you can never rely on a transaction at all. If I have no way to know that disproofs don't exist, I can't rely on a transaction because others might have disproofs. How can Alice rely on a txn from Bob if Charlie may have a disproof? Alice must somehow determine that Charlie has no disproof -- that's the other side.

By the same token you can ask, how do I know the nodes that arrived at a consensus are the whole network and not a small subnetwork of a much larger one which will eventually reach a conflicting consensus? This is more about the step prior to consensus - namely selection of the set of nodes that will matter in the first place, for token T or transaction X. For us we use Kademlia but a naive implementation would just be to list the IP addresses of the nodes directly in the token history itself. Either way you need to have this list. Ripple has the UNL.

But XRP doesn't rely on 100% agreement on the nodes that matter and it has ony a single network that's human managed. It's not clear how you can have sufficient agreement to allow a deterministic algorithm to winnow that set down to an agreed consensus set. XRP has a working, deployed system that's fully specified. We had to solve every problem to do that. You can't handwave solutions to the hard problems and compare that to actual implementations,

Are you imagining some global consensus on which nodes matter for some particular asset or transaction? If so, how is that global consensus achieved? XRP uses humans because it only has to do that once and has an algorithm that doesn't require perfect agreement to allow the system to evolve without a central authority. You can't begin by assuming the hard problem is solved, then compare your solution to the easy remaining problems to the solutions to the hard problem itself that you began by assuming was solved!

It is achieved using a technique called Kademlia which is used in DHTs. The SAFE Network uses it in much the same way as we do: each token has a group of the closest N computers in XOR space to watch it. But there are other ways to do it as well. That consensus is not global, not all nodes know every output.

Download the SAFE Network and run it yourself, it is a working implementation. They solve many related problems, including transferring ownership of files and proving that they are still being stored without revealing their contents.

You might want to add a link to Lamport's paper on Byzantine Fault Tolerance https://people.eecs.berkeley.edu/~luca/cs174/byzantine.pdf . The algorithm you're talking about is called SM in the paper.

This answer is incorrect. It is now well understood that Byzantine agreement requires f < n/3 under partial synchrony or asynchrony even with digital signatures, but can be solved with f < n/2 under synchrony with digital signatures. See e.g. https://eprint.iacr.org/2017/307.pdf

Maybe you are right, but please define "Byzantine agreement" rigorously so we can evaluate the claim. It seems that if n/3 < f < n/2 it can be solved at least with synchrony and digital signatures as you said. Beyond n/2 you can't know whether there was a netsplit and a larger consensus will override yours, so you can't make forward progress if malicious nodes fake a netsplit.

Also how do you explain this, then? https://www.trustnodes.com/2018/08/10/vitalik-buterin-proposes-consensus-algorithm-requires-1-honest ... Leslie Lamport proposed it actually.

Also @qbt937 here is what Lamport's paper that you linked says: Now that we have introduced signed messages, our previous argument that
four generals are required to cope with one traitor no longer holds. In fact, a
three-general solution does exist. We now give an algorithm that copes with m
traitors for any number of generals. (The problem is vacuous if there are fewer
than m + 2 generals.)

@GregoryMagarshak Yes, which agrees with your answer. Though I fail to see what point you are making in your comment.


text:
Fees too high best course of action
When I try to spend about 4.7 mbtc I get an error message  : "Balance not enough". I deduce that network fees should be around 4mbtc, which is kind of high. My balance formed from around 15 faucet inputs 0,5 mbtc each on single adress, so I think that is the source of my problem.
What  should I do now?
1. Does "economical" transfer of these inputs on new address gives me lower fees after that or not?
2. Should I move my balance to other app, or this is not BitcoinWallet problem and any other app give me same fees?

Some of the wallets have ridiculous fee calculations resulting in WAY too many fees. Especially when moving around trivial armounts these turn into real bummers.

So, In my case most easy way out was - make a payment from my adress on my adress of all balance with economical fee, which was small enough, and transaction took an hour and half. Then payment for external adress gone with reasonable enough fees.

source: Stack Exchange

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

sort: votes


text:
What's so special about six blocks for confirming transactions?
I read that when your transaction is part of a block that has five other blocks on top of it, you can feel safe that your transaction is not in danger of being orphaned because someone else would come along and confirm a series of blocks longer than the one of which your transaction belongs. My question is what's so special about six?  It seems like an arbitrary number. Why not five or seven?

Possible duplicate of Why is 6 the number of confirms that is considered secure?

There is nothing particularly special about six. Five blocks would take less time but provide a slightly lower level of assurance. Seven blocks would take longer but would provide a slightly higher level of assurance. Lots of services use fewer than six blocks.

in addition to @David answer read more about Irreversible Transactions

For example, if the attacker controls 10% of the network hashrate but
  the merchant waits for 6 confirmations, the success probability is on
  the order of 0.1%[3]. Because of the opportunity cost of this attack,
  it is only game-theory possible if the bitcoin amount traded is
  comparable to the block reward (but note that an attacking miner can
  attempt a brute force attack against several counterparties at once).

I'm not understnading how the irrevisibliyt of transactions in any way explains why "six" became some sort of unspoken standard.  @David's answer suggests that there is indeed nothing special about 6.

six became a good value, cause after one hour (each block 10min) you had to have so much hash power, that it seems impossible, that someone could re-create the blockchain and make your tx pa to someone else. So as David said, nothing really special, just good sanity and caution for higher values.

I've edited the answer!  @Dave

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


text:
Passphrase works in Bitcoin QT, but does not in Bitcoin Core
I found an usb stick with a wallet.dat.
There is also an old notebook with Bitcoin Wallet v.8.6-beta on it.
Unfortunately I can't sync it on my old notebook and therefore I am not able to send BTC to another wallet.
I then installed Bitcoin Core on my new PC and put the old wallet.dat in the directory.
The bitcoin showed up in the Bitcoin Core Wallet on my new PC; BUT when I tried to send them it says "passphrase is incorrect".
I then doublechecked my passphrase using "change passphrase"-feature on the Bitcoin Wallet on the old notebook and it worked, meaning the passphrase must be correct! I could even do a transaction and put the passphrase (BUT as you know, because it is not synced - the network will not accept the transaction...)
In other forums they recommended using Electrum instead to import wallet.dat.
This did not work for me.... I am not expirenced with bitcoin and IT in general....
So, do you guys have an idea what causes the incorrect passphrase in Bitcoin Core?
Or could you recommend a trustworthy company to solve the problem?

Why would the network not accept the transaction if the wallet is not synced? It should be able to send if you can see the coins in your wallet

The problem described seems quite strange. I don't know what's preventing you from unlocking the wallet.dat. I think this might be caused by InputMethod/halfwidth and fullwidth forms/CapsLock/NumLock... Double check these things before typing your passphrase.
At last, if you still cannot figure out what's preventing you from unlocking the wallet, you could try to export your private keys on your old PC, one by one.
On your new PC, if you have finished the initial syncing with latest version of Bitcoin Core, you may open the debug window, switch to the console tab, then try the rescanblockchain command. This should make your wallet balance up-to-date, which would take some time to complete.
Then, listunspent command would indicate which addresses your bitcoins are currently stored in. You may save the text, then copy it to the old PC.
On your old PC, launch bitcoin-qt. It doesn't matter whether the blockchain syncing is complete or not. Open the console, first use walletpassphrase 'YOUR_PASSPHRASE_HERE' 3600 to keep your wallet unlocked for one hour, then use dumpprivkey ONE_OF_YOUR_BITCOIN_ADDRESSES_HERE for each of your Bitcoin addresses.
Once you get all the private keys, you will be able to import them to almost any Bitcoin wallet.

When you are entering your passphrase in a command line you are writing your password between double quotes like this : "P@ssw0rd". You should enter your password between single quotes like this : 'P@ssw0rd'. If not, it will execute code between those double quotes which alters the password you entered.

Thank you fo helping me. I enter the passphrase in a pop-up window of the application (popup window which opens after I clicked send the BTC) and therefore not i a command line. Do you think this could still be related to somehow?

It could be how different Wallet clients allows text-formatting in the Passphrase text pop-up window.
Earlier I copied the passphrase from a spreadsheet I had made. Just because the cells in the spreadsheet had properties like text-color, background color, etc. the only way my passphrase worked was by typing it in the wallet-client manually.
This isn't a full answer to your problem, but I hope this helps in some way.

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


text:
Bitcoin Transaction Fees - Want to increase fees!
I have my bitcoins on bittrex and I want to pay with increased fee to make sure its confirmation in the least possible time. I don't know how to do that.
In plain words, I want to deposit Bitcoin to my local exchange but bittrex is allowing only 0.001 BTC transaction fees. I want to increase it.
I thought that I'd purchase other altcoins like NEO or LTC and transfer it to other exchange first but so far, I am unable to find any exchange that allows "increasing transaction fees".

Bittrex charges a fixed withdrawal fee of 0.001BTC no matter the amount of BTC you send or the size of the transaction. If you want the confirmation process to go quicker when the network is congested, you have two options:

Ask miners for help.
Tips: Some members on Bitcointalk.org offer free tx accelerator services., if  urgent go for the paid services(beware of the scammy ones though).
Attempt a Child-Pays-For-Parent on the receiver end.

Blockchain.info allows you to set the transaction fee manually, but they are more of a wallet provider than an exchange. Although they have exchange services.

I am using BitGo service. They give a completely fresh deposit address which is valid only for your transaction. I don't know much about bytes and output. I have traded other altcoins on Bittrex exchange and converted it into BTC to take profit. I am not sure about input vs output here. Can you please explain something about Input and Output (remember, BitGo gives fresh address which is valid only for one transaction).
I did the transactions 3 months ago BTC to BitGo address. I didn't check bytes at that time but when I checked it today, it's 1400+ bytes,there were a lot of outputs.plz help

I assume you meant a lot of inputs when you attempt to send from BitGo wallet?
Like this one .
1400+ bytes thats about 10+ inputs, could it be that you deposited to BitGo wallet 10+ times? If you try to consolidate all the BitGo deposits, you will be charged for each one. A transaction with 1 input and 1 output is approximately 192 Bytes. Each additional inputs will add approximately 148 Bytes, and each additional output will add approximately 34 Bytes to the transaction.

I just transferred 0.004 BTC with 0.001 fees but it is showing 201 inputs and  66 outputs. I am worried now, not because of the amount, just because I want to transfer big amount asap. Can you please explain what could be the reason?
https://tradeblock.com/bitcoin/tx/b0f54d5936344e5372f993e3cbdf19ed8931a2cb44cd0d083c50edf79920ee8e
It says 11.xx BTC received. I only sent 0.004 to that address. I am not sure.

Nothing to worry about here, is just Bittrex's way of handling withdrawals. They probably consolidate several withdrawals from different customers in the same transaction. Your withdrawal will not be affected by how they handling withdrawals. Your fee is 0.001BTC no matter if you withdraw 0.01BTC or 100BTC.

There's no way to increase it unless the exchange themselves set the fee. However, as you can see here : https://jochen-hoenicke.de/queue/#24h
The Mempool is getting freed so the fees are getting lower. From my experience bittrex satoshi/byte for that 0.001 is around 400-500. Right now you can get away with 200 satoshi/byte so as long Bittrex actually send the coin immediately, it will confirm in 1-2 blocks.

The problem is, the address where I want to send is up-to 1200+ bytes. The exchange where I want to deposit uses BitGo "pay as you go" service and it always worked fine for us. But the problem is, 1200+ bytes require large transaction fee. Am I missing something.

The info they have is either outdated or still using the amount some people still commit from the congestion for the past days. 1200+ satoshi/byte is too much now and currently 200+ is sufficient to be confirmed within 1-2 blocks. However, bittrex commit 400+ so it will be more than sufficient. Perhaps this graph is clearer : https://btc.com/stats/unconfirmed-tx
Currently, there's only a few unconfirmed transaction that uses 400+ and absolutely none down to 180 satoshi/byte.

Hi there, I think you misunderstood me. It's not 1200+ satoshis per byte. It is like 1200+ bytes because of the output burden of BitGo deposit address. For some reasons there is a big difference between your given link and this one: https://bitcoinfees.earn.com/

I see that it's quite large but you should still be fine, even for 1200+ bytes transaction, the fee per byte should come to around to 700+ satoshi/byte if bittrex actually commit your 0.001 fee entirely. But they probably commit half of that which is still fine currently because 140 satoshi/byte is sufficient. The link you provide does not show how long the transaction have been unconfirmed meaning everything above 140+ are just new transactions, that's why they're very few. All of them should confirm within 1-2 blocks, the fee recommendation shown in that page is inaccurate.

Allow me to further ease your mind : https://blockchain.info/tx/b29319dac4f36739a7794791f3bd5700807d2ce5cb5fe2e31eb5bec7e6d097ec
This is a new 1100 bytes transaction that has only 146sat/byte fee attached to it. It got confirmed within 7 minutes or simply 1 block because right now the bitcoin network is no longer congested and fees are relatively cheap once more.

I just transferred 0.004 BTC with 0.001 fees but it is showing 201 inputs and  66 outputs. I am worried now, not because of the amount, just because I want to transfer big amount asap. Can you please explain what could be the reason?
https://tradeblock.com/bitcoin/tx/b0f54d5936344e5372f993e3cbdf19ed8931a2cb44cd0d083c50edf79920ee8e
It says 11.xx BTC received. I only sent 0.004 to that address. I am not sure.


text:
How can GDAX pay no fees while transfering Bitcoin between wallets?
How is that possible that using GDAX you don't pay network fees (than can go up to 30 USD) to move bitcoins between wallets?
How can GDAX pay all these transactions fee for you?

GDAX is a centralized exchange, they don't actually transfer the Bitcoins between wallets. They have a database that associates every account with how much Bitcoin they are worth.This is why transferring from Coinbase to GDAX is free, because it is the same company running both platforms.

GDAX also covers the transaction fee for withdraws to arbitrary wallets which are not sitting on the GDAX backend. It seems that this fee was the one the OP was asking about which would mean the question hasn't been answered.

I was not asking between gdax and coinbase, but between gdax and other wallets

But the answer stays the same, GDAX to Coinbase or GDAX to any other GDAX owned wallet.

binance wallet are not owned by gdax


text:
bitcoin volatility and transaction fees
We know that the Bitcoin currency is volatile, but does the transaction fees correlate with it's volatility? Is it right to assert that if there is high level of Bitcoin demand, then the currency goes up, and then if the demand comes from a great amount of person, then the network size increases and so the transaction fees could be balanced by a greater availability of blockchain space, or am I going wrong ?

The logic behind the transaction fee in the bitcoin network is that the miners take  in consideration first the txs that have higher fees to be added to the blocks, those txs are taken from the mempool, the place where they should wait until miners decide to add them to a block to be validated.
For example:
If I perform a transaction that has a fee of 300 satoshis it will be first added in the mempool before it goes to a block; and let say, that some minutes later you perform a txs that has a fee of 30000 satoshis it will added  to mempool too, but the miners will consider first your tx because of its higher fee.
Taking that in consideration, when the bitcoin price get up, usually there are a lot of people performing txs and since the size of the blocks is only 1MB, where only can be attached about 2500 txs, much of those people prefer to pay higher fees so their txs could be added to the next block. That cause the mempool get full of transactions waiting to be added to a block.
According that explanation we can say the transaction fees is not directly correlated with the  volatility of bitcoin, it is more correlated with increase or decrease of quantity of transactions waiting in the mempool and the wish of people to get txs done asap. If there are many txs in the mempool people will be more tempted to pay more to get them done.

No, the more people use Bitcoin, the more the transaction fees will go up. This is caused by the fact that the blocks are generated with a 10 minutes average and they can only hold up to 1mb of data. The more people use Bitcoin, the more there's a demand to have their transaction in that small 1mb block. This is why there was a fork for Bitcoin Cash which advocates bigger blocks (Currently 8mb, but they will scale with the demand to keep fees low).


text:
Can I increase or decrease the block reward an year after launching my altcoin?
Can I increase or decrease the block rewards or coin per block once I make my coin public and people start mining it.

Short version: Everyone can follow whatever rules they want. Those who agree on the rules will be able to interact with each other. Those who don't, won't. So, sure, you can change the block reward to be whatever you want but you will then only interoperate with those who agree with your changes.

You can do whatever you want, so long as the people who mine it agree to mine on top of your change.
In Bitcoin, the block reward goes down on a set schedule.  Everyone knows this, and it's baked into the protocol.  Any mining nodes producing blocks that don't conform to this (or any other part of the protocol) are wasting their effort since nobody will accept their blocks.  The rest of the network will continue as if nothing happened.
You can create a coin that says "on Sep 18 2018, the block reward will half", and have that rule baked into the protocol.  Maybe people will mine it...maybe they won't.  If they do, they do so knowing that the block reward will change on that day, and will reject blocks from nodes that don't follow that rule.
You could also create a coin that says "the block reward will never change", and then have some mining nodes change it anyways a year from now.  This would create a hard fork, and again, maybe people will mine on top of the fork...maybe they won't.

If you know in advance how you want it to change, then you can include this as part of the rules for calculating the correct block reward.  The most common way is to base it on block height rather than date, and estimate (based on your target block time) how many blocks will be mined in a year.  For instance, "if block height < 10000 then reward = 10 else reward = 5".  This is how Bitcoin implements its decreasing block reward schedule.
If you change your mind later, you could release a patch which changes the reward.  This will result in a hard fork of your coin between those who adopt the patch and those who do not.  You will have to hope that your argument for a changed reward is sufficiently convincing to your community that the vast majority of users choose to adopt your patch.


text:
Problem with my bitcoin wallet
In the distant 2013 I tried to deal with mining. At that time it was much easier than it is now.
I downloaded the official program (the version I did not remember), installed it on my computer with a powerful, at that time, videocard and mined.
When I decided to stop I had a bit less than 1 btc. Without having any possibility to cash it out I just saved it to my wallet.dat. I did it with the thought in mind that in some time I would restore mining on its base.
Currently, it is already 2 months that I can not restore my wallet. I installed different versions of the software from bitcoin.org, synchronized them, but the balance writes 0.
Can you help me find out the reason of the fact that in 2013 I had some money there (the rate was $ 130) but 0 at the moment?
P.S. The only person who had access to the wallet was me. I even have the exact date I used it for the last time.

First be very careful seeking help online, don't give the wallet.dat file or its contents to anyone, and don't screen share to get help.
Also, backup the wallet.dat file securely to make sure if you accidentally change the contents, you don't lose the money.
I don't use bitcoin core myself, so the following is just what I have been able to find out quickly.
So from here I can see some information about the wallet.dat file format. I believe it to be plain text, so you can just open in a text editor.
It contains - keypairs for each of your addresses that's what you want.
First, step enter each of the public addresses e.g. 1GwV7fPX97hmavc6iNrUZUogmjpLPrPFoE into a site like https://bitref.com/ to see if they have unspent outputs sent to them, i.e. a positive "balance". Only post the public addresses into a browser, they are the shorter strings, like the example I gave.
Now you know which addresses your money was sent to and that your wallet does indeed contain bitcoins and you can relax a little knowing you have all the private keys required to spend those coins.
There are several options going forward past this point, so I think you should check this first. It's safe if you don't modify the file and, again, only post the public addresses into a browser.


text:
Bitcoin General API
I want to create an API that works for all brands of bitcoin.  Is there a way to use one general API used for all brands of bitcoins, or I must create every API for each brand?

What is a Bitcoin brand?

By brand I mean several bitcoin websites

But your API will by definition be provided by some site, so it will be a "brand" on its own?

I mean that there are lots of sites for bitcoin, so for example I want to create an application with a bitcoin API.  Should I create for every website its own API or is there a general and collective way for all bitcoin websites. Thank you

To accomplish what? What kind of API? Exchanging? Transacting? Exchange rate? Transacting? Webwallets? Analysis?

Authentication and exchanging or transacting... but there are several websites such as blockchain, freebitco, bitcointalk, coinbase etc... so when I create an API for example for transacting, is there a third party involved which might be a general API that all bitcoin websites use? I'm sorry if I am confusing you but it's the best way I can explain it.  Thank you

blockchain.info is a webwallet. bitcointalk is a forum. coinbase is an exchange. I don't understand how you can combine them. I'm voting to close this as too broad, but feel free to ask another more focussed question.

Each exchange ("brand" as you named it) provides its own API. Those are mostly similar, allowing access to wallet, history, transaction, ... but there are often small differences (like the return value, the params to provide) wich imply to write one API wrapper per exchange.
HTH


text:
How can I generate addresses for all altcoins?
I want to develop my own exchange website having all the altcoins addresses. I am doing research from past few days and I came to know that I need a copy software client of all the altcoins, and then address can be generated by making rpc calls to these clients.
Do i need to setup these clients on my server (i.e VPS, AWS etc)?
If yes ? then what would be the best server configuration to handle the exchange and do I have to download these client one by one and then implement each ?
If no then how can I implement this ?
Currently I am running a bitcoin client on vps.

You don't have to just create addresses. You have to track what's happening on each network and make sure that you actually have received funds before you can credit deposits to your customers' accounts. There are easier ways to just create addresses, but you would very much want to run at least one full node of each network under your own supervision to track the networks.


text:
Two weeks have past, still nothing on my transactions
Two weeks have past, still nothing, can anybody advise? tried the zap wallet thing, and its just removed the transactions, so theres nothing in my wallet on my mac. the only thing i have to go on is the bitcoin link:
https://blockchain.info/tx/44c784d8f82d962103ffdf5d463a1460150a21cc67a0750d4a3f6a35a0d18d9a?show_adv=true

The fee on that transaction is absurdly low for current network conditions. It would need to be about ten times higher.

Are you sender or recipient of that transaction?

im the sender to https://www.bitstamp.net/ where i want to withdraw

i realise the fee is too low, i didnt understand the whole fee thing until after - willing to pay to get this through

hi David, what are my options, how can i get this through? i will pay to get this push through

Since you already tried "-zapwallettxes", your client is now no longer broadcasting this transaction.
You have four choices(I listed them after difficulty):
1. Wait until it gets dropped from mempool or picked up by a miner.
2. Ask miners for help.
Since you are in urgent need: bitcointalk.org have plenty of members providing free transaction accelerator services. You can also go for the paid services, but be aware don't fall for the scammy ones.
3. Attempting a Replace-By-Fee (RBF) double spend transaction.
4. Attempt a Child-Pays-For-Parent transaction if you are also the recipient of this transaction.

thank you - i will try and pay someone to help - if you know of a genuine service, any help or suggestions would be very much welcomed - thanks :)

I’ve done three transction of btc to my exchange wallet and it been 12 days and still no confirmation
My address are https://blockchain.info/address/3C6FMy8BFeCbVRd7457eBTFoYGQirna1Y3
https://blockchain.info/address/3FYUHdqEQ5Sg7mkMBtyQbUSfJgDbhTejUt
https://blockchain.info/address/3368APnw4u3b18ediJYerdyAA4fcfh5ztE
Please help me im really desperate. I cant afford to loose that much amount

this is not an answer on the questions.


text:
Too late to claim BCH and BTG
I recently came back in from the crypto wilderness and heard about the BCH (Bitcoin Cash)and BTG (Bitcoin Gold), which were given out when the currency forked. I have 2 BTC's which I have started to update.
I was wondering if it's too late to claim the BTG and BCH?

Do you own the private key(s) of the address (es) you have the 2 btc on? And where these coins (or some other amount) located on those addresses the minute before the forks happened?

Hi, thanks for getting back to me. So I have the backup of the wallet from  22nd dec 2017 and 27th march 2014. What I've done is using the current wallet (which is the same as the backup wallets, just more recent) exported private key from the desktop client and then imported the private key into a BCH wallet, but nothing is showing up. Am i missing something

I cannot tell without knowing your btc address. Btw, I suspect the key part that you may be missing is a correct assumption about wether these wallet and backups are really the same. And the balance of those addresses on the minute before the fork. These are things you can easily check on a blockexplorer

@ChristiaanWesterbeek Hi Christian, I'll google how to use block explorer, unless you have time to guide me through it or know of a good tutorial, in the meantime I can provide you my btc addresss if that helps? 16BawiLNCZ8BUsF4kuvte27Tv7Zgjt8Yia

Just checked block explorer, not a complicated as I had feared :)  No transactions have been made on that address, so would my address have changed? If I restore an old wallet will that have retained the original address?

Yes it will. An address does not change. You just had different addresses in the wallets you had and have.

@ChristiaanWesterbeek Thanks Christian, I'll restore an older wallet and see what happens. Thanks for your help :)

There is no deadline to claim these forks. If you have access to the private keys of the addresses that owned Bitcoin during these forks, you own those coins too.

No, its not too late. if both coins were held before the fork, then you can claim them.


text:
One pub address to many cryptocurrency
I've found this in the code on Github:

This pubkey can accept any type of coin, please leave this in
             your config to help support development.
22851477d63a085dbc2398c8430af1c09e7343f6

How do I create a similar address?

It appears to be a hash160 of a public key. Generate an address, then either take the RIPEMD-160(SHA256(key)), or paste the address into this calculator: http://bitcoinvalued.com/tools.php


text:
Cryptocurrency from Scratch?
I remember seeing a question a while back about how to code your own cryptocurrency here:
How to fork Bitcoin and build own cryptocurrency
Unfortunately, it seems to suffer from a lack of in-depth information of how
to "start" the currency in the network. I was wondering what it would take to
implement a new Proof-of-Work/Proof-of-Stake and how to actually get the entire
currency "started".

You don't "start in" a network -- you're building one of those, too. So realistically, the answer here is "social networking."

I was looking for something more on the lines of code ;-) but thanks for the answer.

To create a new Proof-of-Work/Proof-of-Stake system you are going to need to be really creative and possibly know mathematics in depth. May I suggest you read up on how Bitcoin does certain things on the bitcoin wiki.

primordial, I have experience with creating Proof of work / Proof of stake Crypto Systems, if you have any questions feel free to drop me an email.


text:
Deposit Litecoin into bitstamp from coinbase
I have been having an issue trying to transfer my Litecoin from Coinbase to Bitstamp Litecoin deposit. I think I am correctly following all the steps. When I am in the Bitstamp Litecoin deposit page I copy the address, paste it into the Coinbase transfer recipient address, fill in the amounts and hit send.  I then get an error message to use a valid litecoin address. I then try using the old non M* LTC Multisig address, fill in all details and the error message this time is that I do not have enough funds. But I do have these funds.

Make sure you taken off enough for the transfer fee when sending the coins. That's a common reason for a 'not enough funds' warning.


text:
Tried to do a BCC transaction ended in a BTC transaction
I have a local BTC wallet. Which holds coins from pre-fork times.
So I tried to get my BCC amount sent to a wallet on bitfinex. So I used my local wallet with the BitcoinABC client to access the BCCs.
But that ended up in sending my BTCs to this address. The address indeed exists as BTC as well, so the transaction was successful. But i don't even have access to this BTC wallet (only the BCC wallet).
Why did the BitcoinABC client sent my BTCs (which are much higher in value...)? It says BCC everywhere. I was not even aware, that Bitcoin ABC is capable of performing BTC transactions. What did I do wrong?

What version of Bitcoin ABC are you using?  I am not sure, but this might happen if you used an old version from before replay protection was implemented.  Otherwise, this isn't supposed to be possible.  Would you be willing to share the transaction ID?

Version is v0.14.6.0-a46e63c.
Transaction is this: https://blockchair.com/search?q=f343a0cb812fb05839d8e1f044d04db0b4210b7931e3a19628c369a2f4430479


text:
Short-term capital gains taxes for crypto to crypto trades?
If I were to profit off cryptocurrency to cryptocurrency trades throughout the year without ever cashing out my crypto position for USD, would I avoid paying any short-term capital gains taxes on all of my crypto to crypto trades? Would I ultimately only pay long-term capital gains tax once I convert my crypto to USD after the one year mark?

I'm voting to close this question as off-topic because this is a tax question which requires legal expertise.

Ask https://law.stackexchange.com

This is a sensible interesting question actually

It will depend on the tax laws in your country.
Where I live the tax law treats crypto currencies as an asset and requires that my position be reconciled at the end of each financial year for capital gains calculations.
That's not to say I have to do any buy or sells of each year I just have to determine my paper capital gain or loss for the year in order to include it on my tax return.

Asking about the US. So crypto to crypto trades are indeed on the hook for short term capital gains? Not just crypto for fiat trades?


text:
(SOLVED) Transaction not showing after resend (Bitcoin Core/Exodus)
UPDATE: After several hours, the second transaction is now showing up on BlockCypher.
I sent some bitcoin from my Bitcoin Core wallet to my Exodus wallet. The first time, I tried lowballing the fees and the transaction was eventually dropped (not showing up in blockcypher or other sites).
Using -zapwallettxes I was able to successfully recover the bitcoin.
After sending the bitcoin a second time (using the recommended fee), the second transaction is not showing up in blockcypher at all. The status shown in Bitcoin Core is "0/unconfirmed, in memory pool". Any help would be greatly appreciated, thank you.
EDIT: My transaction ID is 115c77086608cab30b92bab4316920787be8a886a5018f5d2eb5512a49a7b6f6; again, it doesn't work on the several blockchain explorer sites I've used.
EDIT 2: After running -zapwallettxes again, the transaction disappears and the bitcoin shows up in my wallet. However, after I remove the command, the transaction re-appears.

It sounds like your second tx is simply unconfirmed. Have you checked any other block explorer websites? If you can post a tx ID or receiving address here someone may be able to help further.

My transaction id is 115c77086608cab30b92bab4316920787be8a886a5018f5d2eb5512a49a7b6f6 as shown in BTC. I've used several other blockchain explorers (blockchain.info, blockexplorer, btc.com) and none of them show my transaction.

It sounds like your wallet is not fully synced to the network, since multiple block explorers do not have a record of it. Ensure your wallet is synced, and then try rebroadcasting the tx

Bitcoin Core is fully up to date. I have re-synced the Exodus wallet; the first transaction (the one that was dropped) disappeared but the second one hasn't showed up. It seems like the Bitcoin Core wallet never sent the bitcoin in the first place. After running -zapwallettxes again the second transaction disappeared and the Bitcoin is back in my wallet. However, after removing -zapwallettxes the transaction reappears.

If the transaction isn't showing up in other block explorers, then I'm guessing your bitcoin core wallet isn't synced and communicating with the network. To be clear, this is different than just 'being up to date' (in terms of software version).


text:
What is the smallest fee you can pay for an on chain transaction?
From what I understand, the smallest fee you can pay to miners per transaction is 1 Sat/byte.
With a basic Bitcoin transaction being roughly 250 bytes that would obviously mean the fee is 250 sats. Would there be a way to pay 1 sat for the entire transaction? Or anything less than 1 sat/byte?
Here is a list of what it would cost for a 1 sat/byte transaction at different bitcoin prices:

Price: $7,500 --- Trans Fee: $0.0187 ≈ $0.02
Price: $100,000 --- Trans Fee: $0.25
Price: $1,000,000 --- Trans Fee: $2.50
Price: $10,000,000 --- Trans Fee: $25.00

If you cannot pay less than 1 sat/byte then, it would effectively make on chain scaling uneconomical (Bitcoin Cash). Let alone the technical implications.

From what I understand, the smallest fee you can pay to miners per transaction is 1 Sat/byte.

It's not true.  A transaction can contain a fee of any amount.  There is nothing to stop you from creating a 250-byte transaction with a fee of 1 satoshi, or 17 satoshis, or even 0 satoshis (no fee at all).  Of course, it will depend on market forces as to whether miners would actually decide to include such transactions in a block.
Many wallets ask you to choose a transaction fee in satoshis per byte, but that's just a convenience for the user (since most miners look at the ratio of fee to transaction size in deciding what to confirm).  It's not an inherent feature of the blockchain.  Under the hood the wallet just multiplies this number by the transaction size to determine the absolute transaction fee.  You could patch the software to set an absolute transaction fee directly, or perhaps even just enter a fractional number of satoshis per byte.
(There are currently rules preventing low- or no-fee transactions from being relayed over the peer-to-peer network, but that's not the only way to get your transaction to a miner; also, those rules are not part of the blockchain consensus rules, so they can be changed without a fork.)
It's true that if we ever get to a point where 1 satoshi is worth a lot of money, then a transaction would have to have either a large fee (>= 1 satoshi) or no fee (0 satoshi).  The former would be expensive, and miners have no incentive to confirm the latter (though they can if they feel like it).
There's been lots of discussion about what will happen if 1 satoshi ceases to be small enough.   One possibility is a lot more use of off-chain transactions.  Another is a hard fork to add more decimal places, which would presumably be uncontroversial.  See Will we ever need smaller amounts of Bitcoin than a Satoshi?

If Bitcoin reaches prices of one million or more per coin, and even Satoshi's aren't a small enough unit, we simply add more granularity. I think it requires a hard fork to do cleanly, but I suppose you could also just hack the transaction formats and introduce it as a soft fork.
We can go to 0.1 or 0.01 Satoshis, or any other denomination, if we want.
Another answer is: If we scale on a second layer, the base-layer arithmetic doesn't matter. Sidechains can use any kind of coin or units. Lightning can use as many decimals as it wants.

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


text:
Bitcoin wallet address format representation
I want to send coins from my ether wallet to another bitcoin wallet that I have got.
I entered my bitcoin wallet receiving address, but MyEtherWallet transaction convert it to another address format that starts with '0x' and I think it's hexadcimal.
How can I know for sure that this address is actually related to the address that I typed??
I am looking for external generator to verify myself that the receiving address that my boitcoin wallet displayed turned into the hexadecimal code they show

MyEtherWallet is a wallet for ETH/ETC and ERC20 tokens. You can't send   coins from MEW to a Bitcoin wallet. Or are you asking for something else?

Yes I can. It's called 'Swap'. Anyone else want to try to answer me?

You should rephrase your question then, there is a big difference between send and exchange.

You are trying to transact with two different types of cryptocurrency.
You cannot send/receive Bitcoin from an Ethereum wallet and vice versa.

I am trying to convert and transfer coins from my ether wallet to my bitcoin wallet. This is functionality that MyEtherWallet provides. But that's not my question. I am asking about bitcoin address different format representation and how to convert from one format to another REGARDLESS my ether wallet.


text:
Bitcoin sent from one wallet to another didn't reach
looking for some help and advice here.
I sent 2.27 BTC from one exchange (Coinsecure) to another (Koinex). However, the receiving exchange (Koinex) only credited 0.327 to my wallet. I have been trying to figure out what happened to the remaining ~1.94, and it appears from blockchain, that these were sent out from my wallet to another address. However, in my Koinex account, I see neither a deposit nor a withdrawal.
All the transactions are in this link:
https://blockchain.info/address/15Rvzpv3L4FTMxoVfxqWHrqu9UKzFEo3gy
What do you think might be going on here? How can Koinex not recognise the receipt and allow the withdrawal without my knowledge or authorisation?
Looking for help from the wonderful experts here, along with suggestions on what I could do. Have tried all the channels to reach out to Koinex (tweets, emails, support requests, Facebook messages), but in vain.

It might be helpful if you include some screenshots from both Coinsecure and Koinex to let us know what they are showing you about these transfers.

Hi Eric, thanks for your comment. After persistent follow-up with Koinex they final responded, investigated and credited me the missing BTCs.


text:
Do BIP199's HTLCs suffer from script malleability?
Do BIP199 HTLCs suffer from sigscript malleability like multisigs do due to OP_CHECKMULTISIG?

The Script define in bip-0199 may suffer from OP_IF malleability if not used in a witness Script (which enforces that the argument to OP_IF is minimal, that is either the empty vector or 0x01).
There may be other malleability sources in this Script that i didn't spot, and more generally malleability being very difficult to reason about it's worth using tools such as Miniscript to prevent your Script's satisfaction(s) to be (too much) malleable.


text:
Can a BIP152 compact block be sent before validation by a node that doesn't know all transactions?
A new block is being relayed from node A to B to C using BIP152 compact block's high-bandwidth mode, which allows relaying a block after only validating its header proof-of-work.  When node B receives the compact block, it's missing some transactions, so node B can't reconstruct the block immediately.  It has to request the missing transactions from node A.
Before B has received the missing transactions, is it possible for it to announce the block to node C?
My understanding is that this is impossible.  The compact block that node B receives only references the missing transactions by their BIP152 shortid, which is generated from each transaction's txid in a way that is specific to each connection (preventing third parties from increasing collision risk).  Since node B is missing the transactions, it also doesn't know their txids, so it is unable to create shortids for them for sending a compact block to node C.
That means, even if node C has the transactions that node B is missing, it will not receive a compact block announcement until node B's transaction request has completed its round trip.  (Of course, this assumes that node C only receives new blocks from node B.)  That seems to imply that the propagation latency reduction of high-bandwidth mode skipping full validation before relay is largely lost when a block includes transactions that are not widely available.

I'll let someone more familiar with the topic formulate a proper answer but i think doing so would open a DoS vector since you wouldn't be able to verify the proof of work at all (and BIP152 explicitly proscribes it). It is also my understanding latency gains are largely lost when most nodes don't already have most transactions.

@AntoinePoinsot That sounds exactly right. Want to turn it into an answer?

Sure, will do! [space for minimum characters count]

B forwarding to C before having received all transactions means forwarding before validating the proof of work, which would open a DoS vector. BIP152 explicitly proscribes doing so:

A node MUST NOT send a cmpctblock message without having validated that the header properly commits to each transaction in the block, and properly builds on top of the existing, fully-validated chain with a valid proof-of-work either as a part of the current most-work valid chain, or building directly on top of it.

With regard to the impossibility for B to construct a compact block announcement to C due to the shortIDs calculation, my understanding is that it is not correct. B can just reuse the same nonce A used in the original announcement. Technically, I think B can just forward the very same cmpctblock message it received from A.
It is also my understanding that the latency reduction, along with the bandwidth savings, are largely lost when most nodes don't have most transactions.

Is this the DoS vector: A receives a valid block; A uses that valid block's header PoW to send B an invalid block (e.g. by swapping a valid shortid for a made-up shortid) with missing transactions; B forwards that invalid block to its peers, wasting bandwidth, memory, and CPU.  The invalid block will potentially propagate across BIP152 high-bandwidth connections faster than the actual valid block for that header propagates. With the requirement to verify the merkle tree means the only way an invalid block can propagate is if that's what the miner produced, meaning they'll lose the block reward

Yes, as nodes are eager to process and share blocks if they didn't validate the PoW you could make the network aggressively broadcast tons of invalid data at no cost.


text:
What is the network mempools unconfirmed transaction expiration time?
I sent a bare $1000 multisig transaction using sendrawtransaction with a too low fee.
When I create a new transaction with a higher fee, I m getting txn-mempool-conflict error, and when I use the bumpfee command, I m getting Transaction is not BIP 125 replaceable.
So given I sent it yesterday, in how much time I would be to access the money again?

Assuming most of the nodes on the network run with the default configuration of maxmempoolexpiry, most of the network mempools will drop your transaction after 336 hours (2 weeks).
You should have crafted your transaction such that it signals BIP125 replaceability (by having at least one of the input nSequence <= 0xfffffffd).
At this point, you could use CPFP (spend the output you just created with a high fee-paying transaction paying for the whole package) or use a pool "transaction accelerator" to send a new version of your transaction paying higher fees.
See also Why is my transaction not getting confirmed and what can I do about it? .

Really annoying. For cpfp,  I m getting input does not exists, it seems transactions accelerators don t accept bare multisig. Is there a way to get my money without facing such huge price volatility risk?

I personally think we should always signal for RBF: "you can't predict the block space market ":) For your CPFP issue it means your node isn't aware of your transaction yet (maybe there is hope here?), or you miscrafted your child transaction.

It appears in the transaction list, so I d rather say it considers the input as already spent because being in the mempool.

No, the error is not the same on conflicting transactions.


text:
Prevented from running Bitcoin Core on macOS
When I install and attempt to use Bitcoin Core I receive the following error:
“Bitcoin Core” can’t be opened because Apple cannot check it for malicious software.
This software needs to be updated. Contact the developer for more information.
Currently, my OS are up to date and Bitcoin Core version I'm using is 23.0.0

Doesn't that prompt allow you to edit your security settings?
You can go into security settings-> general and enable software from "App store and identified developers".
If I'm not correct a simple search on google will find the answer.

Solved! Thanks for the helps. It was a matter of opening the app through the applications folder within finder. That would allow an option to open anyway.


text:
Change output matches payment output type, not previous output type
Using the Bitcoin Core wallet making a transaction which spends a native segwit output and pays to a p2sh-wrapped segwit output will create a p2sh-wrapped change output.
It is different from my expectation that the change output type would match the spent output's type. I'm using version 25.0. I believe this different was different in previous versions (such as 22.0).
Did the behaviour of the Bitcoin Core wallet change? And what is the purpose of matching the payment output type instead of the spent output type?

I assume the difference you make between "native segwit" and "segwit" is the latter (confusingly) actually is p2sh-wrapped segwit? Let me know if my edit doesn't reflect your original question.

This is indeed a behaviour change starting with version 23.0, released in April 2022.
This change was implemented in Bitcoin Core PR #23789 over a concern that users of a less-common address type would immediately expose their change output. This was especially a concern for early adopters of newly introduced Taproot addresses.
This behaviour can be overridden through the changetype option in case a user wants to always receive a specific output type (h/t @Murch).


text:
Is there a difference between OP_PUSHBYTES and OP_PUSHDATA
In some documentation about Script we sometimes have to use OP_PUSHBYTESx or OP_PUSHDATAx to indicate that some number of bytes will be an element to read.
They seem to do the same thing so is there a reason they have different names ?

In what documentation ? I believe you are talking about how rust-bitcoin refers to the OPs > OP_FALSE and < OP_PUSHDATA1

When you click on "Display Script" on this page https://tbtc.bitaps.com/3dd3d1ec850769aac2359efd642ebe292e60502fc17dc33d7be1bc3cc6678621/mvEg6eZ3sUApodedYQrkpEPMMALsr1K1k1 and https://en.bitcoin.it/wiki/Script

Ok; it's what rust-bitcoin does too. Writing an answer.

In what documentation? I believe you are talking about how rust-bitcoin refers to the OPs > OP_FALSE and < OP_PUSHDATA1 and will answer as such.
There are multiple OP codes pushing bytes to the stack, defined as integers.
Special case: pushing small integers
There are dedicating OP codes for pushing integers from -1 to 16 (named OP_1NEGATE, OP_0 and OP_1 to OP_16 and valued 0x4f, Ox00 and 0x51 to 0x60).
They are used for instance for (smallish) multisigs as it saves you 1 byte per number pushed compared to using a "real" push opcode.
"PUSHBYTES": pushing small byte arrays
The (not named in the reference implementation) OP codes valued from 0x01 to 0x4b allow to push from 1 (0x01) to 75 (0x4b) bytes to the stack.
They are commonly used to push pubkeys and signatures.
PUSHDATA: pushing byte arrays
The PUSHDATA1, PUSHDATA2 and PUSHDATA4 (0x4c, 0x4d and 0x4e) operands are used to push a byte array to the stack which size is defined as a variable-length integer .
Further: too many encodings!
This flexibility of encoding introduced malleability in the scriptSig, which was not protected by the signature (which it carries).
BIP62 proposed to restrict this encoding to avoid possible malleation.


text:
Sending lightning payment between TOR lighning nodes, any specific setup required?
I have two c-lightning nodes in different VMs in Qubes OS, both routed through TOR VM.
They both can connect to other public nodes and establish channels with them but when I try sending satoshis between them the sending node gives "Could not find a route" code 205 right away, like it's not even trying.
At the same time in the terminal where lightningd is running I get:
20-07-01T12:46:17.482Z DEBUG gossipd: REPLY WIRE_GOSSIP_GETCHANNELS_REPLY with 0 fds
2020-07-01T12:46:17.484Z DEBUG gossipd: Trying to find a route from (me) to 0xxx_ID_EDITEDOUT_XXX for 40000000msat
2020-07-01T12:46:17.484Z DEBUG gossipd: REPLY WIRE_GOSSIP_GETROUTE_REPLY with 0 fds

Is it possible the problem for that to be related to TOR, considering that I can connect to and open channels with public nodes just fine?
I haven't opened direct channel between the nodes, since I want to play with routing.
But each of those nodes has established channel with some of the most well connected nodes, so route exist for sure.

Is it possible the problem for that to be related to TOR, considering that I can connect to and open channels with public nodes just fine?

No, that's very unlikely. (and contradictory)
Are the channels you created announced ?
Are your two nodes connected to the network ? For a node to find a route it needs to be connected to the peer-to-peer network to trade gossip and build its view of the current state of the network (opened channels and whether they are active).
Without this information there is nothing for it to search routes in.
You can verify that your channels are announced with listpeers (the channels array), or by running listchannels <scid> on your first node (with scid the short channel id of a channel of your second node).
If listchannels returns an empty array you need to connect to some public nodes and wait for your node to sync gossip with the rest of the network.
Finally, as it'll surely be your next concern: be sure to have incoming capacity in at least one of your second node's channel :-).


text:
Why does Miniscript add an extra size check for hash preimage comparisons?
When I input the following miniscript into https://bitcoin.sipa.be/miniscript/:
and(pk(claimant_pk),sha256(H))

I get the following Script:
<claimant_pk> OP_CHECKSIGVERIFY OP_SIZE <20> OP_EQUALVERIFY OP_SHA256 <H>
OP_EQUAL

Why does Miniscript add this size check? Is there a safety concern or some ability for a malicious ScriptSig/ScriptWitness to skip the OP_SHA256 opcode?

This is to avoid a preimage too large to be claimed by one of the parties in a contract.
For instance without this check it would be possible to create a Lightning HTLC that is only claimable by a preimage whose size is larger than the maximum standard witness stack element size. An attacker cooperating with a miner would be able to claim the HTLC onchain on both sides of the attacked node: on the sender side with the "success" transaction (containing the preimage) included in a block by a cooperating miner and on the receiver side after timeout since the Lightning node wouldn't have been able to broadcast the non-standard "success" transaction through the P2P network.
Another example is a cross-chain atomic swap, to avoid a preimage to be valid on one chain but not another with more restrictive size limits. For instance without the size check an atomic swap between chain A which restricts witness stack elements to (say) 50 bytes and chain B which restricts them to 51 bytes could be made non-claimable on A by using a 51 bytes preimage.
As a side effect this makes sure the witness size for satisfying this script can be accurately calculated. (You would otherwise need to take into account the preimage may be as large as the maximum witness stack element size.)
A pull request adding some rationale for this check on Pieter Wuille's website was recently merged. (EDIT: the rationale is now available on the website, at the bottom of the "Translation table" section.)


text:
Bitcoin transaction fee is more than balance?
I have some bitcoins which values 2.45 USD in my wallet.
When I want to send my bitcoins, blockchain (my client) prevents to do it. It tells me that my fee is more than my current balance!
I can't understand it! Then how can I use my money ??

Bitcoin fees aren't set as a percentage of the amount being transferred, but based on the number of bytes needed to encode the transaction.  In principle you can set any fee that you want, but miners will choose the higher-fee transactions to confirm, and others may never be confirmed.  It can be a little tricky to get your money back in that case, depending on the software you are using, so some wallet providers (like blockchain.info) may not let you set a low fee.
According to https://bitcoinfees.earn.com/, the currently recommended fee level is around 0.00000016 BTC/byte.  At the current price of $6,663 USD/BTC, that's about US$0.001 per byte.  So if your transaction would need to be larger than about 2.5 KB, you can't afford to send it.
In particular, if you received your bitcoins in many small transactions, then in order to spend them, your outgoing transaction has to list all the previous transactions you are spending, with a signature for each one.  This requires about 180 bytes each.  So, did you receive more than about 12 transactions previously?  Or are you attempting to "split" your transaction to send coins to many different destination addresses?  That will also increase the transaction size.
There isn't very much you can do about this.  It's possible that transaction fees will be lower in the future, but since it's market-based nobody knows for sure.  Otherwise, you might as well assume those coins are unusable, and make sure in the future to receive coins in larger increments.


text:
How to get the outbound and inbound capacity of a node using LND?
I expected to find an option on lncli to get the exact inbound and outbound capacity of my node, but this is not the case. What is the best way to have this information?

lncli listchannels will tell you the local balance and remote balance of each channel (in satoshis).
You could simply sum up the the balances of all your channels to find the total outgoing capacity (local balance) and incoming capacity (remote balance) you have. Here is a one-liner that reports the sum of your inbound capacity (requires jq):
lncli listchannels | jq -r '.channels[].remote_balance' | awk '{sum+=$1} END {print sum}'
lncli channelbalancewill give you the total outgoing capacity you have, but until AMP is commonplace, it may be more useful to know the capacity of your largest channel alone.

Can you suggest a one-liner to do so?

I suppose the remote balance is the inbound, am I correct?

Yes, remote_balance is inbound, local_balance is outbound. Note that a channel must reserve a small balance for channel closing fees, so you might not always be able to spend the entire reported balance. Here is a one-liner to find inbound capacity (requires jq): lncli listchannels | jq -r '.channels[].remote_balance' | awk '{sum+=$1} END {print sum}'


text:
Can a block have multiple coinbase transactions? Also is there a limit to the number of signatures a multi-sig transaction has or requires?
I am wondering if a block can be created with multiple coinbase transactions. The US government regulates mining pools that have control over the miner's wallets, so it would be fabulous if this could be circumvented by having multiple coinbase transactions to multi-sig wallets. Also is there a limit to the number of signatures that a multi-sig wallet can require?

This really is two separate questions, it would be best if you asked them individually.

A block can only have one coinbase transaction. You could however send the reward+fees of the coinbase transaction to multiple addresses (of any type) just like any other transaction.

is there a limit to the number of signatures that a multi-sig wallet can require?

https://bitcoin.stackexchange.com/a/28092/87716

Note that while the reward and fees can be spent like any other transaction, you must wait 100 blocks for the coinbase output to mature before spending it - this means it cannot be spent within the same block, or another 99 blocks following it.


text:
How to create a Bitcoin Transaction With Protocoin
Please how do I create a btc transaction and broadcast it with protocoin library? I want to create a transaction that will relay to the node without validating inputs and outputs. Of course I know the transaction will not get confirmed. I just want it to be broadcasted for a while.
Does anyone know any way I can use to do this? If there are other simpler methods to do this, I would also appreciate that.

what is protocoin? Have you attempted anything, yet, please share what you've tried and the result.

Your node will discard the invalid transaction and not broadcast it. If it does broadcast it, its peers will ban it for sending invalid data. I think you may get better help if you provide more background information on what you're trying to achieve.

I'm trying to replicate this, but without using the software advertised there. https://youtu.be/s8Ij1oPYBsU


text:
Why would a merchant accept Bitcoin?
I am trying to get the answer for the following example:
Assume I have some bitcoin and want to buy a product from a merchant. Why would the merchant sell that product to me for bitcoin when he bought it from the supplier for dollars?

How do you know the supplier doesn't accept bitcoin as well?

Because he can sell the bitcoin for dollars. And in many cases, his alternative would be to accept a credit card payment which costs him around 2%. Converting bitcoins to dollars costs around 0.2% -- one tenth as much. Also, if he accepts a credit card payment, he has to worry about a chargeback (where you claim the payment was unauthorized and the bank reverses the payment). Bitcoin has no chargebacks.

Many businesses pay suppliers in one currency, and then accept a different currency for payments from customers, this is not a rare situation to be in.
For example, a Canadian business may pay a Chinese supplier in USD, but then accept CAD from their customers in-store. Or an American importer may pay their Japanese supplier in JPY, and then accept payment from their customers in USD.
In both cases, a currency conversion will need to happen at some point, and so the business would do well to find an efficient way to make that conversion. Bitcoin is no different, the merchant can accept it, and then convert to dollars in order to pay bills, etc.
Of course, the merchant does not have to convert the BTC to dollars, they could decide to keep some (or all) of BTC payments in BTC.
As for reasons why a merchant would want to accept BTC in the first place:

As David mentioned, the finality of Bitcoin transactions means chargebacks are not possible (protecting the merchant from fraud).
Accepting Bitcoin allows a merchant to accept payments from any willing customer, allowing unrestricted access to the worldwide market. This may be especially important for merchants from countries with strict capital controls.
Accepting Bitcoin could allow a merchant to remain anonymous, whereas traditional payment gateways will require some KYC to satisfy local regulations.
The merchant may believe that BTC will increase in value, for personal/ideological reasons, and thus want to be paid in it.
The merchant may save a lot in transaction costs (compare to a few % for each credit card or PayPal payment, ten's of dollars for each wire transfer, etc). This could be especially true if the merchant's vendors accepted BTC for payment as well.
Bitcoin allows permissionless innovation, meaning a merchant could code up a customized payment gateway/solution to suit their exact needs. This may enable new forms of payment/funding/etc, that are not easily possible with existing payment gateway providers. For example, a Lightning Network integration could allow a merchant to collect micro-transaction amounts that are not possible through other payment gateways.

Thanks for being so patient and answering to my question. I consider myself dumb in blockchain technology so i request you to kindly bear with me for my follow up question as below. During the time when the blockchain for Bitcoin was created, when a merchant wants to sell a product, Initially since Bitcoin is not guaranteed by the government and does not carry any value in the market, why would anyone exchange a service or a product for a Bitcoin.

@SeethaRaamDevulapalli happy to help, asking questions is a good way to learn. Many of the earliest adopters of bitcoin liked it because it was not ‘guaranteed by a government’. They could see the potential of Bitcoin to do all the things I mentioned above, so they joined the network. Eventually, bitcoins gained value, thanks to the actions of these ideologues, and slowly the network grew (including merchants accepting it as payment).


text:
Why can't I modify someone else's transactions, if I have their signature data?
As I know, signature system is adding signature to end of transaction. And doesn’t hash transaction, so others can know my signature.
If I can send a message directly to the node, can I use other’s signature and send currency to me?
For example, Alice make a transaction sending 1bitcoin to Bob. Then Alice will send her digital signature to nodes. And nodes will verify it is from Alice and share the transaction with address, signature, etc.
At here, I can know her signature and can send a transaction with her signature. Then nodes will verify this transaction is from Alice and share it.
I’m very beginner of cryptocurrency, so can you let me know where has problem?

The signature Alice creates is not just arbitrarily appended to her transaction. It is created by taking the transaction (or in some cases just parts of the transaction) as input, and then by using the relevant private key, a signature is created over this transaction data.
So when Alice signs the transaction, the signature that is created will only be valid for the specific transaction that was signed. If any part of that transaction is modified, then the signature will no longer be seen as valid by other nodes on the network. Thus you cannot just modify the transaction to pay to a different address, as doing so would make the transaction invalid.

A digital signature is produced using a mathematical function that takes two numbers a and b from which the function produces a number c. The mathematical function is one which cannot be reversed, given c and a you cannot work out b.
So a can be the numeric value of a message being signed and b can be a number used as a private key that no one else can ever discover.
A separate mathematical function can take the message a, the signature c and another number d that is related to b and tell you if the signature is good. d is called a public key. You cannot mathematically work out the private key b from this public key d, so the private key b is always a secure secret that is not revealed by the signature or the checking process.
So the signature c of a message a is not usable as a signature for a different message, a different value of a produces a different value of c and the checking process will show this.

A signature as in a scribble on a paper: you could just cut it out and put onto a different piece of paper.
A cryptographic signature: it signs only exactly one specific thing; nothing else. Cannot be put onto different data.
More accurately, it signs a 128 or 256 bit message, which is the hash of whatever you are signing. Different message = different hash => signature not valid.


text:
Cryptocurrency exchanges that have swift code
Is there some cryptocurrency exchange that has SWIFT code?
If a cryptocurrency exchange doesn't have SWIFT code, I cannot send dollars from my bank to it.
Thanks.

Both Binance and Huobi don't seem to have swift code.


text:
Connect to regnet from my WalletAppKit Android app
I'm developing a simple app to learn how to use the bitcoinj library. I'm using the WalletAppKit object to simplify the process and I'm following the official documentation.
When developing I prefer to use bitcoind regtest mode as it's faster than the testnet3 and I don't need to be connected to the i
if (params == RegTestParams.get()) {
    // Regression test mode is designed for testing and development only, so there's no public network for it.
    // If you pick this mode, you're expected to be running a local "bitcoind -regtest" instance.
    kit.connectToLocalHost();
}

I was playing with the WalletTemplate example desktop app and it works just fine on the regnet. Now I'm trying to do the same on my Android app but I don't know how to connect it to my regnet instance running on my machine.
Does anyone know how can I do that?
Thanks in advance,
Felipe

If you're connecting to a bitcoind regtest node and you're trying to connect as an RPC client to it via bitcoinj, it's possible.
Figure out what your Android's IP address is, say x.y.z.w and use the -rpcallowip parameter in bitcoind to allow your (remote) Android app to talk to the regtest bitcoind node.
Spawn bitcoind like this, for example:
bitcoind -debug=1 -printtoconsole -server \
    -regtest -listen -rpcport=8332        \
    -rpcuser=yourrpcuser -rpcpassword=yourrpcpass -rpcallowip=18.138.5.97

WARNING: Security-wise, keep in mind that the RPC password is transmitted over the network in plaintext.

authors: Алексей Уколов


text:
Is there any way to tell if an address has been created on an exchange? (e.g., Coinbase)
I am wondering if there is any way to check that a bitcoin address was created on an exchange.
For example, if I want to only interact with (send BTC to) people that have verified their identity (like on Coinbase), is there any way to check that their address is connected to a Coinbase account?
Thanks.

"Verified" addresses are not something you are likely to see, although could be implemented by trusting a 3rd party (if users choose to opt in).  This isn't really the allure of Bitcoin, so I wouldn't expect such an idea to gain much traction.
Determining if an address belongs to an exchange, however, may be possible using blockchain analysis.  By correlating inputs and outputs of a transaction known to be from an exchange, you may be able to determine with a varying degree off certainty other addresses and transactions that belong to that entity.

No, it's not possible at all. read more How does Bitcoin work

Thanks. So there are no APIs or libraries available or made public by exchanges with lists of wallets created by their site for users?

No, because it's not possible with Bitcoin since there's no particular sign about how that address created or where. Bitcoin built to be like that. Anonymous.

Thanks. I realised that about bitcoin but was curious if exchanges made it public somehow through some APIs when they create those wallets.
I appreciate your help.

Such a verification would require the providing of specific evidence (such as a screen shot, which could still be faked) or a verification by Coinbase themselves.  I wouldn't hold my breath for either of those options, if I were you.


text:
I sent bitcoin to someone and did not get paid
I sent Bitcoin to someone who promised to pay me in cash personally once he received the Bitcoin in his BitPay wallet. But once he got the Bitcoin, I  never got paid by him. Is there anyway I can do something about this matter?

Sorry for your loss. This is why you need a trusted third party (e.g., coinbase.com) when exchanging a digital coin like Bitcoin for some real-world coin like US dollars. Are you sure they received the coins? Is going to the police an option?

Does Bitcoin have a function that would allow the BTC you sent to be returned, No.
The only way to get the BTC back is if the recipient makes a new transaction sending the Bitcoin to your receiving address. If the recipient will not do this, you may think about contacting a lawyer.

Too bad so sad, you learn a lesson.
The person could be poor and pussy and a little son of bitcoin. anyway, sorry for the loose.
Make sure to ask the person for the payment first then you send it.


text:
What does it mean when a confirmed transaction gets reversed?
I am using bitcoin-cli to do verification of transfer. From the wiki, it mentions that a transaction has a higher confidence in confirmation after 6 blocks deep. However, a block that is put into the blockchain should not to be reverted or removed.
So I want to know what will trigger a confirmed transaction to become invalid and what will actually happen to the blocks and the blockchain?
Especially in bitcoin-cli when I get a block with the target transaction, what will happen if this transaction does not get the final confirmation?
Reference: https://en.bitcoin.it/wiki/Confirmation

Every now and then, blocks become orphaned during what is called blockchain reorganization.  This happens when two valid blocks are found at about the same time, and the network is split on which one is considered the top of the blockchain.  These two blocks can contain different sets of transactions, so one block may contain your transaction while the other one doesn't.
This situation will be automatically resolved.  Let's call the two blocks A and B.  Eventually, a new block will be found on top of one of the two competing blocks.  Let's say this new block, C, is found on top of A.  When C is broadcast, any nodes recognizing the B as the tip of the chain will see that more work as been done on the other fork, and will orphan B in favor of A and C.  It will be like B never happened.  If your transaction was confirmed as part of B, it will be like your transaction never happened.
The good news is that it is likely that A and B share a good deal of the same transactions.  Even though you may have been recognizing B instead of A, there's a good chance the transaction will be already confirmed in A when you come around to recognizing it.  If not, it means the transaction will still be in the mempool, and is likely included in C or will be included in a later block.
As you can see, the odds of this happening go down as each new block piles on top of the block containing your transaction.  By the time 5 blocks have been mined on top of the block containing your transaction (thus 6 confirmations) there is no reasonable chance of that block being orphaned.  The transaction is now permanent.


text:
How to set up a node on Testnet of Lightning network on the world map
I am currently having problems posting my node on the "World Map." I can see my node on the "Force Map" on this site.
Can anyone tell me how to enter the public IP so that it can be seen on the "World Map"?
My node is currently showing the pubkey but not the public IP.
Can anyone help me with steps of how to enter the IP of my node?

Is your node have at least one open channel?

Yes, it has 4 open channels.

Is your node expose a public IP and channel has 6 confirmations?

Just want to know how can i enter ip address of my node . I am using "lightning.exe" app , to make channels.

No ,we are not able to set our public IP .

You need to start your lightning server with --externalip flag set to your public IP address. The specific command depends on which implementation you are using at the moment one of lnd, c-lightning or acinq.