Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)

2019-10-14 Thread ZmnSCPxj via Lightning-dev
Good morning Jonas, Orfeas, and all, > > hashing out old ideas in public like an out-of-the-loop person > > Being fully in-the-loop literally seems undesirable anyway. As the scriptless > scripts space gets bigger, I invite everyone to consider contributing to the > scriptless scripts repo at >

Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)

2019-10-11 Thread ZmnSCPxj via Lightning-dev
Good morning Nadav and Lloyd, > I really like the Premium-free American Call Option mitigation you've > described here! I totally agree that it is probably best to move to > computational security rather than rational security. I hadn't thought about > how well High AMP inter-operates with

Re: [Lightning-dev] Increasing fee defaults to 5000+500 for a healthier network?

2019-10-10 Thread ZmnSCPxj via Lightning-dev
Good morning, Looks fine to me. Regards, ZmnSCPxj > Hi all, > > I've been looking at the current lightning network fees, and it > shows that 2/3 are sitting on the default (1000 msat + 1 ppm). > > This has two problems: > > 1. Low fees are now a negative signal: defaults actually indicate >

Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)

2019-10-10 Thread ZmnSCPxj via Lightning-dev
Good morning list, and Nadav, > I would also like to point out the below assumption, which underlies Bass > Amplifier ("multipath payments", "base AMP") and its claim to atomicity: > > - If we agree that my secret `s` is worth `m` millisatoshi, then I (as a > perfectly rational economic

Re: [Lightning-dev] A Payment Point Feature Family (MultiSig, DLC, Escrow, ...)

2019-10-09 Thread ZmnSCPxj via Lightning-dev
Good morning Nadav, Thank you very much for this framework! It seems very good idea, kudos to making this framework. I think, it is possible to make, a miniscript-like language for such things. Indeed, the only material difference, between SCRIPT-based `OP_CHECKSIG`s and Lightning, would be the

[Lightning-dev] Payment point+scalar (was: Re: Proposal: AMPs With Proof of Payment)

2019-10-07 Thread ZmnSCPxj via Lightning-dev
Good morning list, I was contacted off-list about the below statement: > Since bip-schnorr probably will have 1 year of arguing, 1 year of testing+ > developing, and 2 years of miners delaying activation before another UASF, I > am currently tempted to consider implementing 2p-ECDSA already.

Re: [Lightning-dev] [bitcoin-dev] OP_CAT was Re: Continuing the discussion about noinput / anyprevout

2019-10-06 Thread ZmnSCPxj via Lightning-dev
Good morning Peter, Jeremy, and lists, > On Fri, Oct 04, 2019 at 11:40:53AM -0700, Jeremy wrote: > > > Interesting point. > > The script is under your control, so you should be able to ensure that you > > are always using a correctly constructed midstate, e.g., something like: > > scriptPubKey:

Re: [Lightning-dev] OP_CAT was Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-10-04 Thread ZmnSCPxj via Lightning-dev
Good morning Jeremy, > Awhile back, Ethan and I discussed having, rather than OP_CAT, an > OP_SHA256STREAM that uses the streaming properties of a SHA256 hash function > to allow concatenation of an unlimited amount of data, provided the only use > is to hash it. > > You can then use it

Re: [Lightning-dev] OP_CAT was Re: [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-10-03 Thread ZmnSCPxj via Lightning-dev
Good morning Ethan, > To avoid derailing the NO_INPUT conversation, I have changed the > subject to OP_CAT. > > Responding to: > """ > > - `SIGHASH` flags attached to signatures are a misdesign, sadly > retained from the original BitCoin 0.1.0 Alpha for Windows design, on > par with: >

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-10-02 Thread ZmnSCPxj via Lightning-dev
> > let me propose the more radical excision, starting with SegWit v1: > > > > - Remove `SIGHASH` from signatures. > > - Put `SIGHASH` on public keys. > > OP_SETPUBKEYSIGHASH > > > > I don't think you could reasonably do this for key path spends -- if > you included the sighash as part

Re: [Lightning-dev] Proposal: AMPs With Proof of Payment

2019-10-02 Thread ZmnSCPxj via Lightning-dev
Good morning Nadav, Yes, this is possible. https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-March/001100.html This is called as "High" AMP to contrast with OG and Base, and was discussed in Adelaide 2018. At Adelaide 2018 only path decorrelation and High AMP were the known

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-10-01 Thread ZmnSCPxj via Lightning-dev
Good morning lists, Let me propose the below radical idea: * `SIGHASH` flags attached to signatures are a misdesign, sadly retained from the original BitCoin 0.1.0 Alpha for Windows design, on par with: * 1 RETURN * higher-`nSequence` replacement * DER-encoded pubkeys * unrestricted

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-10-01 Thread ZmnSCPxj via Lightning-dev
Good morning aj, > On Mon, Sep 30, 2019 at 11:28:43PM +, ZmnSCPxj via bitcoin-dev wrote: > > > Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode, > > `OP_CHECKSIG_WITHOUT_INPUT`. > > I don't think there's any meaningful difference between making a new > opcode and making a new

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-10-01 Thread ZmnSCPxj via Lightning-dev
Good morning Christian, > > - A standard MuSig 2-of-2 bip-schnorr SegWit v1 Funding Transaction > > Output, confirmed onchain > > - A "translator transaction" spending the above and paying out to a > > SegWit v16 output-tagged output, kept offchain. > > - Decker-Russell-Osuntokun update

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-10-01 Thread ZmnSCPxj via Lightning-dev
Good morning lists, Let me summarize concerns brought up: * Chris concern, is that an ordinary UTXO that is not allocated for `SIGHASH_NOINPUT` use, is inadvertently spent using `SIGHASH_NOINPUT`. * My concern, is that unless a UTXO allocated for `SIGHASH_NOINPUT` use, is *indeed* used with

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-09-30 Thread ZmnSCPxj via Lightning-dev
Good morning list, To elucidate further --- Suppose rather than `SIGHASH_NOINPUT`, we created a new opcode, `OP_CHECKSIG_WITHOUT_INPUT`. This new opcode ignores any `SIGHASH` flags, if present, on a signature, but instead hashes the current transaction without the input references, then

Re: [Lightning-dev] [bitcoin-dev] Continuing the discussion about noinput / anyprevout

2019-09-30 Thread ZmnSCPxj via Lightning-dev
Good morning Christian, > The concern with output tagging is that it hurts fungibility, marking outputs > used in a contract as such and making them identifiable. But maybe it would be > a good idea to create two domains anyway: one for user-addressable > destinations which users can use with

Re: [Lightning-dev] Selling timestamps (via payment points and scalars + Pedersen commitments ) [try2]

2019-09-25 Thread ZmnSCPxj via Lightning-dev
Good morning aj, > On Wed, Sep 25, 2019 at 01:30:39PM +, ZmnSCPxj wrote: > > > > Since it's off chain, you could also provide R and C and a zero knowledge > > > proof that you know an r such that: > > > R = SHA256( r ) > > > C = SHA256( x || r ) > > > > in which case you could do it with

Re: [Lightning-dev] Selling timestamps (via payment points and scalars + Pedersen commitments ) [try2]

2019-09-25 Thread ZmnSCPxj via Lightning-dev
Good morning aj, and list, > > Solution: buy a place in a merkle tree "risk-free" > > > > 1. send hash x of my message (or the merkle root of another tree) to the > > timstamping server > > > > 2. server calculates Pedersen commit: C = xH + rG, hashes it, builds merkle > > tree with

Re: [Lightning-dev] Revocations and Watchtowers

2019-09-19 Thread ZmnSCPxj via Lightning-dev
Good morning Christian, > Even with shachain the storage requirements for the nodes (not the > watchtowers) are far from being constant either: since any old state, > including anything that we built on top of it (HTLCs), so we need to > keep information around to react to those as well

[Lightning-dev] Revocations and Watchtowers

2019-09-19 Thread ZmnSCPxj via Lightning-dev
Good morning list, I was reading through the transcript of recent talk: https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/blockchain-design-patterns/ In section "Revocations and SIGHASH_NOINPUT": > There's another issue in lightning, which is the revocation

Re: [Lightning-dev] [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo

2019-09-18 Thread ZmnSCPxj via Lightning-dev
Good morning Christian, and list, > > > uncooperative membership change: > > > > > > - a subset of channel parties might want to cooperatively sign a > > > channel splicing transaction to 'splice out' uncooperative parties > > > > I believe this is currently considered unsafe. > >

Re: [Lightning-dev] Proposal for Stuckless Payment

2019-09-18 Thread ZmnSCPxj via Lightning-dev
Ohayou Hiroki-san, I agree this possibility. Of note is that this also helps support: 1. Cross-currency swaps without premium-free American Call Option. Exchanges will demand for a premium to be paid for revelation of the second preimage. 2. Non-custodial Escrow. The second preimage is

Re: [Lightning-dev] [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo

2019-09-17 Thread ZmnSCPxj via Lightning-dev
Good morning Richards, and list, > Thanks for the feedback ZmnSCPxj. > > > I imagine a future where most people do not typically have single-signer > > ownership of coins onchain, but are instead share-owners of coins, with > > single-signer ownership occurring onchain only in the case of

Re: [Lightning-dev] Avoiding gossip spam: how many updates do you need?

2019-09-15 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty, As it happens, I already proposed a possible use-case for relatively-common `channel_update`: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-July/002055.html In the final section I mention: > Suppose that in fact, YAijbOJA thinks that the capacity of the >

Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices

2019-09-09 Thread ZmnSCPxj via Lightning-dev
ng implementations to remember who a closed > > short-channel-id used to be connected to. > > * Trampoline nodes will generally require a much larger fee and timelock > > budget, because they also have to build routes. > >   If the fee and timelock budgets are big enough,

Re: [Lightning-dev] [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo

2019-09-09 Thread ZmnSCPxj via Lightning-dev
Good morning Richard, > I believe using the eltoo update scheme as a way to consolidate blocks of > off-chain transactions is an interesting idea worth exploring.   > > ZmnSCPxj brings up some limitations on arbitrary outputs scripts in eltoo. > Although using CSV is more complicated and

Re: [Lightning-dev] Miniscript on LN (was: eltoo implementation in Bitcoin functional test framework)

2019-09-09 Thread ZmnSCPxj via Lightning-dev
Good morning all, I saw also this thread: https://www.reddit.com/r/Bitcoin/comments/d19n6l/miniscript_streamlined_bitcoin_scripting/ezjb4ec/ Regards, ZmnSCPxj > Good morning David, > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Saturday, September 7, 2019 2:43

Re: [Lightning-dev] Miniscript on LN (was: eltoo implementation in Bitcoin functional test framework)

2019-09-08 Thread ZmnSCPxj via Lightning-dev
Good morning David, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, September 7, 2019 2:43 AM, David A. Harding wrote: > > Good morning list, > > I do not see much point in using miniscript for Lightning unless we > > decide to support transporting arbitrary

Re: [Lightning-dev] [bitcoin-dev] Reconciling the off-chain and on-chain models with eltoo

2019-09-06 Thread ZmnSCPxj via Lightning-dev
Good morning Christian, This is effectively transaction cut-through. I mention this in passing here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001986.html > I observe that one may consider any offchain system a specialization of an > offchain transaction cut-through

[Lightning-dev] Miniscript on LN (was: eltoo implementation in Bitcoin functional test framework)

2019-09-05 Thread ZmnSCPxj via Lightning-dev
Good morning list, I do not see much point in using miniscript for Lightning unless we decide to support transporting arbitrary contracts, as here: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-August/001383.html Otherwise, it would be far easier implementation-wise, to just

Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices

2019-08-15 Thread ZmnSCPxj via Lightning-dev
nd timelock budget, because they also have to build routes. If the fee and timelock budgets are big enough, then the trampoline node might decide to open a direct channel to the next trampoline node "just-in-time" for the next trampoline hop. Regards, ZmnSCPxj > > On Wed, Aug

Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices

2019-08-14 Thread ZmnSCPxj via Lightning-dev
Good morning Ecurrencyhodler, It seems to me a trusted model then. Regardless of who makes the channel (the payee cannot determine who the payer is anyway) the payee cannot trustlessly release the product until the channel is deeply confirmed, else your security is only 0-conf, not off-chain.

Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices

2019-08-14 Thread ZmnSCPxj via Lightning-dev
Good morning Ecurrencyhodler, > Hi ZmnSCPxj!  > > Submarine swaps are a great current solution, but we still have to wait for > confirmations. So would `push_msat`; until confirmed deeply the channel opening can still be cancelled by double-spending and it would be foolhardy to deliver the

Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices

2019-08-13 Thread ZmnSCPxj via Lightning-dev
Good morning Ecurrencyhodler, A current and practical way to set up incoming liquidity would be to take some onchain funds, create a channel to a high-uptime node on the network (just run an autopilot), then use a submarine swap (i.e. pay offchain funds to buy onchain funds). Then you can

Re: [Lightning-dev] Paper - Modeling a Steady-State Lightning Network Economy

2019-08-12 Thread ZmnSCPxj via Lightning-dev
Good morning Gregorio, > We argue that in such scenario, in a network of n connected nodes, there is a > tendency towards a state where exactly n-1 channels have perfectly balanced > flows in the two directions ("self-balancing" channels), while all other > channels are either unused, or have

Re: [Lightning-dev] Improving Lightning Network Pathfinding Latency by Path Splicing and Other Real-Time Strategy Game Techniques

2019-08-09 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty, > > > > Typical quotes suggested that commodity hardware would take 2 seconds to > > > > find a route > > > >   > > > > Can you provide a reproducible benchmark or further qualify this number > > > > (2 > > > > seconds)? > > > > No reproducible benchmark. > > OK, on my

Re: [Lightning-dev] Trampoline Routing

2019-08-08 Thread ZmnSCPxj via Lightning-dev
Good morning fiatjaf, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, August 9, 2019 10:35 AM, fiatjaf wrote: > Ok, here's another question/probably-bad-idea: how feasible is it for these > trampoline nodes to return the route they've calculated somehow to the

Re: [Lightning-dev] Fwd: Trampoline Routing

2019-08-05 Thread ZmnSCPxj via Lightning-dev
Good morning fiatjaf, > No. My question was more like why does Alice decide to build a route that for > through T1 and RT2 and not only through one trampoline router she knows. If Alice only always used one trampoline node, then the trampoline node can assume the next hop is always the payee,

Re: [Lightning-dev] Improving Lightning Network Pathfinding Latency by Path Splicing and Other Real-Time Strategy Game Techniques

2019-08-03 Thread ZmnSCPxj via Lightning-dev
> Map Preprocessing > = > Differential Heuristics for A\* --- While researching further, I came upon some hints of a concept called "differential heuristics". I tried to search further for this: *

Re: [Lightning-dev] Trampoline Routing

2019-08-02 Thread ZmnSCPxj via Lightning-dev
Good morning fiatjaf, I proposed before that we could institute a rule where nodes are mapped to some virtual space, and nodes should preferably retain the part of the network graph that connects itself to those nodes near to it in this virtual space (and possibly prefer to channel to those

Re: [Lightning-dev] Improving Lightning Network Pathfinding Latency by Path Splicing and Other Real-Time Strategy Game Techniques

2019-08-02 Thread ZmnSCPxj via Lightning-dev
Good morning Bastien, > > Most solutions to the network flow problem seem to require an accurate view > > of flows at each node, which we do not have. > > Interesting, but for the first hop (local channels) we have the exact balance > available for sending, and for next hops we can consider the

Re: [Lightning-dev] Improving Lightning Network Pathfinding Latency by Path Splicing and Other Real-Time Strategy Game Techniques

2019-08-01 Thread ZmnSCPxj via Lightning-dev
Good morning Bastien, > > I think that the main points that make routing in the Lightning Network > different from game path-finding algorithms are: > > - Paths are consumed by payments, effectively moving available balance > between sides of a channel > - The routing algorithm doesn't know

Re: [Lightning-dev] Improving Lightning Network Pathfinding Latency by Path Splicing and Other Real-Time Strategy Game Techniques

2019-07-31 Thread ZmnSCPxj via Lightning-dev
Good morning laolu, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, August 1, 2019 10:29 AM, Olaoluwa Osuntokun wrote: > > I found out recently (mid-2019) that mainnet Lightning nodes take an > > inordinate amount of time to find a route between themselves

[Lightning-dev] Improving Lightning Network Pathfinding Latency by Path Splicing and Other Real-Time Strategy Game Techniques

2019-07-31 Thread ZmnSCPxj via Lightning-dev
Introduction I found out recently (mid-2019) that mainnet Lightning nodes take an inordinate amount of time to find a route between themselves and an arbitrary payee node. Typical quotes suggested that commodity hardware would take 2 seconds to find a route, then take a few hundred

Re: [Lightning-dev] Selling Signatures: Another Reason to Move to Payment Points

2019-07-17 Thread ZmnSCPxj via Lightning-dev
Good morning Nadav, I strongly disagree that I first proposed payment points + scalars for Lightning. My understanding is that Andrew Poelstra first proposed this. Indeed, his work on Scriptless Script was, to my understanding, primarily motivated by a goal of eventually enabling Lightning

Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty

2019-07-16 Thread ZmnSCPxj via Lightning-dev
Good morning Antoine, > Biggest gains with Eltoo are of course transaction symmetry and removing > toxic waste. Reintroducing penalty on top of > this shouldn't affect this two goals, I agree with Christian that introducing penalty introduces toxic waste. Inadvertent misuse of a backup of an

Re: [Lightning-dev] Congestion and Flow control for Multipath Routing

2019-07-15 Thread ZmnSCPxj via Lightning-dev
Good morning Rene, Thank you for continuing to think about Lightning even while in hospital. Please take care your health. As the usual list spammer, I will of course respond pointlessly. > Protocol idea (base version) > = > Disclaimer: This base version has obvious

Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty

2019-07-15 Thread ZmnSCPxj via Lightning-dev
Good morning list, As usual, I am spamming the list for my amusement. Thus, I would like to thank you for your tolerance and continued attention. We have identified two requirements: 1. We must identify which participant initiated the unilateral close onchain. We do so that if

Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty

2019-07-14 Thread ZmnSCPxj via Lightning-dev
Good morning list, I had another realization about the use of punishment in a multiparticipant (n > 2) setting. And it has to do with contracts that have a sort of "shared ownership". Consider HTLC outputs. Such outputs have shared ownership, as the offerer of the HTLC will be able to reclaim

Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty

2019-07-14 Thread ZmnSCPxj via Lightning-dev
Good morning list, > witness: > "sig(A, hash_type=SINGLE|ANYPREVOUTANYSCRIPT|NONE) sig(P, hash_type=SINGLE)" > (Alice commitment signature) I realized that this would not work. Alice can simply sign `sig(A, hash_type=ALL)` instead at this stage, as she is the only signatory to the `

Re: [Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty

2019-07-13 Thread ZmnSCPxj via Lightning-dev
Good morning Atoine, Thank you for your proposal. > Eltoo has been criticized to lower the cost for a malicious party to > test your monitoring of the chain. If we're able to reintroduce some > form of punishment without breaking transaction symmetry that would be great. The primary advantage

Re: [Lightning-dev] Proposal: Lightning Pre-Image Encryption Standard

2019-07-04 Thread ZmnSCPxj via Lightning-dev
Good morning Alexander, > > > Putting MAC inside the encryption would help ensure that we can detect > > > data replacement over insecure channel, and use of shared secret ensures > > > only intended recipient can decrypt. > > > > Generally you want to MAC the ciphertext + IV, otherwise you

[Lightning-dev] Fee-free rebalancing to support JIT-routing

2019-07-03 Thread ZmnSCPxj via Lightning-dev
Good morning list, As it happens, I was considering about JIT-routing by Rene Pickhardt. And I notice that Rene has been proposing about a "fee-free rebalance" in order to better support JIT-routing. And I have been thinking about this "fee-free rebalance" proposal. As a review, JIT-routing

Re: [Lightning-dev] Escrow Over Lightning?

2019-06-27 Thread ZmnSCPxj via Lightning-dev
Good morning Nadav, > Hi ZmnSCPxj, > > I find this idea super exciting! Thank you. I observe that this idea involves sending a key (`b'`) from buyer (who is paying over the LN, i.e. payer) to seller (who is getting paid over the LN, i.e. payee). As it happens, with knowledge of the contract

Re: [Lightning-dev] Proposal: Lightning Pre-Image Encryption Standard

2019-06-26 Thread ZmnSCPxj via Lightning-dev
Good morning Nadav et al., > > Any node on the route of the payment knows the preimage and can decrypt the > > data. It would be nice to tune the protocol in a way that only the buyer > > can decrypt the data. For example we could use something like this: > > Is this not covered by sending over

Re: [Lightning-dev] Proposal: Lightning Pre-Image Encryption Standard

2019-06-26 Thread ZmnSCPxj via Lightning-dev
Good morning Stepan, > But it depends on the application and communication channel, so I would leave > these details to the app developers. I would mildly disagree, as I worry about proliferation of incompatible applications, or applications that can only work with specific wallets. Still, it

Re: [Lightning-dev] Proposal: Lightning Pre-Image Encryption Standard

2019-06-26 Thread ZmnSCPxj via Lightning-dev
Thank you for your thought. Another idea: would it be useful to split up large data (several megabytes long) and FEC-encode it in chunks (with each chunk having a separate MAC)? That way even if some error occurs during transmission, it is possible to recover without re-downloading entire

Re: [Lightning-dev] Proposal: Lightning Pre-Image Encryption Standard

2019-06-25 Thread ZmnSCPxj via Lightning-dev
Good morning Stepan, and Nadav, Both additions seem good idea to me. > - Sally generates the invoice with the preimage `S` (i.e. x-coordinate of > this point to make it 32-bytes long) Does this require Bob to attempt both positive and negative sign for the y-coordinate? Alternately we can

Re: [Lightning-dev] [PROPOSAL]: FAST - Forked Away Simultaneous Transactions

2019-06-25 Thread ZmnSCPxj via Lightning-dev
Good morning Ugam, > In any case, this is effectively simply creation of fork points and join > points along a multipart path. > That the payment does not later join is merely a detail, especially once we > get to "high" AMP (which requires payment points / scalars). > We decided at previous

Re: [Lightning-dev] Proposal: Lightning Pre-Image Encryption Standard

2019-06-25 Thread ZmnSCPxj via Lightning-dev
Good morning Nadav, I have had a similar idea (although without any details as to algorithm). However, it seems to me that the data seller is trusted to actually encrypt the data honestly (rather than, say, encrypting bytes from `/dev/random`). On the other hand, this is a good way to obsolete

Re: [Lightning-dev] [PROPOSAL]: FAST - Forked Away Simultaneous Transactions

2019-06-25 Thread ZmnSCPxj via Lightning-dev
Good morning Rene and Ugam, Under Scriptless Script (payment point / scalar) this is possible to do while retaining a form of proof-of-payment. However, note that the proof-of-payment scalar will be the sum of Eric and Grace proof-of-payment scalars. I am unsure if that provides undeniable

Re: [Lightning-dev] Proposal for Stuckless Payment

2019-06-25 Thread ZmnSCPxj via Lightning-dev
Good morning Hiroki, Thank you for this. It seems a good solution. And, it seems, yet another reason to move to payment point / scalar from payment hash / preimage. As I understand it, the `y0+y1+...` sums are also the blinding tweaks used for payment decorrelation. My understanding, they will

[Lightning-dev] Escrow Over Lightning?

2019-06-19 Thread ZmnSCPxj via Lightning-dev
Good morning list, One thing I am attempting to think through is some implementation of escrow over Lightning. A non-custodial onchain escrow protocol simply uses a 2-of-3 multisig amongst the two participants and the escrow. Such a contract (like any onchain-enforceable contract) can be

Re: [Lightning-dev] Improve Lightning payment reliability through better error attribution

2019-06-14 Thread ZmnSCPxj via Lightning-dev
Good morning Joost, > Yes that is accurate, although using the time difference between receiving > the `update_add_htlc` and sending back the `update_fail_htlc` would work too. > It would then include the node's processing time. It would not work safely. A node can only propagate an

Re: [Lightning-dev] Improve Lightning payment reliability through better error attribution

2019-06-14 Thread ZmnSCPxj via Lightning-dev
Good morning Joost, > That is definitely a concern. It is up to senders how to interpret the > received timestamps. They can decide to tolerate slight variations. Or they > could just look at the difference between the in and out timestamp, > abandoning the synchronization requirement

Re: [Lightning-dev] Improve Lightning payment reliability through better error attribution

2019-06-14 Thread ZmnSCPxj via Lightning-dev
Good morning Bastien and Joost, Before proceeding with discussing HMACs and preventing nodes from putting words in the mouths of other nodes, perhaps we should consider, how we can ensure that nodes can be forced to be accurate about what happened. For instance, a proposal is for nodes to put

Re: [Lightning-dev] Possibility to Include refund invoice in lightning payments

2019-06-14 Thread ZmnSCPxj via Lightning-dev
Good morning Paberlance, You may be interested in the current work with "TLV" that is on-going at the spec level now. This will allow a sort of key-value map to be sent on every payment. It would be possible, *once TLV has been finalized*, to propose the addition of such data in a Lightning

Re: [Lightning-dev] ECDH for spontaneous payments and offline vending machines

2019-06-11 Thread ZmnSCPxj via Lightning-dev
Good morning Stepan, > Hi ZmnSCPxj, > > > The online node in your proposal is unable to extract `K`, a the > > next-node-ID is never transmitted. > > Then currently for the vending machines we can use a pre-shared common secret > set up at installation time (may be unique for every machine)

Re: [Lightning-dev] ECDH for spontaneous payments and offline vending machines

2019-06-10 Thread ZmnSCPxj via Lightning-dev
Good morning Stepan, > # Offline invoice generation > > Some time ago there was a discussion about offline vending machines, the idea > was to pre-load a vending machine with invoices, display invoices to the user > and ask for the preimage as a payment confirmation. When all invoices are >

Re: [Lightning-dev] ECDH for spontaneous payments and offline vending machines

2019-06-10 Thread ZmnSCPxj via Lightning-dev
Good morning Stepan, These are very good developments and I applaud them. > Vending machine generates an ephemeral key `k` and corresponding ephemeral > node id `K`. It generates an invoice signed with this key. It also includes a > routing information that the payment should go through our

Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

2019-05-19 Thread ZmnSCPxj via Lightning-dev
Good morning Lloyd, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Sunday, May 19, 2019 6:28 PM, Lloyd Fournier wrote: > Hi ZmnSCPxj, > > Sorry for the late reply I only recently had time to review your comments. > I didn't really get your motivation for multiple

Re: [Lightning-dev] Eltoo, anyprevout and chaperone signatures

2019-05-18 Thread ZmnSCPxj via Lightning-dev
Good morning, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday, May 16, 2019 3:55 PM, Bastien TEINTURIER wrote: > Thanks for your answers and links, the previous discussions probably happened > before I joined this list so I'll go dig into the archive ;) > > >

Re: [Lightning-dev] Eltoo, anyprevout and chaperone signatures

2019-05-15 Thread ZmnSCPxj via Lightning-dev
Good morning, > > We could collapse those 1-of-2 multisigs into a single-sig if we just > collaboratively create a shared private key that is specific to the > instance of the protocol upon setup. That minimizes the extra space > needed. For that matter the `OP_CHECKMULTISIG`/`OP_CHECKSIGADD`

Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

2019-05-05 Thread ZmnSCPxj via Lightning-dev
er cross chain option with guaranteed premium. > We made a poster describing this idea here: > https://coblox.tech/docs/financial_crypto19.pdf. > > Cheers, > > Lloyd > On Tue, Apr 23, 2019 at 1:52 PM ZmnSCPxj via Lightning-dev > wrote: > > > Good morning list, > >

Re: [Lightning-dev] Ptarmigan mainnet release

2019-04-29 Thread ZmnSCPxj via Lightning-dev
Omedetou goziemasu Hiroki-san to Nayuta. I hope you have good first mainnet release and fix many bug! Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Tuesday, April 30, 2019 9:00 AM, Hiroki Gondo wrote: > Hi, all. > > I’m Hiroki (Nayuta team). > We

[Lightning-dev] Improving Payment Latency by Fast Forwards

2019-04-24 Thread ZmnSCPxj via Lightning-dev
Introduction Currently, the protocol for forwarding requires 1.5 round trips before the next node can safely forward the payment. This creates much greater latency for payments, and even with the current network at a nascent stage, payments can take entire seconds to complete. As

Re: [Lightning-dev] An Argument For Single-Asset Lightning Network

2019-04-22 Thread ZmnSCPxj via Lightning-dev
Good morning list, Reviving an old thread, but I saw this just recently: http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/atomic-swaps/ Suppose you are a BTC to WJT exchange. I want to pay 1 BTC to send 10 WJT to YAIjbOJA. I have a BTC channel to you. You have a WJT channel

Re: [Lightning-dev] Broken Factory Attack

2019-04-16 Thread ZmnSCPxj via Lightning-dev
Good morning Alejandro, and list, I am uncertain if this would completely solve it, but Discrete Log Contracts has a mechanism by which an Oracle is enforced to reveal its private key, if it publishes multiple signatures signing different messages for a particular sampling. It seems like a way

Re: [Lightning-dev] Stale Factory (and channel) problem

2019-04-16 Thread ZmnSCPxj via Lightning-dev
Good morning Alejandro and list, Let me characterize the problem in detail. * Stale offchain system is the issue where one participant of a multiparticipant offchain system sends a signature that advances the protocol, but is unable to receive further signatures from one or more of the other

Re: [Lightning-dev] Stale Factory (and channel) problem

2019-04-16 Thread ZmnSCPxj via Lightning-dev
Good morning Alejandro, > that's correct, Lightning Factories require support for "transaction > fragments" to be added dynamically, which are only possible when using > non-interactive aggregation signature schemes.  I understand. Unfortunately I am not a mathematician and cannot comment on

Re: [Lightning-dev] Stale Factory (and channel) problem

2019-04-16 Thread ZmnSCPxj via Lightning-dev
Good morning Alejandro, Your analyses seem to be quite spot on. It does seem that factories need some work to be done further. As I understand it, the proposal in "Scalable Lightning Factories for Bitcoin" require a new signature scheme at the blockchain layer, is that correct? I observe that

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-04-09 Thread ZmnSCPxj via Lightning-dev
Good morning m.a.holden, > > Let me clarify: When you say "node" here, do you mean Lightning Network > > node? > > Or do you mean instead an in-memory node? > > Neither. I meant a node in a tree. I tried to use the term bucket to make the > distinction between this and Lightning node. > The

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-04-07 Thread ZmnSCPxj via Lightning-dev
Good morning m.a.holden, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Saturday, April 6, 2019 10:39 AM, m.a.holden m.a.hol...@protonmail.com wrote: > Good morning ZmnSCPxj, > I'll try to clarify my proposal further, but also have a few questions about > yours. > > >

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-04-04 Thread ZmnSCPxj via Lightning-dev
Good morning m.a.holden, > > I think you might have misunderstood what I was proposing, but it's probably > my fault for not expressing it well. With my suggestion, all nodes continue > to be equal participants and there are no special nodes. I used the term > "endpoint" previously to mean one

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

2019-04-04 Thread ZmnSCPxj via Lightning-dev
Good morning Christian, First: > Like mentioned above the entire job of trampolines is to provide base > routing capability, and we should not make special provisions for myopic > trampoline nodes, since routing is their entire reason for existence :-) The point of providing this special

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

2019-04-04 Thread ZmnSCPxj via Lightning-dev
Good morning list, > Could this be implemented by replacing only the front of the trampoline-level > onion? > (presumably with some adjustment of how the HMAC is computed for the new > trampoline layer) I am trying to design a trampoline-level onion that would allow replacement of the first

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-04-02 Thread ZmnSCPxj via Lightning-dev
Good morning list, > One way you could have both determinism and encourage a diverse distribution > of network maps is to treat it as a spatial indexing problem, where the space > we use is the lexicographical space of the node ids (or hashes of), borrowing > some similarities from DHTs. > >

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

2019-04-02 Thread ZmnSCPxj via Lightning-dev
Good morning Pierre and list, > There is another unrelated issue: because trampoline nodes don't know > anything about what happened before they received the onion, they may > unintentionnaly create overlapping routes. So we can't simply use the > payment_hash as we currently do,

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

2019-04-01 Thread ZmnSCPxj via Lightning-dev
Good morning Christian, > > There are two ways we can use this: > > - A simple variant in which we just tell a single trampoline what the > intended recipient is (just a pubkey, and an amount) and it'll find a > route. > > - A complex variant in which a trampoline is given a next

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

2019-04-01 Thread ZmnSCPxj via Lightning-dev
Good morning Pierre, Rene, and list, I would also like to point out that even if the trampoline point does not know the next trampoline point, then it need not fail the routing. (this may occur if we start pruning the routemap as the LN size grows) As long as we can fix the issues regarding

Re: [Lightning-dev] Eltoo in a tree

2019-04-01 Thread ZmnSCPxj via Lightning-dev
Good morning Hossein, This is already known. Indeed, this is the basis of Burchert-Decker-Wattenhofer "Channel Factories". https://www.tik.ee.ethz.ch/file/a20a865ce40d40c8f942cf206a7cba96/Scalable_Funding_Of_Blockchain_Micropayment_Networks%20(1).pdf See also discussion regarding Fulgurite.

Re: [Lightning-dev] Outsourcing route computation with trampoline payments

2019-03-31 Thread ZmnSCPxj via Lightning-dev
Good morning Rene and Pierre, An issue here (which I think also affects Rendezvous Routing) is with compatibility of the HMAC. HMAC covers the entire 1300-byte `hops_data` field. If, in order to reach the next trampoline, more than one intermediate node is inserted, would the packet that

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-03-31 Thread ZmnSCPxj via Lightning-dev
Good morning Rene, > > Maybe I oversee something - in that case sorry for spamming the list - but I > don't understand how you could know the distance from yourself if you don't > know the entire topology? (unless u use it on the pruned view as you > suggested)  That is correct, and the

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-03-31 Thread ZmnSCPxj via Lightning-dev
Good morning Ariel, > > A good pruning heuristic is "channel capacity", which can be checked > > onchain (the value of the UTXO backing the channel is the channel capacity). > > It is good to keep channels with large capacity in the routemap, because > > such large channels are more likely to

Re: [Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-03-29 Thread ZmnSCPxj via Lightning-dev
Good morning Rene, Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, March 29, 2019 1:54 PM, René Pickhardt wrote: > Dear ZmnSCPxj and fellow lightning developers, > > I want to point out two things and make a suggestion for a new gossip > message.  > > > A good

[Lightning-dev] Routemap scaling (was: Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0)

2019-03-28 Thread ZmnSCPxj via Lightning-dev
Good morning Ariel, I am forking this thread as my reply is not at all related to the JIT-Routing. Sent with ProtonMail Secure Email. > Public nodes could advertise channels which don't actually exist directly but > are instead hidden paths that the source node doesn't need to know or care >

Re: [Lightning-dev] Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0

2019-03-25 Thread ZmnSCPxj via Lightning-dev
Good morning Ariel and Rene and list, I have started to consider how best to attack the modified Luaces-Pickhardt JIT-Routing, which reuses the same payment hash as the message to forward. (In the case where JIT-Routing is used by the ultimate source of a payment, the payment hash of the

Re: [Lightning-dev] Just in Time Routing (JIT-Routing) and a channel rebalancing heuristic as an add on for improved routing success in BOLT 1.0

2019-03-22 Thread ZmnSCPxj via Lightning-dev
Good morning list, I have been thinking of JIT-Routing in the context of unidirectional channels, as for example in Eclair Mobile. Now of course unidirectional-only nodes as in Eclair Mobile cannot forward and cannot be intermediate nodes. However, as I pointed out in previous email, the same

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-22 Thread ZmnSCPxj via Lightning-dev
Good morning aj, I understand. Looks like that makes sense. It seems possible to use this, then, together with watchtowers. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Friday, March 22, 2019 10:58 AM, Anthony Towns wrote: > On Fri, Mar 22, 2019

  1   2   3   4   >