Include onchain transactions in events#448
Conversation
|
While the latest BDK 2.2 now shipped event (which would make emitting events easier on our end), we still need lightningdevkit/rust-lightning#3566 to properly classify the transactions in our store. So this remains blocked until the latter ships (likely with LDK 0.3). |
Is there a way we could get this into ldk-node sooner?
The team seems to lean towards favoring option 3, which is not ideal IMHO, but the main argument is that we don't really have the time to go any other route. The issue that I see from my PoV is that option 2 might even seem faster. Could 2 be an option? |
|
Technically unblocked, but we should first land #791, as the API here will depend on the API choices there. |
c832289 to
8362d88
Compare
Let callers obtain the object produced by merge semantics without a second lookup. Preserve the existing boolean API so unrelated call sites and their allocation behavior remain unchanged. Co-Authored-By: HAL 9000
Let wallet sync enqueue on-chain payment events directly. Co-Authored-By: HAL 9000
b20b0b5 to
b2d7c36
Compare
|
Should be good for review now. |
b2d7c36 to
35a60c4
Compare
Notify users when otherwise unclassified on-chain payments reach the anti-reorg confirmation depth. Use the wallet's effective stored payment so classified funding, splice, close, and sweep transactions stay quiet. Co-Authored-By: HAL 9000
The in-memory store source is shared by the library test utilities and integration-test helpers. Keep its unit test in the library-only module so each integration binary does not register and rerun it. Co-Authored-By: HAL 9000
35a60c4 to
176ac00
Compare
Closes #446.
Based on #432.
In #432 we exposed transactions in store. Here we take a stab at exposing them via events. However, to avoid emitting duplicate events for channel-related transactions, this is in draft until we have lightningdevkit/rust-lightning#3566