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.
Seems reasonable to me.
On 4 Feb 2012 14:03, 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 descripti
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 co
OK - I've added a comment to the pull request.
On 2 February 2012 17:39, Matt Corallo 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 +, Gary Rowe wrote:
> > BlueMatt, did the BIP0021 Wiki entry for "
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 +, 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:"
> --
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
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 +, Gary Rowe wrote:
> Andreas has a good point. See RFC 3986 on URI
> schemes: http://tools.ietf.org/html/rfc3986
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
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 cha
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 avo
On Tue, Jan 31, 2012 at 7:22 PM, Matt Corallo 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
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
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
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.
Shudder.
:-)
On 31 January 2012 15:02, Gregory Maxwell wrote:
> On Tue, Jan 31, 2012 at 9:53 AM, Gary Rowe wrote:
> > One never uses doubles or floats for money.
>
> Lots and lots of people do. Go place a sell order on mtgox for
>
> $999
On Tue, Jan 31, 2012 at 9:53 AM, Gary Rowe wrote:
> One never uses doubles or floats for money.
Lots and lots of people do. Go place a sell order on mtgox for
$
On Tue, Jan 31, 2012 at 9:33 AM, slush 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.
M
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=12340 (ish)
*
> 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
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 acr
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 user
21 matches
Mail list logo
