ZmnSCPxj [ARCHIVE] on Nostr: š
Original date posted:2019-02-01 š Original message:Good morning aj, I ...
š
Original date posted:2019-02-01
š Original message:Good morning aj,
I certainly agree.
I hope that PSBT support becomes much, much, much more widespread.
Regards,
ZmnSCPxj
Sent with ProtonMail Secure Email.
āāāāāāā Original Message āāāāāāā
On Thursday, January 31, 2019 2:04 PM, Anthony Towns <aj at erisian.com.au> wrote:
> On Mon, Dec 24, 2018 at 11:47:38AM +0000, ZmnSCPxj via bitcoin-dev wrote:
>
> > A boutique protocol would reduce the number of existing onchain wallets that could be integrated in such UI.
>
> Seems like PSBT would be a sufficient protocol:
>
> 0) lightning node generates a PSBT for a new channel,
> with no inputs and a single output of the 2-of-2 address
>
> 1. wallet funds the PSBT but doesn't sign it, adding a change address
> if necessary, and could combine with other tx's bustapay style
>
> 2. lightning determines txid from PSBT, and creates update/settlement
> tx's for funding tx so funds can be recovered
>
> 3. wallet signs and publishes the PSBT
> 4. lightning sees tx on chain and channel is open
>
> That's a bit more convoluted than "(0) lightning generates an address and
> value, and creates NOINPUT update/settlement tx's for that address/value;
> (1) wallet funds address to exactly that value; (2) lightning monitors
> blockchain for payment to that address" of course.
>
> But it avoids letting users get into the habit of passing NOINPUT
> addresses around, or the risk of a user typo'ing the value and losing
> money immediately, and it has the benefit that the wallet can tweak the
> value if (eg) that avoids a change address or enhances privacy (iirc,
> c-lightning tweaks payment values for that reason). If the channel's
> closed cooperatively, it also avoids ever needing to publish a NOINPUT
> sig (or NOINPUT tagged output).
>
> Does that seem a fair trade off?
>
> Cheers,
> aj
>
Published at
2023-06-07 18:16:10Event JSON
{
"id": "5638c7a881046f7b9b3e8cd64832a4eb27f2d71b907a0dd8452c4aa52515ee81",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686161770,
"kind": 1,
"tags": [
[
"e",
"d115c2cf2fc1879f7295a540eec6df49284da7ea0208c40bff09a5bb6df1c817",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "š
Original date posted:2019-02-01\nš Original message:Good morning aj,\n\nI certainly agree.\nI hope that PSBT support becomes much, much, much more widespread.\n\nRegards,\nZmnSCPxj\n\n\nSent with ProtonMail Secure Email.\n\nāāāāāāā Original Message āāāāāāā\nOn Thursday, January 31, 2019 2:04 PM, Anthony Towns \u003caj at erisian.com.au\u003e wrote:\n\n\u003e On Mon, Dec 24, 2018 at 11:47:38AM +0000, ZmnSCPxj via bitcoin-dev wrote:\n\u003e\n\u003e \u003e A boutique protocol would reduce the number of existing onchain wallets that could be integrated in such UI.\n\u003e\n\u003e Seems like PSBT would be a sufficient protocol:\n\u003e\n\u003e 0) lightning node generates a PSBT for a new channel,\n\u003e with no inputs and a single output of the 2-of-2 address\n\u003e\n\u003e 1. wallet funds the PSBT but doesn't sign it, adding a change address\n\u003e if necessary, and could combine with other tx's bustapay style\n\u003e\n\u003e 2. lightning determines txid from PSBT, and creates update/settlement\n\u003e tx's for funding tx so funds can be recovered\n\u003e\n\u003e 3. wallet signs and publishes the PSBT\n\u003e 4. lightning sees tx on chain and channel is open\n\u003e\n\u003e That's a bit more convoluted than \"(0) lightning generates an address and\n\u003e value, and creates NOINPUT update/settlement tx's for that address/value;\n\u003e (1) wallet funds address to exactly that value; (2) lightning monitors\n\u003e blockchain for payment to that address\" of course.\n\u003e\n\u003e But it avoids letting users get into the habit of passing NOINPUT\n\u003e addresses around, or the risk of a user typo'ing the value and losing\n\u003e money immediately, and it has the benefit that the wallet can tweak the\n\u003e value if (eg) that avoids a change address or enhances privacy (iirc,\n\u003e c-lightning tweaks payment values for that reason). If the channel's\n\u003e closed cooperatively, it also avoids ever needing to publish a NOINPUT\n\u003e sig (or NOINPUT tagged output).\n\u003e\n\u003e Does that seem a fair trade off?\n\u003e\n\u003e Cheers,\n\u003e aj\n\u003e",
"sig": "00d1baa6d6a80f4d4694b0d45801edab0641d34a51a4f21d4d0d4251e2ee42b26fb1db7d1a332bc650b83d59e19f188760bf05685bb1912d1d9db1a30113415f"
}