* removed the `Direction` class
* improved the non-reg test for htlcs
- check actual content instead of only success and roundtrip
- use randomized data for all fields instead of all-zero
- check the remaining data, not only the decoded value (codecs are
chained so a regression here will cause the next codec to fail)
Co-Authored-By: Bastien Teinturier <31281497+t-bast@users.noreply.github.com>
Let a sender manually split a payment and specify a trampoline route.
Fix two flaky tests where the order of payment parts could be
different, resulting in a failed equality test.
If we're relaying multiple HTLCs for the same payment_hash,
we need to list all of those.
The previous code only handled that when Trampoline was used.
With MPP and Trampoline (and particularly the combination of the two),
we need to keep track of multiple amounts, recipients and fees.
There's a trampoline fee and a fee to reach the first trampoline node.
The trampoline nodes must appear in the route, but not as payment recipients.
Adding new fields to payment events and DB structs lets us distinguish those.
We also relax the spec requirement about feature graph dependencies.
The requirement to include `var_onion_optin` in invoice feature bits
was added after the first Phoenix release.
Phoenix users will thus have non spec-compliant invoices in their
payment history.
We accept invoices that don't set this field; this is a harmless
spec violation (as long as we set it in new invoices).
Start relaying trampoline payments with multi-part aggregation (disabled by default,
must be enabled with config).
Recovery after a restart is correctly handled, even if payments were being forwarded.
No DB schema update in this commit.
The trampoline UX will be somewhat bad because many improvements/polish are missing.
Some shortcuts were taken, a few hacks here and there need to be fixed, but nothing too scary.
Those improvements will be done in separate commits before the next release.
Add support for multi-part payments (MPP).
We can now send and receive multi-part payments, with a somewhat basic splitting algorithm that will be refined based on real-world usage.
Compatibility with other implementations hasn't been tested yet as they don't have a branch ready.
This compatibility testing may reveal small details that need to be changed and may invalidate pending multi-part invoices.
* Unify payment events (no more duplication between payment types and events)
* Factorize DB and eventStream interactions: this paves the way for sub-payments that shouldn't be stored in the DB nor emit events.
* Add more fields to the payments DB:
* bolt 11 invoice for sent payment
* external id (for app developers)
* parent id (AMP)
* target node id
* fees
* route (if success)
* failures (if failed)
* Re-work the PaymentsDb interface
* Clarify use of seconds / milliseconds in DB interfaces -> milliseconds everywhere
* Run SQL migrations inside transactions
* added support for 'disable' flag in announcements (see lightningnetwork/lightning-rfc/pull/143)
* now responding TemporaryChannelFailure errors to CMD_ADD_HTLC in OFFLINE
* added helper methods for interpreting ChannelAnnouncement flags
* (gui) added image depicting flags of announcement in channels table
* implemented all failures as per lightningnetwork/lightning-rfc/pull/167
* router: don't use channels that have been announced as disabled
* Sphinx: implement BOLT PR 145
see https://github.com/lightningnetwork/lightning-rfc/pull/145
* Sphinx: use simplified onion proposed in PR145
address and hop-payload fields have fused, and we are now routing based on channel short ids
* Updated relayer to take advantage of shortChannelId
* Sphinx: use more meaningful class names
* BOLT 4: use 32 bytes MAC in reply error packet
instead of 20
* wire: add chainHash field to open message (see https://github.com/lightningnetwork/lightning-rfc/pull/135)
* split validateParams() into "funder" and "fundee" versions (fundee also needs to check the chain hash funder sent in their open message)
* Added a PaymentRequest object
* A `PaymentRequest` can be serialized/deserialized with `write`/`read`
static functions in companion
* Amount validation is handled in constructor
* `ReceivePayment` message in payment handler generates a `PaymentRequest`
* Updated tests
* HTLC succeeds if amount is equal or greater than requested amount
* If the amount paid is more than twice the amount expected, the HTLC fails
* (gui) display payment failed cause in notification
* Improved payment request validation messages
* make max-feerate-mismatch configurable and set default value to 500%
there can be a significant gap between the fee rate estimated by different bitcoin
clients (see estimatesmartfee) so we must set a reasonably high value for the threshold
above which we consider htat local and remote fee rates are too different and close the
channel.
* use difference/average to compare feerate
it becomes symmetrical and easier to reason with, and also more forgiving.
* make "UpdateFee" minimum ratio configurable
* integ tests: removed sleeps, waiting for watches before generating blocks
* fixed a (rarely occuring) race condition related to bulk-generation of test blocks
* malleability fix: we wait the parent of the funding tx or its malleated version to be confirmed,
then we create the funding tx
* set default min depth to 2
* disconnection during WAIT_FOR_FUNDING_CREATED now closes the channel
* use CPFP to create our funding tx
ask bitcoin-core to fund a standard tx which has a segwit output, and spend it to
create our funding tx. the parent and the funding tx are published at the same time
and should end up in the same block.
this should give us some protection against malleability attacks: it should improve the chances
of our funding tx being mined, and if the parent tx loses the race against it malleated version
then our fuding tx will not be published, which is much better than having a conflicted funding
tx
* set default fee-rate-per-kw to 10000
* guestimate that feerate-per-kw is feerate-per-kb / 2 for a standard commit tx
* channel: estimate the fee for the parent of our funding tx
instead of hardcoding it
* integration test: increase channel capacities
because we use a larger feerate-per-kw now
* added a feerateKB2Kw method
* using scodec for failure messages
* we now update routing info and retry payments in case of Update failure
* properly implemented BOLT4/'Receiving Failure Codes' (also fixed a bug with UnknownPaymentHash)
* added integration tests on htlc timeout
* relayer now sends an UpdateFail to downstream when an htlc timeout hits the blockchain
* added integration tests on extracting preimage from blockchain
* cleaning up of htlc bindings in relayer
* router now doesn't send a 2nd request to bitcoind when it is notified of a new channel twice in a short amount of time
* peerclient now asks for witness when retrieving blocks from bitcoind
* getTxBlockHash now returns None instead of an error when tx is in the mempool
* we now look into the mempool when checking for WatchSpent
* fixed FundingSigned been sent twice when deferring an early FundingLocked
* added zeromq listener, removed predefined eclair.conf files in test, limited concurrent rpc calls to 5 for the router
* Update README.md with ZMQ configuration
* Added a warning and link to alpha2 install instructions
* removed PeerClient
* improved PeerWatcher performance
* using scodec for failure messages
* we now update routing info and retry payments in case of Update failure
* properly implemented BOLT4/'Receiving Failure Codes' (also fixed a bug with UnknownPaymentHash)
* BOLT 4: create return packets for failure messages
* bolt 4: add low-level methods for returning error messages
* BOLT 4: return shared secrets along with the onion packet
* codecs: minor fix the UpdateFailHtlc codec
* BOLT 4: return htlc failures
create and propagate htlc failures as per BOLT 4
* update tests
* channel: publish short channel id when restoring data
and not on reconnection
* channel: remove "channel update" parameters from Commitments.sendAdd()
* channel: send "add htlc failed" to relayer
and a more informative message to the sender through handleCommandError
* keep shared secrets local to PaymentLifeCycle
CMD_ADD_HTLC should just know the onion packet (as before), not the shared secrets
* relayer: handle failure cases
wrong expiry, amount, ...
* added a simple test on the fail workflow
* added a 'channel-capacity-exceeded' test
* make PaymentSucceeded and PaymentFailed children of PaymentResult
* relayer: ChannelUpdates should be stored in a Map, not an Option
* reply with update_fail_malformed_htlc when the onion is not parsable
* channel: handle 'update_fail_malformed_htlc' in Shutdown state
and add tests
* minor: AddHtlcSucceeded -> AddHtlcSuccess
* use bitcoin-lib 0.9.10
* clarified which fee rate we are using in calculations, also feeRate->feerate
* added support for UpdateFee
* fixed closing workflow when starting with different fees
* attempt at solving travis issues
* fixed feeratePerKw not cleaned up after tests
* added test on invalid initial feerate
* fixed bitcoind api calls mixup, tested on mainnet
* rebased from wip-bolts
