profile
viewpoint
Andrew Cann canndrew Perth, Australia

canndrew/error_def 17

Rust syntax extension for generating error-handling boilerplate code.

canndrew/crust 3

Reliable p2p network connections in Rust with NAT traversal. One of the most needed libraries for any server-less / decentralised projects

canndrew/crust-futures 3

Port of crust to futures/tokio

canndrew/emoji-quickpick 3

Emoji picking app for Linux

canndrew/c_linked_list 2

Rust library for handling C linked lists

canndrew/atomic-arc 1

Atomically reference-counted atomic pointers for Rust

canndrew/abstractsocket 0

abstract unix sockets support for net.createConnection

canndrew/agda 0

Agda is a dependently typed programming language / interactive theorem prover.

canndrew/beaker-plugin-safe-authenticator 0

SAFE Authenticator plugin for SAFE Browser

canndrew/bincode 0

A binary encoder / decoder implementation in Rust.

create barnchcanndrew/DotNetLightning

branch : channel-reestablish-fix

created branch time in 14 hours

PR opened joemphilips/DotNetLightning

Send correct commitment point in channel_reestablish messages

The commitment points we send in the channel_reestablish messages are wrong. We need to send our commitment point for the peer's most recent commitment, not their point. This commit fixes the issue.

+1 -1

0 comment

1 changed file

pr created time in 2 days

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 6c77950cc48771f140506aeab386f1a7eaf97017

Send correct commitment point in channel_reestablish messages The commitment points we send in the `channel_reestablish` messages is wrong. We need to send our commitment point for the peer's most recent commitment, not theirs. This commit fixes the issue.

view details

push time in 2 days

create barnchcanndrew/DotNetLightning

branch : channel-reestablish-fix-upstream

created branch time in 2 days

push eventcanndrew/DotNetLightning

joe.miyamoto

commit sha 4e910ed7ba511f913b4a9b1122b50aafa9a173ee

Reverse the hash when creating from preimage. When user constructs PaymentRequest from PaymentPreimage, they usually gets it by `PaymentPreimage.Hash` member. But before this commit, they had to reverse the order of the hash before giving it to PaymentRequest constructor(as TaggeedFields). This is not elgonomic, and it breaks the purpose of the member in the first place. This commit reverses the order. This commit also changes the behavior of GetRIPEMD160 method. (Because we were already using `PaymentPreimage.Hash` for BOLT3 tests, and we had to reverse the order again before putting it into the commitment secript)

view details

joe.miyamoto

commit sha cbcbbaab85c321b4848b58b5eb5c20cbd9bbb9ac

Change inner representation of `PaymentHash` The correct usage of `uint256` is that it holds inner value as a little-endian, so that it will shows big-endian encoded string when we print/parse the hex value. Before this commit, it had holded it in big-endian. Which had two problems. 1. It does not align well with `PaymentRequest` construction. 2. It will result to reversed string value when we print/parse. This commit fixes it by always holding uint256 value in a right way. This commit also changes the defualt behavior of `PaymentHash.ToBytes()` so that it will dump big-endian encoded bytes (which probably an user always wants)

view details

joe.miyamoto

commit sha dc263c9e2aea36f550ef9f0608402d70c668b8ae

Change an inner representation of description_hash As the same motivation with the previous commit, we now hold `DescriptionHash` tagged field in `PaymentRequest` to always hold inner `uint256` in the right way.

view details

joe.miyamoto

commit sha 80214e9c49516ce8c8fa71c42a68392259eb60f7

Always hold a `uint256` in a right way. As a same motivation with previous commit, it now holds `uint256` for `chain_genesis` in a right way. * For supported chain hash in `InitTLV` * Before this PR, when constructing genesis_hash from `NBitcoin.Network` it has been reversed the bytes needlessly. Now we just use `NBitcoin.Network.Consensus.HashGenesisBlock`

view details

Joe Miyamoto

commit sha 75f8c4074704103344df03fffaefb0b9b5f09ced

Merge pull request #118 from joemphilips/reverse_endian_for_PaymentHash Always hold bytes in uint256 as a little endian

view details

joe.miyamoto

commit sha 14d62f840fa29135705db571572cb86c787e6cef

Use BlockHeightOffset32 for cltv_expiry_delta in invoice It is delta, so using offset rather than `BlockHeight` (which is made to represent absolute height) makes better sence.

view details

Andrew Cann

commit sha 6f1175a5cdd0958be1a1f02039544a2ae840449c

Use correct channel ID in WaitForFundingSigned

view details

Joe Miyamoto

commit sha 6deb3889e408860095adedbf683d4325dfa986e9

Merge pull request #119 from canndrew/wait-for-funding-signed-channel-id-fix Use correct channel id in WaitForFundingSigned

view details

Alexander Schlindwein

commit sha a50ba661f9dc3877eecf9155b0fb8e09017b1531

Make ClosingData public instead of CLIMutable The ClosingData type was CLIMutable to allow for json serialization and deserialization. However, that only avoided an exception being thrown. The data was lost when writing and reading the json. This commit removes the CLIMutable attribute and makes the type public as the other types.

view details

Joe Miyamoto

commit sha 70da61dc53e5f3ea7f9204c0508f1f5d9e3991ef

Merge pull request #120 from Bobface/closingdata-public Make ClosingData public instead of CLIMutable

view details

Andrew Cann

commit sha df5dfa149465ac43dde5c88a7d672683eff236a1

Mono-hop unidirectional payments

view details

push time in 20 days

pull request commentnblockchain/DotNetLightning

Use correct channel ID in WaitForFundingSigned

Fixed.

canndrew

comment created time in 20 days

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha fda35ef8c935645e65cafd7e60c1c87c2dba50e6

Use correct channel ID in WaitForFundingSigned This makes geewallet's OutgoingUnfundedChannel report the correct/true channel id, rather than the temporary channel id used during the initial stage of channel opening. This is commit 6f1175a5cdd0958be1a1f02039544a2ae840449c in upstream DNL.

view details

push time in 20 days

pull request commentjoemphilips/DotNetLightning

Use correct channel id in WaitForFundingSigned

I don't have permission to merge here. I've rebased it off of latest master though.

canndrew

comment created time in 21 days

push eventcanndrew/DotNetLightning

joe.miyamoto

commit sha 4e910ed7ba511f913b4a9b1122b50aafa9a173ee

Reverse the hash when creating from preimage. When user constructs PaymentRequest from PaymentPreimage, they usually gets it by `PaymentPreimage.Hash` member. But before this commit, they had to reverse the order of the hash before giving it to PaymentRequest constructor(as TaggeedFields). This is not elgonomic, and it breaks the purpose of the member in the first place. This commit reverses the order. This commit also changes the behavior of GetRIPEMD160 method. (Because we were already using `PaymentPreimage.Hash` for BOLT3 tests, and we had to reverse the order again before putting it into the commitment secript)

view details

joe.miyamoto

commit sha cbcbbaab85c321b4848b58b5eb5c20cbd9bbb9ac

Change inner representation of `PaymentHash` The correct usage of `uint256` is that it holds inner value as a little-endian, so that it will shows big-endian encoded string when we print/parse the hex value. Before this commit, it had holded it in big-endian. Which had two problems. 1. It does not align well with `PaymentRequest` construction. 2. It will result to reversed string value when we print/parse. This commit fixes it by always holding uint256 value in a right way. This commit also changes the defualt behavior of `PaymentHash.ToBytes()` so that it will dump big-endian encoded bytes (which probably an user always wants)

view details

joe.miyamoto

commit sha dc263c9e2aea36f550ef9f0608402d70c668b8ae

Change an inner representation of description_hash As the same motivation with the previous commit, we now hold `DescriptionHash` tagged field in `PaymentRequest` to always hold inner `uint256` in the right way.

view details

joe.miyamoto

commit sha 80214e9c49516ce8c8fa71c42a68392259eb60f7

Always hold a `uint256` in a right way. As a same motivation with previous commit, it now holds `uint256` for `chain_genesis` in a right way. * For supported chain hash in `InitTLV` * Before this PR, when constructing genesis_hash from `NBitcoin.Network` it has been reversed the bytes needlessly. Now we just use `NBitcoin.Network.Consensus.HashGenesisBlock`

view details

Joe Miyamoto

commit sha 75f8c4074704103344df03fffaefb0b9b5f09ced

Merge pull request #118 from joemphilips/reverse_endian_for_PaymentHash Always hold bytes in uint256 as a little endian

view details

joe.miyamoto

commit sha 14d62f840fa29135705db571572cb86c787e6cef

Use BlockHeightOffset32 for cltv_expiry_delta in invoice It is delta, so using offset rather than `BlockHeight` (which is made to represent absolute height) makes better sence.

view details

Andrew Cann

commit sha 6f1175a5cdd0958be1a1f02039544a2ae840449c

Use correct channel ID in WaitForFundingSigned

view details

push time in 21 days

pull request commentjoemphilips/DotNetLightning

Always hold bytes in uint256 as a little endian

This LGTM. The inconsistency of reversing the endianess in arbitrary places was the only thing that was bothering me, but that's been fixed.

joemphilips

comment created time in 21 days

pull request commentjoemphilips/DotNetLightning

