MIME-Version: 1.0
In-Reply-To: <CABm2gDrickFojwmUi7GqAhSW5K0yTa_59VjKrY+wAXEq1MYUoA@mail.gmail.com>
References: <CAPswA9w5Sgg6AV=9Pqx5sqbkdrwv9LmwoxmMu7xZsQSNXtmZnQ@mail.gmail.com>
	<CAPg+sBjtovFpLoibpVGLsNJXexBcoiYzjrvctraXntCUZBJsGg@mail.gmail.com>
	<CAPswA9zhB4GV=JJ28RRLFNrkVwExUv36zujmuAjwPd6rG6rvzQ@mail.gmail.com>
	<CALJP9GCBJiofY7k2RJ460CuLuWQunHcx7EcLi1-d07v76Y-E2g@mail.gmail.com>
	<CAPswA9wqdbU0z8ydBt+9M0iQX0VSi1ce=dg3fR2_2bx3-vEqzA@mail.gmail.com>
	<CAPswA9z_xKY6v9=Ejh=01mZN0QCVo1e0RY1FTzXzS39i3tjgAw@mail.gmail.com>
	<CAPswA9xk5QYAXxQ6ES3cnNPeB1FTiiSJgLahLEkSk4CLpoM_QQ@mail.gmail.com>
	<CAPg+sBiWykR6RaHhbyYQbL=A5t1TmHgEmS_sC7jj9d3SUTMO9g@mail.gmail.com>
	<CAPswA9zycU0pwZKaHU9J3Tvg=ovLJ8TZ9OH6ebTPONaRaiOE8g@mail.gmail.com>
	<CAPg+sBhuth22+vAHyS2iwpze8X=-b2wJQ5s1z2FhZ1jsLXobgQ@mail.gmail.com>
	<CAPswA9yB3wfV1auXR=ggXjh+f1C3Qpkv8qP1miQwkc8R2_aBLg@mail.gmail.com>
	<CAPg+sBjp-BmSXhanOuKE0DN1wdfVwCtFwiAbPse1GLxy3+L3nA@mail.gmail.com>
	<CAPswA9zzKvh6G+NqzTmhrNXMSWOPtZ2DGW2t_2Jrisy8x9m2qw@mail.gmail.com>
	<CAPg+sBhZCayaxNg_thO=nzxvuo-xZ-ZeZMXEVWb6Mw2POreOZQ@mail.gmail.com>
	<CAPswA9yFUAqFyNBFBnnwpT=B9RcdNssdjz-_KWbX5GuLM5Uyxw@mail.gmail.com>
	<CAPg+sBigK7K2YVnhcU5Ysf0d0Gbp+GaNdGoKZCco5zvYLKDxFw@mail.gmail.com>
	<CAPswA9wLDpf0Q3aL=a+uaqkFecPgC4ASj73XVfj=MOrof-yh1g@mail.gmail.com>
	<CABm2gDrickFojwmUi7GqAhSW5K0yTa_59VjKrY+wAXEq1MYUoA@mail.gmail.com>
Date: Sun, 26 Jul 2015 23:13:49 +0200
Message-ID: <CAPswA9yYOzehfd=UxV+EmNOSZnY9nif2Y1GZ_FEy7r5UdzGA0g@mail.gmail.com>
From: Kalle Rosenbaum <kalle@rosenbaum.se>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Bitcoin-development] BIP for Proof of Payment
Precedence: list

(Resending to the new bitcoin-dev list after sending to the old list)

2015-07-25 21:34 GMT+02:00 Jorge Tim=C3=B3n <jtimon@jtimon.cc>:
> Then why do you assume they have a policy limit that not even bitcoin cor=
e
> itself maintains (the default limit was moved from 42 to 83 [counting the
> op_return and pushes])?
>
> The policy check is not a consensus rule. Other implementations may have
> another default or not have a limit at all.

Thank you for pointing this out.

That's right. Bitcoin core now support 80 bytes data by default. And
yes, I was wrong in assuming 40 bytes policy in all implementations,
even if 40 bytes was the limit in bitcoin core at the time of writing
the BIP.

If there's a need to increase the size of the nonce, for example to
128 bits instead of the 48 bits as designed in BIP 120, then we can of
course do that, either now or in a subsequent version of PoP.

As noted before though, a longer nonce also means bigger QR codes
generated from the BIP 121 URIs. So I think that 48 bits is a good
tradeoff right now. And as stated in BIP120, a server generating PoP
requests should try to detect brute force attacks, or at least delay
the response (containing the nonce) by some 100 ms or so.

Do you think we need a bigger nonce? In that case, why?

If PoP later becomes an extension of BIP70, then there is no such size
constraint on the nonce, since it will be part of some kind of (e.g.)
PopRequest message and not contained in a QR encoded URI.

/Kalle