I have searched and searched and can't find the answer. If you are running a full node, can you confirm transactions. Or do you just verify/relay transactions? Or is it only miners that can confirm transactions? When I say confirm, I mean, when you spend some bitcoin, you need X confirmations (usually 6) for it to go through. Who does the confirmations? Can it be full nodes? Or is it only miners?
What I mean is, in the wallet, you see X confirmations. Who makes that number go up? (Say, for example, from 0 to 1). Is it miners, full nodes, or both. Realizing that miners run full nodes. But I mean, full nodes that are not miners. Can they add a confirmation? Or does it have to be a miner?
Transactions are confirmed by blocks being added to the blockchain. A transaction's first confirmation is when it is included in a block and that block is mined (added to the blockchain). Each subsequent block added to the blockchain on top of that transaction's block means another confirmation. So a transaction has a number of confirmations equal to its depth in the blockchain.
Confirmations happen because of blocks being added to the blockchain through the process of mining, so per your question, only miners can confirm transactions. Once a block is added, full nodes verify and relay that block, but only miners do the work of actually confirming the transaction.
Related
I am trying to learn the blockchain technology and implement it in our existing product ecosystem. Bitcoin is the best example of blockchain technology.
I have read multiple articles on the internet and found that blockchain is a distributed ledger and every participant in it will maintain a copy of the ledger.
There are around millions of people holding bitcoins.
So all these customers maintain copy of ledger at their end ?
And when we make a new bitcoin transaction we need every other customer's consensus to make transaction successful ?
Or is it that there are a set of bitcoin minors who act on behalf of these customer's and maintain these ledger at their end ?
A Blockchain is a network where everyone is at the same level, i.e. there isn't a centralized authority that holds the system. So, everyone stores all the information.
And when we make a new bitcoin transaction we need every other
customer's consensus to make transaction successful ? Or is it that there are a set of bitcoin minors who act on behalf of these customer's and maintain these ledger at their end ?
The consensus is reached among all the participants of the Blockchain. In the case of Bitcoin, the mechanism used for it is the Proof of Work (PoW).
When a node of Bitcoin gets a new transaction, it verifies the transaction. If all is ok, the node broadcast the transaction to the rest of the nodes of Bitcoin. Every node, when it receives a new transaction, validates it.
The nodes of Bitcoin are miners. They are trying to generate a block. That block will store many transactions. When a node generates a block, the block is broadcast to the rest of the Bitcoin nodes.
When a node receives a new block, it verifies the block, i.e, verifies that all the transactions are valid and the block is correct. If so, the node adds the new block to its blockchain.
All the nodes store the same Blockchain. Also, all the nodes verify all the transactions and all blocks.
If B is transferring bitcoin to C then when will be C receive the bitcoin? Is that after all the miners add that transaction into their local ledger? (I think it is time-consuming and what will happen if some miners are not adding?)
Now, if some miners are finding transaction invalid, while some find it valid so what will be the scenario in that case? When will be C receive the bitcoin?
The blockchain is a public ledger, so B isn't sending the transaction to just C, B is announcing it to everyone in the public network that i am sending bitcoin to C. So everyone in the network can see this transaction and now has to wait to be included in a block.
Miners create blocks of transactions, in every 10 minutes a new block is included into the ledger.and they have to create them in such a way that the rest of the network will accept them. One of the requirements is that the transactions in the block are all valid transactions. So yes, miners will validate that B has send bitcoins to C before they add the transaction to a block.
As all the full nodes in the bitcoin blockchain knows the currect state of bitcoins hold by B, they can easily verify the validity of the transaction.
Note: Each node in the blockchain either accepts or rejects a transaction.
Here's details you may want to have a look
https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages
when will be C receive the bitcoin? Is that after all the minors add
that transaction into their local ledger?
Each minor is trying to mine a block. When someone mines a block, the block is distributed along the network. So, every miner get that block. In a block, there would be some transactions.
However, another block could be mined at the same time. A miner who receives more than one block at the same time will continue mining along a branch. So, after some time, one of the branches will win.
Because of that, a transaction is valid when there are 100 more new blocks (I'm not sure if they are 100 or less) on top of that block.
what will happen if some minors are not adding?
After some time, all the minors will reach consensus about the branch and all of them will have the same blocks.
if some minors are finding transaction invalid, while some find it
valid so what will be the scenario in that case?
When a miner receives a block, verifies if all transactions are valid. If not, it sends a message to the rest of the miners to tell them that the block is invalid.
The result of a transaction (valid or invalid) is the same to all the members of the network.
I have been reading about blockchain and ethereum, but I cannot seem to get my head around a couple of concepts.
First, where in the blockchain is a newly created transaction stored ? So if the blockchain has been on going for some time, and lets say we are on block X right now. If I deploy my contract today, and it gets executed, will my transaction details reside on every block after block X or only on block X + 1 ? And will my transaction details be the only details on that block, or will that block contain every transaction that happened within that time period ? Again, do all of the prior blocks transactions get written to subsequent blocks as well ? What happens if more than 1 transaction gets executed from the same contract, is just written as 2 different blocks or within the same block ?
Second, when designing a contract I have seen that it is usually restricted to two parties that enter into it, and for other people to use the contract a new instance of the contract has to be created, is this understanding correct ? Or should 1 contract be designed in a way that everyone uses it and only one instance of it is ever created ?
where in the blockchain is a newly created transaction stored ?
In the blocks that each node stores.
will my transaction details reside on every block after block X or
only on block X + 1 ?
Each transaction only resides in a block. Each block is related with the previous block, so your transaction is throughout all the blockchain.
And will my transaction details be the only details on that block, or
will that block contain every transaction that happened within that
time period ?
It dependes on the implementation of Blockchain. For example, Bitcoin blocks store all the transactions that have been sent throughout 10 minutes, because each block is mined every 10 minutes (more or less).
Second
Blockchain is a distributed system, where all the members are at the same level. So, they get the consensus about what they are going to do, i.e. all the members have to agree about the functions of their Blockchain.
For each Blockchain, you can have more than one contract. But I'm going to explain it more simply. The Smart Contract is the code that is installed on all the nodes of the Blockchain, and every request is executed against it. So, every node/member must have the same.
In a blockchain system like bitcoin, each peer (participate node) keeps a full copy of the ledger. A peer updates its copy of ledger when it receives and validates a newly arrived block. However, the peers are scattered around the globe, and the network latency among these peers varies a lot. Therefore, how the blockchain system guarantees that all the peers have finished updating their copies of ledger after a block has been propagated?
Bitcoin doesn't guarantee that all ledgers become updated at the same time, bitcoin blockchain provides you with consistent ledger following:
Proof-of-work to cut new block with set of transactions
Longest chain rule
Above guaranties you that if there no more than 51% of the network controlled by one group you will eventually see consistent ledger, e.g. given your ledger at block sequence number 1001 means all nodes in the network will see identical chain of blocks until 1001.
To your question bitcoins use random overlay network to distribute new blocks (pretty similar to gossip algorithm).
UPDATE
See section B. Propagation Method from here:
For the purpose of updating and synchronizing the ledger
replicas only transaction (
tx
) and block (
block
) messages are
relevant. These messages are far more common than any other
message sent on the network and may grow to a considerable
size. In order to avoid sending transaction and block messages
to nodes that already received them from other nodes, they are
not forwarded directly. Instead their availability is announced
to the neighbors by sending them an
inv
message once the
transaction or block has been completely verified. The inv
message contains a set of transaction hashes and block hashes
that have been received by the sender and are now available
to be requested. A node, receiving an inv message for a
transaction or block that it does not yet have locally, will issue
a
getdata
message to the sender of the inv message containing
the hashes of the information it needs. The actual transfer of the block or transaction is done via individual block or tx
messages. Figure 2 visualizes the protocol flow for a single
hop in the broadcast.
I am writing a bitcoin app and looking to implement a 'cancel' feature. All over reddit are references that if under 3 confirmation have occurred, technically a payment can be stopped. Maybe only a minute or 2 available, but still.
I cannot find any reference in the bitcoin api docs to demonstrate how this would be done.
I know that one altcoin uses an intentional 60 min gap to confirm for this very reason.
Anyone know how this is done?
Is it possible to cancel a Bitcoin transaction ...
... which was not yet broadcasted?
Yes, obviously it is possible. I'd propose you choose this method in your Bitcoin app by showing the user a confirmation screen for some seconds with information about the transaction and some buttons saying cancel and confirm. #nahtnam proposed a 60 minute delay which is too much, considering you may lose internet access or want the transaction to appear in the blockchain as soon as possible.
... which was already broadcasted?
Maybe... To cancel such a transaction, you'd need to create a block yourself which moves the inputs of the original transaction to one of your own addresses. (Effectively invalidating the original transaction.) However, creating a block costs several thousand dollars as of now and finding a block is not guaranteed.
Another possibility would be to broadcast another transaction taking the same inputs as the original one and targeting the outputs at one of your own addresses/wallets. To motivate miners to include this transaction instead of the original one, you increase the transaction fee. However, some clients may not relay such double spent transaction to the miners and some miners may reject the double spent transaction and include the original one (the one they received first), instead. (c.f. Bitpay encountered zero double spent in the first 10000 transactions. and Cancelling an unconfirmed transaction by #theymos (bitcoin.stackexchange))
There are some tricks to hide your initial transaction from miners by creating a so-called "non-standard" transaction. Alternatively, the transaction could include a very low fee to make miners reject it for economic reasons. (c.f. Significant losses by double-spending unconfirmed transactions (bitcoin-dev mailing list) and Double-spending by #petertodd (Reddit)) However, this makes your transaction look suspicious to the receiver if they look closer at it and they will most likely ask you to wait until it has one or more confirmations.
Finally, it is also possible if you set a flag on the original transaction to indicate replaceability. You can then replace the original transaction with another one by including the same (one or more) inputs in the replacement transaction. Also, you must pay a higher fee. However, not all miners honour this flag and some might still include your initial transaction. (c.f. Reference to BIP 125: Opt-in Full Replace-by-Fee Signaling)
... which is included in one or more blocks?
No, very unlikely to impossible. You'd need to control a substantial amount of hashing power to create a fork by rebuilding the blockchain starting at the block before the original transaction happened and ending at the block with height = (current public blockchain height) + 1. Therefore, "the more confirmations you have, the more difficult, expensive, and unreliable an attack like this is."
Source: #DannyHamilton (Bitcointalk)
The bitcoin paper by Satoshi Nakamoto explains that this is always possible when you control more than 50% of the hashing power, and possible with a probability less than 1, but greater than 0, if you control less than 50% hashing power. See Bitcoin: A Peer-to-Peer Electronic Cash System.
Though, if you control a substantial amount of hashing power, you are likely incentivised to not undermine the trust in bitcoin by undoing transactions and indirectly hurting your revenue stream from mining.
No. It is impossible to stop a bitcoin transaction. Thats what makes bitcoin so different. There is no way to reverse a transaction except for getting the receiver to send it back to you.
On another note, you could still have a cancel feature. You could set a delay of 60 minutes before you send a transaction and in that gap, someone can cancel but as I mentioned before there is no way to stop a transaction that has already reached the blockchain.
Work out the strategy before making a bitcoin payment. Check that both bitcoin addresses for payer and recipient are correct (use the copy and paste facility). Check that details of the product/service and $ amount are correct. Check that you have the correct private key details. Expect to wait at least 24 hours for confirmation. This allows time for the miners to validate the transaction. Then check your bitcoin account to ensure that the transaction is completed correctly by inserting your private key details into Google search, or check your bitcoin software for the transaction details.
It is complicated and expensive to cancel a transaction. So before you make payment, check, check and check again before sending.