By default, disable creation of transactions when delegate participation less than 50%

[theoreticalbts]

When delegate participation is below 50%, the user is in danger of being on a minority fork and having transactions reverted. In this case, by default the client shouldn't allow the user to create transactions until delegate participation rises.

The thinking is that, if participation is less than 50%, they could be on a minority fork and any transactions are in danger of being reverted. Having transactions reverted is more inconvenient and more likely to lead to losses than simply having transactions rejected immediately.

N.B., delegates should still be able to sign blocks when the network has less than 50% participation, because otherwise the network would die as soon as it dropped below 50% and be quite difficult to restart.

Finally we should advise merchants and exchanges to delay crediting deposits until delegate participation is above 50%. Otherwise an evil person could send BTS to an exchange for cryptocurrency, buy something else (BTC) and then get their BTS back when the fork is resolved in the other direction, leaving the exchange with a loss.

[arhag]

Yes, this would be great. But you should still allow the client to make voting transactions (transactions that move the balance to themselves in order to just change the delegates they vote for) even when delegate participation is below 50%.

It would also be nice if the client showed for recent transactions the number of unique active delegates that have built a signed block on top of the block in which the transaction in question was included. This way a user could know when a transfer has 51 delegate confirmations (typically taking only 8 minutes to reach but could be much longer in the case of network problems) and be very confident that a transfer to them is not likely to become invalid if it was on a minority fork and needs to transition over to the correct fork. This is of course only an indicator of the unlikelihood of a fork happening and there are exceptions such as the case when delegates downgraded from v0.4.25 even after several hours of majority delegate approved rounds.

Also, regarding your comments about advising exchanges to delay crediting deposits, I want to get clarification about what you are saying. It is not so much about waiting until delegate participation is above 50% before instantly crediting a deposit transaction, but rather waiting long enough until at least 50% of active delegates have approved of the deposit transaction, correct? In other words, exchanges would typically have an 8 minute delay on deposits to get the necessary 51 delegate confirmations before allowing the user to make trades with the deposited BTS. Otherwise, it is possible that there could be 100% delegate participation in the previous round, but the first few delegates might be on a minority fork and include the deposit transaction in say the first 4 blocks of the next round, and all the other 97 delegates remaining in the round could end up ignoring those 4 blocks and instead add blocks that do not include the deposit transaction (say because it was not valid) on another fork (the "correct" fork due to majority consensus). If the exchange makes deposits immediately available for trading, the user could have 8 minutes to trade the BTS for BTC and withdraw it into their wallet before the exchange realizes the deposit transaction was on the minority fork.

Finally, I was thinking about an idea to possibly reduce this 8 minute delay. Even though all the delegates should typically validate a given block N submitted at time T in less than 10 seconds after the block was submitted, the delegate signing block N + M has to wait until time T + M*(10 seconds) to provide the signature the adds their approval to all transactions in the blocks that came before it. This is what leads to the minimum 8 minute delay for getting more than 50% of delegates to approve of a transaction before the receiver can feel confident it does not exist on a minority fork. What if an active delegate was allowed to optionally submit a signature approving of a recent block before their designated time slot, sort of like they are allowed to optionally provide price feeds. They wouldn't be producing these blocks, the delegate producing the block could simply include their signatures into the block (only a maximum of 100 such signatures could ever be included per block since the block producer would only include at most one signature from each active delegate other than itself, which would be the signature by the delegate for the most recent block that delegate has signed that wasn't already included in a previous block in the chain). If all delegates submit a signature of the most recent block that they validated to the network (or at least to the private active delegate network), the user's clients could know a transaction is part of the majority-consensus chain only 10-30 seconds after the transaction was submitted.

[theoreticalbts]

We don't want to bloat every block with a bunch of extra delegate sigs. 8 minutes is extremely fast for exchanges who want rock solid confirmation.

[arhag]

We don't want to bloat every block with a bunch of extra delegate sigs. 8 minutes is extremely fast for exchanges who want rock solid confirmation.

Maybe so. But is it good enough for a merchant? I understand the probability of such a fork happening is very low that it can be a negligible cost to the merchant. But the fixed cost of 100 extra signatures per block is also pretty negligible if you consider an average transaction throughput of say 100 tx/s in the future.

Then again, there is no real need for these signatures to be included as part of the block (and therefore need to be stored as part of the official blockchain forever). The delegates can simply broadcast these ephemeral signatures to the network and let the clients download and process them. All previously collected signatures of this type can be completely ignored/erased after a full round (typically every 16 minutes). We get the same fast 10-30 second confirmation time by the majority of delegates (other than in the unusual forking or network disruption situations) without the blockchain/database bloat.