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
>
📝 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
>