Conflicting orders

There's a problem in the protocol when multiple orders are issued by the same user and he doesn't have enough balance to make them all. In this situation the reputed signers may confirm different set of orders (because they received them in a different order for example). Then there's no way they could reach a consensus on which orders they should support. They cannot confirm the other orders because the total orders they would confirm would exceed the user's balance. So all the orders would be left partially confirmed.

There are a few solutions to this problem:

1. We let these orders never confirm, and the user must cancel them to make new ones. In this case we must require 51% of the signers to confirm an order for it to become valid. But even so if a signer misbehaves and confirms all the orders, too many orders may get confirmed. If the confirmations are balanced, it may only take 1 signer to mess up the situation. We could solve this by requiring more than 51% but it's difficult to choose the right percentage.
2. We allow the signers to "unconfirm" an order. But they need a way to decide whether they should or not, to reach a consensus.
3. We make signers publish deposits on the blockchain, so that all the nodes can calculate the balance of each user and validate the orders themselves. Excessive orders would be handled by the blockchain consensus (nodes would reject orders that exceed the user's balance, and consensus would be reached by confirmation in the blocks). One could consider there's a privacy issue with this solution, but the deposit addresses are public anyway so the balance is already public.
4. We make signers publish the UTXO they would use to transfer the order funds when they confirm the order. That way they could confirm multiple conflicting orders by assigning them the same UTXO. The nodes would reject confirmations if the UTXO has already been used to confirm an order. But they would still accept a confirmation of another order if it's included in a block (and would discard the confirmation they accepted). The process is similar to the way double spend are handled. But it implies users can only make one order per UTXO.

I think 3 is the cleanest solution. It would also simplify the protocol because signers would not have to confirm the orders anymore. And users could easily know their own balance.

First, allow me to play the role of a hacker trying to use multiple orders using the same funds to get more proceeds. This will hopefully explain what I perceive the solution to be.

Let's say I have 1 Bitcoin on deposit. I want to trade my Bitcoin for NuBits, except my goal is to get twice as many NuBits as I should, by gaming the system with two orders sent simultaneously.

I place two orders to sell my 1 Bitcoin for 400 NuBits and broadcast them to the network simultaneously. The deposit address employs 8 of 15 multisig. The B&C protocol requires order validations from the number of required signers plus two backup signers. That's 10 of 15 signers in this case.

Let us suppose that 10 out of 15 signers receive order A first while 5 out of 15 signers receive order B first. All signers receive both orders eventually. The 10 signers publish order validations for order A while 5 signers publish order validations for order B. Both order A and order B get permanently stored in the blockchain. When the signers receive the second conflicting order, they check the blockchain and memory pool for use of the deposited funds, so they will not sign order validations for both orders in any case. Let's suppose shareholders have set the number of B&C confirmations required at 3. Once order A has three confirmations and at least 10 order validations also have 3 confirmations, order A is active and valid. Order B remains in the blockchain along with its 5 order validations, but never becomes active and valid, because it never receives 10 order validations.

Let us consider what would happen if order A were received first by 8 signers, while order B were received first by 7 signers. Order A gets 8 order validations while order B gets 7 order validations. While both orders get stored permanently in the blockchain, neither will ever become active and valid. Subsequent orders on the same deposit of 1 Bitcoin will also never receive order validations. The user would have to publish a cancel order message in order to have a chance of submitting a valid order later.

Perhaps the metaphor saying we will handle double orders the same way as double spends isn't helpful, because in the case of a double spend only one spend will make it on to the blockchain, while in our solution both orders appear permanently on the blockchain. However, because order validations are required to make an order valid, they won't both become valid.

That's the process I described in solution 1. The problems I mentioned still apply though:

If the deposit address is a 5 of 15 multisig (shareholders can decide that in the current protocol), then we can have 7 signers confirming order A and 7 signers confirming order B. Both orders would satisfy the "m+2 rule", so they would both be valid. I suggested an easy solution to that: "require 51% of the signers to confirm an order for it to become valid" (instead of "m+2").

But then there's this very rare situation where the 15th signer misbehaves and confirms both orders. Then both orders have been confirmed by 51% of the signers and they are both valid.

We may consider in this case that it's the signer's fault and that can be proven in the blockchain, and shareholder can figure out a solution.

I am in favour of adding a 51% rule in addition to keeping the m+2 rule.