[Discuss] How to ensure receiver get the tx history?

[boolafish]

Successful scenario

Alice give Bob a coin. Bob get all tx history of that coin. The tx is collected into Childchain's block. Bob can verify the tx is in block with his proof and the block hash on root chain.

Issue

How to ensure Bob get the tx history when the tx is collected into block? We kind of want to make sure the event is in the following order: Alice want to start a tx --> Bob get the tx history --> tx get collected into block.

Why we need to make sure Bob get the history? Without history, the only person can challenge would be Alice who already think she gave the coin away and do not have motivation to challenge.

So Bob needs to confirm?

One way is that Bob need to confirm/reply he get the tx history.
Alice -- send tx history & wait for reply --> Bob -- reply success --> Alice --> (Alice or Bob) put tx to child chain

But how if Bob lies here:
Alice -- send tx history & wait for reply --> Bob -- reply failed but actually success --> Alice

In this case, Alice cannot sent the coin to other people otherwise Bob can challenge it. The only thing Alice can do now is probably to withdraw. So if Bob wants the coin, he need to reveal his tx to challenge or need to give up on this.

This is still safe (?), but then every tx receiver now has the power to force sender to withdraw the coin.

Can Alice and Bob use centralized service to transfer the data?

If Alice and Bob only communicate through centralized channel, operator can possibly give the wrong message purposely. eg. Alice send the tx history to Bob through centralized service. The service provider did not transfer the data to Bob but tell Alice it was succeeded. Now Alice lose the motivation to challenge the coin and Bob has no data to challenge. The centralized service can send some invalid block to root chain and then withdraw.

(PS. The centralized service might need to be or need to cooperate with operator to have the permission to write block hash to root chain.)

Real life scenario

If it is a trade/business, receiver can always wait until things get confirmed and then provide the good.
However, in situations that Alice only want to transfer money to Bob, then the above issues become a problem

So what shall the implementation be?

Currently we are planning to implement the most naive solution which relies on operator to provide communication service (@zhouer, right?). However, there might be issue as described above. What's the most simple but yet safe implement solution? And is there other ways to ensure Bob get the tx history?

[mkchungs]

Hello @boolafish,

For Plasma chain to be usable, users should be able to send "coin history" request and retrieve a coin's full tx history whenever necessary. It's natural to assume that plasma operator would be the primary provider for such services. I would like to point out Bob's confirmation is probably not required. Instead, Bob will verify the tx is valid after it has been included in a SMT block.

When Alice decides to send Bob a coin, the entire process should contain two parts:

First part:
Alice retrieves a coin's full tx history -> sends a tx (with full coin history) to the operator -> operator checks the full tx history and include it in the block if valid.

Second part:

• In normal success case, i.e Alice and Operator are honest. Operator will include the valid tx in next available block. Either Alice/or communication provider cam then notify Bob for receiving the coin. Bob should be able to retrieve the full coin tx history verify himself.
• In case Alice is malicious and Operator is incompetent/faulty, i.e. Alice submits an invalid tx and Operator processes it anyway. Then if Alice/operator tries to deceive Bob for receiving the coin, Bob should be able to provide counter-proof using full tx history and treats it as a non-payment.
• In case Alice is honest and Operator is unstable or even malicious, i.e. Alice submits a valid tx to operator but it's getting ignored somehow. Based on severity, Alice can either startExit, rebroadcast the tx, or sending a replaced tx and making herself the new recipient.

In normal situation, users can simply rely on operator(or communication provider) for providing coin's history before and after the transaction. To ensure that user like Bob can 100% retrieve coin's history even when operator is unreachable, one simple approach is publishing every SMT block to outside source like swarm, IPFS or other cloudstores. For example, you can modify the submitBlock(bytes32 blkRoot, uint blknum) to submitBlock(bytes32 blkRoot, bytes32 blkchunkhash, uint blknum), where the blkchunkhash is the swarm hash of the RLP-encoded block. This way, in situation where operator is withholding tx history, Bob can still retrieve all non-empty SMT blocks using the blkchunkhash at for each relevant blocknumber via secondary network and piece back the full history, albeit through "brute force". With this approach, you may gain the benefit of having third parties watching/checking the published block history: If designed with proper incentives, you can gain extra network security by allowing people to challenge operator for including malicious tx in the blocks.

Also with few changes, I think your approach should work just fine. See Below:
Normal Case:
Alice --> providing past tx history to Bob proving she's the current owner --> Bob -- reply "Yes. Alice, you are the true owner" --> Alice -- send the full tx to operator --> operator includes the tx --> Alice send Bob the last tx. --> Bob verify the tx himself from the block
Bob/Alice trying to lies:
Alice --> providing past tx history to Bob proving she's the current owner --> Bob -- reply "No. Alice, you fraudster" --> No tx between them. Operator do nothing

[boolafish]

Thanks @mkchungs !

It's natural to assume that plasma operator would be the primary provider for such services.

I agree, and if even with a centralized operator providing all the service and the system can still be safe for client, then that's where plasma really shines IMHO.

To ensure that user like Bob can 100% retrieve coin's history even when operator is unreachable, one simple approach is publishing every SMT block to outside source like swarm, IPFS or other cloudstores.

I totally agree this is a great solution. However we want to see if centralized service can still do the work (as for easier implementation :p). I would like to take this solution as later step/way to solve the issue. Note that some service might actually want the tx data not to be totally open/transparent by default for privacy as well. So this approach might limit the use case as well. (Though I agree it can increase the security level)

Also with few changes, I think your approach should work just fine

Thanks for this! I think your flow is better! Note that if Alice & Bob is communicating with the channel provided by operator, operator can still lie. However, adding one more flow handling should solve this:

(PS. assume all communication is transferred by operator's channel)
Alice --> providing past tx history to Bob proving she's the current owner --> Bob -- reply "Yes. Alice, you are the true owner" --> Alice -- send the full tx to operator --> operator includes the tx --> Alice send Bob the last tx. --> Operator block the communication in between and did not reply to Alice --> Alice should start exit to protect herself.

[InfiniteIntel]

When both Alice and Bob are present, a third is formed. If both are not present (in agreement), the third is not formed. Formation of the third is proof of action. Can use a time limited escrow/firing window (15 seconds)

(A) "Hi"---> <--- "Hi" (A1)
(B) "Let's transact" ---> <--- "Yes" (B1)
(C) "15 second escrow" ---> <--- "10 second accept" (C1)

Just as in plasma physics, a 4 point pyramid, forms a new fifth point in the center of a higher energy.