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 AD735CD3 for ; Thu, 8 Aug 2019 03:03:15 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5367F829 for ; Thu, 8 Aug 2019 03:03:14 +0000 (UTC) Date: Thu, 08 Aug 2019 03:03:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1565233391; bh=QLvyBG2WGxvveyxhxCvZwA1KoE/PdVF3WkvCTL2cLco=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=l3LuxCMgBdp0i5LP/PBVAO3j2Ij6zwOqcTdWTn8x5nx0ooweV3vyGf26hyTqRbJfW GuaFoLZCb99QfrXcFuu8r5F2y67b/WbxQF2SxIlJXmEi4cwh0iq5YytXZWRFwbJJkb 3S6yO87R07EAbW5MyGdJpzp4hU+zPDly8NW1AuWU= To: Sergio Demian Lerner , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW 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: Thu, 08 Aug 2019 03:03:15 -0000 Good morning Sergio, Sent with ProtonMail Secure Email. =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original Me= ssage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 On Thursday, August 8, 2019 10:09 AM, Sergio Demian Lerner via bitcoin-dev = wrote: > Seems to be comparable to the proposed "Tick Method" from 2013: > https://bitcointalk.org/index.php?topic=3D307211.msg3308565#msg3308565= =C2=A0 > > However I remember that someone told me the tick method had a flaw.. Maybe the use of `SIGHASH_NONE` for both inputs of the TxOut transactions? Also txid malleability. The first can be fixed by not using `SIGHASH_NONE` for one of the inputs an= d requiring a hot privkey to sign with that. The second can be fixed by using SegWit outputs. Regards, ZmnSCPxj > =C2=A0 > > On Wed, Aug 7, 2019 at 6:28 PM Dustin Dettmer via bitcoin-dev wrote: > > > Does revaulting vault up with the same keys, or new ones? > > > > Are they new derivation paths on the same key? > > > > Would love some expanded explanation on how you=E2=80=99re proposing th= is would work. > > > > Thanks, > > Dustin > > > > On Wed, Aug 7, 2019 at 1:35 PM Bryan Bishop via bitcoin-dev wrote: > > > > > 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 othe= r > > > 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 lik= e > > > 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=3DdiNxp3ZTquo > > > https://bitcointalk.org/index.php?topic=3D5111656 > > > > > > - Bryan > > > http://heybryan.org/ > > > _______________________________________________ > > > bitcoin-dev mailing list > > > bitcoin-dev@lists.linuxfoundation.org > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev