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

2018-11-05 Thread Olaoluwa Osuntokun
> Mainly limitations of our descriptor language, TBH. I don't follow...so it's a size issue? Or wanting to avoid "repeated" fields? > I thought about restarting the revocation sequence, but it seems like that > only saves a tiny amount since we only store log(N) entries Yeah that makes sense,

Re: [Lightning-dev] Wireshark plug-in for Lightning Network(BOLT) protocol

2018-11-05 Thread Olaoluwa Osuntokun
Hi tomokio, This is so dope! We've long discussed creating canned protocol transcripts for other implementations to assert their responses again, and I think this is a great first step towards that. > Our proposal: > Every implementation has compile option which enable output key information >

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

2018-11-05 Thread Olaoluwa Osuntokun
> However personally I do not really see the need to create multiple channels > to a single peer, or increase the capacity with a specific peer (via splice > or dual-funding). As Christian says in the other mail, this consideration, > is that it becomes less a network and more of some channels to

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

2018-11-05 Thread Olaoluwa Osuntokun
> This seems at odds with the goal of "if the remote party force closes, then > I get my funds back immediately without requiring knowledge of any secret > data" Scratch that: the static back ups just need to include this CSV value! -- Laolu On Tue, Nov 6, 2018 at 3:29 PM Olaoluwa Osuntokun

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

2018-11-05 Thread Rusty Russell
Olaoluwa Osuntokun writes: > Hi Rusty, > > I'm a big fan in general of most of this! Amongst many other things, it'll: > simplify the whole static channel backup + recovery workflow, and avoid all > the fee related headaches we've run into over the past few months. I certainly hope so! >> -

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

2018-11-05 Thread Olaoluwa Osuntokun
Hi Rusty, I'm a big fan in general of most of this! Amongst many other things, it'll: simplify the whole static channel backup + recovery workflow, and avoid all the fee related headaches we've run into over the past few months. > - HTLC-timeout and HTLC-success txs sigs are >

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

2018-11-05 Thread CJP
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, based on this knowledge? Bob might actually face even worse penalties for

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-05 Thread Gert-Jaap Glasbergen
Op 1 nov. 2018 om 03:38 heeft Rusty Russell mailto:ru...@rustcorp.com.au>> het volgende geschreven: I believe this would render you inoperable in practice; fees are frequently sub-satoshi, so you would fail everything. The entire network would have to drop millisatoshis, and the bitcoin

Re: [Lightning-dev] Proposal for updateable / revokable proofs of payment

2018-11-05 Thread CJP
I think it's true that most of my proposal can be achieved by writing such things in human-readable form in the description field. Mostly, the only thing my proposal does is to put things into a machine- readable form; this may aid in automated processing and maybe a better UI experience. Maybe

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

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