Good morning list,
> Good morning David, and list,
>
> It seems to me possible (though potentially undesirable) to have a "maximally
> private" channel that uses only absolute locktimes.
>
> For maximum privacy, you would need to sign new pairs of commitment
> transactions at every block anyway.
Good morning David, and list,
It seems to me possible (though potentially undesirable) to have a "maximally
private" channel that uses *only* absolute locktimes.
For maximum privacy, you would need to sign new pairs of commitment
transactions at every block anyway.
And if you sign a new pair "t
On Sun, Jan 12, 2020 at 03:01:06PM +, ZmnSCPxj wrote:
> Basically, on every Poon-Dryja commitment transaction [...]
>
> * one output will be directly spendable by the remote side.
> * one output will be spendable by the local side [...] after a
> relative locktime [...]
>
> So if the remote
Good morning David,
> On Tue, Jan 07, 2020 at 12:26:05AM +, ZmnSCPxj wrote:
>
> > For `nSequence` relative-locktime transactions that protect the
> > security of the channel mechanism, these are used in unilateral
> > closes. The issue is that a unilateral close might occur far, far in
> > th
On Tue, Jan 07, 2020 at 12:26:05AM +, ZmnSCPxj wrote:
> For `nSequence` relative-locktime transactions that protect the
> security of the channel mechanism, these are used in unilateral
> closes. The issue is that a unilateral close might occur far, far in
> the future. Thus, any non-0 `nLock
Good morning,
Another point regarding the use of "purely scriptless" (i.e. using pre-signed
`nLockTime` and `nSequence`d transactions) is that there are significantly more
signatures to be generated cooperatively.
We need to use MuSig for these in order to hide in the much larger 1-of-1
anonymi
Good morning David,
> On Wed, Dec 18, 2019 at 02:51:56PM +1100, Lloyd Fournier wrote:
>
> > Hi ZmnSCPxj and Aj,
> > Thanks for starting this discussion ZmnSCPxj. Although transactions with
> > relative lock times are easily distinguishable today, couldn't this
> > situation be improved? Even just
> indeed one can argue that the entire point of enabling Schnorr and Taproot at
> the base layer is to allow us to use payment point+scalar at the Lightning
> layer.
Just to be clear, this statement is intended to be facetious, along the same
vein as "Lightning Network is so awesome, we just
On Wed, Dec 18, 2019 at 02:51:56PM +1100, Lloyd Fournier wrote:
> Hi ZmnSCPxj and Aj,
>
> Thanks for starting this discussion ZmnSCPxj. Although transactions with
> relative lock times are easily distinguishable today, couldn't this
> situation be improved? Even just a few wallets changing their b
Hi ZmnSCPxj and Aj,
Thanks for starting this discussion ZmnSCPxj. Although transactions with
relative lock times are easily distinguishable today, couldn't this
situation be improved? Even just a few wallets changing their behaviour to
set relative time locks on normal payments would weaken the he
Good morning,
> On Sun, Dec 15, 2019 at 03:43:07PM +, ZmnSCPxj via Lightning-dev wrote:
>
> > For now, I am assuming the continued use of the existing Poon-Dryja update
> > mechanism.
> > Decker-Russell-Osuntokun requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`,
> > and its details seem less
On Sun, Dec 15, 2019 at 03:43:07PM +, ZmnSCPxj via Lightning-dev wrote:
> For now, I am assuming the continued use of the existing Poon-Dryja update
> mechanism.
> Decker-Russell-Osuntokun requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`, and
> its details seem less settled for now than taproo
Given the timeline for soft forks to activate on Bitcoin, I don't know
why we'd be super conservative about using new features of the Bitcoin
consensus rules. I think obviously we'd want to rush as fast as we can
into adding real cross-hop privacy to lightning payments, given both the
number of awk
Good morning list,
I would like to initiate some discussion on how Lightning could be updated to
take advantage of the upcoming taproot update to the base layer.
For now, I am assuming the continued use of the existing Poon-Dryja update
mechanism.
Decker-Russell-Osuntokun requires `SIGHASH_NOIN
14 matches
Mail list logo
