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 Tue, Jan 31, 2012 at 11:50 AM, Andy Parkins wrote:
> Hello,
>
> Gulp. Am a little nervous about wading into this swamp. However, it seems
> to me that the debate has veered into the personal and away from the
I think you've been deceived by people who have some interest in
promoting this as
On 2012 January 31 Tuesday, Luke-Jr wrote:
> I'm not aware of any remaining *tangible* objections to BIP 17 at this
> point (Gavin seems concerned over a theoretical
> risk-that-nobody-has-thought-of), but if there's a better solution, I'm
> perfectly fine Withdrawing BIP 17 to support it.
I imag
On Tuesday, January 31, 2012 11:50:58 AM Andy Parkins wrote:
> Gulp. Am a little nervous about wading into this swamp. However, it seems
> to me that the debate has veered into the personal and away from the
> technical. Surely if there are objections to both suggestions, that
> another solution
Hello,
Gulp. Am a little nervous about wading into this swamp. However, it seems
to me that the debate has veered into the personal and away from the
technical. Surely if there are objections to both suggestions, that another
solution might be better? The answer doesn't have to be A or B, i
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.
On Tue, Jan 31, 2012 at 12:17 AM, Gregory Maxwell wrote:
> On Mon, Jan 30, 2012 at 11:33 PM, Michael Hendricks wrote:
>> address manager point to the attacker. If a client has 8 connections
>> to the network, a Sybil attack would succeed 1.7% of the time.
>
> Meh, careful not to mixup addrman cr
On Tue, Jan 31, 2012 at 12:17 AM, Gregory Maxwell wrote:
> On Mon, Jan 30, 2012 at 11:33 PM, Michael Hendricks wrote:
>> address manager point to the attacker. If a client has 8 connections
>> to the network, a Sybil attack would succeed 1.7% of the time.
>
> Meh, careful not to mixup addrman cr
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
We split IRC among all those channels to handle the load when there were 60k
clients.. the ideal thing would be some kind of dynamic sizing, and this
applies to the number of outbound connections and transaction relaying logic
too.. the same values that work for 1k clients don't work as well for
On 1/02/2012 00:12, Gavin Andresen wrote:
> RE: BIP 21 versus BIP 20: I like BIP 21; simpler is better.
>
> RE: signing and dating URIs: good ideas. I think we should agree
> that there is consensus around BIP 21 and then after there is some
> experience with signing/dating URIs you should writ
RE: BIP 21 versus BIP 20: I like BIP 21; simpler is better.
RE: signing and dating URIs: good ideas. I think we should agree
that there is consensus around BIP 21 and then after there is some
experience with signing/dating URIs you should write follow-up BIPs .
--
--
Gavin Andresen
-
>
> IMHO its standard that unknown URL parameters are simply ignored. I
> think we should not change this principle.
>
It's usually the right thing to do to be open to future backward-compatible
changes, but I don't know of any such standard, as it equally makes future
non-backward-compatible chan
On 01/31/2012 11:22 AM, Wladimir wrote:
> To ensure forward compatibility with optional fields, we need to define
> how a client handles fields that it doesn't know about.
>
> When should it display an error message, and when should it silently
> accept and ignore the extraneous fields?
IMHO its
On Tue, Jan 31, 2012 at 10:01:00AM +, Gary Rowe wrote:
> Personally, I feel that simple is best and while a block number represents
> Bitcoin's pulse, there is no guarantee that a block will be discovered at
> any particular moment. From a merchant perspective the main point of the
> expires fi
On Tue, Jan 31, 2012 at 09:35:26AM +0100, Wladimir wrote:
> I also wonder whether the "send to private address" should be part of this
> BIP, or a future one.
It is actually a "send of private key", not to. And I agree, it should be part
of a separate BIP.
--
Pieter
To ensure forward compatibility with optional fields, we need to define how
a client handles fields that it doesn't know about.
When should it display an error message, and when should it silently accept
and ignore the extraneous fields?
(For example, if something that restricts the validity, suc
I think that the "send to private address" field will require more effort
to implement than the simpler "expires" and "message" fields and should be
deferred to a later BIP. There is a pressing need for expires and the only
point of contention I see is the inclusion of a dual representation (block
On 01/30/2012 11:33 PM, Michael Hendricks wrote:
> On Mon, Jan 30, 2012 at 7:05 PM, Gavin Andresen
> wrote:
>> Given the randomness in Pieter's design, that seems extremely unlikely
>> / difficult to do. Is it possible to do a back-of-the-envelope
>> calculation to figure out what percentage of n
I also wonder whether the "send to private address" should be part of this
BIP, or a future one.
IMO (but your mileage may vary) this BIP should only define the bare-bones
URL scheme, AND provide room for future extensions such
as send-to-private-address, send-multiple-signers, and so on. These sh
Generally I prefer BIP 21 over BIP 20.
I'm neutral on the 'send' parameter - present in both BIPs - which I
don't understand. I think a practical usecase should be given in the BIP.
Also, the 'version' parameter is unclear. What does it mean? Is an oder
defined on versions (1.0b > 1.0)? Why is it
> I think it's important that we have more mechanisms then just DNS and
> hardcoded seednodes.
> This is important because the mechanisms we have are all pretty
> subject to blocking. Now— before you say it— Bitcoin isn't intended to
> be blocking resistant (combine it with Tor and Tor anti-censors
34 matches
Mail list logo
