[WIP] Taproot Asset Loopouts #857
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sputn1ck
force-pushed
the
tapas_loopout
branch
from
731271a to
bd69544
Compare
loop: do not error out on context done in the executor
This commit adds a new notification to the proto, which is used by the server to request signatures for a deposit of a static loop in.
…rpc-commits StaticAddr: separate swapserverrpc commits
We remove the static address client and add its rpcs into the SwapClient
…_modules/looprpc/golang.org/x/net-0.33.0 build(deps): bump golang.org/x/net from 0.27.0 to 0.33.0 in /looprpc
Mixed batches approach covers the case where all the inputs are cooperative (function publishBatchCoop) and it is better than fully non-cooperative case (function publishBatch), but it can also create such transaction if needed, i.e. if all the sweeps are non-cooperative. So we can remove functions publishBatch, publishBatchCoop, option WithMixedBatch and associated code in greedy batch selection algorithm.
sweepbatcher: always enabled mixed batches
…set_chans autoloop: ignore asset channels
…sy-wait notifications: do not hog the CPU if there's no L402 token yet
StaticAddr: Withdraw arbitrary amounts
github: update cache version from deprecated v1 to v4
…t-params staticaddr: fix withdraw backwards compat
It should use the c variable passed into the lambda, not the parent t. It should use assert, not require package.
Previously, if a completed batch was visited after a batch to which the sweep was added, it was not deleted because the function returned early. This has been separated into two loops: the first one removes completed batches, and the second one adds the sweep to a batch.
This is needed to fix crashes in unit tests under -race.
Several structures were accessed without protection causing crashes under -race.
The code inside require.Eventually runs in parallel with the event loops of the batcher and its batches. Accessing fields of the batcher and batches must be done within an event loop. To address this, testRunInEventLoop methods were added to the Batcher and batch types. Unit tests were then rewritten to use this approach when accessing batcher and batch fields. Additionally, in many cases, receive operations from RegisterSpendChannel were moved before require.Eventually. This prevents testRunInEventLoop from getting stuck in an event loop while blocked on a RegisterSpendChannel send operation.
Try to catch more race conditions in unit tests.
sweepbatcher: fix race conditions in unit tests
sputn1ck
force-pushed
the
tapas_loopout
branch
2 times, most recently
from
5797027 to
00fbd82
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds taproot assets loop outs.
For now can mostly be ignored, as it is very WIP