0.9.0 Release
opened this issue · comments
Todo:
- Update README.md
Anything else that we should do before then?
I think I'd like to do a simple little fix to the TxOutput dataclass. Because otherwise you get an ugly error message when iterating over anything that is not a simple utf-8 OP_RETURN message...
I think I will keep it really simple and just add an if statement that goes:
- if utf-8 message --> decode
- else --> represent the whole OP_RETURN as raw bytes...
My current inclination on it is to make a design decision here about the scope of bitsv and rather than keep adding more and more... to build ontop of this in polyglot... and have a growing list of recognized OP_RETURN data types e.g.:
- B://
- BCAT://
etc.
and the various multimedia types within that... for downloading and decoding...
I plan to create a "download.py" file in polyglot as the counterpart to the current upload.py. In it there will be a "Download" class for all of this stuff ^^.
I like this, agreed on all counts about the logic and polyglot.
Not sure if you've heard the acronym before, but KISS :).
Actually, there would be no way to know how the op_return is encoded so I'll leave that responsibility to the user and probably just make it hex.
Could maybe have an added luxury of parsing the pushdata op_codes and returning the hex bytes as a separated list... I think that would be more noob friendly...
I think I would send it as raw bytes. Converting to hex and back is slower and odds are that's what they'd be doing. I think someone working with RETURN is going to have to know what they're doing to some extent. polyglot can make it easy, though :).
Separate list might make sense, are you saying if there's multiple OP_RETURNs?
The api gives hex though so might be faster? But I have no strong preference. If it is faster though... the added benefit is that noobs can start to learn rapidly what parts of a rawtx are what
I mean a list of pushdata parts within the op_return... to save people that headache...
Because it's not that easy to figure out how to unpack... so we have an opportunity to tackle it for everyone so they don't have to.
Hmm, I see. In that case maybe the string hex is fine. Although then we need to expect all APIs to return it in that format, or convert it if it's not.
Yeah. But in my experience so far. All API's return op return data as hex.
I realize it's not the most efficient serialization format but that's how it is. I don't really know why hex was chosen instead of bytes...
No problem in that case. Sounds good with me!