Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E254E723 for ; Thu, 4 Aug 2016 03:28:09 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (unknown [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 908EA169 for ; Thu, 4 Aug 2016 03:28:09 +0000 (UTC) Received: from ishibashi.localnet (adsl-98-70-231-167.gnv.bellsouth.net [98.70.231.167]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id EECFC38A17C3; Thu, 4 Aug 2016 03:27:37 +0000 (UTC) X-Hashcash: 1:25:160804:bitcoin-dev@lists.linuxfoundation.org::kJPCPB9T6Hmo8OtB:bNlhp X-Hashcash: 1:25:160804:matthew@roberts.pm::5l/RrRnxnnfjxdvc:brW=g From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, Matthew Roberts Date: Thu, 4 Aug 2016 03:27:34 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.20; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201608040327.36571.luke@dashjr.org> X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RDNS_DYNAMIC autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP clearing house addresses 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, 04 Aug 2016 03:28:10 -0000 On Wednesday, August 03, 2016 6:16:20 PM Matthew Roberts via bitcoin-dev wrote: > In light of the recent hack: what does everyone think of the idea of > creating a new address type that has a reversal key and settlement layer > that can be used to revoke transactions? This isn't something that makes sense at the address, since it represents the recipient and not the sender. Transactions are not sent from addresses ever. > You could specify so that transactions "sent" from these addresses must > receive N confirmations before they can't be revoked, after which the > transaction is "settled" and the coins become redeemable from their > destination output. A settlement phase would also mean that a transaction's > progress was publicly visible so transparent fraud prevention and auditing > would become possible by anyone. This is already possible. Just nLockTime your withdrawls for some future block. Don't sign any transaction that isn't nLockTime'd at least N blocks beyond the present tip. Luke