📅 Original date posted:2018-07-05
📝 Original message:
> #1 lets us leave out double-funded channels. #2 and #3 lets us leave out
> splice.
> For myself, I would rather leave out AMP and double-funding and splicing
> than remove ZKCP.
It isn't one or the other. ZKCPs are compatible with various flavors of AMP.
All of these technologies can be rolled out, some with less coordination
than others. Please stop presenting these upgrades as if they're opposing
and fundamental constrains only allow a handful of them to be deployed.
Dual funded channels allow for immediate bi-directional transfers between
endpoints. Splicing allows channels to contract or grow, as well as: pay out
to on chain addresses, fund new channel on the fly, close into old channels,
consolidate change addresses, create fee inputs for eltoo, orchestrate
closing/opening coin-joins, etc, etc.
-- Laolu
On Wed, Jul 4, 2018 at 10:36 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning all,
>
> > > What's the nasty compromise?
> > >
> > > Let's also not underestimate how big of an update switching to dlog
> based
> > >
> > > HTLCs will be.
> >
> > Was referring to losing proof-of-payment; that's vital in a system
> >
> > without intermediaries. We have to decide what the lesser evil is.
>
> Without the inherent ZKCP, it becomes impossible to build a trustless
> off-to-on/on-to-offchain bridge, since a trustless swap outside of
> Lightning becomes impossible. To my mind, ZKCP is an important building
> block in cryptocurrency: it is what we use in Lightning for routing.
> Further, ZKCP can be composed together to form a larger ZKCP, which again
> is what we use in Lightning for routing.
>
> The ZKCP here is what lets LN endpoint to interact with the chain and lets
> off-to-on/on-to-offchain bridges to be trustless.
>
> off/onchain bridges are important as they provide:
>
> 1. Incoming channels: Get some onchain funds from cold storage (or
> borrowed), create an outgoing channel (likely to the bridge for best chance
> of working), then ask bridge for an invoice to send money to an address you
> control onchain. The outgoing channel capacity becomes incoming capacity,
> you get (most of) your money back (minus fees) onchain.
> 2. Reloading spent channels. Give bridge an invoice and pay to the
> bridge to trigger it reloading your channel.
> 3. Unloading full channels. If you earn so much money (minus what you
> spend on expenses, subcontractors, employees, suppliers, etc.) you can use
> the bridge to send directly to your cold storage.
>
> #1 lets us leave out double-funded channels. #2 and #3 lets us leave out
> splice.
>
> The interaction between bridge and Lightning is simply via BOLT11
> invoices. Those provide the ZKCP necessary to make the bridge trustless.
>
> AMP enhances such a Lightning+bridge network, since the importance of
> maximum channel capacity is reduced if a ZKCP-providing AMP is available.
> For myself, I would rather leave out AMP and double-funding and splicing
> than remove ZKCP.
>
> One could imagine a semi-trusted ZKCP service for real-world items. Some
> semi-trusted institution provides special safeboxes for rent that can be
> unlocked either by seller private key after 1008 blocks, or by the
> recipient key and a proof-of-payment preimage (and records the preimage in
> some publicly-accessible website). To sell a real-world item, make a
> BOLT11 invoice, bring item to a safebox, lock it with appropriate keys and
> the invoice payment hash, give BOLT11 invoice to buyer. Buyer pays and
> gets proof-of-payment preimage, goes to safebox and gets item. Multi-way
> trades (A wants item from B, B wants item from C, C wants item from A) are
> just compositions of ZKCP.
>
> >
> > And yeah, I called it Schnorr-Eltoonicorn not only because it's sooooo
> >
> > pretty, but because actually capturing it will be a saga.
>
> Bards shall sing about The Hunt for Schnorr-Eltoonicorn for ages, until
> Satoshi himself is but a vague memory of a myth long forgotten.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180704/40862c92/attachment.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 12:51:04
in reply to nevent1q…8wwg
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 12:51:04Event JSON
{
"id": "b965b2d25aa2137e4e9bf2145c07b84d8f4aa3b98b77e40034e5ac67ac1a83c1",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686315064,
"kind": 1,
"tags": [
[
"e",
"8705da9b85f9ef58ca8afd03c294dca93ff511081b81057f36ea2baa8a76a7e6",
"",
"root"
],
[
"e",
"9ef863d44604572ad459fcd13cf34204ff3559b95995fd90089a5302bdc695fc",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-07-05\n📝 Original message:\n\u003e #1 lets us leave out double-funded channels. #2 and #3 lets us leave out\n\u003e splice.\n\n\u003e For myself, I would rather leave out AMP and double-funding and splicing\n\u003e than remove ZKCP.\n\nIt isn't one or the other. ZKCPs are compatible with various flavors of AMP.\nAll of these technologies can be rolled out, some with less coordination\nthan others. Please stop presenting these upgrades as if they're opposing\nand fundamental constrains only allow a handful of them to be deployed.\n\nDual funded channels allow for immediate bi-directional transfers between\nendpoints. Splicing allows channels to contract or grow, as well as: pay out\nto on chain addresses, fund new channel on the fly, close into old channels,\nconsolidate change addresses, create fee inputs for eltoo, orchestrate\nclosing/opening coin-joins, etc, etc.\n\n-- Laolu\n\nOn Wed, Jul 4, 2018 at 10:36 PM ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e Good morning all,\n\u003e\n\u003e \u003e \u003e What's the nasty compromise?\n\u003e \u003e \u003e\n\u003e \u003e \u003e Let's also not underestimate how big of an update switching to dlog\n\u003e based\n\u003e \u003e \u003e\n\u003e \u003e \u003e HTLCs will be.\n\u003e \u003e\n\u003e \u003e Was referring to losing proof-of-payment; that's vital in a system\n\u003e \u003e\n\u003e \u003e without intermediaries. We have to decide what the lesser evil is.\n\u003e\n\u003e Without the inherent ZKCP, it becomes impossible to build a trustless\n\u003e off-to-on/on-to-offchain bridge, since a trustless swap outside of\n\u003e Lightning becomes impossible. To my mind, ZKCP is an important building\n\u003e block in cryptocurrency: it is what we use in Lightning for routing.\n\u003e Further, ZKCP can be composed together to form a larger ZKCP, which again\n\u003e is what we use in Lightning for routing.\n\u003e\n\u003e The ZKCP here is what lets LN endpoint to interact with the chain and lets\n\u003e off-to-on/on-to-offchain bridges to be trustless.\n\u003e\n\u003e off/onchain bridges are important as they provide:\n\u003e\n\u003e 1. Incoming channels: Get some onchain funds from cold storage (or\n\u003e borrowed), create an outgoing channel (likely to the bridge for best chance\n\u003e of working), then ask bridge for an invoice to send money to an address you\n\u003e control onchain. The outgoing channel capacity becomes incoming capacity,\n\u003e you get (most of) your money back (minus fees) onchain.\n\u003e 2. Reloading spent channels. Give bridge an invoice and pay to the\n\u003e bridge to trigger it reloading your channel.\n\u003e 3. Unloading full channels. If you earn so much money (minus what you\n\u003e spend on expenses, subcontractors, employees, suppliers, etc.) you can use\n\u003e the bridge to send directly to your cold storage.\n\u003e\n\u003e #1 lets us leave out double-funded channels. #2 and #3 lets us leave out\n\u003e splice.\n\u003e\n\u003e The interaction between bridge and Lightning is simply via BOLT11\n\u003e invoices. Those provide the ZKCP necessary to make the bridge trustless.\n\u003e\n\u003e AMP enhances such a Lightning+bridge network, since the importance of\n\u003e maximum channel capacity is reduced if a ZKCP-providing AMP is available.\n\u003e For myself, I would rather leave out AMP and double-funding and splicing\n\u003e than remove ZKCP.\n\u003e\n\u003e One could imagine a semi-trusted ZKCP service for real-world items. Some\n\u003e semi-trusted institution provides special safeboxes for rent that can be\n\u003e unlocked either by seller private key after 1008 blocks, or by the\n\u003e recipient key and a proof-of-payment preimage (and records the preimage in\n\u003e some publicly-accessible website). To sell a real-world item, make a\n\u003e BOLT11 invoice, bring item to a safebox, lock it with appropriate keys and\n\u003e the invoice payment hash, give BOLT11 invoice to buyer. Buyer pays and\n\u003e gets proof-of-payment preimage, goes to safebox and gets item. Multi-way\n\u003e trades (A wants item from B, B wants item from C, C wants item from A) are\n\u003e just compositions of ZKCP.\n\u003e\n\u003e \u003e\n\u003e \u003e And yeah, I called it Schnorr-Eltoonicorn not only because it's sooooo\n\u003e \u003e\n\u003e \u003e pretty, but because actually capturing it will be a saga.\n\u003e\n\u003e Bards shall sing about The Hunt for Schnorr-Eltoonicorn for ages, until\n\u003e Satoshi himself is but a vague memory of a myth long forgotten.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180704/40862c92/attachment.html\u003e",
"sig": "04f798bb57648bd47e47d85822aa10b4aac8f48643262eaf4ddd30332ea7ad8ba63f7dcd37eb20f57a190eb67ea726963ce1df47752c825c4cc36232ae9cc3a6"
}