Joseph Gleason ⑈ [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-07-22 to 2018-12-03
💬 Posted a total of 9 messages
📚 Participated in the following categories: bitcoin-dev, patch
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 20:15:29

- reply

📅 Original date posted:2018-12-03
📝 Original message:I have a suggestion. If you are concerned about plausible deniability,
then it might make sense to just have the single mnemonic seed lead to a
single xprv key (as usual) and then do a private key derivation from that
based on a password string. The password can be simple, as it is based on
the security of the seed, just as long as the user feels they need for
deniability.
A simple reverse scheme like you describe would just be another thing a
person would know to check if given some seed so I don't see it as
providing much value, but I could be missing something.
On Mon, Dec 3, 2018 at 10:45 AM Steven Hatzakis via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi All,
>
> I've developed a method to check if a mnemonic is also valid when the
> words are put into reverse order (not the entropy), where a given 12 or
> 24-word mnemonic could be valid both in little endian and big endian
> format. I've coined these "Palindromic Mnemonics", but perhaps more
> user-friendly is "reversible mnemonics."
>
> Purpose:
> A checksum-valid reversible mnemonic allows two separate vaults to be
> connected to the same mnemonic string of words, where all a users must do
> is enter the words in reverse order (the last word becomes first, second to
> last becomes second, and so on) to access the secondary (reversed words)
> vault. This utility could provide multiple use-cases, including related to
> combinations with passphrases and plausible deniability, as well as
> conveniences for those wishing to use a separate vault tied to the same
> string of words.
>
> Security:
> For any randomly generated 12-word mnemonic (128-bits of security) the
> chances of it also being reversible are 1/16 (I believe), as a total of 4
> bit positions must be identical (4 bits from the normal mnemonic and
> another 4 bits from the reversed string must match). For a 24-word
> mnemonic, those values increase to 8 bits which need to match 8 bits from
> the reversed string, leading to about 1 in every 256 mnemonics also being
> reversible. While the message space of valid reversible mnemonics should be
> 2^124 for 12 words, that search must still be conducted over a field of 2^128,
> as the hash-derived checksum values otherwise prevent a way to
> deterministically find valid reversible mnemonics without first going
> through invalid reversible ones to check. I think others should chime in on
> whether they believe there is any security loss, in terms of entropy bits
> (assuming the initial 128 bits were generated securely). I estimate at most
> it would be 4-bits of loss for a 12-word mnemonic, but only if an attacker
> had a way to search only the space of valid reversible mnemonics (2**124)
> which I don't think is feasible (could be wrong?). There could also be
> errors in my above assumptions, this is a work in progress and sharing it
> here to solicit initial feedback/interest.
>
> I've already written the code that can be used for testing (on GitHub user
> @hatgit), and when run from terminal/command prompt it is pretty fast to
> find a valid reversible mnemonics, whereas on IDLE in Python on a 32-bit
> and 64-bit machine it could take a few seconds for 12 words and sometimes
> 10 minutes to find a valid 24-word reversible mnemonic.
> Example 12 words reversible (with valid checksum each way):
>
> limit exact seven clarify utility road image fresh leg cabbage hint canoe
>
> And Reversed:
>
> canoe hint cabbage leg fresh image road utility clarify seven exact limit
>
>
> Example 24 reversible:
>
> favorite uncover sugar wealth army shift goose fury market toe message
> remain direct arrow duck afraid enroll salt knife school duck sunny grunt
> argue
>
> And reversed:
>
> argue grunt sunny duck school knife salt enroll afraid duck arrow direct
> remain message toe market fury goose shift army wealth sugar uncover
> favorite
>
>
> My two questions 1) are how useful could this be for
> you/users/devs/service providers etc.. and 2) is any security loss
> occurring and whether it is negligible or not?
>
> Best regards,
>
> Steven Hatzakis
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181203/4182bf2d/attachment.html>

2023-06-07 20:14:11

- reply

