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
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
> Regarding the idea of a signed URI, it is appealing, however, it may not
> work. If I understand it correctly, the main idea appears to be to protect
> a URI from malicious replacement
No. The main idea is to protect the consumer against a malicious seller
pretending that he has not been paid
On Monday, January 30, 2012 2:13:52 PM Gary Rowe wrote:
> Having closely read the BIP20 proposal, I can see your point. As I see it,
> BIP 20 vs BIP 21 is about standardising on a representation of the "amount"
> field. BIP 20 proposes that "amount" can contain alternative
> representations, clearl
Having closely read the BIP20 proposal, I can see your point. As I see it,
BIP 20 vs BIP 21 is about standardising on a representation of the "amount"
field. BIP 20 proposes that "amount" can contain alternative
representations, clearly defined, whereas BIP 21 requires the use of a
single represent
On Monday, January 30, 2012 1:50:03 PM Gary Rowe wrote:
> Speaking on behalf of the MultiBit team (Jim's currently on holiday), we
> will not be supporting Tonal Bitcoins anytime soon. Therefore we back the
> BIP 21 proposal.
It is not correct to imply that BIP 20 requires Tonal Bitcoin support.
I
Hi all,
Speaking on behalf of the MultiBit team (Jim's currently on holiday), we
will not be supporting Tonal Bitcoins anytime soon. Therefore we back the
BIP 21 proposal.
At present MultiBit does not support the "message" or "send" fields but we
would be happy to add this functionality as requir
On Monday, January 30, 2012 1:07:16 PM thoma...@gmx.de wrote:
> I too support BIP21 over BIP20.
BIP 21 is not forwards-compatible, and is intentionally designed to be biased
toward decimal. BIP 20 is neutrally biased, forward-compatible, and has been
implemented for over a year now. If BIP 20 is
I too support BIP21 over BIP20. However, I do not understand the "Sending money
via private key" feature; in which situation would such a URI be useful?
Also, I posted a proposal in the forum, to extend the URI syntax with
signatures. The goal would be to provide a proof of identity of the recip
I agree with BIP 0021
Wladimir
On Mon, Jan 30, 2012 at 12:55 AM, Amir Taaki wrote:
> Matt Corallo posted a modification of BIP 20 in an earlier email and I
> asked him if he wanted to become the champion of that BIP he submitted.
>
> It is a modification of BIP 20 sans the alternative non-decim
Matt Corallo posted a modification of BIP 20 in an earlier email and I asked
him if he wanted to become the champion of that BIP he submitted.
It is a modification of BIP 20 sans the alternative non-decimal number stuff.
https://en.bitcoin.it/wiki/BIP_0021
Right now, I will ask the GUI client
19 matches
Mail list logo