Always hold bytes in uint256 as a little endian

I’ve chosen a second approach. Because that is the correct way to use uint256

This makes sense. I just wish it wasn't so easy to get the wrong endianess out of a uint256, since I just made the same mistake in my code and had to debug it. Some good protection against this would be to hide the internal uint256 of all types that contain one (such as TxId, ChannelId, etc.) and to give those types their own {To,From}{String,Bytes} methods.

joemphilips

comment created time in 21 days

PR opened joemphilips/DotNetLightning

Use correct channel id in WaitForFundingSigned

When we are waiting for the funding_signed message we already know the true channel id of the channel, rather than just the temporary channel id. As such, we can store the true channel id in WaitForFundingSignedData. This fixes a bug in geewallet where querying the channel id of a channel would return the temporary channel id rather than the true channel id.

+5 -3

0 comment

1 changed file

pr created time in 21 days

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 4a4a7f24b2392a7b78db15b356ee379dbc09d978

Fix ObscuredCommitmentNumber generation Obscured commitment numbers treat the commitment number as counting upwards from 0 rather than downwards from UInt48.MaxValue.

view details

Andrew Cann

commit sha d877fbaedfa4c39c3b7e4e176e851a41986ad978

Use correct channel ID in WaitForFundingSigned

view details

push time in 21 days

create barnchcanndrew/DotNetLightning

branch : wait-for-funding-signed-channel-id

created branch time in 21 days

issue commentjoemphilips/DotNetLightning

Stop supporting Infrastructure.

This sounds fine to me. We're not using the infrastructure stuff at all.

joemphilips

comment created time in 22 days

pull request commentjoemphilips/DotNetLightning

Reverse the hash when creating from preimage.

Why does the hash need to be reversed? Does it say somewhere in the spec that the hash is transmitted in little-endian?

joemphilips

comment created time in 22 days

push eventcanndrew/DotNetLightning

Alexander Schlindwein

commit sha 6f5b1c7625e338b2ef05bddb8239193b5e831087

Make ClosingData CLIMutable

view details

Joe Miyamoto

commit sha 2f2a90dc57f91364d8ef3392c29f397a3b990fc4

Merge pull request #116 from Bobface/closingdata-climutable Make ClosingData CLIMutable

view details

Andrew Cann

commit sha 8f7b7ebe5014c01069cad8e260a95f5e0615f501

Expose RevocationSet.{Keys,FromKeys} Allows converting a RevocationSet to/from a list of keys. This allows serializing/deserializing the set.

view details

Andrew Cann

commit sha 2bdb04303b1e4bcef6ec9c77e8d1c73e53962e93

Use correct commitment info in makeChannelReestablish makeChannelReestablish was using hard-coded commitment numbers and keys rather than the info in the Commitments object that it gets passed. This fix makes it use the values in the Commitments object instead.

view details

Joe Miyamoto

commit sha d485e88ef35bd1515818863689e235958db7b6e8

Merge pull request #115 from canndrew/more-revocation-fixes More revocation fixes

view details

Andrew Cann

commit sha 893faeb7ba46fc2de94da93e02b110533fb64395

Fix ObscuredCommitmentNumber generation Obscured commitment numbers treat the commitment number as counting upwards from 0 rather than downwards from UInt48.MaxValue.

view details

joe.miyamoto

commit sha 78ea80838c60d7bed0b295bddeafcada852b8268

fix bug in ShortChannelId serialization * Before this, short_channel_id serialization did not follow the spec.

view details

Joe Miyamoto

commit sha 0d4419dde0c7ca84bff8a092ae976a12464ed8b0

Merge pull request #117 from canndrew/upstream-master-obscured-commitment-number-fix Fix ObscuredCommitmentNumber generation

view details

Andrew Cann

commit sha 42908e910e62d096f7cb7a1bcf8d618120c4db81

Mono-hop unidirectional payments

view details

push time in a month

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 8f7b7ebe5014c01069cad8e260a95f5e0615f501

Expose RevocationSet.{Keys,FromKeys} Allows converting a RevocationSet to/from a list of keys. This allows serializing/deserializing the set.

view details

Andrew Cann

commit sha 2bdb04303b1e4bcef6ec9c77e8d1c73e53962e93

Use correct commitment info in makeChannelReestablish makeChannelReestablish was using hard-coded commitment numbers and keys rather than the info in the Commitments object that it gets passed. This fix makes it use the values in the Commitments object instead.

view details

Joe Miyamoto

commit sha d485e88ef35bd1515818863689e235958db7b6e8

Merge pull request #115 from canndrew/more-revocation-fixes More revocation fixes

view details

Andrew Cann

commit sha 893faeb7ba46fc2de94da93e02b110533fb64395

Fix ObscuredCommitmentNumber generation Obscured commitment numbers treat the commitment number as counting upwards from 0 rather than downwards from UInt48.MaxValue.

view details

push time in a month

PR opened joemphilips/DotNetLightning

Fix ObscuredCommitmentNumber generation

Obscured commitment numbers treat the commitment number as counting upwards from 0 rather than downwards from UInt48.MaxValue.

This hadn't shown up in testing so far since we were only testing against ourselves and so the error cancelled out on both sides.

+5 -5

0 comment

2 changed files

pr created time in a month

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 0938a6b8505de9652b7f2f15f90a77254e7220c0

Expose RevocationSet.{Keys,FromKeys} Allows converting a RevocationSet to/from a list of keys. This allows serializing/deserializing the set.

view details

Andrew Cann

commit sha df51210302747e4657f1b801775117b0f61afb87

Use correct commitment info in makeChannelReestablish makeChannelReestablish was using hard-coded commitment numbers and keys rather than the info in the Commitments object that it gets passed. This fix makes it use the values in the Commitments object instead.

view details

push time in a month

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 8f7b7ebe5014c01069cad8e260a95f5e0615f501

Expose RevocationSet.{Keys,FromKeys} Allows converting a RevocationSet to/from a list of keys. This allows serializing/deserializing the set.

view details

Andrew Cann

commit sha 2bdb04303b1e4bcef6ec9c77e8d1c73e53962e93

Use correct commitment info in makeChannelReestablish makeChannelReestablish was using hard-coded commitment numbers and keys rather than the info in the Commitments object that it gets passed. This fix makes it use the values in the Commitments object instead.

view details

push time in a month

push eventcanndrew/DotNetLightning

Alexander Schlindwein

commit sha 6f5b1c7625e338b2ef05bddb8239193b5e831087

Make ClosingData CLIMutable

view details

Joe Miyamoto

commit sha 2f2a90dc57f91364d8ef3392c29f397a3b990fc4

Merge pull request #116 from Bobface/closingdata-climutable Make ClosingData CLIMutable

view details

Andrew Cann

commit sha 169d6cd8b70a198425794eb0d8b7630ecd3c8115

Expose RevocationSet.{Keys,FromKeys} Allows converting a RevocationSet to/from a list of keys. This allows serializing/deserializing the set.

view details

Andrew Cann

commit sha 827dc57d452e2d034333ff75eae3c3250d7cbfe1

Use correct commitment info in makeChannelReestablish makeChannelReestablish was using hard-coded commitment numbers and keys rather than the info in the Commitments object that it gets passed. This fix makes it use the values in the Commitments object instead.

view details

Andrew Cann

commit sha a4b91cbd40a3c7e7e5667421057851cb1bd317ed

Apply fixes based on feedback

view details

push time in a month

create barnchcanndrew/DotNetLightning

branch : master-with-revocation-keys-api

created branch time in a month

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 7e157ec47a3cdc310a7637fcff30dddd33997797

Apply fixes based on feedback

view details

push time in a month

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 8b656c4f821a7b603cc5e6fe73cdf4cb7a5ee048

Apply fixes based on feedback

view details

push time in a month

Pull request review commentjoemphilips/DotNetLightning

More revocation fixes

 type InsertRevocationKeyError = type RevocationSet private (keys: list<CommitmentNumber * RevocationKey>) =     new() = RevocationSet(List.empty) -    member private this.Keys = keys+    member this.Keys = keys

No, part of the point of this PR is to expose this member so that we can access it and serialize it from geewallet.

canndrew

comment created time in a month

PR opened joemphilips/DotNetLightning

More revocation fixes

This PR adds the ability to convert a RevocationSet to/from a list of CommitmentNumber * RevocationKey. This is useful for being able to serialize a RevocationSet.

It also removes the hard-coded values from the makeChannelReestablish and uses the keys and commitment numbers from the Commitments object instead.

+88 -28

0 comment

8 changed files

pr created time in a month

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha dd3c45257a56d49d2ee44c3110e196c63b08ed1c

Expose RevocationSet.{Keys,FromKeys} Allows converting a RevocationSet to/from a list of keys. This allows serializing/deserializing the set.

view details

Andrew Cann

commit sha dd59317f2cc9fd17164816ba2389f7c2e209179b

Use correct commitment info in makeChannelReestablish makeChannelReestablish was using hard-coded commitment numbers and keys rather than the info in the Commitments object that it gets passed. This fix makes it use the values in the Commitments object instead.

view details

push time in a month

create barnchcanndrew/DotNetLightning

branch : more-revocation-fixes

