search

blockcypher / explorer

Block explorer showcasing the BlockCypher APIs.
https://live.blockcypher.com
Apache License 2.0
1.09k stars 726 forks source link

Embed Data Improvements #153

Open mflaxman opened 9 years ago

mflaxman commented 9 years ago

From #150, moving to a new issue since this is separate from what #150 is about.

@matthieu writes:

I'd add somewhere there's a 40 bytes limit (so 80 hex chars or 40 ascii chars) no?

@acityinohio responds:

An error does show up if you attempt to submit something longer: "Data too long, the maximum length allowed by the bitcoin protocol is 40 characters." But agreed, even nicer glitz would include a character counter depending on type (e.g., updated interactively as you type: 0/80, 1/80, 2/80, etc. for hex, 0/40, 1/40, 2/40, etc. for ASCII)

That error message actually pings the blockcypher API and then if there's an error it returns that message to the block explorer user. I could've easily written my own, but my thinking is that the length might vary by chain (currently the API only supports btc and bcy testnet) so I wanted to just outsource that altogether. Do different chains support different lengths? Is the plan to add support for more chains?

My biggest issue was actually the hexadecimal vs string. I default to hex to avoid the case where someone accidentally embeds hex as a string. If you try to add a string as hex it will error (if the string has non-hex chars, which is very likely but not guaranteed). Does this seem like the right behavior?

mflaxman commented 9 years ago

Thanks to 52e31f22325f60dd129f7a215d96258da551ce68 this feature is now highlighted a bit more prominently in the block explorer.

acityinohio commented 9 years ago

Just took a look in the code; at the moment it's hardcoded to 40 bytes max, across all coins/chains...that may shift to 80 soon (once more bitcoin 0.11 nodes are in the wild, because they support 80 byte OP_RETURNS; dogecoin already supports 80 apparently and litecoin will eventually, and bcy testnet tracks btc). Consequently, I feel okay having some sort of max character view (40chars/80hex for now, 80chars/160hex eventually), even if you rely on the API to send back errors (which definitely makes sense).

Re: second issue, those defaults make sense to me, since hex chars are a subset of ASCII. Easier to error on first then ask for user action to change I think, even if most people want to default to strings. Between the two, I'd rather have the rare case of someone accidentally inserting string as hex, rather than hex as string (which I think is more frequent)...so current behavior makes sense to me.

mflaxman commented 9 years ago

Thanks @acityinohio . I'll leave as-is for now but if this gets a lot of usage then I can do some sort of JS input counter that shows you how much room you have.

If you want to write a blog post about the embed data feature I think the explorer is ready for it. Free proof of existence!

acityinohio commented 9 years ago

:+1: Definitely will do once I'm done with all my presentations next week! I have a long queue of blog posts to write, heh. :)