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.

Sign up for GitHub

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

Jump to bottom

Stop storing lastBlockHash in CouchDB #45

Closed
wtogami opened this issue Jun 19, 2014 · 0 comments
Closed

Stop storing lastBlockHash in CouchDB #45

wtogami opened this issue Jun 19, 2014 · 0 comments

Comments

@wtogami
Copy link
Collaborator

wtogami commented Jun 19, 2014

Currently baron stores the last known blockhash in couchdb. It uses this blockhash on startup with listSinceBlock in order to process incoming payments that may have happened during downtime.

The way we are currently doing this non-ideal because it bloats couchdb with all the deletion and addition of a frequently changing record. Upon every new block it deletes the previous blockhash and adds the new record.

It turns out we do not need to store the last known block hash if we can obtain it from a different part of the database. For example, the most recent transaction blockhash fine to query with listSinceBlock.

Suggested Implementation

  • At startup query CouchDB to find the most recent transaction blockhash. Use that for listSinceBlock and remember it in memory.
    • If no transaction has a blockhash, find the created time of the most recent payment request and approximate a blockhash index from any point prior to that time.
    • If there are no payment requests then just use the current blockhash. There are no incoming payments.
wtogami added a commit that referenced this issue Jun 23, 2014
@wtogami
YOLO! Major Simplification to updatePayment*, Unified Reorg
c27d77d 
* No longer store lastBlockHash in CouchDB, close issue #45.
* lastBlockJob's listSinceBlock is missing double-spent transactions so it was failing to update.
  Meanwhile its reorg handling was redundant to watchpaymentjob and walletnotify.
  Removing reorg handling from lastBlockJob broke reorg_history entirely.
  It turns out reorg handling in other codepaths was broken by a few other errors.
  * validateTransactionBlock() isReorg was always false, logic bug.
  * updatePaymentWithTransaction()'s reorg handling could not work because blockIsValid is
    irrelevant to whether or not you should handle reorg/double-spend.
  * processReorged* functions were encouraging different windy entry points into reorg handling,
    in addition to being inflexible and difficult to trace.

It was simpler to rewrite updatePaymentWithTransaction() to unify all entry points of updatePayment* and
to always handle reorg/double-spent in the same code-path.

It seems to work.  All tests pass.

TODO: There is a new noisy "Document update conflict" that we need to detect and hide.
@wtogami wtogami closed this as completed Jun 23, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@wtogami