created branch time in a month

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 0d7ca38b442e61f45d39d0028a7c572fb2d09f73

Mono-hop unidirectional payments

view details

Andrew Cann

commit sha fa4f4873ab0a2104adf8668ca9760325e8b8a13a

Add and switch to new types for revocation Add the UInt48, RevocationKey, CommitmentPubKey, CommitmentSeed and RevocationSet types. A RevocationKey is a secret key that can be used to revoke a transaction. It's shared in the revoke_and_ack message and stored in the user's wallet in a RevocationSet. A CommitmentPubKey is the public key of a RevocationKey, also known as a "per commitment point". A CommitmentSeed is the master revocation key for a side of a channel and can be used to derive all the revocation keys for that side of that channel. A RevocationSet stores a set of revocation keys in a compact form specified in BOLT #3 which allows earlier keys to be derived from later keys.

view details

Andrew Cann

commit sha 67aeb0760ec040ea35c670be07109b9032714c0b

Expose RevocationSet.{Keys,FromKeys} Allows converting a RevocationSet to/from a list of keys. This allows serializing/deserializing the set.

view details

push time in a month

push eventcanndrew/DotNetLightning

push time in a month

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 21d7dcaa961018116149ca49c8cd81714f485c11

Add Msg suffix to MonoHopUnidirectionalPayment type

view details

push time in a month

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha c15a629625b5764384bca4b887d8db10588c3007

Expose RevocationSet.{Keys,FromKeys} Allows converting a RevocationSet to/from a list of keys. This allows serializing/deserializing the set.

view details

push time in a month

PR opened nblockchain/DotNetLightning

Add and switch to new types for revocation

Add the UInt48, RevocationKey, CommitmentPubKey, CommitmentSeed and RevocationSet types.

A RevocationKey is a secret key that can be used to revoke a transaction. It's shared in the revoke_and_ack message and stored in the user's wallet in a RevocationSet. A CommitmentPubKey is the public key of a RevocationKey, also known as a "per commitment point". A CommitmentSeed is the master revocation key for a side of a channel and can be used to derive all the revocation keys for that side of that channel.

A RevocationSet stores a set of revocation keys in a compact form specified in BOLT #3 which allows earlier keys to be derived from later keys.

+889 -224

0 comment

30 changed files

pr created time in a month

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 7bc9f33e14e5170f03b7629d9adc1a0433ebb7cd

Mono-hop unidirectional payments

view details

push time in a month

push eventcanndrew/DotNetLightning

Andres G. Aragoneses

commit sha acd11cd812ad871a1d977832e685043281493eec

Fix package restore with VS4Mac When opening the solution with VS4Mac, it was giving this error right away: Detected package downgrade: FSharp.Core from 4.7.0 to 4.5.2. Reference the package directly from the project to select a different version. DotNetLightning.Integration.Tests -> DotNetLightning.Server -> DotNetLightning.Core -> FSharp.Core (>= 4.7.0) DotNetLightning.Integration.Tests -> DotNetLightning.Server -> FSharp.Core (>= 4.5.2) Detected package downgrade: FSharp.Core from 4.7.0 to 4.5.2. Reference the package directly from the project to select a different version. DotNetLightning.Integration.Tests -> DotNetLightning.Server -> TaskUtils -> ResultUtils -> FSharp.Core (>= 4.7.0) DotNetLightning.Integration.Tests -> DotNetLightning.Server -> FSharp.Core (>= 4.5.2) Restore failed.

view details

Joe Miyamoto

commit sha d3fa8e9338ae941616397bddf0b4b43305daa6b2

Merge pull request #114 from knocte/fixPkgRestoreVs4Mac Fix package restore with VS4Mac

view details

Andrew Cann

commit sha d98772329071eaf8ad44208c47463a1006f2a3cf

Mono-hop unidirectional payments

view details

push time in a month

push eventcanndrew/DotNetLightning

joe.miyamoto

commit sha 5d228cd4c21562b05e30bff9d4f6e594ef80f6ca

Support LSAT. * Macaroons are Based on https://github.com/JornWildt/Macaroons.Net * Strictly speaking this is an API layer thing. So I wasn't sure I should include it in here. * But it seems people in lightning lab are trying to standardize its use for LN-powered authentication * `VerifyLSATCaveats` extension method is a main entrypoint for the api consumer.

view details

Joe Miyamoto

commit sha 176587ea495bafe01e59fd22959263b7ec13ed95

Merge pull request #101 from joemphilips/macaroon add package for macaroon and its test

view details

joe.miyamoto

commit sha 2d9903f2418a87b0dcf3a1f8663280818efbf006

Specify PrivateAssets="all" for Macaroon

view details

joe.miyamoto

commit sha 9705855d3e890fa3258dd60734e57b8160132e18

Fix BouncyCastle test failure for macaroon. * Macaroon uses nacl(libsodium)-based cryptographic operation for third party caveats. before this commit, Macaroon.csproj was depending on NSec, so it was incompatible with BouncyCastle build. By excluding deps to NSec and delay initializing the cryptographic parts of `Macaroon` , Nsec wont get included in `DotNetLightning.Core` for BouncyCastle build. * We do not support third party caveats for BouncyCastle build we may change our mind later, but for now, third party caveats are not defined in LSAT spec and it is not even used in lnd, so this is ok.

view details

joe.miyamoto

commit sha 416fb3fdac1f955cd8f0077999ddc38cda488175

Skip macaroon tests which uses third party caveats. * Since Third party caveats are only supported through DotNetLightning.Core. This is because third-party caveats uses cryptographic operation. and we want to change the actual implementation in DotNetLightning.Core

view details

Joe Miyamoto

commit sha 87489bf0ce8e6ee6b294ccbf776010cc68032cab

Merge pull request #106 from joemphilips/fix_macaroon_build Fix BouncyCastle test failure for macaroon.

view details

joe.miyamoto

commit sha 8c478b7b4769d655c31f687384df07366e18f813

Stop running Infrastructure tests in CI. * Infrastructure tests are fragile. And we don't have a plan to support it in the future. We will probably remove the whole code later. * see * https://github.com/joemphilips/DotNetLightning/issues/98 * https://github.com/joemphilips/DotNetLightning/issues/99

view details

Andrew Cann

commit sha 0aebb99aceee71140fc99c9a2d9bcdf47a07e5f1

Add `Msg` suffix to message type names This makes code that handles messages more comprehendable.

view details

Andrew Cann

commit sha 321eba1957760b7c182bc02fa25d122fad0b8f0a

Append Msg to the names of some variables In order to bring the variable names more in-line with the new type names from the previous commit.

view details

Joe Miyamoto

commit sha e6c482073bbff05d20977483105370cf19af5a5e

Merge pull request #107 from canndrew/rename-msg-types Add `Msg` suffix to message type names

view details

Andrew Cann

commit sha 974723f7163132c0aa81ac97a183646b512a55fc

Add and switch to new types for revocation Add the UInt48, RevocationKey, CommitmentPubKey, CommitmentSeed and RevocationSet types. A RevocationKey is a secret key that can be used to revoke a transaction. It's shared in the revoke_and_ack message and stored in the user's wallet in a RevocationSet. A CommitmentPubKey is the public key of a RevocationKey, also known as a "per commitment point". A CommitmentSeed is the master revocation key for a side of a channel and can be used to derive all the revocation keys for that side of that channel. A RevocationSet stores a set of revocation keys in a compact form specified in BOLT #3 which allows earlier keys to be derived from later keys.

view details

joe.miyamoto

commit sha c2cd006e12f85fc43701cedbe32766a9524fc31c

Specify PrivateAssets="all" to Macaroon. * It seems that when dependendent project tries to restore DNL, program tries to search a nuget for package Macaroons. Which does not exist for netcoreapp, so it fails to restore. By including everything into DNL by specifying `PrivateAssets="all"`, hopefully it will succeed.

view details

joe.miyamoto

commit sha c63b16879302b798c2a245eb3ab7a026f22d26a1

Add reference from Core tests to macaroon. * Don't know why, but compiler complains that tests can not access Macaroons in BouncyCastleBuild when I specify PrivateAssets="all" for DNL.Core to Macaroons ProjectReference. this fixes test.

view details

Joe Miyamoto

commit sha 973ce39e16cdd6553acdcebda81c5b176e64cb8d

Merge branch 'master' into revocation-types

view details

Joe Miyamoto

commit sha 50dce21fb98d121878d5c4a7c8539dcee9b37772

Merge pull request #108 from canndrew/revocation-types Add and switch to new types for revocation

view details

joe.miyamoto

commit sha 6a284cbc3d64301d624aa74d80f28dfa6ac49cb6

Fix bug in Channel.firstClosingFee * when estimating fee for first closing tx, it was creating WitScript by `Scirpt(ourWitnesses).ToWitScript()` which was trying to deserialize script from literal sequence of bytes instead of treating ourWitnesses as a data which has to get pushed into stack as a wintess item, thus causing argument exception in `ToWitScript()`

view details

joe.miyamoto

commit sha 918ae1a172fb765dc072e85cf8ee5110c8455521

Add a getter for finalized tx when closing channel * Because without this client have no way to publish closing tx when mutually closing.

view details

joe.miyamoto

