<p>Even in conventional systems, a return is a separate transaction from the original purchase. Both are recorded, the original purchase transaction need not be amended so long as the system associates both transactions together. In short, returns are not the same as a transaction cancellation</p>

CC BY-SA 4.0
2021-07-12T09:50:40.847Z
2021-07-12T09:50:40.847Z
RedGrittyBrick
<p>Questions like this <a href="https://bitcoin.meta.stackexchange.com/questions/1011/proposed-timeline-for-scope-change">are off-topic</a> on this forum, however I'll take a stab at answering your question as you seem to have a lot of misunderstanding.</p>

<p>The bigger question you need to ask yourself if why you want to implement your e-commerce application on a 'blockchain'? It would be a gross neglect for basic engineering design principles as blockchain is nothing but a slow and expensive database. I mean I would understand if you wanted to create a Dapp if you are selling drugs and other illegal substances (like SilkRoad) since you wouldn't want a single point of failure and lack of attribution as an owner. However, if you are creating an e-commerce application that is perfectly legal you can create it on a normal database system.</p>

<p>Blockchain is one of the many components that make Bitcoin successful, not the only one. A blockchain is used in Bitcoin to prevent double spend attacks as transaction included in previous blocks get precedence over the latest transaction if they spend the same output, and achieving consensus on a global scale where all participants have the authority to accept changes.</p>

<p>Private blockchain is nothing but an old wine in a new bottle. There are plentiful example of distributed databases with multiple write access available today like Google Spanner or Paxos. So, coming back to the question you need to ask yourself, what are benefits that the "blockchain technology" is providing you that is not possible with existing 'traditional' solutions in the market?</p>

CC BY-SA 4.0
2020-01-01T07:43:49.077Z
A few comments: "other PBFT consensus blockchains": PoW is not PBFT (and PBFT is a specific instance of a class of consensus algorithms called BFT; PoW is not BFT either).
Pieter Wuille
CC BY-SA 4.0
2020-01-01T07:45:56.297Z
Voting to change the state of the database in (P)BFT is equivalent to a block that contains an (possibly illegal) transaction. The immutability is about the history, not about the final state. If you maintain a log of all updates in PBFT, you also have an immutable history. If you make it hashlinked, it's arguably a blockchain even.
Pieter Wuille
CC BY-SA 4.0
2020-01-01T07:48:36.027Z
Last: Paxos and Spanner are not (P)BFT algorithm. BFT consensus keeps working even in the presence of malicious actors, but need 2/3 majority vote (and 2/3 honest participants). Traditional consensus algorithms like Paxos assume only malfunctioning/unreachable as failure modes, but not intentional obstruction. This is fine as they're run by trusted parties (all servers owned by Google), and it reduces the vote to a 1/2 majority.
Pieter Wuille
CC BY-SA 4.0
2020-01-01T08:17:30.513Z
@PieterWuille Thanks for the comments. Updated for (1) (it was a poor choice of words from my part) and added for (3). On (2), what I was referring to is as follows: There is transaction that happens with company A, that pays B and C. All three have write access to the blockchain (with one other company). At some point, A, B and C realize that the current state with the transaction is not beneficial to them. So they completely erase the hashlinkled 'blocks' previous to that and vote on the state that does not contain the transaction. The previous state with that transaction is completely erase
Ugam Kamat
CC BY-SA 4.0
2020-01-01T08:54:22.243Z
Right, my point is more this: in PoW the assumption is that a majority of the hashrate is honest (and indirectly because they act in their own selfish interest). In BFT, the assumption is that 2/3 of the signers are honest and will not sign a conflicting version of history. In both cases it is possible to revert the state if, but only if, those assumptions are broken. The distinction is not in what is possible or not, but under what assumptions that can happen.
Pieter Wuille
CC BY-SA 4.0
2020-01-01T11:06:27.763Z
@PieterWuille Exactly my point in terms of how it can happen. In PoW, to change a state they will need to expend huge amount of compute and electricity costs. This means that the transaction value to be excluded has to be much more (tangible and intangible) than the cost involved to mine all blocks subsequent to it. In PBFT, all they need is a vote to alter the state, which is easier.
Ugam Kamat
CC BY-SA 4.0
2020-01-01T11:47:24.910Z
No, you misunderstand. They cannot just vote to go back to an earlier state; that would be a violation of the protocol, and would be rejected by validators. Just as in PoW creating a low-work branch that branches off an ancestor would be a violation of the protocol and be rejected. A possibility is resetting every validator in the network, but that's not part of the protocol; it's replacing it with something else.
Pieter Wuille
CC BY-SA 4.0
2020-01-01T11:49:46.023Z
Perhaps you mean that they can vote to create a new state, without reverting, that changes the state back to what it was. That may or may not be possible, but it depends on the consensus rules. In something Bitcoin-like, where state transitions depend on things like transactions having valid signatures, even in a PBFT-like context, this would not be possible.
Pieter Wuille
CC BY-SA 4.0
2020-01-01T13:42:00.653Z
@PieterWuille "and would be rejected by validators": I'll try to explain my understanding better. There are 4 validators, A, B, C, and D. The first three want to change the state of the system (exclude a transaction) as it is more beneficial to them. Since they have 75% majority, they can easily do it by vote. However, in PoW although there can be similar collusion by miners, but they would still need to expend energy to build the hashes again. In PBFT there is no cost.
Ugam Kamat
CC BY-SA 4.0
2020-01-01T13:51:43.267Z
No that's not how it works. Either those 3 try to do it by pretending a previous state transition (the one that included the transaction?) never happens, and reverting to an earlier version of history. This is in _violation_ of the protocol, and detectable - the 4th node will treat it as malicious and ignore those messages or something. The alternative is that they sign an update that brings the state back to what it was before the transaction (without pretending the history never happened). This is likely not allowed either - it's similar to a Bitcoin where everyone trust miners.
Pieter Wuille
CC BY-SA 4.0
2020-01-01T13:54:15.620Z
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/102762/discussion-between-pieter-wuille-and-ugam-kamat).
Pieter Wuille
CC BY-SA 4.0
2020-01-02T01:06:22.827Z
What I understand from discussion is that we can use 'voting' to cancel a transaction, maybe this is the reason why @Ugam calls it a "but a slow and expensive database". This is not logical in case of public blockchain because there can be many nodes. The other solution is to use a private blockchain and once we settle down with the transactions we can transfer them to public blockchain. This would help to ease the cost factor also. This is what I read in an article.  However real-world solution required.
user2994783
CC BY-SA 4.0
2020-01-02T01:09:46.543Z
What are validators? Never heard about this term in the context of blockchain. Please provide some link.
user2994783
CC BY-SA 4.0
2020-01-01T07:37:54.107Z
2020-01-01T14:09:40.903Z
2020-01-01T14:09:40.903Z
Ugam Kamat
<p>The blockchain is immutable. So, using bitcoin for shopping websites can cause problems. Customers often want to return purchases in retail scenarios. But Bitcoin is immutable, so we can't reverse the transaction.</p>
<p>Somebody please guide me how to handle the problem of returning goods in bitcoin-based e-commerce.</p>

