0.9.0 Release

[ghost]

Todo:

• Update README.md

Anything else that we should do before then?

[AustEcon]

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 ^^.

[ghost]

I like this, agreed on all counts about the logic and polyglot.

Not sure if you've heard the acronym before, but KISS :).

[AustEcon]

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...

[ghost]

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?

[AustEcon]

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.

[ghost]

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.

[AustEcon]

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...

[ghost]

No problem in that case. Sounds good with me!