commit sha 853bd63ba9ff3c08c718b6b808fb83d2dc5769c5

Make explicit that tx must be broadcasted. * When closing mutually, The API consumer had to get FinalizedTx through ClosingData.FinalizedTx. But this is not straightforward, ideally the returned ChannelEvents must hold the object to perform side-effects directly. So add txToPublish field in MutualClosePerformed event. * Also, make the state simpler by holding only one `FinalizedTx` in `ClosingData` This is because I could not imagine the case that the node wants to broadcast more than one mutually-agreed closing tx.

view details

Joe Miyamoto

commit sha 7290aef035094743f38112c1ffb18da8454ec3a7

Merge pull request #110 from joemphilips/explicit_closing_tx Make explicit that tx must be broadcasted.

view details

joe.miyamoto

commit sha 6b16020e05825d07767c9ae813d4bd4df3385109

use `ECDSASignature.ToCompact` for signature serialization * NBitcoin has been updated to use `NBitcoin.Secp256k1`. * So methods which uses BigInteger are all obsolete.

view details

push time in a month

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 4ff61bde1f6d7ba9feb6dc74e12e06060e76ae3c

Mono-hop unidirectional payments

view details

push time in a month

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha f1d55575acf0346d6c0b4c9c2d1ba8557a84a613

Use MaxFeeRateMismatchRatio in checkRemoteFee The OpenChannelMsgValidation.checkRemoteFee method would reject any open_channel message with a fee rate less than the estimated fee rate, rather than using the provided MaxFeeRateMismatchRatio config option.

view details

Joe Miyamoto

commit sha bed8c3697ed8e3eb52bf1516e0f7f4b9bafa9e5b

Merge pull request #95 from canndrew/fee-rate-mismatch Use MaxFeeRateMismatchRatio in checkRemoteFee

view details

Andrew Cann

commit sha 2ee803e81c4f4f7fe1deb428ca700a6d414526cb

Perform validation on outgoing open_channel messages This allows DotNetLightning to catch problems with the specified channel parameters when opening a channel, rather than relying on the counterparty to reject the channel.

view details

Joe Miyamoto

commit sha 88d334a37b629bb2f1e7d2b165e9d0fd38971652

Merge pull request #97 from canndrew/outgoing-open-channel-validation Outgoing open channel validation

view details

joe.miyamoto

commit sha d4f2740982b3fe9f2e8f40687cfbef6e521e02e0

empty commit for publishing

view details

joe.miyamoto

commit sha af151953e2231f86f2454f70ccaad8513c8649c6

fix bug in PaymentRequest.TryCreate

view details

joe.miyamoto

commit sha ec54d6acdeabe73c949ad0c323da2baa6be1fff8

remove private modifier from TaggedField

view details

joe.miyamoto

commit sha 5644084877c99c8f1b3a467fdb145fc82f29775a

Change PaymentSecret to uint256 * When I first start coding BOLT11 invoice, I thought payment_secret field has something to do with paymentHash. But it is a completely independent concept. It is just a one-time token for authenticating payer in case of Basic-MPP. So it is natural to represent it as uint256 (length of the secret is specified to be 256-bit in BOLT 11)

view details

joe.miyamoto

commit sha 9f5c09c92630330d5fddf2724bc5d24807e63a0d

Re-pushing since nuget validation is running forever.

view details

Andrew Cann

commit sha 200b878e8f3844a6648ebc03f1d368b1c12a405e

Add Message member to error types Add a Message member to error types which returns an error message suitable for displaying to the user, in contrast with ToString which returns a debugging-friendly textual representation of the error object.

view details

Joe Miyamoto

commit sha 42c7cb9df14dec9e8687ef0095def7e0d65b24c2

Merge pull request #102 from canndrew/error-messages Add Message member to error types

view details

joe.miyamoto

commit sha 6398f8a0304d357a2b1b998115af3e1beb8e673e

