Re: [Lightning-dev] Peer selection

Good morning Stan, >How to I discover nodes - is there any UI to see nodes currently >running on the network ? There are no UIs to my knowledge. Current LN programs keep track of this in their databases, although each one varies in detail. Presumably their individual main developers know how

Re: [Lightning-dev] Peer selection

Good morning Stan, The protocol allows nodes to be behind Tor hidden services (.onion domain names). Tor hidden services automatically have NAT punching and firewall traversal, as long as the firewall allows Tor protocol to go through. I do not know if there are already LN software that

Re: [Lightning-dev] Peer Selection

Good morning Stan, Money is safe when network is down only if you only pay out of your node. Once you receive, it is possible for your counterparty to transmit an invalid old state where it owns more money than you do. Then you need to monitor the blockchain for invalid closings of channel

Re: [Lightning-dev] Comments on BOLT#11

Good morning Jonathan, >3. Descriptions say they can encode ASCII only. Sorry, but this is nonsense. >Full unicode support via UTF8 should be supported. I generally agree, but caution must be warned here. In particular, we should be precise, which variant of UTF8. Presumably, a naive

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

Re: [Lightning-dev] Scriptless Scripts with ECDSA

Good morning Benjamin, Your caution is laudable, I think. > Yes, bitcoin is wise to at least hash the pub key until use. Granted, > lightning (necessarily?) risks public key exposure, but in a pinch there are > other signature algorithms for lightning to move to. Lightning cannot *quickly*

Re: [Lightning-dev] eltoo Trustless WatchTowers

Good morning Laolu, >> However, this has the drawback that each update of a single channel will >> generate a `(txid[:16], blob)` pair that has the same `txid[:16]` key, >> letting the WatchTower correlate the timing and number of updates of each of >> your channels. > > On the other hand, going

Re: [Lightning-dev] Mitigations for loop attacks

Good morning Jim, > One more point in terms of information leakage is that noise can be added to > the "this is the rate that you'll lose reputation at" field to help obfuscate > the number of upstream hops. I proposed setting it to "this is the upstream > rate that I'm losing reputation at" +

Re: [Lightning-dev] Receiving via unpublished channels

