Neo: Update policy - Add maximum witness size (in bytes)

[lock9]

This is needed for #840. It limits the size of the witness that can be used in the verification script.

[erikzhang]

I think this can be a constant.

[shargon]

I think the same

[lock9]

What would be the impact if we have to change this? Are you guys sure this won't change in the future? I think it would be a good practice to have this in the policy

[erikzhang]

I don't think it will be modified often. This is a relatively stable limit value.

[shargon]

In fact, there is a limit now
https://github.com/neo-project/neo/blob/53f7d022afba7b1dfce5a437f8bc11557423a7fb/neo/Network/P2P/Payloads/Witness.cs#L31-L32

We should reduce it to 512 or 1024?

[igormcoelho]

I agree @shargon. Regarding value, we need to define max usage reasonable to offer for free.
in fact, its not free, right?
we are paying for size and computation as network fee now...

We are still discussing fee system I think, to avoid failed verifications to consume time from p2p edge.
we can put max size here, but without blocking loops, a max size is pointless.

We can follow "neo segwit" and do not store lon term witnesses, so max size is also pointless.

What is "reasonable" here? How many CN Neo3 expects to have validating blocks? Seven? So we max it to multisig 7/7 (to allow storing all sigs if wanted), in both invocation and verification. If CN increases, this increases automatically. This size will cover 99.9% of all existing applications, the rest can just be deployed.

[lock9]

I understand that this value is not changed often, but what is the impact if we need this to change? Isn't this going to cause a "large mess"?

[shargon]

I think that 14/14 (or lower) won't need to be changed in the future, as igor said, the rest can be deployed

[igormcoelho]

@lock9 this won't affect future stuff, because it only checks during verification. Once it's on block, don't need to reverify (so we can shorten or increase this).

[shargon]

but is deserialized with the block, so it will affect if we decrease this value in the future

[igormcoelho]

But we don't need to revalidate old tx, do we? Best thing is put this together with other network policies... so we definitely avoid this problem (it can increase/reduce, basis on storage).

[lock9]

@igormcoelho so we should add this to the network policy? If we add this to the policy, we can see what was the value in a particular date and time, making it easier to change later.

[igormcoelho]

I mean the PolicyContract (native one)... it will have the whole decisions recorded on chain itself, regarding network policy over time.

[shargon]

not in TX igor, but if you receive a block, you will deserialize it and you could obtain a FormatException if you decrease the value, if you increase it, there are no problem

[shargon]

But we have a lot of values with the same behavior, max entries for arrays (attributes, cosigners, etc..)

[igormcoelho]

But really, the only reason to change this, is noticing huge spam attacks on border...

14/14 on invocation and verfication, allow for approximately:
invocation => 14 x 64 bytes (signatures) = 896 bytes
verification => 14 x 33 bytes (pubkeys) = 462 bytes
plus small stuff, we have around 1500 bytes maximum per witness (which is A LOT in my opinion...)

If some devil soul tries to use expensive stuff, and fault, this is an opportunity for:
1500 / 5 bytes (each syscall in compressed format) = 300 checksig

each checksig takes few microseconds, but 300 may take 0,1ms or more (we need to calculate this). If this "good" soul repeats several tx like this, with difference nonce, it may take considerable amount of time from network edge... with only solution by blacklisting the ip (in my opinion).

If we also count-limit the expensive stuff on verification, let's say, by 14 operations... multisig 14/14 still works, and damage is pretty lowered. Someone may try to vary other expensive stuff, like hashing, etc, but if all of these remain inside same "quota", it will be pretty hard to attack with useless verifications.

[shargon]

Yes, it's a lot of

[shargon]

We can decrease it to 10/10, it will be safe if we want to increase it in the future

[igormcoelho]

10/10 may give us around 1000 bytes, I think so. Still 200 checksig, but much better. Expensive op counting may help too, but this is only important on borders. "Inside network", we can be very strict, if someone routes bad tx via p2p it should be blacklisted immediately (at least temporarily).

[shargon]

@igormcoelho feel free to change my PR with your desired values

[igormcoelho]

is there a PR? Found it: https://github.com/neo-project/neo/pull/1020

[igormcoelho]

@shargon we should definitely adopt a Neo SegWit design now: https://github.com/neo-project/neo/issues/1029

We only need to deny access for VerificationScript on interops.. (invocation is already denied on neo2 due to non-deterministic/maleable nature). So, after a few thousand blocks, we can provide shorter blocks and tx, completely without witnesses. In this sense, this size here is just an _instantaneous_ protection against p2p network edge.