[Bitcoin-development] BIP 21 (modification BIP 20)

[Bitcoin-development] BIP 21 (modification BIP 20)

[Amir Taaki]

[-- Attachment #1: Type: text/plain, Size: 580 bytes --]

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 implementations like MultiBit or Bitcoin-Qt, not different codebases like BitCoinJ or libbitcoin if they support BIP 20 or BIP 21. Feel free to raise any objections.

More weight will be given to GUIs with actual URI scheme implementations and it's good to have a general consensus.

[-- Attachment #2: Type: text/html, Size: 887 bytes --]

Re: [Bitcoin-development] BIP 21 (modification BIP 20)

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

I agree with BIP 0021

Wladimir

On Mon, Jan 30, 2012 at 12:55 AM, Amir Taaki <zgenjix@yahoo.com> 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-decimal number
> stuff.
>
> https://en.bitcoin.it/wiki/BIP_0021
>
> Right now, I will ask the GUI client implementations like MultiBit or
> Bitcoin-Qt, not different codebases like BitCoinJ or libbitcoin if they
> support BIP 20 or BIP 21. Feel free to raise any objections.
>
> More weight will be given to GUIs with actual URI scheme implementations
> and it's good to have a general consensus.
>
>
> ------------------------------------------------------------------------------
> 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: 2051 bytes --]

Re: [Bitcoin-development] BIP 21 (modification BIP 20)

[Andreas Schildbach]

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 an ";" parameter rather than
a normal "&" parameter?


On 01/30/2012 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-decimal number
> stuff.
> 
> https://en.bitcoin.it/wiki/BIP_0021
> 
> Right now, I will ask the GUI client implementations like MultiBit or
> Bitcoin-Qt, not different codebases like BitCoinJ or libbitcoin if they
> support BIP 20 or BIP 21. Feel free to raise any objections.
> 
> More weight will be given to GUIs with actual URI sche me
> implementations and it's good to have a general consensus.
> 
> 
> ------------------------------------------------------------------------------
> 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

Re: [Bitcoin-development] BIP 21 (modification BIP 20)

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 3091 bytes --]

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 should
be forwards-compatible (as Luke-Jr says) in the sense that older clients
can detect schemes they don't understand and give the user an appropriate
error message.

Maybe we need a send-type parameter to define the scheme?

Good point on the version parameter. How are clients supposed to handle
this? Refuse to handle the request if their URL scheme parser version is
older than in the URL? This should be in the BIP.

Wladimir

On Tue, Jan 31, 2012 at 9:23 AM, Andreas Schildbach
<andreas@schildbach.de>wrote:

> 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 an ";" parameter rather than
> a normal "&" parameter?
>
>
> On 01/30/2012 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-decimal number
> > stuff.
> >
> > https://en.bitcoin.it/wiki/BIP_0021
> >
> > Right now, I will ask the GUI client implementations like MultiBit or
> > Bitcoin-Qt, not different codebases like BitCoinJ or libbitcoin if they
> > support BIP 20 or BIP 21. Feel free to raise any objections.
> >
> > More weight will be given to GUIs with actual URI sche me
> > implementations and it's good to have a general consensus.
> >
> >
> >
> ------------------------------------------------------------------------------
> > 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
>
>
>
>
> ------------------------------------------------------------------------------
> 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: 4409 bytes --]

Re: [Bitcoin-development] BIP 21 (modification BIP 20)

[Gary Rowe]

[-- Attachment #1: Type: text/plain, Size: 5447 bytes --]

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
or timestamp).

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 field is to limit risk against currency movement (immediate cash
out) or inventory movement (time limited offer). I have difficulty seeing a
good use case that would need a block. People have been co-ordinating
events based on a UTC timestamp for decades and I think we should stick
with it.

Regarding the "version" field I again think it adds unnecessary complexity.
Pretty much everything that is needed within the Bitcoin URI scheme can be
encoded with suitable optional fields (as query params) making the whole
structure forward compatible. Having a version field seems redundant.

Finally, the URI signing mechanism. Apologies for the earlier
misunderstanding, I was reading from a limited description and it didn't
make the purpose clear. I've since used
https://bitcointalk.org/index.php?topic=58534.msg689190#msg689190 as my
reference which is a lot clearer. I think it's a good idea, and I'll
definitely support it in my MulitBit Merchant project, but it currently
seems to need more work so I think should be deferred into a dedicated BIP.

On 31 January 2012 08:35, Wladimir <laanwj@gmail.com> wrote:

>
> 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 should
> be forwards-compatible (as Luke-Jr says) in the sense that older clients
> can detect schemes they don't understand and give the user an appropriate
> error message.
>
> Maybe we need a send-type parameter to define the scheme?
>
> Good point on the version parameter. How are clients supposed to handle
> this? Refuse to handle the request if their URL scheme parser version is
> older than in the URL? This should be in the BIP.
>
> Wladimir
>
> On Tue, Jan 31, 2012 at 9:23 AM, Andreas Schildbach <andreas@schildbach.de
> > wrote:
>
>> 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 an ";" parameter rather than
>> a normal "&" parameter?
>>
>>
>> On 01/30/2012 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-decimal number
>> > stuff.
>> >
>> > https://en.bitcoin.it/wiki/BIP_0021
>> >
>> > Right now, I will ask the GUI client implementations like MultiBit or
>> > Bitcoin-Qt, not different codebases like BitCoinJ or libbitcoin if they
>> > support BIP 20 or BIP 21. Feel free to raise any objections.
>> >
>> > More weight will be given to GUIs with actual URI sche me
>> > implementations and it's good to have a general consensus.
>> >
>> >
>> >
>> ------------------------------------------------------------------------------
>> > 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
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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: 7461 bytes --]

Re: [Bitcoin-development] BIP 21 (modification BIP 20)

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 6902 bytes --]

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, such as "expires"
is added later on, it is pretty important not to ignore it. Older clients
should refuse to comply.)

URL signing should indeed be addressed in a separate BIP and be an
extension mechanism, IMO.

"expires" and "message" could go into BIP 21 one as they're easy to
implement and don't need much discussion.

Wladimir

On Tue, Jan 31, 2012 at 11:01 AM, Gary Rowe <g.rowe@froot.co.uk> wrote:

> 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
> or timestamp).
>
> 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 field is to limit risk against currency movement (immediate cash
> out) or inventory movement (time limited offer). I have difficulty seeing a
> good use case that would need a block. People have been co-ordinating
> events based on a UTC timestamp for decades and I think we should stick
> with it.
>
> Regarding the "version" field I again think it adds unnecessary
> complexity. Pretty much everything that is needed within the Bitcoin URI
> scheme can be encoded with suitable optional fields (as query params)
> making the whole structure forward compatible. Having a version field seems
> redundant.
>
> Finally, the URI signing mechanism. Apologies for the earlier
> misunderstanding, I was reading from a limited description and it didn't
> make the purpose clear. I've since used
> https://bitcointalk.org/index.php?topic=58534.msg689190#msg689190 as my
> reference which is a lot clearer. I think it's a good idea, and I'll
> definitely support it in my MulitBit Merchant project, but it currently
> seems to need more work so I think should be deferred into a dedicated BIP.
>
> On 31 January 2012 08:35, Wladimir <laanwj@gmail.com> wrote:
>
>>
>> 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 should
>> be forwards-compatible (as Luke-Jr says) in the sense that older clients
>> can detect schemes they don't understand and give the user an appropriate
>> error message.
>>
>> Maybe we need a send-type parameter to define the scheme?
>>
>> Good point on the version parameter. How are clients supposed to handle
>> this? Refuse to handle the request if their URL scheme parser version is
>> older than in the URL? This should be in the BIP.
>>
>> Wladimir
>>
>> On Tue, Jan 31, 2012 at 9:23 AM, Andreas Schildbach <
>> andreas@schildbach.de> wrote:
>>
>>> 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 an ";" parameter rather than
>>> a normal "&" parameter?
>>>
>>>
>>> On 01/30/2012 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-decimal number
>>> > stuff.
>>> >
>>> > https://en.bitcoin.it/wiki/BIP_0021
>>> >
>>> > Right now, I will ask the GUI client implementations like MultiBit or
>>> > Bitcoin-Qt, not different codebases like BitCoinJ or libbitcoin if they
>>> > support BIP 20 or BIP 21. Feel free to raise any objections.
>>> >
>>> > More weight will be given to GUIs with actual URI sche me
>>> > implementations and it's good to have a general consensus.
>>> >
>>> >
>>> >
>>> ------------------------------------------------------------------------------
>>> > 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
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>
>>
>
>
> ------------------------------------------------------------------------------
> 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: 9506 bytes --]

