Strange behavior with register update.

[winnnnnny]

Hello, sorry for disturbing you.

I have observed that update seems to fail under certain conditions.

a = sint(10)
b = sint(0)
# This meaningless update is necessary for triggering update failure. It can update with any value to trigger failure.
b.update(b)
# 'b' needs to update with a value from comparison to trigger update failure.
b.update(sint(11) > a)
# 'b' update with 0, but this update fails. If b update with a value from comparison, then the update succeeds.
b.update(0)
# If there is not an update, then the update above succeeds. In addition, this update needs to use the value from comparison.
a.update(a > 0)
# 'b' is 1 from 'sint(11) > a', so 'b.update(0)' fails.
print_ln('b: %s', b.reveal())

This strange behavior is hard to trigger with four strict requirements explained in the code.
Sorry for taking your precious time to look through the code.

The output is shown below.

Scripts/mascot.sh test
Running mp-spdz/Scripts/../mascot-party.x 0 test -pn 11681 -h localhost -N 2
Running mp-spdz/Scripts/../mascot-party.x 1 test -pn 11681 -h localhost -N 2
Using security parameter 40
b: 1
Significant amount of unused triples of SPDZ gfp. For more accurate benchmarks, consider reducing the batch size with --batch-size.
Note that some protocols have larger minimum batch sizes.
Significant amount of unused bits of SPDZ gfp. For more accurate benchmarks, consider reducing the batch size with --batch-size.
Note that some protocols have larger minimum batch sizes.
The following benchmarks are including preprocessing (offline phase).
Time = 0.864137 seconds 
Data sent = 39.0454 MB in ~851 rounds (party 0; use '-v' for more details)
Global data sent = 78.0907 MB (all parties)
This program might benefit from some protocol options.
Consider adding the following at the beginning of 'test.mpc':
        program.use_edabit(True)

Is this a bug or expected behavior?

Thanks!

[mkskeller]

Thank you for raising this. You should find that d1fefe1 fixes it.

[winnnnnny]

Thank you for repairing this!

[winnnnnny]

Sorry for disturbing you again, @mkskeller.
d1fefe1 seems to make a new bug.

a = sint(2)
b = sint(3)
c = a
# c is 2 here since I update it to 2
print_ln('c: %s', c.reveal())
a.update(b)
# c is 3, but I never update it.
print_ln('c: %s', c.reveal())

It seems that the update to 'a' also updated c, which is not expected behavior.

The output is shown below.

Scripts/mascot.sh test
Running mp-spdz/Scripts/../mascot-party.x 0 test -pn 19705 -h localhost -N 2
Running mp-spdz/Scripts/../mascot-party.x 1 test -pn 19705 -h localhost -N 2
Using security parameter 40
c: 2
c: 3
The following benchmarks are including preprocessing (offline phase).
Time = 0.00206792 seconds 
Data sent = 0.041532 MB in ~537 rounds (party 0; use '-v' for more details)
Global data sent = 0.083064 MB (all parties)

[mkskeller]

I don't consider this a bug because the semantics of assignment in Python is just creating another link to the same object, so you would expect c to be updated if a is. If you want a deep copy, you should use c = sint(a).

[winnnnnny]

Thank you for the suggestion! I will use a deep copy like that in the future.