diff options
| author | Troy Benjegerdes <hozer@hozed.org> | 2016-08-03 21:13:20 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-08-03 21:13:56 +0000 |
| commit | 4ea8a5808fc1aeb341638eadcdc97afce3db5e3a (patch) | |
| tree | 975fba8efd7685421475a9524a57b8661788bc15 /9c | |
| parent | d75c26f5a92c04968079c26f528220f91d3b5a32 (diff) | |
| download | pi-bitcoindev-4ea8a5808fc1aeb341638eadcdc97afce3db5e3a.tar.gz pi-bitcoindev-4ea8a5808fc1aeb341638eadcdc97afce3db5e3a.zip | |
Re: [bitcoin-dev] BIP clearing house addresses
Diffstat (limited to '9c')
| -rw-r--r-- | 9c/11d14e9f3d7eaa10476e5327c32ede4d9e10ea | 109 |
1 files changed, 109 insertions, 0 deletions
diff --git a/9c/11d14e9f3d7eaa10476e5327c32ede4d9e10ea b/9c/11d14e9f3d7eaa10476e5327c32ede4d9e10ea new file mode 100644 index 000000000..0c593b966 --- /dev/null +++ b/9c/11d14e9f3d7eaa10476e5327c32ede4d9e10ea @@ -0,0 +1,109 @@ +Return-Path: <tmagik@hozed.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id E31062C + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 3 Aug 2016 21:13:56 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from bc.grid.coop (bc.grid.coop [162.221.205.91]) + by smtp1.linuxfoundation.org (Postfix) with ESMTP id 47B21112 + for <bitcoin-dev@lists.linuxfoundation.org>; + Wed, 3 Aug 2016 21:13:56 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) (uid 1000) + by bc.grid.coop with local; Wed, 03 Aug 2016 21:13:20 +0000 + id 00000000004800EC.0000000057A25E70.000048F3 +Date: Wed, 3 Aug 2016 21:13:20 +0000 +From: Troy Benjegerdes <hozer@hozed.org> +To: Matthew Roberts <matthew@roberts.pm>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Message-ID: <20160803211320.GA18597@hostname.unassigned> +References: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com> +Mime-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: 7bit +Content-Disposition: inline +In-Reply-To: <CAAEDBiGMGWLeC81vkojGwEqQTT1HQaE=a3z114u6=FXXM2DRtQ@mail.gmail.com> +User-Agent: Mutt/1.5.23 (2014-03-12) +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham + version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Thu, 04 Aug 2016 09:06:15 +0000 +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Wed, 03 Aug 2016 21:13:57 -0000 + +On Thu, Aug 04, 2016 at 04:16:20AM +1000, 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? + +I think many of us who think about human - computer interactions see the +need for a well defined process to roll back unexpected behavior in a computer +system. My 2014 era proposal is https://bitbucket.org/tmagik/catoshi/issues/24 + +The fundamental assumption around cryptocoins is you have a secret (private +key) known only by you. Currently in bitcoin if that assumption changes, the +response is blame the user. 'Incompetence, etc, etc' + +This is bad business. For any cryptocurrency to really get mass market, we +need to provide our users with key revocation, to be used when the assumption +about being the only holder of a secret is broken. + +I think there's a hardfork-worthy choice here: + +1) implement reversal/revocation as an add-on feature +2) implement reversal/revocation as a fundamental that every address gets. + +Ethereum made a quick hardfork choice to reverse a *single* instance of +unexpected behavior, and looks a lot like a bank bailout. We have the chance +to learn from this mistake, and, apparently, make a lot of money trading +on both sides of the hardfork. + +> 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. +> +> The reason why I bring this up is existing OP codes and TX types don't seem +> suitable for a secure clearing mechanism; Nlocktimed TXs won't work for +> this since you can't know ahead of time when and where a withdrawal needs +> to be made, plus there's still the potential for key mismanagement; Similar +> problems with OP_CHECKLOCKTIMEVERIFY apply too ??? unless you keep a private +> key around on the server which would defeat the purpose. The main use case +> here, would be specifically to improve centralized exchange security by +> making it impossible for a hot wallet to be raided all at once. +> +> Thoughts? +> +> Some existing background: +> +> http://hackingdistributed.com/2016/08/03/how-bitfinex-heist-could-have-been-avoided/ +> -- Proposed the basic idea for a time-based clearing house but using +> blockchains directly, this is a much better idea than my own. +> +> roberts.pm/timechain -- My original paper written in 2015 which proposed a +> similar idea for secure wallet design but implemented using time-locked +> ECDSA keys. Obviously a blockchain would work better for this. +> +> Other -- if the idea has already been brought up by other people, I +> apologize. + +> _______________________________________________ +> bitcoin-dev mailing list +> bitcoin-dev@lists.linuxfoundation.org +> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev + + |