Block incoming transactions script for BEP12

[k1rill-fedoseev]

Changes

Transactions can send money to addresses, which are not inspected by some person/service. This script can provide a way of temporary blocking all incoming transactions for the particular address.

[abelliumnt]

What are the potential use cases for this script? Can you give some examples?

[k1rill-fedoseev]

For example, let's consider our case. We are making a crosschain bridge.

• There exists a TSS MultiSig binance account for processing token transfers.
• At some time, we may want to regenerate TSS keys for our account, this process takes some time, changing of keys results in the creation of a new account.
• During the regeneration process and after it, there should be a way of preventing users from sending tokens on unmaintained addresses (old account stops being considered as a valid one, nobody will handle new transfers on it).
• Locking all incoming transfers on the old account will solve this problem.

[abelliumnt]

As far as I know, the regeneration of TSS key will not change the address.

[k1rill-fedoseev]

Yes, it is possible to keep the same address. But our main goal is also to change the set of parties, so that previously generated tss partial keys won't work for the new account.

[akolotov]

As far as I know, the regeneration of TSS key will not change the address.

Could you provide more details how exactly this work?

From my perspective, as Kirill mentioned above an unexpected behaviour is possible in the case if regeneration of TSS keeps the same address. Let me explain on the example:

Imagine that there are 3 parties (A, B and C) in TSS with secrets a1, b1 and c1 on Epoch 0 as so 2 of them are enough to generate signature. The restored public key (address) from the signature is addr.

• Epoch 1: A and B regenerate the secrets to have TSS with a new party D: a2, b2 and d2. The public key (address) that can be restored from the signature generated with new secrets is addr again. So, now the state is:

  • A keeps two secrets a1 and a2
  • B keeps two secrets b1 and b2
  • D keeps one secret d2
  • C keeps one secret c1

• Epoch 2: A and D regenerate the secrets to have TSS with a new party E: a3, d3 and e3. The public key (address) that can be restored from the signature generated with new secrets is addr again. So, now the state is:

  • A keeps three secrets a1, a2 and a3
  • D keeps two secret d2 and d3
  • E keeps one secret e2
  • B keeps two secrets b1 and b2
  • C keeps one secret c1

Now, we see that B and C are not in the main group to generate a signature that will correspond to addr. But they both own secrets b1 and c1 from the epoch 0. So, they can use these secrets to generate a signature that will also correspond to addr.

Is this reasoning correct?

[akolotov]

The feature to block incoming transactions could be also useful for the following scenario:

There is an application that listen BNC transactions sent to an address and do something (e.g. it is a bridge between BNC and ETH). At some moment the application would like to temporarily stop the operations (e.g. a daily limit for operations reached). In this case the application could block incoming transactions and unblock them on the next day.

Also the application could block incoming transactions for maintenance operations: upgrade, shifting to another BNC address etc. Blocking of incoming transactions would allow to have more predictable user expectations in this case.

[brilliant-lx]

outdate, archive it.