Take IMessageSigner in `PaymentRequest`constructor * Previously, `PaymentRequest` was taking `Signature option` in its constructor. this is based on [equivalent method in eclair](https://github.com/ACINQ/eclair/blob/2e79ccaf3ff6e9b78c494a24b2cebcc27fabb07a/eclair-core/src/main/scala/fr/acinq/eclair/payment/PaymentRequest.scala#L41) This had two drawbacks. 1. API user should not care about what that signature is signed for. It is for `PaymentRequest.Hash` but this is private member and should be handled inside. 2. Giving `None` as that signature and calling `.ToString` will prints invoice without signature (which is invalid) Invoice should always contain a signature so option is not correct type here.

view details

joe.miyamoto

commit sha 23e9fa2e0eaef54670713fcebc2d9376c81187ad

add contructor overload to PaymentRequest * for convenience. * If an user does not use separate device for signing. They will probably just want to pass a `Key` instead of learning about `IMessageSigner`

view details

joe.miyamoto

commit sha bffe69c9f2e7e64c586752a05fc38eed8dbbada5

Fix bug when we get hrp from invoice. * Reported in https://github.com/joemphilips/DotNetLightning/issues/104 * When we match against hrp in actual invoice, we must first match against longest value. since we have both "lnbc" and "lnbcrt" But we were using directly from `Map` so the order was not guaranteed. * this commit also changed `List` to `Seq` for the sake of performance.

view details

joe.miyamoto

commit sha bb4b62a0c2f4307a4208de0d3570ff0be94bc76a

use Seq.tryHead when checking hrp in invoice * This is a hotfix for previous commit.

view details

joe.miyamoto

commit sha 02733fbfb5be08a9a84731bd9dfb99979d429057

Fix bug in Channel.firstClosingFee * when estimating fee for first closing tx, it was creating WitScript by `Scirpt(ourWitnesses).ToWitScript()` which was trying to deserialize script from literal sequence of bytes instead of treating ourWitnesses as a data which has to get pushed into stack as a wintess item, thus causing argument exception in `ToWitScript()`

view details

Andrew Cann

commit sha 5b6da44293807c05dc1c791ae6063aa9dea74cc0

Rename Msg to NetworkMsg in error types

view details

Andrew Cann

commit sha 220ba2b7bba96361577025542724ca36f89954ff

Mono-hop unidirectional payments

view details

push time in a month

PR opened nblockchain/DotNetLightning

Small error refactor
  • Add Message field to InvalidMonoHopUnidirectionalPaymentMsg.
  • Rename Msg field of errors to NetworkMsg.
+20 -13

0 comment

2 changed files

pr created time in 2 months

create barnchcanndrew/DotNetLightning

branch : add-message-field

created branch time in 2 months

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha f1d55575acf0346d6c0b4c9c2d1ba8557a84a613

Use MaxFeeRateMismatchRatio in checkRemoteFee The OpenChannelMsgValidation.checkRemoteFee method would reject any open_channel message with a fee rate less than the estimated fee rate, rather than using the provided MaxFeeRateMismatchRatio config option.

view details

Joe Miyamoto

commit sha bed8c3697ed8e3eb52bf1516e0f7f4b9bafa9e5b

Merge pull request #95 from canndrew/fee-rate-mismatch Use MaxFeeRateMismatchRatio in checkRemoteFee

view details

Andrew Cann

commit sha 2ee803e81c4f4f7fe1deb428ca700a6d414526cb

Perform validation on outgoing open_channel messages This allows DotNetLightning to catch problems with the specified channel parameters when opening a channel, rather than relying on the counterparty to reject the channel.

view details

Joe Miyamoto

commit sha 88d334a37b629bb2f1e7d2b165e9d0fd38971652

Merge pull request #97 from canndrew/outgoing-open-channel-validation Outgoing open channel validation

view details

joe.miyamoto

commit sha d4f2740982b3fe9f2e8f40687cfbef6e521e02e0

empty commit for publishing

view details

joe.miyamoto

commit sha af151953e2231f86f2454f70ccaad8513c8649c6

fix bug in PaymentRequest.TryCreate

view details

joe.miyamoto

commit sha ec54d6acdeabe73c949ad0c323da2baa6be1fff8

remove private modifier from TaggedField

view details

joe.miyamoto

commit sha 5644084877c99c8f1b3a467fdb145fc82f29775a

Change PaymentSecret to uint256 * When I first start coding BOLT11 invoice, I thought payment_secret field has something to do with paymentHash. But it is a completely independent concept. It is just a one-time token for authenticating payer in case of Basic-MPP. So it is natural to represent it as uint256 (length of the secret is specified to be 256-bit in BOLT 11)

view details

joe.miyamoto

commit sha 9f5c09c92630330d5fddf2724bc5d24807e63a0d

Re-pushing since nuget validation is running forever.

view details

Andrew Cann

commit sha 200b878e8f3844a6648ebc03f1d368b1c12a405e

Add Message member to error types Add a Message member to error types which returns an error message suitable for displaying to the user, in contrast with ToString which returns a debugging-friendly textual representation of the error object.

view details

Joe Miyamoto

commit sha 42c7cb9df14dec9e8687ef0095def7e0d65b24c2

Merge pull request #102 from canndrew/error-messages Add Message member to error types

view details

joe.miyamoto

commit sha 6398f8a0304d357a2b1b998115af3e1beb8e673e

Take IMessageSigner in `PaymentRequest`constructor * Previously, `PaymentRequest` was taking `Signature option` in its constructor. this is based on [equivalent method in eclair](https://github.com/ACINQ/eclair/blob/2e79ccaf3ff6e9b78c494a24b2cebcc27fabb07a/eclair-core/src/main/scala/fr/acinq/eclair/payment/PaymentRequest.scala#L41) This had two drawbacks. 1. API user should not care about what that signature is signed for. It is for `PaymentRequest.Hash` but this is private member and should be handled inside. 2. Giving `None` as that signature and calling `.ToString` will prints invoice without signature (which is invalid) Invoice should always contain a signature so option is not correct type here.

view details

joe.miyamoto

commit sha 23e9fa2e0eaef54670713fcebc2d9376c81187ad

add contructor overload to PaymentRequest * for convenience. * If an user does not use separate device for signing. They will probably just want to pass a `Key` instead of learning about `IMessageSigner`

view details

joe.miyamoto

commit sha bffe69c9f2e7e64c586752a05fc38eed8dbbada5

Fix bug when we get hrp from invoice. * Reported in https://github.com/joemphilips/DotNetLightning/issues/104 * When we match against hrp in actual invoice, we must first match against longest value. since we have both "lnbc" and "lnbcrt" But we were using directly from `Map` so the order was not guaranteed. * this commit also changed `List` to `Seq` for the sake of performance.

view details

joe.miyamoto

commit sha bb4b62a0c2f4307a4208de0d3570ff0be94bc76a

use Seq.tryHead when checking hrp in invoice * This is a hotfix for previous commit.

view details

joe.miyamoto

commit sha 5d228cd4c21562b05e30bff9d4f6e594ef80f6ca

Support LSAT. * Macaroons are Based on https://github.com/JornWildt/Macaroons.Net * Strictly speaking this is an API layer thing. So I wasn't sure I should include it in here. * But it seems people in lightning lab are trying to standardize its use for LN-powered authentication * `VerifyLSATCaveats` extension method is a main entrypoint for the api consumer.

view details

Joe Miyamoto

commit sha 176587ea495bafe01e59fd22959263b7ec13ed95

Merge pull request #101 from joemphilips/macaroon add package for macaroon and its test

view details

joe.miyamoto

commit sha 2d9903f2418a87b0dcf3a1f8663280818efbf006

Specify PrivateAssets="all" for Macaroon

view details

joe.miyamoto

commit sha 9705855d3e890fa3258dd60734e57b8160132e18

Fix BouncyCastle test failure for macaroon. * Macaroon uses nacl(libsodium)-based cryptographic operation for third party caveats. before this commit, Macaroon.csproj was depending on NSec, so it was incompatible with BouncyCastle build. By excluding deps to NSec and delay initializing the cryptographic parts of `Macaroon` , Nsec wont get included in `DotNetLightning.Core` for BouncyCastle build. * We do not support third party caveats for BouncyCastle build we may change our mind later, but for now, third party caveats are not defined in LSAT spec and it is not even used in lnd, so this is ok.

view details

joe.miyamoto

commit sha 416fb3fdac1f955cd8f0077999ddc38cda488175

Skip macaroon tests which uses third party caveats. * Since Third party caveats are only supported through DotNetLightning.Core. This is because third-party caveats uses cryptographic operation. and we want to change the actual implementation in DotNetLightning.Core

view details

push time in 2 months

pull request commentjoemphilips/DotNetLightning

Add and switch to new types for revocation

Thanks. I've fixed the nits (I didn't know about ToBytes or deref).

canndrew

comment created time in 2 months

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 974723f7163132c0aa81ac97a183646b512a55fc

Add and switch to new types for revocation Add the UInt48, RevocationKey, CommitmentPubKey, CommitmentSeed and RevocationSet types. A RevocationKey is a secret key that can be used to revoke a transaction. It's shared in the revoke_and_ack message and stored in the user's wallet in a RevocationSet. A CommitmentPubKey is the public key of a RevocationKey, also known as a "per commitment point". A CommitmentSeed is the master revocation key for a side of a channel and can be used to derive all the revocation keys for that side of that channel. A RevocationSet stores a set of revocation keys in a compact form specified in BOLT #3 which allows earlier keys to be derived from later keys.

view details

push time in 2 months

PR opened joemphilips/DotNetLightning

Add and switch to new types for revocation

Add the UInt48, RevocationKey, CommitmentPubKey, CommitmentSeed and RevocationSet types.

A RevocationKey is a secret key that can be used to revoke a transaction. It's shared in the revoke_and_ack message and stored in the user's wallet in a RevocationSet. A CommitmentPubKey is the public key of a RevocationKey, also known as a "per commitment point". A CommitmentSeed is the master revocation key for a side of a channel and can be used to derive all the revocation keys for that side of that channel.

A RevocationSet stores a set of revocation keys in a compact form specified in BOLT #3 which allows earlier keys to be derived from later keys.

+907 -225

0 comment

30 changed files

pr created time in 2 months

create barnchcanndrew/DotNetLightning

branch : revocation-types

created branch time in 2 months

pull request commentjoemphilips/DotNetLightning

Add `Msg` suffix to message type names

I've prefixed Msg to some variable names. There's a lot of variables that aren't named after the message type so I didn't search through and find them all.

canndrew

comment created time in 2 months

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 321eba1957760b7c182bc02fa25d122fad0b8f0a

Append Msg to the names of some variables In order to bring the variable names more in-line with the new type names from the previous commit.

view details

push time in 2 months

Pull request review commentjoemphilips/DotNetLightning

Add `Msg` suffix to message type names

 module Channel =                 let localParams = state.InitFundee.LocalParams                 let channelKeys = state.InitFundee.ChannelKeys                 let localCommitmentSecret = ChannelUtils.buildCommitmentSecret (channelKeys.CommitmentSeed, 0UL)-                let acceptChannel = { AcceptChannel.TemporaryChannelId = msg.TemporaryChannelId-                                      DustLimitSatoshis = localParams.DustLimitSatoshis-                                      MaxHTLCValueInFlightMsat = localParams.MaxHTLCValueInFlightMSat-                                      ChannelReserveSatoshis = localParams.ChannelReserveSatoshis-                                      HTLCMinimumMSat = localParams.HTLCMinimumMSat-                                      MinimumDepth = cs.Config.ChannelHandshakeConfig.MinimumDepth-                                      ToSelfDelay = localParams.ToSelfDelay-                                      MaxAcceptedHTLCs = localParams.MaxAcceptedHTLCs-                                      FundingPubKey = channelKeys.FundingKey.PubKey-                                      RevocationBasepoint = channelKeys.RevocationBaseKey.PubKey-                                      PaymentBasepoint = channelKeys.PaymentBaseKey.PubKey-                                      DelayedPaymentBasepoint = channelKeys.DelayedPaymentBaseKey.PubKey-                                      HTLCBasepoint = channelKeys.HTLCBaseKey.PubKey-                                      FirstPerCommitmentPoint = localCommitmentSecret.PubKey-                                      ShutdownScriptPubKey = cs.Config.ChannelOptions.ShutdownScriptPubKey }-+                let acceptChannel: AcceptChannelMsg = {

I moved the type annotation

let acceptChannel = { AcceptChannel.TemporaryChannelId
                      ^^^^^^^^^^^^^
                                   - from here
let acceptChannel: AcceptChannelMsg {
                   ^^^^^^^^^^^^^^^^
                                   - to here

Because another similar line of code in the file required me to (because adding the suffix screwed up the indentation).

Adding the suffix to the variable name is a good idea too though. I'll edit the commit.

canndrew

comment created time in 2 months

PR opened joemphilips/DotNetLightning

Add `Msg` suffix to message type names

This makes code that handles messages more comprehensible.

+527 -517

0 comment

29 changed files

pr created time in 2 months

create barnchcanndrew/DotNetLightning

branch : rename-msg-types

created branch time in 2 months

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 8a94bafff84da7eae1441dd19cfaf761b1e64c4c

Use MaxFeeRateMismatchRatio in checkRemoteFee The OpenChannelMsgValidation.checkRemoteFee method would reject any open_channel message with a fee rate less than the estimated fee rate, rather than using the provided MaxFeeRateMismatchRatio config option.

view details

Andrew Cann

commit sha c18f1646cc4a87d2226128263d59ecd452eac36e

Perform validation on outgoing open_channel messages This allows DotNetLightning to catch problems with the specified channel parameters when opening a channel, rather than relying on the counterparty to reject the channel.

view details

Andrew Cann

commit sha 2ebd15e08a6bb56d67aac999ca5073c4dbbf98e7

Add Message member to error types Add a Message member to error types which returns an error message suitable for displaying to the user, in contrast with ToString which returns a debugging-friendly textual representation of the error object.

view details

push time in 2 months

Pull request review commentjoemphilips/DotNetLightning

Add Message member to error types

 type ChannelError =         | InvalidOperationAddHTLC _ -> Ignore         | RemoteProposedHigherFeeThanBefore(_, _) -> Close     -    override this.ToString() =+    member this.Message =

.NET's exceptions have distinct ToString and Message members. The point is that Message gives a user-friendly string and ToString dumps a textual representation of the entire error object, including the exact value of all the fields.

What prompted this change is that geewallet was printing error message that looked like this:

Error opening channel: Peer responded to our open_channel with an error message: Invalid open_channel from the peer. 
 { Msg =
       { Chainhash =
                    6fe28c0ab6f1b372c1a6a246ae63f74f931e8365e15a089c68d6190000000000
         TemporaryChannelId =
                             ChannelId
                               05a54268153a61c35ded693133aaeeb3c3ac12903e4e4dac215f05aeb5ef9a05
         FundingSatoshis = 0.00030000
         PushMSat = LNMoney 0L
         DustLimitSatoshis = 0.00000005
         MaxHTLCValueInFlightMsat = LNMoney 5000L
         ChannelReserveSatoshis = 0.00000300
         HTLCMinimumMsat = LNMoney 1000L
         FeeRatePerKw = FeeRatePerKw 16357u
         ToSelfDelay = BlockHeightOffset16 6us
         MaxAcceptedHTLCs = 10us
         FundingPubKey =
                        02d39a4e5a41ab40d158684daf16651de2f87a8a8b8e0bf4167a99da52b3be2272
         RevocationBasepoint =
                              03c21ad70f41bb9fc6efa36853c88266c0ca0d48ee61734f4e86380d5e5b46ebe0
         PaymentBasepoint =
                           0249aee64aab597d30e80e11ae4464f9a1b3e2beefdcd2be7535a41b6c4173cf6a
         DelayedPaymentBasepoint =
                                  03d987ff1a55a5a8aae8368970f2d9fa6d2d71a33b4c2441dab60b33c37eff979c
         HTLCBasepoint =
                        02760a472b45b1315db70931378c727367147520a7938389048b021a7c0f072973
         FirstPerCommitmentPoint =
                                  027dfbdea98d8271f924b64b698af2f0995362afe47454c76e70bb7254e78b9ecd
         ChannelFlags = 0uy
         ShutdownScriptPubKey =
                               Some
                                 OP_HASH160 2f24ec0dfc2a1beddb3619f38b62737b19e28d6c OP_EQUAL }
  Errors =
          ["their open_channel msg is invalid";
           "Suitable channel reserve not found. Aborting. (our channel reserve was (0.00000300). and our dust limit was(0.00001701))";
           "channel_reserve_satoshis too small. It was: 0.00000300; but our dust_limit is: 0.00001701"] }

Dumping the Msg field like that isn't really good UX. Plus the error that's being printed there even has an Errors field consisting of a list of strings that look intended to be displayed to the user.

The error type in this case is InvalidOpenChannelError. With this PR that type still has its built-in ToString method which prints all of the above and is useful for developers, but it also has a Message method which returns a concatenation of the Errors strings (separated by ;). So geewallet just calls Message when it displays the error to the user.

canndrew

comment created time in 2 months

pull request commentjoemphilips/DotNetLightning

Add Message member to error types

Telling anything to the user about HTLC doesn't seem to be user-friendly at all.

The only error messages that mention HTLCs are ones that indicate protocol violations by one or other of the parties, not ones that users should normally see. If a user does see one then giving them the details of the error seems strictly better than not giving it to them, and it allows them to file a useful bug report.

canndrew

comment created time in 2 months

Pull request review commentjoemphilips/DotNetLightning

Add Message member to error types

 type ChannelError =         | InvalidOperationAddHTLC _ -> Ignore         | RemoteProposedHigherFeeThanBefore(_, _) -> Close     -    override this.ToString() =+    member this.Message =

This will still have a ToString method. It will just be the default one which prints the contents of the object, which is what you want for debugging.

canndrew

comment created time in 2 months

PR opened joemphilips/DotNetLightning

Add Message member to error types

Add a Message member to error types which returns an error message suitable for displaying to the user, in contrast with ToString which returns a debugging-friendly textual representation of the error object.

This MR also expands on and attempts to improve some of the existing error messages.

+112 -13

0 comment

7 changed files

pr created time in 2 months

create barnchcanndrew/DotNetLightning

branch : error-messages

created branch time in 2 months

issue closedACINQ/eclair-mobile

Unusual formula for measuring the fee rate mismatch

The formula eclair uses for calculating the difference between two fee rates is:

  /**
   * @param referenceFeePerKw reference fee rate per kiloweight
   * @param currentFeePerKw   current fee rate per kiloweight
   * @return the "normalized" difference between i.e local and remote fee rate: |reference - current| / avg(current, reference)
   */
  def feeRateMismatch(referenceFeePerKw: Long, currentFeePerKw: Long): Double =
    Math.abs((2.0 * (referenceFeePerKw - currentFeePerKw)) / (currentFeePerKw + referenceFeePerKw))

This seems a bit odd to me. If the reference fee rate is 1btc and the current fee rate is 0.0001btc then the average of the two will be (approximately) 0.5btc - which is half the reference fee rate but 500 times the current fee rate. It would make more sense to measure this on a log scale so that an infinite difference (in terms of orders-of-magnitude) becomes an infinite feeRateMismatch, rather than a feeRateMismatch of 2.

Is it worth changing the formula to |log(reference) - log(current)|? (And also changing the name of the config option to avoid silently changing its meaning?)

closed time in 2 months

canndrew

issue commentACINQ/eclair-mobile

Unusual formula for measuring the fee rate mismatch

Oops, sorry. I've ported the issue here: https://github.com/ACINQ/eclair/issues/1438

canndrew

comment created time in 2 months

issue openedACINQ/eclair

Unusual formula for measuring the fee rate mismatch

The formula eclair uses for calculating the difference between two fee rates is:

  /**
   * @param referenceFeePerKw reference fee rate per kiloweight
   * @param currentFeePerKw   current fee rate per kiloweight
   * @return the "normalized" difference between i.e local and remote fee rate: |reference - current| / avg(current, reference)
   */
  def feeRateMismatch(referenceFeePerKw: Long, currentFeePerKw: Long): Double =
    Math.abs((2.0 * (referenceFeePerKw - currentFeePerKw)) / (currentFeePerKw + referenceFeePerKw))

This seems a bit odd to me. If the reference fee rate is 1btc and the current fee rate is 0.0001btc then the average of the two will be (approximately) 0.5btc - which is half the reference fee rate but 5000 times the current fee rate. It would make more sense to measure this on a log scale so that an infinite difference (in terms of orders-of-magnitude) becomes an infinite feeRateMismatch, rather than a feeRateMismatch of 2.

Is it worth changing the formula to |log(reference) - log(current)|? (And also changing the name of the config option to avoid silently changing its meaning?)

created time in 2 months

issue openedlightningnetwork/lightning-rfc

Problem with only the funder being able to control the fee rate

Suppose I open a channel when the fee rate is low. Since I'm the funder, it's my responsibility to keep enough money in the channel to pay for the closing transaction. Now suppose that the on-chain fee rate increases. As the funder, I'm the only one who can send an update_fee message to reflect the change, yet I have no incentive to do so since doing so would lower my spendable balance in the channel. Instead I can keep sending htlcs and bring my balance well below what will be required to close the channel given the true fee rate, yet the counterparty can't reject my htlcs since according to agreed-upon fee rate I'm still in the black.

Is there something I'm missing or is this a problem? Is there a reason why the spec only allows the funder to send update_fee messages, rather than allowing either party to re-negotiate the fees at any time?

created time in 2 months

issue openedACINQ/eclair-mobile

Unusual formula for measuring the fee rate mismatch

The formula eclair uses for calculating the difference between two fee rates is:

  /**
   * @param referenceFeePerKw reference fee rate per kiloweight
   * @param currentFeePerKw   current fee rate per kiloweight
   * @return the "normalized" difference between i.e local and remote fee rate: |reference - current| / avg(current, reference)
   */
  def feeRateMismatch(referenceFeePerKw: Long, currentFeePerKw: Long): Double =
    Math.abs((2.0 * (referenceFeePerKw - currentFeePerKw)) / (currentFeePerKw + referenceFeePerKw))

This seems a bit odd to me. If the reference fee rate is 1btc and the current fee rate is 0.0001btc then the average of the two will be (approximately) 0.5btc - which is half the reference fee rate but 500 times the current fee rate. It would make more sense to measure this on a log scale so that an infinite difference (in terms of orders-of-magnitude) becomes an infinite feeRateMismatch, rather than a feeRateMismatch of 2.

Is it worth changing the formula to |log(reference) - log(current)|? (And also changing the name of the config option to avoid silently changing its meaning?)

created time in 2 months

create barnchcanndrew/DotNetLightning

branch : kiss-outgoing-open-channel-validation

created branch time in 2 months

Pull request review commentjoemphilips/DotNetLightning

Outgoing open channel validation

 module internal ChannelHelpers = module internal Validation =      open DotNetLightning.Channel-+    let checkOurOpenChannelMsgAcceptable (conf: ChannelConfig) (msg: OpenChannel) =+        Validation.ofResult(OpenChannelMsgValidation.checkFundingSatoshisLessThanMax msg)+        *^> OpenChannelMsgValidation.checkChannelReserveSatohisLessThanFundingSatoshis msg+        *^> OpenChannelMsgValidation.checkPushMSatLesserThanFundingValue msg+        *^> OpenChannelMsgValidation.checkFundingSatoshisLessThanDustLimitSatoshis msg+        *^> OpenChannelMsgValidation.checkMaxAcceptedHTLCs msg+        *^> OpenChannelMsgValidation.checkFunderCanAffordFee (msg.FeeRatePerKw) msg+        |> Result.mapError(InvalidOpenChannelError.Create msg >> InvalidOpenChannel)

Done. I've added a similar message for their open_channel message too.

canndrew

comment created time in 2 months

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 2ee803e81c4f4f7fe1deb428ca700a6d414526cb

Perform validation on outgoing open_channel messages This allows DotNetLightning to catch problems with the specified channel parameters when opening a channel, rather than relying on the counterparty to reject the channel.

view details

push time in 2 months

pull request commentjoemphilips/DotNetLightning

Fix checkIfFundersAmountSufficient

This PR has been superseded by #97.

canndrew

comment created time in 3 months

PR opened joemphilips/DotNetLightning

Outgoing open channel validation

This builds off of #95 and can be rebased if any further changes occur on that PR.

This PR adds validation to the CreateOutbound channel command which enforces that the channel parameters are sensible - ie. that the channel wouldn't be rejected by any sane and spec-compliant peer.

It also removes the (unused) checkIfFundersAmountSufficient function and moves one of it's checks into a new checkFunderCanAffordFee function. The other two checks were unnecessary and overly restrictive. One of them checked that push_msat is greater than the fundee's channel_reserve, which is unlikely to ever be the case. The other checked that the funder's initial channel balance minus their channel reserve is enough to cover commitment tx fees. This is also unnecessary since a channel is closed when a commitment tx is broadcast and so the channel reserve is no longer relevant. Simply checking that the funder's initial balance is enough to cover the fee is sufficient.

+44 -29

0 comment

3 changed files

pr created time in 3 months

create barnchcanndrew/DotNetLightning

branch : outgoing-open-channel-validation

created branch time in 3 months

Pull request review commentjoemphilips/DotNetLightning

Use MaxFeeRateMismatchRatio in checkRemoteFee

 module private ValidationHelper = /// Helpers to create channel error [<AutoOpen>] module internal ChannelError =+    let feeRateMismatch (FeeRatePerKw remote, FeeRatePerKw local) =+        (2.0 * float (remote - local) / float (remote + local))

I've fixed this.

canndrew

comment created time in 3 months

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha f1d55575acf0346d6c0b4c9c2d1ba8557a84a613

Use MaxFeeRateMismatchRatio in checkRemoteFee The OpenChannelMsgValidation.checkRemoteFee method would reject any open_channel message with a fee rate less than the estimated fee rate, rather than using the provided MaxFeeRateMismatchRatio config option.

view details

push time in 3 months

pull request commentjoemphilips/DotNetLightning

Use MaxFeeRateMismatchRatio in checkRemoteFee

To me, "ratio" conveys a rational number, and not necessarily in the range (0, 1). Also, there's no reason why the MaxFeeRateMismatchRatio in this case can't be greater than 1. It would be silly to set it that high, but it would also be silly to set it higher than about 0.5. There's nothing inherently special about the value 1 in that formula.

canndrew

comment created time in 3 months

PR closed joemphilips/DotNetLightning

Fix checkIfFundersAmountSufficient

OpenChannelMsgValidation.checkIfFundersAmountSufficient incorrectly only fails if both the channel amounts are less than their channel reserves, rather than if either of them are.

This fixes the bug.

+1 -1

4 comments

1 changed file

canndrew

pr closed time in 3 months

pull request commentjoemphilips/DotNetLightning

Fix checkIfFundersAmountSufficient

I'm going to make another PR that splits this function into two and removes the toLocalMSat <= (msg.ChannelReserveSatoshis.ToLNMoney()) check.

canndrew

comment created time in 3 months

pull request commentjoemphilips/DotNetLightning

Fix checkIfFundersAmountSufficient

Actually this function is broken as-is. It checks whether push_msat is larger than the channel reserve but this shouldn't be expected to be the case. The counterparty is allowed to have less than channel_reserve funds in the channel to start with, they're just not allowed to make payments that bring them below the channel reserve.

canndrew

comment created time in 3 months

pull request commentjoemphilips/DotNetLightning

Fix checkIfFundersAmountSufficient

I just noticed that this function isn't actually called from anywhere, though it seems that it should be called from the channel validation module. Is this just an oversight?

canndrew

comment created time in 3 months

PR opened joemphilips/DotNetLightning

Fix checkIfFundersAmountSufficient

OpenChannelMsgValidation.checkIfFundersAmountSufficient incorrectly only fails if both the channel amounts are less than their channel reserves, rather than if either of them are.

This fixes the bug.

+1 -1

0 comment

1 changed file

pr created time in 3 months

create barnchcanndrew/DotNetLightning

branch : open-channel-fee-rate-check

created branch time in 3 months

pull request commentjoemphilips/DotNetLightning

Use MaxFeeRateMismatchRatio in checkRemoteFee

One thing I noticed when doing this is that the MaxFeeRateMismatchRatio option is used weirdly. Given that it has "ratio" in the name, I would expect a value of 1.0 to mean that the fee rates must match exactly, a fee rate of 0.5 or 2.0 to mean that the counterparty's fee rate must be between 50% to 200% of ours, and so forth. In the code though, the formula for calculating the "ratio" is:

let feeRateMismatch (FeeRatePerKw remote, FeeRatePerKw local) =
    (2.0 * float (remote - local) / float (remote + local))
    |> abs

Which means a value of 1.0 actually corresponds to the fee rates being allowed to differ by 33-300 percent, a value of 0.0 means they must match, etc.

Should this config option be re-named or should this formula be modified?

canndrew

comment created time in 3 months

PR opened joemphilips/DotNetLightning

Use MaxFeeRateMismatchRatio in checkRemoteFee

The OpenChannelMsgValidation.checkRemoteFee method rejects any open_channel message with a fee rate less than the estimated fee rate. This PR changes it to use the provided MaxFeeRateMismatchRatio config option.

+14 -10

0 comment

2 changed files

pr created time in 3 months

create barnchcanndrew/DotNetLightning

branch : fee-rate-mismatch

created branch time in 3 months

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha bbc27ea8b30cd94c37b1adcbc42018bed5013d88

Mono-hop unidirectional payments

view details

push time in 3 months

PR opened rust-lang/futures-rs

Add oneshot::Sender::is_connected_to method

I was gonna open an issue asking for this, but it was trivial to implement so I figured I'd just go straight to a PR.

This adds a method to oneshot::Sender to check whether it's connected to a given Receiver:

/// Tests to see whether this `Sender` is connected to the given `Receiver`. That is, whether
/// they were created by the same call to `channel`.
pub fn is_connected_to(&self, receiver: &Receiver<T>) -> bool {
    Arc::ptr_eq(&self.inner, &receiver.inner)
}

Does this seem like a good idea? It would be useful for me.

+6 -0

0 comment

1 changed file

pr created time in 3 months

create barnchcanndrew/futures-rs

branch : oneshot-connected

created branch time in 3 months

Pull request review commentnblockchain/DotNetLightning

Mono-hop unidirectional payments

 type ChannelState =             | ErrFundingLost _             | ErrFundingTimeOut _             | ErrInformationLeak _ -> Abnormal++        member this.Commitments: Option<Commitments> =+            match this with+            | WaitForInitInternal+            | WaitForOpenChannel _+            | WaitForAcceptChannel _+            | WaitForFundingCreated _+            | WaitForFundingSigned _ -> None+            | WaitForFundingConfirmed data -> Some (data :> IHasCommitments).Commitments+            | WaitForFundingLocked data -> Some (data :> IHasCommitments).Commitments+            | Normal data -> Some (data :> IHasCommitments).Commitments+            | Shutdown data -> Some (data :> IHasCommitments).Commitments+            | Negotiating data -> Some (data :> IHasCommitments).Commitments+            | Closing data -> Some (data :> IHasCommitments).Commitments+            | Closed _+            | Offline _+            | Syncing _+            | ErrFundingLost _+            | ErrFundingTimeOut _+            | ErrInformationLeak _ -> None++        member this.SpendableBalance: Option<LNMoney> =+            match this.Commitments with+            | None -> None+            | Some commitments ->+                let remoteCommit =+                    match commitments.RemoteNextCommitInfo with+                    | RemoteNextCommitInfo.Waiting info -> info.NextRemoteCommit+                    | RemoteNextCommitInfo.Revoked _info -> commitments.RemoteCommit+                let reducedRes =+                    remoteCommit.Spec.Reduce(+                        commitments.RemoteChanges.ACKed,+                        commitments.LocalChanges.Proposed+                    )+                let reduced =+                    match reducedRes with+                    | Error err ->+                        failwithf+                            "reducing commit failed even though we have not proposed any changes\+                            error: %A"+                            err+                    | Ok reduced -> reduced+                let fees =+                    if commitments.LocalParams.IsFunder then+                        Transactions.commitTxFee commitments.RemoteParams.DustLimitSatoshis reduced+                        |> LNMoney.FromMoney+                    else+                        LNMoney.Zero+                let channelReserve =+                    commitments.RemoteParams.ChannelReserveSatoshis+                    |> LNMoney.FromMoney+                let totalBalance = reduced.ToRemote+                let untrimmedSpendableBalance = totalBalance - channelReserve - fees+                let htlcSuccessFee =+                    reduced.FeeRatePerKw.ToFee(Transactions.Constants.HTLC_SUCCESS_WEIGHT)+                    |> LNMoney.FromMoney+                let htlcFee =+                    reduced.FeeRatePerKw.ToFee(Transactions.Constants.COMMITMENT_TX_WEIGHT_PER_HTLC)

Fixed.

canndrew

comment created time in 3 months

Pull request review commentnblockchain/DotNetLightning

Mono-hop unidirectional payments

 type LNMoney = | LNMoney of int64 with         let satoshi = Checked.op_Multiply (amount) (decimal lnUnit)         LNMoney(Checked.int64 satoshi) +    static member FromMoney (money: Money) =+        LNMoney.Satoshis(money.Satoshi)

Fixed.

canndrew

comment created time in 3 months

Pull request review commentnblockchain/DotNetLightning

Mono-hop unidirectional payments

 type ChannelState =             | ErrFundingLost _             | ErrFundingTimeOut _             | ErrInformationLeak _ -> Abnormal++        member this.Commitments: Option<Commitments> =+            match this with+            | WaitForInitInternal+            | WaitForOpenChannel _+            | WaitForAcceptChannel _+            | WaitForFundingCreated _+            | WaitForFundingSigned _ -> None+            | WaitForFundingConfirmed data -> Some (data :> IHasCommitments).Commitments+            | WaitForFundingLocked data -> Some (data :> IHasCommitments).Commitments+            | Normal data -> Some (data :> IHasCommitments).Commitments+            | Shutdown data -> Some (data :> IHasCommitments).Commitments+            | Negotiating data -> Some (data :> IHasCommitments).Commitments+            | Closing data -> Some (data :> IHasCommitments).Commitments+            | Closed _+            | Offline _+            | Syncing _+            | ErrFundingLost _+            | ErrFundingTimeOut _+            | ErrInformationLeak _ -> None++        member this.SpendableBalance: Option<LNMoney> =+            match this.Commitments with+            | None -> None+            | Some commitments ->+                let remoteCommit =+                    match commitments.RemoteNextCommitInfo with+                    | RemoteNextCommitInfo.Waiting info -> info.NextRemoteCommit+                    | RemoteNextCommitInfo.Revoked _info -> commitments.RemoteCommit+                let reducedRes =+                    remoteCommit.Spec.Reduce(+                        commitments.RemoteChanges.ACKed,+                        commitments.LocalChanges.Proposed+                    )+                let reduced =+                    match reducedRes with+                    | Error err ->+                        failwithf+                            "reducing commit failed even though we have not proposed any changes\+                            error: %A"+                            err+                    | Ok reduced -> reduced+                let fees =+                    if commitments.LocalParams.IsFunder then+                        Transactions.commitTxFee commitments.RemoteParams.DustLimitSatoshis reduced+                        |> LNMoney.FromMoney+                    else+                        LNMoney.Zero+                let channelReserve =+                    commitments.RemoteParams.ChannelReserveSatoshis+                    |> LNMoney.FromMoney+                let totalBalance = reduced.ToRemote+                let untrimmedSpendableBalance = totalBalance - channelReserve - fees+                let htlcSuccessFee =+                    reduced.FeeRatePerKw.ToFee(Transactions.Constants.HTLC_SUCCESS_WEIGHT)

Fixed.

canndrew

comment created time in 3 months

Pull request review commentnblockchain/DotNetLightning

Mono-hop unidirectional payments

 module internal AcceptChannelMsgValidation =          (check1 |> Validation.ofResult) *^> check2 *^> check3 *^> check4 *^> check5 *^> check6 *^> check7         +module UpdateMonoHopUnidirectionalPaymentWithContext =+    let internal checkWeHaveSufficientFunds (state: Commitments) (currentSpec) =+        let fees =+            if state.LocalParams.IsFunder then+                Transactions.commitTxFee (state.RemoteParams.DustLimitSatoshis) currentSpec

Fixed.

canndrew

comment created time in 3 months

Pull request review commentnblockchain/DotNetLightning

Mono-hop unidirectional payments

 type Commitments = {             match remoteSigned, localSigned with             | Some _, Some htlcIn -> htlcIn.Add |> Some             | _ -> None++        member this.SpendableBalance(): LNMoney =+            let remoteCommit =+                match this.RemoteNextCommitInfo with+                | RemoteNextCommitInfo.Waiting info -> info.NextRemoteCommit+                | RemoteNextCommitInfo.Revoked _info -> this.RemoteCommit+            let reducedRes =+                remoteCommit.Spec.Reduce(+                    this.RemoteChanges.ACKed,+                    this.LocalChanges.Proposed+                )+            let reduced =+                match reducedRes with+                | Error err ->+                    failwithf+                        "reducing commit failed even though we have not proposed any changes\+                        error: %A"+                        err+                | Ok reduced -> reduced+            let fees =+                if this.LocalParams.IsFunder then+                    Transactions.commitTxFee this.RemoteParams.DustLimitSatoshis reduced+                    |> LNMoney.FromMoney+                else+                    LNMoney.Zero+            let channelReserve =+                this.RemoteParams.ChannelReserveSatoshis+                |> LNMoney.FromMoney+            let totalBalance = reduced.ToRemote+            let untrimmedSpendableBalance = totalBalance - channelReserve - fees+            let htlcSuccessFee =+                reduced.FeeRatePerKw.ToFee(Transactions.Constants.HTLC_SUCCESS_WEIGHT)

I've removed the HTLC fees from the calculation and created a seperate PR which adds them back here: #3

canndrew

comment created time in 3 months

Pull request review commentnblockchain/DotNetLightning

Mono-hop unidirectional payments

 and InvalidAcceptChannelError = {         Errors = e     }     +and InvalidMonoHopUnidirectionalPaymentError = {+    Msg: MonoHopUnidirectionalPayment+    Errors: string list+}+    with+    static member Create msg e = {

Done.

canndrew

comment created time in 3 months

PR opened nblockchain/DotNetLightning

Make Commitments.SpendableBalance HTLC-aware

This builds off of #2.

Make Commitments.SpendableBalance consider HTLC fees when calculating the maximum payment size.

+341 -19

0 comment

16 changed files

pr created time in 3 months

create barnchcanndrew/DotNetLightning

branch : spendable-balance-htlc-aware

created branch time in 3 months

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha 98e6c90f8991a50c2b99eda4d924c6bc3b77a664

Mono-hop unidirectional payments

view details

Andrew Cann

commit sha 6d9db4dc36ef10d5432152756c7686816b7e7f07

Fix github workflow to upload BouncyCastle build With this commit the BouncyCastle build is uploaded as DotNetLightning.Kiss and the native build is not uploaded.

view details

Andrew Cann

commit sha c1f1e5f748980ef1b1ef439309f0b24279b33974

Remove InvalidMonoHopUnidirectionalPaymentError.Create method

view details

Andrew Cann

commit sha e8beb8e6edbc4d23d15313bcdc703148db740795

DO NOT MERGE - Remove dust limit check

view details

push time in 3 months

Pull request review commentnblockchain/DotNetLightning

Mono-hop unidirectional payments

 and InvalidAcceptChannelError = {         Errors = e     }     +and InvalidMonoHopUnidirectionalPaymentError = {+    Msg: MonoHopUnidirectionalPayment+    Errors: string list+}+    with+    static member Create msg e = {

I can do. All the other invalid msg types have it though, though they all seem equally pointless. Is it important to be consistent here?

canndrew

comment created time in 3 months

push eventcanndrew/DotNetLightning

Andrew Cann

commit sha d5d8c8c956dd2eb64be6158910b85d4cccd0ca2f

Mono-hop unidirectional payments

view details

Andrew Cann

commit sha 99310ddae302f71fb3d62fbda32f4b9c3be50546

Remove dust limit check

view details

Andrew Cann

commit sha 3a593645e42e0dc76657f716638c67406f35fb01

Fix github workflow to upload BouncyCastle build With this commit the BouncyCastle build is uploaded as DotNetLightning.Kiss and the native build is not uploaded.

view details

push time in 3 months

Pull request review commentnblockchain/DotNetLightning

Mono-hop unidirectional payments

 jobs:       run: |         cd $GITHUB_WORKSPACE/src/DotNetLightning.Core         dotnet pack . -p:Configuration=Release --version-suffix date`date +%Y%m%d-%H%M`-git-`echo $GITHUB_SHA | cut -c 1-7`-${{ matrix.RID }}-        dotnet nuget push ./bin/Release/DotNetLightning.Core.1*.nupkg -k ${{ secrets.NUGET_API_KEY }} -s https://api.nuget.org/v3/index.json\ No newline at end of file+        dotnet nuget push ./bin/Release/DotNetLightning.Kiss.1*.nupkg -k ${{ secrets.NUGET_API_KEY }} -s https://api.nuget.org/v3/index.json

Oops. I've fixed it so that we only upload the BouncyCastle build and we upload it as DotNetLightning.Kiss

canndrew

comment created time in 3 months

more