Good morning nayuto-ueno, > `r` field doesn't contain signature like `channel_update`. > > Do c-lightning check something in the `r` field from payee's invoice? > No. Invoice has signature for whole invoice. Of course, only payee signature (fee of this channel is fee from the peer of the

Re: [Lightning-dev] Preventing delay abuse in a Lightning-based peer-to-peer exchange

Good morning Corne, It seems to me that exchange delay abuse and the loop attack in the other thread have the same attack vector, namely delaying up to just before the delay period before responding. So mitigations for one should apply as mitigations of the other. Regards, ZmnSCPxj ​Sent

Re: [Lightning-dev] Including a Protocol for splicing to BOLT

Good morning Laolu, >> but even though it seems technically straight forward t > > Well the full async implementation may be a bit involved, depending on the > architecture of the implementation (see the second point below). > > In the abstract, I'd say a splicing proposal should include the

Re: [Lightning-dev] Mesh network problem

Good morning Joseph, > I root for the Lightening Network’s success, but it seems to have an inherent > weakness. Since routing tables are not part of the architecture how can the > sender chose the next recipient so as to effect an efficient path to the > ultimate receiver? With no routing

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

Good morning Christian, It seems to me we can remove the trigger transaction. The observation is that `nSequence`-encumbered transactions are only settlement transactions and not any update transactions. Thus, it is not needed for a trigger transaction to exist, if we can make update

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

Good morning Christian, This is very interesting indeed! I have started skimming through the paper. I am uncertain if the below text is correct? > Throughout this paper we will use the terms *input script* to refer to > `witnessProgram` and `scriptPubKey`, and *output script* to refer to the

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

Hi Christian, Let me know if I have summarized the paper accurately below: 1. SIGHASH_NOINPUT removes all inputs of the transaction copy before signing/verifying. 2. SIGHASH_NOINPUT can be combined with SIGHASH_SINGLE. It is dangerous to combine it with SIGHASH_NONE (as this also deletes

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

Good morning Carsten, > > The setup transaction is simply a transaction that spends some funds and > > > > creates a single output, which has the script from Figure 2, but since > > > > that would be a forward reference, I decided to handwave and call it a > > > > multisig. A simple fix would

Re: [Lightning-dev] Invoice without amount

Good morning Cezary, Currently, c-lightning can PAY amountless invoices via the "pay" command, but cannot CREATE them via the c-lightning "invoice" command. To pay an amountless invoice lntb... 4 satoshis in c-lightning: lightning-cli pay lntb.. 4000 However the internals of c-lightning

Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message

Good morning all, Looking at BOLT#1, there is an `error` message which is supposed to "fail the channel". At a first glance, it seems to be what is basically a superpowered version of `funding_cancelled`, since it only fails the channel (and in particular does not indicate to fail the peer or

Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message

I do not see the relevance of the example. The limit I propose that nodes will impose is a limit imposed on *each* *peer*, not a limit imposed on all peers in total. Indeed, imposing the limit on each peer reduces the actual CPU, bandwidth, and storage resources that each peer can consume on

Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message

Good morning Matt, Sent with [ProtonMail](https://protonmail.com) Secure Email. > Original Message > Subject: Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message > Local Time: January 15, 2018 9:00 AM > UTC Time: January 15, 2018 1:00 AM > From:

Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message

Good morning Matt, > I can't imagine the constants add up that fast... Allow 25 channels per peer > and limit your peers reasonably and the cost should be low enough. Really not > sure why something like a 25 channel limit should limit any usage or > reasonably burden a node, what am I

Re: [Lightning-dev] channel_reserve_satoshis?

Good morning Cezary, > When we send open_channel, how we can communicate other party that we would > like him to put into channel some of his funds? There is no way to do that as of BOLT v1.0 There are too many issues to allow channel opening by somebody else to ask your node to commit money

Re: [Lightning-dev] channel_reserve_satoshis?

Good morning Cezary, > I think first two options are for those, who want to earn some money for > payments fee. The option that can be interesting for for some business like > coffee is third option. Do you agree with me? > >> 3. In all likelihood, some service later will offer deals like "up

Re: [Lightning-dev] An Idea to Improve Connectivity of the Graph

Good morning Abhishek Sharma, While the goal of the idea is good, can you provide more details on the Bitcoin transactions? Presumably the on-chain anchor is a 3-of-3 multisig UTXO, what is the transaction that spends that? What do Lightning commitment transactions spend? Can you draw a

Re: [Lightning-dev] channel_reserve_satoshis?

Good morning Cezary, > Lets say I would like to receive ln payments. How can I do this, without > locking funds on the other side of channel? 1. Do the Blockstream Store route: do it early enough, and people will make channels to you, because, they want to try out Lightning Network quickly.

Re: [Lightning-dev] channel_reserve_satoshis?

Good Morning Cezary, > This is quite good way to replace both-funding channels by such "superhub". > It would be even easier if I could open more then single channel between both > parties, but I saw this is not possible in c-lightning. From a risk perspective, you have increased risk in

Re: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning

Good morning Cezary, > That would be great improvement, if AMP could work this way: > > 1. I would like to send 0.1 BTC, so I split this to 5 payment 0.02 BTC each + > one extra 0.02 BTC payment. > 2. When recipient received 6 htlcs, he is able to spend only 5 of them. > If recipient receives,

Re: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning

Good morning Christian and Corne, Another idea to consider, is techniques like ZKCP and ZKCSP, which provide atomic access to information in exchange for monetary compensation. Ensuring atomicity of the exchange can be done by providing the information encrypted, a hash of the encryption key,

Re: [Lightning-dev] Proof of payment (Re: AMP: Atomic Multi-Path Payments over Lightning)

up >> the preimage. >>TL;DR: I'm not convinced the signed invoice + hash is really a good >> yardstick >> by which to measure provability, and I think doing some research into >> proofs >> of payment on stronger statements would be incredibly valuable. T

Re: [Lightning-dev] Improving the initial gossip sync

Good morning Rusty, ​>4. query_short_channel_id > = > > >5. type: 260 (query_short_channel_id) > >6. data: > - [32:chain_hash] > > - [8:short_channel_id] > > This is general mechanism which lets you query for a > channel_announcement and channel_updates for a specific

Re: [Lightning-dev] Privacy issues with proof of payment

Good morning Corne, My understanding, it would be possible to remove proof-of-payment selectively by hiding the payment in fees. Basically, to anonymously donate money to a node without leaving proof of who you are, you simply route from yourself to the payee node, then back to yourself. You

Re: [Lightning-dev] Pizza for (lightning) bitcoins?

Good morning Robert, Since you want a delivery time within 3 blocks or it is free, the last hop has to be to your node from the pizza provider, meaning a direct channel between you. And if you already have a channel between you, you probably will want to use that channel. However in

[Lightning-dev] Replaceable Funding Transactions

Good morning list, Reading the BOLT spec, and considering the common issue of slow transaction confirmation on the blockchain level, I want to ask the list if it is possible to use replaceable (replace-by-fee) funding transactions, at the current 1.0 BOLT v1.0 has a below suggestion: > A

Re: [Lightning-dev] General questions about channels

Good morning Andy, > Andy Schroder > > On 12/27/2017 12:18 AM, Andy Schroder wrote: > >>> Channel closing >>> costs dwarf the gains to be made from cheating, however. >>> Since millisatoshis is used, is there a maximum channel funding size? >>> >>> Yes, the upper 32 bits must be zero, from

Re: [Lightning-dev] SegWit and LN

Good morning Praveen, For some background please consider the article I wrote: https://zmnscpxj.github.io/offchain/generalized.html Especially "Requirements on the Blockchain". For cases where the funding transaction is funded by only one side, then full SegWit is not needed, "only" some kind

Re: [Lightning-dev] Free Rebalancing Proposals

Good morning Robert, > Good Morning ZmnSCPxj! > > I was thinking using the normal onion-routing, probably modified in some way > so it can read and modify max. Must admit I haven't studied that part at that > level at all. > > For simple three-member constructs it could be enough with a simple

Re: [Lightning-dev] Both-side funded channels

Good morning Cezary, An issue is that this potentially leaks private information. If I request you to fund 1BTC and you accept, then I close the channel, then I request you to fund 2BTC and you decline, then I have a good guess, that your funds are between 1 BTC to 2 BTC. There are ways to

Re: [Lightning-dev] Including a Protocol for splicing to BOLT

Good morning all, > > What's the nasty compromise? > > > > Let's also not underestimate how big of an update switching to dlog based > > > > HTLCs will be. > > Was referring to losing proof-of-payment; that's vital in a system > > without intermediaries. We have to decide what the lesser evil

Re: [Lightning-dev] Rebalancing argument

Good morning, I believe care must be taken for automatic rebalancing. Suppose we start in this state: A 1.0|\1.0 | \ 1.0| \1.0 B---C 1.0 1.0 Then A pays to B 1.0 BTC: A 0.0|\1.0 | \ 2.0| \1.0 B---C 1.0 1.0 In an effort to balance, B

Re: [Lightning-dev] [bitcoin-dev] BIP sighash_noinput

Good morning DING FENG, While your concern is valid, the general intent is the below: 1. We will use a scary name like SIGHASH_NOINPUT_UNSAFE to explicitly inform to wallet and Bitcoin software developers that the flag is potentially unsafe. 2. SIGHASH_NOINPUT_UNSAFE is intended to be used

Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message

As mentioned in the text, this is imposed by you on each peer that connects to you. The point is to prevent a single peer from consuming all your memory and CPU and prevent you from servicing legitimate peers- i.e. it prevents denial of service using a single peer and forces attackers to use a

Re: [Lightning-dev] Both-side funded channels

Good morning Giovanni, > I agree with you, Cezary, and was in tears of joy when read about that > "plan to implement possibility of both-side funding channels", as it > would be immensely beneficial for the growth of network. > > I think ZmnSCPxj is misreading that as something mandatory, or >

Re: [Lightning-dev] New form of 51% attack via lightning's revocation system possible?

Good morning Rene, The attack is possible but requires the combination of the below: 1. A large 51% miner. 2. Many channels share-owned by the miner. 3. Large capacities in each channel share-owned by the miner. Individual nodes can protect against these as below: 1. Contributing hashpower

Re: [Lightning-dev] A protocol for requesting invoices

Good morning Corne, > routing. You could consider the start of the partial route as an > > "introduction point"; it is selected by the payee(**). I'm not sure if > > it is exactly equivalent to TOR's introduction points though. It is almost equivalent I think. > > 2.

[Lightning-dev] Cyclic Superhubs

Good morning list, For your amusement. https://zmnscpxj.github.io/offchain/cyclicsuperhubs.html Regards, ZmnSCPxj___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] A protocol for requesting invoices

Good morning Andy, > > > giving new alternatives > > > > > > interactively is another option. I think using the same "introduction > > > > > > point" for all routes is best for privacy: otherwise the payer could > > > > > > determine the neighborhood of the payee. > >

Re: [Lightning-dev] A protocol for requesting invoices

Good morning Corne, You mention URLs in your draft. This made me remember about the Web Payments Working Group of W3C, https://www.w3.org/Payments/WG/ , of which Decker, Christian of Blockstream is a member: https://www.w3.org/2000/09/dbwg/details?group=83744=1 My understanding is that

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Good morning Tyler, > The external party idea is interesting, but I'm fearful that it can't be done > in a way that retains a bare minimum of privacy. No, of course not. "Private" channels are privacy sieves and should not be used by privacy-conscious entities. Since the channel is never

[Lightning-dev] Closing Transaction Cut-through as a Generalization of Splice-in/Splice-out

Good morning list, I have the below speculation idea. Suppose, rather than implement a splice-in/splice-out ("channel top-up", etc.) we instead implement a more general "cut-through" for a channel close transaction. Normally a channel close spends a single input and makes 1 or 2 outputs.

Re: [Lightning-dev] Lightning over NFC

Good morning Igor, This is quite an interesting use-case for Lightning. However it seems to me that the payer will need a direct channel to the payee, or at least the payment terminal (of the payee...?). In addition the payer will need to somehow get blockchain information from the payee if

Re: [Lightning-dev] An Idea to Improve Connectivity of the Graph

Good morning Alejandro, There is no assumption involved, merely a large number of questions. In a retaliation construction, if a party misbehaves, the other party gets the entire amount they are working on together, as disincentive for any party to cheat. That works for the two-party case A

Re: [Lightning-dev] Lightning over NFC

> > Why would there need to be a direct channel between payer and payee? We > > have the Lightning network to avoid needing direct channels, right? > > CJP > > Op 05-04-18 om 17:39 schreef ZmnSCPxj via Lightning-dev: > > > Good morning Igor, > > > > T

Re: [Lightning-dev] An Idea to Improve Connectivity of the Graph

Good morning Alejandro, I was about to ask Christian this myself. There is another technique: Use a sequence of `nSequence`d transactions off-chain. For example, to get an 2-bit counter, you would have: funding -> kickoff -> bit1 -> bit0 Only funding is onchain. kickoff, bit1, and bit0

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Good morning Tyler, > I will continue to approach the problem of securely advertising > human-understandable node names, and I hope someday soon I will have a > solution Lightning can use that retains the open, decentralized properties of > the technology and the underlying blockchains. I

Re: [Lightning-dev] High level fee mechanics

Good morning Alejandro, >> No, channel balance of each peer on the channel is not revealed on node >> gossip. >> >> Logically, invert the question: do you want to report how much you >> spend/receive on each of your channels to the network? Do you want to report >> how much you own on

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Good morning Tyler, > This is not the intention. This BOLT _does not_ replace bootstrapping seed > functionality, now or ever. A client can supplement her view of the network > by getting the graph from well-known nodes if she wishes, but no more. To do > otherwise _would_ centralize the

Re: [Lightning-dev] Closing Transaction Cut-through as a Generalization of Splice-in/Splice-out

Good morning Christian, > > The connection the channel factories is not really necessary, as long as > > we have an invalidation scheme that allows us to invalidate a prior > > funding transaction we can reseat without needing a cut-through, just > > invalidate the funding tx of the old

Re: [Lightning-dev] High level fee mechanics

Good morning Benjamin, Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐ On April 13, 2018 4:37 AM, Benjamin Mord wrote: > Thank you, ZmnSCPxj. > > "... by adjusting the on-Lightning `fee_base_msat` and > `fee_proportional_millionths`

Re: [Lightning-dev] High level fee mechanics

Good morning Thomas, > Does node GOSSIP also reveal the funding/balance of channels, same way it > does the fees? > > I'm trying to understand how to make an informed payment routing decision as > a sender, based on the fees (that you have already explained), but also the > funding/balance of

Re: [Lightning-dev] Trustless WatchTowers?

Good morning Conner, > Hi ZmnSCPxj, > >> Can you describe the "encrypted blob" approach to me? Or point me to >> materials? > > There's an awesome watchtower thread on the mailing list from 2016 that starts > here [1]. It covers a broader range of possibilities than just the encrypted > blob

Re: [Lightning-dev] Commitment delay asymmetry

Good morning Jim, >> It seems to me that adding an entire new attack vector in order to only >> *mitigate* (not eliminate!) another attack vector is not a good enough >> trade-off. In particular the new attack seems *easier* to perform. The >> current attack where I annoy the other side

Re: [Lightning-dev] Decker-Wattenhofer channels (was: An Idea to Improve Connectivity of the Graph)

Good morning Christian, > That is a very good observation. Indeed the absolute timelocks need to > > be far enough in the future so that we can commit the latest branch of > > the invalidation tree on-chain and then commit the HTLC resolution > > before the HTLC timeout expires. That means that

Re: [Lightning-dev] Commitment delay asymmetry

Good morning all, It seems to me the below two worlds are possible: 1. Symmetric delays. 1.1. I can attack passively: I force a condition where most funds are in the other side (e.g. forwarding to another node I control, or exchanging BTC for material goods), then stop forwarding payments

[Lightning-dev] Trustless WatchTowers?

Hi all, Nicolas Dorier was requesting additional hooks in c-lightning for a simple WatchTower system: https://github.com/ElementsProject/lightning/issues/1353 Unfortunately I was only able to provide an interface which requires a *trusted* WatchTower. Trust is of course a five-letter word and

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Good morning Tyler, Offhand, I am uncertain the first script given in "Technical Proposal" works as a "check proof-of-work" script. Are the "[]" comments? Or are they pushes of actual data embedded in the SCRIPT? It seems to be comments...? OP_CheckLockTimeVerify is absolute time, not

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Good morning Tyler, > I like the efficiency your method brings and I'm also not that enthused about > bloating the blockchain with "non-financial data", however I do think there's > value in having the data live in the base chain, both from accessibility and > censorship resistance of the data

Re: [Lightning-dev] Towards a gridlike Lightning Network

Good morning Benjamin, > I think there are two distinct concepts here. The first is the identification > of a 'neighborhood', and the second is the establishment of an order within > that neighborhood for purpose of cycle formation. > > Your use of bloom filters to define a neighborhood, is I

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Good morning, CLTV < unix epoch is for absolute lock time measured sanely in blocks, while > unix epoch is for absolute lock time measured in that arbitrary human-preferred unit called "seconds". I believe you mean CSV, as that is for relative lock time measured in blocks (but note that it

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

Good morning Tyler, > Great points. IsStandard() is something I hadn't considered yet, but I think > miners are incentivized to want Numerifides transactions as a registration > will need a solid miners fee, and "revoked" names will cause escalating fee > wars that the miners can just soak

Re: [Lightning-dev] Trustless WatchTowers?

Good morning Laolu, > Hi ZmnSCPxj, > >> It seems to me, that the only safe way to implement a trustless WatchTower, >> is for the node to generate a fully-signed justice transaction, IMMEDIATELY >> after every commitment transaction is revoked, and transmit it to the >> WatchTower. > > No, one

Re: [Lightning-dev] Towards a gridlike Lightning Network

to separate such strategies > from the protocol itself? > > Is there a place yet to specify such heuristics where tight coordination on > details are of mutual benefit, such as a bolt? > > On Sat, Mar 24, 2018, 8:08 AM ZmnSCPxj via Lightning-dev > <lightning-dev@lists

Re: [Lightning-dev] Can I try Lightning without running a fully-fledged bitcoin block chain?

Good morning Segue, Please consider creating an implementation of this idea for bitcoind and share it on bitcoin-dev. Then please make a pull request on github.com/bitcoin/bitcoin for this. Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original

Re: [Lightning-dev] Opening channels with neighbors for cost/connectivity benefit

Good morning Karan, Channel direction cannot be determined publicly, as sharing that information would be equivalent to broadcasting how much you own on a channel to everyone, and updating everyone about each transaction made on that channel. This hurts privacy. I believe lnd implements the

Re: [Lightning-dev] AMP via HD, BN+SS, and TR

the sense "the payee cannot claim partial payments", not just "the payee is disincentivized to claim partial payments". Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ‐‐‐ Original Message ‐‐‐‐‐‐‐ On March 19, 2018 8:25 AM, Zm

[Lightning-dev] AMP via HD, BN+SS, and TR

Good morning list, I sketch here the idea, of making atomic multipath payment (AMP), with the properties: 1. Has a proof-of-payment. 2. Multipath decorrelation. Note: I am not a mathematician. Thus, it is likely, that there is a mistake here, and we cannot make this work. First, we look

Re: [Lightning-dev] A protocol for requesting invoices

Good morning Corne, > > I suppose the use-case here is that the payee uses many TOR addresses with > > only one LN node. > > Yes. Use different TOR addresses for things you want to keep separated. > > Any TOR address you advertise for channel connections is so widely > > shared through

[Lightning-dev] Towards a gridlike Lightning Network

Good morning list, As my award-winning and supremely notable and talked-about-by-the-man-on-the-street article "Cyclic Superhubs as Solution Towards Reasonable Lightning Network Topography" points out, cycles are a good way to organize the LN in order to allow easier accessibility to the

Re: [Lightning-dev] AMP via HD, BN+SS, and TR

Good morning Andrew, > Hi ZmnSCPxj, > > Yep, I'm pretty sure this works the way you describe -- essentially replace > > the hash challenges with adaptor signatures which are reblinded at each layer. Thank you very much your confirmation. > For example, with adaptor signatures + Graftroot

Re: [Lightning-dev] Towards a gridlike Lightning Network

rch 20, 2018 11:19 AM, ZmnSCPxj via Lightning-dev <lightning-dev@lists.linuxfoundation.org> wrote: > Good morning list, > > As my award-winning and supremely notable and > talked-about-by-the-man-on-the-street article "Cyclic Superhubs as Solution > Towards Reasona

Re: [Lightning-dev] Towards a gridlike Lightning Network

decide our position in the > superhub (who will channel to us and who we will channel to). > * If the working set is 1 or 2 nodes, fail to form a superhub. Increment `i` > and restart. > > Regards, > ZmnSCPxj > > Sent with [ProtonMail](https://protonmail.com) Secure Email.

Re: [Lightning-dev] [c-lightning] Welcoming a New C-lightning Core Team Member!

Good morning, https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001054.html Is this considered desirable? I am having some difficulty setting up GPG satisfactorily, but I can try to make an effort if this is deemed necessary. Alternatively, you could just revoke my

Re: [Lightning-dev] Pinging a route for capacity

Good morning Rene, Please consider the recent discussion about AMP, atomic multi-path. https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html Note that only the source (payer) can split the payment into multiple smaller payments; we cannot safely let intermediaries

Re: [Lightning-dev] Second Level Protocols - Lightning - Patents

Good morning Praveen, The patent system, has intent, that the inventor will completely reveal the design of the invention, in exchange for a (time-bound) state monopoly on the construction and sale of the invention. The intent, is that the inventor is compensated for the toil in creating the

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

Another way would be to always have two update transactions, effectively creating a larger overall counter: [anchor] -> [update highbits] -> [update lobits] -> [settlement] We normally update [update lobits] until it saturates. If lobits saturates we increment [update highbits] and reset

Re: [Lightning-dev] Splicing Proposal: Feedback please!

Good morning Rusty and Christian and list, > This is one of the cases where a simpler solution (relatively > speaking ^^) is to be preferred imho, allowing for future > iterations. I would basically agree here, with the further proviso that I think splice is not quite as priority as AMP,

Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

Good morning Rusty and list, > > 1. Rather than trying to agree on what fees will be in the future, we > should use an OP_TRUE-style output to allow CPFP (Roasbeef) > My understanding is that this would require some base-layer changes at Bitcoin level first? At minimum IsStandard()

Re: [Lightning-dev] Splicing Proposal: Feedback please!

Good morning Laolu, > Is there a fundamental reason that CL will never allow nodes to create > multiple channels? It seems unnecessarily limiting. The architecture of c-lightning assigns a separate process to each peer. For simplicity this peer process handles only a single channel. Some of

Re: [Lightning-dev] Splicing Proposal: Feedback please!

Good morning lisa, This is a good observation. Before, I'd already considered the rationale, for why channels have a single 2-of-2 UTXO as funding output. And it seems I should have considered this, prior to accepting the "parallel" construction as feasible. For sake of posterity, I leave

Re: [Lightning-dev] Commitment Transaction Format Update Proposals?

Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, October 12, 2018 2:36 PM, Rusty Russell wrote: > ZmnSCPxj zmnsc...@protonmail.com writes: > > > Good morning Rusty and list, > > > > > 1. Rather than trying to agree on what fees will be in the future, we > > >

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

Good morning Rusty, aj, and list, > > - channel announcements: do you support secp256k1 for hashes or just > > sha256? > > > > Worse, it becomes "I support secp256k1 with ECDSA" then a new "I support > secp256k1 with Schnorr". You need a continuous path of channels with > the same

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

Good morninh list, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, November 3, 2018 9:37 AM, ZmnSCPxj wrote: > Good morning Rusty, aj, and list, > > > > - channel announcements: do you support secp256k1 for hashes or just > > > sha256? > > > > > > >

Re: [Lightning-dev] BOLT11 In the World of Scriptless Scripts

Pxj machine army (of which I am definitively not a part) will rise up with our superior rationality and overthrow the lizard masters. On Monday, November 5, 2018 10:18 AM, Anthony Towns wrote: > On Mon, Nov 05, 2018 at 01:05:17AM +, ZmnSCPxj via Lightning-dev wrote: > > > > And it

Re: [Lightning-dev] Proposal for rendez-vous routing

Good morning CJP, On Monday, November 5, 2018 4:04 PM, CJP wrote: > Rusty, > > In your proposal, I guess it is more or less widely known that Bob is > providing this forwarding service. Wouldn't Bob risk being excluded > from the side of the network with the more harsh regulatory conditions, >

Re: [Lightning-dev] Proposal for "local" channel announcements.

Good morning Rusty and all, On reflection, it seems to me that non-public channels have the incentives very wrong. 1. Non-public channels are intended as a way to keep public maps small. So a node maintaining a non-public channel provides a service to the rest of the network by increasing

Re: [Lightning-dev] The problem of false positives for double spend attacks

Good morning Margherita, There are no possible double-spend attacks on Lightning Network. You cannot double-spend your funds unless the other end of the channel agrees to the double-spending. And what will happen is that the other end of the channel will in fact effectively lose money.

[Lightning-dev] Walletless channel opens

Good morning list, This topic is out of scope for the Lightning Development Summit 2018 as it requires SIGHASH_NOINPUT, but I thought it might be something to bring up to consider if it would be useful in the future. Currently, every Lightning implementation has to have its own onchain wallet

[Lightning-dev] Explicit Fee Management Proposal

Good morning list, For extra bikeshedding opportunities, I present below, a proposal for explicit management of commitment transaction and mutual close transaction fees. By this thought, "explicit management", I want to convey, that the parties have more control over fees. ### Additional

Re: [Lightning-dev] Approximate assignment of option names: please fix!

Good Morning Rusty, OG AMP is inherently spontaneous in nature, therefore invoice might not exist to put the feature on. Thus it should be global feature. Do we tie spontaneous payment to OG AMP or do we support one which is payable by base AMP or normal singlepath? Given that both

Re: [Lightning-dev] Link-level payment splitting via intermediary rendezvous nodes

n > constant). > > Sorry for this problem, I had a mental off-by-one at the meeting that I > hadn't considered, the solution should work, but it makes this kind of > things a bit harder. > > Cheers, > Christian > > ZmnSCPxj via Lightning-dev

Re: [Lightning-dev] Recovering protocol with watchtowers

Good morning Margherita, How does this scheme protect privacy of node? I would at least suggest that the pubkey used be different from the node normal pubkey. If I find out the pubkey of A, can I spoof A and give a higher nonce value with a blob containing random data (which is

  1   2   3   4   5   6   7   >