BIP 21 (modification BIP 20)
11 messages, 29 to 31 Jan 2012. Started by Amir Taaki.
Wladimir J. van der Laan (4), Andreas Schildbach (2), Amir Taaki, Thomas Voegtlin, Luke Dashjr, Gary Rowe, Pieter Wuille
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.
I agree with BIP 0021
Wladimir
On Mon, Jan 30, 2012 at 12:55 AM, Amir Taaki <zgenjix@yahoo•com> wrote:
Quoted text (28 lines)
> 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 > >
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
On Monday, January 30, 2012 1:07:16 PM thomasV1@gmx•de wrote:
Quoted text (1 line)
> 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.
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:
Quoted text (29 lines)
> 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
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:
Quoted text (56 lines)
> 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 >
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:
Quoted text (93 lines)
> > 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 > >
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:
Quoted text (139 lines)
> 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 > >
On Tue, Jan 31, 2012 at 10:01:00AM +0000, Gary Rowe wrote:
Quoted text (8 lines)
> 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.
On 01/31/2012 11:22 AM, Wladimir wrote:
Quoted text (5 lines)
> 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.
Quoted text (3 lines)
> (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.
Quoted text (4 lines)
> > 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.
Quoted text (7 lines)
> > (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