[Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Amir Taaki]

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 :)

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[slush]

[-- 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 --]

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Amir Taaki]

[-- 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 --]

[Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Gary Rowe]

[-- 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 --]

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Gregory Maxwell]

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.

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Gary Rowe]

[-- 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 --]

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Gregory Maxwell]

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.

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Matt Corallo]

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

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Matt Corallo]

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

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Wladimir]

[-- 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 --]

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Matt Corallo]

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
> 
> 

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Andreas Schildbach]

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 '_'.

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Gary Rowe]

[-- 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 --]

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Matt Corallo]

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 '_'.

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[thomasV1]

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

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Gary Rowe]

[-- 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 --]

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Matt Corallo]

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".

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Luke-Jr]

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.

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Gary Rowe]

[-- 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 --]

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Matt Corallo]

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

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

[Gary Rowe]

[-- 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 --]