package xaya.proto

Get desktop application:
View/edit binary Protocol Buffers messages

* A message on the off-chain broadcast channel.

• optional bytes reinit = 1

  * The channel reinit ID this corresponds to.

• optional StateProof proof = 2

  * The state proof for the move that this represents.

* Metadata for a game channel.

• repeated ChannelParticipant participants = 1

  * The participants of the channel. The order matters.

• optional bytes reinit = 2

  * Identifier for the current "reinitialisation" of the channel. This should be a string of bytes that uniquely identifies the current state of the channel with respect to changes to metadata and other "significant" on-chain changes. For instance, if some participant joins the channel or leaves it, the reinitialisation should be updated. But also if at a later stage the channel again has the same set of participants as previously, it should probably have a different reinitialisation ID then. The exact format of this string and how it is updated may depend on the particular game and its rules for how metadata and participants can change. A good rule of thumb could be to set this to a hash based on the previous identifier and the txid that led to the update. Leaving this field unset is equivalent to an empty string. This is fine, e.g. for the very first state of a channel that was just created, as long as it will be set to something else later on when more changes happen.

• optional bytes custom = 3

  * Custom data that can be used in a game-specific way. For instance, this can hold e.g. the amount of money a game is played for, or some "parameters" that participants agreed upon when they started the channel.

* A participant in a game channel.

Used in: ChannelMetadata

• optional string name = 1

  * The Xaya p/ name of the participant (their main handle).

• optional string address = 2

  * The signing address configured for this channel.

* A message with similar structure to UnknownFieldTest, except that it has some more fields that will show up as unknown if a message of this type is parsed as UnknownFieldTest.

• optional int32 single_int = 1

  These fields match UnknownFieldTest.

• optional string single_str = 2

• optional ExtendedUnknownFieldTest single_msg = 3

• repeated int32 repeated_int = 4

• repeated string repeated_str = 5

• repeated ExtendedUnknownFieldTest repeated_msg = 6

• optional int32 unknown_int = 100

  These fields are in addition to what UnknownFieldTest has.

• optional ExtendedUnknownFieldTest unknown_msg = 101

• repeated int32 unknown_repeated_int = 102

• repeated ExtendedUnknownFieldTest unknown_repeated_msg = 103

* A piece of data with signatures of channel participants.

Used in: StateProof, StateTransition

• optional bytes data = 1

  * The data itself. This can encode different entities, like board states, moves or changes made to a channel in agreement.

• repeated bytes signatures = 2

  * The signatures made on the data by channel participants. Each signature stores raw bytes based on the underlying message signing/verification provider used. For instance, for signing based on Xaya Core's RPC interface with signmessage/verifymessage, the data is the base64-decoded signature string as raw binary. For the message, the channel's ID (uint256) is concatenated with the base64-encoded reinit ID, a nul byte, a string describing what the data is (e.g. "state"), another nul byte and finally the value of "data". All this is hashed with SHA-256 and then converted to a lower-case hex string, which is the "message" for "signmessage".

• optional string for_testing_version = 1000

  * This field is not used in production. It is a field that should never be set. We use it to test that function, and that it is called correctly as we need it.

* A full proof of some state of the game channel and that every participant agrees to it. This starts off some base state and then applies state transitions ending at the target state. This is valid as long as the transitions themselves are valid and all channel participants signed one of the intermediate states. If the initial state is the channel's reinitialisation state, then that is also good and no signatures are required (as long as the transitions themselves are signed by the proper players). It is also fine if someone signed only a state even if they were not the one who did a move, although that is unlikely to occur in practice. A state proof is always seen in context of a particular channel and its current reinitialisation (i.e. these are not part of the explicit state proof itself). This is enforced since that data is part of the signatures made, so that a state proof moved to a different channel or reinit of the same channel is not valid anymore. Note that there are possible efficiency-improvements to the format and rules of such a state proof. For instance, it would be enough if for each player, the *last* state resulting from a move of them is signed. If, for example, some player makes three moves after each other for some reason, then only the last state actually needs a signature and the signatures for "intermediate" states can be left out. For now, this is not implemented, though.

Used in: BroadcastMessage

• optional SignedData initial_state = 1

  * The initial state and potentially signatures on it.

• repeated StateTransition transitions = 2

  * A series of ordered state transitions on top of the initial state.

* A state transition: This is a move made by the current player together with the resulting state signed by that player. If we have a known current state, then this is the information we need to verify that this is the current player's move. Furthermore, by having a state signed by that player afterwards, we get a basis to build upon and proving that that player agreed at this point.

Used in: StateProof

• optional bytes move = 1

  * The player's move encoded in a game-specific format.

• optional SignedData new_state = 2

  * The resulting state and the player's signature.

* An example BoardMove proto for use in unit tests.

• optional string msg = 1

  * When applying this move, set current message to this value.

* An example BoardState proto for use in unit tests.

• optional string msg = 1

  * The current value of a "global message", set by moves.

• optional bool invalid = 2

  * If this is set to true, then we mark the proto as invalid.

• optional string only_compare_this = 3

  * If this field is set on two messages, then equality comparison is done by comparing this field only. This allows us to test both the default proto-comparison equality and a custom equality function.

* A message to test HasAnyUnknownFields. This message contains various fields, including repeated and non-repeated submessages. We also define another message below (ExtendedUnknownFieldTest), which has the same structure but additional fields. Those fields, when set, will become unknown fields in this message.

• optional int32 single_int = 1

• optional string single_str = 2

• optional UnknownFieldTest single_msg = 3

• repeated int32 repeated_int = 4

• repeated string repeated_str = 5

• repeated UnknownFieldTest repeated_msg = 6