Hey Christian,
Love this chain of thought! Back before I'd realized as ZmnSCPxj did that
we have a nice general NOT operation for a given point, I had a similar
thought on this thread
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-October/002213.html
where we eventually figured
Hey ZmnSCPxj,
Your earlier post about how to accomplish ORing points without verifiable
encryption was super interesting.
I think this contains a clever general NOT operation where you double the
payment and use the point as a condition for the "cancellation payment."
This is actually very
Hi Andrés,
> Am I correct in understanding that this is a proposal to change the spec
(maybe add a new BOLT) so that all lightning implementations can try to
support this feature.
Yes, the proposal relies on the use of PTLCs in place of HTLCs which is a
popular change that will (hopefully) be
Hi all,
# Simulating Eltoo / ANYPREVOUT Factories Using SCU Escrows
In this write-up I hope to convince you that it is possible to create some
weak version of Eltoo channels and channel factories today without
SIGHASH_ANYPREVOUT (although the version using this sighash is clearly
superior) using
of more involved ZKPs), but since it still uses OP_CMS, it can't
> be used to modify the funding output.
>
> [1]:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-December/002375.html
>
> -- Laolu
>
>
> On Wed, Apr 22, 2020 at 8:13 AM Nadav Kohen wrote:
>
&
Hello all,
I'd like to give an update on the current state of thinking and coding
surrounding replacing Hash-TimeLock Contracts (HTLCs) with Point-TimeLock
Contracts (PTLCs) (aka Payment Hashes -> Payment Points) in hopes of
sparking interest, discussion, development, etc.
We Want Payment
Good morning ZmnSCPxj and all,
I had this thought too! I wrote a blog post series summarizing much of this
old thread and here are the two posts about Barrier Escrows:
https://suredbits.com/payment-points-and-barrier-escrows/
https://suredbits.com/payment-points-implementing-barrier-escrows/
Good morning ZmnSCPxj,
> The consideration is that much of the cost of a channel is with the setup
and teardown --- E could always just reopen the CE channel again later.
> Thus, the cost that E bears in setting up EE and tearing down EE would be
still similar to the cost of losing CE and
other parties now have the ability to publish an old state? I
might be missing something but this seems like a big problem.
Best,
Nadav
On Wed, Apr 1, 2020 at 1:07 PM Nadav Kohen wrote:
> Hi ZmnSCPxj and list,
>
> Love the idea! I have a couple questions though:
>
> I'm not convinc
Hi Konstantin,
This looks cool and I haven't had a chance yet to spend time with the idea,
but I would like to add that you can likely solve the PoP problem mentioned
under potential issues by having S pay B with an AMP-like setup. We use the
point B + x*G on one payment where x is a nonce
Hey CJP and list,
Thanks for the post!
> Maybe the problem of atomically exchanging two secrets has already been
> solved in a more elegant way (ECDH, anyone?)
I don't know of any nice way of doing this since it seems like it should be
impossible for both parties to learn something in a single
Hi all,
After having some more thinking I think I have another cool thing that can
be done with barrier escrows.
We already have established that pay-for-atomic-multi-payment-setup can be
provided by using a High AMP to a node that is trusted not to collude with
the parties involved (along with
Hi list and ZmnSCPxj,
Glad this has been helpful and I'm not just stating obvious things :)
always hard to tell once the idea has been had.
> I think, it is possible to make, a miniscript-like language for such
things.
> Indeed, the only material difference, between SCRIPT-based
`OP_CHECKSIG`s
Hi list,
I'm back again with another idea about Payment Points and fun things to do
with them! Hopefully this time I'm not entirely just hashing out old ideas
in public like an out-of-the-loop person :)
*TLDR: Adding and ECDH-ing points gives us AND and OR functionality which
we can compose to
Oh darn!
My bad for posting so fast, I should have looked around more :P
Thanks for the info!
And agreed, it would be awesome to have even if just as a proof of concept.
Best,
Nadav
On Wed, Oct 2, 2019 at 6:48 PM ZmnSCPxj wrote:
> Good morning Nadav,
>
> Yes, this is possible.
>
>
>
Hi list,
Like most people I am super excited for AMPs to hit the lightning network!
(For the remainder of this post when I say AMP I mean OG AMP (
https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html)
since that is the one I know)
It is my understanding however
Hey all,
The following is a link to the documentation for what we've been calling a
*PAID* (Payment-Atomic Information Decryption) *API*:
https://test.suredbits.com/api/#historical-prices-data-api-2
despite what the docs say it is currently only working on testnet, but
should be on mainnet within
el like I am missing some background.
>
> LL
>
> On Thu, Jul 18, 2019 at 2:56 AM Nadav Kohen wrote:
>
>> Hi Lloyd,
>>
>> Glad you like it :) And to address your concern, I think that although
>> certainly it is possible for oracles to sell options contracts, it is
Hi All,
I recently posted a proposal here for a scheme through which a trusted data
provider can utilize the Lightning Network to privately sell data where
data is received atomically with purchase.
I've more recently been thinking about situations where a party, that is
*not* trusted, is
Hi ZmnSCPxj and Stepan,
Thanks for all the feedback!
I think doing encrypt-then-mac on chunks of the data would be a great
addition for users to be able to authenticate that they received the
intended data.
> Any node on the route of the payment knows the preimage and can decrypt
the data. It
Hi Ugam,
I also ran into an issue understanding this a while back, here's a PR I
opened to try and make things more clear:
https://github.com/lightningnetwork/lightning-rfc/pull/601
Feel free to add to it or comment if you think things could be improved :)
Best,
Nadav
On Wed, Jun 5, 2019 at
21 matches
Mail list logo
