Skip to content

inability to handle pre-generated 'false return' metadata from other libraries #52

@AustEcon

Description

@AustEcon

The my_key.send([], message=data, custom_pushdata=True) works by allowing the user to pre-generate metadata with the functions contained within op_return.py (which generates a bytearray with the correct op_pushdata op codes for as many elements as there are). But it is the send() that adds the OP_RETURN to the beginning of these bytes. This has caused some users issues when they pregenerate these bytes using other libraries (which have already added the OP_RETURN.

They have gotten it to work by simply removing this first OP_RETURN byte to let bitsv add it but this is a hack and I think it is great to see people using bitsv in combination with other libraries and would like to support it.

I wonder if we cannot simply make the op_return.py functions for generating the bytes fall into line with how these other libraries are doing things.

In hindsight, it actually makes more sense to do it this way so that people can pre-generate any kind of crazy, complicated locking scripts and append them into a transaction as they see fit.

I don't know the best way to implement this though - and haven't given it much thought...

  • I wonder if "custom_pushdata" could be changed to something more like "custom_output=True" and maybe change message --> custom_output(s) (accepting a list of them would future-proof us for a future with multiple custom outputs) ...

We could keep the message and custom_pushdata kwargs for backwards compatibility but deprecate these after a few releases maybe?

Open to suggestions...

I think I can make the send_op_return() work nicely without anyone even noticing that it's changed under the hood... but the send() is like the "low level" function that does everything if you really need it to and so would be nice to have it as intuitive as possible...

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions