Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-08 Thread ZmnSCPxj via Lightning-dev
Good morning aj, > On Sat, Oct 09, 2021 at 01:49:38AM +, ZmnSCPxj wrote: > > > A transaction is required, but I believe it is not necessary to put it > > onchain (at the cost of implementation complexity in the drop-onchain case). > > The trick with that is that if you don't put it on chain,

Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-08 Thread Anthony Towns
On Sat, Oct 09, 2021 at 01:49:38AM +, ZmnSCPxj wrote: > A transaction is required, but I believe it is not necessary to put it > *onchain* (at the cost of implementation complexity in the drop-onchain case). The trick with that is that if you don't put it on chain, you need to calculate the f

Re: [Lightning-dev] Lightning over taproot with PTLCs

2021-10-08 Thread ZmnSCPxj via Lightning-dev
Good morning aj, > In order to transition from BOLT#3 format to this proposal, an onchain > transaction is required, as the "revocable signatures" arrangement cannot > be mimicked via the existing 2-of-2 CHECKMULTISIG output. A transaction is required, but I believe it is not necessar

[Lightning-dev] Lightning over taproot with PTLCs

2021-10-08 Thread Anthony Towns
Hi all, Here's my proposal for replacing BOLT#2 and BOLT#3 to take advantage of taproot and implement PTLCs. It's particularly inspired by ZmnSCPxj's thoughts from Dec 2019 [0], and some of his and Lloyd Fournier's posts since then (which are listed in references) -- in particular, I think those

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

2021-10-08 Thread ZmnSCPxj via Lightning-dev
Good morning Pieter, > Indeed - UTXO set size is an externality that unfortunately Bitcoin's > consensus rules fail to account > for. Having a relay policy that avoids at the very least economically > irrational behavior makes > perfect sense to me. > > It's also not obvious how consensus rules

[Lightning-dev] Removing lnd's source code from the Lightning specs repository

2021-10-08 Thread Fabrice Drouin
Hello, When you navigate to https://github.com/lightningnetwork/ you find - the Lightning Network white paper - the Lightning Network specifications - and ... the source code for lnd! This has been an anomaly for years, which has created some confusion between Lightning the open-source protocol a

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

2021-10-08 Thread ZmnSCPxj via Lightning-dev
Good morning shymaa, > The suggested idea I was replying to is to make all dust TXs invalid by some > nodes. Is this supposed to be consensus change or not? Why "some" nodes and not all? I think the important bit is for full nodes. Non-full-nodes already work at reduced security; what is import

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

2021-10-08 Thread shymaa arafat
The suggested idea I was replying to is to make all dust TXs invalid by some nodes. I suggested a compromise by keeping them in secondary storage for full nodes, and in a separate Merkle Tree for bridge servers. -In bridge servers they won't increase any worstcase, on the contrary this will enhance