Good morning Johnson, Indeed, manual operation is risky.
However the intent is to reduce the requirements on commodity wallets in order to integrate them into a combined onchain and offchain UI. A boutique protocol would reduce the number of existing onchain wallets that could be integrated in such UI. If we could make walletless offchain software in such method, *any* existing wallet with an API to programmatically send arbitrary amount to arbitrary address can be integrated into such UI. This could include hardware wallets. Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Sunday, December 23, 2018 12:56 AM, Johnson Lau <jl2...@xbt.hk> wrote: > > On 22 Dec 2018, at 10:25 PM, ZmnSCPxj zmnsc...@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. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
