Origin: Finalization Window

[micahalcorn]

I'm either a bit confused or concerned about how the finalization window works. 🤔

If I understand correctly, the buyer (or DApp via a default) prescribes an absolute timestamp for the deadline, by which point the buyer is required to either initiate a dispute or forfeit the opportunity to dispute (either by finalizing or letting the seller finalize). In contrast, our previous transaction flow provided a similar window, but it was 21 days _relative to when the seller fulfilled her obligation_.

My concern is that, since a buyer's performance requirement is not tied to a seller's performance requirement, the buyer is at a disadvantage. For example, a seller could accept an offer and then drag out the fulfillment until the eleventh hour when the buyer doesn't have enough time to make a decision about whether or not to initiate a dispute. I suppose that a solution might be for a buyer to prescribe additional deadlines that fall within the finalization window, which are not baked into the contract but can be self-enforced by threatening a dispute. But buyers may not know that they should or may be reluctant to do this. I'm also assuming that there is some cost associated with initiating a dispute (whether monetary or otherwise, and recoverable or not).

Is there something I'm missing about how the new transaction flow works? @nick @tyleryasaka @DanielVF

[DanielVF]

It does seem that the current marketplace contracts are pretty much dispute in time or lose your money.

@nick can say more - I'm not sure how he was envisioning the finalization working.

[nick]

I think there could be a situation where the seller 'runs down the clock' and hopes the buyer does not start a dispute before the finalization window expires. I have heard of Ebay scams where the seller does exactly that: waits until the day before the buyer can no longer dispute the sale then sends a valid tracking number so the buyer thinks the item is on the way, only for the buyer to not receive their goods and lose their money.

For our purposes I think we can solve this by making the dispute policy clear to both buyer and seller and notifying the buyer to take action if deadlines have not been met. For example:

• Buyer makes an offer on a laptop for sale.
• Specifies 3 day shipping with a 14 day finalization window.
• Specifies if goods have not been received within 7 days, a dispute will be filed.
• After 7 days and if buyer has not already finalized, buyer receives reminder to initiate dispute. After 10 days of no action from buyer they get a warning that there are no disputes or refunds after the 14 day window.

The current contract also incentivizes dapps to get the buyer to either finalize or dispute by only paying commission if they do so. So hopefully that'll be enough to incentivize the right behavior from all parties.

Another possibility is that we give the buyer an option to extend the finalization window on-chain - though I think this should be a one time action so they can't do it indefinitely. Not sure if we really need that though 🤔

[micahalcorn]

@franckc @matthewliu ☝️

[matthewliu]

I share similar concerns as @micahalcorn here. There's a problem with different "rolling" expiries depending on when the seller takes action after the buyer's offer. So in one transaction the seller may advance the flow immediately, and in a second the seller may be slow and wait 20 days. From the buyer's perspective I'm much more likely to expect consistent behavior AFTER the seller has taken the next step vs. remember when I created the offer. Is it way too much work to have the logic mirror the old logic with the new marketplace contract?

[nick]

I'll modify the contract to support a relative finalization window by assuming that any given timestamp < 1bn (about 30 years) should be added to the current timestamp. That way we can support both an absolute and relative finalization window.

On top of that, after talking with @wanderingstan last night I realized that instead of the finalization window passing meaning the seller can finalize (and receive their funds)... perhaps it should just mean that a seller can send the transaction to arbitration. It would then be up to the arbitrator to make a decision.

This would make it more difficult for a seller to 'scam' a buyer, but would also mean a seller cannot automatically receive their funds due to an unresponsive buyer without going to arbitration. Thoughts?

[cuongdo]

I like the "old" behavior that gave the buyer 21 days from the end of the seller's responsibilities to file a dispute.

That said, I'm having a hard time understanding the complete set of requirements. I think that this discussion could benefit from a meeting and/or a systematic enumeration of the different scenarios we can envision.

[nick]

A relative finalization window makes sense for some listing types, but not all. When selling my bike, I might want to specify a finalization time of '3 weeks after the seller accepts the offer'. But for a home share, it makes more sense to specify '3 days after checkout', especially if the booking is way in advance. The former would be a relative finalization window, while the latter would be absolute.

[matthewliu]

Sorry, still having a hard time understanding terminology.

Is this what you mean by relative vs. absolute?

relative - not dependent on my last action, but dependent on the follow-on action of the counterparty?

absolute - dependent on my last action, regardless of when the counterparty takes the next step?

[micahalcorn]

@matthewliu from my perspective, absolute means that the buyer (or DApp) sets an exact date for the end of the finalization window; i.e., Tue Aug 28 2018 15:00:00 GMT-0700 (Pacific Daylight Time). Relative means the date which occurs some number of [milli]seconds/hours/days after some other event. In practice, absolute is _one_ stored value (finalizes) and relative is a derived value using _two_ stored values (BUYER_PENDING event and 21 days).

[nick]

Yea that's the idea. The finalization variable is a timestamp (seconds since 1st Jan 1970) the buyer specifies when making an offer. I'm suggesting that if this value is < 1,000,000,000 then it be treated as 'number of seconds after buyer accepts offer' and otherwise be treated as the actual finalization time. That should let us support both use cases.

[micahalcorn]

As discussed with @nick today, we will leave the contract intact as updated with https://github.com/OriginProtocol/origin-js/pull/382 to support a relative finalization window. For now, we will set the finalization window to an arbitrarily high value (say, a year or more) and allow the seller to initiate a dispute if the buyer becomes unresponsive. This will allow us to use the previously-defined finalization window in the future without modifying the contract if we decide that we're comfortable with the risk of seller-abuse and we can't sufficiently trigger the buyers to return and finalize the transactions.

[micahalcorn]

Shortened the window here 😬