ta of a repeated field as input, clients
that expect this field to be |optional| will take the
last input value if it's a primitive type field or merge
all input elements if it's a message type field."
Your comments and suggestions would b
Hello Mike,
Thanks for the feedback. I have indicated some replies below...
Andy Schroder
On 10/20/2014 08:50 AM, Mike Hearn wrote:
Hey Andy,
Thanks for starting this discussion!
One thing this brings up is the never-resolved issue of whether BIPs
should document how we'd /like/ thin
oticed
that micropayment channels have little formality to being established
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
ng
the payment request data. How much power is going to be used for just a
few second payment? It's not like the bluetooth connection is maintained
for a long time like it may be in other non bitcoin use cases.
Where is a more appropriate place to discuss the other issues you have
at l
ttps over a bluetooth
socket. There was some criticism of this, but I don't think it has been
tested to know if it is really a problem or not. If we just run https
over bluetooth, then a lot of my concerns about the message header
inconsistencies will go away and the connection will al
Andy Schroder
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
data transferred.
Yes, this should be a prerequ
Andy Schroder
On 02/22/2015 05:48 PM, Eric Voskuil wrote:
One correction inline below.
e
On 02/22/2015 02:39 PM, Eric Voskuil wrote:
Hi Jan,
This is really nice work.
WRT the Schroder and Schildbach proposal, the generalization of the "r"
and "payment_url" paramete
ze if there is something
rudimentary that I am missing here.
Andy Schroder
On 02/22/2015 08:02 PM, Andreas Schildbach wrote:
On 02/23/2015 12:32 AM, Andy Schroder wrote:
I guess we need to decide whether we want to consider NFC communication
private or not. I don't know that I think it can b
over NFC has to
be better than a unique session key. It adds one more step, but seems to
help. If we do this, can we then safely get rid of the h= parameter?
That should make Mike Hearn happy, and also may alleviate the base64url
debate?
Andy Schroder
On 02/23/2015 09:55 PM, Eric
Andy Schroder
On 02/23/2015 10:09 AM, Jan Vornberger wrote:
Hey!
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?
It do
wallet can still maintain backwards compatibility.
Andy Schroder
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
payee.
This would be the
rs based on the public key they are
encrypting the data with. Is this approach feasible?
* When 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?
Andy Schroder
On 02/24/2015 06:28 AM, Eric Vosku
. See
other e-mails now 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 "Ses
limit spam.
Any thoughts?
Andy Schroder
On 06/10/2015 05:35 AM, Wladimir J. van der Laan wrote:
> On Wed, Jun 10, 2015 at 10:25:12AM +0200, xor wrote:
>> http://www.howtogeek.com/218764/warning-don%E2%80%99t-download-software-from-sourceforge-if-you-can-help-it/
> All our downloa
n idea what the load
may be. I've been told there are about 1,200 subscribers.
http://dir.gmane.org/gmane.comp.bitcoin.devel
Andy Schroder
On 06/10/2015 02:02 PM, Troy Benjegerdes wrote:
I'll sponsor it, if we agree to implement a HashCash spam filter
in the next 6 months. I'v
gital signatures are always broken on messages because
the list server slightly modifies them (?), so my e-mail client
doesn't verify them all.
Andy Schroder
On 06/10/2015 02:36 PM, s7r wrote:
The mail list is public, so it's not like the data on it is somehow
sensitive. Sourcefoge is
Andy Schroder
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 (?), so my e-mail client
doesn't verify them all.
What type of digital signatures specifically? What email c
Andy Schroder
On 06/10/2015 03:20 PM, Peter Todd wrote:
On Wed, Jun 10, 2015 at 03:12:02PM -0400, Andy Schroder wrote:
Andy Schroder
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
non plain text data.
Andy Schroder
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
then receivin
art of the migration plan, but I guess is
this easy to do from SourceForge?
Andy Schroder
On 06/14/2015 06:12 AM, Warren Togami Jr. wrote:
Discomfort with Sourceforge
For a while now people have been expressing concern about
Sourceforge's continued hosting of the bitcoin-dev mailing
Andy Schroder
On 06/14/2015 11:19 PM, Warren Togami Jr. wrote:
On Sun, Jun 14, 2015 at 5:15 AM, Jeff Garzik <mailto:jgar...@bitpay.com>> wrote:
* ACK on moving away from SourceForge mailing lists - though only
once a community-welcomed replacement is up and running
* ACK
21 matches
Mail list logo
