review is simplified in this type of diff if before + after screenshots highlighting what has changed are included in the test plan

rebase and wait for CI to clear but looks good

this is a complicated fix to a niche issue that impacts behavior everywhere. I don't see a compelling case for the impact of this diff justifying its complexity.

clean up loop logic, remove debug log, comments

Add info logging

better while loop logic, more clarity in error msg, use variable instead of hardcode 5 in comment

Overall, the approach here is not ideal. It's not straightforward to handle this elegantly in ecash-agora (or mb it is and I just haven't sat down to work out the math) -- but even if we do handle it in ecash-agora, the performance delta is probably not user noticeable.

this is not a great stopping point but I have done so many rewrites and changes now that wanted to get some kind of anchor in for reference

coming up for air, taking a look at what has happened

• As @emack mentioned, this is 2 diffs. Please make one diff to add the close, and another to add the delay
• npm test does not actually test the behavior described in this diff. If it is impractical to add a unit or integration test, the test plan should include a description of how to repeat the issue before this change, and how to demonstrate that the issue is resolved after this change. Then npm test is demonstrating that existing behavior is preserved with this patch.
• patch version bump npm version patch (can be for just the 2nd of these 2 diffs, or can be a separate npm version patch for each diff), update changelog section of README describing the change

nit, the offer usually refers to the actual AgoraOffer, but in this case we want to specify that we mean a count

• Update the README with discussion of this feature and implementation example
• Minor version bump (npm version minor)
• Update changelog section of README with description of change associated with this version bump

But for ECDSA signatures, the tests fail, as "real" signatures can have a different length than dummy signatures used for leftover calculation.

without benchmarking this is difficult to review. you may need to run this as a custom version on some apps and see how it behaves in prod.

update missed test function name

add TODO for OP_RETURN parsing, update and export actions, use correct order for actions, typo patch

NB will need to add more tests but needs review now to confirm API and dev direction ... extensively testing the wrong API won't help anyone

rebase

remove dead code

green w/ nits on remaining _LEN constants

Is it possible to have a "valid" SLP OP_RETURN string that exceeds the OP_RETURN byte limit?

How is this function expected to be used? For the most part, correctly parsing an SLP OP_RETURN is often irrelevant, since we lack the indexer data (e.g. a well-formed SEND OP_RETURN could be a burn; validity in general depends on the indexer).

patch conditional rendering for test

Pushing up this last round of feedback-based changes to support incremental review, but this is not ready to land yet

Update interfaces, add some intermediate steps, take sighash as a param

this diff was created on the master branch, which makes it difficult to rebase onto the latest master

• If we are switching from px to rem, switch; remove all the px comments, mb keep one to show what the base-level px is
• do not use calc. if some ratios seem unreadable, create a variable for them and use the variable
• remove all unused variables

back out the pythonpath stuff, add dep

debian python note

would be a good change and help to get some of the css more standardized in Cashtab

better comments

tighten up comments, remove "get" prefix from utxo selection methods

TIL coin consolidator is a thing in electrum

another diff just deleted the test

rebase