Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

2014-08-19 Thread J Ross Nicoll
The concern is that if you can monitor traffic in and out of a single
node, you can determine which transactions originate from it vs those
which it relays. That's not great, certainly, but how many nodes
actually require that level of security, and surely they can use Tor or
VPN services if so?

Further, unless the remote nodes are in some way trusted, you're
changing the attack from read-only to requiring the ability to perform 
a man in the middle attack - that doesn't seem much harder to me.

As Gregory states, there's been at least two recent serious if not
catastrophic OpenSSL bugs, and the consequences of Heartbleed if the
Bitcoin network had been vulnerable are the stuff of nightmares.

Very difficult to see the risk/reward payoff being worthwhile.


On 19/08/2014 18:35, Johnathan Corgan wrote:
 On 08/19/2014 09:38 AM, Gregory Maxwell wrote:

 We've dodged several emergency scale vulnerabilities by not having TLS.
 I'm still trying to understand the original premise that we want
 encrypted communications between nodes.

 I can certainly see the value of having *authenticated* traffic with
 specific nodes, using an HMAC for the protocol messages in place of the
 current checksum.


 Bitcoin-development mailing list

Slashdot TV.  
Video for Nerds.  Stuff that matters.
Bitcoin-development mailing list

[Bitcoin-development] Error handling in payment protocol (BIP-0070 and BIP-0072)

2014-04-25 Thread J Ross Nicoll
Dear Gavin, all,

Going over the payment protocol specifications, I've noticed that
there's appears to be a lack of specificity on handling of error states.
In most cases there are reasonably obvious solutions, however it would
seem positive to formalise processes to ensure consistency. I'm
wondering therefore if either you'd be willing to edit the existing BIP,
or advise on whether this is useful to write up as a new BIP?

The main area of concern is handling unexpected problems while sending
the Payment message, or receiving the corresponding PaymentACK message.
For example, in case of a transport layer failure or non-200 HTTP status
code while sending the Payment message, what should the wallet software
do next? Is it safe to re-send the Payment message? I'd propose that for
any transport failure or 500 status code, the client retries after a
delay (suggested at 30-60 seconds). For 400 status codes, the request
should not be repeated, and as such the user should be alerted and a
copy of the Payment message saved to be resent later.

For 300 (redirect and similar) status codes, is it considered safe to
follow redirects? I think we have to, but good to make it clear in the

On the merchant's side; I think it would be useful for there to be
guidance for handling of errors processing Payment messages. I'd suggest
that Payment messages should have a fixed maximum size to avoid merchant
systems theoretically having to accept files of any size; 10MB would
seem far larger than in any way practical, and therefore a good maximum
size? A defined maximum time to wait (to avoid DDoS via connection
holding) might be useful too, although I'd need to do measurements to
find what values are tolerable.

I would like to have the protocol state that merchant systems should
handle repeatedly receiving the same Payment message, and return an
equivalent (if not identical) PaymentACK to each. This is important in
case of a network failure while the client is sending the Payment
message, as outlined above.

Lastly, I'm wondering about potential timing issues with transactions;
if a merchant system wants to see confirmation of a transaction before
sending a PaymentACK, any thoughts on whether it should hold the
connection, or send a PaymentACK with a memo indicating payment has been
seen on the relay network but is not yet confirmed, or something else?

Happy to write this up as a new BIP if that's more appropriate than
editing the original, and please do tell me if I've missed anything
obvious/prior discussion on this topic.


Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
Bitcoin-development mailing list