Who should publish the contract on chain?

[da-kami]

In our current model the two parties that set up the CFD (aka Mr. maker as broker and Mr. taker as trader) both construct the contract transaction together. Eventually both of them end up with a finalized CFD contract that could be published on the Bitcoin blockchain. (unless my understanding is wrong)

Based on the decision who should publish I think we should only enable that one actor to do so!
Otherwise we run into the weird scenario that both have to ensure that the other party acted.
Theoretically we could also say: Both try to publish it and one publication always fails - but that is weird and might lead to one party stalling... I don't think that is good design.

So, I think we should agree on who is expected to publish the contract.
For me it is not totally clear who is expected to publish the contract.

Why the taker?
Because the taker wants to trade and wants to be in charge or publishing the transaction and the costs.

Why the maker?
Because the maker wants to enable the taker to trade, and the maker will likely charge fees for publishing the transaction. the fees could cover (and more) the costs of publishing the transaction.

[DeliciousHair]

I would say the maker should always publish. Fees aside, the logistics of how I see this working is:

maker makes offer, publishes to platform
taker provisionally accepts offer, possibly with modified terms
maker accepts the counteroffer from taker (maybe this iterates multiple times, doesn't matter) but ultimately it's up to maker to seal the deal, so to speak.

[da-kami]

At the moment the maker is the platform and there is no negotiation over the terms of the contract. That does not really make a difference though (it basically just simplifies things).

The argument that the maker wants to be in charge of sealing the deal makes sense. This goes towards our old rule: The party that offers should also be the party that enforces that the deal happens. Good enough for me for now.

[da-kami]

Follow up question based on the assumption that the maker publishes:

Is it possible to design the protocol in a way, so that the maker is the only only one able to publish, or would both parties always have to have the complete knowledge?

The taker has to be able to monitor for the publication; and both parties sign the transaction, so I guess the taker always has to have the knowledge of the complete finalized CFD as well. Correct?
(What would be the behaviour of the taker in case signing is finalized but the maker does not publish?)

[DeliciousHair]

Yeah, both parties would have the complete finalized CFD else it would be a bit... strange?

Assuming by publish you mean putting the transaction on the blockchain, how would it be possible to get both signatures and not publish? Just asking. If that happens though, I would guess there would be a timeout and the CFD would be destroyed?

[da-kami]

Assuming by publish you mean putting the transaction on the blockchain, how would it be possible to get both signatures and not publish? Just asking. If that happens though, I would guess there would be a timeout and the CFD would be destroyed?

I don't think that is technically possible. Once both parties have the signed transactions both will be able to publish them. Since there is no absolute timelocks both parties could wait with publishing the contract. That is why I am asking.
Or am I incorrect and there is an absolute point in time in the contract? @luckysori @bonomat

[bonomat]

Our lock transaction requires two inputs, one from the maker and one from the `taker, and each party needs to sign their respective inputs.

This means, one party could sign first and send over their signature to the other party who does not return the favor.

I don't see an attack vector here. Highlevel this is what happens:

1. exchange a bunch of keys and inputs for tx_lock
2. sign tx_cets, tx_refund, tx_lock and send to the other party
3. only afterwards sign tx_lock and send over to the other party

Imho we can design it in a way that the taker signs tx_lock first and sends it over to the maker who then signs and publishes it.

It feels a bit weird because it adds some sort of trust to the maker to actually do so but I don't think it's an issue.

[da-kami]

If always try to publish there is no problem and no "attack vector" - it's more a "stalling" problem.
If the maker is supposed to publish tx_lock (and we don't implement trying to publish on the taker side) then the taker might be in a scenario where he has to spend the outputs that were used for tx_lock in case the maker does not publish as supposed.

But that adds unnecessary complexity (monitoring for the taker to ensure that the maker did not publish yet, finding another trading partner to spend the output, ...), so in conclusion I would say both should try to publish, because that solves all these problems. They both have an incentive so let them both try.
We can potentially change that later if we feel it is not what we want.

[Rijaspb]

Visit us https://www.rijasexports.com/

[bonomat]

My opinion:

• both should publish

It should be a recognizable error message if the tx_lock is either in the mempool or if ti was already included in a block. We should be able to detect that and prevent stalling.

Why?

• the taker took the offer and wants to execute the contract. If he cannot publish the tx, he has to trust that the maker follows through with it and does not bail out
• the maker came up with the contract and has some sort of business case, he probably also has multiple takers and needs to manage utxos, hence, he has an incentive to publish this tx asap. He also does not want to give the taker the chance to bail out.

// edit//
I interpreted your question as who should publish tx_lock but it's actually the same case for tx_commit/tx_refund and for publishing the cets. Both parties should be able to publish said transactions, hence, I double down on my opinion: both parties should be able to publish and publish tx_lock.