Good morning Rusty,
In BOLT #2 we currently impose a 2^24 satoshi limit on total channel capacity.
Is splicing intended to allow violation of this limit? I do not see it
mentioned in the proposal. Can I splice 21 million bitcoins on a 1-satoshi
channel?
It may be good to start brainstorming p
René Pickhardt writes:
> So let us take the example of Splicing in:
> * The situation before splicing is that we have one output in our funding
> tx that is being spent with each commitment tx. (actually if the channel
> was spliced before we have more inputs but that should not change anything)
>
Dear Rusty,
thanks for the initiative. You suggested in your paragraph "messages
changes during splicing" during splicing to duplicate each commitment
transaction. One which spends the old funding tx and one which spends the
spliced tx. I believe this can be simplified. Though I think my workflow
I agree the r-fields are useful to populate for public channels in many
situations, but care must be taken to not _always_ try them first without
accounting for potentially high fees on those channels.
- Johan
On Wed, Oct 10, 2018 at 5:46 AM Rusty Russell wrote:
> Pierre writes:
> >> But there'
On Mon, Apr 30, 2018 at 05:41:38PM +0200, Christian Decker wrote:
> eltoo is a drop-in replacement for the penalty based invalidation
> mechanism that is used today in the Lightning specification. [...]
Maybe this is obvious, but in case it's not, re: the locktime-based
sequencing in eltoo:
"any
