Hi Bastien,
The use case you're describing strikes me as similar to a slashing protocol
for a LN node and a watchtower, i.e punishing
a lazy watchtower for not broadcasting a penalty tx on remote revoked
state. In both case you want "if A don't do X
unlock some funds for B".
Here a rough
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
From where I'm sitting the fact that OP_CAT allows people to build
more powerful constructions in Bitcoin without introducing additional
complexity at the consensus layer is a positive not a negative. Using
OP_CAT or OP_SUBSTRING to enforce ECDSA nonce reuse is a very powerful
protocol tool for
Good morning t-bast,
Further, we can enforce that RBF is signalled for every spend of the output by:
<0> OP_CHECKSEQUENCEVERIFY OP_DROP OP_SWAP OP_CAT OP_CHECKSIG
Requiring that RBF is signalled gives a little more assurance.
Suppose ACINQ becomes evil and double-spends the output.
The
Thanks a lot David for the suggestion and pointers, that's a really
interesting solution.
I will dive into that in-depth, it could be very useful for many layer-2
constructions.
Thanks ZmnSCPxj as well for the quick feedback and the `OP_CAT`
construction,
a lot of cool tricks coming up once (if?)
Good morning David, t-bast, and all,
> I'm not aware of any way to currently force single-show signatures in
> Bitcoin, so this is pretty theoretical. Also, single-show signatures
> add a lot of fragility to any setup and make useful features like RBF
> fee bumping unavailable.
With `OP_CAT`,
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 Tue, Dec 17, 2019 at 09:34:07AM +0100, Bastien TEINTURIER wrote:
> With Phoenix [1], we've been experimenting with pay-to-open [2].
>
> That works well in practice and provides a great UX for newcomers, but
> it requires temporary trust between the user and our node (until the
> funding tx
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
Good morning t-bast,
>
> Thanks for your response.
>
> > * Once the pre-funding is sufficiently confirmed as per Bob security
> > parameter
>
> This is the part I'm trying to avoid. If we're ok with waiting for
> confirmation, then it's easy to do indeed (and let's just wait for the
> funding
Hi ZmnSCPxj,
Thanks for your response.
* Once the pre-funding is sufficiently confirmed as per Bob security
> parameter
>
This is the part I'm trying to avoid. If we're ok with waiting for
confirmation, then it's easy to do indeed (and let's just wait for the
funding tx to confirm, I believe we
Good morning t-bast,
> Good morning list,
>
> As everyone who has ever used a Lightning wallet is well aware, the
> onboarding process could be
> made smoother. With Phoenix [1], we've been experimenting with pay-to-open
> [2].
>
> That works well in practice and provides a great UX for
Good morning list,
As everyone who has ever used a Lightning wallet is well aware, the
onboarding process could be
made smoother. With Phoenix [1], we've been experimenting with pay-to-open
[2].
That works well in practice and provides a great UX for newcomers, but it
requires temporary trust
13 matches
Mail list logo
