Re: [Lightning-dev] Peer selection

2017-12-13 Thread ZmnSCPxj via Lightning-dev
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

2017-12-13 Thread ZmnSCPxj via Lightning-dev
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

2017-12-13 Thread ZmnSCPxj via Lightning-dev
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

2017-12-11 Thread ZmnSCPxj via Lightning-dev
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] reducing the number of blockchain transactions used by the LN, and the fees paid to confirm them

2017-12-20 Thread ZmnSCPxj via Lightning-dev
Good morning Jim, The idea is called "splce in/out" and as Dario Sneidermanis mentioned, has occasionally been discussed on this list every now and then. To my understanding: 1. The splicing transaction has as input the previous funding transaction output. 2. The splicing transaction has an

Re: [Lightning-dev] Refilling a channel by sending a payment to yourself.

2017-12-20 Thread ZmnSCPxj via Lightning-dev
Good morning Lukehanson, That is correct. Indeed this "pay yourself" technique is a useful way to rebalance funds. The main advantage is that it would work without modification of the protocol. However, to my knowledge, no node software currently actually implements this technique of

Re: [Lightning-dev] reducing the number of blockchain transactions used by the LN, and the fees paid to confirm them

2017-12-21 Thread ZmnSCPxj via Lightning-dev
Good morning Jim, Reviewing again the link from Dario, I find I am myself in that mailing list thread, for some reason. Christian Decker mentions the use of a pre-splice-in transaction, implying yet another transaction necessary for splice-in (if we wish to have "asynchronous" splice-in, i.e.

Re: [Lightning-dev] Why do we need fee estimation in the protocol?

2018-05-14 Thread ZmnSCPxj via Lightning-dev
Good morning CJP, Rusty, and list, > > But why do we need consensus at all? There are two versions of each > > > > commitment transaction: one to be used for unilateral close by one peer > > > > (A), and one to be used by the other (B). Peer A has an interest in > > > > "commit transaction A",

Re: [Lightning-dev] Receiving via unpublished channels

2018-05-07 Thread ZmnSCPxj via Lightning-dev
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

2018-05-08 Thread ZmnSCPxj via Lightning-dev
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] Mitigations for loop attacks

2018-05-09 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty, Jim, and list, > I can destroy your node's reputation by routing crap through you; even > > if it costs me marginaly more reputation than it does you, that just > > means that the largest players can force failure upon smaller players, > > centralizing the network. My

Re: [Lightning-dev] Receiving via unpublished channels

2018-05-08 Thread ZmnSCPxj via Lightning-dev
nSCPxj > > Regards, > > nayuta-ueno > > 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 r

Re: [Lightning-dev] eltoo Trustless WatchTowers

2018-05-09 Thread ZmnSCPxj via Lightning-dev
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

2018-05-09 Thread ZmnSCPxj via Lightning-dev
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

2018-05-15 Thread ZmnSCPxj via Lightning-dev
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] Mitigations for loop attacks

2018-05-16 Thread ZmnSCPxj via Lightning-dev
Good morning Jim, >> This can still be manipulated if Rusty1 opens a direct channel to Jim. Then >> Rusty1 can route payments Rusty1->Jim->Rusty2 that succeed quickly, then >> route payments Rusty1->ZmnSCPxj->Jim->Rusty2 that stall. Thus Rusty2 can >> have the Jim->Rusty2 reputation boosted,

Re: [Lightning-dev] Mitigations for loop attacks

2018-05-22 Thread ZmnSCPxj via Lightning-dev
Good morning Corne, I think onion unpeeling never made it into the BOLT spec precisely due to the problems with it. I think the unpeeling in question is essentially a hop node (rather than the ultimate payer/source) unpeeling the onion in order to find out who was being slow. Perhaps the

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

2018-05-22 Thread ZmnSCPxj via Lightning-dev
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] Mitigations for loop attacks

2018-05-15 Thread ZmnSCPxj via Lightning-dev
Good morning, >> But I can make you look like a delaying node whenever I want. The only >> way to ensure that I lose more reputation than you do is to leak >> information about route length for *everyone*. And even then, it's just >> a matter of numbers. I can make successful payments to

Re: [Lightning-dev] Mitigations for loop attacks

2018-05-18 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty, > Also, you talked about reputation_loss_rate as being a private per-node > > thing, and being an explicit thing in the HTLC. I'm ignoring the > > former, and assuming the latter. Reputation (the score) is a private per-node thing, while the `reputation_loss_rate` is

Re: [Lightning-dev] Imposing minimum 253 sat/ksipa feerate?

2018-06-18 Thread ZmnSCPxj via Lightning-dev
if I am too naive in this > > attack and it is in fact not possible. > > > > (one wonders why the above "SHOULD fail the channel" is indicated in the > > BOLT spec, if the attack above (or a similar attack) is not possible) > > > > > Force closing asymmet

[Lightning-dev] Imposing minimum 253 sat/ksipa feerate?

2018-05-29 Thread ZmnSCPxj via Lightning-dev
Hi all, but most especially non-c-lightning developers, Some time ago, C-lightning imposed a minimum 253 sat/ksipa feerate: https://github.com/ElementsProject/lightning/pull/1251 The reason is that the BOLT spec specifies a fee computation that is not identical to how bitcoind computes fees.

Re: [Lightning-dev] New idea on decentralized identity and truth (Re: Numerifides)

2018-06-06 Thread ZmnSCPxj via Lightning-dev
Good morning Tyler, It seems this can be a layer on top of LN. This is my understanding: the querier requests some mapping and sends also an invoice, the responder either fails, or returns the mapping and pays to the invoice. So the responder pays to the querier. However it seems a little

Re: [Lightning-dev] New idea on decentralized identity and truth (Re: Numerifides)

2018-06-06 Thread ZmnSCPxj via Lightning-dev
Good morning again Tyler, Building off the "server-client database" idea, here is an alternate idea. We have a special node type, an "advertiser node". Aside from normal LN protocol, advertiser nodes also have the below interface: 1. A "write" interface that lets advertisers pay to set a

Re: [Lightning-dev] New idea on decentralized identity and truth (Re: Numerifides)

2018-06-07 Thread ZmnSCPxj via Lightning-dev
Good morning Tyler, > Regarding proof of payment, a receiving node must have some inbound Lightning > capacity. Therefore, they must have spent funds on the LN already. Attackers > can't drain more than they've spent on their channels. Node pubkeys can also > be used such that rapid subsequent

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

2018-06-26 Thread ZmnSCPxj via Lightning-dev
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

2018-06-22 Thread ZmnSCPxj via Lightning-dev
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] [bitcoin-dev] BIP sighash_noinput

2018-07-03 Thread ZmnSCPxj via Lightning-dev
Good morning, >The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing >about what the flag actually does. SIGHASH_NOINPUT_REUSE_VULNERABLE? SIGHASH_NOINPUT_VULNERABLE? Regards, ZmnSCPxj___ Lightning-dev mailing list

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

2018-07-02 Thread ZmnSCPxj via Lightning-dev
Good morning all, > The gossip extension is difficult: > > 3. If we extend channel_announce that won't propagate through old nodes > > until the new channel is 6 deep, and it's wasted space (sigs + old-chanid) > > once the splice is old news. > > 4. If we extend

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

2018-05-01 Thread ZmnSCPxj via Lightning-dev
Good morning Christian, Thank you very much! > > 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. > > > > It sets them to a known constant,

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

2018-05-01 Thread ZmnSCPxj via Lightning-dev
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

2018-05-02 Thread ZmnSCPxj via Lightning-dev
Good morning Christian, > > > 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. > > > > > > > It sets them to a known constant, in

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

2018-04-30 Thread ZmnSCPxj via Lightning-dev
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

2018-05-01 Thread ZmnSCPxj via Lightning-dev
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] Scriptless Scripts with ECDSA

2018-04-29 Thread ZmnSCPxj via Lightning-dev
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

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

2018-05-04 Thread ZmnSCPxj via Lightning-dev
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

2018-01-07 Thread ZmnSCPxj via Lightning-dev
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

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

2018-01-07 Thread ZmnSCPxj via Lightning-dev
Good morning Lightning world, https://github.com/lightningnetwork/lightning-rfc/pull/349 I propose in the above pull request a new `funding_cancelled` message intended to inform the fundee node that the funder node is definitely sure that the channel funding transaction can never confirm.

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

2018-01-22 Thread ZmnSCPxj via Lightning-dev
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

2018-01-22 Thread ZmnSCPxj via Lightning-dev
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] [Question] Unilateral closing during fee increase.