CC BY-SA 4.0
2020-01-02T12:11:25.350Z
Even in conventional systems, a return is a separate transaction from the original purchase. Both are recorded, the original purchase transaction need not be amended so long as the system associates both transactions together. In short, returns are not the same as a transaction cancellation.
RedGrittyBrick
CC BY-SA 4.0
2021-02-11T17:10:12.300Z
Since I saw this as "not applicable to Bitcoin" in the review queue, I've edited it to highlight how the question does not change at all by applying it to Bitcoin. TBH, I don't understand why this is being closed under the "not applicable to Bitcoin" reason.
Murch
<business><retail>
How do you handle returned goods in e-shopping?
user2994783
# How do you handle returned goods in e-shopping?

(Asked by: username_0 on 2020-01-01)

The blockchain is immutable. So, using bitcoin for shopping websites can cause problems. Customers often want to return purchases in retail scenarios. But Bitcoin is immutable, so we can't reverse the transaction.

Somebody please guide me how to handle the problem of returning goods in bitcoin-based e-commerce.

**Tags:** business, retail

> **Comments:**
> **username_1**: Even in conventional systems, a return is a separate transaction from the original purchase. Both are recorded, the original purchase transaction need not be amended so long as the system associates both transactions together. In short, returns are not the same as a transaction cancellation.  
> **username_2**: Since I saw this as "not applicable to Bitcoin" in the review queue, I've edited it to highlight how the question does not change at all by applying it to Bitcoin. TBH, I don't understand why this is being closed under the "not applicable to Bitcoin" reason.  

---

## 2 answers

### Answer by username_1 on 2021-07-12. Score: 1

Even in conventional systems, a return is a separate transaction from the original purchase. Both are recorded, the original purchase transaction need not be amended so long as the system associates both transactions together. In short, returns are not the same as a transaction cancellation


---

### Answer by username_3 on 2020-01-01. Score: 0

