Andy Schroder [ARCHIVE] on Nostr: 📅 Original date posted:2015-02-05 📝 Original message:Hello, I personally would ...
📅 Original date posted:2015-02-05
📝 Original message:Hello,
I personally would prefer as low of range as possible for this bluetooth
application considering the connection is not yet encrypted (mentioned
below), and even if it were, it seems like it is always going to be
better in case there is some vulnerability. From my testing with a
bluetooth radio inside my metal cabinet, the range is ~5 meters, which
is more than enough.
However, the connection is actually a bit slow when the whole
certificate chain is included (~3-4s). You can sort of see this in my
video (http://youtu.be/kkVAhA75k1Y?t=7m39s). A lot of the time is
actually spent verifying the signature, and I'm not sure how much of it
is doing the fetching (I haven't done any detailed timings using "adb
logcat" and looking at the log entries), but I do know it is a little
slower than an HTTPS payment request fetch over wifi (~2-3s). The reason
I know most of the time is the signature verification is because an
HTTPS payment request fetch over wifi and verification using breadwallet
on apple is much faster (<1s) than HTTPS payment request on bitcoin
wallet on android (apparently apple has a significantly more optimized
signature verification algorithm). Bottom line is that there may be ~1s
time transferring the data with this current bluetooth connection. Not
sure how slow it will be with the BLE connection. Time is everything in
a point of sale application.
So, I guess what I am saying is it seems like the lower speed and range
gain with bluetooth low energy are not a benefit in my opinion. I'm not
sure that the latency gain will be a benefit either unless the speed
issues I am noticing with regular bluetooth are actually a latency issue
with just getting the connection established, or actually transmitting
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 length?
Andy Schroder
On 02/05/2015 07:36 PM, Eric Voskuil wrote:
> Hi Andy,
>
> This is good stuff. I've spent quite a bit of time on this question, but
> set aside most of it earlier in the year in order to make some progress
> in other areas. I did review what I found available at the time
> pertaining to the Schildbach implementation and these questions.
> Skimming the links now I'm encouraged, but I see several things that I'd
> like to discuss at greater length than is appropriate here.
>
> The main advantage of BLE over BT is that it uses much less power, with
> a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can
> be even greater and connection latency lower than BT. For payment
> purposes the lower bandwidth isn't much of a hit.
>
> e
>
> On 02/05/2015 03:38 PM, Andy Schroder wrote:
>> Hello,
>>
>> With the recent discussion started today regarding another bluetooth
>> communication proposal created by Airbitz, I'd like to bring people's
>> attention back to this proposal that saw little discussion last fall. I
>> guess I'm not sure why two proposals are being created. Is their some
>> advantage of using bluetooth low energy over standard bluetooth (I'm not
>> well versed in bluetooth low energy)? This NFC coupled approach seems to
>> avoid a lot of issues with identifying the correct payee. You can see
>> this proposed scheme demonstrated in action in a POS application in the
>> video link below which demonstrates it with my fuel pump and Andreas
>> Schildbach's wallet.
>>
>> There was a small discussion that occurred after my original
>> announcement below. If you are new to this e-mail list, you can find an
>> archive of those few replies here:
>> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html
>>
>> Since this original announcement, a few improvements have been made to
>> the proposal:
>>
>> 1. Improved documentation and explanation of the use cases in
>> Schildbach's wallet's wiki
>> 1. https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests
>> 2. Issue with the payment_url field has resolved by changing to a
>> repeated field and requiring the wallet to search for the protocol
>> they want to use, rather than expecting it to be a certain element
>> number in the list.
>> 1. https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
>>
>>
>> Although there are some interesting use cases of Airbitz's proposal's
>> work flow, tapping an NFC radio with a 5 mm range requires much less
>> brain power and time than picking the correct name on the app's screen.
>> The manual name picking is going to be especially crazy in a very
>> congested location. The payer isn't ever going to want to have to try
>> and figure out what register or payment terminal they are at for most
>> applications I would ever use.
>>
>> I'd like to see something happen with this technology. I've also noticed
>> 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 micropayment channels.
>>
>>
>>
>> Andy Schroder
>>
>> On 10/17/2014 03:58 PM, Andy Schroder wrote:
>>> Hello,
>>>
>>> I'd like to introduce two proposed BIPs. They are primarily focused on
>>> implementing the payment protocol using bluetooth connections. I've
>>> been working on automated point of sale devices and bluetooth
>>> communication is critical in my mind due to the potential lack of
>>> internet access at many points of sale, either due to lack of cellular
>>> internet coverage, lack of payee providing wireless internet, and/or
>>> due to financial constraints of the payer prohibiting them from
>>> maintaining a cellular internet service plan. These BIPs are largely
>>> modeled after the current functionality of Andreas Schildbach's
>>> android Bitcoin Wallet's bluetooth capability. I've discussed the
>>> communication scheme with him in depth and believe these proposals to
>>> clearly and accurately represent the communication scheme.
>>>
>>> There is also an additional &h= parameter added to the bitcoin: URI
>>> scheme which applies to both bluetooth and http payment protocol
>>> requests which allows for a hash of the payment request to be
>>> included. This hash was proposed by Andreas as an amendment to BIP72,
>>> but others preferred not to amend BIP72 since it has already been put
>>> into place. The current version of Schildbach's bitcoin wallet already
>>> supports the "h parameter".
>>>
>>> I'd appreciate feedback from everyone, particularly wallet developers
>>> as widespread bluetooth support among wallets is very important to me.
>>> I'm also very new to this mailing list as well as the BIP writing
>>> process, so I'd appreciate your understanding if my conventions are
>>> not standard. I am currently using the naming conventions "TBIP", so
>>> that I can propose /temporary/ BIP numbers, and cross reference
>>> between the two. Obviously these will change if the BIPs are formally
>>> adopted. You can find a copy of these proposed BIPs at the following
>>> links:
>>>
>>> * https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki
>>> * https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
>>>
>>>
>>> If you are interested, you can see a demonstration of many of the
>>> proposed features using Schildbach's wallet and my fuel pump in a
>>> video I recently created: https://youtu.be/kkVAhA75k1Y . The main
>>> thing not implemented is multiple URLs for the payment protocol, so,
>>> as a hack, I'm just presenting https vi QR code and bluetooth via NFC
>>> on my fuel pump for now.
>>>
>>>
>>>
>>> There are a few known issues that could be improved to this bluetooth
>>> communication scheme as well as the general payment protocol and
>>> myself and Andreas would like to receive feedback regarding concerns
>>> and potential solutions. Some of the known issues are:
>>>
>>> * There may seem to be some inconsistency in the connection header
>>> messages between the payment request connection and the payment
>>> connection. This is largely because it is how Andreas originally
>>> implemented the communication and is hesitant to change it since
>>> there are many instances of is software already deployed that
>>> implement this scheme.
>>> * The current method uses an unauthenticated bluetooth connection
>>> for bluetooth 2.1 and newer devices (subject to man in the middle
>>> attacks, but not passive eavesdroppers), and an unsecure and
>>> unauthenticated connection for older devices. The known concerns
>>> here are that someone within 100 meters of the payer could track
>>> the bitcoin addresses used for the transaction and could possibly
>>> replace the refund address by submitting a forged payment message
>>> to the payee. Requiring bluetooth 2.1 and authenticating the
>>> connection out of band unfortunately don't seem to be as
>>> straightforward/simple of a task with most bluetooth libraries
>>> (although I'd love for someone to prove me wrong). It's possible
>>> this communication scheme could be extended to use an https "like"
>>> protocol that would not care if the underlying bluetooth
>>> connection is authenticated or encrypted. It's actually possible
>>> that http over a bluetooth socket (instead of tcp socket) could be
>>> implemented, however it is presently uncertain whether this would
>>> be too slow, too much overhead (both on the devices software and
>>> communication), or if http could easily be run over bluetooth
>>> sockets on all platforms.
>>> * There is no acknowledgement failure message possible in the
>>> payment protocol, only an acknowledgement message or lack of
>>> acknowledgement message. This issue seems to be a concern and as a
>>> result, the memo field is used to send an "ack" or "nack" in
>>> Schildbach's wallet. Can we add a boolean status field to the
>>> payment acknowledgement message?
>>> * I'd personally like a new optional boolean field added to the
>>> "PaymentDetails" portion of the "PaymentRequest" to allow for the
>>> payer's wallet to match the "Output" optional "amount" fields as a
>>> total amount of all Outputs, rather than requiring the amount for
>>> each output to be matched exactly. As it currently is, the payee
>>> can specify multiple receiving addresses in order to require a
>>> payer split up the payments so that when the payee then goes to
>>> spend the funds later, they don't necessarily have to give their
>>> payees as much knowledge of their balances and spending and
>>> receiving habits and sources. As the payment protocol currently is
>>> requiring all output amounts to be matched exactly for each
>>> output, there is no flexibility given to the payer in order to
>>> reduce a merging or unnecessary diverging of account funds, which
>>> can reduce the privacy of both the payer and the payee. If the
>>> payee were given the option to allow the payer the option to
>>> divide the amounts amount the outputs intelligently, there can be
>>> some privacy gained.
>>> * Amount of data stored in QR codes may be getting large when a
>>> backwards compatible URL is used (for wallets that don't support
>>> the payment protocol) and can be difficult to scan with outdoor
>>> screens that have an extra weather resistant pane when in direct
>>> sunlight.
>>> * The number of offline transactions of a wallet is limited to the
>>> known unspent outputs when they go offline. Long term, I'd like to
>>> see wallet devices that can use systems such as Kryptoradio's
>>> DVB-T based broadcast (but this will need yet another radio!).
>>> Another project may be to develop a blockchain query protocol of
>>> some kind where retailers can provide access to blockchain data so
>>> that customer's wallets can update their known unspent outputs via
>>> bluetooth. It's possible such a bluetooth system could be used in
>>> combination of "Kryptoradio" like broadcasts to provide multiple
>>> blockchain references.
>>> * The additional payment_url approach is a bit sloppy of a solution
>>> in the PaymentDetails portion of the PaymentRequest. It would have
>>> been ideal to just change this from an optional field to a
>>> repeated field, however, the backwards compatibility in the
>>> protocol buffer format will provide the last item in the array for
>>> a repeated field (to a code that expects it to be an optional
>>> field), rather than the first. Because of this, backwards
>>> compatibility with https payment requests wouldn't work if the
>>> payment_url field is just changed to a repeated field.
>>> o Possible alternatives to what is described in the proposed BIP
>>> + Change payment_url to a repeated field and then reverse
>>> the order of the parameter numbers in the payment_url,
>>> compared to the bitcoin URL "r parameter".
>>> + Create an additional, new payment_url_multi repeated field
>>> (or some better name), and then leave the original
>>> payment_url field in there for backwards compatibility
>>> (and then maybe phase it out in the future).
>>> o Reference
>>> + https://developers.google.com/protocol-buffers/docs/proto#updating
>>> # "|optional| is compatible with |repeated|. Given
>>> serialized data 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 be greatly appreciated.
>>>
>>> --
>>> Andy Schroder
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/71578b57/attachment.sig>;
📝 Original message:Hello,
I personally would prefer as low of range as possible for this bluetooth
application considering the connection is not yet encrypted (mentioned
below), and even if it were, it seems like it is always going to be
better in case there is some vulnerability. From my testing with a
bluetooth radio inside my metal cabinet, the range is ~5 meters, which
is more than enough.
However, the connection is actually a bit slow when the whole
certificate chain is included (~3-4s). You can sort of see this in my
video (http://youtu.be/kkVAhA75k1Y?t=7m39s). A lot of the time is
actually spent verifying the signature, and I'm not sure how much of it
is doing the fetching (I haven't done any detailed timings using "adb
logcat" and looking at the log entries), but I do know it is a little
slower than an HTTPS payment request fetch over wifi (~2-3s). The reason
I know most of the time is the signature verification is because an
HTTPS payment request fetch over wifi and verification using breadwallet
on apple is much faster (<1s) than HTTPS payment request on bitcoin
wallet on android (apparently apple has a significantly more optimized
signature verification algorithm). Bottom line is that there may be ~1s
time transferring the data with this current bluetooth connection. Not
sure how slow it will be with the BLE connection. Time is everything in
a point of sale application.
So, I guess what I am saying is it seems like the lower speed and range
gain with bluetooth low energy are not a benefit in my opinion. I'm not
sure that the latency gain will be a benefit either unless the speed
issues I am noticing with regular bluetooth are actually a latency issue
with just getting the connection established, or actually transmitting
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 length?
Andy Schroder
On 02/05/2015 07:36 PM, Eric Voskuil wrote:
> Hi Andy,
>
> This is good stuff. I've spent quite a bit of time on this question, but
> set aside most of it earlier in the year in order to make some progress
> in other areas. I did review what I found available at the time
> pertaining to the Schildbach implementation and these questions.
> Skimming the links now I'm encouraged, but I see several things that I'd
> like to discuss at greater length than is appropriate here.
>
> The main advantage of BLE over BT is that it uses much less power, with
> a trade-off in lower bandwidth (100 kbps vs. 2 mbps). The BLE range can
> be even greater and connection latency lower than BT. For payment
> purposes the lower bandwidth isn't much of a hit.
>
> e
>
> On 02/05/2015 03:38 PM, Andy Schroder wrote:
>> Hello,
>>
>> With the recent discussion started today regarding another bluetooth
>> communication proposal created by Airbitz, I'd like to bring people's
>> attention back to this proposal that saw little discussion last fall. I
>> guess I'm not sure why two proposals are being created. Is their some
>> advantage of using bluetooth low energy over standard bluetooth (I'm not
>> well versed in bluetooth low energy)? This NFC coupled approach seems to
>> avoid a lot of issues with identifying the correct payee. You can see
>> this proposed scheme demonstrated in action in a POS application in the
>> video link below which demonstrates it with my fuel pump and Andreas
>> Schildbach's wallet.
>>
>> There was a small discussion that occurred after my original
>> announcement below. If you are new to this e-mail list, you can find an
>> archive of those few replies here:
>> https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg06354.html
>>
>> Since this original announcement, a few improvements have been made to
>> the proposal:
>>
>> 1. Improved documentation and explanation of the use cases in
>> Schildbach's wallet's wiki
>> 1. https://github.com/schildbach/bitcoin-wallet/wiki/Payment-Requests
>> 2. Issue with the payment_url field has resolved by changing to a
>> repeated field and requiring the wallet to search for the protocol
>> they want to use, rather than expecting it to be a certain element
>> number in the list.
>> 1. https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
>>
>>
>> Although there are some interesting use cases of Airbitz's proposal's
>> work flow, tapping an NFC radio with a 5 mm range requires much less
>> brain power and time than picking the correct name on the app's screen.
>> The manual name picking is going to be especially crazy in a very
>> congested location. The payer isn't ever going to want to have to try
>> and figure out what register or payment terminal they are at for most
>> applications I would ever use.
>>
>> I'd like to see something happen with this technology. I've also noticed
>> 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 micropayment channels.
>>
>>
>>
>> Andy Schroder
>>
>> On 10/17/2014 03:58 PM, Andy Schroder wrote:
>>> Hello,
>>>
>>> I'd like to introduce two proposed BIPs. They are primarily focused on
>>> implementing the payment protocol using bluetooth connections. I've
>>> been working on automated point of sale devices and bluetooth
>>> communication is critical in my mind due to the potential lack of
>>> internet access at many points of sale, either due to lack of cellular
>>> internet coverage, lack of payee providing wireless internet, and/or
>>> due to financial constraints of the payer prohibiting them from
>>> maintaining a cellular internet service plan. These BIPs are largely
>>> modeled after the current functionality of Andreas Schildbach's
>>> android Bitcoin Wallet's bluetooth capability. I've discussed the
>>> communication scheme with him in depth and believe these proposals to
>>> clearly and accurately represent the communication scheme.
>>>
>>> There is also an additional &h= parameter added to the bitcoin: URI
>>> scheme which applies to both bluetooth and http payment protocol
>>> requests which allows for a hash of the payment request to be
>>> included. This hash was proposed by Andreas as an amendment to BIP72,
>>> but others preferred not to amend BIP72 since it has already been put
>>> into place. The current version of Schildbach's bitcoin wallet already
>>> supports the "h parameter".
>>>
>>> I'd appreciate feedback from everyone, particularly wallet developers
>>> as widespread bluetooth support among wallets is very important to me.
>>> I'm also very new to this mailing list as well as the BIP writing
>>> process, so I'd appreciate your understanding if my conventions are
>>> not standard. I am currently using the naming conventions "TBIP", so
>>> that I can propose /temporary/ BIP numbers, and cross reference
>>> between the two. Obviously these will change if the BIPs are formally
>>> adopted. You can find a copy of these proposed BIPs at the following
>>> links:
>>>
>>> * https://github.com/AndySchroder/bips/blob/master/tbip-0074.mediawiki
>>> * https://github.com/AndySchroder/bips/blob/master/tbip-0075.mediawiki
>>>
>>>
>>> If you are interested, you can see a demonstration of many of the
>>> proposed features using Schildbach's wallet and my fuel pump in a
>>> video I recently created: https://youtu.be/kkVAhA75k1Y . The main
>>> thing not implemented is multiple URLs for the payment protocol, so,
>>> as a hack, I'm just presenting https vi QR code and bluetooth via NFC
>>> on my fuel pump for now.
>>>
>>>
>>>
>>> There are a few known issues that could be improved to this bluetooth
>>> communication scheme as well as the general payment protocol and
>>> myself and Andreas would like to receive feedback regarding concerns
>>> and potential solutions. Some of the known issues are:
>>>
>>> * There may seem to be some inconsistency in the connection header
>>> messages between the payment request connection and the payment
>>> connection. This is largely because it is how Andreas originally
>>> implemented the communication and is hesitant to change it since
>>> there are many instances of is software already deployed that
>>> implement this scheme.
>>> * The current method uses an unauthenticated bluetooth connection
>>> for bluetooth 2.1 and newer devices (subject to man in the middle
>>> attacks, but not passive eavesdroppers), and an unsecure and
>>> unauthenticated connection for older devices. The known concerns
>>> here are that someone within 100 meters of the payer could track
>>> the bitcoin addresses used for the transaction and could possibly
>>> replace the refund address by submitting a forged payment message
>>> to the payee. Requiring bluetooth 2.1 and authenticating the
>>> connection out of band unfortunately don't seem to be as
>>> straightforward/simple of a task with most bluetooth libraries
>>> (although I'd love for someone to prove me wrong). It's possible
>>> this communication scheme could be extended to use an https "like"
>>> protocol that would not care if the underlying bluetooth
>>> connection is authenticated or encrypted. It's actually possible
>>> that http over a bluetooth socket (instead of tcp socket) could be
>>> implemented, however it is presently uncertain whether this would
>>> be too slow, too much overhead (both on the devices software and
>>> communication), or if http could easily be run over bluetooth
>>> sockets on all platforms.
>>> * There is no acknowledgement failure message possible in the
>>> payment protocol, only an acknowledgement message or lack of
>>> acknowledgement message. This issue seems to be a concern and as a
>>> result, the memo field is used to send an "ack" or "nack" in
>>> Schildbach's wallet. Can we add a boolean status field to the
>>> payment acknowledgement message?
>>> * I'd personally like a new optional boolean field added to the
>>> "PaymentDetails" portion of the "PaymentRequest" to allow for the
>>> payer's wallet to match the "Output" optional "amount" fields as a
>>> total amount of all Outputs, rather than requiring the amount for
>>> each output to be matched exactly. As it currently is, the payee
>>> can specify multiple receiving addresses in order to require a
>>> payer split up the payments so that when the payee then goes to
>>> spend the funds later, they don't necessarily have to give their
>>> payees as much knowledge of their balances and spending and
>>> receiving habits and sources. As the payment protocol currently is
>>> requiring all output amounts to be matched exactly for each
>>> output, there is no flexibility given to the payer in order to
>>> reduce a merging or unnecessary diverging of account funds, which
>>> can reduce the privacy of both the payer and the payee. If the
>>> payee were given the option to allow the payer the option to
>>> divide the amounts amount the outputs intelligently, there can be
>>> some privacy gained.
>>> * Amount of data stored in QR codes may be getting large when a
>>> backwards compatible URL is used (for wallets that don't support
>>> the payment protocol) and can be difficult to scan with outdoor
>>> screens that have an extra weather resistant pane when in direct
>>> sunlight.
>>> * The number of offline transactions of a wallet is limited to the
>>> known unspent outputs when they go offline. Long term, I'd like to
>>> see wallet devices that can use systems such as Kryptoradio's
>>> DVB-T based broadcast (but this will need yet another radio!).
>>> Another project may be to develop a blockchain query protocol of
>>> some kind where retailers can provide access to blockchain data so
>>> that customer's wallets can update their known unspent outputs via
>>> bluetooth. It's possible such a bluetooth system could be used in
>>> combination of "Kryptoradio" like broadcasts to provide multiple
>>> blockchain references.
>>> * The additional payment_url approach is a bit sloppy of a solution
>>> in the PaymentDetails portion of the PaymentRequest. It would have
>>> been ideal to just change this from an optional field to a
>>> repeated field, however, the backwards compatibility in the
>>> protocol buffer format will provide the last item in the array for
>>> a repeated field (to a code that expects it to be an optional
>>> field), rather than the first. Because of this, backwards
>>> compatibility with https payment requests wouldn't work if the
>>> payment_url field is just changed to a repeated field.
>>> o Possible alternatives to what is described in the proposed BIP
>>> + Change payment_url to a repeated field and then reverse
>>> the order of the parameter numbers in the payment_url,
>>> compared to the bitcoin URL "r parameter".
>>> + Create an additional, new payment_url_multi repeated field
>>> (or some better name), and then leave the original
>>> payment_url field in there for backwards compatibility
>>> (and then maybe phase it out in the future).
>>> o Reference
>>> + https://developers.google.com/protocol-buffers/docs/proto#updating
>>> # "|optional| is compatible with |repeated|. Given
>>> serialized data 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 be greatly appreciated.
>>>
>>> --
>>> Andy Schroder
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 555 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150205/71578b57/attachment.sig>;