📅 Original date posted:2018-08-28
📝 Original message:For what it is worth, electrum has a lot or possibly all of what you are
talking about since the electrum servers are designed to quickly answer the
queries of light clients. So right now, you could sync up an electrum
server or use an existing public one and send queries to it with json-rpc.
https://github.com/kyuupichan/electrumx/blob/master/docs/protocol-methods.rst
On Tue, Aug 28, 2018 at 5:36 AM Blockchain Group via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello everyone,
>
> I am C++ & Node.js developer. I want to propose making a new Bitcoin API
> that supports fast quering of Bitcoin blocks and transactions without the
> need for syncing with all previous nodes.
>
> In a typical case where I want to build a full fleged Bitcoin explorer cum
> wallet system on my end with external APIs, I need to sync my node and then
> query for the information I need to show separately. I am proposing a
> unified method of finding/quering the blockchain data with a standardized
> template containing minimal information about the actual mined block or
> transaction yet satify the need of what I want to query.
>
> I am working on making a template and a support mechanism on Node.js. I
> want to propose it as an improvement (BIP). It will be a great help to
> future web developers who want to make something similar.
>
> Thanks
> Sumit Lahiri.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180828/241a010d/attachment.html>

2023-06-07 20:11:36

- reply

📅 Original date posted:2018-04-10
📝 Original message:2) -1 doesn't mean conflicted, it means the transaction is not only
unconfirmed buy depends on another unconfirmed transaction.
1) Depends on what you mean by trusted. If you are giving the user online
access to something that costs you next to nothing to revoke if there is a
problem later, no problem. 0-conf is great. If you are pre-pairing
shipments and will be able to pull the box from the ship stream if there is
a problem, also no problem. If you are sending some other non-reversible
thing like crypto, then you might want to be careful. It really depends on
the value of your things and your tolerance of risk.
In my opinion, an zero-conf transaction is way way better than a credit
card preauth or a check in hand.
On Tue, Apr 10, 2018 at 1:34 PM Maksim Solovjov via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi,
>
> I have few questions regarding ListTransaction RPC call and I hope you can
> help me.
> Documentation for the RPC call is here:
> https://bitcoin.org/en/developer-reference#listtransactions
>
> 1. What does it mean for a transaction ( with 0 confirmations ) to be
> *trusted* or not?
> There is such field in the response of ListTransaction
> As far as I know bitcoin - nothing is trusted unless there are some
> numbers of confirmations.
> How does this value is set to true or false?
>
> 2. When does *confirmations* can be -1 ( conflicted )?
> What does it mean to have conflicted transaction?
> Is it about Transaction Malleability? Double Spend? or both?
>
> 3. *walletconflicts*. What if I add watch-only address to my bitcoind
> process.
> This address will not be a part of my wallet.
> Now, someone will pay me to this address and someone else will make
> Transaction Malleability ( for the sake of example, lets assume this second
> one will be confirmed, not the original one ).
> Will I get a first transaction in *walletconflicts* array when
> ListTransaction will return me second transaction in the response?
>
> Thank you in advance!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180410/212bdb4e/attachment.html>

2023-06-07 19:43:52

- reply

📅 Original date posted:2015-10-22
📝 Original message:I have done a lot of recent work on local key value stores, mostly for a
java electrum server I am working on.
I'd suggest considering LMDB. One downside is that it is memory mapped so
32-bit systems that need over 2gb of storage are right out. Other than
that, it is quite fast and seems reliable in my testing.
On Thu, Oct 22, 2015 at 2:37 PM Jeff Garzik via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Here is the beginnings of an implementation to replace leveldb with
> sqlite: https://github.com/jgarzik/bitcoin/tree/2015_sqlite
>
> It builds, but still needs work before passing tests.
>
> It was noted that leveldb is unmaintained, and this is part of researching
> alternatives that are maintained and reliable.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151022/50d97fdf/attachment.html>

2023-06-07 17:43:28

- reply