2018-01-14 Thread ZmnSCPxj via Lightning-dev
Good Morning Richard, > Original Message > Subject: Re: [Lightning-dev] [Question] Unilateral closing during fee > increase. > Local Time: January 14, 2018 8:37 PM > UTC Time: January 14, 2018 12:37 PM > From: richard.ha...@gmail.com > To: Peter Todd >

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

2018-01-14 Thread ZmnSCPxj via Lightning-dev
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

2018-01-14 Thread ZmnSCPxj via Lightning-dev
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?

2018-02-02 Thread ZmnSCPxj via Lightning-dev
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?

2018-02-04 Thread ZmnSCPxj via Lightning-dev
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

2018-02-04 Thread ZmnSCPxj via Lightning-dev
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?

2018-02-04 Thread ZmnSCPxj via Lightning-dev
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?

2018-02-07 Thread ZmnSCPxj via Lightning-dev
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

2018-02-12 Thread ZmnSCPxj via Lightning-dev
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

2018-02-12 Thread ZmnSCPxj via Lightning-dev
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)

2018-02-13 Thread ZmnSCPxj via Lightning-dev
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

2018-02-19 Thread ZmnSCPxj via Lightning-dev
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

2018-02-22 Thread ZmnSCPxj via Lightning-dev
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?

2018-02-25 Thread ZmnSCPxj via Lightning-dev
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

2018-01-01 Thread ZmnSCPxj via Lightning-dev
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

2017-12-26 Thread ZmnSCPxj via Lightning-dev
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] General questions about channels

2017-12-27 Thread ZmnSCPxj via Lightning-dev
Good morning Andy, Sent with [ProtonMail](https://protonmail.com) Secure Email. > Original Message > Subject: Re: [Lightning-dev] General questions about channels > Local Time: December 27, 2017 2:27 PM > UTC Time: December 27, 2017 6:27 AM > From: i...@andyschroder.com > To:

Re: [Lightning-dev] SegWit and LN

2018-01-02 Thread ZmnSCPxj via Lightning-dev
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] Replaceable Funding Transactions

2018-01-03 Thread ZmnSCPxj via Lightning-dev
Good morning, > I don't see why this wouldn't work as long as implementations on both > ends supports channels multiplexing, like lnd or eclair do (didn't > test it though). Thank you, that is my understanding also. > But being the accepting node, I wouldn't like receiving too many > channel

[Lightning-dev] Arbitrary Bitcoin Contracts over LN

2018-08-01 Thread ZmnSCPxj via Lightning-dev
Good morning list, Recently, somebody on the IRC channel, asked regarding smart contracts being transported via LN. Indeed, this is theoretically possible, provided the "smart contract" is implementable as a Bitcoin SCRIPT. Afterwards, I opined that, for transportation of *arbitrary*

Re: [Lightning-dev] Arbitrary Bitcoin Contracts over LN

2018-08-01 Thread ZmnSCPxj via Lightning-dev
Good morning Christian, > My issue is with the fact that CLTV-branches and nLocktimed spending > transactions also need to be guarded with a further `OP_CSV` condition, > since they may leak on-chain, and be immediately valid. This is the > reason why we introduced the two stage HTLC resolution,

Re: [Lightning-dev] Arbitrary Bitcoin Contracts over LN

2018-08-01 Thread ZmnSCPxj via Lightning-dev
Good morning Michael, > A couple of follow ups please: > > 1) Poon-Dryja (LN penalty), Decker-Wattenhofer and Decker-Osuntokun-Russell > (eltoo) just refer to the process for claiming funds when an old state is > broadcast? Poon-Dryja doesn't require a soft fork but > Decker-Osuntokun-Russell

Re: [Lightning-dev] Free Rebalancing Proposals

2018-08-13 Thread ZmnSCPxj via Lightning-dev
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

2018-09-11 Thread ZmnSCPxj via Lightning-dev
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

2018-07-04 Thread ZmnSCPxj via Lightning-dev
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

2018-07-11 Thread ZmnSCPxj via Lightning-dev
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

2018-07-11 Thread ZmnSCPxj via Lightning-dev
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

2018-01-19 Thread ZmnSCPxj via Lightning-dev
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

2018-09-11 Thread ZmnSCPxj via Lightning-dev
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] Both-side funded channels

2018-09-11 Thread ZmnSCPxj via Lightning-dev
Good morning Cezary, > Thanks for answer, > > Do I understand what you described correctly? If some merchant would like to > just start using ln by receiving funds, he need to: > > 1. Fund channel with amount he would like to be able to receive + dust_limit*2 > 2. Wait for confirmations to

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

2018-03-13 Thread ZmnSCPxj via Lightning-dev
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

2018-03-15 Thread ZmnSCPxj via Lightning-dev
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

2018-03-15 Thread ZmnSCPxj via Lightning-dev
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

2018-03-16 Thread ZmnSCPxj via Lightning-dev
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

2018-03-08 Thread ZmnSCPxj via Lightning-dev
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.

2018-04-10 Thread ZmnSCPxj via Lightning-dev
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

2018-04-10 Thread ZmnSCPxj via Lightning-dev
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

2018-04-05 Thread ZmnSCPxj via Lightning-dev
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

2018-04-05 Thread ZmnSCPxj via Lightning-dev
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

2018-04-05 Thread ZmnSCPxj via Lightning-dev
> > 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

2018-04-11 Thread ZmnSCPxj via Lightning-dev
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.

2018-04-11 Thread ZmnSCPxj via Lightning-dev
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

2018-04-11 Thread ZmnSCPxj via Lightning-dev
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.

2018-04-09 Thread ZmnSCPxj via Lightning-dev
Good morning Tyler, > A side effect of this BOLT would be, as an example, the mobile Eclair wallet > could be updated to accept a domain parameter to specify an initial node to > open a user's first channel to rather than only the option to "autoconnect" > to their hard-coded node, and the

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

2018-04-09 Thread ZmnSCPxj via Lightning-dev
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

2018-04-13 Thread ZmnSCPxj via Lightning-dev
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

2018-04-13 Thread ZmnSCPxj via Lightning-dev
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`

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

2018-04-13 Thread ZmnSCPxj via Lightning-dev
Good morning Christian, I wonder suddenly, about how HTLCs are offered under Decker-Wattenhofer Duplex Micropayment Channels. Under the Decker-Wattenhofer construction, I believe the transaction sequence is the below: funding -> trigger -> (relative-timelock) invalidation tree -> ...

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

2018-04-11 Thread ZmnSCPxj via Lightning-dev
Good morning, > > That is mostly due to the selection of 1 bit sequence diffs, the > > branching gives us a huge increase in the number of invalidations. The > > paper has the example of branching factor of 46, and a tree depth of 11, > > which results in 1.48e11 updates. >From your

Re: [Lightning-dev] High level fee mechanics

2018-04-11 Thread ZmnSCPxj via Lightning-dev
Good morning Benjamin, > Do (should) channels have the option of publicizing their balances, so as to > improve routing performance / scalability in a large network, and for > competitive differentiation among competing routes? This would allow channel > owners to balance privacy with

Re: [Lightning-dev] High level fee mechanics

2018-04-10 Thread ZmnSCPxj via Lightning-dev
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?

2018-04-17 Thread ZmnSCPxj via Lightning-dev
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] Trustless WatchTowers?

2018-04-17 Thread ZmnSCPxj via Lightning-dev
Good morning Conner, I have an insane idea. > One minimal solution could be to send signatures for independent sweep > transactions, allowing the watchtower to sweep each HTLC output individually. > This is nice because it permits the watchtower to sweep exactly the subset > ofHTLCs that ever

Re: [Lightning-dev] Trustless WatchTowers?

2018-04-18 Thread ZmnSCPxj via Lightning-dev
Good morning list, A possible problem with the encrypted blob approach came to my mind. A potential thief, knows the commitment transaction it will attempt to use to steal (obviously). That potential thief, also knows the commitment transaction ID (obviously). In the encrypted blob approach,

Re: [Lightning-dev] Commitment delay asymmetry

2018-04-16 Thread ZmnSCPxj via Lightning-dev
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] Commitment delay asymmetry

2018-04-15 Thread ZmnSCPxj via Lightning-dev
Good morning Daniel, > This makes a lot of sense to me as a way to correct the incentives for > closing channels. I figure that honest nodes that have truly gone offline > will not require (or be able to take advantage of) immediate access to their > balance, such that this change shouldn't

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

2018-04-15 Thread ZmnSCPxj via Lightning-dev
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

2018-04-15 Thread ZmnSCPxj via Lightning-dev
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?

2018-04-15 Thread ZmnSCPxj via Lightning-dev
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.

2018-04-19 Thread ZmnSCPxj via Lightning-dev
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

  1   2   3   >