only call slpSend with bigints

rebase, name/type/spacing nit updates per comments

In D17701#403495, @emack wrote:

Consider a 100% 50% 25% button above the Redeem button similar to binance. Easier for tax calculations when people are just partially selling rounded percentages.

Show "you receive" amount for FIRMA redemptions

some suggestions trying to tighten up the copy, go with whatever you think is best. I don't think anyone reads something longer than a full sentence on the internet anymore. But we really only need a handful of people who "get it" to see this stuff, so I don't think we need to worry about general consumption too much here.

@bot preview-e.cash

@bot preview-e.cash

update proto script, patch lingering "value:" keys in READMEs, downstream impacts of proto script update (other bigints, type handling)

i think will just forget about this for now. we have good demand for the 42-xec reward and no one has complained about it being insufficient.

patch implementation of reduce in cashtab transactions (do not mix bigint and number)

rebase, bigint in reduce, bigint math for token rewards in herald, camelCase patches in ecash-agora, var name patches in cashtab constants, hex instead of decimal for hex-defined constants

remove debug log

rebase

more finds

more atoms_vec finds

apologies for the phab noise here ... not sure how to find all these locally. ninja check-functional is passing

more atoms_vec

test patch

more script patches, update other amounts params

chronik updates from name changes in mint data

update more names, implement

update mock to new shape

update types in chronik-http/src/electrum.rs

rebase, remove debug logs, remove duplicated branch in cashtab wallet migration, revert unrelated lint change in Configure.test.js

please update the ecash-lib change-log per usual version bump (link to this diff, brief description)

ecash-herald copyright update, ecash-agora camelCase patches, rust proto tighten comment line length

In D17641#401568, @emack wrote:

Unable to redeem 7ish XECX for XEC, this is above dust so should be possible?

Redemption worked fine for 10k XECX.

show dust error

changelog update to explain major version bump in ecash-agora

everyone will have to build the webassembly, even if they don't use any ECC.

Why minor here and patch in D17640 ?

nice, step change in UX. much much much better for app devs.

nice, huge step change for dev experience, and esp for apps that use ecash-lib and ecash-agora

update uninitialized interface

rebase

I think the diff is worth landing as is although it may not yet be comprehensive.

more robust check

So, this is not an exhaustive check; it just patches one (probably the most common) error case.

In D17630#401188, @emack wrote:

Can you provide some context on how to validate this output from the script above and that it is indeed excluding the not-bought or cancelled offers?

In D17625#401056, @emack wrote:

On extension the Send button is aligned left, which is correct but the rest of the component is overflowing off to the right as per current behavior. Makes the Send button almost look like a pop up not to mention it covers the labels beneath it.

give button container background color so scroll-behind looks cleaner, line it up with app buttons on mobile

only reason to do this was potential safari behavior (that, if true, this diff would potentially not resolve)

version bump + extension bump

note the test failure is from when I first put the diff up having accidentally deleted the file

This not-quite doubles the package size (compressed: 150.4 kB -> 245.0 kB, uncompressed: 564.2 kB -> 934.9 kB), but since we still stay below 1 MB even uncompressed this doesn't seem to be a big issue