Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: debug print the full bytes #6228

Closed
wants to merge 1 commit into from

Conversation

coolaj86
Copy link

@coolaj86 coolaj86 commented Aug 23, 2024

Either this one, or #6227 but, please, for the love of all that is right in this world, DO NOT print out THE WRONG NUMBER OF BYTES!!!!

Better yet, why are there different forms of serialization for the same object?

Screenshot 2024-08-23 at 11 35 07 AM

This should just consistently serialize to the same object because it's the same output script.

Issue being fixed or feature implemented

What was done?

How Has This Been Tested?

Breaking Changes

Checklist:

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas
  • I have added or updated relevant unit/integration/functional/e2e tests
  • I have made corresponding changes to the documentation
  • I have assigned this pull request to a milestone

@coolaj86
Copy link
Author

coolaj86 commented Aug 23, 2024

P.S. I realize that the byte discrepancy is probably just legacy nonsense from the BitCore devs that you inherited, and that other than accidentally calling the wrong serialize function by mistake when adding the AssetLockTx / ExtraPayload functions to the code, it's probably not your fault. I'm just frustrated because this codebase is always a nightmare to work in and it's red herrings all the way down. EVERY. TIME.

And, yes, if I could hold everything in my head all the time, I would have realized that pkh is 20 bytes and it was only printing 15 bytes and it would have clicked, but since the debug output SHOWED THE BYTES, I thought that they were the bytes and was trying to figure out if the "extra" bytes were a checksum or what.

... I also don't understand why not just reuse the OP_RETURN memo to put in the address. There's already a type byte to signal what's going on and OP_RETURN is common in the industry for creating subprotocols on chains. And you can have multiple OP_RETURNS, so there's no need to have a separate array structure that fundamentally changes the way a transaction is parsed.

🤷‍♂️

But please fix that for anyone else who ever happens to use the debug output to try to understand UNDOCUMENTED features that they have to work with.

@coolaj86
Copy link
Author

And I did take a quick look to see if I could fix the serialization but I couldn't find it. Probably in some UniValue macro 6 layers down...

@PastaPastaPasta
Copy link
Member

Please follow the PR template when opening PRs. I've pasted in the template again for you. Please fill it in. Marking PR as a draft for now, please mark ready for review once done.

@PastaPastaPasta PastaPastaPasta marked this pull request as draft August 23, 2024 18:15
@UdjinM6
Copy link

UdjinM6 commented Oct 25, 2024

superseded by #6229

@UdjinM6 UdjinM6 closed this Oct 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants