Re: [Bitcoin-development] Version bytes "2.0"
On Tuesday, December 13, 2011 6:07:17 AM Mike Hearn wrote: > That's cool. I hope Matts change gets merged soon. Then the issue becomes > how do people find out about this capability? Expecting people to learn how > to hand-craft Bitcoin links won't work. Bitcoin-Qt 0.6 will include a QR Code generator. > But all modern operating systems support copy/paste and drag/drop of rich > content. No, not really. I've found that dragging and dropping links manages to corrupt them most of the time. -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version bytes "2.0"
> > > That's cool. I hope Matts change gets merged soon. Then the issue becomes > how do people find out about this capability? Expecting people to learn how > to hand-craft Bitcoin links won't work. But all modern operating systems > support copy/paste and drag/drop of rich content. Qt probably makes it easy > to expose an UI like this: > >*Pay me*[Copy to clipboard] > > Clicking the link in the UI would pop up an alert saying something like > >"You can drag this link to an email, chat window or editing program." > Good idea! This could be integrated with the QR-code generation ( https://github.com/bitcoin/bitcoin/pull/629) which adds "create a payment link" functionality (but currently only "exports" this link as a QR code). Wladimir -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version bytes "2.0"
> > Base58 was chosen not for human readability but to make it easy to > copy/paste. > It was also chosen for hand-writeability, weirdly enough. That's why it excludes some confusible characters. But Satoshi didn't really understand how people would end up using Bitcoin, he originally imagined most transactions being done directly between pairs of IP addresses. > Copy/paste of HTML content is currently not possible. You *can* already > drag&drop the bitcoin: link to the client. Bluematt has a pull request to > automatically handle bitcoin: URLs when clicked in the browser. > That's cool. I hope Matts change gets merged soon. Then the issue becomes how do people find out about this capability? Expecting people to learn how to hand-craft Bitcoin links won't work. But all modern operating systems support copy/paste and drag/drop of rich content. Qt probably makes it easy to expose an UI like this: *Pay me*[Copy to clipboard] Clicking the link in the UI would pop up an alert saying something like "You can drag this link to an email, chat window or editing program." Dragging it/pushing the copy button would just set the drag/clipboard data as a bit of text/html content. So then you can just copy/paste into an email or HTML editor. It wouldn't work for forums that use bbCode, though I guess there's no particular reason the forum software can't turn into [url=] automatically. -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version bytes "2.0"
All, I fully agree with Mike Hearn on this. Like email addresses, bank numbers, phone numbers, IPv4/v6 addresses and such the bitcoin address is just an opaque identifier for machines to be able to send each other messages. Base58 was chosen not for human readability but to make it easy to copy/paste. Of course, sometimes for security reasons you may want to check the addresses manually, but it is not the prime usage scenario. Although fun as a nerd pasttime, I don't think we should encourage "addresses with meaning" to normal users. Indeed better to focus on alternative ways that don't involve typing or even seeing the addresses. Copy/paste of HTML content is currently not possible. You *can* already drag&drop the bitcoin: link to the client. Bluematt has a pull request to automatically handle bitcoin: URLs when clicked in the browser. Wladimir On Tue, Dec 13, 2011 at 11:38 AM, Mike Hearn wrote: > Why does anyone care what an address looks like? > > If the user is seeing an address, that's a usability fail right there. > It's common today because AFAIK nobody finished off the URL handling > support in the main client for browser integration. It'd be a much better > use of time to finish off that integration and make it easy for people to > create links containing a bitcoin: URL (like with copy/paste of text/html > content). > > -- > Systems Optimization Self Assessment > Improve efficiency and utilization of IT resources. Drive out cost and > improve service delivery. Take 5 minutes to use this Systems Optimization > Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version bytes "2.0"
Why does anyone care what an address looks like? If the user is seeing an address, that's a usability fail right there. It's common today because AFAIK nobody finished off the URL handling support in the main client for browser integration. It'd be a much better use of time to finish off that integration and make it easy for people to create links containing a bitcoin: URL (like with copy/paste of text/html content). -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version bytes "2.0"
On Monday, December 12, 2011 3:56:01 PM Pieter Wuille wrote:
> It seems base58 is actually quite terrible for producing nice
> human-recognizable addresses, even though base58 is specially intended for
> human usage. We'll just have to deal with it, or completely overhaul it
> and move to a saner encoding.
Or both: use this proposal for 20-byte base58 for now, and overhaul it in the
future (maybe when the block chain forks?).
> 0: mainnet pubkey hashes ('1', as before)
> 192: testnet pubnet hashes ('2', instead of 111, 'm' and 'n')
> 5: mainnet script hashes ('3'; for OP_EVAL)
> 196: testnet script hashes ('2', same as normal testnet addresses)
Looks good here.
> 12: mainnet private keys ('Q', 'R' or 'S', instead of 128, '5')
> 204: testnet private keys ('7', instead of 239, '8' and '9')
These are 32-byte, so have no reason IMO to follow the 20-byte proposal.
Since a lot of services are already using version 128 ('5') for bitcoin
private keys, and 128 is "reserved" in the 20-byte proposal, I think it's fair
to leave it alone (for now).
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version bytes "2.0"
It seems base58 is actually quite terrible for producing nice human-recognizable
addresses, even though base58 is specially intended for human usage. We'll just
have to deal with it, or completely overhaul it and move to a saner encoding.
Luke's proposal is somewhat more drastic than my original one, since it removes
the actual "version" notion from the version bytes, and changes testnet
addresses.
However, I think it may be worth it. More data classes have been necessary
before, and new versions haven't. Furthermore, they are far more recognizable to
users, which is something that in particular for OP_EVAL addresses (script
hashes)
will be a plus.
Therefore, I'm in favor of the proposal; the new versions would become:
0: mainnet pubkey hashes ('1', as before)
192: testnet pubnet hashes ('2', instead of 111, 'm' and 'n')
5: mainnet script hashes ('3'; for OP_EVAL)
196: testnet script hashes ('2', same as normal testnet addresses)
12: mainnet private keys ('Q', 'R' or 'S', instead of 128, '5')
204: testnet private keys ('7', instead of 239, '8' and '9')
Comments?
--
Pieter
--
Learn Windows Azure Live! Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for
developers. It will provide a great way to learn Windows Azure and what it
provides. You can attend the event by watching it streamed LIVE online.
Learn more at http://p.sf.net/sfu/ms-windowsazure
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version bytes "2.0"
This should make it compatible with Namecoin addresses... Here's a revised proposal: * Bits 128/64 define network class ** 0 = main network ** 64,128 = reserved ** 192 = test network * Bits 32/16 define network ** 0 = Bitcoin ** 16 = reserved ** 32 = OTHER (next octet) ** 48 = Namecoin The rest is left up to the network to decide; for Bitcoin, it is: * Bits 8/4/2 define data class ** 0 = Public key hash ** 2 = reserved ** 4 = Script hash ** 6 = Public key (raw) ** 8 = Signature ** 10 = reserved ** 12 = Private key (raw) ** 14 = OTHER (next octet) * Bit 1 is freely chosen (for aesthetic assignment) -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Version bytes "2.0"
Some bugs I found in my spec so far: - Bitcoin public keys begin with '2' (same as testnet data) - For the first first-class "aux" network, signatures and private keys will start with the same character. - More "collisions" are possible if the "reserved" values were ever assigned. To address these slightly better, here's a revised proposal: * Bits 128/64 define network class ** 0 = main network ** 64,128 = reserved ** 192 = test network * Bits 32/16 define network ** 0 = Bitcoin ** 16,32 = reserved ** 48 = OTHER (next octet) * Bits 8/4/2 define data class ** 0 = Public key hash ** 2 = reserved ** 4 = Script hash ** 6 = Public key (raw) ** 8 = Signature ** 10 = reserved ** 12 = Private key (raw) ** 14 = OTHER (next octet) * Bit 1 is freely chosen (for aesthetic assignment) Note that under this scheme, both script hashes and raw public keys begin with '3'; I consider this a non-issue since neither are supported by current- generation clients, and both pubkey-hash and script-hash are quite capable of the same functionality as a raw public key. Also, the raw public key will presumably be noticably longer. For reference, a table of version number to first-base58-char mappings: + 0 => 1 -...1 1 => QRSTUVWXYZabcdefghijkmno -..1. 2 => 2opqrstuvwxyz +..11 3 => 2 -.1.. 4 => 23 +.1.1 5 => 3 +.11. 6 => 3 -.111 7 => 34 +1... 8 => 4 -1..1 9 => 45 +1.1. 10 => 5 +1.11 11 => 5 -11.. 12 => 56 +11.1 13 => 6 -111. 14 => 67 + 15 => 7 +...1 16 => 7 -...1...1 17 => 78 +...1..1. 18 => 8 -...1..11 19 => 89 +...1.1.. 20 => 9 +...1.1.1 21 => 9 -...1.11. 22 => 9A +...1.111 23 => A -...11... 24 => AB +...11..1 25 => B +...11.1. 26 => B -...11.11 27 => BC +...111.. 28 => C -...111.1 29 => CD +.... 30 => D +...1 31 => D -..1. 32 => DE +..11 33 => E -..1...1. 34 => EF +..1...11 35 => F +..1..1.. 36 => F -..1..1.1 37 => FG +..1..11. 38 => G -..1..111 39 => GH +..1.1... 40 => H +..1.1..1 41 => H -..1.1.1. 42 => HJ +..1.1.11 43 => J -..1.11.. 44 => JK +..1.11.1 45 => K +..1.111. 46 => K -..1. 47 => KL +..11 48 => L -..11...1 49 => LM +..11..1. 50 => M +..11..11 51 => M -..11.1.. 52 => MN +..11.1.1 53 => N -..11.11. 54 => NP +..11.111 55 => P +..111... 56 => P -..111..1 57 => PQ +..111.1. 58 => Q -..111.11 59 => QR +.... 60 => R +...1 61 => R -..1. 62 => RS +..11 63 => S -.1.. 64 => ST +.1.1 65 => T +.11. 66 => T -.111 67 => TU +.1...1.. 68 => U -.1...1.1 69 => UV +.1...11. 70 => V +.1...111 71 => V -.1..1... 72 => VW +.1..1..1 73 => W -.1..1.1. 74 => WX +.1..1.11 75 => X +.1..11.. 76 => X -.1..11.1 77 => XY +.1..111. 78 => Y -.1.. 79 => YZ +.1.1 80 => Z +.1.1...1 81 => Z -.1.1..1. 82 => Za +.1.1..11 83 => a -.1.1.1.. 84 => ab +.1.1.1.1 85 => b -.1.1.11. 86 => bc +.1.1.111 87 => c +.1.11... 88 => c -.1.11..1 89 => cd +.1.11.1. 90 => d -.1.11.11 91 => de +.1.111.. 92 => e +.1.111.1 93 => e -.1.. 94 => ef +.1.1 95 => f -.11. 96 => fg +.111 97 => g +.11...1. 98 => g -.11...11 99 => gh +.11..1.. 100 => h -.11..1.1 101 => hi +.11..11. 102 => i +.11..111 103 => i -.11.1... 104 => ij +.11.1..1 105 => j -.11.1.1. 106 => jk +.11.1.11 107 => k +.11.11.. 108 => k -.11.11.1 109 => km +.11.111. 110 => m -.11. 111 => mn +.111 112 => n +.111...1 113 => n -.111..1. 114 => no +.111..11 115 => o -.111.1.. 116 => op +.111.1.1 117 => p +.111.11. 118 => p -.111.111 119 => pq +.... 120 => q -...1 121 => qr +..1. 122 => r +..11 123 => r -.1.. 124 => rs +.1.1 125 => s -.11. 126 => st +.111 127 => t +1... 128 => t -1..1 129 => tu +1.1. 130 => u -1.11 131 => uv +11.. 132 => v +11.1 133 => v -111. 134 => vw +1111 135 => w -1...1... 136 => wx +1...1..1 137 => x +1...1.1. 138 => x -1...1.11 139 => xy +1...11.. 140 => y -1...11.1 141 => yz +1...111. 142 => z +1... 143 => z -1..1 144 => 2z +1..1...1 145 => 2 +1..1..1. 146 => 2 +1..1..11 147 => 2 +1..1.1.. 148 => 2 +1..1.1.1 149 => 2 +1..1.11. 150 => 2 +1..1.111 151 => 2 +1..11... 152 => 2 +1..11..1 153 => 2 +1..11.1. 154 => 2 +1..11.11 155 => 2 +1..111.. 156 => 2 +1..111.1 157 => 2 +1... 158 => 2 +1..1 159 => 2 +1.1. 160 => 2 +1.11 161 => 2 +1.1...1. 162 => 2 +1.1...11 163 => 2 +1.1..1.. 164 => 2 +1.1..1.1 165 => 2 +1.1..11. 166 => 2 +1.1..111 167 => 2 +1.1.1... 168 => 2 +1.1.1..1 169 => 2 +1.1.1.1. 170 => 2 +1.1.1.11 171 => 2 +1.1.11.. 172 => 2 +1.1.11.1 173 => 2 +1.1.111. 174 => 2 +1.1. 175 => 2 +1.11 176 => 2 +1.11...1 177 => 2 +1.11..1. 178 => 2 +1.11..11 179 => 2 +1.11.1.. 180 => 2 +1.11.1.1 181 => 2 +1.11.11. 182 => 2 +1.11.111 183 => 2 +1.111... 184 => 2 +1.111..1 185 => 2 +1.111.1. 186 => 2 +1.111.11 187 => 2 +1... 188 => 2 +1..1 189 => 2 +1.1. 190 => 2 +1.11 191 => 2 +11.. 192 => 2 +11.1 193 => 2 +111. 194 => 2 +11
[Bitcoin-development] Version bytes "2.0"
sipa made a nice specification for version numbers a while back, that seemed great at the time. However, there are concerns that it has overlooked a very important factor: usability in base58 encoding. The version currently chosen for script-based addresses (2) makes this excessively complicated for end users-- these addresses, once encoded, may begin with ANY of the following characters: 2opqrstuvwxyz Taking this into account, as well as sipa's original goals, I have come up with the following proposal: * Bits 128/64 define network class ** 0 = main network ** 64,128 = reserved ** 192 = test network * Bits 32/16 define network ** 0 = Bitcoin ** 16,32 = reserved ** 48 = OTHER (next octet) * Bits 8/4/2 define data class ** 0 = Public key hash ** 2 = Public key (raw) ** 4 = Script hash ** 6 = reserved ** 8 = Private key (raw) ** 10 = Signature ** 12 = reserved ** 14 = OTHER (next octet) * Bit 1 is freely chosen (for aesthetic assignment) Unlike sipa's proposal, however, I have (intentionally) neglected to consider the versions currently in use other than the widespread Bitcoin addresses. That means this reassigns the versions used by Namecoin and testnets, and probably messes with the (unmerged) key export format and signature formats. It "wastes" 2 bits (64 and 1) to accomplish aesthetic norms. Bit 64 *could* be assigned in the future if we ever have a "crunch". By using the high bit (128) to designate test networks, all testnet addresses will now begin with '2'. Bitcoin script-hash (aka OP_EVAL) addresses are assigned version 5 (using the aesthetic +1), which means they always begin with '3'. Signatures are on version 10 and/or 11, beginning with '5'. We get two first-class "networks" besides Bitcoin, addresses starting with '7' and 'E' (pubkey), and '9' and 'F' (script). I propose these should be assigned sparingly, only when a network has significant adoption-- the only one I would even *consider* might fit the requirement today is Namecoin. I would also suggest making merged mining support a requirement except for networks that have a proven-better proof-of-work (ie, NOT scrypt). Other networks can use the "other" value (thus beginning with 'L' and 'N') and a second octet (which can be divided up later). Thoughts? Luke -- Cloud Services Checklist: Pricing and Packaging Optimization This white paper is intended to serve as a reference, checklist and point of discussion for anyone considering optimizing the pricing and packaging model of a cloud services business. Read Now! http://www.accelacomm.com/jaw/sfnl/114/51491232/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
