Rebase
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Yesterday
add change to SvgButtonOrLinkCss as well
seems like the root cause here is that mobile browsers occasionally do not clear the hover state. In testing, noticed this is also happening with the SvgButtonOrLinkCss components (e.g. the copy paste button on the wallet page)
fix copied comment
Revert the test change, it doesn't do what I expect and we already have coverage for coinbase in history a few lines above
More robust handling of coinbase txs. This is unreachable code but this guards against future code changes.
Rebase
Fix inaccurate coinbase comment
Rebase
Sun, May 18
Sat, May 17
- Lose isGenesis key and instead require a genesis placeholder tokenId
- Expand Action to accept an array of token actions per comment
- Validate and implement these inputs (will change how we build EMPP OP_RETURNs)
- (potentially) also lose the isMint key, since a MintAction will make this unnecessary
Build Bitcoin ABC Diffs / Diff Testing (preview-e.cash) passed.
Preview is available at http://51.83.66.92:41685 for the next 60 minutes.
@bot preview-e.cash
Fix up image some more
Fix some image artifacts
Rebase
default to dust sats if unspecified, variable name improvements
Use consistent history ordering between the various endpoints.
tests pass locally so pushing up for review; CI issues here seem unrelated to the diff
Fri, May 16
Make clippy happy
The final history ordering is: sort by block height first then txid, but mempool txs go last starting with the txs having confirmed parents (block height 0) and finally the mempool txs with unconfirmed parents (block height -1).
Rebase
preview is not expected to work until this lands, ack on the basic concept of iteratively building this in its own dir and then migrating the site
fix header subscription returning an extra array
Don't assume params in notification is an array of length 1
Fix returning null when there is no history
Tested with an address that initially has confirmed transactions, then receives a mempool transaction, then a new block gets mined: all 3 hashes are identical with Chronik and Fulcrum.
Ensure ordering within historical block
Actually I'm only getting the same result for a single tx in the mempool. When the block is mined the status differs.
I imagine that Chronik does not guarantee that the transaction history is ordered in the same order as inside the block.
I'm now getting the same results with Fulcrum and Chronik, with the expected exception of histories containing transactions with unconfirmed parents.
markdown fix for url