📅 Original date posted:2015-07-23
📝 Original message:I think our friendly original party worm is just trying to evaluate where
we are currently so arguments can be based on data.
I would tend to agree that there are performance improvements to be made
and would rather do that work than limit the block size.
On Thu, Jul 23, 2015 at 10:28 AM Matt Whitlock via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Great data points, but isn't this an argument for improving Electrum
> Server's database performance, not for holding Bitcoin back?
>
> (Nice alias, by the way. Whimmy wham wham wozzle!)
>
>
> On Thursday, 23 July 2015, at 5:56 pm, Slurms MacKenzie via bitcoin-dev
> wrote:
> > Similar to the Bitcoin Node Speed Test, this is a quick quantitative
> look at how the Electrum server software handles under load. The Electrum
> wallet is extremely popular, and the distributed servers which power it are
> all hosted by volunteers without budget. The server requires a fully
> indexed Bitcoin Core daemon running, and produces sizable external index in
> order to allow SPV clients to quickly retrieve their history.
> >
> > 3.9G electrum/utxo
> > 67M electrum/undo
> > 19G electrum/hist
> > 1.4G electrum/addr
> > 24G electrum/
> >
> > Based on my own logs produced by the electrum-server console, it takes
> this server (Xeon, lots of memory, 7200 RPM RAID) approximately 3.7 minutes
> per megabyte of block to process into the index. This seems to hold true
> through the 10 or so blocks I have in my scroll buffer, the contents of
> blocks seem to be of approximately the same processing load. Continuing
> this trend with the current inter-block time of 9.8 minutes, an
> electrum-server instance running on modest-high end dedicated server is
> able to support up to 2.64 MB block sizes before permanently falling behind
> the chain.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/947413eb/attachment.html>

2023-06-07 17:43:27

- reply

📅 Original date posted:2015-07-23
📝 Original message:I have concerns about the performance of the Electrum server software as
well. It seems to load data one block at a time (which normally makes
sense) and I think it is even single threaded on transactions inside the
block.
To try to addresses these issues, I made my own implementation of the
electrum server. It doesn't support UTXO (yet) but happily interacts with
all the clients I've tested. It is heavily multithreaded, uses mongodb as
a key value store and bitcoinj for block and transaction parsing.
https://github.com/fireduck64/jelectrum
You can hit a running instance at:
b.1209k.com:50002:s
or
b.1209k.com:50001:t
A synced node uses 347G of mongodb storage.
Here are the recent blocks imported, with number of transactions and import
time.
http://pastebin.com/cfW3C2L6
These times are based on having mongodb on SSD.
The CPU is 8 core Intel(R) Xeon(R) CPU E5430 @ 2.66GHz
I'd be happy to help with anything you need to evaluate it.
On Thu, Jul 23, 2015 at 9:01 AM Slurms MacKenzie via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Similar to the Bitcoin Node Speed Test, this is a quick quantitative look
> at how the Electrum server software handles under load. The Electrum wallet
> is extremely popular, and the distributed servers which power it are all
> hosted by volunteers without budget. The server requires a fully indexed
> Bitcoin Core daemon running, and produces sizable external index in order
> to allow SPV clients to quickly retrieve their history.
>
> 3.9G electrum/utxo
> 67M electrum/undo
> 19G electrum/hist
> 1.4G electrum/addr
> 24G electrum/
>
> Based on my own logs produced by the electrum-server console, it takes
> this server (Xeon, lots of memory, 7200 RPM RAID) approximately 3.7 minutes
> per megabyte of block to process into the index. This seems to hold true
> through the 10 or so blocks I have in my scroll buffer, the contents of
> blocks seem to be of approximately the same processing load. Continuing
> this trend with the current inter-block time of 9.8 minutes, an
> electrum-server instance running on modest-high end dedicated server is
> able to support up to 2.64 MB block sizes before permanently falling behind
> the chain.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/2fe297d2/attachment-0001.html>

2023-06-07 17:43:20

- reply

📅 Original date posted:2015-07-23
📝 Original message:That is how I read it as well.
On Thu, Jul 23, 2015 at 12:56 PM Marcel Jamin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> He measured the upload capacity of the peers by downloading from them, or
> am I being dumb? :)
>
>
> 2015-07-23 18:05 GMT+02:00 Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org>:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA256
>>
>>
>>
>> On 23 July 2015 10:19:59 GMT-04:00, slurms--- via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >This does not support the theory that the network has the available
>> >bandwidth for increased block sizes, as in its current state 37% of
>> >nodes would fail to upload a 20MB block to a single peer in under 20
>> >seconds (referencing a number quoted by Gavin). If the bar for
>> >suitability is placed at taking only 1% of the block time (6 seconds)
>> >to upload one block to one peer, then 69% of the network fails for 20MB
>> >blocks. For comparison, only 10% fail this metric for 1MB blocks.
>>
>> Note how due to bandwidth being generally asymetric your findings are
>> probably optimistic - you've measured download capacity. On top of that
>> upload is further reduced by the fact that multiple peers at once need to
>> be sent blocks for reliability.
>>
>> Secondly you're measuring a network that isn't under attack - we need
>> significant additional margin to resist attack as performance is
>> consensus-critical.
>>
>> -----BEGIN PGP SIGNATURE-----
>>
>> iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVsRCj
>> AAoJEMCF8hzn9Lnc47AIAIQbznavjd2Rbqxeq5a3GLqeYoI4BZIQYqfWky+6OQtq
>> yGRKaqPtGuES5y9L0k7efivT385mOl87PWnWMy61xxZ9FJgoS+YHkEx8K4tfgfA2
>> yLOKzeFSar2ROCcjHYyPWa2XXjRbNmiLzfNuQyIBArg/Ch9//iXUUM+GG0mChF5k
>> nUxLstXgXDNh5H8xkHeLi4lEbt9HFiwcZnT1Tzeo2dvVTujrtyNb/zEhNZScMXDc
>> UOlT8rBLxzHlytKdXt1GNKIq0feTRJNbreBh7/EB4nYTT54CItaaVXul0LdHd5/2
>> kgKtdbUdeyaRUKrKcvxiuIwclyoOuRQp0DZThsB262o=
>> =tBUM
>> -----END PGP SIGNATURE-----
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150723/1b3c9718/attachment.html>

2023-06-07 17:42:44

- reply

📅 Original date posted:2015-07-22
📝 Original message:I've thought about this as well, (in addition to making a java
implementation of the electrum server).
One solution would be for the client to combine all the addresses they are
interested in into a single bloom filter and send that to the server.
It would be pretty expensive for the server to check every address against
the bloom filter, but maybe for recent blocks (client can send how behind
they are) and for new transactions it wouldn't be bad at all.
The client could end up receiving a bunch of transactions they weren't
interested in but it would likely be manageable.
The client would also need to be fairly clever, including a set of static
ruse addresses and dynamic ruse addresses that they include in the filter.
That way a server would have a hard time using the bloom filter as a
fingerprint and figuring out which addresses are the real ones.
An alternative would be the server sending a bloom filter of addresses in
each block and then the client requesting entire blocks. This would use
more bandwidth, but it seems like it would be pretty simple to implement
and give good anonymity.
Basically the idea is to spend more bandwidth and CPU to keep the server in
the dark on what the client really wants.
On Wed, Jul 22, 2015 at 8:51 AM Thomas Voegtlin via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> Although Electrum clients connect to several servers in order to fetch
> block headers, they typically request address balances and address
> histories from a single server. This means that the chosen server knows
> that a given set of addresses belong to the same wallet. That is true
> even if Electrum is used over TOR.
>
> There have been various proposals to improve on that, but none of them
> really convinced me so far. One recurrent proposal has been to create
> subsets of wallet addresses, and to send them to separate servers. In my
> opinion, this does not really improve anonymity, because it requires
> trusting more servers.
>
> Here is an idea, inspired by TOR, on which I would like to have some
> feedback: We create an anonymous routing layer between Electrum servers
> and clients.
>
> * Each server S publishes a RSA public key, KS
> * Each client receives a list of available servers and their pubkeys
> * For each wallet address, addr_i, a client chooses a server S_i, and a
> RSA keypair (K_addr_i, k_addr_i)
> * The client creates a list of encrypted requests. Each request contains
> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
> * The client chooses a main server M, and sends the list of encrypted
> requests to M
> * M dispatches the client's requests to the corresponding servers S_i
> (without the client's IP address.)
> * Each server decrypts the requests it receives, performs the request,
> and encrypts the result with K_addr_i
> * M receives encrypted responses, and forwards them to the client.
> * The client decrypts the encrypted response with k_addr_i
>
> What do you think? What are the costs and benefits of such an approach?
>
> (Note: this will not work if all servers, or a large fraction of them,
> are controlled by the same entity that controls M)
>
>
> Thomas
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/0cc44782/attachment-0001.html>

2023-06-07 17:42:44

- reply

📅 Original date posted:2015-07-22
📝 Original message:I would recommend the following solution as a decent compromise between
complexity and privacy:
1) Encourage electrum server operators to have their servers reachable as
tor hidden services (.onion addresses)
2) Make sure server discovery works well with .onion addresses
3) Make the privacy a user configurable setting:
- None - Allows any server connection type
- SSL - Requires SSL at least, no plain text
- Tor - Requires tor, no direct TCP
- Multi-Tor - Uses a variety of tor paths to reach a variety of servers
(maybe configurable number of servers)
Default should be 'SSL' probably.
On Wed, Jul 22, 2015 at 3:20 PM Eric Voskuil via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I should add that the obvious resolution to this set of problems is to
> use a distinct Tor route for each Bitcoin address, not to reinvent Tor
> and reproduce its community. So ultimately this is easy to implement,
> but the downside is performance.
>
> But it's important to keep in mind that poor-performing perfect privacy
> for address monitoring is trivial to achieve - just sync the full
> blockchain.
>
> Presumably if you don't trust a server to protect your privacy, you also
> don't trust it with your money. So any robust privacy optimization would
> at least be designed to support partial (SPV) chain clients. It would
> also need to support wallet restoration from backup.
>
> The level of privacy will always be a performance trade-off. The ideal
> solution would allow a client to balance privacy against performance.
>
> e
>
> On 07/22/2015 09:30 AM, Eric Voskuil wrote:
> > Hi Thomas,
> >
> > The scheme is essentially onion routing. The set of {M} are entry nodes
> > and the set of {S} are exit nodes. The weaknesses are as you would see
> > in an analogous TOR implementation:
> >
> > (1) The lack of relay nodes {R} make collaboration between any subset of
> > {M} and {S} trivial.
> >
> > (2) OR is a mixnet, so the size of the network matters a lot.
> >
> > (3) The directory is a perpetual weakness.
> >
> > (4) Content is visible to the exit node (or the final service). This
> > means each address must be passed via a distinct route to prevent
> > correlation.
> >
> > e
> >
> > On 07/22/2015 08:51 AM, Thomas Voegtlin via bitcoin-dev wrote:
> >> Hello,
> >>
> >> Although Electrum clients connect to several servers in order to fetch
> >> block headers, they typically request address balances and address
> >> histories from a single server. This means that the chosen server knows
> >> that a given set of addresses belong to the same wallet. That is true
> >> even if Electrum is used over TOR.
> >>
> >> There have been various proposals to improve on that, but none of them
> >> really convinced me so far. One recurrent proposal has been to create
> >> subsets of wallet addresses, and to send them to separate servers. In my
> >> opinion, this does not really improve anonymity, because it requires
> >> trusting more servers.
> >>
> >> Here is an idea, inspired by TOR, on which I would like to have some
> >> feedback: We create an anonymous routing layer between Electrum servers
> >> and clients.
> >>
> >> * Each server S publishes a RSA public key, KS
> >> * Each client receives a list of available servers and their pubkeys
> >> * For each wallet address, addr_i, a client chooses a server S_i, and a
> >> RSA keypair (K_addr_i, k_addr_i)
> >> * The client creates a list of encrypted requests. Each request contains
> >> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
> >> * The client chooses a main server M, and sends the list of encrypted
> >> requests to M
> >> * M dispatches the client's requests to the corresponding servers S_i
> >> (without the client's IP address.)
> >> * Each server decrypts the requests it receives, performs the request,
> >> and encrypts the result with K_addr_i
> >> * M receives encrypted responses, and forwards them to the client.
> >> * The client decrypts the encrypted response with k_addr_i
> >>
> >> What do you think? What are the costs and benefits of such an approach?
> >>
> >> (Note: this will not work if all servers, or a large fraction of them,
> >> are controlled by the same entity that controls M)
> >>
> >>
> >> Thomas
> >> _______________________________________________
> >
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150722/da02ff32/attachment.html>