[bitcoin-dev] Safer NOINPUT with output tagging
ZmnSCPxj at protonmail.com
Mon Dec 24 11:47:38 UTC 2018
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.
Sent with ProtonMail Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Sunday, December 23, 2018 12:56 AM, Johnson Lau <jl2012 at xbt.hk> wrote:
> > On 22 Dec 2018, at 10:25 PM, ZmnSCPxj ZmnSCPxj at 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.
More information about the bitcoin-dev