Obd #6597
Closed
Obd #6597
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
We use a GitHub Action for sending the coverage to coveralls.io and don't need the goveralls binary anymore.
Instead of hard coding a commit to use for a binary tool that we use during the build process, we now only use "go install" to install the binaries and the golang builtin versioning system to pin the exact version/commit we want to use in go.mod.
The `GO111MODULE` variable is not required from go 1.16 https://go.dev/blog/go116-module-changes
when payment_hash or final_cltv_delta and payment_request was set, the error message showed that the parameters shouldn't be set with dest instead of payment_request [skip ci]
Since bbolt returns references to internally stored data when storing locally it's best to copy the byte slices returned or alternatively convert them to string (which also makes a copy) to avoid crashes casued by memory corruption.
This commit exposes the ChanStatusFlags inside waitingCloseResp such that the channel close type is exposed.
This change avoids enforcing new reserved value when PSBT funding is not finished yet as new inputs and outputs may still be added that could change the outcome of the check. This originally failed in the scenario when funding a channel from external wallet *and depositing to on-chain wallet* was done simultaneously in a single transaction. If such transaction confirms then reserved UTXO is guaranteed to be available but the check didn't take it into account. The enforcement still occurs in the final step of PSBT funding flow, so it is safe. It also occurs in case of non-PSBT funding.
This adds an integration test that makes sure channel can be funded from empty wallet using PSBT if the funding transaction contains an output belonging to the wallet, satisfying the reserve.
The minimum relay fee is always ensured to be above our fee floor except in the very first min relay fee query to bitcoind. This commit ensures that the fee floor is respected in this first query.
In this commit, we switch to always sending a channel type when we're in explicit mode. This is compatible with prior versions of lnd as they won't send a channel type, and we'll just arrive at the same type via the existing implicit funding. Fixes lightningnetwork#6067
Mark an invalid import
add mark to a possible invalide import: lnd does not have omnicore integrated.
mark a possible invalid import.
parseRequest: MUST test asset funding request, not just btc only.
unc openChannel: MUST test asset funding amount, not merely Bitcoin amount.
handle funding and funding acceptor: several place need to pay attention. For example, MUST check the asset amount(reserve) is within the Max-Min range. NOT only the bitcoin.
When the asset is bitcoin, this is the same to milli-satoshi, using 11 decimal, when the asset is omni-asset, this is a simple unsigned 64 int, 8 decimal when translats to string.
check it, may error if set 1
… && go test -run TestFundingManagerNormalWorkflow -v; \n cd routing && go test -run TestFindRoutesWithFeeLimit -v;
…s obto31:200m1pvjl...
fix a typo in comments of asset related cli
|
Wrong repo? |
|
Closed as it's irrelevant. Looks like you've created the PR in the wrong repo. |
|
sorry! error resp |
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.
the master is too old with upstream lightningnetwork/lnd
the pull request will upgrade to master-branch to lnd-v0.14.2-beta(Feb 4, 2022) ,
and add some obd omni-asset function .
Brief:
This release bases Omni-HTLC on the lnd commit and omnicore codebases. Where in omnicore, a new transaction type 7 is introduced to transfer multiple tokens of one property id to multiple receivers in Omnicore.
This release is a sub-project of OmniBOLT, and supports exclusive mode only, adding asset-aware interfaces and commands to lnd's gRPC API and CLI set.
The newly added API and commands are maintained in the following document:
https://omnilaboratory.github.io/obd/#/grpc-api
Environment
OS: Win10, Ubuntu 20.04
golang: 1.9
gcc: 9.3(for compiling Omnicore)
Notes
Currently, supported functions are:
https://omnilaboratory.github.io/obd/#/grpc-api?id=list-of-asset-related-interfaces
The table listing the interfaces also compares the BTC-only lnd interfaces.
What can you do?
Run Omnicore on Regtest mode, and then you can:
You can connect an obd node to all known lightning applications. But without customizing(minimum effort), these applications can only be aware of Bitcoin.
We also built docker images for easier drag-drop building your local OmniBolt lightning network by Polar(will release in Jun).
You MUST not: