added boilerplate code for multihash

[dong77]

No description provided.

[Brechtpd]

Doing bytesToBytes32 like this will be significantly faster (should reduce gas by about ~7500 for every call). Will make a PR if you want.

function bytesToBytes32(
        bytes b,
        uint offset
        )
        public
        pure
        returns (bytes32 out)
    {
        require(b.length >= offset + 32);
        bytes32 temp;
        assembly {
            temp := mload(add(add(b, 0x20), offset))
        }
        return temp;
    }

[dong77]

I also see similar code on Github, please help us improve the existing code. A PR will be more than welcomed.

…

On Apr 22, 2018, at 07:23, Brechtpd ***@***.*** ***@***.***>> wrote: Doing bytesToBytes32 like this will be significantly faster (shuld reduce gas by about ~8000, but more testing is needed). Will make a PR if you want. function bytesToBytes32Fast( bytes b, uint offset ) public pure returns (bytes32 out) { require(b.length >= offset + 32); bytes32 temp; assembly { temp := mload(add(add(b, 0x20), offset)) } return temp; } — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#320 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABoYBwPcMDrk70D8u20RhY2WSOvwtQLIks5trGgjgaJpZM4Ter2i>.

[Brechtpd]

See #321

[Hephyrius]

I feel like encoding the data as a bytes array would be a bit clunky and would waste a bit too much memory as an overhead, I do have an idea in mind but I'm unsure if Daniel would like it.

What I propose is:
bytes32[] similar to the BatchTransfer bytes32[]. The very first element of the bytes32[] would be made up of all the V (uint8) values. Each byte of the bytes32 would be mapped to each order in a manner similar to the bit mapping used in feeselection.

Once Tests are working for 1.6 , I will test the idea out and see if it is viable.

Edit:
I will test the idea out on code as is, I think it would be easy to adapt it to 1.6 when that branch is ready. V, R and S are relatively untouched in 1.6 by the looks of it. I will update once I know if this is worthwhile.

[Brechtpd]

@Hephyrius If I'm interpreting the code correctly, the idea seems to be that the code would support multiple ways of signing without changing the API, hence an opaque array of bytes that contains an ID for the algorithm that should be used for the verification. This way any data can be send for the verification as is needed for the chosen algorithm. Using anything else than a simple byte array (or something equivalent) would limit the extensibility.

[Hephyrius]

This is where the suggestion of the bytes32 being used as the V values could be explored further, say having the first byte of the first bytes32 item be the algorithm selected followed by the non-32byte encoded data for that sig, I think a bytes array is way too expensive and wasteful for most use cases, especially when the bytes array will itse;f form part of another array.

[dong77]

the1.6 branch is still in its very early stage. The general idea is to support https://github.com/multiformats/multihash a bytearray signature scheme that is self-descriptive. Sent from my iPhone

…

On Apr 22, 2018, at 12:49 PM, Harnick Khera ***@***.***> wrote: I feel like encoding the data as a bytes array would be a bit clunky and would waste a bit too much memory as an overhead, I do have an idea in mind but I'm unsure if Daniel would like it. What I propose is: bytes32[] similar to the BatchTransfer bytes32[]. The very first element of the bytes32[] would be made up of all the V (uint8) values. Each byte of the bytes32 would be mapped to each order in a manner similar to the bit mapping used in feeselection. Once Tests are working for 1.6 and this, I will test the idea out and see if it holds water. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[dong77]

I need to do more testing to compare different options. My understanding (may be wrong) is that ‘bytes’ is cheaper than ‘byte[]’ which is basically ‘byte1[]’, and ‘byte[]’ in our case is more suitable than ‘byte32[]’ as some signature may be 33 bytes so ‘byte[]’ is going to save 31 bytes for us.

…

Sent from my iPhone

On Apr 22, 2018, at 3:00 PM, Harnick Khera ***@***.***> wrote: This is where the suggestion of the bytes32 being used as the V values could be explored further, say having the first byte of the first bytes32 item be the algorithm selected followed by the non-32byte encoded data for that sig, I think a bytes array is way too expensive and wasteful for most use cases. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Brechtpd]

That's correct Daniel. From the solidity documentation:

Variables of type bytes and string are special arrays. A bytes is similar to byte[], but it is packed tightly in calldata. string is equal to bytes but does not allow length or index access (for now).

So bytes should always be preferred over byte[] because it is cheaper.