Re: [Lightning-dev] Receiving via unpublished channels
Hi, ZmnSCPxj. I want to ask the other LN implementations (lnd, eclair, ucoin, lit) if we should consider standardizing this behavior (i.e. send `channel_update` after lockin regardless of published/unpublished state). ucoin/ptarmigan does not support `r` field yet(just decode and discards it). Regards, nayuta-ueno (https://github.com/nayutaco/ptarmigan) On 2018/04/27 8:35, ZmnSCPxj via Lightning-dev wrote: Good morning list, While implementing support for `r` field in invoices, I stumbled upon some issues regarding *creating* invoices with `r` fields. In order to receive via an unpublished channel, we need to know what onLightning fees the other side of that channel wants to charge. We cannot use our own onLightning fees because our fees apply if we were forwarding to the other side. However, in case of an unpublished channel, we do not send channel_announcement, and in that case we do not send channel_update. So the other side of the channel never informs us of the onLightning fees they want to charge if we would receive funds by this channel. An idea we want to consider is to simply send `channel_update` as soon as we lock in the channel: https://github.com/ElementsProject/lightning/pull/1330#issuecomment-383931817 I want to ask the other LN implementations (lnd, eclair, ucoin, lit) if we should consider standardizing this behavior (i.e. send `channel_update` after lockin regardless of published/unpublished state). It seems back-compatible: software which does not expect this behavior will simply drop the `channel_update` (as they do not follow a `channel_announcement`). In any case, what was the intended way to get the onLightning fee rates to put into invoice `r` fields for private routes? Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Scriptless Scripts with ECDSA
FWIW, Conner pointed out that the initial ZK Proof for the correctness of the Paillier params (even w/ usage of bulletproofs) has multiple rounds of interaction, iirc up to 5+ (with additional pipelining) rounds of interaction. -- Laolu On Mon, May 7, 2018 at 5:14 PM Olaoluwa Osuntokun wrote: > Actually, just thought about this a bit more and I think it's possible to > deploy this in unison with (or after) any sort of SS based on schnorr > becomes > possible in Bitcoin. My observation is that since both techniques are > based on > the same underlying technique (revealing a secret value in a signature) and > they center around leveraging the onion payload to drop off a payment point > (G*a, or G*a_1*a_2*a_3, etc), then the disclosure within the _links_ can be > heterogeneous, as the same secret is still revealed in an end-to-end > matter. > > As an illustration, consider: A <-> B <-> C. The A <-> B link could use > the 2pc > pailier technique, while the B <-> C link could use the OG SS technique > based > on schnorr. If i'm correct, then this would mean that we can deploy both > techniques, without worrying about fragmenting the network due to the > existence > of two similar but incompatible e2e payment routing schemes! > > -- Laolu > > > On Mon, May 7, 2018 at 4:57 PM Olaoluwa Osuntokun > wrote: > >> Hi Pedro, >> >> Very cool stuff! When I originally discovered the Lindell's technique, my >> immediate thought was the we could phase this in as a way to >> _immediately_ (no >> additional Script upgrades required), replace the regular 2-of-2 >> mulit-sig with >> a single p2wkh. The immediate advantages of this would: be lower fees for >> opening/closing channels (as the public key script, and witness are >> smaller), >> openings and cooperative close transactions would blend in with the >> anonymity >> set of regular p2wkh transactions, and finally the htlc timeout+success >> transactions can be made smaller as we can remove the multi-sig. The >> second >> benefit is nerfed a bit if the channel are advertised, but non-advertised >> channels would be able to take advantage of this "stealth" feature. >> >> The upside of the original application I hand in mind is that it wouldn't >> require any end-to-end changes, as it would only be a link level change >> (diff >> output for the funding transaction). If we wanted to allow these styles of >> channels to be used outside of non-advertised channels, then we would >> need to >> update the way channels are verified in the gossip layer. >> >> Applying this to the realm of allowing us to use randomized payment >> identifiers >> across the route is obviously much, much doper. So then the question >> would be >> what the process of integrating the scheme into the existing protocol >> would >> look like. The primary thing we'd need to account for is the additional >> cryptographic overhead this scheme would add if integrated. Re-reviewing >> the >> paper, there's an initial setup and verification phase (which was omitted >> from >> y'alls note for brevity) where both parties need to complete before the >> actually signing process can take place. Ideally, we can piggy-back this >> setup >> on top of the existing accept_channel/open_channel dance both sides need >> to go >> through in order to advance the channel negotiation process today. >> >> Conner actually started to implement this when we first discovered the >> scheme, >> so we have a pretty good feel w.r.t the implementation of the initial set >> of >> proofs. The three proofs required for the set up phase are: >> >> 1. A proof that that the Paillier public key is well formed. In the >> paper >> they only execute this step for the party that wishes to _obtain_ the >> signature. In our case, since we'll need to sign for HTLCs in both >> directions, but parties will need to execute this step. >> >> 2. A dlog proof for the signing keys themselves. We already do this >> more or >> less, as if the remote party isn't able to sign with their target key, >> then >> we won't be able to update the channel, or even create a valid >> commitment in >> the first place. >> >> 3. A proof that value encrypted (the Paillier ciphertext) is actually >> the >> dlog of the public key to be used for signing. (as an aside this is the >> part >> of the protocol that made me do a double take when first reading it: >> using one >> cryptosystem to encrypt the private key of another cryptosystem in >> order to >> construct a 2pc to allow signing in the latter cryptosystem! soo >> clever!) >> >> First, we'll examine the initial proof. This only needs to be done once >> by both >> parties AFAICT. As a result, we may be able to piggyback this onto the >> initial >> channel funding steps. Reviewing the paper cited on the Lindell paper >> [1], it >> appears this would take 1 RTT, so this shouldn't result in any additional >> round >> trips during the funding process. We should be able to use a Paillier >> modulos >> o
Re: [Lightning-dev] Scriptless Scripts with ECDSA
Actually, just thought about this a bit more and I think it's possible to deploy this in unison with (or after) any sort of SS based on schnorr becomes possible in Bitcoin. My observation is that since both techniques are based on the same underlying technique (revealing a secret value in a signature) and they center around leveraging the onion payload to drop off a payment point (G*a, or G*a_1*a_2*a_3, etc), then the disclosure within the _links_ can be heterogeneous, as the same secret is still revealed in an end-to-end matter. As an illustration, consider: A <-> B <-> C. The A <-> B link could use the 2pc pailier technique, while the B <-> C link could use the OG SS technique based on schnorr. If i'm correct, then this would mean that we can deploy both techniques, without worrying about fragmenting the network due to the existence of two similar but incompatible e2e payment routing schemes! -- Laolu On Mon, May 7, 2018 at 4:57 PM Olaoluwa Osuntokun wrote: > Hi Pedro, > > Very cool stuff! When I originally discovered the Lindell's technique, my > immediate thought was the we could phase this in as a way to _immediately_ > (no > additional Script upgrades required), replace the regular 2-of-2 mulit-sig > with > a single p2wkh. The immediate advantages of this would: be lower fees for > opening/closing channels (as the public key script, and witness are > smaller), > openings and cooperative close transactions would blend in with the > anonymity > set of regular p2wkh transactions, and finally the htlc timeout+success > transactions can be made smaller as we can remove the multi-sig. The second > benefit is nerfed a bit if the channel are advertised, but non-advertised > channels would be able to take advantage of this "stealth" feature. > > The upside of the original application I hand in mind is that it wouldn't > require any end-to-end changes, as it would only be a link level change > (diff > output for the funding transaction). If we wanted to allow these styles of > channels to be used outside of non-advertised channels, then we would need > to > update the way channels are verified in the gossip layer. > > Applying this to the realm of allowing us to use randomized payment > identifiers > across the route is obviously much, much doper. So then the question would > be > what the process of integrating the scheme into the existing protocol would > look like. The primary thing we'd need to account for is the additional > cryptographic overhead this scheme would add if integrated. Re-reviewing > the > paper, there's an initial setup and verification phase (which was omitted > from > y'alls note for brevity) where both parties need to complete before the > actually signing process can take place. Ideally, we can piggy-back this > setup > on top of the existing accept_channel/open_channel dance both sides need > to go > through in order to advance the channel negotiation process today. > > Conner actually started to implement this when we first discovered the > scheme, > so we have a pretty good feel w.r.t the implementation of the initial set > of > proofs. The three proofs required for the set up phase are: > > 1. A proof that that the Paillier public key is well formed. In the paper > they only execute this step for the party that wishes to _obtain_ the > signature. In our case, since we'll need to sign for HTLCs in both > directions, but parties will need to execute this step. > > 2. A dlog proof for the signing keys themselves. We already do this more > or > less, as if the remote party isn't able to sign with their target key, > then > we won't be able to update the channel, or even create a valid > commitment in > the first place. > > 3. A proof that value encrypted (the Paillier ciphertext) is actually the > dlog of the public key to be used for signing. (as an aside this is the > part > of the protocol that made me do a double take when first reading it: > using one > cryptosystem to encrypt the private key of another cryptosystem in order > to > construct a 2pc to allow signing in the latter cryptosystem! soo clever!) > > First, we'll examine the initial proof. This only needs to be done once by > both > parties AFAICT. As a result, we may be able to piggyback this onto the > initial > channel funding steps. Reviewing the paper cited on the Lindell paper [1], > it > appears this would take 1 RTT, so this shouldn't result in any additional > round > trips during the funding process. We should be able to use a Paillier > modulos > of 2048 bits, so nothing too crazy. This would just result in a slightly > bigger > opening message. > > Skipping the second proofs as it's pretty standard. > > The third proof as described (Section 6 of the Lindell paper) is > interactive. > It also contains a ZK range proof as a sub-protocol which as described in > Appendix A is also interactive. However, it was pointed out to us by Omer > Shlomovits on the lnd slack, that we can actual
Re: [Lightning-dev] Scriptless Scripts with ECDSA
> It is also not clear to me how well B-N signature aggregation can work for > Lightning use-cases; certainly onchain claims of unilateral closes can be > made smaller with signature aggregation, but for mutual closes, there is > only one input, unless we support close aggregation somehow >From the PoV, the two-stage HTLCs, depending on how cross-input sigagg was implemented, this would allow us (using sighash_single+anyone_can_pay) to coalesce all the second-layer HTLCs for a particularly state+party into a single transaction with a single signature spending all HTLCs to the second layer/stage. -- Laolu On Sun, Apr 29, 2018 at 9:23 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning Pedro, > > This is certainly of great interest to me; unfortunately I am not a > mathematician and probably cannot review if the math is correct or not. In > particular it seems to me, naively, to be able to implement my AMP idea > which supports both path decorrelation and proof-of-payment, which is based > on SS and HD. > > The Lightning BOLT 1.0 spec is mostly frozen and we have good > inter-implementation working of HTLCs. Supporting SS, whether on top of > ECDSA or Bellare-Neven, will be a large effort, and it is not clear to me > if it is easy to switch between ECDSA and Bellare-Neven dynamically (i.e. > if one hop supports ECDSA SS and the next hop supports Bellare-Neven SS). > > It is also not clear to me how well B-N signature aggregation can work for > Lightning use-cases; certainly onchain claims of unilateral closes can be > made smaller with signature aggregation, but for mutual closes, there is > only one input, unless we support close aggregation somehow (involving more > than two parties, so much more effort). A 2-of-2 with a single signature > (which I believe is the basis of your SS work?) would let the mutual close > and commitment transactions be smaller by one signature and one pubkey, > though. > > At the Lightning BOLT spec level: > > 1. We need a new global feature bit, `option_support_scriptless`, which > would support routing of scriptless-script conditional payments. Paying > via SS can only be done if the entire route supports this option, which may > hamper adoption and complicate routing implementations (cannot route an SS > payment through nodes that do not support SS). > > 2. Depending on how easy it would be to translate between ECDSA and > Bellare-Neven SS, maybe only a local-level feature bit for > `option_support_scriptless_ecdsa` and `option_support_scriptless_bn`? > > 3. Also affects BOLT11 as we would have to support both `SHA256(secret)` > and `secret * G` in invoices, with the latter being used for SS payments. > > 4. We may want intra-path decorrelation (indeed, aside from AMP, this is > the other use of SS on Lightning). This requires passing a blinding secret > to each layer of the onion in the onion routes, I think (?). > > > Regards, > ZmnSCPxj > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Scriptless Scripts with ECDSA
Hi Pedro, Very cool stuff! When I originally discovered the Lindell's technique, my immediate thought was the we could phase this in as a way to _immediately_ (no additional Script upgrades required), replace the regular 2-of-2 mulit-sig with a single p2wkh. The immediate advantages of this would: be lower fees for opening/closing channels (as the public key script, and witness are smaller), openings and cooperative close transactions would blend in with the anonymity set of regular p2wkh transactions, and finally the htlc timeout+success transactions can be made smaller as we can remove the multi-sig. The second benefit is nerfed a bit if the channel are advertised, but non-advertised channels would be able to take advantage of this "stealth" feature. The upside of the original application I hand in mind is that it wouldn't require any end-to-end changes, as it would only be a link level change (diff output for the funding transaction). If we wanted to allow these styles of channels to be used outside of non-advertised channels, then we would need to update the way channels are verified in the gossip layer. Applying this to the realm of allowing us to use randomized payment identifiers across the route is obviously much, much doper. So then the question would be what the process of integrating the scheme into the existing protocol would look like. The primary thing we'd need to account for is the additional cryptographic overhead this scheme would add if integrated. Re-reviewing the paper, there's an initial setup and verification phase (which was omitted from y'alls note for brevity) where both parties need to complete before the actually signing process can take place. Ideally, we can piggy-back this setup on top of the existing accept_channel/open_channel dance both sides need to go through in order to advance the channel negotiation process today. Conner actually started to implement this when we first discovered the scheme, so we have a pretty good feel w.r.t the implementation of the initial set of proofs. The three proofs required for the set up phase are: 1. A proof that that the Paillier public key is well formed. In the paper they only execute this step for the party that wishes to _obtain_ the signature. In our case, since we'll need to sign for HTLCs in both directions, but parties will need to execute this step. 2. A dlog proof for the signing keys themselves. We already do this more or less, as if the remote party isn't able to sign with their target key, then we won't be able to update the channel, or even create a valid commitment in the first place. 3. A proof that value encrypted (the Paillier ciphertext) is actually the dlog of the public key to be used for signing. (as an aside this is the part of the protocol that made me do a double take when first reading it: using one cryptosystem to encrypt the private key of another cryptosystem in order to construct a 2pc to allow signing in the latter cryptosystem! soo clever!) First, we'll examine the initial proof. This only needs to be done once by both parties AFAICT. As a result, we may be able to piggyback this onto the initial channel funding steps. Reviewing the paper cited on the Lindell paper [1], it appears this would take 1 RTT, so this shouldn't result in any additional round trips during the funding process. We should be able to use a Paillier modulos of 2048 bits, so nothing too crazy. This would just result in a slightly bigger opening message. Skipping the second proofs as it's pretty standard. The third proof as described (Section 6 of the Lindell paper) is interactive. It also contains a ZK range proof as a sub-protocol which as described in Appendix A is also interactive. However, it was pointed out to us by Omer Shlomovits on the lnd slack, that we can actually replace their custom range proofs with Bulletproofs. This would make this section non-interactive, allowing the proof itself to take 1.5 RTT AFAICT. Additionally, this would only need to be done once at the start, as AFIACT, we can re-use the encryption of the secp256k1 private key of both parties. The current channel opening process requires 2 RTT, so it seems that we'd be able to easily piggy back all the opening proofs on top of the existing funding protocol. The main cost would be the increased size of these opening messages, and also the additional computational cost of operations within the Paillier modulus and the new range proof. The additional components that would need to be modified are the process of adding+settling an HTLC, and also the onion payload that drops off the point whose dlog is r_1*alpha. Within the current protocol, adding and settling an HTLC are more or less non-interactive, we have a single message for each, which is then staged to be committed in new commitments for both parties. With this new scheme (if I follow it correctly), adding an HTLC now requires N RTT: 1. Alice sends A = G*alpha to Bob. He
Re: [Lightning-dev] Receiving via unpublished channels
Good morning Olauluwa It is Ptarmigan Lightning Network project from Nayuta Ueno/Nayutaco: https://github.com/nayutaco/ptarmigan Name of daemon is ucoind, CLI is ucoincli. Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] BIP sighash_noinput
Given the general enthusiasm, and lack of major criticism, for the `SIGHASH_NOINPUT` proposal, I'd like to formally ask the BBEs (benevolent BIP editors) to be assigned a BIP number. I have hacked together a simple implementation of the hashing implementation in Bitcoin Core [1] though I think it's unlikely to sail through review, and given the lack of ground-work on witness V1 scripts, I can't really test it now, and only the second commit is part of the implementation itself. One issue that was raised off list was that some fork coins have used sighash 0x40 as FORKID. This does not conflict with this proposal since the proposal only applies to segwit transactions, which the fork coins have explicitly disabled :-) I'm looking forward to discussing how to we can move forward to implementing this proposal, and how we can combine multiple proposals into the next soft-fork. Cheers, Christian [1] https://github.com/cdecker/bitcoin/tree/noinput ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Receiving via unpublished channels
AFAIK, all the other implementations already do this (lnd does at least [1]). As otherwise, it wouldn't be possible to properly utilize routing hints. > I want to ask the other LN implementations (lnd, eclair, ucoin, lit) As an side, what's "ucoin"? Searched for a bit and didn't find anything notable. [1]: https://github.com/lightningnetwork/lnd/blob/master/discovery/gossiper.go#L1747 On Thu, Apr 26, 2018 at 4:35 PM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning list, > > While implementing support for `r` field in invoices, I stumbled upon some > issues regarding *creating* invoices with `r` fields. > > In order to receive via an unpublished channel, we need to know what > onLightning fees the other side of that channel wants to charge. We cannot > use our own onLightning fees because our fees apply if we were forwarding > to the other side. > > However, in case of an unpublished channel, we do not send > channel_announcement, and in that case we do not send channel_update. So > the other side of the channel never informs us of the onLightning fees they > want to charge if we would receive funds by this channel. > > An idea we want to consider is to simply send `channel_update` as soon as > we lock in the channel: > https://github.com/ElementsProject/lightning/pull/1330#issuecomment-383931817 > > I want to ask the other LN implementations (lnd, eclair, ucoin, lit) if we > should consider standardizing this behavior (i.e. send `channel_update` > after lockin regardless of published/unpublished state). It seems > back-compatible: software which does not expect this behavior will simply > drop the `channel_update` (as they do not follow a `channel_announcement`). > > In any case, what was the intended way to get the onLightning fee rates to > put into invoice `r` fields for private routes? > > Regards, > ZmnSCPxj > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