Re: [Bitcoin-development] BIP 21 (modification BIP 20)

[Andreas Schildbach]

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 standard that unknown URL parameters are simply ignored. I
think we should not change this principle.

> (For example, if something that restricts the validity, such
> as "expires" is added later on, it is pretty important not to ignore it.
> Older clients should refuse to comply.)

In this case, you'd need to refuse *all* parameters you don't know
about. In consequence, all extensions would break older clients.

Re: [Bitcoin-development] BIP 21 (modification BIP 20)

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

>
> 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 changes impossible.

Whatever will be defined in the BIP is the standard in this case.


> > (For example, if something that restricts the validity, such
> > as "expires" is added later on, it is pretty important not to ignore it.
> > Older clients should refuse to comply.)
>
> In this case, you'd need to refuse *all* parameters you don't know
> about. In consequence, all extensions would break older clients.
>

Which is exactly what I want to avoid by defining this up-front.

A versioning scheme can avoid this. Any BIP that breaks backwards
compatibility (for example, adds a multiple-send type or specific
restriction) should increase the version number. A client rejects URLs with
a version number higher than what it knows about.

That's the simplest way to handle it, and enough IMO.

Wladimir

[-- Attachment #2: Type: text/html, Size: 1652 bytes --]

Re: [Bitcoin-development] BIP 21 (modification BIP 20)

[Pieter Wuille]

On Tue, Jan 31, 2012 at 10:01:00AM +0000, 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 field is to limit risk against currency movement (immediate cash
> out) or inventory movement (time limited offer). I have difficulty seeing a
> good use case that would need a block. People have been co-ordinating
> events based on a UTC timestamp for decades and I think we should stick
> with it.

For merchant purposes, I believe URI's containing a static pubkeyhash-address
are only a temporary solution until more elaborate solutions that deal with
all concerns appear (tagging transactions, feedback to the merchant, making
the receiver responsible for inclusion, certificates that a payment was
accepted, authentication, ...). I believe static addresses are too limited
for this purpose, and we shouldn't be trying to extend them with too many
features.

There have been discussions about more dynamic approaches (such as HTTP
communication to negotiate an address) here, and I've written my own
proposal as well (https://gist.github.com/1237788). The details are not
really relevant at this time, but these dynamic approaches seem a much
better way of dealing with what you're trying to add to the bitcoin URI
system now.

My 2 cents: keep bitcoin URI's simple for now.

-- 
Pieter

Re: [Bitcoin-development] BIP 21 (modification BIP 20)

[thomasV1]

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 recipient; genjix told me that it would be more appropriate to post that here.

My proposal is described here: http://ecdsa.org/bitcoin_URIs.html

My original forum post is here: https://bitcointalk.org/index.php?topic=58534.msg689190#msg689190

-- 
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 21 (modification BIP 20)

[Luke-Jr]

On Monday, January 30, 2012 1:07:16 PM thomasV1@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 to be Superceded, a proposal 
should improve on it, not make it worse with bigotry and short-sightedness.

[Bitcoin-development] BIP 21 (modification BIP 20)

[Gary Rowe]

[-- Attachment #1: Type: text/plain, Size: 1758 bytes --]

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

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 (at MultiBit we were concerned that a
Bitcoin "swatch" would be subjected to the same attack vector and we came
up with the term "swatch swabbing"). If a Bitcoin URI is served up from a
trusted source (e.g. a merchant site over HTTPS) then there is no need for
signing. It should be assumed that the merchant will offer a clean room
payment area so that no untrusted JavaScript will creep into the final page
and wreak havoc.

It would seem that in any situation where the attacker has complete control
over the content of the URI they will be able to successfully swab it to
match their own fraudulent address. Imagine attempting to protect a QR code
posted against a pole attempting to get BTC donations for a charity. How
long before that was replaced by a different version operated by the
thieves with good signatures all round?

Of course, I may have misunderstood so I would welcome further discussion.

One field that the MultiBit team would like to add to the BIP 21 proposal
is "expires" which would contain an ISO8601 formatted date/time in UTC
(e.g. "2000-01-01T23:59:59Z"). This would allow merchants to issue Bitcoin
URIs that would expose them to a currency/inventory risk for a defined
period of time.

Kind regards,

Gary Rowe


PS First post to this list

[-- Attachment #2: Type: text/html, Size: 1902 bytes --]

Re: [Bitcoin-development] BIP 21 (modification BIP 20)

[Luke-Jr]

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.
In fact, the exact opposite is true; it states that even if one unit (eg, TBC) 
would be a more rational way to display a specified amount, clients should 
still interpret it in the way that is deemed to be most intuitive to the user 
(eg, BTC).

Re: [Bitcoin-development] BIP 21 (modification BIP 20)

[Gary Rowe]

[-- Attachment #1: Type: text/plain, Size: 1068 bytes --]

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 representation in decimal notation.

In my view, BIP 21 still wins since it reduces complexity for the end
client both at the human and machine level.

On 30 January 2012 18:56, Luke-Jr <luke@dashjr.org> wrote:

> 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.
> In fact, the exact opposite is true; it states that even if one unit (eg,
> TBC)
> would be a more rational way to display a specified amount, clients should
> still interpret it in the way that is deemed to be most intuitive to the
> user
> (eg, BTC).
>

[-- Attachment #2: Type: text/html, Size: 1405 bytes --]

Re: [Bitcoin-development] BIP 21 (modification BIP 20)

[Luke-Jr]

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, clearly defined, whereas BIP 21 requires the use of a
> single representation in decimal notation.
> 
> In my view, BIP 21 still wins since it reduces complexity for the end
> client both at the human and machine level.

If the goal is to reduce complexity, strtol-compatible amount is the answer ;)

Re: [Bitcoin-development] BIP 21 (modification BIP 20)

[thomasV1]

> 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. Please read the forum.

> If a Bitcoin URI is served up from a
> trusted source (e.g. a merchant site over HTTPS) then there is no need for
> signing. It should be assumed that the merchant will offer a clean room
> payment area so that no untrusted JavaScript will creep into the final
> page
> and wreak havoc.
> 
> It would seem that in any situation where the attacker has complete
> control
> over the content of the URI they will be able to successfully swab it to
> match their own fraudulent address. Imagine attempting to protect a QR
> code
> posted against a pole attempting to get BTC donations for a charity. How
> long before that was replaced by a different version operated by the
> thieves with good signatures all round?
> 
> Of course, I may have misunderstood so I would welcome further discussion.

The bitcoin address that is used to sign URIs will establish the online reputation of the merchant. If a merchant has received a payment and pretends not to have received it, the signed URI will prove him wrong. 

In principle it would be possible to use HTTPS signatures for that purpose, but this is not really the way HTTPS is supposed to work, and it has disadvantages:
- HTTPS is not always available; there are other communication channels.
- A website, even a single page, may contain URIs posted by various merchants; we need to distinguish the identity of the merchant from the identity of the website.
- with signed URIs, a Bitcoin client can easily keep track of the signatures for all the payments it made. if we used the HTTPS signature of the webpage as receipts, then users would need to save them manually. To my knowledge, nobody does that.



> One field that the MultiBit team would like to add to the BIP 21 proposal
> is "expires" which would contain an ISO8601 formatted date/time in UTC
> (e.g. "2000-01-01T23:59:59Z"). This would allow merchants to issue Bitcoin
> URIs that would expose them to a currency/inventory risk for a defined
> period of time.

yes, that too. see my proposal here: https://bitcointalk.org/index.php?topic=60828.0;topicseen

-- 
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 21 (modification BIP 20)

[Gavin Andresen]

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

Re: [Bitcoin-development] BIP 21 (modification BIP 20)

[Cameron Garnham]

[-- Attachment #1.1: Type: text/plain, Size: 509 bytes --]

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 write follow-up BIPs .
> 

If we had a self signed URI, we could just pay directly to the public
key (or calculate the bitcoin address from it).  It
would no longer require a bitcoin address in the URI.

[-- Attachment #1.2: 0x33B5E7D6.asc --]
[-- Type: application/pgp-keys, Size: 2692 bytes --]

[-- Attachment #1.3: 0x33B5E7D6.asc --]
[-- Type: application/pgp-keys, Size: 2690 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 283 bytes --]

Re: [Bitcoin-development] BIP 21 (modification BIP 20)]

[Pieter Wuille]

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