Repository navigation
Cuts down serialization logic - #38
Conversation
deeb050 to
ced96b2
Compare
|
ced96b2 to
7da5c99
Compare
One of the things I have in my notes is that we wanted to overhaul how scripts worked to begin with. When you say "handle scripts a bit better", are you meaning with respect to performance? I believe that the data carrying opcodes are always less than 520 bytes long which is limited by protocol level consensus stuff. In addition to that we rarely manipulate these things except to send them to cryptographic functions which generally require ByteArrayAccess instances. A cursory search shows me that ShortByteStrings don't actually have a ByteArrayAccess instance but I can't tell why. It seems like they should be able to.
I think we can defer this if we do it at all.
I don't have an issue with this. |
|
Scripts. There are some tweaks that we can make to the representation in order to make serialization a bit more performant. However, since we do plan to rework that quite a lot over the next few months, we should not sweat any more changes now. API. It would be nice to export direct serialization functions for the most important types. That helps downstream users (potentially most if we get it right) avoid depending on Witness stack. I'll go ahead and covert this to |
|
wrt Scripts and API we don't need to tie that to this PR. So I'd say merge after the Witness stack change. |
|
Unfortunately, changing the type of |
7da5c99 to
c969561
Compare
- Regularize qualifications
c969561 to
49b948c
Compare
This PR removes the dependencies on
bytesandcereal. Microbenchmarks show thatbinaryis a little faster for encoding and decoding thancereal. Moreover, serializing to lazyByteStringis more composable.Closes #2
Closes #20