Questions like this [are off-topic](https://bitcoin.meta.stackexchange.com/questions/1011/proposed-timeline-for-scope-change) on this forum, however I'll take a stab at answering your question as you seem to have a lot of misunderstanding.

The bigger question you need to ask yourself if why you want to implement your e-commerce application on a 'blockchain'? It would be a gross neglect for basic engineering design principles as blockchain is nothing but a slow and expensive database. I mean I would understand if you wanted to create a Dapp if you are selling drugs and other illegal substances (like SilkRoad) since you wouldn't want a single point of failure and lack of attribution as an owner. However, if you are creating an e-commerce application that is perfectly legal you can create it on a normal database system.

Blockchain is one of the many components that make Bitcoin successful, not the only one. A blockchain is used in Bitcoin to prevent double spend attacks as transaction included in previous blocks get precedence over the latest transaction if they spend the same output, and achieving consensus on a global scale where all participants have the authority to accept changes.

Private blockchain is nothing but an old wine in a new bottle. There are plentiful example of distributed databases with multiple write access available today like Google Spanner or Paxos. So, coming back to the question you need to ask yourself, what are benefits that the "blockchain technology" is providing you that is not possible with existing 'traditional' solutions in the market?

> **Comments:**
> **username_4**: A few comments: "other PBFT consensus blockchains": PoW is not PBFT (and PBFT is a specific instance of a class of consensus algorithms called BFT; PoW is not BFT either).  
> **username_4**: Voting to change the state of the database in (P)BFT is equivalent to a block that contains an (possibly illegal) transaction. The immutability is about the history, not about the final state. If you maintain a log of all updates in PBFT, you also have an immutable history. If you make it hashlinked, it's arguably a blockchain even.  
> **username_4**: Last: Paxos and Spanner are not (P)BFT algorithm. BFT consensus keeps working even in the presence of malicious actors, but need 2/3 majority vote (and 2/3 honest participants). Traditional consensus algorithms like Paxos assume only malfunctioning/unreachable as failure modes, but not intentional obstruction. This is fine as they're run by trusted parties (all servers owned by Google), and it reduces the vote to a 1/2 majority.  
> **username_3**: @username_4 Thanks for the comments. Updated for (1) (it was a poor choice of words from my part) and added for (3). On (2), what I was referring to is as follows: There is transaction that happens with company A, that pays B and C. All three have write access to the blockchain (with one other company). At some point, A, B and C realize that the current state with the transaction is not beneficial to them. So they completely erase the hashlinkled 'blocks' previous to that and vote on the state that does not contain the transaction. The previous state with that transaction is completely erase  
> **username_4**: Right, my point is more this: in PoW the assumption is that a majority of the hashrate is honest (and indirectly because they act in their own selfish interest). In BFT, the assumption is that 2/3 of the signers are honest and will not sign a conflicting version of history. In both cases it is possible to revert the state if, but only if, those assumptions are broken. The distinction is not in what is possible or not, but under what assumptions that can happen.  
> **username_3**: @username_4 Exactly my point in terms of how it can happen. In PoW, to change a state they will need to expend huge amount of compute and electricity costs. This means that the transaction value to be excluded has to be much more (tangible and intangible) than the cost involved to mine all blocks subsequent to it. In PBFT, all they need is a vote to alter the state, which is easier.  
> **username_4**: No, you misunderstand. They cannot just vote to go back to an earlier state; that would be a violation of the protocol, and would be rejected by validators. Just as in PoW creating a low-work branch that branches off an ancestor would be a violation of the protocol and be rejected. A possibility is resetting every validator in the network, but that's not part of the protocol; it's replacing it with something else.  
> **username_4**: Perhaps you mean that they can vote to create a new state, without reverting, that changes the state back to what it was. That may or may not be possible, but it depends on the consensus rules. In something Bitcoin-like, where state transitions depend on things like transactions having valid signatures, even in a PBFT-like context, this would not be possible.  
> **username_3**: @username_4 "and would be rejected by validators": I'll try to explain my understanding better. There are 4 validators, A, B, C, and D. The first three want to change the state of the system (exclude a transaction) as it is more beneficial to them. Since they have 75% majority, they can easily do it by vote. However, in PoW although there can be similar collusion by miners, but they would still need to expend energy to build the hashes again. In PBFT there is no cost.  
> **username_4**: No that's not how it works. Either those 3 try to do it by pretending a previous state transition (the one that included the transaction?) never happens, and reverting to an earlier version of history. This is in _violation_ of the protocol, and detectable - the 4th node will treat it as malicious and ignore those messages or something. The alternative is that they sign an update that brings the state back to what it was before the transaction (without pretending the history never happened). This is likely not allowed either - it's similar to a Bitcoin where everyone trust miners.  
> **username_4**: Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/102762/discussion-between-username_4-username_4-and-username_3).  
> **username_0**: What I understand from discussion is that we can use 'voting' to cancel a transaction, maybe this is the reason why @username_3 calls it a "but a slow and expensive database". This is not logical in case of public blockchain because there can be many nodes. The other solution is to use a private blockchain and once we settle down with the transactions we can transfer them to public blockchain. This would help to ease the cost factor also. This is what I read in an article.  However real-world solution required.  
> **username_0**: What are validators? Never heard about this term in the context of blockchain. Please provide some link.  

---

