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.
Related
Does anyone know what's a hashgraph and the difference from blockchain? If you could explain it to me how it works, I would be pleased!
Thank you in advance!
Hedera Hashgraph is very much different from a regular Blockchain (which is a chain of blocks as its name suggests), it is a DAG (Directed Acyclic Graph).
You can read more about what a DAG is in the link provided but apart from that how Hedera is different is that it is solving the below problems that any DLT should overcome to become Scalable, Secure and Fast without losing Trust:
(1) Performance,
(2) Security,
(3) Governance,
(4) Stability,
(5) Regulatory Compliance.
How is it solving all this simultaneously without losing Trust is something that you can read more in their whitepaper which explains beautifully or refer this article from Rejolut.
One primary problem with any Public Blockchain is the TPS or Transaction per second it can handle and Hedera Hashgraph is miles ahead of the others with being able to clock 100,000 TPS which makes it valuable and preferred option as it offers services like Crypto Service, File Service, Smart Contract Service and Consensus Service.
You can have a look at some of the explorers like Kabuto and Dragonglass to get an idea of the transaction speed and other details.
If you want to play around with Hedera Hashgraph, their docs are very well written or you can use console playground to work on Smart contract and Consensus services directly and maybe use fairorder to do the account management for you to begin with.
Hedera does not use blockchain. It uses DAG, "Directed Acyclic Graph. it keeps the records of communication of all the nodes in Dag and time stamps all these messages. Sending messages between nodes is called gossiping`. Its source code is not open source.
How does the gossip protocol work
In hashgraph, when sending information between nodes, "Alice" will
choose another member at random, such as "Bob". Then Alice will tell
Bob all of the information she knows so far. Alice then repeats this
information with a different random member. Bob repeatedly does the
same, and all other members do the same. In this way, if a single
member becomes aware of new information, it will spread exponentially
fast through the community, until every member is aware of it.
The synchronization of information between two members through the
gossip protocol is called a gossip sync. Upon completion of a gossip
sync, each participating member commemorates the gossip sync with an
event. An event is stored in memory as a data structure composed of a
timestamp, an array of zero or more transactions, two parent hashes,
and a cryptographic signature. The two parent hashes are the hash of
the last event created by the self-parent prior to the gossip sync and
the hash of the last event created by the other-parent prior to the
gossip sync.
Gossiping is the basis of the hashgrap consensus algorithm which uses asynchronous byzantine fault tolerant (abft) . this indicates that there is no specific time when all the nodes reach consensus. In other words abft consensus mechanism has no block time. (there is no blockchain here. neither a block reward)
Since gossiping the fastest way of sperading information, it takes 3-5 seconds for the entire network to reach a consensus.
Hedera claims that the network achieves 10,000 HBAR cryptocurrency transactions per second. (i personally do not believe those claims)
You can also write smart contracts on Hedera. But you cannot execute 10000 smart contract operations per second because Hedera uses EVM and EVM is very slow.
Hedera has no slashing. If validators misbehave, they will not lose any of their crypto holdings. because they claim that hedera hashgraph gives validators less opportunity to misbehave. validators receive the 90% of the network fees.
So I'm trying to understand what practical problems Queues solve. By reading all the information from Google, I get the high-level.
Push message to Queue for processing at a later time
So I'm looking at an architecture from Company A and they have different use cases for Job Queueing like for example
chat messages
file conversion
searching
Heavy sql queries
Why process it at a later time?
Here's my best guess...
Let's say I have an application that can process 10 "things" at a time.
My application then maxes out it's processing capacity.
an 11th request came in so app puts it in the Queue for later processing
Assuming this is a valid Use Case, wouldn't adding more servers to process more "things" make sense? Is it because it's more costly to add more servers than employ a Queue and sacrifice response time a little bit?
Given my Use Case examples, what other problems would Queues solve for them?
Have you ever lined up at a bank when it is busy? You would have waited in a queue.
"But," you could say, "wouldn't adding more staff to process more customers make sense? Is it because it's more costly to add more staff than employ a Queue and sacrifice response time a little bit?"
That would be correct. It can be quite costly to staff a bank based on the peak number of customers who would arrive each day. It is cheaper to staff below this level and have some customers wait in a queue.
Also, the number of customers each day are not 100% predictable. A queue allows excess demand to wait without breaking the system.
Queues enable decoupling.
For example, imagine an online store where customers purchase an item. They select the item, provide a credit card number and click 'Purchase'. If the credit card is declined, the online store can immediately prompt them to re-enter the number. This interaction has to take place immediately while the customer is still online.
However, there is no need to have the customer wait while an invoice is generated, a record is added to the accounting system and inventory is pulled off the shelf. This can be decoupled from the ordering process. A good way to do it is to push the order into a queue, which can be handled by the next system.
If that 'next system' happens to be offline at the moment, there is no reason to cancel the whole sale. The transaction can be processed when the 'next system' comes back online. This is much better than failing the whole process just because one component (which is not required immediately) has a failure.
Bottom line: Queues are excellent. They enable better handling of failures. They makes things more resilient (just wait a few minutes and try again!). They should be used at all times when the process is compatible with a queuing architecture.
Let's do scenarios
Scenario 1 without queue:
you request an endpoint /blabla/do-eveything/
this request do
download an image from very slow FTP
e.g 1.5 sec (can error, retry ? add +X sec)
attach the image to an email
send an email (3 sec)
e.g 1 sec (can error, retry ? add +X sec)
confirmation received > store confirmation to a third company tracking stuff
e.g 1.5 (can error, retry ? add +X sec)
when tracking confirm, update your data from another third company for big data purpose
e.g 2 sec (can error, retry ? add +X sec)
... you get the idead
return the response e.g 11 sec later (this is to slow) or more or timeout when everything failed
End user said internet was faster 20 years ago, maybe I need to change my internet connection or change my 16 threads
Scenario 2 queue everything you can:
you request an endpoint /blabla/do-eveything/
this request do
Queue job "DO_EVERYTHING"
e.g 0.02 sec
Return the response less then 0.250 sec
End user said that is website/app is too fast, I can keep my 56K internet connection
on queue/event system one failed job can be retry later without affeting the end user
you can pause job, add a unlimited number a task/step after the original message
better fault tolerance
Working with queue will allow you a better micro/nano service architecture, better testing because, you can test a single job, intead of a full controller that do everything...
Ye, is maybe more work, more thinking, but a the end no need to think about the work when holidays
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.
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 am using PayPalAPIInterfaceClient (soap service) to get information about transaction (method GetTransactionDetails()) and need to be absolutely sure about transaction status (it means - money has been sent no matter in which direction).
When the transaction is really completed and when is still "on the road"?
For example: I assume, Processed will be followed by InProgress and finally changed to Completed or something like this. On the other hand, Denied or - I don't know - Voided will not change in future.
Can you help me please to decide, which status can be accepted as ultimate (like Completed, but may be even Completed must not mean final money transfer) and which ones are still in one of its sub-state?
I would expect simple "Money finally transferred" & "Money finally not transferred" result, but reality is different.
Shortly, to mirror transaction result into database and manage automatic transactions (from and to client) I need to know this.
I am using the PaymentStatusCodeType enumeration values and my service iterates transaction history to check if the money was transferred or not.
Completed means it's done. You may also want to look into Instant Payment Notification (IPN). It sends real-time updates when transactions hit your PayPal account so you can automate post-transaction tasks accordingly. This includes handling e-checks or other pending payments which won't complete for a few days, refunds, disputes, etc.