On 06/10/2015 03:20 PM, Peter Todd wrote:
On Wed, Jun 10, 2015 at 03:12:02PM -0400, Andy Schroder wrote:
On 06/10/2015 03:03 PM, Peter Todd wrote:
4. Seems like digital signatures are always broken on messages because
the list server slightly modifies them
with non plain text data.
On 06/10/2015 03:43 PM, Peter Todd wrote:
On Wed, Jun 10, 2015 at 03:36:42PM -0400, Andy Schroder wrote:
It's possible that the enigmail extension is not working right, but
I was under the impression that it is just feeding data to gpg and
that the e-mail list finally forwarded them through
the other day.
Now for Eric's e-mail... More below.
On 02/24/2015 09:09 PM, Eric Voskuil wrote:
On 02/24/2015 02:50 PM, Andy Schroder wrote:
We can change resource to Session ID if you want.
I think the URL scheme should
you said a new public key for each tap, do you see that as
every single tap, or do you consider multiple taps from the same
customer the same tap?
On 02/24/2015 06:28 AM, Eric Voskuil wrote:
On 02/23/2015 09:53 PM, Andy Schroder wrote:
I was saying provide a public key via
On 02/23/2015 10:09 AM, Jan Vornberger wrote:
On Sun, Feb 22, 2015 at 05:37:16PM -0500, Andy Schroder wrote:
It's maybe not a bad idea for the wallet to try all payment_url
mechanisms in parallel. Should we add this as a recommendation to
wallets in TBIP75?
On 02/24/2015 05:14 PM, Eric Voskuil wrote:
* Add a s= parameter that uses a unique public key for each session.
This public key identifies the payee to the payer and payer to the
This would be the simple model, which just tacks on another parameter
bluetooth, then a lot of my concerns about the message header
inconsistencies will go away and the connection will also be secure. We
don't have to reinvent anything.
On 02/22/2015 02:08 PM, Jan Vornberger wrote:
I am working on a Bitcoin point of sale terminal based
On 02/22/2015 06:06 PM, Eric Voskuil wrote:
On 02/22/2015 02:37 PM, Andy Schroder wrote:
I'd like to see some discussion too about securing the bluetooth
connection. Right now it is possible for an eavesdropper to monitor the
Yes, this should be a prerequisite
On 02/22/2015 05:48 PM, Eric Voskuil wrote:
One correction inline below.
On 02/22/2015 02:39 PM, Eric Voskuil wrote:
This is really nice work.
WRT the Schroder and Schildbach proposal, the generalization of the r
and payment_url parameters makes sense, with only
practically and it would be awesome if they could be managed over
bluetooth as well. Maybe more improvements to the payment protocol can
simultaneously result (and also extended to bluetooth) that embrace the
establishment of micropayment channels.
On 10/17/2014 03:58 PM
and suggestions would be greatly appreciated.
Description: OpenPGP digital signature
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS
Mail list logo