From: Johnson Lau <jl2012@xbt•hk>
To: ZmnSCPxj <ZmnSCPxj@protonmail•com>
Cc: bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Safer NOINPUT with output tagging
Date: Sun, 23 Dec 2018 00:56:29 +0800 [thread overview]
Message-ID: <CAABEECD-2B12-4852-A440-58809EB6BF56@xbt.hk> (raw)
In-Reply-To: <KFCfNAmHhRvsDJs70UW3l4ssqBtdBrb8gYP5A3cN2hsTPrXVg7f5Yrt2LOo5V0QdAhhoooc3lllXxiiXSVt_28obYBl_XKAgEQkGg1kOj8I=@protonmail.com>
> On 22 Dec 2018, at 10:25 PM, ZmnSCPxj <ZmnSCPxj@protonmail•com> wrote:
>
> Good morning Johnson,
>
>> Generally speaking, I think walletless protocol is needed only when you want to rely a third party to open a offchain smart contract. It could be coinswap, eltoo, or anything similar.
>
> I think a third party would be pointless in general, but then I am strongly against custodiality.
>
> The idea is that you have some kind of hardware wallet or similar "somewhat cold" storage *that you control yourself*, and crate channels for your hot offchain Lightning wallet, without adding more transactions from your somewhat-cold storage to your hot offchain Lightning wallet on the blockchain.
>
> Then you could feed a set of addresses to the hot offchain wallet (addresses your somewhat-cold storage controls) so that when channels are closed, the funds go to your somwhat-cold storage.
>
> I also doubt that any custodial service would want to mess around with deducting funds from what the user input as the desired payment. I have not seen a custodial service that does so (this is not a scientific study; I rarely use custodial services); custodial services will deduct more from your balance than what you send, but will not modify what you send, and will prevent you from sending more than your balance minus the fees they charge for sending onchain.
>
> Even today, custodial services deducting from your sent value (rather than the balance remaining after you send) would be problematic when interacting with merchants (or their payment processors) accepting onchain payments; the merchant would refuse to service a lower value than what it charges and it may be very technically difficult to recover such funds from the merchant.
> I expect such a custodial service would quickly lose users, but the world surprises me often.
>
> Regards,
> ZmnSCPxj
If the users are expected to manually operate a hardware wallet to fund the channel, they might do stupid things like using 2 wallets to make 2 txs, thinking that they could combine the values this way; or “refilling” the offchain wallet with the address, as you suggested. While I appreciate the goal to separate the coin-selecting wallet with the offchain wallet, I am not sure if we should rely on users to do critical steps like entering the right value or not reusing the address. Especially, the setup address should be hidden from user’s view, so only a very few “intelligent advanced users" could try to refill the channel.
If we don’t rely on the user as the bridge between the hardware wallet and the offchain wallet, we need a communication protocol between them. With such protocol, there is no need to spend the setup TXO with NOINPUT.
next prev parent reply other threads:[~2018-12-22 16:56 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 12:32 Johnson Lau
2018-12-17 15:48 ` Ruben Somsen
2018-12-17 20:08 ` Johnson Lau
2018-12-18 10:48 ` Johnson Lau
2018-12-19 22:09 ` Christian Decker
2018-12-20 11:00 ` Johnson Lau
2018-12-20 17:20 ` Christian Decker
2018-12-20 18:04 ` Johnson Lau
2018-12-21 11:15 ` Christian Decker
2018-12-21 16:21 ` Johnson Lau
2018-12-21 11:40 ` ZmnSCPxj
2018-12-21 15:37 ` Johnson Lau
2018-12-22 14:25 ` ZmnSCPxj
2018-12-22 16:56 ` Johnson Lau [this message]
2018-12-24 11:47 ` ZmnSCPxj
2019-01-31 6:04 ` Anthony Towns
2019-02-01 9:36 ` ZmnSCPxj
2019-02-08 19:01 ` Jonas Nick
2019-02-09 10:01 ` Alejandro Ranchal Pedrosa
2019-02-09 16:48 ` Johnson Lau
2019-02-10 4:46 ` Anthony Towns
2019-02-09 16:54 ` Jonas Nick
2019-02-09 10:15 ` Johnson Lau
2019-02-09 16:52 ` Jonas Nick
2019-02-09 17:43 ` Johnson Lau
2019-02-19 19:04 ` Luke Dashjr
2019-02-19 19:22 ` Johnson Lau
2019-02-19 20:24 ` Luke Dashjr
2019-02-19 20:36 ` Johnson Lau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAABEECD-2B12-4852-A440-58809EB6BF56@xbt.hk \
--to=jl2012@xbt$(echo .)hk \
--cc=ZmnSCPxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox