* [Bitcoin-development] BIP 20 Rejected, process for BIP 21N
@ 2012-01-31 14:27 Amir Taaki
2012-01-31 14:33 ` slush
` (2 more replies)
0 siblings, 3 replies; 21+ messages in thread
From: Amir Taaki @ 2012-01-31 14:27 UTC (permalink / raw)
To: bitcoin-development
BIP 20 really has no support among implementations such as Bitcoin-Qt, Electrum, MultiBit or Bitcoin-JS. As the most active and visible user facing GUI projects (all with some form of URI Scheme), their opinion carries the most weight. To a lesser degree Bitcoin-Qt has the large majority of users too (although that's a line of reasoning I'd discourage).
Normally we should probably Reject BIP 21 and re-submit a new standard (for history's sake), but as a) BIP 21 is largely a copy paste of BIP 20 sans some sections b) it is still a draft, probably the best thing here is if you all agree on something to run it by BlueMatt and then we'll make it the new BIP 21.
I can see a consensus forming on most parts. Just the send private key is contentious, and there's the topic of adding a time to expire field for merchants (this is a very good idea IMO).
Also BIP 20 is problematic because it is incompatible with about every standard on the web. All the HTML, URI and everything uses decimal numbers alone. I see no reason for breaking with tradition. Note that everytime I have to write Color or Vectorize (as a British speaker) in my code, I die a little inside. But it's convention and American English = International English. Also it would be cool if all code used a *real* international language (like Esperanto) but the world ain't perfect! We live in a decimal-counting English-speaking Windows-using God-worshipping world!
(no offense to decimal-counting English-speaking Windows-using God-worshipping world- I do half those things too :)
^ permalink raw reply [flat|nested] 21+ messages in thread* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-01-31 14:27 [Bitcoin-development] BIP 20 Rejected, process for BIP 21N Amir Taaki @ 2012-01-31 14:33 ` slush 2012-01-31 14:52 ` Amir Taaki ` (2 more replies) 2012-01-31 16:04 ` Matt Corallo 2012-01-31 16:07 ` Luke-Jr 2 siblings, 3 replies; 21+ messages in thread From: slush @ 2012-01-31 14:33 UTC (permalink / raw) To: Amir Taaki; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 2756 bytes --] Hi Amir, > All the HTML, URI and everything uses decimal numbers alone. I see no reason for breaking with tradition. excuse me if it was already discussed, but maybe using satoshis instead of decimal bitcoin would be better choice? We all know about pains with proper handling decimal numbers across of all implementations - and it's not only about json-rpc. Otherwise I agree, BIP 21 is better than BIP 20 because it's easier to implement all points of the standard. Best, slush On Tue, Jan 31, 2012 at 3:27 PM, Amir Taaki <zgenjix@yahoo•com> wrote: > BIP 20 really has no support among implementations such as Bitcoin-Qt, > Electrum, MultiBit or Bitcoin-JS. As the most active and visible user > facing GUI projects (all with some form of URI Scheme), their opinion > carries the most weight. To a lesser degree Bitcoin-Qt has the large > majority of users too (although that's a line of reasoning I'd discourage). > > Normally we should probably Reject BIP 21 and re-submit a new standard > (for history's sake), but as a) BIP 21 is largely a copy paste of BIP 20 > sans some sections b) it is still a draft, probably the best thing here is > if you all agree on something to run it by BlueMatt and then we'll make it > the new BIP 21. > > I can see a consensus forming on most parts. Just the send private key is > contentious, and there's the topic of adding a time to expire field for > merchants (this is a very good idea IMO). > > Also BIP 20 is problematic because it is incompatible with about every > standard on the web. All the HTML, URI and everything uses decimal numbers > alone. I see no reason for breaking with tradition. Note that everytime I > have to write Color or Vectorize (as a British speaker) in my code, I die a > little inside. But it's convention and American English = International > English. Also it would be cool if all code used a *real* international > language (like Esperanto) but the world ain't perfect! We live in a > decimal-counting English-speaking Windows-using God-worshipping world! > > (no offense to decimal-counting English-speaking Windows-using > God-worshipping world- I do half those things too :) > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 3417 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-01-31 14:33 ` slush @ 2012-01-31 14:52 ` Amir Taaki [not found] ` <CAKm8k+1cHagzj3T27S=h0PueH8EgcCkEajZGgAw7HcQ=N-46ow@mail.gmail.com> 2012-01-31 14:59 ` Gregory Maxwell 2 siblings, 0 replies; 21+ messages in thread From: Amir Taaki @ 2012-01-31 14:52 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 2567 bytes --] > excuse me if it was already discussed, but maybe using satoshis instead of decimal bitcoin would be better ?> choice? We all know about pains with proper handling decimal numbers across of all implementations - and > it's not only about json-rpc. Yeah well it's up to the people who are making this stuff to decide :) On Tue, Jan 31, 2012 at 3:27 PM, Amir Taaki <zgenjix@yahoo•com> wrote: BIP 20 really has no support among implementations such as Bitcoin-Qt, Electrum, MultiBit or Bitcoin-JS. As the most active and visible user facing GUI projects (all with some form of URI Scheme), their opinion carries the most weight. To a lesser degree Bitcoin-Qt has the large majority of users too (although that's a line of reasoning I'd discourage). > >Normally we should probably Reject BIP 21 and re-submit a new standard (for history's sake), but as a) BIP 21 is largely a copy paste of BIP 20 sans some sections b) it is still a draft, probably the best thing here is if you all agree on something to run it by BlueMatt and then we'll make it the new BIP 21. > >I can see a consensus forming on most parts. Just the send private key is contentious, and there's the topic of adding a time to expire field for merchants (this is a very good idea IMO). > >Also BIP 20 is problematic because it is incompatible with about every standard on the web. All the HTML, URI and everything uses decimal numbers alone. I see no reason for breaking with tradition. Note that everytime I have to write Color or Vectorize (as a British speaker) in my code, I die a little inside. But it's convention and American English = International English. Also it would be cool if all code used a *real* international language (like Esperanto) but the world ain't perfect! We live in a decimal-counting English-speaking Windows-using God-worshipping world! > >(no offense to decimal-counting English-speaking Windows-using God-worshipping world- I do half those things too :) > >------------------------------------------------------------------------------ >Keep Your Developer Skills Current with LearnDevNow! >The most comprehensive online learning library for Microsoft developers >is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >Metro Style Apps, more. Free future releases when you subscribe now! >http://p.sf.net/sfu/learndevnow-d2d >_______________________________________________ >Bitcoin-development mailing list >Bitcoin-development@lists•sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 3711 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
[parent not found: <CAKm8k+1cHagzj3T27S=h0PueH8EgcCkEajZGgAw7HcQ=N-46ow@mail.gmail.com>]
* [Bitcoin-development] BIP 20 Rejected, process for BIP 21N [not found] ` <CAKm8k+1cHagzj3T27S=h0PueH8EgcCkEajZGgAw7HcQ=N-46ow@mail.gmail.com> @ 2012-01-31 14:53 ` Gary Rowe 2012-01-31 15:02 ` Gregory Maxwell 0 siblings, 1 reply; 21+ messages in thread From: Gary Rowe @ 2012-01-31 14:53 UTC (permalink / raw) To: Bitcoin Development List [-- Attachment #1: Type: text/plain, Size: 4360 bytes --] Regarding the decimal vs satoshi notation I see a few problems with satoshi: * readability - humans reading the URI would expect it to accurately reflect what is being displayed (subject to internationalisation issues) For example, amount=1.234 is more human readable than amount=123400000 (ish) * backwards compatibility - existing software already uses the decimal notation * forwards compatibility - Bitcoin needs to move beyond the satoshi to 20 dps for some reason, this remains OK within the existing schema, but forces decimals into the satoshi scheme * simplicity - dual decimal/satoshi variants should be discouraged under the "single representation" approach It's relatively straightforward to convert a string encoded decimal into an internal integer for currency calculations just by applying a multiplying factor. One never uses doubles or floats for money. On 31 January 2012 14:33, slush <slush@centrum•cz> wrote: > Hi Amir, > > > All the HTML, URI and everything uses decimal numbers alone. I see no > reason for breaking with tradition. > > excuse me if it was already discussed, but maybe using satoshis instead of > decimal bitcoin would be better choice? We all know about pains with proper > handling decimal numbers across of all implementations - and it's not only > about json-rpc. > > Otherwise I agree, BIP 21 is better than BIP 20 because it's easier to > implement all points of the standard. > > Best, > slush > > On Tue, Jan 31, 2012 at 3:27 PM, Amir Taaki <zgenjix@yahoo•com> wrote: > >> BIP 20 really has no support among implementations such as Bitcoin-Qt, >> Electrum, MultiBit or Bitcoin-JS. As the most active and visible user >> facing GUI projects (all with some form of URI Scheme), their opinion >> carries the most weight. To a lesser degree Bitcoin-Qt has the large >> majority of users too (although that's a line of reasoning I'd discourage). >> >> Normally we should probably Reject BIP 21 and re-submit a new standard >> (for history's sake), but as a) BIP 21 is largely a copy paste of BIP 20 >> sans some sections b) it is still a draft, probably the best thing here is >> if you all agree on something to run it by BlueMatt and then we'll make it >> the new BIP 21. >> >> I can see a consensus forming on most parts. Just the send private key is >> contentious, and there's the topic of adding a time to expire field for >> merchants (this is a very good idea IMO). >> >> Also BIP 20 is problematic because it is incompatible with about every >> standard on the web. All the HTML, URI and everything uses decimal numbers >> alone. I see no reason for breaking with tradition. Note that everytime I >> have to write Color or Vectorize (as a British speaker) in my code, I die a >> little inside. But it's convention and American English = International >> English. Also it would be cool if all code used a *real* international >> language (like Esperanto) but the world ain't perfect! We live in a >> decimal-counting English-speaking Windows-using God-worshipping world! >> >> (no offense to decimal-counting English-speaking Windows-using >> God-worshipping world- I do half those things too :) >> >> >> ------------------------------------------------------------------------------ >> Keep Your Developer Skills Current with LearnDevNow! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-d2d >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 5764 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-01-31 14:53 ` Gary Rowe @ 2012-01-31 15:02 ` Gregory Maxwell 2012-01-31 15:04 ` Gary Rowe 0 siblings, 1 reply; 21+ messages in thread From: Gregory Maxwell @ 2012-01-31 15:02 UTC (permalink / raw) To: Gary Rowe; +Cc: Bitcoin Development List On Tue, Jan 31, 2012 at 9:53 AM, Gary Rowe <g.rowe@froot•co.uk> wrote: > One never uses doubles or floats for money. Lots and lots of people do. Go place a sell order on mtgox for $999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 per BTC and look at the awesome doublemax trade it actually stores for you. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-01-31 15:02 ` Gregory Maxwell @ 2012-01-31 15:04 ` Gary Rowe 0 siblings, 0 replies; 21+ messages in thread From: Gary Rowe @ 2012-01-31 15:04 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Development List [-- Attachment #1: Type: text/plain, Size: 507 bytes --] Shudder. :-) On 31 January 2012 15:02, Gregory Maxwell <gmaxwell@gmail•com> wrote: > On Tue, Jan 31, 2012 at 9:53 AM, Gary Rowe <g.rowe@froot•co.uk> wrote: > > One never uses doubles or floats for money. > > Lots and lots of people do. Go place a sell order on mtgox for > > $999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999999 > per BTC and look at the awesome doublemax trade it actually stores for > you. > [-- Attachment #2: Type: text/html, Size: 854 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-01-31 14:33 ` slush 2012-01-31 14:52 ` Amir Taaki [not found] ` <CAKm8k+1cHagzj3T27S=h0PueH8EgcCkEajZGgAw7HcQ=N-46ow@mail.gmail.com> @ 2012-01-31 14:59 ` Gregory Maxwell 2 siblings, 0 replies; 21+ messages in thread From: Gregory Maxwell @ 2012-01-31 14:59 UTC (permalink / raw) To: slush; +Cc: bitcoin-development On Tue, Jan 31, 2012 at 9:33 AM, slush <slush@centrum•cz> wrote: > excuse me if it was already discussed, but maybe using satoshis instead of > decimal bitcoin would be better choice? We all know about pains with proper > handling decimal numbers across of all implementations - and it's not only > about json-rpc. Mixed bag of worms there, even ignoring what people have already implemented— if you make it use satoshis people who are working with things at COIN scale are inevitably going to end up multiplying numbers stored as radix-2 floating point to get satoshis and then are going to be confused when it comes out "wrong". Using decimal numbers at least lets them treat the values as strings and avoid arithmetic that will end up confusing them. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-01-31 14:27 [Bitcoin-development] BIP 20 Rejected, process for BIP 21N Amir Taaki 2012-01-31 14:33 ` slush @ 2012-01-31 16:04 ` Matt Corallo 2012-01-31 18:22 ` Matt Corallo 2012-01-31 16:07 ` Luke-Jr 2 siblings, 1 reply; 21+ messages in thread From: Matt Corallo @ 2012-01-31 16:04 UTC (permalink / raw) To: bitcoin-development On Tue, 2012-01-31 at 06:27 -0800, Amir Taaki wrote: > BIP 20 really has no support among implementations such as Bitcoin-Qt, Electrum, MultiBit or Bitcoin-JS. As the most active and visible user facing GUI projects (all with some form of URI Scheme), their opinion carries the most weight. To a lesser degree Bitcoin-Qt has the large majority of users too (although that's a line of reasoning I'd discourage). > > Normally we should probably Reject BIP 21 and re-submit a new standard (for history's sake), but as a) BIP 21 is largely a copy paste of BIP 20 sans some sections b) it is still a draft, probably the best thing here is if you all agree on something to run it by BlueMatt and then we'll make it the new BIP 21. > > I can see a consensus forming on most parts. Just the send private key is contentious, and there's the topic of adding a time to expire field for merchants (this is a very good idea IMO). > > Also BIP 20 is problematic because it is incompatible with about every standard on the web. All the HTML, URI and everything uses decimal numbers alone. I see no reason for breaking with tradition. Note that everytime I have to write Color or Vectorize (as a British speaker) in my code, I die a little inside. But it's convention and American English = International English. Also it would be cool if all code used a *real* international language (like Esperanto) but the world ain't perfect! We live in a decimal-counting English-speaking Windows-using God-worshipping world! > > (no offense to decimal-counting English-speaking Windows-using God-worshipping world- I do half those things too :) The send crap was not in the original spec, is not implemented anywhere, and should have been removed as part of the BIP 21 copy/paste. It is now gone. As for the expire time, well thats a bit problematic IMHO. Technically BIP 21 is still a draft, but it is implemented in all versions of Bitcoin-Qt for drag and drop and adding a field which restricts the validity of a URI for new clients, but which old clients will gladly accept could result in some ugly situations IMO. Matt ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-01-31 16:04 ` Matt Corallo @ 2012-01-31 18:22 ` Matt Corallo 2012-01-31 19:02 ` Wladimir ` (2 more replies) 0 siblings, 3 replies; 21+ messages in thread From: Matt Corallo @ 2012-01-31 18:22 UTC (permalink / raw) To: bitcoin-development OK, so I just did some heavy changes to the methods for forward compatibility in BIP 21. Instead of a version number, now new variables will be added either as-is or with a mustimplement: prefix. If a clients does not know what the variable is that is after mustimplement:, it should consider the entire URI invalid and either notify the user or just drop it silently. That way things like expiretime can be added without worrying about old clients ignoring the field. All that said, I dont think its an ideal solution, depending on the names of variables to provide information is ugly. If anyone has a better idea on how to do backward compatibility, please suggest it. In terms of the expiretime field being implemented now, I dont think its appropriate. Because some clients already have an old implementation, the possibility of it getting ignored is too large. The BIP now states that "It is recommended that additional variables prefixed with mustimplement: not be used in a mission-critical way until a grace period of 6 months from the finalization of this BIP has passed in order to allow client developers to release new versions, and users of old clients to upgrade." Mostly, however, I want to keep the list of changes from the Bitcoin-Qt implementation to this BIP very, very minimal this late the 0.6 release cycle (I want to get this BIP finalized and implemented for 0.6, so that at least Bitcoin-Qt will have no version which support OS URI opening with a broken implementation). Matt On Tue, 2012-01-31 at 11:04 -0500, Matt Corallo wrote: > On Tue, 2012-01-31 at 06:27 -0800, Amir Taaki wrote: > > BIP 20 really has no support among implementations such as Bitcoin-Qt, Electrum, MultiBit or Bitcoin-JS. As the most active and visible user facing GUI projects (all with some form of URI Scheme), their opinion carries the most weight. To a lesser degree Bitcoin-Qt has the large majority of users too (although that's a line of reasoning I'd discourage). > > > > Normally we should probably Reject BIP 21 and re-submit a new standard (for history's sake), but as a) BIP 21 is largely a copy paste of BIP 20 sans some sections b) it is still a draft, probably the best thing here is if you all agree on something to run it by BlueMatt and then we'll make it the new BIP 21. > > > > I can see a consensus forming on most parts. Just the send private key is contentious, and there's the topic of adding a time to expire field for merchants (this is a very good idea IMO). > > > > Also BIP 20 is problematic because it is incompatible with about every standard on the web. All the HTML, URI and everything uses decimal numbers alone. I see no reason for breaking with tradition. Note that everytime I have to write Color or Vectorize (as a British speaker) in my code, I die a little inside. But it's convention and American English = International English. Also it would be cool if all code used a *real* international language (like Esperanto) but the world ain't perfect! We live in a decimal-counting English-speaking Windows-using God-worshipping world! > > > > (no offense to decimal-counting English-speaking Windows-using God-worshipping world- I do half those things too :) > > The send crap was not in the original spec, is not implemented anywhere, > and should have been removed as part of the BIP 21 copy/paste. It is > now gone. > > As for the expire time, well thats a bit problematic IMHO. Technically > BIP 21 is still a draft, but it is implemented in all versions of > Bitcoin-Qt for drag and drop and adding a field which restricts the > validity of a URI for new clients, but which old clients will gladly > accept could result in some ugly situations IMO. > > Matt ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-01-31 18:22 ` Matt Corallo @ 2012-01-31 19:02 ` Wladimir 2012-01-31 21:42 ` Matt Corallo 2012-01-31 22:14 ` Andreas Schildbach 2012-02-04 14:03 ` thomasV1 2 siblings, 1 reply; 21+ messages in thread From: Wladimir @ 2012-01-31 19:02 UTC (permalink / raw) To: Matt Corallo; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 437 bytes --] On Tue, Jan 31, 2012 at 7:22 PM, Matt Corallo <bitcoin-list@bluematt•me>wrote: > > All that said, I dont think its an ideal solution, depending on the > names of variables to provide information is ugly. If anyone has a > better idea on how to do backward compatibility, please suggest it. > I like the mustimplement: idea, though I'd recommend a shorter (abbreviated) prefix, to keep URL sizes small for QR codes and such, Wladimir [-- Attachment #2: Type: text/html, Size: 716 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-01-31 19:02 ` Wladimir @ 2012-01-31 21:42 ` Matt Corallo 0 siblings, 0 replies; 21+ messages in thread From: Matt Corallo @ 2012-01-31 21:42 UTC (permalink / raw) To: bitcoin-development OK, I went ahead and changed mustimplement out for req (required). Its not quite as expressive, but its much shorter and still makes sense (IMHO). I also explicitly stated that numbers shouldnt contain commas and should use period to separate whole numbers and fractional decimal fractions (to avoid any localization concerns). Matt On Tue, 2012-01-31 at 20:02 +0100, Wladimir wrote: > > On Tue, Jan 31, 2012 at 7:22 PM, Matt Corallo > <bitcoin-list@bluematt•me> wrote: > > All that said, I dont think its an ideal solution, depending > on the > names of variables to provide information is ugly. If anyone > has a > better idea on how to do backward compatibility, please > suggest it. > > I like the mustimplement: idea, though I'd recommend a shorter > (abbreviated) prefix, to keep URL sizes small for QR codes and such, > > Wladimir > > ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-01-31 18:22 ` Matt Corallo 2012-01-31 19:02 ` Wladimir @ 2012-01-31 22:14 ` Andreas Schildbach 2012-01-31 22:37 ` Gary Rowe 2012-02-04 14:03 ` thomasV1 2 siblings, 1 reply; 21+ messages in thread From: Andreas Schildbach @ 2012-01-31 22:14 UTC (permalink / raw) To: bitcoin-development On 01/31/2012 07:22 PM, Matt Corallo wrote: > that "It is recommended that additional variables prefixed with > mustimplement: not be used in a mission-critical way until a grace Is the ':' sign actually allowed in URL parameter names (unescaped/unencoded)? If not, I'd propose an unrestricted char instead, maybe '_'. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-01-31 22:14 ` Andreas Schildbach @ 2012-01-31 22:37 ` Gary Rowe 2012-01-31 22:47 ` Matt Corallo 0 siblings, 1 reply; 21+ messages in thread From: Gary Rowe @ 2012-01-31 22:37 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1566 bytes --] Andreas has a good point. See RFC 3986 on URI schemes: http://tools.ietf.org/html/rfc3986#page-12 The colon is a reserved general delimiter (similar in use to the / in a typical URL, but applies to URNs etc). As suggested, we get req:something being changed to one of the unreserved characters that do not have to be URL encoded. Again, from the RFC these are * Option A: req_something (underscore) * Option B: req-something (hyphen) * Option C: req~something (tilde) * Option D: req.something (period) Personally, my eye likes Option B, the hyphen. On 31 January 2012 22:14, Andreas Schildbach <andreas@schildbach•de> wrote: > On 01/31/2012 07:22 PM, Matt Corallo wrote: > > > that "It is recommended that additional variables prefixed with > > mustimplement: not be used in a mission-critical way until a grace > > Is the ':' sign actually allowed in URL parameter names > (unescaped/unencoded)? If not, I'd propose an unrestricted char instead, > maybe '_'. > > > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 2384 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-01-31 22:37 ` Gary Rowe @ 2012-01-31 22:47 ` Matt Corallo 0 siblings, 0 replies; 21+ messages in thread From: Matt Corallo @ 2012-01-31 22:47 UTC (permalink / raw) To: bitcoin-development Odd, here I was thinking I checked that. Just goes to show how useful sources other than the rfc itself are... Anyway, Ill change it to a hyphen. Matt On Tue, 2012-01-31 at 22:37 +0000, Gary Rowe wrote: > Andreas has a good point. See RFC 3986 on URI > schemes: http://tools.ietf.org/html/rfc3986#page-12 > > > The colon is a reserved general delimiter (similar in use to the / in > a typical URL, but applies to URNs etc). As suggested, we get > req:something being changed to one of the unreserved characters that > do not have to be URL encoded. Again, from the RFC these are > > > * Option A: req_something (underscore) > * Option B: req-something (hyphen) > * Option C: req~something (tilde) > * Option D: req.something (period) > > > Personally, my eye likes Option B, the hyphen. > > On 31 January 2012 22:14, Andreas Schildbach <andreas@schildbach•de> > wrote: > On 01/31/2012 07:22 PM, Matt Corallo wrote: > > > that "It is recommended that additional variables prefixed > with > > mustimplement: not be used in a mission-critical way until a > grace > > > Is the ':' sign actually allowed in URL parameter names > (unescaped/unencoded)? If not, I'd propose an unrestricted > char instead, > maybe '_'. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-01-31 18:22 ` Matt Corallo 2012-01-31 19:02 ` Wladimir 2012-01-31 22:14 ` Andreas Schildbach @ 2012-02-04 14:03 ` thomasV1 2012-02-04 16:03 ` Gary Rowe 2 siblings, 1 reply; 21+ messages in thread From: thomasV1 @ 2012-02-04 14:03 UTC (permalink / raw) To: bitcoin-development Just another question concerning BIP21: On the wiki, the description of the "message" parameter reads: "message that shown to the user after scanning the QR code" I believe that the purpose of this parameter is to contain a description of the transaction. This has use cases that go beyond QR codes. If I am right, then I would say that naming it "message" is misleading. In fact, "message" suggests that a message will be sent to someone (the recipient of the funds? a third party?), which is not the case here. That parameter should probably be called "description". -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-02-04 14:03 ` thomasV1 @ 2012-02-04 16:03 ` Gary Rowe 2012-02-04 17:15 ` Matt Corallo 0 siblings, 1 reply; 21+ messages in thread From: Gary Rowe @ 2012-02-04 16:03 UTC (permalink / raw) To: Bitcoin Development List [-- Attachment #1: Type: text/plain, Size: 1398 bytes --] Seems reasonable to me. On 4 Feb 2012 14:03, <thomasV1@gmx•de> wrote: > Just another question concerning BIP21: > > On the wiki, the description of the "message" parameter reads: > "message that shown to the user after scanning the QR code" > > I believe that the purpose of this parameter is to contain a description > of the transaction. This has use cases that go beyond QR codes. > > If I am right, then I would say that naming it "message" is misleading. In > fact, "message" suggests that a message will be sent to someone (the > recipient of the funds? a third party?), which is not the case here. That > parameter should probably be called "description". > > -- > Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir > belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 2027 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-02-04 16:03 ` Gary Rowe @ 2012-02-04 17:15 ` Matt Corallo 0 siblings, 0 replies; 21+ messages in thread From: Matt Corallo @ 2012-02-04 17:15 UTC (permalink / raw) To: bitcoin-development I changed the description of the message parameter to be a bit more descriptive, however, I dont want to change the name of the parameter because some clients have already implemented that and I really prefer to make as minor of changes as possible to this BIP even if it is officially only a Draft. Matt On Sat, 2012-02-04 at 16:03 +0000, Gary Rowe wrote: > Seems reasonable to me. > > On 4 Feb 2012 14:03, <thomasV1@gmx•de> wrote: > Just another question concerning BIP21: > > On the wiki, the description of the "message" parameter reads: > "message that shown to the user after scanning the QR code" > > I believe that the purpose of this parameter is to contain a > description of the transaction. This has use cases that go > beyond QR codes. > > If I am right, then I would say that naming it "message" is > misleading. In fact, "message" suggests that a message will be > sent to someone (the recipient of the funds? a third party?), > which is not the case here. That parameter should probably be > called "description". ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-01-31 14:27 [Bitcoin-development] BIP 20 Rejected, process for BIP 21N Amir Taaki 2012-01-31 14:33 ` slush 2012-01-31 16:04 ` Matt Corallo @ 2012-01-31 16:07 ` Luke-Jr 2 siblings, 0 replies; 21+ messages in thread From: Luke-Jr @ 2012-01-31 16:07 UTC (permalink / raw) To: bitcoin-development, Amir Taaki On Tuesday, January 31, 2012 9:27:26 AM Amir Taaki wrote: > BIP 20 really has no support among implementations such as Bitcoin-Qt, > Electrum, MultiBit or Bitcoin-JS. It does among implementations such as Spesmilo and WalletBuddy, and has for some time. More importantly, it achieved consensus and Final status before any objections were made. Final only changes to Superceded. What's the point of a formal BIP process if that process won't be followed? > Also BIP 20 is problematic because it is incompatible with about every > standard on the web. All the HTML, URI and everything uses decimal numbers > alone. I see no reason for breaking with tradition. That's not incompatibility, and not true. The standards use hexadecimal numbers, and I can't even think of a single case off-hand where decimal is used. That being said, I'd be fine with a spec that used strtol-compatible satoshis for amount. This is both simple and forward-compatible. On Tuesday, January 31, 2012 9:53:57 AM Gary Rowe wrote: > Regarding the decimal vs satoshi notation I see a few problems with > satoshi: > > * readability - humans reading the URI would expect it to accurately > reflect what is being displayed (subject to internationalisation issues) > For example, amount=1.234 is more human readable than amount=123400000 > (ish) This is true only for BTC users. While that might be a sensible unit today, it almost certainly won't be in the future. amount=0.00001 is much worse than amount=1000 or amount=1x3 > * backwards compatibility - existing software already uses the decimal > notation Existing software uses Satoshis internally, and it's generally regarded as a design flaw that it uses BTC numbers in the JSON-RPC protocol. > * forwards compatibility - Bitcoin needs to move beyond the satoshi to 20 > dps for some reason, this remains OK within the existing schema, but forces > decimals into the satoshi scheme This strikes me as more of "let's test the code earlier rather than later" than forwards compatibility. The problem is that it's pretty much unanimous that floating-point should never be used, and without that both representations will be rounding when there are smaller units available. ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N @ 2012-02-02 17:07 Gary Rowe 2012-02-02 17:39 ` Matt Corallo 0 siblings, 1 reply; 21+ messages in thread From: Gary Rowe @ 2012-02-02 17:07 UTC (permalink / raw) To: Bitcoin Development List [-- Attachment #1: Type: text/plain, Size: 128 bytes --] BlueMatt, did the BIP0021 Wiki entry for "req:" to "req-" get updated? I'm looking there now and it seems to be still at "req:" [-- Attachment #2: Type: text/html, Size: 166 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-02-02 17:07 Gary Rowe @ 2012-02-02 17:39 ` Matt Corallo 2012-02-02 17:46 ` Gary Rowe 0 siblings, 1 reply; 21+ messages in thread From: Matt Corallo @ 2012-02-02 17:39 UTC (permalink / raw) To: bitcoin-development Not yet, its up to genjix (Amir) to do that. See https://github.com/genjix/bips/pull/2 Matt On Thu, 2012-02-02 at 17:07 +0000, Gary Rowe wrote: > BlueMatt, did the BIP0021 Wiki entry for "req:" to "req-" get updated? > I'm looking there now and it seems to be still at "req:" > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists•sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development ^ permalink raw reply [flat|nested] 21+ messages in thread
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 2012-02-02 17:39 ` Matt Corallo @ 2012-02-02 17:46 ` Gary Rowe 0 siblings, 0 replies; 21+ messages in thread From: Gary Rowe @ 2012-02-02 17:46 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1619 bytes --] OK - I've added a comment to the pull request. On 2 February 2012 17:39, Matt Corallo <bitcoin-list@bluematt•me> wrote: > Not yet, its up to genjix (Amir) to do that. See > https://github.com/genjix/bips/pull/2 > > Matt > > On Thu, 2012-02-02 at 17:07 +0000, Gary Rowe wrote: > > BlueMatt, did the BIP0021 Wiki entry for "req:" to "req-" get updated? > > I'm looking there now and it seems to be still at "req:" > > > ------------------------------------------------------------------------------ > > Keep Your Developer Skills Current with LearnDevNow! > > The most comprehensive online learning library for Microsoft developers > > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > > Metro Style Apps, more. Free future releases when you subscribe now! > > http://p.sf.net/sfu/learndevnow-d2d > > _______________________________________________ Bitcoin-development > mailing list Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > ------------------------------------------------------------------------------ > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 2672 bytes --] ^ permalink raw reply [flat|nested] 21+ messages in thread
end of thread, other threads:[~2012-02-04 17:15 UTC | newest]
Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-01-31 14:27 [Bitcoin-development] BIP 20 Rejected, process for BIP 21N Amir Taaki
2012-01-31 14:33 ` slush
2012-01-31 14:52 ` Amir Taaki
[not found] ` <CAKm8k+1cHagzj3T27S=h0PueH8EgcCkEajZGgAw7HcQ=N-46ow@mail.gmail.com>
2012-01-31 14:53 ` Gary Rowe
2012-01-31 15:02 ` Gregory Maxwell
2012-01-31 15:04 ` Gary Rowe
2012-01-31 14:59 ` Gregory Maxwell
2012-01-31 16:04 ` Matt Corallo
2012-01-31 18:22 ` Matt Corallo
2012-01-31 19:02 ` Wladimir
2012-01-31 21:42 ` Matt Corallo
2012-01-31 22:14 ` Andreas Schildbach
2012-01-31 22:37 ` Gary Rowe
2012-01-31 22:47 ` Matt Corallo
2012-02-04 14:03 ` thomasV1
2012-02-04 16:03 ` Gary Rowe
2012-02-04 17:15 ` Matt Corallo
2012-01-31 16:07 ` Luke-Jr
2012-02-02 17:07 Gary Rowe
2012-02-02 17:39 ` Matt Corallo
2012-02-02 17:46 ` Gary Rowe
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox