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, >

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] 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] 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] 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] 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] 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] 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