diff options
| author | Michael Grønager <gronager@ceptacle.com> | 2012-02-20 12:17:01 +0100 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2012-02-20 11:17:13 +0000 |
| commit | 934c56d40750b07ddcbba5892a7b925c0f9b86ff (patch) | |
| tree | a69192e58bad851b79725856950b32009c9537af | |
| parent | 36a2caf001bb1693afef5cfadbf7275d4fd75014 (diff) | |
| download | pi-bitcoindev-934c56d40750b07ddcbba5892a7b925c0f9b86ff.tar.gz pi-bitcoindev-934c56d40750b07ddcbba5892a7b925c0f9b86ff.zip | |
[Bitcoin-development] BIP-13
| -rw-r--r-- | ac/f4afd6515c4f99a6e8041713c998522a04d00a | 77 |
1 files changed, 77 insertions, 0 deletions
diff --git a/ac/f4afd6515c4f99a6e8041713c998522a04d00a b/ac/f4afd6515c4f99a6e8041713c998522a04d00a new file mode 100644 index 000000000..c3d05afb5 --- /dev/null +++ b/ac/f4afd6515c4f99a6e8041713c998522a04d00a @@ -0,0 +1,77 @@ +Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] + helo=mx.sourceforge.net) + by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <gronager@ceptacle.com>) id 1RzRF3-0001sU-J2 + for bitcoin-development@lists.sourceforge.net; + Mon, 20 Feb 2012 11:17:13 +0000 +X-ACL-Warn: +Received: from 2508ds5-oebr.0.fullrate.dk ([95.166.54.49] + helo=mail.ceptacle.com) + by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) + id 1RzRF1-0003V4-5A for bitcoin-development@lists.sourceforge.net; + Mon, 20 Feb 2012 11:17:13 +0000 +Received: from localhost (localhost [127.0.0.1]) + by mail.ceptacle.com (Postfix) with ESMTP id 63C1317A7DD8 + for <bitcoin-development@lists.sourceforge.net>; + Mon, 20 Feb 2012 12:17:03 +0100 (CET) +X-Virus-Scanned: amavisd-new at ceptacle.com +Received: from mail.ceptacle.com ([127.0.0.1]) + by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new, + port 10024) with ESMTP id 8FdcXHavYlVh + for <bitcoin-development@lists.sourceforge.net>; + Mon, 20 Feb 2012 12:17:02 +0100 (CET) +Received: from [109.105.106.212] (unknown [109.105.106.212]) + by mail.ceptacle.com (Postfix) with ESMTPSA id 884EF17A7DCE + for <bitcoin-development@lists.sourceforge.net>; + Mon, 20 Feb 2012 12:17:02 +0100 (CET) +From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com> +Content-Type: text/plain; charset=us-ascii +Content-Transfer-Encoding: quoted-printable +Date: Mon, 20 Feb 2012 12:17:01 +0100 +Message-Id: <3DA9C79B-D91D-48B2-9469-37BAA037FC50@ceptacle.com> +To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Mime-Version: 1.0 (Apple Message framework v1257) +X-Mailer: Apple Mail (2.1257) +X-Spam-Score: 0.0 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. +X-Headers-End: 1RzRF1-0003V4-5A +Subject: [Bitcoin-development] BIP-13 +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Mon, 20 Feb 2012 11:17:13 -0000 + +Just posted this on the wiki BIP-13 discussion - should I make it into a = +BIP of its own ? + +--- +The "version" portion of the address has so far been labeled "network = +id", and indicates from which network and which chain the address can be = +used for. I think that this change from network id to version is much = +more fundamental and should not just be squeezed in along with bip16/17. = +The right way to do this is to structure the bitcoin address into: + +base58-encode: [one-byte network ID][20-byte hash][one-byte address = +class][3-byte checksum] + +This will move the possibility of using a faulty address from 1 to 4bill = +to 1 to 24mio. Recall that for most other payment systems this checksum = +is 1 to 9! So it should be sufficient. An old client will then render = +the new addresses as useless and they will still maintain their old = +familiar 1xxx look - the whole point in multisig is that it should not = +be a matter of the paying party to worry about securing wallet of the = +receiver, hence he should not be bothered with a new "3" kind of address = +now... --Michael Gronager/libcoin 10:49, 20 February 2012 (GMT) + + + + |