* 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 [Bitcoin-development] BIP 20 Rejected, process for BIP 21N 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
* 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-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-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-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 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 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 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 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 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 14:27 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-01-31 14:27 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 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: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 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
* [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: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
* Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N
2012-01-31 14:27 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
* [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
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-02-02 17:07 [Bitcoin-development] BIP 20 Rejected, process for BIP 21N Gary Rowe
2012-02-02 17:39 ` Matt Corallo
2012-02-02 17:46 ` Gary Rowe
-- strict thread matches above, loose matches on Subject: below --
2012-01-31 14:27 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox