From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 44ABBE36 for ; Wed, 7 Aug 2019 20:34:42 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua1-f54.google.com (mail-ua1-f54.google.com [209.85.222.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2407A7D2 for ; Wed, 7 Aug 2019 20:34:41 +0000 (UTC) Received: by mail-ua1-f54.google.com with SMTP id a97so35495103uaa.9 for ; Wed, 07 Aug 2019 13:34:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=lBWYg3+3KF2AmQLXF1O9+19tyeyJkeu1JlOGUTYnb0w=; b=E2rjFxvjAb+JaFa9GCYXHcybV0GwFOBNmkTQxCJSFMNTUdnpSW0TuDIrkXnnRDX28N Pw5EM9eACB34+cgiWX1OYaXmAyMoWut185NcTR68M7g6T3eWiMWAx0k5ax7WPry2lvwq FXZICVKks2YSgWj1Br38NUE+dFViau2MtNH2wly+fOQ9eXGSzcDg3of7NwjkUlH37Y2S gxvOJBAELQusGH7FRnpns+3vLwMRtfcxdjiQJOwHSE7ymOBCuDC3vAOpmY/plujuuGc1 uhyeE/YLW/zyog0DkHyTB5GKVG+zAuyh5dvHYraBanvFS5Ezz9X03PBPLGO+9lXAkO/p ETJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=lBWYg3+3KF2AmQLXF1O9+19tyeyJkeu1JlOGUTYnb0w=; b=FYX3zde2Y54zG6GEYGw5lMbTPvHV8VqtvA9zyB27b7HwI53WACllWmKW7yNYRwTaxV VShzC4w4DJ11Rm41SEbAnwAZqnwTFZS06HiYBxKK35wjxkkL/S1mPtzXp5fIN+x0xRp8 SEn9STBpLf+cgWMZRJpBVDRhhKy/8nG1r9SXgqiGCgSkiweVs/rPdsfKcVR/uGDNcZcD Eb95ANQCuldq64pmsRzgUSHloriiw1x/Bpc/jvVsyGNLnwrsrb4ypO9fDPTzFHC09IPS 1lhz6fCofoZPM0UNgieTkKHgk7XVuUa4yjEAaRRbKzuinsZFU7mwgiegfwWoXiKqvRoe ps7A== X-Gm-Message-State: APjAAAXBFjKPeYWkOaDFQYw7D1wBLff/GYyVt1/yFH1hQJOY6iV75aGT aYu7Ak2C03DwJi8a8gekB7xyZNf5gTnERiXFjr+etrqV X-Google-Smtp-Source: APXvYqzxcYD8np57cJROTyLT4g+85W7zEPC2hpV971PQHIyp8YiSL/GKriqr/IRXUvmzZQURKi38yynlPE5C2sskfH8= X-Received: by 2002:ab0:70d9:: with SMTP id r25mr6490357ual.109.1565210079688; Wed, 07 Aug 2019 13:34:39 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Bryan Bishop Date: Wed, 7 Aug 2019 15:32:47 -0500 Message-ID: To: Bitcoin Dev , Bryan Bishop Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Aug 2019 20:34:42 -0000 Hi, One of the biggest problems with the vault scheme (besides all of the setup data that has to be stored for a long time) is an attacker that silently steals the hot wallet private key and waits for the vault's owner to make a delayed-spend transaction to initiate a withdrawal from the vault. If the user was unaware of the theft of the key, then the attacker could steal the funds after the delay period. To mitigate this, it is important to choose a stipend or withdrawal amount per withdrawal period like x% of the funds. This limits the total stolen funds to x% because once the funds are stolen the user would know their hot key is compromised, and the user would know to instead use one of the other clawback paths during all of the future withdrawal delay periods instead of letting the delay timeout all the way to the (stolen) default/hot key. The reason why a loss limiter is the way to go is because there's currently no way (that I am aware of, without an upgrade) to force an attacker to reveal his key on the blockchain while also forcing the attacker to use a timelock before the key can spend the coins. I am curious about what the smallest least invasive soft-fork would be for enabling this kind of timelock. There are so many covenant proposals at this point (CHECKSIGFROMSTACK, SECURETHEBAG, CHECKOUTPUTVERIFY, ....). Or there's crazy things like a fork that enables a transaction mode where the (timelock...) script of the first output is automatically prefixed to any of the other scripts on any of the other outputs when an input tries to spend in the future. A thief could add his key to a new output on the transaction and try to spend (just like a user would with a fresh/rotated key), but the OP_CSV would be automatically added to his script to implement the public observation delay window. Also, there was other previous work that I was only informed about today after posting my proposal, so I should mention these as related work: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015793.html https://blog.oleganza.com/post/163955782228/how-segwit-makes-security-better https://www.youtube.com/watch?v=diNxp3ZTquo https://bitcointalk.org/index.php?topic=5111656 - Bryan http://heybryan.org/