📅 Original date posted:2018-07-04
📝 Original message:
Christian Decker <decker.christian at gmail.com> writes:
> ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> writes:
>> For myself, I think splice is less priority than AMP. But I prefer an
>> AMP which retains proper ZKCP (i.e. receipt of preimage at payer
>> implies receipt of payment at payee, to facilitate trustless
>> on-to-offchain and off-to-onchain bridges).
>
> Agreed, multipath routing is a priority, but I think splicing is just as
> much a key piece to a better UX, since it allows to ignore differences
> between on-chain and off-chain funds, showing just a single balance for
> all use-cases.
Agreed, we need both. Multi-channel was a hack because splicing doesn't
exist, and I'd rather not ever have to implement multi-channel :)
AMP is important, but it's a nasty compromise with the current
limitations. I want to have my cake and eat it too, and I'm pretty sure
it's possible once the Scnorr-Eltoonicorn arrives.
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-09 12:51:03
in reply to nevent1q…6f6w
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-09 12:51:03Event JSON
{
"id": "1c2d348a22a840e7fd8895b6066a40eae70ef6f23ca01837bb154c0ac09c3250",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686315063,
"kind": 1,
"tags": [
[
"e",
"8705da9b85f9ef58ca8afd03c294dca93ff511081b81057f36ea2baa8a76a7e6",
"",
"root"
],
[
"e",
"530617235c96cd8892cd67df728b036271d6352ba587fba5edb5b2d0c0711242",
"",
"reply"
],
[
"p",
"72cd40332ec782dd0a7f63acb03e3b6fdafa6d91bd1b6125cd8b7117a1bb8057"
]
],
"content": "📅 Original date posted:2018-07-04\n📝 Original message:\nChristian Decker \u003cdecker.christian at gmail.com\u003e writes:\n\n\u003e ZmnSCPxj via Lightning-dev \u003clightning-dev at lists.linuxfoundation.org\u003e writes:\n\u003e\u003e For myself, I think splice is less priority than AMP. But I prefer an\n\u003e\u003e AMP which retains proper ZKCP (i.e. receipt of preimage at payer\n\u003e\u003e implies receipt of payment at payee, to facilitate trustless\n\u003e\u003e on-to-offchain and off-to-onchain bridges).\n\u003e\n\u003e Agreed, multipath routing is a priority, but I think splicing is just as\n\u003e much a key piece to a better UX, since it allows to ignore differences\n\u003e between on-chain and off-chain funds, showing just a single balance for\n\u003e all use-cases.\n\nAgreed, we need both. Multi-channel was a hack because splicing doesn't\nexist, and I'd rather not ever have to implement multi-channel :)\n\nAMP is important, but it's a nasty compromise with the current\nlimitations. I want to have my cake and eat it too, and I'm pretty sure\nit's possible once the Scnorr-Eltoonicorn arrives.\n\nCheers,\nRusty.",
"sig": "869ca068e77702efcf7e666e80fd529d22b369837b889e9177af45f4dc7e53772f4c5fa67df96507da1ac91f3c02bff0ee06ae294098603bb497346b0bc1eccf"
}