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