This is the error message I get if I try to use whatsonchain to broadcast via their GUI - so I think that means their node still has the default 100kb limit in place for datacarriersize=100000
But even beyond that... if I broadcast via mattercloud, it is relayed okay (Atilla kindly raised the limit to 3MB now)(7025785c8955db545c605693557bcd7ac951fe5c18f15b51fc2bff84ce69ba1f)... but will not appear on whatsonchain while unconfirmed. Nor will it show after 1 confirmation... maybe it will show later on (after a lone wolf miner includes it...) - I don't know.
So I am just putting this here to document the current state of things on the 'data carrier transaction' front.
It would make a big difference in particular for this bitsv library to have a larger cap because mattercloud is throttling number of requests per second and so bcat type data uploads become unfeasible without a paid subscription / api key. (So the first thing I think we can do to address this is to add whatsonchain to our list of apis - which I bet doesn't throttle to the same extent)
OP_PUSHDATA within the executed script would go up to 100MB I believe. But there is not currently a widely adopted standard for 3rd parties to parse this etc.... or how exactly to imbed the payload... and I don't much feel like being on the 'bleeding edge' of it and having to change later.
This is the error message I get if I try to use whatsonchain to broadcast via their GUI - so I think that means their node still has the default 100kb limit in place for
datacarriersize=100000
But even beyond that... if I broadcast via mattercloud, it is relayed okay (Atilla kindly raised the limit to 3MB now)(
7025785c8955db545c605693557bcd7ac951fe5c18f15b51fc2bff84ce69ba1f
)... but will not appear on whatsonchain while unconfirmed. Nor will it show after 1 confirmation... maybe it will show later on (after a lone wolf miner includes it...) - I don't know.So I am just putting this here to document the current state of things on the 'data carrier transaction' front.
It would make a big difference in particular for this bitsv library to have a larger cap because mattercloud is throttling number of requests per second and so
bcat
type data uploads become unfeasible without a paid subscription / api key. (So the first thing I think we can do to address this is to add whatsonchain to our list of apis - which I bet doesn't throttle to the same extent)OP_PUSHDATA within the executed script would go up to 100MB I believe. But there is not currently a widely adopted standard for 3rd parties to parse this etc.... or how exactly to imbed the payload... and I don't much feel like being on the 'bleeding edge' of it and having to change later.