https://tests.bitcoin.it/w/api.php?action=feedcontributions&user=Gafter&feedformat=atomBitcoin Wiki - User contributions [en]2021-08-06T02:53:22ZUser contributionsMediaWiki 1.30.0https://tests.bitcoin.it/w/index.php?title=Tonal_Bitcoin&diff=52757Tonal Bitcoin2014-11-05T17:29:23Z<p>Gafter: /* Compatible Clients */</p>
<hr />
<div>Tonal Bitcoin is a representation of the Bitcoin system aimed toward people who prefer the Tonal number system.<br />
<br />
== Number system ==<br />
<br />
The Tonal number system is an alternative to the decimal and SI ("metric") system, which improves usability by allowing for infinite binary division (note that Bitcoin protocol support is still finite).<br />
Instead of counting: one, two, three, four, five, six, seven, eight, nine, ten, eleven, etc...<br />
In tonal, you would count: an, de, ti, go, su, by, ra, me, ni, ko, hu, vy, la, po, fy, ton, ton-an, etc...<br />
This means you get common binary divisions like one sixteenth (0.0625 in decimal) as a clean number: 0.1 in tonal.<br />
The tonal number system, prior to Bitcoin, already defines everyday units of measure including [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA30#v=onepage&q&f=false lengths], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA32#v=onepage&q&f=false time], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA37#v=onepage&q&f=false capacity, weight], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA38#v=onepage&q&f=false power, gold/silver coinage], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA43#v=onepage&q&f=false calendar], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA44#v=onepage&q&f=false temperature], and even [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA42#v=onepage&q&f=false postage stamps] and [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA45#v=onepage&q&f=false music].<br />
<br />
For more information on the Tonal system in general, please see [http://www.lulu.com/product/file-download/tonal-system/10991091 the book].<br />
<br />
== As an altcoin ==<br />
<br />
While Tonal Bitcoin shares a common blockchain and network with decimal Bitcoin (BTC), it is still also considered to be alternative cryptocurrency ("altcoin") since the units are non-trivially presented differently.<br />
That is, merchants who wish to advertise their product to TBC users would be best to advertise an equivalent TBC price alongside the BTC price.<br />
Additionally, had a separate [[block chain]] ("altchain") been created for TBC, there would have been no advantage to it, and instead enabled a number of abuses and reduced compatibility.<br />
Therefore, as an altcoin, TBC demonstrates an ideal way to extend Bitcoin without needing to resort to unnecessary complications.<br />
<br />
From the altcoin perspective, TBC is seen to have a number of benefits over more common altchain-based altcoins:<br />
* It shares the same blockchain as BTC, so benefits from the full security and difficulty backing the Bitcoin blockchain.<br />
* TBC is mined together with BTC - unlike ordinary merged mining, you don't get BTC plus TBC, just one or the other at your choice.<br />
* TBC is completely compatible with all Bitcoin addresses: if you send BTC to a TBC client's address, it will automatically get converted and vice-versa.<br />
<br />
Tonal Bitcoin is also notably the first altcoin ever, having been created in 2011 January.<br />
<br />
== Specification ==<br />
<br />
Please note, that all numbers of TBC and its divisions/multipliers are written in [http://en.wikipedia.org/wiki/Tonal_System Tonal], not decimal.<br />
This means that instead of counting 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10-- you count: 0, 1, 2, 3, 4, 5, 6, 7, 8, , 9, , , , , , 10. Some higher-value digits may require installing a [http://luke.dashjr.org/education/tonal/glyphs/fonts/ font].<br />
<br />
{| border="1" style="text-align:right;font-family:Console, Luxi Mono, fixed"<br />
|- style="background-color:silver"<br />
! Abbreviation<br />
! Pronunciation<br />
! [[Tonal Bitcoin|Tonal (TBC)]]<br />
! Decimal (BTC)<br />
|-<br />
| <br />
| Tam-Bitcoin<br />
| 1 0000 0000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 2 814 749.767 106 56<br />
|-<br />
| ᵇTBC<br />
| Bong-Bitcoin<br />
| 1 0000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 42.949 672 96<br />
|-<br />
| ᵐTBC<br />
| Mill-Bitcoin<br />
| 1000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 2.684 354 56<br />
|-<br />
| ˢTBC<br />
| San-Bitcoin<br />
| 100&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.167 772 16<br />
|-<br />
| ᵗTBC<br />
| Ton-Bitcoin<br />
| 10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.010 485 76<br />
|-<br />
| TBC<br />
| Bitcoin*<br />
| 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.000 655 36<br />
|-<br />
| TBCᵗ<br />
| Bitcoin-ton<br />
| 0.1&nbsp;&nbsp;&nbsp;<br />
| 0.000 040 96<br />
|-<br />
| TBCˢ<br />
| Bitcoin-san<br />
| 0.01&nbsp;&nbsp;<br />
| 0.000 002 56<br />
|-<br />
| TBCᵐ<br />
| Bitcoin-mill<br />
| 0.001&nbsp;<br />
| 0.000 000 16<br />
|-<br />
| TBCᵇ<br />
| Bitcoin-bong<br />
| 0.0001<br />
| 0.000 000 01<br />
|}<br />
<br />
<small>* Tonal Bitcoin and Decimal Bitcoin can be differentiated by the pronunciation of the numbers. "One bitcoin", "two bitcoin", etc is decimal, but "an bitcoin", "de bitcoin" is tonal.</small><br />
<br />
The total number of Tonal Bitcoins ever (analogous to the 21mil BTC in decimal representation) is just over 7.75059 tam-bitcoin.<br />
<br />
== Compatible Clients ==<br />
<br />
While all Bitcoin clients will correctly approximate values in decimal bitcoin, actual Tonal compatibility is sparse.<br />
<br />
* [[Spesmilo]], despite its name, could be configured to display TBC. However, it is no longer maintained and does not work with recent versions of bitcoin-core.<br />
<br />
== Guessing TBC or BTC ==<br />
<br />
Given variable 'value' in base units (uBTCents/TBCᵇ), one can guess whether it is properly Decimal Bitcoin or Tonal Bitcoin with the following pseudo-code:<br />
<br />
if ( ! ( this % 0x10000 ) )<br />
Choose Tonal Bitcoin<br />
if ( ! ( this % 1000000 ) )<br />
Choose Decimal Bitcoin<br />
if ( ! ( this % 0x100 ) )<br />
Choose Tonal Bitcoin<br />
<br />
=== Python ===<br />
<br />
<pre>import math<br />
<br />
def formatBTC(n, addSign = False):<br />
s = "%0.2f BTC" % (math.ceil(n * 100) / 100.,)<br />
if addSign and n >= 0:<br />
s = "+" + s<br />
return s<br />
<br />
def Bitcoin2BTC(n):<br />
return n / 100000000.<br />
<br />
toTonalDict = dict(((57, u'\ue9d9'), (65, u'\ue9da'), (66, u'\ue9db'), (67, u'\ue9dc'), (68, u'\ue9dd'), (69, u'\ue9de'), (70, u'\ue9df'), (97, u'\ue9da'), (98, u'\ue9db'), (99, u'\ue9dc'), (100, u'\ue9dd'), (101, u'\ue9de'), (102, u'\ue9df')))<br />
<br />
def formatTBC(n, addSign = False):<br />
s = "%x" % n<br />
n %= 1<br />
if n:<br />
s += '.'<br />
while n:<br />
n *= 16<br />
s += "%x" % n<br />
n %= 1<br />
s = unicode(s).translate(toTonalDict)<br />
s += " TBC"<br />
if addSign and n >= 0:<br />
s = "+" + s<br />
return s<br />
<br />
def Bitcoin2TBC(n):<br />
return n / 65536.<br />
<br />
def formatBitcoin(n, addSign = False):<br />
if not n % 0x10000:<br />
return formatTBC(Bitcoin2TBC(n), addSign);<br />
if not n % 1000000:<br />
return formatBTC(Bitcoin2BTC(n), addSign);<br />
if not n % 0x100:<br />
return formatTBC(Bitcoin2TBC(n), addSign);<br />
s = "%d uBTCents" % (n,);<br />
if addSign and n > 0:<br />
s = "+" + s;<br />
return s;</pre><br />
<br />
== Criticism ==<br />
<br />
=== Hexadecimal could be done without new fonts as characters ===<br />
<br />
The tonal notation requires extra nonstandard fonts (the tonal digits are not in Unicode; the tonal digit for decimal 10 resembles the decimal digit 9, which would likely add further confusion). Within the programming community there is a widely accepted convention for hexadecimal notation: use A-F for the higher order digits. Thus hexadecimal notation accomplishes most of the same goals as tonal notation, at least for Bitcoin, with no requirement for changing fonts, and is much more widely known, thus is more suited to wider usage.<br />
<br />
=== Not relevant to Bitcoin ===<br />
<br />
The tonal system could just as easily be applied to any currency. There is no community transacting using Tonal Bitcoin, so the tonal system isn't really relevant to Bitcoin.</div>Gafterhttps://tests.bitcoin.it/w/index.php?title=Tonal_Bitcoin&diff=52756Tonal Bitcoin2014-11-05T17:26:16Z<p>Gafter: /* Hexadecimal could be done without new fonts as characters */</p>
<hr />
<div>Tonal Bitcoin is a representation of the Bitcoin system aimed toward people who prefer the Tonal number system.<br />
<br />
== Number system ==<br />
<br />
The Tonal number system is an alternative to the decimal and SI ("metric") system, which improves usability by allowing for infinite binary division (note that Bitcoin protocol support is still finite).<br />
Instead of counting: one, two, three, four, five, six, seven, eight, nine, ten, eleven, etc...<br />
In tonal, you would count: an, de, ti, go, su, by, ra, me, ni, ko, hu, vy, la, po, fy, ton, ton-an, etc...<br />
This means you get common binary divisions like one sixteenth (0.0625 in decimal) as a clean number: 0.1 in tonal.<br />
The tonal number system, prior to Bitcoin, already defines everyday units of measure including [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA30#v=onepage&q&f=false lengths], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA32#v=onepage&q&f=false time], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA37#v=onepage&q&f=false capacity, weight], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA38#v=onepage&q&f=false power, gold/silver coinage], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA43#v=onepage&q&f=false calendar], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA44#v=onepage&q&f=false temperature], and even [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA42#v=onepage&q&f=false postage stamps] and [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA45#v=onepage&q&f=false music].<br />
<br />
For more information on the Tonal system in general, please see [http://www.lulu.com/product/file-download/tonal-system/10991091 the book].<br />
<br />
== As an altcoin ==<br />
<br />
While Tonal Bitcoin shares a common blockchain and network with decimal Bitcoin (BTC), it is still also considered to be alternative cryptocurrency ("altcoin") since the units are non-trivially presented differently.<br />
That is, merchants who wish to advertise their product to TBC users would be best to advertise an equivalent TBC price alongside the BTC price.<br />
Additionally, had a separate [[block chain]] ("altchain") been created for TBC, there would have been no advantage to it, and instead enabled a number of abuses and reduced compatibility.<br />
Therefore, as an altcoin, TBC demonstrates an ideal way to extend Bitcoin without needing to resort to unnecessary complications.<br />
<br />
From the altcoin perspective, TBC is seen to have a number of benefits over more common altchain-based altcoins:<br />
* It shares the same blockchain as BTC, so benefits from the full security and difficulty backing the Bitcoin blockchain.<br />
* TBC is mined together with BTC - unlike ordinary merged mining, you don't get BTC plus TBC, just one or the other at your choice.<br />
* TBC is completely compatible with all Bitcoin addresses: if you send BTC to a TBC client's address, it will automatically get converted and vice-versa.<br />
<br />
Tonal Bitcoin is also notably the first altcoin ever, having been created in 2011 January.<br />
<br />
== Specification ==<br />
<br />
Please note, that all numbers of TBC and its divisions/multipliers are written in [http://en.wikipedia.org/wiki/Tonal_System Tonal], not decimal.<br />
This means that instead of counting 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10-- you count: 0, 1, 2, 3, 4, 5, 6, 7, 8, , 9, , , , , , 10. Some higher-value digits may require installing a [http://luke.dashjr.org/education/tonal/glyphs/fonts/ font].<br />
<br />
{| border="1" style="text-align:right;font-family:Console, Luxi Mono, fixed"<br />
|- style="background-color:silver"<br />
! Abbreviation<br />
! Pronunciation<br />
! [[Tonal Bitcoin|Tonal (TBC)]]<br />
! Decimal (BTC)<br />
|-<br />
| <br />
| Tam-Bitcoin<br />
| 1 0000 0000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 2 814 749.767 106 56<br />
|-<br />
| ᵇTBC<br />
| Bong-Bitcoin<br />
| 1 0000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 42.949 672 96<br />
|-<br />
| ᵐTBC<br />
| Mill-Bitcoin<br />
| 1000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 2.684 354 56<br />
|-<br />
| ˢTBC<br />
| San-Bitcoin<br />
| 100&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.167 772 16<br />
|-<br />
| ᵗTBC<br />
| Ton-Bitcoin<br />
| 10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.010 485 76<br />
|-<br />
| TBC<br />
| Bitcoin*<br />
| 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.000 655 36<br />
|-<br />
| TBCᵗ<br />
| Bitcoin-ton<br />
| 0.1&nbsp;&nbsp;&nbsp;<br />
| 0.000 040 96<br />
|-<br />
| TBCˢ<br />
| Bitcoin-san<br />
| 0.01&nbsp;&nbsp;<br />
| 0.000 002 56<br />
|-<br />
| TBCᵐ<br />
| Bitcoin-mill<br />
| 0.001&nbsp;<br />
| 0.000 000 16<br />
|-<br />
| TBCᵇ<br />
| Bitcoin-bong<br />
| 0.0001<br />
| 0.000 000 01<br />
|}<br />
<br />
<small>* Tonal Bitcoin and Decimal Bitcoin can be differentiated by the pronunciation of the numbers. "One bitcoin", "two bitcoin", etc is decimal, but "an bitcoin", "de bitcoin" is tonal.</small><br />
<br />
The total number of Tonal Bitcoins ever (analogous to the 21mil BTC in decimal representation) is just over 7.75059 tam-bitcoin.<br />
<br />
== Compatible Clients ==<br />
<br />
While all Bitcoin clients will correctly approximate values in decimal bitcoin, actual Tonal compatibility is sparse.<br />
<br />
* [[Spesmilo]], despite its name, could be configured to display TBC<br />
<br />
== Guessing TBC or BTC ==<br />
<br />
Given variable 'value' in base units (uBTCents/TBCᵇ), one can guess whether it is properly Decimal Bitcoin or Tonal Bitcoin with the following pseudo-code:<br />
<br />
if ( ! ( this % 0x10000 ) )<br />
Choose Tonal Bitcoin<br />
if ( ! ( this % 1000000 ) )<br />
Choose Decimal Bitcoin<br />
if ( ! ( this % 0x100 ) )<br />
Choose Tonal Bitcoin<br />
<br />
=== Python ===<br />
<br />
<pre>import math<br />
<br />
def formatBTC(n, addSign = False):<br />
s = "%0.2f BTC" % (math.ceil(n * 100) / 100.,)<br />
if addSign and n >= 0:<br />
s = "+" + s<br />
return s<br />
<br />
def Bitcoin2BTC(n):<br />
return n / 100000000.<br />
<br />
toTonalDict = dict(((57, u'\ue9d9'), (65, u'\ue9da'), (66, u'\ue9db'), (67, u'\ue9dc'), (68, u'\ue9dd'), (69, u'\ue9de'), (70, u'\ue9df'), (97, u'\ue9da'), (98, u'\ue9db'), (99, u'\ue9dc'), (100, u'\ue9dd'), (101, u'\ue9de'), (102, u'\ue9df')))<br />
<br />
def formatTBC(n, addSign = False):<br />
s = "%x" % n<br />
n %= 1<br />
if n:<br />
s += '.'<br />
while n:<br />
n *= 16<br />
s += "%x" % n<br />
n %= 1<br />
s = unicode(s).translate(toTonalDict)<br />
s += " TBC"<br />
if addSign and n >= 0:<br />
s = "+" + s<br />
return s<br />
<br />
def Bitcoin2TBC(n):<br />
return n / 65536.<br />
<br />
def formatBitcoin(n, addSign = False):<br />
if not n % 0x10000:<br />
return formatTBC(Bitcoin2TBC(n), addSign);<br />
if not n % 1000000:<br />
return formatBTC(Bitcoin2BTC(n), addSign);<br />
if not n % 0x100:<br />
return formatTBC(Bitcoin2TBC(n), addSign);<br />
s = "%d uBTCents" % (n,);<br />
if addSign and n > 0:<br />
s = "+" + s;<br />
return s;</pre><br />
<br />
== Criticism ==<br />
<br />
=== Hexadecimal could be done without new fonts as characters ===<br />
<br />
The tonal notation requires extra nonstandard fonts (the tonal digits are not in Unicode; the tonal digit for decimal 10 resembles the decimal digit 9, which would likely add further confusion). Within the programming community there is a widely accepted convention for hexadecimal notation: use A-F for the higher order digits. Thus hexadecimal notation accomplishes most of the same goals as tonal notation, at least for Bitcoin, with no requirement for changing fonts, and is much more widely known, thus is more suited to wider usage.<br />
<br />
=== Not relevant to Bitcoin ===<br />
<br />
The tonal system could just as easily be applied to any currency. There is no community transacting using Tonal Bitcoin, so the tonal system isn't really relevant to Bitcoin.</div>Gafterhttps://tests.bitcoin.it/w/index.php?title=Tonal_Bitcoin&diff=52755Tonal Bitcoin2014-11-05T17:17:49Z<p>Gafter: Removing non-criticisms from the criticism section.</p>
<hr />
<div>Tonal Bitcoin is a representation of the Bitcoin system aimed toward people who prefer the Tonal number system.<br />
<br />
== Number system ==<br />
<br />
The Tonal number system is an alternative to the decimal and SI ("metric") system, which improves usability by allowing for infinite binary division (note that Bitcoin protocol support is still finite).<br />
Instead of counting: one, two, three, four, five, six, seven, eight, nine, ten, eleven, etc...<br />
In tonal, you would count: an, de, ti, go, su, by, ra, me, ni, ko, hu, vy, la, po, fy, ton, ton-an, etc...<br />
This means you get common binary divisions like one sixteenth (0.0625 in decimal) as a clean number: 0.1 in tonal.<br />
The tonal number system, prior to Bitcoin, already defines everyday units of measure including [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA30#v=onepage&q&f=false lengths], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA32#v=onepage&q&f=false time], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA37#v=onepage&q&f=false capacity, weight], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA38#v=onepage&q&f=false power, gold/silver coinage], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA43#v=onepage&q&f=false calendar], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA44#v=onepage&q&f=false temperature], and even [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA42#v=onepage&q&f=false postage stamps] and [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA45#v=onepage&q&f=false music].<br />
<br />
For more information on the Tonal system in general, please see [http://www.lulu.com/product/file-download/tonal-system/10991091 the book].<br />
<br />
== As an altcoin ==<br />
<br />
While Tonal Bitcoin shares a common blockchain and network with decimal Bitcoin (BTC), it is still also considered to be alternative cryptocurrency ("altcoin") since the units are non-trivially presented differently.<br />
That is, merchants who wish to advertise their product to TBC users would be best to advertise an equivalent TBC price alongside the BTC price.<br />
Additionally, had a separate [[block chain]] ("altchain") been created for TBC, there would have been no advantage to it, and instead enabled a number of abuses and reduced compatibility.<br />
Therefore, as an altcoin, TBC demonstrates an ideal way to extend Bitcoin without needing to resort to unnecessary complications.<br />
<br />
From the altcoin perspective, TBC is seen to have a number of benefits over more common altchain-based altcoins:<br />
* It shares the same blockchain as BTC, so benefits from the full security and difficulty backing the Bitcoin blockchain.<br />
* TBC is mined together with BTC - unlike ordinary merged mining, you don't get BTC plus TBC, just one or the other at your choice.<br />
* TBC is completely compatible with all Bitcoin addresses: if you send BTC to a TBC client's address, it will automatically get converted and vice-versa.<br />
<br />
Tonal Bitcoin is also notably the first altcoin ever, having been created in 2011 January.<br />
<br />
== Specification ==<br />
<br />
Please note, that all numbers of TBC and its divisions/multipliers are written in [http://en.wikipedia.org/wiki/Tonal_System Tonal], not decimal.<br />
This means that instead of counting 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10-- you count: 0, 1, 2, 3, 4, 5, 6, 7, 8, , 9, , , , , , 10. Some higher-value digits may require installing a [http://luke.dashjr.org/education/tonal/glyphs/fonts/ font].<br />
<br />
{| border="1" style="text-align:right;font-family:Console, Luxi Mono, fixed"<br />
|- style="background-color:silver"<br />
! Abbreviation<br />
! Pronunciation<br />
! [[Tonal Bitcoin|Tonal (TBC)]]<br />
! Decimal (BTC)<br />
|-<br />
| <br />
| Tam-Bitcoin<br />
| 1 0000 0000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 2 814 749.767 106 56<br />
|-<br />
| ᵇTBC<br />
| Bong-Bitcoin<br />
| 1 0000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 42.949 672 96<br />
|-<br />
| ᵐTBC<br />
| Mill-Bitcoin<br />
| 1000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 2.684 354 56<br />
|-<br />
| ˢTBC<br />
| San-Bitcoin<br />
| 100&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.167 772 16<br />
|-<br />
| ᵗTBC<br />
| Ton-Bitcoin<br />
| 10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.010 485 76<br />
|-<br />
| TBC<br />
| Bitcoin*<br />
| 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.000 655 36<br />
|-<br />
| TBCᵗ<br />
| Bitcoin-ton<br />
| 0.1&nbsp;&nbsp;&nbsp;<br />
| 0.000 040 96<br />
|-<br />
| TBCˢ<br />
| Bitcoin-san<br />
| 0.01&nbsp;&nbsp;<br />
| 0.000 002 56<br />
|-<br />
| TBCᵐ<br />
| Bitcoin-mill<br />
| 0.001&nbsp;<br />
| 0.000 000 16<br />
|-<br />
| TBCᵇ<br />
| Bitcoin-bong<br />
| 0.0001<br />
| 0.000 000 01<br />
|}<br />
<br />
<small>* Tonal Bitcoin and Decimal Bitcoin can be differentiated by the pronunciation of the numbers. "One bitcoin", "two bitcoin", etc is decimal, but "an bitcoin", "de bitcoin" is tonal.</small><br />
<br />
The total number of Tonal Bitcoins ever (analogous to the 21mil BTC in decimal representation) is just over 7.75059 tam-bitcoin.<br />
<br />
== Compatible Clients ==<br />
<br />
While all Bitcoin clients will correctly approximate values in decimal bitcoin, actual Tonal compatibility is sparse.<br />
<br />
* [[Spesmilo]], despite its name, could be configured to display TBC<br />
<br />
== Guessing TBC or BTC ==<br />
<br />
Given variable 'value' in base units (uBTCents/TBCᵇ), one can guess whether it is properly Decimal Bitcoin or Tonal Bitcoin with the following pseudo-code:<br />
<br />
if ( ! ( this % 0x10000 ) )<br />
Choose Tonal Bitcoin<br />
if ( ! ( this % 1000000 ) )<br />
Choose Decimal Bitcoin<br />
if ( ! ( this % 0x100 ) )<br />
Choose Tonal Bitcoin<br />
<br />
=== Python ===<br />
<br />
<pre>import math<br />
<br />
def formatBTC(n, addSign = False):<br />
s = "%0.2f BTC" % (math.ceil(n * 100) / 100.,)<br />
if addSign and n >= 0:<br />
s = "+" + s<br />
return s<br />
<br />
def Bitcoin2BTC(n):<br />
return n / 100000000.<br />
<br />
toTonalDict = dict(((57, u'\ue9d9'), (65, u'\ue9da'), (66, u'\ue9db'), (67, u'\ue9dc'), (68, u'\ue9dd'), (69, u'\ue9de'), (70, u'\ue9df'), (97, u'\ue9da'), (98, u'\ue9db'), (99, u'\ue9dc'), (100, u'\ue9dd'), (101, u'\ue9de'), (102, u'\ue9df')))<br />
<br />
def formatTBC(n, addSign = False):<br />
s = "%x" % n<br />
n %= 1<br />
if n:<br />
s += '.'<br />
while n:<br />
n *= 16<br />
s += "%x" % n<br />
n %= 1<br />
s = unicode(s).translate(toTonalDict)<br />
s += " TBC"<br />
if addSign and n >= 0:<br />
s = "+" + s<br />
return s<br />
<br />
def Bitcoin2TBC(n):<br />
return n / 65536.<br />
<br />
def formatBitcoin(n, addSign = False):<br />
if not n % 0x10000:<br />
return formatTBC(Bitcoin2TBC(n), addSign);<br />
if not n % 1000000:<br />
return formatBTC(Bitcoin2BTC(n), addSign);<br />
if not n % 0x100:<br />
return formatTBC(Bitcoin2TBC(n), addSign);<br />
s = "%d uBTCents" % (n,);<br />
if addSign and n > 0:<br />
s = "+" + s;<br />
return s;</pre><br />
<br />
== Criticism ==<br />
<br />
=== Hexadecimal could be done without new fonts as characters ===<br />
<br />
The tonal notation requires extra nonstandard fonts (the tonal digits are not in Unicode). Within the programming community there is a widely accepted convention for hexadecimal notation: use A-F for the higher order digits. Thus hexadecimal notation accomplishes most of the same goals as tonal notation, at least for Bitcoin, with no requirement for changing fonts, and is much more widely known, thus is more suited to wider usage.<br />
<br />
=== Not relevant to Bitcoin ===<br />
<br />
The tonal system could just as easily be applied to any currency. There is no community transacting using Tonal Bitcoin, so the tonal system isn't really relevant to Bitcoin.</div>Gafterhttps://tests.bitcoin.it/w/index.php?title=Tonal_Bitcoin&diff=52754Tonal Bitcoin2014-11-05T17:11:14Z<p>Gafter: /* Not relevant to Bitcoin */</p>
<hr />
<div>Tonal Bitcoin is a representation of the Bitcoin system aimed toward people who prefer the Tonal number system.<br />
<br />
== Number system ==<br />
<br />
The Tonal number system is an alternative to the decimal and SI ("metric") system, which improves usability by allowing for infinite binary division (note that Bitcoin protocol support is still finite).<br />
Instead of counting: one, two, three, four, five, six, seven, eight, nine, ten, eleven, etc...<br />
In tonal, you would count: an, de, ti, go, su, by, ra, me, ni, ko, hu, vy, la, po, fy, ton, ton-an, etc...<br />
This means you get common binary divisions like one sixteenth (0.0625 in decimal) as a clean number: 0.1 in tonal.<br />
The tonal number system, prior to Bitcoin, already defines everyday units of measure including [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA30#v=onepage&q&f=false lengths], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA32#v=onepage&q&f=false time], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA37#v=onepage&q&f=false capacity, weight], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA38#v=onepage&q&f=false power, gold/silver coinage], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA43#v=onepage&q&f=false calendar], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA44#v=onepage&q&f=false temperature], and even [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA42#v=onepage&q&f=false postage stamps] and [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA45#v=onepage&q&f=false music].<br />
<br />
For more information on the Tonal system in general, please see [http://www.lulu.com/product/file-download/tonal-system/10991091 the book].<br />
<br />
== As an altcoin ==<br />
<br />
While Tonal Bitcoin shares a common blockchain and network with decimal Bitcoin (BTC), it is still also considered to be alternative cryptocurrency ("altcoin") since the units are non-trivially presented differently.<br />
That is, merchants who wish to advertise their product to TBC users would be best to advertise an equivalent TBC price alongside the BTC price.<br />
Additionally, had a separate [[block chain]] ("altchain") been created for TBC, there would have been no advantage to it, and instead enabled a number of abuses and reduced compatibility.<br />
Therefore, as an altcoin, TBC demonstrates an ideal way to extend Bitcoin without needing to resort to unnecessary complications.<br />
<br />
From the altcoin perspective, TBC is seen to have a number of benefits over more common altchain-based altcoins:<br />
* It shares the same blockchain as BTC, so benefits from the full security and difficulty backing the Bitcoin blockchain.<br />
* TBC is mined together with BTC - unlike ordinary merged mining, you don't get BTC plus TBC, just one or the other at your choice.<br />
* TBC is completely compatible with all Bitcoin addresses: if you send BTC to a TBC client's address, it will automatically get converted and vice-versa.<br />
<br />
Tonal Bitcoin is also notably the first altcoin ever, having been created in 2011 January.<br />
<br />
== Specification ==<br />
<br />
Please note, that all numbers of TBC and its divisions/multipliers are written in [http://en.wikipedia.org/wiki/Tonal_System Tonal], not decimal.<br />
This means that instead of counting 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10-- you count: 0, 1, 2, 3, 4, 5, 6, 7, 8, , 9, , , , , , 10. Some higher-value digits may require installing a [http://luke.dashjr.org/education/tonal/glyphs/fonts/ font].<br />
<br />
{| border="1" style="text-align:right;font-family:Console, Luxi Mono, fixed"<br />
|- style="background-color:silver"<br />
! Abbreviation<br />
! Pronunciation<br />
! [[Tonal Bitcoin|Tonal (TBC)]]<br />
! Decimal (BTC)<br />
|-<br />
| <br />
| Tam-Bitcoin<br />
| 1 0000 0000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 2 814 749.767 106 56<br />
|-<br />
| ᵇTBC<br />
| Bong-Bitcoin<br />
| 1 0000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 42.949 672 96<br />
|-<br />
| ᵐTBC<br />
| Mill-Bitcoin<br />
| 1000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 2.684 354 56<br />
|-<br />
| ˢTBC<br />
| San-Bitcoin<br />
| 100&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.167 772 16<br />
|-<br />
| ᵗTBC<br />
| Ton-Bitcoin<br />
| 10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.010 485 76<br />
|-<br />
| TBC<br />
| Bitcoin*<br />
| 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.000 655 36<br />
|-<br />
| TBCᵗ<br />
| Bitcoin-ton<br />
| 0.1&nbsp;&nbsp;&nbsp;<br />
| 0.000 040 96<br />
|-<br />
| TBCˢ<br />
| Bitcoin-san<br />
| 0.01&nbsp;&nbsp;<br />
| 0.000 002 56<br />
|-<br />
| TBCᵐ<br />
| Bitcoin-mill<br />
| 0.001&nbsp;<br />
| 0.000 000 16<br />
|-<br />
| TBCᵇ<br />
| Bitcoin-bong<br />
| 0.0001<br />
| 0.000 000 01<br />
|}<br />
<br />
<small>* Tonal Bitcoin and Decimal Bitcoin can be differentiated by the pronunciation of the numbers. "One bitcoin", "two bitcoin", etc is decimal, but "an bitcoin", "de bitcoin" is tonal.</small><br />
<br />
The total number of Tonal Bitcoins ever (analogous to the 21mil BTC in decimal representation) is just over 7.75059 tam-bitcoin.<br />
<br />
== Compatible Clients ==<br />
<br />
While all Bitcoin clients will correctly approximate values in decimal bitcoin, actual Tonal compatibility is sparse.<br />
<br />
* [[Spesmilo]], despite its name, could be configured to display TBC<br />
<br />
== Guessing TBC or BTC ==<br />
<br />
Given variable 'value' in base units (uBTCents/TBCᵇ), one can guess whether it is properly Decimal Bitcoin or Tonal Bitcoin with the following pseudo-code:<br />
<br />
if ( ! ( this % 0x10000 ) )<br />
Choose Tonal Bitcoin<br />
if ( ! ( this % 1000000 ) )<br />
Choose Decimal Bitcoin<br />
if ( ! ( this % 0x100 ) )<br />
Choose Tonal Bitcoin<br />
<br />
=== Python ===<br />
<br />
<pre>import math<br />
<br />
def formatBTC(n, addSign = False):<br />
s = "%0.2f BTC" % (math.ceil(n * 100) / 100.,)<br />
if addSign and n >= 0:<br />
s = "+" + s<br />
return s<br />
<br />
def Bitcoin2BTC(n):<br />
return n / 100000000.<br />
<br />
toTonalDict = dict(((57, u'\ue9d9'), (65, u'\ue9da'), (66, u'\ue9db'), (67, u'\ue9dc'), (68, u'\ue9dd'), (69, u'\ue9de'), (70, u'\ue9df'), (97, u'\ue9da'), (98, u'\ue9db'), (99, u'\ue9dc'), (100, u'\ue9dd'), (101, u'\ue9de'), (102, u'\ue9df')))<br />
<br />
def formatTBC(n, addSign = False):<br />
s = "%x" % n<br />
n %= 1<br />
if n:<br />
s += '.'<br />
while n:<br />
n *= 16<br />
s += "%x" % n<br />
n %= 1<br />
s = unicode(s).translate(toTonalDict)<br />
s += " TBC"<br />
if addSign and n >= 0:<br />
s = "+" + s<br />
return s<br />
<br />
def Bitcoin2TBC(n):<br />
return n / 65536.<br />
<br />
def formatBitcoin(n, addSign = False):<br />
if not n % 0x10000:<br />
return formatTBC(Bitcoin2TBC(n), addSign);<br />
if not n % 1000000:<br />
return formatBTC(Bitcoin2BTC(n), addSign);<br />
if not n % 0x100:<br />
return formatTBC(Bitcoin2TBC(n), addSign);<br />
s = "%d uBTCents" % (n,);<br />
if addSign and n > 0:<br />
s = "+" + s;<br />
return s;</pre><br />
<br />
== Criticism ==<br />
<br />
=== Hexadecimal could be done without new fonts as characters ===<br />
<br />
The tonal notation requires extra fonts. Within the programming community there is a widely accepted convention for hexadecimal notation: use A-F for the higher order digits. Thus, one counts 0,1,2,3, ... , 9,A,B,C,D,E,F,10,11 .... There are even two conventions, (which are lacking in tonal notation) for distinguishing a base-16 number from a decimal. The C convention prefixes 0x and the Motorola convention suffixes h. So, the number san, 256 (decimal) would be written 0x100 or 100h. In tonal notation, it would only be written 100, and thus potentially confused with decimal 100 which is 0x64, though this confusion is less of a problem for Bitcoin since the context is always explicit (SI/BTC vs Tonal/TBC units).<br />
<br />
Thus hexadecimal notation accomplishes most of the same goals as tonal notation, at least for Bitcoin, with no requirement for changing fonts, thus is more suited to wider usage. Further the prefix and suffix conventions lead to less ambiguity within the tonal community.<br />
<br />
'''However,''' the goal of Tonal Bitcoin is to bring Bitcoin to Tonal, not to redefine Tonal (which is older than hexadecimal) or advocate change to the number system itself, so this is out of scope.<br />
Additionally, hexadecimal would make referring to "a bitcoin" ambiguous - such a value could mean the equivalent of either one or ten in decimal!<br />
<br />
=== Not relevant to Bitcoin ===<br />
<br />
The tonal system could just as easily be applied to any currency. There is no significant community transacting using Tonal Bitcoin, so the tonal system isn't really relevant to Bitcoin.</div>Gafterhttps://tests.bitcoin.it/w/index.php?title=Tonal_Bitcoin&diff=52753Tonal Bitcoin2014-11-05T17:06:21Z<p>Gafter: Change "people who prefer to use the Tonal number system" to "person who prefers to use the Tonal number system", as only one such person has been identified.</p>
<hr />
<div>Tonal Bitcoin is a representation of the Bitcoin system aimed toward people who prefer the Tonal number system.<br />
<br />
== Number system ==<br />
<br />
The Tonal number system is an alternative to the decimal and SI ("metric") system, which improves usability by allowing for infinite binary division (note that Bitcoin protocol support is still finite).<br />
Instead of counting: one, two, three, four, five, six, seven, eight, nine, ten, eleven, etc...<br />
In tonal, you would count: an, de, ti, go, su, by, ra, me, ni, ko, hu, vy, la, po, fy, ton, ton-an, etc...<br />
This means you get common binary divisions like one sixteenth (0.0625 in decimal) as a clean number: 0.1 in tonal.<br />
The tonal number system, prior to Bitcoin, already defines everyday units of measure including [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA30#v=onepage&q&f=false lengths], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA32#v=onepage&q&f=false time], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA37#v=onepage&q&f=false capacity, weight], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA38#v=onepage&q&f=false power, gold/silver coinage], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA43#v=onepage&q&f=false calendar], [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA44#v=onepage&q&f=false temperature], and even [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA42#v=onepage&q&f=false postage stamps] and [http://books.google.com/books?id=aNYGAAAAYAAJ&pg=PA45#v=onepage&q&f=false music].<br />
<br />
For more information on the Tonal system in general, please see [http://www.lulu.com/product/file-download/tonal-system/10991091 the book].<br />
<br />
== As an altcoin ==<br />
<br />
While Tonal Bitcoin shares a common blockchain and network with decimal Bitcoin (BTC), it is still also considered to be alternative cryptocurrency ("altcoin") since the units are non-trivially presented differently.<br />
That is, merchants who wish to advertise their product to TBC users would be best to advertise an equivalent TBC price alongside the BTC price.<br />
Additionally, had a separate [[block chain]] ("altchain") been created for TBC, there would have been no advantage to it, and instead enabled a number of abuses and reduced compatibility.<br />
Therefore, as an altcoin, TBC demonstrates an ideal way to extend Bitcoin without needing to resort to unnecessary complications.<br />
<br />
From the altcoin perspective, TBC is seen to have a number of benefits over more common altchain-based altcoins:<br />
* It shares the same blockchain as BTC, so benefits from the full security and difficulty backing the Bitcoin blockchain.<br />
* TBC is mined together with BTC - unlike ordinary merged mining, you don't get BTC plus TBC, just one or the other at your choice.<br />
* TBC is completely compatible with all Bitcoin addresses: if you send BTC to a TBC client's address, it will automatically get converted and vice-versa.<br />
<br />
Tonal Bitcoin is also notably the first altcoin ever, having been created in 2011 January.<br />
<br />
== Specification ==<br />
<br />
Please note, that all numbers of TBC and its divisions/multipliers are written in [http://en.wikipedia.org/wiki/Tonal_System Tonal], not decimal.<br />
This means that instead of counting 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10-- you count: 0, 1, 2, 3, 4, 5, 6, 7, 8, , 9, , , , , , 10. Some higher-value digits may require installing a [http://luke.dashjr.org/education/tonal/glyphs/fonts/ font].<br />
<br />
{| border="1" style="text-align:right;font-family:Console, Luxi Mono, fixed"<br />
|- style="background-color:silver"<br />
! Abbreviation<br />
! Pronunciation<br />
! [[Tonal Bitcoin|Tonal (TBC)]]<br />
! Decimal (BTC)<br />
|-<br />
| <br />
| Tam-Bitcoin<br />
| 1 0000 0000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 2 814 749.767 106 56<br />
|-<br />
| ᵇTBC<br />
| Bong-Bitcoin<br />
| 1 0000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 42.949 672 96<br />
|-<br />
| ᵐTBC<br />
| Mill-Bitcoin<br />
| 1000&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 2.684 354 56<br />
|-<br />
| ˢTBC<br />
| San-Bitcoin<br />
| 100&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.167 772 16<br />
|-<br />
| ᵗTBC<br />
| Ton-Bitcoin<br />
| 10&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.010 485 76<br />
|-<br />
| TBC<br />
| Bitcoin*<br />
| 1&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<br />
| 0.000 655 36<br />
|-<br />
| TBCᵗ<br />
| Bitcoin-ton<br />
| 0.1&nbsp;&nbsp;&nbsp;<br />
| 0.000 040 96<br />
|-<br />
| TBCˢ<br />
| Bitcoin-san<br />
| 0.01&nbsp;&nbsp;<br />
| 0.000 002 56<br />
|-<br />
| TBCᵐ<br />
| Bitcoin-mill<br />
| 0.001&nbsp;<br />
| 0.000 000 16<br />
|-<br />
| TBCᵇ<br />
| Bitcoin-bong<br />
| 0.0001<br />
| 0.000 000 01<br />
|}<br />
<br />
<small>* Tonal Bitcoin and Decimal Bitcoin can be differentiated by the pronunciation of the numbers. "One bitcoin", "two bitcoin", etc is decimal, but "an bitcoin", "de bitcoin" is tonal.</small><br />
<br />
The total number of Tonal Bitcoins ever (analogous to the 21mil BTC in decimal representation) is just over 7.75059 tam-bitcoin.<br />
<br />
== Compatible Clients ==<br />
<br />
While all Bitcoin clients will correctly approximate values in decimal bitcoin, actual Tonal compatibility is sparse.<br />
<br />
* [[Spesmilo]], despite its name, could be configured to display TBC<br />
<br />
== Guessing TBC or BTC ==<br />
<br />
Given variable 'value' in base units (uBTCents/TBCᵇ), one can guess whether it is properly Decimal Bitcoin or Tonal Bitcoin with the following pseudo-code:<br />
<br />
if ( ! ( this % 0x10000 ) )<br />
Choose Tonal Bitcoin<br />
if ( ! ( this % 1000000 ) )<br />
Choose Decimal Bitcoin<br />
if ( ! ( this % 0x100 ) )<br />
Choose Tonal Bitcoin<br />
<br />
=== Python ===<br />
<br />
<pre>import math<br />
<br />
def formatBTC(n, addSign = False):<br />
s = "%0.2f BTC" % (math.ceil(n * 100) / 100.,)<br />
if addSign and n >= 0:<br />
s = "+" + s<br />
return s<br />
<br />
def Bitcoin2BTC(n):<br />
return n / 100000000.<br />
<br />
toTonalDict = dict(((57, u'\ue9d9'), (65, u'\ue9da'), (66, u'\ue9db'), (67, u'\ue9dc'), (68, u'\ue9dd'), (69, u'\ue9de'), (70, u'\ue9df'), (97, u'\ue9da'), (98, u'\ue9db'), (99, u'\ue9dc'), (100, u'\ue9dd'), (101, u'\ue9de'), (102, u'\ue9df')))<br />
<br />
def formatTBC(n, addSign = False):<br />
s = "%x" % n<br />
n %= 1<br />
if n:<br />
s += '.'<br />
while n:<br />
n *= 16<br />
s += "%x" % n<br />
n %= 1<br />
s = unicode(s).translate(toTonalDict)<br />
s += " TBC"<br />
if addSign and n >= 0:<br />
s = "+" + s<br />
return s<br />
<br />
def Bitcoin2TBC(n):<br />
return n / 65536.<br />
<br />
def formatBitcoin(n, addSign = False):<br />
if not n % 0x10000:<br />
return formatTBC(Bitcoin2TBC(n), addSign);<br />
if not n % 1000000:<br />
return formatBTC(Bitcoin2BTC(n), addSign);<br />
if not n % 0x100:<br />
return formatTBC(Bitcoin2TBC(n), addSign);<br />
s = "%d uBTCents" % (n,);<br />
if addSign and n > 0:<br />
s = "+" + s;<br />
return s;</pre><br />
<br />
== Criticism ==<br />
<br />
=== Hexadecimal could be done without new fonts as characters ===<br />
<br />
The tonal notation requires extra fonts. Within the programming community there is a widely accepted convention for hexadecimal notation: use A-F for the higher order digits. Thus, one counts 0,1,2,3, ... , 9,A,B,C,D,E,F,10,11 .... There are even two conventions, (which are lacking in tonal notation) for distinguishing a base-16 number from a decimal. The C convention prefixes 0x and the Motorola convention suffixes h. So, the number san, 256 (decimal) would be written 0x100 or 100h. In tonal notation, it would only be written 100, and thus potentially confused with decimal 100 which is 0x64, though this confusion is less of a problem for Bitcoin since the context is always explicit (SI/BTC vs Tonal/TBC units).<br />
<br />
Thus hexadecimal notation accomplishes most of the same goals as tonal notation, at least for Bitcoin, with no requirement for changing fonts, thus is more suited to wider usage. Further the prefix and suffix conventions lead to less ambiguity within the tonal community.<br />
<br />
'''However,''' the goal of Tonal Bitcoin is to bring Bitcoin to Tonal, not to redefine Tonal (which is older than hexadecimal) or advocate change to the number system itself, so this is out of scope.<br />
Additionally, hexadecimal would make referring to "a bitcoin" ambiguous - such a value could mean the equivalent of either one or ten in decimal!<br />
<br />
=== Not relevant to Bitcoin ===<br />
<br />
Contrary to common myth, Bitcoin is not all about anonymity (and in fact, Bitcoin is ''not'' even anonymous itself).<br />
Most people in the world don't care about anonymity, and Bitcoin would never get off the ground if it had a niche one-issue purpose.<br />
Bitcoin is many things to many people, and not everyone has the same ideals or goals in mind.<br />
For the person who prefers to use the Tonal number system, Bitcoin's ability to adapt to it is a "killer feature", and gives him reason to prefer it over his local fiat currency.<br />
{{p-full}}</div>Gafterhttps://tests.bitcoin.it/w/index.php?title=BIP_0032&diff=40588BIP 00322013-08-29T21:38:44Z<p>Gafter: Use public data only in public derivation. Probably was a typo.</p>
<hr />
<div>{{bip}}<br />
<br />
<br />
RECENT CHANGES:<br />
* [16 Apr 2013] Added private derivation for i >= 0x80000000 (less risk of parent private key leakage)<br />
* [30 Apr 2013] Switched from multiplication by I_L to addition of I_L (faster, easier implementation)<br />
* [25 May 2013] Added test vectors<br />
<br />
<pre><br />
BIP: 32<br />
Title: Hierarchical Deterministic Wallets<br />
Author: Pieter Wuille<br />
Status: Accepted<br />
Type: Informational<br />
Created: 11-02-2012<br />
</pre><br />
<br />
==Abstract==<br />
<br />
This document describes [[Deterministic Wallet|hierarchical determinstic wallets]] (or "HD Wallets"): wallets which can be shared partially or entirely with different systems, each with or without the ability to spend coins.<br />
<br />
The specification is intended to set a standard for deterministic wallets that can be interchanged between different clients. Although the wallets described here have many features, not all are required by supporting clients.<br />
<br />
The specification consists of two parts. In a first part, a system for deriving a tree of keypairs from a single seed is presented. The second part demonstrates how to build a wallet structure on top of such a tree.<br />
<br />
==Motivation==<br />
<br />
The Bitcoin reference client uses randomly generated keys. In order to avoid the necessity for a backup after every transaction, (by default) 100 keys are cached in a pool of reserve keys. Still, these wallets are not intended to be shared and used on several systems simultaneously. They support hiding their private keys by using the wallet encrypt feature and not sharing the password, but such "neutered" wallets lose the power to generate public keys as well. <br />
<br />
Deterministic wallets do not require such frequent backups, and elliptic curve mathematics permit schemes where one can calculate the public keys without revealing the private keys. This permits for example a webshop business to let its webserver generate fresh addresses (public key hashes) for each order or for each customer, without giving the webserver access to the corresponding private keys (which are required for spending the received funds).<br />
<br />
However, deterministic wallets typically consist of a single "chain" of keypairs. The fact that there is only one chain means that sharing a wallet happens on an all-or-nothing basis. However, in some cases one only wants some (public) keys to be shared and recoverable. In the example of a webshop, the webserver does not need access to all public keys of the merchant's wallet; only to those addresses which are used to receive customer's payments, and not for example the change addresses that are generated when the merchant spends money. Hierarchical deterministic wallets allow such selective sharing by supporting multiple keypair chains, derived from a single root.<br />
<br />
==Specification: Key derivation==<br />
<br />
===Conventions===<br />
<br />
In the rest of this text we will assume the public key cryptography used in Bitcoin, namely elliptic curve cryptography using the field and curve parameters defined by secp256k1 (http://www.secg.org/index.php?action=secg,docs_secg). Variables below are either:<br />
* integers modulo the order of the curve (referred to as n), serialized as 32 bytes, most significant byte first.<br />
* coordinates of points on the curve, serialized as specified in SEC1 in compressed form: [0x02 or 0x03] + 32 byte x coordinate), where the header byte depends on the parity of the omitted y coordinate.<br />
* byte sequences<br />
<br />
We shall denote the compressed form of point P by &chi;(P), which for secp256k1 will always be 33 bytes long.<br />
<br />
Addition (+) of two coordinates is defined as application of the EC group operation. Multiplication (*) of an integer and a coordinate is defined as repeated application of the EC group operation. The generator element of the curve is called G. The public key K corresponding to the private key k is calculated as k*G. We do not distinguish between numbers or coordinates and their serialization as byte sequences.<br />
<br />
===Extended keys===<br />
<br />
In what follows, we will define a function that derives a number of child keys from a parent key. In order to prevent these from depending solely on the key itself, we extend both private and public keys first with an extra 256 bits of entropy. This extension, called the chain code, is identical for corresponding private and public keys, and consists of 32 bytes.<br />
<br />
We represent an extended private key as (k, c), with k the normal private key, and c the chain code. An extended public key is represented as (K, c), with K = k*G and c the chain code.<br />
<br />
===Child key derivation functions===<br />
<br />
We allow for two different types of derivation: private and public.<br />
* Private derivation: knowledge of the private key k<sub>par</sub> and c<sub>par</sub> is required to compute both k<sub>i</sub> and K<sub>i</sub>.<br />
* Public derivation: knowledge of the public key K<sub>par</sub> and c<sub>par</sub> suffices to compute K<sub>i</sub> (but not k<sub>i</sub>).<br />
<br />
We define the private and public child key derivation functions:<br />
* CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>), defined for both private and public derivation.<br />
* CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>), defined only for public derivation.<br />
<br />
We use the most significant bit of i to specify which type of derivation to use. i is encoded as a 32 bit unsigned integer, most significant byte first; '||' represents concatenation.<br />
<br />
====Private child key derivation====<br />
<br />
To define CKD((k<sub>par</sub>, c<sub>par</sub>), i) &rarr; (k<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, private derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = 0x00 || k<sub>par</sub> || i) [Note: The 0x00 pads the private key to make it 33 bytes long.]<br />
** If 0, public derivation is used: let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(k<sub>par</sub>*G) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* k<sub>i</sub> = I<sub>L</sub> + k<sub>par</sub> (mod n).<br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or k<sub>i</sub> = 0, the resulting key is invalid, and one should proceed with the next value for i.<br />
[Note: this has probability lower than 1 in 2<sup>127</sup>.]<br />
<br />
====Public child key derivation====<br />
<br />
To define CKD'((K<sub>par</sub>, c<sub>par</sub>), i) &rarr; (K<sub>i</sub>, c<sub>i</sub>):<br />
* Check whether the highest bit (0x80000000) of i is set:<br />
** If 1, return error<br />
** If 0, let I = HMAC-SHA512(Key = c<sub>par</sub>, Data = &chi;(K<sub>par</sub>) || i)<br />
* Split I = I<sub>L</sub> || I<sub>R</sub> into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* K<sub>i</sub> = (I<sub>L</sub> + K<sub>par</sub>)*G = I<sub>L</sub>*G + K<sub>par</sub><br />
* c<sub>i</sub> = I<sub>R</sub>.<br />
In case I<sub>L</sub> ≥ n or K<sub>i</sub> is the point at infinity, the resulting key is invalid, and one should proceed with the next value for i.<br />
<br />
Note that the extended public key corresponding to the evaluation of CKD(k<sub>ext</sub>, i) with public derivation (so with i < 0x80000000) is identical to the evaluation of CKD'(K<sub>ext</sub>, i), with K<sub>ext</sub> the extended public key corresponding to k<sub>ext</sub>. Symbolically, CKD((k, c), i)*G = CKD'((k*G, c), i). This implies that CKD' can be used to derive all public keys corresponding to the private keys that CKD would find. It cannot be used to retrieve the private keys, however.<br />
<br />
The HMAC-SHA512 function is specified in [http://tools.ietf.org/html/rfc4231 RFC 4231].<br />
<br />
===The key tree===<br />
<br />
The next step is cascading several CKD constructions to build a tree. We start with one root, the master extended key m. By evaluating CKD(m,i) for several values of i, we get a number of first-degree derivative nodes. As each of these is again an extended key, CKD can be applied to those as well. To shorten notation, we will write CKD(CKD(CKD(m,0x8000003),0x2),0x5) as m/3'/2/5 now.<br />
<br />
Each leaf node in the tree corresponds to an actual keypair, while the internal nodes correspond to the collection of keypairs that descends from them. The chain codes of the leaf nodes are ignored, and only their embedded private or public key is used. Because of this construction, knowing an extended private key allows reconstruction of all descendant private keys and public keys, and knowing an extended public keys allows reconstruction of all descendant public keys derived using public derivation.<br />
<br />
===Key identifiers===<br />
<br />
Extended keys can be identified by the Hash160 (RIPEMD160 after SHA256) of the serialized public key, ignoring the chain code. This corresponds exactly to the data used in traditional Bitcoin addresses. It is not advised to represent this data in base58 format though, as it may be interpreted as an address that way (and wallet software is not required to accept payment to the chain key itself).<br />
<br />
The first 32 bits of the identifier are called the fingerprint.<br />
<br />
===Serialization format===<br />
<br />
Extended public and private keys are serialized as follows:<br />
* 4 byte: version bytes (mainnet: 0x0488B21E public, 0x0488ADE4 private; testnet: 0x043587CF public, 0x04358394 private)<br />
* 1 byte: depth: 0x00 for master nodes, 0x01 for level-1 descendants, .... <br />
* 4 bytes: the fingerprint of the parent's key (0x00000000 if master key)<br />
* 4 bytes: child number. This is the number i in x<sub>i</sub> = x<sub>par</sub>/i, with x<sub>i</sub> the key being serialized. This is encoded in MSB order. (0x00000000 if master key)<br />
* 32 bytes: the chain code<br />
* 33 bytes: the public key or private key data (0x02 + X or 0x03 + X for public keys, 0x00 + k for private keys)<br />
<br />
This 78 byte structure can be encoded like other Bitcoin data in Base58, by first adding 32 checksum bits (derived from the double SHA-256 checksum), and then converting to the Base58 representation. This results in a Base58-encoded string of up to 112 characters. Because of the choice of the version bytes, the Base58 representation will start with "xprv" or "xpub" on mainnet, "tprv" or "tpub" on testnet.<br />
<br />
Note that the fingerprint of the parent only serves as a fast way to detect parent and child nodes in software, and software must be willing to deal with collisions. Internally, the full 160-bit identifier could be used.<br />
<br />
When importing a serialized extended public key, implementations must verify whether the X coordinate in the public key data corresponds to a point on the curve. If not, the extended public key is invalid.<br />
<br />
===Master key generation===<br />
<br />
The total number of possible extended keypairs is almost 2^512, but the produced keys are only 256 bits long, and offer about half of that in terms of security. Therefore, master keys are not generated directly, but instead from a potentially short seed value.<br />
<br />
* Generate a seed S of a chosen length (at least 128 bits, but 256 is advised) from a (P)RNG.<br />
* Calculate I = HMAC-SHA512(key="Bitcoin seed", msg=S)<br />
* Split I into two 32-byte sequences, I<sub>L</sub> and I<sub>R</sub>.<br />
* Use I<sub>L</sub> as master secret key, and I<sub>R</sub> as master chain code.<br />
In case I<sub>L</sub> is 0 or >=n, the master key is invalid.<br />
<br />
[[File:BIP32-derivation.png]]<br />
<br />
==Specification: Wallet structure==<br />
<br />
The previous sections specified key trees and their nodes. The next step is imposing a wallet structure on this tree. The layout defined in this section is a default only, though clients are encouraged to mimick it for compatibility, even if not all features are supported.<br />
<br />
An HDW is organized as several 'accounts'. Accounts are numbered, the default account ("") being number 0. Clients are not required to support more than one account - if not, they only use the default account.<br />
<br />
Each account is composed of two keypair chains: an internal and an external one. The external keychain is used to generate new public addresses, while the internal keychain is used for all other operations (change addresses, generation addresses, ..., anything that doesn't need to be communicated). Clients that do not support separate keychains for these should use the external one for everything.<br />
<br />
* m/i'/0/k corresponds to the k'th keypair of the external chain of account number i of the HDW derived from master m.<br />
* m/i'/1/k corresponds to the k'th keypair of the internal chain of account number i of the HDW derived from master m.<br />
<br />
===Use cases===<br />
<br />
====Full wallet sharing: m====<br />
<br />
In cases where two systems need to access a single shared wallet, and both need to be able to perform spendings, one needs to share the master private extended key. Nodes can keep a pool of N look-ahead keys cached for external chains, to watch for incoming payments. The look-ahead for internal chains can be very small, as no gaps are to be expected here. An extra look-ahead could be active for the first unused account's chains - triggering the creation of a new account when used. Note that the name of the account will still need to be entered manually and cannot be synchronized via the block chain.<br />
<br />
====Audits: M====<br />
<br />
In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key.<br />
<br />
====Per-office balances: m/i'====<br />
<br />
When a business has several independent offices, they can all use wallets derived from a single master. This will allow the headquarters to maintain a super-wallet that sees all incoming and outgoing transactions of all offices, and even permit moving money between the offices.<br />
<br />
====Recurrent business-to-business transactions: M/i'/0====<br />
<br />
In case two business partners often transfer money, one can use the extended public key for the external chain of a specific account (M/i'/0) as a sort of "super address", allowing frequent transactions that cannot (easily) be associated, but without needing to request a new address for each payment.<br />
Such a mechanism could also be used by mining pool operators as variable payout address.<br />
<br />
====Unsecure money receiver: M/i'/0====<br />
<br />
When an unsecure webserver is used to run an e-commerce site, it needs to know public addresses that be used to receive payments. The webserver only needs to know the public extended key of the external chain of a single account. This means someone illegally obtaining access to the webserver can at most see all incoming payments, but will not (trivially) be able to distinguish outgoing transactions, nor see payments received by other webservers if there are several ones.<br />
<br />
==Compatibility==<br />
<br />
To comply with this standard, a client must at least be able to import an extended public or private key, to give access to its direct descendants as wallet keys. The wallet structure (master/account/chain/subchain) presented in the second part of the specification is advisory only, but is suggested as a minimal structure for easy compatibility - even when no separate accounts or distinction between internal and external chains is made. However, implementations may deviate from it for specific needs; more complex applications may call for a more complex tree structure.<br />
<br />
==Security==<br />
<br />
In addition to the expectations from the EC public-key cryptography itself:<br />
* Given a public key K, an attacker cannot find the corresponding private key more efficiently than by solving the EC discrete logarithm problem (assumed to require 2<sup>128</sup> group operations).<br />
the intended security properties of this standard are:<br />
* Given a child extended private key (k<sub>i</sub>,c<sub>i</sub>) and the integer i, an attacker cannot find the parent private key k<sub>par</sub> more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
* Given any number (2 <= N <= 2<sup>32</sup>-1) of (index, extended private key) tuples (i<sub>j</sub>,(p<sub>j</sub>,c<sub>j</sub>)), with distinct i<sub>j</sub>'s, determining whether they are derived from a common parent extended private key (i.e., whether there exists a (p<sub>par</sub>,c<sub>par</sub>) such that for each j in [0..N-1] CKD((p<sub>par</sub>,c<sub>par</sub>),i<sub>j</sub>)=(p<sub>j</sub>,c<sub>j</sub>)), cannot be done more efficiently than a 2<sup>256</sup> brute force of HMAC-SHA512.<br />
Note however that the following properties does not exist:<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child public key (K<sub>i</sub>), it is hard to find i.<br />
* Given a parent extended public key (K<sub>par</sub>,c<sub>par</sub>) and a child private key (k<sub>i</sub>) using public derivation, it is hard to find k<sub>par</sub>.<br />
<br />
Private and public keys must be kept safe as usual. Leaking a private key means access to coins - leaking a public key can mean loss of privacy.<br />
<br />
Somewhat more care must be taken regarding extended keys, as these correspond to an entire (sub)tree of keys. One weakness that may not be immediately obvious, is that knowledge of the extended public key + a private key descending from it is equivalent to knowing the extended private key (i.e., every private and public key) in case public derivation is used. This means that extended public keys must be treated more carefully than regular public keys. This is the reason why accounts at the first level of the default wallet layout use private derivation, so a leak of account-specific (or below) private key never risks compromising the master.<br />
<br />
<br />
==Test Vectors==<br />
<br />
For more detailed information about these (such as intermediate values and other representations), see [[BIP_0032_TestVectors]]<br />
<br />
Test vector 1<br />
<br />
Master (hex): 000102030405060708090a0b0c0d0e0f<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFtXgS5sYJABqqG9YLmC4Q1Rdap9gSE8NqtwybGhePY2gZ29ESFjqJoCu1Rupje8YtGqsefD265TMg7usUDFdp6W1EGMcet8<br />
* ext prv: xprv9s21ZrQH143K3QTDL4LXw2F7HEK3wJUD2nW2nRk4stbPy6cq3jPPqjiChkVvvNKmPGJxWUtg6LnF5kejMRNNU3TGtRBeJgk33yuGBxrMPHi<br />
* [Chain m/0']<br />
* ext pub: xpub68Gmy5EdvgibQVfPdqkBBCHxA5htiqg55crXYuXoQRKfDBFA1WEjWgP6LHhwBZeNK1VTsfTFUHCdrfp1bgwQ9xv5ski8PX9rL2dZXvgGDnw<br />
* ext prv: xprv9uHRZZhk6KAJC1avXpDAp4MDc3sQKNxDiPvvkX8Br5ngLNv1TxvUxt4cV1rGL5hj6KCesnDYUhd7oWgT11eZG7XnxHrnYeSvkzY7d2bhkJ7<br />
* [Chain m/0'/1]<br />
* ext pub: xpub6ASuArnXKPbfEwhqN6e3mwBcDTgzisQN1wXN9BJcM47sSikHjJf3UFHKkNAWbWMiGj7Wf5uMash7SyYq527Hqck2AxYysAA7xmALppuCkwQ<br />
* ext prv: xprv9wTYmMFdV23N2TdNG573QoEsfRrWKQgWeibmLntzniatZvR9BmLnvSxqu53Kw1UmYPxLgboyZQaXwTCg8MSY3H2EU4pWcQDnRnrVA1xe8fs<br />
* [Chain m/0'/1/2']<br />
* ext pub: xpub6D4BDPcP2GT577Vvch3R8wDkScZWzQzMMUm3PWbmWvVJrZwQY4VUNgqFJPMM3No2dFDFGTsxxpG5uJh7n7epu4trkrX7x7DogT5Uv6fcLW5<br />
* ext prv: xprv9z4pot5VBttmtdRTWfWQmoH1taj2axGVzFqSb8C9xaxKymcFzXBDptWmT7FwuEzG3ryjH4ktypQSAewRiNMjANTtpgP4mLTj34bhnZX7UiM<br />
* [Chain m/0'/1/2'/2]<br />
* ext pub: xpub6FHa3pjLCk84BayeJxFW2SP4XRrFd1JYnxeLeU8EqN3vDfZmbqBqaGJAyiLjTAwm6ZLRQUMv1ZACTj37sR62cfN7fe5JnJ7dh8zL4fiyLHV<br />
* ext prv: xprvA2JDeKCSNNZky6uBCviVfJSKyQ1mDYahRjijr5idH2WwLsEd4Hsb2Tyh8RfQMuPh7f7RtyzTtdrbdqqsunu5Mm3wDvUAKRHSC34sJ7in334<br />
* [Chain m/0'/1/2'/2/1000000000]<br />
* ext pub: xpub6H1LXWLaKsWFhvm6RVpEL9P4KfRZSW7abD2ttkWP3SSQvnyA8FSVqNTEcYFgJS2UaFcxupHiYkro49S8yGasTvXEYBVPamhGW6cFJodrTHy<br />
* ext prv: xprvA41z7zogVVwxVSgdKUHDy1SKmdb533PjDz7J6N6mV6uS3ze1ai8FHa8kmHScGpWmj4WggLyQjgPie1rFSruoUihUZREPSL39UNdE3BBDu76<br />
<br />
Test vector 2<br />
<br />
Master (hex): fffcf9f6f3f0edeae7e4e1dedbd8d5d2cfccc9c6c3c0bdbab7b4b1aeaba8a5a29f9c999693908d8a8784817e7b7875726f6c696663605d5a5754514e4b484542<br />
* [Chain m]<br />
* ext pub: xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB<br />
* ext prv: xprv9s21ZrQH143K31xYSDQpPDxsXRTUcvj2iNHm5NUtrGiGG5e2DtALGdso3pGz6ssrdK4PFmM8NSpSBHNqPqm55Qn3LqFtT2emdEXVYsCzC2U<br />
* [Chain m/0]<br />
* ext pub: xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH<br />
* ext prv: xprv9vHkqa6EV4sPZHYqZznhT2NPtPCjKuDKGY38FBWLvgaDx45zo9WQRUT3dKYnjwih2yJD9mkrocEZXo1ex8G81dwSM1fwqWpWkeS3v86pgKt<br />
* [Chain m/0/2147483647']<br />
* ext pub: xpub6ASAVgeehLbnwdqV6UKMHVzgqAG8Gr6riv3Fxxpj8ksbH9ebxaEyBLZ85ySDhKiLDBrQSARLq1uNRts8RuJiHjaDMBU4Zn9h8LZNnBC5y4a<br />
* ext prv: xprv9wSp6B7kry3Vj9m1zSnLvN3xH8RdsPP1Mh7fAaR7aRLcQMKTR2vidYEeEg2mUCTAwCd6vnxVrcjfy2kRgVsFawNzmjuHc2YmYRmagcEPdU9<br />
* [Chain m/0/2147483647'/1]<br />
* ext pub: xpub6DF8uhdarytz3FWdA8TvFSvvAh8dP3283MY7p2V4SeE2wyWmG5mg5EwVvmdMVCQcoNJxGoWaU9DCWh89LojfZ537wTfunKau47EL2dhHKon<br />
* ext prv: xprv9zFnWC6h2cLgpmSA46vutJzBcfJ8yaJGg8cX1e5StJh45BBciYTRXSd25UEPVuesF9yog62tGAQtHjXajPPdbRCHuWS6T8XA2ECKADdw4Ef<br />
* [Chain m/0/2147483647'/1/2147483646']<br />
* ext pub: xpub6ERApfZwUNrhLCkDtcHTcxd75RbzS1ed54G1LkBUHQVHQKqhMkhgbmJbZRkrgZw4koxb5JaHWkY4ALHY2grBGRjaDMzQLcgJvLJuZZvRcEL<br />
* ext prv: xprvA1RpRA33e1JQ7ifknakTFpgNXPmW2YvmhqLQYMmrj4xJXXWYpDPS3xz7iAxn8L39njGVyuoseXzU6rcxFLJ8HFsTjSyQbLYnMpCqE2VbFWc<br />
* [Chain m/0/2147483647'/1/2147483646'/2]<br />
* ext pub: xpub6FnCn6nSzZAw5Tw7cgR9bi15UV96gLZhjDstkXXxvCLsUXBGXPdSnLFbdpq8p9HmGsApME5hQTZ3emM2rnY5agb9rXpVGyy3bdW6EEgAtqt<br />
* ext prv: xprvA2nrNbFZABcdryreWet9Ea4LvTJcGsqrMzxHx98MMrotbir7yrKCEXw7nadnHM8Dq38EGfSh6dqA9QWTyefMLEcBYJUuekgW4BYPJcr9E7j<br />
<br />
==Implementations==<br />
<br />
A Python implementation is available at https://github.com/richardkiss/pycoin<br />
<br />
A Java implementation is available at https://github.com/bitsofproof/supernode/blob/1.1/api/src/main/java/com/bitsofproof/supernode/api/ExtendedKey.java<br />
<br />
==Acknowledgements==<br />
<br />
* Gregory Maxwell for the original idea of type-2 deterministic wallets, and many discussions about it.<br />
* Alan Reiner for the implementation of this scheme in Armory, and the suggestions that followed from that.<br />
* Mike Caldwell for the version bytes to obtain human-recognizable Base58 strings.</div>Gafter