You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently wallet.Sig is defined as a variable size byte array in the abstract wallet package. However, the length of the signature depends upon the signature scheme that we use, which in-turn depends upon the wallet backend we use. Hence, in order to Encode/Decode a wallet.Sig, we directly use the wallet.Sig.Encode / wallet.Backend.DecodeSig` functions.
The problem is that, these Encode/DecodeSig functions do two different things:
1. Convert the blockchain specific concrete data to/from binary format (byte array).
2. Write/Read the data in binary format to/from the wire.
Proposal
As we did for Address, Action, Data and other types (see #257), we can change the definition of wallet.Sig to binary.Unmarshaler and binary.Marshaler. Then
The wallet backend can implement the MarshalBinary, UnmarshalBinary functions. that convert these types to/from binary format.
These type can then be directly decoded using perunio.(En|De)code functions.
Another point to be noted
This will also, remove the usage of perunio package in the channel and wallet packages in backend/ethereum. Using perunio package in these places is a concern because, perunio will now be treated as a specific implementation of the wire protocol and these packages should not directly depend on a specific implementation of wire protocol. Also, since we have introduced (Un)marshalBinary type of each of the abstract types like Action, Address, Data, App (see #257) and Sig (this issue), these functions can be used to convert these types to/from their binary representation.
The text was updated successfully, but these errors were encountered:
Location
[wallet]
Problem
Currently
wallet.Sig
is defined as a variable size byte array in the abstractwallet
package. However, the length of the signature depends upon the signature scheme that we use, which in-turn depends upon the wallet backend we use. Hence, in order toEncode/Decode
awallet.Sig
, we directly use thewallet.Sig.Encode
/ wallet.Backend.DecodeSig` functions.The problem is that, these
Encode/DecodeSig
functions do two different things:Proposal
As we did for
Address
,Action
,Data
and other types (see #257), we can change the definition ofwallet.Sig
tobinary.Unmarshaler
andbinary.Marshaler
. ThenMarshalBinary
,UnmarshalBinary
functions. that convert these types to/from binary format.perunio.(En|De)code
functions.Another point to be noted
This will also, remove the usage of
perunio
package in thechannel
andwallet
packages inbackend/ethereum
. Usingperunio
package in these places is a concern because,perunio
will now be treated as a specific implementation of the wire protocol and these packages should not directly depend on a specific implementation ofwire
protocol. Also, since we have introduced(Un)marshalBinary
type of each of the abstract types likeAction
,Address
,Data
,App
(see #257) andSig
(this issue), these functions can be used to convert these types to/from their binary representation.The text was updated successfully, but these errors were encountered: